企业AI应用落地ROI怎么算？一套可套用的测算模型

我复盘过十来个 AI 落地项目，能拿出一张说得清 ROI 的账表，不到三成。剩下的要么把收益写成“效率提升 30%”这种没人能核对的词，要么成本只算了模型调用费和服务器钱，数据准备、业务集成、运营推广一概没进表。我会要求团队把口径换成 ROI =（年化可归因收益 − 年化总拥有成本）/ 年化总拥有成本，分子分母都得换一遍。

分子里的收益拆三块：替代性人力工时，按岗位综合成本折算；决策时效带来的收入或损失规避；合规与风险成本的下降。分母里的成本拆四块：数据准备、平台与算力、场景开发与集成、运营推广。我统计过的项目里，数据准备通常占总成本的 45% 到 65%，而它恰恰是大多数测算表里被漏掉的一项。只算模型调用费，等于把最大的一块成本藏起来了。

还有一个参数比成本更致命：使用率。一个场景如果实际月活人数占目标人群不到 40%，前期投多少都很难回正。这不是模型的问题，是数据和流程没接进去。说白了，AI 的 ROI 不是算出来的，是设计出来的。下面这张表是我自己在项目启动会上必填的成本科目表，业务方和数据方一起填，谁填不出来，谁就是那个环节的风险点。

填表本身比数字更有价值。我见过太多团队在立项时对数据现状过于乐观，等到开发阶段才发现口径有七个版本，工期一拖再拖，ROI 自然算不过来。先把成本摊开，再谈收益，这个顺序不能反。

很多团队给我的 ROI 表长这样：投入等于大模型 API 费加服务器加两个算法工程师的工资；收益等于客服原来 50 人现在 30 人，省下 20 人。这个算法看着简洁，实际上有两个硬伤。

一个是分子太窄。AI 落地带来的价值里，人力替代往往只占一小部分，更多是“原来做不了的事现在能做了”。比如原来只能看月报，现在每天早上能看到异常预警；原来风控靠事后抽查，现在能事前拦截。这些收益不体现在人头数上，但它真实存在，只是没人去量化。另一个是分母太窄。数据清洗、口径对齐、系统对接、业务培训，这些钱一分不少花，却通常记在数据部门的预算里，没进 AI 项目的账。

我给客户的建议是，把成本按四类科目全口径拉平，一次算清楚：

这张表有个用法：占比只是参考，真正的信号是“某一项占比异常低”。我见过一张表里数据准备只占 8%，一问才知道，是直接把现有的报表数据当成 AI 的输入，中间没有任何口径治理。这种项目上线三个月后的典型表现是：模型答得挺顺，数字全是错的。业务方第一次对不上账，就再也不用了。

传统信息化项目的 ROI，本质上算的是“省下来”。流程线上化，减少流转环节，人力省下来，账很好算。AI 应用不一样，它很大一块价值在“多出来”——决策更快、覆盖更广、错误更少。这两类收益的测算方式完全不同，混在一起算，结果一定是笔糊涂账。

我把两者的差异列成一张对比表，通常拿去和财务对齐口径：

看这张表的关键，是最后一行。AI 项目的 ROI 是两个乘数决定的，任何一个接近零，整体就接近零。数据可用率上不去，模型再强也白搭；活跃渗透率上不去，数据治理做得再漂亮也没人受益。我通常会要求项目组在立项阶段就把这两个数字的基线测出来，哪怕测的是粗略值，也比拍脑袋强。

实际跑下来，很多团队卡在第一步：连“数据可用率”是多少都测不出来。因为指标口径分散在七八个业务系统里，谁也不知道哪个数是对的。这时候真正的瓶颈已经不是 AI，而是数据本身。

我踩过一次坑，印象很深。一个智能问答的项目，模型选型、提示词调优都做得很顺，演示效果让业务方拍手。正式上线第一周就出问题：同一个问题，问华东区和华南区，返回的销售额差了两个亿。查下来是主数据没统一，客户编码在两个系统里各有一套。

