AI Explainability / Contestability / Adverse Action Playbook

定位：面向 CBAP+、AI Product Manager、AI Product Architect、Compliance Product Lead、Solutions Architect 的金融零售 AI 解释性、可争议性和不利行动通知设计手册。本文不是通用 XAI 算法笔记，而是把 explainability 设计成客户可理解、监管可追溯、模型验证可评估、工程可复现、申诉可处理、审计可证明的产品与控制体系。

重要说明：本文是学习、作品集和内部治理训练材料，不构成法律意见、合规结论、审计意见、模型验证报告或监管解释。正式项目必须由 Legal、Compliance、Fair Lending、Model Risk、Privacy、Security、Customer Complaint、Business Owner 和管理层结合机构类型、司法辖区、产品类型、客户群体、数据来源和内部政策确认。

---

Source Anchors

以下官方来源是本文的治理锚点。本文把它们转成产品、流程、架构、评估和证据语言，不把任何法规或框架简化成单一检查项。

---

1. 核心心智模型：Explanation 是受治理的产品接口

Explainability 在金融零售 AI 中不是“让模型把思考过程说出来”，也不是把 SHAP chart 贴给客户。正确心智模型是：

AI explanation =
一个受治理的产品接口，
在特定客户、特定决策、特定政策、特定模型/规则/数据版本下，
向不同受众提供相称、准确、一致、可验证、可争议的解释，
同时保留足以复现、复核、申诉、纠错和审计的证据链。

这意味着 explanation 不是 raw chain-of-thought。客户、审核员、监管人员、模型验证团队和工程师需要看到的是经过治理的 evidence、reason、policy mapping、data lineage、decision boundary、model/system version、human review action 和 outcome，不是模型内部随口生成的一段看似合理的叙述。

1.1 五个常见误区

1.2 Product Architect 的核心问题

设计 explainability / contestability / adverse action 时，先回答七个问题：

1. 哪些系统或人员作出了客户影响性决定？
2. 决定是否属于 adverse action、重要资格判断、费用处置、账户限制、欺诈处置或投资/保险适当性判断？
3. 客户看到的解释、内部人审看到的证据、审计看到的证据是否来自同一决策事实？
4. reason code 的 source of truth 是模型、规则引擎、策略表、人工决定，还是组合决策服务？
5. LLM 是否被允许生成原因？如果不允许，它能做什么改写、摘要或问答？
6. 客户如何纠错、补充证据、申诉、获得复核和收到结果？
7. 六个月后监管问询某个 case 时，团队能否复现当时的输入、输出、版本、证据、通知和复核动作？

---

2. Explainability 分层架构

同一个 AI 决策不能只生成一种解释。金融零售系统至少需要五层 explanation artifact。

2.1 五层之间的关系

Decision facts
  -> reason-code source of truth
  -> evidence graph
  -> user-facing explanation
  -> contestability case package
  -> audit / validation / engineering views

关键原则：客户解释可以更简洁，但不能与内部证据矛盾；内部证据可以更详细，但不能事后重写客户收到的原因；工程 trace 可以帮助排错，但不能替代合规批准过的 reason architecture。

2.2 Explanation View Contract

每个客户影响性 AI 用例都应定义一个 explanation view contract。

---

3. Adverse Action Reason Architecture

Adverse action reason 是一个受控架构，不是最后由 AI “总结一下为什么拒绝”。在信贷等受 Regulation B / ECOA 影响的场景中，核心不是解释听起来是否合理，而是 reason 是否 specific、principal、accurate、actually considered or scored、consistent、timely，并且能映射到可审计证据。

3.1 决策代码 Source of Truth

Reason code 的 source of truth 必须位于正式决策系统或 reason attribution service，而不是 LLM。

Application data
  -> feature pipeline / rules input
  -> policy rules + model score + constraints
  -> decision orchestration
  -> reason attribution service
  -> approved reason codes
  -> customer notice / internal evidence / audit package

3.1.1 Source of truth 设计原则

3.2 禁止模型自行发明原因

LLM 可以帮助把 approved reason 转成更易懂的 customer explanation，但不能发明 reason。尤其在 adverse action 中，必须明确禁止以下模式：

3.2.1 LLM 在 adverse action 中可以做什么

3.3 Reason-Code Catalog

Reason-code catalog 是 adverse action reason architecture 的核心资产。

3.4 Reason Mapping to Evidence

每个 reason 必须能映射到 evidence，不是只映射到 feature name。

3.5 模板治理

Adverse action template 不能由渠道团队随意改写。模板治理至少包括：

