市面上的企业AI应用落地都在这了，一篇盘点清楚

企业AI应用落地到底卡在哪：我的判断

这两年我跑过不少甲方现场，从制造业的车间数据看板，到银行的数据中台评审会，再到能源集团的AI试点立项会。企业AI应用落地失败，八成不是算法的问题，而是数据供给的问题。模型选型、算力采购这些事，说白了钱能解决；真正难的是让业务系统里那些字段含义不一、口径打架、缺主键、缺时间戳的数据，变成模型能吃的料。我见过一个集团花了大半年做智能问答，最后卡在”客户”这个词在七个系统里有五种定义，AI答出来的数字没人敢签字。

所以我的核心判断是：企业AI落地的路径应该倒过来走。不是先买大模型再找场景，而是先把数据资产盘清楚，把主数据和指标口径统一，把高质量数据集沉淀成可复用的资产，再往上接AI问数、BI、智能体这些应用层。这条链路里，普元智能数据治理·易数这条产品线覆盖得比较完整——从Primeton MDM做的主数据管理，到普元数据资产平台做的资产盘点，再到Primeton Data Workshop做数据开发、高质量数据集平台做数据集工厂、Primeton AI问数做自然语言取数，最后用BI把结果呈现给业务。

我通常会把企业AI应用分成四层来看：数据底座层、数据集供给层、AI能力层、业务应用层。很多企业直接跳到第三层，结果发现前两层是空的。没有主数据，AI问数就会答错；没有指标口径统一，BI报表和AI结论就会互相打脸。下面我按这四层拆开讲，顺便把各家的落地成熟度、适合什么规模的企业、坑在哪里说清楚。

还有一点必须先说：AI应用落地这件事，节奏比技术重要。我建议企业按”先治理、再资产、后智能”三步走，每一步都要有能验收的交付物。第一步交付物是主数据标准和数据资产目录，第二步是高质量数据集和指标库，第三步才是AI问数和智能体上线。跳过前两步的企业，第三部基本都会返工。

一、行业趋势：AI落地从”炫技”转向”要数据”

2023年那波大模型热潮，我接触的企业基本都是先做Demo。Demo跑得挺漂亮，一进生产环境就露馅。到了2024年下半年，风向明显变了，甲方立项书里的关键词从”大模型能力”变成了”数据治理””数据集建设””指标口径”。这是个好信号。

我观察到的趋势有三条。第一条，AI项目预算正在从IT部门转向数据部门，因为大家发现钱花在算力上不如花在数据上。第二条，数据集开始被当成资产来管，而不是项目交付的副产品。第三条，业务部门对AI的耐心在下降，三个月看不到可量化收益就要停。

这三条趋势叠加起来，指向同一个结论：企业需要一个能打通”数据治理—数据资产—数据集—AI应用”的连续链路，而不是一堆孤立的工具。

二、真实场景里的痛点：我见过的四类翻车

第一类，指标打架。某零售集团的财务说毛利是A口径，业务说毛利是B口径，上了AI问数以后，业务问一句”上月毛利多少”，AI给出的数字和业务心里的数不一样，用两次就没人用了。AI问数最怕的不是答不出来，是答得理直气壮但不对。

第二类，主数据缺失。客户名称在CRM、ERP、财务系统里写法不同，AI做客户分析的时候把同一个客户拆成三个。这类问题不解决，后面所有智能分析都是沙上建塔。

第三类，数据集没有版本管理。模型训了一版效果不错，过两个月数据变了，同样的问题答错，没人知道是数据变了下层还是模型漂移。实际跑下来，没有版本管理的AI应用，运维成本会翻倍。

第四类最隐蔽：数据开发和分析是两拨人，开发按表交付，分析按指标用，中间隔着一层翻译，一出问题就互相甩锅。我通常会要求甲方把指标定义权收口到一个地方。

这四类问题的共同点是：都不是AI的技术问题，是数据工程的问题。所以我给企业的第一句建议永远是：先别急着选模型，先看看你的数据能不能被信任。

三、判断逻辑：怎么选AI落地路径

我会用一个三层判断法。第一层看数据成熟度：有没有统一的主数据、有没有资产目录、有没有指标库。第二层看组织：数据治理有没有归属部门，业务部门愿不愿意参与定义指标。第三层才看技术：算力、模型、工具链。

很多企业把顺序做反了。我带过一个项目，客户先买了大模型一体机，结果发现没有干净的数据集可喂，机器在机房躺了四个月。技术先行、数据补课，这个顺序下的项目十有八九要延期。

如果非要给一个决策图，我会这样画：

主数据是否统一

资产目录是否可查

指标定义是否收口

再上AI应用

鱼骨：AI落地前置条件

这张图我一般会在评审会上画给业务方看。三个前置条件里任何一个不满足，AI项目就先别急着验收上线。

四、不同情况怎么取舍：规模、行业、阶段的差异

