严重事件报告

11 分钟读完

C13
运维 · 治理与合规

严重事件报告:两天期限考的是发现能力。

自 2026 年 8 月 2 日起,欧盟高风险 AI 系统的提供者只有两天时间,就"大范围侵害基本权利"向市场监管机构报告——而这个时钟不是从法务读到卷宗那一刻起算的,是从组织有合理理由相信自家系统与该损害之间存在因果关联那一刻起算的。两天不是一个写文书的时间表,是一个工程时间表;而几乎所有智能体架构的搭法,都让这条因果关联很难被及时确立:损害显现在一次人工决策的下游,那条轨迹早被采样丢掉了,而看见结果的一方并不是必须去申报的那一方。

STEP 1

触发报告的是后果,不是"模型干了坏事"。

人的第一反应是去找一条"智能体做了什么算坏事"的定义。没有这样的定义。第 3(49) 条是按后果来界定严重事件的,而 AI 系统只要对该后果有所促成即可——直接或间接都算。

  • 致人死亡或对人的健康造成严重损害。整套制度里最快的那个时钟挂在这里。
  • 对关键基础设施的管理或运行造成严重且不可逆的扰乱。
  • 违反欧盟法中旨在保护基本权利的义务。对多数智能体部署而言,真正会被触发的是这一类——招聘或信贷决策中的歧视、对个人数据的非法处理、对某项服务的拒绝准入。它完全不含人身伤害这一要素。
  • 对财产或环境造成严重损害。

在动手设计之前,这种"按后果界定"的框架有两个推论值得先吃透。其一,一个运行完全正常的系统也可能产生一起须报告的事件:不需要任何东西出故障。其二,欧盟委员会的指南草案认为间接因果关联即已足够——它自己举的例子就是:AI 系统给出一份错误分析,只有在临床医生据此行动之后才造成损害。人在回路并不切断这条链。这一点值得说得直白些,因为多数智能体设计里的人工审批环节,都被悄悄当成了一道责任防火墙,而在这里它不是。

注意什么是严重事件:一个没人据以行动的错误答案、一次宕机、一次成本超支、一次没有造成后果的越狱。它们属于故障响应,并且就留在那里。把两者混为一谈,要么造出一条每逢 Sev-3 就触发的监管流水线,要么——远为常见——造出一套从来没有问过基本权利这个问题的工程故障流程。

STEP 2

三个期限,以及决定你架构的那一个。

第 73 条设定的外沿是"自知悉起 15 天",另有两条加速通道;并且无论适用哪条外沿,一旦确立因果关联就必须"立即"报告。

  • 15 天——默认期限,自提供者(或在适用情形下的部署者)知悉该严重事件时起算。
  • 2 天——大范围侵害,或对关键基础设施的严重且不可逆的扰乱。这是应当驱动你做仪表化的那个期限,因为它是唯一一个任何人工流程都撑不过去的。
  • 10 天——可能已致人死亡的情形;这里的触发点被明确写成"已确立、或一旦怀疑存在因果关系"。

泄压阀在第 73(5) 条:允许先提交一份初步的、不完整的报告,其余后补。用它。义务是在窗口内通知,不是在窗口内查完;把这个期限当成调查期限的组织,正是会错过它的那些。初步报告仍然需要的,是足以指明系统、后果、受影响方,以及你为何认为两者相关联——而这个东西,你的遥测要么产得出来,要么产不出来。

把两天通道读成一条系统需求,其余就都跟着出来了:你必须能在数小时而不是数周内回答"是我们哪个系统碰过它、哪个版本、代表谁、输出了什么"。如果这个查询现在还得靠人去日志库里 grep,你就没有两天的能力,再多的政策文档也变不出一个来。

STEP 3

义务和观察,落在不同的公司里。

报告义务落在提供者身上——即以自己名义把这套高风险系统投放市场的一方。而看见损害的,几乎总是部署者。第 26(5) 条把这个环闭上:部署者一旦识别出严重事件,必须立即告知提供者,随后告知进口商或分销商以及相关市场监管机构。

  • 如果你做的是智能体产品,你大概率是提供者,而你的两天时钟,可能由一封周五傍晚六点落进共享收件箱的客户工单启动。从客户到合规的这条接入路径就是那个控制点,而它通常根本没被设计过。
  • 如果你部署的是别人的智能体,你在这条链上,时限外包不出去。你告知提供者的义务是"立即",而提供者能否守住两天期限,取决于你的工单何时到达他们手里。这就是第三方与供应商风险里那套合同论证的具体版本。
  • 实质性修改会把你变成提供者。在系统上署自己的名字,或改变其预期用途,都会把义务挪到你头上——对任何把基础模型包成智能体再卖出去的人来说,这是个现实问题。趁事件还没替你决定之前,用白纸黑字定下来;角色映射属于责任与角色
  • 通用模型提供者另有一条平行义务。依第 55(1)(c) 条,具系统性风险的通用 AI 模型提供者自 2025 年 8 月 2 日起就必须追踪、记录并向 AI 办公室报告严重事件,委员会也已发布了配套模板。如果你的智能体建在这类模型上,画面里就有两条报告链,而它们并不会合并。

写一句话,按角色而非按团队指明:谁能在周日凌晨两点拍板"这件事须报告";再写一句话指明其替补。历史上凡是真正跑得起来的严重事件制度,都有这么一句话,而它是本页里最便宜的一件产出物。

STEP 4

为什么智能体在结构上就不擅长确立因果关联。

