AI Regulatory Architecture / EU AI Act / NIST AI RMF / ISO 42001 解读

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_REGULATORY_ARCHITECTURE_EU_AI_ACT_NIST_ISO42001_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

Source Anchors

核心导读

AI Regulatory Architecture 是把法规义务、风险框架和管理体系翻译成 inventory、risk tier、controls、release gates、runtime monitoring 和 evidence graph。EU AI Act、NIST AI RMF 和 ISO/IEC 42001 的共同价值，不是让企业多写合规文档，而是让 AI 产品从设计开始就具备分类、控制、监督、证据和持续改进能力。

金融零售 AI 通常同时受到 AI 法规、金融监管、消费者保护、隐私、网络安全和模型风险管理影响。监管架构要处理的是义务叠加，而不是单一法规映射。

问题定义

AI 合规失败经常来自架构缺口：

• 没有完整 AI inventory，无法知道哪些系统属于 AI、哪些影响客户权益。
• 风险分级只在文档中，未改变评测、人工监督、日志和 release gate。
• provider、deployer、供应商、业务 owner 和技术 owner 责任不清。
• 控制和证据散落在工单、文档、日志和邮件中，无法响应监管问询。
• 法规变化后无法定位受影响的 use case、模型、数据和供应商。

监管架构要回答：

核心原理与方法

监管架构可用三层框架组织：

EU AI Act 提供 risk-based obligations，NIST AI RMF 提供 govern/map/measure/manage 的风险管理语言，ISO 42001 提供 AI management system 的组织机制。三者可以互补：

方法步骤：

1. 建立 AI system inventory，记录业务目的、用户、影响、模型、数据、供应商和 owner。
2. 对每个 use case 做 applicability 和 risk tiering。
3. 将义务映射为 control profile。
4. 将 control profile 嵌入 architecture pattern、release gate 和 runtime monitor。
5. 建立 evidence graph 和 management review 节奏。
6. 对法规、模型、数据、供应商和业务变化做 impact assessment。

系统与架构模型

Regulatory architecture control plane：

Regulatory Obligation Library
  -> AI System Inventory
  -> Applicability / Risk Tiering
  -> Control Profile
  -> Product Lifecycle Gates
  -> Runtime Monitoring
  -> Evidence Graph
  -> Regulatory Change Radar

核心对象：

关键机制与取舍

风险分级应影响架构：

证据与控制

Obligation-control-evidence map 示例：

证据图查询应能回答：

• 某个客户交互 AI 适用哪些法规和内部政策。
• 最近一次模型变更触发了哪些测试和审批。
• 某个高风险控制的 owner、测试频率和失败记录是什么。
• 某个法规变更影响哪些 use case、供应商和数据源。
• 某个 incident 之后进行了哪些补救和控制强化。

AI 产品与金融零售场景

以客户信贷解释 AI 为例：

真实取舍：解释越自然，越可能引入未授权承诺或额外理由；解释越模板化，客户体验可能下降。监管架构的解决方式是分层解释：标准原因采用批准语言，复杂案例提供人工升级，同时保留完整 evidence trace。

适用时间线（截至 2026-07-01，Omnibus 临时协议口径）

监管主题笔记必须能回答「哪个义务什么时候必须就位」。EU AI Act 关键适用日期：

• 本表是 regulatory change radar 的第一个用例：任何日期变化都应触发受影响 use case 的 impact assessment。
• 库内带日期深读：docs/aipa/day49-article50-compliance.md、docs/AIPA_LONGFORM_5_COMPLIANCE.md。
• 注意旧时间线「高风险 2026-08 生效」已作废（AIPA 黑名单项），引用时以本表口径为准。

反模式

• 把法规映射做成静态表，不连接系统 inventory、控制和证据。
• 风险分级不改变架构和 release gate。
• 用人工监督作为万能控制，但监督者没有信息、时间或权限。
• 只关注模型输出合规，忽略数据、工具调用、供应商和运行监控。
• 法规变化靠人工转发邮件，没有影响分析和 remediation backlog。
• 证据在监管问询时临时拼接，无法证明运行有效性。

最终心智模型

AI Regulatory Architecture 是把外部义务内化为企业 AI 控制面。法规告诉组织必须负责什么，风险框架告诉组织如何识别和管理风险，管理体系告诉组织如何持续运行。成熟设计让每个 AI 系统从 inventory 到运行监控都能被分类、控制、证明和改进。

---

SOTA 检查 (2026-07-01)

• EU AI Act：时间线以 Digital Omnibus 2026-05-07 临时协议口径为准（见上方「适用时间线」专节）；本篇写作时点后的变化以 docs/aipa/day49-article50-compliance.md 的复查为准。
• NIST：AI RMF 1.0（2023-01）+ Generative AI Profile（NIST AI 600-1，2024-07）仍为现行版本。
• ISO：ISO/IEC 42001（2023-12）仍为现行 AIMS 标准；配套的 ISO/IEC 42005（AI 影响评估，2025-05）等标准自 2025 年起陆续发布，做管理体系落地时应一并纳入。
• 本篇框架论断（obligations→controls→evidence 三层、risk tiering 驱动架构）不依赖具体法规版本，仍然成立。Source Anchors 访问日期 2026-07-01。