"模型选好了，算力也到位了，但卡在数据上。"这是近两年AI项目中最常听到的一句话。 本文所称"AI数据集"，主要指企业将结构化业务数据经过治理后，形成可供模型训练、分析推理、智能问数等场景使用的数据集合。不同AI场景对数据的要求各有侧重——产品质量预测依赖传感器和工艺参数的完整性与准确性，智能问数更依赖元数据的语义映射和指标口径的统一——但底层的数据治理逻辑是共通的。 某制造企业的AI团队计划用AI模型做产品质量预测，思路很清晰：把ERP里的生产记录、MES里的工艺参数、LIMS里的检测数据喂给模型。但实际操作中，他们遇到了意想不到的困难——同一个物料在三个系统里用三种编码命名，部分历史检测记录缺少关键字段，跨系统的指标口径各说各话。数据确实"有"，但不在一个能用、可信的状态。 这不是孤例。越来越多的企业发现，从"业务系统里存着数据"到"AI能直接用这些数据"，中间隔着的不是技术问题，而是一整套治理功课。其核心不是简单"把数据喂给模型"，而是建立一套能够持续生产、更新和评价AI数据集的治理机制。本文逐一拆解这中间的十个关键环节。 一、为什么业务数据不能直接"喂"给AI 业务系统中的数据是为业务流程服务的——订单系统的数据负责记录交易，MES的数据负责跟踪生产执行，CRM的数据负责管理客户关系。这些数据在设计之初就没有考虑过"被AI模型消费"这个使用场景。 具体来说，业务数据在三个维度上天然不适合直接用作AI数据集。 口径不一致。同一个业务指标，不同系统可能有不同的理解和计算方式。例如"准时交付率"，有的系统按订单创建时间算，有的按发货确认时间算，数字自然对不上。华东某电子制造企业在数据治理过程中就遇到了这个问题：财务部算出来的产值和运营部算出来的产值对不上，月度经营会上管理层要先花时间确认"到底以哪个数字为准"。AI模型如果学到的是这种口径矛盾的数据，输出的结论也必然自相矛盾。 质量参差。业务系统中普遍存在数据缺失、格式错误、异常值超标等问题。这些问题在日常业务流程中可能被人工校验绕过，但AI模型会规模化使用数据——原本可以通过人工经验绕过的数据问题，可能在模型训练和推理过程中被持续放大。 语义缺失。数据库中的字段名是技术命名——"F_ORDER_AMT""T_PROD_CD"这类标识对开发人员不是问题，但对AI模型而言，它不知道这些字段在业务世界里的实际含义。没有元数据的"翻译层"，AI难以准确建立业务术语与表、字段、指标之间的映射关系。 综合来看，业务数据的三个短板恰好对应了AI数据集的核心要求：口径一致对应"可信"，质量达标对应"可靠"，语义完整对应"可理解"。补齐这三个短板的过程，就是治理全链路的核心任务。 二、治理全链路：十个环节逐一拆解 从业务数据到AI数据集，依次经过十个治理环节。这些环节可以参考龙石数据"理—采—存—管—用"的整体路径进行组织，但各环节之间并非严格割裂，在实际项目中往往交叉推进。以下按大致阶段展开。 理：摸清家底 1. 数据盘点 做什么：系统性地梳理企业有哪些数据、存在哪些系统里、归属哪个业务域、数据量级和更新频率如何。 为什么重要：如果连"数据在哪"都说不清楚，后续的归集、质量和安全工作就是无源之水。盘点是治理全链路的起点。 怎么做：从AI应用瞄准的核心业务域出发，逐系统盘点数据表、字段和关键业务对象。不要把范围铺得太广——先盯住AI会用到的那几套核心系统和核心表即可。产出物是一份数据资产清单，标明每个数据资源的来源系统、业务归属和基本状态。 2. 来源筛选 做什么：围绕明确的AI应用场景，判断哪些数据值得纳入AI数据集，哪些数据与场景无关或质量过低不值得投入。 为什么重要：不是所有数据都值得喂给AI。低质量、低相关性的数据只会增加噪音和治理成本。筛选的标准是"这个数据集对AI应用场景有没有直接价值"。 怎么做：基于第一步的盘点结果，AI团队和业务团队共同确认数据需求范围。质量过差、更新频率过低、与场景无关的数据暂不纳入，先聚焦核心数据源。 采：汇聚数据 3. 多源归集 做什么：将分散在不同业务系统中的数据统一汇聚到治理平台或数据底座中。 为什么重要：数据不汇聚，后续的清洗、标准和质量工作就无法集中执行。归集是打通数据孤岛的第一刀。 怎么做：根据数据类型和时效要求选择归集策略——结构化数据采用批量归集，龙石数据中台对单表精细化的场景可通过拖拽式画布设计数据流转，对需要一次同步多张表的场景可采用向导式批量勾选；需要秒级响应的场景采用实时归集（基于数据库日志的变更数据捕获）。归集过程需要处理数据库异构适配、字符集转换、字段映射等常见工程问题。 存：数据存储 4. 清洗转换 做什么：对归集后的存量数据进行格式统一、异常值处理、空值标记和数据类型转换。 为什么重要：原始数据中的脏数据如果不清理，后续的质量检测和AI训练都会受到影响。清洗是"让数据进入可用状态"的必要工序。 怎么做：格式化处理（日期格式统一、数值精度对齐）、异常识别（超出业务合理范围的值标记或剔除）、缺失值处理（按业务规则填补或标记为空）。清洗规则应当在治理平台中配置为可复用的模板，而非每次手工处理。 管：治理保障 5. 标准统一 做什么：统一数据的编码规范、命名规则、业务术语定义和指标计算口径。 为什么重要：这是AI数据集可信度的关键底座。如果同一个指标在不同系统中代表不同的含义，AI模型学到的是矛盾的信息——输出结果可能在语言上流畅，但在业务逻辑上自相矛盾。 怎么做：从核心主数据对象（如物料、客户、供应商、科目、项目等）入手，制定统一的编码规则和命名规范。然后扩展到关键业务指标的计算口径统一——明确每个指标的取数来源、计算逻辑和更新频率。标准制定后需要沉淀到治理平台中，作为数据接入和使用的强制校验基准。 华东某电子制造企业在治理过程中，从核心业务对象入手，逐一盘点各系统中的存量数据，统一编码规则和校验规范，产出了覆盖全集团的数据标准体系。这个过程的经验是：如果基础编码都没统一，再先进的AI模型也难以产出可信的结果。 6. 质量检测 做什么：依据国家标准定义的质量维度，对数据进行系统性的自动化质量扫描。 为什么重要：质量检测把"数据能不能用"从主观判断变成可量化的客观评价。只有经过质量验证的数据集，AI模型的输出才有可信度。 怎么做：以GB/T 36344-2018《信息技术 数据质量评价指标》[1]为框架。该标准定义了六个评价维度——规范性、完整性、准确性、一致性、时效性和可访问性。除可访问性侧重技术条件外，前五个维度直接影响AI应用效果：规范性决定数据是否按统一格式被模型稳定解析，完整性和准确性决定模型推理的信息基础是否可靠，一致性和时效性决定跨系统关联分析的结论是否可信。 在实操层面，质量检测通常采用旁路监测模式——数据正常入库，质量规则并行扫描，发现问题打标记、告警或生成工单，不阻断业务流程。这种方式在保证质量可见性的同时，不影响业务系统的正常运行。对于希望先开展质量摸底的企业，也可以通过支持 GB/T 36344 评价框架的数据质量工具，对核心数据源进行基线检测，在不影响原有业务流程的情况下识别主要质量问题。 7. 语义补充 做什么：为技术字段补充业务含义说明，让AI能够"读懂"数据。 为什么重要：数据库字段名是给开发人员看的，AI模型需要的是一层业务语义的"翻译"。一个字段叫"F_STAT_CD"，AI不知道它代表"订单状态"还是"客户级别"——除非元数据告诉它。语义补充的本质，是把数据库从"技术字典"升级为"业务字典"。 怎么做：通过元数据管理，为每个字段补充中文名称、业务定义、取值规则、关联关系等信息。这一步在技术上不复杂，但考验的是业务语义的统一能力——同一个业务概念在不同部门之间可能存在隐性差异，需要逐一拉通。在实际项目中，核心数据资产的业务口径梳理往往是投入时间较多的环节，但这一步一旦完成，AI就可以基于一致的语义进行查询和分析。 8. 安全处理 做什么：对AI数据集中可能涉及的敏感信息进行分类分级和脱敏处理。 为什么重要：AI数据集一旦形成，通常会被多个团队使用和分发。如果原始数据中包含个人信息、商业秘密或其他敏感内容，未经脱敏就进入训练流程，不仅存在合规风险，而且一旦泄露几乎无法追溯。安全处理是AI数据集在"可用"和"合规"之间的平衡点。 怎么做：结合 DCMM 2.0（GB/T 36073-2025）[2]的数据安全能力要求，以及现行数据安全和分类分级相关规范，对数据实施分类分级——区分一般数据、重要数据和敏感数据。对敏感字段实施脱敏处理（支持静态脱敏和动态脱敏两种模式），配置按角色、按数据级别的访问控制策略。安全策略还需要支持场景化配置——同一个数据集在内部AI训练、跨部门共享、对外合作三种场景下，脱敏策略和访问权限应当有所不同。 用：应用与交付 9. 版本管理 做什么：对AI数据集的每一次变更进行版本记录，确保训练过程可追溯、可回滚。 为什么重要：AI模型的迭代本质上是在数据上迭代。如果数据集的版本没有记录，当模型效果出现波动时，排查方向就少了一个关键变量——不知道是模型参数的问题还是训练数据变了。版本管理解决的是"这个模型到底是哪批数据训出来的"这个朴素但关键的问题。 怎么做：对数据集建立版本号机制，每次数据更新（新增数据源、调整清洗规则、补充语义标注等）生成新的版本快照。版本信息应至少包含变更时间、变更内容、变更人和变更原因。在治理平台中，版本管理通常与数据资产目录联动——同一份数据集的历史版本在目录中保持可查询、可对比。 10. 服务发布 做什么：将治理完成的AI数据集以标准化形式交付给AI团队或应用系统。 为什么重要：治理的终点不是一份质量报告，而是数据真正被用起来。服务发布是治理全链路从"内部工程"转向"对外交付"的最后一环。 怎么做：根据使用场景选择合适的交付方式——批量训练场景以数据集文件或数据表形式输出，实时推理场景通过API接口提供数据服务（龙石数据中台已支持一键发布API并配置访问控制），探索分析场景通过数据资产门户让AI团队自助检索和使用。交付时需要附带元数据说明文档（数据字典、字段含义、质量评估结果、更新频率），让使用方在做AI训练之前就知道数据的特点和边界。 三、持续治理机制：AI数据集不是一次性交付 走完十个环节，并不意味着治理工作结束。AI模型会迭代，业务数据会更新，数据集的治理需要从"一次性工程"转向"持续运转的机制"。 质量基线的持续监控。以十个环节走完时的质量状态为基准线，配置自动化监控规则，当质量指标偏离基线时自动告警。这相当于把质量从"一次性体检"变成"持续监测"。 数据集的版本追踪。每次数据集发布新版本时，同步记录变更内容和变更原因，确保任何一次模型训练都能对应到确定的数据集版本。这对AI项目中的问题排查和同行评审尤为重要。 反馈闭环。建立从AI应用效果回传到数据集优化的反馈链路——模型在特定场景下的准确率下降、某些特征在实际推理中表现不稳定——这些信号反向驱动数据集的改进策略。闭环一旦建立，数据质量就从"靠人盯"变成了"靠机制走"。 四、以"理采存管用"为框架看AI数据集治理 "理采存管用"五阶段方法论为这十个环节提供了一个结构视角。在"理"阶段搞清楚数据家底，在"采"阶段打通系统间的数据流转，在"存"阶段建立标准化基础，在"管"阶段落实质量和安全要求，在"用"阶段以产品化方式交付——各阶段层层递进，构成了从业务数据到AI数据集的完整价值链。 从DAMA数据管理知识体系（DAMA-DMBOK2）[3]的视角来看，这十个环节覆盖了数据质量管理、元数据管理、主数据管理、数据安全管理和数据集成与互操作等多个核心知识领域。AI数据集的治理不是凭空创造一套新规则，而是将成熟的数据管理实践聚焦到AI这一特定消费场景上。 从多数项目的实践经验来看，在核心数据域完成基础治理后再启动AI应用，比"边用边治"更可控。正如前述电子制造企业的实践所示——如果底层编码都没统一，上层分析就缺乏可靠基础。数据治理的深度，直接决定了AI数据集的最终可信度。 FAQ *Q1：十个环节听起来很多，小团队怎么入手？* 不需要一开始就追求全量覆盖。选取AI应用瞄准的一到两个核心业务域，从数据盘点和质量基线做起，先跑通一条完整链路。企业可以优先从质量基线检测和核心数据语义补充入手，这两项工作通常更容易形成阶段性成果。如果希望先低门槛地摸清数据质量现状，也可以通过免费的质量检测工具做一次基线扫描——例如龙石数据质量管理平台·社区版，部署后即可对核心数据源进行 GB/T 36344 标准框架下的自动化质量检测。 *Q2：已经有数据中台了，还需要专门的AI数据集治理吗？* 两者并非相互替代。数据中台为数据归集、治理和服务提供基础能力，AI数据集治理则进一步面向具体AI场景，对语义、质量、版本和使用反馈提出针对性要求。简单来说：中台把路修好了，但AI需要的路标、信号灯和定期养护需要专门设计。 *Q3：语义补充和元数据管理是一回事吗？* 元数据管理是基础设施——采集技术元数据和业务元数据。语义补充是在元数据基础上的"AI定向增强"——重点是为AI模型提供结构化、可查询的业务语义字典，确保模型能够正确地将业务术语映射到具体的表和字段上。两者的关系是：元数据管理搭框架，语义补充做精装。 *Q4：数据安全和模型安全是什么关系？* 数据安全关注"数据本身的敏感信息保护"——分类分级、脱敏处理、访问控制。模型安全关注"模型输入输出层面的攻击防护"——提示词注入、越狱攻击等。两者是上下游关系：数据安全做不好，敏感信息进入训练数据，模型安全就成了无源之水。结合 DCMM 2.0[2]的数据安全能力要求及现行安全规范，数据脱敏和访问控制是两者之间的衔接点。 参考来源 [1] GB/T 36344-2018《信息技术 数据质量评价指标》，国家市场监督管理总局、中国国家标准化管理委员会 [2] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），全国信息技术标准化技术委员会 [3] DAMA International，《DAMA数据管理知识体系指南（DAMA-DMBOK2）》，机械工业出版社 [4] 龙石数据，AI用数智能体，https://www.longshidata.com/products/aianalysis.html
8月12日（周三）晚8点，龙石数据创始人兼总经理练海荣应国际数据管理协会（DAMA）大中华区主席汪广盛邀请，围绕“AI赋能数据治理，重构数据价值新生态”主题，分享AI与数据治理融合发展的实践探索，拆解企业级AI数据中台的建设思路与落地路径。
三份重量级政策文件在两年内相继出台，从制度、财务、流通三个维度，一步步将数据中台的角色从"数据管道"推向了"资产管理基础设施"。 2022年12月，"数据二十条"（《关于构建数据基础制度更好发挥数据要素作用的意见》）率先发布，以数据资源持有权、加工使用权、产品经营权"三权分置"的框架，第一次在法律层面为数据被界定为"资产"扫清了制度障碍。2023年8月，财政部《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号）紧随其后，于2024年1月正式施行——数据入表进入实操轨道，数据治理不再是IT部门的内部事务，而是直接关联企业资产规模和财务表现的CFO议题。2024年1月，国家数据局发布"数据要素×"三年行动计划（2024—2026年），政策重心从"确权入表"进一步延伸到"合规流通"——数据不仅要管好入好，还要能在合规前提下对外共享和交易。 三份文件的发布时间线，清晰地勾勒出了政策演进的方向：先确权→再入表→后流通。而每一步对数据中台的要求都在升级——确权需要中台提供资产视图，入表需要中台提供质量依据，流通需要中台构建安全可控的数据服务能力。对于已经在数据中台上投入了大量资源的企业而言，这三份文件既意味着新的合规压力，也意味着前所未有的价值释放窗口。 一、三份政策叠加，数据中台的角色正在被重新定义 2022年底发布的"数据二十条"（《关于构建数据基础制度更好发挥数据要素作用的意见》）为数据资产的讨论建立了一个制度基础——数据资源持有权、加工使用权、产品经营权三权分置，让数据在法律层面第一次具备了被界定为"资产"的前提。在此之前，企业即便拥有海量数据，也无法在法律上清晰说明这部分资源的所有权和收益归属。三权分置框架解决了这一底层问题。 紧接着，财政部《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号）于2024年1月正式施行，让数据资产从理论探讨进入了实操层面。这份文件的核心意义不在于定义了某种新的会计科目，而在于让数据治理从一个IT部门的事情变成了CFO的需求——数据能不能入表，直接关系到企业的资产规模和财务表现。而要回答"能不能入表"这个问题，需要三个前置条件：数据范围明确、质量可审计、价值可评估。这三个条件中的每一条，都需要数据中台来承载。 2024年初，国家数据局发布"数据要素×"三年行动计划（2024—2026年），标志着政策从"确权"和"入表"进一步延伸到"流通"。数据不仅要管好、入好，还要在合规前提下对外共享和交易。这对数据中台提出了更高要求——不仅要管理内部数据，还要构建数据服务能力，支撑数据从内部资产向外部要素的转化。 三份文件叠加在一起，指向的是一个共同的信号：数据中台不能只做数据归集和加工的技术平台，它需要成为支撑数据确权、估值、质量保障、合规流通的资产管理基础设施。这个转变不是"锦上添花"的升级选项，而是政策推动下正在发生的角色重塑。 二、入表倒逼中台升级：三项核心能力必须补齐 数据资源入表看起来是财务操作，但实际上它反向倒逼企业补齐数据中台长期缺失的三项能力。 第一项是数据资产盘点——回答"有什么"。 入表的第一步是界定资产范围：哪些数据资源符合入表条件，哪些只是日常运营中产生的业务副产品？没有一套清晰的资产目录，入表范围就是一笔糊涂账。很多企业的数据中台存了大量的数据表，但从未从"资产"的视角做过梳理——这些数据分布在哪些系统、归属于哪些业务域、各自的数据特征和治理水平如何，一概不清楚。资产盘点的本质不是技术问题，而是管理问题：它需要企业建立一套从业务视角出发的数据资源分类和评估标准。 第二项是数据质量验证——回答"值不值钱"。 数据资产入表需要会计师事务所出具可审计的意见，而审计的前提是数据质量可以被验证。GB/T 36344-2018《信息技术 数据质量评价指标》定义了规范性、完整性、准确性、一致性、时效性、可访问性六个维度，为企业提供了标准化的质量评估框架。如果企业的数据中台无法基于这套框架输出结构化的质量评价结果，入表就缺乏量化依据——"凭感觉入表"在审计上走不通。 第三项是合规管理——回答"能不能流通"。 入表只是起点，数据资产后续的共享、交易和融资，都涉及安全合规。数据安全法和数据分类分级制度划定了底线：数据能不能对外提供、以什么方式提供、需要满足哪些安全条件——这些规则都需要在数据中台层面落实。中台如果缺乏统一的安全管控能力，数据资产即便入了表，后续的流通环节也会处处受阻。 这三项能力的共同特征在于：它们不是靠外部审计机构临时进场就能一次性解决的。资产目录需要持续维护、质量监测需要常态化运行、合规管控需要嵌入数据流转的每一个环节。数据中台必须把这些能力内建到平台架构中，而非依赖人工和Excel的临时补救。 三、DCMM 2.0释放的信号：国家标准层面，"数据资产"被正式确认 政策层面的推动，在标准层面很快得到了呼应。2025年发布的DCMM 2.0（GB/T 36073-2025，于2026年7月正式实施）对能力域进行了结构性调整：能力域数量从1.0版本的八个扩展到九个，其中最引人注目的变化是新增了"数据资产"能力域，排在九大域中的第四位。同时，"数据应用"域更名为"数据应用流通"，反映出了从内部应用到外部流通的能力延伸。 DCMM 2.0的九大能力域包括：数据战略、数据治理、数据架构、数据资产（新增）、数据标准、数据质量、数据安全、数据生存周期、数据应用流通。新增的"数据资产"域重点考察企业的三项能力：资产盘点（有没有清晰的资产视图）、价值评估（能不能量化数据资产的业务价值）、资产运营（数据资产能不能持续产生效益）。对照前面政策文件的要求，可以发现DCMM 2.0的"数据资产"域所考察的内容，恰好对应了数据资源入表和流通的前置条件。 从九大域与数据中台的关系来看，数据架构、数据资产、数据标准、数据质量、数据应用流通这五个域与数据中台高度相关，数据治理、数据安全、数据生存周期三个域有中等关联度，数据战略域偏组织层面。这意味着DCMM贯标评估中约有半数以上的能力域需要数据中台作为技术承载——数据中台的成熟度，在相当程度上决定了企业DCMM评估能达到的等级。 DCMM 2.0的意义在于，它把政策层面的"数据是资产"从宏观判断落地成了可评估、可分级的管理标准。政策说数据是资产，标准说怎么评估企业资产化管理的能力。在这两者之间，数据中台是最核心的技术承载平台。 四、理采存管用：在政策与标准之间架设工程落地路径 企业CDO在读完政策和标准之后，往往会面对一个更实际的问题：知道了"应该具备什么能力"、知道了"要达成什么结果"，但从哪里开始？分几步走？ 在这个问题上，龙石数据提出的"理采存管用"五阶段方法论提供了一套工程化的落地框架。它与DCMM标准、外部政策之间的关系可以概括为：DCMM是检查清单（定义了企业数据管理应具备哪些能力），政策是考核指标（规定了数据资产化的方向和目标），而理采存管用是施工图纸（告诉企业在不同阶段分别做什么）。 在数据资产化的语境下，理采存管用五个阶段分别获得了新的解读： 理（资产盘点）：入表前必须搞清楚企业拥有哪些数据资源，哪些具备资产属性。这是一个从"数据在哪里"到"资产有什么"的视角转换。 采（打通资产供应链）：数据分散在不同业务系统中，不汇聚到一处就无法形成统一的资产视图。采的作用就是把各系统的数据归集到一起，为后续的资产化管理提供数据基础。 存（建立资产统一量纲）：不同系统对同一业务实体的编码方式不同、口径不同。如果没有统一的数据模型和标准化的仓库分层，资产目录就会出现"看起来有资产、实际上对不上账"的问题。 管（保障资产可信度）：这是资产化最关键的环节。如果数据治理不到位，入表就只是账目改编。标准规范落标稽核、质量常态化监测、元数据持续维护——这些"管"的动作，决定了入表后的资产到底是"实打实的数据资产"还是"经不起审计的账面数据"。 用（释放资产价值）：入表是起点，用出价值才是终点。资产目录上线后，数据服务、API调用、智能分析等应用场景才能让数据资产真正产生业务回报。 理采存管用的核心价值在于，它把政策要求和标准框架翻译成了可执行的分阶段任务，让数据中台建设从"功能堆砌"变成了"目标导向的能力构建"。每一个阶段的产出，都对应了入表和DCMM贯标中的一个具体前置条件。 五、案例验证：一条已经走通的全链路路径 政策的窗口期不会一直敞开。在多数企业还在论证"数据能不能入表"的阶段，已有先行者完成了实践闭环。 福建某交投集团（企业名称已脱敏，下同）是负责城市数字化运营的核心主体，旗下拥有充电系统、调度系统、安防系统等多个业务系统，积累了大量数据资源。然而这些数据分散在上千张业务表中，家底不清、质量未知——这是多数企业在面对数据资产入表时的典型状态。 项目从资产盘点入手。团队花了数周时间梳理上千张业务表，依据资产入表条件划定边界，识别出充电订单、支付流水、用户档案、对账记录等核心数据资源，最终形成了一份标准化的《企业数据资产目录》。这一步解决的是"哪些数据能入表"的问题。 第二步转向质量保障。以GB/T 36344-2018六个维度为框架，对拟入表的数据资源进行全量自动化质量评价。通过问题清单协助完成了数据修复与整改，最终质量评价总评分达到99.53分，为会计师事务所提供了可审计的质量依据。这一步解决的是"数据能不能经得起审计"的问题。 第三步完成入表确认。律所依据质量报告和资产目录完成合规审查，资产评估机构基于治理成果进行估值，会计师事务所最终完成入表确认。企业资产负债表上新增了一笔数据资产，成为福建省某市首批完成数据资产入表的国有企业。 这个案例说明了一个关键判断：数据资产入表看起来是财务工作，但真正决定成败的环节全在数据治理。资产盘点（理）→ 标准建设（管）→ 质量评估（管）→ 入表确认（用），每一步都在验证治理能力是否到位。治理到位，入表就是水到渠成的产出。 六、窗口期不等人：给CDO的三个行动建议 政策推动的转变往往具有窗口期特征。早期入局者不仅能获得先发优势，还能在后续的数据交易、资产融资等环节占据更有利的位置。对于还在观望阶段的CDO和CIO，有三个动作可以立刻着手。 先摸清家底，不用等完美方案。 选1-2个核心业务域，先做一次数据资产盘点和质量基线评估。不一定现在就回答"数据值多少钱"，但至少要知道自己有什么、数据质量处于什么水平。很多企业卡在"全量入表"的宏大叙事中迟迟不启动，现实中从一两个业务域先跑通全链路，远比等待全局论证更务实。 把资产化能力建在数据中台上。 资产目录编目、数据标准落标、质量常态化监测——这些不是靠外部咨询机构进场一周就能持续运转的能力。它们必须内建在数据中台里，靠系统自动化执行，而非依赖人工维护。目前，部分数据治理平台已经遵循理采存管用方法论进行模块化设计，资产盘点、标准落标、质量闭环等功能可以按需装配，企业能从一个业务域先跑通全链路再横向扩展。 让治理跑在入表前面。 入表是结果而不是目的。把理采存管用的前四步——资产盘点（理）、数据归集（采）、统一模型（存）、质量保障（管）——跑扎实，入表自然水到渠成。反过来，如果跳过治理直奔入表，即便勉强完成，入表后的数据资产也未必经得起后续的审计和估值检验。从多数成功案例来看，较为稳妥的路径是让治理的进度始终领先入表一个身位。 常见问题（FAQ） Q1：做了数据中台，是否一定能满足数据资产入表？ 不一定。数据中台解决的是数据归集、加工和治理的技术支撑问题，而数据资产入表还需要额外的环节——资产范围确认、质量评估报告、合规审查和会计确认。中台提供了必要的数据基础，但入表本身是一个涉及多方专业机构协同的流程。关于入表的具体前置条件，可以参考本文第二节中三项核心能力的拆解。 Q2：DCMM贯标评估和资产入表是什么关系？ 入表依据的是财会〔2023〕11号，是财务侧的操作规范；DCMM 2.0（GB/T 36073-2025）是企业数据管理能力的评估标准。两者不直接等同，但存在高度关联——DCMM 2.0新增的"数据资产"能力域考察的资产盘点、质量评估和价值管理能力，恰好是入表所需的前置条件。完成DCMM贯标的企业，在入表过程中会发现很多前置工作已经就绪。 Q3：中小企业是否有必要做数据资产化？ 有。中小企业的数据体量虽然远不及大型国企，但核心业务数据的价值并不小。不需要追求全量入表，可以从核心业务域的数据资产目录和质量管理起步。如果预算有限，市场上有部分免费可用的数据质量工具——例如龙石数据质量管理平台·社区版，覆盖GB/T 36344六个维度中的核心检测项，可以作为入表前的数据质量核验工具，先摸清质量基线再做投入决策。 参考来源： [1] 中共中央、国务院，《关于构建数据基础制度更好发挥数据要素作用的意见》（"数据二十条"），2022年12月 [2] 财政部，《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号），2023年8月，2024年1月1日起施行 [3] 国家数据局，《"数据要素×"三年行动计划（2024—2026年）》，2024年1月 [4] 全国信息技术标准化技术委员会，《GB/T 36073-2025 数据管理能力评估成熟度模型》（DCMM 2.0），2025年发布，2026年7月实施 [5] 全国信息技术标准化技术委员会，《GB/T 36344-2018 信息技术 数据质量评价指标》，2018年发布 [6] 龙石数据，《数据治理实战指南》，— https://www.longshidata.com/lsdmaterial/dg-guide.html
龙石数据中台 V3.9.2 聚焦全链路安全加固、平台功能瘦身、运维体验精细化三大方向迭代升级。
龙石·企业级AI智能体平台是面向企业用户、IT团队和合作伙伴，提供AI智能体统一使用、自主构建与持续运营能力的一体化平台。
去年年底，一家中型制造企业部署了企业内部大模型，试点阶段的效果让团队兴奋不已——业务总监对着对话框输入"本月华东区销售情况"，系统自动拉取数据、生成图表，几秒钟就给出了分析结果。正式上线后第一周，财务总监找到IT负责人："你那个大模型说华东区销售额3200万，我财务系统里是2800万，差了400万，哪个是准的？" 排查花了整整两天。问题不在模型——模型忠实地汇总了它能找到的数据。问题在于三个业务系统对"华东区"和"销售额"的定义各不相同：ERP系统按发货地址判断区域，CRM按客户归属地判断，而BI报表用的是一个手工维护的区域映射表。大模型把它们混在一起，输出了一个看起来完整、但实际上口径打架的结果。 这是一个缩影。当越来越多企业把大模型推向业务一线时，最先暴露的往往不是模型能力的问题，而是数据治理的缺口。大模型像一个能力极强的翻译官，但它翻译的准确性，取决于给它看的原始材料是否清晰一致。而今天很多企业的数据治理平台，在设计之初并没有为这个场景做好准备。 一、大模型撞上数据治理的墙 大模型对数据质量的要求，远比传统BI和报表系统严苛。传统BI里，一个字段为空，报表上显示"null"，用户一看就知道数据缺失。大模型不一样——空值可能在上下文推理中被补全为一个不确定的数值，用户无法判断这个数值的来源依据。脏数据没有被"忽略"，而是被"放大"了。 具体来说，有三类问题在大模型场景下被急剧暴露。 数据质量问题被放大。 制造企业的ERP系统中，某原材料批次的检验结果字段因历史原因存在零值、负值和超出理论范围的异常值。传统报表按条件过滤后尚可正常使用，但大模型在做趋势分析时将这些异常值纳入计算，导致对供应商质量的判断出现偏差。Andrew Ng 提出的 Data-Centric AI 理念正是在回应这个问题：与持续优化模型相比，持续提升数据质量和治理能力，往往能获得更大的业务收益。 数据标准缺失导致语义混乱。 同一个业务实体在不同系统中用不同的编码规则和取值口径，这不是新问题。但在大模型场景下，模型会混合不同口径的数据生成分析结果——"华东区销售额"这个看似简单的查询，背后可能同时取用了ERP、CRM和手工报表的数据，三者的口径差异在自然语言交互中完全不可见。 元数据割裂让模型行为不可解释。 当缺乏系统化的元数据管理时，追溯一个模型输出偏差的来源从分钟级延长到天级。治理团队不知道模型在回答"客户满意度趋势"时到底关联了哪几张表、取了哪些字段——训练数据变成了黑箱，模型输出的可信度随之坍塌。 二、DCMM 2.0已经在画方向了 有意思的是，国家标准层面已经在为这个趋势做准备。 2025年底发布的 DCMM 2.0（GB/T 36073-2025，2026年7月1日实施），将能力域从旧版的8个扩展为9个。新增的数据资产域被排在第4位，夹在"数据架构"和"数据标准"之间；原有的"数据应用"域更名为数据应用流通，放在第9位收尾。评估指标从441条增加到486项，DCMM 也在2025年6月成功立项为 ISO 国际标准。 这两个变化放到一起看，释放的信号很明确：数据管理能力的评判标准，正在从"有没有治理"升级为"能不能资产化、能不能流动起来为业务所用"。一个静态的、管控导向的治理体系，已经无法响应AI时代对数据供应速度和质量的要求。 DCMM 2.0 的九大能力域（数据战略、数据治理、数据架构、数据资产、数据标准、数据质量、数据安全、数据生存周期、数据应用流通）中，与AI直接相关的能力域至少包含了数据质量、数据标准、数据资产和数据应用流通。这四个域恰恰是传统治理平台架构中最容易被"做完即止"的环节——建完标准就不再更新，编完目录就不再维护，质量规则配置完就不再迭代。而大模型带来的持续用数需求，要求这些能力必须从"一次性工程"转变为"持续运营"。 三、治理平台正在发生的三个转变 如果说DCMM 2.0是从标准层面给出了方向，那么治理平台的产品架构正在从三个维度回应这个方向。 转变一：从纯规则驱动到AI+规则双引擎。 传统治理平台的运作逻辑是规则驱动的：人工梳理元数据、人工配置质量规则、人工打标签、人工维护血缘关系。这套逻辑在面对大模型带来的用数需求时，瓶颈不是准确率，而是速度。 AI正在从两个方向进入治理平台本身。一是用AI治理数据：AI自动发现元数据与血缘关系、AI辅助推荐质量规则（效率提升数量级远超人工配置）、AI识别业务语义（自动将"神仙水"映射为"SK-II精华露"）。二是让治理成果为AI所用：元数据不再是给人看的目录，而是AI理解数据含义的语义层；数据标准不是挂在墙上的规范文档，而是AI跨表关联的翻译层；数据质量不是周期性的质检报告，而是AI输出可信度的实时基础。 两者的关系不是替代——规则保底线，AI提效率。规则负责合规性约束和确定性校验，AI负责自动化发现、智能推荐和语义理解。双引擎协同，才能同时满足AI时代对治理"既快又准"的要求。 转变二：从管控工具到AI基础设施。 很多企业在推进大模型项目时采用了一个顺序："先把大模型跑起来，治理后面再补"。这个顺序在实践中反复遇到同一个问题——半年后业务需求变了，治理的优先级被调整，模型的能力上限卡在了数据质量上。 更务实的方向是，治理本身就是AI基础设施的一部分。DAMA-DMBOK 定义的11个知识领域中，数据质量、元数据管理和主数据管理三项，恰好对应了AI用数场景的三个基础条件：数据可信、数据可理解、实体可关联。这不是偶然的——国际数据管理框架在二十年前划定的核心能力域，在今天的大模型场景下恰恰成了不可或缺的底座。 在这个视角下，"理采存管用"方法论的五阶段闭环也获得了新的含义。"理"阶段产出的资源目录，成为AI理解"有什么数据"的入口；"采"和"存"阶段形成的标准化数据底座，保证AI取数的口径一致；"管"阶段的元数据和质量规则，为AI输出提供可信度保障；而"用"环节本身，正在从"人找数据"演变为"智能体帮人用数据"。 转变三：从人找数据到智能体帮人用数据。 今天大多数企业里，用数据做分析仍然是一件有门槛的事。一个典型的路径是：业务人员提出需求→IT部门排期→技术人员写查询→结果不对→再沟通→再等排期。这个循环走下来，一个简单的"本月各区域销售对比"，从需求提出到拿到结果，常常以天甚至周为单位。 AI用数智能体正在把这个路径压缩成——自然语言提问→AI理解意图→自动定位数据→生成分析结果。它的核心不是"把SQL翻译成自然语言"这么简单，而是在治理到位的前提下，让元数据、数据标准和质量规则共同构成一个AI可理解的数据语义层。当"客户回款数据在哪个表里、口径是什么"这样的问题可以在几秒内得到准确回答时，用数能力才有可能像收发邮件一样成为企业的标配。 四、一个已经落地的样本 以上三个转变不是理论推演。江苏某国企数科（企业名称已脱敏，下同）运营着一个数据要素流通平台，汇聚了大量公共数据与市场化数据资源。平台建成后，运营团队发现了一个尴尬的局面：数据确实"有了"，但用户用不起来。 问题集中在三个断层上。找数难——平台资源丰富，但用户检索依赖关键词匹配，缺乏智能引导，往往多次筛选才能定位所需数据。用数难——平台功能全面、流程规范，但用户对数据申请流程和资源分布缺乏清晰认知，尤其是新用户容易产生困惑。运营难——平台缺乏有效的反馈与需求沉淀机制，用户在使用过程中的问题和需求难以系统收集，导致数据产品迭代缺乏依据。 龙石数据为这个平台构建了"感知-匹配-演进"三位一体的AI用数智能体。不是做一个独立于平台之外的聊天机器人，而是将智能体深度嵌入数据中台的治理成果之上——知识库体系梳理了资源目录、数据产品和使用流程，需求感知引擎通过分析用户的搜索失败记录和浏览中断点自动识别潜在需求，智能匹配引擎基于语义检索理解用户意图并主动推荐数据产品。 效果超出了团队预期。基础咨询工单量显著下降，用户检索耗时大幅缩短，首次申请成功率明显提升。更重要的是运营模式的改变——智能体定期生成需求洞察报告，运营团队据此召开数据产品决策会，数据产品迭代周期明显缩短。用客户原话说："以前推数据产品像蒙着眼睛打靶，智能体给了我们一杆瞄准镜。" 这个案例的价值不在于技术本身，而在于它验证了一个逻辑闭环：治理到位的数据底座→AI理解数据的能力→用户用数门槛降低→用数行为增加→需求反馈→持续优化治理。治理和AI不是先后关系，而是相互驱动的飞轮。 五、给CDO的行动建议 基于上述趋势和落地验证，有三个方向值得关注。 在AI项目启动前，建立最小可用治理。 不需要做到面面俱到——至少让AI知道有哪些数据、在哪里、字段的含义是什么。覆盖核心业务域的数据标准和元数据管理，是决定模型从"能跑"到"可信"的关键一步。 治理能力要嵌入AI管线，而不是独立运作。 不要分两个团队、两本预算。"用"环节暴露的数据问题应该能够自动反馈到"管"环节——跨表关联失败说明主数据标准有缺口，模型输出波动说明质量规则需要更新。治理的反馈回路越短，AI的准确率爬升越快。 评估治理平台时，把"AI原生性"作为一个判断维度。 除了功能完整度和架构兼容性之外，还需要考察：元数据是否为机器可读的结构化格式？数据标准是否可以被下游AI系统调用？质量规则能否在数据被AI使用前自动触发？这些问题目前不是选型标准中的常见条目，但它们会越来越重要。市场上已有部分产品在实践这种架构思路——例如龙石数据中台以"理采存管用"方法论为骨架，将元数据、数据标准和质量管控作为AI用数智能体的基础能力层，治理不是在事后补救，而是在数据流转中实时生效。 六、常见问题 Q：已经在用大模型了，还能回头补治理吗？ 可以。先对核心数据域做质量评估，增量治理规则逐步建立，存量按优先级分批推进。治理不是一次性的"大扫除"，而是持续的运营过程，任何时候开始都不晚。 Q：大模型项目要不要等治理做完再启动？ 不需要。两者可以并行推进，但建议模型面向业务用户之前至少完成核心数据域的标准统一和质量基线。大模型可以先在封闭的、数据质量已知的小范围场景中跑通，再逐步扩大范围。 Q：AI原生治理平台和传统治理平台的核心区别是什么？ 不是功能多少的差异，是架构逻辑的根本不同。传统平台把治理当作独立的功能模块——元数据管理、数据质量管理、标准管理各自独立运行。AI原生平台把治理能力内化为AI用数基础设施——元数据是AI理解数据含义的语义层，数据标准是AI跨表关联的翻译层，质量规则是AI输出可信度的实时保障。前者是"有一套治理功能"，后者是"治理能力在每次数据被使用时自动生效"。 企业AI建设的瓶颈正在从模型能力转向数据能力。治理平台如果继续按照"管控工具"的定位演进，它和大模型之间的关系会越来越像两条各自发展的平行线。而当治理平台把自己定位为AI基础设施的一部分时，数据和智能之间那条曾经模糊的边界，才会真正开始消融。 参考来源 [1] DAMA International, "What is Data Management", https://dama.org/about-dama/what-is-data-management/ [2] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），中华人民共和国国家标准，2025年12月31日发布 [3] Andrew Ng et al., Data-Centric AI, https://datacentricai.org/ [4] DAMA International, DAMA-DMBOK2（数据管理知识体系指南） [5] 国家数据局，《"数据要素×"三年行动计划（2024—2026年）》 [6] 龙石数据，《数据治理实战指南》，— https://www.longshidata.com/lsdmaterial/dg-guide.html
CFO在季度会上问了一句："咱们的数据能不能入表？"数据团队负责人看了看手头那几十个数据质量告警——沉默了。 这不是虚构场景。同一周，另一家制造企业的数据团队也遭遇了类似的尴尬：审计师要求提供拟入表数据的质量评价报告，团队翻遍了系统，只找到一份两年前的手工Excel质量记录——字段缺失率没有统计、跨系统一致性从未对比、数据血缘完全空白。CFO最后拍了板："入表先搁置。" 这两幕正在越来越多的企业中上演。财会〔2023〕11号[2]施行已近两年，数据资产入表从概念讨论走向实际操作，越来越多的CFO和审计师开始把同样的问题摆上台面。而大多数企业的数据治理状态，距离回答"能不能入表"还有三道明显的坎。 一、三道政策令：入表不再是选择题 三大政策正在将数据资产入表从"加分项"推向"必答题"。 DCMM 2.0（GB/T 36073-2025）[1]新增"数据资产"能力域。 这是标准层面的关键信号——评判企业数据管理水平的标准，从"有没有治理"升级为"能不能资产化"。数据不再只是 IT 团队维护的"后台资源"，而是需要被识别、被评估、被量化的企业资产。 财会〔2023〕11号[2]明确了数据资源的会计处理路径。 这份暂行规定施行以来，数据可入表的制度障碍已被扫除，CFO 开始真正关注数据治理——因为数据能不能入表、入多少，直接关系到财务报表。 "数据要素×"三年行动计划进入收官之年。 数据要素市场化配置加速，公共数据授权运营、企业数据资产入表、数据交易定价——这一整套政策组合拳正在推动一个根本变化：企业数据管理的主线任务，已经从"把数据管好"扩展为"让数据成为资产"。 三道政策拧成一股绳，方向已经清楚。问题是：大多数企业的数据治理，还卡在入表的前一道关口上。 二、入表前的三道坎 从我们观察到的企业实践来看，数据资产入表之前，有三道坎几乎家家都会遇到。 第一道坎：资产底数不清。 企业运行多年，数据散落在数十套业务系统中，有多少张表、哪些字段、数据量多大——往往没人能说清楚。而数据资产入表的起点恰恰是"先知道你有什么"。底数不清，入表就无从谈起。 第二道坎：质量参差不齐。 数据入表需要审计依据，但大量企业的数据从未经过系统性的质量评价。同一客户的名称在 CRM 里是"XX有限公司"，在 ERP 里是"XX公司"，在 MES 里又是一个缩写——当数据本身都不可信时，资产估值就失去了基础。数据资产化有一个朴素的前提：数据必须可信。入表只是把这个前提变成了硬性约束。 第三道坎：标准没有统一。 跨系统的数据口径不一致，导致资产边界无法清晰界定。一条"合同金额"数据，财务系统和业务系统各有一套算法，以哪个为准？入表之前，这类问题必须被回答。 这三道坎背后指向同一个事实：数据资产入表的真正难点不是会计处理，而是数据治理。入表倒逼的，本质上是一次治理能力的系统性升级。 三、从被动应对到主动推进：分三步走 面对入表压力，从多数企业的实践来看，一个较为稳妥的做法是将治理任务拆解为三步推进——不是在入表前突击搞一次"大扫除"，而是让治理本身走向体系化。 第一步：先把家底盘清楚。 不谈标准、不谈质量，第一步就是搞清楚自己有什么数据。全量数据资产盘点，涵盖各业务系统的表、字段、数据量、更新频率，最终产出一份可追踪的资产清单。这一步的价值不止于入表——很多企业在盘点过程中才发现，同一个业务域的数据在三个系统里有三种叫法，连业务部门自己都说不清哪个是最新的。入表给了盘点的正当性：不是 IT 部门"又在搞治理"，而是 CFO 和审计师需要这份清单。 第二步：让数据质量可量化。 家底盘清之后，紧跟着的问题是：这些数据可信吗？以 GB/T 36344-2018[3]定义的六个质量维度为框架——规范性、完整性、准确性、一致性、时效性、可访问性——对企业数据做一次系统性的质量扫描和量化评分。除可访问性外，其余五个维度直接影响数据的可用性和可信度。查出来的问题，打标、归类、生成工单、推动修复，让质量管控从"人工经验判断"变成"可追踪的闭环"。跨系统的数据标准统一也应当在这一步完成——统一命名规则、编码规范、核心业务主数据定义。 第三步：把资产管起来。 前两步扎实之后，数据资产化管理的基础就具备了。这一步的核心是建立资产目录，让业务人员用业务语言就能找到数据资产、理解其含义、评估其价值。资产编目、合规审核、价值评估、会计确认——这一系列动作需要 IT、财务、法务、业务多个部门协同完成。入表不是终点：数据被持续使用、产生可计量的业务回报，才是资产化的完整闭环。 需要指出的是，三步走不是一条直线。企业在第一步盘点之后，往往会发现某些数据域的质量问题比预想的严重，需要回到第二步深入治理，才能推进第三步。但从整体方向来看，这三步的顺序相对清晰——跳过盘点直接定标准，容易做出一堆没人用的规范；跳过质量直接入表，写进报表的数据经不起审计。 四、案例验证：一家国企的入表实战 华东某交投集团（企业名称已脱敏，下同）的经历，为上述路径提供了一个完整的注脚。 启动入表工作之初，该集团面临的是一个典型困境：上千张业务表散落在各系统中，无人能说清全貌；同一类数据在不同系统里有不同的命名和口径；数据质量从未被系统性地评估过，无法量化可信度。 整个入表工作的起点，是一次历时数周的全量数据资产盘点（对应第一步"理清家底"）。盘点产出了集团首份完整的数据资产清单，为后续所有工作提供了基础坐标系。 在此基础上，项目团队着手建立跨系统的数据标准体系——统一命名规则、核心实体编码规范、质量评价框架（对应第二步"建标准、管质量"）。标准确立之后，数据质量评分得以量化：最终达到 99.53 分。 第三步进入资产化管理：编目、合规审核、价值评估、会计确认——多部门协同完成首批数据资产入表。 复盘整个过程，一个清晰的结论浮现：入表成功的根本原因，不是评估方法有多精妙，而是前两步——家底盘清了、质量标准统一了——走扎实了。入表不是治理的目的，而是治理扎实之后自然产出的结果。 五、常见问题 Q1：做了数据治理就一定能实现数据资产化吗？ 不一定。数据治理是资产化的必要条件，不是充分条件——但没有治理，资产化一定走不通。质量不可信的数据无法估值，标准不统一的资产边界不清。 Q2：应该先做治理还是先做资产盘点？ 先盘点。不知道有什么数据就去谈治理标准，容易搞出一堆没人用的规范。用"理"先摸清家底，再从中挑选高价值的数据资产优先投入治理资源，产出比更高。 Q3：中小企业资源有限，怎么落地？ 从最核心的一到两个业务域切入，花几周时间完成资产盘点和质量基线，搭建轻量平台跑通闭环。如果需要工具支撑，可以关注一些免费可用的数据质量检测工具——例如龙石数据质量管理平台社区版，覆盖 GB/T 36344[3]标准框架下的质量检测，可先做一次数据质量体检，再根据结果决定下一步投入方向。关键是先动起来，不必追求一步到位。 六、结语 数据资产入表倒逼治理升级——这未必是坏事。 过去，技术团队推着业务走，往往感觉推不动。现在情况反过来了：CFO 和审计师在推着技术团队走，入表的硬性要求反而让治理获得了来自业务端的驱动力。方向比从前更清晰。 从多数企业的实践来看，较为稳妥的做法是先理家底、再建标准、再管质量——三件事做扎实了，入表是水到渠成的事。数据资产入表不应被视为一次性的会计操作，而应被看作企业数据治理能力走向体系化的一个起点。 参考来源 [1] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），2026年7月1日实施 — openstd.samr.gov.cn/bzgk/gb/std?tid=72458 [2] 财政部，《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号），2023年8月 — gov.cn/zhengce/zhengceku/202308/content_6899395.htm [3] GB/T 36344-2018《信息技术 数据质量评价指标》 — openstd.samr.gov.cn/bzgk/gb/std?tid=72297 龙石数据，《数据治理实战指南》，— https://www.longshidata.com/lsdmaterial/dg-guide.html
一家中型制造企业在部署大模型后，内部测试阶段效果不错，问"本月华东区销售情况"能给出清晰的数据和趋势判断。正式上线第一天就出了问题——系统告诉业务副总"华东区上月销售额3200万"，但财务系统里是2800万，差了整整400万。 排查结果指向了一个简单的事实：ERP、CRM和财务系统对"华东区"的定义不同，对"销售额"的计算口径也不一样。模型本身没有出错——它忠实汇总了它能看到的全部数据。问题出在它"看到"的数据本来就不一致。 这个场景折射出一个正在加速的趋势：当大模型从技术验证走向业务一线，最关键的瓶颈往往不是模型能力，而是数据供给质量。Data-Centric AI的研究反复验证了一个判断——AI效果的上限由数据质量决定，而非模型参数。DCMM 2.0（GB/T 36073-2025）[1]更从国家标准层面确认了这一方向：L4量化管理级明确要求企业具备AI支撑能力，数据治理在AI时代已从"最好有"变成了战略级要求。 大模型时代，数据质量的容错率被大幅压缩 传统BI场景下，数据质量问题的后果相对可控。报表上一个数字偏差，使用者在业务层面往往能察觉——"上个月华东没做过这么大单子"——然后人工核查修正。数据错了，人的经验还能兜底。 大模型把这个容错空间压到了几乎不存在。原因是三个机制同时起作用。 第一，大模型输出的是完整分析结论，而非单个数字。当它在回答"今年哪个产品线增长最快"时，会调用多张表、关联多次查询、形成综合判断。链条中某一个环节的数据有问题，可能让整段结论偏离事实。业务人员面对一段逻辑完整的分析文本，很难逐环节拆解验证——这不是看一个数字对不对，而是判断一整套推理是否站得住脚。 第二，大模型天然倾向于信任输入数据。它不会主动质疑"这个字段的值从上下文推断可能不对"，也不会在发现多个数据源对同一指标给出不同数值时提示"请确认口径"。它会根据它能读取到的全部信息，给一个它认为最合理的回答。而如果它读到的信息本身就相互矛盾，这个"最合理的回答"可能恰好是最危险的——看起来有理有据，实际上建立在不一致的数据基础之上。 第三，修复成本呈非线性放大。传统BI场景下排查一个数字偏差，通常追溯到一两张源表就能定位。而大模型关联了多系统、多口径的数据，一次质量问题可能需要回溯多个数据源、对比多套业务口径、跨部门确认数据定义。排查周期从小时级拉长到天级，远超传统场景的量级。 换句话说，大模型不会判断数据对错，但它会让数据中的问题变得比以往任何时候都更难发现、更难追溯、影响更大。Data-Centric AI提出者吴恩达的判断在这里找到了最具体的注脚："与其花80%精力调模型参数，不如花80%精力提升数据质量。"当企业发现花了几百万调优的大模型，在实际业务场景中的表现还不如一个治理到位的中小模型时，数据治理在AI战略中的优先级自然被重新排列。 国家标准已在推动数据供给升级 DCMM 2.0（GB/T 36073-2025）[1]于2026年7月1日正式实施，带来的变化不止是能力域从8个扩展为9个。更值得关注的是成熟度评估体系中对AI能力的明确要求。 新标准将数据管理能力划分为五个成熟度等级：初始级→受管理级→稳健级→量化管理级→优化级。到了L4量化管理级，标准要求企业在数据管理全过程中具备量化评估能力，并引入人工智能等先进技术支撑数据管理决策。这意味着AI应用在DCMM体系中不再是一个可选项——企业若想在评估中达到L4及以上，必须在数据架构、数据质量、数据标准等关键能力域中储备AI用数能力。 九大能力域的重新划定也释放了明确信号。新增的"数据资产"域排在第四位，包含权属管理、价值评估和资产运营三个能力项，与"数据二十条"[3]确立的数据要素市场化政策方向直接呼应。"数据应用"更名为"数据应用流通"，将数据服务、外部数据管理和数据开放纳入统一框架。从标准结构来看，DCMM 2.0正在从"管好数据"向"用好数据"倾斜——而这一转变恰好与AI时代企业对高质量数据供给的需求同频。 与DCMM 2.0互补的是GB/T 36344-2018[2]《信息技术 数据质量评价指标》。该标准定义了六个数据质量评价维度：规范性、完整性、准确性、一致性、时效性和可访问性。除可访问性侧重数据获取的技术条件外，前五个维度直接影响AI应用效果——规范性决定了数据是否按统一格式组织、可被模型稳定解析；完整性和准确性决定了模型赖以推理的信息基础是否可靠；一致性和时效性决定了跨系统关联分析的结论是否可信。 政策层面，高质量数据集建设也在加速从概念走向落地。江苏省2026年率先推动高质量数据集先行先试，147个项目入选省级试点，覆盖制造、医疗、交通等多个领域。龙石数据联合省市场监督管理局数据中心和苏州大学共同申报的"高质量数据集智能底座"项目同期获批，探索数据治理成果向AI训练数据的高效转化路径。 这些标准和政策的交汇，指向同一个方向：高质量数据供给正从一个技术课题上升为制度性要求。以江苏某大数据中心为例，该中心对300余个高频共享数据资源、超过10亿条数据进行了系统性质量评测，累计定位近1000万个数据质量问题，经过持续修复后修复率达到95%，200个高频应用资源的准确率达到100%。公共数据供给从"能用"提升到"好用"——这个跃迁的逻辑，同样适用于企业AI场景下的数据供给。 从"数据可用"到"数据可训"：高质量供给需要三层基础 传统数据治理以满足业务报表和运营分析为主要目标，关注的是数据"能用"——能从不同系统中取到数据、能跑通报表、能支撑日常决策。但大模型对数据的要求不止于此。它需要数据"可训"——能被模型稳定解析、跨系统关联时不产生口径冲突、输出结论可以被追溯和验证。从"可用"到"可训"，需要补上三层基础。 元数据：让AI理解数据含义 元数据是数据的"使用说明书"——它记录了数据从哪里来、经过了哪些加工、每个字段代表什么业务含义。对传统BI来说，元数据的作用更多是辅助性的：分析师查一下表结构、确认一下字段含义。但对大模型而言，元数据层几乎是不可或缺的前提。 原因很简单：大模型在处理数据时，看到的是字段名和数值，但读不懂字段背后的业务语境。一个标注为customer_name的字段，在ERP系统里指签约主体，在CRM系统里指联系人。如果模型在关联这两个系统的数据时不做区分，"客户"的统计口径就直接出错了。元数据的作用，就是在这类场景下提供关键的业务语义——让AI能在理解数据含义的前提下使用数据，而不仅仅是拿到一个可查询的字段。 当监管或审计要求企业说明"训练数据来源和加工过程"时，元数据是唯一可以提供完整追溯链条的依据。没有元数据，训练数据就是一堆脱了上下文的值，数据的可解释性归零。 数据标准：让AI跨系统理解业务 大模型的一大优势是跨数据源关联分析。但这个优势的前提，是不同系统对同一业务概念的定义是一致的，或者至少是可映射的。 现实中的情况往往是反过来的。同一家制造企业，ERP系统按事业部划分"产品线"，MES系统按生产工艺划分"产品线"，CRM系统则按销售目录划分。三套"产品线"对应三种分类逻辑和编码体系，每一套在自己的系统内都自洽，但放到一起就互相冲突。当大模型尝试关联这三个系统的数据做综合分析，它面对的是一堆同名字段指向不同实体——口径不统一导致的结论偏差，比数据缺失更难排查。 数据标准层的作用，就是为不同系统之间建立一套"翻译机制"：ERP编码怎么映射到MES分类、CRM的中文描述对应哪个ERP料号。这不只是技术层面的字段映射——标准层实际上是AI跨系统理解的"业务词典"。有了这层翻译，模型才可能做到"问的是全公司的产品线趋势，回答时自动匹配所有系统的口径"。 数据质量：让AI输出可信 这是最直接的一层，也最容易被低估。GIGO原则（Garbage In, Garbage Out）在传统IT时代是一条经验法则，在大模型时代变成了一个被放大数倍的现实风险。 传统场景下，一条脏数据最多污染一张报表的某个格子。但在大模型场景中，一条脏数据可能被模型在多轮推理中反复调用——它生成第一个分析结果时引用了这个错误值，下一步做趋势对比时继续基于这个结果推导，再下一步做优先级排序时又把这个推导作为权重依据。一条脏数据的"污染半径"在模型推理链中被大幅扩张。 社区的实践经验表明，在正式启动大模型应用之前，至少要对核心数据域做一轮系统性质量评估。市面上也有部分免费的数据质量工具，例如龙石数据质量管理平台·社区版，部署后可对核心数据源进行GB/T 36344标准框架下的质量检测，旁路监测模式不阻断业务流转，适合作为质量基线的快速摸底工具。 三层基础之间的关系不是串行的——不需要等元数据"做完"再建标准、等标准"完美"再做质量。它们之间互相增强：元数据缺失时数据标准难以落地，质量检测的结果反过来可以暴露标准不一致的问题。从多数成功案例来看，选取一个核心业务域，三层并行启动、快速迭代，比逐层推进更高效。 CDO和CIO现在可以着手做的几件事 大模型还在快速迭代，但对数据供给的要求方向已经足够明确。不需要等到"治理100分"再启动AI应用，但启动之前有几件事可以先做。 先做一次数据质量体检。 选取AI应用瞄准的核心业务域，用GB/T 36344[2]的六个维度（除可访问性外重点看前五个）做一次系统性评测。摸清现状后再定优先级：如果多个系统对同一指标口径不一致，先把数据标准做起来；如果核心表的缺失率或异常值比例偏高，先建质量基线。体检的目的不是追求完美，而是知道问题在哪儿、先解决哪个。 建立"数据就绪"的最小体系。 不需要一开始就覆盖全部数据资产——从AI应用会用到的核心表和字段切入。元数据层至少记录这些表和字段的来源、加工过程和业务含义。数据标准层统一核心业务实体（客户、产品、供应商）的编码规则和分类口径。数据质量层在数据接入环节建立完整性、准确性、一致性的自动校验。这个最小体系跑通后，再向更多数据域扩展。 AI用数与数据治理并行推进。 不必等治理做完再上AI。实践中的一个有效策略是：AI用数的需求反向暴露治理短板。当业务人员用自然语言问数据时得到的答案不准，自然会暴露出标准不一致、元数据缺失、质量问题。这比自上而下推动治理更容易取得业务部门的理解和配合。选取一个业务价值最高的用数场景，先跑通再扩展。 关注DCMM 2.0的AI能力要求。 DCMM[1] L4以上要求企业储备AI用数能力，这涉及的是评估时间表而非远期规划。已有企业在进行DCMM 2.0评估准备时，将AI用数能力列为重点建设项。评估现有数据中台是否具备AI用数入口——如自然语言查询、数据资产目录驱动等——是一个务实的起点。市场上已有部分产品（如龙石AI用数智能体）支持自然语言问数、数据不出域的私有化部署，作为数据治理成果的消费层，可以让治理投入更快见到业务价值。 常见问题 问：大模型项目要不要等数据治理做完再启动？ 不需要。选取核心业务域先做质量评估和标准统一，治理工作与AI用数可以并行推进。内测阶段用受控数据集验证效果，是比较稳妥的做法。 问：怎么判断是模型能力问题还是数据质量问题？ 选取一个已知数据质量情况的业务域做测试。如果在该域中模型输出准确度明显高于其他域，说明问题更可能出在数据侧。借助数据质量评估工具对输入数据做系统检测，将检测结果与模型输出效果做对照分析，通常能快速定位根因。 问：中小企业没有专职数据治理团队，怎么起步？ 从数据质量体检开始。目前市面上已有免费可用的数据质量工具（如龙石数据质量管理平台社区版），覆盖GB/T 36344[2]主要维度，部署后可快速摸清数据质量现状，再根据结果确定治理优先级。不需要一开始就铺开全量——先盯住AI应用会用到的那几套核心系统和几张核心表即可。 问：DCMM 2.0 L4要求AI能力，大部分企业L3都不到，怎么办？ DCMM是能力建设的方向标，不是紧急合规线。企业可以根据自身所处阶段，先锚定与AI效果最直接相关的2-3个能力域重点建设——尤其是"数据质量"和"数据标准"两个域。先做到L3稳健级的核心能力，再向L4量化管理级演进。标准提供的是一条可参照的路径，不是一张时间表。 大模型代表了企业AI应用的前沿方向，但它的上限取决于数据供给质量而非模型参数规模。Data-Centric AI的核心理念在DCMM 2.0[1]标准中得到了制度性确认——数据治理已成为AI基础设施的组成部分，而非应用上线前的一项准备工序。 对企业CDO和CIO而言，眼下最务实的做法是从三层基础中最薄弱的环节切入，在AI用数中暴露问题、迭代优化。当模型能力不再是稀缺资源，高质量的数据供给就是AI应用效果的分水岭。这一能力，正在从技术课题转变为企业AI战略的核心竞争力。 参考来源 [1] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），2026年7月1日实施 — openstd.samr.gov.cn/bzgk/gb/std?tid=72458 [2] GB/T 36344-2018《信息技术 数据质量评价指标》 — openstd.samr.gov.cn/bzgk/gb/std?tid=72297 [3] 中共中央、国务院，《关于构建数据基础制度更好发挥数据要素作用的意见》（"数据二十条"），2022年12月 — gov.cn/zhengce/2022-12/19/content_5732695.htm [4] 龙石数据成功入选2026年江苏省高质量数据集建设先行先试项目试点 — https://www.longshidata.com/blog/c/c2026061101.html
当CFO下一次推门进来说"我们也要做数据资产入表"时，你的平台能不能答出这五个问题？ 第一问：企业有哪些数据资源？ 上百个业务系统、上千张表，能不能用一份结构化的资产目录把它们说清楚——而不用IT团队加班翻Excel？ 第二问：数据质量有多高？ 会计师事务所要的是系统性、可重复、可追溯的质量评价结果，不是一句"我们一直在用、应该还行"。 第三问：跨系统的数据口径统一了吗？ 同一个客户在CRM里叫"客户名称"，在ERP里叫"往来单位"——资产边界划不清，估值从何谈起？ 第四问：资产目录建好了吗？ 入表范围的划定，依赖的是一份面向审计和业务方的正式资产清单，而不是技术文档里的表结构说明。 第五问：这些能力是建在平台上，还是寄托在人的经验上？ 如果答案全是后者，那入表的准备还远没有完成。 数据资产入表正在从少数先行企业的"试点"走向制度化的"扩面"。对于此前还在观望的CDO、CIO来说，"入不入表"已经不是一个远期话题——以上五个问题，接下来的两年内大概率会被CFO和审计机构逐一追问。 入表不是会计问题，是数据治理问题 不少企业高管的直觉反应是："入表是财务部的事，跟我们信息部门关系不大。" 这个判断可能恰好弄反了。拆开数据资产入表的五个核心环节来看——资产盘点、合规审核、质量评价、价值评估、会计确认——前三个环节的本质都是数据治理工作，而不是财务操作。 资产盘点考验的是元数据管理能力：你能不能系统性地说清楚企业有多少数据、存在哪里、归属哪个业务域？合规审核考验的是分类分级和安全策略是否落地。质量评价更是纯数据治理范畴——按 GB/T 36344-2018[3]定义的六个维度（规范性、完整性、准确性、一致性、时效性、可访问性），除可访问性外其余五个维度直接影响数据是否"可信到可以入表"。 所以当CFO追问"这批数据能不能入表"时，答案不在财务部的账本里，而在数据治理平台的扎实程度里。一个基础公式是：元数据管理 + 数据标准 + 质量闭环 + 资产编目 = 入表就绪。 四个必检项：你的平台能过几关？ 如果把入表看作一次"数据审计"，那么数据治理平台就是这场审计的主要被查对象。以下四个维度，分别对应入表流程中的关键堵点。 元数据管理：你能说清楚自己有什么数据吗？ 资产盘点是入表的起点——入表范围取决于你对自身数据资源的掌控程度。如果元数据管理还停留在人工整理Excel的阶段，面对上百个业务系统、上千张表，盘清家底本身就是一项浩大工程。更关键的是，没有血缘分析能力，你很难追溯一张报表的上游来源——讲不清楚数据"从哪来"，入表范围就是一笔糊涂账。 从行业实践来看，具备自动采集元数据和血缘分析能力的治理平台，在这个环节能将盘点周期从数周压缩到数天。 数据标准：跨系统的"数据语言"统一了吗？ 同一个客户实体，CRM 里叫"客户名称"，ERP 里叫"往来单位"，数据仓库里又变成了"签约方"——三个名字可能指向同一个对象，但系统不认。数据口径不统一，资产边界就无法清晰界定，估值就更无从谈起。 DCMM 2.0[2]将数据标准列为独立能力域，考察的是企业是否建立了统一的业务术语、参考数据和主数据标准。入表场景下，这不再是一个"锦上添花"的技术规范，而是直接影响资产范围的底线条件。 数据质量：你的数据经得起审计吗？ 入表需要可审计的质量依据——不是技术团队一句"这批数据我们一直在用，应该还行"能够替代的。会计师事务所要求的是系统化、可重复、可追溯的质量评价结果。 GB/T 36344[3]的六个维度中，规范性（字段格式是否统一）、完整性（关键字段有无缺失）、准确性（数值是否与业务实际一致）、一致性（跨系统数据是否吻合）、时效性（数据更新是否及时）这五个维度构成了入表质量评价的基本框架。平台需要具备全量自动化质量扫描能力，能够输出结构化的质量报告，而不是对数据质量做一次性的手工排查。 资产编目：入表的"资产清单"建好了吗？ 即使前三项都达标，如果缺少一份结构化的数据资产目录，入表范围仍然无法被清晰界定。DCMM 2.0[2]新增的数据资产域，考察的正是企业是否建立了资产目录、是否具备资产分类与标签管理能力。 资产目录不是一份技术文档——它是面向审计和业务方的"数据产品手册"，需要说清楚每项数据资产的业务含义、覆盖范围、更新频率和质量状态。没有这份目录，入表范围的划定就带有较大的主观判断成分，经不起审计追问。 案例：一张上千张表的答卷 福建某交投集团（企业名称已脱敏，下同）是负责城市数字化运营的国有企业，拥有充电系统等多个业务系统，上千张业务表散落在不同数据库中。当数据资产入表被提上日程时，他们面临的问题和大多数企业一样：家底不清、质量未知、流程不熟。 整个项目按六个阶段推进：资产盘点→资产登记→质量评价→合规审核→价值评估→会计入表。其中，龙石数据承担了质量评价环节，并协同律所、会计师事务所和资产评估机构完成全链条服务。 关键节点有两个。一是资产盘点阶段，通过自动化扫描与业务规则相结合，从上千张表中梳理出充电订单、支付流水等核心数据资源，形成标准化的《企业数据资产目录》——这是后续所有工作的基础。二是质量评价阶段，以 GB/T 36344[3]为框架对拟入表数据进行全量自动化扫描，最终质量评价总评分达到 99.53 分（满分 100），会计师事务所据此确认质量符合入表要求。 该集团最终成为福建省某市首批完成数据资产入表的国有企业。回头看，入表的瓶颈并不在会计师事务所的专业能力，而在数据治理平台的基础有多扎实——资产目录决定了入表范围，质量评价决定了入表可信度。以龙石数据中台为例，其从资产盘点、标准管理、质量评价到资产编目的端到端支撑能力，正是在这类全链条服务中积累和验证的。 FAQ Q1：数据治理做到位了，就一定能入表吗？ 不一定。治理是必要条件但不是充分条件。数据质量不过关，估值无从谈起；标准不统一，资产边界就划不清——这些确实取决于治理的扎实程度。但入表本身还需要完成资产确认、合规审核和价值评估三个专业环节，这些超出了数据治理平台的范畴。比较准确的理解是：治理到位是入表的前提，入表是治理成果在财务层面的确认。 Q2：企业应该先做治理还是先做资产盘点？ 从多数案例的实际操作路径来看，比较合理的顺序是先盘点。福建交投花了数周时间先把上千张表的家底摸清楚，再在此基础上建立标准体系。如果反过来——还不知自己有什么数据就去定标准，容易搞出一套没人用的规范。当然，如果企业的数据标准基础已经比较好，两条线也可以并行推进。 Q3：中小企业有必要为入表铺这么大盘子吗？ 不需要像大型国企那样全量铺开。比较务实的做法是选一两个核心业务域，花几周时间做资产盘点加质量基线，再搭建轻量平台跑通从盘点到编目的闭环。第一步始终是搞清楚自己有什么——这和企业规模无关。如果不确定从哪里入手，也可以先用免费的数据质量评估工具对核心业务数据做一次扫描，了解当前数据质量的基线水平再做规划。例如龙石数据质量管理平台·社区版，部署后即可对核心数据源进行 GB/T 36344[3]标准框架下的质量检测，以较低的成本完成入表前的第一步质量摸底。 结语 DCMM 2.0[2]已于 2026 年 7 月正式实施，在贯标评估中，"你们的数据资产情况如何"正在从一个加分项变成基准问题。对于尚未启动入表准备的企业来说，当前比较紧迫的三个动作是：先把家底摸清楚，再把资产化的能力建在平台上而不是Excel里，最后选一个高价值域跑通从盘点到编目的全流程。 工业时代的企业竞争围绕设备和资金展开，数字时代的竞争天平正在向数据资产的运营能力倾斜。这个转变不是一夜之间发生的，但它确实在加速。 参考来源 [1] 财政部，《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号），2023年8月 — gov.cn/zhengce/zhengceku/202308/content_6899395.htm [2] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），2026年7月1日实施 — openstd.samr.gov.cn/bzgk/gb/std?tid=72458 [3] GB/T 36344-2018《信息技术 数据质量评价指标》 — openstd.samr.gov.cn/bzgk/gb/std?tid=72297
摘要 DCMM 2.0（GB/T 36073-2025）首次在L4量化管理级引入人工智能等先进技术要求，标志着数据管理成熟度评估正式进入"AI原生"时代。本文从DCMM 2.0标准文本出发，解析L4级AI支撑能力的具体内涵与四大应用场景，分析企业在数据质量、数据标准、组织协同和安全合规四个维度面临的挑战，并提出从L3到L4的三阶段实施路径。文章认为，DCMM 2.0的AI要求并非增设技术门槛，而是将Data-Centric AI等行业共识制度化——数据治理的成熟度，正在成为企业AI支撑能力的基础。 一、为什么DCMM 2.0要在L4以上引入AI？ 一家已通过DCMM三级评估的企业CDO，在准备冲刺L4时发现，新版标准的评估指标里新增了一类条目——"是否具备人工智能辅助数据管理能力"。这不是锦上添花，而是L4量化管理级评估的重要组成部分。 要理解这一变化的逻辑，需要先看清DCMM 2.0相对于1.0版的三项关键升级。 1.1 DCMM 2.0的三项关键升级 第一，能力域从8个扩展为9个。新增「数据资产」能力域（权属管理、价值评估、资产运营），将数据资产化从行业实践上升为国家标准框架。「数据应用」更名为「数据应用流通」，新增外部数据管理能力项，覆盖了数据从内部使用到外部流通的全链路。 第二，评估指标体系从定性描述升级为486项量化指标。DCMM 1.0的441项指标侧重"有没有"，DCMM 2.0的486项指标进一步追问"运行得怎么样"——不仅要求具备书面制度和执行记录，更需要可量化的管理数据作为证据。 第三，L4量化管理级引入人工智能等先进技术。这是DCMM标准历史上首次将技术能力写入成熟度等级。标准对L4的定义是"组织将数据视为获取竞争优势的核心要素，通过量化管理驱动管理效能提升；引入人工智能等先进技术，全面提升数据管理工作效率"。同时，安全域的要求也较1.0显著增强，能力项从策略/管理/审计升级为合规管理/安全防护/安全审计。 1.2 L4量化管理级到底要求什么 DCMM 2.0的五级成熟度模型中，L3（稳健级）与L4（量化管理级）之间存在一个质的跃迁。L3的核心是"有"——建立了统一的数据管理体系，各项流程在组织层面运转。L4的核心是"量化"——建立了量化的指标体系来度量管理效能。 典型的L4级量化指标包括：数据问题平均修复时长不超过2小时、关键数据标准覆盖率达到95%以上、数据质量问题的自动发现率等。这些指标的确立，意味着企业的数据管理从"靠人评估"走向"靠数据说话"。 AI在这一跃迁中扮演的角色是效率杠杆。486项量化指标的追踪、数据质量问题的自动发现和推荐修复、元数据的自动采集和血缘分析——这些工作如果全部依赖人工，在达到L4所要求的数据规模和管理精细度时将难以为继。标准在L4引入人工智能等先进技术，本质上是对规模化数据管理效率的必然要求。 1.3 从贯标数据看趋势 截至2025年11月，全国DCMM贯标企业总数已达10,448家，其中DCMM 5级（最高等级）仅33家。DCMM 2.0于2025年12月31日发布，2026年7月1日正式实施。对已获L3等级的企业而言，在准备L4升级评估时需要将AI能力纳入建设规划；对于仍在L2阶段的企业，较为稳妥的做法是在治理底座建设阶段就为AI能力预留接口。 二、AI在数据治理中的四大应用场景 DCMM 2.0在L4引入人工智能等先进技术，对应到数据治理实践中，主要体现在四个核心场景。这些场景并非理论推演，而是已有明确技术路径和落地案例。 2.1 智能分类分级 传统的数据分类分级依赖人工翻阅字段列表逐一标注，当数据量达到数百张表、数千个字段时，维护成本呈指数级增长。AI的介入方式是将分类分级从"人工标注"转变为"智能识别"——系统自动识别敏感字段（身份证号、手机号、金额字段等），根据字段内容和上下文推断数据等级，建立可动态更新的分类标签体系。 该场景对应DCMM 2.0数据安全域（合规管理、安全防护）和数据标准域的能力要求。在L4评估中，数据的分类分级覆盖率是安全域的重要量化指标，AI的自动化能力是实现高覆盖率的基础保障。 2.2 自动化质量规则推荐 数据质量规则的配置在传统模式下高度依赖个人经验——有经验的工程师知道"金额字段要检查非负，日期字段要检查格式"，新人则不知道从何入手。AI的做法是基于字段特征（字段名、数据类型、值域分布）和历史规则库，自动推荐适用的质量校验规则，将规则配置效率提升10倍以上。 该场景直接对应DCMM 2.0数据质量域（数据质量检查、数据质量分析）。L4要求的486项量化指标中，质量域占比显著，自动化规则推荐是实现质量指标追踪的技术前提。 2.3 自然语言查询（NL2SQL） 传统的数据查询链路是"业务人员提需求→IT排期写SQL→返回结果"，整个周期短则数小时、长则数天。自然语言查询（NL2SQL）将这条链路缩短为"业务人员用日常语言提问→系统自动理解意图、生成SQL→返回结果和可视化图表"，将数据查询的门槛从"会写SQL"降低到"会问问题"。 该场景对应DCMM 2.0数据应用流通域（数据应用、数据服务）。市场上已有部分产品（如龙石AI用数智能体）提供开箱即用的NL2SQL能力，简单查询场景准确率达100%，全场景综合准确率超过95%，数据不出域，支持DeepSeek和千问3等主流大模型的智能调度。 2.4 异常检测与智能预警 固定阈值的告警方式长期以来面临"误报多、漏报多"的困境——阈值设高了漏过真实异常，设低了被大量误报淹没。AI通过学习历史数据的趋势和波动模式，能够区分"正常的业务波动"和"需要关注的异常信号"，显著降低误报率，同时提升真实异常的检出率。 该场景横跨DCMM 2.0的数据质量域和数据生存周期域（数据运维），是在L4量化管理框架下实现数据运维效率提升的关键技术路径。 三、L4以上面临的四大核心挑战 四大场景的技术路径已经清晰，但企业从L3走向L4的过程中，面临的挑战主要不在技术层面，而在数据基础、组织协同和制度配套。 3.1 数据质量挑战：不干净的数据直接导致AI输出不可信 大语言模型的一个重要特征是，它对输入数据具有天然的"信任"倾向——模型不会主动质疑数据来源的可靠性，而是将输入数据作为推理的事实基础。当数据存在缺失值、错误记录或重复数据时，这些缺陷会被模型全盘接受并反映在最终输出中。 一个经典案例来自制造业：某企业的ERP系统中"华东区销售额"在同一月份存在两条记录——一条记录3,200万元（含退货冲销前的原始订单），一条记录2,800万元（财务核算后的实际确认），两条记录都标注为"最终版本"。AI在进行区域销售分析时无法判断哪一个数值是正确的，最终输出的分析报告将两个数值进行了简单平均，导致结论与实际情况偏差超过7%。 这正是Data-Centric AI理念所强调的核心观点：AI效果的上限，是由数据质量决定的，而不是由模型参数决定的。在模型能力趋于同质化的当下，数据质量的差异正在成为企业AI能力差异的决定性因素。 3.2 数据标准挑战：AI"读不懂"企业数据 即使数据本身的质量合格，如果AI无法理解数据的业务含义，其输出价值依然有限。问题的根源在于，大多数企业的元数据管理停留在技术层面——表结构、字段类型、长度约束记录得很清楚，但字段的业务语义几乎空白。 例如，一个字段的元数据描述是"VARCHAR(50)，不可为空"，但字段名是amount。在ERP系统中它代表含税订单金额，在财务系统中它代表不含税实际收入，在CRM系统中它代表预估合同金额。AI无法从技术元数据中区分这三个"amount"的业务差异，跨表关联分析时就会出现口径混乱。 DCMM 2.0的数据标准域（业务术语、数据元、指标数据）正是解决这一问题的框架——当企业建立了统一的业务术语标准和数据元标准后，AI就能准确理解"这个amount在财务语境下是不含税金额"，从而在跨表分析时做出正确的语义对齐。 3.3 组织认知挑战：AI和数据治理仍然是两拨人 在不少已经建立数据治理体系的企业中，存在一个结构性矛盾：治理团队的产出和AI团队的需求之间存在断层。 治理团队的工作成果——数据标准文档、质量评估报告、资产目录——以"汇报材料"的形式存在，AI团队看不到也用不上。AI团队从数据湖直接拉取原始数据，治理团队不知道他们在用什么数据、数据质量是否满足AI需求。"管"和"用"是两条平行线，各走各的路。 DCMM 2.0将数据治理组织、制度建设和数据文化建设列为核心能力域，意味着标准本身就预设了一个前提：数据治理首先是组织治理。L4的AI要求不是一个纯技术问题——如果治理团队和AI团队继续各行其是，AI辅助数据管理就缺乏组织层面的运行基础。 3.4 安全合规挑战：大模型放大了数据暴露面 DCMM 2.0将安全域的能力项从策略/管理/审计升级为合规管理/安全防护/安全审计，合规要求的显著增强并非偶然。 在传统BI环境中，数据权限控制可以精确到字段级——某个用户能看到哪些表、哪些字段、甚至能执行什么类型的查询，都可以通过权限体系精细管理。但在大模型的自然语言交互场景下，权限和输出的边界变得难以精细控制：用户的一个"帮我看看各区域的销售情况"可能在执行过程中访问了超出其权限范围的数据，模型在生成回答时也可能无意中暴露了敏感信息。 这也解释了为什么DCMM 2.0强调数据的分类分级和脱敏处理——数据在进入AI系统之前，建议先完成安全域的基础建设，否则AI的便利性与数据的安全性之间会形成一个难以调和的对立。 四、从L3到L4：三阶段实施路径 应对四大挑战的路径，可以归纳为三个阶段。每个阶段对应DCMM 2.0的不同能力域，各阶段之间既有先后关系，也有重叠推进的空间。 需要明确一个基本前提：DCMM 2.0是评估的"检查清单"，理采存管用方法论是工程落地的"施工图纸"。标准告诉企业"应该具备什么能力"，方法论告诉企业"怎么一步步把这些能力建起来"。两者之间的关系，从多数成功案例来看，通常是标准定目标、方法论定路径、产品定落地。 阶段一：夯实治理底座（理→管，约6-12个月） 这一阶段的核心目标是让AI"有数据可用、能读得懂数据"。具体包括四项基础工作： 数据资产目录建设：让AI知道企业有哪些数据，它们在哪里。这不是简单地把表名列出来，而是建立包含业务描述、数据归属、更新频率、质量状态的"数据地图"。 元数据补齐业务语义：为技术元数据补全业务含义——CRM系统中的amount代表"预估合同金额"，DW中的amount代表"不含税实际收入"。这一步是AI理解数据的前置条件。 数据标准统一核心口径：在业务术语层面统一"客户""订单""收入"等高频概念的定义和口径，避免AI跨表分析时的语义歧义。 数据质量基线建设：对核心业务表建立基本的完整性、准确性、一致性质检规则，让AI输出的结果建立在可信数据之上。 这一阶段对应DCMM 2.0的数据架构、数据标准、数据质量三个能力域。以江西某国控集团为例，该企业10余套业务系统分散独立运行，监管数据质量缺乏管控。通过构建覆盖完整性、准确性、一致性、及时性、唯一性五个维度的稽核规则体系，半年内将核心数据质量问题的修复周期从两周缩短至两天（企业名称已脱敏，下同）。 阶段二：AI能力嵌入治理流程（管→用，约12-18个月） 底座夯实之后，将AI能力逐步嵌入数据治理的日常工作流。这个阶段的策略不是"全面铺开"，而是选一个与业务痛点直接关联的场景先跑通： 在质量规则配置中引入AI推荐引擎。目前市场上已有部分数据治理平台（如龙石）在质量规则配置中内置了AI推荐引擎，系统根据字段特征自动推荐适用的校验规则，将配置效率提升10倍以上。 在分类分级中引入AI自动识别，替代人工逐字段标注。 在异常检测中引入AI模式识别，降低传统固定阈值告警的误报率。 在数据查询中引入AI自然语言交互，让业务人员用日常语言直接提问。 这一阶段对应DCMM 2.0的数据安全、数据应用流通两个能力域。关键成功因素不是技术选型，而是组织层面的"管用一体"——AI能力嵌入之后，治理团队的产出（标准、目录、质量基线）直接变成AI团队的输入（语义模型、查询接口、可信数据源），打破"管用分离"的结构性断层。 阶段三：形成量化管理与持续优化闭环（用→理，持续运营） 当AI能力在局部场景验证有效后，下一步是建立量化追踪和持续优化机制，真正实现L4所要求的"数据驱动管理"： 建立覆盖486项指标中核心项的量化追踪体系，例如数据质量问题的自动发现率、修复周期的趋势变化、数据标准的实际覆盖率等。 构建运营闭环：用户反馈（点赞/点踩）→工单处理→知识库更新→模型优化。AI能力的准确率不是一成不变的——随着业务场景的扩展和用户反馈的积累，模型持续自进化。 江苏某国企数科的案例提供了一个参考样本。该企业承接M市数据要素流通平台的建设运营，汇聚了大量公共数据和市场化数据资源，面临"找数难、用数难、运营难"三大瓶颈。通过部署"感知-匹配-演进"三位一体AI智能体，分三阶段推进——知识体系与智能能力建设、应用集成与场景落地、运营闭环与持续优化——实现了基础咨询工单量显著下降、检索耗时大幅缩短、数据产品复用率明显提升。如客户所评价："以前推数据产品像蒙着眼睛打靶，智能体给了我们一杆瞄准镜。" 这一阶段对应DCMM 2.0的数据资产、数据战略两个能力域。需要指出的是，数据治理的终点不是系统上线，而是组织真正具备持续用好数据的能力。这也是龙石数据"产品+培训+陪跑"模式的逻辑——培训解决"知道怎么做"，陪跑解决"能自己做"，最终目标是客户团队独立运转，而非依赖外部厂商。 五、结论 DCMM 2.0在L4量化管理级引入人工智能等先进技术，不应被解读为标准对企业的"增设门槛"。它的实质是将一个已在行业实践中反复验证的共识——数据治理的成熟度决定AI能力的天花板——通过国家标准的形式制度化。 从Data-Centric AI的理念验证，到大模型落地过程中反复撞上数据治理的墙，再到DCMM 2.0将AI能力写入评估框架，这三者指向同一个方向：数据治理正在从"IT部门的后台工作"演变为"AI战略的基础设施"。企业如果不能回答"数据在哪里、质量怎么样、标准是否统一"这三个问题，AI建设就始终缺乏地基。 对企业的实用建议可以归纳为三点。其一，"先理后AI"——AI能力在治理流程中的嵌入，应当建立在数据目录、元数据语义、标准口径和质量基线初步完备的基础之上。其二，"治理即AI基础设施"——元数据是AI理解数据的"翻译层"，数据标准是跨表关联的"统一语义层"，数据质量是AI输出可信度的"基准线"，这三层不是治理的副产品，而是AI的底层依赖。其三，"管用一体"——打破治理团队和AI团队的组织壁垒，让治理产出直接服务于AI应用。 DCMM 2.0的实施只是一个起点。随着数据资产入表（财会〔2023〕11号）、"数据要素×"三年行动计划的推进，数据治理成熟度正在从"贯标评估的一个分数"变成企业数据能力的"硬通货"。对于志在L4及以上的企业，AI不是数据治理做完之后的锦上添花，而是数据治理能力本身的组成部分。 六、FAQ Q1：DCMM 2.0在L4引入人工智能等先进技术，是否意味着企业必须自研AI？ 不是。DCMM 2.0评估的是"是否具备人工智能辅助数据管理能力"，而不是"AI是不是自研的"。企业可以通过引入成熟的AI数据治理产品和工具来满足这一要求，关键在于能力的存在和运行，而非能力的来源。 Q2：企业目前还在L2或L3，有必要现在关注AI吗？ 有必要。L2→L3通常需要12-24个月，L3→L4同样需要12-18个月。如果等到冲刺L4时才开始考虑AI能力建设，时间窗口将非常紧张。较为稳妥的做法是在治理底座建设阶段就为AI能力预留接口——例如在搭建资产目录时就考虑AI的可访问性，在配置质量规则时就引入AI推荐机制。具体的三阶段路径已在第四节详述。 Q3：AI和数据治理到底谁先谁后？ 不完全是先后关系。DCMM 2.0传递的信号是，AI不是治理做完之后的"锦上添花"，而是治理能力发展到L4阶段的"内在要求"。但在实操层面，较为务实的做法是选一个高价值场景（如NL2SQL或质量规则推荐），先把该场景涉及的核心数据域的元数据和标准做扎实，跑通AI用数闭环，再横向扩展到其他场景。不是"等治理完美了再上AI"，也不是"跳过治理直接上AI"，而是"边治理边验证，以用促治"。 Q4：中小企业没有专门的AI团队，怎么满足L4的AI要求？ 中小企业反而可能是AI在数据治理领域落地更容易的场景——团队规模小、数据量相对可控、没有"管用分离"的组织割裂。目前市场上已有部分产品（如龙石AI用数智能体）提供开箱即用的自然语言用数能力，集成DeepSeek和千问3等主流大模型，数据不出域。中小企业的主要工作不是组建AI团队，而是把核心数据域的治理底子打好——确保元数据说清楚业务含义、数据标准统一核心口径、核心表的数据质量达到可用水平。在此基础上，AI用数能力的部署和运行并不需要庞大的技术团队。 参考文献 [1] GB/T 36073-2025,《数据管理能力成熟度评估模型》（DCMM 2.0）, 国家市场监督管理总局、国家标准化管理委员会, 2025年12月31日发布 [2] DAMA International,《DAMA-DMBOK: Data Management Body of Knowledge, 2nd Edition》, Technics Publications, 2017 [3] GB/T 36344-2018,《信息技术 数据质量评价指标》, 国家市场监督管理总局、国家标准化管理委员会, 2018 [4] Andrew Ng et al., "Data-Centric AI", https://datacentricai.org/ [5] 财政部,《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号）, 2023年8月 [6] 国家数据局,《"数据要素×"三年行动计划（2024—2026年）》, 2023年12月 [7] 《中华人民共和国数据安全法》, 2021年9月1日施行 龙石数据，《数据治理实战指南》，— https://www.longshidata.com/lsdmaterial/dg-guide.html
