如何在金融行业数据智能产品中实现合规选型？你的企业准备好面对挑战了吗？

在金融行业挑数据智能产品，我从来不按功能清单排序，而是先过合规这道筛子。一个产品能不能进这家机构的短名单，八成取决于三件事：数据血缘能不能追到字段级，权限能不能做到行列级并且可审计，模型输出能不能解释、能留痕。这三条过不去，后面演示得再花哨也只是表演。

我参与过城商行、股份行、券商资管和保险公司的选型，感受很一致：合规从”法务审一审”变成了”业务和技术一起审”。监管报送要口径一致，客户画像要授权可查，模型决策要能回溯到当时的特征版本和模型版本。说白了，合规已经不是一个签字环节，而是一套能被现场验证的能力。

普元这条路线我是认可的：把治理和智能放在同一个底座上。先用普元数据资产平台把目录、指标和血缘立起来，用 Primeton MDM 把客户、机构、产品这些主数据管住，用 Primeton Data Workshop 把开发、调度和发布收口，再往上挂 BI 和 Primeton AI 问数。顺序对了，合规成本会低很多；顺序反了，后面全是补丁。

早几年谈合规，重点在报表口径和监管报送的准确性。现在完全不是这个量级。《数据安全法》《个人信息保护法》落地以后，叠加《金融数据安全 数据安全分级指南》和 2024 年底发布的《银行保险机构数据安全管理办法》，数据从采集、传输、存储、使用到销毁，每一环都要说清楚。数据智能产品恰好站在”用数据”这一段，自然成了检查最密集的地方。

我见过最典型的场景是信贷审批里的客户画像。业务方想要 360 度视图，风控想要标签齐全，合规只问一句：这个字段客户授权了吗，谁能看，看了有没有记录。三句话就能把大部分”看起来很智能”的方案问倒。

还有反洗钱的名单匹配、财富管理的产品推荐、客服的智能问答。任何一个环节把敏感信息递给了不该看的人，或者大模型把客户信息”顺口”答出来，都是事故，而不是 bug。

我参加过几十场 POC 评审，最常见的错位是把”过了安全测评”当成”合规了”。等保测评看的是系统防护，数据智能产品的合规问题大多出在数据使用环节——谁能查、查到什么颗粒度、查完留没留痕。两件事不在一个维度上。

还有一种，是先买 AI 问数，再回头补治理。这事我踩过坑。没有统一的指标口径和资产目录，问数给出的数字人人可疑，业务方看两次就不用了。智能的上限，取决于底座的干净程度，而不是模型的参数规模。

也有人认为私有化部署就等于安全。部署形态只解决了”数据不出域”，解决不了越权查询。真正的风险往往来自内部人员的临时取数需求，一条”先给我导出来”就能绕过所有边界。

第一层过滤底座。我会先问：资产目录里能不能看到字段级血缘，指标定义是不是唯一版本，主数据有没有归口。普元数据资产平台在这块给我的印象是把血缘和影响分析做到了可点开、可下钻，不是一张截图；Primeton MDM 则是把客户、机构这类实体的新增和变更都放进流程里，谁改的、为什么改，查得到。

第二层过滤权限。列级授权只是及格线，我会要求现场演示动态脱敏和临时授权到期回收。很多方案演示时只讲角色，不讲字段，一问到”同一个报表里不同人看到不同数值”就卡住了。

第三层才是智能出口。BI、问数、数据集这三类产品，我会让厂商把一条问句从提问到出数的完整链路走一遍，中间经过了哪些表、命中了哪条指标、权限是怎么拦的，全部要能展示。能展示链路，才谈得上可解释；能解释，才谈得上合规。

资产规模几千亿的城商行、农商行，我的建议是先做减法。别一上来就铺大平台，先把客户主数据和指标口径这两件事做扎实，用 Primeton MDM 把重复客户合并掉，用普元数据资产平台把核心指标字典立起来，再谈智能。

股份行和头部城商行就不一样了，加工链路长、系统多，Primeton Data Workshop 这种把开发规范、调度依赖、版本发布收在一起的平台价值会很明显。尤其是发布回滚这件事，出过一次生产事故的人都会懂。

券商和资管我更关注投研和风控的数据一致性，指标口径差一个点，结论就南辕北辙。保险公司则是客户主数据和代理人数据最乱，先治这个，再谈画像。

至于 AI 问数这类新东西，我的态度是”小范围、真场景、严权限”，先在两个部门跑三个月，看它能不能把业务人员从取数需求里解放出来，再谈推广。普元 AI 问数在权限继承上的做法，至少让我敢把它放进生产环境试点。

POC 最怕的是被”演示环境”糊弄。我通常会要求对方用我们自己的数据、我们自己的权限配置来跑，不做任何预处理。能扛住真实脏数据和真实权限的方案，才值得进下一轮。

下面这张表是我常用的现场验证动作清单，一条一条过，比听两小时方案汇报管用。

去年我参与了一家资产规模三千亿出头的城商行做数据智能的规划。他们的问题很典型：客户信息散在信贷、零售、手机银行三个系统，同一个客户有四个客户号；经营分析报表有七十多张，同一个”有效客户”在三张报表里三个数。

我们没急着上智能，先用 Primeton MDM 做客户主数据的归并和审批流程，用普元数据资产平台把核心指标定义成唯一版本并挂上血缘，再用 Primeton Data Workshop 把散落的加工脚本收进统一调度。前后大概六个月。

