AI Assurance / Safety Case / Evidence Case Playbook

定位: 面向 AI Solutions Architect / AI PM / AI BA / Risk & Compliance 的 AI 可信性论证手册。目标是把“我们会负责任地使用 AI”这类原则口号, 转换成可审查、可追溯、可挑战、可复核的 evidence structure。

适用范围: 金融零售 AI use case, 尤其是 AML Copilot、KYC Policy Assistant、Credit Policy RAG、Customer Service Copilot、Payment Dispute Assistant。

重要说明: 本文是学习、作品集和内部治理训练材料, 不是法律意见、审计意见、合规结论、模型验证报告或安全认证。正式项目必须由 Legal、Compliance、Risk、Model Risk、Internal Audit、Security、Privacy、Data Owner 和业务管理层确认。

---

1. 为什么需要 AI Assurance Case

企业 AI 项目常见的失败, 不是因为团队没有原则, 而是因为原则没有变成证据。

弱表达通常是:

• 我们重视 responsible AI。
• 我们有 human-in-the-loop。
• 我们做过测试。
• 模型只用于辅助。
• 数据不会泄露。
• 用户可以自己判断。

检查者、审计者、CRO、CTO、董事会和监管方真正会问:

你主张这个系统可信, 具体可信在哪里?
这个主张适用于哪个业务范围、用户范围、数据范围和模型版本?
你用什么论证说明这些控制足够?
证据在哪里, 谁生成, 谁复核, 多久更新一次?
哪些风险仍然存在, 谁接受, 触发什么条件必须停止或整改?

AI Assurance Case 的作用, 是把可信性从口头承诺变成一个可审查的结构:

Use case scope
-> system boundary
-> risk tier
-> top-level claims
-> subclaims
-> arguments
-> evidence
-> assumptions
-> residual risk
-> sign-off
-> continuous monitoring

对于 AI PM / BA / Architect, 这是一种关键职业能力: 不只是推动 AI 上线, 而是能证明 AI 为什么可以在某个边界内上线, 为什么不能超出该边界, 上线后如何持续证明控制仍然有效。

---

2. 与既有学习资产的连接

本文不是替代既有 governance 文档, 而是把它们汇聚成一个可审查的 evidence pack。

一句话定位:

Regulatory Response 说明外部要求和内部义务。
Architecture Review Gate 说明设计和上线门槛。
Regulator Exam Simulation 说明如何被追问。
Board Governance Pack 说明如何被监督。
AI Assurance Case 说明如何用证据证明“可以信任到什么程度”。

---

3. Source Anchors

以下官方来源作为学习锚点。本文引用它们的 assurance、risk management、governance、management system 思路, 不把它们简化成单一检查清单。

使用纪律:

• 不把 anchor 当作法律结论。
• 不只摘录概念, 要转成 artifact、owner、evidence 和 review cadence。
• 每个高影响 use case 都记录 source version、access date、适用性判断和审批记录。
• 任何监管义务、合规判断和审计结论都必须由正式职能确认。

---

4. Assurance 基础概念

4.1 Trust、Trustworthiness、Justified Trust

AI assurance 的关键不是制造更多信任, 而是校准信任:

Under-trust  -> 好系统没人用, 价值无法实现。
Over-trust   -> 用户自动采纳错误输出, 客户、合规和运营风险放大。
Justified trust -> 用户知道何时依赖、何时质疑、何时升级。

4.2 Assurance Case、Safety Case、Evidence Case

一句话区分:

Evidence case 证明“我们有什么材料”。
Assurance case 证明“这些材料为什么足以支持这些主张”。
Safety case 证明“在这些风险和失效模式下, 系统不会造成不可接受的伤害”。

4.3 Claims-Arguments-Evidence 结构

AI assurance case 的最小结构是 CAE:

好 claim 的标准:

• 有范围: 哪个 use case、用户、数据、模型版本、地区、流程阶段。
• 可验证: 能找到证据支持或反驳。
• 可挑战: 审计、风险、安全、业务能提出反例。
• 有责任人: claim owner 和 evidence owner 明确。
• 有时效: 证据不过期, 监控能发现偏离。

弱 claim 与强 claim 的对比:

---

5. AI Assurance Case Reference Model

每个高影响 AI use case 至少应具备以下对象。它们不是文档章节的机械顺序, 而是 assurance case 的数据模型。

5.1 Reference Flow

1. Define scope
2. Draw system boundary
3. Classify risk tier
4. Select claims from claims library
5. Decompose claims into subclaims
6. Write arguments for each claim
7. Map evidence and identify gaps
8. Record assumptions and residual risk
9. Review sufficiency with PM / BA / Architect / Risk
10. Sign off pilot or release with conditions
11. Monitor claim drift and evidence freshness

