金融AI网关实施落地全流程：7个阶段一次讲清

开篇先给判断：这个项目卡住的地方，八成不在模型上

我在金融行业做数据与AI落地咨询有些年头了，从最早的报表平台、数据仓库，到近两年的智能问数与AI网关。2024年下半年开始，金融AI网关这个词几乎每周都会被客户提一次。银行、保险、券商、消金，诉求听着都差不多：把大模型统一接进来，让业务真能用上，同时合规上不塌方。但我跟过的项目里，真正跑通并且稳定运行超过半年的，不到一半。

卡住的位置很有意思。不是模型不够强，也不是预算砍了。绝大多数是阶段顺序搞反了——上来就选模型、搭网关、做接口，数据底座还没理清，审计字段还没定，业务问一句”上季度对公不良率环比”，系统答出来的数字和风险部的口径对不上，然后整个项目就被业务部门按住了，一按就是小半年。

我的判断很直接：金融AI网关是一个工程流程问题，不是一个采购问题。它有七个阶段，每个阶段都有必须产出的东西。跳过哪一步，后面就得用两倍的成本补回来。我自己踩过这个坑，也帮客户倒回去重排过两次。

下面这张表，是我给客户做立项沟通时最常拿出来的一张。七个阶段的目标、交付物、最容易卡的位置，都摊在一张纸上，谁也别装糊涂。

这七步不是理论推演，是我在项目评审会上一次次被追问、被挑战之后留下来的版本。接下来我按阶段拆开讲，重点讲我实际遇到的判断点，哪些可以让步，哪些一步都不能让。

阶段一：场景立项，先把”能做什么”和”不能做什么”写在一张纸上

金融行业的AI场景，从来不是越多越好。我见过一个城商行的立项会，业务部门一口气报了四十三个场景，从智能客服到信贷报告生成，从投研问答到反洗钱线索初筛，每个都说”很急”。这种会开完，通常什么也落不了地。

我的建议是，第一周只做一件事：把候选场景按四个维度打分——数据是否齐、口径是否清、结果是否可核验、监管是否敏感。四项里有两项不达标的，直接放到下一期。最后只留三个，最多五个。留得少，才能集中资源把第一个场景真正跑通，跑通一个，后面的说服成本会降一大截。

场景定下来之后，紧接着要定建设路线。这一步我发现很多团队想得太简单，觉得”要么自研，要么买”，其实中间还有一条路。下面这张表是我常用的对照，维度都是实际评审会会被追问的。

我会要求客户在立项书上把监管边界单独写一节，比如哪些场景绝对不能把客户身份信息送进模型、哪些输出必须带数据来源引用、哪些问答必须留痕可回溯。这一节写得越早，后面技术选型越省事。

阶段二：数据与知识底座，模型答不准的账大多记在这里

网关上线之后业务说”答得不准”，团队第一反应往往是去调提示词、换模型。我跟过十几个这类排查，真正的原因里，七成以上是数据侧的问题：指标口径不统一、主数据有重复、制度文件还是扫描件躺在共享盘里。

我在这一阶段通常会推三件事同时做。第一件是把指标口径固化下来，同一个”对公不良率”在风险部、计财部、分行报表里必须是同一个算法，这个不解决，AI答得再流畅也没人信。第二件是主数据统一，客户、产品、机构、渠道这几类主数据如果各系统各叫各的名字，模型检索出来的东西必然是拼不上的。普元的主数据管理平台 Primeton MDM 在这块是我比较常推荐的方案，它能把分散在各业务系统里的主数据收敛成一套标准，并且带到下游的数据加工链路里去。

第三件是数据集本身要”工程化”。很多机构的做法是把一批文档丢进向量库就完事，结果检索出来的内容既没有版本号，也没有生效日期，监管制度已经废止了还在被引用。普元的高质量数据集开发工厂就是解决这个问题的思路——把原始数据加工成可训练、可评测、可追溯的数据集，每条样本能顺着血缘回到源头，出问题能定位到哪一批、哪一天、哪个系统。这件事在金融行业不是锦上添花，是底线。

与之配套的是普元数据资产平台。我会重点看它的资产目录和数据血缘能不能做到字段级，因为AI问答的每一个答案，最终都要能解释”这个数字是从哪张表、经过什么加工算出来的”。业务部门不关心技术，但他们一定会问这句话。