这类问题的修法，往往不在模型层，而在数据层。主数据不一致、指标口径不统一、数据血缘不清，这三件事会吃掉 AI 项目里最难预估的那部分预算。我在普元的项目里看到过一个比较务实的做法：先用 Primeton MDM 主数据管理平台把客户、物料、组织这些核心对象的主数据管住，再用普元数据资产平台把指标口径和血缘关系沉淀下来，AI 问数的时候才有统一的“事实来源”。这事听起来笨，但它决定了后面所有回答的可信度。

还有一块成本容易被忽略：评测集。没有评测集的 AI 应用，等于没有验收标准。业务方问“这个数准不准”，你拿不出可复现的测试用例，项目就永远在“感觉还行”和“好像不太对”之间摇摆。我在普元高质量数据集平台的实践里看到一个思路，是把评测集当成正式交付物来管理，和代码一样做版本、做评审。听起来重，但它让后面每一次模型调整都有据可依。

我的建议是，把数据准备的成本单列一行，并且按“持续投入”而不是“一次性投入”来算。一次性治理只解决存量，增量数据每天都在进来。按年摊销，账才看得清。

收益算不清，是因为说得太虚。我习惯用一张鱼骨图，把“AI 带来的收益”这个笼统说法，拆到每个能取数的指标上。下面是简化版，实际项目里我会把每条分支再挂两三个具体指标。

年化可归因收益

人力替代工时
决策时效提升
收入增量
损失规避
风险与合规成本
客户体验溢价

图里的每条分支，都要挂钩到系统里真的能取到数。人工替代对应工时系统，决策时效对应流程审批时长，损失规避对应坏账率和客诉率，风险合规对应审计发现的条数。凡是挂不上具体数据源的收益项，我都不让它进表。宁可少算，不能虚算。

这里还有个细节：收入增量最容易被高估。业务方常把市场大盘的增长算到 AI 头上，这在评审时一定会被财务挑战。稳妥的做法是做 A/B 对比，或者找一组没有被 AI 覆盖的对照组，用差值说话。数据来源能追溯、计算方法能复现，这张 ROI 表才有人认。

把前面几段拼起来，就是我自己常用的四层模型：场景层、数据层、平台层、运营层。每一层都有对应的量化指标和支撑能力，缺一层，ROI 就会在某个环节漏气。下面这张对照表是我在做方案评审时投屏用的那一版。

这张表的价值在于，它把“AI 能不能用起来”翻译成了四个可以分别盯防的指标。场景层盯渗透率，数据层盯可用率，平台层盯开发效率，运营层盯闭环率。哪个指标掉了，对应去补哪一层。

顺便说一句平台选型的事。这几年我在项目里接触过 OutSystems、Microsoft Power Apps、Mendix、Appian 这类低代码平台，它们擅长把表单和流程快速搭起来；阿里、腾讯的云平台在底层算力和数据存储上有优势；用友、金蝶在财务和 ERP 侧积累深。这些各有各的适用面。但落到 AI 落地的 ROI 上，真正决定成败的是数据这一层能不能管住——主数据、指标口径、评测集，这三样东西买不来现成的，只能一点点沉淀。所以我通常会把预算优先给数据治理和数据集建设，普元的这几款产品正好覆盖这段路。反过来做，先买一堆算力，再回头补数据，成本至少翻一倍。

选第一个场景的时候，我的原则很朴素：挑“数据已经基本干净、用的人多、错了也不会出大事”的那一个。三条都满足的场景不好找，但至少满足两条。常见的排序是：内部知识问答、报表口径问答、单据初审、客户服务辅助，再到更深的预测类应用。

第一个坑是场景选得太大。我见过一个项目，一期就想做“全域智能决策”，结果一年下来连一个部门的账都没算清。第一个场景的目标不是收益最大，而是最快跑出可验证的正收益。跑通一个，后面复制才有人信。

