稽核軌跡差距：大多數企業 AI 管道在不知情的情況下如何違反 EU AI Act 合規

要求大多數 AI 團隊提供其訓練資料的完整說明——來自何處、對其做了什麼、誰接觸過它，以及以何種形式用於訓練模型——他們無法做到。

不是因為他們疏忽，而是因為他們使用的工具不產生這份說明。典型資料準備堆疊中的每個工具都是獨立運作的，將輸出寫入共享資料夾，與之前發生的事情毫無關聯。結果是一個沒有可追溯歷史的訓練資料集——沒有血統、沒有稽核軌跡、沒有塑造它的決策文件。

根據 EU AI Act 第 10 條，對於高風險 AI 系統，這不只是技術差距，而是合規失敗。根據 HIPAA，對於醫療 AI，這可能構成對安全規則稽核控制要求的違反。隨著 2026 年 8 月 2 日適用截止日期臨近，許多企業 AI 團隊將在最糟糕的時刻發現這個問題。

---

AI 訓練資料稽核軌跡必須包含什麼

在審查為何大多數管道沒有稽核軌跡之前，值得精確說明合規稽核軌跡必須包含的內容。

根據 EU AI Act 第 10 條 和 第 11 條 / 附錄 IV 的技術文件要求，高風險 AI 系統的資料治理文件必須使監管機構或稽核員能夠重建：

• 資料來源：訓練文件來自哪裡？什麼系統、什麼資料擁有者、什麼收集方法？
• 資料選擇理由：為何包含這些資料？採用了哪些標準來包含或排除記錄？
• 預處理操作：在標注之前應用了哪些轉換？解析、清理、去重、標準化——包含方法和參數。
• 去識別化操作：檢測到了哪些 PII 或敏感資料，移除了什麼，使用了什麼方法，以及何時進行？
• 標注事件：誰標注了每條記錄，何時，使用哪些標注指南？標注者間一致性方法是什麼？
• 品質評估：應用了什麼品質評分，結果如何，低品質記錄如何處理？
• 擴充操作：是否生成了合成資料？使用什麼模型、什麼參數、來自哪些源樣本？
• 資料集版本和匯出：哪個具體的資料集版本用於訓練？其組成是什麼？

根據 HIPAA 安全規則 (45 CFR §164.312(b))，稽核控制必須記錄和審查包含或使用電子 PHI 的資訊系統中的活動。對於臨床 AI 訓練管道，這意味著對含有 PHI 文件的每次存取和轉換的日誌——誰、什麼、何時以及做了什麼。

根據 GDPR 問責原則（第 5(2) 條），控制者必須能夠證明符合所有資料保護原則。對於 AI 訓練，這包括證明處理有合法依據、只處理了必要的資料，以及資料按照既定目的處理。

這些框架的綜合要求匯聚到同一個運營需求：從源文件到匯出資料集，對訓練資料發生的一切的結構化、完整且可匯出的記錄。

---

為何大多數管道沒有稽核軌跡

典型的企業 AI 資料準備管道不是一個單一系統，而是一系列獨立工具，每個工具解決一個問題，每個工具將輸出寫入共享文件系統，沒有一個工具知道其他工具的存在。

典型管道如下：

Docling（或 Unstructured.io）解析源 PDF 並將 markdown 或 JSON 匯出到目錄。它不產生解析了什麼、做了哪些解析決策（多列佈局如何處理？表格中提取了什麼？）或源文件的來源的日誌。

清理腳本（自訂 Python、Cleanlab 或類似工具）讀取解析後的文本，去重，並將清理後的記錄寫入另一個目錄。它可能產生摘要日誌，但該日誌通常是一個存在於任何結構化記錄之外的文本文件，未與特定源文件關聯，也未以可查詢的形式保存。

Label Studio 讀取清理後的記錄並讓標注者對其進行標注。它維護自己的標注事件資料庫，但該資料庫未與 Docling 輸出中的源文件關聯，不包含源和標注之間發生的轉換資訊，並產生去除內部稽核元資料的匯出。

擴充腳本（Distilabel、自訂 LangChain 工作流程、直接 API 呼叫）生成合成變體並將其寫入目錄。通常沒有哪些源樣本用於生成哪些合成記錄的日誌。

匯出腳本 合併標注的記錄和合成資料，應用最終過濾，並寫入訓練就緒的 JSONL。每條記錄的來源——來自哪個源文件、經歷了哪些轉換、誰標注了它——在過程中丟失。

結果：一個可以查詢其內容但不能查詢其歷史的訓練資料集。監管機構問「給我看這條訓練記錄的稽核軌跡」，沒有答案。

---

共享血統問題

核心問題不在於個別工具缺乏日誌——大多數都有某種形式的內部活動日誌。問題在於這些日誌沒有連接。沒有一個共享識別符跟隨記錄從源文件穿過解析、清理、標注、擴充和匯出。

沒有共享識別符，你無法：

• 將訓練記錄追溯到其源文件
• 確定哪個標注者標注了特定記錄
• 識別哪些記錄是合成生成的而非來自真實文件
• 顯示在源文件中檢測到了哪些 PHI，並確認在記錄被標注之前已將其移除
• 產生對特定記錄執行的所有操作的完整時間線