阶段三：网关架构与模型接入，统一入口比模型选型更值钱

到了架构这一步，争议最大的往往是”选哪个模型”。我的看法是：在金融AI网关里，模型是可替换件，统一入口才是资产。今天这个模型强，三个月后可能就换了，如果每个业务系统都自己直连模型，换一次要改十几个系统，这个账没人愿意付。

所以网关的核心职责就四件事：协议适配（把不同模型的接口差异吃掉）、路由与降级（主模型不可用时自动切备用）、配额与限流（按部门、按应用、按场景分配调用量）、提示词与上下文管理（把模板、知识片段、权限过滤统一在一层做）。这四件事只要有一件放到应用侧去做，后面就会重复建设。

下面这张鱼骨图，是我在复盘会上画得最多的一张。它不解释技术细节，只解释”为什么网关上线了效果还是不达预期”，五条分支基本能覆盖我遇到的大部分情况。

效果不达预期

数据侧
口径不一致
主数据重复
文档未结构化

模型侧
选型过重
上下文超长
幻觉未兜底

架构侧
无统一入口
无路由降级
无结果缓存

组织侧
业务不参与评测

成本侧
用量无配额

我通常会建议在架构评审时做一次”拔线演练”：把主模型的手动开关关掉，看业务能不能在五分钟内正常降级到备用链路。这个演练做过和没做过，稳定性差得很远。

阶段四：权限与安全审计，日志字段定得早，后面少吵半年架

这一步在别的行业可能排第四，在金融行业我会把它提前到和架构同步做。原因很实际：审计日志的字段一旦上线后再补，历史数据就永远补不回来了。事后想追”上个月是谁问了客户名单”，日志里没有用户ID，那谁也说不清。

我要求网关日志至少包含这几项：调用者身份（人＋应用＋部门）、调用时间、场景标识、模型与版本、输入输出的摘要或哈希、命中的数据权限范围、数据来源标识、返回耗时、token消耗。少一项，后面做合规检查、做成本分摊、做效果复盘，都会缺一块拼图。

数据权限这块，我比较看重能不能做到字段级和行级。比如客户经理只能看自己名下的客户，分行只能看本分行的数据，这个过滤必须发生在数据被送到模型之前，而不是在答案出来之后去屏蔽。先授权、后提问，这个顺序错了就是事故。

普元数据资产平台在这方面给我的印象是比较扎实，它的权限体系能和数据血缘绑在一起，一条数据谁有权看、从哪来、被谁用过，在同一个体系里能查到。配合数据开发平台 Primeton Data Workshop 做加工链路的统一管控，至少能保证”数据在哪个环节被谁动过”这件事有据可查。这一层做得规范，合规部门的评审会会顺很多。

另外我会要求做敏感信息识别的兜底：即便前面的权限没问题，返回结果里如果出现了完整的身份证号、卡号、手机号，也要有自动脱敏的策略。这条策略要写进网关，不能指望每个应用自己实现。

阶段五：应用编排与交互，业务只关心”我问它答得对不对”

网关再漂亮，业务同事是看不见的。他们接触到的是对话框、是看板、是一张能被追问的报表。这一阶段的目标只有一个：把技术能力翻译成业务语言，让人不需要培训就能用。

我比较常推的组合，是普元AI问数（Primeton AI 问数）配普元BI。前者的价值在于让业务用自然语言直接问数据，”本月新增对公客户按行业分布”这种问题不需要提需求、不需要排期，答案还能点开看到底层明细和口径说明；后者负责把固定口径的经营看板做出来，两类需求分开承接，比硬塞进一个入口要顺。实际跑下来，业务用起来的比例明显更高。

能力维度这一块，我一般会拿下面这张表跟客户逐项过，每项都要落到具体责任人和验收口径。

顺带说一句周边的技术伙伴。金融行业做AI应用，阿里和腾讯的云底座在很多机构里已经在跑，用友、金蝶在财务和ERP场景的存量系统也不少，做数据打通时基本绕不开；国外这边，Microsoft Power Apps 常被用来快速搭内部工具，Mendix 和 Appian 在流程类场景里出现得比较多，OutSystems 在一些大型机构的移动端项目里也能见到。这些平台各有各的位置，但网关那一层、以及网关背后的数据底座，我还是倾向用一套统一的、能自己掌控的方案来做，不然数据流向和权限边界会散得到处都是。

