歐盟AI法案於8月2日生效：一份工程合規清單

歐洲聯盟《人工智能法案》（EU AI Act，條例(EU) 2024/1689）將於2026年8月2日全面適用。如果您的AI系統屬於高風險類別——例如招聘、信用評分、教育、關鍵基礎設施、基本服務等——一系列具體、可審計的義務將從“即將實施的法規”轉變為系統必須遵守的法律。

大多數團隊正以2018年應對GDPR的方式來處理此事：一個由律師主導、產出文件的合規項目。但對於AI系統，這種方法註定失敗，原因很簡單：您的系統變化速度比文書工作快。對上個季度模型進行的合規評估，幾乎無法告訴監管機構您今早發佈的內容。

這正是“合規工程”所要解決的問題：將監管合規視為系統的一項屬性——通過設計融入、由流水線強制執行、並持續提供證據——而非事後編寫的報告。可靠性經歷了這一轉變，產生了SRE；安全性也經歷了這一轉變，產生了DevSecOps；合規性將是下一個。

以下是實用版本：高風險系統的核心歐盟AI法案義務，映射到滿足每項義務的工程實踐及其應產出的證據製品。每項遵循相同模式：條款 → 實踐 → 證據。

首先，瞭解關鍵日期：

• 2025年2月2日：禁止的AI實踐生效；AI素養義務。
• 2025年8月2日：通用AI模型義務；治理機構運作。
• 2026年8月2日：全面適用，包括以下高風險義務（附件III系統）。
• 2027年8月2日：嵌入受監管產品的高風險AI（附件I）。

處罰力度與違規程度掛鈎：禁止實踐最高罰款3500萬歐元或全球年營業額的7%；其他多數義務違規最高罰款1500萬歐元或3%。這些與GDPR相當的金額，正是董事會開始詢問工程部門（而非僅法務）有何計劃的原因。

清單：條款 → 實踐 → 證據

1. 誠實分類系統（第6條及附件III）

一切後續工作取決於您的系統是否高風險。實踐：將分類作為版本化的工程決策，記錄在倉庫中，並在每次重要功能變更時重新評估——您在第三季度增加的一個用例可能將低風險系統變為高風險。證據：帶有推理的註明日期的分類備忘錄，受版本控制。

1. 運行持續的風險管理系統（第9條）

法案要求風險管理在整個生命週期內“持續”且“迭代”——這是一個流程要求，而非文件要求。實踐：將風險登記冊作為代碼維護，每次發佈時審查；阻止引入未緩解已知風險的發佈。證據：登記冊的變更歷史，與發佈標籤關聯。

1. 以可審計的方式管理數據（第10條）

訓練、驗證和測試數據必須符合質量標準，且必須檢查可能的偏差。實踐：為每個數據集準備數據集卡片，從源頭到模型的數據溯源，以及作為流水線步驟而非一次性研究運行的偏差檢查。證據：每次訓練運行生成的數據集文檔和偏差測試報告。

1. 生成技術文檔，而非手動編寫（第11條及附件IV）

附件IV文檔必須在上市前存在並保持最新。手工編寫的文檔必然過時。實踐：將文檔視作代碼——在構建時從系統本身（架構、模型版本、評估結果）生成附件IV包。證據：每次發佈可重現的文檔構建。

1. 為尚未到來的審計記錄日誌（第12條）

高風險系統必須在其生命週期內自動記錄事件。實踐：從第一天起圍繞可審計性設計結構化、僅追加的日誌：輸入、決策、模型版本、覆蓋操作——並制定保留策略。證據：日誌本身，不可變且可查詢。

1. 發佈説明，而非假設（第13條）

部署者必須能夠正確解釋和使用系統。實踐：版本化的系統卡片和使用説明，像變更日誌一樣隨每次發佈一起提供。證據：每個版本的説明存檔。

1. 將人工監督設計為功能，而非政策（第14條）

有效監督意味着人類能夠理解、干預和覆蓋。實踐：在產品界面中構建批准/覆蓋/停止路徑——僅存在於政策PDF中的監督並非“有效”。證據：證明人類實際使用控制措施的監督交互日誌。

1. 每次發佈證明準確性、魯棒性和安全性（第15條）

這些是可測量的屬性。實踐：在CI中設置帶有迴歸閾值的評估套件；定期進行對抗性和紅隊測試；將標準網絡安全衞生擴展到模型特定攻擊（投毒、提示注入）。證據：每次發佈的評估報告。

1. 讓SDLC成為您的質量管理體系（第17條）

提供者需要質量管理體系。大多數工程組織已運行了80%的體系——代碼審查、CI/CD、事件響應——只是未命名。實踐：將現有生命週期制度化，填補缺口，讓流水線強制執行。證據：流程文檔加上強制執行流程的CI配置。

1. 將合規評估視為發佈門禁（第43、47-49條）

上市前：合規評估、歐盟合規聲明、CE標誌、在歐盟數據庫註冊。實踐：將其建模為發佈流程的最終門禁，由前九項已生成的證據提供輸入——這就是工程化合規而非文檔化合規的回報。證據：簽名的聲明和註冊記錄。

1. 上線後持續監控（第72-73條）

上市後監控是強制性的，嚴重事件必須報告——最快15天內，更嚴重類別更快。實踐：將生產監控連接到事件處理流程，並將監管報告作為明確的行動手冊步驟。證據：監控儀表板和事件記錄。

本週圍攻方向：

1. 分類（第1項）。當您知道哪些義務實際適用於您時，一半焦慮便會消失。
2. 對照清單進行差距評估。對於每項：實踐是否存在？是否自動產生證據？多數團隊發現日誌和評估接近要求，而文檔和風險管理則不然。
3. 選擇兩個最嚴重的差距並進行工程化——流水線檢查和生成製品，而非文檔。一份生成的附件IV包抵得上十份手寫的。

到8月2日能保持冷靜的團隊，並非擁有最厚活頁夾的團隊，而是那些系統在運行中自動生成合規證據的團隊。這就是整個學科的一句話總結。

完整的合規工程指南正在編寫中。

在此文章發佈時獲取——加入候補名單。

本文為工程指南，而非法律建議。義務因角色（提供者與部署者）、行業及成員國實施而異——請諮詢合格法律顧問以確認您的具體情況。