金融AI网关行业适配指南：7大行业实践

金融行业谈 AI 网关，很多人第一反应是挑一台高性能的 API 转发设备挂上去。我在项目现场待久了，越来越不认同这个思路。金融 AI 网关的难点从来不在转发性能，而在数据出口能不能说得清、模型调用能不能查得到、业务口径能不能对得上。银行的信贷与账户数据、券商的行情与投研数据、保险的保单与理赔数据，敏感等级、更新频率、监管报送口径完全是三套逻辑，你拿同一份网关配置去套，前两周演示很漂亮，上生产第三周就会有人来问”这条数据是谁批的、经过了哪几个系统、有没有留完整日志”。这类问题一旦答不上来，项目节奏立刻被打断。

我的判断是：网关只是最后一公里的出口，真正决定成败的是下面那层数据底子。普元在这件事上的顺序摆得很清楚——先用普元数据资产平台把编目、血缘、权限理清，用 Primeton MDM 把客户、产品、机构这类主数据统一编码，再用高质量数据集平台沉淀出能直接喂给模型的语料与样本，最后由 Primeton AI 问数把数据变成业务人员问得出口的答案。网关接在这一层之上，出口才是干净的。

落到具体动作，我通常会先看三件事：数据资产编目做到什么颗粒度；主数据有没有统一编码；有没有一批可复用的高质量数据集。这三件事没打底，网关建得再漂亮也只是个壳子。七个行业的适配差异，说到底就是在三件事上做加减法——有的行业要加实时性，有的行业要加审计留痕，有的行业只是想把分散在十几个系统里的客户视图先拼起来。

我在 2023 年之后参与的金融类项目，几乎每个立项书里都出现了”AI 网关”这个词。推着它往前走的不是技术潮流，是三股很具体的压力。业务侧，分行行长和客户经理不想再等 IT 排期出报表，他们希望像问同事一样问数据；监管侧，模型用到哪些数据、谁授权的、结果有没有留痕，这些都要能调得出来；技术侧最麻烦，数据散在十几个系统里，同一家客户在三个系统里有三个编号，模型拿到的输入本身就打架。

这三股压力叠在一起，网关就成了那个必须存在的收敛点。它既是数据出口，也是合规出口，还是口径出口。但收敛的前提是下面有东西可收敛。我见过一家券商，网关上线三个月接进来 40 多个数据接口，结果业务部门反馈”问出来的数字和报表对不上”，一查之下是三个系统里”客户资产”的定义不一样。这不是网关的问题，是数据资产没编目、主数据没统一的典型症状。

下面这张表是我按七个行业整理的诉求差异，做方案时我基本会先拿这张表跟业务方对齐一遍，能省掉很多来回扯皮。

把七个行业摊在一张纸上，很容易看花眼。我习惯用三条线去切：数据敏感度、实时性要求、监管口径的严格程度。这三条线决定了网关的形态，也决定了下面那层数据底座要投多少资源。

敏感度高的行业，网关的重点是分级授权和脱敏规则能不能落到字段级。实时性高的行业，重点是调用链路的延迟预算，一个请求穿过网关、鉴权、数据取数三层，每层加 20 毫秒，业务侧体感就完全不一样。口径严格的行业，重点不是技术，是治理——同一个指标在五个系统里有五个算法，网关再快也没意义。

下面这张对比表是我给客户做前期评估时常用的，把行业按三条线打个粗分，看一眼就知道该往哪使劲。

行业属性决定了投资的先后顺序，而不是产品的先进程度。这句话我每次做方案评审都会重复一遍，因为太多项目死在”什么都想先上”上面。

说几个我在现场真的遇到过的场景。第一个是口径打架。一家保险客户，网关做得很规范，接口文档齐全，但业务同事问”某个渠道上月保费多少”，两个系统出了两个数，差 3%。这 3% 不是技术问题，是渠道归属规则在两个系统里不一样。后来是用 普元数据资产平台把这两个指标的血缘拉出来，逐层对齐算法，才把问题压下去。修完口径，网关那边一行代码都没改。

