AI 扩展计划 / Playbooks

AI Complaint Intelligence / Root Cause / Regulatory Response Playbook

重要说明: 本文是学习、作品集和内部治理训练材料, 不构成法律意见、合规结论、监管解释、客户赔付建议、审计意见、模型验证报告或正式投诉回复建议。正式项目必须由 Legal、Compliance、Risk、Complaint Operations、Model Risk、Privacy、Security、Data Governance、Business Owner、Technology Owner 和

761 行AI_COMPLAINT_INTELLIGENCE_ROOT_CAUSE_REGULATORY_RESPONSE_PLAYBOOK.md

AI Complaint Intelligence / Root Cause / Regulatory Response Architecture Playbook

定位: 面向 CBAP+、10 年金融零售产品/BA/开发背景的 AI PM、Product Architect、Enterprise Architect、Complaint Operations、Customer Harm、Compliance Technology、Model Risk、Internal Audit 和 Executive Sponsor。本文不是投诉处理基础教程, 而是把 AI complaint capability 设计成“客户伤害识别、根因定位、产品缺陷闭环、监管响应证据和管理层监督”的企业级架构。核心目标: 让投诉从分散工单升级为可治理、可追溯、可复盘、可审计、可持续改进的 complaint intelligence operating system。

1. Executive Framing

高管不需要一个“自动写投诉回复”的机器人。高管需要一个能回答以下问题的 operating system:

Which complaints indicate customer harm?
Which products, journeys, AI systems and controls are implicated?
Which root causes repeat across channels and regulators?
Which customers were affected and how were they restored?
Which fixes changed product, model, process, policy or control design?
Which evidence proves the response was timely, accurate and governed?
Which residual risks require management acceptance or investment?

Business case:

降低外部投诉、重复投诉和监管响应准备成本。
提高投诉 intake、分类、摘要、路由和证据完整性。
把投诉连接到 customer harm、product defect、control gap 和 CAPA。
识别 AI 在客户旅程和员工处理中的真实贡献。
将投诉样本回流 eval、knowledge governance、release gate 和 board MI。
支持 Legal/Compliance 以事实和证据为基础做正式判断, 而不是事后拼装材料。

Executive one-liner:

Complaint intelligence is the control plane that turns customer pain into traceable product and governance action.

2. Source Anchors

Anchor	Official link	本 playbook 的使用方式
CFPB Consumer Complaint Database	Consumer Complaint Database	外部投诉主题、产品分类、客户叙述和趋势锚点; 用于校准内部 taxonomy、harm monitoring、root-cause themes 和 public complaint learning
CFPB Compliance Circulars	CFPB compliance circulars	监管关注和 consumer finance supervisory signal 入口; 用于 regulatory horizon、control mapping 和 complaint scenario eval
OCC Customer Assistance Group	HelpWithMyBank.gov	银行客户外部投诉/协助渠道锚点; 用于 source routing、evidence freeze、timeline reconstruction 和 regulator response workflow
FDIC consumer complaints	FDIC consumer complaints	FDIC 消费者投诉锚点; 用于 complaint source taxonomy、external complaint routing 和 response package design
Federal Reserve consumer complaints	Federal Reserve Consumer Help	Federal Reserve 消费者投诉锚点; 用于 external complaint intake、case routing、fact reconstruction 和 response evidence
NIST AI Risk Management Framework	NIST AI RMF	用 Govern / Map / Measure / Manage 组织 AI complaint risk、impact mapping、measurement、management action 和 governance evidence
ISO/IEC 42001	ISO/IEC 42001:2023	用 AI management system 的 policy、roles、operational control、performance evaluation、internal audit 和 improvement 设计可持续运营体系

Source nuance:

外部投诉数据库和监管帮助页面不是个案法律结论, 也不是机构内部责任认定。
Circulars 和监管材料应转成 applicability questions、control implications、evidence needs 和 Legal/Compliance review items。
NIST AI RMF 和 ISO/IEC 42001 是 AI 风险管理和管理体系锚点, 不是单个模型通过/失败评分表。
本 playbook 把官方来源转成产品、流程、架构、证据和治理 artifact, 不替代正式法律/合规判断。

3. Operating Principles

Principle	Practical meaning	反模式
Original narrative is evidence	客户原话、录音、聊天和附件必须保留; AI 摘要只是派生产物	用 AI 摘要覆盖客户原文
Complaint category is not harm	产品主题、投诉原因、客户伤害和根因必须分层建模	把 “fees” 当成完整 RCA
No AI legal conclusion	AI 可以提取事实、问题和证据缺口, 不能正式判断法规适用、责任或赔付	回复草稿自动写 “we complied” 或 “not covered”
Evidence at source	证据在流程运行时捕获, 不靠事后补截图	监管问询后手工拼聊天、日志和审批
AI touchpoint traceability	每个投诉能判断 AI 是否影响客户体验或员工处理	无法知道 chatbot、routing model 或 copilot 是否参与
Harm-first prioritization	按客户影响、恢复难度、监管来源和复发风险排序	只按工单先来后到或客户情绪排序
Product defect linkage	重大或重复投诉必须连接产品、流程、模型、知识库、控制或供应商缺陷	个案关闭后没有系统修复
CAPA closure evidence	修复需要有效性验证和复发监控	变更上线即关闭整改
Board MI must drive action	管理层汇报显示风险、owner、决策和残余风险	热词云、总量趋势和平均处理时长堆砌

