EU AI Act 第 10 條實施手冊：從原始資料到合規管道

EU AI Act 第 10 條是直接影響資料團隊的條款。雖然其他條款涉及系統層面的要求、風險管理和透明度義務，但第 10 條專門針對訓練、驗證和測試資料。它規定高風險 AI 系統必須如何處理塑造其行為的資料。

問題在於第 10 條是用法律語言撰寫的。它說的是「訓練、驗證和測試資料集應受到適合 AI 系統預期目的的資料治理和管理實踐的約束。」正確，但無法付諸行動。閱讀這句話的資料工程師無法開始編寫代碼。

本手冊將每項第 10 條要求轉化為具體的工程任務。對於每個子條款，你將獲得：法律要求、實際含義、所需的具體工程工作，以及證明合規的文件範本。

第 10(2)(a) 條：資料治理和管理實踐

法律要求：「訓練、驗證和測試資料集應受到適合 AI 系統預期目的的資料治理和管理實踐的約束。」

實際含義：你需要一個記錄文件化的系統，用於在整個生命周期內管理訓練資料——從收集到退役。「適合預期目的」意味著治理必須與風險成比例。高風險信用評分系統需要比內部文件搜索工具更嚴格的治理。

工程任務：

1. 建立資料治理政策文件，涵蓋：

   • 誰負責訓練資料品質（具名角色，而非團隊）
   • 資料進入管道前需要什麼審批流程
   • 如何報告和解決資料品質問題
   • 多久審查一次資料品質
   • 資料品質低於閾值時如何處理

2. 在訓練資料上實施基於角色的存取控制：

   • 資料管理員：可以批准資料來源和品質閾值
   • 資料工程師：可以在批准的參數範圍內處理和轉換資料
   • 標注員：可以根據批准的指南標記資料
   • 稽核人員：對資料、日誌和文件的只讀存取
   • 在管道工具中定義這些角色，而不只是在政策文件中

3. 創建資料登記冊，追蹤：

   • 用於訓練、驗證和測試的所有資料集
   • 每個資料集的當前版本和狀態（草稿、已批准、使用中、已退役）
   • 每個資料集的指定資料管理員
   • 品質報告、偏差評估和差距分析的連結

文件範本：

Data Governance Policy — [System Name]
1. Scope: This policy applies to all training, validation, and testing data for [system name].
2. Roles: Data Steward: [name]. Data Engineers: [names]. Annotators: [names].
3. Approval Process: New data sources require Data Steward approval before ingestion.
4. Quality Thresholds: [defined metrics and minimum values]
5. Review Cadence: Quality review conducted [monthly/quarterly].
6. Issue Resolution: Quality issues reported via [system] and resolved within [timeframe].

第 10(2)(b) 條：資料集的設計選擇

法律要求：訓練資料應受「相關設計選擇」的約束。

實際含義：記錄你為何選擇這個特定資料集。你考慮了哪些替代方案？為什麼這個資料適合預期目的？這防止了使用任何可用資料而不評估其是否合適的常見模式。

工程任務：

1. 為每個訓練資料集創建資料集設計文件，記錄：

   • AI 系統的預期目的（具體用例，而非一般描述）
   • 什麼資料對此目的最理想
   • 實際可用的資料是什麼
   • 理想與可用之間的差距，以及如何處理這個差距
   • 考慮過的替代資料集及其未被選擇的原因

2. 記錄訓練/驗證/測試分割策略：

   • 資料如何分割（隨機、分層、時間、基於領域）
   • 分割比例的依據
   • 分割如何確保驗證集代表生產條件

3. 記錄資料集設計過程中的任何假設：

   • 「我們假設 2023-2025 年的歷史客戶互動能代表未來互動」
   • 「我們假設訓練資料中的投訴類型分佈與生產中的分佈相符」
   • 這些假設是可測試的——稽核人員可能會要求提供證據

文件範本：

Dataset Design Document — [Dataset Name]
1. Intended Purpose: [specific use case description]
2. Ideal Data: [description of what perfect training data would look like]
3. Available Data: [description of what was actually available]
4. Gap Analysis: [how ideal and available differ, and how gaps were addressed]
5. Alternatives Considered: [other datasets evaluated and reasons for rejection]
6. Split Strategy: [train/val/test split method and rationale]
7. Assumptions: [listed with testability assessment]

第 10(2)(c) 條：資料收集流程

法律要求：訓練資料應受「相關資料收集流程」的約束。

實際含義：記錄資料如何獲得。這包括來源、收集方法、任何同意或授權要求，以及收集日期。

工程任務：