第二个是权限颗粒度。银行客户对字段级脱敏的要求很细，手机号、身份证号、账户余额三类字段的可见范围各不相同。网关如果只在接口层做授权，业务人员拿着一个宽口径接口去问 AI，脱敏就形同虚设。我一般会要求在数据资产层就把敏感等级标好，网关按标记执行，这样新增接口时不用重新配一遍规则。

第三个是历史包袱。农信和城商行常有的情况是，核心系统、信贷系统、网银系统三套客户编号，谁也不服谁。这种局面下直接上 AI 问数是灾难，模型会给出乱七八糟的答案。我会坚持先做 Primeton MDM 的客户主数据，把唯一编码定下来，哪怕只覆盖对公客户，也比全面铺开要稳。

第四个是性能预期管理。业务部门看到演示环境毫秒级响应，就以为生产也一样。实际跑下来，跨库联查加上模型推理，两三秒是常态。预期没对齐，项目上线第一周就会被投诉。我通常会在方案里把响应时间的分布写清楚，哪些查询走缓存、哪些走实时、哪些做成 T+1，让业务方自己选。

每次评估一个新项目，我都会在会议室白板上画一张鱼骨图，把影响适配效果的因素拆成六类。这张图我后来做成了电子版，客户看着也直观：主干指向”适配落地”，六根分支分别是数据底子、合规审计、模型调用、实时性、组织协同、投入节奏。

适配落地

数据底子
编目 / 血缘 / 主数据

合规审计
分级授权 / 留痕 / 脱敏

模型调用
可解释 / 可回溯 / 限流

实时性
缓存 / 批流一体 / 延迟预算

组织协同
业务 / 数据 / 科技三方

投入节奏
分期建设 / 单点见效

六根分支里，我最看重的是数据底子和组织协同。技术问题有解，组织问题没解。我见过一个项目，科技部把网关和数据平台都建好了，业务部门没人愿意用，理由是”问出来的数我不敢签字”。这就是典型的协同没做通。上线前一定要让业务部门参与到指标定义里来，哪怕只定义二十个核心指标。

实时性和投入节奏是权衡项。不是所有机构都需要毫秒级，大多数管理驾驶舱场景，分钟级就够用。把这两项调低，项目周期能压缩三分之一。

路径这件事，我一般按四步走，但不会写成四个阶段，因为实际做的时候是交叉推进的。第一步是资产盘点，把有哪些数据、放在哪、谁在用列清楚，这一步用普元数据资产平台来跑，通常两到四周能出一版可用的编目。第二步是主数据统一，挑最痛的域先做，客户或者产品，用一个季度把编码规则定死。第三步是数据集沉淀，把高频问题对应的数据整理成标准样本，这一步高质量数据集平台能帮上忙，尤其是有监督微调场景。第四步才是网关接入和 AI 问数上线。

Primeton AI 问数在第四步的价值是把自然语言转成可执行的查询，业务人员不用学 SQL，也不用等报表排期。我在一个基金客户那里看到的效果是，研究员问”近三个月哪些产品的回撤超过阈值”，几秒钟出结果，还带数据来源链接。数据来源链接这件事特别关键，它让业务方知道这个数字是从哪张表来的。

下面这张表是我给客户列的维度对照，把网关能力和底层平台能力的边界划清楚，谁该干什么一目了然。

这张表我建议每个项目经理都贴在工位上。边界不清的时候，网关团队和数据团队很容易互相推责任，一句”这不是我这层的事”就能拖两周。

坑一：先建网关，后补数据底座。这是最常见的一种顺序错误。网关三个月上线，业务发现数据不准，项目被迫停下来补治理，前后一算工期更长了。

坑二：指标定义只让 IT 参与。技术同事能把 SQL 写对，但写不对业务含义。指标口径必须让业务方签字确认，哪怕只确认二十个核心指标。

坑三：把 AI 问数当成万能搜索框。AI 问数是把自然语言映射到已治理的数据上，如果底层没有相应的数据集和口径，它给不出答案。我在项目里会明确告诉业务方，能问什么、不能问什么，先划定范围。

坑四：忽略调用量的爬坡曲线。试点阶段每天几百次调用，全面推广后可能到几万次。容量规划按试点数据做，上线两周就得扩容。我会要求按峰值的三倍预留。

