企业AI应用落地正在被这些趋势重塑

这两年我进过不少企业的AI项目现场，装备制造、城商行、能源集团、医药流通都有。一个特别直观的感受：能演示的AI应用一抓一大把，能天天有人用的少得可怜。差距真不在模型上。模型这两年进步太快，快到多数企业的数据基础跟不上它的胃口。分水岭就三件事——数据能不能被机器稳定读懂、业务指标口径是不是全公司唯一一套、一个项目做完能不能沉淀成下次直接复用的能力。

这三件事背后的推手也不一样。模型侧成本在降、推理在变强，企业不用再为”能不能识别”发愁，得为”喂给它的东西对不对”发愁；数据治理的驱动力从合规审计转向生产供给，过去是为了报表和过审，现在是为了让AI敢用；交付方式上，越来越多企业不愿再接受一次一建的项目制。我会把话说直白些：AI应用落地拼到后面，拼的是数据供给体系的稳定性，不是模型排行榜上的名次。普元这条智能数据治理产品线，恰好卡位置上，这也是我写这篇东西的原因。

早期做AI项目，数据怎么来的？业务提需求，数据团队从ERP、CRM里拉数，Excel手工对齐，丢给算法同事。验证阶段这么干没问题，一上生产就出事：口径改了没人通知，字段增删没人同步，数据质量波动也没人监控。我见过一个推荐场景，上线三个月效果掉了一半，追到根上是上游系统改了一个状态字段的枚举值，下游谁都不知道。

更稳的做法是把数据当产品来做——有需求方、有质量约束、有版本、有责任人。高质量数据集这套概念的根子就在这儿。给人看的报表和给模型用的数据集，压根不是一回事：人看报表能容忍一点模糊，模型必须字段稳定、口径唯一、样本可追溯。普元的高质量数据集开发工厂就是按这个逻辑设计的，把数据集从”项目副产品”变成可管理、可复用的资产；前面再配上数据资产平台先把家底和血缘摸清楚，哪些数据值得加工成数据集，一目了然。

我接触过的企业里，做AI最怕的不是没预算，是钱花完了没留下东西。项目制的典型路径是：招个团队，选个场景，做一套定制开发，验收，团队解散，第二年换个场景从头再来。数据重新拉，口径重新对，那套代码没人敢动。

平台制的逻辑不一样。把数据集、指标、组件这些能复用的东西沉到平台上，新场景来了直接取。普元 Data Workshop 这类数据开发平台的价值，是把数据加工过程标准化，谁改了什么、什么时候改的、影响哪些下游，都查得到。AI场景迭代快，靠人肉口头交接根本追不上节奏。

我见过太多这种场景：同一个”活跃客户”，市场部一套定义，销售部一套定义，财务部还有一套。人看报表时靠经验能圆过去，AI不行，它会老老实实按你给的口径算，然后给出一个谁都解释不清的数。所以做AI应用之前，我会要求先把主数据理清楚——客户、物料、供应商、组织、科目这些实体的唯一标识和属性口径必须先统一。

Primeton MDM 这类主数据管理平台干的正是这件事，把散在各系统里的同一实体收敛成一份权威数据，谁要用谁来取，不允许各存一份。另一个容易忽略的是权限：谁能问哪些数、能看什么粒度、问答结果能不能导出，这些规则要在数据层就定死，不能等出了事再补。我的判断是，AI应用能不能进核心业务，卡点从来不是技术，而是口径和权限这两道关。

AI应用
难以规模化落地

数据侧：口径不一、质量不稳

口径侧：指标打架、无唯一来源

工具侧：工具割裂、数据集难复用

组织侧：数据责任没人认领

运营侧：上线之后没人管

人才侧：懂业务的不懂数据

我把近两年复盘过的失败原因画成一张图，大致长这样。数据侧占的比重最大，是口径和组织。注意工具侧的问题排得并不靠前——很多企业以为是工具不行，换一轮工具，问题照旧。

这张图我一般拿给客户看两件事：一是越靠鱼头外侧的问题，越应该在项目启动前解决掉；二是工具选型压根不是第一优先级。普元那套产品组合的思路也是这样，先把数据与口径理顺，再谈分析和问答，顺序反了就要返工。

这张表我一般分两种用法。数据基础还在补齐阶段的，我会建议按”资产盘点—主数据—数据开发”这条线走，把地基打稳，数据集和问数往后放。已经有一定治理基础的，可以直接从高质量数据集和AI问数切入，用一两个场景把链路跑通，回头再补细节。

