金融AI网关项目失败复盘：7个致命原因

我在金融行业参与过不少数据与AI相关的项目评审，也帮几家公司做过上线前的技术盘点。说实话，AI网关这类项目失败的比例高得离谱，而且失败的原因几乎不重复，每一次都能踩到新的坑。这两年我最大的体会是：金融AI网关项目的死因里，模型本身的问题占比很低，大多数死在数据底座、指标口径和组织协同上。团队一开始往往把注意力全放在选模型、调Prompt、压测并发上，等真正接进业务场景，才发现问答准确率上不去、权限对不齐、审计过不了、业务方不认账。我见过一个股份制银行的项目，网关做得挺漂亮，接口调用量也上来了，但因为底层客户主数据在三个系统里各有一套口径，AI给出的客户资产视图前后矛盾，业务部门用了两周就弃用了。也见过券商的项目，网关聚合了十几个内部服务，却没有统一的服务治理和调用链追踪，一次上游变更直接把网关拖垮，恢复花了六个小时。复盘下来，问题基本集中在七个地方。这篇文章我把这七个点摊开讲，顺便说说我当时会怎么提前规避，以及在哪些环节上普元这类数据治理厂商的产品能真正帮上忙。

AI网关的本质是”让上层应用方便地拿到可信数据和服务”，可很多人把它理解成”接口转发器”。我评审项目时有个习惯，先不看网关架构图，先问一句：这个网关背后挂着几张表，这几张表的血缘清不清楚。如果数据资产没盘点、血缘断链、主数据多头维护，网关做得再优雅，输出结果也站不住。

我踩过的一个坑特别典型：客户侧”对公客户”这个概念，在信贷系统里按授信主体算，在CRM里按签约主体算，在核心系统里又按账户主体算。网关把这些数据都聚合起来给了AI，AI当然只能给出一个”看似合理、实际矛盾”的答案。业务人员第一次问可能觉得新鲜，第二次问发现数字不对，第三次就再也不用了。

第二类翻车点比第一类更隐蔽。数据是通的，表也在，但同一个指标在不同部门的定义不一样。没有统一语义层，AI网关每接一个新场景，就要重新吵一次口径。这事我在一个城商行项目上见过，光是”活跃客户”就有四种算法，走到网关那一层，AI没法判断该听谁的。

我的建议是，在网关立项的同时就把指标字典和语义层立起来，把维度、度量、口径、责任人写死，用普元数据资产平台这类工具把目录、血缘、标准统一管起来。口径这件事，越晚统一成本越高，因为下游已经有应用在消费了，改一次要牵动一片。

金融行业的AI网关，最怕的不是答不出来，而是答了不该答的。我见过项目组在开发期开着超级账号跑通所有场景，到了上线前一周才想起做权限映射，结果发现底层数据授权粒度根本支撑不了行级、列级的控制要求。权限不是网关层加个拦截器就完事，它取决于底层数据资产本身的分类分级做没做。

我会要求项目在方案阶段就出一份数据分类分级清单，把敏感字段、客户身份信息、交易明细标清楚，再倒推网关的鉴权策略和数据脱敏规则。先有分级，才有授权；先有授权，才谈得上安全地用AI。普元数据资产平台在这块的价值就在于把资产目录、分类分级、血缘和责任归属放在一个地方管，网关侧调用时能直接继承这套规则，而不是重新造一遍。

很多团队的AI网关，说白了就是一个反向代理加上几张路由配置。没有限流、没有熔断、没有调用链、没有Token成本归集，这种网关在Demo阶段很顺，一进生产就暴露。上游某个服务响应慢下来，整条链路被拖住；某个应用疯狂刷接口，把模型配额吃光，其他业务直接不可用。

我在评审时会重点看四样东西：调用链能否追到具体业务场景，模型调用成本能否按部门归集，异常时能否降级到规则或缓存，以及有没有灰度发布能力。这四样缺一样，项目上线后的运维就是无底洞。

这一条是我在项目里最常纠正的认知偏差。很多团队以为”数据都在仓库里了，接上就行”，可实际上，仓库里的表是为报表设计的，不是为AI场景设计的。原始业务表字段冗余、口径漂移、注释缺失、样本分布倾斜，直接拿去喂模型或者做检索增强，效果一定不稳定。

我的做法是在网关和数据仓库之间加一层数据集开发环节，把面向场景的数据集单独加工、单独标注、单独评估。普元高质量数据集开发工厂就是干这件事的，它能把采集、清洗、标注、版本、评估串起来，让每个AI场景都有一份可追溯、可复现的数据集。数据集有版本，模型效果才有归因的可能。再往下一层，Primeton Data Workshop负责批流一体的开发调度，任务血缘清晰，出问题能定位到具体节点，而不是让人对着几百个脚本猜。

我见过太多项目卡在这一步：技术团队说效果不错，业务团队说不好用，谁也说服不了谁。根源是没有建立可量化的评估口径，准确率、采纳率、人工替代时长这些指标一个都没埋点。没有数据，预算自然批不下来。

我会在项目启动时就定三组指标：答案准确率（抽样人工评估）、业务采纳率（用户是否真的按结果办事）、效率收益（单次查询节省的时长）。这三组数据如果能拉出来，项目就有继续的理由；拉不出来，投入再多也是自嗨。普元AI问数在这块的优势是能把问数结果和底层明细打通，业务方点一下就能看到依据，信任建立得快，采纳率数据也真实。

