DORA/CRD 叠加 — 模型供应商是关键 ICT 第三方，韧性接 durable execution

日期: 2026-09-16 阶段: Phase 3 - AML 调查 Copilot 标签: #dora #ict-third-party #operational-resilience #concentration-risk

核心问题

Day 92-93 把 AI Act Articles 9-15 映射完了。但 AML Copilot 跑在受监管的金融机构里——它头顶的合规不只 AI Act 一部法。今天叠加 DORA（数字运营韧性法案，2025-01-17 生效） 和 CRD（资本要求指令） 这两条金融专属的运营韧性约束。

EBA 2025-11-20 的 AI Act 映射报告说了一句关键的话：AI Act 不是全新的合规宇宙，而是叠在 CRR/CRD/DORA 等既有框架上的一层——监管要的是把 AI 要求「woven into」现有治理，而非另起炉灶。今天回答三个问题：

1. DORA 对 AI 系统要什么？ 核心是「运营韧性」——系统出故障/被攻击/供应商挂掉时，金融机构的关键功能不能断。映射到本项目，这正是 P2 建的 durable execution（断点续跑）+ 降级策略。
2. 一个反直觉的定性：调用 Claude/GPT 的 LLM 供应商，在 DORA 眼里是什么？今天证明——模型供应商是 DORA 意义上的「ICT 第三方」，且头部云/模型商已被列为「关键 ICT 第三方（CTPP）」受直接监管。这把「换个模型 API」从工程决策升级为合规事件。
3. 集中度风险怎么破？ 接 P2 gateway 的多供应商路由。

关键内容

A. DORA 五支柱 → 自家组件，运营韧性接 durable execution

DORA（Regulation EU 2022/2554，2025-01-17 全面适用）建立金融业 ICT 风险的统一框架，五支柱：

支柱③的核心是运营韧性——系统遭遇 ICT 故障（模型 API 超时、限流、宕机）时，金融机构的关键功能（如 SAR 调查流程）不能因此中断或丢失状态。这逐字对应 P2 的 durable execution（src/agent/durable/checkpointMachine.ts，Day 36）：

  DORA 运营韧性场景         durable execution 响应
  ────────────────         ─────────────────────────
  模型 API 调用中途超时  ──► checkpoint 已落，从最近恢复点续跑
                              （不重头跑、不丢已完成证据汇集步骤）
  标签页/进程崩溃        ──► thread_id 寻址 checkpoint，断点续跑
  供应商限流降级        ──► 降级策略：切备用模型/降级到规则基线

降级策略（graceful degradation）是 DORA 的精髓：主模型不可用时，系统不是「报错停摆」，而是降级到「规则基线兜底 + 标记待人工」。本项目 P1 的规则基线（evalBaseline，recall 1.0 的三类规则）正是这个降级落点——LLM 挂了，规则引擎仍能跑出可解释的告警，SAR 调查不至于全停。

反直觉洞察①（durable execution 不只是工程优雅，是 DORA 的运营韧性义务）：直觉把「断点续跑」当作提升用户体验的工程优化（崩了不用重来）。但 DORA 支柱③把它法定化——金融机构的关键功能必须能扛住 ICT 中断。AML 调查若因模型 API 超时而丢失「已汇集的证据 + 已比对的 typology」状态，分析师得重头来过，这在 DORA 下是运营韧性缺陷。所以 Day 36 的 durable execution 不是炫技，是合规承重组件——它和 Day 49 的 HITL（合规承重墙）、Day 92 的 trace（Article 12 留痕）一样，是「好工程恰好满足硬合规」的又一例。

B. 反直觉定性：模型供应商是 DORA 的「关键 ICT 第三方」

这是今天最反直觉的一点。DORA 支柱④管「ICT 第三方风险」。问题：调用 claude-opus-4-8 的 Anthropic、调用 GPT 的 OpenAI、跑在 AWS Bedrock 上的部署——这些供应商在 DORA 眼里算什么？

答案（ESAs / EBA 口径）：AI/LLM 供应商若其产品被受监管金融实体用于关键/重要功能，就是 DORA 意义上的「ICT 第三方服务提供商」；且头部供应商可被进一步定为「关键 ICT 第三方（Critical Third-Party Provider, CTPP）」，受 ESAs 直接监管。

铁证：2025-11 ESAs 公布首批 19 家 CTPP 名单，含 AWS、Google Cloud、Microsoft、Oracle、SAP、Deutsche Telekom（ESAs / IBM 2025-11）。AML Copilot 若部署在 AWS Bedrock 上跑 Claude，它的底层基础设施供应商已经在 CTPP 名单里、已受直接监管。