5.2 Assurance Case 的最小合格标准

一个可提交的 case pack 至少能回答:

---

6. 金融零售 AI 场景

6.1 AML Copilot

示例顶层 claim:

在 2026-Q3 AML pilot 范围内, AML Copilot 只提供 evidence-cited draft 和 investigation assistance, 不自动作出 case disposition 或 regulatory filing decision; 对 high-risk alert 的最终判断仍由授权 AML analyst 和 reviewer 完成。

6.2 KYC Policy Assistant

示例顶层 claim:

KYC Policy Assistant 在已批准政策库内回答 KYC 操作问题, 并以政策引用和生效日期支撑答案; 它不产生客户风险评级审批结论。

6.3 Credit Policy RAG

示例顶层 claim:

Credit Policy RAG 只为授权人员提供政策检索和解释草稿, 所有信贷决策、客户通知和 adverse action reason 仍由既有信贷流程和授权人员确认。

6.4 Customer Service Copilot

示例顶层 claim:

Customer Service Copilot 只为客服生成内部草稿和知识检索建议, 面向客户的最终回复由客服人员确认, 高风险主题按规则升级。

6.5 Payment Dispute Assistant

示例顶层 claim:

Payment Dispute Assistant 可以生成 dispute analysis 和沟通草稿, 但不能独立执行资金动作或最终拒绝客户争议; 所有 case decision 均保留规则引用、人工审批和审计日志。

---

7. Claims Library

Claims library 是可复用主张库。实际项目不能照搬, 必须按 use case scope、risk tier、数据和流程改写。

7.1 Claim 写作公式

For [use case + scope + version],
the system [does / does not do something material],
within [risk boundary / workflow boundary],
because [controls and arguments],
as evidenced by [evidence set],
subject to [assumptions and residual risk].

示例:

For the KYC Policy Assistant pilot used by onboarding analysts in the US small-business segment,
the system provides policy retrieval and checklist drafting but does not approve customer risk ratings,
because it has no write access to the KYC decision field, all answers require policy citation,
and EDD-trigger topics route to supervisor review,
as evidenced by the architecture boundary diagram, RBAC test, groundedness eval, workflow sample review,
subject to the assumption that the approved policy source inventory remains current within the 5-business-day SLA.

---

8. Evidence Mapping

Evidence mapping 的核心问题不是“有没有材料”, 而是“这些材料是否足以支撑某个 claim”。

8.1 Evidence Sufficiency Levels

8.2 Evidence Mapping 示例: AML Copilot

---

9. PM / BA / Architect / Risk 分工

Assurance case 不是 Risk 一个人写, 也不是 Architect 一个人补图。它是跨角色共同构建的可信性论证。

9.1 RACI 示例

R = Responsible, A = Accountable, C = Consulted。

---

10. Assurance Review Workflow

10.1 Discovery Review

目标: 判断是否值得进入正式 design。

输入:

• Opportunity brief。
• 初步 scope。
• materiality screening。
• 初步 system boundary。
• 初步 claim list。

输出:

• continue / refine / stop。
• risk tier 初判。
• evidence gap list。
• 禁止自动化或禁止上线边界。

10.2 Pilot Readiness Review

目标: 判断是否可以小范围试点。

输入:

• system boundary diagram。
• eval report。
• red-team summary。
• data lineage。
• access test。
• human review workflow。
• draft residual risk register。

输出:

• pilot approval with conditions。
• pilot user / data / volume limit。
• monitoring thresholds。
• incident and stop rule。

10.3 Release Assurance Review

目标: 判断是否可以生产发布或扩大范围。

输入:

• updated assurance case。
• pilot results。
• operational logs。
• sample review。
• incident history。
• residual risk decision。
• sign-off memo。

输出:

• release / limited release / no-go。
• accepted residual risk。
• control owner attestation。
• next review date。

10.4 Quarterly Assurance Refresh

目标: 判断 claim 是否仍然成立。

触发条件:

• model / vendor / prompt / RAG index / policy source 重大变更。
• incident、投诉、监管问询、审计发现。
• data drift、cost spike、latency breach、quality decline。
• 扩大用户、地区、客户类型或自动化程度。

刷新动作:

• 重新检查 assumptions。
• 更新 evidence freshness。
• 重跑关键 eval 和 access test。
• 复核 residual risk。
• 更新 board / audit committee reporting。

---

11. 14 天 Lab: AML 或 KYC Assurance Case Pack