4. Capability Map

Capability	目标	关键产物
Complaint intake intelligence	多渠道投诉接收、身份/授权、原文保全、初始路由	intake schema、source taxonomy、evidence manifest
AI-assisted classification	产品、主题、严重度、监管来源、AI 触点、harm signal 分类	taxonomy、classifier eval、override reason
Governed summarization	事实摘要、客户主张、时间线、证据缺口和未解决问题	summary contract、span citation、QA rubric
Harm assessment	金融损失、访问拒绝、错误解释、隐私、延迟、公平性等影响识别	harm taxonomy、severity matrix、triage SLA
AI contribution matching	投诉关联 AI 系统、版本、prompt、RAG、工具调用和人工采纳	AI trace join、model registry link、case timeline
RCA and defect graph	根因定位并连接产品缺陷、控制缺口和 backlog	RCA ontology、defect linkage、CAPA ledger
Regulatory response evidence	外部投诉/问询的事实链、版本、审批和补救证据	evidence pack、timeline export、legal hold record
Customer communication control	回复、状态更新、补救通知和升级路径可控	template library、approval log、language QA
Remediation and CAPA	纠正客户状态、补偿/恢复、修复系统、防复发	corrective action、preventive action、effectiveness verification
Board MI and model risk	管理层监督、风险接受、模型风险和控制有效性	KRI dashboard、model risk report、committee memo

5. Target Reference Architecture

Channels
  customer portal | mobile | call center | branch | email | secure message | social escalation | regulator portals
        |
        v
Complaint intake and preservation
  source router | identity/authz | original narrative store | attachment store | transcript capture
        |
        v
Complaint intelligence services
  classification | summarization | entity extraction | harm scoring | duplicate clustering | language detection
        |
        v
Case and evidence platform
  complaint case | evidence manifest | customer timeline | product event graph | AI trace references
        |
        v
Investigation and decision workspace
  triage | queue routing | reviewer notes | fact verification | communication approval | escalation
        |
        v
RCA / defect / control graph
  RCA ontology | product defects | control gaps | eval gaps | policy/process changes | vendor issues
        |
        v
Remediation and CAPA
  containment | customer correction | compensation workflow | product change | control update | verification
        |
        v
Governance and response
  regulatory response pack | Legal/Compliance review | board MI | model risk monitoring | audit evidence

Architecture decision:

Decision	Recommended approach	Rationale
原文与摘要存储	原文 immutable / append-only, 摘要 versioned and reviewable	原文是证据源, 摘要可能被修正
分类自动化	AI 建议 + confidence + human override for high-risk	避免低估严重度和监管来源
AI trace	complaint case 只保存 trace reference, 不复制全部敏感日志	平衡可追溯性、隐私和最小权限
RCA	taxonomy-driven RCA + expert challenge	防止“模型错了”这种不可修复根因
response drafting	AI draft only, approval required for customer/regulator-facing content	避免越权承诺、法律结论和事实错误
CAPA closure	effectiveness verification + recurrence window	修复必须证明有效, 不止上线变更

6. Data Model: Complaint Event Ledger

投诉系统需要一个 complaint event ledger。它不必是单独数据库, 但必须有统一对象模型和跨系统引用。

Field group	Fields	设计要点
Identity	complaint_id、case_id、customer_id_token、representative_id、account_ref、product_ref	使用 tokenized identifier; 权限控制和审计访问
Source	channel、source_type、regulator_source、received_at、jurisdiction、language、accessibility_needs	支持 SLA、routing、external response workflow
Original evidence	narrative_ref、transcript_ref、attachments_ref、email_ref、call_recording_ref	原始证据不可被 AI 摘要覆盖
Product context	product、journey_step、related_transaction、loan_application、dispute_id、KYC_case_id	支撑 product defect linkage
AI context	ai_touchpoint_flag、ai_system_id、model_version、prompt_version、rag_index、tool_call_ref、employee_copilot_flag	支撑 AI contribution matching
Classification	complaint_category、sub_category、harm_category、severity、regulatory_sensitivity、vulnerable_customer_signal	分类可被人工覆盖并记录原因
Investigation	owner_team、reviewer、facts_verified、evidence_gaps、decision_points、approvals	事实、判断和审批分离
Communication	acknowledgement_ref、status_update_ref、resolution_ref、remediation_notice_ref、regulator_response_ref	所有对外内容版本化
Remediation	correction_action、compensation_action、account_restored_at、customer_notified_at、made_whole_status	补救范围和适用性由授权 owner 确认
RCA/CAPA	root_cause_id、defect_id、control_gap_id、CAPA_id、change_id、eval_update_id、closure_approver	连接修复和防复发
Governance	evidence_status、legal_hold_flag、risk_acceptance_id、board_MI_flag、retention_class	支撑审计、监管响应和管理层监督

