AI Operational Resilience：降级与连续性架构
AI resilience is proven in degraded mode, not in the happy path.
AI Operational Resilience / BCP / Degraded Mode Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_OPERATIONAL_RESILIENCE_BCP_DEGRADED_MODE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| FFIEC Business Continuity Management booklet | https://ithandbook.ffiec.gov/it-booklets/business-continuity-management.aspx | 用 business impact analysis、critical operations、dependency、testing 和 resilience 语言组织 AI BCP |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 定义 AI 风险、控制、监控和降级治理 |
| ISO/IEC 42001 | https://www.iso.org/standard/42001 | 用 AI management system 连接政策、运行控制、绩效评价和持续改进 |
| Federal Reserve SR 26-2 | https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm | 2026 模型风险管理新锚点; 替代 SR 11-7 / SR 21-8, 但当前范围排除 generative AI 与 agentic AI 模型 |
| Federal Reserve SR 20-24 / Interagency Sound Practices for Operational Resilience | https://www.federalreserve.gov/supervisionreg/srletters/SR2024.htm | 用 operational resilience、critical operations、core business lines、third-party dependency 和 impact tolerance 语言设计 AI 连续性 |
核心导读： AI resilience is proven in degraded mode, not in the happy path.
核心导读
AI operational resilience 的重点不是“模型服务是否可用”，而是关键业务在 AI 依赖退化时是否仍能以受控方式提供 minimum viable service。金融零售场景的 AI 依赖包括模型 endpoint、RAG 语料、身份权限、policy engine、工具网关、人审队列、供应商、日志证据和客户沟通链路。任一环节失败，都可能导致错误承诺、延迟处理、监管时限错过或客户损害。
真正的 BCP/DR 设计要预先定义 degraded mode：什么时候降级、降级后哪些能力继续、哪些能力停止、谁有权触发和恢复、客户如何被告知、证据如何保留、积压如何处理、恢复自动化前如何验证。
问题定义
传统 IT 连续性常围绕 data center、应用可用率、数据库恢复和网络故障展开。AI 产品的韧性问题更复杂，因为业务结果依赖多类动态组件：
- 模型供应商可用，但响应质量异常下降或拒绝率上升。
- RAG 索引可访问，但关键政策文档过期或召回失败。
- 工具服务可用，但 policy engine 失效，导致高影响动作无法判断是否可执行。
- 人审队列存在，但 incident 时 volume 暴涨，SLA 无法支持监管时限。
- 日志管道中断，系统可以继续回答客户，却无法保全审计证据。
- 跨境或区域故障后，备用模型可用，但数据 residency 或 consent policy 不允许直接切换。
因此，AI BCP 的问题不是“备用模型在哪里”，而是“关键客户旅程在每种依赖退化下可以安全地退到什么状态”。
核心原理/方法
设计 AI resilience 要从 critical operation mapping 开始：
| 分析层 | 关键问题 |
|---|---|
| Critical operation | 该 AI workflow 支撑哪条核心业务线、客户旅程或监管义务 |
| Business impact | 失败会造成什么客户、资金、合规、声誉和运营影响 |
| Dependency map | 模型、数据、工具、身份、队列、供应商、证据和人工能力依赖什么 |
| Impact tolerance | 业务可接受的最大中断时间、错误率、积压量、客户等待时间和证据缺失 |
| Minimum viable service | 降级后必须保留的最小服务能力和必须停止的能力 |
| Trigger & authority | 触发降级、扩大降级、恢复自动化的指标、角色和审批 |
| Exercise & proof | 通过 tabletop、simulation、chaos drill 和 recovery test 证明方案可执行 |
Degraded mode 不是单一状态，而是 taxonomy：
| 模式 | 适用场景 | 行为 |
|---|---|---|
| Read-only mode | 写入工具或审批链异常 | AI 只能检索、总结、准备草稿，不得执行动作 |
| Template mode | 生成质量或政策引用不可信 | 使用预批准模板和固定 disclosure，不允许自由生成承诺 |
| Human-gated mode | 高风险输出或工具动作无法自动判定 | 全部或分层进入人工复核，并启动容量控制 |
| Queue-and-delay mode | 业务允许延迟但不允许错误 | 暂停自动处理，按优先级积压并告知客户时限 |
| Safe-stop mode | 继续服务会造成不可接受损害 | 停止特定 intent、渠道、工具或产品推荐 |
| Regional containment | 区域、供应商或数据路径异常 | 限制到本地模型、本地数据和本地 review queue |
系统/架构模型
Critical Operation Registry
-> AI Dependency Map
-> Health / Quality / Evidence Monitors
-> Degradation Decision Engine
-> Runbook Orchestrator
-> Workflow Feature Flags / Policy Gates
-> Manual Queue & Workforce Scheduler
-> Customer Communication Service
-> Evidence Preservation Layer
-> Recovery Gate & Post-Incident Review
核心设计：
| 组件 | 职责 |
|---|---|
| Critical operation registry | 把 AI use case 映射到业务线、客户旅程、监管时限、RTO/RPO/SLO 和 owner |
| Dependency map | 记录模型、RAG、向量库、工具、供应商、身份、队列、日志、key、region 和人工技能 |
| Health monitor | 同时监控技术可用性、质量退化、政策命中、证据完整性和人审积压 |
| Degradation decision engine | 根据 trigger、risk tier、impact tolerance 和审批矩阵选择降级模式 |
| Runbook orchestrator | 执行 feature flag、tool disable、routing、template switch、customer notice 和 queue rules |
| Evidence preservation layer | 即使在降级中也记录输入、输出、决策、审批、客户告知和恢复动作 |
| Recovery gate | 自动化恢复前执行 regression eval、sample review、证据完整性检查和业务签核 |
关键原则是 fail controlled，而不是简单 fail open 或 fail closed。低风险内部摘要可以延迟，高影响客户承诺必须安全停止或人工复核。
关键机制与取舍
| 决策 | 取舍 |
|---|---|
| 备用模型 vs 备用流程 | 备用模型能恢复生成能力，但不一定满足合规、数据和质量要求；备用流程更慢但更可控 |
| 自动降级 vs 人工触发 | 自动降级缩短损害窗口；人工触发能考虑业务上下文。高风险场景应采用自动触发 + 人工确认扩展 |
| 保持服务 vs 暂停服务 | 服务连续性不能凌驾于客户保护。错误建议、错误拒绝和错误资金动作比延迟更危险 |
| 人工兜底 vs 队列容量 | 人审不是无限资源；必须定义 surge capacity、优先级、OLA、临时授权和疲劳控制 |
| 区域切换 vs 数据限制 | 跨区容灾可能触发 residency、consent、subprocessor 和 key residency 问题，不能只按技术可用性切换 |
| 证据保全 vs 最小化 | incident 中需要足够证据支持复盘和客户补救，但不能无限扩大敏感数据收集 |
AI resilience 指标也要重新定义。除了 uptime，还应包括：degraded-mode activation time、unsafe output suppression rate、manual backlog age、critical deadline breach、evidence completeness、customer notice timeliness、recovery regression pass rate、repeat incident rate。
证据与控制
AI BCP 需要的证据不是一份静态 runbook，而是一组可证明“演练过、触发过、执行过、恢复过”的记录：
| 证据 | 说明 |
|---|---|
| Business impact analysis | critical operation、客户影响、法规时限、最大可容忍中断和依赖清单 |
| Degraded mode matrix | 每个依赖失败下的允许行为、禁止行为、trigger、owner 和恢复条件 |
| Runbook execution log | 降级触发时间、执行动作、feature flag、工具关闭、队列规则、客户通知 |
| Manual fallback record | 参与人员、技能要求、队列优先级、SLA、review decision 和 override |
| Evidence continuity test | 证明降级期间仍捕获关键事件和审计字段 |
| Recovery gate record | 回归测试、样本复核、积压处理、业务签核和恢复时间 |
| Exercise report | tabletop / simulation 的场景、发现、行动项、owner、关闭证据 |
控制上要避免“技术恢复即业务恢复”。恢复自动化前必须确认：模型质量回到阈值内，RAG 数据当前有效，policy engine 和 tool gateway 正常，积压不会造成重复处理，客户告知和补救完成，证据链没有中断。
金融零售/AI产品场景
信用卡争议处理：如果生成式争议助手的政策召回异常，应切换到 template mode 或 human-gated mode。争议提交时限、客户告知、证据上传和 case closure 不能由不可信生成结果驱动。
欺诈拦截与交易监控：模型或特征服务异常时，不应简单关闭拦截。可按风险层级切换到规则基线、人工复核和限额策略，同时监控 false positive 对客户支付体验的影响。
门店/分行销售助手：如果产品知识库或 suitability gate 异常，系统可继续提供教育性资料，但必须停止个性化推荐、报价和 next best action。
呼叫中心客服：模型供应商故障时，客服应进入 approved script + knowledge search 模式；AI 不再生成自由文本承诺，但仍保留 case summary 和客户沟通证据。
反模式
- BCP 只覆盖应用和数据库，不覆盖模型、RAG、工具、队列、日志、供应商和区域策略。
- 备用模型上线前没有 residency、privacy、quality、policy 和 evidence 验证。
- 将 human review 写成兜底方案，却没有容量模型、排班、技能和 surge trigger。
- 降级期间关闭日志以降低延迟，导致事后无法证明客户收到什么答复。
- 只定义系统恢复时间，不定义客户影响、积压清理和监管时限。
- incident 后直接恢复自动化，没有 regression eval、抽样复核和业务签核。
- 降级客户话术含糊，未区分中断、延迟、人工处理、纠错和补救。
最终心智模型
AI 韧性不是“永不中断”，而是“在不可避免的退化中保持业务边界、客户保护和证据连续”。判断一套架构是否合格，要看它能否在模型、数据、工具、供应商、人审或证据链失效时，自动进入预先批准的最小服务状态，并在恢复前证明风险已回到可接受范围。
金融零售 AI 的 BCP 成熟度，最终体现在 degraded mode：正常路径再漂亮，都不能证明系统有韧性；只有降级路径能证明组织真正理解自己的关键操作、风险边界和控制责任。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。