企业 AI 应由平台团队、创新中心还是业务部门负责？比较三种组织模式的资金与责任边界

先看结果：问题不是平台、创新中心和业务部门三选一，而是每个决定只能有一个明确归属

岚港设备服务集团有四个事业部：现场服务、备件、租赁和保修。管理层成立12人的AI创新中心，九个月内接收11项计划，从原型、数据整理、模型选择到上线支持全部包办。看板显示11个“试点完成”，但只有3个具名业务结果负责人、2个有生产值班人员、4个有批准的数据负责人；业务以为“AI团队负责”，平台组只承诺模型网关可用，创新中心则认为演示通过就已移交。

保修理赔分流助手C-17把工单摘要、证据缺口和候选队列呈给理赔员，人工确认后才入队。上线第八周，产品编码表从R31升到R32，工作流仍读取旧映射；1,260件观察窗内有73件进入错误内部队列，其中16件错过内部响应时限。没有自动拒赔或对外付款，但团队花11小时才确认谁有权暂停，29小时才完成重放和恢复。

整改不是把创新中心改名为平台团队。原12人中6人转为平台产品团队，提供身份、网关、日志、评估工具和受控发布；4人组成轮转创新中心，只做高不确定性发现、标准和辅导，最长12周必须停止、移交或重新批准；另2人分别限时嵌入首批业务产品队并培养接任者。每个生产应用由业务产品队拥有结果、数据语义、人员流程、运行预算和事故决定。11项计划中4项停止、2项留在发现、5项成为业务产品，合计11。

这是一个虚构教学案例，所有公司、人员、项目、事件、比例、时间、预算和结果均为教学数据，不是组织配置基准或真实厂商案例。本文讨论企业AI 运营模式，不提供劳动、人事、会计、采购、法律或监管意见；团队设置与责任仍须结合组织规模、风险和适用义务由相应负责人批准。

三类团队不是三个备选答案，而是分别经营共同能力、未知问题和业务结果

先区分三种组织对象：平台团队经营共同服务，创新中心降低未知，业务产品队经营一个业务结果

平台团队的客户是内部产品队，交付可自助使用、有明确服务目标的共同能力；创新中心的客户是还不会判断问题或缺技能的团队，交付证据、方法、标准和能力转移；业务产品队的客户是流程参与者和受影响对象，交付可持续的业务结果。三者都可能写代码，却不能因此互相替代。

“负责AI”是无效职责，因为它没有对象、结果或时间边界。平台对网关可用性负责，不对C-17理赔队列准确率负责；业务负责人对最终结果和人工流程负责，不能被要求维护底层模型路由集群；创新中心对发现质量和移交完整负责，却不替接收方永久值班。

每个产物只写一个最终负责人，同时可以有多个执行者。责任矩阵可采用RACI方法，也就是分别标明最终负责、执行、咨询和知情角色；若平台、创新中心和业务都被标为最终负责人，事故时仍要开会决定谁行动；若没有最终负责人，成本与风险就会落在最愿意帮忙的人身上。组织设计的目标不是消除协作，而是让协作发生前就知道谁能作最终决定。

三类章程使用同一页模板，但字段不同：团队目的、客户、所属产物、决策、预算、服务窗口、依赖、入口、退出、禁止性工作和指定 A。季度复核不是问“团队忙不忙”，而是抽查三份真实记录：一个需求为何进入、一次坏结果谁作决定、一项成本由谁承担。模板帮助对齐语言，具体责任仍按资产填写。

用五个问题路由工作：共同性、不确定性、业务影响、数据权威和变化节奏比技术栈更重要

请求受理不问“是不是大模型”，而问：能力是否被三个以上产品重复需要；需求和成功标准是否仍高度未知；失败会不会改变客户、员工、设备、交易或权利；谁能解释数据和例外；上线后谁每周改变流程。共同性高且语义稳定的底座倾向平台，高未知且限时的探索倾向创新中心，影响和本地变化高的应用倾向业务产品队。

路由卡为每项计划记录证据而非主观分数：列出使用团队承诺、决定及其影响、数据负责人、预期结果、不确定性、运行窗口、服务依赖和接收团队。没有接收团队的项目最多进入沙箱发现，不能以“以后再找负责人”为理由接生产数据或影响工具。

混合路由很常见。C-17使用平台身份、模型网关和审计组件；创新中心帮助前6周建立任务定义和评估集；保修业务产品队从第7周起拥有工作流、队列映射和运行决定。一个应用用到三类团队，不代表三类团队共同拥有同一终态。

