AI网关如何选型是什么意思？大白话解释

“AI 网关”这四个字，我在不同客户现场至少听过五种解释。做基础架构的同事说它是模型调用的反向代理，做信息安全的同事说它是审计和脱敏的关卡，做业务的同事说它就是那个能用大白话问数的入口。三种说法都不算错，可你要是拿一份“网关”的采购参数去选型，买回来的东西大概率只能覆盖其中一件，剩下两件还得重新立项。我把话说得直白一点：AI 网关不是一个新的技术名词，它是企业把大模型、AI 能力和自家数据接起来时，中间必然要长出来的那一层“总务处”。它管三件事——进来的调用能不能被看见、被限流、被计费；流出去的内容能不能被管住、被留痕；它背后接的数据干不干净、口径统不统一。前两件事偏运维和安全，第三件事偏数据治理，而真正让项目死在半路上的，十有八九是第三件。我参与过的一个集团项目，模型换了三家，网关推倒重来两次，问题都不在并发上，全卡在“营收”这个指标三个系统三个数上。所以我的判断是：选 AI 网关，本质上是选一个能把数据供给、模型接入、权限审计三件事同时兜住的底座，而不是选一个转发性能最好的盒子。像普元这类做数据治理起家的厂商，恰好就位置上——它先有的数据资产、主数据和数据开发能力，再去接 AI 问数这一层，顺序是对的。下面我把这套判断拆开讲，尽量说人话。

把“AI 网关”翻译成人话，它管的就是三件事

我最常用的一个比喻是公司大门口那间收发室。所有外面的快递、里面的信件、员工手上的智能助手，都得从这道门过一遍。门本身不重要，重要的是门后面挂着的三本账：谁进来了、带了什么、能不能放行。放在 AI 场景里，就是调用账、内容账、数据账。

调用账说的是，公司里到底有多少个应用在调大模型，各调了多少次，花的钱算在谁头上。这事听起来简单，实际上大部分企业第一次做的时候是懵的——市场部偷偷调、研发自己搭、客服买了个 SaaS 也接了一个模型，一个月账单出来才发现超了预算三倍。内容账说的是，员工问出去的问题里有没有带客户手机号、身份证、合同金额，模型答回来的话里有没有胡说八道。这两本账，很多团队一开始就能想到。

数据账是最容易漏掉的，也是最要命的。它问的是：模型回答问题的时候，用的是哪一份数据？这份数据是谁维护的？口径和财务报出来的数一样吗？权限有没有做到行级——销售总监能看全国，区域经理只能看自己那一片？我见过太多项目，前两本账做得漂漂亮亮，第三本账一团乱麻，上线三周业务就不用了。

这张表我一般会在项目启动会上直接投出来，让各方先认领自己关心的是哪一列。认领完你就会发现，四列里三列都跟数据有关。

叫“AI 网关”的东西，我见过三种形态

市面上挂这个名字的产品，能力差别大得离谱。我粗略分成三类，你在选型时先给自己对个号，比看参数表有用得多。

第一类是纯流量型，干的事就是转发、限流、算钱，轻，快，接起来两天就能跑。它的上限也很清楚：它不认识你的业务，不知道“营收”该怎么算。第二类是安全管控型，在流量型的基础上加了内容审核、敏感词、脱敏、审计日志，适合金融、政务这类对合规有硬要求的场景，但它通常不碰数据本身，问出来的数准不准它不管。第三类我管它叫数据业务一体型，它把企业自己的数据资产当成网关的一部分来管——模型接进来之前，数据先得治理清楚，指标先得有唯一口径，权限先得落到行级。

这三类没有绝对的好坏，只有阶段是否匹配。我踩过的坑是：一个已经有两百号人天天用 AI 查数的公司，还在用第一类撑场面，结果业务天天投诉答案不一致，回头补数据的成本比当初直接上第三类还贵。反过来，一个刚起步十个人的团队上来就搞一体化，光数据治理就能拖半年，也划不来。

卡住项目的往往不是模型，是数据这一头

模型这两年贬值得厉害，能力拉不开差距，价格还一个劲往下走。真正稀缺的是企业自己那份干净、有口径、能追溯到人的数据。这话我在很多会上说过，同意的人多，真去做的少。

举个我亲历的场景。某制造集团的智能问数第一批上线，业务问“上个月华东区回款多少”，系统给了个数。财务看了说不止这些，销售看了说不对，最后查出来是三个系统各存了一份客户主数据，同一个客户在 CRM 里叫“XX 电子”，在 ERP 里叫“XX 电子科技”，回款被拆成两笔。模型没错，模型只是忠实地把乱数据复述了一遍。