法规的要求其实不高——确立因果关联,或有合理理由相信存在因果关联。之所以难,是因为让智能体好用的那些性质,恰恰就是摧毁证据链的那些。

  • 损害发生在模型下游好几步之外。智能体起草了一封拒信、人把它发了出去、一位候选人被排除了。要主张或排除因果关联,你需要的是整条轨迹而不是最终输出——这正是轨迹级记录不只是评估产物、同时也是合规产物的原因。
  • 轨迹会被采样,轨迹会过期。1% 的采样率是很好的可观测性实践,同时也意味着一百次里有九十九次你无法还原当时发生了什么。30 天的保留窗口很正常,而第 45 天才到的投诉,就是一件你查不了的投诉。这件事在保留与法律保全里定夺,而通常真正做决定的,是当初在链路追踪配置里设默认值的那个人。
  • 产生那次输出的版本已经不存在了。模型版本在轮换、提示词被改过、检索索引被重建过。若没有一份钉死的记录写明某次运行究竟由哪个模型、哪版提示词、哪套工具与哪版索引提供服务,"是不是系统造成的"就无从回答——这是发布与版本管理那套纪律,只不过施加在证据上而不是发布上。
  • 检索是常见的混杂因素。当有害内容来自一份被检索到的文档时,因果问题就分叉了:是系统推理错了,还是忠实地复述了一个糟糕的来源?两者的纠正措施不同,而如果你只记录了答了什么、没记录检索到了什么,就分不开。
  • 非确定性意味着你复现不出来。重跑一遍提示词、得到一个可接受的答案,并不能证明系统没有造成那次损害;而在时间压力下,这是个很诱人的结论。证据是那份记录,不是那次重跑。

这五点指向同一个修法,而它不是一个合规项目。它是一个关于"轨迹里装什么、能活多久"的决定——正是在这一点上,链路追踪不再只是工程上的方便,而成了让你能在两天内报出去的那样东西。

STEP 5

一个事件,多个时钟,不同的收件人。

同一次智能体失败,可以同时是一起严重事件、一起个人数据泄露和一次 ICT 事件,而这些制度之间并不互相让路。搭一条假定"只有一项义务"的流水线,是最常见的错误。

  • GDPR——个人数据泄露须在 72 小时内报给监管机构,判定标准不同,收件人也不同。一个把某客户数据邮件发给了另一位客户的智能体已经触发了它,至于有没有触发第 73 条,则要另行判断。
  • NIS2 与 DORA——各有自己的、往往更快的时钟的行业性事件制度。对 DORA 下的金融实体,对委员会指南较合理的读法是:运营中断走 DORA 通道,而基本权利侵害仍然触发《AI 法案》的申报。请按你所在行业核对当下的口径,别假定它们会合并。
  • 行业产品安全法规——当高风险系统是某受监管产品的安全组件时,既有的事件制度适用,第 73 条会做相应调整以避免重复申报。
  • 客户合同——企业协议里的通知窗口经常比任何一项法定期限都短,而那才是你的客户团队真正会感受到的那个期限。

建一个入口、多个出口。一条一次性把事件对照所有适用制度做完分类的分诊路径,胜过几条各自只看到局部的并行流水线——而且只有在这种结构里,才会有人注意到"GDPR 的时钟三十小时前就开始跑了,而《AI 法案》的评估还在进行中"。那些定性问题应该和技术问题写在同一张表单上。

STEP 6

该建什么,以及按回报排的顺序。

这里没有一件是大工程。但每一件都必须在事件之前就存在,因为没有一件能在两天窗口之内造出来。

  • 一条有具名负责人和明确响应时限的接入路径。凡是可能报进损害的渠道——客服、销售、安全邮箱、产品内的举报按钮——都必须汇入同一个分诊队列,由一个具名角色盯着。多数组织的缺口就在这里:在一张工单被认出"这不只是个 bug"之前的那九十分钟里。
  • 一条活得够久的轨迹。对任何触及附件三用例的系统,保留完整轨迹而非采样,并钉住模型、提示词、工具与索引版本,保留时长至少覆盖你的投诉窗口加上调查时间。这是一笔成本——请刻意地付它,而不是在调查过程中才发现当初的采样率。
  • 一个按主体和时间的查询能力。任何真实事件里的第一个问题都是"把涉及这个人、在这些日期的所有运行调出来"。如果你的轨迹只按请求 ID 建了索引,这个查询要花一周。在数据治理政策划定的边界内,为它建好索引。
  • 一份预填好的报告模板。委员会已发布报告模板;其中稳定的部分——系统标识、预期用途、部署地域、提供者信息、版本命名体系——应当事先就填好,并每季度复核。只有事件相关的字段才该在时间压力下现写。
  • 一次按两天通道跑的演练。取一个说得通的基本权利场景,从一封虚构客户邮件到达那一刻开始掐表,看 48 小时后是否已经存在一份可提交的初步报告。这个演练第一次跑,通常失败在取轨迹那一步,而不是法务那一步。就按你跑故障响应的方式来跑它。
  • 一份纠正措施记录。报告不是终点:法规设想的是调查、纠正行动以及与监管机构的配合。你事后改的任何东西,都必须能追溯回那起事件,这与审计轨迹是同一条证据链。

这个季度就把演练做了,在写任何政策之前。挑一个已经上线、触及附件三用例的智能体,编一起说得通的歧视投诉,计时看回答这三个问题要多久:涉及这个人的是哪几次运行、由哪个模型和哪版提示词服务、智能体究竟做了什么。任何一个答案超过一天,那就是你的结论——而且它是个工程问题,不是法务问题。15 天这个标题期限不是真正的要求;真正的要求是一条从收件箱到"有证据支撑的因果主张"的两天通路,它由保留、索引和一个具名的人搭起来,而这三样都没法事后临时开通。

相关:面向智能体的欧盟《AI 法案》看这条义务所处的整体框架,责任与角色看谁是提供者、谁是部署者,决策回执看那份让因果关系可被论证的按决策记录,以及监管全景看还有哪些制度的时钟与这条并行在跑。