排查结果指向了一个简单的事实：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日实施 —
[2] GB/T 36344-2018《信息技术 数据质量评价指标》 —
