serious-incident-reporting

name

serious-incident-reporting

description

依据欧盟 AI 法案（Regulation (EU) 2024/1689，KI-Verordnung）第 73 条对高风险 AI 系统进行严重事件报告（SIR）。跨四个第 3(49) 条损害类别评估、定性、起草和提交第 73 条严重事件报告通知：死亡或严重健康损害、关键基础设施中断、违反欧盟法律下保护基本权利的义务，以及严重财产或环境损害。涵盖第 73 条期限档（2/10/15 天）、市场监督当局通知、第 26(5) 条下的部署者义务、与 GDPR 第 33/34 条违约通知、NIS2 第 23 条事件报告、DORA 第 19 条 ICT 事件和 MDR 警戒的跨法规映射、纠正措施、根本原因分析，以及通过德国市场监督（BNetzA、BaFin、BSI、BfArM、KBA）的 DACH 区域路由。当被要求评估 AI 事件是否可报告、起草第 73 条严重事件报告通知、构建 AI 事件响应手册、处理 AI 故障、AI 偏见事件、AI 歧视事件或自动化决策失败、识别正确的市场监督当局、管理 2/10/15 天第 73 条期限，或处理欧盟 AI 法案下的 schwerwiegender Vorfall（严重事件）时使用。

欧盟 AI 法案下的严重事件报告（第 73 条）

本技能帮助评估涉及 AI 系统的事件是否触发欧盟 AI 法案第 73 条下的严重事件报告义务，然后将该法律分析转化为实际的响应计划、通知草稿和内部行动清单。

它专为需要可用流程而非抽象评论的提供者、部署者、法律/合规团队、产品负责人和事件响应团队而设计。

何时使用本技能

当用户希望以下事项时使用本技能：

• 评估 AI 相关事件是否构成欧盟 AI 法案下的严重事件
• 决定系统是否因实际为高风险而在范围内
• 确定报告何时必须发生以及属于哪个期限档
• 识别要通知的市场监督当局
• 准备一份实际的第 73 条报告
• 理解第 26(5) 条下的部署者通知义务
• 协调第 73 条与GDPR、NIS2、医疗器械、机械或产品安全报告
• 创建内部事件手册、升级矩阵或管理层简报

开始前的快速现实检查

此工作流仅在系统实际是欧盟 AI 法案下的高风险 AI 系统时适用。

这意味着：

1. 它依据第 6(1) 条属于高风险，因为它是附件 I 产品的安全组件，或其本身就是须经第三方合格评定的此类产品；或
2. 它属于附件 III，且未被第 6(3) 条例外排除。

如果系统仅因靠近受监管工作流而被假定为高风险，先停下来确认分类。如果第 6(3) 条貌似适用，第 73 条下的事件报告可能不会触发，因为该系统从一开始就不在范围内作为高风险。

本技能的产出

根据请求，产出以下部分或全部：

• 一份定性备忘录：范围内 / 范围外 / 不确定
• 一份期限评估：2 天 / 10 天 / 15 天 / 后续报告
• 一份按成员国的接收方地图
• 一份第 73 条事件报告草稿
• 一份跨法规通知矩阵
• 一份面向法律、产品、安全和管理的内部行动检查清单
• 一份用通俗商业语言撰写的简短管理层简报

---

首先快速提问

保持首次接案简短实用。只询问分类和分诊所需的内容。

最低接案问题

1. 涉及哪个 AI 系统？

   • 产品名称
   • 版本/构建
   • 提供者法律实体
   • 预期用途

2. 您为何认为它是高风险的？

   • 附件 I 安全组件/产品？
   • 附件 III 用例？
   • 有任何先前的分类备忘录？
   • 有任何第 6(3) 条非高风险评估？

3. 发生了什么？

   • 发现日期/时间
   • 如不同，事件发生日期/时间
   • 系统做了什么或未能做什么
   • 目前理解的因果链

4. 发生了或可能发生什么损害？

   • 死亡
   • 严重健康损害
   • 严重财产损害
   • 严重环境损害
   • 关键基础设施管理的严重且不可逆的中断

5. 事件发生在何处？

   • 成员国
   • 客户/部署者位置
   • 跨境影响？