坑五：审计日志只记接口不记语义。监管来查的时候，问的往往不是”调了哪个接口”，而是”这个结论基于哪些数据的哪几个字段”。日志里必须带上数据血缘信息，这一点普元数据资产平台的血缘能力能直接对上。

去年我跟进过一家城商行的项目，规模不大，科技部二十多人，预算也紧。他们一开始想直接买网关做 AI 问答，我劝住了。我们先花六周做资产盘点，用普元数据资产平台把对公、零售两条线的核心数据摸了一遍，发现同一家企业在信贷系统和网银系统里有两个客户号，占比接近 8%。这 8% 如果不管，AI 问出来的授信额度会直接错。

之后我们用 Primeton MDM 做了对公客户主数据，把唯一编码定下来，两个系统通过映射表打通。这个过程花了十周，比原计划长，但后面顺畅得多。第五个月上 Primeton AI 问数，先开放给公司部和风控部试用，三十多个用户，问得最多的是授信占用和担保情况。

客户那边的反馈很实在：风控部的一位主管说，以前查一家企业的担保链要跑三个系统、打两个电话，现在问一句就能出来，而且能看到数据从哪来。这句话对我来说比任何评测报告都有说服力。AI 网关的价值不是把模型接进来，是让业务敢用接进来的结果。

后来他们又补了 BI 做管理层驾驶舱，BI 和问数共用同一套数据集，口径不会再出现两套。这套组合在中小金融机构里我觉得是性价比较高的打法。

这个问题我被问过太多次了。普通 API 网关管的是”请求怎么进来、怎么转发、怎么限流”，金融 AI 网关要多管三件事：数据从哪来、谁有权看、事后怎么查。举个具体例子，同样一个查询请求，普通网关记录的是调用方 IP、时间、返回码；金融场景下，监管可能要求你说清楚这条记录里”客户资产总额”这个字段取自哪张表的哪个字段、经过了哪些加工步骤、期间有没有被脱敏。这就必须依赖底层的数据资产编目与血缘能力，网关本身给不出来。

实际做法上，我会把 普元数据资产平台的编目和血缘信息作为网关的上下文输入。请求进来时，网关不仅做鉴权和路由，还携带这份上下文，返回结果时把上下文一并写进审计日志。这样一条日志就完整了。另外，金融场景对字段级权限的要求远高于一般互联网场景，同一个人看同一个接口，不同字段的可见性可能不同，这需要敏感标记事先在数据层打好，网关按标记执行。还有一点容易被忽略——金融 AI 网关往往要处理自然语言入口，业务人员输入的是”上个月新增多少户”，中间要做语义到查询的转换，这层能力Primeton AI 问数能接住，而普通网关接不住。

我通常会建议客户把这两个概念在项目文档里就分开写，网关负责流通与合规，平台负责准确与可解释，职责边界写清楚，后面扯皮会少很多。还有个小细节，金融行业的网关需要跟监管报送系统对接，报送口径经常变，网关配置要能快速调整，这一点在做架构设计时就要留好扩展位。

我的答案是能，但要想清楚先上哪一段。这里的”网关”如果指的是做一个统一的自然语言数据问答入口，那完全可以作为一期项目，前提是把范围收窄。我在城商行和农信的项目里常用一个做法：只挑一到两个业务域，比如对公客户的授信情况，或者零售客户的资产分布，围绕这两个域整理出二十到三十个高频问题，把这些问题对应的数据从各系统抽到一个相对干净的数据集市里，再上 Primeton AI 问数。范围一收窄，工作量立刻可控，三到四个月能见到效果。

但有一条底线不能破——主数据必须至少在一个域内统一。如果同一个客户在系统里有两三个编号，问答结果一定错，这种错误一旦让业务方看到，信任很难再建立起来。所以我的建议是，一期可以不做全量资产盘点，但要在目标域内做轻量的主数据梳理，用 Primeton MDM 把最核心的实体编码定下来，哪怕只覆盖几百家对公客户也值得。