3.6 Consistency Eval

Consistency eval 的目标是证明同一事实不会在不同渠道、不同模型版本、不同语言和不同客服回合中产生冲突 reason。

---

4. Contestability Architecture

Contestability 是客户对解释、数据、结论或处理结果提出争议并获得有效复核的能力。它不是情绪安抚，也不是客服 ticket。它是一个有权利入口、case 类型、证据提交、人工复核、数据纠正、重跑决策、结果通知和审计记录的产品架构。

4.1 Contestability 目标

4.2 End-to-End Workflow

Customer receives explanation / adverse action notice
  -> Customer opens dispute / appeal / reconsideration
  -> Intake classifies issue type and urgency
  -> Identity and authorization check
  -> Evidence package assembled
  -> Customer submits correction or additional evidence
  -> Human reviewer evaluates facts, policy and system decision
  -> Data correction workflow if source data is wrong
  -> Decision re-run or manual reconsideration
  -> Outcome decision recorded
  -> Customer outcome notification
  -> Metrics, complaint linkage, audit retention

4.3 Contestability Case Types

4.4 Human Review Design

人工复核不是“看一眼 AI 结论”。复核界面应把证据结构化呈现：

4.5 Correction and Re-run

当客户指出数据错误时，不能只在申诉系统里写备注。需要明确 corrected data 如何进入重新决策。

Customer correction
  -> source validation
  -> data owner approval
  -> corrected data object / suppression flag
  -> feature recomputation
  -> reason attribution re-run
  -> decision re-evaluation
  -> new notice or outcome letter
  -> audit linkage to original decision

4.5.1 Re-run Controls

4.6 Outcome Notification

申诉结果通知也需要治理，不能只写“经审核维持原决定”。

---

5. Financial Retail Cases

5.1 Credit Denial Explanation Assistant

场景

客户申请信用卡被拒绝，收到 adverse action notice 后在 mobile app 中询问：“为什么我被拒？我怎么改善？”

目标架构

Credit decision engine
  -> reason attribution service
  -> adverse action notice service
  -> explanation assistant retrieval layer
  -> approved FAQ / reason catalog / customer notice
  -> dispute and reconsideration workflow

设计要点

不允许

• Assistant 根据申请表内容猜测“可能因为收入太低”。
• Assistant 把模型分数、拒绝阈值或内部策略细节直接告诉客户。
• Assistant 输出与正式 adverse action notice 不同的原因。
• Assistant 说“AI 决定了您的申请，因此无法解释”。

5.2 Overdraft Fee Explanation

场景

客户被收取透支费，AI 客服解释交易顺序、余额变化、豁免政策和争议路径。

关键风险

客户解释结构

1. 发生了什么：哪一笔交易导致可用余额低于 0
2. 费用依据：适用的账户条款和费用政策
3. 关键时间线：授权、入账、余额变化
4. 可争议路径：如果交易不是本人、余额显示有误或需要困难援助
5. 下一步：提交争议、请求豁免、联系人工

5.3 Fraud False Positive

场景

客户正常交易被 AI 欺诈模型拦截，账户被临时限制。

解释边界

欺诈解释必须避免泄露规避规则，但仍要告诉客户状态、原因类别和解决路径。

Contestability 设计

Customer confirms transaction
  -> step-up authentication
  -> analyst review if high risk
  -> unblock / maintain restriction
  -> customer notification
  -> false-positive label governance
  -> monitoring of repeat false positives by segment

关键 KRI：false positive appeal upheld rate、restriction duration、customer complaint linkage、segment disparity in fraud holds、repeat hold rate。

5.4 Insurance / Wealth Suitability Explanation

保险和财富场景不一定使用 adverse action notice 语言，但仍需要 explanation and contestability。

财富和保险解释的核心是避免把 AI 生成的自然语言伪装成个性化专业建议，除非产品、牌照、披露、适当性和记录保留均支持该建议边界。

---

6. Artifact Templates

6.1 Explanation Policy

6.2 Reason-Code Mapping Template

6.3 Explanation Faithfulness Eval Template

6.4 Contestability Workflow Template

6.5 Adverse Action Evidence Pack

每个 adverse action case 应能生成一个 evidence pack。

6.6 Audit Query Catalog

---

7. Metrics and KRIs

Explainability 和 contestability 的指标不能只看“用户点击率”。金融零售要同时看正确性、一致性、公平性、可操作性、运营效率和合规风险。

7.1 Core Metrics

7.2 Operational Dashboard

7.3 Threshold and Escalation

---