這就是血統——在管道中正向和逆向追蹤資料的能力。這是資料目錄工具旨在為結構化企業資料提供的功能。對於 AI 訓練資料管道，血統幾乎完全缺失。

---

為何改造血統比一開始就構建更難

當團隊意識到需要稽核軌跡時，本能通常是改造：向現有腳本添加日誌、對現有工具進行儀器化、在現有管道之上構建資料目錄。

這種方法一致遇到問題：

追溯性日誌是不完整的：你可以為未來的運行添加日誌，但無法重建在沒有日誌的情況下已經處理的訓練資料的歷史。如果你的模型已經訓練完成，而你現在面臨監管審查，你需要的歷史不存在。

工具 API 不暴露內部決策：Docling 的輸出不告訴你它如何處理特定的佈局歧義。Label Studio 的匯出不告訴你為什麼跳過了一條記錄。你可以記錄工具運行了；你無法記錄它在內部做出的決策。

跨工具識別符不被維護：如果你想將 Label Studio 中的標注記錄與 Docling 輸出中的源文件以及去重腳本中的清理記錄關聯起來，你需要一個在攝入時分配並在每個工具中傳播的通用識別符。大多數工具不接受或保留外部識別符。

工作量隨工具數量增加：管道中的每個額外工具都是需要自訂儀器化的另一個整合點。7 個工具的管道不是 7 倍的日誌工作——而是 7 個潛在的失敗點，每個都需要自訂開發，每個都在失敗時創造差距。

從一開始就將血統構建到管道中——使用一個在所有階段維護來源的單一系統——在架構上比任何改造方法更簡單，並產生更完整的記錄。

---

合規稽核軌跡匯出實際上的樣子

EU AI Act 或 HIPAA 合規的有用稽核軌跡不是文本日誌，而是可查詢、可過濾並以可讀格式呈現給稽核員的結構化記錄。

對於最終訓練資料集中的每條記錄，稽核軌跡應能回答：

對於受 HIPAA 約束的臨床 AI 管道，PHI/PII 行需要額外細節：找到了哪些識別符、使用了什麼方法檢測它們、移除了什麼，以及輸出記錄不包含殘留 PHI 的確認。

在資料集層面，稽核匯出應包括：

• 按來源的總記錄數
• 品質分數分佈
• 標注覆蓋率和標注者間一致性（如適用）
• 合成記錄百分比和生成參數
• 按類別、標籤或文件類型的資料集組成

這就是第 11 條 / 附錄 IV「資料治理文件」在實踐中的樣子——決策和操作的結構化記錄，而非敘述性描述。

---

2026 年 8 月的緊迫性

高風險 AI 系統必須在 2026 年 8 月 2 日前符合 EU AI Act 要求。對於已部署的系統（「現有系統」），有過渡期——但對於在適用日期後開發或重大更新的系統，從部署開始就需要合規。

大多數受監管行業的企業 AI 專案不是一次性部署，而是涉及持續的資料收集、定期重新訓練、模型更新和擴展範圍。訓練資料集的每次更新都是需要符合第 10 條的資料治理的新處理事件。每個重新訓練的模型版本都需要更新的第 11 條技術文件。

等到 2026 年 8 月才考慮稽核軌跡要求的組織，將發現自己處於困難境地：要麼無法證明合規（因為歷史不存在），要麼必須在構建本應在一開始就構建的合規基礎設施時延遲部署。

---

Ertas Data Suite 如何彌補稽核軌跡差距

Ertas Data Suite 在所有五個管道階段——攝入、清理、標注、擴充、匯出——維護統一的專案記錄。每個操作都寫入共享稽核日誌：源文件識別符在攝入時分配並傳播到每個後續操作。沒有獨立工具之間的交接，沒有共享文件系統差距，沒有跨工具識別符問題。

稽核日誌匯出包括記錄級血統（源到最終訓練記錄）、操作級條目（誰在何時做了什麼）和資料集級摘要（組成、品質指標、標注覆蓋率）。匯出格式結構化用於技術文件，而非需要手動彙編。

清理模組記錄每個 PII/PHI 檢測事件——找到了什麼、移除了什麼、使用了什麼方法。標注模組在記錄層面記錄帶有標注者 ID 和時間戳的標注事件。擴充模組記錄哪些源記錄用於生成合成變體。匯出模組在訓練資料旁邊包含資料集清單。

對於面臨 2026 年 8 月 EU AI Act 截止日期——或今天 HIPAA 稽核要求——的團隊，稽核軌跡不是以後要添加的功能，而是合規運營的先決條件。

---

相關閱讀

• EU AI Act Article 10: What It Means for Your AI Training Data — 第 10 條資料治理要求及稽核軌跡必須文件化的詳細說明。
• On-Premise AI Data Preparation: The Compliance Guide for Regulated Industries — 涵蓋 GDPR、HIPAA、EU AI Act 和資料主權的完整合規概覽。
• What Is Data Lineage in Enterprise AI? — 資料血統的運作原理、為何對 AI 訓練管道重要，以及如何實施。