cslawyer1985 欧盟 AI 法案下的严重事件报告（第 73 条）
本技能帮助评估涉及 AI 系统的事件是否触发欧盟 AI 法案第 73 条下的严重事件报告义务，然后将该法律分析转化为实际的响应计划、通知草稿和内部行动清单。
它专为需要可用流程而非抽象评论的提供者、部署者、法律/合规团队、产品负责人和事件响应团队而设计。
何时使用本技能
当用户希望以下事项时使用本技能：
- 评估 AI 相关事件是否构成欧盟 AI 法案下的严重事件
- 决定系统是否因实际为高风险而在范围内
- 确定报告何时必须发生以及属于哪个期限档
- 识别要通知的市场监督当局
- 准备一份实际的第 73 条报告
- 理解第 26(5) 条下的部署者通知义务
- 协调第 73 条与GDPR、NIS2、医疗器械、机械或产品安全报告
- 创建内部事件手册、升级矩阵或管理层简报
开始前的快速现实检查
此工作流仅在系统实际是欧盟 AI 法案下的高风险 AI 系统时适用。
这意味着：
- 它依据第 6(1) 条属于高风险，因为它是附件 I 产品的安全组件，或其本身就是须经第三方合格评定的此类产品；或
- 它属于附件 III，且未被第 6(3) 条例外排除。
如果系统仅因靠近受监管工作流而被假定为高风险，先停下来确认分类。如果第 6(3) 条貌似适用，第 73 条下的事件报告可能不会触发，因为该系统从一开始就不在范围内作为高风险。
本技能的产出
根据请求，产出以下部分或全部：
- 一份定性备忘录：范围内 / 范围外 / 不确定
- 一份期限评估：2 天 / 10 天 / 15 天 / 后续报告
- 一份按成员国的接收方地图
- 一份第 73 条事件报告草稿
- 一份跨法规通知矩阵
- 一份面向法律、产品、安全和管理的内部行动检查清单
- 一份用通俗商业语言撰写的简短管理层简报
首先快速提问
保持首次接案简短实用。只询问分类和分诊所需的内容。
最低接案问题
涉及哪个 AI 系统？
- 产品名称
- 版本/构建
- 提供者法律实体
- 预期用途
您为何认为它是高风险的？
- 附件 I 安全组件/产品？
- 附件 III 用例？
- 有任何先前的分类备忘录？
- 有任何第 6(3) 条非高风险评估？
发生了什么？
- 发现日期/时间
- 如不同，事件发生日期/时间
- 系统做了什么或未能做什么
- 目前理解的因果链
发生了或可能发生什么损害？
- 死亡
- 严重健康损害
- 严重财产损害
- 严重环境损害
- 关键基础设施管理的严重且不可逆的中断
事件发生在何处？
- 成员国
- 客户/部署者位置
- 跨境影响？
谁首先识别了它？
- 提供者
- 部署者
- 分销商/进口商
- 最终用户 / 受影响人
- 当局 / 媒体 / 举报人
已经做了什么？
- 系统已暂停？
- 用户/部署者已被告知？
- 回滚 / 紧急停止 / 访问限制？
- 内部调查已开始？
有任何重叠的制度吗？
- 个人数据泄露？
- NIS2/网络事件？
- 医疗器械或体外诊断？
- 机械 / 产品安全？
- 劳动 / 工作场所影响？
如果时间极短
只问以下四个：
- 系统确定是高风险的吗？
- 事件造成或貌似促成了死亡或严重损害吗？
- 发生在哪个成员国？
- 提供者或部署者何时首次知悉？
核心工作流
按此顺序执行。
步骤 1 — 确认范围：系统实际是高风险的吗？
不要直接跳到报告。
1A. 高风险门禁
检查系统是否依据第 6 条属于高风险：
- 第 6(1) 条：附件行业产品 / 安全组件路径
- 第 6(2) 条：附件 III 路径
- 第 6(3) 条：对某些不构成重大损害风险且不实质影响决策的附件 III 系统的可能例外，画像情形除外
1B. 决定
- 是，明确高风险 → 继续到步骤 2
- 否，明确非高风险 → 第 73 条不适用；仍评估其他制度
- 不清楚 → 说明分类不确定性本身即属重大，并在紧急核验分类的同时以防备性分诊继续
实务指示
如果用户无法提供先前的分类备忘录，请索取：
- 预期用途
- 用户群体
- 行业/背景
- 输出是否实质影响关于人员或安全的决定
- 系统是否为安全组件或受监管产品
如果存在真正的歧义和潜在的严重损害，在分类澄清期间建议采取保守的事件响应姿态。
更深入逻辑请使用 references/incident-qualification.md。
步骤 2 — 定性事件：它是"严重事件"吗？
依据第 3(49) 条，这是法律阈值步骤。
出于实务目的，如果事件直接或间接导致、可能已导致，或貌似促成了以下任一情形，将其视为严重事件：
- 人员死亡
- 对人员健康的严重损害
- 关键基础设施管理和运营的严重且不可逆的中断
- 违反旨在保护基本权利的欧盟法律义务，且该违反后果严重
- 出于运营分诊目的，在事实与法定严重损害阈值或相邻行业规则相符时，也将严重财产或环境损害视为需要立即法律审查并可能规划通知
决策树
事件是否涉及在运行、输出、失败、滥用或可预见滥用中的高风险 AI 系统？
- 如果否 → 不属于第 73 条
- 如果是 → 继续
是否存在与系统相关的实际损害，或有充分证据的近期损害情景？
- 如果否 → 除非事实变化，记录为非严重事件 / 上市后问题
- 如果是 → 继续
损害是否落入严重类别？
- 死亡
- 严重健康损害
- 重大基本权利影响
- 关键基础设施中断
- 可能需要并行报告的同等严重行业损害
是否存在因果联系，或至少有合理可能性？
- 如果是 → 可报告时间线开始计算
- 如果不确定但貌似可能 → 视为升级案件；保存证据并快速决定
- 如果明确否 → 记录原因并监控
实务规则
不要等待完美的取证证明。第 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 — 构建报告包
至少围绕当局会期待的字段组装报告包，即使首份报告不完整。
基本内容
提供者识别
- 法律实体
- 地址 / 联系方式
- 如相关，授权代表
- 关键事件联系人
AI 系统识别
- 名称/型号/版本
- 如相关，CE / 合格 / 注册标识符
- 高风险类别和法律依据
- 预期用途和部署环境
事件事实
- 事件日期/时间
- 知悉日期/时间
- 地点 / 成员国
- 受影响的部署者/客户
- 发生了什么的事实叙述
影响和受影响方
- 受影响人员的数量和类型
- 损害的性质和严重性
- 损害是否仍在持续
- 关键基础设施 / 公共服务影响
- 是否有工人或弱势人群受影响
因果评估
- 已确认因果联系 / 合理可能性 / 调查中
- 已知失败模式或疑似根本原因
- 事件是否涉及可预见的滥用、输入数据问题、模型漂移、人工监督失败或集成失败
遏制和纠正措施
- 系统暂停或回滚
- 向部署者发出警告
- 补丁 / 热修复 / 模型停用
- 人工审查措施
- 客户沟通
证据保存
- 日志已保留
- 截图 / 提示词 / 输出已保存
- 配置和模型版本已冻结
- 已识别相关第三方组件
并行通知
- GDPR / NIS2 / MDR / 产品安全 / 保险人 / 合同通知已发送或待定
计划的后续行动
- 调查负责人
- 下一个报告里程碑
- 补充报告的预期时间
实用报告模板请使用 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 路由开始，叠加行业覆盖
实务起草指导
准备答案时，避免含糊的法律术语。按如下结构组织回复：
- 底线 — 现在报告 / 可能报告 / 仅监控
- 为什么 — 高风险依据 + 严重事件依据 + 因果状态
- 期限 — 2 / 10 / 15 天以及时钟何时开始
- 通知谁 — 当局地图 + 提供者/部署者分工
- 现在发送什么 — 最低报告内容
- 今天做什么 — 暂停、保存日志、通知部署者、分配负责人
- 还可能触发什么 — 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.mdreferences/reporting-requirements.mdreferences/corrective-measures.mdreferences/cross-regulation-mapping.mdreferences/dach-specific.mdreferences/templates.md
免责声明
本技能为欧盟 AI 法案严重事件处理提供结构化的法律运营工作流。它不是个案特定法律意见、行业特定监管意见或取证事实调查的替代品。
重要限制：
- 第 73 条仅适用于实际在范围内的高风险 AI 系统。
- 严重事件分析对事实敏感，可能随证据发展而迅速变化。
- 行业特定的产品、网络、劳动和数据保护规则可能施加并行或更严格的义务。
- 涉及死亡、关键基础设施、医疗器械安全或多州损害时，立即升级给专业律师。