7. Complaint Intake Design

7.1 Source Routing

Source type	Examples	Immediate actions
Internal customer complaint	web form、call center、branch、secure message、mobile app	保存原文、确认产品上下文、初始分类、SLA clock
External regulator complaint	CFPB、OCC、FDIC、Federal Reserve、state regulator	evidence freeze、Legal/Compliance routing、response timeline、senior owner
Executive / social escalation	executive office、public social、media inquiry	reputation risk tag、source verification、communication approval
Employee-identified complaint	frontline escalation、QA finding、complaint misclassification	employee source flag、training/control signal
Complaint-adjacent signal	appeal upheld、dispute reversal、repeat contact、abandonment	harm review, may create complaint/harm event based on policy

7.2 Intake Quality Gates

Gate	Pass condition	Failure action
Source captured	channel/source/time received are recorded	route to intake repair queue
Original narrative preserved	raw text/audio/transcript/attachment ref exists	block summary-only closure
Product context linked	at least product family and journey hypothesis	request additional context or search product event graph
Customer request identified	complaint asks for correction, explanation, refund, review, apology, access, status, other	mark request unknown and assign reviewer
AI touchpoint checked	journey and employee tool logs checked for AI involvement	create AI trace search task
Severity screened	harm/severity/regulatory source/vulnerable signal assessed	escalate if uncertain and potential high impact
Evidence manifest created	evidence refs, missing evidence and owner captured	open evidence collection tasks

7.3 Intake Anti-patterns

Anti-pattern	Why it fails	Fix
“Customer misunderstood” default category	预设客户错, 遮蔽产品和沟通缺陷	使用 neutral assertion categories
Free-text-only intake	后续无法做趋势、RCA 和证据检索	structured taxonomy + raw narrative
AI summary as system of record	摘要可能遗漏或歪曲事实	raw evidence as source of truth
External complaints handled outside case system	监管响应证据和内部 CAPA 断裂	same ledger with external source flag
No AI touchpoint flag	无法判断 AI 是否造成或放大问题	join with AI inventory and trace logs

8. Classification Taxonomy

投诉分类需要多维度, 不应只保留一个 reason code。

Taxonomy layer	Values / examples	Owner
Product family	deposits、credit card、mortgage、auto loan、personal loan、payments、wealth、insurance、wallet、merchant services	Product Ops
Customer assertion	unauthorized、wrong fee、wrong denial、delay、misleading information、privacy concern、discrimination concern、access issue、service failure	Complaint Ops
Journey step	onboarding、application、decision、transaction、servicing、dispute、collections、closure、remediation	Product / BA
Harm category	financial loss、access denial、wrong explanation、privacy exposure、delay、disparate treatment、operational burden、emotional distress	Risk / Customer Harm
Regulatory sensitivity	external complaint、legal threat、protected class concern、privacy/security、credit/adverse action、payments dispute、collections、vulnerable customer	Legal / Compliance
AI contribution type	none detected、customer-facing AI、employee copilot、routing model、summarizer、decision support、workflow automation、vendor model	AI Governance
Root cause hypothesis	data、model、prompt、RAG、workflow、policy、UX、communication、control、vendor、training、governance	RCA Owner
Resolution path	explanation、correction、refund/credit、account restoration、investigation、appeal、policy exception、no action with rationale	Business Owner

Controlled vocabulary:

Use	Avoid
`customer_asserts_wrong_fee`	`customer_is_confused`
`possible_regulatory_sensitivity`	`regulatory_violation` unless Legal/Compliance determined
`AI_contribution_under_review`	`AI_caused_it` before RCA
`evidence_gap_customer_statement_only`	`unproven complaint`
`human_override_AI_summary`	silent edits with no reason
`product_defect_candidate`	`known defect` before review

9. AI Summarization Architecture

9.1 Summary Types and Controls

Summary type	Audience	Controls
Intake summary	complaint triage team	span citation、claim/fact separation、uncertainty markers
Investigation summary	reviewer / investigator	evidence refs、missing facts、timeline and decision points
Executive theme summary	management / board MI	sample traceability、aggregation rules、confidence and data limits
Regulator response support summary	Legal/Compliance / response team	approved facts only、no final wording without review
Customer response draft	complaint owner / authorized responder	approved template、plain language、no unsupported commitment