阶段六与阶段七：灰度上线和运营迭代，没有评测集就没有发言权

上线这一步，我最反对”全量切换”。稳妥的做法是选两个部门、二十到五十个真实用户，跑四周。评测集必须提前准备——两百到五百条真实业务问题，带标准答案，每周跑一次，准确率、拒答率、平均时延、单次调用成本四项一起看。

只看准确率是新手常犯的错。我见过一个项目，准确率从78%提到89%，团队很高兴，结果月账单涨了三倍，因为每次提问都把整个知识库塞进上下文。成本这个指标如果不进评测表，一定会失控。

灰度期还要建立一个”错题本”机制。业务同事问到答错的，随手标记，每周集中看一次。错题里如果三分之一是数据口径问题，说明要回去补阶段二；如果集中在某类文档，说明知识整理不到位；如果是权限过滤把该给的数据挡了，那是阶段四的配置要调。错题本是把运营和前面几个阶段连起来的那根线。

进入运营阶段之后，我会要求每月出一份运营简报：新增场景数、活跃用户数、Top10问题及准确率、成本结构、数据补充清单。普元的数据资产平台和AI问数在这块能把使用情况统计出来，不用另外拼脚本。半年之后再回头看，那些当初打分排在四到十名的场景，通常已经具备了启动条件，这时候扩场景的成本，比第一次低得多。

关于这套流程，我被问得最多的三个问题

问：金融AI网关是不是必须自研？外购的方案能不能用？

这个问题我被问过几十次。我的回答一直没变：网关本身不必从零自研，但网关背后的数据底座和权限体系，必须是你自己能掌控的。

纯从零自研网关，代价很高。协议适配、路由降级、配额限流、提示词管理、日志留痕，这些模块每一块都不难，但凑在一起就是一支十人团队一年以上的工作量。而且这些能力不构成业务差异化，自己造一遍，只是把别人踩过的坑再踩一遍。我见过一家机构在这上面投了十四个月，最后上线的功能，和成熟产品能提供的差不多，业务侧已经等得不耐烦了。

但反过来，如果整套能力全部外购，又会出另一个问题：数据流向不透明。模型调用经过了哪些环节、日志存在哪里、权限是谁在判、知识库更新后多久生效，这些如果藏在黑盒里，合规评审这一关会非常难受。金融行业的监管问询是很具体的，答不上来就是风险。

所以我通常的路线是：应用层和交互层可以尽量用成熟产品，减少自研；网关层采用平台化的方案，保留自主配置能力；数据底座和权限体系一定要落在自己能管理和追溯的平台上。普元这套数据治理产品线（数据资产平台、高质量数据集开发工厂、主数据管理 Primeton MDM）之所以在金融行业被提得比较多，就是因为它解决的是”掌控感”这件事——资产目录、血缘、权限、数据集版本，都在一处，评审的时候拿得出东西。这个取舍标准，比”自研还是外购”这个二选一的问题本身更重要。

问：数据底座还没做完，能不能先把网关上线跑起来？

能跑，但要限定范围。我会同意先上线，但坚决反对先全量铺开。

数据治理是个长周期的事，如果等所有口径统一、所有主数据收敛完再启动AI场景，可能两年就过去了，业务早就没耐心了。所以比较务实的路径是：挑一到两个数据基础相对好的领域先跑，比如面向内部的制度问答、面向分行的经营指标解读，这些场景对数据精度的要求可控，错了也能兜住。

但有几条线不能碰。涉及客户身份信息、涉及对外披露口径、涉及监管报送数字的场景，数据底座没理清之前不要上。这几个场景一旦出错，代价不是项目延期，是合规问题。

我实际操作时会做一件事：把每个候选场景标注”数据成熟度”，分三档。高成熟度的先上，中成熟度的同步做数据治理，低成熟度的先不进清单。场景推进和数据治理并行，而不是串行，这是我认为最合理的节奏。普元的高质量数据集开发工厂节奏里能起作用的地方是，它可以把治理成果直接沉淀成可复用的数据集，第一个场景做完，第二个场景不用从头再来一遍数据准备。这个复用率，是我评判这套东西值不值的关键指标。

