AI Customer Harm / Redress / Recovery Architecture 解读

Source Anchors

核心导读

AI customer harm 不是“模型答错”这一件事，而是 AI 失败、客户影响、发现能力和恢复路径共同形成的产品与治理问题。金融零售 AI 一旦进入支付争议、信贷解释、费用说明、欺诈冻结、催收、投诉分流或客服 RAG，就会影响客户权益、时间成本、资金可得性、申诉机会和监管投诉概率。

成熟的 harm architecture 要回答三类问题：伤害如何被定义和分级，组织如何从运行轨迹、投诉、申诉、人工覆盖、QA、客户旅程和分群差异中发现伤害，系统如何把纠正、补偿、通知、复盘和防复发变成可执行闭环。它不是事故后的客服脚本，而是需求、评测、监控、流程、证据和管理动作之间的连接层。

可以把它理解为：

AI harm architecture =
  harm taxonomy
  + signal detection
  + severity classification
  + customer recourse
  + remediation evidence
  + recurrence prevention

1. 问题定义

低成熟度 AI 产品通常看准确率、满意度、调用量和成本。高成熟度金融 AI 还必须追问：

• 错误是否改变了客户权益、资金、服务准入、申诉机会或隐私暴露面。
• 客户是否知道如何纠错、补资料、申诉或升级。
• 组织是否能发现客户没有主动投诉的隐性伤害。
• 投诉、申诉、人工覆盖和 QA 发现能否回流到风险分类、评测集和控制规则。
• 对已经发生的伤害，能否证明已通知、纠正、补偿、恢复和防复发。

金融零售中的 AI 伤害通常不是单点技术故障，而是“错误输出 + 流程信任 + 客户行动”的组合。例如，支付争议 AI 错误解释提交截止日期，风险不只是知识库召回失败，而是客户可能错过争议权利；信贷解释 AI 编造拒绝原因，风险不只是文本不准确，而是 adverse action、可争辩性和公平信贷证据链失真。

2. 架构模型

Harm architecture 的核心是把客户影响从分散系统中抽象成同一类可治理对象：harm case。每个 case 需要记录来源、客户影响、AI 参与程度、严重度、受影响流程、负责人、纠正动作、客户沟通、证据和复发监控。

runtime traces
  + complaints
  + appeals
  + human overrides
  + QA findings
  + journey abandonment
  + regulator inquiries
  + incident reports
  + segment disparity
  -> harm detection layer
  -> harm case registry
  -> remediation workflow
  -> eval/control update
  -> management reporting

Severity 不能只看“模型错误有多严重”，还要看客户是否已经基于错误采取行动、是否错过权利期限、是否涉及资金或隐私、是否影响受保护群体或 vulnerable customer。

3. 关键机制/生命周期

完整生命周期不是“投诉来了再处理”，而是从设计期到运行期持续捕获客户影响。

design harm taxonomy
  -> instrument signals
  -> detect suspected harm
  -> classify severity
  -> contain or pause
  -> assign accountable owner
  -> human review
  -> correct record / decision / communication
  -> compensate or restore if needed
  -> notify customer
  -> update eval/control
  -> monitor recurrence

关键机制包括：

• 客户可见 recourse：纠错、补材料、申诉、升级和状态查询入口不能藏在普通客服路径里。
• 高风险自动建案：涉及资金、准入、隐私、投诉、弱势客户或监管关键词时，系统自动创建 review case。
• 人工复核边界：人工不是兜底口号，而要明确谁复核、复核什么、依据什么、多久完成。
• 纠正和补偿规则：退款、费用减免、账户恢复、重新评估、重新通知等动作需要规则、审批和证据。
• 防复发闭环：confirmed harm 必须进入 eval set、监控规则、prompt/RAG guardrail、流程培训或 release gate。

伤害信号也需要分层理解：

4. 证据与控制

Harm control 的重点不是证明“系统有控制”，而是证明控制真的运行、发现了问题、触发了动作、完成了恢复，并且改变了后续系统行为。

核心 KRI 不应只用于看板展示，而要绑定阈值、负责人、升级路径和整改期限。

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

Payment dispute AI

主要伤害是错误告诉客户争议不符合条件、延误证据提交、自动生成误导性状态说明。架构上要有 dispute deadline guardrail、客户可见纠错入口、高严重度投诉自动升级、appeal upheld rate 监控，以及被纠正案例进入争议政策 eval set。

Lending explanation AI

主要伤害是 AI 编造拒绝原因、使用过期政策、让客户误以为不能重新申请或不能补充资料。控制重点是 reason code source of truth、adverse action wording guardrail、policy version capture、高影响解释人工复核，以及解释质量的分群一致性。

Customer-service RAG

主要伤害是错误解释费用、账户限制、争议路径或例外条款，对 vulnerable customer 未升级。控制重点是 unsupported policy claim 检测、vulnerable customer escalation、complaint linkage dashboard、source freshness SLA 和高频问题回归评测。

Fraud or account restriction assistant

主要伤害是错误冻结、恢复路径不清、客户反复提交材料、过度披露欺诈规则。控制重点是恢复访问路径、最小必要解释、人工复核 SLA、false positive feedback loop 和客户摩擦 KRI。

6. 反模式

7. 最终心智模型

AI 产品的成熟度不取决于它从不出错，而取决于它能否在出错时保护客户、恢复权益、产生证据并让系统变得更不容易复发。Customer harm architecture 的核心不是“合规兜底”，而是把客户影响纳入产品运行模型。

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

customer impact
  -> harm signal
  -> severity
  -> recourse
  -> remediation
  -> evidence
  -> eval/control update
  -> recurrence monitoring

如果一个 AI 系统只能说明模型指标，却说不清哪些客户可能受害、如何发现、如何纠正、如何补偿、如何通知、如何防复发，它还没有进入金融零售 AI 的生产级治理状态。

---

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

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