目标: 14 天内完成一个可转作品集的 AML Copilot 或 KYC Policy Assistant assurance case pack。建议选择一个场景贯穿到底, 不要中途换题。

11.1 14 天完成标准

最终 pack 至少包括:

• 1 页 Assurance Case Canvas。
• 1 张 system boundary。
• 1 份 risk tiering memo。
• 8-10 条场景化 claims。
• 1 张 Claim-Argument-Evidence Table。
• 1 份 Evidence Sufficiency Checklist。
• 1 份 Residual Risk Register。
• 1 份 Assurance Review Memo。
• 1 页面试表达稿。

作品集表达:

我没有只写“AI 要负责任”, 而是把 AML/KYC AI 系统拆成 scope、risk tier、claims、arguments、evidence、assumptions、residual risk 和 monitoring。这个 pack 可以支持 release gate、审计问询和董事会风险汇报。

---

12. 模板 1: Assurance Case Canvas

---

13. 模板 2: Claim-Argument-Evidence Table

使用方法:

• 每条 claim 至少有一个可检查 evidence。
• 每个 evidence 有 owner、date、version。
• 每个 argument 要承认限制, 不写绝对安全。
• sufficiency 低于 L2 的高影响 claim 不应进入 release。

---

14. 模板 3: Evidence Sufficiency Checklist

---

15. 模板 4: Residual Risk Register

Residual risk 写作纪律:

• 不写“风险很低”这种无证据判断。
• 写清楚剩余风险是什么, 不是重复原始风险。
• 每个 residual risk 必须有 owner 和 review trigger。
• 风险接受要有时间限制, 不做永久接受。

---

16. 模板 5: Assurance Review Memo

# [Use Case] Assurance Review Memo

## 1. Decision Requested

请求批准 [pilot / limited release / production release / scale]。

Decision options:
- Approve with conditions
- Defer pending evidence
- Reject / stop

## 2. Scope and Boundary

- AI role:
- Not AI role:
- Users:
- Customer / case scope:
- Geography:
- Model / vendor / version:
- Data and knowledge sources:
- Downstream systems:

## 3. Risk Tier and Materiality

- Risk tier:
- Customer impact:
- Regulatory / policy sensitivity:
- Data sensitivity:
- Automation level:
- Reversibility:

## 4. Top Claims

| Claim ID | Claim | Sufficiency | Owner |
|---|---|---|---|
| C-01 |  |  |  |

## 5. Evidence Summary

| Evidence | What it proves | Date / version | Owner | Gap |
|---|---|---|---|---|

## 6. Residual Risks

| Risk ID | Residual risk | Decision | Owner | Review trigger |
|---|---|---|---|---|

## 7. Conditions for Approval

- Condition 1:
- Condition 2:
- Condition 3:

## 8. Monitoring and Stop Rule

- Key metrics:
- Thresholds:
- Sampling:
- Incident triggers:
- Stop rule:
- Next review:

## 9. Recommendation

Based on the current scope, evidence sufficiency, residual risk decision, and monitoring plan, the recommendation is [approve / limited approve / defer / stop].

填写要求:

• 每个空格都必须填实际内容或明确写“不适用, 原因是...”。
• recommendation 不得只写“建议批准”, 必须带条件。
• evidence gap 必须转入 approval condition 或 residual risk。

---

17. 面试表达

17.1 30 秒版本

AI assurance 的核心不是说“我们负责任”, 而是把可信性拆成可审查的 claim、argument 和 evidence。比如 AML Copilot, 我会先界定 AI 只做 evidence-cited draft, 不做 case disposition; 然后用 eval report、red-team、trace logs、RBAC test、human review sample 和 residual risk register 证明这个边界有效。这样 PM、BA、Architect、Risk 和审计委员会讨论的是同一套证据, 而不是抽象原则。

17.2 2 分钟版本

我会把 AI assurance case 当成高影响 AI 上线前后的证据结构。第一步是 scope 和 system boundary: AI 做什么、不做什么、用哪些数据、调用哪些模型和工具、输出进入哪个人工流程。第二步是 risk tiering: 看客户影响、监管义务、数据敏感性、自动化程度、可逆性和供应商依赖。第三步写 claims, 例如准确性、groundedness、权限、隐私、安全、人工监督、公平性、可解释、可回滚、供应商和 SLO。第四步为每个 claim 写 argument 和 evidence, 例如 eval report、red-team、trace logs、policy control、human review sample、incident history、model/vendor record、data lineage 和 access test。最后记录 assumptions、residual risk、sign-off 和 monitoring。这样系统不是一次性通过评审, 而是持续证明 claim 仍然成立。

17.3 CTO 深挖

