跳到主要内容

05-事故响应供应链与合规治理

核对日期：2026-05-13。

不稳定项：监管要求、供应商服务条款、模型版本、开源模型许可、Agentic AI 安全事件和行业标准持续变化；发布前必须重新核对适用司法辖区、行业合规和采购条款。

1. 学习目标​

本专题把安全从“设计阶段”推进到“长期运营阶段”：上线后的 AI 系统会遇到模型漂移、供应商变更、数据政策变化、注入绕过、工具事故和真实用户投诉。

学完后你应该能做到：

  • 为 AI 功能设计 kill switch、降级、回滚、通知和复盘流程。
  • 把安全事故转化为回归评测样例。
  • 评估模型供应商、中转 API、开源模型、插件、MCP Server 和数据源的供应链风险。
  • 用 NIST AI RMF 的 Govern、Map、Measure、Manage 思路组织治理闭环。
  • 区分工程安全、组织治理和法律合规的边界。

2. 事故类型​

AI 安全事故通常不是单一漏洞，而是模型、数据、权限和流程共同失效。

类型示例第一动作
注入绕过模型服从恶意网页指令暂停相关入口或降级只读
数据泄漏输出其他用户信息停用功能、保全日志、通知安全团队
工具误用Agent 误发邮件、误退款阻断工具、撤销外部影响
RAG 污染错误政策被检索并引用下架文档、重建索引
输出安全HTML/代码/SQL 导致注入停用渲染或执行链路
供应商异常模型版本变化、服务中断切换 provider、冻结评测
成本攻击恶意长输入消耗预算限流、预算熔断
合规投诉用户要求删除或导出数据启动数据流程和法务评估

事故响应要先止损，再定位，再修复，最后回归。

3. 响应流程​

发现
-> 分级
-> 止血
-> 保全证据
-> 影响评估
-> 修复和回滚
-> 通知和合规处理
-> 复盘
-> 评测回归
-> 门禁更新

每一步都应有负责人：

阶段负责人产出
发现值班/客服/监控incident id
分级安全负责人 + 业务 ownerseverity
止血工程 ownerkill switch、降级、工具禁用
证据平台/安全trace、日志、模型和 Prompt 版本
修复工程 + 安全patch、配置、策略
通知业务 + 法务用户、监管或内部通报
复盘owner根因和行动项
回归评测 owner新增 eval cases

4. Kill Switch 与降级​

AI 功能上线前必须设计停用和降级路径。

控制用途
feature flag快速关闭功能
tool kill switch禁用某类工具，如发送、删除、退款
provider switch切换模型供应商
prompt rollback回退到上个 Prompt 版本
model rollback回退到已评测模型
read-only mode从自动执行降级为只读建议
budget breaker成本异常时熔断
rate limit阻断攻击流量

没有 kill switch 的高风险 AI 功能，不适合直接进入生产。

5. 复盘模板​

# AI 安全事故复盘

## 1. 摘要
- incident id:
- 严重等级:
- 发现时间:
- 恢复时间:
- 影响范围:

## 2. 时间线
## 3. 触发输入和上下文
## 4. 使用的模型、Prompt、工具和数据源
## 5. 直接原因
## 6. 根因分析
## 7. 止损动作
## 8. 修复方案
## 9. 用户、业务或合规影响
## 10. 新增回归样例
## 11. 门禁和流程更新
## 12. 未解决风险

复盘的质量标准：能让未来系统自动或半自动地防住同类问题。

6. 供应链风险​

AI 系统的供应链比传统应用更长。

组件风险
模型供应商数据保留、训练使用、区域、版本变化、SLA
中转 API请求内容被记录、模型来源不透明、密钥泄露、服务条款风险
开源模型许可证、权重来源、后门、评测不充分
Embedding 模型向量漂移、隐私索引、召回变化
Reranker排序偏差、供应中断
MCP Server / 插件工具描述投毒、权限过大、日志不透明
数据源文档污染、过期、版权和访问权限
评测工具judge 偏差、样例泄漏