路由卡不是加权评分表。五个信号中，真实业务影响、没有数据主管或没有接收负责人属于硬性放行门槛，不能被“复用潜力高”抵消。卡片状态只有需要证据、发现、平台候选、业务产品、联合和停止；每次改变保留决策、负责人、日期、支持/反驳证据与下一复核门槛，防高层偏好被包装成小数总分。

C-17事件暴露的不是模型问题，而是交付、运行和停机三个决定没有负责人

C-17技术准确度在试点中达门槛，故障来自R32映射未进入依赖清单。业务配置管理员以为创新中心会监测；创新中心的项目经理在试点结束后转去下一项目；平台值班人员只看到模型网关正常；理赔主管可以手工改队，却不知道有权暂停AI路径。三个团队各自完成局部职责，整体仍无人负责。

复盘把“模型服务正常”与“业务产品正常”分开。73/1,260=5.79%是错误内部路由，16/73=21.92%进一步造成服务等级协议违约；两者不能都称模型错误。人工纠正前57件未超时仍是未遂事件和返工，不能从事件删除。外部拒赔、付款和客户通知均为0，也不能反推系统安全。

修复先指定保修运营负责人为C-17产品总负责人，授予暂停、恢复和退役权；数据管理员负责R32的权威版本与变更事件；平台负责传递依赖变更事件并维护网关与日志；创新中心则把此次事件纳入方法和培训。责任落在具名角色和产物，不写“AI委员会确保一切”。

事件时间线记录R32批准、首个修正、第五个同类修正、响应时限告警、首次通知值班人员、暂停、人工回退、重放和恢复回执。首个错误后没有聚类告警，是产品可观测性缺陷；变更事件没有使用团队，是数据依赖缺陷；平台只报网关健康，是状态模型缺陷。行动列表为每项写负责人、到期日、验证样本和关闭证据，不把“加强沟通”当纠正措施。

平台团队经营的是内部产品：共同控制必须有服务目录、使用路径、服务目标、版本和退出办法

平台章程只包含跨产品稳定需求：身份和最小权限、批准模型目录、调用网关、机密管理、日志与成本元数据、评估执行器、策略钩子、发布模板、事件遥测。它不拥有理赔规则、客服语气、维修严重度、员工决定或任何本地业务结果。

平台以产品方式运营：有路线图、内部客户、支持等级、已知限制、弃用计划和使用数据。业务团队不应被迫迁入；新服务需至少三个具名使用团队、共同契约和平台负责人，只有一个团队使用的复杂例外留在业务层。平台通过铺好的路降低重复，而不是用审批队列控制所有实验。

平台服务目标未达成时由平台值班人员处理；业务产品服务目标未达成时，即使网关仍显示正常，也由产品值班人员处理。两者通过依赖状态和事件协作机制配合。平台可以因共享风险关闭某个模型或适配器，却不能替业务决定是否用人工回退继续理赔；业务可以暂停自己的工作流，却不能私自扩大平台权限。

每项服务还要写清服务等级指标定义、测量来源、统计窗口、错误预算、维护排除项和支持严重程度。99.9%可用性若没有请求分母、成功状态和月度窗口，只是一句口号；评估执行器即使返回HTTP状态码200，若运行摘要值或结果回执缺失也算失败。错误预算耗尽时，平台暂停高风险功能放行，各使用团队仍分别判断自己的产品是否降级或停止。

服务目录必须区分基础、可选和禁止项，否则“中央提供”会无限扩张

目录把服务分为基线、可选托管和不在范围内。基线由企业共同资金支持且生产产品必须使用；可选项按适配和使用成本申请；不在范围内的内容明确留给业务或禁止。每项都要说明合格使用方、负责人、支持时长、服务目标、配额、成本规则、数据类别、版本和替代路径。

服务请求不能靠私聊。使用团队提交目的、用量预测、数据类别、风险等级、预期服务目标和负责人；平台返回支持模式、配额、费用、接入测试与拒绝理由。若平台路线图不接受，业务可在获得架构例外后自建，但必须自己承担生命周期，并保证不绕过强制控制。

每季度检查“只有一个使用团队却由中央永久维护”的服务，决定删除或明确转成业务资产。平台成功不是拥有最多代码，而是使用团队能更快、更安全地独立交付；服务目录不断增长、等待时间也同步增长，说明平台正在重新制造中央项目工厂。

