英國準備應對 AI Agent 重大事故，企業需要怎樣的事故預案

2026 年 10 月 12 日，英國政府宣布將著手建立應對 agentic AI 重大事故的專門能力。政府關心的是：當能夠調用工具、執行連續任務的 AI Agent 超出預期時，公共部門如何迅速查明情況、控制影響並協助受影響者。

英國政府正在制定重大 Agent 事件的專門響應方案。

這項政策信號也給企業提出一個現實問題：如果 Agent 誤發數據、越權操作系統、觸發錯誤付款或陷入重複執行，團隊能否在幾分鐘內關停權限、保存證據，並恢復業務？這項安排屬於政府重大事故響應能力建設。企業日常的事故報告與處置責任仍應依據適用的網絡安全、數據保護、金融監管和合同制度判斷，Agent 場景需要補充相應的應急控制。

一、英國政府正在建立什麼能力

政府書面聲明提出，英國將採取措施強化政府網絡防禦，並建立應對涉及 agentic AI 重大事故的專門能力，同時考慮《網絡安全與韌性法案》（Cyber Security and Resilience Bill）如何應對新興威脅。聲明稱，Agent 在減少人工監督的情況下被更廣泛使用，嚴重事件可能涉及系統超出指令運行，政府需要更快識別問題、控制風險並支持受影響者。

這是一項政府層面的能力建設安排。它說明英國希望為高影響 AI 事件準備專門響應機制，也把 Agent 安全放入國家網絡韌性討論。法案仍處在立法過程中，政策聲明本身沒有為所有企業新增統一的報告時限、事故等級或法定處置流程。

這區分對企業很重要。企業目前仍應按自身適用的網絡安全、數據保護、金融監管和合同要求判斷事故是否需要通知監管者、客戶或合作方。Agent 事故可能觸發既有義務，具體要看洩露了什麼數據、影響了哪些服務、誰承擔監管責任以及事件對客戶造成什麼後果。

英國政府同時強調，專門響應能力要幫助公共部門快速查明異常行為、控制風險並支援受影響者。企業準備預案時可以沿著同樣的順序設計內部決策，但其法律責任仍然落在既有制度上。比如，客服 Agent 把客戶資料發送給錯誤對象，核心問題是個人數據洩露；支付 Agent 重複付款，首先要查支付授權、合同和帳務；控制工業系統的 Agent 造成服務中斷，則可能進入網絡與信息系統安全及行業監管的事故程序。同樣叫作"AI 事故"，報告對象和時限可能完全不同。

二、Agent 事故和傳統系統故障有相同處，也有新難點

企業已有的網絡事件預案，通常包括發現、分級、隔離、取證、通知和恢復。Agent 系統同樣需要這些環節。變化在於，Agent 可能通過工具連接到郵箱、代碼倉庫、數據庫、客戶管理系統、支付接口或雲服務；一次提示或權限配置錯誤，可能連續觸發多個操作。

Agent 權限可能連接郵箱、數據庫、代碼和支付，處置需要還原調用鏈。

比如，Agent 接到一項整理客戶資料的任務後，調用外部 API、寫入共享文檔，再把結果發送給未獲授權的收件人。事故調查需要還原模型輸出和實際執行鏈，包括它收到的指令、訪問的賬戶、工具調用順序、審批記錄、數據對象和每一步發生的時間。

企業的 Agent 清單應覆蓋模型、負責人、部署環境、可訪問數據、可調用工具、使用的密鑰、付款或寫入權限、供應商依賴及停止方式。若多個 Agent 共用同一憑證，或一個流程能在沒有人工確認的情況下完成不可逆操作，事故影響就可能迅速擴大。

事故也未必從模型本身開始。攻擊者可以在網頁、郵件或共享文檔裡埋入提示注入指令，誘導 Agent 忽略原任務並調用企業工具；供應商更新模型版本後，原來穩定的輸出格式也可能改變，進而觸發自動化流程誤操作。調查時要區分輸入內容、模型生成、工具授權和實際執行四個環節。企業只看最後一條聊天記錄，往往找不到真正的控制失效位置。

因此，權限設計應圍繞工具動作展開。讀取公開網頁、讀取客戶檔案、修改客戶檔案、發送外部郵件和付款分別對應不同後果。開發團隊可為每一種工具調用設定身份、用途、數據範圍和有效期；高影響動作再增加人工確認和金額閾值。這樣做的直接好處是，一旦出現異常，安全團隊可以停用單一工具或憑證，保留其他業務繼續運行。

三、先判斷事故進入哪一套法律程序

