AI Control Library：证据图谱
一句话:
AI Control Library / Assurance Evidence Graph 解读
面向对象: AI Governance Lead / Enterprise Architect / Risk Product Manager / Senior BA / Audit Liaison / AI Platform Owner。 核心问题: AI 控制如果只是 checklist, 容易变成上线前打勾。高风险 AI 需要的是 control library + assurance evidence graph: 每个风险、控制目标、控制活动、测试、证据、owner、复核节奏和上线门禁都能追踪。 学习目标: 将 control objective、control activity、test evidence、assurance case、claim-argument-evidence、PRD/ADR/eval/control matrix 和监管问询连接起来。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 AI 风险治理、度量、管理和改进语言组织控制目标 |
| NIST SP 800-53 Rev. 5 | https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final | 参考安全与隐私控制目录、控制族和控制增强思想 |
| NIST Cybersecurity Framework 2.0 | https://www.nist.gov/cyberframework | 参考 Identify / Protect / Detect / Respond / Recover 的运营闭环 |
| ISO/IEC 42001 | https://www.iso.org/standard/81230.html | 参考 AI management system、绩效评价、内部审核和持续改进 |
一句话:
AI Control Library 是控制语言的标准化; Assurance Evidence Graph 是证明这些控制在具体 AI 产品中真实有效的证据链。
1. 为什么 AI 控制不能只靠 Checklist
Checklist 能提醒团队不要漏项, 但不能证明:
- 控制是否覆盖了真实风险。
- 控制是否在 runtime 生效。
- 控制是否被测试过。
- 控制 owner 是否明确。
- 证据是否可追溯到版本和场景。
- 例外是否被批准并有到期日。
- 上线后是否继续监控。
- 审计/监管问题能否快速回答。
AI 风险还会随时间变化:
- 模型升级。
- prompt 改动。
- 知识源更新。
- 工具权限扩展。
- 用户行为变化。
- 监管解释变化。
- 数据分布漂移。
因此控制必须从静态 checklist 升级为:
control objective
-> control activity
-> implementation
-> test
-> evidence
-> owner
-> review cadence
-> monitoring
-> exception
-> improvement
2. Control Library Taxonomy
| Control Domain | 控制目标 | 示例控制 |
|---|---|---|
| Governance | 明确责任、风险分层和审批 | AI inventory、risk tier、RACI、release gate |
| Data | 数据合法、可用、可追溯、可删除 | lineage、quality SLO、PII redaction、retention |
| Knowledge / RAG | 知识源权威、最新、可引用、权限正确 | source registry、freshness check、permission filter |
| Model | 模型适配任务、版本可控、性能可测 | model card、eval threshold、model route approval |
| Prompt / Config | prompt 可版本化、可评估、可回滚 | prompt registry、change control、prompt eval |
| Agent / Tool | 工具权限最小化、副作用可控 | tool allowlist、approval、idempotency、rollback |
| Security / Privacy | 防止泄露、攻击和越权 | DLP、prompt injection tests、secrets handling |
| Human Oversight | 人工复核有效且有容量 | review queue、override reason、calibration |
| Eval / Monitoring | 质量、风险、成本和漂移被监控 | eval dashboard、KRI/SLO、alert runbook |
| Incident | 能暂停、降级、响应和复盘 | kill switch、incident severity、postmortem |
| Vendor | 第三方风险可管理 | due diligence、contract clauses、exit plan |
| Adoption | 用户使用方式安全且有效 | training、feedback、misuse monitoring |
Control library 的每个控制都要有:
- control id。
- control objective。
- applicable risk tier。
- implementation pattern。
- required evidence。
- owner。
- test frequency。
- exception process。
3. Assurance Evidence Graph
图谱结构:
Claim
-> Risk
-> Control objective
-> Control activity
-> Implementation artifact
-> Test
-> Evidence
-> Owner
-> Review cadence
-> Residual risk decision
示例 claim:
客户可见信贷解释 AI 不会生成未经批准的拒贷原因, 并且每次解释都能追溯到政策、数据和人工复核证据。
Evidence graph:
| Node | 示例 |
|---|---|
| Claim | 信贷解释 AI grounded and compliant |
| Risk | hallucinated reason、adverse action inconsistency、fair lending concern |
| Control objective | 输出必须基于 approved reason codes 和政策来源 |
| Control activity | controlled template、RAG citation、human approval for high-risk cases |
| Implementation | policy RAG、reason-code service、approval workflow |
| Test | golden set、red-team、policy contradiction tests |
| Evidence | eval report、trace sample、approval log、source version |
| Owner | Product, Risk, Compliance, Platform |
| Review cadence | monthly monitoring, quarterly control review |
| Residual risk | accepted with HITL and monitoring |
这比“有人工复核”更强, 因为它能证明人工复核覆盖了什么风险、看什么证据、留下什么记录。
4. Release Assurance Case
不同阶段需要不同证据深度。
| Stage | Assurance Question | Evidence |
|---|---|---|
| Discovery | 这个风险是否可控 | risk pre-screen、data readiness、control hypothesis |
| Pilot | 控制是否在受控环境有效 | pilot eval、human review result、trace samples |
| Release | 控制是否满足上线门禁 | release evidence bundle、sign-off、rollback plan |
| Scale | 控制是否能跨业务线/地区扩展 | control coverage、capacity, exception trends |
| Operate | 控制是否持续有效 | monitoring dashboard、incident/postmortem、review log |
Assurance case 结构:
Top claim:
This AI system is safe and fit for release within defined scope.
Arguments:
data is governed
model behavior is evaluated
tool actions are controlled
human oversight is effective
monitoring and incident response are operational
Evidence:
data lineage
eval report
control test
approval logs
dashboard
runbook
postmortem
5. Product / Architecture Integration
| Artifact | 连接到 Evidence Graph |
|---|---|
| PRD | risk tier、user impact、acceptance criteria、guardrails |
| Requirements-to-eval | eval cases、thresholds、monitoring gate |
| ADR | architecture decision、trade-off、residual risk、reversal trigger |
| BPMN/DMN | workflow node、decision rule、handoff、control point |
| Control matrix | risk -> control objective -> activity -> evidence |
| System card | scope、limitations、monitoring、known risks |
| Audit binder | final evidence package |
| Incident postmortem | control failure and corrective action |
BA/PM 的价值在于把这些 artifact 连接起来。 架构师的价值在于让控制不是文档, 而是进入 runtime、logging、release 和 monitoring。
6. Financial Retail Case: Customer-Facing AI Assistant
场景: 银行客服 AI 回答账户费用、争议处理、信贷申请状态和一般政策问题。
关键 claim:
- AI 不会越界提供投资、法律或信贷决策建议。
- AI 使用的政策来源是最新且有权限的。
- 高风险或不确定问题会转人工。
- 客户可纠错、投诉和申诉。
- 所有客户可见回答可追踪。
Evidence graph 摘要:
| Claim | Control Objective | Control Activity | Evidence |
|---|---|---|---|
| 不越界建议 | advice boundary enforced | intent classifier、approved response templates | red-team report、policy breach monitor |
| 来源可信 | answer grounded in approved sources | source registry、citation、freshness SLO | source version log、RAG eval |
| 高风险转人工 | uncertainty and risk escalated | confidence threshold、handoff queue | queue SLA、handoff audit |
| 可纠错申诉 | customer recovery path exists | correction button、appeal workflow | case records、appeal upheld rate |
| 可追踪 | every answer has trace | trace id、model/prompt/source version | trace samples、audit export |
这套图谱可以直接支持:
- 产品上线评审。
- 内审抽查。
- 监管问询。
- 事故复盘。
- 模型/知识源升级评估。
7. Artifact Templates
Control Catalog
| Control ID | Domain | Objective | Applies To | Activity | Evidence | Owner | Frequency |
|---|---|---|---|---|---|---|---|
| AI-RAG-001 | Knowledge | 来源权威且最新 | customer-facing RAG | source registry + freshness check | source log, freshness report | Knowledge Owner | monthly |
Evidence Graph Table
| Claim | Risk | Control Objective | Activity | Test | Evidence | Owner | Review |
|---|---|---|---|---|---|---|---|
| claim | risk | objective | control | test | evidence link | owner | cadence |
Regulator Q&A Map
| Question | Evidence Node | Owner | Response |
|---|---|---|---|
| 这个 AI 如何避免错误政策解释 | RAG eval、source registry、freshness report | Product + Knowledge Owner | 说明控制与监控 |
8. ADR Draft
| 项目 | 内容 |
|---|---|
| 决策 | 对 customer-facing high-risk AI 建立 control library 和 assurance evidence graph, 作为 release/scale gate 的必备工件 |
| 背景 | 静态 checklist 无法证明控制真实覆盖风险并持续有效 |
| 替代方案 | 上线前人工 checklist、单独 audit binder、只依赖模型 eval |
| 选择理由 | evidence graph 能把 claim、risk、control、test、evidence 和 owner 连接, 支持监管/审计/事故复盘 |
| 影响 | 需要 control owner、evidence repository、trace schema、review cadence 和 exception process |
| 反转条件 | 低风险内部工具可采用轻量版 control matrix, 但高风险场景不能取消 evidence graph |
9. 面试表达
30 秒版本
AI 控制不能只靠 checklist, 因为高风险 AI 需要证明控制真实覆盖风险并在运行中有效。我会建立 control library, 定义每个控制目标、控制活动、证据、owner 和复核频率; 再用 assurance evidence graph 把 claim、risk、control、test、evidence 和 residual risk decision 串起来。
2 分钟版本
我会先从系统的 top claims 开始, 例如“客户可见 AI 不会越界建议, 且回答可追溯”。然后拆出风险、控制目标、控制活动、实现工件、测试、证据和 owner。PRD 里定义用户影响和 guardrails, eval contract 定义测试和阈值, ADR 记录架构取舍, runtime trace 记录版本和行为, audit binder 汇总证据。 这样遇到内审或监管问询时, 不只是说“我们有控制”, 而是能展示控制为什么存在、覆盖哪个风险、如何测试、何时复核、上线后如何监控。
CRO / Chief Architect 版本
对 CRO 来说, evidence graph 是残余风险可接受性的证据链。对 Chief Architect 来说, 它是把控制前移到架构和 runtime 的方法。成熟 AI governance 不应该靠最后一轮审批, 而应该让控制目标、技术实现、评估、日志、监控和证据在产品生命周期中持续连接。