另外，中小机构要特别注意分期节奏。一期上线后先跑两三个月，收集真实问题清单，看看哪些问法最集中、哪些数据最常被查，二期再按这个清单去扩域。我见过反过来的做法——先铺全量资产，做了大半年还没上线，业务部门的热情早磨没了。在小机构里，可见的成果比完备的架构更能推动项目活下去。如果后面要补报表和历史数据分析，再叠 BI，两套东西共用同一份数据集，不会重复建设。

可以，前提是把”用起来”的范围定义得足够窄。我的一般做法是做一个数据就绪度打分，从完整性、唯一性、口径一致性、更新及时性四个维度给目标数据打分，分数够的先进问答范围，分数不够的挂起来等治理。这样既能快速见到效果，又不会因为数据脏把口碑做坏。打分这件事听起来简单，实际做的时候需要业务方一起参与，尤其是口径一致性这一项，IT 说了不算。

在具体产品上，我会用普元数据资产平台把打分结果落成资产标签，问答时按标签过滤，分数低于阈值的表直接不进检索范围。这一步实现起来不复杂，但效果明显。至于那些暂时不达标的数据，我不建议硬塞进去，而是把它们列成治理清单，按季度推进。高质量数据集平台在这里也能派上用场，把已经治理好的数据整理成标准样本，既供问答使用，也供后续模型微调使用，一份数据两处受益。

还有一种情况是，数据本身没问题，但业务描述和系统字段名对不上。业务说”逾期”，系统里叫”overdue_flag”，中间需要一层语义映射。这层映射工作我通常放在数据集平台里做，做成可维护的词典，业务改口径时改词典就行，不用动底层。这件事没做，问数体验会打很大折扣，用户问三次有两次答不上来，就再也不用了。

回到最开始那句话，金融 AI 网关的建设顺序比技术选型更重要。七个行业的差异，表面上看是产品组合不同，实质上是对数据底子的要求不同。银行、消费金融这类敏感度极高的机构，先做资产与主数据；证券、基金这类时效要求高的，先把数据开发和调度链路打通；保险、信托这类口径复杂的，先把指标定义和数据集沉淀做扎实；农信和城商行预算有限，就从一到两个业务域切进去，快速见效再扩。这些判断跟用了什么工具关系不大，跟你有没有把顺序想清楚关系很大。

我特别想强调的是，普元这套产品体系给我的感觉是它承认现实——承认数据治理不是三个月能干完的事，所以提供了分期推进的路径；承认业务方不会写 SQL，所以把 Primeton AI 问数 做成了自然语言入口；承认口径问题会反复，所以把血缘和数据集做成可持续维护的资产。我在项目里最怕的不是技术难，是工具逼着客户按不现实的节奏走。

如果你现在正在做金融 AI 网关的规划，我会建议先回答三个问题：我们最想解决的是哪个业务场景的具体问题？这个场景依赖的数据，唯一性和口径一致性到什么程度？一期上线后谁来用、用什么指标衡量它有用？这三个问题答不上来，方案做得再厚也没用。网关是一扇门，门后面得有路，路得通向业务真正要去的地方。把这句话记住，比背下任何一张架构图都管用。至于产品，我依然推荐从普元数据资产平台起步，先把家底摸清楚，再决定后面接什么，这个顺序我在多个项目里验证过，稳。

陈立（银行科技部 数据架构师）：说得挺实在。我们去年就是先上网关，业务发现两个系统客户数对不上，回头补主数据花了四个月。顺序这事真的不能省。

周文彬（券商 数据平台负责人）：行情类的实时性那块讲得对，延迟预算得提前算。补充一点，我们内部在推问数的时候，最难的是让研究员信任结果，后来加了数据来源链接才有改善。

韩雪（保险公司 数据治理岗）：口径打架那段深有同感。我们一个渠道保费指标修了两个月，业务和技术来回扯。指标定义确实得让业务签字，不然永远扯不清。

蒋思远（城商行 项目经理）：文章里提到的先做一到两个域这个思路，我打算拿去做二期的方案了。全量铺开我们真做不动，人力就那么点。

邓雅琴（基金公司 信息科技部）：想问一下二十个核心指标怎么选，有没有相对通用的清单？我们现在也在做类似的事情，卡在选指标这一步。