企业引入 AI，最容易卡住的地方往往不是模型够不够强，而是它能不能真正进入业务流程：数据从哪里来，权限怎么控，输出回到哪个系统，谁对 KPI 负责，出错时谁复核和接手。一篇整理 McKinsey 全球调查的报道指出，88% 的组织已在至少一个业务职能使用 AI，但近三分之二仍停留在实验或早期试点阶段[5]。也就是说，企业并不缺 AI 尝试，缺的是把试点变成稳定运营能力的方法。
先选流程，不要先选模型
企业 AI 的起点不应是「我们要不要上 AI」，而应是「哪个流程值得被重做」。第一批场景不一定要最大，但要足够高频、数据来源清楚、结果可衡量，并且错误能被人工复核。
适合优先导入 AI 的流程，通常有这些特征：
- 团队每天或每周都在重复处理同一类任务。
- 所需数据已经存在于文档库、CRM、ERP、工单系统、数据仓库或内部知识库中。
- 现有流程有明确痛点，例如查找时间长、复制粘贴多、回复不一致、返工率高。
- AI 输出可以被人工抽查、复核、修正，必要时能转人工处理。
- 有业务负责人愿意改流程，并对结果负责。
如果这些条件不存在，先采购工具或模型，很容易得到一次漂亮的 Demo，却很难得到可持续的运营效果。
5 步：把 PoC 做成可落地能力
1. 把需求写成可衡量的业务问题
不要把项目题目写成「导入 AI」。更好的写法是：在某个流程里，哪一类用户反复做什么事，当前卡点是什么，AI 介入后要改善哪个指标。
可以用这个句式开头：
在流程 A 中，角色 B 每周花大量时间处理任务 C；我们希望用 AI 把指标 D 从当前基准改善到目标值，并由业务负责人 E 负责流程调整与效果验收。
启动前至少要回答 5 个问题：
- 谁会每天或每周使用这个 AI 功能？
- AI 会插入哪一个工作步骤，而不是孤立存在？
- 当前基准是多少，例如处理时间、错误率、转化率、投诉率或人工工时？
- 成功 KPI 是效率、质量、收入、成本、风险，还是员工体验？
- 谁有权决定流程怎么改，并承担结果？
没有业务负责人和基准值，PoC 很难判断是否成功，也很难说服组织继续扩大。
2. 挑 1–3 个高频、重复、数据已存在的场景
第一批场景不必追求覆盖全公司，反而应该选高频、重复、数据来源明确、错误成本可控的任务。常见起手式如下：
| 候选场景 | 为什么适合先试 | 第一个 KPI 可以怎么设 |
|---|---|---|
| 客服知识检索 | 答案通常来自 FAQ、产品文档、工单记录或内部知识库 | 平均处理时间、一次解决率、抽样正确率、投诉率 |
| 内部文档问答 | 员工常花时间查制度、流程、产品或技术资料 | 查找时间、人工转问次数、答案采纳率 |
| 报表与会议摘要 | 材料格式相对固定，重复阅读需求高 | 报告产出时间、摘要采纳率、修订次数 |
| 合同或单据字段抽取 | 字段较明确，适合设计人工复核 | 字段正确率、审核时间、返工率 |
| 销售与采购流程辅助 | 可支持信息整理、比对、草拟和初步建议 | 转化率、响应时间、处理周期、人工作业节省 |
不建议一开始就挑最高风险、最复杂、责任边界最模糊的场景。如果数据散乱、流程未标准化，或合规要求很高但治理机制尚未建立，应先补数据和流程，再谈生成式 AI。
3. 在 PoC 前盘点数据、权限与系统连接
AI 落地的难点常不在模型本身，而在数据能否被安全、正确、及时地调用。Talyx 对 RAND Corporation 2024 研究的整理指出，该研究访谈了 65 位资深数据科学家与工程师，并归纳出几个常见 AI 项目失败根因：问题定义被误解、训练数据不足、技术导向而非问题导向、基础设施不足，以及问题本身超出可行范围[4]。
PoC 前至少要检查：
- 数据在哪里：文档库、CRM、ERP、工单系统、数据仓库，还是分散在个人电脑和聊天记录里？
- 数据质量如何：是否过期、重复、缺字段、格式不一致？
- 权限怎么管：不同部门、职级、地区能看到的数据是否不同？
- 更新频率如何：AI 回答的是最新版本，还是几个月前的资料？
- 系统能否连接：AI 输出是否能回到工单、CRM、报表、审批或文档流程？
- 审计是否可追溯：谁问了什么、AI 回答什么、谁采纳或修改，是否能留下记录？
如果数据不可用，模型再强也只能做展示；如果权限设计不清，项目很可能卡在信息安全、隐私、法务、合规或审计环节。
4. 做小型 PoC，但必须接入真实工作流
PoC，也就是概念验证，不应只是会议室里的演示版。更好的做法，是把 PoC 当作第一版产品：接真实用户、真实数据、真实流程，并提前定义成功、扩大和停止条件。
一个能进入运营的 PoC，至少要回答：
- 用户在哪里触发 AI：客服后台、Slack、Teams、CRM、内部门户，还是既有业务系统？
- AI 产出的内容由谁复核？哪些情况必须转人工？
- 错误怎么反馈？反馈后谁负责修数据、调规则或优化提示？
- 哪些任务只能辅助，不能自动完成？
- KPI 达到什么门槛才扩大？低于什么门槛就停止？
这一步的关键不是证明 AI 会回答，而是证明 AI 能在现有流程中被稳定使用，并让某个业务指标变好。
5. 通过治理后，再扩展到第二个部门或更高自动化
扩大 AI 不是多开几个账号。每扩到一个部门，都会遇到新的数据来源、权限规则、流程差异、合规要求和 KPI。
尤其当 AI 从查询、摘要、草拟，走向 AI agents（智能体）或更自主的 agentic AI 时，更应该循序渐进。McKinsey 2025 调查摘要显示，在任何单一职能中，报告已规模化部署 AI agents 的受访者都不超过 10%[2]。McKinsey 另指出，安全与风险是扩展 agentic AI 的首要障碍，而不准确和网络安全仍是最常被提到的 AI 风险[
8]。
更稳妥的扩展顺序是：
- 先让 AI 协助搜索、整理、摘要、草拟。
- 保留 human-in-the-loop，也就是关键环节有人复核，积累错误、例外和使用记录。
- 当正确率、流程稳定性、权限和审计机制成熟后，再自动化低风险步骤。
- 每次扩到新部门前，重新审查数据、权限、法务、合规、信息安全、隐私和审计要求。
KPI 怎么设：不要只看模型准确率
AI 项目如果只量模型准确率，很容易忽略真正的运营价值。更好的 KPI 设计，是先量当前基准，再用多层指标判断是否值得扩大。
| KPI 类型 | 可用指标 | 适合场景 |
|---|---|---|
| 效率 | 平均处理时间、周转时间、每案人工分钟、报告产出时间 | 客服、报表、单据、文档问答 |
| 质量 | 抽样正确率、人工采纳率、返工率、投诉率 | 客服回复、合同抽取、内容草拟 |
| 使用 | 周活跃用户、任务覆盖率、重复使用率、人工转问次数 | 内部助手、知识检索、部门工具 |
| 业务结果 | 转化率、响应速度、案件结案率、每案成本 | 销售、客服、采购、运营流程 |
| 风险治理 | 人工升级率、政策违规次数、敏感数据处理例外、审计缺陷 | 高风险数据、对外回复、agentic AI |
KPI 一开始不必很多，但必须和流程连在一起。如果 PoC 只能证明 AI 能生成一段文字，却不能证明流程更快、更准、更省人力或更可控，就还不能算真正落地。
为什么很多 AI 项目落不了地？
1. 先买工具，再找场景
很多项目从供应商 Demo 或模型能力出发，最后做出看起来很炫、但没人每天需要的功能。Talyx 对 RAND 研究的整理也把「技术导向而非问题导向」列为常见失败根因之一[4]。
2. 问题定义不清，导致各部门期待不同
如果业务端想降低客服工时，IT 端在优化模型准确率，管理层期待成本下降，法务又担心风险，项目就会在不同目标之间拉扯。问题定义被误解同样被列为 AI 项目失败根因之一[4]。
3. 数据和系统没有接上
AI 如果拿不到正确的文档、客户资料、工单记录或交易数据，就只能回答通用问题。即使答案不错，如果输出不能回到 CRM、ERP、文档库或工单系统，用户仍要手动复制粘贴，价值会被流程成本抵消。基础设施不足也是 Talyx 对 RAND 研究整理出的常见失败根因之一[4]。
4. PoC 没有改变真实工作方式
AI 使用率提高，不代表已经完成规模化落地。一篇整理 McKinsey 调查的报道指出，虽然 88% 的组织已在至少一个业务职能使用 AI，但近三分之二仍停在实验或早期试点阶段[5]。如果 PoC 没有进入真实流程、没有业务负责人、没有 KPI，最后往往只会停在展示阶段。
5. 风险治理太晚补
信息安全、隐私、合规、审计和权限控制如果等到上线前才处理，项目很可能被迫返工。对 agentic AI 尤其如此，因为更自主的系统通常需要更清楚的数据边界、行动权限、人工复核和责任归属；McKinsey 指出，安全与风险是扩展 agentic AI 的首要障碍[8]。
场景判断表：什么先做，什么先缓一缓？
| 可以优先做 | 建议先暂缓 |
|---|---|
| 每周或每月高频发生的重复任务 | 一年只发生少数几次的特殊任务 |
| 数据已电子化且来源明确 | 数据分散在个人文件、口头经验或非正式记录中 |
| 规则相对清楚，答案可追溯 | 问题定义不清，部门各说各话 |
| 错误可人工复核与修正 | 错误会直接造成重大合规、财务或安全后果 |
| 有业务负责人愿意改流程 | 只有 IT 或顾问推动，使用部门不投入 |
| KPI 可量化，例如时间、正确率、成本、投诉率 | 只说要创新、要 AI 化，但没有效果定义 |
落在右栏的场景不是永远不能做，而是要先补数据、标准化流程、厘清责任和治理，再导入 AI。
一页 AI 导入检查清单
启动任何 AI 项目前，可以用这 10 个问题快速检查：
- 这个场景解决的是哪个具体业务问题？
- 当前流程基准是多少，例如时间、错误率、成本或投诉率？
- 谁是业务负责人？谁能决定流程要不要改？
- 用户是否真的高频遇到这个问题？
- 所需数据是否已存在、可获取、可更新？
- 权限、隐私、法务、合规、信息安全与审计要求是否清楚？
- AI 输出会进入哪个真实系统或工作流？
- 哪些情况必须保留人工复核？
- 成功、扩大、停止的 KPI 门槛是什么？
- 如果扩到第二个部门，数据、流程与风险假设是否仍然成立？
结论：先把一个流程做成，再谈全公司 AI
企业 AI 落地要从流程改造出发，而不是从模型采购出发。模型是必要能力，但不是落地本身。真正决定项目能否从 PoC 走向运营的，是数据是否可用、权限是否清楚、流程是否愿意改变、风险是否可控，以及 KPI 是否能证明价值。
