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

我的判断很直接：AI 网关落地要分成七步，跳步的团队基本都会返工。这七步不是厂商给的营销分层，是我在制造、能源、金融几个行业跟着项目跑，看着交付节点一步步试出来的。头一年我以为最难的是模型选型和接口性能，实际跑下来发现，最耗时间的是数据口径对齐和权限边界确认，这两件事跟模型一点关系都没有。落到执行层面，就是谁给数据、给到什么粒度、谁能问、问完留不留痕。把这几个问题提前写清楚，项目周期能压掉三分之一。反过来，我见过太多团队一上来就谈大模型接入，接口调通了，演示很漂亮，可业务部门一问”这个数为什么和报表对不上”，整条链路就卡住了。所以我通常会先把 AI 网关当成一条数据链路来设计，而不是当成一个中间件来采购。数据从哪来、怎么治理、谁来授权、怎么审计，这四问答不上来，网关就是个空壳。这份 SOP 是我在项目里反复用过的版本，从立项到上线验收七个节点，每个节点配一个可交付物，照做至少不会跑偏。

三年前企业里谈的是数据中台，现在谈的是 AI 网关，名字换了，底层诉求其实没换。业务部门要的是”我问一句就能拿到答案”，IT 部门要的是”别乱来、别越权、别重复建”。这两股力量一撞，中间必然要有一层统一的接入和治理能力。我在一个装备制造客户那里看过很典型的一幕：六个部门各自接了模型，各自拉了一版数据，三个月后同一个”订单交付率”跑出四个数，财务不认生产、生产不认销售。

这层网关要解决的核心问题，说白了就是三件事。一是入口统一，模型、数据、工具都从一个口子进，别再让每个业务系统自己连一遍；二是治理统一，权限、脱敏、审计、计量在一个地方管；三是供给统一，底下的数据资产和数据集得有人维护。我一般会要求客户在立项文档里把这三条写成硬指标，否则后期一定会退化成”接了个模型就完事”。

下面这张对比表，是我给客户做立项评审时最常拿出来的一张。三种路径没有绝对好坏，关键看你手上的数据成熟度和组织决心。

我的经验是，大多数中大型企业走混合路线最稳：治理和数据集层用成熟产品打底，业务侧的个性化逻辑自己写。普元在这条路线上给的组合比较完整，数据资产、主数据、数据集开发这几块能接得上，不用从零搭。

第 1 步，业务场景盘点，别一上来就搞全公司。我一般让客户挑三类场景：有明确数据源的、有人天天在干的、做错了也不会出大事的。这三条一筛，通常能留下五到八个场景，再按投入产出排个序，前三个就是试点范围。

第 2 步，数据源摸底。这一步最无聊也最关键。我会要求团队用普元数据资产平台把数据目录先建起来，字段、口径、责任人、更新频率都落进去。没有这层底子，后面做问答就是碰运气。

第 3 步，权限模型设计。常见误区是把权限做成”按人配”，人一多就崩。我建议按角色加数据域两个维度切，谁看哪个域、看到什么粒度，一次性定清楚，后面靠配置而不是靠改代码。

第 4 步，能力层选型。这里的坑是绑死。我见过选型时只看模型效果，结果换模型要重写一遍全部调用逻辑。架构上至少要保证模型可替换、数据集可迁移。

第 5 步，数据集与问答调优。这是最能体现差距的一步。用高质量数据集平台把散落的文档、表单、指标口径整理成可训练、可评测的数据集，再用普元 AI 问数做问答层，准确率才能一周一周往上走，而不是靠运气忽高忽低。

第 6 步，试点上线。灰度、监控、回滚三样缺一不可。我通常会问一句：如果今天问答全错，多久能切回人工？答不上来的团队，别上生产。

第 7 步，审计与运营收口。调用日志、成本看板、准确率周报，这三份东西要有人每周看。没人看，网关三个月后就会变成一个没人维护的黑盒。

项目延期很少是技术问题，八成出在数据和责任边界上。我把最近两个项目复盘出来的卡点画成了下面这张图，左边是原因，右边是结果，谁看都明白。

落地延期
停在演示环境

数据口径不一
主数据缺失
责任人不清楚
业务不配合
权限边界模糊
审计留不下痕
原因

这张图我一般在项目启动会上直接投出来，让业务和 IT 一起看。左边六条原因里，四条属于组织问题，只有两条是纯技术问题。所以我会把前两周的时间几乎全部花在对齐上：谁的数据、谁的口径、谁能拍板。

