AI Portfolio Systemic Risk / Dependency Architecture Playbook

定位：面向 CBAP+、金融零售 AI PM、AI Product Architect、Enterprise Architect、Model Risk、Third-Party Risk、Cyber / Operational Resilience 和 AI Governance 负责人。本文不是入门级“AI 风险清单”，而是训练你在企业 AI portfolio 层面识别、量化和治理 correlated AI failures、model / vendor concentration、shared data / knowledge dependency、policy drift、cross-use-case incident propagation 与 portfolio-level controls。

核心判断：

单个 AI use case 的 residual risk 可能是可接受的；但多个 use case 同时依赖同一个模型、供应商、知识源、身份服务、人工复核队列或证据栈时，portfolio dependency risk 可能不可接受。

金融零售企业的 AI 风险不再只是“某个模型是否准确”。真正的架构问题是：当同一个 foundation model 静默升级、同一个 RAG 知识库过期、同一个 policy service 配置漂移、同一个 human review queue 被打爆、同一个 monitoring stack 丢日志时，多少客户旅程、业务决策、监管流程和运营团队会同时受影响。

---

Source Anchors

以下锚点用于组织治理语言、监管对话和架构控制设计。本文是学习、作品集和架构训练材料，不构成法律意见、监管解释、审计结论或认证建议。正式项目必须由 legal、compliance、model risk、third-party risk、cyber、operational resilience、business owner 和 internal audit 按机构、司法辖区、客户影响、数据分类和供应商合同复核。

---

1. 核心心智模型：Use Case Risk vs Portfolio Dependency Risk

传统 AI governance 很容易停在项目层：

Use case intake
-> risk tiering
-> model / data review
-> eval gate
-> release approval
-> ongoing monitoring

这条线仍然必要，但不充分。企业 AI portfolio 的风险来自横向耦合：

多个业务用例
-> 共享模型 / RAG / vendor / policy / identity / HITL / monitoring
-> 共同失效条件
-> 同时影响多个客户旅程、业务流程、控制流程和监管义务

1.1 单点通过不等于组合安全

一个客服总结助手可能是中风险；一个信贷材料摘要助手可能在人工审批前使用，单独看也可接受；一个 AML case summarizer 如果只是辅助调查员阅读，也可能被批准。但如果这三个系统共享：

• 同一个 LLM provider；
• 同一个 embedding model；
• 同一个 customer knowledge base；
• 同一个 prompt / policy guardrail；
• 同一个 case evidence logging stack；
• 同一个人工复核队列；

那么组合风险就不是三份低中风险相加，而是一个 portfolio-level correlated failure surface。

典型问题：

1.2 Portfolio Dependency Risk 的定义

AI portfolio dependency risk = 多个 AI use cases 对共同技术、数据、知识、供应商、控制、运营或人员能力的依赖，在特定压力场景下产生同步失效、放大影响、延迟恢复或证据缺失的风险。

它包含六类机制：

1. Correlation：同一模型行为变化导致多个用例质量一起下降。
2. Concentration：过多高影响用例集中在一个 vendor、cloud、GPU supply、embedding 或 vector DB 上。
3. Propagation：一个政策源、知识库、身份授权或 workflow 配置错误跨用例传播。
4. Contention：共享队列、人工审核、GPU capacity、rate limit、incident team 或 support channel 被争抢。
5. Opacity：共享 observability / evidence stack 失效后，多个用例同时无法解释、复现或证明控制运行。
6. Policy Drift：法规、内部政策、产品条款或风险偏好更新没有同步进入所有 AI 流程，导致不同用例给出不一致或过期行为。

1.3 架构师的关键转身

项目级 AI PM 问：“这个 use case 能不能上线？”

AI Product Architect 问：“这个 use case 应该接入哪些 shared platform controls？”

Enterprise Architect 问：“当这个 shared dependency 失败时，哪些 business capabilities 会同时失效，机构是否接受这个风险？”

CBAP+ 的价值在这里体现：你不是只写需求，而是把 business capability、process、decision、data、policy、system、vendor、control、evidence 和 role accountability 串成一张 dependency architecture。

---

2. Dependency Taxonomy：AI Portfolio 依赖分类

AI dependency taxonomy 要覆盖技术、数据、知识、流程、控制和运营。只登记模型供应商远远不够。