涉及個人信息時，英國《通用數據保護條例》（UK GDPR）第 5 條的數據處理原則、第 25 條的設計和默認保護以及第 32 條的安全措施，是評估事前安排的重要依據。企業需要說明 Agent 為什麼能訪問這批數據、是否只取得完成任務所需的權限、是否有訪問日誌，以及外發或批量導出時是否設置了攔截。對高風險數據處理，第 35 條的數據保護影響評估也可能要求在上線前識別並降低風險。把 Agent 列入一般的軟件採購清單，無法替代對其具體數據訪問範圍的評估。

若事故已經造成個人數據洩露，負責決定處理目的和方式的控制者要依據 UK GDPR 第 33 條判斷是否通知信息專員辦公室（ICO）。存在對個人權利與自由造成風險的可能時，原則上應在知悉後盡可能於 72 小時內通報；即便最初尚未掌握全部事實，也可以先報已知情況，再補充調查結果。處理者依據第 33 條第 2 款，應在知悉後不無故延遲地通知控制者。第 34 條關注另一個問題：若洩露對個人造成高風險，控制者還要及時通知受影響者。未達到通報門檻的事故仍應記錄事實、影響和補救措施，供後續核查。

例如，Agent 誤把十位客戶的身份材料附在外部郵件中，隱私團隊需要確認收件者、文件是否可打開、資料敏感程度、能否召回以及是否已有進一步轉發。判斷通報門檻時，不能只數文件數量。若資料包含身份號碼、財務信息或健康信息，風險判斷會發生變化。安全團隊負責止損和追蹤，法律團隊記錄何時開始"知悉"、依據什麼事實作出報告決定；這兩條工作線必須同時開始。

另一類事故發生在自動決定上。Agent 若直接拒絕客戶貸款、停止某人的賬戶服務或作出類似重大影響決定，企業要檢查英國《2025 年數據使用與訪問法》修訂後的自動化決策規定，尤其是 UK GDPR 第 22A 至 22C 條的適用條件和保障措施。判斷重點是有沒有真正有意義的人工參與、決定是否對個人產生法律或類似重大影響，以及個人能否得到說明、提出意見、請求人工介入並對決定提出異議。例行設置一個"人工審核"按鈕，若審核員沒有足夠信息和時間改變結果，難以解決實質問題。

如果 Agent 維持的是重要公共服務或受監管金融業務，還要單獨檢查行業規則。《2018 年網絡與信息系統條例》對特定關鍵服務運營者和相關數字服務提供者設置安全及重大事件報告要求，適用主體與報告門檻需要依服務類型判斷。金融機構則應把 Agent 故障納入運營韌性、外包和重大業務服務的管理；英國金融行為監管局（FCA）已經公布新的運營事件和第三方報告制度，但相關新統一規則計劃於 2027 年 3 月 18 日實施。企業在 2026 年處理事故時，應先依現行適用規則、監管通知要求和合同安排行動，再為未來制度做準備。

除法定通報外，一份 Agent 事故還可能觸發雲服務合同、客戶數據處理協議和網絡保險保單中的通知條款。法律團隊應在事故初期列出合同相對方、通知觸發條件、期限和所需材料。尤其是模型商、托管商、工具供應商同時參與處理時，客戶希望知道誰能導出日誌、誰能暫停接口、誰負責對外說明。供應商延遲提供這些信息，會直接拖慢企業對法定報告門檻的判斷。

三、預案應讓"停止它"成為可執行動作

第一步是按業務後果分級。讀取公開資料的 Agent 與能改動客戶賬戶、發送外部郵件或執行付款的 Agent，應該採用不同的權限和監測等級。企業可以把異常行為定義為可演練的觸發條件，例如短時間內重複調用、訪問任務範圍之外的數據、金額或調用量異常、持續失敗後仍繼續執行。

應急預案要把分級、撤權、取證和恢復落成可演練動作。

第二步是準備具體的止損開關。應急人員要能撤銷或輪換 API 密鑰，暫停工具連接，凍結支付額度，阻止對外發送，並隔離相關會話或運行環境。若關停 Agent 必須排隊等待供應商處理，企業要提前確認替代聯繫人和合同約定的響應路徑。

第三步是保存調查材料。日誌應盡量覆蓋模型和版本、系統提示、用戶指令、工具請求與響應、審批人、外部服務返回值、時間戳及相關數據對象。保留範圍應遵守隱私和數據最小化要求，同時滿足事故調查、監管報告和合同爭議處理的需要。僅保存聊天窗口截圖，通常不足以重建 Agent 實際執行了哪些動作。