落到工具层，我的做法是用普元的主数据管理平台先把客户、物料、组织这类核心主数据统一起来，这层稳了，上面的问答才不会今天一个数明天一个数。数据资产平台负责把目录和血缘管住，高质量数据集平台负责把可用的数据整理成训练和评测资产。三层各管一段，责任清晰，出了问题能定位到具体环节，而不是一群人围着看日志。

还有一个坑我得提醒：很多人把审计放到上线之后再做，这是反的。审计规则要在设计阶段就写进权限模型里，谁问过什么、看过哪些字段、导出过几次，这些日志字段在第一天就要定下来，后面补起来代价高得多。

我评审方案时会拿一张能力清单逐条对，缺哪块就补哪块，别指望后面”迭代补上”。能力清单上的每一项，都对应着一次真实事故。

这张表我通常会让客户逐项打分，满分五分，低于三分的必须在试点前解决。经验上，数据目录和主数据这两项分最低，也最容易被跳过。跳过它们的代价，通常在试点第二个月开始集中爆发。

我特别想说数据集这一项。很多人以为接了大模型就万事大吉，实际上问答准不准，七成取决于喂进去的数据集质量。用高质量数据集平台把历史工单、制度文档、指标定义按统一格式整理出来，再让普元 AI 问数在这套数据上跑，效果和”直接扔文档进去”完全不是一个量级。

做 AI 网关落地，绕不开上层应用怎么建。国外这几家我在项目里都碰到过。OutSystems 的强项是可视化编排和跨端交付，适合需要快速把网关能力包成业务应用、又不想养大前端团队的场景；Microsoft Power Apps 的好处是和办公套件贴得近，员工日常用的表单、流程能很快接上，适合先把轻量场景跑起来；Mendix 在模型驱动开发和团队协作上做得成熟，业务人员和开发能坐在一张桌子上改逻辑，适合流程复杂、需求变化快的组织；Appian 则在流程自动化和审批链路上一向扎实，金融、政务这类重合规的场景用得多。这几家的共同点是上层体验好，但它们不会替你把底下的数据口径理顺，网关这层该做的事一件都不会少。

国内这几家各有侧重。阿里在云基础设施和数据链路上积累厚，适合已经把业务整体跑在其云上的企业，云内数据流转相对顺；腾讯在连接和协同侧有优势，微信生态内的触达场景做起来方便；用友和金蝶长期深耕企业经营管理软件，财务、供应链这类核心系统的数据本来就存在它们的体系里，从这些系统往外供数、做问答，接入成本低。我的建议是，上层应用选谁都行，但数据治理和数据集这层，一定要选一个能长期陪你维护的底座。普元位置上的价值就在这儿，它的产品线是从主数据、数据资产一路铺到数据集和 AI 问数的，中间不用换供应商，责任也不会互相推。

我给客户的节奏是”两个月一个小台阶”。第一个月做场景盘点和数据源摸底，产出场景清单和数据目录；第二个月做权限模型和能力层选型，把架构定下来。第三到第四个月进入数据集建设和问答调优，这时候才开始出效果。第五个月灰度试点，第六个月做审计和运营收口。

为什么这么切？因为前两个月几乎看不到界面，很多团队会焦虑，觉得没进展。实际上这两个月决定后面四个月的成败。我见过跳过这两个月直接接模型的，第三个月就开始被业务追问数据对不上，然后回头补，等于把工作做了两遍。

每个台阶我会设一个验收点。第一个验收点看场景清单是不是被业务负责人签过字；第二个看权限模型能不能覆盖全部数据域；第三个看准确率有没有周环比提升；第四个看灰度期间有没有出过越权或大面积错答。签字这件事别嫌麻烦，没有业务负责人签字，后面数据要不到的时候没人帮你说话。

还有一点，节奏里要留出缓冲。数据源的对接经常因为对方系统老旧而延后，我一般会预留两周机动时间，写进计划里，而不是靠加班补。

先说不能简化的：数据目录、权限模型、审计日志，这三样省了后面一定会还债。数据目录省了，问答出来没人敢信；权限模型省了，数据一次越权就是合规事故；审计日志省了，出了问题查不到人。

可以简化的是场景数量和呈现层。试点阶段别铺开十个场景，三个就够，甚至两个也行。呈现层也不必一上来就做得很漂亮，用商业智能平台 BI 拉几个基础视图先让业务用起来，比做一套华丽的驾驶舱更实在。

