AI 可以替團隊決定什麼？用權責表劃出建議與核准界線

把 AI 參與的工作分成可自動完成、只能建議與必須核准，並為每個決定指定負責角色、覆寫方式和例外路徑。

導入生成式 AI 後，團隊很快會遇到一個問題：AI 能把事情做完，不代表它有權替組織承諾結果。需要管理的不是每一句回答，而是每個決定會動用哪些資源、改變誰的權益、能不能復原。先把工作分成「可自動完成、只能建議、必須由人核准」，再標明最後決策者與例外出口，團隊才知道何時放手、何時停下。下面用一套權責表，把界線接到日常工作，從小型內部動作一路檢查到對外承諾。

列出 AI 參與決定

先別只列「客服」或「銷售」這類部門名稱，應把工作拆成可觀察的決定點：AI 收到哪些資料、挑了什麼選項、接著觸發什麼動作，以及動作影響誰。常見流程可拆成讀取、整理、分類、建議、寫入和對外承諾；權限要逐步指定，不能因前段已自動化，就把後段也交給 AI。每個決定點記下輸入來源、影響對象、失誤後能否撤回、是否涉及個人或商業敏感資料，以及誰能停止流程。再標示結果是純內部整理、會改變紀錄，還是會讓客戶、同事或合作方收到訊息。能重做、範圍窄、且不改變權利義務的步驟，才適合評估自動完成；價格、退款、聘用、存取權、承諾日期或對外發布，都應分開列，不能藏在「客服自動化」等大標題裡。假設訂單進件後，AI 可把地址整理成標準格式；它若判斷要加急，只能先標記待確認；若要改交期，則由具名的人決定。把決定點連到實際動作，團隊才不會把流暢回答誤當成組織授權，也能找出缺資料、範圍太大或應先交給人處理的環節。清單還要註明哪些決定只是暫存建議，避免日後有人把標記欄當成已核准結果。操作清單可從一筆最近發生的流程倒推：先找出 AI 讀取的欄位，再圈出它可以呼叫的後續動作，將「分類」和「派送」分成兩列。每列都寫明結果去向，例如只出現在內部工作清單，或會更新客戶資料；若不知道呼叫後會改什麼，就先視為不可自動執行。這份盤點不要求先選模型，而是確認每一步的授權邊界。盤點時也記下人工接手後如何回到佇列，避免同一案件被重複處理。

區分建議與核准

「AI 產生內容」和「AI 有權採取行動」要分開設定。可自動完成的項目，需有明確條件、有限影響、可回復方式與事後紀錄；只能建議的項目，可以排序或草擬，但不得寫入正式欄位、送出訊息或觸發付款；必須核准的項目，應由有權承擔結果的人先看見理由、依據與可能影響，再做確認。判斷時可問三件事：這個動作會不會讓外部的人以為公司已答應？會不會改變金額、權限或服務水準？出錯後能不能完整復原？只要答案牽涉重大承諾或難以撤回，就把核准放在人手上。下表是可自行調整的假設範例，折扣門檻並非任何品牌的既定政策：

例如團隊假設五趴以下折扣可由現有政策核准，但 AI 只可檢查條件並草擬理由；即使數字符合，也由負責人確認客戶、品項和有效期間後才送出。核准紀錄要對應同一筆案件與內容版本；修改金額或對象後，舊核准失效，重新確認。這樣可避免「曾經按過同意」被解讀成涵蓋後續變更。核准不能用事後抽查代替。若一項任務同時含草擬和送出，應拆開授權：AI 先產生草稿，人核對對象與內容後才按自己的權限送出。若流程無法拆開、也沒有清楚中止點，整段先降為只能建議。抽查用於發現偏差，不等於逐筆核准；不能以提高抽查頻率替代必要核准。

指定最終決策角色

每種會產生實際影響的決定，都要有一個明確的最終決策角色。角色可以因流程不同而不同，但同一筆事情不能只寫「主管核准」或「相關人員確認」；要指定職務、授權範圍、代理安排，以及有利益衝突時的替代人選。決策角色負責判斷是否接受建議、能否例外放行及如何承擔後續處理；執行者則負責照核准內容操作，兩者不一定要是同一人。資料維護者可確認來源是否完整，流程負責人可調整作業規則，卻不應因此自動擁有價格或權限變更的批准權。先為每類決定填出「提出者、建議者、核准者、執行者、被通知者」，再檢查是否出現無人負責、多人都以為別人會核准，或同一人提出並批准高影響動作的情形。假設 AI 發現客戶要求延後交貨，業務承辦人可補充對話與庫存資訊，AI 可列出可行選項；最後要由有交期授權的營運角色選定方案，客服依核准內容回覆。若營運角色不在，事先指定代理職務；若超出兩者授權，則暫停回覆並升到更高責任層級，而非讓模型自行挑一個看似合理的日期。把角色資訊放在流程入口可找到的位置，並在交接或組織調整時同步更新。這使核准權跟責任相連，也讓團隊知道該找誰解決卡住的案件。角色表還要註明授權依據由誰維護，以及暫代者可處理到哪個範圍；若只有特定主管能批准，就要提供案件暫存方式，不能因等待而讓流程自行放行。跨部門決定可讓多方提供意見，但指定一人作最終選擇，並記錄不同意見如何處理，避免多人共同負責最後變成無人負責。

