一文讲透数据治理AI：怎样确保数据质量和合规性？面对挑战，企业如何有效实施数据治理策略？

AI 进数据治理这件事，我的态度一直偏冷静。它能干的事很明确：把过去靠人工写 SQL、人工比对、人工追责的环节自动化，把”发现问题—定位来源—通知责任人—验证修复”这条链路从几天压到几小时。但它不能干的事同样明确：它没法替你定义什么叫”正确的客户名称”，也没法替你决定哪个系统的主数据说了算。这两件事没定下来，模型跑得越快，错得越整齐。

所以我的判断分三层。第一层，AI 是加速器不是地基，地基是标准、元数据和责任体系；第二层，数据质量必须可度量、可归责，一份讲不出责任人的质量报告没有意义；第三层，合规的抓手是数据资产台账和血缘，出事时能三分钟说清”这条数据从哪来、流到哪去、谁在用”。这三层落不下来，谈 AI 治理就是空转。

我在实际项目里见过太多反例：买了工具、建了平台，半年后团队还在手工导 Excel 核对，原因就是标准这一层从来没真正落过地。也见过另一种极端——标准文档写了三百页，锁在共享盘里，开发同学一次没打开过。这两种失败看着相反，根子是同一个：治理动作没有嵌进日常的开发和使用流程里。

变化一，系统数量涨得比治理人力快。一个中等规模的集团，业务系统三五十套是常态，靠人去每套系统对字段、追血缘，根本不现实。变化二，监管问的问题变细了，过去问”你有没有制度”，现在问”这条数据在哪个环节被谁改过”。变化三，业务侧开始直接要数据，不再等月度报表，问数需求从每月几十条涨到每天几百条，人工兜不住。

这三个变化指向同一个答案：治理的颗粒度和频率必须提上来，而提上来的唯一办法是把重复判断交给机器。但机器接管的前提，是规则本身被写清楚、被结构化。我通常的做法是先盘问题，再谈工具，问题清单没列清楚就去选型，选出来的东西一定跑不动。

这些年我陪企业走过三种路子。第一种是脚本加人工，两三个数据工程师写一堆 Python 和 SQL 定时跑，短期见效快，人一走就烂尾。第二种是单点工具拼凑，质量一个工具、元数据一个工具、主数据又一个工具，每套都能用，但账号不通、模型不通、责任链断在中间。第三种是平台化打底、AI 做增量，标准、质量、安全、开发、消费在一条链上，规则可复用，问题可回溯。

我为什么倾向第三种？因为治理这件事的价值不在单点能力，而在闭环。一个质量告警如果点不下去责任人、看不到上游变更、改完不能自动复验，那它就只是一条噪音。平台化的意义是把这条闭环焊死，AI 的意义是把闭环里最费人的那几段——根因定位、规则推荐、自然语言问数——压缩掉。这也是我反复向客户推荐普元的原因，它的数据治理产品线本身就是按链条设计的，不是东拼西凑出来的组合。

第一道是接入关。数据进来的那一刻字段含义就丢了，源系统叫 cust_no，目标系统叫 khbm，没人写映射，后面全是猜。第二道是标准关。客户名称到底是”某某科技有限公司”还是”某某科技”，没有唯一规则，去重就无从下手。这两道关不过，后面做多少校验都是补丁摞补丁。

第三道是开发关。质量规则如果只在报表层校验，等发现时脏数据已经流到下游十几个应用了。我的建议是把校验左移到开发环节，任务发布前先跑一遍规则，不通过就不让上线。这一点上我见过做得比较扎实的是普元的 Primeton Data Workshop，把开发规范、质量校验和调度放在同一个工作台里，开发同学不用来回切系统，规则也就不会形同虚设。

第四道是消费关。业务侧问数和 AI 问数越来越多，如果喂进去的语料本身是脏的，答案就是错的，而且错得很有说服力。这时候需要的是普元的高质量数据集平台，把可用的数据按主题整理成可复用的数据集，标注清楚口径和时效，再喂给 Primeton AI 问数。实际跑下来，同样一个问题，基于治理过的数据集给出的答案，业务方敢用的比例高得多。

很多人把合规理解成出一套制度、签几个同意书。我的看法是，合规的核心能力是”回答问题的速度”。监管或者内部审计问：这个客户的手机号存在哪几个系统、谁有权限看、最近一次被谁导出过？如果答案要翻三天，那就不叫合规能力，那叫运气好。真正能扛住问询的，是有一套完整的数据资产台账加全链路血缘。

