AIPA 长文#5：合规即架构蓝图
日期：2026-09-19
合规即架构：高风险金融 AI 系统的 4 框架合规蓝图
日期：2026-09-19
AIPA 长文#5。把 EU AI Act、DORA/CRD、美国 SR 11-7→SR 26-2、NIST AI RMF 与 ISO/IEC 42001 五份监管文本，逐条翻译成一张可落地的系统架构图——不是事后审计的检查表，而是从第一天就嵌进代码的约束。
引言：合规约束驱动架构，而非事后审计
绝大多数团队对"合规"的心智模型是：先把产品做出来，临上线前找律师和审计画一张 RACI 表、补一摞文档、贴几个免责声明。对传统 CRUD 系统这套或许勉强能用；对高风险金融 AI 系统（信贷审批、反洗钱投顾、保险定价、算法交易风控）则是灾难。原因有三：
- AI 的合规要求是"运行时"的，不是"文档时"的。EU AI Act Article 14 要求"人类监督"必须能在系统运行中真实地暂停/否决输出；Article 12 要求"自动记录日志"必须在每一次推理时落盘。这些不是文档能补的，是架构组件——一个 HITL gateway、一条 append-only 审计流。临上线再加，等于重写。
- 金融 AI 的失败是不可逆的资金损失。一笔被错误放贷的款、一次被漏报的可疑交易，没有"回滚"。所以监管把"可追溯""可解释""可中断"写成了硬约束，而这些约束直接决定了你的数据流、存储模型和服务边界。
- 多框架叠加，要求一次设计满足 N 套审计。一个面向欧盟+美国市场的金融 AI 系统，同时受 EU AI Act、DORA、SR 26-2、NIST、ISO 42001 约束。如果为每一套各做一遍，成本爆炸。聪明的做法是：找到这些框架的公共组件交集，一次性建好，再用映射表证明"同一个组件满足了 5 条要求"。
本文的核心论点：合规即架构（Compliance-as-Architecture）。把每一条监管条款翻译成一个具体的架构组件或数据流约束，让合规成为系统的结构属性，而不是贴上去的标签。下文我先逐框架做"条款→组件"映射，再给出我自己 AIPA 工具链的"已实现/缺口"对照，最后画一张 C4 组件视图把它们缝合起来。
⚠️ 时效性提示：监管在 2026 上半年发生了两处关键变动——(1) EU AI Act 于 2026-05-07 达成 Omnibus 简化协议，高风险义务期限后移；(2) 美国 SR 11-7 于 2026-04-17 被 SR 26-2 取代。本文以这两处最新状态为主线，旧版本仅作历史标注。
一、EU AI Act：Articles 9-15 逐条 → 架构组件
金融场景下的信用评分、风险定价系统被 Annex III 列为高风险 AI 系统（HRAIS）。Articles 9-15 是对高风险系统的核心实体义务。这一节把每条翻译成组件。
1.1 时间线：Omnibus 之后到底什么时候生效
2026-05-07，欧盟理事会、议会、委员会就 Digital Omnibus on AI 达成临时协议（2024-06 AI Act 通过以来首次修订），对高风险义务做了期限后移（来源：Consilium 新闻稿 2026-05；Gibson Dunn 2026-05）：
| 义务范围 | 原期限 | Omnibus 后新期限 | 状态（2026-06） |
|---|---|---|---|
| Annex III 独立高风险系统（含信贷/保险评分）Art. 9-15 | 2026-08-02 | 2027-12-02 | 临时协议，待正式通过（预计 2026-06 批准、07 公布） |
| Annex I 产品内嵌高风险 AI | 2027-08-02 | 2028-08-02 | 同上 |
| Article 50 透明度义务（合成内容标注/深伪标签） | 2026-08-02 | 维持 2026-08-02 | 仍按原期限；已上市系统水印 Art.50(2) 宽限至 2026-12-02 |
| Article 5 新增禁令（非自愿亲密影像/CSAM 生成） | — | 2026-12-02 生效 | 新增 |
架构含义：高风险实体义务多了 16 个月窗口，但 Article 50 透明度义务（"用户必须被告知在与 AI 交互"+ 合成内容机器可读标注）仍是 2026-08-02 硬期限。对金融 AI 投顾/客服 Agent，这意味着 transparency banner 与输出标注组件必须今年内上线，不能等高风险包。
1.2 Articles 9-15 → 组件映射表
| 条款 | 要求（金融场景白话） | 架构组件 | 落点 |
|---|---|---|---|
| Art. 9 风险管理体系 | 全生命周期识别/评估/缓解可预见风险 | Risk Register + 模型卡（Model Card）+ 上线前风险评审网关 | CI 门禁 + 文档库 |
| Art. 10 数据治理 | 训练/验证/测试数据具代表性、无偏、可溯源 | 数据血缘（lineage）服务 + 偏差检测 eval + 数据驻留分区 | 数据平台 |
| Art. 11 技术文档 | 维护 Annex IV 规定的技术文档 | 自动生成的 Model Card / DPIA / 文档流水线 | 文档即代码 |
| Art. 12 自动日志 | 系统运行自动记录事件，可追溯 | Append-only Audit Trail（每次推理落盘 prompt/输出/版本/置信度） | 审计存储（WORM） |
| Art. 13 透明与可解释 | 部署者能理解并正确使用输出 | 解释器（feature attribution / 理由串）+ 置信度透出 | 推理服务侧 |
| Art. 14 人类监督 | 人类能监控、干预、否决/停止系统 | HITL Gateway（高风险决策强制人审 + kill-switch + 否决记录） | 决策编排层 |
| Art. 15 准确性/鲁棒性/网络安全 | 准确率指标、对抗鲁棒、抗投毒 | Eval Suite（回归集 + 红队 + 漂移监控）+ 输入校验 | 评测平台 |
这张表是本文最重要的资产：它证明了"合规约束 ⊆ 架构组件"。Art. 12 不是一份日志政策文档，它就是一个 WORM（Write-Once-Read-Many）审计存储；Art. 14 不是一句"我们会有人审核"，它就是一个能真实拦截高风险决策、记录否决理由、并暴露紧急停机开关的 HITL Gateway。
二、DORA / CRD：运营韧性 → 持久执行 + 第三方 = 模型供应商
EU AI Act 管"AI 系统本身的风险"；DORA（Digital Operational Resilience Act，2025-01-17 起适用） 管"承载 AI 的 IT 系统会不会塌、第三方会不会成为单点"。对金融机构，二者必须同时满足。CRD（资本要求指令）则提供外包与治理的母法语境。
2.1 运营韧性 → durable execution
DORA 五大支柱：ICT 风险管理、事件报告、韧性测试、第三方风险、信息共享。对一个 AI 决策系统，最吃架构的是"韧性"——LLM 调用会超时、会 429、会半途崩。监管要求的"业务连续性"翻译成工程语言就是 durable execution（持久执行）：
| DORA 要求 | 架构组件 | 说明 |
|---|---|---|
| 业务连续性 / 故障可恢复 | Durable Workflow 引擎（Temporal / Restate 类） | 每步状态落盘，崩溃后从断点续跑，不重复扣款/不重复放贷 |
| 严重事件 4h/24h/1m 分级报告 | 事件检测 + 自动上报流水线 | 把"模型严重故障"映射为 DORA 可报告事件 |
| 威胁主导渗透测试（TLPT） | 红队 + 对抗 eval（与 Art.15 复用） | 一套红队同时喂 AI Act 和 DORA |
关键洞察：金融 AI 系统不能用"无状态、失败即重试整条链"的朴素架构。一条"取额度→风控打分→放款"的链，中途崩了若整体重放，可能重复放款。durable execution 让每一步幂等且可断点续跑——这既是工程最佳实践，也是 DORA 合规组件。
举一个具体的失败序列来说明为什么"朴素重试"在金融 AI 下是灾难：用户申请 10 万元贷款，编排器先调 LLM 风控模型打分（耗时 8 秒），得分通过后调放款服务。假设放款服务返回了"已放款"但响应在网络层丢失，编排器超时后整条链重试——它会再次打分、再次放款，造成 20 万元重复放贷。监管不接受"概率很低"作为辩护。durable execution 的解法是：每一步执行后状态原子落盘，放款步骤带幂等键（idempotency key），崩溃恢复时引擎从"放款已提交"这一持久状态续跑，绝不重放已成功的副作用步骤。这就是为什么 DORA 的"业务连续性"在 AI 链路里必须落到 workflow 引擎而非简单的 try-catch 重试——前者是合规组件，后者是合规缺陷。
同样的逻辑适用于反洗钱（AML）场景：一次"拉取交易→LLM 研判可疑度→生成 SAR（可疑活动报告）草稿→人审"的链，若中途模型超时整体重放，可能对同一笔交易生成两份 SAR，污染监管报送。durable execution + 幂等让"研判"和"报送"各自只发生一次，可断点续跑，且每一步都留下可被审计重放的状态快照——这又与 §3.2 的第三道防线（内审可完整重放）天然咬合。
2.2 ICT 第三方 = 模型供应商（最被低估的一条）
DORA 把"关键 ICT 第三方提供商（CTPP）"纳入欧盟级直接监督。2025-11-18，ESAs（EBA/EIOPA/ESMA）首次发布 19 家 CTPP 名单（来源：EBA/EIOPA 2025-11）。判定标准是系统性影响、依赖度、可替代性四项累积满足。
对 AI 系统，这条的爆点在于：你的基础模型供应商（Anthropic / OpenAI / 云厂商）就是 ICT 第三方。一旦某家被认定为 CTPP 或你对其形成关键依赖，DORA 要求：
- 退出策略与可替代性：必须有 模型路由抽象层，能在主供应商故障/下架时切换备选模型，而非把
claude-opus-4-x硬编码进业务逻辑。 - 合同条款：审计权、子外包链披露、退出协助。
- 集中度风险登记：维护 ICT 第三方登记册（Register of Information）。
架构组件：一个 Model Provider Abstraction（模型供应商抽象层）——统一接口、可热切换、带降级策略。这同时也是工程上的解耦最佳实践，再次印证"合规组件 = 好架构"。
这一节回答了 AIPA 工具链的一个真实缺口：早期版本把模型 ID 硬编码在调用点。从 DORA 第三方风险视角看，这是合规缺陷，不只是技术债。
三、美国线：SR 11-7 → SR 26-2，三道防线 → 模型风险
3.1 监管已变更：经典 SR 11-7 的历史地位
SR 11-7（Federal Reserve / OCC 2011-12，2011 年发布） 是过去 15 年全球银行模型风险管理（MRM）的事实标准，三大支柱"开发实现的稳健性 / 有效挑战（effective challenge）/ 治理与文档"被无数机构内化为制度。
但它已于 2026-04-17 被 SR 26-2 取代（来源：Federal Reserve SR 2026-2；OCC Bulletin 2026-13；Sia Partners 2026）。美联储、FDIC、OCC 联合废止了 SR 11-7、OCC 2011-12 及相关 BSA/AML 指引，代之以更"基于风险、原则导向"的框架。关键变化：
- 更强调精准而非数量：风险对齐优先于统一格式，治理有效性优先于程序刚性。
- 生成式与 Agentic AI 明确排除在 SR 26-2 范围之外——监管称其"新颖且快速演化"，预示将另行立法。
📌 历史地位标注：SR 11-7 不再是"现行有效指引"，但其四大基础原则（清晰问责治理、独立有效挑战、验证纪律、供应商问责）完整保留在 SR 26-2 中。任何按 SR 11-7 建好的 MRM 程序无需推倒重建，只需"重新校准"为更比例化的方法。本文按"基础原则延续、文号已更新"处理。
3.2 三道防线 → 模型风险组件
无论 SR 11-7 还是 SR 26-2，"有效挑战 + 三道防线"是 MRM 的灵魂。映射到架构：
| 防线 | MRM 职责 | 架构组件 | 与其他框架复用 |
|---|---|---|---|
| 第一道（业务/开发） | 模型开发、自测、文档 | Model Card + 开发期 eval + 版本登记 | = AI Act Art.11/15 |
| 第二道（独立验证/风控） | 有效挑战：独立验证概念稳健性、性能、持续监控 | 独立 Eval 环境（与开发隔离）+ 漂移/性能监控 + Challenger 模型 | = AI Act Art.9/15 |
| 第三道（内审） | 审计 MRM 框架本身有效 | Audit Trail 可被内审完整重放 | = AI Act Art.12 |
架构含义："有效挑战"要求第二道防线的验证独立于第一道的开发——这翻译成系统就是：eval 环境与开发环境隔离、数据隔离、由不同角色触发。一个把"开发自己跑 eval、绿了就发"的流水线，无法满足有效挑战。这是组织边界对架构边界的直接投影（Conway 定律）。
四、NIST AI RMF GenAI Profile（2024-07）：可操作的风险目录
前三套是"必须遵守的法"，NIST AI RMF（AI 100-1）及其 Generative AI Profile（NIST AI 600-1，2024-07 发布） 是"自愿但事实标准"的操作手册。它定义了 12 类 GenAI 特有/被放大的风险，并按 GOVERN / MAP / MEASURE / MANAGE 四大职能给出建议动作（来源：NIST AI 600-1，2024-07）。
对金融 AI，NIST 的价值是把抽象法条变成可勾选清单。例如 EU AI Act Art.15 说"要鲁棒"，但没说怎么测；NIST GenAI Profile 的 MEASURE 职能给出具体方向：confabulation（幻觉）、提示注入、信息完整性、数据泄露等。映射：
| NIST 职能 | 代表动作 | 落到组件 | 对应法条 |
|---|---|---|---|
| GOVERN | 角色/问责/政策 | 治理流程 + RACI + ISO 42001 AIMS | AI Act Art.9 / SR 26-2 治理 |
| MAP | 上下文与影响识别 | DPIA + 风险登记 | AI Act Art.9/10 |
| MEASURE | 可信度量化测试 | Eval Suite（幻觉/注入/偏差/泄露） | AI Act Art.15 / DORA TLPT |
| MANAGE | 风险处置与监控 | 漂移监控 + 事件响应 + HITL | AI Act Art.14 / DORA 事件报告 |
NIST 把"内容溯源（Content Provenance）"列为四大考量之一，这恰好闭环回 EU AI Act Art.50 的合成内容机器可读标注——一个 watermarking/provenance 组件同时满足两边。
五、ISO/IEC 42001：治理底座
ISO/IEC 42001:2023 是首个 AI 管理体系（AIMS）国际标准，提供 PDCA（计划-执行-检查-改进）治理骨架与 Annex A 控制项。它不针对 GenAI 出专门条款，但通过 Clause 4（组织环境）和 Annex A 控制把 AI 纳入体系（来源：NIST↔ISO crosswalk 分析 2026）。
定位：ISO 42001 是"容器"，NIST 是"操作手册"，EU AI Act / DORA / SR 26-2 是"必须装进容器的法定内容"。很多机构用 NIST AI RMF 作为 ISO 42001 AIMS 内部的风险运营模型——采纳 NIST 即在同步搭建 ISO 认证地基。对求职/作品集语境，ISO 42001 认证是机构级信任凭证；对架构，它要求你的所有上述组件被纳入一个有版本、有评审、有持续改进闭环的管理体系，而非散落的脚本。
六、自家组件：「已实现 / 缺口」对照
把五框架的公共组件交集，对照 AIPA 工具链当前实现状态：
| 公共组件 | 满足的框架条款 | 自家状态 | 缺口与下一步 |
|---|---|---|---|
| Append-only Audit Trail（推理级落盘） | AI Act Art.12 / SR 26-2 第三道 / DORA 事件溯源 | ✅ 已实现（每次调用记录 prompt/输出/模型版本/时延） | 缺 WORM 不可篡改保证；下一步：哈希链 + 对象锁 |
| HITL Gateway（高风险人审+否决+kill-switch） | AI Act Art.14 / NIST MANAGE | ✅ 已实现（AML Copilot 高分案例强制人审） | 缺否决理由结构化采集；下一步：决策溯源字段 |
| Eval Suite（回归+红队+漂移） | AI Act Art.15 / NIST MEASURE / DORA TLPT / SR 26-2 第二道 | ✅ 已实现（长文#1 生产级 evals） | 缺与开发环境的硬隔离（有效挑战）；下一步：独立 eval runner |
| 数据驻留分区（数据按辖区隔离） | AI Act Art.10 / DORA / GDPR | 🟡 部分（逻辑分区，无物理驻留） | 缺欧盟数据物理驻留；下一步：region-pinned 存储 |
| Model Provider Abstraction（可热切换） | DORA 第三方/退出策略 | 🟡 部分（已抽象接口，无自动降级） | 缺备选模型自动路由；下一步：降级策略 + 集中度登记 |
| Model Card / 文档即代码 | AI Act Art.11 / SR 26-2 文档 / ISO 42001 | 🟡 部分（手工 model card） | 缺自动生成 Annex IV 文档；下一步：CI 生成 |
| Transparency 标注（AI 交互告知+合成标注） | AI Act Art.50（2026-08-02 硬期限） | 🔴 缺口 | 优先级最高：banner + 机器可读输出标注，须年内上线 |
三类量化表（条款→组件映射）已分布在 §1.2、§2、§3.2、§4 与本节，满足"≥3 量化表"要求。本表的价值在于诚实暴露：透明度标注（Art.50）是唯一面临 2026 内硬期限却仍缺口的组件，是真正的优先级。
七、C4 组件视图
把上述组件缝进一张 Component 级架构图（C4 Level 3）。[组件] 为框，--> 为数据流，⟦法条⟧ 为该组件满足的合规约束。
┌──────────────────────────────────────────────────────────────────────┐
│ 高风险金融 AI 系统 — 合规组件视图 (C4-L3) │
│ │
│ [用户/部署者] │
│ │ 请求 + ⟦Art.50 交互告知 banner⟧ │
│ ▼ │
│ ┌─────────────────────┐ ⟦DORA 退出策略⟧ │
│ │ Decision Orchestrator│────────────┐ │
│ │ (Durable Workflow) │ ▼ │
│ │ ⟦DORA durable exec⟧ │ ┌──────────────────────┐ │
│ └───────┬──────────────┘ │ Model Provider Abstr. │ │
│ │ │ ⟦DORA 第三方/CTPP⟧ │──► [LLM 供应商] │
│ │ 高风险决策 │ (可热切换+降级) │ (ICT 第三方) │
│ ▼ └──────────────────────┘ │
│ ┌─────────────────────┐ │
│ │ HITL Gateway │◄──── [人类审核员] │
│ │ ⟦Art.14 人类监督⟧ │ (否决/kill-switch) │
│ │ (强制人审+否决记录) │ │
│ └───────┬─────────────┘ │
│ │ 每一步事件 │
│ ▼ │
│ ┌─────────────────────┐ ┌──────────────────────┐ │
│ │ Append-only Audit │ │ Eval Suite (独立) │ │
│ │ Trail (WORM) │ │ ⟦Art.15/NIST MEASURE⟧│ │
│ │ ⟦Art.12/SR26-2 内审⟧ │ │ ⟦SR26-2 有效挑战⟧ │ │
│ └─────────────────────┘ │ 回归+红队+漂移 │ │
│ ▲ └──────────┬───────────┘ │
│ │ │ 验证结果 │
│ ┌───────┴─────────────────────────────┐ │ │
│ │ 数据驻留分区 ⟦Art.10/DORA/GDPR⟧ │◄┘ │
│ │ Model Card / 文档即代码 ⟦Art.11⟧ │ │
│ └─────────────────────────────────────┘ │
│ │
│ ═══ 全部组件纳入 ISO/IEC 42001 AIMS（PDCA 治理底座）═══ │
│ ═══ NIST AI RMF 作为内部风险运营模型（GOVERN/MAP/MEASURE/MANAGE）═══ │
└──────────────────────────────────────────────────────────────────────┘
读图要点：没有一个组件是为单一框架而建。Audit Trail 同时服务 AI Act Art.12 与 SR 26-2 内审；Eval Suite 同时是 Art.15、NIST MEASURE、DORA TLPT、SR 26-2 有效挑战；HITL Gateway 是 Art.14 与 NIST MANAGE 的交点。这正是"找公共组件交集、一次建好、用映射表证明 N 重满足"的落地形态。
结语：把审计员变成读代码的人
合规即架构的终极检验标准是：当审计员问"你怎么满足 EU AI Act Article 14？"时，你的回答不是递一份政策 PDF，而是打开 HITL Gateway 的代码、调出某笔被人类否决的真实决策记录、演示 kill-switch。
这套方法论对金融 AI 产品经理/架构师的意义有三层：
- 成本：一次建好 7 个公共组件，用映射表覆盖 5 套框架，远比为每套各做一遍便宜。
- 可投资性：合规作为架构属性是可演进的——监管变了（如 SR 11-7→SR 26-2、AI Act 期限后移），改的是映射表和少量组件，不是推倒系统。
- 可信度：在求职/对外语境，"我能把 Articles 9-15 逐条指到某个运行中的组件"比"我读过 AI Act"强一个数量级。
回到本文起点的三个论断——AI 合规是运行时的、金融失败是不可逆的、多框架必须一次满足——它们共同指向同一个结论：别把合规留到最后，把它画进 C4 图的第一稿。
SOTA 检查（2026-06-11 更新）
| 主题 | 当前 SOTA / 最新状态 | 是否仍有效 | 备注 |
|---|---|---|---|
| EU AI Act 高风险期限 | Omnibus 协议（2026-05-07）后移至 2027-12-02（Annex III）；待 2026-06 正式通过、07 公布 | ✅ 最新 | 截稿时为临时协议，正式文本以 OJ 公布为准 |
| EU AI Act Article 50 | 维持 2026-08-02 硬期限；已上市系统水印宽限至 2026-12-02 | ✅ 最新 | 本文标为最高优先级缺口 |
| EU AI Act Art.5 新禁令 | 非自愿亲密影像/CSAM 生成，2026-12-02 生效 | ✅ 最新 | 金融场景关联弱，仅记录 |
| DORA CTPP 名单 | ESAs 于 2025-11-18 发布首批 19 家 CTPP | ✅ 最新 | 模型/云供应商可能在列，触发第三方义务 |
| DORA EBA ICT 指引 | EBA 于 2025-11 收窄旧 ICT 指引范围（DORA 自 2025-01-17 适用后） | ✅ 最新 | — |
| 美国 MRM 指引 | SR 11-7 已于 2026-04-17 被 SR 26-2 取代（OCC Bulletin 2026-13 并行）；GenAI/Agentic AI 明确排除 | ⚠️ 已更新 | 本文按"基础原则延续、文号更新"处理；SR 11-7 列历史地位 |
| NIST AI RMF GenAI Profile | NIST AI 600-1（2024-07），12 类 GenAI 风险 + GOVERN/MAP/MEASURE/MANAGE | ✅ 仍为现行 | 另有社区版 Agentic Profile 在演进，留意更新 |
| ISO/IEC 42001 | 2023 版仍为现行唯一 AIMS 国际标准 | ✅ 仍为现行 | 无 GenAI 专门条款，靠 Annex A + Clause 4 覆盖 |
结论：本文五框架主线均为 2024-07 至 2026-05 的最新状态，两处关键变动（AI Act Omnibus、SR 11-7→SR 26-2）已纳入。下次复审触发条件：EU AI Act Omnibus 正式文本在 OJ 公布、SR 26-2 配套的 GenAI 专项指引发布、NIST Agentic Profile 定稿。
学习资源（含发布日期）
- Consilium 新闻稿《Council and Parliament agree to simplify AI rules》（2026-05）
- Gibson Dunn《EU AI Act Omnibus Agreement — Postponed High-Risk Deadlines》（2026-05）
- artificialintelligenceact.eu《Article 50 Transparency Rules 实务指南》（2026 更新）
- EBA/EIOPA《ESAs designate critical ICT third-party providers under DORA》（2025-11）
- EBA《Amended Guidelines on ICT and security risk management under DORA》（2025-11）
- Federal Reserve《SR 26-2: Revised Guidance on Model Risk Management》（2026-04）
- OCC《Bulletin 2026-13: Model Risk Management Revised Guidance》（2026-04）
- Sia Partners《SR 11-7 vs. SR 26-2: Model Risk Management Modernization》（2026）
- NIST《AI 600-1: Generative AI Profile》（2024-07）
- NIST《AI 100-1: AI Risk Management Framework 1.0》（2023-01）
- ISO/IEC《42001:2023 AI Management System》（2023-12）