摘要
10-16/01 画了义务地图、02 落地了模型卡证据，本文把「证据」固化成可寻证的治理闭环：AI 合规不是一次性项目，而是持续承诺。核心是四件事——不可变审计日志（集中化、加密、留存≥5 年、标准化 schema）、HITL 事件记录（含人类覆盖原因）、模型卡即审计摘要，以及把文档当代码（doc-as-code，CI/CD 自动生成）。再用 NIST AI RMF vs EU AI Act 对比表选型，把 10-15 生产平台的可观测性直接复用为合规证据，形成「能跑、能看住、能审计」的完整形态。
一句话结论：合规证据链的终局不是「写一份漂亮的文档」，而是「让每一次模型变更、每一次人类覆盖、每一条监控告警都自动落进不可变日志，并随代码提交自动生成可机读文档」——把 10-15 的生产可观测性从工程资产升级为法律资产。
1. 合规不是一次性项目，而是持续承诺
EU AI Act 的执行逻辑里最容易被误解的一点是：很多人把合规当成「上线前做一次评估、拿一张证书」，然后束之高阁。但法案的设计是持续性的——高风险义务生效后，供应商要维持技术文件更新、部署方要做基本权利影响评估、所有方要跑市场后置监控（Article 72）。
Rends.ai 把合规拆成「治理组织 → 风险分类 → 审计追踪 → 人类监督 → 监控响应 → 文档留存 → 监管对接」七步闭环，并指出：非合规罚款最高可达全球年营收 6%。这不是一次性成本，而是持续运营的 overhead。
心态转变：把合规当「待办清单」会漏，把它当「生产线」才不会。下面四件事，是把生产线跑起来的关键零件。
2. 不可变审计日志基础设施
审计追踪（audit trail）是合规闭环的「黑匣子」。它的设计原则：
| 原则 | 落地要点 | 反模式 |
|---|---|---|
| 集中化 | 所有 AI 系统的日志进统一管道，而非散落各服务 | 各团队各存一份，对账无门 |
| 不可变（immutable） | 写后只读（WORM）或哈希链，禁止篡改/删除 | 日志可被运维随意改 |
| 加密 | 传输与静态加密，PII 脱敏 | 明文落盘 |
| 留存 ≥5 年（高风险） | 高于一般业务日志周期 | 按 90 天滚动删除 |
| 标准化 schema | 统一字段：who/what/when/why/version | 各系统字段各异，无法检索 |
标准化的日志 schema 至少要 capture：操作主体、被操作的模型/版本、时间戳、输入/输出摘要（脱敏）、决策结果、人类覆盖标记与原因、关联模型卡版本哈希。
3. HITL 事件记录：人类覆盖要记「原因」
EU AI Act 与 NIST AI RMF 都强调有意义的人类监督（human oversight）。审计方最关心的不是「有没有人审」，而是「人审的时候发生了什么」。
金融审计领域的实践值得借鉴：当人类覆盖（override）AI 决策时，事件必须记录覆盖原因。这在信贷审批、可疑交易上报等场景尤其关键——审计方能据此判断覆盖是否恰当、是否暴露模型缺陷。
{"event_id":"ovr-2026-10-16-8841","model_version":"kuaidi-llm-pro@27","card_hash":"sha256:9f2c...","ai_decision":"reject_credit","human_override":true,"override_reason":"申请人提供纸质收入证明，模型未接入该数据源","operator":"reviewer-052","timestamp":"2026-10-16T09:41:22Z"}经验：覆盖率异常（≈100% 通过或≈0% 采纳）本身就是信号。10-10/01 讲过的「审批表演反模式」在这里同样成立——覆盖日志要能暴露「人在假装审」。
4. 模型卡即审计摘要，数据字典补溯源
前面（10-16/02）讲模型卡是技术底稿，这里它是审计摘要：审计方拿到模型卡，能在几分钟内理解系统能力、风险画像、数据使用策略。
但模型卡之外，金融企业还会维护数据字典（data dictionary）——定义 AI 系统用到的所有数据元素：来源、格式、质量检查。数据字典是验证数据完整性与追溯数据血缘的必备件，尤其当「模型失败往往源于数据而非模型本身」时。
组合拳：模型卡（能力/风险/评测）+ 数据字典（数据血缘/质量）+ 不可变日志（运行时事实），三件套覆盖「设计—数据—运行」全链证据。
5. NIST AI RMF vs EU AI Act：怎么选
两者常被并列提及，但性质不同。一张对比表说清边界：
| 维度 | EU AI Act | NIST AI RMF |
|---|---|---|
| 性质 | 法律（欧盟强制） | 自愿框架（美国） |
| 适用范围 | 欧盟高风险 AI 系统 | 所有 AI 系统，自愿采用 |
| 核心要求 | 风险评估、数据治理、人类监督、技术文件 | 风险映射/度量/管理（Map/Measure/Manage） |
| 审计证据 | 技术文件、日志、符合性评估 | 风险评估、缓解计划 |
| 优势 | 有法律约束力、要求明确 | 灵活、广泛认可 |
| 劣势 | 对小企业复杂昂贵 | 无强制力、缺执法 |
| 最适合 | 欧盟大型机构 | 美国机构/最佳实践 |
实务：在欧盟有业务的团队用 Act 满足法律证据，用 RMF 把风险管理流程跑顺。两套框架可互补，不必二选一。
6. 第三方审计与符合性评估（notified body）
高风险系统（尤其是 Annex I 嵌入产品的）需要公告机构（notified body）做符合性评估。即使不强制，定期内/外部审计也是治理成熟度信号：
- 内部审计：定期审 AI 治理与合规程序。
- 外部审计：独立审计方评估合规成熟度。
- 符合性评估：高风险系统由 notified body 验证（法案适用时）。
注意：没有任何测试方能「认证合规」——他们只提供证据。法律合规最终由律师或 notified body 判定（呼应 10-16/01 的 Article 50 测试边界）。
7. 把文档当代码：doc-as-code
2026 年企业 AI 文档标准的最大改变是：文档必须被视为代码。具体做法：
- 文档与模型的训练脚本、部署配置同仓存储。
- 模型卡、数据字典通过 CI/CD在每次提交/retrain 时自动生成或更新。
- 文档进入版本控制，带审计轨迹与数据溯源追踪。
这样文档不再「落后于模型迭代」，而是与代码同频。SpecsWriter 的建议组件与频率：
| 文档组件 | 受众 | 更新频率 | 状态 |
|---|---|---|---|
| 模型卡 | 监管/用户 | 每次 retrain | 强制 |
| API 规范 | 开发者 | 每次提交 | 建议 |
| 数据溯源报告 | 审计方 | 季度 | 强制 |
| 安全影响报告 | CISO/法务 | 半年 | 强制 |
8. 与 10-15 生产平台贯通：可观测性即证据
这是本篇最关键的「复用」论点：10-15 构建的生产平台，其可观测性数据天然就是合规证据。
- 10-15/02 的 L1/L2/L3 监控（延迟/成本/质量/漂移）→ 直接对应 Annex IV 2(d) 的「性能监控证据」与 Article 72 市场后置监控计划。
- 10-15/01 的金丝雀门禁（质量信号）→ 是「变更前验证程序」的运行时证据。
- 10-15/03 的 A/B 归因（效果数据）→ 支撑「特定人群性能/歧视性影响」的分层指标。
- 10-11/01 的 CI 红队扫描→ 是 Annex IV 2(d)「对抗性测试指标」的直接产出。
# .github/workflows/doc-as-code.yml —— 每次 retrain 自动生成模型卡 + 审计锚定name:doc-as-codeon:workflow_run:workflows:["retrain-pipeline"]types:[completed]jobs:gen-card:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4-run:python tools/gen_model_card.py--version ${{github.run_number}}-run:|# 把模型卡哈希写入不可变日志，作为合规锚点 python tools/anchor_audit_log.py cards/kuaidi-llm-pro-v*.yaml-uses:actions/upload-artifact@v4with:name:model-cardpath:cards/# anchor_audit_log.py —— 把文档变更写入不可变审计日志（哈希链）importhashlib,json,time,os CHAIN_FILE="audit/chain.jsonl"defanchor(path):withopen(path,"rb")asf:digest=hashlib.sha256(f.read()).hexdigest()prev=""ifos.path.exists(CHAIN_FILE):withopen(CHAIN_FILE)asf:last=list(f)[-1]prev=json.loads(last)["hash"]record={"ts":time.time(),"doc":os.path.basename(path),"hash":digest,"prev":prev,# 哈希链，篡改即断}withopen(CHAIN_FILE,"a")asf:f.write(json.dumps(record)+"\n")returnrecord9. 常见问题 FAQ
Q1：合规做一次评估拿证书就行了吗？
A：不行。法案是持续性的：技术文件要更新、部署方要做影响评估、所有方跑市场后置监控。把它当生产线而非待办清单。
Q2：审计日志要留存多久？
A：高风险 AI 至少 5 年；模型卡/技术文件依 Article 18 留存 10 年。且是「可随时取证」的不可变留存，不是单纯备份。
Q3：人类覆盖只要记「覆盖了」就行？
A：不够，要记覆盖原因。审计方据此判断覆盖是否恰当、是否暴露模型缺陷；覆盖率异常（≈100% 通过）本身也是风险信号。
Q4：NIST AI RMF 和 EU AI Act 选哪个？
A：不二选一。Act 是欧盟法律强制，RMF 是美国自愿框架；在欧盟有业务用 Act 满足法律，用 RMF 跑顺风险管理流程，互补。
Q5：第三方机构能「认证我们合规」吗？
A：不能。测试方只提供证据，法律合规由律师或 notified body 判定。别把「过了测试」等同于「合规」。
Q6：doc-as-code 会不会增加研发负担？
A：短期有成本，长期降本。文档与代码同仓、CI 自动生成，避免「文档永远落后于模型」的债；且合规审计时直接导出，省下突击补文档的人力。
Q7：10-15 的生产监控怎么变成合规证据？
A：L1/L2/L3 监控对应 Annex IV 性能监控与 Article 72 后置监控；金丝雀门禁是变更验证证据；A/B 归因支撑分层歧视性影响指标；CI 红队是对抗性测试证据。同一套埋点，两种读法。
Q8：数据字典和数据集卡重复吗？
A：互补不重复。数据集卡讲「训练数据的来源与处理」，数据字典讲「系统运行时用到的所有数据元素的来源/格式/质量检查」，后者更偏线上血缘与完整性验证。
Q9：小企业怎么低成本起步？
A：先做 Article 50 透明度（告知+水印，已生效），再用 doc-as-code 自动攒模型卡草稿，跑 NIST AI RMF 的 Map/Measure/Manage 流程。高风险义务 2027 才硬性落地，现在攒证据最划算。
10. 参考资料
- Rends.ai,EU AI Act Compliance for AI Agents: Building Governance Programs and Audit Trails, 2026（七步闭环、不可变日志、HITL、留存≥5 年、符合性评估、罚款 6% 营收）
- Financial Audit Expert,Financial AI Compliance Audit Strategies 2026, 2026（模型卡+数据字典+HITL 原因、NIST AI RMF vs EU AI Act 对比表、IBM Watson OpenScale/Fiddler/Arthur）
- SpecsWriter,Enterprise AI Documentation Standards for 2026, 2026（doc-as-code、文档组件与更新频率表）
- NIST,AI Risk Management Framework (AI RMF 1.0), 2023（Map/Measure/Manage/Govern）
- Regulation (EU) 2026/1744（Digital Omnibus on AI）, Official Journal 2026-07-24
- 本专栏，企业级 LLM 应用上线与灰度发布, 2026-10-15
- 本专栏，LLM 应用线上可观测性, 2026-10-15
- 本专栏，Agent 安全红队常态化, 2026-10-11