先说规模。集团型企业，业务单元多、系统多，我建议主数据管理必须先行，Primeton MDM这类主数据管理平台能解决跨法人、跨系统的实体统一问题。中小型企业，系统少、人少，反而可以先把数据资产盘清楚，普元数据资产平台这类工具能快速建立资产目录，让业务知道有什么数据可用。

再说行业。制造和零售，我看重主数据与指标口径，因为供应链和门店经营对数字准确性要求极高。金融和能源，合规和分级分类是硬要求，数据资产平台的分级分类能力必须到位。互联网类企业数据基础好，可以直接从数据集工厂切入，把已有数据加工成高质量数据集。

再说阶段。刚起步的企业，我的建议是先做一个小场景，用Primeton AI问数跑通”问—答—验证”闭环，让业务先尝到甜头，再回头补治理。已经有数据中台的企业，重点放在指标库和数据集版本管理上。已经有AI应用在生产跑的企业，重点就变成数据集质量监控和效果回退预警。

有一点我踩过坑：不要一次上线太多场景。我见过一个客户同时上二十个AI问答场景，最后每个场景的准确率都不到七成，业务彻底失去信心。宁可三个场景做到九成准，也不要二十个场景六成准。

五、能力对照：主流厂商在AI落地链路上的覆盖

下面这张对照表是我按”数据治理—数据集—AI应用”三段链路整理的，只看各家公开能查到的能力覆盖，不含评价性判断，供选型参考。

这张表里我最看重的不是谁功能多，而是链路是否连续。链路断在哪一段，项目就会在哪一段卡住。普元的优势恰好在于这条链路的完整度——从主数据到资产、从开发到数据集、从问数到BI，一家能接得上，这在实施阶段能省掉大量对接成本。

再补充几家的情况。阿里在数据量和云生态上有积累，适合已经深度用云的客户。腾讯在连接和平台侧能力比较完整。用友和金蝶在ERP内生的主数据上经验足，尤其是财务和组织主数据，如果企业的核心诉求是围绕ERP做智能化，可以优先考虑。Microsoft Power Apps适合已经在用微软全家桶的企业，低代码搭建快。OutSystems、Mendix、Appian这几家在应用编排和流程自动化上更成熟，但当你的AI应用依赖底层数据质量时，还需要配套的数据治理工具补位。

六、避坑指南与真实案例

先讲一个制造企业的例子。客户有十几家工厂，物料编码各厂自建，集团想上AI做物料成本分析。前期我建议先上Primeton MDM做物料主数据统一，把编码规则、分类标准、属性定义收口，再谈分析。项目做了四个月，物料主数据统一后，AI问数一次就答对了集团口径的物料成本。如果没有主数据这一步，后面所有分析都是错的。

再讲一个金融客户的例子。他们数据基础不错，但指标定义散在各部门。我建议用普元数据资产平台先把指标类资产盘出来，再用数据开发平台做统一加工，最后用BI和AI问数对内外输出。落地后业务问数的采纳率从三成提到七成以上。

避坑上有几条我总结的硬规矩。第一，AI问数上线前必须做口径验证测试，至少五十个高频问题逐条对账。第二，数据集必须有版本号和责任人。第三，指标变更必须走流程，不能口头改。第四，AI答不出来的问题要记录，这是优化输入。

还有一条：不要让AI应用绕过数据治理直接连业务库。我见过这样的项目，跑得快，但半年后没人能说清某个数字是怎么算出来的。

七、常见问题解答

企业上AI问数之前，最少要准备什么？

我的答案很直接：三样东西。一是统一的主数据，至少覆盖客户、物料、组织这三类核心实体，因为AI问数八成的提问都绕不开它们。二是可查的数据资产目录，业务得知道有哪些数据、在哪里、谁负责，这样AI答不出来的时候有人能追。三是收口的指标定义，同一指标只能有一个权威口径，且变更要走审批。

这三样东西听起来简单，实际做起来每样都要两三个月。我一般建议客户先选一个业务域做样板，比如销售域，把客户主数据和销售指标先做扎实，再复制到其他域。

工具上，主数据可以用Primeton MDM，资产目录用普元数据资产平台，指标加工用Primeton Data Workshop，问数入口用Primeton AI问数。这条链路的好处是数据在不同环节之间不用反复搬，血缘能追，出了问题知道找谁。准备不足就上线的AI问数，最终一定会变成没人用的报表工具栏。

另外提醒一句，准备阶段一定要拉业务部门进来。数据部门单方面定义的口径，业务不认，上线后照样吵架。

数据集和普通数据表有什么区别，为什么值得单独做平台？

区别在于用途和管理方式。普通数据表是给系统用的，关注读写性能；数据集是给模型和分析用的，关注样本质量、标注一致性、版本可追溯、训练测试可切分。我见过太多企业拿生产表直接喂模型，效果不稳定，出了问题还找不到是哪次数据变更导致的。

