AI Portfolio Systemic Risk / Dependency Architecture 解读

面向对象: Enterprise Architect / AI Portfolio Lead / AI Product Architect / Risk Product Lead / Senior BA。 核心问题: 单个 AI use case 的风险可接受, 不代表整个 AI portfolio 的风险可接受。多个产品共用同一个模型、供应商、RAG 知识源、身份服务、human review queue 或 evidence stack 时, 会产生组合级依赖和相关失败。 学习目标: 建立 AI dependency graph、concentration risk heatmap、blast-radius map、fallback diversity、portfolio KRI 和 systemic incident response 的架构能力。

---

Source Anchors

一句话:

Portfolio risk starts where shared AI dependencies make independent failures correlated.

---

1. 为什么项目级 AI 风险评审不够

项目评审常问:

• 这个 use case 风险等级是什么。
• 这个模型是否通过验证。
• 这个 prompt 是否测试。
• 这个 agent 是否有 human oversight。

组合级风险问:

• 有多少关键流程依赖同一个模型供应商。
• 同一个政策知识库错误会影响多少产品。
• 同一个 embedding/index bug 会污染多少 RAG 系统。
• 同一个 human review queue 是否会被多个 agent 同时压垮。
• 同一个 tool gateway 故障会导致多少业务流程停止。
• 供应商模型更新会不会同时改变多个产品行为。

项目级看是绿色, portfolio 级可能是红色。

---

2. Dependency Taxonomy

---

3. Dependency Graph Method

用图而不是表管理:

Use Case -> AI Capability -> Model -> Data/Knowledge -> Tools -> Control -> Human Queue -> Vendor -> Evidence

每个 node 记录:

• owner。
• criticality。
• number of dependent use cases。
• risk tier mix。
• fallback option。
• exit difficulty。
• incident history。
• SLO/KRI。
• review cadence。

每条 edge 记录:

• dependency type。
• strength。
• data sensitivity。
• action authority。
• failure propagation path。

---

4. Concentration Risk Heatmap

高风险不是因为组件坏, 而是因为它坏了会同时影响很多高价值流程。

---

5. 金融零售案例

5.1 Shared model risk

客服、贷款、AML、投诉都接同一个模型。供应商更新模型后:

• 客服拒答率变化。
• 贷款政策解释风格变化。
• AML narrative 漏掉某类 red flag。
• 投诉处理语气不符合品牌/监管要求。

控制:

• model release impact assessment。
• canary by use case。
• high-risk use case freeze window。
• model diversity for critical workflows。

5.2 Shared policy source risk

财富顾问助手和投诉 agent 共用政策库。政策库 ingestion 出错:

• 客户收到过期披露。
• 投诉回复引用旧政策。
• advisor meeting note 误导。

控制:

• source authority registry。
• freshness SLO。
• ingestion validation。
• affected-use-case query。

5.3 Human review queue overload

多个 agent 都把异常升级到同一个中心审核队列。营销活动后 case 激增:

• 高风险贷款例外延迟。
• 投诉 SLA 超时。
• AML alert 积压。

控制:

• queue capacity model。
• priority policy。
• degraded autonomy level。
• surge staffing playbook。

---

6. Controls

---

7. Portfolio KRIs

---

8. AI Dependency Register

# AI Dependency Register

Dependency name:
Dependency type:
Owner:
Criticality:
Dependent use cases:
Highest risk tier:
Data sensitivity:
Action authority:
Vendor / platform:
Fallback:
Exit difficulty:
SLO/KRI:
Incident history:
Current risk rating:
Risk acceptance owner:
Review date:

---

9. Portfolio Governance Cadence

管理层需要看的不是每个项目的 demo, 而是:

• 哪些 AI 能力已经成为关键基础设施。
• 哪些依赖没有替代方案。
• 哪些风险被多个产品共同放大。
• 哪些控制能证明有效。

---

10. 面试表达

30 秒版本:

我会把 AI 风险分成 use-case risk 和 portfolio dependency risk。单个 use case 通过评审不代表组合安全。我要画 dependency graph, 看多个 AI 产品是否共用同一模型、供应商、RAG 源、工具网关、身份服务、human review queue 和 evidence stack, 然后管理 concentration、blast radius、fallback、kill switch 和 portfolio KRIs。

2 分钟版本:

在金融零售里, AI 很快会从 POC 变成共享能力。客服、贷款、AML、投诉可能共用同一个模型、政策知识库、tool gateway 和审核队列。单看每个项目都合理, 但同一供应商更新、同一知识源错误、同一审核队列过载, 会导致相关失败。 我的做法是建立 AI dependency register 和 graph, 每个 use case 映射到 model、data/knowledge、tool、policy、identity、human queue、vendor 和 evidence stack。然后做 concentration heatmap 和 blast-radius map, 识别高风险共享依赖。 控制上包括 concentration limit、fallback diversity、domain segmentation、kill switch hierarchy、vendor exit drill、shared service SLO 和 incident propagation analysis。这样 AI portfolio 不只是项目集合, 而是可治理的企业架构。

---

11. Portfolio Exercise

选 5 个 AI use cases:

1. 客服 copilot。
2. AML assistant。
3. lending policy RAG。
4. complaint response agent。
5. wealth advisor assistant。

为它们画:

• dependency graph。
• concentration heatmap。
• blast-radius map。
• fallback matrix。
• portfolio KRI dashboard。

最后写一页 memo:

Which shared AI dependency is most dangerous, why, and what architecture decision reduces blast radius?