反直觉洞察②（「换个模型 API」是合规事件，不是工程决策）：工程师把「从 Claude 切到 GPT」「从直连切到 Bedrock」当作一行配置改动。但 DORA 把模型/云供应商定性为 ICT 第三方——每次引入或切换供应商，都要做第三方风险评估、合同条款审查（审计权、数据驻留、退出策略）、并纳入第三方依赖映射。更反直觉的是：你以为在选「哪个模型更聪明」，DORA 关心的是「这家供应商挂了，你的关键功能能不能撑住、能不能切走」。Day 47 的 Pareto 路由（按成本/质量选模型）在 DORA 视角下多了一个维度——供应商不是 fungible 的算力，是受监管的第三方依赖。这把模型选型从「技术选型」抬到「第三方风险治理」。

DORA 对 ICT 第三方合同的硬要求（须写进与供应商的合同）：服务级别、审计权、安全要求、数据存储/处理地点、退出策略（exit strategy）——金融机构必须能在供应商失效时「拔插头换人」。对 AML Copilot：不能把 prompt/编排逻辑深度耦合到单一供应商的私有特性（如某家独有的 tool-calling 格式），否则退出策略落空。

C. 集中度风险 → gateway 多供应商路由

DORA 支柱④还点名集中度风险（concentration risk）：金融机构不能把关键功能过度集中在单一或少数供应商。EBA：「map third-party ICT dependencies and ensure critical functions are not too heavily concentrated with a single provider」。

映射到本项目——这正是 P2 gateway（src/agent/gateway/）多供应商路由的合规依据。Day 46 的 gateway 路由原本是为「成本/质量 Pareto 最优」（Day 47），DORA 给它叠加第二个动机：供应商冗余。

  集中度风险缓解（伪代码，规划）：
  function routeWithResilience(req):
    primary   = pickByPareto(req)              // Day 47 成本/质量最优
    fallbacks = otherProviders(exclude=primary) // 供应商冗余（DORA 支柱④）
    if primary.healthy:  return primary
    else:                return failover(fallbacks)  // 降级不停摆
  // 约束叠加：先满足数据驻留（Day 93）→ 在合规端点集内取 Pareto → 留 fallback

这把三个约束叠进同一个 gateway：数据驻留（Day 93 AI Act/GDPR）+ Pareto 最优（Day 47 成本）+ 供应商冗余（Day 94 DORA 集中度）。三者优先级：驻留是硬门槛（先过滤）→ 冗余是韧性底线（必留 fallback）→ Pareto 是在前两者约束内的优化目标。

D. EBA「woven into」：AI Act 是叠加层不是平行系统

EBA 2025-11-20 报告的关键定性：AI Act 不是全新合规宇宙，而是叠在 CRR/CRD/DORA/PSD2/EBA Guidelines 上的一层。具体到信用评分 AI——银行不需要从零搭新质量管理框架，而是扩展既有的模型治理、信用风险流程、DORA-ICT 框架，把 AI 要求（数据治理、模型监控、可解释性）显式锚进去。

EBA 还说：暂未发现需新增或修订 EBA Guidelines 的迫切需要，将通过后续行动推动共同监管方法。

反直觉洞察③（合规不是 N 部法各建一套，是同一套工程满足多部法的交集）：直觉以为 AI Act + DORA + SR 11-7 + GDPR 要建四套合规系统。EBA 的「woven into」点破了这点——它们大量重叠：AI Act Article 12 的「lifetime 日志」、DORA 支柱②的「事件可检测可上报」、SR 11-7 的「持续监控」，都落到同一个 trace/observability 底座；AI Act Article 9 的「持续风险管理」、DORA 支柱①的「ICT 风险管理」、CRD 的「模型风险」，都落到同一个 failureTaxonomy + eval 闭环。本项目不该按法律条文建 N 套并行系统，而该建一套覆盖多法交集的工程底座，再用映射表（Day 92 的 aiActMapping）证明它满足每部法的对应条款。这才是「合规架构」该有的形态——映射，不是堆叠。

设计要点/决策表

对本项目的落地