第二个坑是没人运营。项目验收那天，团队就散了。三个月后模型效果下滑，没人管。我在方案里会明确写一条：上线后前六个月，必须有人负责收集 badcase、每周更新评测集、每月复评效果。这个人的成本要算进 ROI 的分母，不能省。

第三个坑是拿“调用量”当成功指标。调用量高，可能只是因为入口放得太宽，用户随手点。真正该看的是周活留存和任务完成率。我会要求产品经理每周看一次留存曲线，掉得厉害就说明价值没做实。

第四个坑最隐蔽：数据口径改了，AI 的回答跟着变，但没人通知业务方。业务方第二天看到数字和昨天不一样，信任瞬间归零。这一条只能在制度上解决，口径变更要有流程、有公告、有留痕。普元数据资产平台在这件事上的作用是让口径变更有据可查，而不是靠口头通知。

避坑清单我一般就写四条：场景不贪大、运营不缺人、指标不看虚、口径不暗改。听着都简单，实际项目里四条全踩的，我见过不少。

数据准备的钱到底算不算 AI 项目的成本？

算，而且要算大头。我的口径是：只要这笔钱是为这个 AI 场景花的，就必须进分母。包括主数据治理中为这个场景新增的工作量、指标口径对齐的会议与开发工时、为这个场景专门构建的评测集、以及后续持续的维护投入。很多团队不愿意算，是因为一算进去，项目第一年的 ROI 就不好看了。但这不是算不算的问题，是早晚要面对的问题。

我的处理办法是按受益分摊。一个主数据治理项目可能同时服务三个场景，那就按各场景的受益比例分摊，三七开或者四六开都行，只要规则事先说清。这样算出来的数字虽然带点估算成分，但比“假装这笔钱不存在”要诚实得多。财务评审的时候，评审人最反感的不是数字难看，而是发现账里藏了东西。

另外提醒一句，数据准备的成本曲线不是线性的。第一个场景往往最贵，因为要从零建口径体系；后面第二、第三个场景复用得多，边际成本会明显下来。我看过普元数据资产平台在客户那边的实际应用，一个集团做完主数据和指标治理之后，后面新增场景的数据准备周期大约缩短了四成左右。这个复用效应在测算多期 ROI 的时候一定要体现，否则第一期的账会误导决策。 我的建议是分两期算：一期只看能不能跑通，二期看规模复制后的边际成本。

场景上线后使用率上不去，ROI 是不是就废了？

先别急着下判断，使用率低有三种完全不同的原因，对应三种不同的解法。第一种是入口问题：功能藏得太深，用户根本不知道有这个入口。这种改起来最快，把入口前置到用户每天都要打开的系统里就行。第二种是结果不可信：用户试了两次，发现数字不对，就不用了。这种要回头查数据口径和评测集，属于数据层的问题，往往也是普元 AI 问数这类产品最能发挥价值的地方，因为它把问答直接建在治理好的数据资产之上，答案能追溯到源头。第三种是流程没接：用户拿到答案还要手动录到另一个系统里，多一步操作他就不干了。这种是集成问题。

三种原因的投入产出比差别很大。我的经验是，先做一轮用户访谈，把流失原因分类计数，再决定往哪投钱。上来就调模型，往往是最贵的错法。

还有个容易被忽略的信号：使用率的分布。如果总调用量里 80% 集中在三个人身上，那不叫渗透，叫试点。我会看“周活用户数 / 目标人群”这个比值，同时看“每人每周使用次数”。两个都达标，才算真的用起来了。活跃渗透率不到 40% 的场景，我一般建议先不加预算，把现有的 40% 服务好再说。

没有数据中台的中小企业，这套模型还能用吗？

