AI Customer-Facing Regulated Product Playbook

核心导读：客户可见受监管 AI 不是“更聪明的聊天机器人”，而是一套带披露、边界、人工升级、客户救济、持续监控和审计证据的服务系统。

学习主线：从客户旅程出发，识别 AI 何时影响客户权益、销售理解、投诉路径、信贷解释、财富建议和人工可达性，再把这些风险转成产品策略、流程控制、架构组件和证据记录。

系统边界：本文覆盖 customer-facing AI、AI-assisted customer communication、contact center automation、wealth/credit/service assistant 和可进入客户记录的内部辅助输出；纯后台开发效率、一般数据分析和不影响客户沟通或权益的内部工具不作为重点。

证据输出：最终应能形成 use case intake、regulated intent taxonomy、disclosure matrix、handoff rules、complaint routing、adverse action reason control、reference architecture、monitoring dashboard、incident runbook 和 audit evidence pack。

重要说明：本文是系统学习和内部治理训练材料，不构成法律意见、合规结论、审计意见、模型验证报告或监管解释。正式项目必须由 Legal、Compliance、Risk、Model Risk、Fair Lending、Privacy、Security、Accessibility、Business Owner 和管理层结合机构类型、司法辖区、产品类型、客户群体和内部政策确认。本文按 2026-06-29 访问到的公开官方材料建立学习锚点；涉及 EU AI Act 的适用日期、美国联邦与州法、证券/投资顾问规则、银行监管要求和机构政策时，必须以正式法律审查为准。

---

Source Anchors

以下来源是本文的监管与治理锚点。本文把它们转成产品、流程、架构、运营和证据要求，不把任何来源简化成单一检查项。

---

1. 核心导读：客户可见 AI 是受监管服务系统

客户可见受监管 AI 的核心不是“模型回答得像人”，而是：

Customer-facing regulated AI =
在客户知道自己正与 AI 或 AI 辅助服务互动的前提下，
在明确的产品、建议、销售、信贷、投诉和人工升级边界内，
用可验证知识、合规话术、权限控制、人类监督和生产监控，
向客户提供有用但不过界的服务，
并能在出错时解释、补救、复盘和证明控制真实运行。

系统边界判断：

---

2. Internal Copilot vs Customer-Facing AI

很多团队把内部 copilot 的治理方式直接搬到客户 chatbot，这是危险的。客户可见 AI 的风险不是“员工会不会采纳 AI”，而是客户可能被 AI 直接影响、误导、阻断、销售、拒绝、劝服或带入受监管流程。

2.1 设计原则差异

---

3. 风险分层：先按客户影响，而不是按模型先进程度

客户可见 AI 的风险等级应由“客户会受到什么影响”决定，而不是由“是不是生成式 AI”决定。

3.1 进入高风险的触发条件

---

4. Customer Journey：把风险放回客户旅程

客户可见 AI 不能只设计一个聊天窗口。它应覆盖从入口到事后复盘的完整旅程。

Discovery
-> AI disclosure
-> Identity and consent
-> Intent detection
-> Boundary classification
-> Knowledge / API / policy response
-> Suitability / sales / adverse-action checks
-> Human escalation when needed
-> Case creation and customer confirmation
-> Monitoring, QA, complaint and incident loop

---

5. Disclosure / Transparency：披露不是页脚小字

EU AI Act Article 50 给出的通用启发是：直接与自然人互动的 AI 系统应让相关人员知道其正在与 AI 系统互动；信息应清晰、可区分，并符合适用的无障碍要求。即使某个美国银行场景不直接适用 EU AI Act，这也是客户可见 AI 的优秀设计基线。

5.1 披露时点

5.2 披露内容的四层

5.3 披露文案反例

---

6. Suitability / Advice Boundary：教育、推荐、建议和交易必须分层

财富、投资、保险和复杂金融产品是客户可见 AI 最容易越界的场景。核心设计不是让 AI 永远拒答，而是把话题分成可允许的教育信息、需披露的产品比较、需适当性控制的个性化推荐、以及必须由授权流程完成的交易。

6.1 Advice boundary 决策树

