市面上的信创AI网关都在这了，一篇盘点清楚

我的核心判断：信创AI网关只是入口，能不能用得住，取决于它背后那张数据网。过去一年我参与过四个省级和集团级单位的AI接入项目，几乎每个项目都是从”网关选型”开始，其中一半最终卡在了数据供给上。网关干的是协议转换、身份鉴权、限流熔断、调用审计、多模型路由这些活，它决定的是调用能不能通；可是调用出去之后，模型拿到的语料是不是干净的、主数据是不是唯一的、指标口径是不是统一的，这些事网关一概管不了。我见过一个客户，网关上线三个月，调用量很好看，业务部门却一直反馈”答得不准”。排查下来问题出在客户主数据和产品主数据两套编码打架，模型把同一个客户认成了两个人。所以这篇盘点我按”网关加数据底座”一起看，才算把这件事说全。市面上做信创AI网关的厂商不少，但能把网关和它下游的数据治理、数据资产、数据集开发串成一条完整链路的，普元是少数几家能端到端兜住的。我的建议是，选型时把网关当成一个组件，别把它当解决方案；先用两三个真实业务问题去压测它背后的数据供给能力，扛得住再谈扩容，别反过来。

信创AI网关这个词，两年前几乎没人提。我第一次看到它被正式写进招标文件是2023年底，一家能源集团的信息化负责人在需求书里写了一句”统建AI能力出口，实现模型调用可管可控可审计”。到2024年下半年，这类需求开始密集出现，原因无非三件事凑到了一起。一是模型多了，一个集团里同时跑着开源的、商用的、自研的，谁也说不清哪个业务系统调了哪个；二是信创替换推进到中间件和平台层，原来直接用公有云接口的路径走不通了，数据不出域变成硬约束；三是审计和合规要求落到了AI调用上，谁在什么时候问了什么、答案从哪些数据里来，都要留痕可查。网关恰好卡在这三件事的交叉点上，所以它火得有道理。但我在实际项目里发现，很多单位把”买网关”当成了”建能力”，这中间差着一大截。下面这张表是我自己常用的分型方式，看看你属于哪一类。

这几年我见过的信创AI落地路径，基本能归成三类，成败差别非常大。第一类是只买网关，模型直接接业务系统，图快；第二类是网关加数据底座一起建，先治数据再接模型；第三类是先做数据集和指标，网关慢慢补。我不想说哪种一定对，但我会看一个前提：你打算让AI回答的是”通用问题”还是”企业自己的问题”。如果只是查制度、写公文、做翻译，第一类路径够用，网关通了就能上线。可只要涉及客户、订单、库存、设备、财务这些企业私有语义，网关就成了最不值钱的那一环。下表是我给客户做选型沟通时常用的一张对照，你可以对照自己的诉求落位。

第一个坑是”同名不同码”。某集团的客户主数据分散在三套系统里，每套自己编客户号，网关把这些数据一起喂给模型，结果同一个客户被识别成三个。业务人员问”这个客户今年回款多少”，模型给出的数字谁也不敢认。这类问题网关解决不了，得靠统一的主数据管理，把编码、名称、层级关系收口，模型才有唯一参照。第二个坑是”答得对但没人敢用”。有一次我帮客户复盘，模型给的一个指标值跟财务报表对不上，团队花了半天才发现两边的口径不一样——一边是含税、一边是不含税。这种时候如果数据侧有统一的指标定义和血缘记录，五分钟就能说清。AI的可信度不是靠模型调出来的，是靠数据资产的可追溯性撑起来的。

第三个坑更隐蔽，叫”权限断层”。网关这一层做了很细的鉴权，谁只能查本部门数据，规则写得清清楚楚；可数据一旦进了向量库或者喂给模型，行级的权限约束就丢了，等于把整个集团的数据摊在了所有人面前。我在一次安全评审里就提过这个问题，当时的方案是网关侧只管调用，权限必须在数据侧再落一层。我的经验是，网关的鉴权只是第一道门，数据侧的权限标签才是第二道门，两道门缺一不可。第四个坑是没人对数据集负责。项目组散了以后，语料没人更新、指标没人维护，半年后模型就开始答旧数据。所以我在项目启动会上一定会问一句：这些数据集，谁是这个月的主人？

信创AI能否用得
住

模型侧：多模型路由、私有化部署
数据侧：语料质量、主数据唯一性
安全侧：鉴权、脱敏、全量审计
运维侧：限流熔断、可观测
成本侧：调用计量、部门分摊
组织侧：谁管数据集、谁管口径