CTO 可能问: “技术上怎么保证 case 可复现、可回滚、可监控?”

回答要点:

• 我会要求所有关键输出有 request id、user id、case id、source ids、model version、prompt version、RAG index version、tool call 和 timestamp。
• 通过 model gateway 统一控制模型、工具、日志、策略和成本。
• prompt、RAG index、policy source、模型版本和权限配置都进入 change control。
• release gate 前做 regression eval、access test、red-team 和 rollback test。
• 上线后用 quality、groundedness、latency、cost、incident、override 和 user behavior 指标监控 claim drift。
• 如果供应商模型变更或 quality threshold breach, 自动触发 limited mode、rollback 或 kill switch。

一句话:

我不会只问模型准不准, 我会设计一条从请求、检索、推理、工具调用、人工决策到审计日志的可复现链路。

17.4 CRO 深挖

CRO 可能问: “哪些风险还没被消除, 为什么可以接受?”

回答要点:

• 我会区分 original risk、control effect 和 residual risk, 不把控制存在等同于风险消失。
• residual risk register 会写清风险表述、影响、控制、剩余严重度、owner、接受条件和 review trigger。
• 高影响风险必须有业务 owner 和 risk owner 共同接受, 并设置 expiry date。
• 对客户权益、AML、KYC、credit、payment dispute 等场景, 我会单独看 false negative、false positive、unsupported claim、policy mismatch、privacy leakage 和 human overreliance。
• 如果 evidence sufficiency 不够, 我会建议 limited pilot 或 defer, 而不是用培训材料掩盖证据缺口。

一句话:

我会让管理层明确知道: 我们接受的不是“AI 风险”, 而是在特定边界、控制、监控和停止条件下的剩余风险。

17.5 Audit Committee 深挖

Audit Committee 可能问: “管理层怎么证明控制真的运行?”

回答要点:

• 我会把 board-level claim 连接到底层 evidence: eval、red-team、access test、human review sample、incident history 和 monitoring dashboard。
• 每个 claim 有 owner、evidence owner、review date 和 freshness requirement。
• 对关键控制做抽样, 例如 SAR draft 是否有引用、reviewer 是否编辑过、越权访问是否失败、policy source 是否最新。
• incident 和 audit finding 会触发 assurance case refresh, 而不是只进入项目问题清单。
• 管理层 attestation 只基于可检查证据, 不基于 vendor 宣传或团队自信。

一句话:

审计委员会需要的不是更多 AI 术语, 而是可抽样、可复现、可追责、可升级的控制证据。

---

18. 常见误区与修正

---

19. 作品集转化建议

如果把本文转成求职作品集, 建议做一个 8-12 页的 case pack:

1. 封面: “AML Copilot Assurance Case Pack” 或 “KYC Policy Assistant Assurance Case Pack”。
2. 一页 business context: 业务目标、用户、AI role、not AI role。
3. 一页 system boundary: 数据、模型、RAG、工具、日志、人工流程。
4. 一页 risk tiering: materiality、客户影响、监管义务、数据敏感性。
5. 两页 claims library: 8-10 条场景化 claims。
6. 两页 CAE table: claim、argument、evidence、sufficiency、owner。
7. 一页 residual risk register。
8. 一页 monitoring and stop rule。
9. 一页 executive assurance review memo。
10. 一页 interview talk track。

作品集标题可以强调:

From Responsible AI Principles to Auditable Assurance Evidence

面试中你要表达的差异化能力:

• 你懂 AI 产品价值, 但不会让价值叙事压过风险证据。
• 你懂 BA 流程和异常路径, 能把人工监督设计成真实控制。
• 你懂架构边界和 traceability, 能让 AI 输出可复现、可监控、可回滚。
• 你懂风险和审计语言, 能把 residual risk 讲给 CRO 和 Audit Committee。

---

20. 一页速记

AI Assurance Case =
可信性主张 + 论证 + 证据 + 剩余风险 + 持续监控

不要问:
“我们有没有 responsible AI?”

要问:
1. 我们主张 AI 在什么边界内可信?
2. 这个主张由哪些子主张支撑?
3. 为什么这些控制足够?
4. 证据在哪里, 谁负责, 是否新鲜, 是否可复现?
5. 哪些风险仍然存在, 谁接受, 何时复核?
6. 上线后如何发现 claim 不再成立?

最终判断标准:

如果监管、内审、CRO、CTO 或 Audit Committee 随机挑一条 AI 可信性声明,
团队能在 10 分钟内拿出 scope、argument、evidence、owner、residual risk 和 monitoring,
这才是可运营的 AI assurance。