AI 事件与严重事故报告记录（事件台账 + 对外报告底稿）

章节结构（8）

1. 1. 一、事件分类分级与报告义务对照表

   先把"什么算事件、什么算严重事件、命中哪条报告义务"写成一张表，这是整份文档的地基。欧盟人工智能法案第 3 条第 (49) 项对"严重事件"作了定义，第 73 条则据此设定了不同的时限档位；文档中应逐档写明触发条件与对应时限：一般情形为在提供者（或部署者）知悉严重事件后立即报告，且无论如何不迟于 15 日，报告期限应考虑严重事件的严重程度；属于广泛侵害或第 3 条第 (49)(b) 项所定义严重事件的，应立即报告且不迟于 2 日；导致人员死亡的，在确立或一旦怀疑高风险系统与该严重事件存在因果关系后立即报告，且不迟于自知悉之日起 10 日。法条还允许在必要时先提交不完整的初步报告、随后补交完整报告——把这一点写进流程，可以避免团队因"信息不全"而错过时限。同一事件往往同时命中多条义务：涉及个人数据泄露的按 GDPR 第 33 条在知悉后 72 小时内向监管机关通报（如可能）、高风险时按第 34 条告知数据主体；在中国，网络产品服务存在安全缺陷漏洞且涉及危害国家安全、公共利益的，按《网络数据安全管理条例》第十条在 24 小时内向有关主管部门报告；生成式服务发现违法内容的按《生成式人工智能服务管理暂行办法》第十四条处置并向有关主管部门报告。报告对象一栏要单独核对一件事：第 73(1) 条的默认收件人是事件发生地成员国的市场监管机关，但条例 (EU) 2026/1744（AI Omnibus）第 1(31) 条在第 75 条新增第 1a 款——作为对第 73 条的减损，属于第 75(1) 条项下由人工智能办公室专属监管的高风险 AI 系统，其提供者应当向**人工智能办公室**报告严重事件，第 73(2) 至 (9) 款比照适用，再由人工智能办公室将相关信息迅速转交相应成员国的市场监管机关。第 75(1)(a) 项覆盖的正是"基于通用人工智能模型、且模型与系统由同一提供者（或同一企业内的提供者）开发"的 AI 系统（附件 I 产品相关、附件 III 第 2 点、执法/边境/金融机构在第 74(6) 条项下的情形、以及附件 III 第 8 点司法行政除外），中国自研基座并自建应用的企业极易落入这一档，填错收件人会直接导致"已报告但未向正确机关报告"。对照表的列建议为：事件类型 / 判定标准 / 适用法域与条款 / 报告时限 / 报告对象（按第 73 条还是第 75(1a) 条确定）/ 报告模板编号 / 内部决策人。

   需要附的证据

   • · 事件分类分级标准文件（含 AI 特有事件类型）
   • · 报告义务对照表（列如上，覆盖所有服务地域）
   • · "知悉"时点的认定规则（从哪个系统告警/工单/投诉起算）
   • · 各档时限的内部提前预警设置（如 2 日档在 12 小时内必须上会）
   • · 判定标准的年度复核记录

   常见失分点

   • · 只准备了信息安全事件分级，没有 AI 特有事件类型（模型输出造成的健康、安全或基本权利损害、关键基础设施中断、歧视性结果）；
   • · "知悉"时点无认定规则，事后对是否超期各执一词；
   • · 把 15 日当作默认档，忽略 2 日与 10 日两档更短的时限；
   • · 报告对象一律填成「事件发生地成员国市场监管机关」，未判断是否属于第 75(1a) 条应向人工智能办公室报告的情形；
   • · 对照表只覆盖欧盟，在中国、新加坡等市场的报告义务缺失；
   • · 未设计"先报不完整初步报告"的路径，团队等齐信息才报而超期。