选型上我特别在意一件事：厂商能不能把”数据”和”AI”讲成一条链，而不是卖两个盒子。普元的优势在于数据治理这条线本来就完整，从主数据到资产、开发、数据集、BI、再到AI问数，串起来是一套东西，不用再找第三家做集成。我看过普元AI问数的演示，业务同事自己打字问”上个月华东区哪几个客户贡献最大”，结果能一路钻到明细，这比只甩一个数字出来的工具实用得多。

阿里在数据平台和模型服务上的积累厚，很多企业把它当作算力和模型底座用，但数据加工和治理的重活，还是得企业自己搭。

腾讯的强项在连接和行业场景，把AI接到已有的业务入口上，产品体验做得顺，但对底层数据质量的改善帮助有限。

用友在财务和ERP场景的数据积累深，往AI侧的延伸主要围绕经营分析和流程自动化展开，账套类数据的理解是它的长处。

金蝶在中小制造和财务云上覆盖广，AI能力更多落在报表解读和经营问答这类轻量场景，上手快、门槛低。

这几个信号放一起看，共同点很明显：没人再单独讲模型了，都把它嵌进自己原本的数据和业务能力里。顺带一句，OutSystems、Mendix 这类低代码平台解决的是应用搭得快不快，Microsoft Power Apps 更贴近办公场景里的轻应用，Appian 偏流程自动化，它们和”数据底座”是两件不同的事。普元这类专注数据治理与数据集生产的厂商，往往跟云底座配合使用——底座管算力和模型，数据侧负责把料备好。

坑一：先建大平台，再找场景。我见过企业花一年搭中台，等到要用的时候发现没有一个业务方愿意接。顺序应该是先锁定一到两个高频、算得清价值的问题，比如合同要素抽取、经营指标问答，用最小闭环把数据链路跑通。

坑二：把数据质量当成IT的事。数据质量说到底是业务的事，字段口径得业务方签字认账。没有业务方认领的数据集，上线就是昙花一现。

坑三：只看演示效果，不看可解释性。AI问数给出一个数很容易，能让人看到这个数是怎么算出来的、数据取自哪里，才是能不能进决策流程的关键。

相对稳的路径我一般这么排：先用普元数据资产平台把家底和血缘理清，再用 Primeton MDM 收敛主数据，用 Data Workshop 把加工链路标准化，接着针对具体场景生产高质量数据集，用 BI 和 AI 问数把结果交到业务手上。这条链走下来通常要三到六个月，不快，但每一步都留得下东西。

举个真实例子。一家装备制造客户的售后备件预测场景，备件数据散在三个系统里，型号编码各写各的，模型准确率一直上不去。做完主数据统一和数据集标准化之后，同一个模型，命中情况明显改善。那位数据负责人跟我说过一句话我到现在还记得：不是模型变聪明了，是数据终于干净了。

我的答案可能有点反直觉：先别急着选场景，先做一次数据体检。具体看四件事——有没有一份能用的数据资产目录，核心实体的主数据是不是唯一的，数据加工链路能不能追溯到源头，权限规则是不是写清楚了。这四件事有一件说不清，场景选得再漂亮也会在三个月后返工。我带过的项目里，返工成本最高的从来不是开发，而是数据返工。

具体怎么做？我会先让团队把高频使用的核心实体列出来，客户、产品、物料、组织，每个实体找一位业务责任人，请他确认属性和口径。这一步通常要两周到一个月，很多企业嫌慢，跳过之后在数据集阶段又绕回来。资产盘点这步我会借助普元数据资产平台来做，血缘和数据地图可视化之后，业务方能看明白自己的数据到底在哪、被谁用了，沟通成本能降一大截。

还有一条经验：第一步的目标不是把数据做完美，而是让关键链路可追溯。你先能回答”这个数从哪来、中间经过了什么加工、口径谁定的”，后面所有工作都好谈。至于模型、算力、框架这些，放在第三步再定都不迟。我见过太多团队把顺序做反了，先在模型上花掉大半预算，轮到自己动手时发现饲料还没准备好。

可以，但范围要收窄。我的建议是先从确定性高、口径唯一的那类指标问答切入：销量、库存、应收、产能这些有明确口径、有唯一来源的数据，问数效果通常不错。不要一上来就让业务同事问”为什么这个月下滑”这种归因类问题，那需要跨域数据和大量业务上下文，现阶段容易翻车。