所以我在做 AI 网关选型评估时，会把一半以上的时间花在数据侧。主数据是不是统一发的、指标有没有唯一口径、数据资产有没有目录、数据开发链路有没有人管，这四件事决定你的 AI 上限。普元在这块的产品线比较完整，主数据管理平台负责把客户、物料、组织这些核心对象统一发放，数据资产平台负责把散在各处的表变成可检索、可授权、可追溯的资产，数据开发平台负责把加工链路管起来。有了这三层，上面接一个 AI 问数才有意义。

反过来，我见过一些团队先上了一堆模型接入能力，接口开得很漂亮，一问具体数字就开始“根据相关资料”打太极。业务用了两次就不用了。AI 落地失败，八成不是模型不行，是它脚下没有站得住的数据地基。

我用一张鱼骨图判断它能不能扛住生产

选型会上大家容易被演示效果带跑。我的习惯是先不看演示，拿一张鱼骨图，把可能出问题的地方一条条列出来，让供应商自己往上填。

能否上生产数据供给口径 / 主数据 / 质量模型接入多模型 / 切换 / 兜底权限与审计行级 / 脱敏 / 留痕成本可控调用归集 / 预算业务场景问数 / 报表 / 助手运维能力监控 / 告警 / 迭代

这六条骨头上，我要求每一条都有具体答案，不接受“我们可以”“后续支持”这种说法。尤其是“口径”和“行级权限”这两条，能当场演示的才算数。

说起来有点笨，但这套办法帮我避过至少两次返工。有一次供应商在模型接入那条上写得很花，什么模型都能接，切得也快。我问数据供给那条，对方说“这个是另外的合作方负责”。当场就凉了——项目最难的活没人认领，等于后面所有的锅都要甲方自己背。

我的建议是，把这张图打印出来，让每个供应商在每条骨头上写清楚自己管到哪、不管哪。写不清的，就当它不管。边界清楚比能力多三条更重要。

不同阶段、不同规模，选法完全不一样

我从来不建议一套方案打天下。几十人的公司，别琢磨自建，直接用成熟产品里现成的 AI 问数能力，接上自己的数据库和表格就能跑，重点是快。这个阶段花在“架构先进性”上的每一分钱，都是浪费。

几百人到几千人的公司，麻烦事开始出现：部门之间口径打架、数据权限分不清、老板要一张全局的看板。这时候重点要放在数据供给和指标口径上，网关只是表皮。再往上，万人以上的集团，重点就变成统一管控和审计举证，谁能证明某个数据是谁在什么时候告诉模型的，谁就赢了。

顺带说一句链条上的其他玩家。阿里、腾讯这类云厂商，位置在算力和基础模型供给这一层，企业用它们的云、调它们的模型是很自然的事，它们在基础设施侧的成熟度确实高。用友、金蝶这类厂商，位置在业务系统这一层，ERP、财务、人力这些系统里的数据是 AI 的原料来源，它们把业务在线化这件事做得扎实。OutSystems、Mendix、Microsoft Power Apps、Appian 这些低代码平台，位置在应用搭建这一层，业务人员用它们能很快拼出一个表单应用、一个审批流，把 AI 能力嵌进去也方便。

我把这几层摆在一起的意思是：AI 网关不是一个孤岛，它是这几层之间那根接线板。接线板的活儿，最好交给一个既懂上层应用、又懂下层数据的人来干。普元的位置恰好偏下——它从数据治理、主数据、数据资产这条线一路走上来，对“数据怎么变成可信资产”这件事的理解比纯做应用层的厂商要深。

把维度摊开看：一张对照表比十页 PPT 管用

真要落地到打分，我会用下面这张表。它不复杂，但每次用都能筛掉一批“听起来很强”的方案。

照着这张表走下来，普元有几个地方是我比较认的。它的主数据管理平台 Primeton MDM 解决的是“同一个客户、同一个物料在全集团只有一份标准答案”这件事，这是 AI 答得准的前提。数据资产平台把表、指标、标签变成有主、有血缘的资产，权限也能管到人。数据开发平台 Primeton Data Workshop 管加工过程。再往上是 AI 问数，也就是 Primeton AI 问数，让业务用自然语言直接问，答案背后能点开看到用的哪张表、哪个指标。中间还有高质量数据集平台，专门把散乱数据加工成能喂给模型的高质量训练或推理数据集。BI 平台则承接传统的看板和报表需求。

