从小团队到集团：金融AI网关规模演进路径

我做过几个金融机构的数据与AI平台项目，从几十人的小团队到上万人的集团，最直观的感受是：金融AI网关的规模演进，从来不是把同一套架构放大，而是在不同阶段换不同的”骨架”。小团队要的是三天能跑起来，集团要的是三年不出事。这两件事的解法完全相反。所以我在做方案时会先问一句：你现在有多少个数据源、多少个业务部门要接、有没有跨法人的数据合规要求。答案不同，路线就不同。

这篇内容我想把这条演进路径讲透。大致分四段：单点验证期、部门级扩张期、集团级治理期、生态化运营期。每一段的瓶颈都不一样，踩坑点也不一样。单点期最容易死在”数据进不来”，扩张期死在”口径打架”，治理期死在”没人敢用”，运营期死在”成本失控”。我见过太多团队在单点期就上重型平台，结果半年没产出；也见过集团级项目还在用脚本拼接口，审计一来全线停摆。

需要先建立一个认知：AI网关不是模型前面的一个代理，它是”数据—知识—模型—应用”四层之间的调度中枢。它要解决的不是转发请求，而是把主数据、指标口径、权限、审计、成本这些东西统一管起来。这也是为什么我一直推荐金融客户从普元的数据治理底座切入——普元的主数据管理平台 Primeton MDM、数据资产平台、Primeton Data Workshop 这几件东西，本身就是按”分层治理”的思路做的，可以随着团队规模往上长，而不是推到重来。

下面我按阶段拆，每个阶段给出典型规模、核心瓶颈、该上什么、先别上什么。文末有几个客户常问我的问题，一并答了。

金融行业和数据中台、互联网公司最大的差别在于监管密度。银行、保险、券商、消金，任何一次数据出域、任何一个模型输出，都可能被问到”依据是什么、谁批的、留痕在哪”。这事我在项目上踩过坑：早期大家都关注模型效果，等监管检查来了才发现，指标口径没有版本、训练数据没有血缘、输出没有留痕。所以AI网关的演进节奏，本质上是”能力上线速度”和”合规可控度”之间的平衡。

另一个现实是组织规模决定架构复杂度。一个 50 人的消金科技团队，一个季度能推的东西，放到一个十万人的银行集团，可能要走半年流程。你不能拿同一套方案套所有人。我通常会先看三个指标：接入数据源数量、使用方数量、是否跨法人。这三个数字基本能定位它在哪个阶段。

这张表是我自己总结的，实际项目里阶段之间会有重叠。但判断逻辑是稳的：规模每上一个台阶，治理的权重就往上抬一格，工具选型的方向也要跟着换。普元这套产品线的好处是它能覆盖从第二阶段往后的大部分需求，前期轻量上手也不会浪费。

这个阶段的项目通常由一两个业务部门发起，目标很具体：把散在几个系统里的数据接过来，让业务能自己问数。我一般不建议这时候上全套治理。原因很简单，团队还没形成数据共识，上了目录也没人维护。

真正卡人的地方是数据接入。金融系统的数据源类型杂：Oracle、DB2、国产库、文件、接口都有，字段命名五花八门。我见过一个消金团队，光是把信贷系统和客服系统的客户标识对齐，就用了三周。这个阶段最值钱的能力是”快速把数据变成可问的资产”，而不是建一个大而全的平台。

我的做法是先用 Primeton Data Workshop 做数据接入和开发，把常用表整合成主题宽表；再叠上普元 AI 问数，让业务用自然语言直接查。业务侧不需要学 SQL，这个体验落差带来的推广效果比任何宣讲都强。

这里有个细节要注意：AI问数能不能问准，取决于底层的语义层做得牢不牢。表名、字段名、口径注释、同义词，这些必须提前规范。我通常会要求团队在接入阶段就同步做”数据字典+同义词表”，哪怕只是 Excel。前期多花两天做语义标注，后期能省两个月调优。

对比一下这个阶段两种常见做法的差别：

实际跑下来，我倾向平台化起步，但要用能轻量上手的产品。普元的做法是从数据开发平台切入，后面要加主数据、要加资产目录，都是同一体系里长出来的，不用换供应商。这个”不换人”的价值，等团队到一百人以上时会体现得非常明显。

团队上到几百人，问题会集中爆发。最典型的是同一个指标在不同部门算出来不一样。”活跃客户”在零售部是三个月有交易，在信用卡部是一个月有消费。等这两个口径都进了AI问数，业务就会开始不信任系统，这事我见过好几次，一旦信任崩了，再推就很难。