2. 2. 二、事件发现渠道与受理登记

   列出全部可能发现事件的渠道并确保每一条都通向同一个受理入口：系统监控与告警、上市后监测（第 72 条）指标异常、日志（第 12 条）分析、用户投诉与举报、部署者与企业客户反馈、外部研究者的漏洞披露、媒体与社交平台舆情、监管机关或执法机关的问询、以及内部员工上报。每条渠道写明：接收人/系统、7×24 覆盖情况、转入受理入口的方式与时延。受理登记要在第一时间固定几项事实：发现时间、发现渠道、初步描述、涉及的系统与版本、涉及的地域与用户范围、初步严重性判断、以及"知悉"时点的认定。登记本身必须快于任何判断——很多超期不是因为判断慢，而是因为最初几个小时没人登记，时钟其实早就开始走了。

   需要附的证据

   • · 发现渠道清单与各渠道的接收人、覆盖时段
   • · 统一受理入口的配置与转单规则
   • · 受理登记表模板（含"知悉"时点字段）
   • · 各渠道到受理的时延统计
   • · 漏洞披露政策与外部研究者响应记录
   • · 监管问询的接收与转办流程

   常见失分点

   • · 客户通过销售或客服反馈的问题从未进入事件流程，几周后才被发现是严重事件；
   • · 渠道只覆盖工作时间，周末与节假日的事件无人受理；
   • · 受理登记要求填写字段过多，一线为了省事直接跳过登记；
   • · 漏洞披露邮箱无人查收，研究者转向公开披露，事件以最坏方式暴露；
   • · 监管问询由个别员工私下处理，公司层面无记录。

3. 3. 三、严重性判定与因果关系认定

   第 73(2) 条把报告触发点设在"提供者已确立 AI 系统与该严重事件之间的因果关系或此种关系的合理可能性"。"合理可能性"这一措辞很关键：不需要完成根因分析才开始计时，只要因果关系有合理可能即应报告。因此判定流程要分两步：先做快速判定（是否可能属于严重事件、是否可能与 AI 系统相关、命中哪一档时限），再做详细认定（根因、影响范围、责任边界）。快速判定必须在小时级完成并有明确决策人，详细认定可以并行推进。判定内容包括：损害类型与程度（人身伤害、健康损害、财产损失、基本权利侵害、关键基础设施中断、环境损害）、受影响人数与地域、事件是否仍在持续、以及是否存在扩散风险。因果关系认定要保留技术证据链：相关日志、模型版本、输入输出样本、配置快照。注意第 73(6) 条：报告后提供者应当立即就该严重事件与相关 AI 系统开展必要调查，包括对事件进行风险评估并采取纠正措施；提供者应当在调查期间与主管机关（必要时还有相关公告机构）合作，且在告知主管机关之前不得进行任何可能以影响后续原因评估的方式改变该 AI 系统的调查——这一条意味着"先改再报"是明确被禁止的。

   需要附的证据

   • · 快速判定流程与决策人指定（含 7×24 备份人）
   • · 严重性判定记录（损害类型、程度、范围、持续性）
   • · 因果关系认定的技术证据链（日志、版本、样本、配置快照）
   • · 证据固定与保全流程（避免被后续修复覆盖）
   • · "不得在告知主管机关前改变系统"的技术控制（变更冻结机制）
   • · 判定分歧时的升级路径

   常见失分点

   • · 等根因分析完成才开始计时，而法条以"合理可能性"为触发点，时限早已开始；
   • · 工程团队第一反应是回滚与热修，把关键证据与现场覆盖掉，且在告知主管机关前已改变系统；
   • · 判定决策人只有一人且无备份，事件发生在其休假期间时无人拍板；
   • · 日志留存期限短于调查周期，关键时段数据已被清理；
   • · 严重性判定只看技术影响，未评估基本权利影响与受影响人数。

4. 4. 四、应急处置、遏制与用户保护措施

   在报告的同时推进处置，但两条线要分开记录，避免处置动作污染证据。处置内容包括：遏制（限流、关闭受影响功能、回滚到上一稳定版本、提高人工复核比例、针对性拦截规则）、影响消减（撤回错误输出、纠正已作出的错误决定、为受影响个人提供救济）、以及恢复（验证修复有效、分阶段恢复、加强监控期）。每一项动作记录：动作内容、执行人、执行时间、审批人、以及是否可能影响后续原因评估——最后这一项对应第 73(6) 条的限制，若某项动作会改变系统状态且可能影响原因评估，须在告知主管机关后再执行，或在执行前完整保全现场。用户保护方面要判断三件事：是否需要向受影响用户直接告知（GDPR 第 34 条在对自然人权利与自由可能造成高风险时要求不当延迟地告知数据主体）、是否需要向企业客户履行合同项下的通知义务、以及是否需要发布公开说明。中国《网络安全法》第二十七条要求制定网络安全事件应急预案并按规定及时处置与报告，应急预案应当与本节的处置流程保持一致。

   需要附的证据

   • · 处置动作台账（动作、执行人、时间、审批人、对原因评估的影响判断）
   • · 证据保全记录（快照、日志导出、哈希）
   • · 受影响用户告知文本与发送记录（含语言版本）
   • · 企业客户通知记录与合同条款依据
   • · 公开说明发布记录与口径审批
   • · 错误输出撤回与错误决定纠正的执行记录
   • · 网络安全事件应急预案文本与本次演练/实战对照

   常见失分点

   • · 为尽快止损直接修改线上系统，未保全现场也未先告知主管机关，违反第 73(6) 条的限制；
   • · 只做技术遏制，未纠正已经作出的错误决定，受影响个人的损害持续；
   • · 对企业客户的通知时限长于合同约定，触发违约；
   • · 公开说明与向监管提交的报告口径不一致；
   • · 应急预案是文档柜里的文件，实战时无人按它执行。