2.1 Dependency Criticality 的三个维度

对每个依赖都要打三类分：

可用一个简单公式做初筛：

Dependency Portfolio Criticality
= Impacted High-Risk Use Cases
  x Coupling Intensity
  x Recovery Time Gap
  x Evidence Loss Severity

这个公式不是精算模型，而是帮助管理层看到：风险不只来自“这个依赖坏了”，而来自“它坏的时候，我们同时失去多少业务能力、控制能力和证明能力”。

---

3. Portfolio Risk Map 与 Dependency Graph 方法

AI portfolio 风险图不是项目清单，而是一张有方向、有权重、有 owner、有控制状态的 dependency graph。

3.1 建图对象

3.2 Edge 类型

3.3 建图步骤

1. 从高影响 business capability 开始：不要从模型清单开始。先列客户服务、信贷、AML、欺诈、财富、投诉、分行运营、监管报告等能力。
2. 把 AI use case 映射到 capability：每个 use case 只能有一个 primary capability，但可以有多个 secondary capability。
3. 登记 shared dependencies：模型、vendor、cloud / GPU、embedding、vector DB、knowledge source、policy service、identity、workflow、HITL、monitoring / evidence stack。
4. 标注 dependency edge：实时路径、批处理路径、控制路径、证据路径、人工路径要分开。
5. 计算 exposure concentration：看某个依赖承载了多少高风险用例、多少客户交互量、多少关键流程、多少控制证据。
6. 跑压力场景：模型升级、供应商中断、政策漂移、RAG 索引损坏、身份服务误配置、HITL 队列积压、日志丢失。
7. 定义 portfolio controls：集中度限制、分段隔离、fallback diversity、kill switch hierarchy、shared SLO、exit drill、dependency risk review。
8. 纳入治理节奏：月度 portfolio KRI、季度 dependency risk review、重大变更前 dependency impact assessment、事故后 propagation analysis。

3.4 简化图例

Customer Service AI
  -> Model A
  -> Embedding E1
  -> Vector DB V1
  -> Customer Policy KB
  -> Policy Service P1
  -> HITL Queue Q1
  -> Evidence Stack O1

Lending AI
  -> Model A
  -> Embedding E1
  -> Vector DB V1
  -> Credit Policy KB
  -> Policy Service P1
  -> HITL Queue Q2
  -> Evidence Stack O1

AML AI
  -> Model A
  -> Embedding E1
  -> Vector DB V1
  -> AML Typology KB
  -> Policy Service P1
  -> HITL Queue Q3
  -> Evidence Stack O1

项目级看，三个系统各自有模型、RAG、人工复核和监控。Portfolio 级看，Model A、Embedding E1、Vector DB V1、Policy Service P1、Evidence Stack O1 是共同失效点。

3.5 Heatmap 的两个坐标

Portfolio heatmap 不建议只用 likelihood / impact。对 dependency architecture 更有效的坐标是：

X-axis: Concentration / Coupling
Y-axis: Business / Regulatory Impact

---

4. Financial Retail Cases

Case 1：客服 + 信贷 + AML 共用同一模型、RAG、Vendor

场景

一家零售金融机构为了提升效率，采用同一个 enterprise LLM vendor 和 RAG platform：

• 客服 AI：回答账户、费用、产品、争议处理问题。
• Lending AI：总结申请材料、解释信贷政策、生成审批备忘录草稿。
• AML AI：总结 suspicious activity case、提取交易模式、建议调查问题。

项目团队分别完成了风险评估：

Portfolio 级问题

三者共享同一组关键依赖：

Vendor X
-> Model X-Reasoning
-> Embedding X-Embed
-> RAG SaaS X-Knowledge
-> Vector index managed by Vendor X
-> Policy guardrail template maintained by Vendor X
-> Shared evidence export API

如果 Vendor X 的模型更新改变了 summarization bias，可能出现：

• 客服回答更自信，但引用条款不完整；
• Lending summary 低估负面收入波动；
• AML summary 过度压缩异常交易序列，遗漏关键模式；
• 三个团队都以为是“个别质量波动”，没有意识到共同根因是模型行为变化。

架构诊断

Portfolio controls

