要用 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 矩陣，並分清執行、問責、諮詢與知會