目录
AI Adoption / Change Management / AI Literacy / Role Redesign Playbook
目标: 训练在企业金融零售场景中, 如何把 AI 从 POC、demo、个人效率工具推进为可采用、可运营、可审计、可证明收益的组织能力。
适用对象: AI PM、BA、Enterprise Architect、AI Transformation Lead、Change Manager、Operations Lead、Risk/Compliance Partner、业务条线负责人。
核心原则: AI adoption 不是“上线模型 + 发培训通知”, 而是产品设计、流程再造、角色重构、治理证据、激励机制和收益实现共同组成的组织系统。
1. 定位与相邻资产连接
本手册补齐的是 AI 转型中的 adoption / change management 层。docs/AI_TRANSFORMATION_VALUE_OFFICE_PLAYBOOK.md 解决 portfolio funding、benefit realization、risk gate、kill/scale decision; 本文件回答一个更贴近一线的问题:
为什么 AI POC 看起来成功, 但上线后没人用、用不好、用不久、收益无法被财务确认?
连接资产 已解决的问题 本手册如何承接 docs/AI_TRANSFORMATION_VALUE_OFFICE_PLAYBOOK.mdportfolio gate、benefits register、scale/stop decision 把 adoption 指标、workflow redesign、training、support、resistance signals 接入 value review docs/AI_REQUIREMENTS_TO_EVAL_COOKBOOK.md从需求到 eval 的可验证路径 把用户反馈、误用模式、工作流断点回灌到 EvalOps docs/AI_OPERATING_MODEL_RACI_RUNBOOK.mdAI operating model 与 RACI 把 adoption owner、change champion、support tier、manager cadence 固化到 RACI docs/AI_GOVERNANCE_EVALOPS_RISK_90_PLAN.mdAI 治理、评估、风险能力训练 把 AI literacy 和 role-based training 作为治理控制的一部分 docs/AI_ROLE_COMPETENCY_MATRIX_2026.mdAI 时代岗位能力矩阵 把岗位能力进一步落到 role redesign、培训路径和绩效信号
一句话定位:
AI Adoption = behavior change + workflow redesign + role redesign + AI literacy + support model + benefit proof + EvalOps feedback.
这不是传统变更管理的换皮。AI 的采用挑战更难, 因为它同时改变了:
改变对象 传统系统上线 AI 系统上线 工具行为 用户学习新界面 用户还要理解概率性输出、置信度、幻觉、边界、升级路径 流程控制 规则相对稳定 规则、模型、提示词、数据、风险阈值会持续迭代 责任归属 系统执行确定逻辑 人机协同下要重新定义谁判断、谁批准、谁承担残余风险 绩效影响 自动化明确步骤 AI 可能重分配工作价值, 引发身份焦虑和岗位边界冲突 治理证据 需求、测试、UAT、权限 还需要 eval、monitoring、AI literacy、human oversight、incident log
2. Source Anchors
本手册使用以下公开框架作为治理锚点, 并转化为企业金融零售采用管理实践。它不是法律意见, 也不替代机构内部合规判断。
Source 与 adoption 的关系 在本手册中的落点 EU AI Act Article 4 AI literacy 要求 AI 系统 providers/deployers 尽最大程度确保相关人员具备足够 AI literacy, 并考虑技术知识、经验、教育、培训、使用场景及受影响人群 第 6 章 AI literacy obligations, 第 12 章培训课程, 第 19 章模板 NIST AI RMF Govern / Manage NIST AI RMF Playbook 围绕 Govern、Map、Measure、Manage 提供行动建议; adoption 需要嵌入治理、责任、监控和风险处理 第 5 章 adoption operating model, 第 15 章 metrics, 第 18 章 EvalOps loop ISO/IEC 42001 AI management system 强调建立、实施、维护并持续改进 AI 管理体系 第 5 章 operating model, 第 13 章 enablement assets, 第 16 章 support model OMB M-24-10 2024 年美国联邦 AI 治理、创新、风险管理备忘录, 强调 CAIO、用例清单、权利/安全影响 AI 的最低风险管理实践 第 5 章治理论坛, 第 17 章 benefit realization, 第 20 章场景化控制 OMB M-25-21 2025 年文件已取代 M-24-10, 强调 innovation、governance、public trust 本手册保留 M-24-10 的结构性启发, 同时提醒使用时应核对最新适用政策
参考链接:
3. 为什么 AI Adoption 经常死在 POC 之后
3.1 POC 成功不等于组织采用
POC 经常证明的是“模型在小样本上能演示”, 不是“业务在真实约束下会改变行为”。金融零售企业尤其容易出现 POC illusion, 因为流程长、控制多、岗位分工细、数据权限复杂、监管解释成本高。
POC 阶段看起来成功 规模化阶段真实问题 结果 Demo 能回答产品知识 一线人员不知道什么时候可以信、什么时候必须升级人工 用得谨慎, 采用率低 Pilot 准确率不错 真实客户问题长尾复杂, exception handling 不完整 投诉、返工、合规风险上升 节省时间估算很高 用户仍要复制粘贴、核对、留痕、补录 净节省不成立 Sponsor 支持 中层经理担心团队指标、排班、责任被改变 软抵抗 技术团队能上线 业务 owner 没有 adoption target 和 benefit ownership 上线后无人推动 用户培训完成 培训只讲功能, 不讲判断标准、禁止用法和责任边界 误用、弃用并存 风险评审通过 没有持续 monitoring、incident route、model drift response 运行风险积累
3.2 POC 后失败的十个根因
根因 典型表现 深层原因 修复动作 问题定义停留在“能不能用 AI” 用例名称是“客服 Agent”而不是“缩短投诉分类到分派时间” 技术方案替代业务问题 用 job-to-be-done、baseline、target behavior 重写 use case 没有流程再造 AI 输出仍要人工在多个系统间搬运 只改工具, 不改 workflow 画 AS-IS / TO-BE / exception path / audit path 角色边界未重设 一线问“出错算谁的” human oversight 没有工作化 定义 maker/checker/approver/escalation owner 缺少 AI literacy 员工把 AI 当搜索引擎或权威裁判 不理解概率性、上下文、数据边界 role-based literacy training + scenario drills 管理者不改节奏 经理仍按旧 KPI 管理 incentive 与新行为冲突 修改 team huddle、QA sample、coaching、绩效信号 支持模型薄弱 用户遇到错误只会截图发群 没有 support tier 和知识库 建 L1/L2/L3 support、issue taxonomy、SLA 没有反馈回路 用户反馈进入聊天群, 没进 backlog/eval set adoption 与 EvalOps 脱节 把反馈分类为 UX、workflow、data、prompt、model、policy 收益无法确认 节省工时被质疑 没有 baseline、control group、finance sign-off 建 benefits register 与 adoption-adjusted ROI 风险控制过重或过轻 要么没人敢用, 要么随便用 风险分层不清 按 use case risk tier 设置权限、审批、监控 组织叙事错误 员工理解为“AI 要替代我” 没有 role redesign 和职业路径 明确人类判断价值、升级技能、岗位转型路径
3.3 POC 到 Scale 的证据门槛
证据 最低要求 金融零售建议 Adoption evidence 活跃使用、任务完成、重复使用、弃用原因 分角色、分网点/团队、分流程节点看 adoption Quality evidence 输出质量、错误类型、人工覆盖率 结合 QA 抽检、投诉、合规复核、客户影响 Workflow evidence TO-BE 流程被真实执行 记录例外路径、返工率、平均处理时间 Literacy evidence 关键岗位完成培训并通过情景测试 高风险岗位需年度复训和使用授权 Risk evidence 风险控制、日志、升级、回滚、incident path 对权利/安全/客户资金影响用例设置更强 gate Benefit evidence baseline、目标、实际、归因、财务确认 不只算节省小时, 还算质量、风险、收入、客户体验
4. Adoption 是产品、系统和组织问题
4.1 三层问题模型
层级 核心问题 关键产物 失败信号 Product 用户为什么要在当前任务中用它 Persona、Jobs-to-be-Done、UX flow、trust cue、permission design 用户说“挺好, 但我还是用旧办法” System AI 如何嵌入流程、数据、权限、审计、运营 TO-BE workflow、integration map、control map、runbook AI 输出无法进入核心系统或无法留痕 Organization 谁负责、谁学习、谁被激励、谁承担风险 RACI、training path、manager cadence、incentive plan sponsor 支持但中层不推动, 一线观望
4.2 Adoption Product Canvas
Canvas 项 问题 示例: 零售银行客户投诉分类助手 Target behavior 期待用户改变什么行为 客服主管不再手工读完投诉后分派, 而是先使用 AI 分类建议并确认 Moment of use 用户在何时使用 新投诉进入队列后的前 2 分钟 Trust requirement 用户需要什么才敢用 分类理由、引用原文、置信度、相似案例、升级建议 Friction removed 去掉什么阻力 自动读取投诉文本、自动写入工单分类字段、保留人工 override Human decision 人保留什么判断 是否涉及监管投诉、是否升级敏感客户、最终分类确认 Prohibited use 不能做什么 不允许自动关闭投诉, 不允许生成未核实客户承诺 Manager routine 经理如何推动 每日看 adoption dashboard, 抽样复核 override case Benefit proof 如何证明价值 首次分派时间、返工率、误分类率、投诉 SLA breach、人工处理时长
4.3 Adoption Backlog
AI 产品 backlog 不能只放模型功能, 还要放 adoption enablers。
Backlog 类型 示例条目 Owner Workflow 把 AI 分类结果写入工单系统并支持人工修改原因 BA + Architect Trust 输出理由必须引用客户原文和政策段落 AI PM + EvalOps Training 建 12 个投诉分类情景演练题 BA + Ops QA Support 建立“错误分类”一键反馈入口 Product + Support Governance 高风险投诉自动提示二线复核 Risk + Architect Metrics Dashboard 区分 adoption、quality、benefit、risk PM + Data Incentive 团队 KPI 加入正确使用率和返工率 Business owner + HR
5. Adoption Operating Model
5.1 生命周期
Stage 目标 Adoption 工作 出口证据 Discovery 判断是否值得改变流程 Stakeholder map、baseline、persona、resistance scan、AI literacy needs Adoption hypothesis Pilot design 设计可学习的小范围试点 Pilot cohort、training、support tier、usage policy、manager cadence Pilot adoption plan Pilot run 验证真实行为改变 Usage monitoring、office hour、feedback triage、QA sampling Pilot adoption report Release 控制上线并减少误用 Role-based authorization、go-live support、incident path、knowledge base Release readiness pack Scale 扩大范围并标准化 Train-the-trainer、champion network、incentive alignment、benefit tracking Scale readiness memo Continuous improvement 把采用反馈变成系统改进 EvalOps feedback loop、workflow backlog、policy refresh、recertification Monthly adoption review
5.2 Adoption RACI
Activity Business Owner AI PM BA Architect Change Lead Risk/Compliance Ops Manager HR/L&D EvalOps Adoption objective A R C I C C C I I Stakeholder segmentation A R R I R C C C I Workflow redesign A C R C C C R I I Role redesign A C R C R C R C I AI literacy curriculum C R R C R C C A/R C Training delivery C C C I R C R A/R I Usage policy A R C C C A/R C I C Support model A R C R R C R I C Adoption dashboard A R C C C C C I R Benefit realization A R R I C C C I C Feedback to eval C R R C C C C I A/R
5.3 Governance Forums
Forum Cadence 参与者 议题 输出 Adoption design clinic Discovery / pilot 前 PM、BA、Ops、Change、Risk、Architect 目标行为、流程断点、stakeholder map Adoption canvas Pilot daily huddle Pilot 前 1-2 周每日 15 分钟 Pilot team、manager、support、PM 使用阻力、错误案例、培训缺口 Daily issue log Weekly adoption review 上线后前 8 周每周 Business owner、PM、BA、Ops、EvalOps 使用、质量、反馈、返工、收益 Adoption action list Monthly value review 每月 Value Office、Finance、Risk、Business adoption-adjusted benefit、scale/stop Scale/stop recommendation Quarterly literacy review 每季度 HR/L&D、Risk、PM、业务负责人 培训覆盖、认证、事件、政策变化 Curriculum refresh
6. AI Literacy Obligations
6.1 AI Literacy 的企业解释
AI literacy 不是“会写 prompt”。在企业金融零售中, 它至少包括:
能力 具体含义 为什么重要 概念理解 知道 AI 输出是概率性建议, 不是事实或审批结论 防止自动化偏见和过度信任 场景边界 知道系统适用任务、禁止任务、升级条件 防止越权使用 数据意识 知道哪些客户数据、敏感信息、商业秘密不能输入或外传 防止隐私、保密和监管风险 输出判断 能检查引用、理由、异常、置信度、缺失信息 提高 human oversight 质量 责任边界 知道 AI、人、经理、审批人的责任分工 防止“系统说的”成为责任逃避 反馈能力 能把错误输出转化为可分析反馈 支撑 EvalOps 改进 客户影响意识 知道 AI 可能影响客户权益、价格、授信、投诉、公平性 金融零售中直接关系合规和信任
6.2 Role-Based Literacy Matrix
角色 必备 AI literacy 认证方式 复训频率 一线客服/网点员工 适用场景、禁止输入、输出核查、升级路径、客户沟通边界 情景题 + 主管抽查 半年 信贷/风控分析师 模型限制、特征敏感性、解释要求、人工复核、偏差识别 案例分析 + override review 半年 营销/CRM 运营 个性化推荐边界、同意管理、敏感客群、误导性内容风险 Campaign review drill 半年 PM/PO adoption metrics、风险分层、eval 设计、feedback loop、benefits Use case review board 演示 每季度更新 BA 流程重构、规则/例外抽取、role redesign、培训场景设计 AS-IS/TO-BE + scenario pack 每季度更新 Architect AI reference architecture、logging、access control、fallback、auditability Architecture review 每季度更新 Manager 团队 adoption 指标、coaching、激励、质量抽检 Manager adoption review 半年 Risk/Compliance AI risk taxonomy、control evidence、monitoring、incident response Control evidence review 每季度 Executive value/risk trade-off、scale/stop criteria、accountability Decision memo review 每年
6.3 AI Literacy Control Evidence
Evidence 内容 审计价值 Training roster 谁完成了什么课程, 对应哪个系统权限 证明部署方已进行角色化培训 Scenario test result 高风险任务的情景判断题成绩 证明不是只看视频打卡 Usage policy acknowledgement 用户确认理解禁止用法和升级条件 支撑责任边界 Manager coaching log 经理如何复盘错误使用和优秀案例 证明采用不是一次性培训 Exception review log 用户 override、升级、误用案例 连接 human oversight 与 EvalOps Recertification record 高风险岗位周期复训 应对模型/政策/流程变化
7. Stakeholder Segmentation
7.1 不要把“用户”当成一个群体
AI adoption 的 stakeholder 不是简单的 end user。金融零售环境中, 一个 AI 用例会影响流程 owner、风险 owner、IT owner、模型 owner、一线员工、客户、审计、工会/员工代表、外包供应商。
Segment 关心什么 可能阻力 Adoption 策略 Executive sponsor 价值、风险、速度、声誉 看不到真实收益 用 benefit register + risk dashboard 汇报 Business owner KPI、流程稳定、资源 担心上线影响运营 让其拥有 target behavior 和 benefit Middle manager 排班、质量、绩效、团队士气 担心指标失控或岗位被削 设计 manager cadence 和团队激励 Power user 效率、专业判断、话语权 担心 AI 降低专业价值 让其成为 champion 和场景训练者 Skeptical expert 准确性、边界、专业尊严 抓住错误证明系统不可信 邀请参与 eval set 和红队测试 Casual user 简单、省事、少出错 不愿改变习惯 嵌入工作流, 减少额外点击 Risk/compliance 控制、证据、客户权益 担心黑箱和误用 提供 control map、日志、升级路径 IT/architecture 安全、集成、可维护 担心 shadow AI 和工具泛滥 走 reference architecture 与平台能力 HR/L&D 能力建设、岗位变化 课程泛化、难以评估 采用 role-based curriculum Customer 公平、隐私、解释、体验 不信任机器决策 明确人工复核、解释和申诉机制
7.2 Adoption Persona
Persona 典型角色 成功定义 设计重点 Decision confirmer 信贷审批复核、投诉分类主管 更快做出更一致的判断 evidence, confidence, override Work drafter 客服、理财经理、运营文案 更快生成初稿但保留人工把关 policy grounding, tone guardrail Exception handler 二线支持、合规复核 快速识别复杂或高风险案例 escalation, audit trail Workflow orchestrator 运营经理、网点主管 看见瓶颈和资源分配建议 dashboard, queue integration Control owner 风险、合规、审计 证明 AI 使用受控 logs, control evidence, incident Value owner 业务负责人、财务伙伴 证明收益真实可归因 baseline, benefit model
7.3 Stakeholder Map Template
Stakeholder Current pain Desired behavior Perceived loss Perceived gain Influence Support level Engagement action 网点主管 新员工培训慢, 产品规则问答多 用 AI 辅助答疑并抽查 担心员工照抄错误答案 培训时间缩短 5 3 邀请参与训练题和每周复盘 资深柜员 熟悉规则, 是团队咨询对象 贡献边界案例并做 champion 专业权威被削弱 成为 AI coach 4 2 给其审核权、署名知识资产 合规经理 担心误导客户 审核高风险回答策略 承担监管解释压力 控制证据更完整 5 3 提供日志、禁止话术和抽样报告
8. Workflow Redesign
8.1 工作流重设计不是画一张 TO-BE 图
AI workflow redesign 必须同时回答六个问题:
AI 在哪个流程节点介入?
AI 读取哪些数据, 输出到哪里?
人类在什么时候确认、修改、拒绝或升级?
哪些情况必须禁止自动化?
如何留痕、审计、回滚?
输出错误时如何进入反馈和改进?
8.2 AS-IS / TO-BE 对照
维度 AS-IS TO-BE with AI 设计检查 Trigger 用户手工打开多个系统 任务进入队列自动触发 AI 建议 是否可追踪触发条件 Input 人工复制客户资料和历史记录 系统按权限拉取必要上下文 是否最小必要、可审计 AI action 无 分类、摘要、建议、初稿、异常标记 是否限定用途 Human action 全量阅读并手工判断 复核 AI 证据, 确认/修改/拒绝 是否保留 human oversight Exception 靠经验升级 系统按规则提示升级 是否覆盖敏感客群、投诉、欺诈、合规 Record 结果字段 + 少量备注 AI 输出、引用、人工修改、理由、时间戳 是否支持审计 Feedback 口头反馈或群消息 结构化反馈进入 backlog/eval 是否形成闭环
8.3 Human-in-the-Loop Pattern
Pattern 适用场景 人类职责 风险 Draft and approve 客服回复、营销文案、需求初稿 检查事实、语气、合规边界后发送 人类变成橡皮章 Recommend and decide 信贷补件建议、理财产品匹配 参考建议, 独立做决定并记录理由 自动化偏见 Triage and escalate 投诉分类、欺诈预警 确认分类, 升级高风险案例 错误分类导致 SLA 失守 Monitor and intervene 运营队列、异常交易监控 监控阈值, 干预异常 警报疲劳 Assist and document BA 访谈摘要、架构审查纪要 核对上下文, 形成记录 幻觉进入正式文档
8.4 Workflow Redesign Checklist
检查项 通过标准 任务边界 每个 AI action 都能映射到具体业务任务, 不用“助手”这类泛化描述 数据边界 输入字段、来源、权限、保留时间明确 决策边界 哪些输出只是建议, 哪些能自动执行, 哪些必须人工确认 例外路径 客户投诉、弱势客群、资金损失、监管敏感、模型低置信度都有升级路径 留痕 原始输入、AI 输出、人工修改、最终决定、责任人、时间戳可追踪 运营 日常监控、抽样 QA、incident handling、support escalation 有 owner 反馈 反馈能进入 EvalOps, 而不是停留在聊天群 收益 TO-BE 流程能改变 baseline 指标, 不是只增加一个工具
9. Role Redesign
9.1 AI 不只是替代任务, 而是重组岗位
角色重设计的关键是区分:
类型 含义 管理动作 Automatable task 可被系统稳定完成的重复任务 自动化并监控质量 Augmented task AI 提供建议, 人类判断 设计 oversight、training、override Human premium task 需要同理心、谈判、复杂判断、责任承担 强化岗位价值和培训 New task AI 引入后新增的任务 明确 owner, 纳入工时和绩效
9.2 Role Impact Assessment
角色 被 AI 改变的任务 新增职责 风险 Role redesign 方向 客服坐席 FAQ 查询、工单摘要、回复初稿 检查 AI 答案、标记错误、处理敏感升级 照抄错误答案 从信息检索者转为客户问题解决者 网点理财经理 产品资料查询、客户沟通初稿 检查适当性、解释风险、记录客户偏好 误导销售 从产品介绍者转为需求诊断和信任经营者 信贷分析师 材料摘要、风险提示、补件建议 复核证据、判断例外、记录 override 自动化偏见 从资料整理者转为风险判断者 运营主管 队列分配、异常识别 调整人力、复盘瓶颈、coach 团队 只看产能不看质量 从排班管理者转为人机流程管理者 BA 访谈摘要、流程草图、需求初稿 设计 AI-assisted workflow、定义 acceptance/eval criteria 把 AI 输出当需求事实 从需求记录者转为问题建模和证据设计者 PM 功能 backlog、用户故事初稿 管 adoption、risk、benefit、feedback loop 只追求功能上线 从 feature owner 转为 behavior/value owner Architect 架构草案、模式检索 设计可审计、可回滚、可观测 AI 系统 POC 架构直上生产 从 solution designer 转为 AI control system designer
9.3 Job Redesign Canvas
项 问题 Role purpose AI 介入后, 这个岗位存在的核心价值是什么 Tasks removed 哪些任务减少或消失 Tasks augmented 哪些任务变成人机协作 Tasks added 哪些新任务必须被承认并分配时间 Decision rights 哪些决定仍由人做, 哪些由系统建议 Accountability 出错时岗位需要承担什么责任, 不承担什么责任 Skills 需要新增哪些 AI literacy、数据、流程、风险能力 Metrics 绩效如何从“处理量”转向“质量 + 采用 + 判断” Career path 资深员工如何升级为 champion、trainer、QA、process owner
9.4 常见岗位焦虑与回应
焦虑 不好的回应 更好的回应 AI 会不会替代我 “不会, 放心” “重复检索和初稿会减少, 但客户判断、例外处理、合规解释、关系经营会变得更重要; 我们会把这些纳入岗位和绩效。” 出错算谁的 “系统只是辅助” “最终决定权、复核要求、升级路径和日志责任会写入流程; 你不需要为系统未知错误背锅, 但需要按流程核查和反馈。” 我为什么要教 AI “这是公司要求” “你贡献的边界案例会变成知识资产, 并影响 champion 资格、培训角色和绩效认可。” AI 让工作更复杂 “熟悉就好了” “我们会移除重复录入, 把反馈入口嵌进系统, 并用净节省时间而不是使用次数衡量。”
10. Change Strategy
10.1 Change Narrative
AI adoption 的叙事不能只说效率。金融零售员工更关心客户信任、风险责任和岗位价值。
错误叙事 风险 推荐叙事 “AI 将大幅降低人力成本” 触发防御和抵抗 “AI 把重复检索、整理、初稿交给系统, 让人把时间放到判断、客户沟通和例外处理。” “模型准确率很高, 大家放心用” 过度承诺 “系统在已定义场景中表现达标, 但特定条件必须人工复核和升级。” “所有团队都要尽快用起来” 盲目扩张 “先在高痛点、低到中风险、流程 owner 明确的场景建立可复制模式。” “培训后就上线” 忽视行为改变 “培训、经理复盘、支持、指标和反馈闭环一起上线。”
10.2 Change Readiness Assessment
维度 1 分 3 分 5 分 Sponsor ownership 只有口头支持 参与 gate, 但不管 adoption 拥有 target behavior 和 benefit Manager readiness 未参与设计 知道工具, 但无管理动作 有 huddle、coaching、QA 节奏 Workflow fit 工具独立存在 半集成, 仍需复制粘贴 嵌入核心工作流并留痕 Literacy 通用 AI 培训 基于角色培训 情景认证 + 复训 + 授权 Support 群里问问题 有 FAQ 和联系人 L1/L2/L3 + SLA + issue taxonomy Incentive 指标不变 增加使用要求 指标同时看采用、质量、收益、风险 Trust 用户只能看答案 有解释和置信度 有证据、引用、override、反馈 Risk controls 事后补控制 基本权限和日志 风险分层、升级、incident、monitoring
10.3 Rollout Pattern
模式 适用情况 优点 风险控制 Champion-led pilot 专家多、流程复杂 快速发现边界案例 champion 不能代表普通用户, 需第二波验证 Cohort rollout 大量同类用户 易培训、易比较 每批次设置 stop/go gate Shadow mode 高风险决策 不影响真实客户 需要比较 AI 建议与人工结果 Assistive mode first 需要建立信任 降低抵抗 明确何时可提升自动化 Site-by-site rollout 网点/区域差异大 易吸收本地差异 防止每个区域变成不同产品
11. Incentive Design
11.1 不要奖励“使用次数”
只奖励使用次数会导致低质量点击、形式主义和误用。AI adoption 的激励要同时看使用、质量、风险和收益。
指标类型 好指标 坏指标 Usage eligible task adoption rate、repeat use、active teams 总登录次数、总 prompt 数 Quality first-pass quality、override reason quality、QA pass rate 输出生成数量 Risk policy violation rate、unsafe input rate、escalation compliance 零升级率 Learning feedback submitted、accepted improvement cases、scenario test pass 培训完成截图 Benefit cycle time reduction、rework reduction、SLA improvement 未经核实的节省小时
11.2 Incentive by Role
角色 激励信号 防止副作用 一线员工 正确使用率、优质反馈、低返工、高客户满意 不把 AI 使用作为单一硬指标 资深专家 边界案例贡献、训练材料贡献、champion coaching 不让专家只承担额外工作无认可 中层经理 团队 adoption + QA + benefit + incident 不鼓励压低升级数量 PM/BA adopted value、workflow impact、feedback closure 不只奖励上线功能 Architect reuse、observability、control effectiveness、cost-to-serve 不只奖励新技术复杂度 Risk/Compliance 控制前置、事件减少、可审计性 不把所有风险变成禁止
11.3 Recognition Mechanisms
机制 设计 Champion badge 与真实贡献绑定: 培训、案例、QA、反馈闭环 Case contribution credit 被纳入 eval set 或培训案例的员工得到记录 Team adoption review 每月表彰“高质量采用”而不是最高使用量 Career path 从 power user 到 AI process coach、AI QA lead、knowledge owner Manager scorecard 加入团队 AI literacy、采用质量、收益达成、风险事件
12. Training Curriculum
12.1 课程分层
Level 对象 目标 时长 认证方式 L0 AI Awareness 全员 理解 AI 机会、风险、公司政策 45-60 分钟 小测 L1 Safe User 所有使用者 会在授权场景中安全使用 2 小时 情景题 L2 Role Practitioner 关键岗位 会在具体流程中判断、复核、反馈 半天 案例演练 L3 Champion power user、专家 能 coaching、收集案例、参与 eval 1-2 天 实战评审 L4 Owner PM、BA、Architect、Ops、Risk 能设计 adoption、workflow、controls、metrics 2-3 天 Use case pack L5 Executive 高管、业务负责人 能做 funding、risk acceptance、scale/stop 90 分钟 Decision simulation
12.2 L1 Safe User Curriculum
模块 内容 金融零售练习 AI 基础 概率性输出、幻觉、上下文窗口、数据限制 判断 5 个 AI 回答中哪些不能直接给客户 公司政策 授权工具、禁止工具、禁止输入、客户数据规则 识别哪些字段不能输入外部工具 场景边界 允许、谨慎、禁止用法 将 20 个任务分为 allow / caution / prohibit 输出核查 引用、事实、政策、数字、客户影响 核查理财产品介绍初稿 升级路径 低置信度、敏感客户、投诉、资金损失 选择正确 escalation route 反馈提交 如何报告错误、缺失知识、流程阻力 提交结构化 issue
12.3 L4 Owner Curriculum
模块 PM 重点 BA 重点 Architect 重点 Use case framing Value hypothesis、adoption target Problem statement、baseline Feasibility and integration boundary Workflow redesign Target behavior、UX friction AS-IS/TO-BE、exceptions Event flow、audit/logging EvalOps Product acceptance + eval criteria Scenario set and edge cases Test harness, monitoring, release gate Risk control Risk-tiered product policy Control procedures Access, data flow, fallback, observability Change management Stakeholder plan、incentive Role impact、training scenarios Supportability, runbook Benefit realization Adoption-adjusted ROI Baseline measurement Cost-to-serve and scalability
12.4 Scenario-Based Exam Examples
场景 问题 合格答案特征 客服回复 AI 生成“我们承诺 3 天内赔付” 识别未授权承诺, 改为按政策说明并升级 信贷分析 AI 建议拒绝某客户, 理由含模糊职业推断 要求可解释证据, 检查敏感代理变量, 人工复核 营销文案 AI 生成“稳赚不赔” 识别误导性宣传, 改为风险披露和合规话术 投诉分类 AI 将监管投诉归为普通咨询 根据关键词和客户影响升级二线 内部知识问答 AI 引用旧政策 检查版本日期, 反馈知识库过期
13. Enablement Assets
13.1 最小可用 Enablement Pack
Asset 内容 Owner One-page usage policy 允许/禁止/谨慎用法、数据输入规则、责任边界 Risk + PM Role quick guide 每个岗位如何用、何时不用、如何升级 BA + Ops Scenario library 真实业务情景、好答案、坏答案、解释 BA + QA Prompt patterns 经过审核的任务模板和示例 PM + Champion Output checklist 事实、政策、数字、客户承诺、敏感信息核查 Risk + Ops Feedback form 错误类型、任务、输入摘要、期望输出、影响 EvalOps + PM Manager huddle guide 每周复盘问题、指标、案例 Change Lead Support FAQ 常见问题、已知限制、修复状态 Support + Product Go-live pack 上线时间、范围、权限、支持、回滚 PM + Architect Benefits tracker baseline、target、actual、adoption adjustment PM + Finance
13.2 Usage Policy 示例
类别 规则 可以使用 摘要内部知识、生成客服回复初稿、提取投诉要点、草拟需求访谈纪要 谨慎使用 涉及客户权益、价格、授信、投资建议、投诉处理、监管解释的任务 禁止使用 自动批准/拒绝客户申请、未经批准输入敏感个人数据到外部工具、让 AI 绕过政策、生成虚假承诺 必须人工复核 客户可见内容、影响客户权益的建议、高风险投诉、低置信度输出 必须升级 涉及监管投诉、潜在资金损失、欺诈、歧视、公平性、客户威胁自伤或他伤等敏感情况
13.3 Manager Huddle Guide
问题 目的 本周哪些任务最适合用 AI, 哪些不适合 强化场景边界 哪个 AI 输出最有帮助, 为什么 传播好实践 哪个 AI 输出需要纠正, 如何发现的 建立健康怀疑 哪些流程仍然浪费时间 发现 workflow backlog 哪些反馈已经被采纳 让用户看到反馈价值 本周是否有 policy violation 或 near miss 提前处理风险
14. Resistance Patterns
14.1 抵抗不是坏事, 它是系统反馈
抵抗常常暴露 adoption design 的缺陷。不要把所有反对者贴上“不拥抱变化”的标签。
Resistance pattern 表现 真实信号 处理方式 Passive non-use 培训完成但不用 工具没嵌入工作流或收益不明显 观察任务现场, 去掉摩擦 Expert skepticism 专家不断指出错误 eval set 缺边界案例 邀请专家参与红队和 QA Manager silence 经理不反对也不推动 激励和管理节奏未改变 给经理 scorecard 和 huddle guide Compliance freeze 风险团队要求无限审查 风险分层和控制证据不足 建 control map 和 limited release Workaround 用户复制到未授权工具 官方工具慢、不好用或限制过死 分析 shadow AI 原因, 改 UX 和 policy Overuse 用户所有事情都问 AI literacy 不足, 误以为越用越好 明确 prohibited use 和 QA 抽样 Fear of replacement 员工公开或私下反对 role redesign 缺失 讲清岗位价值、技能路径和激励 Data anxiety 不敢输入任何信息 数据规则不清 提供字段级 allow/caution/prohibit
14.2 Resistance Response Playbook
信号 诊断问题 介入动作 成功证据 adoption < 30% 是不知道、不能用、还是不愿用 用户访谈 + task observation 阻力分类清楚 override 很高 AI 质量差还是用户不信任 抽样 override reason 错误类型进入 eval feedback 少 用户懒还是反馈无回音 简化反馈入口 + 发布修复日志 feedback volume 和质量上升 风险事件多 培训差还是控制差 事件复盘 + 权限/流程调整 violation rate 下降 经理不看 dashboard 指标无用还是无责任 修改管理节奏和责任 huddle 记录稳定
15. Adoption Metrics
15.1 四层指标
层级 指标 解释 Adoption eligible task adoption rate、weekly active users、repeat use、cohort retention 是否真正被用于目标任务 Quality QA pass rate、first-pass acceptance、override rate、rework rate、hallucination rate 用得是否正确 Risk policy violation、unsafe input、missed escalation、incident、customer complaint 是否安全可控 Value cycle time、cost per case、SLA、conversion、NPS、loss reduction、risk avoidance 是否产生可确认收益
15.2 指标定义表
Metric 定义 频率 Owner 注意事项 Eligible task adoption rate 目标任务中使用 AI 的比例 周 PM + Ops 分母必须是适用任务, 不是所有任务 Assisted completion rate 使用 AI 后完成任务的比例 周 PM 不能单独代表质量 First-pass acceptance AI 初稿被少量修改后采纳的比例 周 QA 需定义“少量修改” Override rate 人工拒绝或大幅修改 AI 建议的比例 周 BA + EvalOps 高 override 不一定坏, 要看原因 Escalation compliance 应升级案例中正确升级的比例 周 Risk + Ops 高风险场景核心指标 Feedback closure time 用户反馈到处理结论的时间 周 Product + EvalOps 防止反馈黑洞 Net time saved 旧流程时间减新流程总时间 月 Finance + PM 包含核查、反馈、返工 Adoption-adjusted benefit 理论收益 × 合格采用率 × 质量系数 月 Value Office 用于 scale/stop
15.3 Adoption Dashboard
Section 关键问题 指标 Reach 谁可以用、谁真的用 licensed users、trained users、active users Task fit 用在正确任务上吗 eligible task adoption、prohibited use Quality 输出是否可用 acceptance、override、QA pass Safety 是否按规则使用 unsafe input、missed escalation、incident Learning 反馈是否转化为改进 feedback count、closure、eval updates Benefit 是否产生收益 cycle time、rework、SLA、cost、revenue Equity/Fairness 是否影响特定客群 segment-level error、complaint、appeal
16. Support Model
16.1 AI Support 不能只靠产品群
AI 支持需要处理工具问题、流程问题、模型质量问题、政策问题和风险事件。单一 IT helpdesk 不够。
Tier 处理内容 Owner SLA 示例 L0 Self-service FAQ、快速指南、已知限制、培训材料 Product + L&D 即时 L1 Business support 如何使用、流程问题、普通错误反馈 Champion + Ops support 1 个工作日 L2 Product/EvalOps 输出质量、知识缺失、prompt、eval failure PM + EvalOps 2-5 个工作日 L3 Technical/platform 权限、集成、日志、性能、系统故障 Platform + Architect 按 incident severity L4 Risk/Compliance policy violation、客户影响、监管敏感 Risk + Legal + Business owner 立即升级
16.2 Issue Taxonomy
Issue type 示例 路由 UX friction 用户需要复制粘贴三次 Product backlog Workflow gap AI 输出无法写入核心系统 BA + Architect Knowledge gap 回答引用旧政策 Knowledge owner + EvalOps Model quality 摘要遗漏关键事实 EvalOps Policy ambiguity 不知道某字段能否输入 Risk + Data privacy Misuse 用户让 AI 给客户承诺收益 Manager + Risk Incident 错误输出已影响客户权益 Incident response Benefit gap 用了但没省时间 PM + BA + Finance
16.3 Known Limitations Register
Limitation Impact User guidance Owner Review date 不能保证识别所有监管投诉 可能误分类高风险投诉 包含监管、媒体、律师、银保监等关键词时必须人工复核 Risk + EvalOps 每月 产品政策库有 T+1 更新延迟 可能引用非最新规则 高风险客户承诺前必须核对政策系统 Knowledge owner 每周 对方言语音转写准确率波动 摘要可能遗漏事实 低置信转写必须听录音 Ops QA 每月
17. Benefit Realization Connection
17.1 Adoption 连接 Value Office
在 AI_TRANSFORMATION_VALUE_OFFICE_PLAYBOOK 中, benefit realization 需要 baseline、target、actual、finance sign-off。AI adoption 是连接模型能力与财务收益的中间层。
Model capability -> Workflow change -> User adoption -> Quality-controlled use -> Business outcome -> Finance-recognized benefit
如果 adoption 不达标, 理论 ROI 不能进入 scale decision。
17.2 Benefits Register 扩展字段
Field 定义 示例 Baseline metric AI 前的业务基线 平均投诉首次分派 18 分钟 Target behavior 用户需要改变的行为 主管先用 AI 分类建议并确认 Adoption rate 适用任务采用比例 72% Quality coefficient 合格采用比例或 QA 调整因子 0.86 Realized benefit 实际收益 18 分钟降至 9 分钟, 返工率未上升 Finance sign-off 财务是否认可 认可运营工时节省, 暂不认可 FTE reduction Risk adjustment 风险/事件对收益的扣减 1 次 near miss, 加强升级规则 Scale decision 下一步 扩展至 3 个区域, 保持人工确认
17.3 Adoption-Adjusted ROI
Adoption-adjusted benefit =
theoretical gross benefit
× eligible task adoption rate
× quality coefficient
× risk adjustment factor
- incremental run cost
- training and support cost
- process change cost
项 解释 theoretical gross benefit POC/business case 中估算的最大收益 eligible task adoption rate 真正适用任务中的采用比例 quality coefficient 质量、返工、人工复核后的折减 risk adjustment factor 事件、投诉、控制缺陷导致的折减 run cost 模型、平台、监控、人工支持成本 training/support/process cost 组织采用的真实成本
18. Feedback Loop Into EvalOps
18.1 Adoption Feedback 不是普通用户反馈
AI adoption feedback 应该被结构化为 eval、data、prompt、workflow、policy、training、UX 七类。
Feedback type 用户语言 EvalOps 转化 Wrong answer “这个答案错了” 加入失败样本, 标注 expected answer Missing context “它不知道我们分行的规则” 检查 retrieval source 和 metadata filter Bad reasoning “结论对, 理由不对” 增加 rationale eval Unsafe output “它建议我这么承诺客户” 加入 safety eval 和 policy guardrail Workflow friction “我要复制到另一个系统” 进入 workflow/integration backlog Ambiguous policy “我不知道能不能用” 更新 usage policy 和 training Training gap “新员工不会判断” 增加情景演练
18.2 EvalOps Loop
Step 输入 动作 输出 Capture 用户反馈、QA 抽样、incident、override 结构化分类 Feedback record Triage 影响范围、风险等级、频率 决定处理路径 Product / Eval / Risk / Training ticket Convert 典型案例 转成 eval item、policy example、training scenario Updated test set Fix prompt、retrieval、model、workflow、policy 实施修复 Release candidate Validate regression eval、business QA、risk review 验证未引入新问题 Eval report Communicate 修复内容、限制、用户动作 发布变更说明 Trust reinforcement Monitor 相关指标 看问题是否下降 Adoption review
18.3 Feedback Severity
Severity 定义 处理 S0 Incident 已影响客户权益、资金、监管义务或重大声誉 立即停用相关能力或降级, 启动 incident S1 High risk near miss 若未被人工发现会造成客户/合规影响 24 小时内 triage, 加 guardrail 或升级规则 S2 Quality degradation 影响任务效率或返工, 暂未造成客户影响 进入 eval/product backlog S3 Usability issue 增加摩擦但不影响安全 产品优化 S4 Learning request 用户不理解如何使用 培训和 enablement 更新
19. Templates
19.1 Adoption Plan Template
# AI Adoption Plan
## 1. Use Case
- Name:
- Business owner:
- Target workflow:
- Target users:
- Risk tier:
## 2. Target Behavior
- Current behavior:
- Desired behavior:
- Moment of use:
- Human decision retained:
- Prohibited use:
## 3. Stakeholders
| Stakeholder | Pain | Desired behavior | Resistance | Engagement |
|---|---|---|---|---|
## 4. Workflow
- AS-IS summary:
- TO-BE summary:
- AI input:
- AI output:
- Human confirmation:
- Exception path:
- Audit trail:
## 5. Role Redesign
| Role | Tasks removed | Tasks augmented | Tasks added | New skills | Metrics |
|---|---|---|---|---|---|
## 6. AI Literacy
- Required training level:
- Scenario exam:
- Authorization rule:
- Recertification:
## 7. Enablement
- Quick guide:
- Scenario library:
- Manager huddle:
- Feedback channel:
- Support model:
## 8. Metrics
| Metric | Baseline | Target | Owner | Review cadence |
|---|---:|---:|---|---|
## 9. Feedback to EvalOps
- Feedback taxonomy:
- Severity route:
- Eval update cadence:
## 10. Benefit Realization
- Baseline:
- Adoption-adjusted benefit formula:
- Finance sign-off owner:
- Scale/stop criteria:
19.2 AI Literacy Policy Template
# AI Literacy Policy
## Purpose
确保所有参与 AI 系统开发、运营、使用、监督或受其影响的关键人员, 具备与其角色、经验、任务风险和使用场景相匹配的 AI literacy。
## Role-Based Requirement
| Role | Minimum level | Training | Exam | Authorization |
|---|---|---|---|---|
## Covered Topics
- AI system purpose and limits
- Data handling and prohibited inputs
- Output verification
- Human oversight and escalation
- Customer impact and fairness
- Incident and feedback process
## Evidence
- Training roster
- Scenario test result
- Policy acknowledgement
- Recertification record
- Exception and incident learning
19.3 Role Redesign Workshop Template
Step 问题 输出 Task inventory 岗位一周内实际做哪些任务 Task list AI impact mapping 哪些任务自动化、增强、保留、新增 Impact matrix Decision rights 哪些决定归人、AI、经理、审批人 Decision map Accountability 出错时谁负责什么 Responsibility statement Skill gap 新角色需要哪些技能 Training plan Metric redesign 旧 KPI 是否会阻碍新行为 New scorecard Career path 资深员工如何升级 Champion / QA / coach path
19.4 Resistance Interview Guide
问题 想发现什么 你在哪个具体任务中最不愿使用 AI 找到任务级阻力 如果不用它, 你现在怎么完成任务 识别替代路径 你最担心哪类错误 发现 trust requirement 哪个步骤让你觉得更麻烦 发现 workflow friction 出错时你认为责任是谁的 发现 accountability gap 哪个功能改变会让你愿意再试 找 adoption backlog 你愿意贡献什么边界案例 找 champion 或 skeptical expert
19.5 Scale Readiness Checklist
Gate 通过标准 Adoption 目标任务合格采用率达到预设阈值, 且普通用户 cohort 不低于 champion cohort 太多 Quality QA pass、override reason、返工率达标 Risk 无未关闭高风险事件, 升级路径有效 Literacy 目标用户完成角色化培训和情景认证 Support L1/L2/L3 支持运行稳定, FAQ 和 known limitations 更新 Benefit 财务认可 adoption-adjusted benefit 或明确下一阶段验证方式 Architecture 日志、权限、监控、成本、回滚、容量准备完成 Change 经理 cadence、激励、role redesign 已落地
20. Financial Retail Scenarios
20.1 客服知识助手
维度 设计 Target behavior 坐席用 AI 查找政策和生成回复初稿, 但客户可见内容必须人工确认 AI literacy 禁止虚构承诺, 必须核对产品条款和版本日期 Workflow 嵌入 CRM/工单, 自动带入客户问题和产品类型 Controls 高风险关键词触发升级; 输出引用知识库段落 Metrics AHT、first contact resolution、QA pass、投诉升级、unsafe answer Role redesign 坐席从知识检索转向问题解决和情绪处理
20.2 投诉分类与监管敏感识别
维度 设计 Target behavior 投诉进入队列后 AI 给出分类、严重性、建议 SLA 和升级理由 AI literacy 用户必须理解监管投诉、资金损失、媒体曝光等升级条件 Workflow AI 分类写入工单草稿, 人工确认后生效 Controls 低置信度和敏感词强制二线复核 Metrics 首次分派时间、误分类率、SLA breach、监管投诉漏识别 Role redesign 主管从手工分派转向例外判断和质量管理
20.3 信贷材料预审
维度 设计 Target behavior 分析师使用 AI 摘要材料、提示缺失文件、列出风险点 AI literacy AI 不得直接做批准/拒绝结论; 注意敏感变量和代理歧视 Workflow 与 LOS/文档管理系统集成, 输出补件建议和证据引用 Controls 人工记录最终判断和 override reason Metrics 材料完整率、补件轮次、审批周期、QA finding、fairness review Role redesign 分析师从资料整理转为风险解释和例外判断
20.4 理财销售辅助
维度 设计 Target behavior 理财经理用 AI 准备客户沟通提纲, 但产品适当性和风险揭示必须人工确认 AI literacy 禁止收益承诺、夸大宣传、忽略风险等级 Workflow 读取已授权客户画像和产品资料, 生成谈话准备而非自动推荐 Controls 合规话术检查、风险揭示 checklist、客户确认留痕 Metrics 合规抽检、客户投诉、转化率、适当性缺陷 Role redesign 理财经理从产品推介转向需求诊断、风险沟通和关系经营
20.5 反欺诈运营
维度 设计 Target behavior 运营人员用 AI 汇总警报上下文、建议调查步骤 AI literacy 区分可疑信号和事实结论; 不得仅凭 AI 关闭或冻结账户 Workflow 与 case management、交易监控、客户联系记录集成 Controls 高金额、高脆弱客户、跨境异常强制升级 Metrics true positive、false positive、investigation time、customer harm、appeal Role redesign 调查员从信息收集转为证据判断和客户影响权衡
20.6 BA / PM / Architect 内部提效
维度 设计 Target behavior 用 AI 生成访谈摘要、需求初稿、架构选项, 但正式文档必须人工核查 AI literacy 不把 AI 输出当事实; 不输入未授权客户数据或机密信息 Workflow 连接文档库、需求系统、架构评审流程 Controls 引用来源、版本、review log Metrics 需求返工率、评审缺陷、cycle time、stakeholder satisfaction Role redesign BA/PM/Architect 从文档生产转向问题定义、决策设计和证据管理
21. PM / BA / Architect 职责
21.1 AI PM
职责 具体动作 产物 Adoption as product 定义目标行为、用户旅程、信任机制、采用指标 Adoption canvas Value ownership 把采用、质量、风险与收益连接 Benefits model Backlog management 平衡功能、workflow、training、support、eval Adoption backlog Stakeholder orchestration 推动 sponsor、manager、risk、platform 对齐 Stakeholder plan Scale/stop 用证据决定扩展、收缩或停止 Scale/stop memo
21.2 AI BA
职责 具体动作 产物 Problem framing 把“做 AI”转成具体流程痛点 Problem statement Workflow redesign AS-IS/TO-BE、例外、角色、控制 Workflow pack Scenario design 收集真实任务、边界案例、培训题 Scenario library Role redesign 评估岗位任务变化和责任边界 Role impact assessment Feedback analysis 将用户反馈归类并转为需求/eval Feedback taxonomy
21.3 AI Architect
职责 具体动作 产物 Integration design 数据流、系统流、权限、日志、审计 Architecture diagram Control by design fallback、human oversight、monitoring、rate limit Control map Operability runbook、SLA、support tier、incident response Ops runbook Scalability 成本、容量、复用、平台能力 Scale architecture EvalOps enablement 反馈采集、测试集、监控指标、release gate EvalOps integration
21.4 三者协作界面
问题 PM BA Architect 用户为什么会用 定义价值和动机 发现任务痛点 降低技术摩擦 怎么嵌入流程 排优先级 设计流程 设计集成 如何安全使用 定义产品政策 设计人工步骤 设计技术控制 如何证明收益 定义指标和决策 建 baseline 提供数据和日志 如何持续改进 管 backlog 分析反馈 支撑 EvalOps
22. 30-Day AI Adoption Lab
22.1 目标
30 天内不追求大规模上线, 而是完成一个金融零售 AI 用例的 adoption design、pilot、反馈闭环和 scale/stop 证据包。
22.2 Day-by-Day Plan
Day 主题 产出 1 选择用例和业务 owner Use case charter 2 明确 baseline 和 target behavior Baseline note 3 Stakeholder segmentation Stakeholder map 4 用户现场观察或访谈 Pain point log 5 AS-IS workflow AS-IS diagram 6 TO-BE workflow with AI TO-BE diagram 7 Role impact assessment Role redesign draft 8 Risk tier and usage policy Usage policy v1 9 AI literacy needs Training matrix 10 Scenario library draft 10-15 scenarios 11 Metrics design Adoption dashboard spec 12 Support model L1/L2/L3 routing 13 Feedback taxonomy Feedback form 14 Pilot cohort selection Pilot plan 15 Training delivery Training roster 16 Pilot launch Go-live checklist 17 Daily huddle 1 Issue log 18 Daily huddle 2 Updated FAQ 19 QA sampling QA findings 20 Feedback triage EvalOps tickets 21 Manager coaching Huddle notes 22 Resistance interviews Resistance report 23 Workflow fixes Backlog update 24 Training refresh Scenario update 25 Metrics review Adoption dashboard v1 26 Benefit calculation Adoption-adjusted benefit 27 Risk review Control evidence 28 Scale readiness Scale checklist 29 Scale/stop memo Decision memo 30 Executive readout Adoption lab pack
22.3 Lab Deliverables
Deliverable 合格标准 Use case charter 有业务 owner、目标流程、风险等级、成功指标 Adoption canvas 目标行为、moment of use、trust requirement 清楚 Workflow pack AS-IS、TO-BE、exception、audit trail 完整 Role redesign 任务变化、责任边界、新技能、新指标明确 Training pack 角色化课程和情景题完成 Support pack 支持层级、FAQ、issue taxonomy、SLA 明确 EvalOps feedback 至少 10 个反馈转为 eval/training/product ticket Benefit memo 计算 adoption-adjusted benefit Scale/stop memo 用证据提出下一步
23. Interview Answers
23.1 为什么很多 AI POC 成功后无法规模化?
30 秒版本
因为 POC 通常只证明模型或 demo 可行, 没有证明真实工作流、角色责任、用户采用、风险控制和收益归因可行。AI 规模化失败通常不是单点技术问题, 而是产品、系统和组织问题。
2 分钟版本
我会从六个方面解释。第一, POC 的样本和场景通常被简化, 没有覆盖长尾异常和真实数据权限。第二, AI 没有嵌入核心流程, 用户还要复制粘贴、核查和补录, 净收益消失。第三, 人机责任没有定义, 一线会担心“出错算谁的”。第四, AI literacy 不足, 用户要么过度信任, 要么完全不敢用。第五, 中层经理的 KPI 和管理节奏没有变化, adoption 没有人负责。第六, 收益没有 baseline、adoption rate、quality coefficient 和 finance sign-off, 所以 scale gate 过不了。
我的做法是把 POC 后的 scale gate 改成证据驱动: adoption evidence、quality evidence、workflow evidence、risk evidence、literacy evidence 和 benefit evidence 都要达标。
23.2 如何设计企业 AI adoption plan?
30 秒版本
我会先定义目标行为和流程节点, 再做 stakeholder segmentation、workflow redesign、role redesign、AI literacy、support model、adoption metrics, 最后把反馈接入 EvalOps 和 benefit realization。
2 分钟版本
第一步不是写培训计划, 而是定义 adoption as product: 谁在什么任务、什么时刻、为什么使用 AI, 使用后行为如何改变。第二步画 AS-IS/TO-BE, 明确 AI 输入输出、人类确认、例外路径和审计留痕。第三步做角色重设计, 说明哪些任务减少、哪些增强、哪些新增, 以及责任边界。第四步按角色设计 AI literacy, 尤其是禁止用法、输出核查、客户影响和升级条件。第五步建立 L1/L2/L3 支持模型和反馈 taxonomy。第六步用 adoption、quality、risk、value 四层指标管理。最后把用户反馈转成 eval set、workflow backlog、policy update 和 training scenario。
23.3 AI literacy 在企业里应该如何落地?
30 秒版本
AI literacy 不是 prompt training, 而是让不同角色具备与其任务风险相匹配的知识、判断和责任意识。它要通过角色化培训、情景考试、使用授权、复训和控制证据落地。
2 分钟版本
我会先按角色分层: 普通用户需要理解适用场景、禁止输入、输出核查和升级路径; 高风险岗位需要掌握客户权益、偏差、公平性和 human oversight; PM/BA/Architect 需要能设计 eval、流程、控制和收益指标; 高管需要能做 scale/stop 和 risk acceptance。落地方式不是全员一门课, 而是 role-based curriculum + scenario-based exam + usage policy acknowledgement + recertification。对金融零售来说, 还要特别覆盖客户数据、投诉、授信、投资建议、反欺诈等敏感场景。
23.4 如何处理员工对 AI 的抵抗?
30 秒版本
我不会把抵抗简单看成态度问题, 而会把它当作 adoption design 的反馈。先判断是工具摩擦、质量不信任、责任不清、岗位焦虑、激励冲突还是风险政策不清, 再分别处理。
2 分钟版本
常见抵抗有几类: passive non-use 说明工具没有嵌入工作流; expert skepticism 说明 eval set 缺少边界案例; manager silence 说明中层激励和节奏没改; compliance freeze 说明控制证据不足; shadow AI 说明官方工具不好用或政策过死; fear of replacement 说明 role redesign 和职业路径没讲清。处理方式包括任务现场观察、阻力访谈、邀请专家做 champion、建立 manager huddle、优化流程集成、提供支持模型, 并把优质反馈和案例贡献纳入认可机制。
23.5 PM、BA、Architect 在 AI adoption 中分别负责什么?
30 秒版本
PM 负责 adopted value, BA 负责 workflow and role clarity, Architect 负责 controlled and operable system。三者共同把 AI 从功能上线变成可采用的业务能力。
2 分钟版本
PM 要定义目标行为、采用指标、价值假设、stakeholder plan 和 scale/stop criteria。BA 要把业务问题拆成 AS-IS/TO-BE、例外路径、角色变化、情景测试和培训案例。Architect 要设计数据流、权限、日志、监控、fallback、supportability 和 EvalOps integration。比如在投诉分类助手中, PM 关心首次分派时间和 adoption-adjusted benefit; BA 关心监管投诉例外路径和主管确认步骤; Architect 关心工单集成、日志、置信度阈值和回滚。三者缺一不可。
23.6 如何把 adoption feedback 接入 EvalOps?
30 秒版本
要把反馈结构化, 不只是收集用户意见。每条反馈应被分类为模型质量、知识缺失、policy ambiguity、workflow friction、training gap、unsafe output 等, 然后进入 eval set、产品 backlog、政策更新或培训材料。
2 分钟版本
我会建立 capture、triage、convert、fix、validate、communicate、monitor 七步闭环。用户反馈、QA 抽样、override reason 和 incident 都进入同一个 taxonomy。高风险问题进入 incident 或 release gate; 高频质量问题转成 regression eval; 知识缺失进入 RAG source 和 metadata 修复; 流程摩擦进入 workflow backlog; policy ambiguity 更新 usage policy; 培训缺口转成 scenario drill。每次修复后要发布变更说明, 让用户看到反馈有结果, 这本身会提高 adoption。
24. Quick Reference
24.1 Adoption Failure Diagnostic
症状 优先检查 培训完成但不用 目标行为、workflow fit、经理节奏 用了但收益不明显 净节省时间、返工、复制粘贴、质量折减 用户不敢用 AI literacy、责任边界、trust cue 用户乱用 policy、权限、禁止用法、QA 风险团队卡住 risk tier、control evidence、limited release Sponsor 失去兴趣 benefit register、adoption dashboard、scale/stop memo 专家持续反对 eval 边界案例、专家参与机制
24.2 采用前必须说清的十句话
这个 AI 用例服务哪个具体业务任务。
哪些人可以用, 哪些人不能用。
哪些数据可以输入, 哪些数据禁止输入。
AI 输出是什么性质: 初稿、建议、分类、警报还是决定。
哪些场景必须人工复核。
哪些场景必须升级。
出错时如何反馈和处理。
谁看 adoption、quality、risk、benefit 指标。
这个岗位因为 AI 增加和减少了哪些任务。
收益如何被财务确认, 达不到标准何时停止或调整。
25. Final Operating Principle
企业 AI adoption 的核心不是让更多人“使用 AI”, 而是让组织在可控风险下形成新的高质量工作方式。
成熟的 AI adoption 应该满足五个条件:
条件 含义 Useful 解决真实高频或高价值问题 Usable 嵌入工作流, 降低净摩擦 Trustworthy 用户知道何时信、何时查、何时升级 Governed 权限、日志、风险、培训、支持和事件处理可审计 Valuable 收益被 adoption、quality、risk 调整后仍成立
当一个 AI 用例同时满足这些条件, 它才从 POC 变成企业能力。