当 AI 卓越中心成为瓶颈时

两年前，组建 AI 卓越中心（CoE）是一项负责任的举措。当时没人知道如何评估模型，采购部门不清楚推理合同该是什么样，而法律部门则希望有一个明确的责任方。将那十个懂行的人集中到一个中心团队显然是正确的做法。

如今，正是这个团队导致你的产品工程师为了修改一个 Prompt 要等上六周。CoE 审查每一次系统消息（system-message）的修改，掌握着公司唯一的评估框架，并由一个每两周开一次会的委员会来把持模型升级。团队已经察觉到了这一点。他们开始使用个人 API 密钥发布产品，在 CoE 永远看不到的 Notebook 中运行评估，并将客户数据粘贴到任何响应最快的工具中。你并没有防止影子 AI —— 而是你创造了它，并给了它一个需要躲避的治理机构。

令人不安的是，没有人犯错。CoE 是启动阶段的正确结构，但在现在则是错误的结构。组织架构图和代码库一样具有生命周期，这里的失败模式在于将脚手架误认为架构 —— 让临时结构存在时间过长，以至于人们开始在上面搭建承重墙。

引导逻辑及其失效点

集中化的 CoE 解决了一个特定问题：专家稀缺且风险定价不明。在企业采用 AI 的第一年，这两个条件都成立。只有少数人知道幻觉驱动的事故是什么样的；没有人拥有评估流水线；每份供应商合同都是第一次谈判。集中这些知识意味着每个团队的首个 AI 项目都能基于组织的最佳认知而非从零开始。

但这两个条件都会消退。专家不再稀缺 —— 经过两年的交付，你的产品团队中已经有了调试过检索故障并编写过评估套件的工程师，其中一些人甚至比那些一直在审查文档而非交付产品的 CoE 成员更擅长此道。风险不再是定价不明的 —— 组织已经有了事故记录、既定的供应商条款和法律先例。支持集权化的输入因素悄然消失，而结构却依然存在。

剩下的只有排队。集中审查随人头数线性扩展，而需求则随着公司内每个团队都采用 AI 而增长，因此差距每季度都在扩大。对 AI CoE 失败的行业分析一致指向了三个特征：不断累积的审批延迟、各业务部门构建绕行系统，以及中心团队陷入知识过载。如果你的 CoE 申请表里有一个“优先级理由”字段，说明你正在实行配额制 —— 而对竞争对手视为日常环境的能力实行配额制，是一个战略问题，而非流程细节。

影子 AI 是组织绕过损害的路径

网络隐喻非常精准。到 2025 年的调查显示，未经授权的 AI 使用比例在员工中占到一半到五分之四之间 —— 一项大型研究发现，81% 的员工和 88% 的安全主管在使用未经批准的工具，而高管是最严重的违规者，并非例外。成本也不是假设性的：违规分析现在将大约五分之一的事件归咎于影子 AI，其成本明显高于普通违规，因为数据流在出故障前一直是不可见的。

这是 CoE 领导者所抵制的：这种使用并非反抗，而是需求。每一次未经授权的 ChatGPT 会话都是一个信号，表明某个工作流需要 AI，而核准的路径太慢、太受限或太隐蔽。为期六周的审查队列并不能降低 AI 风险。它只是将风险从你可以观察到的渠道转移到了你无法观察到的渠道。关卡变成了一个过滤器，筛选出的恰恰是你最想防止的用法 —— 未经审查、未记录的个人账户行为。

这个悖论值得直白说明：中央关卡越严格，你实际的 AI 使用就越缺乏治理。 被人们绕过的治理不是治理，而是带排队的表演。

是脚手架，而非架构

我们以前做过这种实验。云卓越中心（Cloud CoE）在十年前也经历了同样的轨迹：在迁移过程中不可缺，随后日益变成一个平台团队早已不再需要的审查委员会。那些能够平稳过渡的团队有意将重点从“执行”转向“赋能” —— 他们停止审批部署，开始构建着陆区（landing zones）、策略即代码（policy-as-code）和自助式基础设施。而那些表现糟糕的团队则保留了审批会议，眼睁睁看着工程团队绕过他们。敏捷 CoE、数据科学 CoE、DevOps CoE —— 同样的曲线，同样的岔路口。

教训是：CoE 是一种成熟度阶段的结构，而非永久性的组织单位。它的目的是使自己以原始形式变得不再必要。这种重新定义改变了你配备人员的方式（轮岗，而非终身职业）、衡量它的方式（转化的能力，而非审查的项目），以及你谈论它终结的方式（毕业，而非失败）。