1. Concentration limit：同一 vendor / model 不得承载超过既定阈值的 Tier 1 / Tier 2 customer-impact use cases，超过阈值必须由 AI Risk Committee 批准。
2. Model diversity for critical paths：高影响摘要类用例至少保留一个可运行 fallback model 或 extractive baseline，用于事故、回归测试和紧急切换。
3. Shared regression pack：每次模型、embedding、RAG 平台或 vendor policy template 变化，都要运行跨用例 golden set，包括客服条款、信贷边界案例、AML typology。
4. Dependency incident flag：任一 use case 出现异常时，incident triage 必须检查是否存在共同模型、RAG、embedding、vendor、evidence stack。
5. Evidence independence：关键 use case 的 trace / audit export 不应只依赖 vendor 自有界面；至少要有机构侧日志落地和不可篡改保留策略。

Case 2：财富助手与投诉 Agent 共用同一政策源

场景

财富助手面向理财顾问，帮助解释产品适配性、费用、风险等级和披露要求。投诉 Agent 面向后台投诉团队，帮助分析客户投诉是否涉及误导销售、费用争议或不当建议。

两个系统都连接同一个 “Wealth Policy Knowledge Base”：

Wealth Assistant
  -> Wealth Policy KB
  -> Product Disclosure Docs
  -> Suitability Policy

Complaint Agent
  -> Wealth Policy KB
  -> Product Disclosure Docs
  -> Complaint Handling SOP

Portfolio 级问题

某次政策更新后，产品费用披露文档已更新，但 suitability policy 的例外条款未同步进入 RAG index。财富助手继续引用旧规则，投诉 Agent 则用同一旧规则判断历史投诉是否成立。

这不是一个简单知识库过期问题，而是 policy drift 在前台建议和后台纠错流程之间形成闭环偏差：

• 前台可能持续给出过期解释；
• 后台投诉分析可能低估问题严重性；
• 管理层看到的 complaint trend 被低估；
• remediation 范围被错误缩小。

架构诊断

Portfolio controls

1. Policy source of record：明确每类政策的 authoritative source，不允许团队私自复制政策片段作为长期知识源。
2. Effective-date aware retrieval：RAG metadata 必须包含 effective date、retirement date、jurisdiction、product、channel、customer segment。
3. Cross-use-case consistency tests：财富助手、客服、投诉、分行员工助手对同一政策问题必须给出一致边界；不要求措辞相同，但结论、引用和升级路径必须一致。
4. Policy drift watchlist：高风险政策变更后，在 7 / 14 / 30 天内抽样查看相关 AI 输出、人工 override、投诉、quality review 和 customer correction。
5. Closed-loop remediation：投诉 Agent 发现政策解释错误时，必须触发前台助手知识库、prompt、training note 和 advisor communication 的同步整改。

Case 3：Branch Operations Agent 打爆共享 HITL Queue

场景

分行运营 Agent 帮员工处理开户、地址变更、遗失卡、异常交易解释和客户资料补全。上线初期设计了人审：

Agent low confidence
-> HITL queue
-> Operations specialist review
-> Approve / edit / reject

同一个 HITL queue 后来被多个 AI 用例复用：

• 分行运营 Agent；
• 客服投诉草稿 Agent；
• KYC exception Agent；
• Loan documentation completeness Agent；
• Fraud case pre-review Agent。

Portfolio 级问题

某周新政策和促销活动同时上线，分行运营 Agent 的 low-confidence rate 从 8% 升到 24%。大量任务进入共享 HITL queue，导致：

• KYC exception 审核超时；
• fraud case pre-review 延迟；
• 投诉回复 SLA 破裂；
• 分行员工绕过 AI 建议，手工处理但缺少记录；
• 管理层误以为是“人力不足”，没有发现是 AI confidence drift + shared queue contention。

架构诊断

Portfolio controls

1. Queue segmentation：按风险等级、监管时限、客户影响和业务流程隔离队列，不把所有 AI fallback 都丢进一个池子。
2. Surge capacity plan：高峰、政策更新、事故、活动、系统变更期间预设临时 reviewer、优先级规则和自动降级策略。
3. HITL SLO as shared control SLO：人工队列不是运营细节，而是 portfolio control；必须有 SLO、capacity、skill coverage、alert 和 owner。
4. Confidence drift trigger：任一 use case 的 low-confidence、escalation、override 异常上升时，检查是否会冲击共享 HITL。
5. Workaround monitoring：监控 AI bypass、manual completion、missing trace、late review，防止员工绕过控制后形成 invisible risk。