服务请求表包含请求编号、产品编号、目的、数据类别、风险等级、用量预测、延迟与可用性需求、区域、负责人、成本中心、失效日期和回退方案。平台返回“已支持”“有条件支持”“例外”或“已拒绝”，并附契约测试、配额、预计成本和复核日期。有条件支持超过期限会自动降级，不允许一张临时例外成为永久的隐性产品。

创新中心交付学习和能力转移：每项工作从进入时就要写结束日期和接收方

AI创新中心（下文简称“创新中心”）处理三类任务：高不确定性用例发现、跨团队新方法的首次验证、对业务与平台的短期赋能。它可以共建试点、评估风险和形成参考实现，但永久代运营不在默认服务范围内。C-17的错误正是试点结束时没有明确谁接手生产运行。

每项参与在第一天就写清问题、反事实、影响边界、抽样方法、决策日期、容量上限和接收方。第4周仍没有业务负责人或合法数据，不延长技术探索；第8周没有可接受证据，合理结论就是停止；第12周接收方仍未通过运行就绪检查，不能让创新中心以“临时支持”为由无期限续命。

创新中心成员的绩效不按试点数量，而按高质量停止、证据可复核、方法被吸收、接收团队独立运行和同类问题减少。若创新中心靠拥有生产系统证明价值，它会囤积稀缺专家，业务永远建立不起自己的能力，下一年仍会申请更大的中央团队。

参与账本逐周记录假设、已用容量、样本变化、风险、反证、接收方就绪和剩余未知项。第4、8、12周的复核使用预先写好的门槛，不因演示受欢迎改变主目标。状态为活跃、被证据阻塞、转移就绪、已停止或例外；已停止保留可复用方法和失败原因，不删除不利结果来提高“成功率”。

业务产品队拥有最终业务结果：模型只是依赖，人员、规则、数据和回退都在产品边界内

C-17业务产品队由产品总负责人、理赔领域负责人、产品与AI工程师、数据管家、服务运营人员和按风险参与的风险复核人组成。部分角色可以兼职，但相应的决定权不能空缺。这个团队拥有合格案例定义、队列策略、人工复核、培训、工作流评估、业务结果、运行与变更预算、值班安排、事件处理和退役决定。

业务负责人不能把模型供应商或平台团队当作结果负责人。第三方服务失败时，由业务决定暂停、降级或使用人工路径，平台协助技术恢复。平台更换模型时，业务用自己的评估和护栏决定是否升级；平台共同测试通过，不等于C-17的路由、公平性或响应时限已经通过验收。

业务队也不能以“我们对结果负责”为理由绕过共同身份、日志、风险分级和事件通报。自治发生在共同护栏内：团队可以决定待办顺序、本地策略和放行节奏，同时接受可审计的强制接口。这才是分布式责任，而不是各事业部各自购买未登记工具。

产品运营表按周显示合格任务量、AI与人工的最终处理结果、更正、暂停、响应时限、成本、未关闭风险、依赖状态和值班健康；每个指标写清分母、来源、数据延迟和它支持的决定。业务会议不直接读模型平均分，而从异常案例随机抽样，检查来源、人工覆盖和最终影响。运行手册列出正常、降级、人工、暂停与退役五条路径，并由值班人员实际演练一次。

一个具名产品负责人必须同时拿到决定权、预算和坏消息，赞助人头衔本身不够

每个生产AI产品只设一个产品总负责人，可以是业务高管授权的产品负责人或流程负责人。其权利包含确定目标与范围、接受残余风险、分配业务预算、暂停与恢复、批准重大变更和启动退役；义务包含查看不利指标、保证人员回退、参加事件处置和向相应治理机构说明。

赞助人可为组合争取资源，却不自动拥有日常产品决定；产品负责人可负责产品，却不能自行接受组织规定需更高层批准的风险。决策权矩阵写明哪些在产品内、哪些升级到风险/道德/法律或高管负责人。升级不把A变成委员会，只是由预定义的另一个具名权利人作特定决定。

代理和离岗也预先处理。负责人缺席时由指定副手接管，超过30天必须重新签章程；组织调整、预算冻结或负责人离职会自动把产品状态降为受限，禁止新影响，直到新负责人、资金和值班人员就位。“大家都知道谁负责”不是可审计控制。