9.2 Summary Rubric

Criterion	Pass standard	Failure example
Faithfulness	所有关键事实可指回原文或证据	客户说 “charged twice”, 摘要写成 “asked about fee”
Completeness	金额、时间、产品、请求、伤害、渠道、之前互动都保留	漏掉客户已联系三次
Neutrality	不预设客户、员工或机构责任	写成 “customer did not understand”
Risk sensitivity	识别外部投诉、隐私、歧视、信贷、支付、催收、脆弱客户信号	把 CFPB 来源当普通客服工单
Actionability	列出需要核查的事实和 evidence owner	只写情绪描述
Boundary control	不做法规适用、责任、赔付或正式合规结论	写成 “not eligible under regulation”

9.3 AI Summary Output Contract

complaint_summary:
  summary_version: "v1"
  source_refs:
    - narrative_span_id
    - transcript_segment_id
  customer_claims:
    - claim: "Customer says a duplicate fee was charged after chatbot said no refund path existed."
      source_ref: "span-004"
      status: "customer-stated"
  verified_facts:
    - fact: "Two fee transactions exist on account timeline."
      evidence_ref: "txn-ledger-112"
      status: "system-record"
  possible_harm:
    - category: "financial_loss"
      impact: "Potential duplicate fee and delay in refund review."
      confidence: "medium"
  regulatory_sensitivity:
    - "external_complaint_source"
    - "fee_explanation"
  ai_touchpoint:
    - system_id: "AI-CS-RAG-002"
      trace_ref: "trace-789"
      role: "customer-facing answer"
  open_questions:
    - "Was the chatbot response based on current fee policy?"
    - "Was refund/dispute path visible to the customer?"
  prohibited_conclusions_not_made:
    - "legal_applicability"
    - "liability"
    - "compensation_amount"

10. Harm Severity Matrix

Severity	Definition	Examples	Default handling
H0 near miss	AI/流程错误被拦截, 客户未受影响	QA 发现摘要遗漏但未用于处理	log, trend, fix in backlog based on risk
H1 low impact	一次性轻微不便或解释不清, 无明显资金/权益影响	状态更新表达不清, 客户二次询问	correct communication, monitor trend
H2 material inconvenience	延迟、重复提交、错误解释、小额费用、短期访问阻断	投诉被分错队列导致响应延迟	supervisor review, customer update, RCA
H3 significant harm	资金损失、错误拒绝、隐私暴露、监管投诉、脆弱客户或正式申诉	CFPB 投诉称 AI 错误阻断 dispute path	same-day escalation, evidence freeze, CAPA
H4 systemic / critical	批量影响、受保护群体差异、重大隐私/资金/监管暴露	某版本 chatbot 系统性误导客户权利路径	crisis governance, executive owner, cohort review

Severity modifiers:

外部监管来源或律师/媒体信号。
客户可能错过期限、申诉机会或权益恢复窗口。
影响信贷、支付争议、催收、KYC/AML、隐私、安全、财富建议。
vulnerable customer、有限语言能力、无障碍需求、困难援助、欺诈受害者。
同一 AI system / prompt / policy / product journey 关联多个案例。
证据缺口导致无法重建事实。

11. Root Cause Analysis Framework

11.1 RCA Stages

Complaint trigger
  -> harm and severity assessment
  -> AI contribution matching
  -> direct cause identification
  -> systemic cause analysis
  -> control gap mapping
  -> corrective and preventive action
  -> effectiveness verification
  -> closure and recurrence monitoring

11.2 RCA Taxonomy

Root cause family	Typical causes	Correction candidates
Data	stale product data、wrong customer status、missing transaction、label ambiguity、poor lineage	data quality rule、source reconciliation、data contract
Model	classifier confusion、severity underestimation、poor calibration、segment performance gap	retraining、threshold change、eval suite、monitoring
Prompt	instruction conflict、missing refusal rule、tone mismatch、weak uncertainty handling	prompt revision、prompt review gate、prohibited outputs
RAG / knowledge	superseded policy、low-authority source、bad chunking、permission filter miss、citation mismatch	source governance、index rebuild、retrieval ranking、citation gate
Workflow	wrong queue、broken handoff、SLA clock missing、manual workarounds	routing rules、BPMN update、case state machine
Product UX	hidden complaint path、unclear status、duplicate upload、non-actionable errors	journey redesign、content update、accessibility review
Communication	unsupported promise、unclear response、blame language、inconsistent template	template update、approval flow、QA sampling
Policy / procedure	SOP unclear、exception path missing、owner ambiguity	SOP revision、decision table、training
Control	no release gate、no monitoring、no evidence capture、no sampling	control library update、KRI、evidence automation
Vendor	vendor model change、service outage、insufficient audit right、subprocessor issue	contract control、change notice、fallback
Governance	risk acceptance undocumented、committee bypass、unclear accountability	RACI、approval gate、management attestation

