AI Fairness / Fair Lending / Bias Control Architecture Playbook

定位: 面向 CBAP+、AI Product Manager、Product Architect、Risk Product Lead、Solutions Architect、Model Risk Partner 和金融零售 AI 治理负责人。本手册不是基础的多元化宣言, 而是把 AI fairness / fair lending / bias control 设计成可需求化、可架构化、可评估、可监控、可审计、可挑战的产品控制体系。

重要说明: 本文是学习、作品集和企业方案设计材料, 不构成法律意见、合规结论、模型验证报告或监管解释。正式项目必须由 Legal、Compliance、Fair Lending、Model Risk、Privacy、Security、Business Owner、Data Owner、Operations、Vendor Risk、Internal Audit 和管理层结合机构类型、司法辖区、产品范围、客户影响、数据授权和内部政策确认。

---

1. Source Anchors

以下官方来源是本手册的锚点。使用方式不是复制条文, 而是把监管和标准语言转成产品需求、控制目标、架构边界、评估设计、监控指标和 evidence binder。

学习纪律:

• 官方来源进入 Source Anchor -> Internal Policy -> Control Objective -> Requirement -> Test -> Evidence 链路。
• Fairness 不等同于某个数学指标, 也不等同于删除 protected attributes。
• Fair lending 相关判断必须由合规和法律团队确认, 产品与架构团队的职责是把事实、边界、数据、模型、流程、控制和证据讲清楚。
• 对跨司法辖区金融零售 AI, 应同时考虑信贷监管、消费者保护、隐私、模型风险、第三方风险、安全、记录留存、投诉、申诉和运营韧性。

---

2. Core Mental Model: Fairness 是产品和架构控制问题

2.1 一句话

AI fairness in financial retail is not a single model metric. It is a product and architecture control system that governs who is affected, which decision is influenced, what data and proxies are used, how segment outcomes are measured, how humans override, how customers are explained to, and how evidence is retained.

高级团队不要问: “这个模型公平吗?” 要问: “这个 AI 系统在这个业务流程、客户群、决策权、数据来源、人工复核、解释机制、监控窗口和残余风险边界下, 是否具备可证明的公平控制?”

2.2 从 metric thinking 到 control thinking

2.3 Control Plane 视角

Fairness control plane 应覆盖七个问题:

1. Scope: 哪些产品、客户、渠道、地区、决策和解释受影响。
2. Data: 哪些数据、标签、特征、文档和第三方信号进入系统。
3. Proxy: 哪些变量可能间接代表 protected class 或 vulnerable segment。
4. Decision: AI 输出如何影响 eligibility、pricing、prioritization、fraud flag、collections、service、marketing 或 explanation。
5. Human: 人工如何复核、覆盖、升级、纠错、补救和记录理由。
6. Monitoring: 上线后如何按 segment、channel、language、product、model version 和 reviewer group 监控。
7. Evidence: 如何证明控制被设计、测试、批准、运行、挑战和改进。

---

3. Fairness Scope: 金融零售中哪些决策要纳入

Fairness scope 不能只覆盖贷款审批。金融零售 AI 会在多个客户旅程中改变机会、价格、摩擦、服务质量和解释质量。

Scope decision 的实用规则:

• 只要 AI 改变客户获得产品、价格、服务、补救、人工关注、解释或申诉机会, 就纳入 fairness scope。
• 只要 AI 输出被员工当作事实、排名、风险分数、建议动作或客户话术, 就纳入 control plane。
• 即使 AI 只是 assistant, 如果它系统性影响人工判断, 也需要 segment evaluation 和 human review monitoring。

---

4. Bias Sources: 偏差不是只来自训练数据

NIST SP 1270 的重要启发是: bias 是 socio-technical problem。金融零售中, 偏差来自数据、制度、业务策略、流程、人工、供应商、部署和 UX 的组合。

高级 PM / Architect 要把 bias source 写进需求, 不是上线前让 Data Science 做一次报告。正确表达是:

For this use case, fairness risk can enter through historical labels, proxy features, missing documentation, model routing, reviewer behavior, language support, and post-decision feedback. Therefore, our requirements include protected attribute governance, proxy detection, segment evaluation, human review calibration, monitoring, and an evidence binder.

---

5. Requirements Architecture: 把公平性写成可验收需求

