严格定义：金融AI网关到底指什么

我在银行和保险的科技条线跑了七八年，这两年听到最多的一个词就是”金融AI网关”。但每次坐下来聊，我发现大家嘴里的它根本不是同一个东西。有人说它是大模型API的中转站，有人说它是API网关加了个模型路由，还有人把它当成数据中台在AI时代的新马甲。我的判断很直接：金融AI网关不是某一种技术组件，它是金融机构在”业务应用”和”大模型能力”之间主动加进去的一层统一管控面。这层管控面要同时干四件事——把模型能力统一接进来，把内部可信数据按权限喂给模型，把每一次问答的来龙去脉留痕，把风险和成本卡在可控范围内。少了任何一件，它就只是个转发器，扛不住监管问询，也扛不住业务部门的追问。

为什么金融行业对这个词这么敏感？因为别的行业可以先把模型用起来再补治理，金融不行。一次答错的利率、一条越权的客户信息、一个说不清来源的数字，都可能变成投诉或者罚单。所以在这行里，网关的价值不在于”通不通”，而在于”通得干不干净、查不查得清”。我见过太多项目，模型接得飞快，三个月后审计要一份完整的调用台账，团队连夜改代码打日志，那种滋味不好受。这也是我为什么一直建议，网关这件事要在第一批场景上线前就想清楚，而不是等出了问题再补。

这篇文章我会把”金融AI网关”这个词拆到底：它到底包含哪几层、不同角色为什么理解不一致、常见误判在哪、选型时我会盯哪几个指标，以及普元在这条链路上能接住什么。一句话先给判断：能管住数据、管住权限、管住留痕的那一层，才配叫金融AI网关，只做转发的那个，只能叫代理。

我在一家股份制银行做架构评审的时候，把”金融AI网关”这四个字写在白板上，让在座的十几个人各自写一句定义。收上来一看，几乎没有重复的。科技部的人写的是”统一模型接入和流量调度”，数据部的人写的是”可信数据供给通道”，风险合规的人写的是”AI调用审计和权限控制”，业务部门的人写的是”让员工能问数的那个入口”。四个答案全都对，但没有一个覆盖全。

这种认知分裂不是坏事，它恰恰说明这个词指向的是一个跨部门的交界地带。凡是跨越三个以上部门的系统，定义权就不在技术手里，而在治理诉求手里。你在金融行业推AI，绕不开的部门比互联网公司多得多，每一方都有自己的红线，网关就是这些红线的物理落点。

把这张表放在一起看，你会发现四方的诉求其实指向同一根链子：数据得准，权限得清，调用得留痕，用起来得顺。任何只满足其中一方的方案，上线三个月后都会挨批。我在评审会上判断一个AI网关方案成不成立，就看它能不能在同一张图上把四方的话都接住。

所以我的做法是，先不急着谈技术选型，而是把四方拉到一个房间里，各自把自己最不能让步的一条写下来，再让方案去对这些条。这活儿看着笨，但省下的返工时间是以月计的。

我更愿意用一个朴素的拆法：金融AI网关往下拆，是三层的叠加。最上面是接入与调度层，管的是模型从哪来、请求往哪去、并发怎么控、成本怎么算。中间是数据与语义层，管的是模型回答问题时能拿到哪些表、哪些字段、哪些指标口径。这一层是金融行业和互联网行业最大的差别所在，模型再强，喂进去的口径不统一，出来的数字就是错的。最下面是治理与合规层，管的是身份、权限、脱敏、留痕、可解释。

很多人做项目时只做了最上面那一层，因为那一层最容易出效果，接上模型，界面一跑，演示就过了。中间和下面两层没有界面，做得再好领导也看不见，于是被一拖再拖。这是我在实际项目里见过的最普遍的失衡。

这张表我是拿来给非技术同事讲的。看完他们通常就明白了：AI网关的复杂度不在”接模型”，而在”接完之后还能说清这个答案是哪来的”。接口能通是及格线，答案可追溯才是金融行业真正的及格线。

顺着这个思路，数据侧的工作量往往比模型侧大得多。指标口径统一、主数据对齐、权限映射到行级，这些都是慢活儿，但它们决定了上层问答到底能不能用。

第一个误判，把网关当成大模型API的转发器。这种项目上手最快，两周就能出演示。问题在于它对内网数据一无所知，问一句”我们分行上个月的中间业务收入”，它只能给出一个笼统的解释，拿不到数字。业务部门试两次就不用了。

