AI 事件响应（AI Incident Response）

模型输出有害内容、智能体误删数据、接口被刷爆或上下文里的隐私被外泄，都属于 AI 事件。响应流程解决的是「出事之后按什么顺序做动作」，避免临场各自为战，把可挽回的问题拖成不可挽回。与传统服务故障不同，AI 事件的起因常在语义层，日志里未必有明确报错，所以分级与证据固定要更早动手。本条只讲组织内部的响应动作；对监管的上报义务与对用户的告知要求属于另一条线，见 incident-reporting。

先分级，再决定投入

• 影响面：涉及单个用户、单个租户还是全量用户，是否牵涉个人信息、资金动作或外部系统。
• 可逆性：错误的文字建议可以撤回，已经执行的外部动作（转账、发帖、删除、下发指令）不可逆，优先级最高。
• 持续与扩散：是一次性触发还是被批量利用，是否会通过分享、缓存或下游系统继续扩散。
• 触发来源：来自用户输入、外部内容注入还是模型自身漂移，来源不同决定止血点不同。

止血动作

• 降级而非停机：先切到只读、模板回答或转人工的降级模式，保住基本可用性再查根因。
• 版本回滚：回滚模型、提示词或策略版本，优先恢复到已知正常的配置。
• 权限收紧：临时收回高风险工具权限、封禁滥用账号，切断损害继续产生的路径。
• 固定证据：保存请求、上下文、工具调用与输出日志，避免排查过程中现场被覆盖。
• 口径同步：第一时间对齐客服与值班话术，避免一线在事实未清时给出前后矛盾的解释。

内部复盘与改进

复盘要产出可验证的改进项：补哪条评测、加哪个拦截、改哪处权限、谁负责、什么时候完成，否则同类事件必然复发。复盘结论还应回写到上线前的检查清单里，让下一次发布自带这次的教训。内部同时要把事实时间线固定下来，供对外上报与告知引用——两套说法会放大信任损失，而口径一致的前提是内部先对齐事实。

靠演练而不是文档

响应能力来自演练：定期用真实场景做桌面推演，确认值班链路、回滚手段与止血决策都能在压力下跑通。事件结束后把时间线、决策依据与未解决项归档，既便于审计，也让同类判断有先例可循。需要提醒的是，止血动作本身也要留痕并可撤销，否则应急操作会变成新的风险来源。