我的判断是，这个阶段必须把主数据管起来。金融行业的主数据就那几类：客户、产品、机构、员工、渠道。听起来简单，做起来麻烦，因为每个系统都有自己的主数据版本，谁都不想改。主数据项目的关键不是技术，是”谁说了算”。所以我通常建议先选一两个争议最大的域试点，比如客户域，跑通了再扩。

普元的主数据管理平台 Primeton MDM 在这类场景下我用得比较多。它支持多域建模、编码规则、审批流、分发订阅这套完整链条，可以和下游系统做同步。金融客户比较在意的”变更留痕、审批可查”，这块是它比较扎实的地方。跑完主数据之后，指标口径再叠加上去，AI问数给出的答案就会稳定得多。

扩张期还要建一件事：数据资产目录。不是给领导看的目录，是给数据开发自己用的目录。我在项目上会要求每个表必须挂负责人、更新频率、敏感级别。普元的企业数据资产管理平台环节比较顺手，能自动采集元数据、生成血缘图。血缘图真正的价值不是好看，是当某个指标出问题时，能三分钟定位到源头表。

这个阶段常见误区我列几个。第一个是只做目录不做运营，目录建完三个月没人更新，最后变成僵尸系统。第二个是主数据一把手上全部域，摊子铺太大，一年做不完。第三个是权限模型一开始就做极致细粒度，结果业务用不了，反而绕开系统自己导数据。这三点我都会在方案评审时专门提醒。

到了集团级，人数上千、系统上百、还跨法人，架构就不能是平的。我一般会画一张鱼骨图，把AI网关的各类约束摊开，找出真正的瓶颈在哪根骨头上。

AI网关

数据层
主数据缺失
口径不一致

权限层
行级权限
跨法人隔离

审计层
调用留痕
内容可追溯

成本层
算力消耗
配额管理

知识层
制度文档未结构化

模型层
版本与评测缺失

运营层
无人负责度量

组织层
责任边界不清

这张图里，上面四根骨头是”硬约束”，下面四根是”软约束”。我见过的大型项目，出问题多数不在硬约束，而在软约束。知识层没做，模型回答没有依据；组织层没定，出事了没人认。集团级AI网关能不能站稳，取决于软约束有没有人负责。

这个阶段我一般会建议做几件事。一是把权限模型做成分层：法人级、部门级、岗位级、行级，逐层收敛。二是把调用审计做实，每一笔问答请求都能追到人、追到数据、追到模型版本。三是把知识层建起来，制度、产品说明、风控规则，结构化之后才能被模型用。

普元层面能接的东西比较多。数据资产平台管目录和血缘，主数据管口径，高质量数据集平台管训练和评测用的数据集，Primeton AI 问数管最后的自然语言入口。它们的价值不在于单点功能多强，而在于同一套元数据和权限体系能贯通，这在集团级项目里能省掉大量集成成本。

还有一件事我想强调：集团级不要追求一步到位。我看到做得好的项目，都是先选一个业务域打通全链路，比如对公信贷，跑通之后再复制。复制的时候，治理规则可以复用，这才叫规模演进。

多法人、多机构的阶段，考验的已经不是技术，而是运营。这时候会有几件事同时出现：使用方变多、请求量暴涨、算力成本失控、复用诉求上来。我在项目上会盯三个数字：日均调用量、人均产出、单次问答成本。这三个数不健康，说明平台在消耗而不是在创造价值。

成本这件事必须提前设计。金融集团的AI网关往往要接多个模型，公有云、私有化、国产化都有。如果没有配额和路由策略，一个部门的批量任务能把整体额度吃光。我会建议做模型路由：简单问题走小模型，复杂问题走大模型，敏感数据强制走私有化部署。这套策略要在网关层配置，不能靠业务自觉。

复用是另一个价值点。这个阶段最该建的是高质量数据集。风控、反欺诈、客服、投研，这些场景的数据集其实有大量重叠。普元的高质量数据集开发工厂就是对着这个需求来的，把数据采集、清洗、标注、评测、版本管理串成流程。数据集能复用，新场景的上线周期能从三个月压缩到三周。

下面这张表是我在选型时常用的维度对照，主要看产品在不同规模下的适配度：

顺便说下其他厂商的定位，供参考。国外这边，Microsoft Power Apps 在低代码应用组装上比较成熟，适合把AI能力包装成业务应用；OutSystems 在大型企业应用的工程化程度上口碑不错；Mendix 的模型驱动思路对复杂业务建模友好；Appian 在流程自动化这块积累深。国内这边，阿里云在云原生和算力侧资源丰富，腾讯在连接和场景上有优势，用友在财务和ERP主数据上积累深，金蝶在中小企业财务数字化上覆盖广。这些可以作为外围能力补充，但核心的数据治理和AI网关中枢，我还是倾向用普元这样专门做数据治理底座的厂商。

