没有责任矩阵，AI 项目迟早会乱

责任矩阵不是管理表格，是 AI 项目里“谁拍板谁兜底谁能喊停”的工程底座。没写清，迟早乱。

你做 AI 项目，最容易被误伤的一步不是模型效果，而是责任。

你把功能跑通了，大家都挺兴奋；一旦出了问题，最先开始消耗的不是算力，是时间和信任。因为你会发现一件尴尬的事：没人知道谁能拍板，谁必须兜底，谁有权暂停。

我的观点

没有责任矩阵，AI 项目迟早会乱。

这里的“乱”，不是吵两句架那么简单，而是三件事同时发生：

• 决策被拖成群聊：谁都能提意见，但没人能做决定。
• 风险被拖成默认上线：因为没人敢说“先停”。
• 复盘被拖成下次注意：因为没有人对“关闭问题”负责。
• 信任被拖成消耗：每一次扯皮都在透支团队对 AI 的耐心，后面再推任何试点都更难。

更麻烦的是，这四件事会互相放大：决策慢 → 风险只能默认上线 → 出事只能“下次注意” → 信任流失 → 下次更没人愿意拍板。所以责任矩阵不是“管理动作”，它是让上面这条恶化链断掉的那个扣。

为什么 AI 项目更需要这张表

传统系统出问题，你大概率能看到系统信号，比如报错、超时、非 200。

| 维度 | 传统系统故障 | AI 项目故障 | | --- | --- | --- | | 你能看见吗 | 多半有报错、日志、告警 | 系统一切正常，结果却已错 | | 谁来定位 | 技术团队按栈排查 | 先吵“这是谁的锅” | | 处置动作 | 回滚 / 重启 / 修代码 | 谁有权停、谁兜底说不清 | | 复盘落点 | 改一行配置或补一个监控 | 一句“下次注意”，没有关闭人 |

AI 项目更常见的故障，是系统一切正常，但结果已经错了。这会把问题从“技术定位”，变成“组织扯皮”——而且越往后越贵：定位不清时，你付的是加班；责任不清时，你付的是客户信任和监管代价。

NIST 的 AI 风险管理框架把治理放在第一层，核心就是把角色、责任和问责机制写清楚。ISO/IEC 42001 也要求组织建立 AI 风险与治理职责（角色、问责、权限）。你要是这层缺了，后面再补评测、灰度、监控，都会更费劲——因为它们都没有回答那个最朴素的问题：“谁拍板”。

一个你一定见过的场景

假设你在一家机构推进一个“智能审核助手”。它会给出审核建议，但最终仍由人工确认。

上线第 3 天，业务说“建议乱给”，技术说“模型没问题”，安全问“权限是不是越界”，运维说“日志不全看不出来”。

会开了一上午，你们没有把问题推进一步，因为大家都在争一句话：

谁负责。

这时候你才发现，真正卡住项目的不是技术栈，而是你们从来没写过“责任栈”。

为什么大多数团队写不出这张表

不是大家不知道它有用，而是三件现实的事把它拦住了：

• 上线节奏压着：业务要快，治理常被推到“稳定后再补”，结果永远没到稳定那天。
• 没人认领 owner：责任矩阵是跨部门的事，业务、产品、技术、安全各有各的 KPI，谁都不想当那个“拦着大家往前冲”的人。
• 误以为要写制度：一想到“矩阵”就觉得要出一份红头文件，于是迟迟不动手。

其实它最开始可以只是一张贴在群公告里的表。先有，比先完美重要；先写清 8 个动作，比先写 80 个动作有用。等你真靠它救过一次火，复盘时自然有人愿意把它固化成流程。

责任矩阵到底写什么

你不需要一上来就写成制度。

先把 8 个最容易扯皮的动作写清楚，责任矩阵就能立起来。写法建议用最常见的 RACI：

• A：最终对结果负责的人（每个动作只能有一个 A）
• R：具体执行的人
• C：需要被征询的人
• I：需要被告知的人

下面是一张最小可用的例子。你不用照抄，照着改成你们自己的字段就行。

| 动作 | 业务负责人 | 产品负责人 | 科技负责人 | 安全与合规 | 运维 | | --- | --- | --- | --- | --- | --- | | 需求边界冻结（什么不做） | A | R | C | C | I | | 数据接入与脱敏口径 | C | C | A | R | I | | 权限开通与越权检查 | I | C | R | A | C | | 提示词与规则口径变更 | C | A | R | C | I | | 灰度放量节奏（5%→20%→50%） | A | R | R | C | C | | 异常判定与停线（触发条件） | A | R | R | A | C | | 回退与恢复（回到旧流程） | A | C | R | C | A | | 周复盘与问题关闭 | A | R | R | C | C |