日誌保全最好由事先指定的人员執行，並保留原始文件、導出時間和訪問記錄。若事件涉及員工誤操作、供應商違約或外部攻擊，後續可能出現監管調查或民事爭議。此時企業需要證明某次工具調用來自哪個賬戶、使用了哪一版模型、是否經過批准，以及輸出如何轉化為系統動作。對日誌做覆蓋式清理或在調查前匆忙升級系統，可能使關鍵證據消失。留存方案也應設置訪問限制，避免調查資料本身成為第二次數據洩露。

最後是通知與恢復。事故負責人需要根據事件類型確認適用的法定通知義務、合同通知時限和客戶溝通責任。恢復服務之前，應輪換憑證、復核數據完整性、收緊權限，並用受控測試確認漏洞或錯誤配置已處理。對於高風險 Agent，還可以安排跨部門桌面演練，模擬夜間發生的自動付款、數據洩露或供應商服務中斷。

預案還要明確誰擁有每個決定。業務負責人判斷任務是否可以暫停，安全團隊負責撤銷憑證和隔離環境，隱私或法律團隊判斷通知義務，供應商管理人員聯繫模型與雲服務提供方，管理層則處理業務連續性和客戶影響。若權限分散在不同團隊，演練中應記錄從發現異常到完成止損所需的時間。

企業可以選一個具體場景做第一次演練：Agent 在深夜接到被篡改的任務，開始批量導出客戶資料並調用外部服務。演練參與者需要說明誰能暫停任務、哪個密鑰先撤銷、日誌存放在哪裡、外部供應商由誰聯繫，以及哪些業務在檢查數據完整性之前保持關閉。把動作走一遍，往往比單純更新一份政策文件更能暴露預案中的空白。

一次完整演練還要測試報告決策。假設凌晨 2 點發現異常，3 點凍結 Agent 賬戶，6 點確認數據流向境外接口，上午仍無法核實接收方是否留存。隱私、信息安全和業務負責人應在每個時間點分別記錄已知事實、待核查事項、臨時保護措施和下次更新節點。這樣，72 小時不會被誤當成"可以等三天再調查"的寬限期；管理層也能看見何時需要先作初步通報，何時需要向客戶給出直接風險提示。

恢復階段最容易被忽視的是業務數據。付款 Agent 重複執行後，停掉程序只能阻止新付款，已經發出的指令還要與銀行流水、客戶賬本及供應商帳單核對；客服 Agent 發送錯誤建議後，需要找出受影響的客戶並更正記錄。恢復審批應由業務負責人和安全負責人共同完成，至少確認憑證已更換、受影響數據已校驗、補償措施已經安排、監測閾值已更新。對外公告應使用已經核實的事實，避免把初步猜測寫成最終原因。

四、把英國政策信號轉成內部治理問題

英國的專門響應能力仍在建設，企業可以先把現有應急制度映射到 Agent 的運行方式：誰負責判定事故、誰可以停用系統、日誌由誰保全、哪些業務需要先通知客戶，以及恢復前由誰批准。對於受監管機構，AI 風險管理、外包治理和運營韌性要求也應納入同一套演練設計。

這項工作不必等到新的 AI 專門法規出台。只要 Agent 已獲得訪問、寫入或付款權限，企業就可以檢查這些權限是否有期限、是否按任務限定、是否可以緊急撤銷，並確認供應商故障或模型更新時業務如何降級運行。

從合同安排看，企業在採購 Agent 產品時就應取得事故處置所需的權利：緊急暫停或限流接口、導出調用記錄、獲知重大模型更新和安全事件、約束分包商訪問、要求供應商協助調查，並明確數據刪除和返還方式。若業務高度依賴一家供應商，還需要預先決定在它停服時改為人工處理還是切換備份服務。合同條款只有與真實操作流程、聯繫人和演練結果對應，事故發生後才能發揮作用。

筆者認為，法律實務中最值得先做的是一張"動作---責任"對照表。把讀取、修改、發送、付款四類 Agent 動作分別連接到授權人、可撤銷憑證、日誌位置、法定報告判斷者和業務恢復批准人。它可以從一個高風險系統開始製作，隨後擴展到全公司。企業每增加一個新工具連接，就更新這張表；一旦發生事故，值班人員能沿著同一條路徑完成止損和取證，法律人員也能據此判斷接下來應該通知誰。

本內容僅供參考，不構成任何金融、投資、法律或稅務建議。文中提及的任何活動、獎勵、線上活動或相關資訊，不應被視為對購買、出售或交易任何加密資產的推薦、招攬或邀請。加密資產具有高波動性，存在價值損失風險。WEEX服務、產品及相關活動的可用性可能因地區而異。用戶在參與前有責任確保符合當地適用法律法規。