1. 在你的攝入管道中實施自動來源追蹤：

   • 記錄每個攝入文件的來源 URI 或文件路徑
   • 記錄收集日期（獲得資料的時間，而非來源創建的時間）
   • 記錄收集方法（API 拉取、文件上傳、網頁抓取、手動輸入）

2. 維護來源登記冊，追蹤：

   • 目前使用的所有資料來源
   • 使用每個來源的法律依據（同意、合法利益、授權、公有領域）
   • 授權限制（如適用）：資料可用於模型訓練嗎？是否有地理限制？
   • 有時限授權或同意的到期日

3. 對來自個人的資料實施同意追蹤：

   • 給予了什麼同意？
   • 何時給予的？
   • 可以撤回嗎？如果可以，從訓練集中移除該人資料的流程是什麼？

文件範本：

Data Collection Record — [Source Name]
1. Source: [URI, database, file location]
2. Collection Method: [API, upload, scrape, manual]
3. Collection Date: [date range]
4. Legal Basis: [consent, license, legitimate interest, public domain]
5. License Details: [license name, restrictions, expiration]
6. Consent Status: [applicable/not applicable, withdrawal process]
7. Update Frequency: [how often this source is re-collected]

第 10(2)(d) 條：資料準備操作

法律要求：訓練資料應受「相關資料準備操作的約束，例如標注、標記、清理、更新、豐富和彙總。」

實際含義：對資料應用的每次轉換都必須記錄在案並建立日誌。這是操作上最密集的要求，因為它涵蓋整個資料管道。

工程任務：

1. 為每次轉換實施自動日誌記錄（技術規格請參閱我們關於不可變稽核追蹤的文章）：

   • 清理：移除了什麼、為什麼、影響了多少記錄
   • 標記：誰標記的、使用了什麼分類體系、應用了什麼品質檢查
   • 增強：使用了什麼方法、創建了多少合成記錄
   • 彙總：合併了哪些記錄、應用了什麼彙總邏輯

2. 對每個中間資料集進行版本控制：

   • 在每個轉換階段後，創建一個版本化快照
   • 將每個快照連結到生成它的轉換日誌條目
   • 啟用回滾到任何先前版本的功能

3. 在每個階段進行驗證：

   • 在每次轉換後運行自動品質檢查
   • 將驗證結果與轉換日誌一起記錄
   • 定義最低品質閾值——如果轉換使品質降至閾值以下，停止管道並提醒資料管理員

文件範本：

Data Preparation Log — [Dataset Version]
Generated automatically by pipeline logging system.
See audit trail entries [ID range] for detailed transformation records.
Summary:
- Cleaning: [X] operations, [Y] records modified, [Z] records removed
- Labeling: [X] records labeled by [Y] annotators, agreement rate [Z]%
- Augmentation: [X] synthetic records generated, [Y] passed quality filter
- Total input records: [N], Total output records: [M]

第 10(2)(e) 條：可用性、數量和適宜性評估

法律要求：訓練資料應受「對所需資料集的可用性、數量和適宜性進行評估」的約束。

實際含義：在訓練前，正式評估你是否有足夠的資料、你擁有的資料是否適合預期目的，以及是否存在差距。

工程任務：

1. 定量評估：

   • 訓練、驗證和測試集中的記錄總數
   • 每個類別/分類的記錄數（用於分類任務）
   • 最低類別代表性閾值（例如，每個類別至少 50 個示例）
   • 統計效能分析：資料集是否足夠大以偵測你需要的效應？

2. 適宜性評估：

   • 領域覆蓋範圍：訓練資料是否涵蓋模型在生產中會遇到的所有場景？
   • 時間覆蓋範圍：資料是否夠新？如果在 2024 年的資料上訓練，模型在 2026 年的查詢上表現如何？
   • 語言覆蓋範圍：資料是否涵蓋系統將服務的所有語言和方言？
   • 邊緣案例覆蓋範圍：罕見但重要的場景是否有代表性？

3. 可用性評估：

   • 什麼資料可以改善模型但目前不可用？
   • 獲取額外資料的計劃是什麼？
   • 是否存在獲取所需資料的法律或技術障礙？

文件範本：

Data Assessment Report — [Dataset Version]
1. Quantity: [total records] training, [total] validation, [total] test
2. Class Distribution: [table of classes and record counts]
3. Minimum Representation: [threshold] — all classes meet/do not meet threshold
4. Domain Coverage: [assessment with specific gaps identified]
5. Temporal Coverage: Data from [date range]. Currency assessment: [current/stale/mixed]
6. Availability Gaps: [data that would improve the model but is unavailable]
7. Remediation Plan: [how gaps will be addressed]

第 10(2)(f) 條：偏差檢查

法律要求：訓練資料應受「對可能影響人員健康和安全、對基本權利產生負面影響或導致歧視的可能偏差進行審查」的約束。

