AI 扩展计划 / Playbooks
AI Trust Experience / Product Governance Playbook
以下官方或 primary sources 作为本文的设计锚点。本文把它们转成产品、体验、架构、治理和证据要求, 不把任何来源简化成单一检查项。访问日期按 2026-06-29 记录。
961 行AI_TRUST_EXPERIENCE_PRODUCT_GOVERNANCE_PLAYBOOK.md
AI Trust Experience / Product Governance Playbook
适用对象: AI PM、Product Architect、UX Lead、AI Governance、Model Risk、Compliance Product、Digital Banking / Wealth / Credit / AML 产品负责人。 核心问题: 如何把 AI 信任体验从“免责声明 + 好看的聊天界面”升级为可披露、可校准、可控制、可升级、可申诉、可审计、可持续治理的产品架构。 学习目标: 训练高级 AI 产品体验与治理判断力: 何时透明、如何解释、何时拒答、何时升级、如何防止过度依赖、如何设计受监管对话边界、如何保护脆弱客户、如何把客户信任转成可运行的产品控制和 evidence pack。 重要说明: 本文是学习、作品集和内部治理训练材料, 不是法律意见、合规结论、审计意见、模型验证报告或监管解释。正式项目必须由 Legal、Compliance、Risk、Model Risk、Privacy、Security、Accessibility、Business Owner、Operations Owner 和管理层结合机构类型、司法辖区、产品范围、客户群体和内部政策确认。
Source Anchors
以下官方或 primary sources 作为本文的设计锚点。本文把它们转成产品、体验、架构、治理和证据要求, 不把任何来源简化成单一检查项。访问日期按 2026-06-29 记录。
| Anchor | Official / primary source | 在本 playbook 中的用法 |
|---|---|---|
| Microsoft Guidelines for Human-AI Interaction | https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/ | 用 human-AI interaction 的阶段性原则组织 expectation setting、contextual help、uncertainty、feedback、correction、dismissal、control、learning 和 recovery。 |
| NIST AI RMF 1.0 | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 把 trust experience 纳入 AI 风险治理、度量、上线门禁和持续监控。 |
| NIST AI RMF Generative AI Profile | https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence | 用于 GenAI 特有风险: hallucination、information integrity、over-reliance、misuse、content provenance、third-party dependency、incident response。 |
| ISO 9241-210 Human-centred design | https://www.iso.org/standard/77520.html | 用 human-centred design lifecycle 约束 AI 产品体验: 用户、任务、环境、可用性目标、迭代评估和全生命周期管理。 |
| Google People + AI Guidebook | https://pair.withgoogle.com/guidebook/ | 用于 trust calibration、mental model、explainability、feedback and control、errors and graceful failure 的产品设计语言。 |
Standards-to-artifacts:
| Source lens | 可以产出的 artifact | 面试表达 |
|---|---|---|
| Human-AI Interaction Guidelines | AI interaction policy、conversation state machine、error and handoff pattern library | “我不会只写聊天文案, 我会按交互阶段定义用户预期、控制权、失败恢复和长期学习。” |
| NIST AI RMF | Trust risk tier、control pack、release gate、monitoring dashboard | “我把信任体验纳入 AI risk lifecycle, 用治理、场景、度量和处置闭环管理。” |
| NIST GenAI Profile | GenAI trust risk checklist、over-reliance control、content provenance spec、incident taxonomy | “我把生成式 AI 的幻觉、来源、滥用和过度依赖当成产品风险, 而不是单纯模型问题。” |
| ISO 9241-210 | User context study、trust usability evaluation、accessibility review、iterative validation plan | “我用人本设计生命周期验证真实用户、任务和环境, 而不是靠团队主观体验判断。” |
| Google PAIR Guidebook | Trust calibration canvas、feedback and control design、graceful failure journey | “我会让用户既不过度信任 AI, 也不会因为黑箱而完全不敢用。” |
1. 高级定位: Trust Is Product Architecture
AI trust 不是品牌语气、免责声明、模型准确率或 UI 上的“可信”标签。它是一个产品架构问题:
AI Trust Experience =
用户知道 AI 在哪里参与,
理解 AI 能力和边界,
能看到足够证据和不确定性,
能控制、拒绝、纠错、升级和申诉,
在受监管边界内获得一致体验,
并且组织能证明这些控制真实运行。
信任体验的核心不是让用户“相信 AI”, 而是让用户形成 calibrated trust:
- 该信任时敢用。
- 不该信任时能识别。
- 高风险时能转人、暂停或要求证据。
- 出错后能获得救济、复盘和改进。
1.1 Trust Debt
AI 产品会积累 trust debt。它不像技术债只影响维护成本, 而是直接影响客户权益、员工判断、监管证据和品牌声誉。
| Trust debt | 表现 | 长期后果 |
|---|---|---|
| 黑箱债 | 用户不知道 AI 用了什么信息、为什么这样回答 | 投诉时无法解释, 审计时无法复现 |
| 过度承诺债 | 产品文案暗示 AI 全能、实时、个性化、无错误 | 错误输出被理解为机构承诺 |
| 边界债 | 客服、信贷、财富、投诉、AML 边界混在一个聊天体验里 | AI 误入受监管建议、正式通知或合规结论 |
| 控制债 | 用户没有暂停、人工、纠错、申诉和退出路径 | 自助化变成服务阻断 |
| 证据债 | 只有 transcript, 没有 source、version、policy、approval、handoff 记录 | 事故和监管问询无法还原 |
| 反馈债 | thumbs up/down 没有进入 eval、知识和政策更新 | 同类错误反复发生 |
1.2 信任不是越多越好
| 错误目标 | 为什么危险 | 正确目标 |
|---|---|---|
| 提高用户对 AI 的信任 | 可能鼓励 automation bias 和盲目采纳 | 校准信任, 让信任与证据、风险和能力相匹配 |
| 让 AI 看起来像真人 | 可能造成身份误导和责任混乱 | 明确 AI / human / AI-assisted human 的身份 |
| 用免责声明覆盖所有风险 | 免责声明不能替代控制和救济 | 用产品边界、证据、升级和审核降低风险 |
| 把解释做成越详细越好 | 信息过载会降低可用性和理解 | 按风险提供分层解释和可展开证据 |
| 所有不确定都显示百分比 | 数字置信度可能制造虚假精确感 | 用任务相关的 evidence strength、source freshness、missing info 信号 |
1.3 角色分工
| Role | 信任体验责任 | 关键产出 |
|---|---|---|
| AI PM | 定义 trust promise、风险边界、客户权益、release gate 和 success metric | Trust Experience PRD、risk-tiered roadmap、release memo |
| Product Architect | 把信任要求映射到系统边界、policy engine、audit、handoff、control architecture | Trust architecture map、ADR、control matrix |
| UX Lead | 设计披露、解释、不确定性、拒答、控制、申诉和脆弱客户体验 | Interaction spec、evidence UI、error and handoff patterns |
| AI Governance | 建立 use case tier、policy、monitoring、incident、evidence 和管理层报告 | AI governance pack、control evidence、risk review |
| Compliance / Legal | 确认受监管边界、客户沟通、销售、信贷、投诉、记录保留和监管义务 | Product policy sign-off、communication review |
| Operations Owner | 负责人工升级、SLA、投诉、复核、培训和反馈闭环 | Handoff runbook、QA plan、complaint workflow |
| EvalOps / Model Risk | 验证输出质量、解释质量、拒答质量、过度依赖和 drift | Eval set、calibration report、monitoring dashboard |
2. Advanced Framework: TEX-Gov
TEX-Gov = Trust Experience Governance。它把 AI 信任体验拆成八层决策, 每层都有产品问题、架构控制和证据要求。
TEX-Gov stack
Trust intent
-> decision boundary
-> disclosure and consent
-> evidence and explanation
-> uncertainty and refusal
-> user control and handoff
-> feedback, complaint and appeal
-> governance, monitoring and audit
| Layer | 目标 | 决策问题 | 必备 artifact | Stop signal |
|---|---|---|---|---|
| L1 Trust intent | 定义产品要获得哪种信任 | 用户应信任 AI 做什么, 不应信任它做什么 | Trust promise statement | “让用户相信我们”这种空泛目标 |
| L2 Decision boundary | 划清 AI、人、规则和正式系统的责任 | AI 是解释、总结、建议、草拟、执行还是决定 | Decision boundary map | AI 输出可能被当成正式决策但无控制 |
| L3 Disclosure and consent | 让用户知道 AI 参与和数据用途 | 何时披露、披露什么、何时需要 consent 或 opt-out | Disclosure matrix、consent register | 披露藏在页脚或一次性勾选 |
| L4 Evidence and explanation | 展示来源、理由和可验证依据 | 哪些证据足够, 哪些解释必须可追溯 | Evidence display spec、reason code map | 解释由模型临场编造 |
| L5 Uncertainty and refusal | 管理不确定、未知和禁止场景 | 何时回答、澄清、拒答、降级或转人 | Refusal policy、uncertainty taxonomy | AI 为了完成任务而猜测 |
| L6 User control and handoff | 让用户能控制 AI 和获得人工支持 | 用户能暂停、编辑、撤回、转人、选择非 AI 路径吗 | Control inventory、handoff runbook | “人工入口”不可达或无 SLA |
| L7 Complaint and appeal | 出错后提供救济和复盘 | 客户如何投诉、申诉、纠正记录、获得 case ID | Complaint / appeal UX map | AI 循环答复投诉, 不建单 |
| L8 Governance and audit | 证明信任控制真实运行 | 谁监控、谁审批变更、谁处理事故 | Trust dashboard、audit event schema | 只有 UI, 没有日志、owner 和 release gate |
2.1 Trust Experience Decision Flow
User intent detected
-> identity / entitlement check
-> regulated boundary classification
-> data and consent check
-> source and evidence check
-> answer / clarify / refuse / escalate
-> user control offered
-> audit event written
-> feedback and complaint loop
-> eval, policy and knowledge update
2.2 Trust Risk Tiering
| Tier | 用户影响 | 金融零售例子 | 默认体验策略 |
|---|---|---|---|
| Tier 0: Public information | 公开、低风险、非个性化 | 网点时间、产品公开费率入口、普通 FAQ | 简洁 AI 披露、来源链接、基础反馈 |
| Tier 1: Personal service | 涉及账户、交易、费用、状态 | 账单解释、交易查询、费用说明、争议进度 | 强身份验证、系统事实优先、可转人工 |
| Tier 2: Regulated guidance | 涉及产品选择、资格、风险、权益 | 信用卡选择、贷款条件解释、投资教育、困难援助 | 建议边界、合规话术、来源和升级路径 |
| Tier 3: High-impact support | 影响信贷、财富、投诉、AML、账户限制 | 信贷 copilot、财富建议边界、投诉处理、AML narrative | 人工复核、完整 evidence、release gate、专项监控 |
| Tier 4: Automated action | AI 直接触发客户权益变化或正式动作 | 自动拒贷、自动调额、自动冻结账户、自动下单 | 默认禁止或强审批; 需要正式风险接受、可撤销、申诉和停机 |
3. Trust Calibration
Trust calibration 的目标是让用户信任程度与 AI 能力、证据质量、任务风险和可逆性匹配。它同时防止 under-trust 和 over-trust。
3.1 信任校准矩阵
| AI behavior | 用户容易误解 | 应展示的信号 | 不应展示 |
|---|---|---|---|
| Retrieve | 以为检索结果完整 | 来源、更新时间、覆盖范围、权限过滤说明 | “已找到全部相关资料” |
| Summarize | 以为摘要没有遗漏 | 摘要范围、缺失字段、关键原文引用、可展开证据 | 没有来源的流畅长段落 |
| Explain | 以为解释就是正式原因 | 解释类型、适用范围、正式文件优先级 | 模型生成的“可能原因”冒充正式 reason |
| Recommend | 以为建议适合自己 | 依据、排除项、替代方案、人工最终判断 | 默认选中 AI 推荐项 |
| Draft | 以为草稿可直接发送 | 审核状态、可编辑字段、合规锁定片段 | “一键发送”高风险客户沟通 |
| Act | 以为 AI 可自主处理 | 动作影响、确认步骤、撤销路径、审批人 | 隐形工具调用或批量自动批准 |
3.2 校准信号库
| Signal | 使用场景 | 产品写法 |
|---|---|---|
| Source strength | RAG / policy / account answer | “基于当前账户系统记录和 2026-05-01 生效的费用政策。” |
| Freshness | 费率、政策、产品条款 | “资料更新时间: 2026-06-20。若近期收到新通知, 以正式通知为准。” |
| Missing information | 信贷、财富、投诉 | “还缺少收入证明和最近一期账单, 因此不能判断资格。” |
| Scope boundary | 投资、税务、法律、信贷 | “我可以解释一般规则, 不能在聊天中提供正式审批或个性化投资建议。” |
| Uncertainty category | 模型推断、来源冲突、数据缺失 | “资料来源存在冲突, 我会转给人工团队确认。” |
| Human review state | Copilot / draft / high-risk action | “AI 草稿, 未经审核。需要 underwriter 确认后才能进入客户沟通。” |
| Action impact | Tool use / workflow | “确认后将创建争议交易 case, 不会立即退回资金。” |
3.3 不要滥用置信度百分比
在金融零售体验里, “87% confident”通常不是好解释。它可能让用户以为系统有精确概率, 但概率并不一定对应客户理解的正确性、法律适用性或风险。
更实用的表达:
| 弱表达 | 更好的表达 |
|---|---|
| “我有 92% 把握。” | “这个回答有当前政策来源支持, 但不包含你最近一次人工审批结果。” |
| “低置信度。” | “账户系统没有返回足够信息, 需要人工查询。” |
| “可能适合你。” | “我只能展示一般产品条件; 个性化推荐需要完成风险承受能力和适当性流程。” |
| “模型认为原因是收入不足。” | “正式拒绝原因必须来自信贷决策系统或 adverse action reason pipeline。” |
4. Human-AI Interaction Guidelines: 产品化映射
Human-AI interaction 不是一组 UI 文案, 而是一组 lifecycle requirements。下面把常见原则转成产品需求语言。
| Interaction phase | 产品要求 | 金融零售实现 |
|---|---|---|
| 初次接触 | 建立正确 mental model: AI 是什么、能做什么、不能做什么 | 首屏披露 AI 身份、任务范围、人工入口和敏感场景边界 |
| 正常使用 | 提供上下文相关帮助, 不打断主任务 | 对账单解释显示对应交易、费用政策和下一步动作 |
| 系统不确定 | 及时表达不确定和缺失信息 | 来源冲突、身份未验证、政策过期时澄清或转人 |
| 用户纠正 | 允许用户纠错并让系统承认修正 | 客户指出交易不属于本人时, 进入争议流程而不是继续 FAQ |
| 用户控制 | 让用户能撤销、编辑、停用、选择人工 | 高影响动作前二次确认; 个性化可关闭; transcript 可导出 |
| 错误恢复 | 给出可执行下一步 | “我无法确认该费用, 已创建 case #123, 预计 2 个工作日回复。” |
| 长期使用 | 从反馈中改进, 但不隐性改变用户权益 | 反馈进入 eval 和知识更新; 不用投诉反馈自动训练个性化销售模型 |
| 组织治理 | 记录变更、评估和运行证据 | prompt、policy、source、model、tool、handoff、complaint 都可审计 |
4.1 交互状态机
Start
-> disclose AI identity
-> classify user intent
-> check identity / entitlement / consent
-> check regulated boundary
-> gather evidence
-> respond / clarify / refuse / escalate
-> offer control
-> record outcome
-> feedback / complaint / appeal
| State | 必须记录 | 失败处理 |
|---|---|---|
| Disclosure shown | disclosure version、channel、locale、timestamp | 没有披露时不得进入高风险对话 |
| Intent classified | intent、risk tier、classifier version、confidence category | 高风险低把握时人工路由 |
| Consent checked | consent type、purpose、status、expiry | 没有必要 consent 时降级到非个性化 |
| Evidence gathered | source IDs、effective date、retrieval query、tool result | 来源不足时拒答或升级 |
| Response generated | model、prompt、policy version、answer type | 输出违反 policy 时阻断 |
| Handoff triggered | reason、queue、SLA、context summary | 转接失败时创建 case 并确认给用户 |
| Complaint captured | complaint category、case ID、owner | 不允许继续用 AI 循环答复正式投诉 |
5. Transparency, Disclosure and Consent
透明不是把所有技术细节展示给用户, 而是让用户在关键时点知道足以做出合理选择的信息。
5.1 AI disclosure 四层
| Layer | 用户需要知道 | 设计要求 |
|---|---|---|
| Identity | 这是 AI、AI-assisted human 还是 human | 不用拟人化命名、头像或延迟效果误导用户 |
| Role | AI 在流程里做什么 | 区分回答 FAQ、总结资料、草拟回复、推荐下一步、执行动作 |
| Boundary | AI 不能做什么 | 信贷正式原因、投资建议、投诉裁决、法律税务意见、AML 通知边界明确 |
| Recourse | 出错或不满意怎么办 | 人工、投诉、申诉、纠错、记录更正和 case ID 可达 |
5.2 披露时点矩阵
| 时点 | 披露内容 | UI 设计 |
|---|---|---|
| 首次进入 AI 体验 | AI 身份、任务范围、人工入口 | 对话顶部常驻简短标识, 不是只弹一次 |
| 进入账户问题 | 身份验证和数据使用范围 | “查询个人账户信息前需要验证身份。” |
| 进入个性化 | 使用哪些数据做个性化 | 展示 purpose、data categories、关闭路径 |
| 进入受监管边界 | 建议、正式通知、投诉、信贷、财富边界 | inline boundary notice, 不用长篇免责 |
| 进入工具动作 | 动作影响、确认、撤销 | action review sheet |
| 人工接管 | AI 是否退出、上下文是否转给人工 | “已转人工, AI 不再生成后续回复。” |
5.3 Consent 不是万能豁免
| Consent type | 适用场景 | 不允许用来做什么 |
|---|---|---|
| Data processing consent | 使用客户数据生成个性化服务 | 规避必要的数据最小化、权限和保留要求 |
| Personalization opt-in | 根据偏好排序内容或提示 | 偷偷把服务问题转成销售推荐 |
| Proactive outreach consent | 主动提醒、营销、健康度提示 | 掩盖诱导性销售或高压话术 |
| Recording / transcript consent | 记录对话用于服务和质检 | 把投诉数据无限期用于模型训练 |
| Human handoff consent | 把对话摘要转给人工 | 隐藏敏感信息共享范围 |
Consent 设计规则:
- consent 必须按 purpose 分开, 不用一个总开关覆盖所有数据用途。
- opt-out 后仍要提供合理的非 AI 或低个性化服务路径。
- 不把 consent 文案写成放弃投诉、申诉、人工服务或正式通知权利。
- consent 状态必须可审计: version、timestamp、channel、purpose、expiry、撤回记录。
6. Explanation and Evidence Display
解释不是让模型“解释自己为什么这么想”。在金融零售里, 有效解释必须回到真实来源、真实规则、真实决策系统和真实人工判断。
6.1 Evidence hierarchy
| Evidence level | 信任强度 | 例子 | 使用规则 |
|---|---|---|---|
| System of record | 最高 | 核心银行账户系统、贷款审批系统、case management | 事实状态优先来自这里 |
| Approved policy / product master | 高 | 费用政策、产品条款、credit policy、wealth product catalog | 必须有 owner、effective date、version |
| Regulated notice / official document | 高 | adverse action notice、客户合同、投诉回复函 | AI 只能解释, 不能替代或改写正式文件 |
| Reviewed knowledge base | 中 | FAQ、客服知识库、培训材料 | 需要 freshness 和 content owner |
| Model inference | 低到中 | 意图识别、摘要、分类、草稿 | 不得单独支撑高影响结论 |
| User-provided statement | 情境证据 | 客户描述、员工备注 | 需要标记为 self-reported, 不等于事实 |
6.2 Evidence display pattern
| 场景 | 用户需要看到 | 不必展示 |
|---|---|---|
| 客户问费用 | 费用金额、交易、政策链接、适用日期、下一步 | prompt、embedding、token details |
| 客户问信贷结果 | 正式通知来源、主要原因解释、申诉或补件路径 | 模型生成的猜测性 reason |
| 财富教育 | 产品类型、风险、费用、适用条件、是否个性化 | 复杂模型分数 |
| 员工 copilot | 引用、缺失资料、冲突证据、policy exception、AI 草稿状态 | 面向客户的简化话术 |
| AML copilot | 交易证据、实体关系、规则触发、历史 case、narrative source map | 客户可见解释或 tipping-off 风险信息 |
6.3 Explanation types
| Explanation type | 适用场景 | 设计要求 |
|---|---|---|
| Factual explanation | “这笔费用是什么?” | 来自系统记录和政策; 显示来源和时间 |
| Procedural explanation | “接下来怎么办?” | 展示流程、时限、case ID、人工责任 |
| Decision explanation | “为什么被拒?” | 来自正式 reason pipeline; 不由 LLM 编造 |
| Recommendation rationale | “为什么建议这一步?” | 显示输入因素、规则、替代方案、排除项 |
| Refusal explanation | “为什么不能回答?” | 说明边界和可行替代路径 |
| Escalation explanation | “为什么转人工?” | 说明风险、缺失信息或权限边界 |
6.4 Reason 不等于 Rationalization
| 弱设计 | 风险 | 高级设计 |
|---|---|---|
| LLM 根据客户资料生成“看似合理”的拒贷原因 | rationalization, fair lending 和 adverse action 风险 | 拒贷原因来自决策系统 reason code, LLM 只解释已批准 reason 的含义 |
| AI 总结 AML suspicious rationale 并建议提交 SAR | 可能让 AI 隐性做合规结论 | AI 生成 evidence map 和 narrative draft, SAR 决策由合格人员记录 |
| 财富助手解释“你适合高收益基金” | 未完成适当性和销售合规 | AI 解释产品风险和一般原则, 个性化建议进入正式流程 |
| 客服 AI 用“系统判断”回应投诉 | 阻断客户救济 | AI 创建投诉 case, 给出编号、SLA 和人工处理路径 |
7. Uncertainty, Refusal and Escalation
高质量 AI 产品不是永远回答, 而是知道什么时候不回答。
7.1 Uncertainty taxonomy
| Uncertainty type | 表现 | 产品动作 |
|---|---|---|
| Missing data | 缺少账户、申请、收入、交易、case 信息 | 澄清或引导补充, 不猜测 |
| Source conflict | 政策与系统、旧版与新版、渠道信息冲突 | 标记冲突, 转人工或 policy owner |
| Stale source | 费率、规则、产品条款过期 | 阻断回答或显示更新时间并升级 |
| Ambiguous intent | 客户问题可能是投诉、欺诈、销售或普通咨询 | 先澄清, 高风险倾向升级 |
| Unauthorized request | 未验证身份或越权数据请求 | 拒绝披露, 提供认证路径 |
| Regulated boundary | 信贷、财富、法律、税务、AML 等边界 | 解释边界, 转正式流程 |
| Safety concern | 脆弱客户、诈骗、胁迫、紧急风险 | 人工优先、风险团队路由 |
7.2 Refusal pattern
好的拒答包含四件事:
Boundary
-> reason
-> safe alternative
-> escalation / next step
| 场景 | 不好的拒答 | 好的拒答 |
|---|---|---|
| 财富建议 | “我不能提供投资建议。” | “我可以解释产品类型、费用和一般风险; 如果你需要基于个人目标的建议, 我会转到持牌顾问或正式适当性流程。” |
| 信贷结果 | “无法判断。” | “我不能在聊天中生成正式拒绝原因。若已有正式通知, 我可以解释通知中的主要原因; 若未收到, 我可以帮你查询状态或转人工。” |
| 投诉 | “请换个问题。” | “这听起来像正式投诉。我会创建投诉 case 并转人工处理, 你将收到编号和预计回复时间。” |
| AML 客户询问 | “系统检测到异常。” | “为保护账户安全, 某些风控细节无法在聊天中披露。我可以帮你联系账户安全团队并说明需要你提供的材料。” |
7.3 Escalation rules
| Trigger | 默认动作 | 必须携带的上下文 |
|---|---|---|
| 投诉、监管、法律威胁 | 创建 case 并人工处理 | 客户原话、产品、渠道、时间、AI 输出、情绪和诉求 |
| 脆弱客户信号 | 人工优先, 降低销售压力 | 信号类型、语言需求、无障碍需求、风险提示 |
| 来源冲突 | 转 policy owner 或 trained agent | 冲突来源、版本、有效日期 |
| 高影响动作 | 停止自动流程, 进入审批 | action payload、风险等级、用户确认、审批人 |
| 客户要求人工 | 直接转人工或预约回呼 | 已验证身份、问题摘要、已尝试步骤 |
| 重复失败 | 创建 case, 不继续循环 | 最近 N 轮对话、失败类型、客户反馈 |
7.4 Warm handoff
Warm handoff 不是把客户扔进另一个队列。它必须保证:
- 客户不用重复身份和问题。
- 人工能看到 AI 已确认的信息、来源和失败原因。
- AI 在人工接管后停止自动生成客户可见回答。
- 客户收到 case ID、SLA、渠道和后续动作。
- handoff failure 有兜底: 回呼、工单、邮件或安全消息中心。
8. Regulated Conversation Boundaries
受监管金融零售 AI 最重要的体验设计是边界管理。边界不是“不能说”的清单, 而是决定回答、澄清、拒答、升级和正式流程的策略系统。
8.1 Intent boundary matrix
| Intent | AI 可做 | AI 不可做 | 必需控制 |
|---|---|---|---|
| General banking FAQ | 解释公开规则、费用、营业时间 | 暗示个案承诺 | 来源和更新时间 |
| Account service | 查询状态、解释交易、创建服务请求 | 未认证披露账户信息 | 身份验证、权限、audit |
| Credit education | 解释评分因素、申请流程、补件要求 | 编造拒绝原因、承诺批准 | reason code boundary、正式通知优先 |
| Credit copilot | 草拟贷审 memo、列缺失资料、引用政策 | 自动审批、自动 adverse action | underwriter review、policy citations |
| Wealth education | 解释资产类别、风险、费用 | 未评估前推荐具体产品 | suitability boundary、licensed handoff |
| Sales / marketing | 展示公开产品信息、资格条件 | 夸大收益、隐瞒费用、个性化诱导 | approved scripts、disclosure |
| Complaint / dispute | 识别投诉、建单、说明流程 | 把投诉当 FAQ 化解、不建单 | case ID、SLA、人工 owner |
| Fraud / AML | 收集客户材料、账户安全升级 | 披露监控规则、提示规避 | security routing、tipping-off controls |
| Legal / tax | 提供一般教育和正式资源入口 | 作为法律或税务顾问 | refusal + referral |
| Vulnerable customer | 简化语言、人工优先、保护性确认 | 高压销售、复杂免责声明 | vulnerability routing、accessibility |
8.2 Conversation policy engine
User message
-> intent classifier
-> risk tier classifier
-> identity / entitlement check
-> consent and preference service
-> product / jurisdiction / role policy
-> source availability check
-> response policy:
answer | ask clarification | refuse | handoff | create case | route to formal workflow
Policy engine 不应只靠 prompt。高风险边界需要结构化规则、版本化政策、可审计决策和人工审批。
8.3 Boundary artifacts
| Artifact | 内容 |
|---|---|
| Regulated intent taxonomy | 意图、风险等级、触发词、模型分类、人工校验规则 |
| Allowed / disallowed response map | 每个 intent 下可回答、不可回答、必须升级的内容 |
| Approved language library | 客服、信贷、财富、投诉、拒答、升级话术 |
| Product and jurisdiction policy map | 不同产品、州/国家、客户类型、渠道的差异 |
| Handoff and case routing map | 队列、SLA、owner、上下文摘要、失败兜底 |
| Boundary eval set | 越界测试、prompt injection、ambiguous intent、vulnerable customer scenarios |
9. Vulnerable Customers
脆弱客户不是标签化人群, 而是产品必须识别和降低伤害风险的情境。AI 体验尤其容易放大语言、认知、情绪、经济压力和数字可达性问题。
9.1 脆弱性信号
| Signal | 可能风险 | 体验策略 |
|---|---|---|
| 年龄或认知困难表述 | 难以理解复杂条款或 AI 边界 | 简明语言、人工优先、确认理解 |
| 语言障碍 | 误解费用、期限、风险 | 合格语言支持、避免机器翻译替代正式文件 |
| 残障或无障碍需求 | 无法完成自助流程 | accessible UI、替代渠道、人工协助 |
| 经济困难 | 可能被销售或收费误导 | hardship route、禁止高压销售 |
| 诈骗或胁迫迹象 | 资金损失、账户风险 | fraud team escalation、保护性暂停 |
| 情绪危机或重复困惑 | 服务阻断、投诉升级 | human escalation、slow down、case ownership |
9.2 Vulnerable customer design rules
- 不用 AI 继续推动销售流程, 直到风险信号解除或人工确认。
- 不用复杂免责声明替代清晰解释。
- 对关键选择提供 “review before submit” 和人工帮助。
- 避免默认同意、倒计时、损失厌恶型营销和高压话术。
- 记录触发原因和处置, 但避免不必要的敏感标签扩散。
- 不把脆弱性推断用于差别定价、服务降级或未经审查的自动决策。
9.3 Accessibility and comprehension
| Requirement | AI product implication |
|---|---|
| 可读性 | 高风险信息用短句、明确动作、可展开详情 |
| 多渠道 | 重要结果不只在聊天里展示, 同步到安全消息或正式文件 |
| 可听可读 | 语音助手和屏幕阅读器支持 AI 披露、边界和确认 |
| 可暂停 | 用户可以保存进度、回看证据、稍后继续 |
| 可人工 | 人工入口明显且不会因用户关闭 AI 个性化而消失 |
10. Complaint, Appeal and Recourse UX
信任体验的终点不是回答正确, 而是出错后能补救。投诉和申诉 UX 是 AI trust 的关键控制。
10.1 Complaint detection
| 用户表达 | 不应做 | 应做 |
|---|---|---|
| “我要投诉” | 继续 FAQ | 创建 complaint case |
| “你们这笔费用不合理” | 用政策反复解释 | 识别 disputed fee, 给出争议或投诉路径 |
| “我要找监管机构” | 触发防御性话术 | 转人工并记录 regulatory escalation signal |
| “这个 AI 一直答错” | 只收 thumbs down | 创建 AI quality issue 和 customer service case |
| “我要上诉/复核” | 说“系统结果无法改变” | 引导正式 appeal / reconsideration process |
10.2 Recourse journey
Customer challenge
-> AI recognizes complaint / appeal / correction intent
-> AI stops persuasive loop
-> case created with transcript and evidence
-> customer receives case ID and SLA
-> human owner reviews
-> outcome communicated through approved channel
-> AI quality issue linked to eval and policy update
10.3 Appeal UX fields
| Field | 说明 |
|---|---|
| Case ID | 客户可引用的正式编号 |
| Issue category | 投诉、申诉、资料更正、争议交易、AI 错误、服务可达性 |
| Customer statement | 客户原话保留, 不被 AI 改写为有利于机构的摘要 |
| AI interaction record | AI 披露、输出、来源、拒答、升级、模型和 policy version |
| Evidence pack | 系统事实、政策、正式文件、人工备注 |
| Owner and SLA | 谁处理、何时回复、通过什么渠道 |
| Outcome and correction | 结果、原因、补救、是否更新知识库或 eval |
11. User Control and Over-Reliance Prevention
用户控制不是“设置里有关闭按钮”。在 AI 产品里, 控制权必须嵌入任务关键节点。
11.1 Control inventory
| Control | 客户-facing AI | Internal copilot |
|---|---|---|
| Pause AI | 暂停自动建议或转人工 | 暂停建议面板 |
| Ask for source | 展开来源、更新时间、正式文件 | 查看引用、原文、证据图谱 |
| Edit / correct | 更正个人信息或问题摘要 | 编辑草稿并保留 diff |
| Refuse personalization | 关闭个性化排序或建议 | 选择不使用历史偏好 |
| Human handoff | 转人工、预约回呼、建工单 | escalate to SME / supervisor |
| Undo / cancel | 动作前确认, 动作后撤销路径 | 回滚 case update 或 draft |
| Export / record | 获取 transcript、case ID、正式通知 | evidence export for audit |
| Preference control | 语言、渠道、无障碍、通知频率 | reviewer settings、alert threshold |
11.2 Over-reliance controls
| 风险 | 控制 |
|---|---|
| AI 建议被默认采纳 | 不默认选中高风险建议; 要求用户或员工主动确认 |
| 审核者 rubber stamp | 随机插入 challenge cases; 记录 review time 和 override reason |
| AI 解释过于流畅 | 显示 evidence gaps、source conflicts、AI draft status |
| 批量批准风险 | 高风险任务禁止一键批量 approve |
| 模型权威感过强 | 用“建议 / 草稿 / 需要确认”状态, 不用“最佳 / 保证 / 已判断” |
| 绩效指标驱动盲从 | 不用单纯 speed KPI 压倒 quality、override 和 complaint metrics |
| 客户被 AI 说服放弃权利 | 投诉、争议、困难援助、人工入口不可被推荐算法隐藏 |
11.3 Under-reliance 也要管理
AI 如果经常拒答、解释差、来源弱、人工转接慢, 用户会完全绕开系统。对低风险、证据充分、可逆的任务, 产品应减少不必要摩擦:
- 常见公开 FAQ 不需要多层 consent。
- 已验证账户事实可直接展示, 但附来源和下一步。
- 低风险草稿可让员工快速采纳, 但保留 edit diff。
- 反复人工确认会降低 adoption, 应按风险分层。
12. Product Policy Architecture
AI trust 不能只靠 prompt policy。受监管产品需要 policy-as-product architecture。
12.1 Reference architecture
Channel UI
-> AI disclosure and consent layer
-> identity, entitlement and preference service
-> regulated intent and risk classifier
-> product / jurisdiction / customer policy engine
-> retrieval, source and evidence service
-> model gateway and prompt / response policy
-> tool gateway and action approval
-> explanation, refusal and handoff renderer
-> audit log, feedback, complaint and eval loop
12.2 Architecture principles
| Principle | 解释 |
|---|---|
| Deterministic controls before probabilistic generation | 身份、权限、产品资格、正式 reason、tool permission 不应靠 LLM 临场判断 |
| Policy versioning is product versioning | 话术、拒答、升级、来源、工具权限都要有版本和审批 |
| Evidence before eloquence | 没有证据时优先拒答或升级, 不用更流畅的话术掩盖 |
| Human path is part of the product | 人工、投诉、申诉不是 fallback ticket, 是 AI 体验核心能力 |
| Traceability by design | 每次高风险输出都能还原 source、model、prompt、policy、user action、handoff |
| Accessibility and vulnerability are controls | 无障碍和脆弱客户保护不是体验加分项, 是风险控制 |
| Feedback must close the loop | 用户反馈必须进入 eval、知识、policy、training 或 incident, 不能停在满意度报表 |
12.3 Architecture-to-product mapping
| Trust requirement | Product design | Architecture control | Evidence |
|---|---|---|---|
| AI disclosure | 首屏和关键节点披露 | Disclosure config service | disclosure version log |
| Consent | purpose-based opt-in / opt-out | Consent and preference service | consent event log |
| Regulated boundary | intent-specific answer / refuse / handoff | Policy engine + intent classifier | decision trace |
| Evidence display | 来源卡、更新时间、缺失信息 | Retrieval metadata + citation validator | source trace |
| Explanation | reason code、rationale、next step | Reason pipeline + template renderer | explanation record |
| Uncertainty | source conflict / missing data signals | Evidence quality scoring | uncertainty event |
| Refusal | 边界解释和安全替代路径 | Response policy guardrail | refusal log |
| Handoff | warm transfer、case ID、SLA | Case management integration | handoff record |
| User control | edit、undo、pause、human | UI state + tool gateway | user action log |
| Complaint / appeal | complaint recognition and case creation | Complaint workflow integration | complaint evidence pack |
| Over-reliance prevention | active confirmation、challenge prompts | Review workflow rules | override and review analytics |
| Monitoring | trust dashboard and alerts | Observability pipeline | weekly quality report |
13. Financial Retail Cases
13.1 Customer-Facing AI: Digital Banking Assistant
| Dimension | 设计决策 |
|---|---|
| Trust promise | “帮助客户理解账户、费用、交易和服务流程; 不替代正式通知、投诉处理、信贷审批或投资建议。” |
| Main risks | 错误费用解释、阻断人工、误识别投诉、未认证泄露账户、过度个性化销售 |
| Experience architecture | AI disclosure、identity check、intent tiering、policy RAG、account API、complaint detection、warm handoff |
| Evidence display | 账户系统事实 + 费用政策 + 生效日期 + case next step |
| Refusal / escalation | 投诉、争议、欺诈、脆弱客户、来源冲突、高额费用异常转人工 |
| Metrics | first-contact resolution with quality、handoff success、complaint capture rate、unsupported answer rate、customer comprehension |
| Stop signals | AI 把投诉当 FAQ、无法转人工、费用政策过期仍回答、客户被误导放弃争议权利 |
13.2 Credit Copilot
Credit copilot 的信任对象主要是 underwriter、loan officer、risk reviewer 和 audit, 但最终影响客户权益。
| Dimension | 设计决策 |
|---|---|
| Trust promise | “帮助整理资料、发现缺失项、引用政策、草拟 memo; 不自动做 credit decision, 不生成未经验证的 adverse action reason。” |
| Main risks | rationalized reason、fair lending 风险、审批责任模糊、自动化偏见、政策引用错误 |
| Experience architecture | document extraction、policy RAG、reason code service、underwriter review queue、model and prompt versioning |
| Evidence display | 客户资料来源、政策条款、缺失字段、exception tags、AI draft label |
| Control | underwriter edit diff、override reason、dual approval for exception、adverse action reason from formal pipeline |
| Metrics | memo accuracy、missing-doc recall、policy citation accuracy、override rate、reviewer calibration、fair lending review flags |
| Stop signals | LLM 编造拒绝理由、审批者批量 rubber stamp、政策版本无法追溯、reason 与正式系统不一致 |
13.3 Wealth Assistant Boundary
财富 AI 的核心不是“推荐能力”, 而是区分 education、general product information、personalized advice 和 execution。
| Layer | AI 可做 | 必须转人工或正式流程 |
|---|---|---|
| Education | 解释股票、债券、基金、风险、费用、分散投资概念 | 客户要求“我应该买什么” |
| Product information | 展示公开产品信息、费用、风险等级和适用条件 | 按客户资料排序为“最适合” |
| Planning support | 帮客户整理目标、期限、风险偏好问题 | 给具体资产配置或产品建议 |
| Personalized advice | 仅在完成机构允许的 suitability / advisory workflow 后支持 | 未授权渠道、未更新风险评估、脆弱客户销售信号 |
| Execution | 引导到正式交易界面、显示确认和披露 | 让生成式聊天直接下单或绕过确认 |
Trust design:
- 每次进入个性化意图时显示 advice boundary。
- 产品排序必须解释排序依据, 并标注是否个性化。
- 高风险或复杂产品显示费用、流动性、主要风险和适当性要求。
- 客户表现出困惑、压力、诈骗或脆弱信号时暂停销售导向流程。
- 交易执行必须离开开放生成文本, 进入正式交易确认和记录保留。
13.4 AML Analyst Copilot
AML copilot 的信任对象是 analyst、QA、compliance 和 regulator。客户不应看到 AML 监控逻辑或可规避信息。
| Dimension | 设计决策 |
|---|---|
| Trust promise | “帮助 analyst 汇总证据、实体关系、交易模式和 narrative draft; 不自动决定 SAR filing, 不向客户披露监控逻辑。” |
| Main risks | tipping-off、虚假 narrative、遗漏证据、过度依赖、敏感数据外泄、无法审计 |
| Experience architecture | case graph、transaction evidence、policy RAG、draft narrative、analyst review、QA sampling、audit export |
| Evidence display | 交易链路、账户关系、触发规则、source timestamps、历史 case references |
| Control | analyst reject/edit/escalate、SAR decision outside model、supervisor review、data minimization |
| Metrics | evidence coverage、citation correctness、analyst disagreement、QA defect rate、SAR narrative rework、false comfort indicators |
| Stop signals | AI 建议“无需提交 SAR”且被默认采纳、客户渠道泄露调查原因、narrative 无证据、模型更新无回归测试 |
14. Trust Metrics and Feedback Loops
AI trust 不能只看 CSAT 或 adoption。高 usage 可能代表过度依赖, 低 complaint 可能代表投诉入口被阻断。
14.1 Metric system
| Metric | 解释 | 风险解读 |
|---|---|---|
| Calibrated adoption | 低风险任务采用率高, 高风险任务复核率足够 | 比总 usage 更有意义 |
| Unsupported answer rate | 无来源或来源不足的回答比例 | 高则说明 evidence gate 失效 |
| Boundary violation rate | AI 越过信贷、财富、投诉、法律等边界 | 必须进入 incident / release gate |
| Handoff success rate | 转人工成功并携带上下文的比例 | 低则说明人工路径只是装饰 |
| Complaint capture rate | 投诉意图被正确建单比例 | 低可能是服务阻断风险 |
| Appeal / correction completion | 申诉、纠错获得处理和结果的比例 | 衡量 recourse 是否真实 |
| Over-reliance signal | 批量采纳、低审阅时间、低 override 但高缺陷 | 需要 reviewer calibration |
| Under-reliance signal | 合格任务也被用户绕开 | 可能是解释差、拒答过多、慢或不可信 |
| Vulnerable customer outcome | 脆弱信号后的人工、投诉、销售抑制和满意度 | 需要隐私和公平使用审查 |
| Feedback-to-fix cycle time | 反馈进入知识、policy、eval 或模型修复的时间 | 长则说明反馈闭环断裂 |
14.2 Feedback routing
| Feedback type | 去哪里 | 产出 |
|---|---|---|
| Wrong answer | EvalOps + knowledge owner | eval case、source fix、regression test |
| Wrong boundary | AI Governance + Compliance | policy update、conversation rule fix |
| Bad handoff | Operations owner | queue fix、SLA review、handoff template update |
| Complaint about AI | Complaint team + PM | customer case、AI quality issue、risk review |
| Accessibility issue | UX + Accessibility + Legal | accessibility remediation |
| Reviewer disagreement | Model Risk + Ops | calibration session、rubric update |
| Prompt injection / misuse | Security + Platform | threat model update、guardrail fix |
| Cost or latency causing degraded UX | Platform + PM | routing, caching, fallback, SLO update |
14.3 Anti-metrics
不要把以下指标单独作为成功:
- AI deflection rate: 如果只是减少人工接触, 可能伤害服务可达性。
- Average handle time reduction: 如果导致错误、投诉或过度依赖, 不是成功。
- Thumbs-up rate: 容易受界面位置和用户疲劳影响。
- Model benchmark score: 不等于业务场景中的解释、边界和救济能力。
- Zero complaint: 可能表示投诉入口不可见或被 AI 阻断。
15. Templates and Artifacts
15.1 Trust Experience Canvas
| Field | 填写内容 |
|---|---|
| Use case | 业务场景、用户、渠道、客户影响 |
| Trust promise | 用户应该信任 AI 做什么 |
| Non-trust boundary | 用户不应该信任 AI 做什么 |
| Risk tier | Tier 0-4 和理由 |
| AI behavior | retrieve、summarize、explain、recommend、draft、act |
| Regulated boundary | 信贷、财富、投诉、AML、隐私、无障碍、销售等 |
| Evidence requirement | 必须有哪些 source、version、effective date、owner |
| Transparency design | 披露时点、内容、持久性和可访问性 |
| Control design | pause、edit、undo、human、appeal、opt-out |
| Handoff design | 触发条件、队列、SLA、context summary |
| Metrics | calibration、quality、complaint、handoff、over-reliance |
| Release gate | 上线前必须通过的 eval、review、sign-off |
15.2 Regulated Conversation Policy Matrix
| Intent | Allowed response | Disallowed response | Required evidence | Escalation trigger | Owner |
|---|---|---|---|---|---|
| Credit result explanation | 解释正式通知中的 reason | 猜测拒绝原因 | decision reason code、notice ID | 客户争议或未收到通知 | Credit / Compliance |
| Wealth product question | 解释公开产品和一般风险 | 个性化推荐 | product master、risk disclosure | 个性化建议请求 | Wealth Compliance |
| Complaint | 建单、确认编号、说明 SLA | 继续劝说客户接受解释 | transcript、case category | 任意投诉意图 | Complaint Ops |
| Fraud concern | 收集材料、转安全团队 | 披露检测规则 | authentication、fraud queue | 账户风险、诈骗信号 | Fraud Ops |
15.3 Evidence Display Spec
| Section | 内容 |
|---|---|
| Evidence card | source title、owner、effective date、last reviewed、jurisdiction、product scope |
| Answer status | verified fact、AI summary、AI draft、human reviewed、formal notice |
| Missing info | 缺少哪些字段、如何补充、是否阻断回答 |
| Conflict signal | 哪些来源冲突、谁负责确认 |
| Explanation level | brief answer、expanded rationale、audit view |
| Action link | dispute、appeal、update info、contact advisor、human support |
15.4 Refusal and Escalation Script Spec
| Field | 要求 |
|---|---|
| Boundary statement | 说明不能做什么, 不使用模糊借口 |
| Reason | 用客户能理解的语言说明原因 |
| Safe alternative | 提供可行路径, 如正式流程、人工、教育资料 |
| Escalation path | 队列、SLA、case ID 或下一个动作 |
| Audit tag | refusal reason code、risk tier、policy version |
15.5 AI Trust Release Gate
| Gate | Pass criteria |
|---|---|
| Disclosure | 关键时点披露清晰、可访问、可记录 |
| Boundary | 受监管 intent 测试通过, 越界输出被阻断 |
| Evidence | 高风险回答有 source、version、effective date |
| Refusal | 拒答不空洞, 有替代路径 |
| Handoff | 人工转接真实可用, 上下文完整, SLA 明确 |
| Complaint / appeal | 投诉和申诉可被识别、建单、追踪 |
| Vulnerable customers | 脆弱信号测试通过, 不触发销售压力 |
| Over-reliance | 审核者和客户不会被默认引导盲从 |
| Monitoring | dashboard、alerts、owner、incident runbook 已上线 |
| Evidence pack | audit log schema 可还原关键输出和动作 |
15.6 Audit Event Schema
| Field | 说明 |
|---|---|
| event_id | 唯一事件 ID |
| user_role | customer、agent、analyst、underwriter、advisor、admin |
| channel | mobile、web、branch、contact center、internal tool |
| disclosure_version | 展示的 AI disclosure 版本 |
| consent_state | purpose、status、timestamp |
| intent_and_risk | intent、risk tier、classifier version |
| model_context | model、prompt、policy、tool permissions |
| evidence_context | source IDs、retrieval query、effective date、citation validation |
| response_type | answer、clarify、refuse、handoff、case_creation、action_request |
| user_control | edit、pause、handoff、appeal、undo、feedback |
| outcome | resolved、escalated、complaint、abandoned、incident |
| reviewer_action | approve、edit、reject、override、escalate |
16. 30-Day Lab
目标: 30 天内产出一个可面试展示的 AI Trust Experience / Product Governance portfolio pack, 以金融零售受监管场景为主线。
Week 1: Trust Risk and Journey
| Day | 任务 | 产出 |
|---|---|---|
| 1 | 选择一个 use case: 客户 AI、信贷 copilot、财富助手或 AML copilot | Use case brief |
| 2 | 定义 trust promise 和 non-trust boundary | Trust Experience Canvas v1 |
| 3 | 做 trust risk tiering 和 harm scenario map | Risk tier memo |
| 4 | 画 customer / employee journey, 标注 AI 介入点 | Journey map |
| 5 | 建 regulated intent taxonomy | Intent boundary table |
| 6 | 设计 AI disclosure 和 consent 时点 | Disclosure matrix |
| 7 | 复盘 Week 1, 写一页 executive summary | Trust problem statement |
Week 2: Evidence, Control and Conversation Policy
| Day | 任务 | 产出 |
|---|---|---|
| 8 | 定义 evidence hierarchy 和 source ownership | Evidence map |
| 9 | 设计 explanation types 和 evidence display | Evidence display spec |
| 10 | 设计 uncertainty taxonomy | Uncertainty policy |
| 11 | 写 refusal / escalation patterns | Refusal library |
| 12 | 设计 complaint / appeal UX | Recourse journey |
| 13 | 设计 vulnerable customer safeguards | Vulnerability checklist |
| 14 | 复盘 Week 2, 做 5 个边界测试案例 | Boundary eval cases |
Week 3: Architecture and Governance
| Day | 任务 | 产出 |
|---|---|---|
| 15 | 画 trust product architecture | Architecture diagram text |
| 16 | 把体验要求映射到架构控制 | Architecture-to-product mapping |
| 17 | 设计 audit event schema | Audit schema |
| 18 | 设计 release gate 和 sign-off | Release gate checklist |
| 19 | 设计 trust metrics dashboard | Metrics spec |
| 20 | 设计 feedback-to-fix loop | Feedback operating model |
| 21 | 复盘 Week 3, 写 ADR: policy engine vs prompt-only guardrail | ADR |
Week 4: Cases and Interview Pack
| Day | 任务 | 产出 |
|---|---|---|
| 22 | 完成 customer-facing AI case | Case study 1 |
| 23 | 完成 credit copilot case | Case study 2 |
| 24 | 完成 wealth assistant boundary case | Case study 3 |
| 25 | 完成 AML analyst copilot case | Case study 4 |
| 26 | 准备 trust incident scenario 和 response | Incident playbook |
| 27 | 准备 governance review pack | Governance deck outline |
| 28 | 写 8-10 个 interview answers | Interview answer set |
| 29 | 把 artifacts 整理成 portfolio storyline | Portfolio narrative |
| 30 | 做一次 20 分钟 mock interview 和复盘 | Final trust experience pack |
17. Interview Answers
Q1: 你如何设计一个银行 AI 产品的信任体验?
30 秒版本:
我会把信任当成产品架构, 不是 UI 文案。先定义 AI 能做什么和不能做什么, 再按风险分层设计披露、证据、解释、不确定性、拒答、人工升级、投诉申诉和审计证据。目标不是让用户盲目信任, 而是 calibrated trust。
2 分钟版本:
我会从 use case 的客户影响开始, 判断 AI 是 retrieve、summarize、recommend、draft 还是 act。然后做 decision boundary map, 明确哪些由 AI 辅助, 哪些必须由规则系统、人工或正式流程决定。对客户可见体验, 我会设计 AI disclosure、数据和个性化 consent、来源展示、正式通知边界、拒答和人工入口。对内部 copilot, 我会设计 reviewer evidence、override reason、edit diff 和 audit trail。最后用 release gate 和 dashboard 管理: unsupported answer、boundary violation、handoff success、complaint capture、over-reliance signal 和 feedback-to-fix cycle。
Q2: 如何防止用户或员工过度依赖 AI?
30 秒版本:
过度依赖不能靠一句“AI 仅供参考”解决。要在流程里设计证据、主动确认、替代方案、override、人工复核、批量批准限制和 reviewer calibration。
2 分钟版本:
我会先识别高影响节点: 信贷理由、财富建议、AML narrative、投诉处理和客户账户动作。对这些节点, AI 输出不默认选中, 不允许一键批量批准, 必须展示来源、缺失信息和不确定性。员工端要记录 edit diff、reject 和 override reason, 并通过抽样复核和 challenge cases 校准 reviewer。客户端要能转人工、申诉、纠错和关闭个性化。指标上不能只看采用率, 还要看低审阅时间、高采纳低 override、投诉和质量缺陷的组合信号。
Q3: 透明度应该做到多细?
30 秒版本:
透明度不是把模型细节全展示出来, 而是在关键时点给用户足够信息做合理选择: AI 身份、角色、边界、来源、不确定性、数据用途和救济路径。
2 分钟版本:
我会分层设计透明度。普通 FAQ 展示 AI 身份和来源即可; 账户问题需要身份和数据使用边界; 信贷、财富、投诉等场景需要明确正式流程和人工路径; 高影响动作要展示动作影响、确认和撤销路径。解释也要按风险分层: 客户看到简洁来源和下一步, 员工看到证据、缺失字段、policy version 和 edit controls, audit 看到完整 trace。透明度过细会造成信息过载, 过少会变成黑箱。
Q4: 什么时候 AI 应该拒答或升级?
30 秒版本:
当数据缺失、来源冲突、身份未验证、问题进入信贷/财富/投诉/AML 等受监管边界, 或出现脆弱客户和安全风险时, AI 应拒答、澄清或升级。
2 分钟版本:
我会定义 uncertainty taxonomy 和 regulated intent matrix。拒答不是简单说“不能回答”, 而是说明边界、原因、可行替代路径和下一步。例如财富建议场景, AI 可以解释产品风险, 但客户要求“根据我的资产推荐产品”时应进入 suitability 或持牌顾问流程。投诉场景不应继续 FAQ, 应创建 case。AML 场景不能向客户披露监控逻辑, 但可以转账户安全团队。所有拒答和升级都应记录 reason code 和 policy version。
Q5: 如何设计 AI disclosure?
30 秒版本:
AI disclosure 要覆盖身份、角色、边界和救济, 并在关键时点重复出现。不能只放在首次弹窗或页脚。
2 分钟版本:
我会设计 disclosure matrix。首次进入说明这是 AI 助手、适用任务和人工入口; 进入账户信息前说明身份验证; 进入个性化前说明数据用途和 opt-out; 进入信贷、财富、投诉或工具动作前说明正式流程边界和动作影响。披露要可访问、可记录、按渠道适配, 并与 consent service 和 audit log 连接。尤其不能让 AI 通过头像、名字或延迟效果假装人工。
Q6: 信贷 copilot 的产品边界怎么定?
30 秒版本:
信贷 copilot 可以整理资料、引用政策、发现缺失项和草拟 memo, 但不能自动审批, 也不能由 LLM 编造 adverse action reason。
2 分钟版本:
我会把信贷 copilot 定位为 decision support, 不是 decision maker。正式审批仍由信贷规则、模型、underwriter 和审批流程完成。AI 可以做文档抽取、政策检索、缺失资料提示和 memo 草稿, 但 reason code 必须来自正式决策系统或 reason pipeline。UI 上要标注 AI draft、显示引用、允许 underwriter edit/reject/override, 并记录 edit diff 和 override reason。上线前需要 policy citation eval、reason consistency eval、fair lending review 和 audit trace。
Q7: 财富 AI 助手如何避免越界?
30 秒版本:
关键是把 education、general product information、personalized advice 和 execution 分层。AI 可以教育和解释, 但个性化建议和交易必须进入适当性和正式流程。
2 分钟版本:
我会在意图分类里识别客户是否提供个人目标、期限、资产、风险偏好并要求建议。一旦进入个性化建议, AI 不直接推荐具体产品, 而是转到 suitability assessment 或持牌顾问流程。产品信息可以展示公开费用、风险等级和适用条件, 但不能默认排序为“最适合你”。交易执行必须离开开放聊天, 进入正式交易界面、披露和确认。脆弱客户或诈骗信号出现时要暂停销售导向路径。
Q8: AML analyst copilot 如何建立信任而不制造合规风险?
30 秒版本:
AML copilot 应帮助汇总证据和草拟 narrative, 但不做 SAR 决策, 不向客户披露监控逻辑, 并保留完整证据链和人工复核。
2 分钟版本:
我会设计 evidence-first analyst experience: 交易链路、实体关系、规则触发、历史 case 和政策引用都可展开。AI narrative 必须标记为 draft, analyst 可以 edit/reject/escalate, SAR filing 决策在正式流程里由合格人员记录。架构上需要数据最小化、权限过滤、audit export 和 prompt/tool versioning。指标上看 evidence coverage、citation correctness、analyst disagreement、QA defect 和 over-reliance signal。任何客户渠道都不能泄露 AML 监控规则或调查原因。
Q9: 如何处理 AI 出错后的投诉和申诉?
30 秒版本:
AI 出错后的补救路径必须产品化: 识别投诉、停止循环答复、创建 case、给客户编号和 SLA、保留证据、人工处理, 并把问题回流到 eval 和 policy。
2 分钟版本:
我会把 complaint / appeal intent 作为高优先级分类。用户说“我要投诉”“我要复核”“这个 AI 答错导致损失”时, AI 不能继续说服或 FAQ, 必须建单。case 里保留客户原话、AI 输出、来源、模型和 policy version、披露记录、handoff 和后续人工处理。客户要拿到 case ID、预计回复时间和正式渠道。内部还要把问题分类到知识错误、边界错误、模型错误、handoff 错误或服务可达性问题, 进入整改闭环。
Q10: 如何向高管解释 AI trust experience 的 ROI?
30 秒版本:
AI trust experience 的 ROI 不只是提升满意度, 还包括降低投诉、返工、错误赔付、监管风险、人工升级失败和无效 adoption, 同时提高可控规模化能力。
2 分钟版本:
我会用 risk-adjusted value 解释。没有 trust architecture 的 AI 可能短期减少人工接触, 但会增加投诉、错误沟通、监管问询和员工返工。成熟信任体验可以提升低风险自助完成率, 同时保证高风险场景正确升级; 可以通过证据和解释减少重复联系; 通过反馈闭环降低同类错误; 通过审计 trace 降低事故处置成本。指标上我会同时看业务价值、质量、投诉、handoff、over-reliance 和整改周期, 避免只看 deflection rate。
18. Portfolio Packaging
这份 playbook 可以转化为以下作品集资产:
| Portfolio asset | 展示能力 |
|---|---|
| Trust Experience Canvas | 能把 AI 信任目标、边界、风险和控制压缩成一页 |
| Regulated Conversation Matrix | 能设计受监管金融零售对话边界 |
| Evidence Display Spec | 能把解释性和证据链变成产品界面和数据要求 |
| Product Policy Architecture | 能把 UX governance 映射到 policy engine、audit、handoff 和 eval |
| Complaint / Appeal Journey | 能设计客户救济和 AI 事故补救 |
| Trust Metrics Dashboard | 能避免只看 adoption, 用校准信任指标管理上线后风险 |
| Four case studies | 能覆盖 customer-facing AI、credit、wealth、AML 四类高价值金融场景 |
面试收束句:
“我设计 AI 产品时不会把 trust 当成文案或品牌感受。我会把它拆成 disclosure、boundary、evidence、uncertainty、control、handoff、recourse、monitoring 和 audit, 再映射到产品体验、系统架构和治理证据。这样 AI 才能在受监管金融零售场景中被客户、员工、管理层和监管方校准地信任。”