AI Customer Vulnerability / Accessibility / Inclusive AI Architecture Playbook

面向对象: Advanced AI PM / Senior BA / AI Product Architect / Customer Experience Architect / Enterprise Architect / Accessibility Lead / Conduct Risk / Compliance / Complaint Operations / Model Risk / Fraud-Scam Risk / Frontline Operations / Financial Retail Business Owner。 核心问题: 如何把 vulnerable-customer recognition、accessible AI channel、dignified intervention、human handoff、agent-assist guardrails、complaints linkage 和 operating controls 设计成可落地、可审计、可持续改进的金融零售 AI 架构? 学习目标: 形成一套 action-oriented playbook, 能支持高管 framing、taxonomy、decision gates、RACI、roadmap、evidence pack、QA/eval、metrics、anti-patterns、tabletop 和 portfolio artifacts。 定位: 本文不是基础 customer journey 或 accessibility 入门, 而是训练你把 vulnerable-customer treatment、inclusive UX、AI agent-assist、human handoff、conduct controls、model risk 和 complaint evidence 做成可执行的产品架构与运营体系。

核心判断:

Vulnerability-aware AI should not label customers. It should detect support needs, reduce harm, preserve autonomy, make channels accessible, escalate safely, and prove fair treatment.

---

0. Disclaimer

本文是学习、架构训练和作品集材料, 不构成法律意见、监管意见、合规结论、ADA/WCAG 合规认证、消费者保护意见、医疗判断、心理健康判断、能力评估、信贷/保险/投资建议或客户通知建议。

正式项目必须由 Legal、Compliance、Accessibility、Customer Experience、Conduct Risk、Privacy、Model Risk、Operational Risk、Fraud/Scam Risk、Complaint Operations、Frontline Operations、Information Security、Data Governance、Product Owner、Internal Audit 和必要的外部顾问共同判断。

本文提供的是 decision support architecture。它避免给出“客户一定属于脆弱群体”“必须阻断交易”“必然违反监管”“已经满足无障碍合规”等结论。

---

1. Executive Framing

金融零售 AI 的客户伤害通常不是单一模型错误造成的。它来自多个控制面没有连接:

• AI interface 无法被残障客户使用。
• Chatbot 让客户在 hardship、bereavement、fraud 或 complaint 场景反复解释。
• 模型把客户状态贴成永久标签。
• Agent-assist 给员工过度自信的脚本。
• Scam warning 阻断了客户但没有解释、复核或投诉路径。
• Plain-language 改写隐藏了费用、期限、风险或客户权利。
• Complaint 没有链接到 AI run、final message、handoff 和 remediation。

高管需要的不是“AI 关怀功能”。高管需要回答:

Are vulnerable-customer situations recognized early enough?
Are interventions proportionate and explainable?
Can customers still choose, appeal, complain and switch channels?
Are AI channels accessible by design?
Can employees rely on guardrailed assistance without diagnosing customers?
Can the institution prove fair treatment later?

Executive one-liner:

Inclusive AI is a customer-outcome control plane, not a chatbot tone setting.

---

2. Source Anchors

Source nuance:

• WCAG/ADA anchor 不是只给前端团队使用, 它影响 AI journey、content lifecycle、vendor requirement、QA、complaint RCA 和 release governance。
• CFPB/FTC anchors 不是本文的法律结论, 而是训练金融零售 AI 的 consumer protection and conduct-risk language。
• NIST AI RMF 和 ISO/IEC 42001 是 governance scaffolding, 不是单个模型评估表。

---

3. Thesis and Operating Principles

Thesis:

Inclusive AI architecture should make support easier to receive,
not make customers easier to label.

Why it matters: vulnerable-customer treatment sits at the intersection of accessibility, customer experience, privacy, conduct risk, model risk, fraud/scam controls, complaints and frontline operations. If these controls are separate, AI will either miss high-harm situations or over-intervene in ways that reduce dignity and autonomy.

---

4. Vulnerability Taxonomy for AI Product Architecture

Taxonomy 目标是 routing and support, not identity classification。

Controlled vocabulary:

---

5. Reference Architecture

AI customer interaction
  -> channel/accessibility baseline
  -> preference and accommodation service
  -> consent / purpose / data minimization gate
  -> situation signal detector
  -> harm-risk tiering
  -> inclusive UX orchestrator
  -> agent-assist guardrail service
  -> specialist handoff / safe pause / complaint route
  -> final-channel capture
  -> evidence ledger
  -> QA, model risk, accessibility and conduct monitoring
  -> CAPA and release governance

Architecture capabilities:

---

6. Decision Gates

Gate 0: Use Case Eligibility

Gate 1: Data Purpose and Consent

Gate 2: Model Behavior

Gate 3: Intervention Proportionality

Gate 4: Human Handoff

Gate 5: Complaint and Remediation

---

7. Required Artifacts

Product / Architecture Decision Matrix

Control Matrix

---

8. Signal Design and Data Minimization

Signal specification template:

Purpose matrix:

---

9. Inclusive UX Standards

Non-negotiable interaction rules:

• Provide a clear non-AI route for high-stakes journeys。
• Let customers switch channel without losing context。
• Make generated content compatible with screen readers and keyboard navigation。
• Avoid timeouts during hardship, bereavement, fraud dispute and document upload journeys。
• Show fees, dates, consequences, deadlines and rights explicitly。
• Use plain language without changing approved legal/financial meaning。
• Confirm critical choices before irreversible action。
• Provide complaint, appeal or review routes when AI contributes to friction or restriction。

AI interface checks:

Plain-language pattern:

1. What happened.
2. What it means for you.
3. What options you have.
4. What will happen next.
5. How to get human help or complain.

---

10. Agent-Assist Guardrails

Agent-assist output structure:

Customer-stated facts:
Observable workflow facts:
Possible support need:
Why this may matter:
Recommended next step:
Prohibited actions:
Uncertainty:
Customer-facing language option:
Escalation queue:
Evidence IDs:

Prohibited outputs:

Agent-assist QA must sample:

• High-risk escalations。
• AI summaries edited by employees。
• Customer-visible scripts。
• Cases with complaint, refund, fee waiver, transaction hold, fraud claim, hardship plan or bereavement document。
• Cases where customer requested accommodation or channel switch。

---

11. Human Handoff and Escalation Model

Handoff packet:

---

12. RACI / Operating Model

Governance cadence:

---

13. Implementation Roadmap

Days 1-30: Foundation

Days 31-60: Controlled Pilot

Days 61-90: Scale and Assurance

---

14. Evidence Pack

Minimum evidence fields:

Evidence rules:

• Store raw trace and curated summary separately。
• Preserve customer-stated words, but do not over-distribute sensitive details。
• Capture what customer actually saw or heard。
• Record model uncertainty and human decision。
• Track evidence gaps as control defects。

---

15. QA / Eval / Model Risk

Scenario eval suite should include:

Model risk questions:

• Is this model making, recommending or merely drafting customer-impacting actions?
• Can the model output affect fees, access, fraud holds, hardship, complaints, credit or insurance?
• Which vulnerable scenarios are in validation data?
• How are false positives and false negatives measured by harm, not just accuracy?
• What monitoring detects drift in tone, escalation, refusal, hallucinated policy and over-intervention?
• What change control is required when prompt, model, RAG source, channel or handoff policy changes?

Accessibility QA:

• Automated scans are required but insufficient。
• Manual keyboard and screen reader tests must cover complete high-stakes journeys。
• Dynamic AI content must be tested, not only static pages。
• Customer documents and generated PDFs need accessible alternatives。
• Voice and call-center flows need repeat, pause, handoff and relay considerations。

---

16. Complaints, Remediation and CAPA

Complaint linkage workflow:

complaint intake
  -> identify AI/customer support involvement
  -> link AI run and final-channel content
  -> classify support_need_type and alleged harm
  -> preserve evidence
  -> specialist review
  -> remediation decision
  -> RCA
  -> CAPA
  -> metrics and governance reporting

Remediation categories:

CAPA quality bar:

• Root cause names product/model/process/vendor/training/data issue。
• Owner and due date exist。
• Customer impact and complaint population bounded。
• Evidence proves closure, not just status change。
• Metrics show whether defect recurs。

---

17. Checklists

17.1 Release Checklist

17.2 Handoff Checklist

17.3 Agent-Assist Review Checklist

17.4 Vendor Checklist

---

18. Metrics and KRIs

Balanced scorecard:

Access: customers can complete the journey.
Comprehension: customers understand choices and consequences.
Protection: high-harm cases are escalated.
Autonomy: interventions are proportionate and reviewable.
Dignity: customers are not labeled or forced to repeat distress.
Evidence: the institution can replay fair treatment.
Learning: complaints and QA improve the system.

---

19. Anti-Patterns

---

20. Tabletop Scenarios

Scenario 1: Scam Transfer Pressure

A customer attempts a large new-payee wire transfer while repeatedly saying
the recipient told them not to answer bank questions. The AI assistant detects
known scam-script language and recommends a safe pause.