客户是否要求解释概念？
  是 -> 使用教育模板和来源引用。
  否 -> 客户是否要求比较具体产品？
    是 -> 只提供公开属性、费用、风险和适用条件；避免“最适合你”。
    否 -> 客户是否提供个人资金、期限、目标、风险偏好或账户信息并要求建议？
      是 -> 进入适当性/持牌顾问/人工流程。
      否 -> 客户是否要求执行交易？
        是 -> 跳转正式交易和确认流程，不让生成式文本直接替代交易指令。
        否 -> 回到意图澄清。

6.2 适当性控制矩阵

---

7. Adverse Action / Fair Lending：AI 不能让理由变模糊

信贷 AI 的关键不是“给客户一个听起来合理的解释”，而是 formal adverse action notice 和客户聊天解释必须都能回到真实决策因素。CFPB 的两个 adverse action 锚点给出清晰方向：复杂模型、AI 或黑盒不能成为不能提供具体准确理由的借口；样表 checklist 不能替代实际主要原因。

7.1 哪些场景需要特别警惕

7.2 Adverse action reason pipeline

Credit decision model / rules
-> decision factors captured at decision time
-> reason ranking and policy mapping
-> compliance-approved reason code dictionary
-> notice generation system
-> customer communication record
-> chatbot explanation limited to the approved notice and glossary
-> dispute / reconsideration / complaint route

7.3 Fair lending monitoring

7.4 客户问答边界示例

---

8. Complaints：不能让 AI 把投诉当闲聊

投诉不是情绪标签，而是受监管流程入口。客户可见 AI 必须识别、记录、路由、确认和监控投诉，尤其不能让 chatbot 用循环回答阻断客户表达不满或寻求救济。

8.1 Complaint trigger taxonomy

8.2 Complaint handling control

---

9. Accessibility：无障碍不是 UI 尾项

客户可见 AI 如果替代传统客服入口，就必须服务不能顺利使用标准聊天界面的人。无障碍设计要覆盖视觉、听觉、运动、认知、语言、设备和金融素养差异。

9.1 无障碍验收样例

---

10. Human Escalation：人工升级是产品能力，不是失败兜底

CFPB chatbot report 的核心警示之一是：有缺陷的 chatbot 如果阻止客户获得实时人工支持，可能造成法律、服务和客户伤害风险。客户可见 AI 的人工升级必须是可设计、可测量、可证明的能力。

10.1 强制升级场景

10.2 Warm handoff 最低标准

---

11. Sales Compliance：AI 不能把销售话术变成“个性化魔术”

客户可见 AI 很容易在服务中自然转向销售：客户问费用、额度、收益、保障，AI 可能顺手推荐产品。销售合规的重点是：真实、清晰、有依据、不过度承诺、不隐藏风险、不利用客户脆弱性、不把 AI 能力包装成专业保证。

11.1 FTC AI claims 到金融 AI 销售

11.2 销售边界控制

11.3 禁止话术

---

12. Hallucination Prevention：受监管场景要先控制可回答性

金融客户服务中，hallucination 不是简单的“答错了”。它可能变成错误费率、错误权利、错误期限、错误资格、错误承诺、错误投诉处理或错误投资建议。

12.1 Answerability-first pattern

Classify intent
-> Check regulated boundary
-> Check identity and permissions
-> Retrieve approved source or call authoritative API
-> Validate source freshness and jurisdiction
-> Generate only within approved answer type
-> Run compliance and hallucination checks
-> Escalate if unsupported, stale, conflicting or high impact

12.2 不同答案类型的控制

---

13. Reference Architecture：把合规边界做进系统

客户可见 AI 的架构不能只是 channel -> LLM -> response。它需要策略引擎、来源治理、工具网关、监控和证据层。

Digital / Voice / Branch Channel
  -> AI disclosure and consent component
  -> Identity, auth and customer context
  -> Intent and risk boundary classifier
  -> Policy / compliance decision engine
  -> Orchestrator
      -> Approved knowledge retrieval
      -> Authoritative product / account APIs
      -> Claims library
      -> Suitability / eligibility / fair lending services
      -> Tool gateway with approval rules
  -> Response composer with templates and guardrails
  -> Human escalation and case management
  -> Trace, monitoring, QA, complaint and incident evidence store

13.1 架构组件职责