設計人工覆寫方式

人工覆寫要能在工作流程中實際使用，而不只是文件裡的一句「必要時由人工介入」。先設計三個動作：暫停尚未執行的決定、撤回可逆的已執行動作、將單一案件交給指定角色。人員應能看見 AI 的建議、採用的資料、已發生的動作及撤回限制；如果不能復原，就明確標示尚未送出或已產生的外部影響，讓人改採補救流程。覆寫權也要有限度：一般承辦人可退回建議，授權主管可批准例外，系統管理者可暫停某類自動動作；停用範圍應盡量只涵蓋受影響的步驟，並留下恢復條件。每次覆寫記錄操作者、時間、案件、原建議、實際選擇和簡短理由，不必收集與處理無關的私密對話。假設 AI 把詢問退貨的訊息分到售前，客服可改派到售後並標記原因；若發現整批案件都被分錯，流程負責人先停用該分類的自動派送，再檢查錯誤來源，其他安全步驟仍可繼續。覆寫不是讓人無限改寫政策，也不能用來跳過核准；若人員想越過原有授權，仍須交給對應決策者。定期查看覆寫紀錄，找出常見誤判、規則模糊或資料缺漏，再修正流程條件。每次調整後都要重新確認哪些人可操作、何種情況可復原，以及發生外部影響時由誰接手。覆寫入口應靠近待執行動作，否則操作人得先搜尋流程說明，緊急時容易直接照常送出。也要清楚區分「退回這筆」與「暫停整類動作」的權限，避免一般承辦人誤停整條流程，或管理者只處理單筆卻漏掉共通故障。若動作已送到外部系統，覆寫要明確轉為補救與通知步驟，不能假裝刪除內部紀錄就等於影響已消失。

記錄例外升級路徑

權責表要寫出遇到例外時下一步做什麼。常見升級條件包括必填資料缺漏、來源互相矛盾、案件超過授權範圍、對象或金額無法核實、AI 找不到適用規則，以及同一類錯誤重複出現。觸發後先停止尚未完成的外部動作，保留足以判斷的必要資訊，再依風險送到第一責任角色；若該角色無法處理或逾越授權，再升到下一層。路徑應包含負責職務、替代窗口、要附上的背景、回覆期限由誰設定，以及等待期間如何告知受影響的人；不要只寫「通知管理員」，也不要讓無人回應的案件持續自動重試。紀錄目的在還原決定，不是把所有對話永久複製，所以只保留判斷所需的欄位，限制可讀取的人，並確認保存方式符合團隊既有資料管理規則。假設退款申請金額與訂單紀錄不一致，AI 不得選擇較高或較低數字代替判斷；它應停止送出、附上兩處來源及案件編號，交由退款授權人確認。若授權人無法判定，就升級給帳務或流程負責角色，並由承辦人告知客戶正在核對，不先承諾結果。若例外代表規則本身有缺口，案件結束後由流程負責人提出修訂，經原核准角色確認再啟用；不要在個別案件裡默默放寬條件。把升級結果回填到同一決定紀錄，可讓之後的人知道問題如何解決、規則是否更新。升級條件最好描述成可觀察事實，例如必要欄位缺少、兩份紀錄的數值不一致，而不是「看起來風險偏高」；後者要補上由誰判斷與依據。路徑還要明確指出案件等待時由誰持續回應，避免轉交後客戶找不到窗口，也避免 AI 在收到新訊息時重新啟動原本已暫停的動作。

用邊界案例桌上演練

上線前用桌上演練檢查權責表能不能真的指引行動。由一人扮演提出案件的人，一人扮演 AI 流程操作角色，一人扮演核准者，再安排觀察者逐項記錄：誰先看到資訊、何時停止自動動作、誰有權做決定、核准內容是否對得上執行內容，以及無人回應時案件落在哪裡。案例要刻意涵蓋正常情況與邊界：資料完整且可逆的內部整理、資料缺漏但客戶等待回覆、建議與既定政策衝突、已核准內容被修改、原核准者缺席、以及已對外送出後才發現錯誤。每題先讓參與者按流程作答，不要由主持人暗示正確角色；若答案分歧，代表表格缺少條件、責任人或升級路徑。假設演練中 AI 建議自動補償一筆延誤訂單，但規則只授權提出補償方案，沒有授權執行。觀察者應確認流程會不會先攔住對外訊息，再把訂單、建議和授權依據交給指定主管；主管拒絕後，執行端也不應因舊建議仍存在而送出。把發現的缺口改成可檢查的條件，例如哪些欄位必須齊全、哪些角色可批准、哪種變更會讓核准失效。演練結束後指定負責修表的人與複驗案例，直到不同角色都能得出一致處置，再逐步開放自動動作。現在可先挑一條會影響客戶或金額的流程，寫出決定點和核准角色，再到 ZhenheAI 首頁 了解品牌相關資訊。練習紀錄只需寫下情境、參與角色、實際走過的步驟、卡住的位置和修訂責任人；不要把模擬結果包裝成真實客訴或已驗證的營運改善。複驗時更換一個關鍵條件，例如資料來源改變或代理者接手，確認規則在角色輪替後仍能導出相同的安全處置。