8. Provenance and Audit Evidence Architecture

W3C PROV 的价值在于把“谁用什么数据，通过什么活动，生成了什么结果”结构化。金融零售 explanation evidence 可以借鉴 entity / activity / agent 的思路。

8.1 PROV 风格对象

8.2 Evidence Graph Example

Customer application snapshot A
  wasGeneratedBy intake activity I
  wasUsedBy feature computation F

Feature vector V
  wasGeneratedBy F
  used bureau file B and stated income S

Decision D
  wasGeneratedBy decision activity X
  used V, model M v3.8, ruleset R 2026-Q2

Reason code RC1
  wasDerivedFrom D and feature group FG17
  wasMappedBy reason catalog C v12

Notice N
  wasGeneratedBy notice service NS
  used template T v4 and reason codes RC1, RC2

Appeal case AC
  wasStartedBy customer CUST
  used Notice N and customer upload U
  wasReviewedBy reviewer HR1

8.3 Evidence Store Requirements

---

9. Requirements for BA / PM / Architect

9.1 Business Requirements

9.2 Functional Requirements

9.3 Non-Functional Requirements

---

10. Implementation Blueprint

10.1 Reference Components

10.2 Sequence

1. Customer applies / transaction occurs / account event happens
2. Decision Orchestrator calls model, rules and policy services
3. Reason Attribution Service derives approved reason codes
4. Evidence Graph Store receives decision snapshot and provenance bundle
5. Explanation Composer generates notice or explanation using approved templates
6. Guardrail checks reason support, policy version, language and leakage
7. Notice Service delivers customer communication and archives proof
8. Customer asks follow-up through assistant or starts appeal
9. Contestability Case System assembles evidence pack
10. Human reviewer resolves case and triggers re-run if needed
11. Audit and Metrics Layer updates KRIs and retention records

10.3 Build vs Buy Questions

---

11. Governance Operating Model

11.1 RACI

11.2 Change Management

任何以下变更都应触发 explanation impact assessment：

• 模型版本、scorecard、ruleset、threshold 或 policy rule 变更。
• reason catalog 新增、合并、停用或文本改写。
• notice template、渠道文案、客服脚本、LLM prompt 或 RAG knowledge base 变更。
• 供应商数据源、bureau mapping、income verification provider、fraud signal provider 变更。
• 申诉流程、SLA、人工复核权限或 outcome templates 变更。
• 监控阈值、fairness segment、complaint taxonomy 变更。

11.3 Release Gate

上线前必须通过：

---

12. Interview Section

12.1 30-second answer

我会把 explainability 设计成受治理的产品接口，而不是让模型输出 raw chain-of-thought。核心是先建立 decision reason source of truth：adverse action reason code 必须来自决策系统、规则、模型归因和证据映射，禁止 LLM 自行发明原因。然后按受众分层：客户看到简明、可行动的解释和申诉入口；审核和监管看到 reason、证据、版本、通知和人审记录；模型验证看 faithfulness、consistency 和公平性指标。最后把 contestability 做成完整 workflow：客户可争议、可补充材料、人工复核、纠错、重跑、结果通知，并用 evidence pack 支撑审计。

12.2 2-minute answer

在 regulated financial AI 中，我不会把 explainability 当成一个模型特性，而会把它当成一个 end-to-end control and product architecture。第一步是界定场景：是信贷 adverse action、透支费解释、欺诈误报、财富适当性，还是普通客服说明。不同客户影响对应不同解释深度和审计要求。

第二步是建立 reason architecture。以信贷为例，reason code 必须有 source of truth，来自 decision engine、ruleset、model attribution 或人工复核系统，并且要映射到 evidence object、policy version 和 customer template。LLM 不能发明拒绝原因，只能在 approved reason 和 approved evidence summary 之内做 plain-language explanation。这样才能保证正式 notice、客服脚本、chatbot 回答和审计材料一致。

第三步是 explanation layering。客户层解释要清楚说明主要原因、使用信息类型、客户可以做什么；监管和内审层要看到 notice、reason、证据、版本、发送时间和人审记录；模型风险层要评估 reason faithfulness、stability、segment disparity 和 model upgrade drift；工程层要保留可复现 trace，但不能把 debug trace 或 raw reasoning 暴露给客户。

第四步是 contestability。解释如果不能被争议，只是单向通知。我要设计 dispute / appeal intake、身份验证、证据包组装、人工复核、数据纠正、用 corrected data 重跑或重裁、结果通知和投诉联动。指标上我会看 explanation correctness、unsupported reason rate、appeal upheld rate、segment disparity in explanations、stale policy citation、human override、complaint linkage 和 reproducibility rate。这样 explainability 才从“看起来透明”变成可运营、可审计、可合规的系统能力。

