AI 项目的失败，很少死在算法上。
真正让项目停在 Demo 阶段的，是数据没法用、模型上线后没人管、以及出了事找不到谁负责。这三件事听起来都不新鲜，但它们决定了大多数企业能不能把 AI 做成常规业务。
关于试点无法规模化的比例，各家统计从 70% 到 95% 不等。口径差得挺远，结论倒是一致：能把它跑成日常运营的，是少数。投资额年年涨，回报在报表上找不到，于是下一年预算会上，CIO 开始被问一些不太好答的问题。
一、数据的问题不是不够多，是不能用
传统的数据治理是为合规服务的：报表能出、审计能过，任务就算完成。但这样的数据喂不进模型：字段命名混乱、同一指标三个口径、样本集中在头部场景、长尾没有标注。Gartner 有过一个被反复引用的判断，说八成以上的 AI 项目栽在数据上。具体数字可以争，一线做过项目的人大概都有体感。
「AI 就绪数据」不是把数据洗干净这么简单。它指的是能直接进训练管道的样本：标注过、结构化、覆盖真实业务分布。要做出这种东西，靠采购工具没用，得动组织：各业务域自己管自己的数据、中央只定标准和接口（联邦制），一份谁都能查的企业级数据资产目录，以及把数据质量写进业务部门的考核指标。
最后一条最难推，也最有效。没有考核，数据治理永远是 IT 部门的独角戏。
二、MLOps：模型上线那天就开始衰退
一个常见场景：模型在 notebook 里 AUC 0.85，部署三个月后业务方说「不准了」。追下去发现是上游系统改了个字段类型，没人通知。这不属于算法问题，属于运维问题。
MLOps 做的事说穿了就是给模型建流水线。数据进来先校验，训练过程能复现，上线走灰度，上线后持续盯输入分布和预测分布。这里要区分两个概念：数据漂移是输入本身变了，概念漂移是输入和输出之间的关系变了。两者的监控指标和应对方式都不一样，混在一起看只会误判。阈值触发后自动重训，做不到自动，至少做到自动告警，别等季度复盘才发现模型已经在裸奔。
要不要一上来就建完整平台？我的看法是不必。先把版本管理、数据校验、监控告警这三件事做扎实，收益比买一套 MLOps 产品大得多。
三、组织：CoE 不是万能药
卓越中心这个模式被讲得太多，失败案例反而少有人提。我见过两种典型走法：一种是 CoE 慢慢变成了审批部门，所有 AI 项目都要过它一道，最后变成瓶颈；另一种是 CoE 只负责做 Demo 和宣讲，业务部门看完觉得不错，回头自己找人重做一遍。
Hub-and-Spoke 本身没问题，问题在于边界没划清：中央管标准、平台和跨部门复用，各业务单元的 AI 人员管落地。派驻的人要向业务负责人汇报，不然他永远是外人。
双轨所有权这条是对的，但得写具体。技术团队对模型指标负责，业务负责人对钱负责。注意是「负责人」，有名字的那种，不能写成「业务部门」。责任落到部门，等于没有责任。
四、四步走，以及每步最容易翻车的地方
- 战略锚定。CEO 或 COO 挂帅，别让 IT 自己立项自己验收。挑一两个账算得清的用例，跟 CFO 一起把「成功」定义成数字。这一步最常见的错，是选了一个看起来很 AI、但业务上没人真的痛的场景。
- 基建先行。第一个项目别指望它赚钱。它的真实产出是数据管道、部署流程、评估方法，这些东西第二个项目能直接复用，第一个项目就算成功。反过来，如果每个项目都要重新搭一遍，说明基建没沉下来。
- 重构工作流。别把 AI 塞进旧流程里。找一线的人把端到端流程画出来，先看哪几步能直接去掉，再谈加速。人类在环要设退出条件，否则它会变成永久的人工补丁。
- 规模化运营。把试点当产品管：有产品经理、有 SLA、有迭代节奏。封成能力包向外复制是对的，但别做成只有 PPT 的能力包。
最后
AI 转型的难点从来不在模型本身。数据能不能用、模型上线后有没有人盯、出了事谁签字，这三件事解决不了，再好的算法也只能停在演示阶段。
文里提到的成熟度诊断模型和落地清单，整理在 apd.cn 的专题页里，需要的话可以直接去看：企业 AI 转型实战指南。