AI CoE应该做什么，不应该做什么

AI转型早期建立Center of Excellence很自然。专家稀缺、风险高、工具混乱，企业需要集中力量。问题通常发生在第二阶段：所有业务Use Case继续排队找CoE，中央团队越来越大，也越来越慢。一个成熟的AI CoE需要主动改变自己的职责。

做平台，不做所有项目

模型接入、Agent框架、Evaluation、身份权限和通用工具具有明显复用价值。CoE应该尽量把它们平台化。业务团队使用标准能力后，可以更快推进自己的场景。如果中央团队长期亲自交付每个Use Case，规模化很快遇到人力瓶颈。

做治理框架，不做审批工厂

CoE可以定义风险等级、数据边界、安全和合规标准。低风险场景按既定规则快速试验，高风险进入更严格Review。治理尽量嵌入平台。逐项人工审批只适合早期。

做复杂能力，不抢业务Owner

高难度Agent架构、Evaluation和模型风险适合中央专家承担。场景价值、工作流和业务结果应该由业务团队拥有。谁离客户和流程最近，谁更适合定义需求。

做Enablement，让能力向外扩散

CoE的重要产出还包括人才。识别L3/L4成员，组织实践社区，沉淀案例和失败，让业务团队逐渐具备自主能力。中央团队的成功，不应该表现为所有事情都离不开它。

提前定义退出条件

哪些能力成熟后交给平台团队？哪些场景类型可以完全下放？CoE规模何时应该稳定甚至缩小？这些问题最好从一开始就讨论。最健康的CoE往往会逐渐“失去一些工作”。基础能力进入平台，业务能力进入各部门，中央团队专注更前沿、更共性的难题。

CoE应该用什么指标评价自己

如果用“完成多少AI项目”评价，中央团队自然会把项目留在手里。更合理的指标包括平台复用率、业务团队自助率、高风险问题处理质量、能力覆盖和组织学习速度。这些指标鼓励CoE把能力扩散出去。指标设计会直接决定中央团队最终成为赋能平台，还是新的交付瓶颈。

CoE也要管理自己的能力更新

中央团队很容易因为服务内部需求太多，反而没有时间跟踪前沿技术。可以明确保留一部分容量做研究、实验和平台升级。否则，CoE两年后可能变成维护旧AI方案的交付中心。中央能力存在的理由之一，就是帮助组织持续看见下一波变化。这并不代表CoE被削弱。

它说明组织已经长出了自己的AI能力。

CoE应交付“组织乘数”，而非项目数量

中央团队最有价值的工作，是让其他团队更快、更安全地完成下一次实践。一个统一模型网关、一套可复用评估框架、清楚的风险分级、一个经过验证的工作流模式，可能比亲自交付十个场景产生更大长期价值。衡量CoE时，应看复用率、业务自主完成比例、从想法到受控试验的时间和重复问题下降，而非只看上线数。

这也意味着CoE必须敢于拒绝高度定制、缺少业务Owner的项目。若中央团队为了证明价值接下所有需求，短期看很忙，长期会形成排队与依赖。项目服务可以保留在少数高复杂、强复用或高风险场景，用于发现平台与方法上的共性缺口。

平台、方法与前沿能力需要不同产品思维

平台面向开发和业务团队，要求稳定接口、成本透明、可观察与服务等级；方法面向工作流Owner，要求任务拆解、价值假设、Evaluation和变革工具；前沿能力面向未来机会与风险，允许更高不确定性，却要有清楚学习目标。

三类工作如果混在同一队列里，紧急项目会挤压平台建设，平台维护又会挤压前沿探索。CoE可以为每类能力设置Owner和容量边界，以季度组合评审决定投入。中央团队自身也需要经营系统。

联邦网络比中央专家名单更能扩散能力

业务中的L3/L4成员应与CoE形成实践网络。中央提供共通评估、平台、跨域风险和培养机制；领域成员维护真实样例、业务规则与异常；平台团队把高频判断自动化。双方通过案例评审和版本更新持续交换知识。这套网络需要正式时间和责任。若领域专家只能业余参与，实践社区很快退化成分享会。CoE应与业务负责人约定成员投入、交付与发展回报，让扩散能力进入岗位和绩效。

