Agent 治理要赶在扩规模之前：推荐错了能不采纳，执行错了已经发生

Deloitte 的 2026 State of AI in the Enterprise（副标题 The Untapped Edge）里，有两条曲线正在分叉：今天有 23% 的企业至少在中度使用 agentic AI，两年内这个数字预计冲到 74%；而现在就说自己「已有成熟的自主 Agent 治理模型」的，只有 21%。报告给这一节起的标题很直白——AI agents are scaling faster than the guardrails，Agent 的扩张跑在了护栏前面。

「要重视治理」是几乎所有行业报告的标准结尾，读者点头，然后什么也不会做。这份报告值得抠的不是这句结论，而是它顺手回答了两个更硬的问题：为什么 Agent 的治理不能沿用现有那一套，以及「成熟」到底指哪几件具体的事。

人审核那道闸，从流程里消失了

报告第 20 页有一句话，是整件事的承重墙：与提供建议供人采纳的传统 AI 系统不同，Agent 直接采取行动——下单、发出通信、修改系统。

差别不在能力强弱，在止损点的位置。一个推荐型的 AI 给出错误结论，链条是「模型出错 → 人看到 → 人决定不采纳 → 没有后果」；人审核这一步天然是一道闸，哪怕流程里没人明确设计过它，它也在那儿。Agent 的链条是「模型出错 → 直接执行 → 后果已经产生 → 人事后才知道」。同样的错误率，一边是虚惊一场，一边是已经发生的事实。

所以要变的不是治理力度，而是治理的位置：从事后审阅产出，前移到事前定义边界、事中实时监控、事后可完整追溯。这三段都得有人设计，因为再没有一个默认的人工环节替你兜底了。

报告说的「成熟」，是四件可以逐条检查的事

Deloitte 没有给出一张量化评分表，但把成熟治理必须具备的能力写得相当具体——反过来说，约 80% 的受访企业目前并不具备这样的成熟治理能力：

1. 清晰边界：明确定义哪些决策 Agent 可以独立做，哪些必须经过人工批准。
2. 实时监控：跟踪 Agent 行为，对异常发出标记。
3. 完整审计轨迹：捕获 Agent 全部行动链，用于问责，也用于持续改进。
4. 跨职能结构：IT、法务、合规与业务单元负责人共同制定政策、监控绩效、处理升级。

这四条的价值在于可判定：它们不是「加强管控」这种没法验收的说法，而是能对着一条条问「我们有没有」。第四条尤其容易被跳过——它不是系统功能，落不到某个工单上。但报告在建议章节里点明了后果：高层领导亲自参与塑造 AI 治理的企业，取得的业务价值显著高于把这件事全权委托给技术团队的企业。边界该划在哪里，本质上是业务和法务的判断，技术团队独自定不了，也不该由它独自背。

这个 21%，还得再打个折

这里必须说清口径：21% 是受访者的自我评估，不是第三方审计的结果。 Deloitte 调查了 24 国 3235 名总监到 C 级的 IT 与业务领导者（2025 年 8–9 月，IT 与业务大致各半），采集的是这些人对自己组织的判断，报告没有对其中任何一家的实际治理水平做独立核验。

同一份报告里还有一组数字可以拿来当参照：42% 的企业认为自己的战略高度就绪，30% 认为自己在风险与治理上高度就绪。当「成熟」「就绪」的判定权在受访者自己手里，答案通常偏乐观。合理的读法是：21% 更像上限，而不是下限。

反过来，另一组数字更能说明手上答案有多少——企业最担心的 AI 风险几乎全部落在治理相关的项目上：数据隐私与安全 73%、法律与知识产权及监管合规 50%、治理能力与监督 46%、模型质量与一致性及可解释性 46%。担心得越集中，越说明这些问题还没有被解决。

但治理也不是把审批链加长

如果读到这里的结论是「那就先把流程管起来，所有 Agent 动作都走审批」，那是走到了另一个极端，报告本身也不支持这个做法。它在建议章节里划了三条边界，值得原样记住：

• 治理要接进已有的风险与监督结构，而不是另起一套平行的「影子」职能；
• 目标不是增加官僚流程，而是形成清晰、可调整的护栏，让团队能在速度中稳妥推进；
• 治理要在风险管理和创新之间校准，让监督使实验成为可能，而不是把实验按住。

报告观察到跑得最好的企业采取的是「有节制」的路径：从低风险场景起步，边扩张边把治理能力建起来，而不是先大规模铺开再回头补，也不是等治理体系齐备了才允许上线。这两种极端都会输——前者是风险敞口，后者是永远停在试点。

由此可以得到一个比「有没有治理」更好用的判断标准：你的治理设计，是让团队更敢把 Agent 放上生产，还是更不敢？ 如果答案是后者，那多半不是治理做得太多，而是做错了位置——用审批链去补的，本该是边界定义和审计轨迹的活。

从哪里开始

多数团队眼下的真实状态是：Agent 已经在跑了，但「哪些它能自己做、哪些必须人点头」这句话从来没有被写下来过——散落在几个开发同学各自的判断里，谁也没觉得这是个需要拍板的决定。检验方法很简单：把这个问题抛给团队，如果十分钟内给不出一份能让法务和业务都点头的清单，那就是还没有边界。

顺序建议是先易后难、先硬后软：先把边界写下来（一张两列的表就够：可自主执行的动作 / 必须人工批准的动作），再补审计轨迹（出事能还原，是所有事后动作的前提），然后是实时监控，最后把法务与业务正式拉进这个机制。前两步的成本远低于大多数人的预期，却能把「不敢放上生产」这件事解决掉一大半。

这正是白泽明理服务阶梯第一层要解决的问题——先把 AI 稳定、可控、可审计地接进来，再谈把它变成工程能力、变成产品。顺序反过来，扩张速度只会变成风险的放大器。