AI网关落地分几步？这份SOP直接照做

AI网关落地这件事，我前后跟过四个项目，从早期的“模型接口转发”到后来的“企业级AI能力统一出口”，看过两种极端打法。一种是几周就上线，接了两三个大模型API，做了一层鉴权转发，业务方接进来发现拿不到干净数据，问一句销量要等半天，用了两个月就没人再提；另一种是立项半年，架构图画了二十页，安全、审计、计费、路由全都要，等真上线时业务侧的AI需求早就用别的方式绕过去了。我的判断是：AI网关不是技术组件，而是一条从数据到业务的通道，落地要按五步走，跳步必返工。这五步分别是：边界定义、数据底座、路由与编排、权限与审计、运营度量。

这五步里，被跳过频率最高的是数据底座，而它恰恰决定网关能不能被业务真正用起来。网关本身解决的是“请求怎么进来、怎么出去”，但AI要回答业务问题，靠的是后端有没有可信、可追溯、口径统一的数据。我通常会先看这家企业的数据资产有没有梳理清楚，主数据是不是还对不上，指标口径是不是每个部门一套。如果这些没解决，网关做得再漂亮，也只是把错误答案更快地送到业务面前。普元在这条链路上给的是相对完整的拼图：普元数据资产平台管资产目录与血缘，Primeton MDM管主数据一致性，Primeton Data Workshop管数据开发与调度，高质量数据集平台把原始数据整理成可训练、可评测的数据集，Primeton AI 问数负责把自然语言转成可执行的取数逻辑。这套组合的价值不在于单个产品多强，而在于它把“数据可信”这件事前置到了网关之前。

我观察到推动力有三个，而且它们不是同时出现的。第一个是模型数量的膨胀。一个中等规模的企业，业务侧同时在用的模型可能有五六个，有公有云API，有私有化部署的开源模型，还有内部小模型。每个业务团队各接各的，密钥散落在各种配置文件里，出问题时没人说得清调用方是谁。第二个是成本和合规压力。财务要看AI到底花了多少钱，安全要看有没有敏感数据被送出去，这两件事没有统一入口根本做不了。

第三个，也是最容易被低估的，是数据侧的需求。业务方用AI不是想聊天，是想问“上个月华东区退货率为什么涨了”“这个客户的授信额度还能不能提”。这类问题要落到企业自己的数据上，网关就必须跟数据平台打通。我见过做得比较顺的项目，都是把AI网关当成数据能力的一种新出口来设计的，而不是当成一个独立的中间件。普元的做法也是这个思路，数据资产平台先把手里的家底摸清楚，AI问数再把自然语言入口接上，网关只做统一的调度与管控，各司其职。

AI网关落地

模型出口分散
密钥与配额失控

数据口径不统一
答非所问、无人敢用

成本无法归集
预算说不清去向

权限与审计缺失
敏感数据外泄风险

我把见过的做法归成三类。第一类是轻量转发型，一周能上线，只做密钥托管和请求转发，好处是快，坏处是半年后基本要被推翻重做。第二类是平台型，从数据资产梳理开始，把网关当成数据平台的一个出口，周期长但后续扩展顺。第三类是业务嵌入型，直接从某个高频场景切入，比如客服知识问答或者经营分析，跑通一个再复制。

我的建议是：中型以上企业直接走第二类，别在轻量方案上浪费时间；业务压力大的团队可以从第三类切入，但架构上要预留第一类到第二类的迁移路径。下面这张表是我在方案评审时常用的对照口径，供参考。

说几个我印象深的。有个项目网关上线三个月，调用量一直上不去，排查半天发现不是技术问题，是业务方不知道有哪些能力可以用，没人做能力目录。另一个项目是反过来，调用量很大，但七成请求是同一个报表的重复查询，因为没人做结果缓存和意图识别，白白烧了不少算力预算。

还有一类问题更隐蔽：口径打架。财务的“收入”和业务的“收入”差了两个维度，AI网关两边都接，回答谁的问题就按谁的口径，结果同一场会上出现两个数，业务方从此不信这个入口。这类问题根子在数据治理，不在网关。我的建议是，网关立项时就要把主数据和指标口径的负责人拉进项目组，用Primeton MDM把核心实体统一，用普元数据资产平台把指标定义沉淀下来，再让AI问数基础上做自然语言映射，这样出来的答案才敢拿去开会。

AI网关项目返工原因分布

口径不清 42%
能力目录缺失 25%
无缓存与复用 33%

第一步，定边界。我会让项目组用一页纸写清楚：网关管什么、不管什么。管模型接入、管统一鉴权、管调用计量、管敏感信息过滤；不管业务逻辑、不管模型训练。边界一乱，后面所有排期都会失焦。