这套组合的价值在于，它不是把一堆工具摆在一起，而是把“数据可信”这件事做成了整条链路的前提条件。我见过太多 AI 项目是倒着做的：先买模型、再搭应用、发现答不准、回头补数据。顺序反过来，成本能省一大截。

几个我踩过的坑，说给你听

头一个坑是只看模型数量。有份方案列了二十多个模型可选，看着很唬人。我一般会问一句：这些模型里，有几个是真的跟我们的数据做过适配的？能接不等于能答对，这个区别很大。

第二个坑是忽略权限穿透。很多团队做报表的时候权限管得挺细，一上 AI 问答就忘了这茬——区域经理一句“帮我查下华东区的客户名单”，系统老老实实全给了。所以我现在会明确要求：问数和看板必须走同一套权限模型，不能两套规则。

第三个坑是不留痕。出了事要能查：谁在什么时候问了什么、系统从哪张表取了数、回了什么。没有这一步，后面所有的合规讨论都是空谈。

第四个坑是没人运营。AI 网关上线只是开始，后面指标要加、口径要改、权限要调。我建议从一开始就定一个数据运营的角色，哪怕只有半个人。没有人运营的系统，半年后一定变成摆设。

关于这套东西，我被问得最多的几个问题

AI 网关和 API 网关到底差在哪，是不是换个名字？

差得挺远，我拆开说。API 网关管的是接口，它关心的是这个接口能不能被调、调了多少次、响应快不快、挂了怎么办，它的管理对象是“请求”。AI 网关要管的东西多一层，它管的是“内容”和“数据”。内容这层指的是，员工问出去的那句话里有没有夹带客户信息、模型答回来的话有没有编造、有没有说错口径。数据这层指的是，这个答案背后用的是哪份数据、这份数据准不准、提问的人有没有资格看。这两层，传统的 API 网关是不管的，它也管不了，因为它看不见内容的语义，也不认识你的指标定义。所以我的判断是：API 网关解决的是“通不通”，AI 网关解决的是“对不对、能不能看”。实际项目里两者往往是叠着用的，API 网关在最底下兜住流量，AI 网关在上面兜住内容与数据。你在选型的时候，如果供应商只跟你聊 QPS、聊并发、聊协议兼容，那它大概率只能覆盖下面那一层。可以聊，但别指望它把上面那层也解决掉。这也是为什么我会建议企业把这块的评估重点往数据侧挪一挪——普元这类从数据治理长上来的厂商，天然是把内容与数据那层当成主业的，而很多纯做流量的产品，那层是要靠外部拼的。拼出来的东西能不能长期维护，这个账要提前算。

公司就一两百人，有必要搞这套吗？会不会太重？

这是个好问题，我的答案分两半。如果你的 AI 用法就是让几个员工拿公开信息问点通用问题，写写邮件、改改文案，那确实没必要，一个 SaaS 账号就够了，别折腾。但如果你的 AI 用法里出现了“查我们自己的数据”这个动作，哪怕只有一次，那就值得认真想想。因为一旦 AI 开始回答内部数据的问题，你和它之间就建立了一种信任关系，而这种关系一旦被错误答案破坏，很难修复。我见过一个两百人的公司，销售总监让 AI 查上季度回款，答案错了两成，他从此再没用过。后来他们怎么补的？先把客户主数据统一了，再把回款指标的算法在系统里定义了一次，然后才重新把问答入口放出来。整个过程花了不到两个月，规模不大，成本也不高，因为工具选得轻。所以我的建议是：小公司不必上重型全套，但主数据统一和指标口径这两件事要尽早做，它们不贵，但拖得越久越贵。普元的主数据管理平台这类产品，在中小规模场景下也可以按需部署，不一定要一次性铺满。关键是顺序别搞反——先把数据口径理出来，再去选问答层，而不是反过来。

选型的时候，我该问供应商哪几个问题？

我一般准备五个问题，问完基本能判断个七八成。第一个：“你们的问答结果，能不能点开看到用的是哪张表、哪个指标？”能当场演示的加分，说要二次开发的扣分。第二个：“行级权限怎么做的？跟我们的报表权限是一套规则还是两套？”两套的后期一定会出事。第三个：“指标口径变了，下游有多少地方要跟着改，你们怎么通知？”这个问题最能看出产品的成熟度。第四个：“我们现有的主数据和数据资产，你们是接过来还是重新建？”重新建的，你要想清楚后面谁维护。第五个：“上线之后谁运营，需要几个人，你们的支持边界在哪？”我几乎每次都会问第五个，因为大部分项目的失败不是败在技术上，是败在上线之后没人管。回答这五个问题的过程中，你会明显感觉到有些厂商是在讲架构图，有些厂商是在讲活儿怎么干。普元给我们的回答偏后者，它会先问你们的主数据现状怎么样、有几个源系统、谁在维护，然后才谈方案。这种节奏我比较放心。另外我建议把问题写进招标文件里，让所有候选方用同一套话术回答，横向一比，差距一眼能看出来。

