為 AI 訓練資料建立不可變稽核追蹤：技術要求

當 EU AI Act 表示 AI 系統必須維護其操作記錄時，並不意味著「在某處保存日誌文件」。它的意思是可驗證、防篡改的記錄，稽核員可以獨立確認這些記錄自創建以來未被修改。記錄必須涵蓋訓練資料的整個生命週期——從初始收集到每個處理步驟，直到在模型訓練中的最終使用。

這是一個工程問題，而非政策問題。你無法用治理文件或手動記錄流程來解決它。你需要一個使修改歷史記錄不可能的技術系統——不只是困難，不只是可稽核，而是在架構上不可能。

本文涵蓋建立此類系統的技術要求：「不可變」在實踐中的含義、架構選項、在每個管道階段記錄什麼、儲存要求和整合考量。

「不可變」在此情境中的含義

稽核追蹤情境中的不可變性有一個特定的技術定義：一旦記錄被寫入，任何用戶、管理員或系統流程都無法修改、覆寫或刪除它。記錄在其整個保留期間以原始形式存在。

這比大多數記錄系統提供的保證更強。寫入文件的典型應用程式日誌可以被任何有文件系統訪問權限的人編輯。資料庫日誌可以被任何有寫入權限的人更新或刪除。即使是大多數資料庫中的「僅附加」配置也可以被管理員規避。

真正的不可變性需要以下一個或多個技術機制：

一次寫入儲存：在寫入後物理上或邏輯上防止修改的儲存媒體或配置。AWS S3 Object Lock、Azure Immutable Blob Storage 和 WORM（一次寫入多次讀取）儲存系統在儲存層提供此功能。對於本地部署，NetApp SnapLock 和類似技術在本地硬體上提供 WORM 儲存。

密碼學鏈接：每個日誌條目包含前一個條目的哈希值，創建一個修改任何單個條目都會使所有後續條目無效的鏈。這與區塊鏈使用的原理相同，但不需要分散式共識開銷。

數位簽名：每個日誌條目由記錄系統持有的私鑰簽名。對應的公鑰允許任何人驗證條目是由授權系統創建的，且未被修改。

具有行級安全的僅附加資料庫：具有適當行級安全策略的 PostgreSQL 可以防止對稽核表的 UPDATE 和 DELETE 操作，同時允許 INSERT。這是最弱的不可變性形式——資料庫管理員仍然可以規避它——但結合密碼學驗證，它提供了合理的保證。

對於 EU AI Act 合規，實際最低要求是帶有密碼學完整性驗證的僅附加儲存。稽核員應該能夠獨立驗證日誌未被篡改。

架構選項

選項 1：帶密碼學哈希的僅附加資料庫

對於擁有現有 PostgreSQL 基礎設施的團隊，這是最直接的方法。

實施：

創建一個具有僅插入權限的專用稽核架構
每個日誌條目包含其內容的 SHA-256 哈希值加上前一個條目的哈希值（哈希鏈）
行級安全策略防止對稽核表的 UPDATE 和 DELETE
一個單獨的驗證服務定期驗證哈希鏈完整性
將哈希鏈檢查點匯出到不可變的外部儲存用於獨立驗證

優點：使用現有資料庫基礎設施、快速查詢、熟悉的工具。

限制：具有超級用戶訪問權限的資料庫管理員可以繞過行級安全。通過以下方式緩解：(a) 將超級用戶訪問限制於帶有單獨記錄的緊急情況，(b) 將哈希檢查點匯出到 DBA 不控制的單獨系統，(c) 使用與生產資料庫不同管理員的單獨稽核資料庫。

成本：除現有 PostgreSQL 基礎設施外幾乎沒有額外成本。哈希計算每個日誌條目增加不到 1 毫秒。

選項 2：用於資料集版本控制的 Merkle 樹

Merkle 樹對資料集中的每條記錄進行哈希，然後對哈希對進行哈希，然後對這些哈希對進行哈希，直到得到單一根哈希。根哈希唯一標識資料集的確切內容。在單條記錄中更改一個字符，根哈希就會改變。

實施：

當資料集版本最終確定時，計算其 Merkle 樹根哈希
將根哈希存儲在防篡改位置（已簽名、加時間戳、匯出到不可變儲存）
要驗證資料集版本，重新計算其 Merkle 樹並比較根哈希
要識別版本之間哪些記錄發生了變化，比較中間哈希（高效差異比較）

