EU AI Act 高風險系統要求：要求什麼，以及沒有告訴你什麼

大多數將受 EU AI Act 高風險系統要求約束的企業還不知道這一點。類別比頭條新聞所暗示的更廣泛，合規義務比簡短的 GDPR 式通知和同意框架更為實質。

以下是法規實際要求什麼、何時適用，以及典型企業 AI 部署中合規差距最大的地方。

八個高風險類別（附件 III）

EU AI Act 在附件 III 中定義了高風險 AI 系統。屬於這些類別之一的任何 AI 系統都受第 9–16 條中全套高風險系統要求的約束。

1. 生物特徵識別 — 用於實時或後處理生物特徵識別自然人的系統。遠程生物特徵識別系統。基於敏感屬性的生物特徵分類。情緒識別系統。這個類別是為什麼員工監控或客戶驗證中的人臉識別 AI 幾乎肯定在範圍之內。

2. 關鍵基礎設施 — 用於關鍵基礎設施（能源、水、燃氣、供暖、交通）管理或運營的 AI。電網的預測性維護 AI 符合條件。AI 輔助的 SCADA 系統符合條件。這不僅限於直接做出安全關鍵決策的 AI——還包括為這些決策提供資訊的 AI。

3. 教育和職業培訓 — 決定教育機構入學、評估學生、監控和偵測作弊、確定學習路徑的 AI。如果你在歐洲向學校或大學銷售用於招生、評估或監考的 AI，你在範圍之內。

4. 就業和工人 — 用於招聘、選拔、僱用過程中的評估、晉升和解僱決策、任務分配、監控工人績效和行為的 AI。這是比任何其他類別都更多企業受到波及的類別。AI 履歷篩選、AI 面試分析、AI 績效管理工具——全部在範圍之內。

5. 基本服務獲取 — 用於信用決策、保險核保和理賠評估、緊急服務調度、福利資格認定的 AI 系統。信用評分 AI、保險 AI、自動化福利處理——全部在範圍之內。如果你的 AI 影響誰獲得信用、保險或政府服務，它就被定義為高風險的。

6. 執法 — 用於個人風險評估、證據可靠性評估、個人風險剖析、犯罪分析和預測的 AI。大多數執法 AI 在範圍之內，例外很少。

7. 移民和庇護管理 — 用於邊境管控、審查庇護申請、評估非法移民風險的 AI。主要是政府性質的，但影響向邊境主管機構銷售的供應商。

8. 司法行政和民主程序 — 協助法院研究、解釋和適用法律的 AI；在選舉環境中使用的 AI。法院使用的法律 AI 工具、選舉相關 AI 在範圍之內。

為什麼比企業認為的更多企業在範圍之內

僅就業類別就已很廣泛。如果你的企業人力資源功能使用以下任何工具，你幾乎肯定在部署高風險 AI 系統：

AI 輔助的履歷篩選或申請人追蹤
AI 輔助的視頻面試分析
基於 AI 的技能評估或認知測試
AI 績效管理或生產力監控
影響人員編制決策的 AI 驅動人力規劃

「但我們只是將其作為幫助人力資源做決策的工具，而非自動做決策」並不是豁免。附件 III 涵蓋在這些流程中「使用」的 AI 系統，無論 AI 是否具有最終決策權。AI 參與就業決策流程仍在範圍之內。

同樣，基本服務類別涵蓋任何影響信用決策的 AI——不只是自動化信用評分系統，還有 AI 輔助核保、導致帳戶限制的 AI 欺詐偵測，以及在貸款工作流程中產生用於風險評估的 AI。

第 9–16 條實際要求什麼

第 9 條：風險管理系統

不是一次性風險評估——而是持續的風險管理系統。第 9 條要求高風險 AI 供應商：識別和分析已知和可預見的風險，估計和評估使用中可能出現的風險，採取風險管理措施，測試系統以驗證風險管理措施有效，並持續記錄風險管理流程。

「持續」在這裡是關鍵詞。這不是部署前的核對清單。這是一個在系統在現場運行時、新風險出現時以及部署環境變化時不斷更新的持續計劃。

第 10 條：訓練、驗證和測試資料

這是大多數企業準備最不充分的條款。第 10 條要求訓練、驗證和測試資料集：

符合其預期目的的適當品質標準
對可能影響使用環境中人員的偏差進行了檢查
考慮了特定於地理、行為或功能環境的特徵
相關、有代表性、完整且盡可能無錯誤
有資料數據溯源——來源、收集方法、準備操作

第 10 條不是關於訓練集中個人資料的 GDPR 合規。它是關於訓練資料治理。它要求記錄文件化的品質標準、偏差檢查，以及用於訓練或驗證高風險系統的每個資料集的來源追蹤。

