要用 AI 创建 RACI 矩阵，应把具体交付物、活动或决定作为行，提供获批角色与授权清单，只让 AI 整理分配并提示缺口。真正执行和授权工作的人必须共同确认最终的 Responsible、Accountable、Consulted 与 Informed 关系。

先应用受控 AI 工作流，并以获批的项目计划为输入。RACI 用于明确已知工作的责任，不负责设计组织、授予权限，也不能替代利益相关者地图。

关键要点

行必须是可观察的交付物、活动、控制或决定。

列来自真实角色和授权记录，不能依赖职位刻板印象。

先确认谁实际执行，再确认谁最终问责。

每行默认只有一个 Accountable，获批制度另有规定时才记录例外。

Consulted 是双向参与，Informed 是单向知会。

必须检查缺 R、多个 A、权限不足、负载过高和角色冲突。

用 AI 创建 RACI 矩阵实际要决定什么？

RACI 记录各角色怎样参与一项确定工作。Responsible 执行或协调工作；Accountable 对结果最终负责并拥有所需权限；Consulted 在行动或决定前提供双向意见；Informed 接收单向结果或状态。

英国 Secure by Design 指南使用 RACI 矩阵协商角色与责任，并定义了 Responsible、Accountable、Consulted 和 Informed。［1］ GOV.UK 的 Global HR Design 指南进一步指出，每个流程应有一位明确的 Accountable，而 R、C、I 可以有多个。［2］这可作为默认方法，但最终必须服从你所在组织真正适用的治理制度。

代码	核心问题	要核对的证据
R	谁执行或协调？	流程图、操作程序、工作包
A	谁有权批准并对结果负责？	授权、章程、政策、决策权
C	谁必须在行动前提供意见？	控制、专业知识、咨询义务
I	谁必须收到结果或状态？	报告、通知、相关方义务

RACI 不是绩效评分，不表示谁级别更高、更重要、更忙或应该承担过错。写进姓名也不能证明本人已经接受任务或拥有足够时间和权限。

提示 AI 前要收集哪些输入？

先固定范围与版本。覆盖整个转型的矩阵通常太模糊，应选择一个流程、阶段、产品增量、决策序列或明确的交付物集合。

收集：

获批范围、工作分解、流程图或控制目录；
交付物、决定及其验收点；
使用稳定角色名的角色目录；
章程、授权额度、审批权与职责分离规则；
供应商或合作方的合同责任；
强制咨询、通知、监管和记录步骤；
工作负载、替补和升级安排。

北爱尔兰政府的项目管理资源把角色、责任、组织、规划、控制和治理放在同一交付语境中。［3］缺少这些上下文的矩阵可能看似完整，却把批准权交给没有决策权限的人。

使用 AI 前应尽量以角色标识替代员工姓名，并移除绩效评语、私密消息、受保护特征、薪酬、医疗资料和商业机密。

怎样定义矩阵的行和列？

每一行都应有动作、对象和完成或决策点。“安全”“市场”“管理”过于宽泛；“批准生产访问”“核实验收证据”或“批准后通知受影响客户”才可验证。

常用行类型有三种：

交付物行：明确谁产出以及谁验收。
活动行：明确谁执行一个可重复步骤。
决定行：明确谁准备证据、谁决定、谁接收结果。

不要在一行混合多个层级。“设计、开发、测试、批准并上线服务”包含不同的执行者和审批者，应在证据、权限或交接改变之处拆开。

列的粒度要一致。不要无依据地混合“财务部”“项目经理”和个人姓名。每个角色都应链接到获批角色说明、授权或合同责任。

每个“工作项–角色”分配使用一条记录。把以下可复用字段契约保存在一起，让复核人能够重建矩阵、证据与审批过程：

记录组	必填字段
控制	`Matrix ID/version`、`Scope`、`Owner`、`Effective date`、`Review trigger`、`Approval`、`Change log`
工作项	`Deliverable/activity/decision ID`、`Work item`
角色	`Role ID`、`Role holder`、`R/A/C/I`
证据	`Authority source`、`Responsible evidence`、`Accountable evidence`
沟通	`Consultation trigger`、`Information channel`
例外	`Exception rationale`

