AI Portfolio Systemic Risk：依赖架构
单个 AI use case 的风险可接受，不代表整个 AI portfolio 的风险可接受。当多个产品共用同一个模型、供应商、RAG 知识源、embedding、工具网关、身份服务、human review queue 或 evidence stack 时，原本独立的失败会变成相关失败。
AI Portfolio Systemic Risk / Dependency Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_PORTFOLIO_SYSTEMIC_RISK_DEPENDENCY_ARCHITECTURE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| 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/81230.html | 把 portfolio governance、management review 和持续改进纳入 AI 管理体系 |
| Federal Reserve SR 23-4 | https://www.federalreserve.gov/supervisionreg/srletters/SR2304.htm | 参考第三方风险管理和业务韧性思维 |
| OCC Bulletin 2023-17 | https://www.occ.gov/news-issuances/bulletins/2023/bulletin-2023-17.html | 参考银行第三方风险管理原则 |
| NIST CSF | https://www.nist.gov/cyberframework | 参考 identify/protect/detect/respond/recover 的组合级控制 |
| FSB | https://www.fsb.org/ | 参考 AI 对金融稳定、集中度和第三方依赖的系统性风险讨论 |
核心导读
单个 AI use case 的风险可接受，不代表整个 AI portfolio 的风险可接受。当多个产品共用同一个模型、供应商、RAG 知识源、embedding、工具网关、身份服务、human review queue 或 evidence stack 时，原本独立的失败会变成相关失败。
Portfolio systemic risk 的核心不是“某个 AI 项目会不会出错”，而是“哪些共享依赖会让多个高价值流程同时失效、同时漂移、同时过载或同时失去证据”。因此企业级 AI 架构需要 dependency graph、concentration risk heatmap、blast-radius map、fallback diversity、portfolio KRIs 和 systemic incident response。
1. 问题定义：项目级评审看不见相关失败
项目级 AI 风险评审通常关注：
| 项目级问题 | 作用 |
|---|---|
| use case 风险等级是什么 | 判断单个场景影响 |
| 模型是否通过验证 | 判断当前模型表现 |
| prompt 和 RAG 是否测试 | 判断输出质量 |
| 是否有人类监督 | 判断控制边界 |
| 是否有日志和审批 | 判断审计能力 |
组合级风险问的是另一组问题：
| 组合级问题 | 关注点 |
|---|---|
| 有多少关键流程依赖同一个模型供应商 | vendor concentration |
| 同一个政策知识库错误会影响多少产品 | shared knowledge source |
| 同一个 embedding/index bug 会污染多少 RAG 系统 | retrieval dependency |
| 同一个 human review queue 是否会被多个 Agent 同时压垮 | oversight capacity |
| 同一个 tool gateway 故障会导致多少流程停止 | shared action layer |
| 供应商模型更新会不会同时改变多个产品行为 | correlated drift |
| evidence stack 故障时哪些系统会变成审计黑洞 | audit dependency |
项目级看是绿色，portfolio 级可能已经是红色。AI 从 POC 走向平台化后，系统性风险往往来自共享能力，而不是单个功能本身。
2. 架构模型：用 dependency graph 管理 AI portfolio
2.1 Dependency taxonomy
AI 组合风险来自多层依赖，而不只是模型供应商。
| Dependency | 例子 | 风险 |
|---|---|---|
| Model | same frontier model for all copilots | correlated behavior drift |
| Vendor | single LLM vendor | concentration、outage、contract leverage |
| Cloud/GPU | same region/provider | capacity and resilience risk |
| Embedding model | shared embedding for RAG | retrieval drift |
| Vector DB | shared vector platform | outage、deletion complexity |
| Knowledge source | policy repository | stale policy affects many systems |
| Tool gateway | shared action layer | systemic tool failure |
| Identity service | delegated auth | cross-agent authorization incident |
| Policy service | runtime guardrails | global false allow/deny |
| Human queue | centralized reviewer pool | overload、escalation failure |
| Evidence stack | trace/evidence lake | audit blackout |
| Vendor support | managed agent platform | incident response dependency |
2.2 Dependency graph
Portfolio architecture 应用图来表达，而不是只用项目清单。
Use Case
-> AI Capability
-> Model / Vendor
-> Data / Knowledge
-> Retrieval / Embedding / Vector DB
-> Tools / Action Layer
-> Identity / Policy Controls
-> Human Review Queue
-> Evidence Stack
每个 node 至少记录：
| Node attribute | 作用 |
|---|---|
| owner | 明确责任方 |
| criticality | 判断业务关键性 |
| dependent use cases | 衡量集中度 |
| risk tier mix | 区分低风险与高风险依赖 |
| fallback option | 判断韧性 |
| exit difficulty | 判断替换难度 |
| incident history | 识别重复风险 |
| SLO/KRI | 量化运营状态 |
| review cadence | 建立治理节奏 |
每条 edge 至少记录：
| Edge attribute | 作用 |
|---|---|
| dependency type | 模型、数据、工具、身份、证据等 |
| strength | hard dependency 还是 optional dependency |
| data sensitivity | 评估隐私和合规影响 |
| action authority | 判断是否会改变客户或系统状态 |
| failure propagation path | 识别故障如何扩散 |
2.3 Concentration risk heatmap
集中度风险不是因为组件“可能坏”，而是因为它坏了会同时影响很多高价值流程。
| Dependency | Dependent use cases | Risk tier | Fallback | Heat |
|---|---|---|---|---|
| LLM vendor A | 18 | medium/high | weak | red |
| Policy RAG source | 9 | high | manual policy search | amber |
| Tool gateway | 14 | high | read-only degrade | red |
| Human review queue | 11 | high | overflow team | amber |
| Evidence lake | 22 | all | delayed export | red |
Heatmap 的价值在于把“共享能力”重新解释为“共享失败面”。越多高风险 use cases 依赖同一节点，越需要分段、替代、降级和演练。
3. 关键机制与生命周期
3.1 Portfolio dependency lifecycle
AI portfolio 风险应以生命周期方式管理：
| 阶段 | 机制 |
|---|---|
| Inventory | 建立 AI use case 与 shared dependency register |
| Map | 画 dependency graph 和 failure propagation path |
| Classify | 标注 risk tier、criticality、data sensitivity、action authority |
| Measure | 计算 concentration、fallback gap、queue utilization、evidence completeness |
| Segment | 按业务域、风险等级、客户影响隔离 blast radius |
| Diversify | 为关键流程建立模型、供应商、知识源或人工降级路径 |
| Monitor | 用 portfolio KRIs 监控相关失败和共享瓶颈 |
| Drill | 演练 vendor exit、model rollback、queue surge、evidence outage |
| Respond | 事故时查询 affected use cases，分层降级和 containment |
| Review | 管理层定期接受或降低组合级剩余风险 |
3.2 Blast-radius map
Blast radius 关注某个共享节点失效时会影响什么。
| 共享节点 | 失效方式 | 影响面 | 降级策略 |
|---|---|---|---|
| Model provider | outage、silent model update、quality regression | 多个 copilot/agent 行为同时变化 | freeze high-risk flows、fallback model、manual queue |
| Policy source | ingestion error、stale document、wrong version | 多个 RAG 输出引用错误政策 | source rollback、affected-use-case query、manual lookup |
| Tool gateway | authorization bug、latency、policy false allow/deny | 多个 Agent 无法执行或越权执行 | read-only mode、tool-scope disable、domain kill switch |
| Human review queue | overload、SLA breach、skill mismatch | 高风险 exception 延迟或漏审 | priority policy、surge staffing、autonomy downgrade |
| Evidence lake | data loss、pipeline failure、access outage | 审计、复盘、validation 失效 | local buffer、delayed export、critical event replication |
3.3 Fallback diversity
Fallback 不能只写“人工处理”。不同依赖需要不同降级路径：
| 依赖类型 | 有效 fallback |
|---|---|
| Model | alternative model、frozen model version、rule-based response、draft-only mode |
| RAG source | authoritative manual search、last-known-good index、source rollback |
| Tool gateway | read-only degrade、manual action queue、tool-scope isolation |
| Identity service | cached entitlement for low-risk read、deny high-risk action、break-glass with review |
| Human queue | priority triage、overflow team、risk-based SLA、temporary autonomy downgrade |
| Evidence stack | local critical-event buffer、append-only export、replay from source systems |
真正的 resilience 不是“每个项目有应急方案”，而是 portfolio 层知道哪些 fallback 会同时被多个项目争用。
3.4 Governance cadence
组合级治理需要固定节奏，也需要事件触发。
| Cadence | 内容 |
|---|---|
| Weekly | incident、KRI breach、capacity、model/vendor changes |
| Monthly | concentration heatmap、fallback readiness、shared control effectiveness |
| Quarterly | portfolio risk acceptance、vendor exit drill、dependency stress test |
| Event-driven | model update、vendor incident、policy source change、regulatory change |
管理层需要看的不是每个项目的 demo，而是哪些 AI 能力已经成为关键基础设施，哪些依赖没有替代方案，哪些风险被多个产品共同放大，哪些控制能证明有效。
4. 证据与控制
4.1 Portfolio controls
| Control | 作用 |
|---|---|
| Concentration limits | 限制单一模型/供应商/平台承载过多 high-risk use cases |
| Blast-radius segmentation | 按业务域、风险等级、客户影响隔离 |
| Fallback diversity | 不同 use case 有不同降级路径 |
| Kill switch hierarchy | global、domain、agent、tool、model 多级停用 |
| Shared service SLO | 对 tool gateway、identity、evidence stack 定义 SLO |
| Vendor exit drill | 定期演练替换模型、供应商或托管平台 |
| Dependency review board | 评审新增 use case 对组合风险的影响 |
| Incident propagation analysis | 事故后查询受影响 use cases 和 shared nodes |
| Release impact assessment | 模型、policy、RAG、tool 变化前评估组合影响 |
4.2 Portfolio KRIs
| KRI | 为什么重要 |
|---|---|
| % high-risk use cases on same model | 模型集中度 |
| % use cases without fallback | 韧性缺口 |
| number of shared critical dependencies | 系统性依赖数量 |
| evidence completeness by dependency | 审计黑洞 |
| vendor incident exposure | 第三方风险 |
| kill-switch coverage | 可控性 |
| review queue utilization | 人类监督可持续性 |
| policy source freshness breach | 知识源风险 |
| cross-use-case incident count | 相关失败 |
| model release exposure | 供应商更新影响面 |
4.3 Evidence for portfolio governance
Portfolio governance 需要能查询：
| 查询 | 用途 |
|---|---|
| 哪些 high-risk use cases 依赖同一模型版本 | 评估 correlated drift |
| 某个政策源错误影响哪些 Agent 输出 | 快速 containment |
| 哪些 Agent 使用同一 tool gateway 写入客户状态 | 评估 action-layer blast radius |
| 哪些流程共用同一审核队列且 SLA 接近上限 | 预防 human oversight failure |
| 某次供应商事故期间有哪些 run 发生 | 事故影响评估 |
| 哪些 use cases 没有可验证 fallback | 韧性整改 |
没有这类 portfolio evidence，治理会退化成项目汇报，而不是企业架构级风险管理。
5. 金融零售与 AI 产品场景
5.1 Shared model risk
客服、贷款、AML、投诉都接入同一个模型。供应商更新模型后，可能同时出现：客服拒答率变化、贷款政策解释风格变化、AML narrative 漏掉某类 red flag、投诉回复语气不符合品牌或监管要求。
控制重点包括 model release impact assessment、按 use case canary、高风险流程 freeze window、关键流程的 model diversity，以及对供应商变更的事件触发评审。
5.2 Shared policy source risk
财富顾问助手和投诉 Agent 共用政策库。政策库 ingestion 出错后，客户可能收到过期披露，投诉回复引用旧政策，advisor meeting note 误导客户或顾问。
控制重点包括 source authority registry、freshness SLO、ingestion validation、last-known-good index、affected-use-case query。
5.3 Human review queue overload
多个 Agent 都把异常升级到同一个中心审核队列。营销活动、监管变化或系统故障导致 case 激增后，高风险贷款例外可能延迟、投诉 SLA 超时、AML alert 积压。
控制重点包括 queue capacity model、priority policy、overflow team、risk-based SLA、temporary autonomy downgrade。人类监督本身也是共享依赖，不能假设无限可用。
5.4 Evidence stack concentration
所有 AI use cases 都把 trace 和 evidence 写入同一个 evidence lake。该管道故障时，AI 仍然可能继续对外服务，但审计、事故复盘、模型验证和监管响应会同时失明。
控制重点包括 critical event replication、local buffering、evidence completeness KRI、high-risk action evidence gate，以及 evidence outage 时的自动降级策略。
6. 反模式
| 反模式 | 问题 |
|---|---|
| 每个 use case 独立过评审 | 看不到共享模型、供应商、工具、队列和证据栈造成的相关失败 |
| 把 AI 平台能力都视为效率资产 | 忽略共享能力一旦失效就是共享风险 |
| 所有场景默认接同一个最佳模型 | 模型漂移或供应商事故会同步影响多个高风险流程 |
| Fallback 全写成人工处理 | 人工队列本身可能是最脆弱的共享瓶颈 |
| 没有 blast-radius map | 事故发生后无法快速判断受影响 use cases |
| Kill switch 只有全局关停 | 无法按模型、工具、业务域、风险等级精准降级 |
| Evidence stack 不纳入韧性设计 | AI 还能运行，但组织失去审计和复盘能力 |
| 新项目接入共享能力无需组合评审 | portfolio 风险随项目数量隐性累积 |
7. 最终心智模型
AI portfolio 不是一组项目，而是一张共享依赖网络。单个 use case 的风险来自任务本身，组合级风险来自依赖集中、失败相关、降级争用和证据缺失。企业级 AI 架构必须把模型、供应商、RAG、工具、身份、人工队列和 evidence 都视为可失效、可过载、可漂移的关键基础设施。
可以用一个压缩公式理解：
Portfolio AI risk
= use-case risk
+ shared dependency concentration
+ correlated failure paths
+ fallback contention
+ evidence blind spots
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。