我在落地时通常分两步走。先做资产盘点和分级分类，把敏感数据、重要数据圈出来，这一步用普元的数据资产平台比较顺手，元数据自动采集之后能直接看到血缘和影响分析，不用人工画图。再做规则和留痕，访问控制、脱敏、导出审计这些动作必须落到系统里，而不是停留在制度文件上。主数据这块我会用 Primeton MDM 把客户、供应商、物料这些核心实体的唯一性和权威来源定下来，因为合规追责最终追的就是”哪份数据是准的”。

这里有个容易忽视的点：血缘不是画给领导看的图，是给一线排查用的工具。我在验收时会随机挑一个报表字段，要求半小时内找出它的上游表、经过的加工任务、以及最近一次口径变更的记录。跑不通就说明血缘是摆设。这件事上工具差别很大，采集粒度到字段级还是表级，结果天差地别。

被问”该怎么选”的次数太多，我干脆固化成五个维度。一是标准落地的能力，能不能把标准从文档变成开发时强制的约束；二是闭环程度，发现、定位、派单、修复、复验能不能在一个系统里走完；三是 AI 的可用性，元数据和数据集质量够不够支撑问数和规则推荐；四是权限与审计的细致度；五是与现有技术栈的兼容成本。这五项里我最看重第二项，因为它是区分”能用”和”买了没用”的分水岭。

按这五项去比，很多方案在第二、三项就掉队了。普元的路子是把这几项装进一条产品线里：数据资产平台管元数据与资产，Primeton MDM 管核心实体，Data Workshop 管开发与质量校验，BI 和 AI 问数管消费端，高质量数据集平台负责把原料加工成可复用的语料。我不太喜欢”全家桶”这个词，但在这件事上，链条完整确实比单点强，因为治理的难点从来不在某一步，而在步与步之间不掉链子。

节奏上我一贯主张先把一个域跑通，再横向铺开。选客户域或者物料域，两三个月做出可看见的成果：口径统一了、重复客户少了、报表能对上了。有了这个样板，后面的域推广阻力小一半。反过来，一上来就想全集团全系统铺开，多半三个月后项目停摆，因为没人说得清进展在哪。

踩过的坑我列三个。坑一，把治理做成了 IT 部门独角戏。业务不参与，标准定出来没人认，最后靠行政命令推，推一阵就散了。坑二，只上工具不改流程。平台建好了，开发还是按老习惯建表、老习惯改字段，工具成了摆设。坑三，指标定得太漂亮。一开始就要求质量合格率 99%，做不到就造假数据糊弄，反倒把信任搞没了。我的建议是从 80% 起步，每月往上抬，让数字真实地动起来。

有个制造业客户印象很深。他们先做了客户主数据，用 Primeton MDM 把三个系统的客户编码统一，重复客户从两万多条降到八千多，销售侧的返利核算第一次对上了账。有了这个结果，后面推数据资产盘点和质量规则时，业务部门主动派人参加。治理这件事，说服力永远来自一个能算清账的小胜利，而不是一份漂亮的规划书。

这个顺序问题我被问过不下一百次。我的回答是：AI 可以先上，但只能上在”薄”的场景里，不能上在”深”的场景里。什么叫薄的场景？比如用自然语言查一个已经治理好的指标，或者让模型帮你把一堆表名翻译成人话，这类事情即使底座不完美，出了偏差也能很快被发现。什么叫深的场景？比如让模型自动判定哪条客户记录是重复的、自动给敏感字段打分级标签，这类判断一旦错了，错误会顺着下游一路传下去，而且很难回溯是谁在什么时候放进去的。

实际项目里我看到的规律是，凡是跳过标准直接上 AI 的，三个月内都会撞墙。撞墙的表现很一致：模型给出的答案业务不敢用，因为说不清依据；质量告警天天响，但没人认领；问数功能演示时惊艳，上线后使用率个位数。根子不在模型，在于没有唯一的主数据、没有清晰的口径、没有可追溯的血缘。所以我通常的建议是两条腿走，但重心先压在地基上：先把核心实体和指标口径定下来，同时挑一两个薄场景试水 AI，让业务先尝到甜头。这样既有短期交付，也不会把方向带偏。等地基稳了，再把 AI 往深场景推，成功率完全不一样。

