AI 稽核軌跡怎麼記？從模型版本、RAG 到 Agent 外部動作
AI 系統出錯時，團隊常只找到最後一段模型回覆，卻不知道當時使用哪個 prompt、檢索了哪些版本、呼叫者有什麼權限、人工批准看過什麼，或外部工具究竟成功幾次。稽核軌跡的目的不是「日誌越多越好」，而是讓一筆正式成果能用最小必要資訊重建決策與外部狀態。
NIST AI RMF Core 把文件化、透明度、角色、測試、部署後監控與事件處理放進 Govern、Map、Measure、Manage。NIST SP 800-218A 則補充生成式 AI 生命週期的安全開發實務。這些是可裁剪的風險管理與安全開發資源，不是固定日誌 schema，也不代表保存所有輸入輸出就符合任何法規或契約。
先定義一個跨系統共同工作 ID
從入口收到工作時建立不可猜測的工作 ID，傳到政策決策、模型、檢索、工具、queue、人工批准與外部系統。每個事件另有事件 ID、時間、環境、服務、動作與結果，並用 parent ID 表達呼叫關係。不要用使用者 Email、對話全文或秘密當關聯鍵。
抽一筆正式工作，應能從AI 稽核證據資料庫列出的「端到端稽核 Trace」回到用途、Owner、版本、權限、批准與外部結果。若跨系統時鐘不同，也要記錄時區、同步來源與可接受偏差，避免時間線顛倒。
記錄實際生效版本，不只記模型名稱
至少保存模型不可變版本或供應商回報版本、prompt／system policy hash、參數、輸出 schema、資料／索引 manifest、工具契約、政策版本與發布 ID。只寫「GPT」「最新版」或檔名 final 無法重現。對遠端別名和供應商設定，記錄請求時實際回報與變更偵測結果。
可用AI 系統變更資料庫整理哪些相依變更會影響評測與回復，再把每次發布的 manifest 和企業 AI 控制措施資料庫中的版本固定、發布閘門連接。
RAG 同時記查詢、權限決策與來源版本
RAG 不能只記最後引用。需要記錄呼叫者的角色／租戶參照、套用的 ACL 政策、查詢轉換版本、候選文件 ID 與版本、分數、被權限拒絕的數量、實際送入模型的片段參照及回答引用。對跨權限測試，確認候選文件階段就拒絕，而不是模型生成後才遮掉答案。
這些欄位可能揭露文件存在性，必須限制查閱。可使用合成資料測跨租戶與撤權，並以受控 ID 參照真實文件，不要把完整機密段落重複寫進 trace。
Agent 要記批准、冪等與外部真實狀態
Agent 的「我已完成」不是交易證據。每次工具呼叫記服務身分、工具與 schema 版本、目的地、經驗證參數、政策允許／拒絕、批准請求 hash、冪等鍵、重試、工具回應、外部交易 ID 與查詢後的實際狀態。多步驟流程還要記狀態轉移、部分成功、補償與人工接手。
用AI Agent 最小權限指南建立邊界，並在AI 測試案例庫加入逾時、回應遺失、重放、並發、參數變更與補償失敗案例。
敏感資訊採遮罩、參照與分層保存
不要把 token、金鑰、完整個資、機密文件或所有 prompt 原文直接寫入集中式日誌。欄位先允許清單化；敏感內容用遮罩、雜湊、分類與受控物件參照，必要原文放在更高權限、較短保存的證據區。對錯誤堆疊、HTTP header、工具參數與供應商回應特別測秘密洩漏。
不同日誌用途可有不同保存期：營運指標、可追溯 trace、批准／交易、資安事件和模型改善資料不必全部一起保存。保存與刪除應連到AI 資料外洩處理指南與組織真實的事件、隱私及契約流程。
驗證日誌可用，而不是只確認有寫入
定期隨機抽樣重建一筆生成、RAG 與 Agent 工作，檢查缺欄、共同 ID、時鐘、版本、權限、批准與外部結果。測日誌管線中斷、queue 堆積、輪替、延遲、重複、未授權修改與查閱。建立合成事件，確認告警能送達適任角色並保留接手證據。