AI Act 映射 I — Articles 9-12 落到 audit log / model registry / 数据血缘

日期: 2026-09-14 阶段: Phase 3 - AML 调查 Copilot 标签: #eu-ai-act #high-risk #risk-management #data-governance

核心问题

Day 49 把 Article 50（透明义务）精读到条款级，结论是：AML Copilot 的 SAR 文本因「非公众发布 + HITL 担责」基本落进豁免。但 Article 50 只是 AI Act 的透明度章，是相对轻的一档。真正重的是第三章第二节「高风险 AI 系统的要求」（Articles 9-15）——一旦 AML Copilot 被归为高风险（Annex III 涉「信用评估/金融服务」边界，见 D 节），就要扛 Articles 9-15 的全套义务。

今天回答两个问题：

1. Articles 9-12 各要什么？ 这四条是「过程性义务」——风险管理系统（9）、数据治理（10）、技术文档（11）、记录留存（12）。直觉以为这是「写一堆合规文档」的纸面活，今天证明它们每一条都精确映射到本项目已经在建的工程组件——risk management → failureTaxonomy、data governance → 66 案金标的数据血缘、record-keeping → trace/OTel 底座。合规要求和好的工程实践同构，不是额外负担。
2. 新期限到底是哪天？今天（2026-09-14）要不要合规？ 媒体口径混乱（有说 2026-08、有说 2027-12）。今天把 Omnibus（2026-05-07 临时协议）的精确时间线钉死，并指出一个反直觉点：期限推迟到 2027-12-02，不等于今天可以不做——Articles 9-12 要求的是「贯穿全生命周期的持续过程」，临到期限前补不出来。

今天产出一张「Articles 9-12 → 架构组件」映射表，和一份「已实现/缺口」对照。

关键内容

A. Article 9 风险管理系统 → failureTaxonomy + evals 闭环

精读原文（artificialintelligenceact.eu 权威转录，持续更新）。Article 9(1)：

「A risk management system shall be established, implemented, documented and maintained in relation to high-risk AI systems.」

关键在 9(2)——它不是一次性文档，而是贯穿全生命周期的持续迭代过程：

「a continuous iterative process planned and run throughout the entire lifecycle...requiring regular systematic review and updating.」

9(2) 拆成四步，恰好是一个闭环：

反直觉洞察①（Article 9 不是文档，是 evals 闭环；合规要求和好工程同构）：直觉把「风险管理系统」想成一份 Word 文档、年审一次。但 9(2) 的关键词是 continuous iterative process throughout entire lifecycle——它要的正是「持续识别失效模式 → 测 → 缓解 → 上线后回流再识别」的工程闭环。本项目 P1 建的 failureTaxonomy（识别）+ blocking eval gate（缓解）+ judge 漂移监控（上市后），本来就是为了让 AI 可靠才建的，恰好逐项满足 Article 9。合规不是在工程之外再贴一层，而是把已有的 evals 闭环文档化、可审计化。把它当文档活的人，会在期限前手忙脚乱补一份和真实系统脱节的纸面材料——而真实风险管理早该长在 CI 里。

9(5) 还要求残余风险可接受、9(9) 要求评估对未成年人/弱势群体的不利影响——后者对 AML 的映射是：SAR 误判会冻结无辜者账户，弱势群体（低收入/移民）更易被规则误伤，这是 fairness 维度，须在 failureTaxonomy 里显式建一类「人群偏差」失效（当前 6 类未含，列入缺口）。

B. Article 10 数据治理 → 66 案金标的数据血缘

Article 10 管「训练/验证/测试数据集」。原文 10(2) 要求数据集「relevant, sufficiently representative, to the best extent possible free of errors and complete」，且要有「appropriate statistical properties」覆盖目标人群。

本项目当前不微调模型（用 prompt + RAG），但 Article 10 的精神直接套到 66 案金标 + V11 80 案合成集（P1 建）：

反直觉洞察②（不微调模型 ≠ Article 10 不适用；评测集就是「数据集」）：很多团队以为「我们只用 prompt + RAG、不训练模型，Article 10 数据治理跟我无关」。错。Article 10 管的是「用于系统的数据集」，评测集（eval set）和 RAG 知识库同样是决定系统行为的数据——一个有偏的评测集（只覆盖结构化拆分、漏掉贸易洗钱）会让你的 judge 系统性地放过整类风险。本项目的 66 案金标必须按 10(2)(f)「examine bias」做类型学覆盖审计：哪些洗钱类型学被测、哪些没测、分布是否代表真实告警分布。数据血缘（每条金标的来源 + 标注者 + 类型学标签）就是 Article 10 的合规证据。

