AI 稽核軌跡：你需要記錄什麼以及監管機構為何會要求

稽核軌跡不是關於記錄一切，而是關於事後能夠回答具體問題：做出了什麼決策、由什麼系統、基於什麼輸入、在什麼時間、有什麼人類監督，以及接下來發生了什麼。

歐盟、美國和英國的監管機構正在趨向類似的問題。他們可能使用不同的法律語言，但核心要求是相同的：如果你的 AI 做出了一個重要決策，你應該能夠完整地重建它。

大多數企業 AI 部署今天無法做到這一點。以下是你需要什麼，以及每個監管框架要求什麼。

法規實際上說了什麼

EU AI Act

EU AI Act 有三條直接涉及日誌要求：

第 13 條（透明度） 要求高風險 AI 系統足夠透明，讓部署者能夠適當地解讀和使用輸出。系統必須提供可解讀的輸出——不只是決策，而是決策的依據。

第 17 條（品質管理系統） 要求高風險 AI 系統的提供者實施包括記錄保存程序、資料治理和上市後監控的品質管理系統。品質管理系統本身必須被記錄並可稽核。

附錄 IV（技術文件） 規定了必須記錄的內容：系統一般描述、設計和開發的詳細描述（包括訓練方法和訓練資料）、監控和評估措施，以及風險管理措施。這些文件必須維護並保持最新。

第 30 條 是最具體的日誌要求：高風險 AI 系統的提供者和部署者必須保存 AI 系統自動生成的日誌，期限適合預期用途，最少 10 年。日誌必須足以支持對決策的事後調查。

十年是很長的保留期。大多數工程團隊以週或月來考慮日誌保留。對於根據 EU AI Act 被分類為高風險的 AI 系統，義務長達十年。

HIPAA 技術保障措施 (45 CFR §164.312)

HIPAA 的技術保障要求適用於任何創建、接收、維護或傳輸電子受保護健康資訊 (ePHI) 的系統。如果你的 AI 系統接觸病患資料，以下適用：

• 存取控制：唯一使用者識別、自動登出、加密
• 稽核控制：記錄和檢查包含 ePHI 的資訊系統中活動的硬體、軟體和程序機制
• 完整性控制：驗證 ePHI 未被更改或銷毀的機制
• 傳輸安全：傳輸中的 ePHI 加密

這裡相關的是稽核控制要求。HIPAA 沒有規定具體記錄什麼，但 HHS 指導明確表示日誌應捕獲誰存取了什麼資料、何時以及為什麼。保留期：從創建或最後有效日期起 6 年。

SR 11-7（聯邦儲備 / OCC 模型風險管理）

聯邦儲備關於模型風險管理的 SR 11-7 指導要求銀行使用的模型具有涵蓋以下內容的文件：

• 模型目的和預期用途
• 理論和邏輯描述
• 資料輸入和假設
• 模型限制
• 驗證程序
• 持續性能監控

對於 AI/ML 模型，監管機構強調了記錄模型輸入、輸出和性能指標的重要性，以支持持續監控和失敗調查。關鍵原則是獨立驗證者必須能夠重現模型輸出——這需要推理時輸入和模型版本的完整日誌。

AI 稽核軌跡的 8 個最低要素

這八個要素涵蓋任何合規級 AI 稽核軌跡必須捕獲的最低要求。缺少任何一個都會創造監管機構會發現的差距。

1. 帶完整性雜湊的輸入資料

記錄呈現給模型的輸入——如果原始輸入太大，則記錄其表示。關鍵是包含輸入資料的密碼雜湊（SHA-256 是標準）。這讓你以後能夠驗證記錄的輸入是否與實際處理的相符。沒有完整性雜湊，記錄的輸入記錄可能被質疑。

對於包含 ePHI 的輸入，記錄對資料記錄的引用而非資料本身——但確保引用是明確的且雜湊涵蓋引用的內容。

2. 模型版本和配置

這是最常見的缺失要素。記錄處理請求的確切模型版本：不只是「GPT-4」，而是具體版本、檢查點或模型 ID。包含推理配置：溫度、top-p、最大令牌數、系統提示雜湊。

如果你無法在歷史推理時指定確切的模型版本，你就無法重建系統在那個時間產生的行為。這對任何監管審查都是關鍵差距。

3. 在可用時帶置信度或概率的輸出

記錄完整的模型輸出。對於分類任務，記錄置信度分數或概率分佈，而非只是最高預測。「已批准」的二元分類輸出遠不如「已批准（0.73 置信度）」有用——後者告訴你這是一個自信的還是邊緣的決策。

對於生成輸出，記錄完整文本。儲存是便宜的。在監管查詢期間無法產生驅動下游行動的確切輸出是昂貴的。

4. UTC 時間戳

記錄 UTC 時間戳，而非本地時間。監管調查通常跨越時區邊界。精確到毫秒的 UTC 消除了歧義。確保你的日誌基礎設施具有 NTP 同步——時間戳完整性很重要。