平台工程已经为这一目标准备好了词汇：铺平的道路（paved roads）。你得到的不再是一个审查你部署的团队，而是一条极其平滑的道路，以至于偏离它比遵循它还要费力。受控的路径就是快速的路径 —— 在带有内置日志记录的网关后的核准模型、作为任何团队都可以在 CI 中运行的共享基础设施评估框架、作为自动化策略检查而非委员会议程项的 Prompt 修改审查。自助服务取代了工单队列；策略即代码取代了人工把守。合规性成为平台的属性，而非会议的结果。

该解散卓越中心（CoE）的信号

你不需要顾问来告诉你卓越中心（CoE）何时从加速器变成了瓶颈。这些信号是可以衡量的：

• 队列长度呈上升趋势。 如果平均审批时间逐季增长，而 CoE 的吞吐量却保持不变，数学上的结果只有一个。
• 例外率。 计算领导层授权了多少次“就这一次”的绕过。每一次例外都是在承认，该流程无法平衡组织实际的风险与速度。当例外变成常规时，流程其实已经名存实亡——只是你还没把它埋了。
• 标准滞后。 当 CoE 的核准模式文档推荐的是你的团队两季前就已经放弃的技术时——例如上一代模型的提示词模式，或是无法覆盖 Agent 的评估（evals）——这个中心就不再是卓越的所在地了。
• 影子用量增长。 如果你的 CASB 或网络日志显示，未经授权的 AI 流量正在增长，而官方的受理单据却在萎缩，那么组织已经投过票了。
• 人才流动。 当你最优秀的 CoE 工程师转岗到产品团队去“真正交付”时，他们是在告诉你有趣的问题都流向了哪里。

以上任何两项同时出现，都意味着关于解散的讨论早已逾期。如果五项全中，说明团队已经自行解散了 CoE；只是组织架构图还没更新而已。

哪些职能需要永久保持中心化

解散作为“守门人”的 CoE 并不意味着将一切去中心化——而这正是那些盲目跟风的人容易犯错的地方。麦肯锡 2025 年的 AI 现状研究发现，高绩效者在进行激进、分布式的 AI 采用时，会配合中心化的治理、人工参与的规则以及明确的高管责任制。解决这一表面矛盾的方法是：底层中心化，决策分布式。

有三件事值得永久保持中心化：

• 供应商话语权。 模型合同、价格谈判和容量承诺都能从聚合中受益。二十个团队分别与同一个模型供应商谈判简直是在烧钱，而中心化网关也是用量可见性的所在地。
• 事件学习。 当一个业务单元发生 AI 故障时，教训必须传达到所有部门。事件回顾、红队发现以及对实际错误原因的分类是天然的垄断性职能——分布式团队没有动力分享失败，反而有充分的理由掩盖失败。
• 评估底层架构。 并不是评估（evals）本身——团队应该负责各自领域的评估——而是测试框架（harness）、共享基准以及回归测试基础设施。这些设施能确保“我们已经评估过”在公司的每个角落都代表着相同的含义。这是 AI 领域的构建系统（build system）：没有人想在本地维护它，但每个人都希望它是卓越的。

注意清单中缺少的内容：用例审批、提示词审查、单个产品的模型选择。这些决策权属于对结果负责的团队，他们在平台提供的“铺平之路”上运行。

在第一天就规划好解散

这一切的执行方案取决于你所处的位置。如果你现在正在组建 CoE，请在章程中写明它的落幕标准：“当 N 个团队交付了 AI 功能且评估框架实现自助化时，该团队将转变为平台职能。”一个拥有明确“毕业条件”的 CoE，其行为方式与一个为了保住永久预算而存在的 CoE 完全不同——它会构建工具而不是流程，因为只有工具能在转型中存续下来。

如果你正在运行一个信号显示已经到期的 CoE，你的行动应该是转型而非删除。审查职能转变为共享网关上的“策略即代码”（policy-as-code）。专家职能转变为嵌入式轮岗——CoE 工程师在产品团队中度过两个季度，而且大多不再回来，这正是关键所在。治理职能缩减为三个永久性的中心职能：供应商、事件和评估。人力通常不会缩减；只是从阅读文档重新部署到修筑道路上。

如果你所在的业务团队目前正在绕过 CoE：你用个人 API 密钥构建的“影子工具”是证据，而不是耻辱。把它带到关于解散的讨论中。修筑“铺平之路”最快的方法，就是展示大家已经在走的“捷径（desire path）”。

能够正确处理这一问题的组织，既不是那些从未建立过 CoE 的组织，也不是那些永远保留 CoE 的组织。他们是那些知道脚手架（scaffolding）与架构（architecture）之间区别的组织——并且在脚手架仍是成功标志时就将其拆除，而不是任由其成为采用停滞时刻的纪念碑。