11.3 RCA Quality Bar

Weak RCA	Strong RCA
“AI gave wrong answer”	“RAG retrieved superseded policy because source authority ranking ignored effective date; prompt did not force current-policy check; no complaint KRI linked to fee-policy errors”
“Agent handled poorly”	“Agent workspace displayed AI summary without missing-fact flag; training did not require review of source transcript for H3 external complaints”
“Customer misunderstood”	“Customer communication template did not explain dispute path and chatbot fallback hid human escalation in fee-error scenarios”
“Volume spike”	“Campaign increased annual-fee questions by 4x; routing model threshold not recalibrated and backlog SLA alert did not trigger”

12. Product Defect Linkage

投诉智能系统应维护 complaint-to-defect graph:

complaint_id
  -> harm_event_id
  -> product_capability_id
  -> journey_step
  -> ai_system_id / trace_ref
  -> root_cause_id
  -> product_defect_id
  -> control_gap_id
  -> change_request_id
  -> eval_update_id
  -> CAPA_id
  -> verification_result

12.1 Defect Creation Decision Table

Condition	Create product defect?	Additional action
H3/H4 complaint with product or AI contribution	Yes	executive escalation and evidence freeze
H2 complaints repeat above threshold in same journey	Yes	trend RCA and backlog prioritization
AI summary/classification error affects routing or response	Yes	model/prompt/eval issue and QA sampling
external complaint references same prior unresolved issue	Yes	CAPA review and management escalation
one-off complaint with no systemic issue after review	No product defect	document rationale and monitor trend
unclear evidence but potential high harm	provisional defect candidate	assign owner and time-box investigation

12.2 Product Backlog Fields

Field	Example
defect_id	`DEF-COMP-FEE-RAG-2026-014`
linked_complaints	complaint ids / cluster id
harm_category	wrong explanation + financial loss
affected_capability	credit card fee explanation RAG
affected_journey	servicing -> fee question -> dispute path
AI component	retriever + prompt + customer-facing response
root cause	stale source ranked above current policy
control gap	no effective-date retrieval gate
fix scope	source governance + retriever + prompt + eval + UX handoff
release gate	model risk review, complaint ops approval, compliance content approval
verification	locked eval, QA sample, complaint trend, recurrence window

13. Complaint-to-Control Loop

13.1 Required Resolution Outcomes

Every material complaint cluster should resolve into one or more:

Outcome	Meaning
Case-specific correction	客户个案事实或状态被纠正
Customer remediation	账户、费用、访问、解释、补偿或服务路径被恢复
Product defect	产品/旅程/UX/流程进入修复
AI system issue	model、prompt、RAG、tool、summary、classifier 进入治理变更
Control update	新增或修改控制、KRI、sampling、release gate
Eval update	投诉样本脱敏后进入 regression / safety / harm eval
Training/SOP update	员工处理、审批、模板、handoff 规则变更
Risk acceptance	管理层接受残余风险, 有 owner、理由、期限和复核
No systemic issue rationale	记录为什么无需系统修复, 并定义监控条件

13.2 Control Library Mapping

Finding	Control objective	Evidence
high-risk complaints misrouted	H3/H4 source and harm signals route to senior queue	classifier eval, routing log, override sample
AI summary omits customer request	summaries preserve claim/request/impact with source span	summary QA report, prompt version, reviewer overrides
stale policy in RAG	only current approved policy can support customer-facing answer	source inventory, effective date check, retrieval log
response overpromises outcome	customer communications use approved templates and fact refs	template approval, draft diff, final message record
repeated fee complaints	complaint themes trigger product defect review	theme dashboard, defect ticket, committee minutes
CAPA closure too fast	closure requires post-fix monitoring and recurrence check	eval run, production KRI, closure approval

14. Regulatory Response Evidence Pack

外部投诉或监管问询需要一套可复用 evidence binder。它不是为包装结论服务, 而是让授权团队快速重建事实、行动和控制。

14.1 Evidence Binder Structure

Section	Contents	Purpose
01-source-intake	external complaint source, received timestamp, original narrative, attachments, authorization	证明投诉如何进入机构
02-customer-product-context	account/product references, transaction/application/case timeline, prior contacts	建立事实背景
03-AI-involvement	AI system inventory record, trace refs, model/prompt/RAG/tool versions, employee adoption/override	判断 AI 参与方式
04-investigation	evidence manifest, verified facts, unresolved facts, reviewer notes, approvals	说明调查过程
05-policy-procedure	relevant internal SOP, template, rule catalog version, ownership	说明当时流程和控制
06-customer-communications	acknowledgement, status updates, final response, remediation notice	证明沟通内容和时间
07-remediation	correction, compensation, account restoration, customer notification, cohort review	证明客户恢复动作
08-RCA-CAPA	root cause, corrective action, preventive action, change records, eval updates	证明系统修复
09-management-oversight	escalation, committee decision, risk acceptance, board MI extracts	证明管理层监督
10-response-approval	Legal/Compliance review, final response approval, submission record	证明正式回复治理