13.2 数据最小化与隐私

---

14. Monitoring：客户可见 AI 的仪表盘要看客户伤害

生产监控不能只看 latency、token cost 和 CSAT。受监管 AI 需要监控回答质量、合规边界、客户服务可得性、群体差异、投诉、销售话术和事故信号。

14.1 QA 抽样策略

---

15. Incident Response：AI 事故要能定位客户、输出和控制失效

客户可见 AI 事故不是“模型答错几句”这么简单。金融机构需要判断客户是否受损、是否需要通知、补救、监管沟通、模型回滚、知识库修复、销售纠偏或公平信贷 review。

15.1 事故分级

15.2 事故响应流程

Detect
-> Triage severity and affected scope
-> Contain model / intent / tool / channel
-> Preserve evidence
-> Identify customers and conversations
-> Assess legal, compliance, financial and operational impact
-> Remediate customers and system
-> Run regression and red-team tests
-> Approve restart
-> Post-incident review and control update

15.3 事故证据包

---

16. Trust Calibration：既不能伪装全能，也不能让客户失去信任

信任校准的目标是让客户准确理解 AI 能力：知道什么时候可以自助，什么时候需要人工，什么时候必须依赖正式文件或专业顾问。

16.1 客户信任校准文案

---

17. UI Content Rules：客户可见内容必须按风险类型写

17.1 通用内容规则

17.2 场景话术规则

---

18. Red-Team Cases：上线前要测真实客户伤害路径

红队不只是 jailbreak。客户可见金融 AI 的红队要覆盖误导销售、投诉阻断、信贷解释、适当性越界、无障碍失败和人工升级失败。

---

19. 金融零售场景样例

19.1 信用卡客服 AI

19.2 Mortgage / Personal Loan AI

19.3 财富管理 AI

19.4 Contact Center AI Voicebot

---

20. Operating Model：把客户保护责任落到控制域

客户可见 AI 的责任不应按“谁写需求、谁做架构、谁审批文案”割裂。更稳健的 operating model 是把客户影响、流程规则、系统控制、合规审查、运行监控和事故处置分别落到控制域，并让每个控制域都有可审计输出。

20.1 Governance Accountability Matrix

R = Responsible，A = Accountable，C = Consulted。

20.2 Control Evidence By Domain

---

21. Templates：用“信用卡客服 AI 助手”做完整样例

以下模板均给出完整样例。正式项目复制时应替换为真实业务值，并保留审批、版本和证据。

21.1 Use Case Intake

21.2 Regulated Conversation Boundary Card

21.3 Disclosure Copy Sheet

21.4 Adverse Action Reason Control

21.5 Complaint Routing Rule

21.6 Monitoring Dashboard Spec

21.7 Incident Report

---

22. 30-Day System Learning Lab：从场景到证据包

目标：30 天内完成一个可复盘的“客户可见受监管 AI 系统证据包”，以信用卡客服、财富服务或贷款预审任选一个场景为主线。重点不是包装成果，而是证明每个关键设计判断都有边界、控制、证据和复盘路径。

30 天 System Evidence 清单

---

23. Decision Narrative：关键设计判断

这一节不再按碎片问题背诵，而是把常见争议压缩成可复用的系统判断。每个 narrative 都应回答三件事：核心原则是什么，系统如何实现，留下什么证据。

23.1 Internal Copilot 与 Customer-Facing AI 的边界

核心判断：internal copilot 的主要风险是员工如何采纳 AI；customer-facing AI 的风险是客户直接被 AI 告知、影响、销售、拒绝、升级或阻断。因此客户可见 AI 需要额外设计披露、人工可达性、投诉、销售合规、适当性、adverse action、无障碍和客户补救。

系统展开：边界判断应从客户影响而不是模型类型切入。内部 copilot 可以依赖员工培训、复核和内部政策，但客户可见 AI 必须在首次互动披露 AI 身份，明确能力边界，防止把 FAQ 变成建议或销售，把投诉变成普通情绪，把信贷解释变成编造原因。架构上需要 intent classifier、policy engine、RAG 来源治理、tool gateway、human handoff、monitoring 和 incident response。成功标准不是 containment 越高越好，而是客户能获得准确服务、人工支持和合规救济。

