AI Customer Harm：救济与恢复架构
一句话:
AI Customer Harm / Redress / Recovery Architecture 解读
面向对象: AI PM / Product Architect / Customer Experience Risk Lead / Senior BA / Compliance Product Lead。 核心问题: AI 失败不是只看模型有没有答错。真正的产品风险是客户是否受到伤害, 是否能发现, 是否有救济路径, 是否能恢复权益, 是否能证明组织已经纠正并防止复发。 学习目标: 建立 customer harm taxonomy、recourse workflow、remediation evidence、harm KRI 和 recovery operating model。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 risk management 语言组织 harm、impact、control 和 monitoring |
| NIST GenAI Profile | https://www.nist.gov/itl/ai-risk-management-framework/generative-artificial-intelligence-profile | 参考生成式 AI 风险、misuse、overreliance、information integrity |
| EU AI Act, Regulation (EU) 2024/1689 | https://eur-lex.europa.eu/eli/reg/2024/1689/oj | 参考 high-risk AI、human oversight、post-market monitoring、incident reporting |
| CFPB Consumer Complaints | https://www.consumerfinance.gov/data-research/consumer-complaints/ | 参考金融消费者投诉信号和问题分类 |
| FTC AI claims guidance | https://www.ftc.gov/business-guidance/blog/2023/02/keep-your-ai-claims-check | 参考 AI 宣称、误导性体验和客户风险沟通 |
一句话:
AI customer harm = AI-related failure + customer impact + weak detection or recovery path.
1. 为什么 Harm Architecture 是高级产品能力
低成熟度 AI 产品只问:
模型准确率多少？
用户满意度多少？
调用量多少？
高成熟度 AI 产品还问:
- 错误是否影响客户权益。
- 客户是否知道如何纠错。
- 组织是否能发现隐性伤害。
- 投诉、申诉、人工覆盖是否能回流到风险模型。
- 是否能证明已通知、纠正、补偿、恢复和防复发。
在金融零售场景里, AI 可能造成的伤害不是抽象伦理问题, 而是:
- 错误拒绝服务。
- 错误解释费用。
- 延迟处理争议。
- 错误分类投诉。
- 暴露隐私数据。
- 诱导客户相信错误政策。
- 对某类客户产生不公平体验。
2. Customer Harm Taxonomy
| Harm type | 示例 | 典型 AI 触发点 |
|---|---|---|
| Financial loss | 错误费用解释导致客户未及时申诉 | policy RAG hallucination |
| Access denial | 客户被错误引导放弃申请 | eligibility assistant |
| Wrong explanation | 拒绝原因、费用原因、争议状态解释错误 | explanation generator |
| Privacy exposure | RAG/日志泄露 PII | context assembly / logging |
| Discrimination | 某群体误拒率或误报率更高 | model/data/proxy bias |
| Delay | AI 错误分流导致 SLA 超时 | routing agent |
| Emotional distress | 欺诈/催收/投诉场景语气不当 | generated communication |
| Regulatory complaint | AI 答复被客户提交监管投诉 | customer-facing AI |
| Operational burden | 人工团队被大量错误升级淹没 | agent escalation design |
产品负责人要把 harm taxonomy 放进需求、评测、监控和 incident taxonomy, 而不是事故发生后临时归类。
3. Harm Signal Architecture
伤害信号不只来自模型 telemetry。
runtime traces
+ complaints
+ appeals
+ human overrides
+ QA findings
+ journey abandonment
+ regulator inquiries
+ incident reports
+ segment disparity
-> harm detection layer
| Signal | 可以发现什么 |
|---|---|
| Complaint reason | 客户感知的错误、误导、延迟 |
| Appeal upheld | 自动化或 AI 辅助流程错误 |
| Override spike | 人类不信任 AI 建议 |
| Escalation miss | 应人工处理但未升级 |
| Abandoned journey | 客户因错误解释或体验放弃 |
| QA defect | 内部发现但客户未投诉 |
| Segment disparity | 某群体受到更高失败率 |
| Regulator inquiry | 外部严重信号 |
| Cost reversal | 组织主动退款/纠正 |
4. Recourse Workflow
一条完整救济路径:
detect
-> classify harm
-> pause or contain
-> notify owner
-> human review
-> correct record / decision / communication
-> compensate or restore if needed
-> notify customer
-> update eval/control
-> monitor recurrence
关键设计:
- 客户能看见申诉/纠错入口。
- 高风险伤害自动创建 review case。
- 纠正动作有 owner、SLA、证据。
- 补偿不是临时人工决定, 而是有规则和审批。
- 伤害样本进入 eval set, 防止复发。
5. 金融零售案例
5.1 Payment dispute AI
伤害:
- 错误告诉客户争议不符合条件。
- 延误证据提交。
- 自动生成误导性状态说明。
控制:
- dispute deadline guardrail。
- customer-visible correction path。
- high-severity complaint auto-escalation。
- appeal upheld rate monitoring。
5.2 Lending explanation AI
伤害:
- AI 编造拒绝原因。
- 使用过期政策。
- 客户误以为不能重新申请。
控制:
- reason code source of truth。
- adverse action wording guardrail。
- policy version capture。
- human review for high impact explanation。
5.3 Customer-service RAG
伤害:
- 错误解释费用、账户限制、申诉路径。
- 对 vulnerable customer 未升级。
控制:
- vulnerable customer classifier。
- no unsupported policy claim。
- complaint linkage dashboard。
6. Harm Severity Matrix
| Severity | 客户影响 | 处理 |
|---|---|---|
| S0 | 无客户影响, 内部缺陷 | backlog fix |
| S1 | 轻微误导, 无损失 | correction + monitoring |
| S2 | 延迟、返工、轻微经济影响 | customer notification + remediation |
| S3 | 重大权益、资金、隐私或合规风险 | incident process + executive owner |
| S4 | 大规模或监管关注风险 | crisis response + regulator-ready evidence |
Severity 要同时看:
- harm magnitude。
- number of customers。
- reversibility。
- vulnerable customer impact。
- protected class / fairness concern。
- regulatory exposure。
7. Metrics / KRIs
| Metric | 用途 |
|---|---|
| AI-linked complaint rate | 识别客户可感知伤害 |
| Appeal upheld rate | 判断 AI/自动化错误 |
| Remediation SLA | 救济速度 |
| Repeat harm rate | 防复发效果 |
| Customer notification delay | 透明度 |
| Segment harm disparity | 公平性风险 |
| Evidence completeness | 审计能力 |
| Escalation miss rate | 人类监督有效性 |
| Compensation amount | 经济影响 |
8. 面试表达
30 秒版本:
我不会只用模型准确率管理 AI 风险。金融零售 AI 要有 customer harm architecture: 定义伤害分类、检测信号、严重度、申诉入口、人工复核、纠正补偿、客户通知和防复发评测。真正成熟的 AI 产品能证明发现了哪些客户伤害、如何恢复权益、如何防止再次发生。
2 分钟版本:
我会先把 AI harm 定义成 failure、customer impact 和 recovery path 的组合。比如支付争议 AI 错误解释截止日期, 不只是回答错, 而是可能让客户失去申诉机会。 架构上我会把 complaints、appeals、overrides、QA findings、journey abandonment、incident tags、segment disparity 和 telemetry 接入 harm detection layer。每个 harm case 进入 detect-classify-contain-review-correct-compensate-notify-monitor 的闭环。 产品上要有客户可见的纠错/申诉入口, 内部要有 severity matrix、owner、SLA、remediation evidence pack 和 recurrence monitoring。这样 AI 治理不只是防错, 还能在出错后保护客户和组织。
9. Portfolio Exercise
选择一个 customer-facing AI:
- 写 harm taxonomy。
- 画 harm signal architecture。
- 设计 recourse workflow。
- 写 severity matrix。
- 定义 8 个 KRI。
- 写一页 executive remediation memo。
输出:
- Customer Harm Control Pack。
- Recourse workflow diagram。
- Remediation evidence checklist。