CoE从成立第一天就需要退出路线

退出不等于解散所有中央能力，而是把临时职责转移到稳定组织。业务价值归业务Owner，人才与岗位进入HR和管理系统，模型与数据进入平台，风险控制进入正式治理，CoE保留前沿探索和少量跨域标准。每半年可以做一次依赖测试：暂停中央团队的主动催办，观察哪些机制停止；统计业务能够自主完成的试验比例；检查平台与规则能否脱离原项目成员运行。依赖下降，才说明CoE在创造组织能力。

一个CoE从项目工厂转向能力平台的路径

第一阶段，CoE亲自参与三到五条代表性价值流，目的是识别共通需求：模型接入、数据权限、评估、监控、工作流设计和人才判断。每做完一个项目，都要回答哪些工作可以沉淀为共享能力，哪些必须由领域保留。第二阶段，把通用部分产品化，业务团队共同交付；第三阶段，业务在护栏内自主，CoE只处理前沿和高复杂问题。

转型期间要管理服务预期。CoE可以发布清楚的“服务菜单”：哪些平台能力自助，哪些方法有模板和辅导，哪些高风险事项进入咨询，哪些定制交付不接。透明边界比不断扩大团队更能减少排队和冲突。

CoE的季度看板应包含能力外溢

除了系统可用性和风险事件，可以追踪业务自主完成的实验比例、标准组件复用、从申请到试验的周期、人工审批占比、领域L3/L4覆盖、重复故障与Stop List。前沿探索则看解决了哪些关键未知，是否成功转交。

若项目数上升，自主比例下降，说明中央依赖加重；若平台复用高、业务结果仍不清楚，说明业务Owner或价值方法不足；若治理事件少却审批时间持续增长，可能是组织用慢速掩盖风险。指标必须能够揭示CoE自身的失效模式。

什么职责不适合过早下放

当领域团队缺少评估能力、共享平台尚不稳定或高影响风险边界仍在探索时，中央可以暂时承担更多工作。下放速度应随证据，而非出于减少CoE成本。关键是把临时集中写明退出条件，并在执行中培养接收方，否则“暂时”会永久化。

CoE需要自己的产品发现机制

共享平台不能只根据最大声的项目需求建设。CoE应观察多个场景的重复摩擦：相同数据权限、相同评估、相同日志缺口或相同人工Review。只有跨场景重复出现、能够显著降低下一次成本的需求，才适合进入平台路线。

平台团队还要验证业务是否真正采用。组件发布量不代表复用，模板下载不代表工作改变。可以跟踪首次使用时间、成功完成率、支持请求、绕过行为和对端到端交付的影响。CoE也需要像产品团队一样管理用户和Outcome。

与外部伙伴合作时，内部能力仍要留下

供应商可以加速模型、平台和场景建设，却不能替企业拥有业务标准、风险容忍度和最终责任。合同和交付设计应要求知识、评估、运行文档和关键决策可迁移，内部人员参与真实判断，避免项目结束后只剩一个黑箱服务。外部专家最有价值的贡献是帮助组织缩短学习曲线。若每次升级都必须重新购买同样的解释和配置，CoE没有形成自己的能力资产。

CoE负责维护共同语言

Value Hypothesis、Human Gate、Evaluation、Context、Override和Scale Gate等概念若在各团队含义不同，复用会迅速失效。CoE可以维护少量、稳定、可操作的定义和模板，让跨部门讨论对齐，同时允许领域增加细节。共同语言是联邦组织中低成本协调的重要基础。

CoE的负责人需要定期检查团队时间结构：多少投入在重复支持、平台产品、领域赋能、治理更新和前沿探索。若重复支持长期占满容量，应优先修复自助体验、文档或产品接口；若前沿研究很多却无人接收，要收紧业务连接。时间结构比组织名称更能说明CoE实际扮演的角色。

从观点到管理动作

成熟CoE的存在感可能下降，影响力却上升：业务更少排队，平台承载更多重复能力，领域Judge能够本地决策，中央专家集中处理真正新的问题。这种“被依赖得更少”，恰恰是赋能组织最有说服力的结果。

延伸依据：NIST AI Risk Management Framework、NIST AI Metrology Center、OECD AI-WIPS