证据输出：interaction type classification、AI disclosure log、intent/risk label、handoff event、source trace、customer-visible output、complaint linkage。

23.2 Disclosure 与 Transparency 的设计原则

核心判断：披露要在首次互动和关键边界出现，清晰说明客户正在和 AI 互动、AI 能做什么、不能做什么、如何找人工，并符合无障碍要求。

系统展开：披露按身份、能力、限制和升级四层设计。入口处说明这是 AI 助手；涉及账户信息时说明需要认证；涉及信贷、投资、投诉时说明正式流程和人工入口。EU AI Act Article 50 给了设计基线：直接与自然人交互的 AI 应让对方知道自己在和 AI 互动，且信息清晰、可区分、可访问。披露不是免责声明，它要和流程、权限、监控、人工升级一起运行。

证据输出：disclosure version、placement、channel rendering record、accessibility check、consent/preference event、handoff availability proof。

23.3 Adverse Action Reason 的解释边界

核心判断：AI 可以解释正式通知中的已批准原因，但不能现场编造原因，也不能用黑盒模型无法解释作为借口。

系统展开：CFPB 的 adverse action guidance 明确：复杂算法、AI 或黑盒不免除提供具体准确主要原因的义务。系统设计应把 decision factors、reason ranking、approved reason dictionary、notice generation 和 chatbot explanation 串成 reason pipeline。Chatbot 只能解释正式通知中的 reason code 和下一步，例如复核、补资料或纠错；不能说“模型觉得你风险高”这种 vague reason，也不能用样表里最接近的原因替代真实原因。

证据输出：decision system version、principal reason codes、notice template/version、chatbot explanation template、reason mismatch QA、fair lending slice monitoring。

23.4 Human Escalation 是产品能力

核心判断：人工升级不是失败兜底，而是客户可见 AI 的核心服务能力。客户要求人工、投诉、欺诈、困难援助、信贷、财富和连续失败都要强制升级，并监控转接成功率。

系统展开：CFPB chatbot report 提醒金融机构，低质量 chatbot 如果阻断 live human support，会带来服务和合规风险。设计上要有 mandatory handoff rules、warm handoff summary、queue SLA、case ID 和 AI pause。指标上不能只看 containment，还要看 escalation success、repeat contact、complaint rate、无障碍模式成功率和高风险队列等待时间。

证据输出：handoff trigger reason、queue target、transcript summary、customer confirmation、SLA timestamp、abandon/retry metrics。

23.5 Wealth AI 的 Suitability / Advice Boundary

核心判断：财富 AI 必须把教育、产品信息、个性化推荐和交易执行分层；未完成适当性评估前，不应推荐具体产品或包装成“适合你”的建议。

系统展开：客户问“债券基金是什么”可以教育；问“你们有哪些产品”可以展示公开属性；问“我 5 万美元该买什么”就进入个性化建议边界。此时要检查客户画像是否有效、产品风险等级、目标市场、披露和顾问资质。交易执行要进入正式交易界面和确认，不让生成式聊天直接下单。

证据输出：intent boundary label、customer profile freshness、product risk tags、suitability gate result、disclosure record、licensed channel handoff。

23.6 Hallucination Prevention 的系统模式

核心判断：受监管场景要先判断可回答性，再回答；数字、日期、费率来自权威 API，高风险内容用模板，来源过期或冲突就拒答或升级。

系统展开：answerability-first architecture 的顺序是 intent -> boundary -> identity -> approved source/API -> freshness -> template -> compliance check -> escalation。RAG 只能检索批准知识库，费率和账户事实必须来自系统 API，adverse action 和投诉用结构化流程。上线前要用受监管问答集做 regression eval，上线后监控 groundedness、source freshness、API mismatch 和 high-risk QA failure。

证据输出：answerability decision、retrieval source IDs、freshness check、tool/API result hash、template ID、blocked/escaped unsupported answer metrics。

23.7 Complaint Handling 的闭环

核心判断：投诉触发词和重复失败必须创建 case 或转投诉队列，客户要拿到确认和下一步，不能让 AI 反复安抚或继续销售。