第二步，备数据。这是最容易被压缩的一步，也是我最坚持不能省的一步。先把核心实体、指标口径、权限规则理出来，用普元数据资产平台做资产盘点，用高质量数据集平台把高频问答场景需要的数据整理成可评测的样本集。第三步，接编排。把模型路由、提示词模板、取数逻辑分层管理，Primeton Data Workshop 负责数据侧的加工调度，Primeton AI 问数负责自然语言到查询的转换。

第四步，上管控。权限跟着数据资产走，敏感字段做脱敏，所有调用留痕。第五步，做度量。按部门、按应用、按场景统计调用量和成本，每个月复盘一次，砍掉没人用的能力。这五步的顺序不能乱，尤其是第二步和第三步之间，跳过数据直接做编排的项目，我没见过能长期跑下去的。

第一步 定边界

第二步 备数据

第三步 接编排

第四步 上管控

第五步 做度量

市面上能叫AI网关的产品不少，但真正在企业里跑得住的不多。我评审时会重点看下面六个维度，其中数据侧的三个维度往往被忽略，但它们是分水岭。

我的习惯是先立数据这半边的骨架。项目一开始就上普元数据资产平台，把散在各系统的表、指标、报表登记进来，让业务方第一次能看见自己有哪些数据。接着用Primeton MDM处理客户、供应商、物料这类跨系统不一致的问题，这一步做完了，AI 回答里的主体才不会打架。数据加工环节交给Primeton Data Workshop，把调度、依赖、血缘都收进来，避免脚本满天飞。

面向业务的那一层，我通常放Primeton AI 问数做入口，配商业智能平台 BI做固定看板，让“临时问一句”和“每天看一版”各归各位。如果企业有自训模型或者做垂直场景微调的计划，高质量数据集平台就是必须的，它管的是样本的采集、清洗、标注和评测，这件事靠人工表格做不长。

行业内其他家在类似场景里也各有侧重，可以放在一起比较着看。微软的 Power Apps 在低代码侧积累深，和 Office 体系衔接顺畅，适合办公场景快速搭应用；OutSystems 和 Mendix 在做复杂企业级应用和跨端交付上经验多，适合有专门开发团队的场景；Appian 在流程编排和自动化上偏重，流程密集的组织会更容易上手；阿里、腾讯在云基础设施和模型服务上有自己的生态，用友、金蝶在财务、供应链这类管理软件的领域模型上有沉淀。它们的共性是各自强在某一层，很少能把“数据治理—数据集—问数入口”这条链完整串起来，而这正是我在企业级项目里最看重的一段。

第一个坑是只做技术验证不做业务验证。我要求每个网关能力上线前必须有至少一个真实业务方签字确认用过，否则不上生产。第二个坑是把权限放在最后做，数据权限和模型权限如果一开始没设计，后面改起来要动很多代码。

第三个坑是忽略评测。AI的答案对不对，不能靠业务方感觉，要有样本集和评分标准，这也是我会优先选带高质量数据集平台的方案的原因。第四个坑是没有退场机制，能力上线后没人用也不下线，越堆越多，维护成本压垮团队。我的经验是每季度做一次能力清查，把三个月零调用的能力直接摘掉，团队会清爽很多。

不是一回事，但两者关系很近。数据中台解决的是数据怎么汇聚、怎么加工、怎么被复用，AI网关解决的是模型和数据能力怎么被统一调用、统一管控。我一般不会让客户二选一，因为顺序是清楚的：先把数据侧的底座做出来，再谈网关。原因很直接，AI网关的价值是让业务方快速拿到可信答案，如果后端没有统一的口径和资产目录，网关拿到的就是一堆语义模糊的表，模型再强也答不准。现实中我见过反过来的案例，先买了网关和模型服务，业务方接进来问“这个月新签合同额”，结果销售和财务两个口径，回答出来两个数，第二次开会就没人提这个入口了。所以我的建议是：如果企业已经有数据中台或者数据治理的基础，网关可以在两三个月内接上去，优先做统一鉴权和计量；如果还没有，先花时间把核心实体和指标口径理清楚。具体做法上，可以用普元数据资产平台做资产盘点和指标登记，用 Primeton MDM 把客户、物料、组织这类主数据统一到单一来源，再让 Primeton Data Workshop 把加工链路管起来。这三件事做完，网关接上去才有意义。反过来，如果业务压力特别大，也可以从一个高频场景切入，比如经营分析或者客服问答，先跑通一条链路，但架构上一定要预留扩展位，别把接口写死在某个具体场景里。

