AI Operational Resilience / BCP / Degraded Mode Architecture Playbook

配对阅读：本手册的原理/架构解读版是 docs/ai-foundations/papers/108-ai-operational-resilience-bcp-degraded-mode-architecture.md。先读 paper 建立机制与取舍，再用本手册落地为模板、RACI 与门禁，两者不需要重复精读。

核心导读: AI operational resilience 研究的不是模型是否在线, 而是 AI 参与客户可见或受监管流程后, 关键运营在依赖故障、质量降级、证据缺失或人工队列过载时是否还能保持受控服务。 学习主线: 从 critical operation 和 impact tolerance 出发, 建立 dependency graph、degraded mode taxonomy、manual fallback、customer communication、evidence preservation、recovery gate 和 tabletop exercise。 系统边界: 本文是金融零售 AI 韧性架构学习材料, 不构成法律、监管、审计、业务连续性认证、模型验证或第三方风险意见。正式项目必须由 legal、compliance、model risk、operational risk、technology、business owner、third-party risk、privacy、security、internal audit 和高管治理论坛确认。 证据输出: critical operation map、AI dependency graph、impact tolerance memo、degraded mode matrix、manual fallback runbook、evidence preservation plan、recovery gate memo、tabletop exercise record 和 remediation register。

核心判断:

AI 的运营韧性不是“模型可用率”, 而是当模型、RAG、工具、身份、policy engine、eval、HITL、vendor 或 evidence stack 降级时, 关键运营是否还能在预设边界内安全运行。

这份 playbook 明确区别于 incident postmortem:

• Incident postmortem 是事后学习。
• Operational resilience / BCP 是事前设计。
• Degraded mode 是事故中保持关键服务连续性的受控状态。
• Recovery exercise 是证明这些设计真实可执行的机制。

---

1. Executive Framing

金融零售 AI 的关键风险不只来自错误回答, 也来自关键运营在压力状态下没有可执行的降级方案。

当客户服务 AI、信贷政策助手、AML case summarizer、欺诈复核 copilot、投诉回复 agent、财富顾问 copilot、分行员工助手和监管变更助手进入生产后, 它们会逐渐成为业务运营的一部分。它们可能不直接做最终决定, 但会影响:

• 客户得到的说明。
• 员工看到的证据。
• case 的优先级。
• 投诉的处理节奏。
• 信贷或欺诈复核的解释。
• AML / KYC 调查材料。
• 管理层和监管检查需要的 evidence。

正常状态下的 AI governance 会问:

这个 use case 是否批准上线。
模型是否验证。
prompt 是否测试。
RAG 是否有 citation。
工具是否有审批。
人审是否存在。

BCP / operational resilience 要继续问:

如果模型 provider 只剩 20% 容量, 关键流程怎么运行。
如果 RAG index 过期 12 小时, 哪些问题必须拒答或模板化。
如果 identity service 无法返回 entitlement, AI 是否还能个性化。
如果 policy engine false allow, 哪些工具动作必须停。
如果 HITL queue 积压 8 小时, 哪些 case 优先。
如果 evidence export API 故障, 哪些输出必须进入本地证据账本。
如果 vendor 同时降级运行路径和证据路径, 谁能接受残余风险。

运营韧性的高级目标不是让 AI 永不失败, 而是让失败保持在 impact tolerance 内:

• 客户不被误导。
• 受监管流程不失控。
• 关键服务不无序中断。
• 人工队列不被低风险任务打爆。
• 证据不丢失。
• 恢复有门禁。
• 管理层知道谁在做什么决定。

---

2. Source Anchors

以下来源用于建立监管语言、治理语言和架构控制语言。本文是学习和架构训练材料, 不构成法律意见、监管解释、审计结论或认证建议。正式项目必须由 legal、compliance、model risk、operational risk、technology、business owner、third-party risk、privacy、security 和 internal audit 结合机构政策与司法辖区复核。

2.1 2026 SR 26-2 Nuance

SR 26-2 的当前 nuance 对 AI 架构师很重要:

• 它在 2026-04-17 发布。
• 它替代了 SR 11-7 和 SR 21-8。
• 它采用更风险分层的 model risk management 语言。
• 它当前不覆盖 generative AI 和 agentic AI 模型。
• 它不应被误读为 GenAI / agentic AI 的完整监管要求。
• 对金融零售 AI BCP 来说, 它仍可提供治理、验证、持续监控、变更控制和风险接受的结构化思想。

实务表达:

我会明确区分“SR 26-2 是否直接适用”与“SR 26-2 的治理原则是否可借鉴”。客户可见或受监管 GenAI / agentic workflow 的 BCP 设计, 需要叠加 NIST AI RMF、ISO/IEC 42001、FFIEC BCM、operational resilience 和机构内部模型/AI/第三方/网络/业务连续性政策。

---

3. Critical Operation Mapping

AI BCP 不能从模型清单开始, 要从 critical operations 开始。

3.1 Critical Operation Definition

在金融零售环境中, critical operation 指某个业务能力或流程一旦中断、严重降级或证据缺失, 可能影响:

• 客户资金、账户、权益、费用、申诉或法律权利。
• 核心业务线的持续运营。
• AML / KYC / fraud / credit / complaint / privacy 等受监管义务。
• 机构安全稳健。
• 管理层、审计或监管检查所需的可证明性。

3.2 AI-Enabled Critical Operation Inventory

3.3 Impact Tolerance

Impact tolerance 不等于技术 SLO。它回答: 在严重但合理的压力场景下, 机构最多能承受多少中断、积压、错误和证据缺口。

4. AI Dependency Graph

AI BCP 要画 dependency graph, 不是只写系统清单。

4.1 Dependency Types

4.2 Graph View

Critical operation
  -> AI workflow
  -> customer / employee channel
  -> model route
  -> prompt / policy bundle
  -> RAG source and index
  -> tool gateway
  -> identity and entitlement
  -> policy engine
  -> HITL queue
  -> evidence ledger
  -> vendor and cloud dependencies
  -> recovery gate

4.3 Dependency Edge Attributes

5. Degraded Mode Taxonomy

Degraded mode 是预先批准的运行状态。它不是临时“关一点功能”, 而是有 trigger、allowed behavior、blocked behavior、owner、evidence 和 recovery condition。

5.1 Taxonomy Matrix

5.2 Trigger Design

6. RTO, RPO And AI SLOs

Traditional DR metrics must be translated for AI.

6.1 Definitions

6.2 Suggested AI Resilience Targets

6.3 SLO Catalog

---

7. Manual Fallback Design

Manual fallback is not “let humans handle it”. It is a designed operating model.

7.1 Manual Fallback Components

7.2 Manual Fallback Flow

degradation trigger
  -> freeze risky automation
  -> classify active requests by risk and deadline
  -> route Tier 1 cases to skilled reviewers
  -> provide policy snapshot and evidence viewer
  -> record manual decision and customer communication
  -> monitor backlog and breach risk
  -> recover automation only after gate approval

7.3 Queue Priority Rules

8. Customer Communication

Degraded AI service must be communicated carefully. The message should avoid over-disclosing technical internals while being accurate about service state, customer impact and next steps.

8.1 Communication Principles

8.2 Customer-Facing States

8.3 Regulated Workflow Messaging

9. Evidence Preservation

Evidence is part of resilience. If the organization cannot reconstruct what the AI saw, decided, retrieved, proposed, blocked, escalated and communicated, recovery is incomplete.

9.1 Evidence Fields

9.2 Local Evidence Ledger

When vendor evidence export is degraded, Tier 1 workflows should write a local append-only record:

trace_id
timestamp
workflow
risk_tier
mode
model_route
prompt_version
source_ids
policy_decision
tool_action
human_review
customer_visible_flag
fallback_reason
hash_of_output

This ledger should be:

• append-only。
• access-controlled。
• time-synchronized。
• retained under approved policy。
• reconciled with vendor export after recovery。
• included in audit evidence binder。

10. BCP / DR Operating Model

10.1 Decision Rights

10.2 Recovery Gate