例如，一条合成记录可以写成 DEC-07: approve production release，R 为 ROLE-DELIVERY，A 为 ROLE-CHANGE-AUTHORITY，C 为 ROLE-SECURITY，I 为 ROLE-SUPPORT。以 DELEGATION-04 作为权限来源，在真实角色持有人确认前保持 NEEDS_OWNER_REVIEW。这些标识只展示结构，不代表建议的角色分配。

矩阵生效前，要让实际角色持有人共同确认各行和角色分配。真正的控制点是达成并记录一致意见，而不是生成表格。

怎样分配 Responsible 和 Accountable？

先找 Responsible：谁拥有完成工作所需的流程、资源、访问、能力和义务？每个可执行行通常至少需要一个 R。

再找 Accountable：谁能接受结果、授权决定、解决冲突并对完成情况负责？不能根据级别或职称推断 A，必须核对章程、授权、政策或合同。

默认每行只有一个 A，这样决定和升级路径才清楚。若获批治理模型确实采用共同问责，必须把依据、权限划分、共同决定方式和僵局处理写成明确例外；AI 无权自行创建例外。

应避免：

所有人都是 R，实际无人牵头；
把最高级参会者自动写为 A；
让供应商为买方独有的决定承担 A；
在要求职责分离的控制中让同一角色准备并独立批准；
因 A 会“想办法”而留下空白 R；
关键责任只绑定个人姓名，人员变动后失效。

怎样区分 Consulted 和 Informed？

Consulted 表示在开展工作或作出决定之前，要征求并考虑对方的意见。这是双向沟通，所以该行应写明何时咨询、期望得到什么输入，以及意见迟交或存在争议时怎样处理。

Informed 表示该角色接收结果、状态或决定，沟通主要是单向的。被知会的角色不会仅仅因为收到报告就获得审批权。

C 要克制使用。一大群 Consulted 角色会形成一个隐性的共识流程，拖慢交付。要问：这个角色是否提供必需的专业意见、是否拥有受影响的控制、是否代表某项明确的相关方义务，或政策是否要求其参与？如果都不是，I 可能就够了。

反过来，也不要为了缩短流程，就把必须参与的控制负责人从 C 降为 I。先如实映射实际义务，再另行改进流程。

怎样让 AI 安全起草？

提供版本化行清单、获批角色目录、授权证据、分配限制和输出结构，要求保留来源标识并单列未决项。

提示应要求：

不新增、删除、合并或改名角色和工作行；
不根据职称推断权限、能力、时间或责任；
只有证据支持时才提出分配建议；
缺少证据时标为 NEEDS_OWNER_REVIEW；
提示无 R、无 A、多个 A 或不兼容分配；
按所给沟通要求区分 C 与 I；
保留流程、章程、授权或政策引用；
输出建议而非任命。

AI 可统一角色名称、按模板排列、发现空白单元格和起草工作坊问题，但不能任命负责人、修改授权、解决职责分离冲突或把沉默当成接受。

怎样系统复核矩阵？

横向逐行检查：是否至少有一个 R？是否恰好一个 A 或有批准例外？A 是否有真实权限与升级路径？C 是否确实要在完成前提供意见？必要通知是否有 I？控制是否要求准备与审批分离？

纵向逐角色检查：某个角色是否承担不现实的大量 R？A 是否集中在无关审批上？C 是否因不敢排除而遍布全表？替补和离岗交接是否明确？跨团队与供应商安排是否符合协议？矩阵是否与权限、程序或访问控制冲突？

不能用单元格数量直接衡量负载，因为两行工作的投入可能差异巨大。矩阵用于发现问题，最终要向本人和计划数据核实。

运营步骤应与SOP 清单工作流衔接；若目标是追踪需求与验证证据，应采用需求追踪矩阵，不要塞进 RACI。

怎样确认、发布和维护矩阵？