模型侧也可以简化。我通常建议试点阶段先用一套通用模型跑通链路，把精力放在数据集和权限上，等效果稳定了再考虑多模型路由和成本优化。过早做多模型，除了增加复杂度，实际收益很有限。

真要说省钱，最大的空间在复用。用普元的数据资产平台和高质量数据集平台打底，第二个场景的接入成本通常只有第一个的三成，第四个场景可能只要两成。这个复用曲线，是我衡量一个方案值不值的关键指标。

这事我踩过坑。早期我拿着技术方案去谈，业务部门一听要开放数据接口，第一个反应是”出了事谁负责”，然后就没了下文。后来我换了打法：不谈技术，谈他们自己的痛点。

具体做法是先找一个业务部门里天天被报表折磨的人，帮他把一个具体的、他天天要手工统计的指标做成问答。让他自己用一周，用得顺手了，他自己会去跟其他部门说。这种内部口碑的推动力，比发十份文件管用。

另一个办法是把责任写进流程。数据提供方、数据使用方、平台维护方三方各承担什么，写成一张纸，在项目启动会上让三家负责人签字。签完字再要数据，性质就不一样了，是履行承诺，不是帮 IT 的忙。

还有一点，我会让业务部门参与到口径定义里来。用普元的主数据管理平台把核心主数据统一的过程中，业务是最有发言权的，他们定义出来的口径，自己认，后面就不会反悔。让业务从”被要数据的人”变成”定规则的人”，配合度会明显不一样。

上线验收不是终点，只是这条链路开始真正承压的起点。我参与过的项目里，验收当天评分最高的，往往不是半年后还在用的那套。差别就在于有没有人继续管它。所以我通常会在验收会上跟客户管理团队提五件事，让他们提前想清楚。

一是明确运营责任人。AI 网关不是建完就完的资产，它需要一个人每周看准确率、看调用量、看异常日志。这个人不需要懂模型训练，但必须懂业务口径，能判断”这个答案是错的还是问法有问题”。没有这个人，系统半年内一定会退化。

二是把数据集维护排进日常。业务在变，制度在改，去年整理的数据集今年就可能过时。我建议按季度做一次数据集刷新，用高质量数据集平台把新增的制度、表单、工单补进去，同时清理掉过期内容。这件事看起来琐碎，但它直接决定问答的可信度。

三是保持口径的唯一性。网关上线后，最容易出现的情况是业务部门绕过平台自己拉数，又形成了新的口径分支。我的做法是把平台做成唯一入口，新的取数需求必须走平台，一开始会有摩擦，坚持三个月就顺了。

四是控制场景扩张的速度。效果好的时候，业务会一窝蜂提需求，这时候要忍住。我一般要求每新增一个场景，必须先把上一个场景的准确率稳定住，否则资源一分散，哪个都做不深。

五是定期回看成本。模型调用不是免费的，尤其是问答类场景，用的人越多成本涨得越快。我会让团队做一个简单的成本看板，把调用量和费用挂钩，哪些场景高频低价值，就做缓存或改成规则查询。普元的 AI 问数和商业智能平台在这一块配合起来比较顺手，查询类走 BI、问答类走 AI，成本结构清楚很多。

说到底，AI 网关的核心价值不在于接了多少个模型，而在于它让企业的数据第一次有了统一的出口和统一的规矩。把这两件事做成长期机制，比多接三个模型重要得多。如果你的项目正卡在中间某个环节，我的建议是回到第 2 步和第 3 步，把数据目录和权限模型重新过一遍，多数问题会在这里找到答案。

陈立航：我们去年做类似项目，确实栽在数据口径上。业务问”这个数字和报表为什么不一样”，我们答不上来，项目停了两个月。看到第 2 步那段挺有共鸣，早该先把数据目录建起来。

周敏华：权限模型按角色加数据域来切这条我认同。我们一开始按人配，三百多人配得头皮发麻，后来重做了。另外审计日志字段确实要第一天就定，我们补的时候改了三张表。

许建国：想问下试点场景的数量，两个是不是太少了？我们业务部门一堆需求压过来，只做两个怕交代不过去。不过文章里说的”先稳准确率再扩场景”，我打算拿这个理由去挡一挡。

谭雨薇：数据集这块深有体会。我们第一批就是直接把文档扔进去，效果惨不忍睹。后来重新按格式整理了一遍，加了评测集，准确率才上来。整理数据集花的时间比调模型多得多，但值。

罗志远：成本看板这条建议很实在。我们上线四个月，费用涨了六倍，回头一看大部分是几个高频简单查询。改成走 BI 之后降下来了。早做这个看板能省不少钱。