企業 AI 專案誰負責？從業務 Owner 到資安法務的 RACI 分工
AI 專案失敗常不是模型不夠強，而是責任沒有被說清楚：業務期待技術團隊決定用途，技術團隊等待資料，資安與法務直到上線前才被通知。RACI 可以把 Responsible、Accountable、Consulted、Informed 四種責任寫進每項交付，但一張表不能取代真正有權決策的人。
先分清四個字母
- R 負責執行：實際完成工作，可以有多個。
- A 最終負責與批准：對結果承擔責任，通常每項只有一個。
- C 諮詢：在決策前提供專業意見，必須有雙向溝通。
- I 知會：接收結果或變更資訊，不負責批准。
若每一格都是所有人，RACI 就失去作用。尤其要避免沒有 A，或把外部供應商寫成公司內部風險的唯一 A。
七個常見角色
業務與流程 owner
定義工作問題、允許用途、基準、價值與人工接手，通常是使用情境是否值得繼續的 A。先完成AI 使用情境一頁簡報，讓責任對應具體工作。
產品或專案負責人
整合範圍、時程、需求、風險、決策與交付，確保每個未解問題有人負責，不代替資料、資安或法務作專業批准。
資料 owner
批准資料來源、用途、權限、品質、更新與刪除。資料工程師可以負責管線，但不應默認擁有業務資料的批准權。
技術與平台團隊
負責架構、整合、版本、測試、容量、監控與回復，說明技術限制與依賴。NIST AI RMF 的 actor 說明把設計、開發、部署、營運與治理視為不同工作，適合依專案規模拆角色。
資安、隱私與法務
依資料、威脅、契約與適用法律提供審查，對各自制度的例外接受要有明確權限。不能只在上線前收到通知，也不應讓他們替業務決定專案價值。
使用者與受影響代表
提供真實工作、例外與可用性回饋，參與測試與人機交接設計。高影響情境要考慮受影響者，而不只是付費部門。
供應商
對契約中的服務、安全、資料處理、事故與支援負責；公司仍要指定內部 owner 管理供應商與整體結果。
把 RACI 套到六個決策
- 情境與範圍：業務 A，專案 R，資料、技術、治理 C。
- 資料使用：資料 owner A，資料與技術團隊 R，隱私法務 C。
- 測試與門檻：業務或產品 A，技術與領域專家 R，治理 C。
- 正式上線：有授權的業務或治理主管 A，各控制 owner R。
- 事件處理：事件指揮 A，資安與系統團隊 R，法務、業務、供應商 C。
- 停用與退場：系統 owner A，技術、資料與採購 R，受影響部門 I。
這只是一般起點，實際 A 必須符合公司授權與專業要求。ISO/IEC 42001 說明 AI 管理系統需建立、實施、維護與持續改善，RACI 也應隨組織與系統變更複查，不是專案啟動時填一次。
RACI 會議的輸出
每項工作寫交付物、A、R、C、I、到期日、證據位置與升級路徑。把結果放入AI 系統清冊，事件則使用AI 事件紀錄模板。若角色沒有時間或權限執行，不能只在表上填名字，要降低範圍或補資源。
最後依AI PoC 到上線清單逐項確認 owner；沒有 A 的高風險控制，不應進入正式上線。