---

5. Portfolio-Level Controls

5.1 Concentration Limits

Concentration limits 不是简单规定“最多几个供应商”。金融零售 AI 要按风险权重定义限制。

建议使用 risk-weighted exposure：

Risk Weighted AI Exposure
= customer interactions x risk tier weight
  + regulated decisions x decision weight
  + sensitive records accessed x data weight
  + revenue / loss exposure x financial weight

然后对每个模型、vendor、cloud、RAG、policy source、HITL queue、evidence stack 计算占比。

5.2 Blast-Radius Segmentation

Blast-radius segmentation 的目标不是所有东西都隔离，而是让一个依赖失败时不会横向吞掉整个 portfolio。

一个成熟的 AI platform 应该允许共享基础能力，同时用 routing、policy、identity、data filter、logging、rate limit 和 kill switch 做分段。

5.3 Fallback Diversity

Fallback 不是“模型 A 挂了就切模型 B”。有效 fallback 必须覆盖四种差异：

Fallback 设计必须测试，不测试的 fallback 只是幻觉控制。每个 Tier 1 / Tier 2 use case 至少每季度做一次 fallback drill 或 tabletop exercise。

5.4 Kill Switch Hierarchy

Kill switch 要分层，避免只有“全关”这一种粗暴选项。

Kill switch 需要明确：

• 谁有权触发；
• 触发后哪些系统自动通知；
• 降级后的客户和员工体验；
• 恢复条件和 evidence requirement；
• 事后是否进入 risk acceptance 或 remediation。

5.5 Shared Service SLO

共享 AI 服务必须像核心平台一样有 SLO，而不是作为项目工具随意使用。

5.6 Vendor Exit Drill

Exit plan 写在合同里不等于可执行。AI vendor exit drill 要验证：

1. 模型调用是否能切到替代 provider 或机构自托管模型。
2. Prompt、eval、golden set、trace schema 是否 vendor-neutral。
3. RAG 文档、metadata、embedding、index、citation history 是否能导出或重建。
4. 生产日志、事故证据、human feedback、annotation 是否能保留。
5. 数据删除、训练排除、保留期限和子处理方记录是否可证明。
6. 替代方案的成本、延迟、质量和控制差异是否被业务接受。
7. 客户沟通、员工指引、监管通知和服务降级脚本是否准备好。

Exit drill 的结果不应只给 procurement，而应进入 architecture review、risk committee 和 portfolio roadmap。

5.7 Dependency Risk Review

重大 AI 变更必须做 dependency risk review，而不是只做功能回归。

触发条件：

• foundation model、embedding、reranker、judge model 版本变化；
• vendor 合同、子处理方、数据条款、区域或 SLA 变化；
• 新用例接入 shared model / RAG / policy / HITL / evidence stack；
• 高风险政策或产品条款更新；
• AI use case risk tier 升级；
• 事故、near miss、监管问询、客户投诉趋势异常；
• capacity、latency、cost、queue backlog 超过 KRI threshold。

Review 输出：

• impacted use cases；
• shared dependencies；
• blast radius；
• regression / eval scope；
• control gaps；
• kill switch readiness；
• fallback readiness；
• residual risk owner；
• approval / remediation decision。

5.8 Incident Propagation Analysis

AI incident postmortem 不能只问“这个 use case 为什么出错”，还要问“这个错误会不会已经传播到其他 use cases”。

Propagation analysis checklist：

---

6. Artifacts / Templates

6.1 AI Dependency Register

6.2 Concentration Risk Heatmap

Heat 判定不要只看数量。一个依赖如果同时具备 high customer impact、low substitutability、evidence criticality，就算 use case 数量不多，也可能是红色。

6.3 Blast-Radius Map

6.4 Scenario Stress Test

6.5 Shared Control Library

6.6 Portfolio Risk Acceptance Memo

Decision title:
Accept temporary concentration risk for Model A across customer service, lending, and AML AI use cases

Decision owner:
Chief Risk Officer, with AI Governance Committee endorsement

