英国准备应对 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服务、产品及相关活动的可用性可能因地区而异。用户在参与前有责任确保符合当地适用法律法规。