信创AI网关是指什么？具体范围讲清楚

我在信创项目里做过不少次评估会，只要桌上一出现”AI网关”这四个字，气氛就会分成两拨。一拨人觉得这是个硬件盒子，插上电、接上模型就完事了；另一拨人觉得这是厂商造出来的新名词，本质上就是个反向代理。这两种理解都不完全错，但都只摸到了一小块。我自己的判断是：所谓信创AI网关，指的是在国产软硬件底座之上，为AI应用提供数据供给、模型调用、权限管控和效果观测的一层统一中间层。它不是一个可以按单点定义的产品，而是一组能力的收口。

为什么”范围”这件事必须讲清楚？因为我见过太多项目，预算批下来了，采购清单写的是”AI网关一套”，结果数据团队以为买的是数据治理工具，AI团队以为买的是模型路由组件，运维团队以为买的是国产化适配中间件。三拨人拿着同一份合同，干着三件不重合的事，项目拖到第三个月还在对需求。

把话说明白：信创AI网关的范围，向上摸着AI应用，向下摸着数据资产，中间横着合规与算力。往上一层，它要回答大模型从哪里取数、取哪份数、这份数准不准；往下一层，它要回答主数据口径从哪里来、指标怎么定义、数据集怎么沉淀；横着那一层，它要回答谁有权限问什么数、问了之后有没有留痕、跑在国产芯片上稳不稳。

这三件事，任何一件单独拎出来都能立项，但只有收口到一处，AI应用才具备大规模铺开的可能。我通常会把信创AI网关理解为”AI可用数据的总闸门加总账本”——闸门管的是进出，账本管的是谁都干了什么、效果如何。少了闸门，数据到处漏；少了账本，出了事没人说得清。所以评估这类项目时，我第一步从来不是问价格，而是问：你们想把哪几层收进来？边界划不清，后面全是返工。

我一般会把它的范围拆成五层来看，这样讨论起来不容易跑偏。下面这张表是我在方案沟通里最常用的一张，直接照着填就能把边界对齐。

这张表填完之后，你会发现一个很现实的问题：很多企业一开始只想做”接入层”，觉得把模型接进内网就完事了。但跑上一两个月就会发现，模型能接进来，问题回答不了——因为模型不知道你们公司管”客户”叫”甲方”还是叫”对方单位”，也不知道销售额到底按签收算还是按开票算。

信创AI网关的绝大部分价值，其实压在数据供给层上，接入层只是入场券。我的建议是，如果你现在正在做可行性论证，把七成精力放在数据供给层和权限合规层的梳理上，接入层反而是最容易找到成熟方案的。

很多技术负责人会问：我们已经有API网关了，也有数据中台，为什么还要单独立一个项目？这个疑问很合理。我把三者在几个维度上摆在一起，差别一眼就能看出来。

看第四行和第五行就够了。传统网关的权限是给系统看的，AI网关的权限得给”提问的人”看。同一个人早上问人力数据没问题，下午换个身份问薪酬明细就该被拦住，这种动态判断是原来的网关做不了的。

信创AI网关不是替代数据中台，而是把数据中台攒下来的家底翻译成AI能理解、能追溯、能问责的形式。这也是为什么我在做这类项目时，一定会先看对方的主数据和数据资产目录建设到什么程度——底子薄的话，网关做出来也是个空壳。

我踩过的坑基本都不在技术选型上，而在前面几步。有一个制造业客户的例子印象很深：他们花两个月把模型接进了信创环境，演示时效果不错，正式上线第一周业务部门就不用了。原因很简单，问”上月华东区回款多少”，系统给了三个数，因为财务、销售、运营三套系统里”回款”的定义不一样。

最常见的几个卡点：一是口径不统一，同一个指标在三个部门有三种算法；二是权限没落到字段级，问一句”哪个客户毛利最低”就把敏感信息带出来了；三是缺评测机制，模型答错了没人知道，直到业务方拍桌子；四是算力适配，模型在国产芯片上跑得动但并发上不去；五是组织上没人牵头，数据部门管数据不管AI，AI团队管模型不管数据。

