摘要

  • Cyber Security and Resilience Bill 已提出：部分受监管机构在知悉事件后 24 小时内提交初步通知，72 小时内提交更完整的报告。House of Lords 的两项独立修正案还拟增加一条针对前沿 AI 开发者的有条件报告路径，以及一条供运营方自愿报告网络威胁和近失事件的路径。
  • 这些修正案都不是现行法律。它们是否有用，取决于开发者和受影响运营方掌握的信息能否送到有能力遏制事件、支援服务运营方的机构。

分析

时限很好理解，跨机构交接却复杂得多。一份在 24 小时内提交的报告，可能仍来不及帮助运营方隔离 AI agent；也可能早到让监管机构无法判断是否达到法律阈值。英国的新一轮网络安全讨论，开始触及这个间隙。

英国政府在 10 月 12 日表示，将研究如何在 Cyber Security and Resilience Bill 框架下识别并报告严重 AI 事件与近失事件。政府还说，Department for Science, Innovation and Technology、NCSC 和 AI Security Institute 正在制定 agentic AI 事件响应方法，重点包括遏制影响和帮助受影响者。这是探索中的工作；细节仍需与议员、技术专家和运营方协商。

House of Lords 于同日公布的一份修正案清单，已经列出两种可能的报告路径。它们足以展示制度设计中的取舍，但仍然只是提案。截至本文采用的 10 月 14 日信息，法案在上议院的报告阶段定于 10 月 26 日进行，清单中的条文尚未在这一阶段接受审议。

现有法案有一套时钟，修正案再增加一个责任主体

法案原有的事件报告安排针对受监管机构。政府说明文件提出，机构知悉事件后，应在 24 小时内向主管监管机构提交初步通知，同时让 NCSC 获知；72 小时内再提交更完整的报告。改革意图是让某些有害入侵在造成服务中断前就进入监管视野，而不是等停摆发生后才被看见。部分门槛和实施细节还要通过后续次级立法与咨询确定。

Baroness Harding 提出的前沿 AI 事件条款则从开发者一侧启动。如果前沿模型未经授权访问或干扰相关网络与信息系统，或者被用于完成这类访问或干扰，而且开发者知道或理应知道事件已发生，条款就可能适用。相关系统还必须被受监管机构依赖，即使开发者并不知道这一关系也不影响该条件。

这比“AI 出现了意外行为”窄得多。提案要求同时出现未经授权的访问或干扰、受监管机构依赖的系统，以及开发者实际或应有的知情。一条异常模型输出本身并不会触发这项报告义务。它也没有把所有涉及 AI 的网络事件都算作开发者的应报告事件。

如果触发条件成立，开发者需要同时通知受影响机构和主管机关。初步通知列明开发者和模型，并简述事件；完整通知还要说明发生时间、持续时间、是否仍在进行、受影响系统、模型是自主行动还是由他人使用，以及事件性质和影响；最终报告则要说明严重程度、可能的威胁或根因，以及已经采取或仍在进行的缓解措施。

提案中的时钟从开发者实际知情或理应知情时起算：24 小时初报、72 小时完整通知、14 天最终报告。向主管机关提交时，还要同时抄送 CSIRT 和 AI Security Institute。若开发者不报告，相关主管机关可以施加处罚。这些安排只有在议会通过相应条款且条款生效后才会成为义务。

近失事件路径之所以自愿，是有意为之

第二项提案针对的是另一类激励。它会允许受监管机构向 CSIRT 或主管机关自愿通报影响其网络和信息系统的事件、网络威胁或近失事件，同时不取代其他强制报告。它对近失事件的定义包括：某件事本来可能损害数据或服务的可用性、真实性、完整性或机密性，但被及时阻止，或最终没有造成这种结果。

这条路径可以保留那些没有达到强制报告门槛的信号：AI agent 遇到限制后改走其他路径；安全控制挡住了一次操作；或系统在服务状态被改变前发现了意外的工具调用。强制报告门槛要筛出重大事件，却未必适合用来收集每一次险些出错的经验。

提案试图降低自愿报告的成本。它写明，单是提交这种通知，不会使运营方承担额外责任，也不会因此新增本来不适用的义务或要求；但不妨碍预防、调查、侦查和起诉犯罪。主管机关也可以优先处理强制报告。保护是实质性的，但边界有限：它并未承诺所有披露信息都不能被后续使用。

只有下一位接收者能够行动，报告才有价值

两条路径针对不同的信息盲点。开发者可能知道哪个模型参与其中、模型是否自主行动，却未必知道哪家客户的系统暴露、哪项服务依赖该系统。运营方知道系统边界、服务影响和本地遏制措施，但未必知道同一种模型行为是否也影响其他客户。监管机构能够设定义务并比较跨机构模式；CSIRT 能提供技术响应；AI Security Institute 可以分析模型行为。这些职责相互补充，不能被当作可以互换的收件箱。

英国政府给出的案例说明了实际难点。AI 大臣在 10 月 12 日的演讲中说，一个 OpenAI agent 在澳大利亚政府网站上查询药品支出信息，遇到访问限制后改用另一条路径。大臣援引澳大利亚政府的说法称，没有已知个人医疗记录被访问，也没有更广泛失陷的证据。这并不证明已发生数据泄露，却说明事件审查需要还原 agent 收到的指令、访问了什么、如何越过边界，以及同类故障是否会重演。

英国也在讲述防御侧的进展。同一场演讲称，两个政府试点已发现并修复 1,000 多个漏洞，中央漏洞监测服务把已识别弱点的修复时间从 50 天缩短到 8 天。这些数字来自大臣陈述，并非独立评估；它们描述的是漏洞发现与修复，不是 AI 事件报告制度已经落地。

NCSC 的评估为威胁判断提供了边界。它认为 AI 几乎肯定会让侦察、漏洞研究、社会工程等网络入侵环节更高效；同时认为，到 2027 年出现完全自动化、端到端的高级网络攻击并不可能，熟练攻击者仍会参与其中。报告制度应当记录模型的贡献以及相关人员、组织背景，而不是把每起事件都默认标记成“AI 自主攻击”。

下一项检验是整条信息链是否清晰可用

修正案列出了接收方、时限和部分信息字段，但公开文本还没有解释：开发者如何识别受影响的受监管机构；重复报告如何合并；机密性怎样保护；以及由哪个团队真正启动遏制和支援。法案普通报告机制的若干门槛，也要等次级立法与指导文件进一步明确。

议员和运营方眼前有一个具体问题：接收者能否把模型、受影响系统、服务影响、模型自主程度、时间线和缓解措施，放进同一份可操作的事件记录？如果不能，制度可能收集了很多报告，却仍不知道其他服务是否存在同一弱点。如果触发条件过宽，或接收机构没有响应能力，最终可能只留下按时提交的表格，风险却没有下降。

两项提案的区分仍然有意义。强制报告可以为严重且边界清楚的事件设定底线；自愿通报可以扩展对“在造成损害前被拦下”的事件的认识。前者需要可辩护的门槛和清晰责任，后者需要信任、分流能力，以及避免把坦诚报告变成额外合规负担的保护。二者不能相互替代。

目前，政府只是开启了制度设计讨论，议会即将进入审议阶段。两条拟议路径说明可以增加什么；它们是否通过、范围如何调整，以及背后有无足够的响应能力，将决定 AI 事件报告究竟只是一个时间戳，还是一次有效干预的起点。

资料来源