什么应该中央化，什么应该业务自治

AI规模化很快会遇到一个Operating Model问题。全部中央统一，业务觉得慢。全部分散，各部门重复建设，安全和数据问题增加。中央化与自治需要按对象拆开，选择极端通常会损失速度或一致性。

基础设施适合中央化

模型网关、身份、数据平台、监控、成本管理和基础Agent框架有明显规模经济。统一建设可以降低重复成本，也提高安全性。业务团队不应该每次从底层重新搭建。

高风险规则需要一致

隐私、安全、法律、审计和模型风险标准必须保持一致。业务可以在护栏内快速创新，但不能自行改变红线。这部分通常需要中央治理。

场景和Workflow应该业务自治

业务团队最了解客户、流程和结果。他们应该有权决定哪里值得用AI，怎样重新设计工作，怎样衡量价值。中央团队提供方法和能力，不代替业务Owner。

能力与实践适合联邦化

AI人才分布在各团队。通过实践社区、共享组件、Champion和专家网络连接起来，可以同时保持速度和学习。这是一种联邦结构。

边界会随成熟度变化

早期专家少，更多事情可以集中。业务能力提高后，职责逐步下放。新的高风险技术出现时，部分能力又可能重新集中。AI Operating Model需要定期重审。

Centralize/Federate可以按四个问题判断

这项能力是否有显著规模经济？错误是否会造成企业级外溢风险？业务Context是否高度本地化？决策是否需要快速靠近一线？四个问题可以帮助团队逐项决定，减少围绕组织理念的抽象争论。同一个领域也可能分层：底层模型平台中央化，业务Prompt与Workflow自治，高风险Evaluation共享。

组织边界最好形成明确RACI或Decision Rights

很多中央与业务冲突来自“大家都以为自己负责”。对于模型选择、数据、Workflow、Evaluation、业务结果和风险批准，可以明确谁Responsible、谁Accountable、谁Consulted。形式不重要。重要的是不同团队对权力和责任有同一理解。

这会减少大量规模化阶段的组织摩擦。好的组织设计不会消灭中央与自治之间的张力。它只是让需要一致的地方保持一致，需要速度的地方获得足够空间。

判断边界要看四种组织经济性

第一是规模经济：统一建设能否显著降低重复成本。第二是风险外溢：一个团队的错误是否会影响客户、品牌、监管或其他业务。第三是Context依赖：高质量决定是否需要贴近本地流程与客户。第四是变化速度：中央协调是否会错过业务窗口。

模型网关、身份、日志和成本管理通常具有规模经济；隐私、安全和高影响责任具有风险外溢；场景价值、流程设计和领域评估高度依赖Context；探索方式需要较快反馈。把对象逐项放入这四个问题，比争论“中央好还是分散好”更有操作性。

统一标准不等于统一实现

企业可以统一最低控制与接口，同时允许业务采用不同实现。例如所有高影响场景都必须具备证据记录、人工接管和事件升级，但具体评估案例由领域团队维护；所有Agent都通过统一身份和日志，具体工作流由业务设计。

这种“标准中央化、实现自治”需要机器可执行的护栏。数据分类、权限、成本额度、模型清单和最低评估可以嵌入平台，低风险团队无需等待委员会。中央治理由逐项批准转向设计规则、监测例外和更新底线。

自治必须和能力成熟度绑定

同样的权限不必一次给所有团队。自治范围可以根据领域风险、Owner投入、评估能力、运行记录和异常处理成熟度逐步扩大。新团队先在只读、低影响和受控数据中试验；形成稳定证据后，再获得更多模型、数据和行动权限。成熟度机制也要允许收回权限。若团队长期不维护评估、重大异常未及时处理或Owner缺位，自治边界应缩小。这样，自治成为以证据换取的责任空间，而非一项永久组织身份。

冲突需要一个可升级的决策机制

中央团队关注一致性与外溢风险，业务团队关注速度与客户价值，两者冲突很正常。企业应预先说明谁对哪类决定拥有最终权、需要什么证据、多久必须答复，以及无法达成一致时由谁裁决。Decision Rights比泛泛的“加强协同”更能减少摩擦。