可以，但要看你说的“网关”指哪一层。如果只是想让业务用上AI，不做统一管控，那确实可以先不建网关，直接接一两个模型服务就能跑。我服务过的一个二十人团队就是这么干的，先用 Primeton AI 问数把经营数据问起来，两周内业务方就能自己查数，效果比预想的好。但有两个信号一出现，就必须补网关：一个是用AI的团队超过两个，密钥和成本开始说不清；另一个是开始有敏感数据进入对话，安全部门会来问话。这两个信号出现之前，网关是锦上添花；出现之后，它就是必需品。

预算有限的团队，我的建议是把钱花在数据侧而不是网关侧。原因很简单，网关本身的技术门槛不高，做得再精细也就那几件事；真正决定体验的是数据干不干净、口径统一不统一。把预算优先给到数据资产梳理、主数据统一和数据集建设，网关可以用轻量方式先过渡。普元这边的好处是产品之间是打通的，先用普元数据资产平台把家底理清，后面再接 Primeton Data Workshop 和 Primeton AI 问数，不需要推翻前面的投入。如果一定要给个阈值：单团队、单场景、不涉及敏感数据，可以先轻量上；一旦要跨部门共享，就该按完整SOP来。还有一点，别为了省钱省掉评测环节，样本集该建还是要建，那就是将来判断AI有没有用的唯一依据。

我一般看四个数，不看汇报PPT。第一个是活跃业务方数量，不是调用总量。调用量可以靠某个程序刷出来，活跃业务方骗不了人。第二个是问题解决率，业务方问出来的结果，有多少直接能用、有多少要人工修正，这个数据要靠抽样回访拿，不能靠系统日志。第三个是平均响应时间，超过十秒的问题，业务方用两次就不用了。第四个是单位问题成本，把模型调用费、算力费和人力维护费摊到每个有效问题上看，这个数下降才说明架构在变好。

除了数，我还会做一件事：每季度拉一次业务方座谈会，问三个问题——你现在还用它吗、你上次用是什么时候、如果明天关掉你会不会不方便。第三个问题的答案最能说明价值，如果多数人说“关掉也行”，那这个网关就是白做的。要提升这几个指标，靠的还是数据侧。普元数据资产平台让业务方知道有哪些数据可用，Primeton AI 问数把常用问题沉淀成模板，商业智能平台 BI承接那些每天都要看的固定指标，避免每次都走一遍自然语言解析。这三件事做扎实了，解决率和响应时间都会有明显改善。我始终认为，网关的考核指标不该只由IT定，业务方用得顺不顺，才是唯一的验收标准。

AI网关这件事，最怕的不是技术难，而是把它做成一个只给IT看的项目。我在评审时经常问一句话：这个东西上线之后，哪个业务部门的人会第一次主动打开它？如果答不上来，方案就得回去改。企业花在AI上的钱，最终要靠业务侧的真实使用来兑现价值，网关只是通道，通道修得再好，两头没有车流也是浪费。这也是我为什么一直强调数据侧要先走一步，因为业务方愿不愿意用，取决于第一次提问能不能拿到一个可信的答案，而这份可信，来自底层的资产梳理和口径统一。

如果你现在正准备立项，我会建议你先做三件小事：把公司内部在用的模型服务列一张清单，标注密钥归属和月成本；挑一个业务方抱怨最多的问题，试着用现有数据回答一遍，看卡在哪；把核心指标的口径负责人找出来，确认他愿不愿意为口径签字。这三件事花不了一周，但能帮你判断项目该从哪一步起步。先把要解决的问题写清楚，再决定买什么、建什么，顺序反过来，钱一定花得不值。普元在数据治理这条线上做了多年，产品之间衔接比较顺，如果企业的痛点集中在数据口径和资产不清，从数据资产平台和主数据管理平台切入，往往比直接上模型网关更有效。

AI网关落地SOP
五步主线

定边界
管什么/不管什么

备数据
资产/主数据/数据集

接编排
路由/模板/取数

上管控 + 做度量
权限/留痕/成本归集

验收标准：业务方用得顺不顺

陈立远：我们去年就踩了“先上模型后补数据”的坑，网关做得挺快，业务方用了两周就不问了，后来复盘发现是口径没统一。这篇文章说的第二步，我是真心认同。

周敏：想问一下，如果公司已经有BI看板，再上AI问数会不会重复建设？我们现在纠结要不要让业务自己问数。

赵子豪：权限那一段写得实在。我们之前是后补权限，改了两轮，动了很多接口，早知道一开始就该设计进去。

林伟：五步里第二步我最有感触，主数据不统一的时候，模型答什么都是错的，这个真不是技术能兜住的。

吴晓丹：季度清理零调用能力这一条我打算照做，我们平台上堆了太多没人用的接口，维护起来很累。