C. Articles 11-12 技术文档 + 记录留存 → model registry + trace/OTel 底座

Article 11 技术文档：要求高风险系统在上市前备好 Annex IV 规定的技术文档，并持续更新。Annex IV 含：系统的总体描述、组件/版本、训练数据来源、评测指标、风险管理措施。映射到本项目——这正是一份 model registry（模型/prompt 版本 + 评测结果 + 数据血缘的登记表）。

Article 12 记录留存，原文 12(1)：

「High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.」

12(2) 要求日志能：识别 Article 79(1) 的风险情形 / 便利上市后监控（Article 72）/ 监控运行（Article 26(5)）。这和 P1 的 OTel GenAI trace 底座（src/aml/observability/attributeMap.ts）逐字对应——自动记录每次 LLM 调用、工具调用、检索的 span，正是 Article 12 要的「automatic recording of events over lifetime」。

  Article 11/12 要求            本项目组件（P1 已建/规划）
  ─────────────────            ──────────────────────────
  Annex IV 技术文档      ◄──►   model registry: {promptVersion, model,
   (组件/版本/评测)              evalBaseline 快照, 数据血缘}（规划）
  12(1) 自动事件日志     ◄──►   src/agent/trace + observability/
   (贯穿生命周期)                attributeMap.ts → OTel GenAI span
  12(2) 可追溯/上市后监控 ◄──►  trace 回流 + Langfuse 自托管（Day 25）

反直觉洞察③（Article 12 的「lifetime」否定了「采样日志」）：工程上常对 trace 做采样（Day 8 设计的 trace 采样，省存储）。但 Article 12 要「over the lifetime of the system」——对进入 SAR 提交链路的高风险决策，采样会丢掉恰恰最该留痕的那条。设计取舍：非合规链路可采样（省成本），但「AI 起草 → 人工复核 → 提交」的合规关键路径必须全量留痕、不可采样。这把 Day 8 的「均匀采样」改成「按合规关键性分层留存」——和 Day 49 的「合规关键路径全量 provenance」是同一条原则的两次出现。

D. 触发前提：AML Copilot 是不是高risk？新期限到底哪天

Articles 9-12 全套义务只在「高风险」时触发。AML 是否高风险取决于 Annex III 分类——Annex III(5)(b) 涉「用于评估自然人信用度/信用评分的 AI」。AML 监控不是信用评分，但若系统输出影响「金融服务获取」（如冻结账户、拒绝交易），存在被解读为高风险的边界风险。保守工程立场：按高风险准备 Articles 9-15，即便最终判定非高风险，这些组件也是好系统该有的。

Omnibus（2026-05-07 临时协议，Gibson Dunn / Hogan Lovells 2026-05）的精确时间线：

反直觉洞察④（推迟到 2027-12 ≠ 今天可不做）：Article 9 明确要「continuous iterative process throughout entire lifecycle」——这种贯穿全生命周期的过程不可能在 2027-11 临时搭出来。期限给的是「正式合规挂牌」的时间，不是「现在可以不建」的许可。本项目在 P1-P3 边建 evals/trace/数据血缘，到 2027-12 期限时这些已运行一年多、有真实历史数据，远胜临期补一份脱节的纸面材料。Omnibus 推迟的价值是「不用赶 2026-08」，不是「2027-12 前躺平」。

设计要点/决策表

对本项目的落地