14.2 Response Readiness Checklist

Check	Pass condition
Source authenticity	external source, date/time, complaint id and attachments captured
Timeline consistency	all events use normalized timestamp and event source
Original vs derived	original narrative and AI summaries separated
AI traceability	AI versions and outputs can be referenced without overexposing sensitive logs
Fact status	facts are marked customer-stated, system-record, employee-observed, under-review
Communication approval	customer/regulator-facing content has authorized approval
Remediation status	correction/restoration/compensation status is recorded with owner
CAPA status	root cause and preventive action have evidence and verification metric
Legal/Compliance ownership	applicability, response wording and submission decision owned by authorized teams
Retention/legal hold	evidence hold and retention class applied where required by policy

15. Customer Communications Control

15.1 Communication Decision Table

Communication type	AI role	Required controls
Acknowledgement	draft allowed	template, source/time confirmation, no outcome promise
Status update	draft allowed with fact refs	latest case status, next step, delay reason, owner approval for H3/H4
Information request	draft with evidence-gap list	request only necessary facts, avoid duplicate requests, accessibility review
Explanation of resolution	draft support only	evidence references, approved reason codes, human approval
Remediation notice	draft support only	remediation decision exists, customer-impact language reviewed
External regulator response	research and structuring only	Legal/Compliance-owned final response and submission

15.2 Prohibited AI Outputs

AI complaint tools should not independently produce:

Final legal or compliance conclusions.
Statements that a regulation applies or does not apply to a customer without authorized review.
Unsupported denial, eligibility, liability, fraud, negligence or blame statements.
Compensation amounts or refund promises not backed by approved workflow.
Claims that customer harm is resolved without remediation evidence.
Statements that hide complaint, appeal, escalation or human review paths.

15.3 Plain-Language Response Requirements

Requirement	Why it matters
State what was reviewed	客户和 reviewer 能理解事实基础
Distinguish facts and next steps	避免把调查中事项写成结论
Explain action taken	说明纠正、恢复、补救或继续调查动作
Provide path for questions or review	避免 dead-end automation 和重复投诉
Avoid blame and technical jargon	降低情绪伤害和误解
Preserve accessibility and language needs	支持公平体验和可达性

16. Remediation / CAPA Operating Model

16.1 CAPA Workflow

Detect complaint / harm signal
  -> classify severity and source
  -> contain customer-impacting path
  -> investigate and verify facts
  -> assess AI contribution
  -> perform RCA
  -> define corrective action
  -> define preventive action
  -> update product/model/process/control/eval
  -> verify effectiveness
  -> monitor recurrence
  -> close with approval

16.2 Corrective vs Preventive Actions

Problem	Corrective action	Preventive action
customer received wrong fee explanation	send corrected explanation and review fee impact	update RAG source governance and fee-policy eval
complaint misrouted as low severity	reassign case and accelerate review	tune classifier, add external-source sentinel
AI summary omitted vulnerability signal	reviewer updates case and customer handling	summary contract includes vulnerability/accessibility field
response draft overpromised refund timing	replace response with approved template	response safety eval and approval gate
repeated complaint cluster across branch/call center	cohort review and customer outreach where approved	product journey redesign and board MI monitoring

16.3 Closure Criteria

Closure dimension	Evidence
Customer restored	account/action/status corrected, customer notified, open request addressed
Root cause fixed	linked change deployed or process/SOP/control updated
Control strengthened	control owner, frequency, evidence and KRI defined
Eval updated	relevant complaint scenario added to regression/safety/harm eval
Effectiveness proven	before/after metric, QA sample, production KRI, recurrence window
Residual risk handled	risk acceptance or further action documented
Governance approved	appropriate owner signs closure based on severity

17. Model Risk and AI Governance

17.1 Risk Tiering

Use case	Risk tier lens	Default controls
complaint classifier	May affect regulatory response, customer harm triage and SLA	model/prompt eval, human override, monitoring by source/product/segment
complaint summarizer	May shape investigation and response	faithfulness eval, span citation, reviewer approval for high risk
response drafter	Customer/regulator-facing content risk	approved templates, prohibited outputs, human approval
RCA suggester	May bias defect and control decisions	expert review, taxonomy constraint, no legal conclusion
trend analyzer	Management MI and board action risk	metric lineage, data quality, confidence limits
duplicate detector	May hide individual harm or reveal systemic clusters	precision/recall sampling, human cluster review

17.2 Evaluation Suite