Business rationale:
Model A currently provides materially better multilingual quality, latency, and integration support than alternatives. Immediate diversification would delay three critical risk-reduction initiatives.

Risk accepted:
Model A supports 3 Tier 1 and 5 Tier 2 use cases, including customer-facing service explanations, lending document summarization, and AML case summarization. A model behavior change, regional outage, or vendor evidence export failure could affect multiple regulated workflows simultaneously.

Compensating controls:
1. Cross-use-case regression pack before any model version change.
2. L3 shared dependency kill switch in model gateway.
3. Extractive summarization fallback for lending and AML.
4. Independent institution-side trace retention for Tier 1 use cases.
5. Monthly concentration KRI reporting to AI Governance Committee.
6. Vendor exit drill completed within 90 days.

Time boundary:
Risk acceptance expires in 6 months or earlier if concentration threshold exceeds approved exposure.

Review triggers:
Vendor incident, model version change, new Tier 1 onboarding, KRI breach, regulatory inquiry, evidence export failure, or customer harm incident.

Residual risk statement:
Residual portfolio dependency risk remains elevated but is accepted temporarily because controls reduce immediate blast radius and a funded diversification roadmap is in execution.

---

7. Metrics / KRIs

Portfolio-level AI KRIs 要同时覆盖 concentration、correlation、control effectiveness、resilience、evidence 和 human capacity。

7.1 Concentration KRIs

7.2 Correlated Failure KRIs

7.3 Resilience / Control KRIs

7.4 Policy Drift KRIs

7.5 Suggested Thresholding

阈值不要一次定死。建议按三步成熟：

1. Baseline：先记录 60-90 天，建立模型、RAG、HITL、policy、evidence 的自然波动范围。
2. Risk appetite alignment：按 customer impact、regulatory obligation、operational resilience 设定红黄线。
3. Dynamic triggers：在模型升级、政策变更、供应商事件、业务高峰、监管检查期间临时收紧阈值。

---

8. Governance Cadence

Portfolio dependency risk 必须进入固定治理节奏，否则会被项目进度吞掉。

8.1 RACI

8.2 Architecture Review Questions

在 AI Architecture Review Board 上，不要只问系统图。问这些问题：

1. 这个 use case 新增了哪些 shared dependencies？
2. 它会提高哪个模型、vendor、RAG、policy、HITL、evidence stack 的 concentration？
3. 依赖失败时，blast radius 是 use-case、domain 还是 enterprise？
4. fallback 是 tested fallback，还是文档里的想法？
5. 事故时能否按 dependency 维度 kill switch，而不是只能全关应用？
6. RAG 的 authoritative source、effective date、ACL 和 index version 如何证明？
7. 人工复核队列是否已有容量、技能、优先级和 surge plan？
8. 监控证据是否在机构侧保留，还是只在 vendor portal？
9. 这个变更是否需要 cross-use-case regression？
10. 哪个管理层角色接受 residual portfolio dependency risk？

---

9. Operating Model：从项目治理到 Portfolio Control Plane

9.1 三层控制面

没有 portfolio control plane 的企业，会不断批准“看起来都可控”的单个用例，直到某个共享依赖出事时才发现整体不可控。

9.2 Control Plane 的最小可行组件

1. AI use case inventory：不是静态清单，而是连接 dependency graph。
2. Dependency register：模型、vendor、cloud、embedding、vector DB、knowledge source、policy service、identity、workflow、HITL、monitoring。
3. Model / RAG gateway：集中记录版本、路由、policy decision、latency、fallback、kill switch。
4. Knowledge governance workflow：source owner、metadata、effective date、ACL、index refresh、citation eval。
5. Shared KRI dashboard：concentration、quality drift、HITL saturation、policy drift、evidence completeness。
6. Change impact analyzer：模型或政策变更时查询 impacted use cases 和 required regression。
7. Incident propagation playbook：按 dependency 追踪 cross-use-case impact。
8. Risk acceptance workflow：portfolio-level residual risk 的 owner、期限、条件、复核触发器。

9.3 CBAP+ 需求写法

不要只写：

系统应记录模型调用日志。

要写成 portfolio requirement：

For every Tier 1 and Tier 2 AI use case, the platform shall record model version, prompt version, retrieval source IDs, policy decision ID, tool call parameters, human review action, fallback status, and dependency ID, so that incident responders can identify all use cases affected by a shared dependency failure within 30 minutes.