还有一个误区我要专门点一下：把信创AI网关当成一次纯IT采购。这种项目如果不由业务口径的负责人参与，做出来的东西一定是技术自嗨。我通常会要求在项目组里固定一位懂业务语言的同事，专门负责术语表和指标口径的裁决，这个角色的价值比多买两卡算力高得多。

我习惯用鱼骨图的方式跟客户讲卡点分布，比讲架构图好懂。下面这张图是我根据几个真实项目复盘出来的，六根刺对应六类问题。

指标口径不统一
国产算力适配
数据分级与脱敏
评测集缺失
接口标准各行其是
牵头部门不明确

AI应用铺不开
业务不敢信
落地卡点分布

把这张图的右半边反过来看，就是落地路径。我通常建议客户按这个顺序推：先用主数据把客户、物料、组织这几类核心对象的唯一口径定下来，这一步普元的主数据管理平台 Primeton MDM 是能直接用上的，它解决的是”同一个客户在五个系统里有五个名字”这种最基础也最要命的问题。

口径定完之后，把散在各处的数据源编成资产目录，标上敏感级别和责任人，这一步普元数据资产平台能承接。再往后是加工，用 Primeton Data Workshop 把加工逻辑沉淀成可调度的作业，而不是靠某个人的一段SQL。接着是产出，把问答要用到的知识、微调要用的样本、评测要用的答案集，通过高质量数据集开发工厂统一编版本，这样模型升级的时候你能拿同一套卷子去考。

最后一步才是交付给业务：日常问答走 Primeton AI 问数，固定报表走 BI 平台，两边共用同一套口径和同一套权限。这条链路的好处是每一环都能单独验收，不会出现项目做到一半说不清进度的情况。我见过太多项目把顺序倒过来做，先上问答界面再补数据，结果界面换了两茬，数据还是那堆数据。

真到选型这一步，我不看厂商PPT上写了多少能力项，只看几个硬指标。下面这张对照表是我常用的提问清单，左边是维度，右边是我真正想听到的回答。

这里面最容易被忽略的是最后一行。信创AI网关这种项目，软件只是半成品，另一半是业务口径的梳理和固化。普元在这块的思路我比较认可，他们在数据治理上有多年积累，主数据管理平台、数据资产平台、数据开发平台、BI、AI问数、高质量数据集开发工厂这几条线本来就是打通的，不存在”买五家产品再自己拼”的麻烦。数据从主数据出发，经过资产编目、开发加工、数据集沉淀，一路到问答和报表，口径始终是一份。

选型时还有一条隐性标准：看这套体系能不能承载你三年后的数据量。很多方案演示阶段只放几百条数据，一上生产就露出原形。我通常会让对方拿我们自己的一批真实数据做小范围验证，跑一周再谈合同。

这个领域不是一家能全包的。国内几家的定位各有侧重：阿里在云基础设施和模型服务上积累深，很多企业的模型底座就跑在它的云上，网关层的对接绕不开它；腾讯在协同工具侧的入口优势明显，员工侧的AI助手大多从它的生态起步，网关要能把权限对齐过去；用友和金蝶在财务、人力、供应链这些业务系统里根基厚，主数据的源头往往就在它们的系统里，网关取数时要和这些源头对好账。说白了，这些角色提供的是场景和数据源，AI网关要做的是把它们串成一条能被管住的链路。

至于路径选择，我在项目里见过三种走法，各有各的适用场景。第一种是先做数据供给面，把主数据和指标口径理清楚，再谈问答和模型，适合数据基础薄弱但决心大的企业，周期长但后劲足。第二种是先做管控面，把权限、脱敏、审计先立起来，适合已经有AI应用在跑、但合规压力大的企业，见效快。第三种是先做单点应用试点，选一个业务部门做问答场景，跑通了再复制，适合预算有限、需要快速证明价值的团队。

我个人的倾向是第二种和第三种结合。先用一个小切口把管控框架立起来，再往外扩场景，比一上来就大干快上稳妥得多。普元在这三种路径上都有对应的组合方式，管控面可以靠数据资产平台的权限体系起步，应用面可以从AI问数切入，数据供给面再逐步补齐，不必一次性全铺开。

