别迷信智能体了：95% 企业 AI 落地失败，都是输在数据治理

别迷信智能体了：95% 企业 AI 落地失败，都是输在数据治理

当企业急着上智能体，却被“数据现实”按了暂停键

先说说近两年在大型集团反复看到的现象：

• 顶层设计阶段：雄心勃勃要推一批智能体，通用型+业务专属型，目标全面支撑业务和管理；

• 落地体验阶段：一轮试用下来，反馈出奇统一——

  “数据不行，问不准、看不懂、不敢用。”

智能体本身没问题，它只是把多年积累的数据问题一次性摊在了桌面上。最终所有问题的求解，都得回到一个底层判断：

一、典型集团的数据治理“缩略图”

用几个高频画面，足以勾勒出很多集团的共性现状。

1. 监管报送：上千个字段，全靠人海战术

• 每月向监管或上级单位报送大批数据，字段动辄成百上千；
• 大部分仍是人工采集、手工填报；
• 没有清晰的口径、来源和复用机制，改一次模板，就要折腾一整片部门。

2. AI 问数：对接了系统，却只连上“原始库表”

• 通用问数智能体已上线，打通了几个核心系统的原始数据表；
• 问项目、问指标、试点问“某员工工作经历”，能答，但答得零散、模糊、难校验；
• 说白了：

  模型连的不是“治理好的指标和数据资产”，而是“裸奔的源数据”。

3. 经营驾驶舱：主要靠填报

• 集团层面有一个“经营分析驾驶舱”，主要服务决策层；
• 指标来自各业务系统“加工好之后”往中台一丢，中台只负责展示；
• 各业务条线自己的驾驶舱几乎没有，业务问题依旧靠“报表 + PPT”解决。

4. 中台变成“数据中转站”

• 业务系统一堆：人力、财务、合规、OA……各管一摊；

• 数据中台：谁要数据，就去各系统拎一份出来，最多做下分类就丢出去；

• 没有统一模型、没有加工层、没有对外的数据服务目录，

  更像“物流中转站”，不是“数据资产工厂”。

5. 组织与标准：人人用数据，却没人真“管数据”

• 没有集团级的数据治理组织，没有域数据 Owner；
• 信息部门管系统、业务部门管报表，各自优化、缺少统筹；
• 有过一版数据标准，但一直停在“拟稿状态”，没有真正发布执行。

一旦出现数据问题：谁解释？谁拍板？谁负责？

二、问题不在“技术太差”，而在“系统缺位”

把这些现象抽象一下，其实就是四句话：

1. 没有体系化的数据治理框架

   组织、职责、制度、流程都不成型，问题只能靠人情协调。

2. 监管报送、经营分析，从未被当作“数据资产”系统规划

   只有字段和表格，没有集团级统一指标和可管理的指标体系。

3. 中台只做“搬运”，不做“治理 + 产品化”

   没有统一数据模型，没有沉淀公共指标和特征，更谈不上标准化数据服务。

4. AI 项目跑在数据治理前面

   先立十个智能体，再发现“每个智能体都在要同一批基础数据”，

   最后只能回头重做一次数据治理。

一句话：

三、一条更现实、也更普适的数据治理路径

对于正在筹划智能体、AI 项目的集团，更建议采用一条“务实三步走”。

第一步：选一条“牵引链路”，而不是“一口吃个胖子”

用一个场景串起三件事，而不是一上来搞“全域治理”：

• 监管报送中最关键的那部分数据；
• 集团经营驾驶舱中最核心的那几类指标；
• 一个高度相关的试点智能体（如经营分析 / 投资决策智能体）。

目标是打通一条完整链路：

只有真正打通一条，后面扩展到更多域才有参考模板。

第二步：先立“骨架”：组织、职责和问题闭环

至少要把三件事说清楚：

1. 集团级数据治理机制

• 成立数据治理委员会或类似机制，由主要领导 / 分管领导挂帅；
• 统一决策：为什么做、先做什么、做到什么程度算合格。

• 域数据 Owner 制
• 按业务域（投资、资金、人力、风险等）设立域数据 Owner；
• 负责口径解释、质量归责、变更发起。

• 数据问题处理闭环
• 建立数据问题工单和处置流程，和 IT 变更、需求管理打通；
• 形成“发现问题 → 归类 → 定责 → 调整 → 验证”的常态机制。

没有这层骨架，所有标准、模型、中台、智能体，

第三步：让中台从“仓储中心”升级为“资产工厂”

中台至少要补上四项基础能力：

1. 统一业务数据模型

   围绕项目全周期、资金闭环、员工生命周期等建立统一模型，

   把“散数据”拼成“业务故事”。

2. 沉淀指标与特征

   从字段上升到指标，构建集团统一指标体系，

   为驾驶舱、报送、智能体共用。

3. 标准化数据服务

   对外提供可查询、可复用的数据服务目录（API / 主题视图 / 数据集），

   让“要数据”变成“调服务”。

4. 质量与血缘监控

   中台层面内嵌质量规则和监控，记录血缘，

   让“这个数是怎么算出来的”有据可查。

在这个基础上，智能体再去连中台，才算真正“吃对粮”。

四、把智能体当“放大镜”，而不是“遮羞布”

一个原则可以写进项目蓝图里：

这样做有两个好处：

• 智能体会不断暴露薄弱数据域，反向驱动治理；
• 智能体本身也从“玩具”变成“数据质量的试金石”。

五、给准备大规模上智能体的企业的几条共通建议

最后，用几条“高密度”的建议收个尾：

1. 先把数据当基础设施，再把智能体当生产工具

   顺序不要反：不是“上完智能体再补数据”，而是“用智能体牵引数据治理”。

2. 用业务闭环设定里程碑，而不是技术模块

   比如，从“监管报送 + 经营驾驶舱 + 一个试点智能体”开始，

   做深做透，再扩展到人力、预算、风险等更多链路。

3. 从字段思维升级到指标思维

   把领导关心的问题，抽象为一组可管理的指标体系，

   再反推模型、中台加工和智能体回答能力。

4. 接受这是一个 3–5 年的工程，但每年都要有可见成果

   不指望“一步到位”，也不接受“年复一年只做试点”。

5. 让数据治理从“项目”变成“机制”

   今天为智能体做的治理投入，

   明天会在监管合规、经营分析、内部精细化管理中不断回本。