優點：大型資料集的高效驗證（你可以通過檢查單個根哈希來驗證 100 萬條記錄的資料集）。版本之間的高效差異比較。具有良好安全屬性的標準密碼學原語。

限制：Merkle 樹驗證資料集完整性，但不捕獲過程（誰在何時做了什麼）。將 Merkle 樹用於資料集版本控制，同時使用單獨的日誌鏈記錄操作歷史。

成本：為 100 萬條記錄的資料集計算 Merkle 樹需要 2-5 秒。在資料管道的情境中可以忽略不計。

選項 3：已簽名的日誌條目

每個日誌條目使用由硬體安全模組（HSM）或金鑰管理服務管理的私鑰進行數位簽名。

實施：

記錄服務持有一個簽名金鑰（理想情況下在 HSM 中以防篡改）
每個日誌條目被序列化為規範格式並簽名
簽名與日誌條目一起存儲
驗證只需要可以自由共享的公鑰
可信時間戳機構（TSA）提供獨立的時間戳驗證

優點：每個條目都可以獨立驗證——無需驗證整個鏈就可以驗證單個條目。可信時間戳提供條目創建時間的獨立證明。這是用於法律和監管目的的最強形式的證據。

限制：HSM 基礎設施增加了複雜性和成本。TSA 整合需要對時間戳機構的網路訪問（儘管時間戳可以批量處理）。

成本：HSM 租用或購買（雲端 HSM 每年 $500-$5,000，本地硬體 HSM $10,000-$50,000）。TSA 服務對中等使用量通常是免費或低成本的。

對大多數企業的推薦方法

結合選項 1 和 2：用於操作日誌的帶哈希鏈的僅附加資料庫，以及用於資料集版本完整性的 Merkle 樹。如果你的風險狀況或監管解釋需要最高保證級別，添加選項 3（帶可信時間戳的已簽名條目）。

這種組合提供：操作級不可變性（哈希鏈接的日誌條目）、資料集級完整性驗證（Merkle 樹），以及安全性和操作複雜性之間的實際平衡。

在每個管道階段記錄什麼

日誌記錄要求特定於資料管道的每個階段。以下是完整規範。

攝取階段

- 源文件路徑或 URI
- 源文件哈希（原始文件的 SHA-256）
- 源文件格式（PDF、DOCX、HTML 等）
- 源文件大小（字節）
- 提取方法（使用的解析器、版本）
- 提取時間戳
- 操作員 ID（發起攝取的人員）
- 輸出記錄計數
- 提取置信度分數（用於 OCR）
- 提取期間的任何錯誤或警告

清理階段

- 輸入資料集版本 ID
- 清理操作類型（OCR 糾正、去重、正規化等）
- 參數（應用的閾值、字典、規則）
- 已處理記錄數
- 已修改記錄（計數和百分比）
- 已刪除記錄（計數、百分比和刪除原因）
- 前後樣本（3-5 個有代表性的例子）
- 清理時間戳
- 操作員 ID
- 輸出資料集版本 ID

標注階段

- 輸入資料集版本 ID
- 標注方法（手動、模型輔助、全自動）
- 標注員 ID
- 標注模式版本（使用的分類法）
- 應用的標注（按類別分布）
- 置信度分數（用於模型輔助標注）
- 審查狀態（已審查/未審查）
- 標注員間一致性分數（如果有多個標注員）
- 標注時間戳
- 操作員 ID（用於監督）
- 輸出資料集版本 ID

增強階段

- 輸入資料集版本 ID
- 增強方法（同義詞替換、反向翻譯、合成生成等）
- 參數（用於生成的模型、溫度、採樣方法）
- 生成的合成記錄計數
- 應用的品質過濾（有多少生成的記錄被拒絕及原因）
- 增強時間戳
- 操作員 ID
- 輸出資料集版本 ID

匯出階段

- 輸入資料集版本 ID
- 輸出格式（JSONL、CSV、Parquet 等）
- 輸出模式版本
- 匯出中的記錄計數
- 輸出文件哈希（SHA-256）
- 目標（模型訓練管道 ID、儲存路徑）
- 匯出時間戳
- 操作員 ID
- 匯出資料集的 Merkle 樹根哈希

儲存要求

稽核日誌儲存是一個長期承諾。對於高風險 AI 系統，保留要求實際上是系統壽命加上合理的退役後期限。標準解釋是最少 10 年。