6. 谁首先识别了它？

   • 提供者
   • 部署者
   • 分销商/进口商
   • 最终用户 / 受影响人
   • 当局 / 媒体 / 举报人

7. 已经做了什么？

   • 系统已暂停？
   • 用户/部署者已被告知？
   • 回滚 / 紧急停止 / 访问限制？
   • 内部调查已开始？

8. 有任何重叠的制度吗？

   • 个人数据泄露？
   • NIS2/网络事件？
   • 医疗器械或体外诊断？
   • 机械 / 产品安全？
   • 劳动 / 工作场所影响？

如果时间极短

只问以下四个：

• 系统确定是高风险的吗？
• 事件造成或貌似促成了死亡或严重损害吗？
• 发生在哪个成员国？
• 提供者或部署者何时首次知悉？

---

核心工作流

按此顺序执行。

步骤 1 — 确认范围：系统实际是高风险的吗？

不要直接跳到报告。

1A. 高风险门禁

检查系统是否依据第 6 条属于高风险：

• 第 6(1) 条：附件行业产品 / 安全组件路径
• 第 6(2) 条：附件 III 路径
• 第 6(3) 条：对某些不构成重大损害风险且不实质影响决策的附件 III 系统的可能例外，画像情形除外

1B. 决定

• 是，明确高风险 → 继续到步骤 2
• 否，明确非高风险 → 第 73 条不适用；仍评估其他制度
• 不清楚 → 说明分类不确定性本身即属重大，并在紧急核验分类的同时以防备性分诊继续

实务指示

如果用户无法提供先前的分类备忘录，请索取：

• 预期用途
• 用户群体
• 行业/背景
• 输出是否实质影响关于人员或安全的决定
• 系统是否为安全组件或受监管产品

如果存在真正的歧义和潜在的严重损害，在分类澄清期间建议采取保守的事件响应姿态。

更深入逻辑请使用 references/incident-qualification.md。

---

步骤 2 — 定性事件：它是"严重事件"吗？

依据第 3(49) 条，这是法律阈值步骤。

出于实务目的，如果事件直接或间接导致、可能已导致，或貌似促成了以下任一情形，将其视为严重事件：

• 人员死亡
• 对人员健康的严重损害
• 关键基础设施管理和运营的严重且不可逆的中断
• 违反旨在保护基本权利的欧盟法律义务，且该违反后果严重
• 出于运营分诊目的，在事实与法定严重损害阈值或相邻行业规则相符时，也将严重财产或环境损害视为需要立即法律审查并可能规划通知

决策树

1. 事件是否涉及在运行、输出、失败、滥用或可预见滥用中的高风险 AI 系统？

   • 如果否 → 不属于第 73 条
   • 如果是 → 继续

2. 是否存在与系统相关的实际损害，或有充分证据的近期损害情景？

   • 如果否 → 除非事实变化，记录为非严重事件 / 上市后问题
   • 如果是 → 继续

3. 损害是否落入严重类别？

   • 死亡
   • 严重健康损害
   • 重大基本权利影响
   • 关键基础设施中断
   • 可能需要并行报告的同等严重行业损害

4. 是否存在因果联系，或至少有合理可能性？

   • 如果是 → 可报告时间线开始计算
   • 如果不确定但貌似可能 → 视为升级案件；保存证据并快速决定
   • 如果明确否 → 记录原因并监控

实务规则

不要等待完美的取证证明。第 73(2) 条在提供者已确定因果联系或存在该联系的合理可能性时即被触发。

示例和边界情况请使用 references/incident-qualification.md。

---

步骤 3 — 将事件放入正确的期限档

一旦存在因果联系或合理可能性，确定报告期限。

情形	期限	条款	触发
标准严重事件	立即，最多 15 天	第 73(2) 条	已确定因果联系或合理可能性
广泛侵权或第 3(49)(b) 条类型	立即，最多 2 天	第 73(3) 条	知悉事件
人员死亡	立即，最多 10 天	第 73(4) 条	已确定或疑似因果联系

标准规则 — 第 73(2) 条

• 在确定因果联系或合理可能性后立即报告
• 且不迟于提供者或（如适用）部署者知悉严重事件后 15 天