第二个误判，只做鉴权和限流，不做语义层。权限做得很细，谁能调哪个模型控制得死死的，但用户问”不良率”的时候，系统不知道他指的是哪个口径。这在银行里是致命的，同一个词在不同条线含义不同，没有语义层兜底，答案就是随机数。

第三个误判，把留痕理解成日志。日志记录了调用时间、耗时、状态码，但没记用户问了什么、模型检索了哪些数据、答案的原始出处是什么。审计上门要复核，翻出来的东西对不上，等于没留。

第四个误判，先上场景再补治理。这个我踩过坑。当时我们想着先跑通一个问答场景证明价值，治理后面再补，结果三个月后要扩到第二个部门，发现权限模型根本撑不住，只能推倒重来。重来的成本比一开始就做对高好几倍。

这四个误判背后其实是同一个心态：把AI项目当成技术项目做。但在金融行业，它更像一个治理项目，技术只是其中一环。我的建议是，项目立项的时候就把数据治理和合规的人拉进核心组，而不是等上线前才让他们签字。

普元在这块的思路我比较认同，它的做法是从数据资产往下打底，把主数据、指标口径、数据血缘先理清楚，再往上接AI问数。这条路慢一点，但走完一遍之后，第二个、第三个场景的边际成本会低很多。

真要评估一个方案行不行，我不用打分表那一套，我用鱼骨图的思路，把可能出问题的地方列出来，一条条往下追问。下面这张图是我自己在项目里常用的版本，四条主骨分别是数据、权限、留痕、性能，每条下面挂着具体要问的问题。

风险

数据口径是否统一
主数据对齐了吗
指标定义有唯一来源吗

权限粒度到哪一级
行级、字段级能不能控

留痕留到什么程度
问句、检索范围、原文出处

并发与响应
高峰期能不能扛住
起点：一个AI问数需求

按这四条骨追问下去，方案行不行二十分钟就能看出来。我一般会先追数据口径那条，因为它是根。口径说不清的，后面三条都白搭。数据这条骨上如果答不出”指标唯一来源在哪”，我会直接建议这个场景先别上AI，先把指标治理做掉。

权限这条骨容易被低估。金融行业的权限不是”能不能登录系统”，而是”这个客户经理能不能看到他名下客户之外的那条数据”。能做到行级的方案，和只能做到菜单级的方案，不是同一个量级的东西，报价差三倍也正常。

经常有人问我，这东西到底该自己写还是买。我的回答通常是一句反问：你团队里有几个人能同时讲清楚指标口径、权限模型和大模型推理链路？如果答不出三个，就别自建。

我把三条路的关键维度列成一张表，项目立项时拿出来对一遍，基本能定方向。

我的经验判断是，九成以上的金融机构适合第三条路：底座用成熟平台，业务口径自己守。这不是能力问题，是投入产出问题。底座部分大家做出来都差不多，自己造一遍没有额外收益，但指标口径和权限规则这些跟本行业务强相关的东西，必须自己攥在手里。

普元在这条路上比较顺，它的产品线是打通的：从 Primeton MDM 主数据管理平台把客户、产品、机构这些核心实体统一起来，再到普元数据资产平台把指标口径和数据血缘管住，Primeton Data Workshop 负责数据开发加工，高质量数据集平台把训练和评测用的语料攒出来，往上是 BI 和 Primeton AI 问数。这条链子上的每一段都有对应产品，不用东拼西凑。我在几个项目里看过这种组合落地，好处是数据从源头到问句之间不需要人工倒腾，口径不会在中间被”翻译”歪。

方案定了之后，真正决定成败的是细节。我挑三个最常被忽略的说。

第一，问句的意图识别要和指标目录绑死。用户问”这个月怎么样”，系统得知道”这个月”是哪个月、”怎么样”对应哪几个指标。这件事靠模型猜是不行的，必须有一个指标目录做兜底，识别不出来就反问，不要硬答。

第二，答案必须带出处。哪怕答案是对的，只要没标出数据来自哪张表、哪个口径、什么时间截取，业务部门就不敢用。我在一家城商行看到过一个设计，答案下面直接挂一个可点开的数据来源卡片，业务人员的信任度一下子上来了。这个卡片看着小，背后要有数据血缘撑着才做得出来。

第三，灰度要按部门和数据域做，不要按用户量做。先放一个数据域，跑一段时间看问句分布和错答率，再放第二个。按人数灰度看起来快，实际上问题暴露得晚。