5.1 Fairness requirement 的结构

一个可执行的 fairness requirement 至少包含十个字段:

5.2 Requirement patterns

5.3 Non-functional requirements

Fairness 也要进入 NFR:

---

6. Bias Control Architecture

6.1 Reference architecture

Use case intake
-> Customer impact and legal scope assessment
-> AI / model / vendor inventory
-> Data lineage and feature inventory
-> Protected attribute governance and proxy estimation for testing
-> Proxy-risk analysis and feature challenge
-> Segment evaluation and fairness metric pack
-> Policy constraints and decision guardrails
-> Human review design and calibration
-> Release gate and risk acceptance
-> Production monitoring and alerting
-> Issue remediation, customer correction, model change control
-> Evidence binder and audit / regulator response

6.2 Protected attribute handling

Protected attribute handling 是公平性架构中最容易被误解的部分。高级方案不是简单使用或删除, 而是按用途分区。

设计要点:

• Data minimization: 只收集、生成和保留达到 fairness testing / compliance 目的所需的数据。
• Purpose limitation: 区分 monitoring / audit / validation 与 production decisioning。
• Access segregation: 能做 fairness analysis 的团队不一定能改生产模型; 能改模型的团队不一定能看个人级 protected data。
• Lineage: 记录 protected attribute 来源、采集依据、估算方法、刷新频率、质量限制和使用范围。
• Retention: 与 Reg B、模型风险、内部政策、诉讼保全和隐私要求对齐。

6.3 Proxy detection

Proxy risk control 的目标不是机械删除所有相关变量, 而是识别哪些变量可能导致不正当差异影响, 并证明业务必要性、替代方案和控制措施。

Proxy-risk register 至少记录:

• feature / signal / vendor score 名称
• 业务用途和业务必要性
• 与 protected attribute / proxy estimate 的关系
• 对结果的边际影响
• 可替代变量或策略
• 监控指标
• owner 和批准记录
• 保留、限制、移除或替代的决定理由

6.4 Segment evaluation

Segment evaluation 要同时看 outcome、error、calibration、process、explanation 和 remediation。

Intersectionality 要进入抽样设计。只看单一维度会掩盖风险, 例如:

• race proxy + gender + age band
• language + channel + geography
• self-employed + documentation type + product
• branch customer + digital customer + call center customer
• new-to-credit + thin-file + immigrant documentation pattern

6.5 Policy constraints and guardrails

在金融零售中, fairness 不能只靠模型训练。系统必须把政策约束写成可执行控制。

6.6 Human review calibration

人工复核不是 fairness 的装饰, 是一个需要设计和监控的控制。

Reviewer dashboard 应包含:

• assigned case mix by segment
• approve / decline / escalate / override rate
• average handling time and queue age
• reason-code edits
• QA defects
• customer complaint and appeal linkage
• drift versus peer group and historical baseline

6.7 Monitoring and alerting

上线后监控要覆盖模型、业务、流程、人工和客户反馈。

Alert design:

• Hard stop: production decisioning or explanation generation is paused for affected flow when evidence shows severe unsupported adverse action, unauthorized feature use, or broken monitor.
• Release hold: new model / prompt / policy / vendor version cannot expand until segment evaluation passes or risk acceptance is approved.
• Enhanced review: high-risk segment, channel or product enters increased manual review and QA sampling.
• Remediation workflow: issue owner, root cause, affected population, customer correction, retraining or policy change are tracked to closure.

6.8 Evidence binder

Evidence binder 是 fairness control 的审计接口。它应该让内部审计、模型验证、合规或监管检查人员能够重建: 什么系统、影响谁、依据什么、如何测试、谁批准、上线后如何监控、问题如何修复。

---

7. Metrics and Tradeoffs

7.1 Metric families

7.2 Tradeoff map

7.3 Metric selection by use case

---

8. Financial Retail Cases

8.1 Lending prequalification

Scenario: AI 模型用于个人贷款预审排序, 决定哪些客户看到 prequalified offer 或进入人工 follow-up。

Design:

• Decision boundary: AI 只做预审排序和 invitation recommendation, final credit decision 仍由 approved credit decision engine 和授权人员执行。
• Protected attribute handling: production 不使用 protected attributes; fair lending testing zone 使用 approved protected-class data 或 proxy estimates 做 segment analysis。
• Proxy controls: ZIP、branch、device、education、employment stability、language、marketing channel 进入 proxy-risk register。
• Segment evaluation: approval proxy, prequalification exposure, application completion, downstream approval, pricing distribution, false negative for qualified customers。
• Explanation: 预审说明不能暗示最终批准; adverse action reason 来自真实信贷决策, 不由 LLM 生成。
• Monitoring: offer exposure disparity、application abandonment、counteroffer rate、manual override、complaints。
• Evidence: feature review, less discriminatory alternative memo, segment eval matrix, release approval, monthly dashboard。

Failure mode:

• 模型不直接拒贷, 但只把 offer 给某些渠道客户, 造成机会分配差异。
• Marketing team 把 prequalification 当纯增长工具, 忽视 fair lending exposure。

Architect answer:

Prequalification is not low risk just because it is not final underwriting. It changes who receives a credit opportunity. I would govern it as a credit access control with exposure parity, proxy review, reason-code boundary, and downstream approval monitoring.

8.2 Credit explanation assistant

Scenario: LLM 帮客服或客户解释信用申请结果、原因码、补件要求和 reconsideration 路径。

Design:

• Source control: LLM 只能使用 approved decision record、reason code、policy source、notice template 和 FAQ。
• Reason fidelity: 每个解释句子必须追溯到真实 reason code 或政策条款。
• No invented adverse action: 系统不得编造“收入不足”“信用历史短”等未出现在 decision record 中的原因。
• Language parity: English、Spanish、Chinese 等语言解释需要同等具体性、可读性和申诉路径。
• Human oversight: 客户发送前由授权人员确认高风险解释; chatbot 自助解释要有 escalation。
• Monitoring: unsupported reason rate、translation defect、complaint、appeal confusion、agent edit rate。

Failure mode:

• LLM 为了“更有帮助”补充听起来合理但不真实的拒绝原因。
• 不同语言版本把 specific reasons 变成泛泛表达, 影响客户理解和申诉。

Architect answer:

For credit explanations, the model is not the source of truth. The source of truth is the approved decision record and reason-code engine. The LLM can translate and explain, but it cannot create reasons.

8.3 Fraud alert triage

Scenario: AI 对交易或账户行为排序, 决定哪些 alert 被拦截、升级、释放或要求 step-up authentication。

Design:

• Harm model: false positive 可能造成账户冻结、交易失败、工资不可用、客户羞辱和投诉。
• Segment eval: false positive disparity, confirmed fraud rate calibration, freeze duration, release SLA by language / channel / geography。
• Step-up design: 优先使用可逆、低摩擦验证, 避免直接冻结成为默认动作。
• Human calibration: investigator override、release decision、case aging 按 segment 监控。
• Vendor challenge: vendor fraud score 必须在机构数据上 backtest, 不能只看 global performance。
• Customer remediation: 错误冻结有明确释放、道歉、费用补偿和投诉处理流程。

Failure mode:

• 某些移民客户或跨境交易客户因行为不同被高频误报。
• 高风险队列积压导致某类客户冻结时间更长。

Architect answer:

Fraud fairness is not about approving fraud. It is about controlling unnecessary customer friction and false positives while still managing loss. The key metrics are false positive disparity, freeze duration, step-up success, and investigator override parity.

8.4 Collections prioritization

Scenario: AI 为逾期客户推荐 next-best-action: 短信、电话、延期、还款计划、困难客户支持或停止联系。

Design:

• Policy constraints: 联系频率、时间窗口、禁止话术、vulnerable customer safeguards 和 hardship policy 写成规则。
• Segment eval: contact frequency disparity, hardship false negative, repayment plan access, complaint rate, cure rate。
• UX fairness: 数字渠道不可达客户不能因此被过度电话联系; 语言客户应获得等价 hardship 说明。
• Human review: reviewer 必须记录为什么选择加强联系、降级联系或提供救助。
• Monitoring: vulnerable customer detection QA、complaint coding、right-party contact、agent script adherence。

Failure mode:

• 模型把“高回款概率”客户排到前面, 导致某些困难客户被高频联系, 而救助方案暴露不足。
• 优化回款率挤压客户保护指标。

Architect answer:

Collections AI must optimize risk-adjusted recovery under customer protection constraints. The objective function cannot be pure dollars collected; it must include contact policy, hardship support, complaint risk, and segment-level treatment.

8.5 Branch / customer-service routing

Scenario: AI 根据客户问题、价值、情绪、语言和风险把客户路由到 chatbot、call center、branch specialist 或 complaint team。

Design:

• Service-level parity: 等待时间、转人工率、一次解决率、投诉升级率按 segment 监控。
• Accessibility: 老年客户、残障客户、低数字能力客户和非英语客户必须有可达路径。
• Model routing: 不同语言或渠道不能被路由到低质量模型或更长等待队列。
• Human review: 高风险投诉、威胁、欺诈、信贷、费用争议必须升级到授权队列。
• Monitoring: abandonment、repeat contact、sentiment misclassification、resolution disparity。

Failure mode:

• 高价值客户更快进入人工, 低余额客户长期困在 chatbot。
• 非英语客户被默认转低质量翻译流程, 导致投诉和误解增加。

Architect answer:

Service routing creates fairness risk because it controls access to human help. I would treat service quality, wait time, escalation access, and resolution outcome as fairness metrics, not just operations metrics.

---

9. Artifact Templates

9.1 Fairness Requirement Canvas

9.2 Segment Eval Matrix

Matrix 使用规则:

• 不只填 selection rate, 必须同时填 error、calibration、process 和 explanation。
• 对小样本 segment 使用置信区间、rolling window 和 qualitative review。
• 每个 finding 必须有 action、owner 和复核日期。

9.3 Proxy-Risk Register

9.4 Fairness Control Map

9.5 Monitoring Dashboard Template

9.6 Model / Vendor Challenge Memo

---

10. Governance Operating Model

10.1 Roles and RACI

10.2 Release gates

10.3 Issue management

Fairness issue 不应停留在 dashboard。它要进入 formal issue workflow:

---

11. Common Architecture Anti-Patterns

---

12. Interview Section

12.1 30-second answer

我不会把 AI fairness 当成单个模型指标, 而是把它设计成金融服务的产品和架构控制体系。第一步定义 AI 影响的决策: eligibility、pricing、fraud flag、collections、service routing 或 explanation。第二步设计 protected attribute handling、proxy-risk review、segment evaluation 和 reason-code fidelity。第三步把 human review、monitoring、alert、issue remediation 和 evidence binder 接入上线门禁。这样既能看 disparate impact、false positive / false negative disparity、calibration 和 service-level disparity, 也能证明控制被执行过。

12.2 2-minute answer

在金融服务里, AI fairness 的核心不是“模型有没有用敏感字段”, 而是 AI 系统是否在真实业务流程中造成不公平机会、价格、摩擦、服务或解释。我的设计会分五层。

第一层是 scope 和 decision authority。先确认 AI 影响的是信贷资格、定价、预审、欺诈拦截、催收优先级、客服路由、营销触达还是 adverse action explanation, 并明确 AI 是否只是 assistant、ranking tool、recommendation engine 或 final decision component。

第二层是 data and proxy control。protected attributes 通常不进入生产决策特征, 但在法律和合规批准下可以进入隔离的 fairness testing zone。对 ZIP、语言、渠道、设备、雇佣、教育、地理和 vendor score 做 proxy-risk analysis, 评估业务必要性和替代方案。

第三层是 evaluation。除了总体 AUC 或 loss, 我会按受保护或敏感 segment 做 selection rate、disparate impact、equal opportunity、false positive disparity、false negative disparity、calibration、service-level disparity、override disparity 和 explanation fidelity。对信贷场景, adverse action reason 必须来自真实决策记录和 approved reason-code mapping, LLM 不能编造原因。

第四层是 operational control。设计 human review calibration、blind sample、override logging、queue SLA、complaint / appeal linkage、monitoring dashboard、alert threshold、pause / rollback criteria 和 customer remediation。

第五层是 governance and evidence。每个高影响 use case 都要有 source anchors、policy mapping、data lineage、proxy register、segment eval matrix、model / vendor challenge memo、release approval、monitoring snapshots 和 issue log。这样公平性不是一次性评审, 而是贯穿 discovery、design、validation、release、operate 和 change management 的控制平面。

---