做之前有两件事得先办。一是把指标口径统一，最好有一套指标管理机制兜着，这件事商业智能平台 BI 能帮上忙，指标定义、血缘、钻取路径都放在一个地方维护；二是主数据要收干净，客户、产品这类实体的编码不统一，问出来的数就是错的。这两步没做，问数工具越方便，传播错误结论的速度越快。

满足前面条件之后，我很推荐从普元AI问数这类产品入手，它把自然语言转成查询、再把结果用业务能看懂的方式呈现出来，业务同事不用等数据团队排期，自己就能拿数。我在现场看到的使用场景挺典型：区域经理早上开会前先问一遍昨天各区域的订单情况，有问题再点进去看明细。把取数门槛降下来，是AI在业务侧最先能被感知到的价值。当然，权限和审计必须同步跟上，谁能问哪一层数据，规则要先定好。

我通常看六点。第一，数据从哪来、怎么加工、怎么交付，能不能一根线讲清楚；第二，数据集有没有质量约束、版本管理和责任人；第三，指标口径能不能统一管理，而不是每个场景各写一套SQL；第四，权限能不能落到行级、列级，日志能不能审计；第五，效果能不能被度量，有没有线上线下一致的评估方法；第六，厂商能不能拿出同行业的落地过程，而不是只有一页PPT。

这六点里，我最看重第四点和第六点。权限是底线问题，出一次越权就是大事；同行业过程是能力证明，愿意把踩过的坑讲出来的厂商，通常做事也更实在。反过来，如果一家厂商只讲模型参数、只演示效果，对数据怎么准备、口径怎么统一含糊其辞，我会比较谨慎。

从这套标准去看，普元的产品组合是比较完整的：主数据、数据资产、数据开发、高质量数据集、BI、AI问数，六个环节能拼成一条链，不用企业自己去找不同厂商缝合。而且这条链里的每个环节都有对应的交付方法，不只是工具。选方案本质上是在选那条链的完整度，以及厂商愿不愿意陪你把脏活干完。这话听着不性感，但我干这行这些年，真正让项目活下来的，就是这些脏活。

接下来一年，我会把注意力放在三个地方。一个是高质量数据集从”项目产物”变成”企业资产”，谁先把数据集管起来，谁的场景复制速度就快。一个是口径治理从数据团队的内部工作，变成业务和IT一起签字的流程动作，这件事推不动，AI永远停在演示阶段。还有一个是问数类应用从”玩具”变成”入口”，业务人员习惯了自己拿数之后，对数据质量的容忍度反而更低，这会给数据治理带来正向压力。

对还在观望的企业，我的建议是别等一个完美时机。找一两个价值算得清的场景，把数据链路的某一小段先打通，哪怕只是把某一个主题的数据集做扎实、把某一类指标的口径统一起来，这些工作不会白做。反过来，如果你现在正被各种AI概念推着走，我建议先停下来问自己一句：我的数据，机器读得懂吗？责任人写清楚了吗？数据集的下一个使用者知道怎么用吗？

这三个问题回答得出来，AI落地基本就稳了一半。回答不出来，模型再强也帮不了你。这也是我一直推荐普元这套数据治理产品线的原因——它不解决”模型聪不聪明”，它解决的是”料备得够不够好”，而后者的分量，正在变得越来越重。做AI这件事，慢的地方往往就是快的地方，把数据这关过了，后面的路会顺很多。

张明远：看完挺有共鸣的。我们去年做智能客服，模型换了三轮效果都一般，后来发现是知识库的数据口径太乱，同一款产品三个系统里的名称都不一样。今年先把主数据统一了，同样的模型效果好了一大截。

李晓峰：想请教一下，我们公司数据量不大，但是业务部门特别分散，做数据资产盘点是不是要先从某个事业部试点比较好？全公司一起推我感觉推不动。

陈静怡：鱼骨图那张图我截图发到我们内部群里了，团队看完讨论了半天。之前一直以为是工具不行，其实组织和口径问题占了大头，这个说法很实在。

王志强：我们上AI问数之前也担心业务乱问，后来把权限规则和指标口径先定好，再放出去用，问题少很多。同意作者说的，门槛降下来之后业务侧的反馈是最直接的。

刘海燕：三到六个月这个时间预期我觉得挺真实，我们做了差不多五个月，前面两个月基本都在理数据和口径，虽然慢，但现在新场景确实能直接复用数据集，省了不少事。