责任确认书包含产物编号、所作决定、授权依据、已考虑方案、证据、残余风险、限制条件、失效日期、最终负责人和副手。它不要求负责人亲自完成分析，却要求其看见反证和资源后果。高风险批准附到放行记录；日常待办决定可以批量记录。这样既不把责任简化成签名仪式，也不让“咨询过领导”替代决定。

组合委员会只决定资金池上限、共同风险容忍、跨事业部优先级和无法由产品解决的冲突。它不审批每次提示词、数据修正或恢复。会议决议必须落到具名决策负责人、资源、期限和可验证状态；若决议仍写“有关团队协同推进”，秘书处退回重写，不让集体语言重新制造空白责任。

960万元资金分成平台基础、限时探索和业务产品三本账，避免中央预算隐藏真实消费

年度AI预算边界为960万元。平台基础预算320万元，其中共同运行与人员240万元、共同安全、评估与可观测能力80万元；创新中心组合预算160万元，只支持限时探索和赋能；业务产品预算480万元，其中产品人员与运行、变更360万元，可归属的模型与工具用量120万元。320+160+480=960万元。

平台与创新中心的企业资金不表示“免费”。平台基础预算保证必要的共同能力不会因某事业部短期使用下降而消失；创新中心预算允许探索在没有正面结果时诚实停止；业务预算让需求方感受到产品、复核、事件和用量的完整成本。内部转拨只改变成本中心，不能再计入一次企业总成本。

预算确认书把计划编号、成本池、期间、负责人、上限、实际支出、预测、结束状态和内部转拨关联起来。C-17移交后，创新中心不再支付生产修复；平台基础预算支付网关的共同部分；保修业务单元支付本地工作流与可归属用量。没有接收预算就不能完成生产移交，更不能靠个人加班维持表面正常。

季度对账同时核对供应商发票、平台用量、人员容量和业务账簿。转拨单必须同时减少来源成本池、增加目标成本池，企业汇总时抵消内部转拨；已承诺但未使用的容量、共享折扣和外币差异单列，不硬塞给某个产品。预测超过上限10%时进入负责人复核，可能采取优化、增加预算、限流或停止，财务不替产品团队选择质量与成本的取舍。

分摊显示先建立可见性，正式分摊只用于能解释、能影响且会改变行为的成本

平台把费用分为固定共同成本、可归属用量、产品专属成本和未分配成本。模型令牌、专属向量存储和使用团队支持可以按产品编号计量；企业身份底座、安全扫描和最低值班能力属于共同基础。每月所有负责人收到成本分摊展示，列明数量、单位、分配规则、共享份额和差异；是否正式记入各部门账目由财务政策决定。

本案例120万元可归因使用量已经包含在480万元业务产品预算内，由平台统一支付供应商账单后再向四个业务单元分配；企业总额仍是960万元，不是1,080万元。若把所有平台固定成本按令牌摊给早期少数产品，会惩罚先行者；若所有用量永远由中央预算吸收，业务会提出无边界需求。分配规则要服务决策，不追求虚假精确。

分摊前问四项：负责人能否验证用量，能否通过设计改变成本，分配是否稳定可解释，记账负担是否低于行为收益。不满足就分摊显示并保留中央预算。成本异常同时通知平台和产品：平台查共同浪费，业务决定流量、质量与成本权衡。

分配记录保存计量源、标记覆盖率、共享驱动因素、费率周期、折扣处理、未分配金额和申诉负责人。产品有10个工作日质疑，不因财务月结覆盖原记录。若标记覆盖率低于95%，差额进入未分配并指定修复期限，而不是按人数或收入随意摊分；该95%是本案例内部控制门槛，不是FinOps通用要求。

从项目受理到生产移交必须是一条证据链，不能靠创新中心的口头承诺跨过责任空档

项目受理先判断问题和接收能力，再决定由谁做；没有接收方的“好点子”只能留在发现区

统一请求受理字段包括业务问题、受影响用户、当前基线、非AI替代方案、影响、风险等级、数据负责人、潜在产品负责人、复用方、依赖、12周容量和决策日期。秘书处检查完整性，平台、创新中心和业务代表组成的三方小组在30分钟内只决定路由，不在会上替团队设计方案。

11项计划重审后，4项因重复、无基线或无负责人而停止；2项有真实问题但任务与数据仍未知，留在创新中心继续发现；5项已有使用者、负责人和运行资金，转为业务产品。平台从多个项目抽取网关、评估执行器等共同能力，但不把它们伪装成第12个“业务用例”。

