AI Customer Vulnerability：可访问与包容性架构
Inclusive AI 不是“更有同理心的 chatbot”。在金融零售里，它是一套 customer-outcome control system：把客户在某段旅程中的支持需求、可访问性需求和高伤害风险识别出来，用最小侵入的方式提供帮助，并证明客户没有因为处境困难、沟通障碍或数字无障碍需求而受到更差服务。
AI Customer Vulnerability / Accessibility / Inclusive AI Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_CUSTOMER_VULNERABILITY_ACCESSIBILITY_INCLUSIVE_AI_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
重要说明: 本文只讨论金融零售 inclusive AI 的产品与架构设计，不构成法律、监管、ADA/WCAG 合规认证、消费者保护、医疗/心理判断、能力评估、信贷/保险/投资建议、模型验证或客户通知结论。真实项目必须由 Legal、Compliance、Accessibility、Customer Experience、Conduct Risk、Privacy、Model Risk、Operational Risk、Frontline Operations、Complaint Operations、Fraud/Scam Risk、Product、Data Governance、Information Security 等共同确认。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| WCAG 2.2 | https://www.w3.org/TR/WCAG22/ | 用 Perceivable / Operable / Understandable / Robust 及 success criteria 建立数字渠道和 AI interface 的 accessibility baseline |
| DOJ ADA web guidance | https://www.ada.gov/resources/web-guidance/ | 用 ADA web accessibility guidance 训练 web/mobile/AI self-service 渠道的可访问性治理语言 |
| CFPB compliance circulars landing page | https://www.consumerfinance.gov/compliance/circulars/ | 用 consumer financial protection、unfair/deceptive/abusive conduct、servicing、complaints 和市场行为风险的监管语言组织 conduct-risk thinking；具体 circular 适用性须由合规/法律判断 |
| FTC advertising and marketing guidance | https://www.ftc.gov/business-guidance/advertising-marketing | 用 truthful marketing、substantiation、dark patterns、endorsement/claim control 的思想约束 AI-generated advice、sales script、hardship offer 和 vulnerability-sensitive messaging |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 vulnerable-customer AI risk、harm taxonomy、control effectiveness、monitoring 和 continuous improvement |
| ISO/IEC 42001 overview | https://www.iso.org/standard/42001 | 用 AI management system、policy、roles、operation、performance evaluation、audit 和 improvement 建立 inclusive AI operating model |
核心导读
Inclusive AI 不是“更有同理心的 chatbot”。在金融零售里，它是一套 customer-outcome control system：把客户在某段旅程中的支持需求、可访问性需求和高伤害风险识别出来，用最小侵入的方式提供帮助，并证明客户没有因为处境困难、沟通障碍或数字无障碍需求而受到更差服务。
AI 改变的是服务处理链的早期判断。传统流程往往等客户明确投诉、失败多次或进入人工队列后才补救；AI 可以在交互摩擦、客户陈述、账户事件、语言偏好、欺诈/诈骗信号和员工观察中发现 support need，并动态调整说明方式、渠道、handoff、safe pause 或 specialist review。但这种能力也会引入新的伤害：把情境信号变成人格标签，把保护变成剥夺自主权，把困难信息用于销售或定价，把弱 sentiment 推断当作事实。
因此，本篇的学习重点是“情境支持”而不是“识别脆弱客户”。证据链要能重放客户说了什么、系统观察到什么、AI 建议了什么、最终客户看见/听见什么、人工如何决定、投诉如何闭环。治理边界要明确禁止诊断式推断、永久标签化、无目的敏感信息扩散和基于 vulnerability signal 的商业利用；高伤害场景需要可解释升级、人工复核、可访问替代渠道和可撤回的客户偏好管理。
问题定义
客户脆弱性不是一个稳定、永久的人格标签，而是一种情境风险：失业、丧亲、诈骗、语言障碍、无障碍需求、认知负荷、还款困难、投诉压力、家庭胁迫或服务失败，都可能使同一个客户在某个旅程中更容易受到伤害。
AI 系统的风险不只是“没有识别出 vulnerable situation”。更常见的是：
| 风险 | 表现 | 架构含义 |
|---|---|---|
| 过度推断 | 从年龄、语速、停顿、设备、语言或行为推断 disability、capacity、mental health | 必须使用 situation signal，而不是 person label |
| 过度干预 | 因模型认为客户脆弱而阻断交易、隐藏选项、降低自主权 | 干预强度要和可证明 harm risk 对齐 |
| 低质量帮助 | 用同一套 bot flow 处理 hardship、bereavement、scam、complaint、accessibility | 需要 specialist handoff 和 journey-specific controls |
| 证据缺口 | 无法证明客户看到什么、AI 建议什么、员工如何处理 | final-channel capture 和 evidence ledger 必须进入设计 |
| 尊严损害 | 客户被贴标签、重复陈述创伤、敏感信息扩散 | controlled vocabulary、role-based access、note hygiene |
成熟问题不是“模型能否判断这个人 vulnerable”，而是：
What situation signals show elevated support or harm risk?
What is the least intrusive helpful response?
What choice remains with the customer?
What must be escalated to a trained human?
What data is necessary and purpose-bound?
What evidence proves fair and dignified treatment?
核心原理/方法
核心方法是 situation-aware support。字段和流程应表达支持需要，而不是客户缺陷：
support_need_type
vulnerability_context
elevated_harm_risk
requested_accommodation
customer_preference
handoff_reason
agent_assist_recommendation
避免的字段和话术：
is_vulnerable = true
mentally_unfit
elderly_risky
low_capability
problem_customer
信号分层：
| Signal class | Examples | 使用边界 |
|---|---|---|
| Explicit customer statement | “我失业了”“我看不懂”“有人让我转钱” | 强 support trigger，但只记录完成目的所需事实 |
| Customer-selected preference | large print、screen reader、language、relay call | 用于等效服务，不推断 diagnosis |
| Interaction friction | abandon、重复错误、长时间停留、failed upload | 只用于 soft support offer 或 UX defect |
| Account/event context | missed payment、overdraft、death notification、complaint、unusual transfer | 用于 routing and support，不直接不利处理 |
| Frontline observation | branch/call-center notes、coercion concern、scam script | 需要 controlled vocabulary、review and QA |
关键原则：
- accessibility 是 release gate，不是 UI checklist。
- plain language 不能删掉金融含义、费用、期限、权利和限制。
- vulnerability signal 只能用于保护和支持，不能用于高压销售、价格提取或服务降级。
- emotion/sentiment 是弱信号，不是诊断、投诉结论或不利决策依据。
- final message、handoff packet、human decision 和 complaint outcome 必须可重放。
系统/架构模型
参考架构：
customer interaction
-> accessibility and preference layer
-> consent / purpose / data minimization gate
-> situation signal detection
-> risk tiering and confidence governance
-> inclusive UX adaptation
-> agent-assist recommendation with guardrails
-> human handoff / specialist escalation
-> complaint / remediation / fraud / hardship linkage
-> evidence ledger and QA sampling
-> model risk, conduct risk and accessibility governance
核心组件：
| Component | 职责 |
|---|---|
| Accessibility baseline | AI chat、voice、forms、upload、notifications、documents、handoff 满足可访问性测试 |
| Preference and accommodation service | 保存客户明确选择的 channel、language、format、assistive preference |
| Signal detection layer | 识别 support need，但标记 source、confidence、sensitivity、allowed use |
| Risk tiering engine | 区分 informational、support、high-harm、urgent escalation |
| Inclusive interaction orchestrator | plain language、step-by-step、channel switch、human option |
| Agent-assist guardrail | 给员工提示事实、uncertainty、prohibited actions 和 escalation basis |
| Specialist handoff | hardship、bereavement、fraud/scam、accessibility、complaint 专业队列 |
| Evidence ledger | 记录 signal、prompt、model、source、recommendation、human decision、final content |
| Governance loop | accessibility audit、conduct QA、model validation、complaint RCA、CAPA |
关键机制与取舍
Vulnerability-sensitive architecture 的难点在于干预强度和客户自主权的平衡。
| Pattern | 使用时机 | 好设计 | 坏设计 |
|---|---|---|---|
| Soft support offer | 低置信度 friction 或客户表达困惑 | 提供分步说明、专员、渠道切换 | 告诉客户“你似乎无法理解” |
| Plain-language toggle | 复杂费用、拒绝、hardship、fraud、投诉说明 | simple / detailed 含义一致 | 简化版隐藏关键限制 |
| Channel switch | 客户请求电话、branch、relay、paper、secure message | 保留上下文与 case id | 让客户从 bot 起点重来 |
| Safe pause | scam/coercion 高风险、不可逆动作 | 解释风险、提供复核、专员 | 无解释冻结或羞辱客户 |
| Specialist handoff | bereavement、hardship、accessibility complaint、distress | handoff packet 减少重复陈述 | 多部门要求客户重复创伤 |
| Customer-controlled disclosure | 客户愿意保存偏好/授权 | 明确用途、访问、保留、修改 | 扩散到所有 CRM notes |
| Appeal/review path | AI 或员工建议导致 hold、限制、拒绝 | 人工复核和投诉入口 | “系统判断无法继续” |
Handoff tiering：
| Tier | Trigger | AI action | Human action |
|---|---|---|---|
| 0 Accessibility preference | 客户选择格式、语言、辅助路径 | 应用 preference，确认是否保存 | 普通服务团队 |
| 1 Support need | 困惑、流程摩擦、plain-language 请求 | 简化解释、分步选项、渠道切换 | 员工继续服务 |
| 2 Vulnerability context | hardship、bereavement、language barrier、distress | 推荐专员，限制 sales pressure | trained specialist |
| 3 High harm risk | scam/coercion、elder risk concern、重大 financial loss | safe pause、fraud/hardship/complaint escalation | specialist + supervisor |
| 4 Urgent sensitive | self-harm language、abuse/coercion immediate risk、legal-sensitive complaint | approved emergency/escalation script，停止自动化 | policy-defined crisis/legal path |
证据与控制
Evidence ledger 最少要捕获：
case_id
customer-stated issue
support_need_type
requested accommodation or preference
signal source and confidence
data sensitivity and retention rule
AI run id / model / prompt / source
recommendation and prohibited actions shown to employee
human decision and reason
final-channel content
handoff queue and SLA
complaint/remediation link
QA result and CAPA id
控制矩阵：
| Control objective | Control activity | Evidence |
|---|---|---|
| 确保 AI channel 可访问 | WCAG/accessibility release gate 覆盖 chat、forms、voice、documents、handoff | test report、defect closure、assistive tech transcript |
| 避免客户标签化 | schema 区分 situation signal、support need、preference | data dictionary、field access rule、QA note audit |
| 最小化敏感数据 | purpose-based collection、role access、retention | privacy review、retention config、access logs |
| 保留自主权 | 解释、选择、复核、complaint route | final message、override path、review decision |
| 降低认知负荷 | approved plain-language patterns、review before submission | content review、readability evidence、user test |
| 升级高伤害场景 | scam、hardship、bereavement、accessibility complaint、distress tiering | handoff packet、specialist outcome |
| 控制 agent-assist | 禁止 diagnosis、unsupported promise、coercive script | prompt policy、eval result、employee confirmation |
| 监控公平性 | friction、completion、reversal、complaints by permitted segments/proxies | monitoring dashboard、model risk review |
| 投诉闭环 | complaint record 链接 AI run、channel、content、support need、RCA | complaint file、CAPA |
指标应平衡 protection、autonomy、access、conduct 和 evidence：assistive-tech completion、repeat-story rate、handoff quality、false pause、human review reversal、complaint uphold、prohibited diagnosis rate、hallucinated policy rate、final-channel capture、CAPA aging。
金融零售/AI产品场景
- Collections hardship chatbot：客户说失业和看不懂方案，AI 触发 hardship path、plain-language options、specialist handoff，并阻止高压话术。
- Scam transfer warning：客户在电话指导下发起大额转账，系统 safe pause，解释风险，升级 fraud specialist，同时保存客户最终响应。
- Bereavement servicing：客户提交死亡证明后，document reuse 和 sensitive note control 避免反复要求讲述关系和上传同一文件。
- Elder-risk branch assist：员工不能写“老人糊涂”；系统要求可观察事实、交易异常、客户陈述和 supervisor review。
- Credit adverse action explanation：AI 只能用 approved reason 和 plain-language pattern 起草，不能删掉权利、期限和限制。
- Accessibility complaint：screen reader 无法完成 fraud dispute，系统创建 accessibility incident、alternative channel、remediation 和 product defect backlog。
- Wealth/insurance call：grieving 或 distressed customer 触发 sales suppression、suitability review 和 conduct QA。
反模式
| 反模式 | 风险 | 更好的控制 |
|---|---|---|
| permanent vulnerable flag | stigma、bias、privacy risk | situation-based support_need with retention/access |
| age-only elder-risk rule | 不准确且可能不公平 | behavior/context + human review |
| accessibility 只做自动化扫描 | 漏掉 keyboard、screen reader、cognitive journey | manual assistive tech QA |
| LLM 随意简化 regulated content | 遗漏费用、期限、权利、限制 | approved content patterns and review |
| scam protection 变 paternalism | 客户失去控制且无法解释 | safe pause + review/appeal |
| agent-assist diagnosis | 员工采纳 unsupported conclusion | no-diagnosis prompt、QA、note hygiene |
| vulnerability signals 用于销售 | exploitation and conduct risk | suppression rules |
| complaint 不链接 AI trace | RCA 和 remediation 失效 | complaint schema includes AI run/content/channel |
| automation rate 作为主指标 | 把困难客户困在 self-service | balanced outcome metrics |
最终心智模型
Inclusive AI 的核心不是识别“脆弱客户”，而是识别高伤害情境并提供最小侵入的支持。成熟架构要能证明：客户没有被标签化，帮助没有变成强制，AI 渠道可访问，高风险情境被有尊严地升级，隐私和自主权被保留，投诉能回到证据、模型、内容、员工和流程根因，并转化为可执行改进。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。