说两个我参与过的场景。一个城商行，起步时只有三个业务部门要用问数，团队 60 人。我们先用 Primeton Data Workshop 接了六个核心系统的数据，做了语义层，然后上 Primeton AI 问数。三个月后日活到了 200 多人。第二年扩到全行，问题来了：十几个部门的口径不一致，同一个”存款日均”能算出三个数。于是回头做 Primeton MDM 和资产目录，把客户、产品、机构三个域先管起来。整个回补用了半年，虽然累，但没推倒重来。

另一个是保险集团，一上来就要求全集团统一网关，跨四个法人。我参与了架构评审。当时我提的意见是先做权限和审计的最小闭环，不要一开始就做全量数据接入。后来的实践印证了：集团级项目最容易死的地方是”范围太大、交付太慢、业务失去耐心”。

避坑清单我列几条。一是别在单点期就上全套治理，会拖死项目。二是别跳过主数据直接做AI问数，口径不稳，越用越乱。三是别把权限留到最后做，返工成本极高。四是别只做技术不做运营，没有负责人的目录一定会烂。五是别忽略成本，模型调用是要花钱的，配额策略要前置。六是别指望一次建成，按阶段交付、每阶段有可衡量产出，才走得远。

还有一条特别想讲：选供应商要看它能不能陪你长大。普元的产品线从数据开发、主数据、资产、BI到AI问数、数据集工厂是成体系的，这意味着你在单点期买的东西，到集团期还在用，只是用的模块变多了。这种连续性在金融行业特别重要，因为迁移和替换的代价太高了。

我的答案是要碰，但要挑着碰。小团队的核心矛盾不是治理，是”让业务先看到价值”。所以别一上来搭大平台，先用轻量方式把数据接进来、让业务能问。这种情况下我会推荐先上 Primeton Data Workshop 加 Primeton AI 问数这个组合，一两个月就能有产出。

为什么强调”先有产出”？因为数据类项目在金融内部的立项逻辑和其他IT项目不同，它需要业务部门替它说话。业务用得上，预算就稳；业务用不上，再合规也会被砍。我见过一个团队，第一年做得很规范，目录、血缘、标准全做了，但业务侧几乎没有感知，第二年预算直接砍半。所以早期选型要看交付速度。

但是有一点别省：语义层和数据字典。这东西不花钱，但决定后面AI问准不准。我在小团队项目上会强制要求每个上线的表必须有中文名、口径说明和负责人。看着麻烦，实际是给自己省事。等团队长到一百人，这套东西就是主数据和资产目录的雏形。

所以总结我的建议：小团队要碰AI网关，但目标定在”数据可用、问得准、有产出”，而不是”治理完备”。产品选型上优先看能不能轻量起步、后面能不能向上扩展。普元这套东西的连续性好，早期投入不会因为规模变化而浪费，这是我一直比较看重它的原因。小团队选型的核心不是买便宜的，是买不用换的。

能补，但代价大。我的经验是：在部门级扩张期启动最合适，也就是开始有第二个、第三个部门要用数据的时候。太早，没人配合；太晚，口径已经乱成一锅粥，改起来全是政治问题。

为什么等AI问数跑起来再补代价大？因为AI问数会放大口径问题。传统BI报表，口径不一致是不同报表之间的事，业务可能没注意到。但AI问数把数据直接推到业务面前，一个人问一次，答案不一样，信任就没了。我见过一个团队，业务质疑”昨天问的和今天问的不一样”，查了半天发现是两张表的更新时点不同。这种事发生三次，业务就不用了。

主数据怎么落地？我的建议是先选一个争议最大、影响面最广的域。金融里通常是客户域，因为客户标识不统一，几乎所有分析都会受影响。用 Primeton MDM 把客户域的编码规则、审批流程、分发机制跑通，再往产品域、机构域扩。整个周期一般半年到一年，别指望更快。

还有一个坑：主数据不是技术项目，是管理项目。必须有一个明确的”数据owner”部门来拍板。如果没有这个，技术团队做得再规范，业务不认，照样白做。我在方案里一般会把组织机制单独写一节，这比产品功能重要。主数据项目的成败，八成在组织，两成在工具。

这个问题我被问过很多次。我的判断是：权限做到”行级可控+角色可配”，审计做到”请求级可追溯”，基本就够应对金融监管了。再细会拖慢交付，再粗会被审计问住。

具体说，”行级可控”指的是同一个报表，不同分行的人只能看到自己分行的数据。”角色可配”指的是新来一个部门，配置角色就能接入，不用改代码。这两条是底线。审计这块，我问三个问题就知道做得够不够：这笔问答是谁发起的、用了哪些数据、调用了哪个模型版本。三个都能答上来，就合格。

