AI 風險台帳怎麼做？情境、控制、證據與剩餘風險範本
AI 風險台帳最常見的問題，是每一列都寫「幻覺、偏見、資安」，卻沒有指明哪個用途、誰受影響、透過哪條資料或工具路徑發生，也沒有可驗證控制與停止條件。這種台帳很難排序、無法交接，系統變更後也不會提醒團隊重評。
NIST AI RMF Core 的 Map 要理解脈絡、目的、範圍、人機監督與影響；Measure 要測量、記錄限制與控制有效性；Manage 則處理優先順序、剩餘風險、監控、事件與回復。Core 動作不是固定勾選表，Playbook 也是自願性建議；組織仍需依實際用途與權限裁剪，不能把完成台帳宣稱為法律意見、風險接受或合規認證。
一列只描述一個可判讀的風險情境
用「在某用途與條件下，某原因可能造成某事件，影響某對象與結果」來寫。例如：「客服 RAG 在撤權後仍從共用快取召回舊文件，可能讓不同租戶看見受限內容」。原因、事件、影響與邊界清楚後，才能選出檢索前 ACL、租戶快取鍵、撤權與跨租戶測試，而不是籠統寫「資料外洩」。
先用AI 風險初篩工具確認高影響、敏感資料、外部動作與可逆性，再從AI 事故類型資料庫參考具體失敗模式。未知資料要標成待調查，不能當成沒有風險。
把來源、影響與受影響者分開
來源可能是模型變異、不可信文件、資料過期、權限錯誤、工具契約、人工負荷或供應商變更；影響則可能是權益、安全、金錢、隱私、營運、聲譽與改善成本。記錄受影響者、規模、持續時間、可發現性與可逆性，並保存判斷依據和限制。不要只用單一平均分數讓重大個案被抵銷。
每個風險連到控制、Owner 與證據
控制欄位應寫實際實施層：政策、資料、IAM、程式、工具、人工或營運，而不是只寫「加強管理」。從企業 AI 控制措施資料庫挑選控制後，指定控制 Owner、實施位置、驗證方法、所需證據與失效模式。再到AI 稽核證據資料庫選擇設計、執行與有效性材料。
一個控制存在，不代表有效。RAG 寫了「禁止跨租戶」仍需候選文件、ACL 決策與撤權測試；Agent 有批准按鈕仍需請求 hash、參數變更、逾時與外部結果；監控有儀表板仍需告警送達、停止與接手演練。
分開記錄固有風險與剩餘風險
固有風險描述未考慮控制時的情境；剩餘風險則在控制經驗證後，記錄仍可能發生的機率、影響、不確定性與未完成缺口。不要把「已規劃控制」當成已降低，也不要用供應商宣稱替代實測。若風險超出組織容忍度，應限縮資料、用途、權限或維持人工／read-only，而不是只把評分改低。
風險接受必須由有權角色依明確期間、範圍、理由、監控、補償控制與到期作成，不能由工具或編輯部替組織批准。
設定停止條件與重新評估觸發
對重大失敗寫可執行條件，例如跨租戶內容出現在候選資料、未批准外部動作、找不到正式版本、刪除無法完成、告警無人接手或回復演練失敗。停止要連到撤權、停 queue、回切、轉人工與通知角色。
模型、prompt、資料、索引、工具、權限、供應商、使用者群體、法規／契約或錯誤後果改變時，觸發重新評估。用AI 變更影響分析器建立重測範圍，避免只靠年度排程。
用台帳管理改善，不用台帳掩蓋未知
每列保存風險 ID、用途與版本、情境、受影響者、依據、固有風險、控制、Owner、證據、驗證結果、剩餘風險、決策、停止條件、改善工單、到期與重評觸發。定期對帳正式清冊、事故、申訴、變更與監控，關閉風險前確認外部狀態與改善真的完成。