• 新建 src/aml/compliance/aiActMapping.ts：导出 articleMapping() → ArticleMap[]，每条 { article: 9|10|11|12, requirement, component, status: 'implemented'|'partial'|'gap', evidence }。把本日 A-C 的映射表硬编码为可单测的结构化数据——CI 里断言「Article 12 → trace 底座 status='implemented'」「Article 9(9) 人群偏差 status='gap'」，让合规缺口在测试里可见、可追踪。
• failureTaxonomy 增类：在 src/aml/failureTaxonomy.ts 现有 6 类基础上，规划新增第 7 类「人群偏差/fairness」（Article 9(9) + 10(2)(f) 要求），对应 SAR 误判对弱势群体的不利影响。本日仅落映射与缺口标注，实际增类在 fairness 评测设计时做（计划语气，未实现）。
• model registry 规划：Article 11 技术文档对应一个 src/aml/compliance/modelRegistry.ts（规划）——登记 { promptVersion, model: 'claude-opus-4-8', evalBaselineSnapshot, dataLineage: goldCaseSources }。当前 P3 仅定义接口形状，与 evalBaseline.ts 的聚合结果对接。
• trace 分层留存：把 Day 8 的「均匀采样」决策升级为「合规关键路径（SAR 起草→复核→提交）全量、非关键链路可采样」，写进 src/agent/trace 的采样策略注释。Article 12「lifetime」是这个分层的法条依据。
• 诚实标注：aiActMapping.ts 头注明确——本模块是合规义务的架构映射，非法律意见；高风险判定（Annex III 信用/金融边界）尚无定论，按保守口径准备；Articles 9-15 义务推迟至 2027-12-02（Omnibus 2026-05-07 临时协议，最终文本待 OJ 公布，须重核）；model registry / fairness 增类为规划项，未实现。

参考资料

1. artificialintelligenceact.eu — Article 9: Risk Management System：9(1)「established, implemented, documented and maintained」；9(2)「continuous iterative process throughout the entire lifecycle」四步（识别/估计/上市后分析/缓解）；9(5) 残余风险可接受；9(9) 未成年人/弱势群体不利影响（权威转录，持续更新）
2. artificialintelligenceact.eu — Article 10: Data and Data Governance：10(2) 数据集「relevant, sufficiently representative, free of errors」；10(2)(f) examine bias；10(2)(g) 缓解偏差措施（持续更新）
3. artificialintelligenceact.eu — Article 12: Record-Keeping：12(1)「automatic recording of events (logs) over the lifetime」；12(2) 识别 Article 79(1) 风险/上市后监控（Article 72）/运行监控（Article 26(5)）（持续更新）
4. Gibson Dunn — EU AI Act Omnibus Agreement: Postponed High-Risk Deadlines：2026-05-07 三方临时协议；Annex III 独立高风险义务推迟至 2027-12-02，Annex I 嵌入产品至 2028-08-02；须 OJ 正式公布方生效，预计 2026-08-02 前（2026-05）
5. Hogan Lovells / IAPP — EU legislators agree to delay for high-risk AI rules：推迟理由为技术标准/指南未就绪，避免企业为不存在的标准受罚（2026-05）
6. 本仓库 src/aml/failureTaxonomy.ts（6 类失效，待加 fairness 类）、src/aml/observability/attributeMap.ts（OTel GenAI → Article 12）、src/aml/evalBaseline.ts、src/agent/trace（trace 底座）(2026-06)

SOTA 检查 (2026-06-11)

• Articles 9-12 条文在 2026-06 稳定：高风险要求条文（第三章第二节）自 2024-06 AI Act 通过以来未改；Omnibus（2026-05-07）改的是生效时间线而非义务内容——Articles 9-15 的实质要求不变，只是 Annex III 独立系统的合规期限推迟至 2027-12-02。
• Omnibus 最终文本未定稿（live 风险）：本笔记基于 2026-05-07 临时协议（Gibson Dunn / Hogan Lovells / IAPP 2026-05 一致口径），最终须经 OJ 正式公布方生效（预计 2026-08-02 前）。新期限 2027-12-02 在最终文本公布前仍可能微调，须在 2026-Q4 重核——这是顶层时效性硬规则要求的「禁引未定稿法条而不标状态」。
• 高风险分类口径仍是 live 争议：AML 是否落 Annex III（信用/金融服务边界）尚无监管定论；EBA/ESMA 的 AI 监管指引（衔接 DORA，见 Day 94）会影响最终判定。本项目按保守「假定高风险」准备，是有意识地宁过勿缺。
• 「合规即文档」是过时认知：2026 监管与工程共识是「Article 9 的 risk management system 是 continuous iterative process，不是年审文档」——本笔记反直觉洞察①（合规闭环和 evals 闭环同构）是这一共识的工程落地，仍是 live 的踩坑提醒（多数团队仍把它当纸面活临期补）。
• 待跟踪：Omnibus 最终文本公布与确切期限；AML 是否被明确归类 Annex III 高风险；Annex IV 技术文档的细化指南（决定 model registry 字段）；fairness 增类落地后回填 failureTaxonomy 与本笔记缺口表。