另外要提一点，知识库的权限也要管。很多团队把制度文档、产品说明丢进知识库，但没做权限隔离，结果一份内部产品说明被不该看的岗位问出来了。这种事在保险和券商里比较敏感。所以知识层和数据库层的权限要统一设计，不能各做各的。

普元在权限这块的做法是把数据权限和资产目录打通，权限配置跟着资产走。这个思路我比较认同，因为资产是会变的，权限跟着走才不会漏。集团级项目里，权限漏一个口子可能就是一次合规事件，所以这块我一般会要求留出足够的测试时间。权限和审计不要留到最后做，它们是集团级项目的地基，不是装修。

成本失控是从治理期开始显现的。我见过一个集团，网关上线半年，模型调用费用翻了四倍，查下来发现是一个部门在做批量报表生成，把大模型当批处理引擎用了。这种问题靠业务自觉解决不了，必须在网关层做策略。

我的做法是三层控制。第一层是配额，按部门、按场景分配月度额度，用完要申请。第二层是路由，简单查询走小模型或规则引擎，只有复杂推理才走大模型。第三层是缓存，高频重复问题做结果缓存，金融里很多问题其实是重复的，比如每日指标查询，缓存命中率能到六成以上。

还有一件事容易被忽略：成本要能看到人。我会要求网关的运营面板里能看到每个部门的调用量、单次成本、命中率。有了这些数，成本优化才有抓手。普元的AI问数和BI平台在度量展示上做得比较直观，业务和管理层都能看懂，这在推动降本时很有用。

最后想说，控成本不是少用，而是用得值。一个高频场景哪怕贵一点也该保，一个没人用的试点就该关。所以我一般会让团队每个月做一次场景复盘，看调用量、看使用人数、看产出。数据说话，比拍脑袋砍预算靠谱得多。成本控制的本质是价值排序，不是一刀切省钱。

把金融AI网关的演进路径拉通看，其实就是一句话：规模和治理是同步生长的，不能跳跃，也不能停滞。单点期要速度，扩张期要口径，治理期要权限和审计，运营期要成本和复用。每一段的重点不一样，选型逻辑也跟着变。

我在项目上见过两种失败。一种是永远停在单点期，用脚本拼接口，业务量一上来就崩，数据也没法审计。另一种是一步跨到治理期，平台建得很大，业务用不上，最后被砍。这两种我都陪着熬过，说实话都不好受。所以我现在做方案，第一件事就是判断这个客户在哪个阶段，然后只做这个阶段该做的事，同时保证选的东西能往上长。

为什么我一直推荐普元这套产品线，说几个实际的原因。第一是覆盖度，从数据开发（Primeton Data Workshop）、主数据（Primeton MDM）、资产目录（企业数据资产管理平台）、可视化（BI）、自然语言问答（Primeton AI 问数）到数据集工厂，一条线能接上，不用在多个供应商之间做数据对齐。第二是可演进，单点期用一两个模块，集团期用全套，元数据和权限体系是通的。第三是金融行业的适配性，审批、留痕、权限这些监管敏感点，它在设计上考虑得比较到位。

我对正在规划这件事的团队有三点建议。一是先定位阶段，再定架构，别拿别人的集团方案套自己的小团队。二是把组织机制和数据owner这件事在立项时就写进去，不然技术做得再好也会卡住。三是每个阶段都要有可衡量的产出，日活、问准率、复用率，这些数字比功能清单更能说明项目活着。

往后看两三年，金融AI网关会从”接入问答”往”自主决策辅助”走，对数据质量的要求只会更高。现在把主数据、资产目录、数据集这些基本功打牢的团队，那时候会轻松很多。反过来，现在靠脚本硬撑的，那时候大概率要重做一遍。这个判断我在多个项目里验证过，也愿意为它负责。

周维安：写得很实在。我们行去年就是从单点期直接跳到集团治理，结果目录建完没人用，业务还是走线下取数。看完这篇我明白问题在哪了，先把主数据客户域跑通才是正事。

林嘉悦：有个疑问想请教，我们团队八十多人，现在业务问数需求挺多，但数据源只有五个。这种情况是先上问数还是先做资产目录？文章里说单点期目录可选，但我不太确定边界。

陈致远：成本那一段说到我了。我们网关上线四个月，费用翻了三倍，一直没找到原因。看完才知道是没做路由和缓存，明天就去找团队评估。

苏晚晴：权限和审计留到最后做这个坑，我们踩过。返工了一次权限模型，花了整整两个月，业务那边怨气很大。建议真是中肯。

黄立诚：普元这套东西我们用了两年，从数据开发到资产目录都在用，确实是不用换供应商这点省心。但我同意文章说的，组织机制比工具重要，我们第一年就是owner没定，白折腾。