可以把决定分成平台标准、业务流程、风险例外、跨域复用和投资优先级。每类决定只有一个Accountable Owner，其他角色提供专业输入。重大例外留下期限和复核条件，避免临时批准逐渐变成永久漏洞。

用客户服务场景划一次边界

企业可以中央建设模型网关、身份、日志、成本和通用知识检索，统一隐私、客户权益和高影响承诺的底线。各业务线则根据产品、语言和服务流程设计具体助手，维护领域评估，决定哪些问题适合自动建议、哪些必须升级，并对解决率与客户结果负责。

若某业务线希望Agent自动发放补偿，Decision Rights应进一步细化：中央规定金额、审计与禁止条件，业务定义客户分层和流程，超过阈值进入经理批准，所有动作通过统一日志。这样既避免每个团队重建安全底座，也避免中央不了解客户Context却代替业务设计细节。

一个边界冲突如何裁决

业务希望快速接入新模型，平台担心稳定与成本，风险团队关注数据流向。裁决不应无限开会，而要基于预先协议：业务提交价值假设和评估结果，平台在约定时限内验证接口与运行，风险按数据和影响分级；若只用于低风险内部草稿，可以受限试验，若涉及客户决定则提高门槛。

重大例外写明范围、批准人、到期日和退出条件。到期后根据真实证据转为正式标准、延长或终止。例外管理的质量，决定联邦结构能否同时保持速度与一致性。

避免“名义自治、实际无能力”

把场景责任交给业务，却不提供平台、人才、预算和升级路径，只会让自治变成责任下放。每次扩大自治前要检查：是否有业务Owner、领域Judge、可用评估、稳定平台和真实运行反馈。缺口由中央与业务共同补齐。反过来，中央提供全套能力却保留所有批准，也会让业务无法成长。成熟边界应让团队用能力和记录换取更大空间，并允许在质量下降时暂时收回。

数据与Context往往需要双重治理

中央团队适合定义数据分类、身份、访问协议、保留与审计，领域团队更了解哪些信息足以支持判断、何时过期、什么语义容易误用。只做中央数据治理，可能安全却缺少可用Context；只靠业务整理，又容易出现权限和一致性风险。

可以由中央提供可信数据接口和技术控制，领域Owner维护业务含义、质量阈值和更新责任。Evaluation记录某类错误是否来自Context，反过来推动数据和知识改进。Context因此成为中央与业务共同拥有的生产资产。

成本管理也应中央可见、业务可负责

统一网关能够看见模型调用、供应商和基础设施成本，业务Owner则需要理解每项成本对应什么价值流。中央只设总额度，会让高价值探索和低价值使用一起受限；完全由业务采购，又会失去规模议价和风险控制。较好的做法是中央提供透明单价、预算护栏和异常预警，业务对单位结果与使用选择负责。成本变化进入模型路由和场景组合决策，避免AI账单增长后才开始寻找Owner。

边界调整需要变更管理

从中央交付转向业务自治，会改变岗位、权力和支持关系。接收团队需要实践机会、服务协议和失败后的升级路径；中央人员也要从“替别人做”转向“设计平台和方法”。若只宣布新RACI，旧行为不会自动改变。边界迁移应通过共同运行、能力证据和逐步退出完成。

企业可以每半年做一次边界审计：哪些中央服务形成排队，哪些业务重复建设，哪些风险例外过多，哪些团队的自治记录足以扩大范围。审计结果直接调整Decision Rights、平台路线和能力投资。边界由此成为可经营的设计变量，而非组织重组时才讨论一次的问题。

从观点到管理动作

中央与业务的边界不应写成一张永不变化的组织图。它更像一组持续校准的决策协议：共享能力集中建设，领域价值贴近业务，风险底线保持一致，自治范围用证据获得。这样的结构既保护规模，也保护学习速度。

延伸依据：NIST AI RMF Core、NIST Generative AI Profile、OECD AI-WIPS