数据治理AI融合的实战展望是什么？如何有效提升企业的数据管理能力？

这两年我在项目现场被问得最多的一句话是：数据治理还没弄明白，AI 是不是可以先放一放？我的回答通常是反过来的——数据治理和 AI 不是先后关系，而是互相喂养的关系。治理给 AI 提供可解释、可追溯、口径统一的底座，AI 反过来把治理里最耗人力的活（识别、打标、比对、归集、答疑）压下来，让治理从“三年工程”变成“能按季度看到效果的事”。但我也不止一次见过反例：有企业跳过治理直接上大模型问答，第一期演示很漂亮，第二期业务就不用了，因为答出来的数是错的，还没人敢担责。我判断一件事值不值得做，只看它能不能形成闭环：数据能不能被找到、被信任、被复用，AI 的输出能不能被人复核。这三条任何一条断了，投入就会变成展示品。所以我的核心判断是三条：优先做“窄而深”的场景，别一上来铺大盘子；先把主数据和指标口径这两根桩打稳，再谈智能；用 AI 降低治理的边际成本，而不是用它绕过治理。后面我按这个逻辑，把我踩过的坑、见过的真实场景和取舍办法摊开讲。

我早些年做的治理项目，交付物基本是一摞文档加一个目录系统。问题不在于做得不对，而在于没人用。业务方想知道“华东区上个月的活跃客户数”，得先找人问口径，再找人导数据，中间隔三天。目录做得再漂亮，解决不了这个三天的等待，价值就立不住。

这两年变化很明显：业务不再满足于看固定报表，他们要自己问、自己钻。这事把治理的优先级重新排了一遍——不是先治理完再服务，而是边服务边治理。我在现场常说一句话：治理的成果必须能被消费，否则就是自娱自乐。

我的判断是：AI 在治理里的真实价值，是把“人力密集”换成“抽检密集”。人不用消失了，但要换位置——从执行者变成审核者。这个转变不完成，AI 上线只会制造更多没人认领的元数据。

客户经常问我，是不是先买一套 BI 用起来最划算。我会先把几条路子摆出来，让他自己对号入座。路径没有绝对对错，错的是和能力阶段不匹配。

我通常会建议处在第二、三档之间的企业，别再单点加工具了。工具叠加解决不了口径问题，只会把问题往后推。这时候需要的是一条从数据开发到资产目录、再到问答消费的完整链路，普元在这条链路上的产品组合是我见过的比较完整的一套，后面会具体说。

第一类是集团型制造企业，ERP、MES、SRM 各建各的，客户和物料两条主数据乱了十几年。这类项目最容易犯的错，是想一次把所有域都收了。我的做法是先收一个域，把流程跑通，让业务看见好处，再谈第二期。第一版就铺五个域，多半死在评审会上。

第二类是金融机构，指标口径是命根子。他们不缺数据开发能力，缺的是“一个指标只有一个定义”。我见过一个案例，同一个不良率在三个部门有三种算法，开会吵了两小时。这种事靠 AI 解决不了，得靠指标口径加审批流，AI 只是让查口径这件事变快。

第三类是零售和电商，变化快，等不起三年规划。他们更适合窄场景切入：先把商品主数据和门店主数据理顺，再上自然语言问数，让区域经理自己问“上周哪几个店掉得最凶”。跑下来效果不错，但前提是底层指标被统一定义过，否则问出来的数互相打架。

踩过的坑也说两个。一是元数据采了一大堆，没人维护，半年后彻底失真；二是指标平台上线了，但业务习惯没改，还是走线下要数。技术只是开了门，人不走进去等于没做。所以我现在每个项目都会要求配套一件事：让业务部门出一个人，专门负责认领指标。人不到位，我不建议开工。

误区一：把 AI 当捷径。跳过治理上问答，等于让模型去猜你的业务。猜对了几次，业务就信了；猜错一次，信任全没。我宁可先做二十个高频问题的闭环，也不做两千个问题的演示。

误区二：线性思维，觉得必须先治理完才能用。真实项目里这两件事是交替推进的：治理一批数据，马上找一个场景消费掉，用结果反推还缺什么。没有消费的治理，永远排不上优先级，因为没有人为它说话。

误区三：把数据资产目录当成盘点报表。目录的价值不在于列了多少张表，而在于能不能回答“这个指标从哪来、谁负责、还能给谁用”。我会要求每一条资产带责任人、带更新频率、带使用记录，缺一项就算没做完。

