跳到主要內容

IL 301 · 模組 7

人機與治理審查

實際演練停用、復原、撤權與例外處理,確認治理機制不是紙上條款。

開始第一節
已完成 0 / 2

學習目標

  • 實際演練停用、復原與撤權三種治理動作,記錄每一種動作的完成時間與缺口。
  • 設計例外處理流程:誰能核准例外、例外的範圍與有效期限如何記錄。
  • 判斷治理審查是否可以確認 Pilot 具備進入 Adoption Gate 討論的治理基礎。

演練停用、復原與撤權

60 分鐘

三種治理演練

Module 1 定義了停止權,Module 5 在 Pilot 期間可能已經演練過一次異常應變。人機與治理審查要求團隊系統性地演練三種治理動作,並記錄實際耗時,而不是只在文件裡宣稱「可以隨時停用」。

三種治理演練與記錄重點
演練類型演練內容記錄重點
停用(Disable)立即停止 AI 自動回覆,全面轉回人工流程從下令到實際生效的時間、期間是否有案件卡在中間狀態
復原(Recovery)從停用狀態恢復 AI 輔助運作,確認資料與狀態一致恢復後是否需要重新驗證版本、有無資料遺失或重複處理
撤權(Revocation)撤銷特定帳號或工具的存取權限撤權生效時間、撤權後是否還能透過其他路徑存取

注意

常見錯誤:只演練「怎麼啟動」卻從未實際演練過「怎麼停用」。停用與撤權往往涉及跨系統操作,第一次演練經常會發現流程文件寫的步驟和實際系統操作有落差,這正是演練的價值所在。

重點: 沒有實際演練過的停用、復原、撤權機制,不能算是已經準備好;演練本身就是治理審查需要的證據。

例外處理與治理結論

60 分鐘

例外處理與治理結論

任何治理制度都需要處理「這個情況不在原本設計範圍內,但情況緊急」的例外。沒有明確例外流程的制度,往往在真正需要例外時被繞過,反而失去治理效力。

例外處理必填欄位
欄位說明
核准人具名或具體角色,且不能是提出例外請求的同一人
例外範圍具體限定哪些案件、哪些功能適用此例外,不能是「全面放寬」
有效期限例外必須有明確到期日,到期後自動失效,需要重新核准才能延續
事後審查例外結束後由治理審查者複核,確認例外期間沒有超出核准範圍
  1. 練習:治理審查總結(使用 SYN-CS-001)
    完成一份治理審查總結,作為進入 Module 8 導入重設計的前置條件。
  2. 步驟 1:填寫三種演練結果
    為停用、復原、撤權各寫一段實際演練紀錄,包含耗時與發現的缺口。
  3. 步驟 2:草擬一個例外情境
    假設「尖峰時段系統延遲,客服主管臨時要求暫時放寬信心門檻」,依例外處理必填欄位寫出完整記錄。
  4. 步驟 3:治理結論
    根據演練結果,判斷目前的治理機制是否足以支持進入 Adoption Gate 討論,或是否仍有 blocking 缺口需要先補齊。

資訊

治理審查的結論不是「通過或不通過」的二分結果,而是清楚陳述哪些治理能力已經驗證、哪些仍是缺口,讓 Module 9 高階主管簡報能誠實呈現風險,而不是隱藏未解決的治理問題。
自我檢測

客服主管在尖峰時段臨時要求「先暫時放寬信心門檻,讓 AI 多處理一些案件」。依照本模組的例外處理原則,下列哪一種做法最恰當?

客服主管在尖峰時段臨時要求「先暫時放寬信心門檻,讓 AI 多處理一些案件」。依照本模組的例外處理原則,下列哪一種做法最恰當?

重點: 例外處理如果沒有範圍、期限與事後審查,就會變成繞過治理制度的後門。

接下來做什麼?