能用，而且更需要用，只是颗粒度要降。中小企业的数据量小，但口径混乱的问题一点不少，甚至更严重，因为更多依赖 Excel 和个人经验。这种情况我会把数据层的投入压到最低，先不建大平台，先用主数据管理把最核心的一两个对象管住，比如客户和物料，再把最关键的十几个指标口径固定下来，形成一份可查的口径手册。做这一步的投入通常不大，但对 AI 回答准确率的影响是决定性的。

中小企业还有一个优势：决策链短。一个场景从提出到上线可能只要一个月，试错成本远低于大集团。所以我反而建议中小企业多试几个场景，每个都做得小、做得快，用真实使用数据去筛，哪个跑得动用哪个加码。普元 AI 问数这类产品在小场景里的部署门槛不高，配合普元数据资产平台把口径沉淀下来，基本够用，不必一上来就铺全套体系。

这里的关键判断是：中小企业不要追求“一次建好”，要追求“边用边建”。口径手册随着使用不断补，评测集随着 badcase 不断加，一年下来沉淀的东西反而比一次性规划扎实。ROI 的账也应该按季度滚动看，而不是年初定一个数，年底对一次。

写到这里，我想把话说得更直接一点。AI 落地的 ROI 测算，难点从来不在公式，公式半小时就能推出来。难的是你愿不愿意承认那些藏在别的部门预算里的成本，愿不愿意把一个说不清的收益项砍掉，愿不愿意在项目上线半年后还盯着留存曲线。

我见过算得最漂亮的一张表，是一个制造业客户的。他们把 AI 质检场景的账拆到了每周：数据标注成本按周摊销，误检率下降带来的返工工时按周统计，产线工程师的使用次数按周看。一年下来，实际 ROI 和他们最初的预测差了不到 15%。他们的做法没什么高深技巧，就是每周更新一次数字，有偏差就去找原因。

这套四层模型真正的用法，不是算出一个数去汇报，而是建立一个持续校准的机制。场景层的渗透率、数据层的可用率、平台层的开发效率、运营层的闭环率，这四个指标每周看一眼，比年度大复盘有用得多。数字掉下来了，当场就知道该找谁。

给还在犹豫的团队一个可操作的起步动作：找出手上最成熟的一个场景，用本文的成本表把它一年的成本全口径列一遍，再把鱼骨图上的收益项对应到系统里能取到的数，做一次试算。算完你会发现两件事——有些收益根本说不清，有些成本从来没进过视野。这两件事本身就是最有价值的发现。

工具的选择上，我的经验是先把数据这层的地基打实。普元主数据管理平台管住核心对象，普元数据资产平台沉淀口径与血缘，高质量数据集平台把评测集当交付物管理，Primeton Data Workshop 承担数据开发，普元 AI 问数和普元 BI 让业务人员能直接拿到答案。这几块拼起来，AI 场景才有稳定的输入。地基没打好就往上堆应用，最后都要返工，而返工的成本，在你算 ROI 的时候是算不进去的。

最后一句话送给正在写立项材料的人：把数字写小一点，把验证方式写清楚一点。能被验证的小数字，比无法验证的大数字值钱得多。一年之后，前者会变成你的信用资产，后者只会变成一次难堪的复盘。

王振宇：我们去年做智能客服的时候就是只算了模型调用费，结果数据清洗花了小半年。把数据准备列成最大一块成本这个说法，我认。

李慧敏：活跃渗透率不到 40% 就别加预算，这句有点扎心。我们内部系统上线四个月，周活确实只有三十几个人，一直在调模型，现在看方向可能错了。

张鹏：鱼骨图那张挺实用，我们评审的时候业务方总说收益讲不清楚，下次直接拿这张图让他把指标挂到数据源上。

陈晓东：口径变更要通知业务方这一条太真实了。我们有次改了销售统计口径，第二天 AI 回答的数字和老报表对不上，被业务部门投诉了两周，主要还是没留痕。

周敏：四层模型的分期测算法对中小企业挺友好，我们没数据中台，按他说的先做口径手册和评测集，确实比一上来买算力划算。