受理时限只约束何时给出路由决定及理由，不承诺所有想法都会开工。被拒者会收到决策记录、证据缺口和可重新提交条件。业务绕过受理流程购买的工具仍须进入资产清单和风险流程；治理不能用漫长排队逼出未登记的AI使用，而要提供足够快的合规路径和清楚的例外机制。

组合登记册把请求受理状态与真实资产、合同和成本连接。搁置超过60天自动关闭，发现工作必须有结束日期，业务产品必须关联运行手册和成本中心，平台候选必须关联三个使用团队的承诺。每月把登记信息与身份系统、供应商发票和代码仓库扫描结果对账；发现未登记的生产调用时先限制影响，再补负责人和评估，不能只补一行名称就恢复正常状态。

发现工作设置五道移交门：价值、风险、技术、运行和资金任何一道没有接收证据都不能生产

中心参与每两周更新证据，不以演示完成度判断。放行门槛 1确认问题、基线和非 AI 替代方案；放行门槛 2确认任务、数据用途和风险；放行门槛 3用评估证明技术可行且限制可接受；放行门槛 4由接收队演练监测、人工回退、事件和回滚；放行门槛 5确认未来两个季度资金与容量。

C-17旧试点只通过G3就上线；新制度要求五份回执。创新中心可以帮助补材料，但不能代表接收方签署G4和G5。高层要求“先上线再补负责人”时，参与负责人将例外、期限、限制和具名批准人写入登记册；没有批准记录的口头催促不改变放行门槛。

移交后设30天强化支持期：创新中心只处理事先列明的知识缺口，产品队从第一天起接手值班和变更。第15天与第30天检查独立运行；若常规任务仍由创新中心完成，就回到G4和G5修复或限制，而不是默认延长支持期。转移的是能力和责任，不只是代码仓库权限。

放行门槛检查清单不是只收文档：G1随机访谈两名实际用户，G2重放一个越权来源，G3跑正常/边界/失败样本，G4在非办公时段模拟依赖中断，G5由财务核对两季度容量。每个失败写影响限制和负责人；部分门通过不产生平均分。例外只能缩小范围或延迟术语，不能把未过的运行就绪改名为“可接受风险”。

交接包必须让接收队在创新中心离线时独立处理一次坏路径

移交包包括章程、架构、数据与来源、模型与系统版本、评估、已知故障、权限、服务目标、仪表盘、运行手册、供应商、成本预测、未关闭风险、待办事项和退役触发器。接收队不靠参加讲解会签字，而要进行闭卷演练：创新中心只观察、不操作，由业务队处理模拟的依赖变更和工具超时。

仓库、仪表盘和云账户完成转交，都不等于运行责任已经移交。接收方必须能解释主要失败、找到来源授权、停止影响、核对执行中的任务、联系依赖负责人并恢复。若这些操作只能由原作者完成，系统仍由创新中心隐性拥有。

支持约定列明严重程度、平台与产品响应、创新中心咨询时数、供应商路径和升级机制。强化支持期结束后，创新中心不再承担一线值班；出现新的跨企业共性问题时，可以重新建立限时参与。这样既不抛弃业务团队，也不让“请教一下”恢复为永久免费代运维。

交接清单还要逐项转移服务身份、密钥负责人、仪表板访问、供应商联系人、数据协议、调度器、告警、备份、固定测试样本和工单。每项只有已接收、已拒绝或不适用，禁止模糊填写“已分享”。已拒绝会阻断对应影响；接收方修复并重跑闭卷样本后，由原中心负责人与新产品负责人共同签署转移确认书。

生命周期责任矩阵按产物和决定填写：每行只能有一个最终负责人

责任矩阵不能写“平台、中心和业务共同负责AI”。它要按问题、共享服务、领域数据、产品发布、残余风险、事件、供应商和退役拆行。执行者可以有多人，最终负责人只能有一个；咨询方必须提供具体输入，知情方则要说明何时通过什么产物获知。

重大残余风险若按政策要求由高层批准，就新增“风险接受”一行，由具名高管或风险负责人承担最终责任；这不改变C-17日常运行的产品负责人。供应商对合同服务水平负责，企业内部仍要有供应商负责人和产品负责人，不能把最终负责人写成供应商。审计、法律和安全可以有否决权或独立监督权，也应在决策权限中写清，不能用责任矩阵的字母掩盖。

