AI 治理證據清單：從政策文件到可驗證的執行紀錄
企業建立 AI 治理制度後，常見的下一個問題是：「稽核時到底要拿出什麼？」只交一份政策，只能說明組織曾設計規則，不能證明正式系統有照規則運作，更不能證明控制能在錯誤、逾時、撤權或供應商變更時有效。相反地，把所有 prompt、輸入輸出與日誌永久保存，也可能增加個資、秘密與內部架構暴露。
NIST AI RMF Core 以 Govern、Map、Measure、Manage 描述成果，相關動作不是固定順序的逐項勾選表；NIST 也正進行 AI RMF 1.0 更新。NIST SP 800-53A 提供可依生命週期、風險與組織容忍度裁剪的控制評估方法。這些資料可用來設計證據思路，但不會自動構成法律意見、合規認證、稽核結論或所有用途都充分的證據清單。
先把證據分成設計、執行與有效性
設計證據回答「控制原本怎麼設計」，例如政策、流程、架構圖、資料保存矩陣、角色與門檻。執行證據回答「指定期間內有沒有照做」，例如版本化批准、發布 manifest、權限覆核、刪除結果與告警處置。有效性證據回答「遇到失敗條件是否真的阻擋或恢復」，例如跨租戶拒絕、no-go 阻止發布、冪等測試、回切及夜間接手演練。
只缺其中一層，判讀就會偏差。政策存在但未接入工作流，是設計沒有執行；每次都有批准截圖，但參數可在批准後改變，是執行紀錄無法證明有效。可先從AI 稽核證據資料庫挑選三層材料，再回到企業 AI 控制措施資料庫確認每份證據對應的控制目的。
每份證據要綁定範圍、版本、時間與 Owner
證據最少要回答：哪一個用途與環境、哪些模型／prompt／資料／索引／工具版本、涵蓋哪個時間、由誰產生與誰覆核、結果是什麼、是否有例外，以及什麼改變會讓它過期。沒有這些脈絡的截圖很容易過時，也無法證明畫面設定就是正式生效設定。
對動態控制，應保存機器可讀匯出、設定版本或查詢，而不是只拍畫面。對人工決策，保存有權角色看到的版本、請求 hash、批准／拒絕、理由、條件與到期。用AI 系統清冊先固定用途和資產，再用AI 系統變更資料庫定義變更後需重產哪些證據。
從實際系統反查，不只向 Owner 索取文件
清冊要和 API gateway、IAM、帳單、程式庫、採購與供應商清單對帳；資料流圖要用一筆正式工作逐跳確認；批准要與實際部署版本和工具參數核對；刪除政策要放入可追蹤測試資料，走到索引、快取、備份與供應商回覆。這種交叉驗證能找到影子 AI、孤兒權限、只有 UI 生效的遮罩，以及文件寫了但後端沒有阻擋的流程。
保護證據本身，避免為稽核製造新風險
證據遵循最小必要：不保存 token、金鑰原文；能用合成敏感標記就不用真實個資；能用 hash、版本 ID 或受控參照就不複製整份 prompt 和文件。限制誰能產生、改寫、查閱與匯出，保留查閱紀錄與完整性檢查，並依資料類型設定保存與刪除。若必須保存真實事件證據，應由有權角色依實際法規、契約與事件需求決定範圍。
用失效與過期條件維持證據可信度
每份證據都要有觸發重驗條件。模型、prompt、資料、索引、工具、權限、供應商、用途、受影響者或錯誤後果改變，都可能使舊證據失效。另設定週期性抽查，但不要把固定年度覆核當成唯一機制。可用AI 變更影響分析器產生重測起點，並在正式發布後持續觀察分版本與分群結果。
建立可交接的證據索引
不要把材料散落在聊天、信箱和個人硬碟。為每項控制建立證據 ID、用途、期間、Owner、位置、敏感度、版本、驗證方法、結果、例外、到期與改善工單。索引可以指向受控系統，不必把敏感原文集中複製。用AI 證據規劃器產生第一版清單後，交由業務、資料、資安、隱私／法務、IAM、平台與稽核角色依真實系統裁剪。