Normal mode must not resume just because the vendor status page turns green.

Recovery gate should include:

• dependency health stable for defined window。
• no unresolved critical KRI breach。
• regression eval pass for affected workflows。
• evidence sync or approved local ledger reconciliation。
• sampled human review of degraded-period outputs。
• tool side-effect reconciliation。
• HITL queue within tolerance or approved backlog plan。
• business owner signoff。
• model risk / compliance signoff for Tier 1。
• restart decision recorded。

---

11. Tabletop Exercises

Exercises prove whether BCP is executable.

11.1 Exercise Types

11.2 Scenario 1: Model Provider Outage

At 09:15, Model Provider A reports elevated errors and rate limiting.
Customer service AI, lending assistant and complaint agent use Provider A.
RAG and tools are healthy.
Evidence export remains healthy.

Expected decisions:

• Switch Tier 2 general service to fallback model or template。
• Move Tier 1 complaint responses to draft-only。
• Keep credit reason explanations under human confirmation。
• Monitor fallback quality and latency。
• Notify operations of reduced automation。

11.3 Scenario 2: RAG Index Stale

Policy team updated fee waiver and dispute policies at 07:00.
RAG index refresh failed silently.
Customer-facing AI continues retrieving yesterday's policy.

Expected decisions:

• Disable free-form fee / dispute answers。
• Use approved templates and authoritative policy search。
• Query affected customer-visible answers since 07:00。
• Preserve retrieved source IDs and policy effective dates。
• Recover only after index validation and sample review。

11.4 Exercise Scoring

---

12. RACI

---

13. Templates

13.1 AI BCP Use Case Card

13.2 Degraded Mode Decision Card

13.3 Recovery Decision Memo

13.4 Communication And Executive Brief Template

---

14. Governance Cadence

---

15. 30-Day System Learning Lab

目标: 30 天内完成一套 AI Operational Resilience / BCP / Degraded Mode Architecture system evidence pack。推荐选择 Complaint response agent、Lending policy assistant、AML case summarizer 或 Customer service AI。

16. Decision Narrative and Design Review Questions

本节采用系统评审叙事。每个条目都应说明韧性原则、架构控制、治理证据和运行边界, 避免只停留在口号式解释。

AI Resilience Scope Beyond Conventional BCP

Decision Narrative: 普通 BCP 关注服务中断、站点切换、人员和流程恢复。AI operational resilience 还要覆盖语义正确性、RAG freshness、policy decision、tool side effect、identity entitlement、HITL capacity 和 evidence completeness。AI 可能没有宕机但已经不安全, 所以需要 normal、degraded、safe-stop 和 recovery gate。

System Evidence: 证据包应从 critical operation map 开始, 把每个 AI workflow 连接到客户权益、监管义务、最小可行服务、impact tolerance 和依赖图。然后定义触发条件、降级状态、人工接管、客户沟通、证据保存、恢复门禁和 risk acceptance。这样 BCP 不只是技术恢复计划, 而是关键业务在 AI 失效状态下的受控运行设计。

Customer-Visible Degraded Mode

Decision Narrative: 客户可见 AI 应按风险降级为 citation-required、template-only、draft-only、manual-first 或 safe-stop。费用、投诉、信贷、财富和客户权益相关内容, 在 RAG、policy、identity 或 evidence 不完整时不能自由生成或自动发送。恢复 normal 前必须通过 eval、样本复核、证据同步和业务签字。

System Evidence: 降级矩阵要覆盖 customer-facing state、allowed output、blocked action、required source、review queue、communication template 和 recovery condition。例如 RAG stale 时客服 AI 只能使用预批准模板或转人工; identity entitlement 不可用时不能个性化; evidence export 不可用时高风险输出必须切 draft-only 并写入本地证据账本。

Human-in-the-Loop Capacity Boundary

Decision Narrative: HITL 不是天然 fallback。HITL 只有在有容量、技能、优先级、SLA、证据和决策权限时才是控制。否则它会在事故中变成瓶颈。AI BCP 必须设计队列分级、surge staffing、deadline routing、review payload 和 backlog threshold。