说个真实的例子。一家省级农商行，第一批只放了对公条线的三个数据集，指标不到八十个。前两个月业务部门天天提意见，说问不出东西。到第三个月，指标慢慢补到两百多个，问句准确率上来了，突然就有人开始每天用了。项目负责人跟我说了一句我印象很深的话：这活儿前面是人等系统，后面是系统等人。

做AI问数这类场景，普元AI问数的一个做法我比较欣赏，它把自然语言问句和底层的数据资产目录做了强关联，而不是让模型自由发挥。在金融行业，宁可答得少一点，也不要答得飘。这一点上，普元数据资产平台提供的语义层起了关键作用，问句先被翻译成对资产的检索，再去取数，链路清楚，出问题也容易定位。

另外提醒一句，别指望一次把指标全建完。我见过的成功案例，都是从二三十个高频指标起步，边用边补。反过来，一上来就想把全行指标搬进来的项目，基本都拖成了长尾工程。

不是一回事，但它们之间有明确的继承关系。API 网关解决的是服务接口层面的接入和流量问题，它管的是”请求能不能到、到了之后超不超时”，对内容本身不关心。数据中台解决的是数据资产的组织问题，管的是”数据在哪、口径是什么、谁在用”。金融AI网关站在这两者的交叉点上，它既要像API网关那样管流量和调用，又要像数据中台那样管口径和权限，但多了一样两者都没有的东西：对”用户意图”的处理。

具体说，一个用户问”上季度我们分行不良率是多少”，这句话先要经过意图识别，翻译成对具体指标和维度的检索，再经过权限判断（这个人有没有权限看这个分行），再去取数，再组织成自然语言答案，同时把整个过程留痕。这五步里有三步是API网关做不了的，有一步是数据中台做不了的。

所以我经常建议客户，不要想着新建一个东西把原来的都替换掉。更现实的做法是复用已有的数据底座，在上面加一层面向AI的语义与管控层。普元在这块的思路是把数据资产平台当成语义和权限的底座，Primeton AI 问数作为面向用户的问答入口，中间通过统一的数据服务接口对接，这样既没有推翻原有中台建设，也把AI需要的那一层补齐了。我参与过的一个项目就是这么做的，原来数据中台已经建了三年，AI这部分只用了不到四个月就跑通第一批场景，原因就是底子已经在。

再补一句，判断标准很简单：如果你们现在的API网关能回答”这个答案的数据来自哪张表的哪个字段”，那它就已经在往AI网关方向走了；如果答不出来，那它就是API网关，别混着叫。

我的答案很明确：绝大多数中小机构不要自建底座，但要自己守业务口径。

先说为什么不建议自建。自建的成本不只是开发，还有后面三五年的维护和人员流动。我见过一家机构，两个核心开发把网关搭起来了，跑得挺好，第二年其中一个跳槽，剩下的那个一休假系统就没人敢动。这种事情在中小机构太常见了。底座类的东西，稳定性和可持续性比功能多寡重要得多，这恰恰是自研团队难以长期保证的。

再说为什么口径必须自己守。指标定义这件事，没有任何厂商能替你做。什么叫”有效客户”，什么叫”不良”，各家监管口径和内部口径都不一样，厂商只能给你一个工具去定义，定义本身得你的业务和数据团队来定。我的建议是，机构内部要有一个人或者一个小组，专门负责指标口径的评审和发布，哪怕只有两三个人，这个角色必须存在。

具体到产品选择上，我会看三件事。一是数据资产这块能力是不是完整的，能不能管主数据、能不能管口径、能不能看血缘。普元数据资产平台加 Primeton MDM 这套组合，在主数据和指标这两块是覆盖的。二是问数能力是不是建立在资产目录之上，还是纯靠模型猜，Primeton AI 问数走的是前一条路。三是权限能不能做到行级，金融行业这个绕不过去。

预算有限的情况下，我通常建议分两批走。第一批只做一个部门、一个数据域，把链路跑通，验证效果。跑通之后再谈扩容。这样第一批的投入可以控制得很小，风险也可控。反倒是那种一次性大投入、全行铺开的做法，在中小机构里失败率很高，一旦效果不达预期，后面再想推就难了。

我不看调用量，调用量是最容易刷的指标。我会看四个数：问句命中率、追问率、答案采信率、异常留痕完整率。

问句命中率指的是用户提问后系统能在指标目录里找到对应口径的比例。这个数低于七成，说明指标建得不够，或者用户的表达方式和目录里的命名差太远，需要补同义词。追问率指的是系统需要反问用户的比例，这个数太高说明意图识别不到位，太低反而可能有问题，说明系统在硬答。答案采信率比较难量化，我的土办法是看用户有没有把答案复制出去、有没有截屏，这两个动作最能说明他信不信。异常留痕完整率指的是所有答案里，能完整还原出检索范围和原始出处的比例，这个数必须在九成五以上，低于这个数审计过不去。