加速规则 — 第 73(3) 条

如果存在：

• 广泛侵权，或
• 第 3(49)(b) 条所覆盖类型的严重事件

则报告：

• 立即，且
• 不迟于知悉后 2 天

死亡规则 — 第 73(4) 条

如果事件涉及人员死亡：

• 一旦确定甚至疑似因果联系，立即报告
• 且不迟于知悉后 10 天

不完整的初始报告 — 第 73(5) 条

如果事实仍在发展中：

• 按时发送初始不完整报告
• 尽快附上更完整的报告

后续调查 — 第 73(6) 条

报告后：

• 毫不迟延地调查
• 进行风险评估
• 采取纠正行动
• 与当局合作
• 在通知当局之前，避免以可能损害因果分析的方式改变系统

期限逻辑请使用 references/reporting-requirements.md。

---

步骤 4 — 识别正确的接收方当局

基线规则很简单：

• 通知事件发生地成员国的市场监督当局

但实施在操作上很棘手，尤其是在跨境或行业特定案件中。

4A. 核心接收方逻辑

• 事件发生在单一成员国 → 通知该国的市场监督当局
• 事件发生在多个成员国 → 在适当处准备主导国地图和并行通知
• 位置不确定 → 识别损害在何处实现、系统在何处部署，以及受影响人或基础设施位于何处

4B. 德国

对德国，将联邦网络局（Bundesnetzagentur，BNetzA）作为 AI 法案市场监督路由的主要实务入口点，同时检查是否需要行业特定的主管当局参与。

常见示例：

• 医疗器械背景 → 国家医疗器械当局链
• 机械 / 产品安全背景 → 行业产品安全渠道可能也重要
• 关键基础设施或网络背景 → NIS2 / BSI 或行业特定渠道可能并行运行
• 雇佣背景 → 增加劳动、劳资委员会和数据保护分析

4C. 第 62 条参考

第 62 条（"报告违规和举报人保护的渠道"）要求成员国建立报告违规的渠道。在实践中，这些渠道也充当事件相关问题与操作指导的入口点。AI 办公室预计将提供模板和信息工具。第 62 条本身不是事件报告规则，但它在识别正确联系点方面具有操作重要性。

请使用 references/dach-specific.md 和 references/reporting-requirements.md。

---

步骤 5 — 构建报告包

至少围绕当局会期待的字段组装报告包，即使首份报告不完整。

基本内容

1. 提供者识别

   • 法律实体
   • 地址 / 联系方式
   • 如相关，授权代表
   • 关键事件联系人

2. AI 系统识别

   • 名称/型号/版本
   • 如相关，CE / 合格 / 注册标识符
   • 高风险类别和法律依据
   • 预期用途和部署环境

3. 事件事实

   • 事件日期/时间
   • 知悉日期/时间
   • 地点 / 成员国
   • 受影响的部署者/客户
   • 发生了什么的事实叙述

4. 影响和受影响方

   • 受影响人员的数量和类型
   • 损害的性质和严重性
   • 损害是否仍在持续
   • 关键基础设施 / 公共服务影响
   • 是否有工人或弱势人群受影响

5. 因果评估

   • 已确认因果联系 / 合理可能性 / 调查中
   • 已知失败模式或疑似根本原因
   • 事件是否涉及可预见的滥用、输入数据问题、模型漂移、人工监督失败或集成失败

6. 遏制和纠正措施

   • 系统暂停或回滚
   • 向部署者发出警告
   • 补丁 / 热修复 / 模型停用
   • 人工审查措施
   • 客户沟通

7. 证据保存

   • 日志已保留
   • 截图 / 提示词 / 输出已保存
   • 配置和模型版本已冻结
   • 已识别相关第三方组件

8. 并行通知

   • GDPR / NIS2 / MDR / 产品安全 / 保险人 / 合同通知已发送或待定

9. 计划的后续行动

   • 调查负责人
   • 下一个报告里程碑
   • 补充报告的预期时间

实用报告模板请使用 references/templates.md。

---

步骤 6 — 处理第 26(5) 条下的部署者义务

如果用户是部署者，或提供者通过部署者得知了问题，明确适用第 26(5) 条。