5. 5. 五、对外报告底稿与提交记录

   为每一类报告义务预先准备一份底稿模板，事发时只需填空。欧盟严重事件报告底稿应覆盖：提供者与欧盟授权代表信息；AI 系统标识与版本；严重事件发生地成员国（第 73(1) 条要求向事件发生地成员国的市场监管机关报告）；事件描述与时间线；损害类型与受影响人数；因果关系的当前认定与证据；已采取与拟采取的措施；以及联系人。GDPR 第 33(3) 条对泄露通报的内容有明确要求：描述个人数据泄露的性质，包括在可能情况下说明受影响数据主体的类别与大致人数以及受影响个人数据记录的类别与大致数量；提供数据保护官或可获取更多信息的其他联系点的姓名与联系方式；描述个人数据泄露可能造成的后果；描述控制者已采取或拟采取的应对措施，包括在适当情况下为减轻可能的不利影响所采取的措施。中国 24 小时报告底稿应覆盖缺陷/漏洞情况、涉及范围、可能危害、已采取措施与后续计划。每份底稿附上：提交渠道、接收方联系方式、以及历史提交记录（提交时间、方式、回执、后续沟通）。第 73(5) 条允许先提交不完整的初步报告并随后补交完整报告，因此底稿应设计成"初步版/完整版"两栏。

   需要附的证据

   • · 各类报告底稿模板（初步版/完整版两栏）
   • · 报告对象清单与联系方式（按成员国/地区、含备用联系方式）
   • · 提交渠道说明与账号/凭据的可用性检查记录
   • · 历史提交记录与回执
   • · 补充报告与后续沟通记录
   • · 报告内容的内部审批流程（谁有权签发对外报告）

   常见失分点

   • · 事发时才查找主管机关联系方式，几小时耗在找人上；
   • · 不知道向哪个成员国报告——第 73(1) 条指向事件发生地成员国，而非公司注册地；
   • · 坚持等信息齐全再报，放弃了第 73(5) 条允许的初步报告路径；
   • · GDPR 通报缺少第 33(3) 条要求的要素（尤其是可能后果与减轻措施）；
   • · 对外报告由工程团队直接发出，未经法务审阅，用词造成不必要的责任承认。

6. 6. 六、价值链通知：向上游提供者与下游部署者的信息流转

   AI 事件很少停留在一家公司内部。本节写明双向的信息流转安排。向上游：若事件与所使用的第三方模型、数据集或组件相关，按合同与第 25 条的配合安排通知上游提供者，并索取其掌握的信息（日志、已知问题、其他客户的类似报告）。向下游：若本公司是模型或系统的提供者，事件可能影响下游部署者履行其自身义务（第 26 条的运行义务、第 27 条的 FRIA 更新、第 73 条的部署者报告路径），应及时通知并提供足以让其判断影响的信息——包括受影响的版本区间、触发条件、临时缓解措施与修复时间表。第 73 条同时覆盖提供者与部署者：部署者在某些情形下自身负有报告义务，其报告依赖提供者提供的信息，因此通知的及时性直接决定下游能否合规。企业客户合同中通常另有更短的通知时限（24 小时或 48 小时），要与法定时限一并纳入时间线管理。通知内容要事前拟定统一口径，避免不同销售对不同客户给出不一致的说法。

   需要附的证据

   • · 上下游通知对象清单与合同项下的通知时限
   • · 通知模板（上游索取信息 / 下游影响告知两类）
   • · 通知发出记录与对方回执
   • · 向上游索取信息的请求与答复记录（第 25(4) 条）
   • · 统一对外口径文件与其审批记录
   • · 下游部署者履行自身报告义务所需信息的清单

   常见失分点

   • · 只顾自己向监管报告，忘记下游部署者也有报告义务且依赖你提供信息；
   • · 合同约定的 24 小时客户通知被忽略，法定 72 小时被当作统一口径；
   • · 不同销售对不同客户给出不同版本的事件说明；
   • · 向上游索取信息无正式记录，事后无法说明已尽合理努力；
   • · 通知内容过于笼统（"存在一个已修复的问题"），下游无法判断自身是否受影响。