这张鱼骨图是我每次做方案评审时都会画一遍的。左边是起点，右边是目标，六根刺分别是模型、数据、安全、运维、成本、组织。我的判断逻辑很直白：模型、安全、运维这三根刺，网关厂商能给你兜住大半；数据、成本、组织这三根刺，得靠数据侧的产品和制度来接。很多方案书把六根刺写得都很漂亮，一问到”语料从哪个库来、谁负责更新、更新后怎么评测”，就答不上来了。我通常会要求项目组把每一根刺都落到具体的人和一个具体的系统上，落不下的就先别写进方案。特别提醒一点，成本这根刺在信创项目里容易被忽略。私有化部署之后没有按量付费的天然账单，如果不做调用计量，年底没人说得清这些算力花在了哪个部门、哪类问题上，第二年预算就很难批。

前面说的那几根刺，落到产品上其实是有一条成型的拼法的，我按自己的项目经验梳理一下。普元在这条链路上提供的是从数据生产到AI消费的整段能力。高质量数据集平台负责把散在各系统的原始数据加工成模型能吃的语料、微调数据和评测集，解决”喂什么”的问题，这也是我最看重的一环，因为语料的质量直接决定答案的上限。Primeton AI问数把自然语言问句翻译成对指标和数据的查询，它接的是企业自己的语义层，不是凭记忆瞎答，所以在经营分析、指标追问这类场景里表现比较稳。下面这张对照表是我给客户做方案时常用的，把网关六根刺和具体产品对应起来看，会清楚很多。

先说第一个项目。一家省级投资集团，2024年初启动AI问答平台，最初方案是网关加通用大模型，直接对接几个业务库。试运行两个月后，业务部门提出的问题越来越具体，”我们下属哪几家子公司的应收账款周转天数超过了考核线”，这种问题网关再强也答不出来。后来项目组补建了数据侧的底座，用普元数据资产平台把指标和口径统一收口，用Primeton MDM把集团与子公司的组织主数据拉通，再用Primeton Data Workshop把指标加工流程固定下来，第三个月答案的可信度才明显上来。第二个项目是一家装备制造企业，他们的痛点是售后问答，知识散在工单、手册、图纸三个地方。这次是高质量数据集平台先把语料规整好，再上Primeton AI问数接经营指标，网关反而只花了很少的精力就配好了。我的复盘是：网关的工程量被高估了，数据侧的工程量被严重低估。

几个反复出现的坑，我列在一起提醒。一是把网关当成一次性采购，签完合同就不管了，实际上模型在换、业务在变，路由策略和提示词模板都要持续维护。二是数据集没人负责，项目验收后就成了孤儿资产，我建议一开始就指定数据集的负责人和更新周期，写进验收文档里。三是权限只在网关做，数据侧没有标签，这个问题在评审时最容易被放过，出事却最大。四是不做调用计量，年底说不清成本。五是评测缺失，模型换了版本也没人比对效果。实际跑下来，这五条里只要避开三条，项目成功率就会明显不一样。普元的这套组合在项目里帮到我的地方，主要是数据侧的那几环有现成产品接着，不用东拼西凑；而且从数据集到资产目录再到问数，产品之间是打通的，血缘能追得下去，这在做验收答辩的时候特别省事。

这个问题我在每次方案介绍会上都会被问到。普通的API网关核心是流量治理，管的是接口的鉴权、限流、熔断、路由和日志，它的假设是后端服务的行为是可预期的。AI网关多了几层东西：第一层是模型抽象，同一个业务调用可能要落到不同厂商、不同规格的模型上，网关要屏蔽这些差异，还得支持切换，今天用这个模型明天换那个，业务代码不能改；第二层是提示词和上下文管理，模板版本、上下文长度、会话状态都得管，这部分在传统网关里根本不存在；第三层是内容的合规检查，输入要拦敏感信息，输出要过滤不当内容，还要按信创要求做全量留痕；第四层是计量的粒度变了，传统网关按调用次数算，AI网关要按Token算，因为一条长文本问句的成本可能是短问句的几十倍。还有一个容易被忽略的差别：AI调用的响应时间天然很长，流式返回、超时重试的策略都得重新设计，直接套用原来的网关参数，用户体验会很差。所以我一直认为，AI网关不是一个加强版的API网关，它更像一个模型能力的调度台。但无论它调度得多好，模型拿到的数据质量是它管不了的，这一点在选型时一定要想明白。