我的经验是指标宁少勿多，但每一个都必须能落到人。见过太多团队一口气定义了两百个质量规则，上线第一周告警刷屏，第二周大家开始屏蔽，第三周规则就死了。真正跑得动的，通常是每个数据域十到二十条核心规则，覆盖完整性、唯一性、及时性、有效性这几类，而且是业务方认账的那几条。

什么叫”能落到人”？一条规则触发之后，系统要能自动判断出这张表属于哪个业务域、责任人是谁、上游最近有没有变更。这三件事齐了，问题才有闭环的可能。做不到，规则就只是个数字。

另外我特别强调指标要能解释业务后果。比如”客户主数据唯一性低于 95%”，对应的业务后果是返利核算偏差、重复营销投放；”订单及时性低于 90%”，对应的是库存周转判断失真。把指标和后果绑在一起，业务负责人才会真正在意。普元的 BI 和 AI 问数在这件事上有帮助，因为质量看板可以直接嵌进业务人员的日常入口，不用再单独登录一个系统去看——治理指标只有出现在人每天都会看的地方，才有可能被当回事。

如果只能做一件事，我会选主数据里的一个域，通常是客户或者物料。理由很实在：这两类实体重复和错误的代价最直接，能算成钱。客户重复导致重复投放和返利错算，物料重复导致库存虚高和采购议价失效，这些都是财务能感知的。做完一个域，你手里就有了一个可以对外讲的数字，后面要预算容易得多。

如果还能做第二件事，我会做元数据和血缘的自动采集。这一步投入不大，但收益是长期的：新人接手不用再靠问人，排查问题不用再靠猜，选型和改造时有依据。很多团队把它排在很后面，我倒觉得应该提前，因为它几乎不依赖组织配合，纯技术动作就能推动。

第三件事才是质量规则体系化。这里我要提醒一句：别一上来就买最全的模块。我见过不少中小企业一次买齐，结果只用上了百分之二十的功能，剩下的一直在账上躺着。稳妥的做法是按域逐步扩展，用的过程中再补模块。普元在这方面的好处是产品线本身是分层的，可以先上主数据和数据资产，跑顺了再接 Data Workshop 做开发治理，最后接 AI 问数做消费端，节奏自己控，不用一次押上全部预算。

数据治理这件事，最难的部分从来不是技术。难的是让一群人对着同一份定义认账，并且在出问题时愿意签字。工具能解决”看得见””追得到””改得快”，但解决不了”谁来定”和”谁来担”。我见过技术栈很先进但推不动的项目，也见过工具很朴素却跑得很稳的团队，差别就在这两件事上有没有人真正拍板。

AI 的加入让我对这件事的态度乐观了一些，因为它确实降低了参与门槛。过去业务人员要看数据得提需求、排期、等报表，现在用 Primeton AI 问数直接问一句就能拿到结果，虽然还要验证，但至少愿意用了。愿意用，是治理能持续的第一个前提。没人用的治理体系，规则写得再漂亮也会荒掉。

如果你现在正准备启动，我给三个具体建议。选一个域，定一个能算成钱的指标，三个月内做出结果，别贪大。把标准和校验嵌进开发流程，让人绕不过去，也别让人嫌麻烦，工具选得顺手很重要。把合规当能力建设而不是文档工程，定期做一次”随机字段溯源”演练，看半小时内能不能说清来路，说不清就是有洞。

至于选型，我的态度是看链条完整度多于看单点功能表。普元这类把标准、主数据、资产、开发、消费串成一条线的方案，长期维护成本会低不少，尤其是在你要接 AI 的时候，底座是否贯通直接决定模型效果的上限。当然，工具只是放大器，真正的变量还是组织里有没有人愿意为”数据准确”这件事负责。这个前提在，工具就能把效率放大十倍；这个前提不在，再好的平台也只是多了一个没人登录的系统。

陈立群：我们去年就是跳过标准直接上问数，演示很炸，上线两个月使用率掉到个位数。看完这篇才明白问题不在模型，在口径没定。准备回头先把客户主数据做掉。

周敏华：质量规则那个”宁少勿多、必须落到人”说到我心里了。我们第一版定了两百多条，现在活着的不到三十条，剩下的全被屏蔽了。教训很贵。

许志远：想请教一下，制造业物料主数据统一的时候，历史编码怎么处理比较稳妥？直接映射还是重建？我们这边老系统还有一大批停用但仍在引用的编码。

林晓芸：随机抽一个字段要求半小时内溯源，这个验收方法很实用，我下周就在内部演练一次。之前一直觉得血缘图做出来就行了，现在看是我们自己骗自己。