7. 7. 七、调查、纠正措施与风险管理回流

   第 73(6) 条要求：报告之后提供者应当立即就该严重事件与相关 AI 系统开展必要调查，包括对事件进行风险评估并采取纠正措施；并在调查期间与主管机关以及（若相关）有关公告机构合作。本节写明调查与纠正的闭环：调查范围与方法（日志分析、复现、数据审查、代码审查、人员访谈）；根因分析结论（技术根因、流程根因、组织根因，三层都要写）；纠正措施（立即措施、短期措施、结构性措施，各自的负责人与时限）；有效性验证（如何证明同类事件不会复发——新增的测试用例、监控指标、门禁规则）；以及回流路径——事件结论必须回到第 9 条风险管理体系（新增或调整风险条目）、附件 IV 第 6 项变更台账（记录为相关变更）、第 72 条上市后监测计划（新增监测指标）、以及技术文档相应章节。若事件暴露出的是设计层面的问题，还要评估是否构成第 43(4) 条意义上的实质性修改，进而是否需要重新合格评定。调查过程中与主管机关的每一次沟通都要留痕。

   需要附的证据

   • · 调查方案与调查报告（含三层根因分析）
   • · 纠正措施台账（分级、负责人、时限、完成证据）
   • · 有效性验证记录（新增测试用例、监控指标、门禁规则）
   • · 风险登记表的更新记录（新增/调整条目）
   • · 变更台账与技术文档的同步更新记录
   • · 实质性修改判定记录（第 43(4) 条）
   • · 与主管机关及公告机构的沟通记录

   常见失分点

   • · 根因分析只到技术层（"某个阈值设置错误"），不追流程与组织根因，同类事件半年后重演；
   • · 纠正措施全部是"加强监控""加强培训"，无结构性改动；
   • · 调查结论从未回流到风险登记表与技术文档，闭环断裂；
   • · 设计层面的修复未评估是否构成实质性修改，合格评定状态存疑；
   • · 与主管机关的沟通由不同人分头进行，口径不一致。

8. 8. 八、事件台账、指标与演练

   台账是本模板在平时的形态，也是监管检查与客户尽调时最能说明治理成熟度的材料。建议字段：事件编号、发现时间、"知悉"时点、发现渠道、涉及系统与版本、涉及地域、事件类型与严重级别、是否触发各法域报告义务（逐条勾选）、各项报告的实际提交时间与时限余量、遏制措施、根因层级、纠正措施与关闭时间、经验教训、以及关联的风险登记表条目编号。基于台账做趋势分析：事件数量与类型分布、平均发现时长与平均报告时长、时限达成率、重复根因占比、纠正措施按期关闭率。这些指标同时服务于第 72 条上市后监测。演练方面：至少每年一次桌面推演，覆盖最短时限档（2 日档与 24 小时档），验证联系方式可用、决策人可达、模板可用、证据可快速保全；每次演练记录发现的问题并纳入改进。另需明确台账的保存期限与访问权限——事件记录往往含敏感技术细节与个人信息，既要可被监管调阅，也要受控。

   需要附的证据

   • · 事件台账（字段如上，含时限余量字段）
   • · 趋势分析报告（按季度或半年）
   • · 指标定义与计算方法说明
   • · 年度演练计划、演练脚本与演练记录
   • · 演练发现的问题清单与改进落实记录
   • · 台账保存期限、访问权限与脱敏规则
   • · 与上市后监测计划的指标对接说明

   常见失分点

   • · 台账只记录"已关闭"，没有时限余量数据，无法证明各档时限被遵守；
   • · 从未演练最短时限档，真实事件中发现联系方式失效或决策人无法联系；
   • · 重复根因占比很高却无人关注，说明纠正措施长期流于表面；
   • · 台账权限过宽，含个人信息的事件详情被大范围可见；
   • · 事件指标与上市后监测各成体系，同一现象被统计两次且口径不同。