关于企业AI，市面上已经吵了太多模型、GPU、向量数据库和智能体框架。这些讨论当然重要。但真正决定企业AI能不能成的变化，发生在模型的下面。

几十年来，元数据的意思就是“文档”。团队建数据目录，是为了让人能找到数据集；治理项目记录定义与归属；血缘关系帮人在出事之后回溯是哪里坏了。

过去，元数据是在描述业务。而AI指望用元数据来跑业务。这中间的落差，比听起来大得多。

AI系统不会继承一位资深分析师脑子里的多年机构知识。它不知道财务口径的“收入”剔除了退货，而销售口径的“收入”把退货算进去；它不知道某个客户ID在三年前一次迁移之后就不可靠了；它也不知道“流失”上个季度被重新定义过。

人是靠时间、通常还靠吃过一次亏才学会这些的。AI则会用它碰巧落到的那套定义直接给答案，背后没有“吃过一次亏”的记忆可依赖。这就是元数据为什么必须从文档变成基础设施。

业务语义，现在也是基础设施

基础设施是那种每个应用都在用、却不会去想的东西：网络、身份、存储。每个应用都默认它存在。现在，“业务语义”也该进这份名单了。

每一个AI应用，都依赖客户、收入、产品、合同、风险这些定义在各系统之间保持稳定。一旦不稳，AI放大这种不一致的速度，会超过任何人工团队。

BI最早把这个问题摆到我们面前。两块仪表盘给出两个不同的数，因为两个工具用两种方式实现了同一个指标。多数组织学会了忍：对账会、表格对决、关于“谁的报表对”的长期争论。

AI把对语义不一致的容忍度打没了。仪表盘上一个错数，屋里总有人能看出来；而智能体照着错数去做，错误会在自动化流程里跑起来，等有人发现已经晚了。

模型是对着它拿到的业务上下文做推理的。上下文是碎的，它就会给出一个“自信的错答案”，而这比明显的错答案更糟。没有受治理的上下文，AI智能体只是一个语速很快、表达很好的猜谜者。

这是架构问题，模型规模再大也改不了。解法是让每个AI系统都从受治理、且在全企业范围内保持一致的业务定义出发去做推理，不管最终是哪个平台在消费这些定义。

语义不一致，BI时代能忍，AI时代不能

企业治理花了20年回答一个问题：谁能访问这份数据？这个问题依然重要。AI又提出了第二个同样重要的问题：这份数据到底是什么意思？

两位分析师权限完全一样，也可能算出两个不同的数，只要他们用两种方式算同一个指标。多数治理平台把定义记录下来就到此为止了，而“强制执行定义”是另一件事，通常没人做。

多数企业走到今天，是把多个元数据工具拼成一个方案：每个症状买一件对的工具，买的时间还各不相同。溯源工具用来复盘哪里坏了，目录用来找数据，治理平台用来定策略，语义层用来撑BI。没有一件是设计在共享地基上的。

每笔采购解决了自己那一小块，也各自留了一份“这些东西是什么意思”的副本。买到第四个工具时，活儿分散在四个地方出钱，没有任何一处真正负责，也没有任何地方在度量效果，而企业还在问当初那个问题。

AI让这个缺口更难忽视。模型会用它最先找到的那套定义，而且不管用哪套，语气都一样自信，对两套定义之间的冲突完全无感。自信是模型的属性，跟它底下压着什么业务逻辑无关。

治理必须越过访问控制，把业务定义和实现这些定义的系统连起来，并挂上归属、版本历史与血缘。词条里的那条定义，和系统里真正执行的那条定义，永远不该漂移开。

当记录在案的定义和应用实际执行的语义不一致时，治理就变成了行政动作，而不是运营能力。AI只是比以往任何技术都更快地把这个缺口暴露出来，让人没法再装看不见。

厂商中立，成了战略选择题

平台层面还有一件事在变。现在每一家主流云厂商都自带某种版本的治理、指标定义或AI上下文能力。这是实打实的进步，企业也该期待这个。

但几乎没有哪家企业活在单一厂商的围墙里。多数企业跑着多个云、一堆遗留应用、若干SaaS工具、几个BI平台，还有来自不止一家供应商的AI服务。每个平台都在为自己的世界做优化。

业务定义必须能穿过所有这些平台。如果每个平台都留一份自己版本的“这些是什么意思”，组织就把同样的碎片化重建了一遍，只不过这次它埋在AI工作流更深处，更难被发现。

厂商中立的元数据架构，解决的是跟任何单一厂商平台都不同的问题。当业务定义能跟着企业走、而不是被关在某个平台里，组织得到的是战略弹性，而不是又一种形式的锁定。

归属权留在企业手里，与最终由哪种技术来消费这些定义无关。这意味着不必每次基础设施一变，就把业务重新定义一遍。

随着AI生态持续变动，握住业务语义的所有权，和握住数据本身的所有权一样重要。

未来五年：MetadataOps，把定义当软件管

元数据管理正在进入第二代。

第一代讲发现：找到数据集、记录谁拥有它、把目录建起来。这是必要的工作，今天多数企业还在做，但已经不够了。

第二代讲执行。元数据将决定AI系统怎么推理、分析平台怎么算指标、治理策略怎么落地，以及组织如何证明机器替它做出的某个决定，来路是什么。

这需要另一种设计：血缘、编目、治理与业务定义，全部取自同一套共享的元数据地基。业务上下文变成一个统一的运营模型，每个消费系统都直接读它。

业务定义也会越来越像软件：纳入版本控制，走开发流水线，上线前做影响面测试——就像代码变更在上线前要测一遍那样。AI智能体、分析平台、数据库和应用，读的都是同一套受治理的定义。

这门手艺有了名字：MetadataOps，还配了一个岗位。MetadataOps工程师负责一条业务定义走到生产环境的全过程，就像平台工程师负责代码走到生产环境那样。这个岗位位于上下文工程（context engineering）的上游：上下文工程决定什么内容能进到智能体的窗口里，而MetadataOps决定先有什么东西存在、可供检索。

企业要把业务语义当作一项工程资产来建设和维护，用跟生产环境里其他东西一样的纪律。真正的突破在这里：企业终于肯把“上下文”这件事，交给他们花了很多年给代码、基础设施和安全的那套工程纪律。

二十年里，元数据是在事后解释企业。下一个十年，要看它能不能在决策做出之前就引导企业。

（本文作者Christian Bremeau，文章属外部贡献者观点。）