依据第 26(5) 条，高风险 AI 系统的部署者必须：

• 依据使用说明监控运行
• 当他们认为使用可能产生风险时，毫不迟延地通知提供者/分销商和相关市场监督当局，并暂停使用
• 当他们识别到严重事件时，立即先通知提供者，然后通知进口商或分销商和相关市场监督当局
• 如无法联系到提供者，第 73 条比照适用（mutatis mutandis）

实务含义

如果用户是部署者：

• 在保存证据和准备当局通知之前，不要等待提供者"接管"
• 在风险实时存在时暂停使用
• 记录联系提供者的尝试
• 保存日志至少适用留存期，注意第 26(6) 条要求日志在部署者控制下时至少保存六个月

如果用户是提供者：

• 询问部署者何时及如何首先注意到该事件
• 询问部署者是否已通知当局
• 快速对齐口径，避免相互矛盾的报告

请使用 references/corrective-measures.md。

---

步骤 7 — 映射重叠的法律制度

第 73 条很少单独存在。运行一次并行义务检查。

7A. GDPR

询问：

• 事件是否涉及个人数据？
• 是否存在未经授权的访问、丢失、损坏、暴露或不公平/自动化决定影响？
• 事件是否触发向监督当局的 GDPR 第 33 条违约通知？
• 是否需要向数据主体发出 GDPR 第 34 条通知？
• 事件是否暴露了有缺陷或过时的 DPIA？

7B. NIS2 / 网络安全

询问：

• 实体是否为重要（essential）或重要（important）实体？
• 事件是否损害了网络/信息系统的可用性、真实性、完整性或保密性？
• 适用的国家 NIS2 实施是否触发了早期预警 / 事件通知义务？

7C. 医疗器械 / IVD / 机械 / 产品安全

对嵌入受监管产品中的 AI 系统：

• 检查事件是否也必须按 MDR/IVDR 警戒规则报告
• 检查机械或通用产品安全事件渠道是否适用
• 注意第 73(9) 和 (10) 条：在存在等效联盟报告制度的情况下，AI 法案事件通知可能限于某些类型的事件，尤其是影响第 3(49)(c) 条基本权利的事件，且医疗器械路径事件前往指定的国家主管当局

7D. 雇佣与德国劳资委员会问题

如果事件发生在雇佣或工作场所监控背景下：

• 评估是否需要告知工人代表 / 劳资委员会
• 在德国，记住 BetrVG 的共同决定和信息义务可能活跃，尤其是系统监控行为或绩效或影响人事决定时

请使用 references/cross-regulation-mapping.md 和 references/dach-specific.md。

---

步骤 8 — 推动纠正措施和调查纪律

报告不是终点。运营响应同样重要。

第 73(6) 条下的提供者检查清单

• 毫不迟延地开始调查
• 对事件和系统进行风险评估
• 识别纠正行动
• 在相关处与当局和被通知机构合作
• 保存证据，并在当局协调之前避免对系统进行不受控制的变更

良好实践行动

• 冻结模型/版本标识符
• 快照配置、提示词、训练/微调引用和部署环境
• 记录人工监督是否因设计、工作量、UI、指示或用户变通而失败
• 评估事件是否暗示跨客户的更广泛现场纠正行动
• 审查上市后监控系统和投诉处理流程是否按设计工作

向用户的产出

• 立即遏制行动
• 利益相关者沟通图
• 现场纠正 / 补丁 / 回滚计划
• 法律报告矩阵
• 董事会或管理层简报

请使用 references/corrective-measures.md 和 references/templates.md。

---

决策逻辑摘要

快速分诊树

Q1. 系统实际是高风险的吗？

• 否 → 第 73 条排除，检查其他制度
• 是 / 可能是 → Q2

Q2. 事件是否符合严重事件损害类别？

• 否 → 记录并监控
• 是 / 可能 → Q3

Q3. 是否存在因果联系或合理可能性？

• 否 → 记录并在事实发展时重新评估
• 是 / 貌似可能 → Q4

Q4. 适用哪个期限档？

• 死亡 → 立即 / 最多 10 天
• 广泛 / 第 3(49)(b) 条类型 → 立即 / 最多 2 天
• 其他 → 立即 / 最多 15 天