Expected decisions: whether to pause, what to tell customer, fraud specialist SLA, what evidence to preserve, when to allow override, how to handle complaint if customer objects。

Scenario 2: Bereavement Journey Breakdown

A spouse reports a death and uploads documents. The AI chatbot asks for the
same documents three times and sends a generic collections message the next day.

Expected decisions: bereavement routing, document reuse, apology/correction, collections suppression, sensitive note access, complaint/remediation linkage。

Scenario 3: Accessibility Barrier in Fraud Dispute

A screen reader user cannot complete an AI-guided fraud dispute form before
the deadline. The chatbot says the form is required and offers no alternative.

Expected decisions: equivalent access, deadline protection, defect severity, remediation, accessibility release gate, vendor escalation。

Scenario 4: Agent-Assist Overreach

An agent-assist summary labels an older branch customer as cognitively impaired
and recommends blocking a withdrawal. The actual evidence is a single confusing
conversation and an unusual transaction.

Expected decisions: note rewrite, evidence-based concern, supervisor review, customer explanation, no age-only action, QA and training fix。

Scenario 5: Hardship Sales Pressure

A collections copilot recommends a refinance product during a hardship call,
even though the customer asked for temporary payment relief.

Expected decisions: sales suppression, hardship options, conduct QA, script change, customer remediation review。

---

21. Portfolio Deliverables

Portfolio storyline:

I designed an inclusive AI architecture for financial retail vulnerable-customer situations.
The system does not label customers; it identifies support needs, applies accessible UX,
guards agent assistance, escalates high-harm scenarios, links complaints to evidence,
and measures whether customers are protected without losing autonomy.

---

22. Interview Answers

Q1: 如何设计 AI vulnerable customer detection?

30 秒:

我不会把它设计成客户永久标签。我会定义 support_need taxonomy, 优先使用客户明确表达和偏好, 对行为信号只触发 soft support, 对 scam/hardship/bereavement/accessibility complaint 等高伤害场景用人工升级。关键控制是 data minimization、purpose limitation、human review、final-channel capture 和 complaint linkage。

Q2: Inclusive AI 和普通 accessibility 有什么区别?

30 秒:

普通 accessibility 偏界面可用性, inclusive AI 还覆盖 AI-generated content、agent-assist、plain-language、channel switching、vulnerability signals、conduct risk、human handoff、model validation 和投诉闭环。它是 customer outcome architecture, 不是 UI checklist。

Q3: 如何避免 AI 干预损害客户自主权?

30 秒:

用 proportional intervention。低风险提供选择, 中风险建议专员, 高风险才 safe pause。每个限制性动作都要有 reason、plain-language explanation、human review、customer recourse 和 evidence。模型置信度不能单独决定限制客户。

Q4: Agent-assist 应该怎么控?

30 秒:

控制重点是 no diagnosis、no unsupported promise、no coercive sales、show uncertainty、policy-based handoff reason、human decision logging 和 final-channel capture。AI 可以帮员工看见风险, 不能替员工判断客户能力或合规结论。

Q5: 用什么指标证明系统真的更包容?

30 秒:

我会看 accessibility completion、channel switch success、repeat-story rate、high-harm false negatives、false pause rate、complaint AI-linkage、remediation cycle time、prohibited-output rate 和 CAPA aging。只看 automation rate 会把问题做偏。

---

23. Practical Templates

23.1 Support Signal Card

23.2 Safe Pause Decision Record

Case ID:
Customer action paused:
Harm risk:
Evidence observed:
Customer explanation provided:
Specialist owner:
Review/override route:
Complaint route:
Final customer message ID:
Decision outcome:

23.3 Executive One-Pager

Use case:
Customer population:
Vulnerable situations covered:
Accessibility status:
Intervention model:
Human handoff model:
Complaint and remediation linkage:
Key metrics:
Top residual risks:
Decisions needed:

23.4 Complaint RCA Template

Complaint ID:
AI run/content/channel IDs:
Customer-stated issue:
Support need involved:
Alleged harm:
Root cause:
Remediation:
Control gap:
CAPA owner:
Closure evidence:

24. Final Operating Principle

这套 playbook 的成熟度可以用一个问题检验:

When a customer is confused, disabled by the channel, grieving, under scam pressure,
in hardship, distressed or complaining, does the AI system preserve access,
choice, dignity, privacy, fair treatment and evidence at the same time?

如果答案不清楚, 不是缺一个“关怀话术”。问题是 AI product architecture、accessibility、customer experience、conduct risk、model risk、frontline operations 和 complaint governance 还没有成为同一套 operating system。