大多數使用雲端 AI API 的企業無法提供這些文件，因為他們沒有以稽核能力準備訓練資料。如果你在私有資料上微調了模型，但無法提供該資料如何收集、如何進行偏差檢查以及如何處理的文件——你不符合第 10 條要求。

第 11 條：技術文件

在部署高風險 AI 系統之前，供應商必須準備涵蓋附件 IV 規定的 11 個要素的技術文件：

AI 系統的一般描述及其預期目的
包括組件、架構和算法的詳細描述
開發流程描述——方法論、設計選擇、假設
監控、功能和控制措施描述
驗證和測試程序描述，包括測試資料和結果
風險管理文件（第 9 條）
整個生命週期中所做更改的描述
適用標準清單及合規文件
EU 合格聲明副本
實施的信息安全措施
使用說明

這是部署前文件要求，而非部署後報告要求。你在部署前就需要文件，而非出了問題之後才需要。

第 13 條：對用戶的透明度和資訊提供

高風險 AI 系統必須對其部署者（使用它們的企業）透明，包括：系統的目的和限制、進行測試所依據的準確性、健壯性和網路安全水平、系統可能無法可靠運行的情況、人工監督措施，以及所需的計算資源。

這是上游透明度——從供應商到部署者。如果你從供應商購買高風險 AI，你有權獲得這些資訊。如果你在銷售，你必須提供。

第 14 條：人工監督

高風險 AI 系統的設計和開發必須能夠實現有效的人工監督。這意味著系統必須允許操作員完全理解系統的能力和限制、監控其運行、能夠識別和處理異常和故障，並能夠忽略、覆蓋或干預系統的運行。

關鍵點：停止系統的能力必須是可用的。無法被人工操作員關閉或覆蓋的高風險 AI 系統，無論技術文件說什麼，都不符合第 14 條。

第 15 條：準確性、健壯性和網路安全

高風險 AI 系統必須在其整個生命週期內達到適合其預期目的的準確性水平，並對錯誤、故障和未經授權的行為修改嘗試具有韌性。準確性必須在技術文件中聲明——量化的，而非定性描述的。

「我們的模型高度準確」不滿足第 15 條。「我們的模型在附件 IV 中描述的驗證集上達到 94.3% 的準確性，在代表性不足的人口統計子群上達到 91.7% 的準確性」才符合。

截止日期現實

EU AI Act 下的高風險系統要求從 2026 年 8 月起適用。如果你今天在部署高風險 AI 系統，你還有時間建立合規——但時間不多，需要建立的範圍很大。

合規時間表因文件要求而進一步壓縮。第 11 條要求部署前文件。如果你在資料準備時沒有追蹤來源，你就無法事後記錄第 10 條訓練資料治理。

第 30 條日誌記錄要求

第 30 條要求高風險 AI 系統供應商在適合預期目的的期間保留系統運行日誌。這不是關於記錄 API 呼叫。它是關於記錄決策過程——系統用什麼輸入、什麼參數做了什麼，以產生什麼輸出。

對於大多數受監管用途，日誌記錄要求持續系統整個生命週期。金融決策可能根據現有金融法規需要 10 年以上的日誌記錄。醫療保健應用可能需要在患者記錄保留期間保留日誌。

第 10 條合規的本地部署優勢

以下是第 10 條合規在實踐中的樣子：你需要能夠提供文件，顯示訓練中使用的每個資料集的來源、應用的品質標準、進行的偏差檢查以及執行的預處理操作。這些文件必須在部署前存在。

帶有內置稽核日誌記錄的本地資料準備管道是第 10 條合規的架構正確解決方案。每個轉換步驟都帶時間戳、操作員 ID 和參數記錄。每個資料來源都有文件記錄。每個品質門都被記錄。每個偏差檢查輸出都被保存。

這正是 Ertas Data Suite 提供的——一個 Tauri 2.0 原生桌面應用程式，用於 AI 資料準備，每個管道步驟都內置稽核追蹤：攝入、清理、標記、增強、匯出。稽核日誌以適合 EU AI Act 第 30 條技術文件的格式匯出，每次轉換都可追溯到特定操作員和時間戳。

EU AI Act 不規定技術實施——只規定結果。你在「如何」實現合規上有靈活性，但在「是否」合規上沒有選擇。問題是你目前的基礎設施是否使所需結果可以實現。

對於受高風險系統要求約束的企業——特別是醫療保健、金融、人力資源和法律領域的企業——沒有資料數據溯源追蹤的雲端 API AI 是合規的架構錯誤起點。文件要求無法事後滿足。

預約與 Ertas 的探索通話 →，了解第 10 條和第 30 條合規在實踐中是什麼樣子，以及 Ertas Data Suite 的稽核日誌本地管道是否符合你的合規要求。