Q5. 谁报告？

• 默认按第 73 条由提供者报告
• 部署者依据第 26(5) 条也有义务

Q6. 向何处？

• 事件发生地成员国的市场监督当局
• 德国：从 BNetzA 路由开始，叠加行业覆盖

---

实务起草指导

准备答案时，避免含糊的法律术语。按如下结构组织回复：

1. 底线 — 现在报告 / 可能报告 / 仅监控
2. 为什么 — 高风险依据 + 严重事件依据 + 因果状态
3. 期限 — 2 / 10 / 15 天以及时钟何时开始
4. 通知谁 — 当局地图 + 提供者/部署者分工
5. 现在发送什么 — 最低报告内容
6. 今天做什么 — 暂停、保存日志、通知部署者、分配负责人
7. 还可能触发什么 — GDPR、NIS2、MDR 等

---

DACH 特定说明

德国

• 将 BNetzA 视为德国 AI 法案市场监督路由/报告问题的主要实务入口点。
• 检查是否需要同时通知行业当局。
• 如果员工受影响，考虑 BetrVG、内部调查协议以及与工人代表的沟通。
• 如果涉及个人数据，并行识别 GDPR 下的德国主管监督当局。

奥地利

• 核验特定 AI 法案和行业背景下的国家主管当局。
• 在事实时间紧迫时，先准备报告包，并行敲定接收方确认。

瑞士

• 瑞士不是欧盟成员国，因此第 73 条本身在瑞士不是欧盟成员国报告路径。
• 但瑞士事件可能仍在合同、产品安全、数据保护方面具有意义，并且如果同一 AI 系统在欧盟内造成或促成了事件或影响了欧盟部署，也可能对欧盟报告有意义。

请使用 references/dach-specific.md。

---

Omnibus / 时机说明

Digital Omnibus 简化包（委员会 2025 年 12 月提案）于 2026 年 5 月 7 日推进至理事会/议会临时政治协议。若正式通过，该协议将把附件 III 高风险义务的适用日期移至 2027 年 12 月 2 日，附件 I 高风险义务移至 2028 年 8 月 2 日。它尚不是已通过的法律 — 待正式通过和官方公报发布。目前，不要仅基于临时协议改写法律实质内容。

实务规则：

• 在时机重要处将临时协议作为背景注明
• 除非且直到修订被通过并生效，适用现行已颁布的法律

---

输出格式

使用本技能时，将回复定制为以下交付物。

交付物 1 — 定性快照

• 系统分类：高风险 / 非高风险 / 不确定
• 第 6 条依据
• 如相关，第 6(3) 条例外评估
• 严重事件：是 / 否 / 不确定
• 因果联系：已确定 / 合理可能 / 未确定

交付物 2 — 报告建议

• 需要报告：是 / 可能是 / 尚未
• 期限档：2 / 10 / 15 天
• 知悉日期
• 时钟起始理由
• 需要初始不完整报告：是 / 否

交付物 3 — 接收方地图

• 成员国
• 主要市场监督当局
• 行业特定当局重叠
• 提供者与部署者通知分工

交付物 4 — 行动计划

• 未来 4 小时
• 未来 24 小时
• 未来 7 天

交付物 5 — 草稿

如被要求，提供：

• 第 73 条通知草稿
• 部署者致提供者的通知
• 管理层简报
• 跨法规通知矩阵

---

参考文件

这些用于更深入的分析和实务起草：

• references/incident-qualification.md
• references/reporting-requirements.md
• references/corrective-measures.md
• references/cross-regulation-mapping.md
• references/dach-specific.md
• references/templates.md

---

免责声明

本技能为欧盟 AI 法案严重事件处理提供结构化的法律运营工作流。它不是个案特定法律意见、行业特定监管意见或取证事实调查的替代品。

重要限制：

• 第 73 条仅适用于实际在范围内的高风险 AI 系统。
• 严重事件分析对事实敏感，可能随证据发展而迅速变化。
• 行业特定的产品、网络、劳动和数据保护规则可能施加并行或更严格的义务。
• 涉及死亡、关键基础设施、医疗器械安全或多州损害时，立即升级给专业律师。