AI 扩展计划 / Playbooks
AI Control Library / Assurance Evidence Graph Playbook
这些来源作为控制库和证据图谱的设计锚点。实战中不要把它们机械转成问卷, 而要转成 control objective、control activity、test method、evidence、owner、cadence 和 gate decision。
514 行AI_CONTROL_LIBRARY_ASSURANCE_EVIDENCE_GRAPH_PLAYBOOK.md
AI Control Library / Assurance Evidence Graph Playbook
定位: 面向 AI PM / AI BA / Solutions Architect / Enterprise Architect / Risk / Compliance / Internal Audit 的 AI 控制库与证据图谱实战手册。
目标: 把 AI control objective、control activity、test evidence、assurance case、claim-argument-evidence、control-to-requirement traceability、release gate、monitoring 和监管问询材料连接成一套可运营、可审计、可复核的 evidence graph。
核心观点: AI 控制库不是一张 checklist, 而是一套能证明“哪些 AI 风险在什么边界内被哪些控制降低到可接受水平”的证据系统。
使用方式: 每个高影响 AI use case 在 pilot、release、scale 三个阶段维护一张 control-to-evidence graph, 并把关键节点同步到 PRD、ADR、eval contract、control matrix、release gate 和 audit binder。
重要说明: 本文是学习、作品集和治理设计材料, 不是法律意见、审计意见、模型验证结论或监管解释。正式项目必须由 Legal、Compliance、Risk、Model Risk、Internal Audit、Security、Privacy、Data Owner 和业务管理层按适用司法辖区确认。
1. Source Anchors
这些来源作为控制库和证据图谱的设计锚点。实战中不要把它们机械转成问卷, 而要转成 control objective、control activity、test method、evidence、owner、cadence 和 gate decision。
| Anchor | Official Link | 在本文中的用法 |
|---|---|---|
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 AI 风险、控制、评估和持续监控 |
| NIST SP 800-53 Rev. 5 | https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final | 借鉴控制库的结构化语言: control family、control objective、control enhancement、assessment procedure、evidence |
| NIST Cybersecurity Framework 2.0 | https://www.nist.gov/cyberframework | 用 Govern / Identify / Protect / Detect / Respond / Recover 连接 AI security、privacy、incident 和 resilience 控制 |
| ISO/IEC 42001 | https://www.iso.org/standard/81230.html | 用 AI management system 视角组织范围、责任、风险机会、运行控制、绩效评价、持续改进和管理评审 |
使用纪律:
- Source anchor 提供控制语言和治理结构, 不直接给出某个机构的合规结论。
- AI control library 必须按 use case、风险等级、业务流程、模型形态、数据敏感性和自动化程度裁剪。
- 每个高风险 claim 必须能追到 evidence, 每份关键 evidence 必须能追回 control objective 和 release decision。
- 对监管、内审和模型风险问询, 不用“我们遵循某框架”作为回答终点, 而要展示证据链。
2. One-Sentence Positioning
AI Control Library defines what must be controlled; Assurance Case explains why the controls are sufficient; Evidence Graph proves the controls operated with traceable artifacts.
中文表达:
AI 控制库定义“必须控制什么”, assurance case 说明“为什么这些控制足以支撑上线主张”, evidence graph 证明“控制在特定系统、版本、数据、流程和时间窗口内真实运行过”。
最小闭环:
Business requirement
-> AI risk
-> control objective
-> control activity
-> test method
-> evidence
-> claim-argument-evidence
-> release gate
-> production monitoring
-> regulator-ready evidence graph
三者分工:
| 对象 | 回答的问题 | 典型产物 |
|---|---|---|
| Control library | 对某类 AI 风险, 组织要求哪些控制目标和控制活动? | control catalog、risk-control matrix、control standard |
| Assurance case | 在某个 use case 和版本边界内, 为什么可以认为系统满足上线主张? | claim-argument-evidence memo、residual risk statement、sign-off |
| Evidence graph | 哪些证据支持哪些 claim、control、test、owner 和 review cadence? | evidence graph table、traceability graph、audit binder index |
3. 为什么 AI 控制不能只靠 checklist
Checklist 的价值是提醒团队别遗漏常见事项, 但它不能独立证明 AI 系统可上线、可运营、可接受监管和审计挑战。AI 控制的核心难点不是“有没有控制项”, 而是“控制项是否覆盖具体风险, 是否被测试, 是否有证据, 是否仍然有效”。
3.1 Checklist 的典型失效方式
| 失效方式 | 表面看起来 | 实际问题 |
|---|---|---|
| 无上下文 | “已完成人工复核控制” | 不知道复核哪个输出、哪个角色、覆盖比例、是否能覆盖自动化偏见 |
| 无证据充分性 | “已完成模型评估” | 不知道测试集是否覆盖真实失败模式、阈值如何设定、失败样本如何处置 |
| 无版本边界 | “RAG 已测试通过” | prompt、retriever、index、policy source、embedding model 变更后证据失效 |
| 无运行证明 | “上线时通过安全评审” | 生产中 prompt injection、权限漂移、日志泄露、供应商变更没有持续监控 |
| 无责任链 | “风险可接受” | 不知道谁接受、接受到什么时候、触发什么条件需要重新评审 |
| 无问询路径 | “材料都在共享盘” | 监管问起某个 claim 时, 团队无法在有限时间内拿出同一口径的证据链 |
3.2 AI 控制需要图谱化的原因
AI 系统的风险来自多个层面同时变化:
- 业务流程会变: 客户群、操作人员、审批节点、政策解释发生调整。
- 数据会变: 数据源、质量、权限、标签、知识库版本、保留规则发生变化。
- 模型会变: vendor model、内部模型、prompt、system instruction、tool schema、guardrail 发生变化。
- 使用方式会变: 用户从“参考 AI”逐渐变成“默认采纳 AI”。
- 外部要求会变: 监管关注、审计范围、供应商条款、安全威胁和行业事件持续变化。
因此 AI 控制必须从静态 checklist 升级为 evidence graph:
Requirement traceability: 业务和监管要求追到控制
Risk traceability: 风险追到控制目标和控制活动
Evidence traceability: 控制追到测试、证据、owner 和复核节奏
Change traceability: 变更追到受影响的 claim、control、test 和 evidence
Question traceability: 监管问询追到标准回答和证据索引
3.3 好控制表达与弱控制表达
| 弱表达 | 问题 | 强表达 |
|---|---|---|
| “系统有 human-in-the-loop。” | 没有说明人工复核的强度和证据 | “所有 AML high-risk alert 的 AI narrative 在进入 case record 前必须由 L2 analyst 审批; 日志记录 AI draft、human edit diff、approval user、timestamp 和最终 disposition。” |
| “RAG 会引用来源。” | 没有证明来源正确或当前有效 | “生产回答必须引用 approved policy repository 中 effective status 为 active 的 source id; citation audit 每周抽样 100 条, high-risk wrong citation 为 release blocker。” |
| “模型经过测试。” | 不知道测试覆盖什么风险 | “Eval contract 覆盖 common、edge、missing-data、policy-conflict、adversarial 和 historical incident cases; critical unauthorized-action failure 必须为 0。” |
| “供应商已评估。” | 无法连接到具体 AI 风险 | “Vendor due diligence 覆盖 data use terms、model update notice、subprocessor、incident notification、exit plan 和 no-training configuration, 并映射到第三方 AI 控制目标。” |
4. Control Library Taxonomy
AI control library 应该按控制域组织, 但每个控制项都必须能落到 use case。下面的 taxonomy 适合金融零售 AI 项目, 尤其是 customer-facing AI、AML / KYC / fraud agent、credit policy RAG、投诉处理助手和运营 Copilot。
| Domain | Control Objective | Control Activity | Test Evidence | Gate Signal |
|---|---|---|---|---|
| Governance | 所有 AI use case 被登记、分级、审批和问责 | 建立 AI inventory、risk tiering、RACI、stage gate、exception register | AI inventory record、risk tier worksheet、committee minutes、owner attestation | 无 owner、无 risk tier、无审批记录则不能进入 pilot |
| Data | 数据使用可授权、可追溯、可最小化、可按权限隔离 | 维护 data lineage、data classification、PII handling、quality checks、retention rule | data flow diagram、data quality report、privacy review、access log sample | 未批准敏感数据或权限不清则不能接入生产 |
| Model | 模型用途、限制、表现、变更和监控清楚 | 维护 model record、model card、benchmark、risk-tiered evaluation、version control | model card、eval report、model selection memo、change log | 高风险失败未关闭则不能 release |
| RAG | 知识来源受控, 检索结果可引用、可复核、可更新 | source approval、index versioning、citation requirement、freshness check、retrieval evaluation | source inventory、index build record、citation audit、retrieval eval report | wrong citation 或 stale source 超阈值则 no-go |
| Agent / Tool | 工具调用受 allowlist、权限、审批和审计约束 | tool registry、scope restriction、dry-run、human approval、execution log | tool permission matrix、test run log、approval workflow sample | 能执行客户影响动作但无人工审批则 no-go |
| Security / Privacy | Prompt、日志、模型调用、向量库和工具链不扩大安全与隐私风险 | threat modeling、RBAC、DLP、prompt injection defense、log minimization、encryption | threat model、red-team report、access review、DLP finding closure | critical security finding 未关闭则不能生产 |
| Human Oversight | 人工复核是真实可操作的控制, 不是形式签字 | define reviewer role、override ability、review queue、training、quality sampling | SOP、training record、override log、review sample | 用户不能理解或推翻 AI 输出则不能高影响上线 |
| Monitoring | 上线后持续证明质量、安全、成本、漂移和采用情况 | production metrics、KRI/KPI dashboard、alert threshold、sampling review、claim drift check | monitoring dashboard、alert history、sample review report | 监控盲区覆盖高风险 claim 则限制发布范围 |
| Incident | AI incident 和 near miss 可发现、升级、隔离、复盘和整改 | severity taxonomy、stop rule、rollback、RCA、customer impact assessment | incident runbook、drill record、postmortem、control retest | 无 stop authority 或 rollback 机制则不能 release |
| Vendor | 第三方 AI 服务、模型、数据处理和变更受控 | TPRM review、contract terms、model update notice、SLA、exit plan、subprocessor review | vendor due diligence、DPA、SLA、exit test evidence | 高风险 vendor 缺合同关键条款则不能接入敏感场景 |
| Adoption | 用户采用、信任校准和业务价值被运营, 防止 over-trust 与 under-trust | onboarding、usage analytics、trust calibration、feedback loop、change management | training completion、usage dashboard、feedback themes、benefit tracking | 价值无法衡量或自动化偏见上升则暂停扩展 |
4.1 控制 ID 命名建议
控制 ID 不追求复杂, 但要支持检索、映射和版本管理:
AICL-GOV-001 AI use case inventory and ownership
AICL-DATA-002 Data lineage and authorization
AICL-RAG-003 Approved source and citation control
AICL-AGT-004 Tool allowlist and human approval
AICL-MON-005 Production quality and safety monitoring
每个控制项至少包含:
| 字段 | 说明 |
|---|---|
| Control ID | 唯一编号, 支持版本和引用 |
| Domain | 控制域, 如 data、RAG、agent/tool |
| Risk Statement | 控制要降低的 AI 风险 |
| Control Objective | 希望达成的控制状态 |
| Control Activity | 实际执行的动作、系统规则或流程门禁 |
| Test Method | 设计有效性和运行有效性的测试方法 |
| Evidence | 可检查材料, 包括日志、报告、审批、抽样结果 |
| Owner | 控制 owner 和 evidence owner |
| Frequency | 触发式、每次发布、每周、每月、季度、年度 |
| Failure Condition | 什么情况导致 release blocker、incident 或整改 |
5. Evidence Graph
Evidence graph 的目标是让一个监管、内审或架构评审问题可以从高层 claim 追到具体证据, 也可以从某份证据反向追到它支撑了哪些控制和上线决策。
5.1 标准链路
Claim
-> Risk
-> Control Objective
-> Control Activity
-> Test
-> Evidence
-> Owner
-> Review Cadence
| Node | 解释 | 示例 |
|---|---|---|
| Claim | 可审查的可信性主张 | “AML Agent 不会自动关闭告警或提交 SAR。” |
| Risk | 该 claim 管理的风险 | AI 越权执行监管敏感动作 |
| Control Objective | 控制希望达成的状态 | 所有 case disposition 和 SAR submission 保留人工审批 |
| Control Activity | 实际控制动作 | 移除 disposition API 写权限, 工具调用仅允许 read / draft, SAR 提交按钮只对 human role 开放 |
| Test | 验证控制是否设计并运行有效 | RBAC 测试、API negative test、日志抽样、workflow walkthrough |
| Evidence | 测试和控制运行的证据 | permission matrix、negative test report、case log sample、release sign-off |
| Owner | 谁对控制和证据负责 | AML Ops Owner、Platform Owner、Security Owner |
| Review Cadence | 证据刷新和复核节奏 | 每次 release、每月 access review、季度 assurance review |
5.2 Edge 类型
| Edge | 含义 | 典型问题 |
|---|---|---|
| supports | evidence 支持 test 或 claim | 这份报告支持哪个主张? |
| mitigates | control objective 降低 risk | 这个风险由哪些控制降低? |
| implements | control activity 实现 control objective | 控制目标在系统中如何落地? |
| verifies | test 验证 control activity | 控制有没有被测试? |
| owns | owner 对 control 或 evidence 负责 | 证据过期时找谁? |
| refreshes | cadence 定义复核节奏 | 多久重新证明一次? |
| blocks | failed test 阻断 release gate | 哪些失败会 no-go? |
| traces_to | requirement 映射到 risk/control/evidence | 监管要求或 PRD requirement 如何落到控制? |
5.3 Regulator-Ready Evidence Graph 的质量标准
一张监管就绪的 evidence graph 至少满足:
- 每个 material claim 至少有一个 risk、一个 control objective、一个 test 和一份 evidence。
- 每个 release blocker 有明确 failure condition、owner、decision record 和 remediation evidence。
- 每份 high-value evidence 有版本、生成日期、复核人、样本范围、保留规则和访问权限。
- 每个高风险变更能识别受影响的 claim、control、eval case、monitoring signal 和 regulator Q&A。
- 每个监管问询都能定位到 factual answer、control owner、evidence path、residual risk 和管理层口径。
5.4 图谱查询示例
| 查询 | 业务意义 |
|---|---|
显示所有支持 AI does not make final credit decision 的 evidence | 支撑客户权益和自动化决策边界说明 |
找出所有 RAG wrong citation 风险对应的 control 和 failed tests | 识别 release gate 中的质量阻断点 |
| 列出过去 90 天内证据过期的 high-risk claims | 做季度 assurance review |
| 查找某次 prompt 变更影响哪些 eval contract 和 monitoring signals | 做变更影响分析 |
| 输出 AML Agent 对监管问询的 claim-argument-evidence map | 准备检查室材料 |
6. Release Assurance Case
Release assurance case 不是上线审批表的附件, 而是 gate decision 的理由。它用 claim-argument-evidence 结构说明: 在当前阶段、范围、用户、数据、模型和控制条件下, 系统是否可以进入下一阶段。
6.1 CAE 结构
| 元素 | 作用 | 金融零售 AI 示例 |
|---|---|---|
| Claim | 明确、可挑战的上线主张 | “Customer Service AI 在 limited release 中只回答已批准 FAQ 和账户服务政策, 不承诺费用减免或信贷决定。” |
| Argument | 说明为什么证据足以支持 claim | “RAG source 仅来自 approved policy repository; forbidden action classifier 和 response policy 阻断承诺性动作; 人工抽检覆盖高风险问题。” |
| Evidence | 支撑 argument 的材料 | source inventory、retrieval eval、policy violation eval、red-team report、sample QA、release gate minutes |
6.2 Pilot / Release / Scale 证据深度
| Stage | 目标 | 证据深度 | Gate Decision |
|---|---|---|---|
| Pilot | 证明 use case 有价值, 且在窄范围内不会制造不可接受风险 | use case scope、risk tier、limited data lineage、baseline eval、human review SOP、manual fallback、pilot monitoring | approve pilot / restrict scope / stop |
| Release | 证明生产边界、控制设计、评测、监控、事件响应和责任链完整 | full PRD traceability、ADR、eval contract、control matrix、security/privacy review、release eval report、incident runbook、audit log sample | release / limited release / no-go |
| Scale | 证明控制在更大用户、更多流程、更多流量和持续变更下仍有效 | trend monitoring、control operating effectiveness test、adoption and trust calibration、vendor review、drift review、incident history、quarterly assurance memo | scale / hold / redesign / retire |
6.3 Release Gate 的硬阻断条件
以下情况不应通过生产 release:
- AI 可执行客户影响或监管敏感动作, 但无 tool allowlist、权限隔离和人工审批。
- 高风险输出没有 eval contract, 或 eval 没有覆盖真实失败模式。
- RAG 无 approved source inventory、freshness control、citation audit 或权限过滤。
- 日志无法重建关键输出的 input reference、retrieved source、model version、prompt version、user action。
- 供应商数据使用、模型更新通知、事件通知、subprocessor 或退出方案不清。
- 监控无法发现 critical failure, 或无 stop authority 与 rollback path。
- 关键 residual risk 没有 owner、expiry、review trigger 和明确接受记录。
6.4 Assurance Case 评审口径
评审时不要只问“证据是否存在”, 要问:
| 问题 | 判断重点 |
|---|---|
| Claim 是否过宽? | 是否限定 use case、用户、数据、模型版本、时间窗口和地区 |
| Argument 是否跳跃? | 是否能解释为什么这些控制足够, 而不是只列材料 |
| Evidence 是否匹配? | 证据是否直接证明 claim, 还是只证明团队做过相关工作 |
| Evidence 是否新鲜? | 变更后是否重新测试, 证据是否仍适用 |
| Residual risk 是否可接受? | 谁接受、接受多久、触发什么条件重审 |
7. Product / Architecture Integration
AI control library 和 evidence graph 不能只放在 GRC 工具里。它必须嵌入产品、架构、评测、发布和运营资产, 否则控制会变成事后整理。
7.1 从 PRD 到 Audit Binder 的连接
PRD
-> Risk and requirement traceability
-> ADR
-> Eval contract
-> Control matrix
-> Release gate
-> Monitoring plan
-> Audit binder
-> Regulator Q&A map
| Artifact | 连接方式 | 关键字段 |
|---|---|---|
| PRD | 定义业务目标、用户、流程、AI 作用边界、不可接受行为 | AI role、decision boundary、user journey、failure mode、acceptance metric |
| ADR | 记录架构选择及其控制后果 | model/vendor choice、RAG pattern、tool permission、logging、fallback、tradeoff |
| Eval Contract | 把需求和风险转成可测标准 | scenario、rubric、threshold、critical failure、sample source、reviewer role |
| Control Matrix | 把风险、控制目标、控制活动、测试和证据连起来 | control ID、risk、activity、test、evidence、owner、frequency |
| Release Gate | 汇总是否允许进入 pilot、release、scale | pass/fail、conditions、blockers、exceptions、approval、expiry |
| Monitoring Plan | 上线后证明 claim 仍成立 | metric、threshold、alert owner、sampling cadence、incident trigger |
| Audit Binder | 按问询路径组织证据 | evidence index、version、owner、review record、retention |
| Regulator Q&A Map | 把常见问题映射到 factual answer 和 evidence | question、answer、claim、control、evidence、owner |
7.2 产品门禁中的控制点
| Product Decision | 必须连接的控制 |
|---|---|
| AI 是否面向客户 | disclosure、content safety、policy boundary、complaint handling、customer impact monitoring |
| AI 是否生成建议 | grounding、explanation、human review、confidence / uncertainty display、override tracking |
| AI 是否执行动作 | tool allowlist、approval workflow、segregation of duties、transaction log、rollback |
| AI 是否使用客户数据 | data authorization、PII minimization、privacy review、retention、vendor data terms |
| AI 是否接入 RAG | source approval、index versioning、entitlement filtering、citation audit、stale source handling |
| AI 是否影响合规流程 | policy mapping、case record integrity、reviewer accountability、audit trail、regulatory response pack |
7.3 架构门禁中的控制点
| Architecture Area | 架构师要证明什么 | 证据 |
|---|---|---|
| System boundary | AI 在哪里读、写、生成、调用工具、记录日志 | C4 diagram、sequence diagram、data flow |
| Data boundary | 哪些数据进入 prompt、RAG、logs、monitoring 和 vendor service | data lineage、field inventory、masking policy |
| Trust boundary | 用户输入、retrieved content、tool output 和 model output 的信任等级不同 | threat model、prompt injection test、content trust policy |
| Permission boundary | AI 不扩大用户原有权限 | RBAC mapping、entitlement filter test、access log |
| Change boundary | prompt、model、index、tool、policy source 变更都有回归路径 | change log、regression eval、approval ticket |
| Recovery boundary | 出错时可以停用、降级、回滚、人工接管 | rollback plan、manual fallback test、incident drill |
7.4 Control-to-Requirement Traceability
需求不能停在 “AI should be accurate and safe”。更好的表达:
Requirement:
AML Agent must draft investigation summaries grounded in approved case evidence.
Risk:
Unsupported or misleading summary causes analyst error and weak regulatory evidence.
Control Objective:
Every material factual claim in the summary is traceable to approved case evidence.
Control Activity:
The system attaches source IDs to material facts, blocks unsupported conclusions, and requires analyst approval before saving to case record.
Test:
Grounding eval, citation audit, analyst review sample, negative test for unsupported facts.
Evidence:
Eval report, citation audit log, case record sample, approval workflow log.
8. Financial Retail Case: AML Investigation Agent Evidence Graph
8.1 场景边界
| 维度 | 设定 |
|---|---|
| Use case | AML Investigation Agent 辅助 analyst 阅读告警、交易、KYC 档案、历史 case notes 和 AML policy |
| AI role | retrieve、summarize、draft、red-flag checklist、evidence citation |
| AI 不做 | 不自动关闭 alert, 不自动提交 SAR, 不更改客户风险评级, 不绕过主管审批 |
| 用户 | AML L1 analyst、L2 reviewer、QA reviewer |
| 数据 | case management、transaction monitoring、KYC profile、approved AML policy repository |
| 风险级别 | 高影响, 因涉及 AML 合规义务、监管检查证据和客户影响 |
8.2 Top-Level Assurance Claims
| Claim ID | Claim |
|---|---|
| AML-C1 | Agent 只生成草稿和证据组织, 不执行最终 AML disposition 或 SAR submission。 |
| AML-C2 | Agent 的 material factual statements 可追溯到 approved case evidence 或 approved AML policy。 |
| AML-C3 | Agent 不扩大 analyst 对客户数据、历史案件或政策资料的访问权限。 |
| AML-C4 | High-risk alert 的 AI 输出必须经过授权人员复核后才能进入 case record。 |
| AML-C5 | 生产运行中可监控 unsupported claim、wrong citation、override、latency、cost、incident 和 drift。 |
8.3 Evidence Graph Table
| Claim | Risk | Control Objective | Control Activity | Test | Evidence | Owner | Cadence |
|---|---|---|---|---|---|---|---|
| AML-C1 | AI 越权关闭告警或提交 SAR | 监管敏感动作只由授权人员执行 | Tool allowlist 仅允许 read、retrieve、draft; disposition API 无 AI 写权限 | API negative test、RBAC walkthrough、workflow sample | tool registry、permission matrix、negative test report、case action log sample | Platform Owner / AML Ops | 每次 release 和季度 access review |
| AML-C2 | 无依据 narrative 误导 analyst | 所有关键事实可追溯到 case evidence | 输出包含 source id; unsupported conclusion 被阻断或标记 evidence missing | grounding eval、citation audit、expert review sample | eval report、citation audit、review sample、failed case analysis | EvalOps / AML QA | 每次 release, 上线后每周抽样 |
| AML-C3 | AI 检索到用户无权查看的数据 | AI 继承 analyst 权限, 不扩大可见范围 | RAG retrieval 使用 entitlement filter; logs 不显示非授权字段 | access control test、cross-case leakage test、log masking test | entitlement test result、retrieval trace sample、log masking evidence | Security / Data Owner | 每次 index 变更和月度复核 |
| AML-C4 | 人工复核流于形式 | 高风险输出必须由合格 reviewer 审批 | UI 强制 review queue; 保存 case record 前记录 reviewer action 和 edit diff | workflow walkthrough、sample review、training validation | SOP、training record、approval log、edit diff sample | AML Ops / L2 Reviewer Lead | 每月 QA 抽样和每次流程变更 |
| AML-C5 | 上线后质量或安全漂移未发现 | 关键质量、安全、采用和事故指标持续监控 | dashboard 跟踪 wrong citation、unsupported claim、override、incident、cost、latency | monitoring alert test、dashboard review、incident drill | monitoring dashboard、alert history、incident drill record、quarterly assurance memo | RiskOps / Platform Owner | 每周运营 review, 季度 assurance review |
8.4 监管或内审问询响应
| Question | Factual Answer | Evidence Path |
|---|---|---|
| AI 是否会替代 analyst 做 AML 判断? | 不会。Agent 只能汇总、检索和生成草稿; disposition 和 SAR submission 仍由授权人员在 case management system 中完成。 | AML-C1、tool registry、permission matrix、case action log sample |
| 如何证明 AI narrative 没有编造事实? | 每个 material factual statement 需要 source id; release eval 和每周 citation audit 检查 unsupported claim 和 wrong citation。 | AML-C2、grounding eval、citation audit、expert review sample |
| AI 是否扩大了客户数据访问范围? | 不扩大。检索层继承 analyst entitlement, 并通过 cross-case leakage test 和 access log 抽样验证。 | AML-C3、entitlement filter test、retrieval trace、access review |
| 如果 AI 错误影响案件记录怎么办? | 触发 AI incident runbook, 冻结相关版本, 做影响范围分析、case correction、control retest 和复盘。 | AML-C5、incident runbook、postmortem、control retest |
8.5 Customer-Facing Variant
如果场景改成 customer-facing AI, 证据图谱要额外强化:
- disclosure 和客户理解: 客户是否知道 AI 参与服务, 何时转人工。
- policy boundary: AI 不承诺费用减免、授信批准、监管解释或法律结论。
- complaint and correction: 客户如何申诉、纠错和获得人工复核。
- vulnerable customer handling: 对弱势客户、语言障碍、特殊需求客户设置更高人工转接门槛。
- channel monitoring: 监控错误回答、升级率、投诉、客户损害、重复联系和人工覆盖率。
9. Artifact Templates
以下模板用于作品集、项目启动和审计准备。模板中的示例是字段要求和表达方式, 正式项目应按机构制度、GRC 工具、模型风险流程和数据治理标准落地。
9.1 Control Catalog Template
| Field | 填写要求 | 示例 |
|---|---|---|
| Control ID | 唯一编号, 可跨文档引用 | AICL-RAG-003 |
| Control Name | 控制名称要动宾清楚 | Approved RAG source and citation control |
| Domain | 控制域 | RAG |
| Risk Statement | 写清风险事件和影响 | 未批准或过期政策被检索, 导致客户或员工收到错误合规解释 |
| Control Objective | 希望达到的控制状态 | 生产 RAG 仅使用已批准、有效、可追溯的知识来源 |
| Control Activity | 实际动作、系统规则或流程 | source registry 审批后进入 index; 每次 index build 记录 source version; 输出必须带 source id |
| Control Type | preventive、detective、corrective、directive | preventive + detective |
| Test Method | 如何验证设计和运行有效 | source sample test、citation audit、index build review |
| Evidence | 可检查材料 | source registry、index build log、citation audit report |
| Owner | 控制 owner 和 evidence owner | Knowledge Owner / Platform Owner |
| Frequency | 执行或复核频率 | 每次 source/index 变更, 每周抽样 |
| Failure Condition | 何时阻断或升级 | wrong citation 高风险样本超过阈值; source effective status 不是 active |
9.2 Evidence Graph Table Template
| Claim ID | Risk ID | Requirement ID | Control ID | Control Activity | Test ID | Evidence ID | Evidence Quality | Owner | Cadence | Gate Impact |
|---|---|---|---|---|---|---|---|---|---|---|
| AML-C2 | AML-R7 | PRD-REQ-14 | AICL-RAG-003 | Material facts require source id | EVAL-GRD-02 | EV-CIT-2026Q3-01 | sample size, version, reviewer, date recorded | EvalOps Owner | weekly sample | release blocker if critical failure occurs |
Evidence Quality 建议包含:
- coverage: 覆盖哪些场景、用户、数据、版本。
- freshness: 证据生成日期和适用版本。
- independence: 是否由二线、三线或独立 reviewer 复核。
- reproducibility: 是否能重放输入、检索、输出和人工动作。
- retention: 保留期限和访问控制。
9.3 Assurance Case Memo Template
# Assurance Case Memo: System Name / Release Version
## Scope
- Use case:
- Users:
- Business process:
- AI role:
- Excluded actions:
- Model / vendor / version:
- Data and knowledge sources:
- Release stage:
## Top-Level Claims
| Claim ID | Claim | Owner | Review Date |
|---|---|---|---|
## Claim-Argument-Evidence
| Claim | Argument | Evidence | Residual Risk | Decision |
|---|---|---|---|---|
## Control Coverage
| Risk | Control Objective | Control Activity | Test | Evidence |
|---|---|---|---|---|
## Release Gate Decision
- Decision:
- Conditions:
- Blockers closed:
- Accepted residual risks:
- Stop rules:
- Next assurance review:
## Monitoring and Change Triggers
| Trigger | Required Action | Owner |
|---|---|---|
写作标准:
- Scope 要明确边界, 不用“企业 AI 平台整体可信”这类过宽主张。
- Claim 要可验证, 不写“系统安全可靠”这种无法审查的句子。
- Argument 要说明为什么证据足够, 不只是把 evidence list 粘贴进文档。
- Decision 要说明条件、时效和复核触发点。
9.4 Regulator Q&A Map Template
| Examiner Question | Factual Answer | Claim | Control ID | Evidence | Owner | Residual Risk / Follow-Up |
|---|---|---|---|---|---|---|
| 这个 AI 是否会做最终客户影响决定? | AI 只生成建议和草稿, 最终决定由授权人员在核心系统完成。 | C-DEC-001 | AICL-HITL-004 | workflow map、approval log、sample review | Business Ops Owner | automation bias 通过培训、override monitoring 和 QA 抽样管理 |
| 如何证明知识库没有使用过期政策? | 生产 index 只接收 approved source registry 中 active 状态的政策版本。 | C-RAG-002 | AICL-RAG-003 | source registry、index build log、freshness dashboard | Knowledge Owner | 政策紧急更新触发 out-of-cycle index rebuild |
| 模型供应商更新会不会绕过内部审批? | 高风险系统要求 vendor update notice, 重大变更触发 regression eval 和 staged rollout。 | C-VND-003 | AICL-VND-006 | vendor terms、change log、regression report | Vendor Owner | 紧急供应商变更进入 risk acceptance review |
10. Interview Answers
10.1 30 秒版本
AI control library 不能只是 checklist。我的做法是把控制库设计成 evidence graph: 从 business requirement 和 AI risk 出发, 映射到 control objective、control activity、test、evidence、owner 和 review cadence。上线时用 assurance case 的 claim-argument-evidence 结构说明为什么当前版本可以 pilot、release 或 scale; 上线后用 monitoring 和 incident loop 持续证明 claim 没有漂移。这样面对监管或内审时, 每个回答都能追到具体控制和证据。
10.2 2 分钟版本
我会把 AI 控制体系拆成三层。第一层是 control library, 定义 governance、data、model、RAG、agent/tool、security/privacy、human oversight、monitoring、incident、vendor 和 adoption 等控制域。每个控制项都写清 risk statement、control objective、control activity、test method、evidence、owner、frequency 和 failure condition。
第二层是 assurance case。对于具体 use case, 比如 AML Investigation Agent, 我不会泛泛说“有人工复核”或“模型已测试”, 而是写成 claim-argument-evidence: Agent 不自动关闭告警, 因为工具权限没有 disposition write API, workflow 需要 analyst approval, 并且 negative test 和 case log sample 支撑这个主张。
第三层是 evidence graph。它把 claim、risk、control objective、control activity、test、evidence、owner 和 cadence 连接起来。这样 PRD 中的 AI 边界、ADR 中的架构选择、eval contract 中的测试阈值、control matrix 中的控制活动、release gate 中的 go/no-go 决策和 audit binder 中的材料是一条链。监管问询时, 团队不是临时找材料, 而是直接从问题追到 claim、control 和 evidence。
10.3 CRO 版本
我会把这个问题表述为“管理层如何知道 AI residual risk 在风险偏好内”。控制库负责定义最低控制期望; assurance case 负责说明在某个 use case、版本和范围内哪些 claim 被证据支持; evidence graph 负责证明控制设计和运行结果。CRO 需要看到的不是模型准确率单点指标, 而是 material AI inventory、risk tier、control coverage、critical failure trend、policy exceptions、incidents、accepted residual risks、owner accountability 和 stop rules。这样 AI 风险可以进入常规风险治理节奏, 而不是作为技术项目单独运行。
10.4 Chief Architect 版本
我会从架构可追溯性回答。AI 系统的 control library 必须嵌入架构边界: 数据边界、权限边界、模型边界、RAG source 边界、tool execution 边界、日志边界和恢复边界。每个 ADR 都要说明它影响哪些 control objective; 每次 prompt、model、index、tool 或 policy source 变更都要触发受影响 eval 和 evidence 的刷新。Chief Architect 关注的是系统在持续变化下仍能证明控制有效, 所以 evidence graph 应该成为 architecture governance 的一部分, 支持 release gate、change impact analysis、incident review 和监管材料生成。