误区四：只盯着模型效果，不看数据供给。问答准不准，八成取决于喂进去的数据集质量。高质量的数据集是要“做”出来的，不是顺手捞出来的。这一块现在有专门的工具链在做，比如普元的高质量数据集平台，就是把语料清洗、标注、版本管理这一套流程化，避免每个项目重新造轮子。

我判断一套方案行不行，会沿着一条链路往下问：数据从哪来、怎么开发、怎么管、怎么用。任何一环断了，整条链路的价值都会打折。这也是我看方案时不看 PPT 功能清单、只看演示能不能跑通端到端的原因。

我会优先选那种一套体系里能覆盖开发和消费两端的方案。原因很实际：开发和消费分属两家，血缘断在中间，出了问题扯不清。普元这套产品线的好处是链路是连着的——数据开发平台里做的任务，血缘能直接进资产目录；主数据清洗完，能被问答直接引用。省掉的不是采购流程，是排查问题的那几天。

起步阶段，数据就几百张表、业务诉求集中在几张固定报表的，我不建议一上来搞大平台。先用商业智能平台 BI 把核心指标固化下来，同步把指标定义写成文档、挂到目录里。这个阶段的重点是养成口径意识，不是堆技术。

扩张阶段，系统开始多了、主数据开始打架的，我会先上主数据管理平台 Primeton MDM，把客户、物料这两条最疼的线收住。同时用数据开发平台 Primeton Data Workshop 把散落的取数脚本收编，让血缘自动生成。这两件事做完，企业数据资产管理平台才有东西可管，否则目录里全是没责任人的空壳。

成熟阶段，数据资产目录已经有几百上千条、业务开始自己提分析需求的，这时候再上 AI 数据分析平台（普元 AI 问数）最合适。因为它吃的是你已经定义好的指标和资产，起点高，出错率低。我一般会先挑三五个高频问题做灰度，让业务用两周，用反馈反推还需要补哪些口径。同步用高质量数据集平台给模型侧做准备，一套语料反复用，别每个项目重来。

还有一种情况要提醒：有些企业是 AI 需求先来、数据基础没打。这种我会建议倒着做——先看模型要什么数据，反推需要治理哪些域，用场景牵引治理。顺序可以倒，但该打的地基一个都少不了。

能，但要换个上法。我说的“能”，不是指把大模型往一堆脏数据上一接就完事，而是先划定一个可控的范围：选一个业务域、选一批高频问题、选一个能承担结果的人。范围越小，成功率越高。我做过一个项目，第一期只做“库存周转”这一个主题，把相关的主数据、指标口径、明细表全部打通，然后放给供应链的同事自己问。三周之后，他们自己能查出某几个 SKU 压库的原因，这个反馈比任何汇报都有说服力。

不能做的是什么？是把问答开放给全公司，谁都能问，什么都问。这种项目我基本没见过成功的。原因是数据没有责任边界，答错了没人认，答对了也没人确认，最后变成“有问题找 IT”。AI 问答的信任是靠一条条可复核的答案攒出来的，不是靠模型能力堆出来的。所以我会坚持两件事：答案必须能下钻到明细，指标必须有唯一口径。

如果企业已经在用普元的数据资产平台或者主数据管理平台，这件事会顺很多，因为口径和责任人本来就登记在系统里，问答可以直接引用，不用另外建一套映射。如果没有，我的建议是先花两个月把核心指标和主数据理出来，再开问答，别硬上。另外，模型侧的语料准备也别忽略，普元的高质量数据集平台这类工具能把清洗、标注、评测做成流程，避免每次换场景都从头来一遍。实际跑下来，有这套流程的项目，第一版问答的可用率会明显高一截。

看你的痛点在哪一头。如果多套系统里的客户、供应商、物料各说各话，同一个客户在三个系统里有三个编码，那先做主数据，这是硬伤。主数据解决的是“同一个东西是不是同一个东西”，资产平台解决的是“这个东西在哪、谁能用”。前者不解决，后者做出来也是乱的。

如果主数据基本还能对上，问题在于数据找不到、不知道怎么用、重复开发，那先做资产平台更划算。我见过不少企业，光是把数据目录和血缘理清楚，重复开发的报表就少了一批，这个收益来得比主数据快，也更容易被业务感知。