• 新建 src/aml/compliance/doraMapping.ts：导出 doraPillarMapping() → PillarMap[]，每条 { pillar: 1|2|3|4|5, requirement, component, status }，把 A 节五支柱映射表结构化。CI 断言「支柱③运营韧性 → checkpointMachine status='implemented'」「支柱④第三方 → gateway 多供应商 status='partial'」。与 Day 92/93 的 aiActMapping.ts 并列，共同构成「合规映射层」。
• gateway 韧性路由：在 src/agent/gateway/ 规划 routeWithResilience()，叠加数据驻留过滤（Day 93）+ 供应商冗余 fallback（本日）+ Pareto 优化（Day 47）。当前 P3 仅定义路由策略与约束优先级注释，实际 failover 在 gateway 健康检查接入时实现（计划语气，未实现）。
• 降级到规则基线：在编排层（src/agent/orchestrator）规划降级路径——LLM 调用连续失败/超时 → 降级到 src/aml/evalBaseline.ts 的规则引擎跑出可解释告警 + 标记「降级模式，待人工」。这是 DORA graceful degradation 的落点，复用 P1 规则基线。
• 第三方依赖映射文档：规划 src/aml/compliance/ictDependencies.ts——登记 { provider, service, criticality, isCTPP: boolean, exitStrategy, dataRegion }，硬编码当前依赖（如 Anthropic/AWS Bedrock，标注是否在 19 家 CTPP 名单）。这是 DORA 支柱④的依赖映射证据。
• 诚实标注：doraMapping.ts 头注明确——本模块是 DORA 义务的架构映射非法律意见；DORA 自 2025-01-17 适用，19 家 CTPP 名单为 2025-11 ESAs 首批（后续会扩充，须重核）；本项目当前为前端教学装置，真实 DORA 合规需后端 + 真实供应商合同 + 退出策略演练，本日仅落映射与路由策略；EBA「woven into」口径引自 2025-11-20 报告（非正式监管指引，EBA 明确声明非 supervisory expectation）。

参考资料

1. EBA — AI Act implications for the EU banking sector（2025-11-20）：AI Act 非全新合规宇宙，叠在 CRR/CRD/DORA/PSD2/EBA Guidelines 上；银行扩展既有模型治理/信用风险/DORA-ICT 框架，把 AI 要求 woven into，非另搭平行系统；暂无新增 EBA Guidelines 迫切需要（EBA 声明此非 supervisory expectation/法律意见）(2025-11)
2. ESAs / IBM — DORA & Critical ICT Third-Party Providers：DORA 2025-01-17 全面适用；2025-11 ESAs 公布首批 19 家 CTPP 含 AWS/Google Cloud/Microsoft/Oracle/SAP/Deutsche Telekom；AI/LLM 供应商被受监管实体用于关键功能即属 ICT 第三方，头部可定为 CTPP 受 ESAs 直接监管 (2025-11)
3. PwC / Nemko — DORA 五支柱：ICT 风险管理/事件报告/数字韧性测试/第三方风险/信息共享；第三方合同须含审计权、数据地点、退出策略；集中度风险须映射依赖、避免单一供应商过度集中 (2026)
4. 本仓库 src/agent/durable/checkpointMachine.ts（断点续跑=运营韧性）、src/agent/gateway/（多供应商路由=集中度缓解）、src/aml/evalBaseline.ts（规则基线=降级兜底）、src/agent/orchestrator（降级路径）、Day 36 durable / Day 46-47 gateway+Pareto (2026-06)

SOTA 检查 (2026-06-11)

• DORA 在 2026-06 是 live 且执行中：2025-01-17 全面适用已一年半，监管进入执行阶段；2025-11 首批 19 家 CTPP 名单是关键里程碑——头部云/SaaS 已受 ESAs 直接监管，名单后续会扩充（须周期性重核 AML 依赖的供应商是否被新增）。
• 「AI 供应商=ICT 第三方」是 2025-2026 监管共识：ESAs/EBA 口径明确——LLM/AI 供应商被金融实体用于关键功能即落 DORA 第三方框架；本笔记反直觉洞察②（换 API=合规事件）是这一共识的工程落地，且是 live 踩坑点（多数团队仍把模型选型当纯技术决策，忽略第三方风险治理）。
• EBA「woven into」口径稳健但非正式指引：2025-11-20 报告明确声明「不代表 supervisory expectation 或法律意见，随 AI Office/AI Board 指南演进可能再澄清」——本笔记引用时已标注此免责性质，避免把 EBA mapping 当成终局监管立场。AI Act 与 DORA/CRD 的精确边界仍随后续 RTS/指南细化。
• CRD6 + DORA 内部治理指引在制定中：EBA 2025 就 CRD6/DORA 下的内部治理指引征询意见（Simmons & Simmons 2025）——内部治理、模型风险与 ICT 风险的整合口径仍在收敛，本项目「一套底座满足多法交集」的架构方向与此一致，但具体条款映射须随指引定稿回填。
• 待跟踪：19 家 CTPP 名单扩充（AML 依赖供应商是否被纳入）；EBA CRD6/DORA 内部治理指引定稿；DORA 威胁导向渗透测试（TLPT）对 AI 系统的具体适用口径（影响 MCPTox 红队是否需对齐 TLPT 标准）；本项目接后端后的真实退出策略演练。