AI 底层逻辑 / 经典论文
AI Control Library：证据图谱
AI Control Library 是把风险要求翻译成稳定、可复用、可测试的控制语言；Assurance Evidence Graph 是把这些控制和具体产品、数据、模型、流程、测试、日志、例外和审批连接起来。前者解决“应该控制什么”，后者解决“如何证明控制真实运行”。
182 行ai-foundations/papers/82-ai-control-library-assurance-evidence-graph.md
AI Control Library / Assurance Evidence Graph 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_CONTROL_LIBRARY_ASSURANCE_EVIDENCE_GRAPH_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 AI 风险治理、度量、管理和改进语言组织控制目标（AI RMF 1.0 发布 2023-01；2025-03 更新覆盖生成式 AI 与第三方模型风险） |
| NIST SP 800-53 Rev. 5 | https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final | 参考安全与隐私控制目录、控制族和控制增强思想（Rev. 5 发布 2020-09） |
| NIST Cybersecurity Framework 2.0 | https://www.nist.gov/cyberframework | 参考 Identify / Protect / Detect / Respond / Recover 的运营闭环（CSF 2.0 发布 2024-02） |
| ISO/IEC 42001 | https://www.iso.org/standard/81230.html | 参考 AI management system、绩效评价、内部审核和持续改进（ISO/IEC 42001:2023 发布 2023-12） |
核心导读
AI Control Library 是把风险要求翻译成稳定、可复用、可测试的控制语言；Assurance Evidence Graph 是把这些控制和具体产品、数据、模型、流程、测试、日志、例外和审批连接起来。前者解决“应该控制什么”，后者解决“如何证明控制真实运行”。
金融零售场景中的 AI 控制不能停留在 checklist。监管、审计、模型风险、网络安全、隐私和业务责任最终都会追问同一件事：某个 AI 输出为什么可以被信任，出现异常时谁能发现、谁能停止、谁能解释、谁能修复。
问题定义
传统控制清单在 AI 系统中容易失效，因为 AI 风险不是单点风险：
- 同一个模型在不同业务上下文中风险等级不同。
- RAG 的答案质量取决于知识源、检索策略、权限、提示词、重排、生成和后处理。
- 工具调用会产生外部副作用，控制必须覆盖权限、幂等、补偿和审计。
- 模型版本、prompt 版本、数据版本和政策版本持续变化，发布时合格不代表运行中合格。
- 监管问询不会满足于“我们有流程”，而会要求看到证据链。
控制库和证据图要共同回答：
| 问题 | 需要的机制 |
|---|---|
| 风险从哪里来 | AI use case risk mapping、threat model、impact assessment |
| 控制如何定义 | control objective、control activity、control owner、test method |
| 控制在哪里执行 | design-time gate、pipeline check、runtime guardrail、monitoring rule |
| 证据如何产生 | eval report、trace log、access log、approval record、incident record |
| 如何证明闭环 | finding、remediation、exception、retest、management review |
核心原理与方法
控制库需要从“控制项列表”升级为“控制对象模型”。
| 控制对象 | 含义 |
|---|---|
| Control Objective | 要达成的风险控制目标，例如防止越权知识访问 |
| Control Activity | 实际活动，例如按用户权限过滤检索 corpus |
| Control Test | 如何验证活动有效，例如权限矩阵测试、红队用例 |
| Evidence | 支撑控制有效性的证据，例如测试结果、日志样本、配置快照 |
| Control Owner | 对控制设计和运行负责的角色或团队 |
| Frequency | 每次发布、每日、每月、事件触发或持续监控 |
| Exception | 偏离控制时的批准、有效期、补偿控制和关闭条件 |
AI 控制库通常覆盖八类控制：
| 控制族 | 典型控制 |
|---|---|
| Governance | inventory、risk tiering、approval、policy mapping |
| Data & Knowledge | provenance、quality、access control、retention、PII minimization |
| Model & Prompt | model selection、prompt versioning、model change review |
| Evaluation | baseline eval、regression eval、bias/toxicity/safety tests |
| Runtime Guardrails | content filter、tool permission、rate limit、human escalation |
| Observability | trace、metrics、logs、drift、cost、override reason |
| Incident & Recovery | kill switch、rollback、customer remediation、postmortem |
| Third Party | vendor evidence、contract controls、SLA、exit testing |
Assurance Evidence Graph 则把这些控制变成可查询的图：
Use Case
-> Risk Scenario
-> Control Objective
-> Control Activity
-> Test Procedure
-> Evidence Object
-> Finding / Exception
-> Remediation
-> Release Decision
系统与架构模型
一个可运营的 AI control architecture 可以分为五层：
Policy & Obligation Layer
-> Control Library Layer
-> Product Integration Layer
-> Evidence Generation Layer
-> Assurance Query Layer
| 层 | 架构职责 |
|---|---|
| Policy & Obligation | 映射法规、内部政策、风险 appetite、行业标准 |
| Control Library | 维护控制目标、活动、测试方法、owner、频率和适用条件 |
| Product Integration | 把控制嵌入需求、架构、CI/CD、模型网关、RAG、tool runtime |
| Evidence Generation | 自动或半自动生成 eval、trace、approval、configuration、incident evidence |
| Assurance Query | 支持审计、监管、管理评审和发布决策的证据查询 |
证据对象需要标准化，否则后续无法形成图：
| Evidence Object | 必备字段 |
|---|---|
| Eval Report | use case、model/prompt/data version、test suite、result、threshold、failure class |
| Runtime Trace | user/session、retrieved sources、prompt version、tool calls、output、guardrail actions |
| Control Test | control id、test method、sample、result、tester、date、finding |
| Approval Record | decision、approver、risk acceptance、expiry、conditions |
| Incident Record | trigger、impact、root cause、containment、remediation、retest |
关键机制与取舍
控制设计要处理几个实际取舍。
| 取舍 | 判断原则 |
|---|---|
| 统一控制库 vs 场景定制 | 控制语言统一，阈值、样本、测试用例按风险等级和业务影响定制 |
| 自动控制 vs 人工复核 | 高频、可形式化控制自动化；价值判断、客户影响和例外批准保留人工责任 |
| 发布前控制 vs 运行时控制 | 离线 eval 只能证明 baseline，客户交互和工具调用必须有 runtime guardrails |
| 证据完整性 vs 运营成本 | 高风险场景保留细粒度 trace，低风险场景可抽样但必须保留决策链 |
| 控制强度 vs 产品体验 | 过强拦截会降低可用性，过弱控制会放大风险；阈值必须用 failure data 调整 |
控制库不应成为审批阻塞器，而应成为产品化的 guardrail 服务。团队在设计 use case 时能直接选择适用控制，平台能自动生成部分证据，治理团队关注例外、趋势和高风险变化。
证据与控制
控制必须有 claim-argument-evidence 结构：
| Claim | Argument | Evidence |
|---|---|---|
| 该客服 AI 不会回答超出授权范围的问题 | 检索层按身份过滤，生成层拒绝无来源内容 | 权限测试、RAG trace、拒答 eval、配置快照 |
| 该模型变更不会降低投诉处理质量 | 使用固定回归集和线上抽样比较 | eval report、A/B quality review、override trend |
| 工具调用不会造成不可逆错误 | 高影响操作需人工确认，失败有补偿流程 | tool policy、trace log、HITL approval、compensation record |
| 客户影响事件可被发现和处理 | 有监控阈值、升级规则和响应 playbook | alert history、incident ticket、postmortem、retest |
典型 control-evidence matrix：
| Control ID | Control Objective | Activity | Evidence | Frequency | Release Impact |
|---|---|---|---|---|---|
| AI-DATA-01 | 防止越权检索 | corpus access filter 与用户 entitlement 绑定 | access test、retrieval trace | 每次发布+持续监控 | 阻断高风险发布 |
| AI-EVAL-02 | 保持回答质量 | 固定 eval suite 和业务失败分类 | eval report、failure trend | 每次模型/prompt 变更 | 未达阈值不得扩大流量 |
| AI-OPS-03 | 可快速停止异常功能 | kill switch 和 rollback runbook | 演练记录、配置快照 | 季度演练 | 未演练不得进入客户渠道 |
| AI-TPRM-04 | 管理供应商模型变更 | 变更通知、影响评估、回归测试 | vendor notice、impact assessment | 供应商变更触发 | 变更未评估不得升级 |
AI 产品与金融零售场景
以客户服务 AI assistant 为例，控制库不能只写“需要人工监督”。它要落到以下系统机制：
| 风险 | 控制设计 | 证据 |
|---|---|---|
| 编造费用政策 | 只允许使用已批准知识源，答案必须引用 source id | RAG trace、source freshness report、无来源拒答测试 |
| 泄露客户信息 | 检索按客户身份和坐席权限过滤，日志脱敏 | entitlement test、PII masking test、access log |
| 错误承诺赔付 | 涉及赔付和争议处理时转人工或生成建议不自动执行 | intent classifier eval、handoff trace、override review |
| 模型更新导致质量下降 | prompt/model change 触发回归评测和小流量监控 | eval trend、canary report、incident threshold |
| 监管问询无法追溯 | 每个回答保留 trace id、来源、版本和控制结果 | evidence graph query、retention policy proof |
这里的产品取舍很具体：如果强制每个回答都引用来源，可能降低自然度；如果允许自由生成，风险会转移到投诉和监管层。成熟设计通常采用分级策略：低风险 FAQ 可直接回答，高风险费用/合约/投诉场景要求来源引用和人工接管。
反模式
- 把控制库做成静态 Excel，不能连接 use case、系统配置和运行证据。
- 控制目标写得很宏观，例如“确保公平透明”，却没有活动、测试和证据。
- 只在上线前收集证据，忽略模型、知识、prompt 和政策变更后的回归。
- 所有场景使用同一控制强度，导致低风险场景过慢、高风险场景不够严。
- 证据散落在文档、邮件、工单和日志系统中，监管问询时无法重建链路。
- 只证明控制存在，不证明控制有效。
最终心智模型
AI 控制库定义组织对 AI 风险的标准动作；证据图证明这些动作在具体产品中被执行并产生效果。真正可用的控制体系不是发布前检查表，而是一套贯穿设计、交付、运行、事件、复盘和改进的 assurance operating system。
SOTA 检查 (2026-07-01)
- 本篇「控制族 → 控制目录」的思路已被 NIST 官方产品化：NIST 于 2025-08-14 发布 SP 800-53 Control Overlays for Securing AI Systems（COSAiS）概念文件，计划为五类用例（生成式 AI 应用、预测式 AI、单 Agent 系统、多 Agent 系统、AI 开发者安全开发实践）提供基于 SP 800-53 Rev. 5 的控制叠加层。本篇 Source Anchors 用 SP 800-53 做控制目录参考的选择仍成立，且后续可直接换用 COSAiS 正式稿作为 AI 专用控制目录。
- NIST AI RMF 仍是内部风险管理操作模型的主流锚点：AI RMF 1.0（2023-01）之后，2025-03 更新覆盖生成式 AI、供应链与第三方模型评估；生成式 AI Profile（NIST AI 600-1）已单列；AI RMF 1.1 补充与 Cyber AI Profile 预计 2026 年内推进。本篇以 AI RMF 语言组织控制目标的做法未被替代。
- ISO/IEC 42001:2023（2023-12）截至 2026 年仍是唯一可认证的 AI 管理体系标准；2026 年企业主流做法是多框架并行——NIST AI RMF 做内部风险管理操作模型、ISO 42001 做面向客户的可认证治理证明、EU AI Act 做法律合规层。NIST AI Resource Center 已收录 AI RMF ↔ ISO 42001 的 72 行 crosswalk，本篇 Policy & Obligation Layer 的「多义务源映射到统一控制库」设计正对应这一实践。
- 监管时间线更新（影响控制落地节奏，不影响控制模型）：EU AI Act GPAI 义务已于 2025-08-02 生效，但 Annex III 高风险系统义务经 Digital Omnibus（2026-05 确认）推迟至 2027-12-02。证据图作为「监管问询对接层」的定位不变，金融零售高风险场景获得更长的证据体系建设窗口，但 GPAI 透明度类证据（模型来源、训练数据摘要）已是现役要求。
- 控制目录生态在 2025 年明显变密：除 NIST COSAiS 外，Cloud Security Alliance 也发布了 AI 控制框架（AI Controls Matrix，CSA 2025-09 有两者对比分析）。这印证本篇的判断——控制语言统一、阈值按风险分级定制，而不是每个团队自造 checklist。
- 不随版本过时的框架性结论：控制对象模型（Objective / Activity / Test / Evidence / Owner / Frequency / Exception）、claim-argument-evidence 结构、五层控制架构、以及「证明控制存在 ≠ 证明控制有效」的反模式判断，均为框架级内容，不依赖任何具体标准版本。落地操作层见配对篇
docs/AI_CONTROL_LIBRARY_ASSURANCE_EVIDENCE_GRAPH_PLAYBOOK.md，监管问询与董事会证据消费视角见docs/AI_REGULATORY_RESPONSE_PLAYBOOK.md与docs/AI_BOARD_AUDIT_COMMITTEE_GOVERNANCE_PACK.md，评测证据的生成机制见docs/AI_GOVERNANCE_EVALOPS_RISK_90_PLAN.md。