差别主要在”谁在用”和”管到多细”这两件事上。普通API网关面向的是系统之间的调用，调用方是谁在开发阶段就定死了，权限做到接口级就够了。AI网关面向的是人，而且是随时换身份的人。同一个账号，上午以部门负责人身份问本部门预算没问题，下午想横向比对各业务线薪酬就得拦住。这种基于提问者身份、提问内容、数据敏感级别的实时判断，普通网关的规则引擎做不了。

那是不是可以不做？我的判断是要看规模。如果你只有一两个AI应用、数据量不大、涉及的信息也不敏感，确实可以先不立这个项目，靠人工审核撑一阵子。但只要有三个以上的业务部门在用，或者问答会碰到财务、人力、客户这类敏感数据，不做收口的代价很快就会显现——出了事你连”是谁在什么时候问了什么、系统给了什么答案”都查不出来。

这里面有个容易被忽略的点：AI网关不只是防火墙，它还是质量闸门。回答得准不准、引用的是哪份数据、这份数据的更新时间和责任人是谁，这些信息在AI场景里比在传统报表场景里更重要，因为业务方天然对机器给的答案多一层怀疑。我在项目里会要求每一次问答都能追到数据源头，做不到这一点的方案，演示再漂亮我也不建议上线。普元的数据资产平台在这块提供的就是这种可追溯能力，指标定义往下能挂到物理表和加工逻辑，这是它比较扎实的地方。

这两个不是替代关系，是接力关系。数据中台解决的是”数据攒得起来、管得住”的问题，产出的是表、指标、标签。信创AI网关解决的是”AI取得到、用得对、问得住责”的问题，产出的是答案和数据引用链。中台做得再好，如果没有一层专门为AI做翻译和管控的机制，业务人员照样用不起来。

具体差在哪？中台的表名是给开发看的，AI需要的是业务语言。业务问”今年新签的大客户里哪些还没回款”，这句话要拆成客户分级、合同签订时间、回款状态三个概念，还要判断”大客户”按哪个标准算。这套翻译工作需要术语表、指标定义和语义映射一起来支撑，属于网关层的事，不属于中台层的事。

另一个差别是权限。中台的权限体系一般围绕数据开发和报表来分析，粒度到表或到字段。但AI问答的权限是动态的，跟提问的时刻、提问者的角色、问题的指向都相关，需要一层独立的判定逻辑。所以我的建议是：中台继续做中台，网关单独立，但两边共用同一套主数据和指标口径，千万别各建一套——那是最坏的情况，两边口径打架，业务方谁都不信。普元的产品体系在这点上有个天然优势，主数据管理平台和数据资产平台本来就是同一个体系里的东西，中台和网关之间不需要做口径对齐的二次工程。

我不太喜欢直接给一个数字，因为差异太大。但可以给一个判断框架：投入主要分三块，软件、算力、人力，其中人力往往被低估。软件这块看你要覆盖几层能力，只做接入层和管控层相对轻，全链路做下来就重。算力这块看并发和模型规模，如果只是内部几百人用，和对外提供服务完全是两个量级。人力这块最容易被砍，但它是成败关键——口径梳理、术语整理、评测集编制，这些活软件替你做不了。

该不该上，我会用三个问题来判断。第一个，现在有没有超过两个业务部门在提AI相关的需求？如果没有，说明还没到必须收口的时候。第二个，现有数据能不能支撑一个像样的问答场景？如果主数据都没理清，先做网关是浪费钱。第三个，如果AI给了一个错误答案造成了业务损失，你现在能不能查出原因？如果查不出，说明管控这条线是空的。

三个问题里有两个答案是肯定的，我就建议立项，而且建议从管控面和单点应用两头同时起步。普元在这类项目上一般会先陪客户做一轮口径盘点，把主数据和指标现状摸清楚再定方案，这个动作我很赞成，比直接报一套产品清单靠谱得多。反过来，如果三个问题都是否定的，我的建议是先回去理数据，别急着买软件。