不要只写：

系统应支持人工复核。

要写成 shared control requirement：

The shared HITL service shall route review tasks by risk tier, regulatory deadline, customer impact, and required reviewer skill, and shall expose backlog, age, SLA breach, override rate, and surge capacity indicators by use case and portfolio dependency group.

---

10. Interview Section

Question

How do you manage AI risk at portfolio level, not just per project?

30-Second Answer

我会把 AI 风险从 use-case review 提升到 dependency architecture。单个项目可能通过评审，但如果多个客服、信贷、AML、财富或投诉用例共享同一个模型、vendor、RAG、policy service、HITL queue 或 evidence stack，就会产生 correlated failure 和 concentration risk。我的做法是建立 AI dependency register 和 portfolio dependency graph，按模型、供应商、知识源、策略服务、人工队列和证据栈计算 risk-weighted exposure；再用 concentration limits、blast-radius segmentation、fallback diversity、kill switch hierarchy、shared service SLO、vendor exit drill 和 incident propagation analysis 管理组合风险。

2-Minute Answer

项目级 AI risk management 主要回答“这个 use case 是否可以上线”。但金融零售企业真正危险的是 portfolio dependency risk：多个看似独立的 AI 用例共享同一模型、供应商、RAG 知识库、policy service、identity、workflow、human review queue 或 monitoring evidence stack。一旦模型升级、供应商中断、政策源漂移、权限过滤错误或人工队列过载，失败会跨用例传播，影响客户服务、信贷、AML、财富、投诉和分行运营。

我的管理方法分四步。第一，建立 AI dependency taxonomy 和 register，不只登记模型，还登记 vendor、cloud / GPU、embedding、vector DB、knowledge source、policy service、identity、workflow、HITL 和 evidence stack。第二，画 portfolio dependency graph，把 use case、business capability、risk tier、customer impact、dependency、control 和 owner 连接起来，计算 concentration、coupling、substitutability 和 blast radius。第三，设计 portfolio-level controls，例如单一模型和供应商的 concentration limits，高风险域的 blast-radius segmentation，模型和检索的 fallback diversity，按依赖分层的 kill switch，shared service SLO，vendor exit drill，以及任何 AI incident 都要做 propagation analysis。第四，把这些指标纳入治理节奏：周度运营看 SLO 和队列，月度看 KRI 和 concentration heatmap，季度做 dependency risk review 和 scenario stress test，重大变更前做 cross-use-case regression。

如果面试官追问例子，我会用金融零售场景说明：客服、信贷和 AML 如果共用同一模型和 RAG vendor，单个项目都可能是可接受风险，但 portfolio 级别可能已经超过风险偏好。我的架构目标不是阻止共享，而是让共享可见、可度量、可隔离、可降级、可退出、可审计。

---

11. Portfolio Exercise

Exercise Goal

为一家中型金融零售机构设计 AI Portfolio Systemic Risk / Dependency Architecture。假设已有 12 个 AI use cases：

1. 客服 AI assistant；
2. 分行员工知识助手；
3. 信贷材料摘要；
4. AML case summarizer；
5. fraud alert triage；
6. wealth advisor copilot；
7. complaint response agent；
8. KYC exception assistant；
9. collections script assistant；
10. operations procedure assistant；
11. regulatory change summarizer；
12. developer coding assistant。

Step 1：分级

按客户影响、监管影响、数据敏感度、动作权限和可逆性给每个 use case 分 Tier 1 / Tier 2 / Tier 3。

建议：

Step 2：画 dependency graph

为每个 use case 标出：

• model；
• vendor；
• cloud / GPU；
• embedding；
• vector DB；
• knowledge source；
• policy service；
• identity；
• workflow；
• human review queue；
• monitoring / evidence stack。

输出一张表：

Step 3：识别红色依赖

回答：

1. 哪个 model 支撑最多 Tier 1 / Tier 2 use cases？
2. 哪个 vendor 同时控制运行路径和证据路径？
3. 哪个 knowledge source 的 policy drift 会影响前台和后台？
4. 哪个 HITL queue 可能在事故中成为瓶颈？
5. 哪个 monitoring / evidence dependency 失效后会导致多个 use case 无法 replay？