13. Portfolio Exercise

目标: 设计一个“个人贷款 AI 预审 + 信用解释助手”的 fairness / fair lending control package, 可作为 CBAP+ / AI PM / Product Architect / Risk Product Lead 面试作品集。

13.1 Case brief

一家金融零售机构计划上线 AI-powered personal loan prequalification。系统用客户交易、信用局数据、营销响应、数字行为和历史申请数据生成预审排序。通过预审的客户会看到 offer banner, 可继续申请。客服端还有一个 LLM assistant, 用于解释预审、补件、拒绝原因和 reconsideration 路径。

13.2 Deliverables

13.3 Success criteria

• 能说明为什么 prequalification 也会产生 fair lending exposure。
• 能解释为什么 protected attributes 可以被隔离用于 fairness testing, 但不默认进入 production decisioning。
• 能识别至少五类 protected-class proxy risk, 并给出业务必要性和替代方案分析。
• 能定义 segment evaluation, 覆盖 outcome、error、calibration、process、explanation 和 human override。
• 能说明 adverse action reason 为什么不能由 LLM 自由生成。
• 能给出上线前 release gate 和上线后 monitoring / remediation 流程。
• 能把每个控制映射到 evidence binder, 支撑审计或监管问询。

---

14. Practitioner Checklist

14.1 Discovery

• 是否明确 AI 影响的 decision context: eligibility、pricing、prioritization、fraud / AML flags、service、collections、marketing、explanations。
• 是否定义客户伤害: 机会缺失、价格更高、误拦、等待更久、补件负担、错误解释、申诉受阻。
• 是否完成 legal / compliance / fair lending applicability review 的事实准备。
• 是否登记 AI asset、model、vendor、data source、decision owner 和 human owner。

14.2 Data and feature

• 是否有 data lineage、label definition、feature inventory 和 third-party signal inventory。
• 是否区分 production decisioning features 与 fairness testing data。
• 是否对 protected attribute / proxy estimate 做访问控制、用途限制、留痕和保留设计。
• 是否完成 proxy-risk register, 包含业务必要性、替代方案和监控指标。
• 是否分析 missingness、channel coverage、language coverage 和 historical label bias。

14.3 Evaluation

• 是否按 segment 和 intersectional slice 评估。
• 是否同时覆盖 selection / outcome、false positive、false negative、calibration、process SLA、explanation 和 override。
• 是否记录 baseline、comparator、threshold、置信区间和小样本处理方法。
• 是否对 adverse action reason、credit explanation 和 translation 做 QA。
• 是否把 evaluation 结果转成 release decision, 而不是只存报告。

14.4 Architecture and operations

• 是否有 feature whitelist、policy constraints、reason-code control、routing constraints 和 experiment guardrails。
• 是否定义 human review authority、blind sample、override reason、reviewer calibration 和 QA sampling。
• 是否能按 customer、case、model version、prompt version、policy version、reviewer、vendor version 重建记录。
• 是否有 rollback、pause、enhanced review 和 customer remediation criteria。
• 是否把 fairness monitors 纳入 production observability, 而不是离线分析。

14.5 Governance and evidence

• 是否有 fair lending / model risk / legal / business sign-off 或正式 risk acceptance。
• 是否有 model / vendor challenge memo, 覆盖 institution-specific backtest 和 change control。
• 是否有 evidence binder, 覆盖 source anchors、policy mapping、data、model、eval、human review、release、monitoring、issue remediation。
• 是否定义 monitoring cadence、alert owner、issue SLA 和治理报告节奏。
• 是否把投诉、申诉、客户补救和监管问询纳入 feedback loop。

---

15. Final Operating Principle

金融零售 AI 公平性的成熟度, 不在于团队能说出多少 fairness metrics, 而在于能否把公平性变成可运行的控制平面:

Fairness requirement
-> data and proxy governance
-> segment evaluation
-> policy and human controls
-> release gate
-> monitoring and issue management
-> customer remediation
-> evidence binder
-> governance challenge

高级 CBAP+ / AI PM / Architect 的价值, 是把“模型是否公平”这个抽象问题拆成产品边界、流程责任、架构控制、评估证据和治理决策。这样团队才能在不牺牲创新速度的情况下, 对客户机会、公平待遇、监管问责和组织信任负责。