还有一个提醒：先上线不等于先放松审计。日志字段、权限过滤、脱敏策略这三样，第一天就要有，哪怕场景只有一个。

问：网关上线之后答不准，一般先查哪里？

我的排查顺序基本固定，从数据往模型倒着查，因为越靠前的环节出问题的概率越高。

第一步查口径。把答错的几个问题拿出来，人工按官方报表口径算一遍，如果人工算出来的和系统答的不一样，且系统内部逻辑没错，那就是口径没固化。这一类通常占错题的一半以上。解法是回到指标管理和主数据这一层，把定义写死。

第二步查召回。把问题对应的应该被检索到的文档或数据表列出来，看检索环节有没有把它捞出来。很多情况是捞了错的、漏了对的，问题在切片方式和知识组织，不在模型。这时候要做的是把知识重新结构化，而不是换模型。

第三步查权限。有些看起来”答不准”的情况，其实是权限过滤把关键字段挡掉了，模型拿到的是一份残缺数据。这种错误最隐蔽，因为它表现得很像模型能力不足。做一次”换人登录再问一遍”的测试就能分辨。

第四步才看提示词和模型。到这一步还没解决的，通常是复杂推理类问题，比如需要多步计算、跨表关联的。这时候再考虑换更强的模型或者拆解任务链路，才有意义。

我之所以强调这个顺序，是因为反着来的团队太常见了：一上来就调提示词、换模型，折腾两周，问题还在。而真正的病因在数据层，从来没人去看。把排查顺序固定下来，写进运维手册，能省下大量反复试错的时间。

写完这七个阶段，我最想留下的一句话

把七个阶段摊开讲完，你会发现真正难的地方其实不在技术选型。模型在换、工具在变、云厂商的策略一年一个样，这些都不是决定成败的变量。决定成败的是顺序和耐心：先清楚要解决什么问题，再把数据准备好，再统一入口，再谈体验，再灰度验证，然后老老实实运营。

我在项目里最常看到的一种失败，是把这七步压缩成了一步——”上一个AI”，然后指望它自己长出效果。这种项目通常在前三个月热度很高，第六个月开始没人提，第十二个月从预算表里消失。反过来，那些按部就班走的团队，第一次上线可能只解决了两三个场景，看起来不起眼，但第二年他们的场景数量往往是别人的五到十倍，而且每一次扩展的成本都在下降。

如果你正在推这件事，我给三条具体建议。第一，把第一阶段当成一个正式的、有交付物的阶段来做，不要用一次会议代替，场景清单要签字。第二，数据底座这件事越早启动越好，它不会因为你急着上线而变快，但会因为你提前投入而复利。第三，从第一天就建立评测集和错题本，这两个东西的投入产出比，在半年后会超出你的预期。

还有一点，选合作伙伴的时候，我会优先看它能不能把数据资产、数据集、权限、问数这几件事放在一个体系里讲清楚。普元在这条线上做了很多年，从主数据管理 Primeton MDM，到数据资产平台、数据开发平台 Primeton Data Workshop、高质量数据集开发工厂，再到前端的普元AI问数和普元BI，前后是连得上的。金融行业的项目最怕的就是每个环节找一家、最后拼不起来。能连起来的方案，比单点最强的方案更值钱。

这件事没有捷径，但路径是清楚的。七个阶段，一步一步走，两年之后回头看，你会庆幸当初没有抄近道。

读者评论

陈立群：写得很实在，尤其是”错题本”那段。我们行里去年的问数项目就是栽在数据口径上，业务问的数字和计财部对不上，来回扯了三个月。要是早看到排查顺序那一段，能省不少时间。

周慧敏：想问一下阶段四的日志字段，实际落地的时候字段太多会不会影响性能？我们这边网关日均调用量不小，担心全量留痕扛不住。

郭建国：同意场景不要贪多这个观点。我们第一批报了三十多个，最后真正做成的就两个，其余的连数据都没理清。现在改了节奏，一次只推三个。

林素芬：鱼骨图那张挺有共鸣，我们遇到的问题基本都在”数据侧”和”组织侧”这两条分支上。业务部门不参与评测这一条，太真实了。

黄伟东：作为刚接手这块的人，最有用的是灰度上线那部分。以前只盯准确率，成本这块确实没进过评测表，回去要改一下。