AI 事件响应手册：当你的模型出错时该怎么办

AI 事件不同于软件事件。当软件系统有 bug 时，你找到代码行、修复它并部署补丁。故障模式是确定性的：相同输入总是产出相同的错误输出。

AI 故障模式是统计性的。模型不会在传统意义上"崩溃"——它以某种概率在某些输入分布上产出错误输出。故障可能在任何人注意到之前已经发生了数周。受影响的人群可能是可识别且庞大的，这触发了披露义务。根因可能发生在训练期间——故障出现前数月——使修复比代码回滚复杂得多。

这些差异要求一个独立的事件响应流程。本手册涵盖完整生命周期：检测、分诊、调查、修复、披露和事后审查。

事件严重级别分类

严重性	定义	示例
P0——危急	AI 系统导致或促成人身伤害；经济损失超过$100K；监管违规；或超过1,000人受错误决策影响	被执行的错误医疗建议；大规模歧视性贷款决策
P1——高	AI 系统为定义群体产出系统性错误输出；发现合规缺口；如公开则有声誉风险	欺诈检测模型以显著更高比率阻止某人口群体
P2——中	AI 系统为输入子集产出不正确输出；无即时个人伤害；可无需通知即可纠正	文档摘要模型在特定格式上失败
P3——低	质量退化被注意到；无个人伤害；无合规影响	模型准确率指标下降但未超过警报阈值

阶段 1：检测和分诊

目标：P0 和 P1 事件 0-2 小时

分诊清单

在前 2 小时内完成（P0/P1）：

步骤 1：确定严重性

故障性质是什么？
个人是否受到影响？如果是，有多少人、严重程度如何？
是否有监管报告义务？
分配初始严重性：P0 / P1 / P2 / P3

步骤 2：识别受影响系统

步骤 3：估计范围

步骤 4：保留证据——在任何修复之前

导出覆盖事件期间的审计日志
保存展示故障的示例输入和输出
记录当前模型版本和配置
在证据保留之前不要更新、回滚或修改模型

步骤 5：即时通知

即时遏制

证据保留后，决定遏制方式：

选项 A：流量重路由 — 将流量从受影响模型版本引导走。

选项 B：暂停用例 — 暂停 AI 辅助处理，将所有案例路由到人工审查。

阶段 2：调查

目标：P0/P1 2-24 小时；P2 最多5天

根因分析框架

AI 事件通常追溯到四种根因之一：

根因类型 1：模型行为变化 — 模型版本最近是否更改？供应商是否未通知就更新了模型？

根因类型 2：数据分布偏移 — 失败的输入与模型训练数据在质量上是否不同？

根因类型 3：提示或集成 bug — 提示模板是否更改？预处理逻辑是否产生了格式错误的输入？

根因类型 4：人工监督失败 — 人工审查员是否在批准本应拒绝的输出？覆盖率是否异常低？

阶段 3：修复

即时修复（第1-2天）

回滚到最后已知良好的模型版本，或在无安全版本时暂停用例。

短期修复（第3-30天）

识别事件期间处理的所有可能受影响的案例，用修正后的模型重新处理。

长期修复（第30天以上）

根因	长期修复
模型行为变化（供应商）	协商版本锁定；评估供应商记分卡；考虑替代供应商或自有模型
数据分布偏移	实施输入分布监控；更新训练数据
提示/集成 bug	添加覆盖失败案例类型的集成测试
人工监督失败	重新校准审查员；调整审查界面

阶段 4：披露

监管披露

EU AI Act：第73条要求高风险 AI 系统提供商向成员国市场监督机构报告严重事件。

GDPR 第33条：个人数据违规必须在72小时内报告。

HIPAA 违规通知规则：如果涉及 PHI，评估违规通知义务。

SR 11-7：模型风险事件应通过现有报告渠道文档化和报告。

阶段 5：事后审查

在事件结束后10个工作日内进行。

时间线重建
确认的根因
经验教训
政策和流程更新
模型治理文档更新

将审计日志连接到调查

AI 事件的根因分析完全依赖于审计日志的质量和完整性。Ertas Data Suite 为每个处理步骤生成不可变的、带时间戳的审计记录——谁运行的、输入是什么、输出是什么以及哪个操作员审查了它。

预约 Ertas 发现通话 →