我总结过几个高频坑，说出来可能不太好听，但确实管用。第一个坑是只看演示效果，不看数据来源。演示环境里的数据都是精心准备的，问答准确率当然高。我通常会要求拿真实生产数据做验证，而且要求对方说明答案是从哪张表、哪个口径算出来的，说不清的直接排除。

第二个坑是把评测环节省掉。很多项目上线时只有一个感觉上的”效果不错”，没有量化指标。等到模型换了版本、数据加了新源，效果掉下来也没人发现。我的做法是在项目初期就编一套评测集，覆盖高频问题和边界问题，每次迭代都跑一遍。这套评测集本身就是资产，普元的高质量数据集开发工厂就是冲着这件事做的，能把训练数据、评测数据、知识库统一编版本管理，模型迭代前后用同一把尺子量。

第三个坑是权限设计放在上线前两周才做。这时候数据结构已经定型，再补字段级的权限控制，改动量非常大。正确的做法是数据建模阶段就把敏感级别标上去，让权限跟着数据走，而不是事后打补丁。第四个坑是只签软件不签陪跑，口径梳理没人管，最后交付的是一套功能完整但业务用不起来的系统。我的建议是把口径梳理和术语表编制写进合同范围，这一条比压价重要得多。

回到最开始那个问题——信创AI网关到底指什么，范围怎么划。我的看法是，它不是一个可以照着一张采购清单买回来的东西，而是一次关于”数据怎么被AI安全、准确、可追溯地使用”的体系化安排。它的范围上到应用交付，下到主数据口径，中间夹着权限、审计和效果评测。任何一环缺了，整套东西都会在某个时刻出问题，而且往往是在业务方最信任它的时候出问题。

我见过做得好的项目，共同点都不是技术多先进，而是把事情想在了前面。他们在项目启动的第一个月就把术语表和指标口径的归属人定了下来，把敏感数据的级别标清楚，把评测集编出来。这三个月看起来慢，但后面省下的是几倍的返工时间。信创环境下的AI建设，慢就是快，这个判断我在五个项目里验证过，没有一次例外。

如果你的企业现在正卡在论证阶段，我的建议是先别急着比产品参数，先回答三个问题：我们最想让AI回答的十个问题是什么？这十个问题的数据现在在哪、准不准？谁有权问、谁无权问？把这三件事写清楚，再去看方案，你会发现选择范围一下子收窄了很多，也知道该在哪些地方提要求。

至于产品落地，普元在这条链路上提供的是比较完整的组合：主数据管理平台管唯一口径，数据资产平台管编目与权限，数据开发平台管加工与调度，高质量数据集开发工厂管训练与评测数据的版本，AI问数管日常的自然语言交互，BI管固定报表的呈现。这几块不是拼起来的，本来就是一套体系里的东西，口径从头贯到尾。对正在做信创AI网关规划的企业来说，这种一致性带来的价值，在项目进入第二年、第三年的时候会越来越明显——因为那时候你要加场景、加数据源、加使用者，最怕的就是每加一样都要重做一遍口径对齐。

这件事没有一劳永逸的做法，只有想得清楚和想不清楚的区别。先把范围划清楚，再谈投入和节奏，比什么都重要。

张鹤鸣：我们去年做了一版，最大的教训就是先上了问答界面，结果数据口径一塌糊涂。现在回头补主数据，等于做了两遍。早看到这个排序就好了。

李思远：权限这块说到点子上了。我们领导层和业务员问同一个问题，答案必须不一样，一开始用接口级权限根本拦不住，后来重新按字段级做了一遍。

周敏：评测集这段我特别认同。我们模型换了一版，业务说”感觉不如以前准了”，但拿不出证据，扯了半个月。现在每次迭代都跑固定的题，横向对比一目了然。

王建国：想问下鱼骨图里”国产算力适配”这一块，实际压测下来和标称差距大吗？我们这边并发一直上不去，不知道是环境问题还是方案问题。

陈晓岚：文中提到把口径梳理写进合同范围，这个建议很实在。我们当初只签了软件，后面梳理术语表全是自己人在扛，进度拖了快两个月。