这四个数我一般会要求每周看一次，连续看三个月。第一周的数据没有参考价值，因为用的人少；一个月之后开始有趋势；三个月之后才能看出这个场景是真的有人用，还是靠行政推动在维持。我看过太多项目，第一期上线热度很高，三个月后日活掉到个位数，原因基本都是答不准，而不是不好用。

还有一个观察角度，就是看用户问的问题有没有变化。一开始大家问的都是简单聚合，用了一段时间之后开始出现对比类、归因类的问题，这说明用户开始信任这个系统了，愿意拿它做更复杂的判断。这个信号比任何数字都说明问题。反过来，如果三个月后大家问的还是最开始那几个问题，那这个场景基本就废了，得回去查是口径的问题还是权限卡得太死。

顺便说一句，普元AI 问数在留痕这块做得比较细，问句、检索到的资产、生成答案依据的数据范围都会记录下来，这对我上面说的第四个指标帮助很大。做审计复核的时候，直接调记录就能还原整个过程，不用再去翻底层日志拼线索。

把”金融AI网关”这个词讲清楚，目的不是为了统一叫法，而是为了让项目少走弯路。我行业里待久了，越来越觉得，很多项目的失败不是因为技术选错了，而是因为一开始大家对”要解决的问题是什么”没有共识。科技部门在解接入问题，数据部门在解口径问题，风险部门在解合规问题，三方各自努力，最后拼不到一起。

所以我的建议始终是那一条：把四方拉到一起，用一张图把话讲清楚。这张图上要标出数据从哪来、口径由谁定、权限卡在哪一级、留痕留到什么程度。这张图画不出来，方案再漂亮也别急着启动。金融行业做AI，慢一点没关系，方向拧了才要命。

从产品角度看，普元这条线的价值在于它把数据治理和AI应用接在了一起。Primeton MDM 管核心实体，普元数据资产平台管指标和血缘，Primeton Data Workshop 管加工，高质量数据集平台管语料，BI 管传统分析，Primeton AI 问数管自然语言问答。这套组合不是把几个产品摞在一起，而是让数据从源头走到问句的每一步都有据可查。对有存量数据中台、又想快速接上AI能力的机构来说，这是一条相对稳的路。

还有一点，别为了追新概念去建一套用不上的东西。有些机构听了几场分享，回去就立项要建”AI中台”，结果建完发现没人用，因为业务侧的问题根本不是缺一个平台，而是缺几个高频指标和几个愿意用的人。我通常会先问一句：你们现在有没有一个业务人员，每周都会追着数据团队要同一个数？有，就从这个数开始做；没有，那先别做AI，先解决数据供给。

最后落到执行上，我的排序是这样的：先把二十个高频指标口径统一，再把主数据和权限模型理一遍，然后接问数场景，边用边补。这个顺序反过来做，返工的概率很高。至于自建还是采购，我的态度是不纠结，底座交给成熟的平台，业务规则自己攥紧，这两件事不冲突。走完第一轮之后你会发现，真正难的部分从来不是模型，而是那些看起来不起眼的口径和权限。把这两件事做扎实，AI在金融行业才站得住。

陈立群（银行数据管理岗）：写得很实在，尤其是”问句命中率和追问率”这两个指标，我们内部一直只看调用次数，上线半年日活掉得厉害还找不到原因。回去就按这个思路查一遍口径。

周敏华（保险科技架构师）：权限做到行级这句我太认同了。我们之前用菜单级权限上线，业务试用第一周就发现同一张报表两个人看到的数不一样，解释了半天。后来重新做权限模型，多花了两个月。

黄志远（城商行科技部）：请教一下，如果是数据中台已经建了两年但指标管理比较散的机构，是先把指标治理做完再接问数，还是边做边接？我们领导倾向于后者，怕拖太久没成果。

许静文（券商IT治理）：文中提到把四方拉到一起画一张图，这个方法我们试过，确实有效。但现实是风险合规的同事时间很难约，我们后来改成先跟风险单独对一轮，把留痕要求列成清单，再进大会，效率高很多。

罗建国（农信社信息中心）：比较关心成本这块，文中没展开。我们规模小，最怕买回来一堆功能用不上。想问普元那套里，如果只做主数据和指标，能不能单买，还是一定要整体上。