---

13. Portfolio Exercise

13.1 练习题：设计一个信用卡拒绝解释与申诉系统

背景：一家区域银行计划上线 AI-assisted credit card underwriting。模型参与申请评分，规则引擎处理政策拒绝，人审处理边界样本。你要设计客户拒绝解释助手、adverse action notice reason pipeline、申诉流程和审计证据包。

交付物

13.2 Suggested Architecture Diagram Text

[Application Channels]
      |
[Decision Orchestrator] -- [Rules Engine]
      |                   -- [Model Scoring Service]
      |                   -- [Manual Review Workbench]
      |
[Reason Attribution Service]
      |
[Reason Catalog + Policy Registry]
      |
[Explanation Composer + LLM Guardrails]
      |
[Notice Service] ---- [Customer Explanation Assistant]
      |                         |
[Evidence Graph Store]          |
      |                         |
[Contestability Case Management + Human Review]
      |
[Audit Query + KRI Dashboard]

13.3 Evaluation Scenarios

---

14. Checklist

14.1 Product and Compliance Checklist

• 每个客户影响性 use case 已完成 risk tier 和 regulatory impact assessment。
• adverse action reason 的 source of truth 不在 LLM。
• reason catalog 已定义 owner、版本、适用范围、证据要求和停用机制。
• 客户解释、notice、客服脚本和 chatbot 回答使用同一 reason source。
• LLM 输出被限制在 approved reason、approved template 和 approved evidence summary 内。
• 客户能清楚看到纠错、申诉、补充材料、人工联系和结果通知路径。
• 申诉流程支持 human review、source data correction、re-run / reconsideration 和 outcome notification。
• 高风险 case 支持 maker-checker、supervisor approval 或 specialized review。
• 模板已通过 Legal、Compliance、Fair Lending、Accessibility 和 Business review。
• 多语言解释经过语义一致性检查。

14.2 Architecture and Data Checklist

• decision_id 能贯穿申请、决策、reason、notice、chat、appeal、audit。
• 原始 decision snapshot、feature snapshot、model version、ruleset version 和 policy version 可保留并复现。
• 每个 reason code 映射到 evidence object，不只映射到自然语言。
• evidence pack 自动生成，不依赖人工事后整理。
• debug trace 与 customer-facing explanation 分层存储和授权访问。
• fraud / risk sensitive details 有披露边界和 redaction policy。
• stale policy citation validator 已接入 notice 和 assistant。
• audit query catalog 覆盖 notice timeliness、reason consistency、appeal outcomes、segment disparity。
• release pipeline 包含 reason drift、template regression 和 LLM faithfulness eval。
• data correction workflow 不覆盖原始 snapshot，而是产生可追溯 corrected data object。

14.3 Metrics and Operations Checklist

• explanation correctness 被抽样和自动化监控。
• unsupported reason rate 有阻断阈值和事件升级。
• appeal upheld rate 按 reason、产品、渠道、segment 分解。
• segment disparity in explanations 定期进入 Fair Lending / Compliance review。
• stale policy citation rate 有 owner 和修复 SLA。
• human override rate 被用于识别 automation bias 或模型质量问题。
• complaint linkage 能把 explanation failure 与投诉、监管投诉、社媒升级连接。
• contestability completion rate 和 drop-off 被用于优化客户旅程。
• reviewer training 覆盖 AI limitations、reason policy、bias、customer vulnerability 和 evidence review。
• 每次重大 incident 后更新 reason catalog、eval set、workflow 和 audit queries。

---

15. 一页总结

金融零售 AI 的 explainability 不是展示模型“为什么这么想”，而是把客户影响性决策变成可解释、可争议、可复核、可纠正、可审计的产品能力。最关键的架构决策是把 reason code source of truth 从 LLM 中剥离出来，放到受治理的 decision / reason attribution layer；把客户解释、内部证据、模型验证、工程 trace 和 internal reasoning traces 分层；把 adverse action reason 与 evidence、template、policy、version 和 notice 绑定；把 contestability 做成端到端 case workflow；把 audit evidence 设计成运行时自动生成的 provenance graph。

一句话作品集表达：

I design explainability as a governed product interface: reason codes come from the decision system, explanations are audience-layered, adverse action notices are evidence-backed and consistent, contestability is a full appeal and correction workflow, and every decision produces an audit-ready provenance package.