收益：
- 能够对 AI 特定事件类型进行分类并设计响应周期
- 能够在活动前定义角色、权限和法律报告义务
- 能够通过业务连续性和无责备事后分析建立永久改进
无论你保护得多么好，总有一天会出现问题：密钥会泄漏，注入会起作用，提供商会崩溃，或者输出会损害客户。一个成熟的机构之所以成熟，不是不发生事件，而是在事件发生时做好准备并迅速行动。在本单元中，我们将学习人工智能特定的事件响应计划、角色、步骤和业务连续性。
为什么人工智能中的事件响应有所不同？
在典型的安全事件中，“关闭系统，隔离”通常就足够了。人工智能事件还有其他维度：事件可能不在代码中，而是在模型的行为中（例如系统性不正确/有偏差的输出）；证据在提示/响应日志中；而“撤消”有时是不可能的，因为错误的输出已经成为一个决定。因此，AI事件计划应该涵盖经典安全和模型行为。
注意：事件发生时，计划不是书面的，而是实施的。谁给谁打电话、谁有权“停止系统”以及如何进行沟通，都必须在事件发生之前决定。
AI 事件类型
- 数据泄露：PII 或机密数据泄露（通过提示、日志或输出）。
- 安全漏洞：密钥泄露、成功注入、未经授权的访问。
- 有害/有偏见的输出：模型系统地产生了不正确的、歧视性的或危险的响应。
- 服务中断：提供商崩溃或达到速度限制；系统无法响应。
- 滥用：该系统被用于其设计目的之外的有害目的。
循序渐进：事件响应周期
- 检测。监控警报、用户投诉或审计结果揭示了该事件。
- 排序并确定优先级。根据影响和传播程度给出级别（例如 P1 严重 - P3 低）。
- 包含。阻止传播：撤销密钥、关闭功能、将系统拉至只读。
- 消灭并恢复。修复根本原因，恢复安全状态。
- 报告一下。及时告知法律/合同通知义务（例如 KVKK 72 小时）和受影响的人员。
- 事后检查（尸检）。不要指责，记录根本原因和永久解决方案。
角色和责任
应明确谁在事件中做什么：事件指挥官（唯一做出决定的人）、技术响应（停止/修复系统）、沟通（客户/管理层/监管机构）、法律/合规（报告义务）。在小团队中，一个人可以担任多个角色，但角色必须书面化。
四个可复制模板
事件分类提示：
对以下事件进行分类：{{ event_description }}识别：- 类型：数据泄漏/安全漏洞/恶意输出/中断/滥用- 影响：有多少人/记录、什么数据类别、金钱/合规后果？- 传播：停止还是正在进行？- 优先级：P1 / P2 / P3 + 理由- 第一个控制步骤：应该立即做什么？
第一响应（遏制）清单：
事件确认后的前30分钟内：- [ ] 禁用受影响的功能/工具或将其设置为只读- [ ] 取消可疑密钥/会话- [ ] 保留证据（冻结相关日志，记录trace_id）- [ ] 通知事件指挥官和所需角色- [ ] 部署临时安全模式/备份流程
通知草稿提示：
为以下事件编写一份内部通知草稿：{{ event_summary }}必须包括：发生了什么（用非技术语言）、何时注意到、哪些数据/谁受到了影响、到目前为止已完成的操作、后续步骤、可以从谁那里获得其他信息。请勿包含猜测或指控。
尸检骨架：
事件后审查（无责备）：- 时间线：检测 -> 控制 -> 恢复（分钟） - 根本原因：技术 + 流程规模 - 哪些进展顺利/哪些进展不佳 - 永久修复（谁、何时）- 监控/控制以尽早捕获此事件
弱提示/强提示
糟糕的方法
强硬的做法
在没有计划的情况下即兴参加活动
预先写好的计划、角色和权限
先说“谁有罪”
首先是遏制，然后是无责备的事后剖析
延迟/跳过通知
法定期限内（如72小时）通知
等待同样的事件再次发生
从事后分析中提取永久控制权
三个迷你箱
案例 1——在 72 小时规则内被捕。一家公司的一名员工注意到，由于配置错误，日志中 1,200 条客户记录被暴露。由于有书面计划，事件指挥官很清楚；团队在40分钟内关闭了访问，法律在72小时内做出了KVKK通知。及时报告大大降低了犯罪风险和声誉损害。
案例 2 — 只读安全模式处理了中断。主模提供者外出3小时。该公司的业务连续性计划包括切换到备份提供商和“安全模式”（仅限关键功能）。尽管用户失去了全部功能，但系统仍然存在；关键行动并未停止。
案例 3 — 尸检防止复发。成功的间接注入将另一个用户的数据泄露给了助手。非责备事后分析表明，根本原因是缺乏<数据>隔离。添加了永久修复（隔离+输出扫描+回归测试）；同级别的攻击再次没有成功。
提示：在不指责的情况下进行事后剖析。目的不是找人，而是加强系统，不允许同样的事件再次发生。指责文化会导致人们隐瞒事情，这是最危险的。
常见错误
- 活动前没有准备书面计划和角色分配。
- 在控制之前陷入争论/指责。
- 缺少法律通知义务（KVKK/GDPR 截止日期）。
- 重置系统而不保留证据（日志）。
- 不考虑备份提供商/安全模式来实现业务连续性。
- 不进行事后分析，为同一事件的重复留下空间。
综上所述
- 成熟不是没有事件，而是没有事件。这意味着在事情发生时要做好准备并迅速行动。
- AI事件可以在模型行为中而不是在代码中；证据在提示/响应日志中，并且逆转并不总是可能的。
- 响应周期：检测、分类、遏制、恢复、报告、事后分析。
- 角色和权限（事件指挥官、技术、通信、法律）应在事件发生前以书面形式确定。
- 用于业务连续性的备份提供商/安全模式；无责备的事后剖析和永久纠正对于事件的后果至关重要。
应用任务
为您自己的 AI 系统编写一份事件响应计划草案：列出三种最有可能的事件类型，确定初始 30 分钟的遏制清单以及每种事件的角色。然后做一个桌面练习：逐步演练“密钥泄露”场景，指出并纠正计划中任何缺失/模糊的点。
清单
- [ ] 有书面的事件响应计划和角色分配。
- [ ] 谁有权“停止系统”，一目了然。
- [ ] 前 30 分钟收容检查表已准备就绪。
- [ ] 规定了法定通知期限和责任人。
- [ ] 为业务连续性规划的备份提供商/安全模式。
- [ ] 对每个事件进行无责事后剖析和永久纠正。