《互联网产品的 AI 架构·平台化与治理》附录 A 治理角色与职责速查

附录 A 的用法

治理讨论最容易停在“大家都要负责”。这句话听起来正确，实际等于没人负责。能力重复建设时，平台说是业务先提的需求；版本漂移时，提供方说是调用方不升级；配额超支时，租户管理员说是平台没有提前拦。每个角色都能自证清白，问题却真实发生了。

这份附录把卷四涉及的角色压成六张卡片。每张卡片回答四件事：负责什么、能决定什么、明确不负责什么、交出什么。四件事缺一件，职责就会在交接处蒸发。

先定位角色，再讨论流程。角色不清，流程只会把扯皮正式化。

职责划分的三条原则

单一问责

每一项治理决策只能有一个最终问责人，写作 A（Accountable）。A 可以听取多方意见，但必须独自承担“这件事为什么这么定”的解释责任。多个 A 等于没有 A，因为冲突发生时没有人有义务拍板。

单一问责不等于单人执行。A 可以把执行交给多个 R（Responsible），但不能再把最终责任分出去。RACI 表里一行出现两个 A，通常不是设计精细，而是设计没做完。

决策权与执行权分开

决策权回答“能不能做”，执行权回答“怎么做”。平台团队拥有路由、限流、降级开关的执行权，但不拥有“某个业务能力是否值得存在”的决策权；能力提供方拥有版本发布与退役的决策权，但不拥有租户额度如何分配的决策权。

分开的好处是冲突可裁决。执行方按已批准规则动作，决策方对规则本身负责。两者合一，平台就会从裁判变成运动员，任何技术选择都会被解释成平台利益。

交接物必须可验收

职责的边界不在组织架构图上，而在交接物上。能力提供方交给平台一份能力条目，平台要能逐字段验收；租户管理员交给平台一张额度调整单，平台要能校验份额之和；安全交给提供方一份分级结论，提供方要能据此改数据流。

交接物没有验收判据，等于把责任留在空气里。附录 B 的字段表就是为验收准备的：字段齐全、引用一致、时效有效，才算交接完成。

六个角色

平台团队

平台团队最容易越界的地方，是把“我能拦”当成“我该定”。能拦是执行权，该定是决策权。平台可以拒绝一次不符合规则的调用，但不能自行决定某个租户的份额应该给谁。

能力提供方

提供方的“负责”必须落到数字上。A 链基线是成功率 96.25%、每次成功交付 3,496 微元、P95 3,523ms；B 链是 99.58%、3,804 微元、1,738ms；C 链是 95.00%、2,429 微元、793ms。说不清自己能力的基线，就无法判断一次发布是优化还是退化。

调用方

调用方不是“提需求的人”，而是链路的一部分。它决定了失败如何呈现给用户，也决定了重试会不会把一次故障放大成一次事故。把调用方排除在治理之外，等于把最接近用户的一层交给运气。

租户管理员

租户管理员同时拥有分配权与回收权，这两项不能拆开。只有分配权没有回收权，借用就会变成永久转移；只有回收权没有分配权，团队会绕过管理员直接找平台。示例口径是租户月度总额 1 亿微元，内容团队 4,000 万、客服团队 3,000 万、交易团队 3,000 万，三者相加正好 1 亿，任何新增份额都必须同时调整总额或某个份额。

安全/合规

安全/合规的否决权只针对不可逆风险，不用于替业务做优先级排序。它可以说“这批数据不能出域”，不能直接说“这个能力不该上线”。前者是边界，后者是经营判断，越界会让安全角色失去可信度。

评审委员会

委员会的价值不在“多一道审批”，而在“把冲突变成可检索的记录”。一次没有条件、没有 owner、没有复查日期的通过，只是把风险推迟到上线之后。

一张 RACI 表

R 是执行，A 是最终问责，C 是事先咨询，I 是事后知会。每行只能有一个 A。

这张表有三处值得注意。第一，主版本变更的 A 在委员会，不在提供方；因为不兼容变更的影响跨团队，单个提供方无法承担协调责任。第二，数据分级的 A 在安全，提供方是 R；提供方可以决定怎么实现，不能决定数据能去哪里。第三，季度复盘的 A 在委员会，平台、提供方与安全都是 R；复盘不是平台写给自己的总结。

角色与治理对象的对应

对象与角色不是一一对应。一个能力可能由平台团队运营，也可能由业务团队运营；关键不是组织归属，而是 A 是否明确。平台团队运营能力时，必须同时接受“提供方”角色的约束，不能用自己的平台身份豁免质量与成本责任。

三个职责冲突与裁决

冲突一：退役节奏 vs 大客户依赖

场景：提供方计划 2027-01-31 下线 chat.reply@1.9.0，调用方 A 链仍占 18% 调用量（示例值），平台希望 2026-12-01 直接切到 2.1.0，理由是技术栈更统一。

裁决：