RACI 只解决一个问题：出了事，谁能拍板，谁必须兜底，谁能先喊停。

最容易漏掉的，是暂停权

很多团队写了“谁负责”，但没写“谁有权暂停”。

结果就是出事时所有人都在等批示，风险窗口越拖越大。

我建议你把暂停权拆成三条，写进矩阵或补充条款：

• 业务暂停权：当输出影响客户权益或对外承诺时，业务可以直接停用 AI 推荐，不等技术结论。
• 合规暂停权：当触发合规红线或越权风险时，合规可以要求立即停线并启动审计。
• 技术暂停权：当系统指标异常或数据污染时，技术可以先切回旧流程，后补说明。

这三条能成立的前提，是你们提前写清“停了之后怎么走”，比如切回旧流程的步骤、通知对象、恢复条件和复盘口径。

责任矩阵不是越多越好

常见反噬是把它写成“全员责任书”：每行都塞满 A，等于没有 A。几条尺寸原则：

• 一个动作只能有一个 A。多个 A 会互相默认对方会兜底，最后谁都不底。
• 角色别超过 6 个。列太多，表就没人看；抓不准的先并掉。
• 先覆盖“会出事”的动作，不是“所有”动作。上线前先有边界冻结、权限、灰度、停线、回退这五条，其它慢慢补。
• 写在能看见的地方。它要进需求评审、进上线 checklist，而不是躺在某个文档角落。

它和你们已有的制度怎么接

别把它当成又一套新流程。大多数机构已经有变更管理、安全合规、ITIL 之类的框架，责任矩阵只要“接进去”就行：

• 边界冻结 → 接到变更管理的“范围确认”节点；
• 权限与越权检查 → 接到安全合规的“访问控制”条款；
• 灰度与停线 → 接到发布管理的“回滚预案”节点。

这么接，它就不是额外负担，而是把原本散在各部门口头的约定，钉成一条谁都赖不掉的链。

监管已经在替你回答“谁负责”

你不一定现在就冲着合规去做这件事，但趋势很清楚：欧盟 AI Act（Regulation (EU) 2024/1689）对高风险 AI 系统设了问责与风险管理义务，2026-08-02 起相关条款全面强制；ISO/IEC 42001 也要求组织建立 AI 角色与问责机制。换句话说，外部已经在把“谁负责、谁兜底”从软建议变成硬要求。提前把矩阵写清楚，不是为了应付检查，而是等检查来的时候，你手里已经有一份能直接交出去的东西。

你今天能做的一个最小动作

如果你今天只能做一件事，就做这个：

• 选 5 个最常见的出错场景，写清触发条件和下一步动作。
• 把这 5 条对应到责任矩阵的行里，补齐谁是 A。
• 约定一个原则：A 不到场也能生效，不能靠“临时开会拍板”。

你会发现，A 一旦写清楚，很多争论会自己消失，因为问题终于能被递到“该接的人”手里。

举个例子，假设你们的“智能客服”上线后开始乱承诺退款。没有矩阵时，客服等产品、产品等技术、技术说“模型输出没法 100% 控”，一圈下来客户已经投诉到监管。有了矩阵：业务在触发“对外承诺错误”时直接暂停 AI 推荐（业务暂停权），安全在越权风险时要求停线（合规暂停权），技术切回旧流程。同一件事，从“群聊扯皮三天”变成“十分钟内有人接、有人停、有人回退”。差别不在模型，在谁能被找到。

签名式自检

• 你们的 AI 输出如果错了，谁有权第一时间说“先停”。
• “停”之后，回到旧流程的动作写在哪里。
• 需求边界是谁签字冻结的，冻结后谁还能改。
• 提示词或规则口径变更，谁验收，验收标准是什么。
• 本周复盘里，至少有一个问题被关闭，而不是一句下次注意。

你答不上来这些问题，就先别急着扩量。

关于作者

参考资料

1. NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST.AI.100-1（2023-01）。用于“治理要先写清角色与问责机制”的论证。https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
2. ISO/IEC 42001:2023《人工智能管理体系》要求组织建立 AI 风险与治理职责（角色、问责、权限），可作为“责任矩阵应先于评测、灰度与监控”的体系化佐证。https://www.iso.org/standard/81230.html
3. EU AI Act（Regulation (EU) 2024/1689）对高风险 AI 系统设问责与风险管理义务，2026-08-02 起相关条款全面强制，可作为“谁负责、谁兜底”监管趋势的旁证。https://eur-lex.europa.eu/eli/reg/2024/1689/oj
4. 文中“智能审核助手”一节为假设场景（构造用于说明，非亲历项目），不含真实客户数据。