AI 專案跨 HR、IT、營運三個主管，誰能說了算？一張權責表避免「三方都同意、沒人負責」

教學方法專題｜案例、時程與表單為編輯設計示例，非客戶實績或已完成的產品實測。

核心答案：HR 希望加快新人訓練，IT 擔心帳號權限，營運認為內部資料不完整。三方都說支持 AI，但三個月後專案仍未開始。問題不是缺少共識會議，而是沒有區分「誰有最終業務責任」與「誰有不可被跳過的安全否決權」。

專題編輯：Iris Hsieh｜高階主管、轉型專案負責人

圖說：天地人原創編輯流程圖，為教學示意，非真實企業現場或產品操作畫面。

「共同決策」常被誤用為「責任不明」

跨部門 AI 專案常有多個利害關係人，但不等於每項決定要三位主管共同負責。應把決策拆開：業務是否值得做，由流程擁有者負責；技術是否可安全實作，由 IT 與資安提出不可逾越條件；人員培訓是否達標，由 HR 或人才發展主管評估。當某項風險超出公司既有政策時，應循正式風險核准機制，不可用主管投票取代資安規範。

一張表分清五種權限

這是可依公司治理調整的示範權責表，不是法律強制規定的單一標準。重點是每一項決策只有明確的決定者，並保留安全、合規與資料權限的獨立控制。

一個最容易衝突的案例

HR 想用 AI 分析員工教育訓練的需求，營運想加入工作績效資料，IT 則認為目前沒有合法核准的資料合併目的。正確程序不是要 IT「配合業務需求」，而是先釐清目的、最小資料範圍與合法使用條件。若無法取得合規資料，專案應縮小成匿名化、任務層級的訓練需求分析；仍有疑義時就停止。

同樣地，即便 IT 可以技術上提供某個 API，也不代表可以替業務決定對客戶的正式承諾。可做到與被授權做到，是兩件事。

決策卡：讓會議結束後有人能採取行動

每次決策記錄八欄：decision_id、待決問題、可選方案、業務決定者、風險會簽者、決議日期、剩餘風險、下次檢視時間。超過期限未決時，由指定的專案贊助人召開升級會議，但不得繞過硬性合規門檻。

會議摘要提示詞：

請將以下不含機密資訊的 AI 專案會議紀錄轉成決策卡。只列出已明確決議事項；任何尚未核准的資料存取、系統寫入與個人資料處理，標示「未授權」。不得根據與會者語氣推測已經同意。另列待確認責任人與截止日期。

衡量治理是否生效

不看開了多少協調會議，而看有多少決策有主人、多少風險在正式上線前被阻擋、多少阻塞能在合理時限內被解除。NIST AI 風險管理框架強調治理、監測、應對與持續改進；企業可以把這些原則轉成具體的決策權責，而不是再增加一層空泛的 AI 委員會。

做決策之前，先指定哪一種問題由誰決定

「能不能購買工具」是採購與預算問題；「工具能不能讀取資料」是資料授權與風險問題；「成果是否能交付客戶」是營運品質與契約問題。若把三件事放在同一張會議決議中，通常會因為有人對其中一項有疑慮，而整案停滯。把問題拆開後，能先核准低風險的準備工作，同時對未解決的高風險項目維持阻擋。

用四個衝突題目測試權責表

當 HR 希望導入 AI 排班建議，但資安認為資料集含敏感資訊，是否可以退回合成資料進行流程教學？當 IT 表示工具可安裝，但採購合約尚未簽署，誰有權開始付費？當營運要求 AI 自動寄送客戶通知，但客服主管尚未確認文字及補救責任，誰有權停止？當專案已上線但出現異常，由誰先暫停、誰批准恢復？

這四種測試要能在會議結束時指出唯一的業務決策者、必要會簽及安全否決條件。若仍回答「大家共同決定」，權責表就還沒完成。

避免把決策速度當成唯一 KPI

有些延遲是資訊不足，應補證據；有些延遲是責任沒指定，應升級協調；有些延遲是風險未解除，則停止才是合格結果。專案管理者可以追蹤每種原因的案件數與解決時間，但不能把「最少被資安阻擋」當成管理績效。

圖說：依本文工作方法繪製的原創示意流程；並非系統實測畫面。

讀者可立即使用的工作資產

範本：ai_decision_rights.csv 教學工作包（ZIP）。此檔案包含教學用的示例資料，不是實際企業統計或已完成測試的證據。

資料來源與適用邊界

• NIST：Artificial Intelligence Risk Management Framework: Generative AI Profile。
• NIST：AI RMF Core。
• OWASP：AI Agent Security Cheat Sheet。

本篇以官方文件與通用流程治理原則為基礎，並提出原創工作方法；不代表對任何企業租戶、ERP 版本或 AI 產品完成實機測試。價格、方案、法規與功能會變動，採購或正式部署前應與供應商、IT、資安及資料責任人查證。教學數據與案例均為模擬。

讀者下一步： 將範本帶回企業，先由實際流程擁有人確認現況與限制，再決定是否需要企業內訓或 AI 導入試點。