每條條目大小：典型的結構化日誌條目（JSON 格式，包含上述所有字段）為 500 字節到 2KB，取決於階段和參數數量。平均：約 1KB。

使用量估算：一個每天處理 5,000 條記錄的中等活躍資料管道大約生成：

每天 5-10 個攝取日誌條目（批次攝取）
每天 10-20 個轉換日誌條目
每天 50-100 個標注日誌條目（每個標注會話一個）
每週 5-10 個匯出日誌條目

總計：每天約 100-150 個日誌條目，或每年約 50,000 個。

以每條條目 1KB 計：每年約 50MB 的原始日誌資料。10 年後：500MB。

這是微不足道的小。儲存成本不是限制因素。限制因素是完整性——確保 500MB 資料在儲存遷移、硬體更換和組織變更期間 10 年保持未修改。

建議：將稽核日誌存儲在至少兩個獨立位置，並進行獨立完整性驗證。如果一個副本被破壞，另一個提供參考。對於本地部署，這意味著由不同團隊管理的兩個單獨的儲存系統。

對於資料集快照：完整的資料集快照更大——10 萬條記錄、每條記錄 2KB 的資料集為 200MB。在 10 年內存儲 50 個資料集版本為 10GB。仍然可以管理，但要為歷史版本規劃壓縮歸檔儲存。

與現有系統的整合

大多數企業已經擁有記錄基礎設施。AI 資料管道的稽核追蹤應該與現有系統整合——而不是取代它們。

ELK Stack（Elasticsearch、Logstash、Kibana）

如果你的組織使用 ELK 進行集中記錄：

將 AI 管道稽核日誌發送到具有一次寫入索引生命週期管理的專用 Elasticsearch 索引
使用 Kibana 儀表板創建面向稽核員的視圖
將哈希鏈驗證添加為自訂 Logstash 過濾器
限制：Elasticsearch 本機不提供密碼學不可變性——將哈希鏈驗證添加為應用程式層檢查

Splunk

Splunk Enterprise 提供具有防篡改功能的「合規」部署模式：

為具有完整性驗證的 AI 稽核日誌配置專用索引
使用 Splunk 內建的資料完整性驗證來檢測篡改
為常見稽核查詢創建帶有保存搜索的面向稽核員的儀表板
限制：Splunk 的防篡改檢測基於哈希，而非預防——它在事後檢測修改，而非預防修改

專用稽核系統

對於需要最高保證級別的組織：

專用僅附加資料庫（與操作資料庫分開）
HSM 支持的每個日誌條目簽名
獨立時間戳機構整合
具有只讀視圖和匯出功能的稽核員訪問門戶
持續運行的自動完整性驗證

Ertas Data Suite

Ertas Data Suite 本機實施不可變稽核記錄。平台中的每個操作都生成一個帶哈希鏈、加時間戳的日誌條目，帶有操作員識別。資料集版本使用 Merkle 樹根哈希跟踪。稽核追蹤在應用程式層是僅附加的，可以匯出到外部不可變儲存用於獨立驗證。

對於從零開始建構合規基礎設施的團隊，這消除了 2-3 個月在記錄和溯源系統上的工程工作。平台處理技術要求——哈希鏈、完整性驗證、資料集版本控制、操作員跟踪——因此合規團隊可以專注於文件和流程要求。

實施時間線

對於從零開始建立不可變稽核追蹤基礎設施的團隊：

第 1-2 週：設計每個管道階段的日誌模式。定義哈希鏈機制。選擇儲存後端。

第 3-4 週：實施記錄服務。在每個管道階段添加日誌生成。實施哈希鏈計算。

第 5-6 週：實施完整性驗證——一個端到端驗證哈希鏈並報告任何中斷的服務。實施資料集版本哈希（Merkle 樹）。

第 7-8 週：建立面向稽核員的介面——對日誌、溯源視圖和資料集版本比較的只讀訪問。實施用於獨立驗證的日誌匯出。

第 9-10 週：測試。嘗試篡改日誌並驗證檢測。用真實使用量進行負載測試。僅使用系統的證據進行模擬稽核。

總計：2-3 名工程師團隊需要 10 週的工程工作量。這可以與其他合規衝刺活動並行運行。

對於採用 Ertas Data Suite 的團隊，時間線壓縮到 2-3 週——主要是資料遷移和配置，而非工程工作。