System Evidence: manual fallback 需要 queue priority rules、staffing model、review packet、decision authority、backlog SLO、handoff evidence 和 escalation path。Tabletop exercise 应验证在供应商降级、RAG stale 或政策引擎故障时, 人工队列是否能处理 Tier 1 case, 哪些低风险任务暂停, 哪些客户承诺必须延后。

Evidence Preservation as Continuity Control

Decision Narrative: Evidence export 故障会触发降级, 因为高风险 AI 输出必须可复原、可审计、可解释。没有 evidence, 事故后无法证明模型版本、prompt、retrieved source、policy decision、tool action 和 human review。Tier 1 客户可见 workflow 在 evidence export 故障时应至少切 draft-only 并启用本地证据账本。

System Evidence: evidence preservation plan 应定义本地证据账本、trace id、版本字段、hash、保留期、reconciliation job 和 audit replay test。恢复前不仅要恢复 API, 还要证明降级期间的输出、审批、工具动作和客户沟通已经补录、校验并可抽样重放。

Policy Engine False-Allow Response

Decision Narrative: Policy engine false allow 需要先把高风险写工具切 read-only, 查询 exposure window 内的 side effects, 保留 policy decision log 和 tool ledger, 再做客户和业务补救。恢复前必须通过 policy regression、审批链路验证和工具幂等检查。

System Evidence: 响应证据应包括 exposure window、affected workflow、blocked tool list、side-effect ledger、客户影响分析、补救动作、policy regression result 和 approval-chain replay。false allow 不是单纯模型质量问题, 而是授权控制面失效, 必须进入 operational resilience、security、risk 和 incident management 的共同处理路径。

AI RTO/RPO/SLO Semantics

Decision Narrative: AI RTO 是恢复受控服务的时间, 不一定是恢复完整自动化。AI RPO 是可接受的证据、source、prompt、tool、human review 记录损失窗口。Tier 1 客户可见流程可能要求 30-60 分钟内恢复 template 或 manual service, 且不能有不可恢复证据缺口。

System Evidence: AI SLO catalog 应区分 availability、answerability、citation correctness、tool success、evidence completeness、review queue age、customer communication timeliness 和 recovery reconciliation。RTO/RPO 不能只由技术平台定义, 还要由 business owner、operational risk 和 compliance 按客户影响与监管义务批准。

Recovery Gate Design

Decision Narrative: 恢复 normal mode 不能只看供应商状态页变绿。恢复 gate 要看 dependency health、regression eval、样本复核、evidence reconciliation、tool side-effect reconciliation、HITL backlog、客户影响和业务 / 风险 / 合规签字。

System Evidence: recovery memo 应列出触发原因、降级期间影响、已执行控制、待补录证据、样本复核结果、已验证依赖、剩余风险、恢复范围和签字人。对客户可见或受监管流程, 可以先恢复 template-only 或 draft-only, 再分阶段恢复 full AI assistance。

Executive Value Narrative

Decision Narrative: AI BCP 不是阻碍自动化, 而是保护关键运营。当 AI 依赖失败时, 机构需要知道哪些服务继续、哪些服务降级、哪些动作停止、谁做决定、客户如何沟通、证据如何保全、何时恢复。这能降低客户伤害、监管风险和混乱停机。

System Evidence: 高管材料应使用 impact tolerance、critical operation、customer harm、regulatory obligation、dependency concentration、manual capacity、evidence integrity 和 recovery decision 语言, 而不是只汇报模型可用率。最有价值的输出是可演练的 degraded mode runbook 和 remediation backlog, 因为它们证明企业知道如何在 AI 不可信或不可用时继续受控运营。

---

17. System Evidence Pack and Self-Assessment

System evidence pack:

Self-assessment checklist:

---

18. Final Principle

AI operational resilience 的成熟度可以用系统检验:

When AI is degraded, do we already know which customer promises stop, which operations continue, which humans take over, which evidence is preserved, which executives decide, and what proof is required before automation returns?

如果答案不清楚, 企业只是把 AI 功能上线了, 还没有把 AI 做成关键运营能力。