会前发出范围、行定义、角色目录、证据链接和矩阵草稿。邀请实际的角色持有人和治理模型的负责人，而不只是审阅别人工作的经理。

一次审阅一行：

确认输出或决定及其完成条件；
根据实际运作流程确认 R；
根据授权记录确认 A；
确认必需的 C 和 I 关系；
检验冲突、缺勤、工作负荷和升级路径；
记录一致意见、异议、证据缺口和已批准的例外。

不要让工作坊变成一次组织重组会议。如果参与者发现缺少某个角色、授权不清或控制互不相容，就记录一项治理行动及其负责人。在该行动获批之前，这一 RACI 行保持未决。

怎样发布和维护矩阵？

发布记录应包含矩阵 ID、范围、版本、生效日期、来源版本、审批者、例外和变更日志。从实际使用它的程序和项目控制中链接到这份记录，以免职责变化后人们还在依赖某份导出副本。

定义变更触发条件，例如流程重新设计、阶段转换、供应商变更、授权更新、控制检查发现、团队重组、反复出现的交接失误，或具名角色出现空缺。只在政策要求时设定定期复核；按事件触发的复核往往更有用。

每次修订时，比较各行和各项分配，解释变化原因，重新取得确认，并按记录政策保留上一版本。姓名改变不一定意味着角色改变，角色头衔改变也不能证明权限已经改变。

NIST 的 AI RMF Core 要求记录角色、职责、问责、人类监督以及对 AI 风险的治理。［4］对 AI 辅助的起草过程也要同样严谨：写明谁提供证据、谁审阅建议、谁批准矩阵、谁监督其使用。

总结

以具体工作和决定限定 RACI 范围。
以获批角色和授权记录为真源。
先确认 R，再确认 A；默认每行一个 A。
C 是双向参与，I 是单向知会。
复核缺口、权限、负载、冲突与职责分离。
由角色持有人确认，并建立版本与触发器。

常见问题

AI 可以自动分配 RACI 角色吗？

不可以。它能整理证据和提示矛盾，但只有获授权的人能分配责任。职称本身不能证明权限或可用时间。

每行都必须恰好一个 Accountable 吗？

一个 A 是保持决定和升级清晰的默认方法。只有获批治理制度定义了共同权限和僵局处理时，才使用共同问责。

同一人可以同时是 R 和 A 吗？

可以，前提是该角色既执行又拥有结果，而且不违反职责分离规则；还要核对负载和审批权限。

某行没有 Responsible 怎么办？

把它当作运营模型缺口。不要指派最相近的职称，应确认谁拥有流程、能力、访问和义务并取得同意。

出现多个 Accountable 怎么办？

先检查该行是否混合多个决定或交付物，并按需拆分。若确为共同问责，要记录制度依据和升级方式。

Consulted 多少算太多？

没有通用数字。每个 C 都要有明确输入和时间；只需接收结果的人通常属于 I。

RACI 等同组织架构图吗？

不等同。组织图展示汇报关系，RACI 映射具体工作或决定中的参与方式；两者都不能自动证明授权。

多久复核一次 RACI？

在流程、阶段、供应商、授权、控制或团队变化时复核，也要遵守制度规定的周期。重复交接失败也是强触发器。

免责声明：本文仅提供一般责任设计信息；请遵守所在组织的治理、用工、控制、合同和记录要求。

来源：

UK Secure by Design — Agreeing Roles and Responsibilities — https://www.security.gov.uk/policy-and-guidance/secure-by-design/activities/agreeing-roles-and-responsibilities/
GOV.UK — Global HR Design Principles 2024 — https://www.gov.uk/government/publications/global-hr-design/global-hr-design-principles-2024-html
Northern Ireland Department of Finance — Programme and Project Management Tools and Techniques — https://www.finance-ni.gov.uk/articles/programme-and-project-management-tools-and-techniques
NIST — AI Risk Management Framework Core — https://airc.nist.gov/airmf-resources/airmf/5-sec-core/

Sources checked 2026 年 9 月 4 日。

如何用 AI 创建 RACI 矩阵，并分清执行、问责、咨询与知会