AI Fairness / Fair Lending / Bias Control Architecture 解读

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_FAIRNESS_FAIR_LENDING_BIAS_CONTROL_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

Source Anchors

核心导读

AI fairness 不是一个上线前指标，也不是把 protected class 从特征表里删掉就完成。金融服务里的 fairness 是产品边界、数据来源、代理变量、模型行为、人工复核、解释、客户救济、监控和证据共同构成的控制系统。

公平性架构要解决两个张力：一方面，决策执行中不能使用不被允许的属性或产生歧视性效果；另一方面，验证和监控公平性又需要对分群结果、代理变量、服务质量、投诉和申诉进行可控分析。成熟做法不是追求“一个公平分数”，而是按 use case、客户权益、法律语境和流程影响建立一组可解释、可追溯、可整改的 fairness controls。

可以把它理解为：

AI fairness architecture =
  fairness requirement
  + proxy-risk control
  + segment evaluation
  + process and human-review control
  + remediation path
  + governance evidence

1. 问题定义

公平性不只出现在正式信贷审批。AI 只要影响客户是否被鼓励申请、是否被优先服务、是否被标记为欺诈、是否被推送 offer、是否收到一致解释，就可能改变机会、成本、摩擦和权益。

金融零售中的偏见来源往往跨越数据、流程和组织边界。模型团队看到的是 feature 和 label，产品架构上还要看到 customer journey、人工队列、供应商模型、渠道语言、日志缺失、投诉处理和反馈循环。

2. 架构模型

Fairness architecture 的核心是把“公平性要求”从原则性声明转成可运行的控制图谱。这个图谱要连接客户权益、受影响决策、数据和代理变量、模型/系统评测、人工复核、监控指标、问题整改和证据。

fairness requirements
  -> use-case and customer-impact scope
  -> data/proxy assessment
  -> model/system segment evaluation
  -> process and human-review controls
  -> monitoring dashboard
  -> issue remediation
  -> governance evidence

关键架构对象：

受保护属性的处理是架构难点。训练、评估和监控可能需要分群证据，但决策执行中可能禁止使用某些属性；因此要把环境、权限、用途和留存分开设计。

3. 关键机制/生命周期

Fairness 不是上线前一次评估，而是随数据、客户组合、阈值、渠道、人工复核和监管语境持续变化的生命周期。

scope the decision
  -> define fairness requirements
  -> assess data and proxy risk
  -> evaluate model/system slices
  -> calibrate human review
  -> approve risk and controls
  -> monitor outcomes and service levels
  -> investigate disparity
  -> remediate data/model/process/UX/vendor
  -> retest and archive evidence

关键机制包括：

• Use-case scoping：先判断 AI 影响 eligibility、pricing、fraud flags、service routing、collections、marketing 还是 explanation；不同场景的公平性指标和阈值不同。
• Proxy challenge：不是只看显式敏感属性，而要识别邮编、语言、设备、渠道、职业、收入来源、商户类别等代理变量。
• Segment evaluation：不能只看总体准确率，要看 false positive、false negative、approval rate、service level、override、complaint、appeal 等分群差异。
• Human-review calibration：人工复核本身可能制造偏差，必须监控 reviewer 标准、覆盖率、队列分配和推翻率。
• Remediation branching：差异出现后，不一定通过调阈值解决；可能需要修数据、改流程、改解释、改渠道体验、改供应商配置或改人工队列。

没有一个指标能“证明公平”。指标组合必须由 use case、法律语境、业务目标和客户影响共同决定。

4. 证据与控制

Fairness evidence 要能证明三件事：组织知道哪些客户权益可能受影响，已经用合适切片和控制检查过，发现问题后有可追溯整改和复测。

一个实用的 fairness control map 不应是空表单，而应把字段作为可查询对象：

5. 金融零售/AI产品场景

Lending prequalification assistant

风险不是只有正式拒绝。预审话术可能让某些申请人放弃申请，预审建议和正式审批边界不清，解释不一致也会形成公平信贷风险。控制重点是 approved explanation templates、no discouragement policy、abandonment segment eval、reason-code source of truth 和客户可争辩路径。

Fraud alert triage

某些语言、地区、设备、商户或渠道组合可能 false positive 更高，导致账户冻结、验证负担和服务等待不公平。控制重点是 false positive disparity monitoring、queue fairness、customer impact review、appeal/upheld feedback loop 和恢复访问路径。

Collections prioritization

AI 可能优先联系特定群体、未识别 vulnerable customer、生成不一致话术或改变联系频率。控制重点是 vulnerability flag escalation、script governance、contact frequency guardrail、segment-level complaint KRI 和人工复核校准。

Customer service routing

AI 路由可能让某些语言、渠道或产品客户等待更久，或者把高风险投诉误判为低风险咨询。控制重点是 service-level disparity、complaint escalation recall、language-specific eval 和 abandoned journey monitoring。

6. 反模式

7. 最终心智模型

Fairness 是 AI 产品架构里的控制系统，不是模型验证报告的附录。它从“这个 AI 影响什么客户权益”开始，到“哪些差异不可接受、如何发现、谁修复、如何证明修复有效”结束。

最终要形成一条稳定链路：

customer right or service outcome
  -> fairness requirement
  -> data/proxy assessment
  -> segment evaluation
  -> process and human-review control
  -> monitoring
  -> remediation
  -> evidence

如果一个金融 AI 系统只能说总体指标提升，却不能说明哪些客户群、哪些渠道、哪些流程、哪些解释和哪些人工复核路径被公平性控制覆盖，它就还没有具备生产级 fair lending / bias control 能力。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。