去年年底，一家中型制造企业部署了企业内部大模型，试点阶段的效果让团队兴奋不已——业务总监对着对话框输入"本月华东区销售情况"，系统自动拉取数据、生成图表，几秒钟就给出了分析结果。正式上线后第一周，财务总监找到IT负责人："你那个大模型说华东区销售额3200万，我财务系统里是2800万，差了400万，哪个是准的？"
排查花了整整两天。问题不在模型——模型忠实地汇总了它能找到的数据。问题在于三个业务系统对"华东区"和"销售额"的定义各不相同：ERP系统按发货地址判断区域，CRM按客户归属地判断，而BI报表用的是一个手工维护的区域映射表。大模型把它们混在一起，输出了一个看起来完整、但实际上口径打架的结果。
这是一个缩影。当越来越多企业把大模型推向业务一线时，最先暴露的往往不是模型能力的问题，而是数据治理的缺口。大模型像一个能力极强的翻译官，但它翻译的准确性，取决于给它看的原始材料是否清晰一致。而今天很多企业的数据治理平台，在设计之初并没有为这个场景做好准备。
一、大模型撞上数据治理的墙：从架构视角看三类断裂
大模型对数据质量的要求，远比传统BI和报表系统严苛。传统BI里，一个字段为空，报表上显示"null"，用户一看就知道数据缺失。大模型不一样——空值可能在上下文推理中被补全为一个不确定的数值，用户无法判断这个数值的来源依据。脏数据没有被"忽略"，而是被"放大"了。
从架构层面看，大模型场景下暴露的问题可以归纳为三个层面的断裂。
数据层的质量断裂。 制造企业的ERP系统中，某原材料批次的检验结果字段因历史原因存在零值、负值和超出理论范围的异常值。传统报表按条件过滤后尚可正常使用，但大模型在做趋势分析时将这些异常值纳入计算，导致对供应商质量的判断出现偏差。Andrew Ng 提出的 Data-Centric AI 理念正是在回应这个问题：与持续优化模型相比，持续提升数据质量和治理能力，往往能获得更大的业务收益。从架构上看，这意味着质量管控不能停留在"入库校验"这一道关口，而需要在数据被AI消费的每一个环节都建立质量门禁。
语义层的标准断裂。 同一个业务实体在不同系统中用不同的编码规则和取值口径，这不是新问题。但在大模型场景下，模型会混合不同口径的数据生成分析结果——"华东区销售额"这个看似简单的查询，背后可能同时取用了ERP、CRM和手工报表的数据，三者的口径差异在自然语言交互中完全不可见。这暴露了传统数据架构中的一个关键缺陷：数据标准被设计为"给人看的文档"，而非"给机器理解的语义映射层"。
元数据层的链路断裂。 当缺乏系统化的元数据管理时，追溯一个模型输出偏差的来源从分钟级延长到天级。治理团队不知道模型在回答"客户满意度趋势"时到底关联了哪几张表、取了哪些字段——训练数据变成了黑箱，模型输出的可信度随之坍塌。这在架构上的本质是：数据血缘链路在AI消费端是断开的，元数据没有成为AI推理链路的一部分。
二、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消费的数据达到可信基线
- 消费层： AI可调用的元数据API、语义检索接口和智能体推理引擎，让治理能力在数据被使用的每一刻实时生效
这四层不是独立的功能模块，而是层层依赖、协同运转的整体——下层为上层提供基础能力，上层消费下层产出并在使用中反向驱动下层优化。
转变三：从人找数据到智能体帮人用数据——交互层的重构。
今天大多数企业里，用数据做分析仍然是一件有门槛的事。一个典型的路径是：业务人员提出需求→IT部门排期→技术人员写查询→结果不对→再沟通→再等排期。这个循环走下来，一个简单的"本月各区域销售对比"，从需求提出到拿到结果，常常以天甚至周为单位。
AI用数智能体正在把这个路径压缩成——自然语言提问→AI理解意图→自动定位数据→生成分析结果。它的核心不是"把SQL翻译成自然语言"这么简单，而是在治理到位的前提下，让元数据、数据标准和质量规则共同构成一个AI可理解的数据语义层。当"客户回款数据在哪个表里、口径是什么"这样的问题可以在几秒内得到准确回答时，用数能力才有可能像收发邮件一样成为企业的标配。
四、一个已经落地的架构样本
以上三个转变不是理论推演。江苏某国企数科运营着一个数据要素流通平台，汇聚了大量公共数据与市场化数据资源。平台建成后，运营团队发现了一个尴尬的局面：数据确实"有了"，但用户用不起来。
问题集中在三个断层上。找数难——平台资源丰富，但用户检索依赖关键词匹配，缺乏智能引导，往往多次筛选才能定位所需数据。用数难——平台功能全面、流程规范，但用户对数据申请流程和资源分布缺乏清晰认知，尤其是新用户容易产生困惑。运营难——平台缺乏有效的反馈与需求沉淀机制，用户在使用过程中的问题和需求难以系统收集，导致数据产品迭代缺乏依据。
项目团队为这个平台构建了"感知-匹配-演进"三位一体的AI用数智能体。不是做一个独立于平台之外的聊天机器人，而是将智能体深度嵌入数据中台的治理成果之上——知识库体系梳理了资源目录、数据产品和使用流程，需求感知引擎通过分析用户的搜索失败记录和浏览中断点自动识别潜在需求，智能匹配引擎基于语义检索理解用户意图并主动推荐数据产品。
效果超出了团队预期。基础咨询工单量显著下降，用户检索耗时大幅缩短，首次申请成功率明显提升。更重要的是运营模式的改变——智能体定期生成需求洞察报告，运营团队据此召开数据产品决策会，数据产品迭代周期明显缩短。用客户原话说："以前推数据产品像蒙着眼睛打靶，智能体给了我们一杆瞄准镜。"
这个案例的架构价值在于它验证了一个完整的逻辑闭环：治理到位的数据底座→AI理解数据的能力→用户用数门槛降低→用数行为增加→需求反馈→持续优化治理。治理和AI不是先后关系，而是相互驱动的飞轮。
五、给架构师的建议
基于上述趋势和落地验证，有三个方向值得架构师关注。
在AI项目启动前，建立最小可用治理层。 不需要做到面面俱到——至少让AI知道有哪些数据、在哪里、字段的含义是什么。覆盖核心业务域的数据标准和元数据管理，是决定模型从"能跑"到"可信"的关键一步。在架构设计中，建议将元数据API作为AI数据管线的必选组件，而非可选项。
治理能力要嵌入AI管线，而不是独立运作。 不要分两个团队、两本预算。架构上建议设计一个治理反馈回路："用"环节暴露的数据问题应该能够自动反馈到"管"环节——跨表关联失败说明主数据标准有缺口，模型输出波动说明质量规则需要更新。治理的反馈回路越短，AI的准确率爬升越快。
评估治理平台时，把"AI原生性"作为架构评审的核心维度之一。 除了功能完整度和架构兼容性之外，还需要考察：元数据是否为机器可读的结构化格式？数据标准是否可以被下游AI系统调用？质量规则能否在数据被AI使用前自动触发？这些问题目前不是选型标准中的常见条目，但它们会越来越重要。一个好的AI原生治理平台，应当在架构上将元数据、数据标准和质量管控作为AI用数智能体的基础能力层——治理不是在事后补救，而是在数据流转中实时生效。
六、常见问题
Q：已经在用大模型了，还能回头补治理吗？
可以。先对核心数据域做质量评估，增量治理规则逐步建立，存量按优先级分批推进。治理不是一次性的"大扫除"，而是持续的运营过程，任何时候开始都不晚。
Q：大模型项目要不要等治理做完再启动？
不需要。两者可以并行推进，但建议模型面向业务用户之前至少完成核心数据域的标准统一和质量基线。大模型可以先在封闭的、数据质量已知的小范围场景中跑通，再逐步扩大范围。
Q：AI原生治理平台和传统治理平台在架构上的核心区别是什么？
不是功能多少的差异，是架构逻辑的根本不同。传统平台把治理当作独立的功能模块——元数据管理、数据质量管理、标准管理各自独立运行。AI原生平台把治理能力内化为AI用数基础设施——元数据是AI理解数据含义的语义层，数据标准是AI跨表关联的翻译层，质量规则是AI输出可信度的实时保障。前者是"有一套治理功能"，后者是"治理能力在每次数据被使用时自动生效"。架构上最关键的差异在于：传统平台的治理模块是面向人的（给人看的目录、给人读的报告），AI原生平台的治理模块必须同时面向机器（结构化API输出、事件驱动的质量触发、可被程序化消费的数据标准）。
企业AI建设的瓶颈正在从模型能力转向数据能力。治理平台如果继续按照"管控工具"的定位演进，它和大模型之间的关系会越来越像两条各自发展的平行线。而当治理平台把自己定位为AI基础设施的一部分时，数据和智能之间那条曾经模糊的边界，才会真正开始消融。