每季度抽5个产品做产物审查：随机选一个变更、一次运行、一个事件或未遂事件，从回执核对最终负责人是否真的收到信息并作出决定。纸面责任矩阵与实际值班通知、预算或仓库权限不一致时，按控制缺陷处理，先修正权限和工具，再要求个人承担责任。

责任矩阵工作簿为每行附上决策对象、触发条件、最终负责人、执行者、咨询方、知情方、系统权限、产物、响应时限和副手，避免一张字母矩阵失去运行含义。抽查若发现值班人员属于执行者，但暂停权限仍在一个不明确的委员会，结论就是未通过；若最终负责人看不到成本或人员信息，先补仪表盘与授权。修订保留版本和生效日期，事故按当时版本复盘，不能事后重写责任。

依赖与事故需要双线负责：平台恢复共同能力，业务控制本地影响

数据、模型和供应商分别有负责人：技术依赖集中采购，不会把业务后果转移给平台或厂商

数据负责人批准用途、权限、质量和变更通知；平台负责人管理模型目录、网关和共同供应商的运行数据；产品负责人判断特定模型与数据组合是否适合C-17并承担本地最终结果；采购或供应商负责人管理合同、退出和供应商升级。一个角色可以兼任多个职责，但这四类决定的回执不能消失。

变更事件包含依赖编号、旧版本、新版本、生效时间、受影响使用团队和必要验收。平台能传播事件并阻止未固定版本，却不知道R32如何改变保修语义；C-17团队必须维护契约测试和本地标准答案。若数据负责人无法提供稳定的变更信号，产品就要增加快照、对账或缩小使用范围。

供应商服务“符合合同服务水平”也可能不适合本地任务；平台共同评估通过，也可能在C-17的分层案例中失败。合同赔偿不能替代客户纠正、人工回退或监管与内部报告。组织边界应与技术和合同边界对齐，但不能假设它们天然一致。

依赖登记表包含依赖编号、类型、技术负责人、语义负责人、供应商负责人、使用团队、固定版本、变更通道、测试、回退、支持窗口和退出方案。每季度模拟一次供应商中断和一次数据结构变更，分别验证平台与业务的决定。无法联系负责人或回退方案未经演练时，产品状态降为受限并缩短运行窗口。

事故采用双负责人协作：平台恢复共同依赖，业务产品控制本地影响和受影响流程

每个生产事件先指定产品事件指挥官；若共享依赖受影响，再由平台事件指挥官负责平台处置线。两人共享时间线，但决定不同：平台可以隔离模型或网关，产品可以暂停C-17、启用人工队列、协调案例和决定业务通知。创新中心只在需要方法或历史背景时提供咨询。

C-17复演时由产品负责人在18分钟内暂停。平台确认网关健康，但R32变更事件没有登记；业务转入人工队列，随后重放73个历史测试样本和40个新测试样本，由负责人签署恢复决定。18分钟只是本案例的一次演练结果，不是所有企业都应采用的服务目标。正式目标要按影响与运营能力设定，并用真实值班系统的时间戳验证。

“到底谁值班”在上线前通过呼叫测试回答。电话树、聊天群和月度委员会不能替代24/7或明确支持时长的轮班表。没有夜间能力的产品应限制运行窗口或保持无AI 回退；把告警发给创新中心个人手机不是运营模式。

事件记录使用一条主时间线、两条处置线和一组最终计数。产品事件指挥官记录受影响案例、人工队列、通知和业务恢复；平台事件指挥官记录受影响的依赖使用方、版本、隔离和服务恢复；每30分钟在联合检查点核对是否能安全恢复。复盘行动分别回到产品、平台、数据团队或创新中心的方法库，不产生无人负责的“跨团队改进”清单。

人才和组织转型要留下独立运行能力，而不是留下更换名称的中央依赖

人才采用轮转和嵌入而不是永久借调：专家要培养接任者

平台需要产品管理、可靠性、安全和开发者体验；创新中心需要发现、领域协调、评估和教学；业务队需要产品、领域、数据、工程和运营。稀缺AI专家可以在创新中心轮转6个月，或嵌入业务8至12周，但从开始就要指定归属团队、目标能力、接任者和返回日期。

容量计划通过限制在制工作保护团队。4人创新中心同时最多参与4项工作，每项都有每周容量上限，不能接受11个“最高优先级”；6人平台按服务路线图和值班储备排期；业务负责人在立项前承诺产品、领域和运维容量。没有容量就是没有通过入口门槛，不能靠个人加班填补。