系统展开：complaint trigger taxonomy 应覆盖“我要投诉”“乱收费”“不公平”“监管”“歧视”“找主管”等表达。AI 一旦命中，就停止销售和争辩，创建 case、给编号、说明下一步、转人工或回访。运营上监控 complaint capture、repeat contact、theme spike 和投诉未建单样本，把投诉信号接入产品和模型改进。

证据输出：trigger phrase、complaint classifier result、case ID、sales suppression flag、handoff queue、root cause category、remediation status。

23.8 Monitoring Dashboard 的客户伤害视角

核心判断：客户可见 AI 的 dashboard 除了技术指标，还要看客户伤害指标：投诉、人工转接、合规边界、销售话术、adverse action reason、fair lending、无障碍和事件。

系统展开：监控可分为 groundedness、regulated intent、human escalation、adverse action、fair lending、suitability、sales compliance、complaints、accessibility、security/operations。比如 containment 提升但投诉和转人工失败同时上升，说明 AI 可能在阻断服务。模型、prompt、policy 和知识库变更都要做 pre/post regression 和高风险抽样。

证据输出：metric definition、slice logic、alert threshold、owner、action runbook、release comparison、incident linkage。

23.9 Cross-Functional Governance 的组织方式

核心判断：客户可见 AI 的治理应按控制域组织：产品边界、流程规则、系统架构、法律合规、模型风险、公平性、运营队列、安全隐私分别承担可审计证据，而不是停留在角色话术。

系统展开：Product Governance 负责 use case intake、风险分层、指标和上线门禁；Process & Requirements 负责 AS-IS/TO-BE、intent taxonomy、handoff rules、complaint fields 和操作流程；Architecture 负责 reference architecture、data flow、RAG governance、tool gateway、auth、logging、kill switch。Legal 和 Compliance 审披露、销售、投诉、advice、adverse action；Model Risk 和 Fair Lending 做验证和群体影响；Ops 负责人工队列和培训。

证据输出：accountability matrix、release sign-off、control owner list、policy exception log、residual risk memo、operating readiness review。

23.10 Cost Reduction 的价值边界

核心判断：AI 可以降低低风险服务成本，但不能以降低成本为目标牺牲客户支持、投诉入口和高风险人工升级。

系统展开：目标应改成“提高低风险自助解决率，同时保护高风险客户路径”。指标不能只看 containment 和 AHT，还要看投诉、repeat contact、人工转接成功率、无障碍成功率、错误补救成本和监管风险。CFPB chatbot report 对“用 chatbot 替代 live support”的风险有明确警示，所以成本收益模型必须扣除客户伤害和合规成本。

证据输出：risk-adjusted value model、containment by risk tier、repeat contact delta、complaint-adjusted savings、handoff success and remediation cost。

23.11 Incident Response 的证据链

核心判断：AI incident response 要先分级，再 containment，保留 trace，识别受影响客户，评估补救，修复后回归测试并审批重启。

系统展开：错误费率、错误拒贷原因、投诉未建单、数据泄露都可能是高风险。流程是 detect、triage、contain、preserve evidence、scope customers、assess impact、remediate、regression、approve restart、post-incident review。证据包要包括时间线、trace、客户影响、控制失效、补救、审批和残余风险。

证据输出：incident severity、affected customer scope、control failure analysis、containment action、customer remediation record、regression results、restart approval。

23.12 NIST AI RMF 的产品化使用

核心判断：NIST AI RMF 的价值在于用 Govern / Map / Measure / Manage 把客户可见 AI 从功能变成治理闭环。

系统展开：Govern 定义 owner、accountability matrix、政策和 release gate；Map 识别客户旅程、伤害路径、受监管 intent 和人群；Measure 做 eval、QA、fairness、accessibility、sales compliance 和 incident metrics；Manage 做人工升级、停机、修复、客户补救和持续改进。NIST 的 trustworthy AI 特征也能转成产品验收：可靠、安全、韧性、透明、可解释、隐私和公平。

证据输出：AI RMF mapping、control inventory、measurement plan、risk treatment log、management review record。

23.13 Design Review Questions

---

24. 上线前自检清单

核心记忆：

客户可见 AI 不是“更自然的客服界面”，
而是一个带披露、边界、证据、人工、监控和补救能力的受监管服务系统。