Eval suite	Measures	Sample sources
classification eval	category, severity, source, harm, AI touchpoint accuracy	historical complaints, synthetic edge cases
summary faithfulness eval	omission, distortion, unsupported inference, source-span alignment	human-labeled summaries
harm extraction eval	financial/access/privacy/delay/fairness detection	remediated cases and complaint narratives
response safety eval	overpromise, blame, legal conclusion, unclear next step	approved/rejected response drafts
RCA quality eval	actionable root cause, layer depth, control linkage	closed CAPA and expert challenge cases
segment performance	language, channel, vulnerable signals, product, geography	stratified samples

17.3 Monitoring KRIs

KRI	Why it matters
AI-linked complaint rate	客户投诉是否集中在 AI 触点
high-risk misroute rate	H3/H4 或外部投诉是否被低估
summary override rate	人工频繁改摘要说明模型或 contract 有问题
unsupported response draft rate	回复生成安全边界是否有效
complaint cluster recurrence	同根因是否复发
CAPA aging	根因修复是否拖延
evidence completeness	监管/审计响应是否可证明
segment disparity in complaints	某群体或渠道是否承受更高伤害
remediation SLA breach	客户恢复是否及时
risk acceptance expiry breach	残余风险是否过期未复核

18. Board MI and Executive Reporting

18.1 Board Dashboard

Board question	Metric / visualization
哪些客户伤害风险正在上升?	complaint severity trend by product/journey/source
AI 是否造成或放大投诉?	AI-linked complaint clusters by system/version
外部监管投诉是否集中在某些主题?	CFPB/OCC/FDIC/Fed/state source trend and aging
客户是否被恢复?	made-whole status, remediation SLA, unresolved H3/H4
系统性根因是什么?	top RCA families, repeat root causes, CAPA aging
控制是否有效?	evidence completeness, summary QA pass, misroute rate
管理层做了什么决策?	open decisions, risk acceptances, investment asks
风险是否复发?	recurrence after closure, post-fix monitoring status

18.2 Executive Memo Template

# Complaint Intelligence Management Update

## Headline risk
One sentence on current complaint risk and management action.

## Material themes
- Theme, affected product/journey, source, severity, trend.

## AI involvement
- AI systems or employee tools implicated, status of trace review.

## Customer harm and remediation
- Affected cohort, remediation status, open issues.

## Root cause and CAPA
- RCA family, corrective actions, preventive controls, owner, due date.

## Evidence and regulatory readiness
- Evidence completeness, external response status, approval owner.

## Decisions requested
- Funding, scope reduction, release pause, risk acceptance, policy change.

19. RACI

Activity	PM	BA	Architect	Complaint Ops	Legal/Compliance	Model Risk	Data/Security	Business Owner	Internal Audit
taxonomy design	A	R	C	R	C	C	C	C	I
intake workflow	C	R	C	A/R	C	I	C	C	I
AI trace architecture	C	C	A/R	C	C	C	R	I	I
summary/routing eval	A	R	C	R	C	R	C	C	I
regulatory response wording	I	C	I	R	A/R	C	I	C	I
RCA and CAPA	A	R	C	R	C	C	C	A	I
product defect prioritization	A/R	C	C	C	C	C	I	A/R	I
board MI	R	C	C	C	C	C	C	A	I
control testing	I	C	C	C	C	C	C	I	A/R

Legend: R = Responsible, A = Accountable, C = Consulted, I = Informed.

20. Implementation Roadmap

0-30 days: Establish control baseline

Workstream	Deliverable
taxonomy	complaint category, harm category, AI contribution and RCA taxonomy
source routing	internal/external complaint source map and escalation rules
evidence	complaint event ledger fields and evidence manifest
AI summary	summary contract, prohibited outputs, human review rules
MI	baseline dashboard: severity, source, product, aging, evidence completeness

31-60 days: Connect intelligence loop

Workstream	Deliverable
AI trace	join complaint cases to AI inventory and trace refs
eval	classification, summary faithfulness, harm extraction and response safety eval
product defects	complaint-to-defect graph and escalation thresholds
CAPA	root cause ledger, corrective/preventive action workflow
communications	approved templates and response draft approval workflow

61-90 days: Institutionalize governance

Workstream	Deliverable
regulatory response	evidence binder and response readiness checklist
board MI	executive dashboard with RCA, CAPA aging, residual risk
model risk	monitoring KRIs, segment performance, override analysis
control library	complaint-to-control mapping and test procedures
operating model	RACI, committee cadence, risk acceptance and recurrence review

21. Evidence / Control Checklist