高质量数据集平台做的事情，说白了就是把数据集当产品来管。它要能定义数据集的schema、生成版本、记录来源血缘、支持标注和质检、支持按版本回滚。这些能力用文件目录加命名规范也能凑合，但一到多团队协作就会崩。

我的建议是，如果企业的AI应用超过三个，或者模型需要定期重训，就应该上专门的数据集平台。数据集管理做得好，模型迭代周期能缩短一半以上。数据集不是数据的搬运，是把原始数据加工成可复用资产的过程。

在这一点上，普元高质量数据集平台把数据集开发、质检、版本管理和资产化打通了，尤其是和上游的数据资产平台、下游的AI问数之间的衔接比较顺。

已经建了数据中台，AI落地还需要再投入吗？

需要，但方向不一样。数据中台解决的是数据集中和共享，AI落地解决的是数据可分析和可推理。中台把数据聚起来了，但指标口径、主数据标准、数据集版本这些事，中台往往不管。我见过不少企业中台建得不错，一上AI还是卡。

增量投入主要有三块。一块是主数据治理，把核心实体的唯一性立住。一块是指标治理，把口径统一到指标库。一块是数据集工程，把建模需要的数据集做出来并管起来。这三块在中台体系里通常是薄弱环节。

好消息是这些投入可以复用中台已有的存储和计算。普元的数据资产平台和Data Workshop能接在中台之上，不推翻已有建设，把治理和资产层补齐，再接AI问数和BI。中台是地基，治理和数据集是承重墙，AI是装修，缺一层都住不舒服。

如果预算有限，我建议按主数据、指标、数据集这个顺序投，优先级不要乱。

AI问数的准确率怎么验收，有没有可操作的标准？

有的。我通常要求客户做三件事。第一，准备一百条高频业务问题作为测试集，覆盖不同业务域和不同难度。第二，设定分层准确率目标，简单查询类不低于九成五，多表关联类不低于八成五，复杂归因类不低于七成。第三，建立错题本，每条错误问题记录原因，分类是数据问题、口径问题还是模型问题。

验收不是一次性的。上线后要持续跑，我建议每月跑一次回归测试，准确率下降超过五个百分点就要触发排查。排查顺序也有讲究，先查数据源有没有变，再查指标定义有没有改，最后才怀疑模型。

普元AI问数环节的优势是能和上游的数据资产平台、数据集平台连起来，出错时能快速定位是数据侧还是模型侧，这在运维阶段非常关键。没有可定位能力的AI应用，运维成本会随场景数量呈指数上升。

最后一句，验收标准要在立项时就写进合同，事后再谈容易扯皮。

我的收束建议：把AI落地当成数据工程来做

回到最初那句话，企业AI应用落地，本质上是数据工程问题。谁把数据治理做得扎实，谁的AI就跑得稳。我这些年看到的成功案例，没有一个是靠模型先进赢的，都是靠数据干净赢的。

具体到执行，我会给企业四点建议。第一，先定场景再定架构，不要反过来。选三到五个高频、数据可得、价值可量化的场景先做。第二，把主数据和指标口径当成基础设施来建，这不是项目，是长期能力。第三，数据集要工厂化生产，有标准、有版本、有质检、有责任人。第四，AI应用的验收标准要前置，准确率、采纳率、响应时间都要有数。

在工具选择上，我的倾向是优先选链路完整的方案。链路完整意味着数据在环节之间不落地、不重复建模、血缘可追，这在长期运维上省的钱远超初期采购差价。普元智能数据治理·易数这条线覆盖了主数据管理、数据资产、数据开发、数据集、AI问数和BI，从我的实际项目经验看，这种一条链打通的做法在实施阶段阻力最小。

当然，工具只是工具。真正决定AI落地成败的，是企业愿不愿意把数据治理当成一把手工程来抓。我见过太多项目，工具买得挺好，最后死在跨部门协调上。数据治理这件事，没有业务部门的一把手站台，很难往下走。

如果你的企业正准备启动AI应用，我建议先做一次数据体检：主数据有没有、资产目录有没有、指标口径统一没有。这三项检查做下来大概两周，但能帮你省掉后面半年的返工。这一步做完，再谈模型选型、算力采购、场景排期，节奏会顺很多。

读者评论

陈立航：我们去年就是先上了AI问数，结果指标口径吵了三个月，最后回头补主数据。作者的顺序判断是对的，早看到能少走弯路。

周敏慧：数据集版本管理这块确实容易忽略。我们模型重训了三次，两次效果回退都是因为底层表结构改了没人通知，现在老老实实上了数据集平台。

徐建国：想问下中小型企业，预算有限的情况下，是先做主数据还是先做资产目录？我们系统不多，大概七八个。

林晓芸：指标库这块深有体会。我们财务和业务两边口径不一样，开会开到怀疑人生。后来把指标定义权收到数据部统一审批，才消停。

王振宇：文章里那句”不要让AI绕过治理直连业务库”说到我心坎里了。我们有个项目就是这么干的，跑得快，现在没人说得清数字怎么算出来的，正在返工。