运行监控、事故与退役
本节目标
把上线前的风险假设变成运行阈值、行动和责任人；识别尚未造成损害的危险信号与已经发生的事故；在系统不再值得或无法安全运行时完整退役。
从风险登记到监控
每项重要风险都要有信号、分母、分群、阈值、观察窗口、数据质量检查、负责人和超限动作。例如“错误建议伤害小语种用户”不能只监控总体满意度，应按语言查看有人工判定的严重错误率，并规定何时限流、切换人工或停用。
监控可分四层：
- 系统与供应链：可用性、延迟、成本、依赖/模型版本漂移、权限和配置变化。
- 质量与行为：任务成功、幻觉/引用错误、拒绝、重复工具调用、人工覆盖、越权和失效模式。
- 人和社会影响：投诉、申诉、不同群体差异、过度依赖、可达性、工作人员负担和实际损害。
- 控制健康：审批绕过、日志缺失、评测陈旧、事件演练、删除失败和供应商通知。
关键绩效指标（KPI）说明是否实现目标；关键风险指标（KRI）说明风险是否上升。高采用率可能是 KPI，却也可能伴随过度依赖；两者要一起解释。
事故、危险与问题
OECD 2024 术语工作把已经造成实际损害的事件称为 AI incident，把具有潜在损害的事件称为 AI hazard。组织可据此区分但必须定义自己的升级范围：一次未遂越权、严重分群漂移或供应商安全通知即使尚无确认损害，也应进入危险/问题流程。
这套广义 AI 事故/危险记录不能替代网络安全、隐私、产品安全或行业事件流程。若涉及攻击或漏洞，还要补充攻击向量、身份/权限、受影响组件、利用状态和遏制证据；同一事实可以关联多个工单，但应共享稳定事件 ID，避免不同团队各自形成冲突时间线。
最小记录包括：事件 ID、发现时间/渠道、系统与版本、实际或潜在影响、受影响者/地区、证据来源、已知不确定性、严重级别、负责人、限制影响动作、通知判断、恢复条件和复盘行动。不要在普通工单中复制不必要的个人数据或秘密。
响应闭环
检测与分级→限制影响（停工具、限流、回退、转人工、吊销身份）→保存受控证据→确认范围与根因→由授权团队判断内外通知→修复与独立验证→分阶段恢复→复盘。把真实路径加入回归集，并检查同一供应商/组件影响的其他系统。
任何固定的监管通知对象和时限都可能因地区、角色、行业、数据和损害类型不同。本库不提供通用时限；事件手册应预先列出法律/隐私/安全升级联系人，由有资质人员按当时有效规则判断。
安全退役
退役不是把界面关闭。计划应包括：
- 停止入口、任务、API、工具和自动触发，撤销身份、密钥与网络权限。
- 通知用户、受影响业务、供应商和下游系统，提供人工或替代流程。
- 按授权与保留规则处理数据、索引、缓存、日志、评测集、备份和供应商副本。
- 保存最少必要的审批、版本、事件和决策证据；记录何时、由谁、依据什么退役。
- 终止合同、释放资源并验证不再产生费用或调用；确认下游没有继续依赖旧输出。
- 处理历史决定的申诉、纠错与持续影响；在约定时间复查残留副本和访问。
练习与自测
为“客服草稿 Agent”选三项 KPI 和五项 KRI。每项写分母、分群、阈值、负责人和动作；再模拟供应商静默换模导致投诉上升，完成危险/事故记录和退役清单。
- 监控信号能追溯到影响评估中的具体风险。
- 阈值超限会触发明确动作，而非只生成仪表板。
- 能区分实际损害、潜在危险和一般缺陷，并保留升级空间。
- 退役覆盖身份、数据、供应商、下游、用户和历史救济。
下一步与资料基线
下一步进入 法规、标准与地区复核。资料获取日期：2026-07-21。参考 OECD 对 AI incident/hazard 的定义、OECD AI 事故通用报告框架 与 NIST AI RMF Core 的持续治理和退役要求。