AI 扩展计划 / Playbooks
AI Customer Harm / Recourse / Remediation Playbook
重要说明：本文是学习、作品集和内部治理训练材料，不构成法律意见、合规结论、审计意见、模型验证报告、监管解释或赔偿建议。正式项目必须由 Legal、Compliance、Risk、Model Risk、Fair Lending、Privacy、Security、Accessibility、Operations、Business Owner、Technology Owner 和管理层结合机构类型、司法
779 行AI_CUSTOMER_HARM_RECOURSE_REMEDIATION_PLAYBOOK.md
AI Customer Harm / Recourse / Remediation Playbook
定位：面向 CBAP+、AI Product Manager、AI Product Architect、Customer Experience Risk Lead、Solutions Architect、Model Risk、Compliance、Operations、Digital Banking、Lending、Payments、Wealth、AML/KYC 团队的高级实战手册。本文关注的不是普通客服话术，而是金融零售 AI 系统造成或放大的客户伤害如何被识别、分类、监控、补救、恢复和证明已经恢复。目标是把 customer harm 从“客户投诉后个案处理”升级为可治理、可度量、可追溯、可审计、可复盘的产品与架构能力。
重要说明：本文是学习、作品集和内部治理训练材料，不构成法律意见、合规结论、审计意见、模型验证报告、监管解释或赔偿建议。正式项目必须由 Legal、Compliance、Risk、Model Risk、Fair Lending、Privacy、Security、Accessibility、Operations、Business Owner、Technology Owner 和管理层结合机构类型、司法辖区、产品范围、客户群体、合同义务和内部政策确认。访问日期按 2026-06-30 记录。
Source Anchors
以下官方来源作为本文的设计锚点。本文把这些来源转成产品需求、流程控制、运行监控、客户救济、证据包和管理层决策语言，不把任何来源简化为单一检查表。
| Anchor | Official link | 本 playbook 的使用方式 |
|---|---|---|
| NIST AI Risk Management Framework | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 AI customer harm 的治理、场景映射、指标测量、处置闭环和持续改进。NIST 页面显示 AI RMF 1.0 正在修订，正式项目应跟踪版本变化。 |
| NIST AI RMF Generative AI Profile | https://www.nist.gov/itl/ai-risk-management-framework/generative-artificial-intelligence-profile 和 https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence | 用户给出的 NIST GenAI Profile 路径在 2026-06-30 访问时返回 404；当前可访问的 NIST 官方 publication 页面用于 GenAI 风险锚点。本文用它处理 hallucination、信息完整性、over-reliance、content provenance、third-party dependency、abuse、incident response 和 evidence。 |
| EU AI Act: Regulation (EU) 2024/1689 | https://eur-lex.europa.eu/eli/reg/2024/1689/oj | 用于理解 AI 系统风险分层、透明度、高风险系统、post-market monitoring、serious incident、deployer / provider responsibility、记录和客户影响治理。正式适用性由 Legal / Compliance 判断。 |
| CFPB Consumer Complaint Database | https://www.consumerfinance.gov/data-research/consumer-complaints/ | 用作 consumer harm signal 的外部参照：投诉主题、公司响应、趋势、产品类别和客户叙述可以反向校准内部 complaint taxonomy、root cause 分类和 remediation proof。 |
| FTC Business Blog: Keep your AI claims in check | https://www.ftc.gov/business-guidance/blog/2023/02/keep-your-ai-claims-check | 用于 AI 产品声明、营销承诺、效果证明和 customer communication 的边界：不要把 AI 能力说成无证据承诺，不要用“AI”掩盖真实限制、错误概率或专业服务边界。 |
Source-to-artifact mapping:
| Source lens | 需要落到的 artifact | 面试表达 |
|---|---|---|
| NIST AI RMF | AI harm risk register、harm KRI dashboard、control library、release gate、incident review | “我用 Govern / Map / Measure / Manage 管理客户伤害，而不是只看模型准确率。” |
| NIST GenAI Profile | RAG harm taxonomy、hallucination impact matrix、content provenance evidence、prompt / retrieval change log | “生成式 AI 的风险不是回答错一句话，而是错信息进入客户旅程后是否造成权益、资金、隐私或解释损害。” |
| EU AI Act | AI inventory、risk tier、post-market monitoring plan、serious incident escalation、deployer evidence | “我会把客户影响、自动化程度、人类监督和生产监控作为 AI 系统适用性事实基础。” |
| CFPB complaints | Complaint taxonomy、recourse trigger、trend monitoring、external complaint reconciliation | “投诉不是客服噪音，而是 harm detection 的生产信号。” |
| FTC AI claims guidance | AI claims review、customer notice、marketing substantiation file、communication control | “如果产品说 AI 能解决、判断或建议，就要能证明能力边界和恢复路径。” |
1. 核心心智模型：AI Customer Harm 不是只有模型错误
金融零售 AI 的 customer harm 不能只定义为 model error。一个模型输出错误但没有进入客户决策，可能只是质量问题；一个看似“部分正确”的输出如果让客户错过争议期限、被错误拒绝、被迫重复提交材料、泄露隐私或无法获得人工帮助，就是客户伤害。
本文使用一个更适合产品、架构和运营团队的公式：
AI Customer Harm =
Wrong action
+ Customer impact
+ Weak recovery path
解释：
- Wrong action：AI 系统、AI 辅助员工、自动化策略、RAG 答案、评分模型、建议引擎或工作流采取了错误、误导、不完整、不公平、过度自信、过度延迟或无权限的动作。
- Customer impact：客户受到资金、访问、权益、解释、隐私、时间、情绪、合规、声誉或运营负担影响。
- Weak recovery path：客户不知道如何申诉，人工入口不可达，审核材料缺失，纠正太慢，补偿不足，解释不清，问题重复发生，组织无法证明已经恢复。
因此，高级 AI PM / Architect 不能只问：
模型准不准？
而要问：
AI 的输出进入了哪个客户旅程？
它改变了什么动作、承诺、排序、拒绝、建议、通知或服务路径？
客户最坏会损失什么？
客户如何发现、质疑、暂停、升级、纠正和获得补偿？
我们如何证明影响范围已经识别、客户已经恢复、根因已经修复、同类伤害没有继续发生？
1.1 三层伤害栈
| 层级 | 问题 | 典型失败 |
|---|---|---|
| AI behavior layer | 模型、prompt、检索、规则、阈值、agent tool use 是否产生错误行为 | 幻觉、错误解释、错误分类、过度拒绝、错误路由、过期知识、prompt injection、工具调用失败 |
| Customer journey layer | 错误行为进入哪个客户触点和流程 | 客户被拒绝、错过期限、收到错误建议、无法联系人工、被重复要求提交材料 |
| Recovery layer | 伤害发生后客户和组织如何恢复 | 无申诉入口、case owner 不清、日志不完整、没有补偿机制、无法批量找出受影响客户 |
高级判断的关键：很多组织只修第一层，把 prompt 改了、模型换了、阈值调了，却没有处理第二层和第三层。客户伤害管理必须同时修正 AI behavior、customer journey 和 recovery path。
1.2 Customer harm 与 incident 的区别
| 维度 | 普通 AI incident | AI customer harm |
|---|---|---|
| 判断中心 | 系统是否异常 | 客户是否受到实际或合理可预见的影响 |
| 触发来源 | 监控报警、模型漂移、服务故障、安全事件 | 投诉、申诉、拒绝、损失、延迟、隐私暴露、监管问询、群体差异 |
| 处置目标 | 恢复系统稳定 | 恢复客户状态、权益、资金、解释、信任和证据 |
| 成功标准 | 服务可用、错误率下降 | 客户 made whole、原因可解释、影响范围完整、同类伤害停止 |
| 证据要求 | 技术日志、变更记录、报警记录 | 再叠加客户通知、个案审核、补偿记录、申诉结果、群体公平性和复发监控 |
1.3 Recourse 是产品能力，不是售后动作
Recourse 指客户能够质疑、申诉、纠正、获得人工审核、恢复权益、获得补偿或获得清晰解释的制度化路径。成熟的 recourse 不依赖某个客服是否有经验，而是被嵌入：
- Journey design：客户在关键节点能看到申诉、人工、解释和暂停入口。
- Decision architecture：每个 AI-assisted decision 都能关联理由、证据、版本和责任人。
- Case management：客户申诉进入统一 case，不在聊天记录、邮件和工单之间丢失。
- Operational policy：不同 harm severity 有明确 SLA、审批和补偿权限。
- Evidence capture：客户恢复所需的事实、日志、通知、审核和纠正动作自动沉淀。
- Monitoring：补救后继续看 repeat harm、segment disparity 和 recurring root cause。
2. 设计原则：从“支持客户”升级为“恢复客户”
| 原则 | 实战含义 | 反模式 |
|---|---|---|
| Impact-first | 先按客户影响分级，再按模型错误类型分析 | 只按技术严重程度排队，忽略客户权益和资金影响 |
| Recoverability by design | 高影响 AI 动作必须默认可质疑、可暂停、可撤销或可人工复核 | 上线后才想如何申诉和赔偿 |
| No dead-end automation | AI 不得把客户困在无法完成任务、无法找人、无法申诉的自助循环 | Chatbot 反复回答同一句，隐藏人工入口 |
| Explain what matters | 解释要服务于客户行动和权利，不是展示技术细节 | 给出一堆特征权重，但客户仍不知道如何纠正 |
| Evidence at source | 证据在流程运行时生成，不靠事故后拼截图 | 事后手动整理聊天记录、日志和审批邮件 |
| Segment-aware recovery | 监控不同客户群、语言、渠道、地区、产品和脆弱客户的伤害差异 | 平均指标达标但弱势群体持续受害 |
| Proportionate compensation | 补偿与损失、延迟、错误拒绝、客户负担和监管风险相匹配 | 只道歉不纠正资金或权益 |
| Closed-loop learning | 每个 harm case 都要进入 root cause、eval、知识库、流程和控制改进 | 个案处理完即关闭，没有系统性学习 |
2.1 AI PM 的关键转向
传统客服项目常以 deflection rate、AHT、cost-to-serve、CSAT 衡量成功。AI customer harm 管理要求把目标改成：
- 客户是否获得正确行动，而不仅是得到快速回答。
- 错误是否被快速发现，而不仅是投诉数量下降。
- 人工入口是否在高风险场景可达，而不是被自助化吞掉。
- 补救是否恢复客户状态，而不是只关闭工单。
- 证据是否能经受审计，而不是只满足内部复盘。
3. Harm Taxonomy：客户伤害分类法
分类法必须服务于三件事：生产识别、处置优先级和证据证明。下面分类可作为金融零售 AI harm taxonomy 的基础版本。
| Harm category | 定义 | 金融零售例子 | 关键监控信号 | 初始处置 |
|---|---|---|---|---|
| Financial loss | AI 直接或间接造成客户资金损失、费用增加、利息损失、错过退款或错误交易 | 支付争议 AI 错误拒绝 provisional credit；RAG 错误告知费用减免条件；财富助手误导客户卖出产品 | 退款失败、费用争议、赔偿请求、appeal upheld、负余额、chargeback reversal | 暂停相关自动拒绝，人工复核，计算损失，纠正账户，补偿费用和利息 |
| Access denial | AI 造成账户、服务、信用、支付、申诉、人工支持或产品访问被不当拒绝 | AML false positive 支持流程把客户锁在资料补交流程；信贷预审 AI 错误拒绝继续申请 | 登录失败、账户限制、拒绝率突增、abandoned journey、人工升级失败、KYC loop | 恢复访问或提供临时通道，人工验证，解除错误限制，记录拒绝原因 |
| Wrong explanation | AI 给出错误、不完整、过度泛化或不可行动的解释，影响客户理解和纠正能力 | 贷款拒绝解释把原因说成“信用评分不足”，实际主因是收入验证缺失；客服 RAG 错引政策 | explanation dispute、客户重复追问、员工覆盖输出、adverse action review fail | 重新生成正式解释，人工校验，纠正客户记录，更新 reason code pipeline |
| Privacy exposure | AI 泄露、暴露、混合、过度收集或不当使用客户个人信息、账户信息或敏感信息 | RAG 答案返回其他客户信息；聊天总结进入错误客户档案；prompt 日志保存未脱敏数据 | DLP alert、客户报告、QA finding、异常检索、跨账户引用、访问日志异常 | 立即隔离数据，通知隐私/安全团队，评估通知义务，删除错误记录，限制检索范围 |
| Discrimination | AI 对受保护属性或代理变量导致不公平拒绝、价格、服务质量、解释或负担差异 | 某语言客户更难到达人工；某邮编贷款解释更模糊；某年龄段财富建议被过度保守 | segment disparity、fair lending review、投诉集中、appeal upheld disparity | 启动公平性分析，冻结高风险规则，人工复核受影响群体，修正特征/阈值/流程 |
| Delay | AI 造成客户请求、争议、投诉、贷款、KYC、AML 或服务恢复延迟 | AI 分类错误把支付争议排到低优先级；文档提取错误导致贷款材料重复等待 | SLA breach、queue aging、duplicate contacts、timeout、journey abandonment | 调整队列优先级，人工清理积压，通知客户新时限，补偿可量化延迟损失 |
| Emotional distress | AI 以冷漠、威胁、错误、反复拒绝或不当语气放大客户压力，尤其在欺诈、丧亲、困难援助场景 | 客户报告欺诈后被 AI 反复要求“再确认交易”；困难援助 chatbot 使用催收式语气 | negative sentiment spike、supervisor escalation、complaint narrative、vulnerable customer flag | 人工 warm handoff，道歉，简化证明材料，主管复核，更新 tone / policy constraints |
| Regulatory complaint | AI 错误引发 CFPB、州监管、金融申诉、仲裁、内审、媒体或外部投诉 | 客户因 chatbot 阻断争议权利向 CFPB 投诉；错误 adverse action explanation 被监管问询 | regulator inquiry、external complaint、legal hold、complaint keyword、executive escalation | 法务合规牵头，冻结证据，完整重建时间线，统一口径，开展同类客户影响评估 |
| Operational burden | AI 把错误成本转嫁给客户或一线员工，要求重复提交、重复解释、重复验证或跨渠道追赶 | 客户上传收入材料后 AI 仍要求重复上传；客服每次都要手动纠错 AI 摘要 | repeat contact、duplicate document upload、manual override、employee correction rate | 减少重复要求，自动复用已验证材料，修正工作流，给一线清晰处置权限 |
3.1 Taxonomy 使用纪律
一个 harm case 可以有多个 category，但必须有一个 primary harm category，用于 SLA、owner 和 executive reporting。分类时不要只看客户最先表达的情绪，而要还原客户旅程中的可验证影响。
推荐字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| primary_harm_category | 主伤害类型 | Financial loss |
| secondary_harm_categories | 次级伤害类型 | Delay, Emotional distress |
| ai_contribution_type | AI 如何参与 | Automated decision, AI-assisted employee, RAG response, model score, workflow routing |
| customer_impact | 对客户造成的实际影响 | 错误拒绝 500 美元争议退款，客户被收取滞纳金 |
| recoverability_status | 是否可恢复 | Fully recoverable, partially recoverable, difficult to restore |
| evidence_status | 证据是否足够 | Complete, partial, inconsistent, missing critical logs |
4. Harm Severity Matrix：按客户影响和恢复难度分级
严重度不是技术团队单方面定义。应由客户影响、影响范围、可恢复性、时间敏感度、脆弱客户、监管暴露和复发风险共同决定。
| Severity | 客户影响 | 影响范围 | 恢复难度 | 处置时限 | 决策层级 |
|---|---|---|---|---|---|
| H0 - Near miss | AI 错误被内部控制拦截，客户未受影响 | 单点或小范围 | 易恢复 | 记录并进入趋势监控 | Product / Ops owner |
| H1 - Low impact | 客户轻微不便、一次性误导、无资金或权益损失 | 个案 | 易恢复 | 1-3 个工作日内处理 | Operations lead |
| H2 - Material inconvenience | 客户被延误、重复提交、错误解释、短期访问受阻或小额费用影响 | 个案或局部群体 | 可恢复但需要人工介入 | 24-48 小时内 triage | Product + Ops + Risk |
| H3 - Significant harm | 资金损失、错误拒绝、隐私暴露、明显群体差异、正式投诉或高价值客户权益受损 | 多客户或高敏个案 | 需要补偿、纠正记录或监管证据 | 当日升级，按小时跟踪 | Incident lead + Legal/Compliance |
| H4 - Critical / systemic | 系统性错误、受保护群体差异、重大隐私暴露、严重资金损失、监管重大问询、媒体风险 | 批量或跨产品 | 恢复复杂，可能需要批量 remediation | 立即启动 crisis protocol | Executive risk committee |
4.1 升级触发器
即使单个客户损失不大，出现以下任一信号也应提高严重度：
- 同一 AI 版本、prompt、retriever、规则或阈值关联多个相似 harm。
- 客户属于 vulnerable customer、老年客户、有限英语能力客户、困难援助、欺诈受害者或受监管保护场景。
- 影响信贷、支付争议、投诉、催收、财富建议、账户冻结或正式通知。
- 客户可能错过法定、合同或机构政策规定的期限。
- 证据链存在缺口，无法复现 AI 输出或人工采纳过程。
- 外部投诉、监管问询、律师函或媒体信号出现。
5. Harm Signal Architecture：从投诉噪音到生产监控
AI harm detection 不能只靠客户明确说“AI 伤害了我”。多数客户不会知道 AI 在何处参与，他们只会说“你们拒绝了我”“一直没人处理”“解释不对”“系统让我重复上传”“客服回答前后矛盾”。因此信号架构必须把明确信号和弱信号统一起来。
Customer / Employee / System signals
-> Signal ingestion
-> Harm normalization
-> AI contribution matching
-> Severity scoring
-> Case creation or incident escalation
-> Recourse workflow
-> Remediation evidence pack
-> KRI dashboard and recurrence monitoring
5.1 必须纳入的信号源
| Signal source | 说明 | 需要捕获的字段 | Harm 价值 |
|---|---|---|---|
| Complaints | 内部投诉、外部投诉、CFPB/监管投诉、社交媒体升级 | product、journey、complaint text、channel、customer segment、AI touchpoint、resolution | 客户伤害最直接的叙述来源 |
| Appeals | 信贷、争议、KYC、费用、账户限制、财富适当性等申诉 | original decision、appeal reason、appeal outcome、upheld flag、reviewer | appeal upheld 是 AI 决策质量和恢复有效性的强信号 |
| Overrides | 员工覆盖 AI 推荐、评分、摘要、分类、话术或 next-best-action | AI output、human action、override reason、employee role、policy citation | 员工长期覆盖同类输出说明 AI 正在制造运营负担 |
| Escalations | 客户或员工升级到主管、二线、合规、法务、执行投诉团队 | escalation reason、prior contacts、handoff time、resolution path | 识别 no-dead-end automation 和高情绪压力场景 |
| Abandoned journeys | 客户在争议、贷款、KYC、投诉、聊天、上传材料中途放弃 | journey step、last AI response、error code、time spent、repeat attempt | 客户未投诉但已经放弃，是隐藏伤害的关键来源 |
| Regulator inquiries | CFPB、州监管、证券/保险监管、内审、外审问询 | inquiry type、affected product、date range、requested evidence、legal hold | 触发证据冻结、口径一致和批量影响评估 |
| Incident tags | 技术事故、数据事故、模型事故、知识库事故、供应商事故标签 | incident id、service、model version、time window、customer cohort | 把技术事故连接到客户影响 |
| QA findings | Contact center QA、model QA、RAG QA、policy QA、fairness QA | sample id、finding type、severity、policy violated、customer impact | 发现低频高影响错误和训练机会 |
| Model telemetry | confidence、uncertainty、retrieval score、tool error、fallback rate、drift、latency | model_id、version、prompt_id、retrieved_docs、score、threshold、output_hash | 把 AI 行为与客户 case 关联，支撑 root cause |
5.2 Harm Event Ledger
成熟组织需要一个 harm event ledger，不一定是独立系统，但必须有统一数据模型。它连接 AI inventory、case management、model telemetry、customer journey、complaints 和 evidence binder。
| 字段组 | 字段 | 设计要点 |
|---|---|---|
| Identity | harm_event_id、case_id、customer_id_token、product、channel、journey_step | 客户标识应 tokenized，满足隐私和最小化访问要求 |
| AI context | ai_system_id、model_id、model_version、prompt_version、retriever_version、policy_rule_id、tool_call_id | 能复现当时 AI 参与方式 |
| Decision/action | original_output、action_taken、human_adopted_flag、override_flag、decision_timestamp | 记录 AI 输出和最终动作的差异 |
| Impact | harm_category、severity、financial_amount、access_impact、privacy_scope、delay_hours、segment_flags | 支撑 severity 和 KRI |
| Recourse | customer_notified_at、review_owner、pause_action、correction_action、compensation_action、restoration_at、explanation_sent_at | 支撑恢复证明 |
| Evidence | transcript_ref、log_ref、data_snapshot_ref、policy_ref、approval_ref、communication_ref、audit_hash | 证据不一定都放在 ledger，但要有引用 |
| Closure | root_cause、control_fix、cohort_reviewed、repeat_monitoring_window、closure_approver、closure_date | 关闭不是工单关闭，而是恢复和复发监控启动 |
5.3 Signal Normalization
同一个伤害会以不同语言出现。标准化层应把自然语言、工单分类和系统事件映射到 harm taxonomy。
| 客户/员工原话 | 标准 harm signal | 可能的 AI contribution |
|---|---|---|
| “你们机器人一直说不能退，但主管说可以。” | Wrong explanation + Financial loss | RAG policy retrieval error |
| “我已经上传三次收入证明了。” | Operational burden + Delay | Document AI extraction failure or workflow state mismatch |
| “系统说我不符合条件，但没有说明怎么改。” | Access denial + Wrong explanation | Eligibility model + insufficient reason code |
| “我没有办法联系真人。” | Access denial + Emotional distress | Chatbot containment policy |
| “我账户被冻结后没人告诉我缺什么材料。” | Access denial + Delay | AML case triage and customer notice failure |
5.4 Architecture Controls
| Control | 目的 | 实现方式 |
|---|---|---|
| AI touchpoint tagging | 知道哪些客户旅程有 AI 参与 | 在 event schema 中加入 ai_system_id、ai_assisted_flag、automation_level |
| Complaint-to-AI matching | 把投诉映射到 AI 版本和流程 | case 时间窗、customer journey id、decision id、model telemetry join |
| Appeal outcome feedback | 把申诉结果回流模型和规则治理 | appeal upheld 进入 eval set、risk review、threshold review |
| Override reason taxonomy | 区分员工纠错、政策例外、客户偏好和 AI 错误 | 强制选择 structured reason，允许补充文本 |
| Abandonment sentinel | 发现客户无声离开 | 高风险 journey 中连续失败、长时间停留、重复进入、上传失败触发 case |
| Regulator-ready evidence freeze | 外部问询时锁定证据 | legal hold、版本快照、日志保留策略、证据访问审计 |
6. Recourse Architecture：Detect, Notify, Pause, Review, Correct, Compensate, Restore, Explain, Monitor
Recourse architecture 是一条端到端恢复链。任何一个环节缺失，客户可能仍然受害，组织也无法证明已经修复。
Detect
-> Notify
-> Pause
-> Review
-> Correct
-> Compensate
-> Restore
-> Explain
-> Monitor recurrence
6.1 Recourse Workflow
| Step | 目标 | 系统动作 | 人工动作 | 证据 |
|---|---|---|---|---|
| Detect | 发现潜在伤害 | 从 complaints、appeals、overrides、telemetry、QA、abandonment 生成 harm event | Triage owner 确认分类和严重度 | signal record、case id、AI context |
| Notify | 告知客户或内部 owner | 生成客户通知、内部 alert、regulatory hold notice | 判断通知内容、渠道、时点和法律要求 | notification copy、send log、approval |
| Pause | 防止伤害扩大 | 暂停自动拒绝、RAG 答案、agent tool、规则或 cohort rollout | Product/Risk 决定 pause scope | feature flag log、change approval |
| Review | 人工复核事实和客户影响 | 拉取 decision packet、transcript、policy、model logs | Reviewer 按政策和客户事实复核 | review checklist、reviewer notes |
| Correct | 更正错误记录、动作或输出 | 更新账户、工单、决策、知识库、reason code、模型配置 | 确认纠正符合业务和合规要求 | correction log、before/after snapshot |
| Compensate | 补偿可量化损失和合理负担 | 计算费用、利息、退款、服务补偿 | 批准补偿金额和例外 | compensation calculation、approval |
| Restore | 恢复客户状态、访问、权益和服务路径 | 解除错误限制、恢复额度、重启流程、优先处理 | 确认客户可以实际使用服务 | restoration timestamp、customer confirmation |
| Explain | 给出可理解、可行动、不过度承诺的解释 | 使用 approved communication template | 人工校验高风险解释和正式通知 | message version、policy citation |
| Monitor recurrence | 证明同类伤害没有继续发生 | KRI dashboard、cohort scan、post-fix eval | Risk/Product 周期复核并关闭 | monitoring report、closure approval |
6.2 Recourse Decision Tree
| 判断问题 | Yes 时动作 | No 时动作 |
|---|---|---|
| 客户是否可能受到资金、权益、访问、隐私或监管影响 | 升级 H2+，创建 harm event 和 recourse case | 记录为低风险质量问题并进入趋势监控 |
| AI 是否参与了输出、排序、拒绝、路由、解释、摘要或员工建议 | 关联 AI system id 和版本 | 按非 AI 客户事件处理，但保留人工确认 |
| 是否仍在继续影响其他客户 | 暂停相关自动化或 cohort rollout | 进入个案恢复和 root cause |
| 是否存在可量化损失 | 计算退款、费用、利息、补偿或权益恢复 | 评估非金钱恢复：解释、道歉、优先处理、记录纠正 |
| 是否涉及脆弱客户、受保护群体、监管投诉或外部问询 | Legal/Compliance/Risk 进入审批链 | Product/Ops 按标准 SLA 处理 |
| 是否能复现 AI 输出和最终动作 | 进入根因和恢复证明 | 启动 evidence gap review，提升控制风险等级 |
6.3 RACI
| Activity | AI PM | Solutions Architect | Ops / CX | Model Risk | Legal / Compliance | Data / Security | Executive Owner |
|---|---|---|---|---|---|---|---|
| Harm taxonomy owner | A | C | R | C | C | C | I |
| Signal architecture | A | R | R | C | C | C | I |
| Severity triage | A | C | R | C | C | I | I |
| Pause / rollback | A | R | C | C | C | C | I / A for H4 |
| Customer review | C | I | R | C | C | I | I |
| Compensation policy | C | I | R | I | A | I | A for high amount |
| Evidence pack | A | R | R | C | C | C | I |
| Executive memo | R | C | C | C | C | I | A |
RACI 解释：R = Responsible，A = Accountable，C = Consulted，I = Informed。不同机构可按三道防线、模型风险政策和业务授权调整。
7. Proving Recovery：如何证明客户已经恢复
“处理完工单”不等于 “customer recovered”。恢复证明必须能回答四个问题：
- 影响范围是否完整识别：哪些客户、哪些交易、哪些渠道、哪些 AI 版本、哪个时间窗。
- 客户状态是否恢复：资金、访问、解释、权益、记录、服务路径是否已经纠正。
- 根因是否修复：模型、prompt、知识库、规则、流程、权限、培训或供应商问题是否已经改正。
- 同类伤害是否停止：修复后监控窗口内 repeat harm、appeal upheld、complaint、override、segment disparity 是否下降到可接受范围。
7.1 Remediation Evidence Pack
| Evidence section | 内容 | 质量要求 |
|---|---|---|
| Event summary | 发生了什么、何时发现、影响哪个产品和流程、严重度 | 一页内可被高管理解，事实和推断分开 |
| AI system context | AI system id、model/prompt/retriever/rule version、automation level、human oversight | 能连接 AI inventory 和 release record |
| Customer impact cohort | 受影响客户清单、筛选逻辑、排除逻辑、抽样验证 | SQL/规则/脚本有版本和审核记录 |
| Timeline | 发生、发现、升级、暂停、通知、复核、纠正、补偿、恢复、关闭时间 | 时间戳来自系统日志或审批记录 |
| Root cause analysis | 技术根因、流程根因、控制缺口、组织责任 | 不把原因停留在“模型错误” |
| Decision packet samples | 原始输出、最终动作、人工采纳/覆盖、政策依据、客户材料 | 保护隐私，使用受控访问 |
| Customer communications | 通知、解释、道歉、正式信函、补偿说明、申诉权利 | 用批准版本，记录发送和客户回应 |
| Financial correction | 退款、费用逆转、利息、补偿、税务或账务影响 | 计算逻辑可复核 |
| Restoration proof | 账户访问、额度、服务状态、投诉状态、KYC/AML 状态、材料状态 | 有 before/after 证据 |
| Control fix | feature flag、rule change、prompt change、knowledge update、model rollback、policy update、training | 关联变更审批和验证结果 |
| Post-fix monitoring | 监控窗口、KRI、复发情况、segment disparity、appeal outcome | 证明同类伤害没有持续发生 |
| Closure approval | Product、Ops、Risk、Compliance、Legal、Executive 的关闭意见 | 高严重度需要明确风险接受或关闭批准 |
7.2 Made Whole 判断
客户恢复不仅是“赔了钱”。不同 harm 需要不同恢复标准。
| Harm | Made whole 标准 |
|---|---|
| Financial loss | 错误费用、利息、罚金、退款、补偿和相关账户记录已纠正；客户不因错误承担后续负面影响 |
| Access denial | 客户可重新访问账户、服务、申诉、人工支持或产品流程；错误限制或拒绝记录已修正 |
| Wrong explanation | 客户收到准确、具体、可行动的解释；正式通知如涉及监管要求需重新审查 |
| Privacy exposure | 暴露范围、通知义务、数据删除/隔离、访问限制和后续监控已完成 |
| Discrimination | 受影响群体被识别并复核；不公平差异被修正；必要时批量纠正和补偿 |
| Delay | 客户请求被优先处理；因延迟产生的损失、费用或错过机会被评估和处理 |
| Emotional distress | 客户获得人工支持、道歉和简化流程；高敏场景由受训人员处理 |
| Regulatory complaint | 外部投诉得到一致、证据充分的回应；内部控制缺口进入整改 |
| Operational burden | 重复提交、重复验证、跨渠道追赶被消除；客户无需再次承担错误成本 |
8. Financial Retail Cases
8.1 Payment Dispute AI：支付争议 AI 错误拒绝
场景：AI 对交易争议进行分类、材料完整性判断、provisional credit 推荐或拒绝路由。模型把“unauthorized transaction”误判为“merchant dispute”，导致客户没有及时获得临时入账，后续产生滞纳金和资金压力。
| 维度 | 设计要点 |
|---|---|
| 可能伤害 | Financial loss、Delay、Wrong explanation、Emotional distress、Regulatory complaint |
| 主要信号 | dispute appeal upheld、客户重复来电、provisional credit reversal、late fee、监管投诉、AI classification override |
| 关键控制 | 高金额、高敏、欺诈关键词、脆弱客户信号进入人工复核；争议类型 AI 分类不得单独决定客户权利；客户材料缺失时给出明确行动清单 |
| Recourse | 暂停同类自动拒绝；人工复核 affected cohort；补发临时入账或退款；逆转费用和利息；发送解释；更新分类 eval set |
| Recovery proof | 受影响交易清单、AI 分类日志、人工复核结果、账户纠正、费用逆转、客户通知、修复后 upheld appeal 下降 |
高级 PM 面试点：支付争议场景的 recourse 不能只让客户“重新提交”。如果 AI 错误导致客户错过或延迟权益，机构应主动识别同类客户并恢复资金状态。
8.2 Lending Explanation AI：信贷解释 AI 给出错误原因
场景：AI 将 credit decision reason 转成客户可读解释。系统把真实主因“income verification incomplete”转成泛化的“credit history insufficient”，客户因此不知道应补交收入材料，也无法有效申诉。
| 维度 | 设计要点 |
|---|---|
| 可能伤害 | Wrong explanation、Access denial、Discrimination、Regulatory complaint、Operational burden |
| 主要信号 | explanation dispute、appeal upheld、call reason “why denied”、不同群体解释清晰度差异、manual reason code correction |
| 关键控制 | reason code pipeline 与正式决策系统绑定；LLM 只能润色 approved reason，不得创造原因；每个解释必须可追溯到实际主要原因 |
| Recourse | 重新出具准确解释；允许客户补正材料或重新审查；检查同一 reason transformation 影响范围；审查 segment disparity |
| Recovery proof | 原始决策理由、AI 生成解释、人工校验、重新通知、申诉结果、reason transformation 修复记录 |
高级 PM 面试点：解释不是“让用户感觉透明”，而是让客户能理解实际原因并采取合理行动。错误解释会把模型风险转化为客户权利损害。
8.3 Customer-Service RAG：客服 RAG 错引政策
场景：客户问信用卡年费减免、困难援助、争议时限或费用规则。RAG 检索到过期政策，回答“不能减免”，但当前政策允许特定条件下减免。客户放弃申请并支付费用。
| 维度 | 设计要点 |
|---|---|
| 可能伤害 | Financial loss、Wrong explanation、Operational burden、Delay |
| 主要信号 | policy QA fail、retrieval source stale、客户重复追问、员工 override、费用争议、abandoned journey |
| 关键控制 | 知识库文档有效期、policy owner、source freshness、citation guardrail、high-impact answer approval；高风险政策答案需要人工或系统 API 验证 |
| Recourse | 识别引用过期政策的会话；主动通知可申请客户；退还错误费用；更新知识库；加 stale source blocker |
| Recovery proof | source document version、conversation list、customer cohort、fee reversal、knowledge update approval、post-fix QA pass |
高级 PM 面试点：RAG 的伤害不只在“幻觉”，也在“看起来有出处但出处过期或不适用”。source freshness 是客户救济设计的一部分。
8.4 Wealth Advisory Assistant：财富助手越界建议
场景：财富管理 APP 的 AI assistant 本应提供教育和产品信息，却根据客户资产和风险偏好建议“可以加仓某高波动基金”。客户理解为机构建议并交易，随后损失。
| 维度 | 设计要点 |
|---|---|
| 可能伤害 | Financial loss、Wrong explanation、Regulatory complaint、Emotional distress |
| 主要信号 | trade after AI interaction、complaint “AI told me to buy”、advisor override、suitability exception、high-risk product query |
| 关键控制 | 教育、销售、建议、下单边界明确；高风险产品、个性化建议和交易动作必须转持牌人员或适当性流程；AI 不得给出具体买卖指令 |
| Recourse | 冻结相关话术；复核交易前 AI 对话；评估客户适当性、披露和损失因果；必要时补偿或交易纠正；更新 policy guardrail |
| Recovery proof | AI conversation、客户 profile、产品风险等级、交易时间线、advisor review、客户沟通、control change |
高级 PM 面试点：财富 AI 的最大风险不是答错定义，而是越过 education / recommendation / advice / execution 的边界，造成客户把 AI 输出当成专业建议。
8.5 AML False Positive Support：AML 误报支持流程伤害客户
场景：交易监控模型标记客户账户异常，客户服务 AI 只能回复“请等待审核”，无法说明需要哪些材料，也无法升级。客户工资入账和账单支付受到影响，反复提交材料仍无法恢复。
| 维度 | 设计要点 |
|---|---|
| 可能伤害 | Access denial、Delay、Operational burden、Emotional distress、Regulatory complaint |
| 主要信号 | account restriction aging、repeat document upload、call escalation、complaint “account frozen”、manual release after review、false positive rate |
| 关键控制 | AML 保密边界与客户可行动解释分离；AI 可说明流程状态、可提交材料和预计时限，但不得泄露敏感监控规则；高影响冻结需要 human case owner |
| Recourse | 人工复核 false positive；给客户明确材料清单和时间线；恢复账户或提供替代通道；检查同类 false positive cohort；优化 triage queue |
| Recovery proof | restriction timeline、customer notice、documents received、human review、release timestamp、repeat false positive monitoring |
高级 PM 面试点：AML 场景要平衡合规保密和客户可恢复性。不能因为不能披露监控规则，就让客户完全不知道如何恢复服务。
9. Artifact Templates
以下模板以“字段 + 规则 + 示例”呈现，便于直接转成 PRD、Confluence、Jira、GRC、case management 或 evidence binder。
9.1 Harm Taxonomy Template
| Field | Rule | Example |
|---|---|---|
| Category code | 使用稳定编号，便于报表和审计 | HARM-FIN-LOSS |
| Category name | 使用客户影响语言，不使用纯技术语言 | Financial loss |
| Definition | 一句话说明何时适用 | AI 造成或放大客户资金、费用、利息、退款或经济权益损失 |
| Included scenarios | 列出 3-7 个业务场景 | 错误费用、错误拒付、错误拒绝退款、错误投资建议、错过补偿 |
| Excluded scenarios | 明确不属于该类的边界 | 只有内部测试错误且未触达客户 |
| Primary signals | 可生产监控的信号 | appeal upheld、fee reversal、complaint amount、payment dispute reopened |
| Initial severity floor | 最低严重度 | H2；涉及批量或监管投诉时 H3+ |
| Recourse owner | 默认 owner | Payments Ops + Product Owner |
| Evidence required | 关闭 case 前需要的证据 | 决策日志、账户更正、补偿计算、客户通知 |
9.2 Harm Severity Matrix Template
| Dimension | H1 | H2 | H3 | H4 |
|---|---|---|---|---|
| Financial impact | 无资金损失或极小金额 | 小额费用、短期资金占用 | 明显损失、错误拒付、利息/罚金 | 批量重大损失或系统性错误 |
| Access impact | 短时不便 | 服务流程受阻 | 账户、信贷、支付或申诉被错误拒绝 | 大规模账户限制或关键服务不可达 |
| Explanation impact | 轻微不清楚 | 客户无法采取正确行动 | 正式通知或权益解释错误 | 批量错误解释或监管关注 |
| Privacy impact | 无敏感暴露 | 内部错放低敏信息 | 客户 PII 暴露或跨客户混淆 | 批量敏感数据暴露 |
| Segment impact | 未见差异 | 局部差异需要复核 | 受保护群体或脆弱客户明显受影响 | 系统性差异或外部投诉 |
| Recovery effort | 单次修正 | 需要人工复核和客户通知 | 需要补偿、批量扫描或合规参与 | 需要 executive response 和专项治理 |
9.3 Recourse Workflow Template
| Workflow field | Rule | Example |
|---|---|---|
| Trigger | 明确哪些信号创建 recourse case | Payment dispute appeal upheld after AI denial |
| Intake owner | 负责首轮分类和严重度 | CX Risk Triage Lead |
| Pause criteria | 何时暂停自动化 | 24 小时内出现 3 个同类 upheld appeals 或单个 H3 case |
| Review packet | 人工复核必须看到的材料 | AI output、policy version、customer documents、decision log、prior contacts |
| Customer action | 客户需要做什么，越少越好 | 不要求客户重复提交已在系统中的材料 |
| Correction action | 机构主动做什么 | Reopen dispute、issue provisional credit、reverse late fee |
| Compensation authority | 谁能批准什么金额或权益恢复 | Ops manager up to policy limit；高额由 Risk/Legal 审批 |
| Closure criteria | case 关闭条件 | 客户账户已更正，通知已发送，post-fix monitoring 已启动 |
9.4 Remediation Evidence Pack Template
| Section | Required content | Acceptance criteria |
|---|---|---|
| Executive summary | harm、scope、root cause、customer recovery、residual risk | 高管 3 分钟能理解决策 |
| Scope methodology | cohort query、时间窗、AI 版本、产品范围 | 可复核、可重复执行、有排除理由 |
| Customer impact table | 客户数、金额、状态、segment、通知状态 | 汇总数与明细一致 |
| Correction ledger | 每项纠正动作和完成时间 | 有系统记录或审批记录 |
| Compensation ledger | 金额、规则、审批、发放状态 | 财务和客户账户可对账 |
| Communication archive | 通知文本、发送渠道、发送时间、失败重试 | 与客户 case 对齐 |
| Control fix evidence | 变更记录、测试、审批、上线时间 | 证明根因已处理 |
| Monitoring results | 修复后 KRI、sample QA、segment review | 能证明复发风险受控 |
9.5 Customer Communication Template
客户沟通要做到准确、克制、可行动、不过度承诺。下面给出一个支付争议 AI 错误分类后的示例文本，正式使用需经 Legal / Compliance / Brand / Accessibility 审查。
我们完成了对您 2026-06-12 提交的交易争议请求的重新审核。此前系统将该请求归类为商户争议，导致处理路径不正确。我们已经更正分类，并按照未授权交易争议流程继续处理。
我们已经在您的账户中完成以下动作：
1. 重新打开争议案件，并由专员复核。
2. 撤销因该处理延迟产生的 35 美元滞纳金。
3. 将案件状态更新为“人工复核中”，预计在 5 个工作日内向您提供下一步结果。
您无需重复提交已经提供的材料。如果您有新的证明文件，可以通过手机银行争议案件页面上传，也可以联系人工专员。我们会在案件页面保留本次更正记录。
沟通控制要点：
- 不把“AI 出错”作为推卸责任的表达。
- 明确已经采取的纠正动作。
- 明确客户是否还需要行动。
- 明确时间线和人工入口。
- 避免承诺尚未完成的补偿或结论。
- 高风险场景使用正式通知和审核流程。
9.6 Executive Risk Memo Template
| Memo section | 内容规则 | 示例表达 |
|---|---|---|
| Decision needed | 管理层需要批准、接受或升级什么 | 批准对 1,248 名客户执行批量费用逆转，并暂停相关 AI 自动分类规则 |
| Harm summary | 用客户影响语言描述 | AI-assisted dispute classifier 将部分未授权交易错误路由为商户争议，造成处理延迟和费用影响 |
| Scope | 客户数、金额、产品、渠道、时间窗 | 影响窗口为 2026-06-01 至 2026-06-18，涉及信用卡争议渠道 |
| Customer recovery | 已恢复和仍在处理的数量 | 1,102 名客户已完成费用逆转，146 名客户进入人工复核 |
| Root cause | 技术、流程、控制共同说明 | 新增 merchant descriptor 特征后未覆盖欺诈关键词回归测试，且高风险争议缺少人工抽样门禁 |
| Risk assessment | 客户、合规、运营、声誉、复发风险 | 当前复发风险已通过规则暂停降低，仍需 14 天 post-fix monitoring |
| Recommendation | 明确下一步 | 执行批量通知、完成补偿、上线分类回归测试门禁、每周向风险委员会报告 |
| Evidence location | 指向证据包 | Evidence binder: AI-HARM-2026-06-PAY-DISPUTE-001 |
10. Metrics / KRIs
AI customer harm 指标必须同时覆盖发生率、恢复质量、速度、公平性和证据质量。只看投诉量会低估隐藏伤害；只看模型准确率会忽略客户影响。
| Metric / KRI | Definition | Why it matters | Typical slice |
|---|---|---|---|
| Harm rate | confirmed harm cases / AI-involved customer journeys | 观察 AI 客户旅程实际伤害率 | product、channel、AI system、version、segment |
| Repeat harm | same customer or same root cause harm recurrence within monitoring window | 判断恢复是否真正有效 | customer、root cause、journey step |
| Appeal upheld rate | appeals reversed or corrected / total appeals for AI-involved decisions | AI 决策或解释错误的强信号 | decision type、segment、reviewer、model version |
| Remediation SLA | cases restored within policy time / total harm cases | 衡量恢复速度 | severity、owner、product |
| Customer notification delay | notification timestamp - harm confirmed timestamp | 伤害确认后通知是否及时 | severity、channel、legal review path |
| Segment disparity | harm, denial, appeal upheld, delay or notification metrics by segment | 检测公平性和脆弱客户影响 | geography、language、age band、income proxy、protected-class proxy where lawful |
| Evidence completeness | evidence sections complete / required evidence sections | 证明恢复和审计 readiness | severity、system、owner |
| Override harm conversion | overrides later linked to confirmed harm / total overrides | 员工纠错是否预示客户伤害 | AI output type、team、policy |
| Abandonment recovery rate | abandoned high-risk journeys contacted or restored / total eligible abandoned journeys | 捕捉未投诉客户 | journey、step、device、language |
| Recourse accessibility | customers reaching human review / customers requesting or needing review | 防止 AI 自助化阻断救济 | channel、language、disability accommodation |
| Compensation accuracy | compensation adjustments without rework / total compensation cases | 衡量补偿计算和账务质量 | harm type、product、approval tier |
| Post-fix recurrence | same harm events after control fix / baseline | 判断根因修复是否有效 | model version、prompt version、rule id |
10.1 KRI Threshold 设计
| KRI | Green | Amber | Red | Action |
|---|---|---|---|---|
| Appeal upheld rate for AI decisions | 稳定低于历史基线 | 连续 2 周上升 | 超过基线 2 倍或高严重度个案出现 | Amber 触发 root cause review；Red 暂停相关自动化 |
| Customer notification delay H3+ | 当日通知或按批准流程执行 | 超过内部目标 | 未经批准延迟或客户先从外部渠道获知 | Red 触发 Legal/Compliance escalation |
| Evidence completeness H3+ | 100% required sections complete | 非关键证据缺失 | 决策日志、客户通知或恢复证明缺失 | Red 禁止关闭事件 |
| Segment disparity in harm rate | 无显著差异或有业务解释 | 差异扩大但样本有限 | 差异稳定存在且无合理解释 | 启动 fairness review 和 cohort remediation |
| Repeat harm | 修复后无复发 | 单点复发 | 同根因多次复发 | 重新打开 incident，升级 owner |
11. Product and Architecture Requirements
11.1 PRD Requirements
| Requirement area | Requirement |
|---|---|
| AI disclosure | 客户在适当时点知道 AI 或 AI-assisted process 参与了回答、路由、建议或决策支持 |
| Recourse entry | 高影响旅程必须提供清晰的人工复核、申诉、投诉或纠错入口 |
| Decision packet | 每个 AI-involved high-impact action 都要生成 decision packet，包含输入、输出、版本、政策依据、人工动作和时间戳 |
| Customer impact tagging | 事件和工单必须标记 potential harm category、severity 和 AI contribution |
| Pause mechanism | Product / Risk 能按 AI system、version、journey、cohort 或 rule 快速暂停相关自动化 |
| Explainability boundary | 客户解释必须来自 approved reason、policy 或 verified source；生成式 AI 不得创造正式理由 |
| Evidence-by-design | 证据在流程中自动产生，并与 case、AI inventory、model telemetry 和 customer communication 关联 |
| Batch remediation | 系统必须支持按时间窗、版本、规则、客户群体识别受影响 cohort，并执行批量恢复 |
| Accessibility | 通知、申诉和人工入口要考虑语言、无障碍、移动端、老年客户和脆弱客户 |
11.2 Solution Architecture Pattern
Channels
mobile / web / contact center / branch / email / regulator portal
AI layer
model / prompt / retriever / rules / agent tools / decision service
Control layer
policy engine / feature flags / human review queue / reason code service / consent and disclosure
Signal layer
complaints / appeals / overrides / escalations / abandoned journeys / QA / telemetry / regulator inquiries
Harm intelligence layer
harm event ledger / severity scoring / cohort detection / root cause taxonomy / KRI dashboard
Recourse operations
case management / customer communication / correction / compensation / restoration / evidence binder
Governance
AI inventory / release gates / model risk / compliance approval / audit / executive reporting
11.3 Integration Points
| Integration | Purpose | Risk if missing |
|---|---|---|
| AI inventory to case management | 知道哪个 AI 系统参与了客户 case | 只能看到工单，看不到 AI 版本和责任系统 |
| Model telemetry to complaint data | 把客户叙述连接到 AI 输出 | 投诉趋势无法驱动模型和知识库修复 |
| Decision service to evidence binder | 保存决策包和恢复证据 | 监管问询时无法复现 |
| Feature flag to incident workflow | 快速暂停或回滚高风险自动化 | 发现伤害后仍继续影响客户 |
| Compensation engine to case closure | 确认补偿已实际入账 | 工单关闭但客户资金未恢复 |
| Customer communication archive to legal hold | 保留对客户说了什么 | 外部投诉时口径无法证明 |
12. Operating Model
12.1 Three Lines of Defense
| Line | Role in AI customer harm |
|---|---|
| First line: Business / Product / Operations | 设计 recourse、处理客户恢复、运行控制、监控 KRI、维护证据 |
| Second line: Risk / Compliance / Model Risk / Privacy / Fair Lending | 设定政策、挑战设计、审查高风险事件、监督公平性和监管响应 |
| Third line: Internal Audit | 独立评估 harm management framework、控制设计、运行有效性和证据质量 |
12.2 Governance Cadence
| Cadence | Meeting | Inputs | Outputs |
|---|---|---|---|
| Daily for H3/H4 | Harm incident standup | New cases、pause status、customer recovery、evidence gaps | action owner、deadline、customer communication decision |
| Weekly | AI harm review | KRI dashboard、appeals、overrides、complaints、QA findings | root cause backlog、control changes、training needs |
| Monthly | Product risk committee | trend、segment disparity、recourse SLA、evidence completeness | risk acceptance、roadmap priority、policy updates |
| Quarterly | Executive governance | systemic themes、regulatory inquiries、material remediation | investment decision、risk appetite update、audit readiness |
12.3 Root Cause Taxonomy
| Root cause | Examples | Fix pattern |
|---|---|---|
| Model behavior | misclassification、calibration failure、drift、insufficient eval | retraining、threshold change、eval expansion、human gate |
| Retrieval / knowledge | stale source、wrong document、missing citation、policy ambiguity | content governance、source freshness、retrieval filter、policy owner sign-off |
| Prompt / agent design | overconfident tone、unsafe tool use、hidden escalation | prompt policy、tool permission、refusal and handoff state machine |
| Workflow design | no appeal path、bad queue priority、duplicate document request | service blueprint redesign、case routing、state synchronization |
| Data quality | wrong customer record、missing data、identity merge issue | data correction、lineage control、quality monitoring |
| Human adoption | employee over-relies on AI、fails to review | training、UI friction、review checklist、supervisor sampling |
| Policy / governance | unclear owner、weak approval、no pause criteria | RACI、release gate、risk appetite、control library |
| Vendor / third party | model change、API behavior change、missing logs | vendor SLA、change notification、contractual evidence rights |
13. Interview Section
Question: How do you design customer recourse for AI failures?
30-second answer
我会先把 AI failure 从“模型答错”改定义为“错误动作 + 客户影响 + 弱恢复路径”。设计 recourse 时，我会在客户旅程中预埋 detect、notify、pause、review、correct、compensate、restore、explain 和 monitor recurrence。也就是说，高风险 AI 决策必须可申诉、可人工复核、可暂停、可纠正，并且每一步都有证据。最后我会用 harm rate、appeal upheld、remediation SLA、notification delay、segment disparity 和 evidence completeness 来证明客户已恢复、根因已修复、同类伤害没有继续发生。
2-minute answer
我不会把 AI recourse 设计成客服 FAQ 或“联系人工”按钮。金融零售场景里，AI 可能影响支付争议、信贷解释、账户限制、AML false positive、财富建议和投诉处理，所以 recourse 必须是产品架构和运营控制。
第一步是 harm taxonomy。我要定义 financial loss、access denial、wrong explanation、privacy exposure、discrimination、delay、emotional distress、regulatory complaint 和 operational burden，并给每类定义 severity、SLA、owner 和 evidence。
第二步是 signal architecture。客户通常不知道 AI 参与了哪里，所以不能只靠投诉。我会把 complaints、appeals、overrides、escalations、abandoned journeys、regulator inquiries、incident tags、QA findings 和 model telemetry 接到 harm event ledger，关联 AI system、model version、prompt version、journey step 和客户影响。
第三步是 recourse workflow。发现潜在伤害后，要通知客户或内部 owner，暂停可能继续伤害的自动化，人工复核事实，纠正账户或决策，补偿资金损失，恢复访问或权益，给出准确解释，并在修复后监控复发。
第四步是证明恢复。每个高严重度 case 都要有 remediation evidence pack，包括影响范围、时间线、决策日志、客户沟通、纠正记录、补偿计算、控制修复和 post-fix monitoring。我的成功标准不是“工单关闭”，而是客户 made whole、同类客户被识别、根因被修复、证据可审计。
如果面试官追问落地，我会举支付争议 AI 的例子：一旦 appeal upheld 或同类投诉上升，我会暂停自动拒绝，批量找出同一模型版本影响的争议案件，人工复核，补发 provisional credit 或退费，通知客户，并把错误样本加入 eval 和 release gate。
14. Portfolio Exercise
Exercise: Design an AI Customer Harm Recourse System for a Retail Bank
背景：一家零售银行上线了三个客户可见 AI 能力：
- 支付争议 AI：自动分类争议类型并推荐处理路径。
- 信贷解释 AI：把拒贷或提额失败原因转成客户可读解释。
- 客服 RAG：回答账户、费用、困难援助和争议流程问题。
最近 30 天出现以下信号：
- 支付争议 appeal upheld rate 从 8% 上升到 19%。
- 信贷解释相关投诉中，“解释不清楚”和“原因不对”增加。
- 客服 RAG 在年费减免政策上出现过期引用。
- 有 2 个 CFPB 投诉提到 “chatbot would not let me talk to a person”。
- Contact center 员工覆盖 AI 摘要和建议的比例上升。
14.1 Deliverables
| Deliverable | 产出要求 |
|---|---|
| Harm taxonomy | 至少覆盖 9 类 harm，并标出每类信号、severity floor、recourse owner |
| Signal architecture | 画出 complaints、appeals、overrides、abandoned journeys、QA、telemetry 到 harm ledger 的数据流 |
| Severity matrix | 定义 H0-H4，说明升级触发器和管理层参与条件 |
| Recourse workflow | 针对支付争议 AI 写出 detect-to-monitor 的端到端流程 |
| Remediation evidence pack | 为一个 H3 事件列出证据目录、owner、质量标准 |
| Metrics dashboard | 定义 harm rate、repeat harm、appeal upheld、remediation SLA、notification delay、segment disparity、evidence completeness |
| Executive memo | 写一页管理层决策 memo，建议是否暂停自动争议分类和是否批量补偿 |
14.2 Evaluation Rubric
| Level | 标准 |
|---|---|
| Basic | 能列出 AI 错误和客服处理路径，但缺少客户影响、证据和批量恢复 |
| Strong | 能按 harm taxonomy、severity、recourse workflow 和 KRI 组织方案 |
| Advanced | 能连接 AI inventory、model telemetry、complaints、appeals、evidence binder 和 governance；能说明如何证明客户 made whole |
| Executive-ready | 能做出暂停、补偿、客户通知、监管准备和长期控制投资的管理层建议 |
15. Checklist
15.1 Use Case Intake
- AI 是否参与客户可见回答、排序、拒绝、建议、解释、路由、摘要或员工决策支持。
- 客户是否可能受到资金、访问、解释、隐私、公平性、时间、情绪、监管或运营负担影响。
- 是否定义了 harm taxonomy、severity floor、recourse owner 和 SLA。
- 是否识别高风险客户群体、语言、渠道、产品和脆弱客户。
- 是否有人工复核、申诉、投诉、暂停和回滚路径。
- 是否明确哪些 AI 输出不能作为正式通知、建议或拒绝理由。
15.2 Pre-Launch Gate
- AI inventory 已登记 system id、owner、model/prompt/retriever/rule version 和 automation level。
- Decision packet schema 已定义并在测试中生成。
- Customer communication 已经 Legal / Compliance / Brand / Accessibility 审查。
- Harm signals 已接入 complaints、appeals、overrides、escalations、abandoned journeys、QA 和 telemetry。
- Pause criteria 和 feature flag / rollback 机制已经演练。
- 高风险场景已完成 fairness、privacy、security、model risk 和 operational readiness review。
- Evidence pack 的证据来源、保留期限和访问权限已确认。
15.3 Production Monitoring
- 每周查看 harm rate、appeal upheld、override rate、abandonment、repeat contact 和 QA findings。
- 每月按 segment 查看 denial、delay、appeal upheld、notification delay 和 remediation SLA。
- 每次 model、prompt、retriever、knowledge base、policy 或 workflow 变更后比较 post-change harm signal。
- 外部投诉和监管问询进入 harm ledger，并关联 AI touchpoint。
- H3/H4 case 有每日恢复跟踪和 evidence gap review。
15.4 Remediation Closure
- 影响客户 cohort 已完整识别，筛选逻辑已复核。
- 客户资金、访问、权益、记录、解释或服务路径已恢复。
- 补偿计算、审批和入账已完成并可对账。
- 客户通知已发送，失败发送有重试或替代渠道记录。
- 根因控制已修复，并通过测试或生产监控验证。
- Segment disparity 已检查并记录结论。
- Evidence completeness 达到关闭标准。
- Repeat harm monitoring window 已启动并有 owner。
- 高严重度事件由指定 Product / Risk / Compliance / Legal / Executive owner 批准关闭。
15.5 Red Flags
- 团队说“这是模型误差，不是客户伤害”，但客户已经被拒绝、延误、收费或误导。
- 投诉下降，但 abandoned journeys、repeat contact 或 external complaints 上升。
- 人工入口存在，但客户需要多轮 chatbot 失败后才能找到。
- 员工大量 override AI，却没有结构化 reason 和 root cause review。
- AI 生成解释无法追溯到正式决策理由或政策来源。
- 修复只改 prompt，没有识别受影响客户和补偿。
- 工单关闭，但客户账户、费用、限制、正式记录或服务路径没有恢复。
- 证据包只有会议纪要和截图，没有系统日志、版本、时间线、客户通知和纠正记录。
16. Final Operating View
AI customer harm management 的成熟状态不是“AI 很少出错”，而是组织能持续证明：
We know where AI touches customers.
We know what harm can occur.
We detect harm from multiple signals.
We give customers reachable recourse.
We pause harmful automation quickly.
We review and correct with evidence.
We compensate and restore customers proportionately.
We explain in a way customers can act on.
We monitor recurrence and segment disparity.
We can prove recovery to customers, executives, auditors and regulators.
对 CBAP+、AI PM、AI Product Architect、Customer Experience Risk Lead 和 Solutions Architect 来说，这就是从“做一个 AI 功能”升级为“经营一个可信、可恢复、可审计的 AI 客户影响系统”。