AI 系統稽核軌跡設計

為 AI 系統設計全面的稽核軌跡,支援鑑識調查、法規合規與事件回應。

概觀

AI 系統的稽核軌跡是系統生命週期中每個重要事件的時序紀錄:每個推論請求、每個組態變更、每個模型更新、每次護欄觸發與每次管理動作。若妥善設計,稽核軌跡使鑑識調查人員能精確重建發生了什麼、何時發生、誰或什麼造成的。

AI 稽核軌跡的重要性隨法規要求的出現戲劇性地成長。EU AI Act(Regulation 2024/1689)要求高風險 AI 系統包含「事件自動記錄(日誌)」,並有特定保留與細節要求。NIST AI Risk Management Framework 強調日誌與監控為 AI 風險管理的關鍵元件。除合規之外,稽核軌跡是 AI 鑑識的基礎——沒有它,事件調查會退化為臆測。

本文涵蓋 AI 系統稽核軌跡的設計原則、實作模式與營運考量。聚焦於使稽核軌跡對鑑識調查有用,同時符合法規要求並維持系統效能。

要記錄什麼

推論事件

每個推論請求與回應都應以足夠細節記錄以能重建互動。

AuditEventType 列舉定義事件類型:INFERENCE_REQUEST、INFERENCE_RESPONSE、GUARDRAIL_TRIGGER、MODEL_LOAD、MODEL_UPDATE、CONFIG_CHANGE、ADMIN_ACTION、ERROR、AUTHENTICATION、RATE_LIMIT。

AuditEvent 資料類別含 event_id、event_type、timestamp、model_id、model_version、event_data、user_id、session_id、source_ip、parent_event_id(用於關聯請求/回應對)、integrity_hash。

compute_integrity_hash(previous_hash) 計算鏈接的完整性雜湊以提供防竄改證據:每個事件的雜湊包含前一事件的雜湊,形成類似區塊鏈的雜湊鏈。任何事件被竄改都會破壞鏈。內容以排序鍵序列化 event_id、event_type、timestamp、model_id、event_data、user_id 與 previous_hash 後計算 SHA-256。

AuditTrailLogger 為 AI 系統提供結構化稽核軌跡日誌,具雜湊鏈、結構化事件類型與可查詢輸出。核心方法:

• log_inference_request(model_id, model_version, input_text, input_hash, user_id, session_id, source_ip, parameters):記錄推論請求。對隱私敏感部署記錄 input_hash 而非完整 input_text;retention 政策允許時才記錄完整文字。
• log_inference_response(request_event_id, ..., output_text, output_hash, latency_ms, token_count, finish_reason, guardrail_results):記錄推論回應,parent_event_id 指向對應請求。
• log_guardrail_trigger(request_event_id, ..., guardrail_name, trigger_reason, action_taken, scores):記錄護欄觸發事件。
• log_model_update(model_id, old_version, new_version, update_type, authorized_by, change_description, weight_hash):記錄模型更新。
• log_config_change(...config_key, old_value, new_value, changed_by):記錄組態變更。
• _emit(event):計算完整性雜湊並寫入 sink,前一雜湊設為剛計算的雜湊以維持鏈。

模型生命週期事件

除推論外,稽核軌跡必須捕捉模型生命週期中的事件。關鍵事件包括:training_start(訓練開始)、training_end(訓練結束)、evaluation(於基準評估)、checkpoint_saved(檢查點寫入)、deployment(部署至服務基礎設施)、rollback(回滾)、retirement(退役)、fine_tuning(微調)、quantization(量化)、safety_eval(安全評估)。

防竄改機制

雜湊鏈驗證

上述雜湊鏈提供防竄改證據:若任何事件被修改或刪除,鏈會在該點破裂。

AuditChainVerifier.verify_chain(events) 驗證稽核軌跡雜湊鏈完整性,以前一事件的雜湊重新計算每個事件的雜湊並與儲存雜湊比對。回傳結構:狀態(INTACT/BROKEN/EMPTY)、已檢查事件數、鏈破裂清單(位置、event_id、預期雜湊、儲存雜湊),以及第一個破裂位置。

外部時間戳

高保證環境中,稽核事件應由外部受信任時間戳授權機構(TSA)依 RFC 3161 提供時間戳。此措施防止取得稽核系統存取權的攻擊者回溯事件時間。

法規對齊

EU AI Act 要求(第 12 條)

EU AI Act 第 12 條規定高風險 AI 系統的日誌要求:

NIST AI RMF 對齊

NIST AI RMF 的 MEASURE 功能(MF-3.2)要求「追蹤與記錄 AI 系統效能、可信特性與衝擊」。稽核軌跡透過提供可查詢的系統行為歷史紀錄直接支援此項。

儲存與保留

儲存架構

AuditLogSink 是稽核日誌儲存後端的抽象基底,定義 write(event) 與 query(start_time, end_time, event_types, model_id, user_id, limit) 介面。

FileAuditLogSink 是僅能追加的檔案型實作,適用於單節點部署或作為轉發至集中式日誌系統前的本地緩衝。write 將事件以 JSON Lines 格式寫入當前檔案;query 逐檔讀取、依時間範圍、事件類型、model_id、user_id 過濾,並在達到 limit 時停止。

保留政策

不同事件類型依法規義務與鑑識價值有不同保留要求:

鑑識查詢模式

重建事件時間線

reconstruct_incident_timeline(sink, incident_start, incident_end, model_id) 查詢稽核軌跡以重建事件時間線。依 model_id 與時間範圍查詢事件、依時間戳排序,並為每個事件標註序號、時間差(自事件開始)、事件類型、事件 ID 與摘要。若有前一事件,亦標註與前一事件的時間差。

_summarize_event(event) 產生人類可讀摘要:推論請求附上輸入長度;護欄觸發附上護欄名稱與觸發原因;模型更新附上舊/新版本;組態變更附上變更鍵。

效能考量

稽核軌跡日誌為每個推論請求增加延遲。最小化效能衝擊的設計決策:

1. 非同步寫入:緩衝稽核事件並非同步寫入。記憶體緩衝區應有上限以防止記憶體耗盡。
2. 批次 I/O:將多個事件分組為單次寫入操作。
3. 獨立儲存路徑:稽核日誌不應與模型推論競爭 I/O 頻寬。
4. 高流量部署的採樣:每日處理數百萬請求的系統,考慮對可設定比例記錄完整細節,其餘僅記錄元資料。切勿降低護欄觸發或錯誤事件的日誌。
5. 雜湊鏈批次驗證:批次計算與驗證雜湊鏈,而非每個事件同步計算。

參考資料

• European Parliament. (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act). Article 12: Record-keeping. https://eur-lex.europa.eu/eli/reg/2024/1689
• NIST. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. https://doi.org/10.6028/NIST.AI.100-1
• OWASP. (2025). OWASP Top 10 for Large Language Model Applications. LLM09: Improper Output Handling. https://owasp.org/www-project-top-10-for-large-language-model-applications/