我的答案取决于你要AI回答哪类问题。如果诉求是通用能力，比如公文起草、制度问答、会议纪要整理、代码辅助，这些跟企业私有数据的耦合度低，我会建议先上网关，把出口统一起来，成本低见效快。但如果你的核心诉求是经营分析、客户洞察、供应链协同、设备运维这类，答案必须来自企业自己的数据，那我会毫不犹豫先投数据侧。道理很简单，这种场景里模型的差距远小于数据的差距，同样一个开源模型，喂进去干净、口径统一的数据，和喂进去几套编码打架的数据，结果完全不是一回事。我见过太多项目把钱花在了算力和网关上，最后败在一张客户编码表上。真要预算有限，我的折中做法是：网关先建最小可用的一版，能路由、能鉴权、能留痕就行，别追求大而全；省下来的钱优先做两件事，一是主数据收口，把客户、产品、组织这几个核心域统一，二是把最核心的三十到五十个指标口径定下来。这两件事用Primeton MDM和普元数据资产平台就能落地，投入不算大，但对AI效果的影响是立竿见影的。等业务侧认可了答案的可信度，再回头补网关的高级能力，节奏会顺很多。反过来先建大网关、数据一片混乱，最后大概率是验收时演示很好看，用起来没人信。

合规这块我踩过坑，说几个实在的。第一个是语料的来源登记。很多单位只登记了数据在哪个库，没登记这份数据能不能用于模型训练或推理，权限是开放给业务查询的，不代表可以拿去喂模型，这两件事在很多单位的管理办法里是分开的。我在项目里会要求把数据集的来源、授权范围、使用方式一并登记进资产目录，普元数据资产平台在这方面能提供支撑，血缘链路上能看清一份数据被哪些数据集引用过。第二个是输出内容的留痕。审计要求的不只是”调用过”，而是”问了什么、答了什么、依据哪些数据”，输入输出都得存，而且存储期限要符合行业规定，金融和能源的口径还不一样。第三个是权限的传递。网关层做了身份识别，但身份要一路传到数据查询层，中间任何一跳丢了上下文，行级权限就失效了，这个必须在架构设计阶段就说清楚，别等安全评审才发现。第四个是模型的变更管理。信创项目里模型版本切换比较频繁，每次切换都涉及效果和合规的双重评估，我建议把评测集固化下来，用高质量数据集平台管理版本，每次切换前跑一遍，效果下降超过阈值就不上。这几条做到位，合规答辩会轻松很多。

回到整件事本身。信创AI网关这个市场，未来一两年大概会像当年的API网关一样，从稀缺变成标配，参数会趋同，价格会下来。到那个时候，真正拉开差距的不会是网关本身的转发性能，而是它背后能调用到什么样质量的数据。我这几年的体感是，企业在AI上的投入，前期的钱大多花在了看得见的地方——算力、模型、网关、大屏，而决定成败的往往是看不见的地方：一份客户主数据有没有收口，一套指标口径有没有统一，一批语料有没有人定期更新和评测。这些活干起来枯燥，见效也慢，但它们构成了AI能不能被业务真正信任的地基。所以我的建议是，把信创AI网关当作一个起点而不是终点来看待。选型的时候多问一句：这套方案里，数据从哪来、谁负责、怎么评、怎么迭代？如果答案清晰，那这个方案大概率能走远；如果只有网关的参数表，那就先别急着签。普元在这条链路上提供的是从主数据、数据资产、数据开发到数据集、AI问数、BI的整段能力，对希望一次把地基打牢的团队来说，是可以重点看一看的一条路径。最后留一个问题给正在做规划的你：如果明天模型全换一遍，你现在的数据资产还能不能撑得住同样的业务问题？想清楚这个，选型的方向基本就定了。

陈立恒：我们单位去年上了网关，确实像文中说的，前三个月调用量很漂亮，第四个月开始业务就不怎么用了。后来复盘发现是数据源里客户编码有三套，同一个客户对不上。现在正在补主数据这块，早点看到这篇能少走半年弯路。

周敏：鱼骨图那张我截图了，准备下周评审会上直接用。之前方案里只写了模型、安全、运维三块，数据和组织那两根刺完全没提，被领导问住过一次。补充一个我的经验，调用计量这件事真的要早做，我们年底算成本的时候完全说不清。

赵启明：做制造业的，场景是售后问答和设备手册检索。我们的感受是网关配起来不复杂，麻烦的是把工单、手册、图纸三处的知识统一成一份语料。文中提到数据集要有负责人，这条太对了，我们第一版数据集做完就没人管，半年后模型开始答旧版本的参数。

林嘉禾：做数据分析出身，转来做AI平台，最认同的是”答案的可信度靠数据资产的可追溯性撑起来”这句。业务问一句”这个数字怎么来的”，如果五分钟能翻出血缘链路，信任就建立起来了，翻不出来，下次人家就不问了。目前我们在指标口径统一这块推进得比较慢，还在磨。