你的 AI 治理早已失效，只是你还没察觉到。
系统通过了审查，边界清晰，上报路径有文档记录，所有人都认同这些规则。
然而六个月后，没有人记得那条线当初划在哪里。
这不是治理设计的失败，而是治理维护的失败。它也是那些开局良好、结局糟糕的 AI 系统最常见的原因之一。
治理漂移是指那些让 AI 系统在安全且符合预期的边界内运行的约束，被逐渐、几乎不可察觉地侵蚀。它的发生不是因为有人做出了糟糕的决定，而是因为没有人回头审视几个月前做出的决定——那时情境不同、压力更小、系统也还是全新的。
漂移是如何发生的
治理漂移遵循一种可预见的模式。它始于系统全新、组织谨慎的时期：阈值保守、上报路径被小心翼翼地遵循、每个异常都经过审查。治理结构之所以严密，是因为系统尚未证明自己。
随后警惕逐渐放松——不是有意识的，而是渐进式的。一个原本需要人工审阅的阈值开始被绕过，因为过去五十次输出都是正确的。上报路径沦为走过场，因为审阅者反正一直都是在批准一切。为某种特定故障模式设置的约束看起来不再必要，因为那种故障模式已经好几个月没有出现了。
每一次放松单独看来都合情合理，没有哪一次变更让人感觉像违规。但实际约束与预期约束之间的差距在扩大，原本的治理框架所要预防的故障模式变得越来越可能发生。当故障最终发生时，事后复盘会揭示：护栏是被一块一块地拆掉的，由理智的人在理智的压力下为之，却没有任何一个可以指认的决定性时刻。
治理漂移不会产生随机故障。它会在可预见的模式中产生可预见的故障——就在边缘处，也就是原本约束最至关重要的地方。
漂移的三大驱动因素
治理漂移由三股相互叠加的力量驱动：
成功偏差。每一次正确的输出都会降低人们对下一次输出风险的感知。久而久之，在试点阶段显得必要的约束开始显得多余。没有人质疑这种成功是否真实，或者条件是否会改变。
归属扩散。设计治理框架的人离开了。新团队成员继承了这些约束，却不理解其背后的理由。缺乏上下文，约束就显得武断。原本的故障模式不再属于集体记忆。
激励错位。运营团队以吞吐量和正常运行时间来考核，而治理约束制造摩擦。在没有明显故障的情况下，运营团队有强烈的动机去削减治理开销。负责让系统持续运行的团队，并不是设计原始约束的那个团队。
行之有效的结构性机制
单靠个人的警惕是不够的。推动漂移的力量太过持续、太过渐进。预防需要结构性的机制。
定期治理审查。框架应当内置一个到期时间——不是针对约束本身，而是针对审查周期。每个季度，组织都明确地重新审视治理约束，并追问原有条件是否仍然成立。一次没有产生任何变更的治理审查，往往是一次不够诚实的审查。
漂移检测。组织应当独立于系统性能来衡量治理约束是否真的在被执行。一个系统可以在治理框架被悄悄拆除的同时仍表现良好。当合规率下降——人工审阅不再进行、上报路径不被遵循、阈值不被遵守——那就是漂移正在发生的信号。
约束可追溯性。每一条约束都应附上理由：它所预防的故障模式、它适用的条件，以及审查的节奏。这能防止团队成员更替时机构记忆的丢失，并且当某条约束在未重新审视其原始理由的情况下被放松时，让漂移变得可见。
成熟的治理是什么样子
在成熟的组织中，治理不是一份在发布时就归档封存的文件。它是在系统整个生命周期中被持续实践、挑战和打磨的活体。边界可见，理由有记录，漂移被度量，归属也清晰。
这些组织的治理并不比别家更严格，而是更审慎。当某条约束变更时，那是因为有人做出了有意识的决定，而不是因为某个流程悄悄萎缩了。当漂移被检测到时，它是在故障发生之前被调查，而非之后。
你的治理框架有多老了？你上次检查它是否仍然完好是什么时候？