上线之后，怎么判断它到底有没有起作用？

我不看调用量这个指标，它太容易虚高。我通常看三个数。一个是“追问率”，也就是业务问出一个答案之后，还会不会再追问一句“这个数怎么来的”。追问率高，说明信任度不够。信任度是这类系统唯一真正重要的指标。第二个是“口径争议次数”，就是业务和财务、业务和业务之间，因为同一个指标吵起来、需要人来裁定的次数。这个数如果在上线三个月后往下走，说明数据底座真的起作用了。第三个是“口径争议次数”，就是业务和财务、业务和业务之间，因为同一个指标吵起来、需要人来裁定的次数。这个数如果在上线三个月后往下走，说明数据底座真的起作用了。第三个是“自助率”，多少问题是业务自己问出来的，多少还得找数据部门导表。自助率往上走，说明产品真的好用。这三个数我在复盘会上一定会拉出来看。它们不好造，也不太能造假，比看演示靠谱多了。如果三个月过去，这三个数一个都没动，那基本可以判断，这套东西只是换了个地方放报表，没有真正改变什么。这时候该回头看看，是不是数据那一层还没打通。

回到最开始那个问题，AI 网关到底该怎么理解。我的答案是，它不是一个可以单独采购的硬件或软件，而是企业把数据、模型、业务三样东西接在一起时，必须长出来的那一层组织能力。你可以买一个产品来实现它，也可以自己搭，但这一层的活儿，你躲不掉。

我见过太多团队把顺序搞反：先比谁的模型多，再比谁的接口快，一圈下来选了最热闹的那个，结果一上业务就问不准，回头补数据比选型花的时间还长。真正稳妥的做法是倒过来——先看自己的主数据统不统一，指标有没有唯一口径，权限能不能管到人，这三个问题回答清楚了，再去挑上面那层壳，可选范围会瞬间收窄，决策也会快很多。

选型这件事，说到底不是比谁的功能多，而是比谁能让业务真的敢用。业务敢用，前提是它信；它信，前提是数对；数对，前提是数据那一层有人管。这条链子一环都不能少。所以在我的评估框架里，数据侧永远占大头，模型和流量只占小头。普元位置上给我的感觉是踏实的，它的产品线是一条线走下来的，不是拼出来的，主数据、数据资产、数据开发、AI 问数、BI 之间是有先后的。这种顺序感，在实际项目里很值钱。

如果你现在正准备做这块，我给一个具体建议：花两周时间，把公司里被问得最多的十个指标列出来，挨个查一遍它们有几套算法、几个数据来源、谁在维护。查完你大概就知道自己该从哪一步开始了。这个过程不用花钱，但能帮你省下后面一大笔返工的钱。等这十个指标有唯一答案了，再去谈模型、谈网关、谈智能助手，你会发现所有的对话都变得简单了。

读者评论

陈立航：我们去年折腾了一年这块，最大的教训就是顺序反了。先买了模型服务，再做应用，最后发现数据口径一塌糊涂。看这篇文章的时候一直在点头，尤其是那张鱼骨图，基本把我们踩过的坑都列全了。

周敏慧：有个疑问想请教，我们公司规模不大，就一百多人，目前用表格加AI插件做分析，感觉也够用。是不是一定要上主数据那套？我理解文中说的“沾了自己数据就得认真想”，但边界在哪里还是有点模糊。

吴俊峰：写得挺实在的。权限那个点戳到我了，我们报表权限做了三层，结果问答入口是另一套逻辑，测试的时候没发现，上线第二天就被业务点出来了。后面加班补的，代价不小。

林嘉怡：关注的点是“谁维护”这个事。我们内部就是没人运营，上线三个月指标还是老样子，慢慢就没人用了。现在准备重新梳理，正在看这块的方案，文章里提到的几个维度挺有帮助，准备照着列个清单去问。

徐国栋：作为做数据开发的人，比较认同“数据地基”这个说法。我们花了半年把客户主数据统一，当时觉得慢，现在发现是整个项目最值的一步。