绩效分别对齐：平台看使用团队的接入前置时间、可靠性和自助率；创新中心看证据质量、停止与移交质量和能力增长；业务看结果、质量、风险、成本与运行健康状态。若所有人都按“上线AI数量”奖励，三类边界会再次坍塌成演示工厂。

技能矩阵按角色列出“必须独立完成”“可在支持下完成”和“只需理解”三档，再用工作样本验证：平台工程师处理配额异常，创新中心负责人写反证备忘录，产品负责人作暂停决定，数据管家解释变更权威，值班员协调执行中的任务。课程完成不等于能力；连续两次演练仍依赖原专家，就必须延长跟岗支持，不能宣告移交完成。

两季度转型用事实而非重组公告验收：先给现有产品负责人，再拆预算、服务和人才流动

第1至2周盘点全部AI资产、预算、服务身份、负责人、值班人员和依赖；第3至4周为5个生产产品指定最终负责人、暂停权和临时运行手册；第5至8周发布平台目录与三本资金账，重审11项计划；第9至12周完成C-17等首批移交演练。第二季度收口成本分摊展示、创新中心退出、责任矩阵审查和弃用工作。

仪表盘不把会议、培训人数、试点数或平台调用量当作最终成功。组织健康要看负责人覆盖率、从告警到暂停的时间、移交独立性、创新中心参与时长、平台接入前置时间、事件关闭、未分配成本和产品结果。指标按产品与团队类型切分，避免平台整体服务指标掩盖C-17最终结果失效。

常见诊断很直接：中心参与超过12周且仍接手值班，是永久代运营；平台待办按高管项目排序且没有服务契约，是中央交付队；业务有预算却没有数据负责人和值班能力，仍是项目而非产品；委员会每次出事才决定谁最终负责，就是集体不负责。转型完成的证据是这些状态消失，不是组织图换颜色。

过渡仪表板的每项指标都有决策负责人和阈值：负责人覆盖低于100%时禁止新增生产，独立移交低于100%时维持强化支持或限制，未分配成本高于5%时修复成本标签但不强行收费，创新中心参与超过12周时必须停止或取得例外，呼叫演练失败时当天修复轮班表。阈值均为岚港案例内部选择，其他组织应按风险和容量重新设定。

最终交付是一套可运行的联邦式契约，并用官方资料校准原则边界

最小交付包含团队章程、五问信号路由卡、平台服务目录、创新中心参与约定、业务产品章程、问责与决策权、三本资金账、成本分摊展示规则、五道移交关口、移交演练、生命周期责任矩阵、依赖所有权、双负责人事件运行手册、容量计划和两季度过渡仪表板。

资料用于校准而非复制组织答案：NIST人工智能风险管理框架核心部分要求角色、责任和沟通清楚，管理层承担风险决定，并在生产中监测和管理第三方风险；微软当前的云采用框架把平台的规模化基础与护栏、工作负载的端到端业务生命周期、创新中心的标准与咨询职能区分开，并建议成熟后让创新中心从集中控制转向咨询。这些是厂商指导，不是适用于所有企业的强制结构。

GOV.UK 人工智能指南建议特定项目指定高级责任负责人并跨生命周期明确责任，本文只借用具名责任原则，不把英国政府要求套作企业法律义务。FinOps 基金会指出分摊显示应建立可见性，而分摊是否需要取决于组织会计政策；政府问责局框架以治理、数据、性能和监控四个互补面审视问责，本文不声称案例接受政府审计或符合某项认证。

• NIST AI Risk Management Framework Core
• Microsoft Cloud Adoption Framework：Organizational readiness for AI agents
• Microsoft Cloud Adoption Framework：Establish an AI Center of Excellence
• GOV.UK：Artificial Intelligence Playbook for the UK Government
• FinOps Framework：Invoicing & Chargeback
• U.S. GAO：Artificial Intelligence Accountability Framework

明天开始时，先不要成立新委员会。拿出现有AI资产和成本清单，找一个生产产品，请业务、平台、创新、数据和财务负责人分别写下谁能暂停、谁接手值班、谁付下一张账单、谁批准数据变更、谁决定退役；答案不一致的地方就是第一批组织缺陷。先修一个真实产品的决定权和回执，再把可复用契约扩到组合。