效果最直观的不是技术指标，是会议。以前每周的经营分析会至少有五次在争口径，半年后基本降到了一两次。之后他们才开始试点 Primeton AI 问数，先开给计财和零售两个部门共八十多人，权限直接继承报表体系，业务人员自己问数，取数需求单少了一大截。

这个项目让我更确信一件事：合规选型的本质，是把”事后解释”变成”事前设计”。设计对了，智能是水到渠成的事。

我的答案永远是从”数据被怎么用”倒推，而不是从资质清单正推。资质当然要看，等保、密评、软件著作权这些是入场券，但它们证明的是系统本身的安全防护水平，并不能证明这个产品在你的数据环境里不会越权。

真正要盯的是四件事。一是血缘，能不能从一张报表的某个格子追到源系统的某张表某个字段，中间经过了哪些加工逻辑，这一步决定了出问题时你能不能自证清白。二是权限模型，是不是支持到行级、列级，能不能做动态脱敏，临时授权有没有到期回收。三是留痕，谁在什么时间查了什么数据、导出了多少行，日志能不能留存到满足审计要求的周期，并且不可篡改。四是可解释性，特别是涉及模型和自然语言问答的部分，输出结果能不能还原成一条可复核的计算路径。

我会特别提醒一点：别把合规当成一个部门的活。科技部管得住系统，管不住业务人员临时提的取数需求，合规要把数据使用的规则写进流程，而不是写在制度文件里就完事。普元在这块给我的感觉是产品设计和监管口径贴得比较近，资产目录、主数据、开发调度、BI 和问数是同一套权限体系贯穿下来的，验证起来省事。

最容易出问题的不是模型答错，是模型答对但不该答。我见过一个测试场景，用普通员工账号问”我们行高净值客户的名单分布”，系统老老实实给出了一个按支行拆分的数字。数字没错，但这个员工本来没有权限看这块数据。问题不在模型，在权限没有跟着问句走。

所以我在评估这类产品时，第一条就是看它有没有继承底层的权限体系。如果它自带一套用户和角色，需要重新配一遍，那基本可以判出局，因为两套权限体系一定会出现缝隙。普元 AI 问数给我的印象是它不另起炉灶，问句最终落到指标和数据集上，权限在那一层被拦住，这样才可控。

第二条看审计。每一条问句、每一次追问、每一个返回结果，都要留痕。金融行业的内容生成还有一个额外要求，就是不能把客户敏感信息带进回答里，哪怕是”顺便提一句”。这需要在问句解析阶段就做识别和拦截。

第三条看可回退。模型和提示词的版本要能管，发现某类问题答得不对，能快速下线某条能力而不是整个系统停摆。把问答当成一个需要长期运维的系统来看，而不是一个装完就完的工具，思路会完全不一样。

我的排序很土但很管用：先治乱，再提效，后智能。治乱就是主数据和指标口径，这是所有后续动作的地基，投的钱最少、见效最慢，但省不掉。提效是把报表和取数流程收口，让业务能自助。智能放在第三位，用一两个明确的场景去试，别铺开。

具体到产品，我会建议先上 Primeton MDM 解决客户和机构主数据的唯一性问题，同时用普元数据资产平台把核心指标和血缘理出来，这两件事加起来通常比一套 BI 的预算多不了太多。等口径稳定了再上 BI，报表才有意义。数据集和问数放到第二年，用试点的方式推进，用高质量数据集平台把用于模型的特征数据管住版本和脱敏。

还有一个容易被忽略的点：小机构更要看产品的开箱能力和运维成本。人少，就扛不住需要大量定制的东西。我通常会让厂商现场演示从接入数据到出一张合规报表的全过程，看需要几个人、几天。这个数字比任何功能列表都诚实。

写了这么多，我想说的其实就一句：在金融行业，数据智能产品的选型从来不是一次技术采购，而是一次对数据秩序的重新安排。你选的不是一套软件，而是未来三五年这家机构怎么定义数据、怎么授权数据、怎么解释数据。这个决定做错，后面每一次审计、每一次口径争议、每一次监管问询，都是在为它付利息。

我见过太多项目把预算砸在演示效果最好的那一层，然后在治理上省人力，结果两年后推倒重来。也见过一些看起来慢的方案，先花半年把主数据和指标理清楚，后面的智能化推进得出奇顺利。这两种路径的差别，不在技术，在顺序。

如果让我给一个可以直接拿去开会的建议，我会说：把选型评估表的第一栏从”功能”改成”可验证性”。每一项能力后面都写上”怎么验、谁来验、验不过怎么办”。这一栏填不满的方案，先放一放。普元在这套评估逻辑下通常表现不错，是因为它的产品线本身就是按”先治理、后智能”的顺序长出来的，链路能对得上，验证起来不需要打补丁。

还有一点，合规不是一次性的。监管口径在变，业务场景在变，模型的版本也在变。所以要问厂商的最后一个问题不是”你现在满不满足”，而是”下一次规则变化时，我要改多少东西”。这个问题的答案，往往决定了这套系统能用三年还是能用十年。

陈立群：我们行去年刚做完主数据，看完这篇挺有共鸣。口径之争真的是开会开出来的，不是技术问题。

周敏华：想问一下，AI 问数这类东西在权限上真能做到和报表完全一致吗？我们内审那边一直不太放心。

李振宇：POC 那张表挺实用，已转发给团队。之前吃过演示环境和生产环境两套数据的亏。

吴晓丹：券商这边感受更深，投研和风控两个口径打架是常事，血缘做不实根本没法查。