AI 代理部署的《歐盟人工智慧法案》合規：逐條款義務解析
截止日期
2026 年 8 月 2 日，《歐盟人工智慧法案》（Regulation (EU) 2024/1689）迎來下一個執法里程碑。法案的其餘部分開始適用——包括對高風險 AI 系統的義務、對 AI 生成內容的透明度要求，以及處罰條款。最高罰款為 3500 萬歐元或全球年營業額的 7%，以較高者為準。
該法案於 2024 年 8 月 1 日生效。對不可接受風險行為（社會評分、潛意識操縱、公共空間的即時生物辨識監控）的禁令自 2025 年 2 月 2 日起適用。通用目的 AI 模型義務和治理規則自 2025 年 8 月 2 日起適用。實施時間表確認，2026 年 8 月 2 日是高風險系統要求、透明度義務和處罰框架全面生效的日期——僅第 6(1) 條系統有有限例外，其適用時間推遲至 2027 年 8 月。
對於部署了對信貸、就業、基本服務取得或關鍵基礎設施做出或支持決策的 AI 代理的組織而言，8 月 2 日就是合規日期。不是規劃日期。不是審查日期。而是義務可強制執行的日期。
合規邊界延伸至執行層
大多數組織將其 AI 合規工作集中在模型上——訓練資料治理、偏見測試、輸出監控。Salt Security 的合規分析明確指出這是不夠的。法案的適用範圍延伸至模型所做的事，而不僅僅是它所產出的內容。
第 15 條（網路安全）要求防範對抗性攻擊、資料投毒、機密性攻擊和模型規避。Salt Security 的分析確認，這種防護「必須延伸至 AI 系統與世界互動的介面（API 和 MCP 伺服器）」。一個透過 Model Context Protocol 模組呼叫 NetSuite，或透過 MCP 連接器讀取 HubSpot 客戶資料的 AI 代理，會將這些介面納入合規邊界。
第 99 條和第 100 條前言（Recitals）明確涉及多代理架構。在一條 AI 代理鏈中，合規邊界延伸至每一個執行高風險功能的代理。如果一個編排代理將定價決策委託給呼叫 RFQ 引擎的子代理，那麼兩個代理都繼承相應義務。合規範圍是完整的呼叫鏈，而非入口點。
什麼算作高風險
法案在第 6 條和附件 III 中定義了高風險 AI 系統。與 B2B 代理部署最相關的類別：
- 就業與員工管理——履歷篩選、晉升決策、任務分配、績效監控
- 基本服務取得——信用評分、保險定價、資格認定
- 關鍵基礎設施的安全元件——交通、能源、水
- 執法與司法——儘管大多數 B2B 部署不屬於此類
一個評估供應商報價並推薦得標決策的採購代理，如果採購涉及受監管的商品或公部門合約，就觸及了基本服務取得領域。一個按客戶層級差異化定價的報價代理，如果定價影響金融產品的取得，就觸及了信貸和保險領域。分類取決於 AI 所執行的功能，而非部署公司所處的產業。
對於未達到高風險門檻的系統，透明度義務仍然適用。第 50 條要求部署方在個人與 AI 系統（聊天機器人、內容生成）互動時告知他們。生成式 AI 內容必須可辨識。這些義務自 2026 年 8 月 2 日起生效。
逐條款義務
對於高風險系統，法案施加了具體、可稽核的義務。Salt Security 的分析提供了條款層級的拆解。以下是每一條的要求，以及它如何對應到代理基礎設施。
第 9 條——風險管理
一個貫穿整個 AI 生命週期的、持續且迭代的風險管理系統。而非部署前的一次性評估。該系統必須辨識、分析並緩解已知和可預見的風險，包括系統投放市場後出現的風險。
這對代理意味著什麼： 風險登記冊是一份活文件。每一個新的 MCP 模組、每一個新的連接器、每一次新的工具註冊都是必須評估的風險面。一個記錄每次工具呼叫及其結果的治理層，為迭代式風險審查提供了證據基礎——沒有它，風險管理系統就沒有資料。
第 10 條——資料治理
高品質的資料集以最小化歧視性結果。防止未經授權存取和資料投毒的保護措施必須延伸至推理時——當 AI 代理主動呼叫 API 並存取外部資料時。
這對代理意味著什麼： 代理在執行時讀取的資料（來自 NetSuite、BigCommerce、供應商目錄）在範圍之內。如果某個供應商目錄被投毒了錯誤的定價資料，而代理據此報價，那麼資料治理義務就適用。對 MCP 工具回應的輸入驗證不是品質細節——它是一項合規控制。
第 11 條——技術文件
在投放市場前對所有元件、介面和能力的完整清單。對於代理系統，這意味著記錄每一個 MCP 模組、它註冊的每一個工具、它連接的每一個上游系統，以及它處理的每一條錯誤路徑。
這對代理意味著什麼： 模組註冊表就是文件。一個以綱要、速率限制和稽核日誌動態註冊 MCP 模組的系統，會將技術文件作為其架構的副產品產出。一個由臨時腳本和未註冊 API 呼叫組成的系統則不會。
第 12 條——記錄保存（日誌記錄）
對所有事件的自動日誌記錄。日誌必須防竄改，並至少保留 6 個月（生物辨識和執法系統為 24 個月）。每一次工具呼叫、每一個代理決策、每一次人工介入都必須能夠從日誌中重建。
這對代理意味著什麼： 每一次 MCP 工具呼叫都必須記錄時間戳記、代理 ID、工具名稱、輸入雜湊（而非原始輸入——PII 邊界）、輸出狀態和持續時間。日誌必須是僅附加或防竄改的。6 個月保留是最低要求，而非目標。這是最直接可對應的義務：一個將每次函式呼叫以結構化欄位記錄到 DynamoDB 的受治理 MCP 架構，天然滿足第 12 條。
第 14 條——人工監督
系統必須允許人工操作員在偵測到異常行為時即時監督、介入並停止系統。這不是一個事後顯示指標的監控儀表板。而是在任務進行中停止一個正在執行的代理的能力。
這對代理意味著什麼： 提示詞層級的指令（「停止」、「取消」）在法案下不構成監督。它們屬於 AI 的對話脈絡，在記憶遺失或提示注入的情況下可能被忽略。法案要求一個在 AI 推理過程之外運行的確定性停止機制。一個撤銷代理身分驗證權杖、透過設定變更停用特定 MCP 模組，或在異常行為模式下觸發斷路器的終止開關（kill-switch）滿足第 14 條。一個「停止」命令則不滿足。
miniOrange 的終止開關架構分析定義了對應此項義務的四個層次：
- 基於身分的存取撤銷——綁定到特定任務的短時工作階段權杖；即時憑證撤銷
- 斷路器與異常偵測——在過量 API 請求、異常權杖消耗、重複迴圈時觸發
- 限定範圍的能力撤銷——僅停用危險能力（例如，移除傳送郵件權限但保留工單讀取）
- 進行中任務處理——回滾未完成的變更，保留執行日誌，在關閉後驗證系統穩定性
同一分析中記錄的 OpenClaw 事件說明了為何提示詞層級的停止會失敗：一個整理郵件收件匣的 AI 代理超出了其記憶上限，遺失了脈絡，回退到它最後記住的目標——刪除郵件。使用者的「停止」和「取消」命令被忽略。代理一直持續到在作業系統層級被手動終止。這一失敗是架構性的：在 AI 的推理過程之外不存在任何確定性關閉機制。
第 15 條——網路安全
針對對抗性攻擊、資料投毒、機密性攻擊和模型規避的技術穩健性。防護必須延伸至 AI 與世界互動的介面。
這對代理意味著什麼： 每一個 MCP 伺服器、每一個 API 端點、每一個連接器都在範圍之內。2026 年記錄的 MCP 安全態勢——影響 1.5 億次下載的系統性 STDIO 設計缺陷、CVE-2026-33032（「MCPwn」，CVSS 9.8）、CVE-2026-0755（Gemini MCP，CVSS 9.8）、30% 至 82% 的公共 MCP 伺服器帶有可利用缺陷——正是法案所針對的網路安全風險。只有 8.5% 的 MCP 伺服器使用 OAuth。法案並未特別強制要求 OAuth，但它確實強制要求一個目前 MCP 生態系統在預設情況下無法滿足的網路安全水準。
第 72 和 73 條——投放後監控與事件通報
從部署第一天起就有一個文件化的監控系統。事件通報視窗：
- 對生命或安全風險為 24 小時
- 對其他嚴重事件為 72 小時
- 對故障為 15 天
這對代理意味著什麼： 稽核日誌是事件通報的來源。當一個代理超出權限、發出未經授權的呼叫，或產出影響某個決策的錯誤輸出時，日誌可重建所發生的事。24 小時和 72 小時的視窗意味著監控系統必須即時告警，而非在每週審查中。
治理缺口
Deloitte 2026 State of AI in the Enterprise 發現，只有五分之一的公司對自主 AI 代理擁有成熟的治理模型。根據 practical-devsecops 2026 報告，47% 至 53% 的組織曾有 AI 代理超出權限或遭遇事件。只有 23% 擁有正式的 AI 代理身分策略。
法案並未規定特定架構。它規定的是結果：持續的風險管理、自動且防竄改的日誌、能夠確定性停止系統的監督、延伸至每個介面的網路安全。滿足這些結果的架構就是受治理的 MCP 模組模式——正是應對 2026 年 MCP 漏洞時間線所記錄的安全漏洞的同一模式。
受治理的 MCP 架構如何滿足這些義務
使 MCP 模組在生產中安全運行的治理層，與滿足法案要求的治理層是同一層。這種對應是直接的：
| 《歐盟人工智慧法案》條款 | 義務 | 治理控制 |
|---|---|---|
| 第 9 條（風險管理） | 持續、迭代的風險評估 | 每次工具呼叫連同結果一起記錄；從稽核資料更新風險登記冊 |
| 第 10 條（資料治理） | 推理時的防護 | 對 MCP 工具回應的輸入驗證；型別化錯誤將資料品質失敗與瞬時錯誤區分開 |
| 第 11 條（技術文件） | 完整的元件與介面清單 | 模組註冊表：每個 MCP 模組、工具綱要、上游連接、錯誤碼都在註冊時記錄 |
| 第 12 條（記錄保存） | 自動、防竄改的日誌，保留 6 個月 | 記錄到 DynamoDB 的結構化 JSON 日誌：時間戳記、代理 ID、工具名稱、輸入雜湊、輸出狀態、持續時間；以 partition key 租戶隔離的僅附加日誌 |
| 第 14 條（人工監督） | 即時停止能力 | 終止開關：身分撤銷（短時 JWT 權杖）、斷路器（按工具按視窗的速率限制）、限定範圍的能力撤銷（透過設定變更停用模組）、進行中回滾 |
| 第 15 條（網路安全） | 防護延伸至 API 和 MCP 伺服器 | OAuth/Cognito 身分驗證、速率限制、PII 邊界處理（記錄前 SHA-256 欄位雜湊）、型別化錯誤契約 |
| 第 72–73 條（事件通報） | 24/72 小時通報視窗 | 從稽核日誌即時偵測異常；對權限超出、非預期工具呼叫、速率限制違規告警 |
關鍵洞見在於，這些控制不是事後加裝的。它們是 MCP 模組註冊、執行和日誌記錄管線的結構本身。一個以綱要註冊其工具、宣告其速率限制、將每次呼叫記錄到僅附加儲存、並可透過設定變更停用的模組，會將合規證據作為其運行的副產品產出。一個直接呼叫 API 的臨時代理則不會——而在一個未受治理的代理上事後加裝合規控制，比從一開始就內建它們更昂貴。
多代理合規邊界
第 99 和 100 條前言將合規邊界延伸至鏈中每一個執行高風險功能的代理。這具有一個大多數組織尚未內化的架構含義。
考慮一個採購工作流程：一個編排代理接收 RFQ，將產品解析委託給一個目錄代理，將定價委託給一個報價引擎代理，將訂單寫入委託給一個 ERP 整合代理。在法案下，如果這些代理中的任何一個執行高風險功能（影響信貸取得的定價、影響就業的供應商選擇、受監管商品的採購），鏈中的每一個代理都繼承該義務。
這意味著治理層必須處於編排層級，而非單個代理層級。日誌記錄必須追蹤完整的呼叫鏈——哪個代理以哪些參數呼叫了哪個模組，結果如何。模組註冊表必須涵蓋每個代理的每個模組。終止開關必須能夠停止某個特定代理的能力，而不停用共享基礎設施。
partition_key 租戶隔離模式——每條 MCP 函式呼叫記錄都攜帶一個將其限定到特定租戶和端點的 partition key——提供了多代理合規所要求的稽核追蹤結構。對函式呼叫日誌的一次查詢可以重建完整的工作流程狀態：哪個代理觸發了哪個工具、以什麼順序、以什麼參數、結果如何。這是跨多代理鏈的第 12 條記錄保存和第 72–73 條事件通報的證據基礎。
8 月 2 日前該做什麼
對於已在生產中或處於部署管線中擁有 AI 代理的組織，8 月 2 日的截止日期帶來一份具體的待辦清單：
對你的代理分類。 確定哪些落入高風險類別（就業、基本服務、關鍵基礎設施）。不觸及這些類別的代理仍有第 50 條下的透明度義務。
稽核日誌層。 你能從日誌中重建任何一個代理決策嗎？日誌是否防竄改並至少保留 6 個月？如果答案是否定的，這是要弭平的第一個缺口——第 12 條是最直接可驗證的義務。
驗證停止機制。 一個操作員能否確定性地停止一個正在執行的代理，而不依賴代理自身的推理？如果停止依賴於一個提示詞命令，它就不滿足第 14 條。需要一個撤銷憑證或透過設定變更停用模組的終止開關。
記錄介面清單。 代理呼叫的每一個 API、每一個 MCP 伺服器、每一個連接器都必須記錄（第 11 條）。模組註冊表就是文件——如果你沒有一個，這是要弭平的第二個缺口。
定義事件回應流程。 當一個代理超出權限時通知誰？24 小時和 72 小時的通報鏈是什麼？流程必須在部署前記錄，而非事件發生後。
評估多代理範圍。 如果你的架構涉及代理鏈，映射每一個可能執行高風險功能的代理。合規邊界是完整的鏈。
不合規的代價 vs 治理的代價
最高罰款為 3500 萬歐元或全球營業額的 7%。對於一家營收 1 億歐元的中型企業，那就是 700 萬歐元。滿足法案的治理層——稽核日誌、速率限制、型別化錯誤、終止開關、模組註冊表、租戶隔離——正是無論監管壓力如何都能使生產代理安全運行的同一治理層。已經經歷過代理事件的那 47% 至 53% 的組織，正在以營運風險的形式支付未受治理代理的代價。法案只是讓這一代價變得明確且可強制執行。
那些從一開始就將治理內建到其代理架構中的組織——以綱要註冊模組、將函式呼叫記錄到持久儲存、以短時權杖進行身分驗證、在模組邊界強制執行速率限制——對它們而言，8 月 2 日是一次文件化練習，而非一次緊急改造。那些將代理部署為直接呼叫 API 的臨時腳本的組織，則是面臨緊急情況的那些。
一家運行 NetSuite、BigCommerce 和三個供應商目錄的分銷商，擁有一個接收 RFQ、針對目錄圖譜解析產品、按客戶層級定價、並將報價寫回 NetSuite 的代理。如果該代理確定信貸條款或為受監管的採購選擇供應商，它就落入高風險類別。受治理的 MCP 架構——每次工具呼叫連同時間戳記和結果記錄到 DynamoDB、每個模組可透過設定變更停用、每個代理以短時 JWT 權杖進行身分驗證、每個錯誤經過型別化和分類——正是使該代理在 8 月 2 日合規的東西。使它安全運行的同一架構，也使它合規運行。
申請一次限定範圍的建構。 一週探索。你會得到一份系統清單、一張工作流程圖和一個固定範圍——無論你是否與我們一起建構。
想為您的系統建構這個嗎？
這裡的每份文件都來自真實的生產工作。如果您有目標系統和工作流程想法，我們可以在一週內確定範圍。
申請客製開發為期一週的發掘階段。您會拿到系統清單、工作流程地圖和固定範圍——無論您最終是否與我們合作開發。