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

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

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

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

法規實際上說了什麼

EU AI Act

EU AI Act 有數項條文直接涉及日誌要求：

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

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

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

第 12 條（記錄保存） 是最具體的日誌要求：高風險 AI 系統在建置時就必須具備在系統整個生命週期中自動記錄事件的能力。第 19 條和第 26 條第 6 項 訂下保留期的下限：提供者（第 19 條）和部署者（第 26 條第 6 項）必須保存這些自動生成的日誌，期限適合預期用途，最少六個月。日誌必須足以支持對決策的事後調查。

六個月只是下限。期限必須與預期用途相稱，因此驅動重大決策的系統通常需要把日誌保存到遠超過這個最低要求。EU AI Act 中以十年計的義務落在文件上：技術文件和歐盟符合性聲明必須保存 10 年（第 18 條和第 47 條第 7 項）。

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 第 11 條和附錄 IV 要求記錄整個管道，而不只是輸入和輸出。如果你的 AI 系統涉及檢索增強生成，檢索到的文件是決定輸出的輸入的一部分。如果預處理標準化或轉換輸入，那種轉換是血統的一部分。

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

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

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

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

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

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

儲存和保留

保留要求因框架而異：

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

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

Ertas Data Suite：內建稽核日誌

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

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

預約 Ertas 探索通話 →

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