記錄請求收到的時間和回應返回的時間。延遲資料可能與性能調查相關。

5. 操作使用者或系統身份

誰或什麼觸發了這次推理？記錄人工發起請求的已認證使用者 ID，或自動管道請求的系統/服務識別符。這支持存取模式分析，並識別哪些使用者或系統參與了正在審查的決策。

不要記錄共享憑證。你 AI 管道中的每個操作者都應該有唯一的、可稽核的身份。

6. 在 HITL 適用時的人工審閱決策

如果你的系統包含人在迴路中的審閱——在驅動重要行動之前審閱 AI 輸出的人——明確記錄審閱結果。誰審閱了、何時、做了什麼決定，以及是否覆蓋了 AI 建議。

人工審閱通常是監管機構對高風險決策最感興趣的。「AI 將其標記為高風險」如果沒有「且有執照的專業人員審閱並同意/不同意」就是不完整的。

7. 採取的下游行動

記錄 AI 輸出的結果。分類本身是沒有意義的——你的系統對其做了什麼？記錄下游行動：索賠已批准、申請被標記待審閱、文件被路由到 X 部門、警報發送給 Y。

這在 AI 決策和現實世界後果之間建立了閉環。它讓你能夠回答「系統在 3 月 5 日對病患 12345 做了什麼？」

8. 任何覆蓋或升級

當人工覆蓋 AI 決策，或觸發例外流程時，將其明確記錄為覆蓋事件。如果你的工作流程捕獲了原因，則包含原因。這些資料對監管目的和模型改進都有價值——系統性覆蓋表明模型在哪裡校準不當。

血統差距

大多數考慮過這個問題的團隊已經涵蓋了輸入和輸出日誌。差距在中間：轉換管道。

你的 AI 輸出不只是原始使用者輸入的函數，而是檢索結果、預處理步驟、上下文組裝、提示模板和系統指令的函數——這些都可能沒有被記錄。

EU AI Act 第 30 條要求記錄整個管道，而不只是輸入和輸出。如果你的 AI 系統涉及檢索增強生成，檢索到的文件是決定輸出的輸入的一部分。如果預處理標準化或轉換輸入，那種轉換是血統的一部分。

映射原始輸入和模型呼叫之間的每個轉換步驟，並記錄每個步驟。這比記錄邊緣更難——但這是監管機構在調查具體決策時尋找的內容。

監管機構在稽核中實際上看什麼

進行 AI 稽核的監管機構不讀取每個日誌條目，而是採樣並提出具體問題。

模式是：一個具體決策正在審查中（一個被拒絕的索賠、一個被標記的交易、一個高風險分類）。監管機構想要完整地重建那個決策。他們會要求那次具體推理的記錄——輸入、模型版本、輸出、人工審閱、下游行動。然後他們會檢查完整性：所有 8 個要素都存在嗎？時間戳一致嗎？模型版本有記錄嗎？有人類監督的證據嗎？

如果正在審查的具體決策缺少任何要素，那就是一個發現。如果稽核軌跡無法確認在特定日期運行的是哪個模型版本，那就是一個發現。如果政策要求人工審閱但日誌中沒有記錄，那就是一個發現。

實際含義：你的稽核軌跡基礎設施需要讓個別記錄查找快速，並確保在寫入時的完整性——而非作為定期批次檢查。

儲存和保留

保留要求因框架而異：

• HIPAA：從創建或最後有效日期起 6 年
• EU AI Act（高風險系統）：最少 10 年
• SR 11-7：沒有明確規定，但銀行檢查週期表明實踐中為 5 到 7 年
• FDA SaMD：與產品生命週期一致，通常為 2 年或產品生命週期中較長者

針對你監管環境中最長適用期限進行設計。分層儲存（近期記錄使用熱存儲，舊記錄使用冷存儲）在保持可及性的同時管理成本。確保冷存儲對特定記錄檢索有索引——需要完整恢復才能查詢的批次存檔存儲不是稽核就緒的。

Ertas Data Suite：內建稽核日誌

對於 AI 資料準備管道——產生訓練資料、微調資料集和標注語料庫的上游工作——Ertas Data Suite 記錄每個帶時間戳、操作員 ID 和所應用操作完整記錄的轉換步驟。每個攝入、清理、標注、擴充和匯出操作都是不可變稽核鏈的一部分。

平台直接匯出符合 EU AI Act 第 30 條的技術文件。對於資料準備管道本身受稽核的受監管企業，這意味著血統預設已被捕獲——而非事後重建。

預約 Ertas 探索通話 →

稽核軌跡不是你在構建系統後添加的東西，而是需要從一開始就在設計中加入的東西。在生產 AI 系統中改造全面日誌的成本，一致高於第一次就正確構建的成本——而在監管查詢期間遺漏它的成本更高。