Area	Check
Intake	original narrative, source, product context, received time, attachments captured
Classification	product, issue, harm, severity, source and AI contribution assigned or marked under review
Summary	AI summary has source spans, uncertainty and reviewer status
AI trace	related AI system/version/prompt/RAG/tool references captured where applicable
Investigation	facts distinguish customer-stated, system-record, employee-observed and under-review
Communication	customer-facing content approved and stored with final version
Remediation	correction/restoration/compensation status and owner recorded
RCA	root cause points to fixable layer and control gap
CAPA	corrective and preventive actions linked to changes and eval updates
Verification	fix effectiveness measured with eval, QA, KRI and recurrence window
Regulatory response	evidence pack complete and Legal/Compliance approval recorded
Board MI	material themes, residual risk and management decisions reported

22. Anti-patterns

Anti-pattern	Consequence	Better design
Treating AI complaint tool as cost-reduction chatbot	Faster but less reliable complaint closure	design as evidence and control system
Replacing original narrative with summary	Loss of evidence and customer voice	immutable raw evidence + versioned summary
One taxonomy field for everything	Cannot distinguish issue, harm and root cause	multi-layer taxonomy
No linkage to AI traces	Cannot assess AI contribution	trace refs joined to case timeline
RCA stops at “agent error”	Training becomes default fix for system defects	root-cause ontology across data/model/RAG/workflow/control
Regulatory complaints handled separately	External response does not improve product controls	same ledger with source and evidence flags
CAPA closes after deployment	No proof fix worked	effectiveness verification and recurrence monitoring
Board sees only counts	No management action	risk/action dashboard with owners and residual risk
AI draft sends directly to customer	Unsupported commitment or legal conclusion risk	human approval and template controls

23. Portfolio Case Drill

Scenario: A retail bank deploys an AI assistant in mobile and call center channels. Complaints rise around credit card fees, payment disputes and account restrictions. Some complaints arrive through CFPB, OCC Customer Assistance Group, FDIC consumer complaint channel and Federal Reserve Consumer Help depending on entity/product routing. Legal/Compliance owns formal applicability and response decisions.

Build the following:

Artifact	Required content
Complaint event ledger	schema with original narrative, source, product, AI touchpoint, evidence, classification, remediation
Harm taxonomy	financial loss, access denial, wrong explanation, privacy, delay, disparate treatment, operational burden
AI summary contract	source-span citations, claim/fact separation, open questions, prohibited conclusions
RCA ontology	data, model, prompt, RAG, workflow, UX, communication, control, vendor, governance
Complaint-to-defect graph	complaint cluster to product defect, control update, eval update and CAPA
Evidence binder	source, timeline, AI trace, policy version, communications, remediation, approvals
Board MI	dashboard with AI-linked complaints, external source trend, RCA, CAPA aging, evidence completeness
Interview memo	one-page explanation of architecture decisions and risk boundaries

Evaluation bar:

You can explain why complaint intelligence is not generic CRM analytics.
You can show how AI summarization is controlled and audited.
You can connect customer harm to product defect and control update.
You can support regulatory response with facts while leaving applicability and wording to Legal/Compliance.
You can demonstrate model risk controls for classifier, summarizer, response drafter and trend analyzer.

24. Interview-Ready Language

30 秒版本:

我会把 AI 投诉体系设计成 complaint intelligence architecture, 而不是自动回复工具。它从原始投诉和证据保全开始, 用 AI 辅助分类、摘要、伤害识别和趋势聚类, 再把投诉连接到 AI trace、客户旅程、根因、产品缺陷、控制修复、CAPA、监管响应证据和董事会 MI。正式法规适用和回复口径由 Legal/Compliance 负责, 但产品和架构必须让事实链、修复链和证据链可重建。

2 分钟版本:

金融零售 AI 投诉的核心不是处理更多工单, 而是发现 customer harm 和系统性控制缺口。我会先建立 complaint event ledger: 保存原始叙述、来源、渠道、产品、journey step、AI touchpoint、证据引用、摘要版本、分类、伤害和处置。AI 可以做 triage、summarization、harm scoring 和 duplicate clustering, 但高风险场景必须人工复核, 并且摘要必须指回原始证据。第二层是 RCA 和 product defect graph。每个重大投诉要连接到 data、model、prompt、RAG、workflow、UX、communication、control、vendor 或 governance 根因, 然后产生 corrective action、preventive action、eval update、control update 和 post-fix monitoring。第三层是监管响应证据。外部投诉要能快速导出 source record、customer timeline、AI trace、policy version、communication record、remediation 和 CAPA evidence。这样团队不会在监管问询后临时拼材料, 而是在日常运营中持续生成可审计证据。

Senior follow-up answer:

我会特别防止两个误区。第一, 不能让 AI summary 成为事实源; 原始投诉才是 evidence, summary 只是可版本化、可质疑、可复核的派生产物。第二, 不能把所有投诉都归因于一线员工或客户误解; 投诉必须能回到产品设计、知识库、模型、流程、控制和治理。只有这样, AI complaint capability 才能从成本中心变成产品风险和客户信任的控制平面。