# Serious Incident Reporting

> 依据欧盟 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（严重事件）时使用。

- Skill: `cslawyer1985/serious-incident-reporting` (Agent Skill, multi-file: 9 files)
- Install (CLI): `npx skillmds@latest add cslawyer1985/serious-incident-reporting`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cslawyer1985/serious-incident-reporting/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: cslawyer1985 (https://skillmd.com/u/cslawyer1985)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cslawyer1985/serious-incident-reporting

---


# 欧盟 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 系统**。
- 严重事件分析**对事实敏感**，可能随证据发展而迅速变化。
- 行业特定的产品、网络、劳动和数据保护规则可能施加**并行或更严格**的义务。
- 涉及死亡、关键基础设施、医疗器械安全或多州损害时，立即升级给专业律师。