采购或接入前至少回答：

  • 数据是否用于训练或改进服务？
  • 数据保留多久？能否关闭保留？
  • 是否支持企业协议、DPA、区域控制？
  • 是否提供审计日志和 request id？
  • 模型版本是否可固定？
  • 是否有 SLA、退出方案和价格变更风险？
  • 如果供应商不可用，系统如何降级？

7. 中转 API 特别风险​

中转 API 可能便宜，但安全和合规风险更高：

  • 业务数据和用户输入经过中转方。
  • 官方 key 或账号可能由中转方托管。
  • 实际模型和路由不透明。
  • 数据保留和日志策略不透明。
  • 可能违反上游服务条款。
  • 供应中断、封禁、账单争议难追责。

适用边界：

场景建议
公开数据、个人实验、低风险 demo可谨慎使用，避免敏感数据
内部工具、非敏感原型需明确数据策略和退出方案
用户数据、企业知识库、生产业务默认不使用，除非通过正式安全和法务评审
高敏、受监管、资金/医疗/人事不应作为默认方案

8. 治理闭环​

可以用 NIST AI RMF 的四类活动组织治理：

活动在 AI 工程中的落地
Govern定义角色、政策、风险接受标准、供应商准入
Map映射场景、数据、用户、影响、信任边界
Measure评测正确性、安全、偏差、鲁棒性、成本和可用性
Manage发布门禁、监控、事故响应、回滚和持续改进

治理不是一次性文档，而是随着模型、Prompt、数据和工具版本变化持续运行的机制。

9. 合规边界​

工程团队不应假装自己能独立完成法律判断，但必须提供合规评估需要的材料：

  • 数据分类和流向。
  • 数据处理目的。
  • 模型和供应商清单。
  • 是否跨境或跨区域。
  • 日志和保留期。
  • 删除、导出、纠错流程。
  • 自动化决策是否影响用户权益。
  • 人类复核和申诉机制。
  • 安全测试和事故记录。

法律和合规团队判断“是否允许”，工程团队负责“系统是否真的按允许的方式运行”。

10. 工程案例​

10.1 Prompt 更新导致泄漏​

问题：Prompt v0.8 新增“详细解释依据”，导致模型输出内部审批备注。

响应：

  • 回滚 Prompt 到 v0.7。
  • 禁用该功能的详细解释模式。
  • 导出受影响 trace。
  • 添加敏感备注泄漏 eval。
  • 更新发布门禁：Prompt 改动必须跑安全集。

10.2 RAG 索引污染​

问题：爬虫把恶意网页索引进知识库，用户问答时触发间接注入。

响应：

  • 下架污染文档。
  • 重建相关索引。
  • 增加入库扫描和来源 allowlist。
  • 复盘检索日志，确认影响范围。
  • 新增文档污染回归样例。

11. 常见反模式​

反模式表现后果修正
无停用开关出事只能改代码事故扩大feature flag 和 tool switch
复盘只写加强 Prompt没有系统改进问题复发控制、eval、门禁
供应商只看价格不看数据政策合规风险安全和法务评审
不固定模型版本上游变化不知情分数漂移版本记录和回归
合规材料后补上线后才问法务返工或停服需求阶段建档

12. 练习​

为“企业知识库问答系统”写一份事故响应方案：

  • 设计 4 个事故等级。
  • 为注入绕过、数据泄漏、供应商中断、RAG 污染分别写止损动作。
  • 设计 kill switch 和降级路径。
  • 写一个复盘模板。
  • 说明哪些事故样例必须进入回归评测。

13. 验收题​

  1. AI 安全事故为什么要先止血再定位？
  2. 一个高风险 AI 功能至少需要哪些 kill switch？
  3. 为什么复盘必须产出回归 eval？
  4. 中转 API 的主要供应链风险是什么？
  5. NIST AI RMF 的 Govern、Map、Measure、Manage 如何映射到 AI 工程流程？

14. 延伸阅读​