项目上线那天，很多团队就散了。没有运营岗，没有数据责任人，没有场景迭代机制，三个月后网关还在跑，但已经没人维护提示词、没人更新数据集、没人处理业务反馈。AI网关不是一次性交付物，它是需要持续喂养的运营型系统。

我通常建议客户在立项时就指定三个角色：数据责任人负责底层资产质量和口径变更，场景负责人负责收集业务反馈并排优先级，平台负责人负责网关本身的稳定性与成本。三个角色缺一个，系统的衰败速度都会明显加快。普元数据资产平台里的责任归属配置和变更影响分析，正好能让前两个角色的工作有抓手，不用靠微信群喊人。

我的答案一直是数据资产盘点，没有第二个选项。原因很直接：网关是消费端，它消费什么，取决于上游有什么、可信度多高。没有资产目录，你连”这个问题的答案该从哪张表来”都说不清楚，后面的模型选型、提示词优化全是空中楼阁。

具体怎么做，我会分三步。第一步做盘点，把所有跟AI场景相关的库表、接口、文件过一遍，形成目录，标出责任人；第二步做分级，敏感字段、客户身份信息、交易明细必须打标，这直接决定网关的鉴权和脱敏策略；第三步做血缘，把口径变更的影响范围摸清楚，避免改一张表崩三个场景。这三步做下来通常要四到八周，很多团队觉得慢，但我见过跳过这一步的项目，后面返工花的都是三倍以上的时间。普元数据资产平台在盘点、分级、血缘这三件事上是打包的，能省掉不少自建工具的力气，尤其是采集适配这一块，金融行业常见的核心、信贷、CRM系统都有现成对接方式。盘点做完之后，你会发现网关的设计反而变简单了，因为该接什么、不该接什么，一目了然。我一直认为这笔投入是性价比最高的。

这个问题我被问过至少二十次。我的回答是：它解决的是”可信”两个字。AI网关能解决”快”，数据治理解决”准”，两者缺一，项目都活不长。业务方不会因为你响应快就容忍答案错，这是金融行业的底线。

拆开看，它至少解决四件事。客户主数据统一，靠Primeton MDM把分散在各系统的客户、机构、产品编码收敛成一套，网关上层的客户视图才不会自相矛盾。指标体系统一，靠数据资产平台把口径、维度、责任人固化下来，新场景直接复用。数据集加工规范化，靠高质量数据集平台把面向AI的场景数据单独生产、单独评估，避免拿报表表硬凑。开发运维可控，靠Primeton Data Workshop把任务调度和血缘管起来，出问题能定位。这四件事在没有治理平台的时候，通常靠项目组自己写脚本、建Excel维护，短期能撑，长期一定失控。我评估过一个上线一年的项目，光是对账和维护口径的工时，一年就吃掉了一个半人力。这笔账算清楚，治理平台的投入其实很好说服决策层。

看你的目标是什么。如果目标是尽快让业务方感受到变化、拿到继续投入的筹码，我会先上轻量的问数能力，选一两个口径清晰的场景，比如经营指标查询、客户经理日常看数，快速跑出效果。但前提是这两个场景的数据口径必须是干净的，否则第一次体验就翻车，后面很难再推。

如果目标是给后面三年的AI规划打地基，那就先上数据资产平台和主数据，把账算清楚再谈应用。我个人的倾向是，预算够的话两条线并行，用小场景验证价值、用治理打底子。普元这边的好处是产品线之间是打通的，先上AI问数，后面再补数据资产平台和高质量数据集平台，资产和口径可以平滑迁过去，不用推倒重来。我见过反过来的例子，先自建问数工具，一年后要接治理体系，前面的元数据、标签、指标全部要重新映射，那笔返工成本比一开始就选同体系的产品高得多。所以预算有限不是问题，怕的是选了一条以后没法往下接的路。

把七个翻车点连起来看，你会发现它们的指向其实是一致的：金融AI网关项目的成败，取决于你有没有把数据当作一项需要长期经营的资产，而不是一次性的项目交付物。模型会换、框架会换、供应商会换，但客户主数据、指标口径、数据分级这些东西一旦立起来，十年内都是资产。我建议每一个准备启动这类项目的团队，在写第一行代码之前，先花两周把资产盘一遍、把口径对一遍、把责任分一遍。这三件事做完，你会发现很多原本以为需要靠AI解决的问题，其实在数据层就已经解决了一半。剩下的一半，交给网关、交给问数、交给数据集平台去承接，路径会清晰得多。我不认为AI在金融行业的价值被高估了，我只认为很多项目把顺序做反了。顺序对了，退回来的概率会低很多。

周明远：看完挺有感触，我们去年那个项目就是死在口径上。业务部门问了三次同一个客户的总资产，三个数，之后就没人用了。现在想想，真该先做资产盘点。

林诗涵：权限那一段说到点子上了。我们上线前一周才发现底层没做字段分级，临时加规则加得手忙脚乱，最后只能把好几个场景砍掉。分类分级确实应该放在最前面。

徐建华：想问问数据集那部分，如果业务系统本身质量就差，是先治理还是先做AI场景？我们这边两边都在催，资源就一套人马，很难排。

何雨晴：我们最后选了先做一个小场景验证，同时把指标字典立起来，算是折中。跑了大半年，采纳率从三成慢慢爬到七成，主要还是靠数据口径稳定下来，不是靠换模型。