Step 4：设计控制组合

对每个红色依赖至少设计：

• concentration limit；
• blast-radius segmentation；
• fallback diversity；
• kill switch level；
• SLO / KRI；
• owner；
• exit or recovery drill；
• risk acceptance condition。

Step 5：写 portfolio risk acceptance memo

选择一个无法立即降低的 concentration risk，写一页 memo：

• business rationale；
• residual risk；
• impacted use cases；
• compensating controls；
• time boundary；
• review triggers；
• exit / diversification roadmap；
• accountable executive。

Step 6：做 tabletop exercise

选择一个压力场景：

Vendor X announces emergency model rollback after discovering a safety regression.
Your institution uses Vendor X model across customer service, lending, AML, and complaint AI.
Evidence export API is also degraded.

演练 90 分钟：

1. 识别 impacted use cases；
2. 决定 kill switch level；
3. 切换 fallback；
4. 启动 HITL prioritization；
5. 固化证据；
6. 形成客户、员工、监管和管理层沟通；
7. 输出 remediation backlog。

---

12. Checklist

12.1 Portfolio Inventory

• 每个 AI use case 都有 risk tier、business capability、owner、approved boundary。
• 每个 use case 都连接到 dependency register，而不是孤立记录。
• Dependency taxonomy 覆盖 model、vendor、cloud / GPU、embedding、vector DB、knowledge source、policy service、identity、workflow、HITL、monitoring / evidence stack。
• 每个 shared dependency 都有 technical owner、business owner、risk owner。
• 每个 high-impact dependency 都有 substitutability 和 exit time 估计。

12.2 Concentration And Blast Radius

• 已计算单一模型、vendor、RAG、policy service、HITL、evidence stack 的 risk-weighted exposure。
• 高集中度依赖有 heatmap、threshold、executive visibility。
• Tier 1 / Tier 2 use cases 不会无意识集中在同一不可替代 vendor。
• Blast-radius map 覆盖模型漂移、RAG 错误、政策漂移、HITL 饱和、证据失效、供应商中断。
• 高风险共享依赖有明确 kill switch level 和恢复条件。

12.3 Controls And Resilience

• 关键 use cases 有 tested fallback，而不只是设计文档。
• Shared services 有 SLO，包括 model gateway、RAG、policy service、HITL、evidence stack。
• Vendor exit drill 验证数据、prompt、eval、trace、index、合同和运营迁移。
• Human review queue 有风险优先级、技能路由、surge plan 和 saturation alert。
• Evidence retention 不完全依赖 vendor portal。

12.4 Policy Drift And Knowledge Governance

• 每个政策源有 authoritative source owner。
• RAG metadata 包含 effective date、retirement date、jurisdiction、product、channel、customer segment。
• 高风险政策变更会触发 index refresh、prompt / policy rule review、cross-use-case regression。
• 前台和后台用例对同一政策问题有 consistency eval。
• 投诉、override、manual correction 能回流到知识治理和产品整改。

12.5 Incident And Governance

• AI incident template 包含 dependency propagation analysis。
• 事故 triage 会查询共同模型、vendor、RAG、policy、identity、workflow、HITL 和 evidence stack。
• Portfolio KRI 至少月度进入 AI Governance Committee。
• Dependency risk review 至少季度执行一次。
• Portfolio-level risk acceptance 有 owner、期限、条件、触发器和 compensating controls。

---

13. 最后的架构判断

金融零售 AI 的成熟标志，不是模型数量、PoC 数量或 demo 效果，而是企业能否回答：

1. 我们的 AI portfolio 最关键的共同依赖是什么？
2. 哪些单点依赖已经超出风险偏好？
3. 哪些 use case 会在同一模型、政策、知识库、人工队列或证据栈失败时一起受影响？
4. 我们能否在 30 分钟内识别 impacted use cases？
5. 我们能否按依赖隔离、降级、切换和恢复，而不是全企业混乱停机？
6. 我们能否向管理层、审计和监管证明控制真实运行？

如果答案不清楚，企业还停留在项目级 AI governance。真正的 AI enterprise architecture 要把每个 use case 放回 portfolio graph，把每个 shared dependency 变成可见、可度量、可控制、可演练、可退出、可审计的架构对象。