国际数据管理协会（DAMA International）是全球最具影响力的数据管理专业组织之一。其发布的《DAMA-DMBOK（Data Management Body of Knowledge）》被广泛视为数据管理领域的基础知识体系。 DAMA 对数据管理给出了经典定义： "Data Management is the development, execution, and supervision of plans, policies, programs, and practices that deliver, control, protect, and enhance the value of data and information assets throughout their lifecycles." —— DAMA International 即 数据管理是围绕数据和信息资产全生命周期开展规划、执行和监督的一系列制度、流程与实践活动，其目标是交付、控制、保护并持续提升数据资产价值。 在此基础上，DAMA-DMBOK 将数据管理拆解为多个知识领域，覆盖治理、架构、质量、安全、元数据、主数据等核心能力，构建了一套完整的数据管理理论框架。 但在实际项目中，很多企业都会遇到同一个问题： DAMA 告诉我们应该做什么，却没有直接告诉我们应该从哪里开始，以及具体如何推进。 尤其是在数据中台建设过程中，企业真正需要的往往不是一套知识体系，而是一套能够指导项目实施的工程化方法。 经过大量项目实践可以发现，龙石数据提出的“理采存管用”方法论，恰好能够将 DAMA 的理论框架转化为可执行的落地路径。 一、DAMA 的 11 个知识领域：一张全景图 先快速过一遍 DAMA-DMBOK 的核心领域，为后续的映射做铺垫： 领域 核心关切 在中台建设中的含义 数据治理 谁决策、谁负责、制度怎么定 治理组织和制度建设 数据架构 数据怎么组织、怎么流动 数据模型和集成架构设计 数据建模与设计 概念模型、逻辑模型、物理模型 数仓分层和模型设计 数据存储与操作 数据存在哪、怎么管 存储选型和运维 数据安全 谁能看、谁能改 权限和脱敏 数据集成与互操作 不同系统的数据怎么通 多源异构数据汇聚 文档与内容管理 非结构化数据怎么管 文档和知识库 参考数据与主数据 核心实体的统一编码 主数据管理 数据仓库与 BI 分析怎么支持 报表和可视化 元数据管理 数据从哪来、什么意思 元数据采集和血缘 数据质量 数据准不准、全不全 质量规则和监控 从内容覆盖范围来看，DAMA 已经回答了企业数据管理“应该建设哪些能力”的问题。 但对于很多企业而言，更现实的问题是： 这些能力应该如何组织？ 哪些先做？ 哪些后做？ 如何形成建设闭环？ 二、DAMA 与 DCMM：国际理论与中国标准 在国内数据治理领域，除了 DAMA，还有一个经常被提及的标准——DCMM。 DCMM（Data Management Capability Maturity Model）即《数据管理能力成熟度评估模型》，是我国首个数据管理领域国家标准（GB/T 36073-2018）。 注：DCMM 2.0（GB/T 36073-2025）已正式发布，将于 2026 年 7 月 1 日起实施。相较 1.0 版本，能力域从 8 个扩展为 9 个，新增"数据资产"能力域。本文以现行 GB/T 36073-2018 为基础论述，实际引用时建议参考 2.0 版本。 标准指出： “帮助组织运用先进的数据管理理念和方法，建立和评价自身数据管理能力，持续完善数据管理组织、程序和制度，充分发挥数据在促进组织战略达成方面的价值。” DCMM 将数据管理能力划分为八大能力域： 数据战略 数据治理 数据架构 数据标准 数据质量 数据应用 数据安全 数据生命周期 同时建立了五级成熟度评价体系： 一级：初始级 二级：受管理级 三级：稳健级 四级：量化管理级 五级：优化级 从本质上看： 体系 关注重点 DAMA 数据管理知识体系 DCMM 数据管理成熟度评价 数据中台 数据能力平台建设 理采存管用 数据治理实施路径 三者并不冲突，而是关注点不同。 DAMA 解决的是：应该建设什么能力 DCMM 解决的是：能力建设达到什么水平 而数据中台项目需要解决的是：如何把这些能力真正建设出来 三、理采存管用：DAMA 的工程化落地 如果说 DAMA 是"理论教材"，那龙石数据的"理采存管用"就是"落地手册"。 五阶方法论不是对 DAMA 的简化，而是按照工程落地顺序对 DAMA 各领域的重新编排： 可以看到，DAMA 的知识体系被系统性地分配到了五个阶段中。其中"管"阶段承载了最多的治理职能——质量、元数据、主数据、安全，多个领域在这一环节集中落地。 这不是简单的分类对应。关键在于顺序——DAMA 告诉你"要做什么"，理采存管用告诉你"先做什么、后做什么、怎么串起来"。 四、为什么顺序很重要？ 很多中台项目失败，不是因为某个领域没做，而是顺序错了。 典型错误一：在"理"之前就做"采"。 数据资产还没盘点、标准还没定、治理组织还没建，就开始写 ETL 脚本接数据。结果是接进来的数据口径不一致，后面还得返工。上海某化工企业的教训很典型——中台项目启动后直接开始接 MES 和 ERP，三个月后发现物料编码在两边完全对不上，之前的集成工作全部重来。而正确的顺序是先做"理"：统一主数据标准、建立数据质量规则，再进入采集环节。该企业调整路径后，交付及时率从不足 70% 提升到了 91%。 典型错误二：在"管"之前就做"用"。 数据标准没统一、质量没控制、元数据没采集，就开始做报表和 AI 分析。一个常见的后果是：同一个销售额，BI 页面和财务系统差了几百万，业务部门再也不敢用。 典型错误三："管"只做技术检查，不做业务治理。 DAMA 强调数据治理首先是组织治理——要有明确的权责和考核机制。如果质量规则只在技术层面跑，没有人对业务口径负责，那数据问题永远不会从源头解决。 五、AI时代，为什么更需要数据治理？ 随着大模型快速发展，越来越多企业开始建设：AI问数、AI分析助手、AI数据助手、企业知识库。但实践证明：AI效果的上限往往取决于数据质量。 近年来兴起的 Data-Centric AI 理论认为： 与持续优化模型相比，持续提升数据质量和数据治理能力，往往能够获得更大的业务收益。 原因很简单，如果指标定义不统一、主数据不统一、元数据缺失、数据质量不可控，那么AI只会把错误答案生成得更快。 因此，AI时代并没有削弱数据治理的重要性，反而进一步提高了数据治理的战略价值。对于企业而言：数据治理是AI的基础设施。 理采存管用中的"管"，本质上是在为未来的AI应用打基础。而"用"阶段中的智能问数、智能分析，则是治理成果的集中体现。 这一趋势已在政策层面得到印证。2026年，江苏省数据局统筹启动了高质量数据集建设先行先试项目，依据国家"人工智能+"部署及《江苏省发展数据标注产业建设高质量数据集实施方案（2025—2027年）》要求，全省共 147 个项目入选省级试点。龙石数据联合江苏省市场监督管理局数据中心、苏州大学共同申报的"高质量数据集智能底座"项目顺利入选平台搭建类试点——这意味着高质量数据集建设正在从政策驱动走向工程落地，而数据治理能力是这一进程的核心基础设施。 六、怎么落地？一个实操路径 结合 DAMA 框架和理采存管用方法论，建议按以下路径推进： 第一步：用 DAMA 做成熟度评估。 在启动中台建设之前，对照 DAMA 的 11 个领域做一个快速自评：哪些领域已经有基础？哪些是空白？这一步只需要一周，但能避免后面几个月的方向性错误。 第二步：用"理"阶段建治理基础。 根据评估结果，优先建立治理组织和数据标准。DAMA 讲的"数据治理"领域对应到实践，就是在这一阶段完成——明确谁对数据质量负责、统一核心主数据编码、建立变更管理流程。 第三步：采、存、管螺旋推进。 不追求一步到位。选 1-2 个高价值数据域（比如客户域、产品域），走通"采集→建模→治理"的闭环，形成可复用的模板后再扩展。 第四步："用"推动持续迭代。 治理的目的是用。把治理后的数据通过 API 共享、BI 报表或 AI 智能问数等方式推向业务端。业务使用中产生的新需求，反馈回"理"阶段，启动新一轮规划。 七、常见问题 Q1：DAMA 和 DCMM 是什么关系？ DAMA 是国际数据管理协会发布的知识体系（DMBOK），DCMM 是中国国家标准（GB/T 36073-2018）。DCMM 参考了 DAMA 的框架，但增加了成熟度等级评估（1-5 级）。两者的核心思想一致：数据治理首先是组织治理，其次才是技术治理。2026 年 7 月起 DCMM 2.0（GB/T 36073-2025）将正式实施，能力域从 8 个扩展为 9 个，新增"数据资产"能力域。 Q2：中小企业需要关注 DAMA 全部 11 个领域吗？ 不需要。建议重点关注数据治理、数据质量、主数据、元数据这四个基础领域，先把数据"管明白"再扩展。四个领域跑通后，数据仓库和 BI、数据安全的优先级自然上升。 Q3：理采存管用和 DAMA 冲突吗？ 不冲突。DAMA 是知识框架，理采存管用是工程落地方法。可以把理采存管用理解为"DAMA 的施工版"——它保留了 DAMA 的核心思想，但按照工程实践重新编排了顺序和重点。 Q4：治理能力建设需要多长时间？ 取决于起点。如果已经有一定的数据基础（系统建设、团队配置），可以在一个数据域内快速验证： 短期（3 个月）：完成一个数据域的盘点、标准和治理闭环，跑通"理→采→存→管→用"全流程，让业务看到效果 中期（6-12 个月）：将成功模式扩展到 3-5 个核心数据域，建立治理运营常态机制 长期（1-2 年）：形成全企业的数据治理文化，治理活动从"专项项目"变成"日常习惯" 关键在于不要追求一步到位。先跑通一个域，用效果争取更多资源，比一开始就铺开更有可持续性。 参考来源 [1] DAMA International，《What is Data Management?》 [2] DAMA International，《DAMA-DMBOK2 Data Management Body of Knowledge》 [3] GB/T 36073-2018《数据管理能力成熟度评估模型（DCMM）》 [4] GB/T 36073-2025《数据管理能力成熟度评估模型（DCMM 2.0）》，2026 年 7 月 1 日起实施，能力域扩展至九个，新增"数据资产" [5] 国家数据局，《"数据要素×"三年行动计划（2024—2026年）》 [6] Andrew Ng 等，《Data-Centric AI Resource Hub》 [7] 中国电子信息行业联合会，《DCMM标准解读与实施指南》
前几天和一个制造企业的 CDO 聊天，他说了一句话让我愣了半天。 "我们数据中台项目做了三年，预算花了大几百万，团队扩到十几个人。上个月老板问我：效果在哪？我居然答不上来。" 不是他没做事。平台搭了，数据接了，报表出了。但你要问他——业务部门用了吗？决策效率提升了吗？数据资产能说清楚有哪些了吗？——三个问题，三个沉默。 这不是个例。过去几年我们见了太多"建了但没见效"的数据中台。表面上是"项目推进慢""业务不配合"，但根子上的问题比这些深得多，Gartner调研显示，超过三分之一的企业机构依然对数据中台的可行性和适用性感到困惑。 实际上，这个问题在国内外数据治理领域并不是新问题。国际数据管理协会 DAMA 对数据管理的定义是： "Data Management is the development, execution, and supervision of plans, policies, programs, and practices that deliver, control, protect, and enhance the value of data and information assets throughout their lifecycles." 翻译过来就是：数据管理不仅是技术建设，而是围绕数据全生命周期开展的规划、制度、组织、流程与实践活动，其目标是持续提升数据资产价值。 这意味着：数据中台只是载体，数据治理才是核心。 很多企业把顺序做反了，于是出现了下面的典型问题。 一、战略与业务脱节：中台被当成IT项目在推进 最致命的一个问题。 很多企业的数据中台，从一开始就被定义成了一个"技术平台建设项目"。立项是 IT 部门提的，预算走的是信息化预算，考核指标是"平台上线"和"系统对接完成率"。 说白了，没人问过一个关键问题：这个中台到底要帮业务解决什么？ 一个化工客户的中台建了两年，技术架构很漂亮，Hadoop 集群、数据湖、流批一体——什么都有。但一线的生产主任从来没用过。为什么？因为中台接入了 DCS 温度数据、MES 产量数据、LIMS 质检数据，却没人把这些数据翻译成"这一批次的良品率为什么下降了"这种业务价值。 技术团队觉得"数据都在那里，业务自己去看"。业务团队觉得"一堆表我根本看不懂"。双方互相等，等了三年。 根因：中台立项时没有明确的业务场景拉动，建设过程中业务部门始终是"旁观者"而非"参与者"。最终交付的是一个技术平台，而不是一个业务能力。 二、组织权责模糊：治理委员会形同虚设 这个问题比技术问题更难解决。 很多企业也意识到了"光建平台不行"，于是成立了数据治理委员会。主任一般是 CIO 或 VP 挂名，成员是各部门派来的代表。 但实际运转起来是什么样？两个月开一次会，会上各部门汇报一下"数据治理进展"，实际没有任何人有权力推动跨部门的数据标准落地。财务部说"我的科目编码用了十年不能改"，供应链说"我的物料编码跟财务对不上但我也没办法"，IT 部门说"标准定不下来我没法做数据集成"。 根因：治理委员会只有"协调"职能，没有"决策"权力。当数据标准涉及跨部门利益时，没人能拍板。结果就是标准永远定不下来，数据永远对不齐。 事实上，DCMM（数据管理能力成熟度模型）将数据治理组织、制度建设和治理沟通列为核心能力域之一。其核心思想就是： 数据治理首先是组织治理，其次才是技术治理。 很多成功企业都有一个共同特点：数据标准被纳入绩效考核。当数据标准成为经营责任，而不仅仅是 IT 要求时，推进速度往往会发生质变。 三、数据基础薄弱：地基没打好就开始盖楼 很多中台项目把 80% 的精力放在了"建平台"上，却忽略了数据本身。 一个典型的场景：平台上线了，数据也接进来了，但业务部门一查发现——同一个客户在 CRM 里叫"A 有限公司"，在 ERP 里叫"A 股份"，在 WMS 里叫"A 集团"。三套系统的销售数据按客户维度根本没法汇总。业务部门甩下一句"数据都不准"，再也不用中台了。 这就是数据标准的缺失。 再比如数据质量。字段缺失、格式错误、时间偏差——这些问题如果在数据进入中台时不发现，等到 BI 报表出错了才追溯，成本很高。更重要的是，业务部门被坑过一次就不再信任中台的数据了。 还有元数据。很多企业做完数据集成之后，没人知道每个字段是从哪个系统来的、经过了什么加工、由谁负责维护。出了问题排查半天，最后还是回到最原始的方式——挨个系统查。 根因：数据标准、数据质量和元数据管理这三件事，是数据中台能用的前提。平台是楼，数据是地基。地基不打，楼盖得再高也没人敢住。 DAMA-DMBOK 十一个知识领域中，数据质量、元数据管理、数据治理、主数据管理，都属于基础能力建设范畴。 业内有一句非常经典的话： Garbage In, Garbage Out. 垃圾数据进去，只会产生垃圾结果。 数据平台可以建设半年。但企业对数据的信任一旦丢失，可能几年都无法恢复。 四、资产目录缺失：数据有了，却没人知道有什么 接了几十个系统、上百张表之后，出现了一个尴尬的局面——只有当初做集成的几个人知道中台里有哪些数据。 业务人员想查一个数据，要么去翻几个月前的项目文档，要么直接在群里 @ 数据团队。数据团队变成了"人肉数据目录"，每天都在回复"这个字段在哪个表""那个数据从哪里来"。 一个 211 大学的信息中心主任跟我说，他们旧数据平台最大的问题不是技术不行，是"老师和学生根本不知道平台里有什么数据"。想申请一个跨部门的数据，得跑三四个部门盖章，流程走完一两周过去了。 根因：建了中台但没有建"数据资产目录"。数据进来了是进来了，但没有编目、没有检索、没有申请通道。数据资产的发现和获取成本太高，导致"有数据但找不到、找到了但用不上"。 国际上越来越多的数据治理实践认为：数据目录是数据资产化的重要入口。 因为数据资产的价值，不仅在于存储，更在于发现与使用。如果数据找不到、看不懂、申请不到，那么即使平台投入再大，也无法真正形成数据资产。 得益于人工智能的快速发展，找资源现在变得越来越方便。龙石数据的 AI 用数智能体能够帮助快速定位组织内可用的数据资源——当你提出与数据相关的需求时，智能体可以明确告知所需数据存放在哪里、业务口径是什么、使用条件如何，并指导如何进行申请。 五、效果评估缺位：没有度量，就没有持续改进 最后一个问题，也是最容易被忽略的。 数据中台建了三年，如果没人问"效果在哪"，那责任不只在执行团队，也在机制。因为没有定义"什么算见效"。 很多中台项目的验收标准是"平台功能上线""数据接入完成率 95%"。但没有人定义业务侧的指标——数据共享效率提升了多少？跨部门数据申请的时间缩短了多少？业务部门自助取数的比例提高了多少？ 没有度量，就没有反馈。没有反馈，团队就不知道下一步该优化什么。最后中台变成了一个"上线即巅峰"的项目——上线那天是最高光时刻，之后就是漫长的沉寂。 根因：中台建设缺乏分阶段的业务效果评估，导致持续优化的动力不足。最终中台从"战略项目"变成了"运维工作"。 从"建平台"转向"建能力" 经过大量项目实践后，一个越来越明显的趋势正在出现——企业开始意识到：数据治理不是一次性交付项目，而是一种持续运营能力。 这也是为什么越来越多企业开始采用"产品+培训+陪跑"的模式。原因很简单：系统可以买，能力买不来。如果企业内部没有形成数据治理组织、数据治理流程、数据治理人才，那么平台最终仍然会闲置。 在众多数据治理实践中，龙石数据提出了"理采存管用"五阶方法论—— 阶段 核心内容 理（梳理） 规划与盘点。明确战略、建立组织与制度体系，全面梳理业务、信息系统及数据资源，形成数据资源清单。 采（采集） 归集与整合。通过批量或实时方式，将多源异构数据抽取、清洗并加载至目标端，打破数据孤岛。 存（存储） 建模与存储。规划数据仓库分层架构，设计科学的数据模型，将整合后的数据规范、有序地存储。 管（管理） 治理与保障。实施元数据、数据标准、数据质量、主数据、数据安全等核心领域的管控，全面提升数据一致性与可信度。 用（应用） 价值释放。基于治理成果，通过数据查询、可视化分析、API共享、指标标签及AI智能体等方式，将数据能力赋能于业务决策与创新。 该方法论是一个完整的闭环：从规划（理）开始，经过采集（采）、存储（存）和治理（管），最终实现价值应用（用），而应用产生的新需求又会推动新一轮的梳理与优化。 与传统"先建平台再找场景"的模式相比，这种方式更强调业务价值驱动。 同时，在项目实施过程中，龙石数据并不只是提供产品平台，更多采用"产品 + 培训 + 陪跑"的服务模式——通过治理组织建设、标准体系建设、项目辅导、实战培训，帮助企业逐步培养自己的数据治理团队。真正成熟的数据治理体系，不是供应商在治理，而是企业自己具备治理能力。 写在最后 很多企业认为：数据中台没见效，是因为技术不够先进。 但过去几年行业实践反复证明，真正决定成败的往往不是技术，而是—— 有没有业务牵引 有没有治理组织 有没有数据标准 有没有资产管理 有没有效果度量 平台解决的是"能不能做"。治理解决的是"为什么做、谁来做、怎么持续做"。 数据中台建设三年仍不见效，问题可能不在中台本身——而在于企业还没有真正完成从"项目思维"向"治理思维"的转变。 FAQ Q1：数据中台和数据治理到底是什么关系？ 数据中台是技术载体，数据治理是管理体系。 没有治理的数据中台容易沦为数据仓库；没有中台的数据治理又缺少落地抓手。二者应该同步规划、同步建设。 Q2：企业应该先建设数据中台还是先做数据治理？ 建议先开展数据资产盘点和治理规划。至少明确数据现状、数据标准、主数据体系和治理组织，然后再规划平台建设。否则很容易反复返工。 Q3：中小企业需要做数据治理吗？ 需要。数据治理并不等于大投入。很多企业早期通过指标标准统一、数据目录建设、数据质量检查就能获得明显收益。关键在于循序渐进。 Q4：数据治理多久能见到效果？ 通常建议选择 1-2 个高价值场景先落地，例如经营分析、客户分析、项目管理、供应链分析。一般 3-6 个月即可看到阶段性成果。 Q5：数据治理项目为什么容易失败？ 最常见原因有五个：业务缺席、组织缺位、标准缺失、数据质量差、没有持续运营机制。技术问题通常不是第一原因。 Q6：企业如何培养自己的数据治理能力？ 实践证明，单纯购买平台很难解决问题。更有效的方式是方法论指导、产品工具支撑、专项培训、项目陪跑同步推进。最终形成企业自己的数据治理组织、制度和人才体系，实现从"供应商驱动"向"企业自主运营"的转变。 参考来源 1. DAMA International. What is Data Management? https://dama.org/about-dama/what-is-data-management/ 2.中国国际科学交流中心. DCMM 数据管理能力成熟度模型. https://www.china-isc.org.cn/pinggu/show-317.aspx 3.DAMA International. DAMA-DMBOK 数据管理知识体系指南. arXiv. Data Catalog: The Gateway to Data Assetization. https://arxiv.org/abs/2402.05211
龙石数据质量管理平台社区版现已正式开放，快来体验吧。
龙石数据质量管理平台·社区（免费）版将于明日正式上线。欢迎关注产品动态，体验企业级数据质量管理能力。
AI 时代最贵的成本，不是模型采购费用。而是在错误数据基础上的反复试错。 做 AI 之前，先看一眼你的数据。花一两周做一次数据质量体检，可能会省下半年甚至一年的试错。这可能是整个 AI 项目中投入最小、回报最高的一步。
随着重点领域行业高质量数据集的逐步建成，以及“场景—数据—模型—应用”双向循环反馈机制的形成，我国有望建立起一条完备的数据安全供给链。通过全面落实《实施方案》中的各项技术与治理举措，人工智能治理得以在数据输入端筑起坚实的合规屏障，实现技术快速演进与治理体系协同共生的新局面。
AI+数仓不是噱头，它能落地，但需要选对场景、管好预期、打好基本功。别指望AI一步到位解决所有问题，也别因为AI有缺陷就否定它的价值。用对了地方，它就是提升效率的好工具。
龙石数据联合江苏省市场监督管理局数据中心、苏州大学共同申报的“高质量数据集智能底座”项目，顺利入选。
最近跟几个做数据治理的朋友聊天，大家的焦虑感出奇地一致：大模型在元数据标注、数据质量检测、血缘分析这些场景上越做越好，很多以前需要人工干的活，AI能自动干了。那数据团队以后还能干什么？ 这个问题问得好，也问得及时。2026年以来，AI+数据治理已经成为行业共识——IT之家、天极网等多家技术媒体近期发布的分析报告都指出，数据治理平台正在从"被动规则引擎"转向"主动智能协同中枢"。三维天地、数语科技等厂商也相继推出了AI驱动的治理产品。 但我想先把一个关键认知摆在这里：AI接管的不是数据团队的工作，而是数据团队工作中那些重复性高、标准化程度高的部分。剩下的部分——策略制定、复杂判断、跨部门协同、业务价值评估——恰恰是数据团队真正应该投入精力的地方。 一、AI在数据治理中到底能干什么？ 在讨论"数据团队该干什么"之前，先明确"AI能干什么"。目前来看，AI在数据治理中的价值主要集中在四个场景。 场景一，元数据智能管理。传统模式下，元数据的采集、标注、分类分级几乎全靠人工——逐张表、逐个字段地写注释、定义业务含义。大模型在自然语言理解上的能力，可以自动识别字段的业务语义、推断数据分类、推荐数据分级建议。人需要做的是审核和确认，而不是从零开始标注。 场景二，数据质量智能检测。传统数据质量治理依赖人工定义检核规则——空值检查、格式校验、一致性比对等。AI可以从历史数据中自动发现异常模式，推荐质量检核规则，甚至预测潜在的数据质量问题。比如AI发现某个字段的值分布突然发生偏移，可能是上游系统变更导致的，它会主动预警，而不是等问题被业务方投诉了才发现。 场景三，数据血缘自动追踪。传统血缘分析依赖人工维护或工具半自动采集，覆盖范围有限且容易断裂。AI可以通过分析SQL逻辑、ETL脚本、API调用链路，自动生成端到端的数据血缘图谱，并在数据变更时自动评估影响范围。 场景四，合规风险智能识别。随着《数据安全法》《个人信息保护法》的实施，数据合规成为治理重点。AI可以自动识别敏感数据字段（如身份证号、手机号等），匹配合规策略，并生成合规风险报告，帮助团队提前发现潜在的合规风险。 下面这张图展示了AI与人在数据治理中的协作关系。 从图1可以看出，AI和人各有分工、相互配合。AI负责执行和辅助，人负责决策和审核。这个关系定义清楚了，后面的事情就好 二、AI治理的能力边界在哪？ 谈AI赋能，不能只说好处不说局限。AI在数据治理中能做到什么程度，我画了一张成熟度模型来界定。 如图所示，我把它分成了四个层级。需要客观说明的是： L1（人工规则驱动）是目前不少企业所处的阶段。治理工作高度依赖人工，效率低但可控。这个阶段不丢人，关键是要有向L2升级的意识。 L2（AI辅助治理）是当前可行的目标。AI负责生成初稿（规则、标注、报告），人负责审核确认。这个阶段投入产出比相对较高，也是目前头部厂商产品主推的方向。 L3（AI深度参与）需要较强的数据基础。要让AI主动检测异常、推荐治理策略，前提是元数据完善、数据质量基线清晰、治理流程标准化。如果这些基础没打好，AI的能力也无法充分发挥。 L4（自治治理）目前更多是愿景。完全由AI自主处理治理任务、人只在关键节点把关——这个目标在技术上还有不少挑战需要克服，短期内不建议作为企业的主要目标。 务实建议：大多数企业应该把目标定在L2到L3之间——让AI承担执行层面的重复工作，让人聚焦于策略和判断。不要被厂商的营销话术带着跑，以为买了个AI治理平台就能直接跳到L4。 三、数据团队的角色怎么变？ AI接管的越多，数据团队就越需要重新定义自己的价值。我用一张图来说明这个转变。 如图所示，数据团队的角色正在从"治理执行者"转向"数据资产运营者"。具体来说，有四个变化。 3.1 从 写规则 到 审规则 以前数据团队的大量精力花在编写和维护数据质量规则上——一张表几十个字段，每个字段可能需要好几条检核规则，几百张表下来就是海量的规则维护工作。AI介入后，这部分工作可以大幅缩减。AI根据数据特征和历史模式推荐规则，数据团队的重点变成审核这些规则是否合理、是否覆盖了业务关注的质量维度。 3.2 从 做治理 到 建体系 AI能帮你发现数据质量问题，但"发现之后怎么办"需要人来设计：这个质量问题由谁负责？修复优先级怎么排？跨部门的数据口径冲突怎么协调？这些是治理体系建设的问题，AI替代不了。数据团队需要把更多精力放在治理组织架构、流程机制、考核标准的建设上。 3.3 从 对内支撑 到 对业务赋能 传统数据治理大多是"对内"的——给技术团队用、给数据团队用，业务方的感知很弱。AI介入后，数据团队可以从重复性工作中释放出精力，去思考一个更关键的问题：治理的成果怎么转化为业务价值？比如，数据质量提升之后，报表的准确率提高了多少？决策效率改善了多少？这些量化评估能让业务方看到治理的实际价值，从而更愿意配合治理工作。 3.4 从 被动响应 到 主动运营 以前数据治理的模式是"出了问题再处理"——业务投诉数据不准，再去排查修复。AI的主动检测能力让"事前预防"成为可能。数据团队可以基于AI的预警信息，提前介入处理潜在的数据风险，把治理从被动响应转变为主动预防与持续优化。 四、落地过程中容易踩的坑 基于行业观察和实践经验，总结几个常见的坑。 坑一，跳过基础建设直接上AI。有些团队元数据管理还没做起来、数据标准还没建立、质量基线都没量，就急着引入AI治理工具。结果AI生成的建议质量很差——因为连AI都不知道哪些字段是什么含义。数据基础是AI治理的前提，这个顺序不能颠倒。 坑二，把AI治理当成纯技术项目。数据治理本质上是一个管理问题。AI能提升治理的执行效率，但"数据标准由谁制定""质量不达标的责任怎么界定""跨部门数据冲突由谁协调"这些管理层面的问题，AI解决不了。必须有配套的治理组织、流程和机制。 坑三，期望AI完全自动化。目前阶段，AI在数据治理中更适合"辅助"定位。让AI自动执行所有治理任务、完全不需要人工介入——这个目标在当前技术条件下不现实。尤其在涉及敏感数据分级、合规判断等场景，人工审核环节不能省。 坑四，忽视AI自身的治理风险。网易的一篇文章提到，当AI Agent从"能对话"演进到"能执行"时，其引发的数据治理与安全风险较传统AI显著提升。比如AI在执行数据治理任务时可能误操作敏感数据，或者AI生成的治理规则本身存在偏见。因此，对AI的治理行为本身也需要建立监控和约束机制。 五、几个关键的优化建议 最后，给几个实操层面的优化建议。 建议一，分场景逐步引入AI，不要贪多。建议从元数据管理和数据质量检测这两个场景切入——这两个场景标准化程度高、效果容易衡量、投入产出比相对明确。验证成功后再逐步扩展到血缘分析、合规识别等场景。 建议二，建立"AI生成+人工审核"的标准流程。无论哪个场景，都应该设计明确的人机协作流程：AI生成治理建议→人工审核确认→执行→记录反馈→优化AI模型。这个闭环是AI治理效果持续提升的关键。 建议三，量化治理效果，让价值可见。AI介入前后，数据质量问题的发现效率提升了多少？元数据标注的人工投入降低了多少？数据治理报告的出具周期缩短了多少？这些量化指标不仅能评估AI治理的实际效果，也能帮助数据团队向管理层和业务方展示治理工作的价值。 建议四，关注AI治理平台的安全与合规。引入AI治理工具时，要确认其对敏感数据的处理方式——数据是否会上传到云端？是否支持私有化部署？对AI的治理行为是否有审计日志？《数据安全法》和《个人信息保护法》对数据处理有明确要求，AI治理工具也必须满足这些合规要求。 六、写在最后 回到开头的问题：当AI介入数据治理，数据团队该干什么？ 答案其实很清楚：AI接管的是"执行"，数据团队应该聚焦于"策略、协同和价值"。制定治理策略、审核AI的建议、推动跨部门协同、量化治理的业务价值——这些才是数据团队在新阶段的核心工作。 换个角度看，AI不是在抢数据团队的饭碗，而是在帮数据团队从繁琐的执行工作中解放出来，去做更有价值的事。关键在于你能不能抓住这个转变的窗口期，主动调整自己的定位和能力结构。 来源（公众号）：华哥聊数据
一、为什么突然都在聊AI+数仓？ 过去两年，大模型的风刮到了数据基础设施领域。从Text-to-SQL到AI辅助建模，从自动化ETL到智能数据治理，各大厂商和开源社区陆续推出一系列工具，试图用大模型改造传统数仓的工作方式。 这个方向的内在逻辑不难理解。传统数仓建设有几大痛点：建模周期长、数据清洗依赖人工规则、ETL链路出问题需要运维半夜爬起来定位。每个环节都存在大量重复性劳动，而这些恰好是大模型擅长的事情——理解自然语言、生成代码、识别模式规律。 但一个有意思的现象是：同样一套技术方案，有的公司用得比较顺畅，建模效率明显提升，数据质量问题大幅减少；有的公司投入了不少资源，折腾了大半年，最后得出的结论是"大模型没啥用"。相似的底层技术，结果差别很大。 这背后的原因在哪？结合我这几年的一线观察，我总结了四个层面的关键分水岭。 二、跑得通的公司，做对了什么？ 1. 先把数据底子打扫干净 这是最基础、也最容易被忽视的一点。跑得通的公司，在引入AI之前，已经完成了数据标准化的基础工作——字段命名规范统一、数据字典完整、指标口径明确、元数据管理到位。大模型进来之后，有标准的元数据做上下文，不需要去"猜"某个字段的业务含义。 反过来，跑不通的公司往往是"数据裸奔"状态。同一个客户ID，CRM系统里叫customer_id，订单系统里叫user_no，日志系统里叫uid。大模型面对这种混乱的局面，别说生成准确的SQL，连理解都费劲。很多项目一上来就希望大模型"端到端"解决问题，结果数据质量不过关，大模型输出的东西也是错的，团队信心一下就被打没了。 一个判断标准：如果你现有的数仓连基本的指标口径都没有对齐，先别急着上AI。把标准定了，把字典建了，再谈大模型赋能。 2. 选对了切入点，从小场景开始跑 从我了解到的情况来看，跑得通的公司通常遵循"小切口、速赢"的策略。很多不会一上来就搞一个"企业级AI平台"，而是先挑一个高频、痛点明确、价值可量化的场景。 比如： Text-to-SQL查询：让业务人员用自然语言查数，减少数据开发写SQL的重复需求 数据质量自动稽核：用大模型识别异常数据，补充人工校验规则的不足 元数据自动补充：根据表结构和业务上下文，自动生成字段描述和业务定义 这些场景的共同点是：边界清晰、见效快、业务方感知强。一旦跑通一个场景，团队信心建立，后续推进其他场景就容易得多。而一上来就想"用AI重构整个数仓体系"的公司，项目周期拖得太长，业务方耐心耗光，往往无疾而终。 3. 懂得"什么该交给AI，什么不该" 这是很多技术团队容易忽略的问题。大模型不是万能的，也不是所有任务都适合交给它。从我观察到的做法来看，跑得通的公司普遍建立了一套分层分工机制： 任务类型 处理方式 典型场景 简单、规则明确的 传统脚本/SQL 基础数据校验 固定报表查询 复杂、需要语义理解的 大模型处理 模糊查询转SQL、异常归因分析 高频且对延迟敏感的 轻量级模型或规则引擎 实时数据质量拦截 低频且对准确度要求高的 大模型+人工审核 复杂建模、数据口径映射 核心原则是：大模型只做"需要理解能力"的事情，不碰"可以用规则解决"的事情。这样做既能控制调用成本，又能保证效率和准确率的平衡。 三、跑不通的公司，踩了哪些坑？ 坑一，数据没清干净就上AI 最典型的场景是：企业把全量业务数据直接丢给大模型，期望它自动完成清洗和治理。结果大模型面对各种不一致的字段、缺失的关联关系、混乱的编码体系，输出的数据质量大打折扣。 举个常见的例子：供应商名称这个字段，在不同业务系统里可能写成完全不同的格式——全称、简称、中英文混写、带标点不带标点。如果不在入库前做标准化映射，大模型花再多精力去"理解"这些变体，效果也不如先把数据洗干净再喂给模型。这背后是一个基本的顺序问题：AI不能替代数据治理，但它能加速已经标准化的数据治理流程。顺序反了，结果就是事倍功半。 坑二，一上来就搞"全场景覆盖" 这个问题在传统IT项目中就常见，到了AI时代被放大了。从我的经验来看，AI项目的不确定性比传统项目更高，因为你无法预判大模型在某个具体场景下的表现。场景越多，不确定性叠加，项目失败的几率也随之上升。 常见的情况是：公司成立AI+数据专项组，目标同时覆盖销售、运营、供应链、客服多个场景，预算和周期定得很高。结果几个月过去了，连第一个场景还没跑通——每个场景都需要不同的数据准备、不同的Prompt调优、不同的评估标准。资源有限却全面铺开，很容易每个场景都做不透。 一个务实的建议：如果团队还在探索阶段，先集中资源打穿一个场景，验证了价值再横向复制。 坑三，技术部门单干，业务部门不参与 大模型需要"学"业务知识。如果业务部门不参与需求定义、不提供高质量的业务语料、不参与结果评估，大模型生成的SQL和模型很可能跟实际业务需求对不上。 举个例子，"计算客户流失率"这个需求，不同部门的理解可能完全不同。销售部门认为"三个月未下单"就算流失，运营部门认为"六个月未登录"才算，财务部门可能按"账户余额为零"来定义。口径差异，大模型自己是"悟"不出来的。 坑四，忽视成本与效率的平衡 大模型的API调用成本因模型和厂商而异，按token计费的模式下，高频调用会产生一定的开销。如果所有数据操作都走大模型，月结时的费用可能会比较可观。 比如，日常的GMV查询、转化率报表这类高频查询，用大模型走一遍自然语言转SQL，延迟可能比直接跑一条预计算的SQL慢不少，调用成本也更高。把任务分层——高频、确定性高的走规则引擎或预计算，低频、模糊的走大模型——可能是更合理的做法。 四、优化方向，怎么从"跑不通"变成"跑得通"？ 方向一，从高频痛点场景切入，快速验证 如果你的公司还在探索阶段，可以考虑从这些场景入手： 数据质量稽核：大模型识别异常数据的能力在一些场景下已经具备实用价值，落地门槛相对较低 元数据自动补全：基于表结构和字段名生成业务含义描述，能较快提升数据字典的覆盖率 自然语言查询（Text-to-SQL）：适用于报表需求频繁、数据开发资源紧张的团队 ETL脚本辅助生成：适合数据量大、重复性ETL任务多的场景 每个场景建议先做小范围POC验证，确认价值后再投入资源做生产化。 方向二，建立闭环验证机制 大模型输出结果建议配合人工确认机制： 项目初期：人工复核比例适当提高，重点关注大模型输出是否符合预期 稳定期：复核比例逐步降低，同时建立自动化监控基线 成熟期：通过bad case反向驱动模型和Prompt的持续优化 每次发现大模型输出有误，记录下来分析原因——是Prompt写得不够精准？是数据本身有问题？还是场景超出了模型的能力边界？这些积累会成为后续优化的重要基础。 方向三，数据安全底线不能破 数仓里存储着大量业务数据和用户信息，直接送到公有云大模型接口存在合规风险。在实际落地中，建议做到： 敏感字段（手机号、身份证、邮箱等）在输入大模型前进行脱敏处理 所有API调用留存审计日志 明确数据使用边界，不超出业务需要的范围 有条件的企业可优先考虑私有化部署方案 五、未来展望，AI+数仓会走向哪里？ 从过去两年的行业实践来看，AI+数仓的发展有几个方向已经逐渐清晰： 第一，AI辅助能力会逐步融入数仓工具链。就像OLAP引擎成为数仓标配一样，AI辅助建模、智能数据质量稽核、自动化运维诊断等能力，在未来几年可能会成为数据平台的基础功能。企业需要思考的不是"要不要用"，而是"用在哪些环节最合适"。 第二，不同规模的模型会协同工作。大模型擅长复杂推理和语义理解，在需要"理解"的场景下优势明显。而小模型或规则引擎在处理高频、确定性任务时，在成本和响应速度上更具优势。两者配合使用，可能是更务实的方案。 第三，数据治理的重要性不会降低，反而会提升。AI越强，对数据质量的要求越高。一条不准确的数据口径，经过大模型处理后，可能产出一份看起来逻辑严谨但结论错误的报告。数据治理不是可以被AI替代的工作，而是需要和AI同步加强的基础工程。 第四，人机协同是现阶段较为可行的模式。短期内"AI替代数仓工程师"不太现实。更务实的路径是：AI处理重复性、规则清晰的常规任务，人工负责复杂决策、异常处理和效果兜底。从我接触到的案例来看，这个分工模式在成本、效率和质量三个维度上综合表现不错。 最后说句实在话：AI+数仓这件事没有捷径。先把数据管好，选对场景，边界划清楚，再让AI进来干活。按这个顺序走，大概率能跑通。反过来，跳过前两步直接上AI，十有八九要交学费。 来源（公众号）：华哥聊数据