實際含義：分析訓練資料中的偏差——不是作為一次性核對，而是作為持續的過程。重點是可能造成實際傷害的偏差：招聘歧視、有偏差的信用決策、教育或執法中的不公平對待。

工程任務：

1. 人口統計分析（如適用）：

   • 衡量訓練資料中受保護特徵的代表性
   • 將訓練資料人口統計與模型將服務的人群進行比較
   • 識別代表性不足或過度代表的群體

2. 標籤偏差偵測：

   • 衡量不同人口統計群體的標注者間一致性
   • 檢查標籤分佈是否因標注者背景而異
   • 識別可能編碼偏差的系統性標記模式

3. 代理變量偵測：

   • 識別與受保護特徵相關的特徵（例如，郵遞區號作為種族的代理）
   • 記錄包含、排除或緩解每個代理變量的決定

4. 公平性指標：

   • 計算驗證集上的公平性指標：人口統計均等、機會均等、預測均等
   • 為每個指標定義可接受的閾值
   • 記錄任何超出可接受範圍的指標以及採取的補救措施

文件範本：

Bias Examination Report — [Dataset Version]
1. Demographic Representation: [table comparing training data demographics to target population]
2. Underrepresented Groups: [identified groups and degree of underrepresentation]
3. Label Bias Analysis: [inter-annotator agreement by group, findings]
4. Proxy Variables: [identified proxies, decision for each (include/exclude/mitigate)]
5. Fairness Metrics: [metric values vs thresholds, pass/fail for each]
6. Remediation Actions: [what was done to address identified biases]
7. Residual Risk: [biases that could not be fully mitigated, with justification]

第 10(2)(g) 條：識別資料差距

法律要求：訓練資料應受「識別相關資料差距或不足，以及如何解決這些差距和不足」的約束。

實際含義：這與 (e) 中的適宜性評估不同。差距識別專門針對可能影響系統在其預期目的上表現的不足——缺失的場景、代表性不足的用例、盲點。

工程任務：

1. 覆蓋範圍差距分析：

   • 將所有預期用例映射到訓練資料覆蓋範圍
   • 對於每個用例，驗證訓練資料是否包含代表性示例
   • 識別零個或不足訓練資料的用例

2. 驗證集上的錯誤分析：

   • 在驗證集上運行模型並分析錯誤
   • 按類型分類錯誤（假陽性、假陰性、錯誤類別）
   • 識別暗示資料差距的系統性錯誤模式

3. 補救規劃：

   • 對於每個識別的差距，定義補救計劃：收集更多資料、合成示例、調整模型範圍，或為差距場景添加人工介入
   • 設置補救時間表
   • 追蹤補救進度

文件範本：

Data Gap Analysis — [Dataset Version]
1. Use Case Coverage Matrix: [table mapping use cases to training data availability]
2. Identified Gaps: [list of gaps with severity assessment]
3. Error Pattern Analysis: [systematic errors linked to data gaps]
4. Remediation Plan:
   - Gap 1: [description] → [remediation action] → [timeline] → [status]
   - Gap 2: [description] → [remediation action] → [timeline] → [status]
5. Accepted Risks: [gaps that cannot be remediated, with impact assessment and mitigations]

整合所有內容

第 10 條合規不是一次性項目。它是一個持續的操作要求。上述文件必須：

• 創建：在系統部署之前（或對於現有系統，在 2026 年 8 月 2 日截止日期之前）
• 更新：每當訓練資料更改、模型重新訓練或系統範圍改變時
• 審查：定期（至少每季度）以確保準確性
• 可用：在合理時間內可供稽核人員審查（高風險系統在同一工作日內）

工程任務是實質性的但定義明確的。對於從零開始的團隊，預計在管道日誌記錄、品質評估、偏差分析和文件系統上需要 8 至 12 週的實施工作。對於使用 Ertas Data Suite 的團隊，大部分基礎設施已內置——該平台從其稽核追蹤已捕獲的資料中生成符合第 10 條的文件。

關鍵原則：如果沒有記錄，就等於沒有發生。每次評估、每個決定、每次轉換都必須產生可驗證的記錄。這份記錄就是第 10 條合規是操作性的而非願景性的證據。

延伸閱讀

• EU AI Act Article 10 Data Prep Documentation — 深入了解資料準備操作特定的文件要求。
• EU AI Act Article 10 vs Article 30: Training Data Requirements — 第 10 條和第 30 條如何相互作用，以及各自對你的資料管道有何要求。
• EU AI Act Data Governance Checklist for High-Risk Systems — 跨所有相關 EU AI Act 條款的資料治理要求綜合核對清單。