• 退役决策权在提供方，但必须提交迁移计划、影响面、回滚版本与至少 90 天弃用窗口。
• 平台只能按已批准窗口执行路由变更，不能以“技术更优”为由提前切流。
• 调用方在窗口内完成契约适配，迁移率每周上报；未达标由租户管理员协调资源，不改变窗口。
• 评审委员会只在跨团队无法达成时仲裁，仲裁结果是决策记录，不是口头通知。

判据：下线前 30 天迁移率不低于 95%，回滚版本可用，A 链成功率不低于 96.25% 基线。三条缺一条，下线延期，而不是“先切了再说”。

冲突二：额度再分配 vs 单次硬上限

场景：租户管理员把内容团队 4,000 万份额中的 500 万借给交易团队；交易团队的站内下单咨询希望把单次上限从 3,000 微元临时提到 6,000。

裁决：

• 租户管理员有份额再分配权，但借用必须走额度调整单，写明窗口、归还日与审批人，并在下一计费周期生效。
• 单次上限是平台技术上限，租户管理员无权调整。摘要 6,200、回复 4,200、下单 3,000 微元是能力级上限，不是可协商额度。
• 平台执行当前生效版本，不接受口头放行；紧急情况只能走例外流程，由评审委员会批准并登记到期时间。
• 超额部分由租户总额承担，不能转嫁给平台或供应商。

判据：调整单、窗口、归还日、执行日志四件齐全。只有调整单没有执行日志，说明规则停在纸面；只有执行日志没有调整单，说明平台在替租户做决定。

冲突三：安全叫停 vs 已批准灰度

场景：安全/合规在灰度第二天发现新提示版本可能把 internal 数据发到外部供应商；评审委员会上周已批准 10% 灰度。

裁决：

• 安全对数据出域有一票否决。平台在 30 分钟内关闭开关并回滚到上一版本。
• 评审委员会在 48 小时内追认，补决策记录；提供方提交数据流、供应商通知与再评估报告。
• 灰度比例不能稀释不可逆风险。“已批准”不等于“免检”，批准的是当时的证据，不是未来的所有变更。
• 不计入提供方质量事故，但计入治理例外台账，季度复盘必须出现。

判据：止血时间不超过 30 分钟，回滚成功率 100%，供应商通知不超过 72 小时。三条都达成，才可以把这次叫停记为“有效拦截”，而不是“过度反应”。

一次跨团队交接的走查

场景：chat.reply@1.9.0 退役，A 链迁移到 2.1.0

T-90  提供方提交退役计划：窗口、影响面、回滚版本、迁移负责人
T-60  平台核对目录与配额；调用方确认契约差异与降级预案
T-30  迁移率达到 95%；安全复核 dataClass 与出域区域未变化
T-7   平台预置路由；灰度 10% → 50%，观察失败率与 P95
T-0   关闭 1.9.0 新调用；保留只读回放 30 天
T+30  复盘：成功率、成功交付成本、人工介入率与基线对比

每个时间点的动作都有唯一 owner。T-90 是提供方，T-60 是平台与调用方共同验收，T-30 是安全，T-7 是平台，T-0 是平台执行提供方决策，T+30 是委员会主持。走查的价值不是排期，而是暴露“这一步到底谁签字”。

交接物的验收口径

验收不是“收到邮件”，而是“能据此执行”。平台收到能力条目，要能直接生成路由与配额规则；调用方收到契约，要能直接写校验与降级；安全收到数据流，要能直接判断是否出域。

角色空缺时的代偿

治理体系不可能一开始就六类角色齐全。小团队常见的是平台兼提供方、租户管理员空缺、安全由研发兼任。代偿可以，但必须有期限与记录。

代偿期的决策仍然要留痕。临时 owner 不是永久 owner，到期未补，相关能力应停止新接入，而不是默认续期。代偿的最大风险不是做得差，而是没人记得它是临时的。

常见错误与边界

• 把角色写成部门名，没有可联系的人。部门会重组，责任不能悬空。
• 让平台同时拥有能力质量和额度分配，裁判与运动员合一，冲突无法裁决。
• RACI 一行多个 A，冲突时人人有责等于无人拍板。
• 交接物没有验收判据，只有“发过邮件”“拉过群”。
• 安全只在线上线前签字，不参与运行期变更，灰度后的新风险无人看。
• 租户管理员只有分配权没有回收权，借用变成永久转移。
• 评审委员会只做一次准入，不做例外到期清理，台账越积越厚。
• 把“已批准灰度”当成“任何后续风险都免检”，用比例稀释不可逆风险。

小结

治理角色的核心不是分工图，而是三件事：每项决策有唯一 A，决策权与执行权分开，交接物可验收。六类角色各自守住边界，跨团队冲突才有裁决的起点。

RACI 表不是装饰。它应该出现在每一次评审材料的第一页，让所有人先确认“这件事谁拍板”。表里出现两个 A、空白格或全是 C，说明职责还没设计完。

角色清楚之后，下一步是把角色要看的字段固定下来。附录 B 给出能力目录、契约、配额与版本矩阵的字段速查；字段是角色的语言，没有共同字段，角色之间只能靠形容词沟通。