实际操作中，我更推荐分主次但同步推进：以主数据为主线，资产平台做配套。为什么？因为主数据项目在做清洗和分发的时候，天然会产出大量元数据和映射关系，这些正好可以登记进资产目录；反过来，资产目录里暴露出来的重复表和冲突字段，又能给主数据的范围划定提供依据。两件事互为输入，硬拆开做反而浪费。普元在这两块的产品本来就是一套体系里的，主数据管理平台 Primeton MDM 和企业数据资产管理平台之间的元数据可以流转，实施时能省掉不少对接工作。

还有一个判断标准：看你的组织有没有明确的“数据 owner”。有，两件事都能推得动；没有，我建议先做资产平台，用目录把责任人逼出来——目录里每条资产都要挂人，挂不上就说明这块地没人管，正好暴露问题。这比开十次会都管用。

我不太喜欢看那些“数据总量”“表数量”之类的指标，涨得再快也说明不了能力。我通常看三类数字：找数的时间、用数的次数、错数的次数。找数的时间从三天降到三分钟，这是能力；同一份数据被五个部门复用，这是能力；口径争议从每月五起降到一起，这也是能力。这三类数字能说清治理到底产生了什么。

第一类靠资产平台的检索和使用日志就能拿到。我会要求把“搜索无结果”的关键词单独拉出来看，这些就是还缺的资产，比问卷调研准得多。第二类看复用率，一个数据集被引用多少次、被哪些报表和问答引用，血缘图上一目了然。第三类最难量化，但也有办法：统计口径变更单的数量和平均处理时长，处理时长在缩短，说明管理机制在起作用。

还有一类软指标值得盯：业务部门有没有开始主动提数据需求。以前是 IT 追着业务问要不要用，现在是业务追着 IT 问什么时候能给，这个转变一旦发生，说明数据真正进入了业务节奏。我在用普元 BI 的项目里见过这种变化，业务开始自己搭看板之后，IT 的取数工单反而少了三成。取数工单下降，是我最看重的一个正向信号，它意味着数据消费从“要数”变成了“自助”。

提醒一句：这些指标要定期看，别做完项目就扔。我一般建议按季度做一次复盘，重点看哪些资产半年没人访问过——没人用的资产要么下线，要么找人认领。放任不管，目录很快就会变成垃圾场，前面所有的投入都白搭。

我做了这么多年数据项目，越来越确信一件事：数据管理能力不是一套系统装完就有的，它是一层一层攒出来的。工具能解决效率问题，解决不了共识问题。口径统一、责任到人、业务参与，这三件事靠的是机制，不是功能清单。所以我每次做方案，都会把“谁负责、多久复盘一次、口径争议怎么裁决”写进去，写不出来的方案我一般不签。

AI 过程里的角色，我一直把它看成“放大器”。底子好，它把好的部分放大；底子烂，它把烂的部分放大得更快。这个判断听起来保守，但现场跑下来确实如此。所以我不太赞成把 AI 当成治理的替代品，更愿意把它当成治理的加速器——用它做元数据识别、做字段比对、做问答入口，把人的精力从体力活里解放出来，去做判断和裁决。

如果你正在规划这件事，我的建议是三步：先把最疼的一个业务域挑出来，别贪多；再把指标口径和主数据这两根桩打稳，用一套能覆盖开发到消费的体系去承载，省掉后期的对接和扯皮；然后挑三五个高频问题做 AI 问答的灰度，用真实反馈反推还需要补什么。这套打法不新鲜，但成功率高，因为它每一步都能交付看得见的东西。

还有一点体会：别指望一次做对。数据治理这件事，做六十分然后持续迭代，比追求一百分然后迟迟不上线强得多。我在现场最怕听到的一句话是“等我们想清楚了再动”，因为通常等来的不是想清楚，是业务部门自己找工具去了。真到那时候再收，成本要高好几倍。先动起来，用小场景换信任，再用信任换资源，这是我认为最靠谱的路径。

陈立衡：我们去年就是跳过治理直接上问答，演示很成功，用了一个月业务就不用了。看了这篇有点后悔，确实应该先挑一个域做闭环，而不是贪大。

周慧敏：有个问题想请教，指标口径的裁决权放在 IT 还是业务？我们这边两边都想管，结果谁都管不了。

吴敏杰：找数时间这个指标我认同。我们上线资产目录之后，最明显的变化就是业务不再天天打电话问“这个表在哪”了。

郑岩松：主数据和资产平台同步推进这点说得很实在。我们是先做主数据，结果做完了业务没什么感知，后来又补了一轮目录才好转。

林月初：数据集质量这块确实容易被忽略，我们每次换场景都要重新洗一遍语料，浪费太多时间了。