EU AI Act 第 10 條 vs 第 30 條：你的資料團隊需要了解的內容

如果你的組織在歐盟構建或部署高風險 AI 系統，EU AI Act 中有兩個條款將直接影響你的資料團隊的運作方式：第 10 條（資料和資料治理）和第 30 條（技術文件）。它們相關但不同——混淆它們會導致合規差距。

本文分解每個條款的要求、誰負責，以及它們在實踐中如何相互作用。

第 10 條：資料和資料治理

第 10 條關注的是準備訓練資料的流程。它為高風險 AI 系統的訓練、驗證和測試資料集的管理設定要求。

要求什麼

涵蓋以下方面的資料治理實踐：

• 資料收集和來源的設計選擇
• 資料準備操作（清理、標記、聚合）
• 相關性和代表性評估
• 對可能偏差的檢查
• 識別資料差距或不足

資料品質標準，包括：

• 訓練資料必須相關、充分代表且盡可能無錯誤
• 資料集必須適合 AI 系統的預期目的
• 統計特性必須被理解和記錄

偏差檢查：

• 必須對資料集進行可能導致歧視性結果的偏差檢查
• 識別偏差時，必須採取適當措施加以處理
• 檢查過程本身必須記錄文件

誰負責

第 10 條義務落在高風險 AI 系統的提供商身上——開發或委託 AI 系統並將其投放市場的實體。在實踐中，這意味著資料團隊、ML 工程師及其管理鏈。

實際挑戰

第 10 條要求你的資料準備流程是有記錄文件的且可稽核的。這是大多數企業面臨困難的地方——不是因為他們不清理資料或檢查偏差，而是因為這些步驟發生在分散的腳本、筆記本和臨時流程中，沒有統一記錄。

第 30 條：技術文件

第 30 條關注的是輸出——你必須為每個高風險 AI 系統產生和維護的文件。

要求什麼

技術文件必須包括：

• AI 系統、其預期目的和提供商的一般描述
• 系統要素的詳細描述，包括算法、資料、訓練流程和設計選擇
• 關於訓練資料的資訊：資料來源、範圍、主要特徵、收集方法論、標記程序及資料清理/準備方法
• 驗證和測試程序：指標、測試結果和性能基準
• 風險管理措施：識別的風險和緩解步驟
• 監控和更新計劃：部署後監控方法

誰負責

與第 10 條相同——提供商。但第 30 條文件還需要在要求時提供給市場監管機構。這意味著文件必須是有組織的、完整的且可存取的——不是埋在團隊 wiki 中或分散在 Git 提交中。

實際挑戰

第 30 條要求你產生一份連貫的文件（或文件集），描述你的整個 AI 系統，包括其訓練資料數據溯源。如果你的資料管道是一串不連接的工具，事後組裝這份文件既昂貴又容易出錯。

它們如何相互作用

將第 10 條視為流程要求，將第 30 條視為報告要求。它們是互補的：

第 10 條告訴你你的資料管道必須做什麼。第 30 條告訴你必須能夠證明它做了什麼。

大多數企業存在的差距

典型的企業 AI 管道具有某種形式的第 10 條合規——團隊確實清理資料、檢查偏差並驗證品質。缺少的是與第 30 條的連結：證明這些步驟發生了的文件，包括什麼資料、由誰執行，以及結果如何。

這個差距的存在是因為大多數資料管道由不連接的工具構建：

1. 攝入在一個工具中進行（Docling、Unstructured.io、自訂解析器）
2. 清理在 Python 腳本或筆記本中進行
3. 標記在 Label Studio 或 Prodigy 中進行
4. 品質評分在 Cleanlab 或自訂代碼中進行
5. 匯出在另一個腳本中進行

在每個邊界，稽核追蹤的連續性斷裂。攝入工具不知道清理腳本做了什麼。標記工具不知道在清理過程中過濾掉了什麼。品質評分器不知道它正在評估的資料的原始來源。

合規管道的樣子

為了同時滿足第 10 條和第 30 條，資料管道需要：

1. 統一日誌記錄：每個階段的每個操作都記錄在單一稽核日誌中
2. 操作員歸屬：誰執行或批准了每個步驟，帶時間戳
3. 資料數據溯源：能夠通過每次轉換追蹤任何輸出記錄回其原始來源
4. 品質指標：自動記錄品質分數、錯誤率和偏差評估
5. 匯出能力：一鍵生成滿足第 30 條格式要求的文件

這從根本上說是一個架構問題，而非合規補丁。在單一系統中處理完整管道的平台——如 Ertas Data Suite——將文件作為正常操作的副產品生成，因為每個階段共享相同的日誌基礎設施。

你的資料團隊現在應該做什麼

1. 稽核你目前的管道是否存在第 10 條差距：偏差檢查是否有記錄？資料治理實踐是否已書面說明？
2. 評估你的第 30 條準備狀態：你今天能否為你的 AI 系統產生完整的技術文件？
3. 識別數據溯源斷點：在你目前的工具鏈中，稽核追蹤連續性在哪裡失敗？
4. 為 2026 年 8 月做計劃：將合規內建到新管道中，而不是改裝到現有管道

執法截止日期正在臨近。從一開始就建入文件的成本是事後重建成本的一小部分。