R

A05 AI 项目失败的组织归因

创建 2026-06-07 更新 2026-06-11 1 条双链 组织采纳 专题 AI 整理

一个 80% 失败率的项目类别，要怎么读它的失败？本节点要解决的问题是：当一个 AI 项目”技术选型对了、模型也跑通了 demo，却在企业里彻底烂尾”，我们该把账记在谁头上——模型、数据、还是组织？这不是事后追责的口水仗，而是 PM 最贵的一次判断：归因错了，就会修错地方。如果把组织失败误读成技术失败，你会换模型、加算力、招算法工程师，而真正的病灶——数据孤岛、流程不配、激励不对、无人 owner——一个都没动。本节的视角是归因诊断学（attribution diagnostics）：借社会心理学的”归因偏差”与组织行为学的”失败根因分析”，把”AI 项目为什么死”从技术叙事里抢回来。

§0 为什么是”组织归因”而不是”技术归因”

读者脑中默认的失败框架几乎都是技术框架：模型不够强、幻觉太多（见 幻觉）、上下文窗口太小、推理太贵。这个框架不是错，而是系统性地选错了解释层。

先把两个框架摆清楚：

框架核心命题修复动作失效场景
技术归因项目死于模型/数据/算力能力不足换模型、加 GPU、做 RAG、招算法当 demo 已跑通、能力足够时，继续投技术=药不对症
组织归因项目死于组织没准备好接住这个能力拉通数据、改流程、对齐激励、设 owner当能力确实是硬天花板（如要求超出当前 AI 边界）时，组织再努力也白搭

判断主轴在此立住：多数企业 AI 失败是组织失败，不是技术失败。这句话有据可查的最硬支撑来自 RAND Corporation 2024 年 8 月的报告 The Root Causes of Failure for Artificial Intelligence Projects（Ryseff, De Bruhl, Newberry；基于 65 名 5 年以上经验的数据科学家/工程师深度访谈，报告号 RRA2680-1）。RAND 列出的五大根因——问题定义失准、训练数据不足、技术优先心态、基础设施缺口、问题超出 AI 能力边界——前四个是组织性的，只有第五个是技术性的。换句话说，这家以国防研究著称、方法论极硬的机构，逐条访谈后得出的结论是：技术不是主犯。

但 §0 的任务不是宣判技术无罪，而是挡掉两种相反的错误框架：

  • 错误框架 A（技术决定论）：默认 AI 失败=技术不行。这是本节主要反对的。
  • 错误框架 B（组织万能论）：以为只要组织变革到位，任何 AI 项目都能成。这是 RAND 第五条根因要挡的——当任务超出当前 AI 能力边界（如要求模型做可靠的多步因果推理），再好的组织也救不活。

所以本节点的精确立场是：在”能力足够、却部署失败”的项目里，组织归因解释力远大于技术归因；但归因诊断的第一步，恰恰是先排除”能力天花板”这个技术前提。 这是一个有边界的判断，不是”组织决定一切”的口号。

§1 四类组织病灶：数据孤岛 / 流程不配 / 激励不对 / 无 owner

把”组织失败”这个大词拆成可操作的四个病灶——这是 PM 在选型会和复盘会上真正能指着说”问题在这”的东西。

病灶症状demo 阶段为何看不见生产阶段为何致命
数据孤岛模型要的数据散在 17 个系统、口径不一、有漂移demo 用清洗过的受控样本数据生产数据治理不达标，模型拿不到喂养
流程不配现有业务流程混乱、不可测，AI 无处嵌入demo 在理想流程假设下跑Agent 要求流程稳定可测才能自动化（见 m207 - Agent 产品化：场景推演与失败模式）
激励不对用 AI 不算 KPI，省下的人力被算成”裁员风险”demo 阶段没人靠它考核一线没动机用、中层怕担责，采纳率归零
无 owner项目悬在 IT 与业务之间的”归属真空”demo 由创新团队临时托管没人对端到端结果负责，扩展期失去 C 级赞助

这四个病灶不是并列的，而是有因果链的：数据孤岛和流程不配是”基础设施级”病灶，激励不对和无 owner 是”治理级”病灶。Gartner（2025 年 2 月新闻稿，基于 2024 Q3 对 248 名数据管理领导者的调查）预测：到 2026 年，因缺乏 AI-ready 数据而被放弃的项目将达 ≥60%——这直接坐实”数据孤岛”是头号杀手。而 BCG 的 10-20-70 法则（《Where’s the Value in AI?》2024 年 10 月，n=1000 CxO，覆盖 59 国）给出了资源配比的反共识结论：AI 成功的决定因素中，算法只占 10%，数据与技术占 20%，人/流程/文化变革占 70%。现实中大多数组织的资源投入恰好倒置——把钱砸在 10% 的算法上，对 70% 的组织变革视而不见。

[!note] 数字的口径警告 “85% AI 项目失败”是被误引最严重的数字。它源自 Gartner 约 2018 年的一条预测，原义是”到 2022 年 85% 的 AI 项目会因数据偏差、算法错配而产生错误输出（erroneous outcomes）“——不是”项目失败”，更不是”项目被叫停”。传播中时态和语义双双丢失。引用失败率时务必区分口径：项目停止 ≠ 无 ROI ≠ 产生错误输出，三者数字差异极大（55%–95%），不可混用。

§2 归因偏差：为什么组织系统性地”修错地方”

如果组织失败是主因，为什么企业普遍把账记在技术头上？这里需要调度社会心理学的归因理论——它解释的不是”失败是什么”，而是”人为什么会把失败归错因”。

RAND 报告里藏着一张极有说服力的”感知 vs 实际”错位表：

企业认为的失败主因（感知）RAND 访谈揭示的实际主因
AI 人才短缺问题定义失准（最高频根因）
幻觉 / 模型质量差治理与变更管理缺失
算力成本太高数据基础设施差距
模型能力不足端用户未参与共同设计

左列全是技术 / 资源归因，右列全是组织 / 流程归因。这个系统性错位，正是社会心理学所说的基本归因偏差（fundamental attribution error，Lee Ross 1977 提出）的组织版变体：人倾向于把失败归于外部、可见、不涉及自身责任的因素（“模型不够强”），而非内部、隐性、指向自身组织缺陷的因素（“我们的流程没准备好""我们没设 owner”）。技术归因之所以诱人，是因为它免责——是 AI 不行，不是我们不行。

这正是”修错地方”的认知机制：归因偏差让组织把诊断指针永远指向技术，于是不断换模型、加算力，而真正的组织病灶因为”指不到自己”而被永久回避。

[!note] 跨域呼应：从社会心理学到组织防御 把归因偏差再往组织层推一步，会撞上 Chris Argyris 的组织防御性常规（organizational defensive routines，《Overcoming Organizational Defenses》1990）。Argyris 的洞察是：组织会无意识地建立一套”防御性惯例”，专门避免触及那些会让管理层难堪的根因。“AI 项目失败因为模型不行”恰是一条完美的防御性叙事——它把失败外包给技术供应商，保护了内部的流程缺陷和无 owner 的治理真空不被审视。归因偏差是个体认知 bug，组织防御是把这个 bug 制度化。 这解释了为什么即便 RAND 这类报告反复指出组织根因，企业的修复动作仍年复一年地落在技术侧——不是不知道，而是组织有动机不去知道。这一层呼应可链入 0117社会学 的组织社会学脉络。

§3 跨域归因：把”事故根因分析”搬进 AI 失败诊断

AI 项目失败的归因，不该是 AI 领域的独创发明。安全工程、医疗事故、航空事故领域，几十年前就建立了成熟的根因分析（Root Cause Analysis）与系统性事故归因方法论。把它们迁移过来，能给 AI 失败归因一个比”技术 vs 组织”二分更精细的工具。

最值得借的是 James Reason 的瑞士奶酪模型（Swiss Cheese Model，《Human Error》1990）。Reason 的核心命题是：重大事故几乎从不源于单一原因，而是多层防御（每层都像有孔的奶酪片）的孔恰好对齐，让风险一路穿透。对 AI 项目失败的迁移：

  • 第一层孔：问题定义失准（业务方说不清要 AI 解决什么）
  • 第二层孔：数据孤岛（要的数据拿不到）
  • 第三层孔：流程不配（AI 没处嵌入）
  • 第四层孔：激励不对（没人有动机用）
  • 第五层孔：无 owner（没人对结果负责）

任何一层”补上”都可能救活项目；五层孔全对齐，项目必死。这个模型的 PM 价值在于：它把”AI 失败”从寻找单一替罪羊（“都怪模型”）转向识别防御层的系统性缺失。这正是 Reason 区分的”人因错误”（active failures，前线操作失误）与”潜在条件”（latent conditions，组织决策埋下的隐患）——AI 项目的失败，绝大多数是潜在条件，是组织早在选型前就埋下的孔。

跨域迁移也带来一个反例校准：航空安全的归因文化是”无指责文化”（just culture），因为追个人责任会让人隐瞒错误。但 AI 项目的”无 owner”病灶恰恰相反——问题不是追责太狠，而是根本没人可追。这说明跨域框架不能照搬：瑞士奶酪模型的”多层防御”诊断框架可迁移，但它的”无指责”治理处方在 AI 治理真空场景下需要反过来用——先建立 owner，才谈得上无指责。

§4 判断主轴：归因诊断的四个致命错位

这是本节点的命门。90% 的 PM 在 AI 失败归因上会踩的四个坑，每个带”症状 → 为什么会错 → 正确做法 → 真实反例”四件套。

错位一：把”demo 成功”当成”能力已验证”，于是把生产失败归给技术执行

  • 症状：demo 惊艳，上线拉胯，结论是”工程没做好，再优化模型”。
  • 为什么会错：demo 和生产是两个分布——demo 用清洗数据、理想流程、无合规约束；生产面对脏数据、混乱流程、安全审查。失败不在技术，在组织没把生产环境准备到 demo 的假设水平。
  • 正确做法：归因前先问”demo 的成立条件，生产环境满足几条？“——把数据质量、流程稳定性、合规通道逐条对账。
  • 真实反例：IDC×Lenovo CIO Playbook 2025（样本 3120 人）显示，每 33 个 AI PoC 仅约 4 个（≈12%）进入生产。IDC 分析师 Ashish Nadkarni 直言：“大多数 PoC 的启动并非因为强有力的商业案例”——高管受 AI 营销压力驱动，GenAI 项目审批门槛低于常规 IT。这意味着大量项目从立项就缺组织前提，根本不是技术问题。

错位二：把”无 ROI”等同于”项目失败”，归因时混用不同口径的失败率

  • 症状：拿”95% 失败”吓人，却不说这个数字测的是什么。
  • 为什么会错：MIT NANDA《The GenAI Divide》（2025，Challapally 等，300 项公开部署+52 家机构访谈+153 名高管问卷）的”95%“指的是GenAI 试点未实现可衡量 P&L 影响，不是”项目全部失败”。且该报告被 Marketing AI Institute（2025-08）批评：成功定义过窄（仅计六个月内可量化 KPI），忽略效率与成本价值，“零回报”结论来自仅 52 次访谈，研究者自承”方向性准确”而非精确基准。
  • 正确做法：归因前先锁定”失败”的定义——是没上线、还是上线无 ROI、还是输出有错。不同定义对应不同病灶。
  • 真实反例：BCG 的 74%（“难以实现并规模化 AI 价值”，大样本跨国）与 Menlo Ventures 的 47% 商业转化率（高于传统 SaaS 的 25%）看似矛盾，实则测的是两件事——前者是企业内部项目成功率，后者是商业化 AI 产品采纳率。混用就会归错因。

错位三：把”员工不用”归给”产品体验差”，而非”激励不对”

  • 症状：采纳率低，结论是”UI 不好用，再迭代功能”。
  • 为什么会错：在企业内部，员工用不用 AI 工具，激励结构比产品体验更决定行为。省下的工时若被算成”你不忙了=可以裁员”，再好用的工具员工也会抵触。这是经济学的激励相容问题，不是产品问题。
  • 正确做法：归因采纳失败时，先查激励——用 AI 是否计入考核？省下的产能去了哪？中层用 AI 出错是否比不用更担责？
  • 真实反例：MIT NANDA 报告同时指出，失败核心是”学习机制缺失、系统集成不足、缺乏场景适配”——而非产品本身不好。员工大量用个人账号的 ChatGPT 而不用公司部署的工具，恰恰说明问题不在 AI 能力，在公司工具与激励/工作流的错配。

错位四：把”没有 owner”当成”协调问题”，而非”治理结构缺陷”

  • 症状：项目推不动，结论是”再开个对齐会、加个项目经理”。
  • 为什么会错：“无 owner”不是缺一个协调人，而是没有任何人对端到端结果（跨 IT–业务边界）负责且有权调动资源。加项目经理而不给权，只是给治理真空盖了块布。
  • 正确做法：归因时区分”协调不足”（缺会议）与”问责真空”（缺有权有责的 owner）。后者要的是组织结构调整，不是多开会。
  • 真实反例：McKinsey《The State of AI》（2025 年 3 月，约 2000 人、105 国）发现：AI 高绩效企业拥有强高层领导参与度的概率是普通企业的 3 倍，进行”工作流根本重设计”的概率是 2.8 倍（55% vs 20%）。差距不在协调频率，在有没有一个有权重塑工作流的 owner。

§5 产品 PM 视角补盲：归因的三个非工程盲点

跳出”工程 PM”视角，AI 失败归因还有三个最容易看走眼的非技术维度。

用户心理盲点：归因偏差也发生在用户身上。 一线员工解释自己不用 AI 时，会说”它不准""它幻觉”（技术归因），但真实原因往往是”我用它出错要担责，不用它没人怪我”（激励/心理安全归因）。PM 若照单全收用户的技术归因，就会去优化准确率，而真正要修的是心理安全——让员工敢试、敢错、敢问而不被罚（Prosci、Centric Consulting 反复强调”心理安全是 Change Champion 工作的前提”）。

商业模式盲点：失败归因要算”商业案例的虚实”。 如 IDC 指出的，很多 PoC 立项时根本没有真实商业案例，是被 AI 营销 FOMO 推上马的。这类项目”失败”其实是伪需求的正常死亡，归因时不该记到技术或组织执行头上，而该记到立项治理头上——审批门槛太低本身就是组织病灶。

合规边界盲点：从沙盒到生产的死亡谷常被误读为技术问题。 demo 在沙盒里跑得欢，进生产却卡在安全审查、监管合规、可解释性要求上。PM 容易把这归为”工程化没做好”，实则是组织没有为 AI 建立合规通道——这是治理缺失，不是技术缺失。在 Rick 熟悉的滴滴/99 场景里（涉及安全感知、费用治理、用户数据），这条合规通道的缺失足以让一个技术完备的 AI 项目永远停在沙盒。

§6 对手框架回应：组织归因会不会是另一种”免责叙事”？

业界反方立场（接受 + 边界）： Andrew Ng 等技术派长期主张”AI 落地的瓶颈本质是数据工程问题”——脏数据、标注不足、数据管道脆弱才是真凶，“组织变革”是软话，落不到实处。

接受它对的部分： Ng 是对的——数据确实是高频根因。Gartner 60%、RAND 第二条根因都坐实了。把”组织失败”喊成空洞的”要重视文化变革”，确实是逃避具体工程债的软话。

但坚持本节的边界： 数据问题本身的根仍是组织的——数据孤岛不是技术现象，是组织把数据分割在各部门、各自为政、无统一治理的结果。修数据管道是工程动作，但为什么数据会孤岛、为什么没人统一治理是组织问题。Ng 的框架在”修复层”是对的（确实要做数据工程），但在”归因层”仍把果当成了因。

Rick 未读的对手框架引入（破 echo chamber）： 这里要引入两个本专题作者不熟悉的反方框架来逼问自己：

  1. Melvin Conway 的康威定律（1968）：“设计系统的组织，其产出的系统结构必然复制该组织的沟通结构。” 对 AI 失败归因的逼问：如果失败是组织结构的镜像，那么”修组织”可能比”修 AI”还难——你不是在调一个参数，是在重组人与权力。这给”组织归因”泼了盆冷水：诊断出组织病灶容易，真要修组织，阻力可能远超换模型。这是组织归因框架自身的失效边界。

  2. 归因理论里的”自利偏差”反向版：组织也可能反向滥用组织归因——把所有失败都归给”文化没到位""员工没准备好”，从而免除技术选型者和决策层的责任。也就是说，“组织归因”如果被滥用，会变成另一种基本归因偏差：把责任从”我们选错了技术/定错了问题”推给”组织/文化/员工”这个模糊集体。本节坚持组织归因，但承认它有被武器化为新免责叙事的风险——这正是下面 failure scenario 要标注的。

failure scenario 显式标注： 本节”多数 AI 失败是组织失败”的结论，在以下场景失效：(a) 任务超出当前 AI 能力边界（RAND 第五条根因，如要求可靠多步因果推理）——此时组织再努力也救不活，归因就该是技术；(b) 在初创公司/小团队场景——没有数据孤岛、没有跨部门壁垒、owner 就是创始人，组织归因的解释力大幅下降，技术能力成为主导变量。

§7 PM 决策启示：三类落地

面试怎么用： 当面试官问”你怎么看 AI 项目高失败率”，不要复读”模型不够强”。用归因诊断框架答：先区分失败口径（停止/无 ROI/错误输出），再用 RAND 五根因+BCG 10-20-70 指出”前四根因和 70% 决定因素都是组织性的”，最后用归因偏差解释”为什么企业系统性修错地方”。这一套能 30 秒把你从”会用 AI 的 PM”升级成”会诊断组织的 PM”。

选型怎么用： 选型会上别只比模型 benchmark。拿出”四病灶检查清单”——数据能不能拿到（孤岛）、流程能不能嵌入（不配）、用了算不算 KPI（激励）、谁对结果负责（owner）。任何一项打叉，再好的模型选型都救不活这个项目。 把这张清单当成选型的前置门槛，而非事后复盘。

复现怎么用： 复现一个失败的 AI 项目时，用瑞士奶酪模型做根因分析——别找单一替罪羊，逐层排查五个孔哪些对齐了。先排除”能力天花板”（技术前提），再逐层诊断组织防御层。这能避免”换了三个模型还是失败”的重复踩坑。

§8 与已有节点的关系

  • 对 m207 - Agent 产品化：场景推演与失败模式 的升级对照（不复述）：m207 §2.4.4 讲的是 Agent 的技术性失败模式（规划失败、工具调用失败、推理错误、无限循环、雪崩效应、安全越界）——那是”系统内部”如何走样。本节点升高一个抽象层，讲”系统外部”——同一个技术完备的 Agent，为什么在组织里部署失败。两者是互补的：m207 回答”AI 自己怎么坏”，A05 回答”组织怎么把好 AI 用死”。不复述 m207 的六类技术失败模式。
  • 对 m208 - AI 基础设施与中间件选型 的对话：m208 解决”选型对不对”的技术判断，本节点恰恰从”选型对了仍失败”切入，是 m208 的反面接续——选型正确只是必要条件，组织接得住才是充分条件。
  • 对 p307 - Copilot 到 Autopilot 光谱 的呼应：p307 §3.7.2 讲依错误成本/任务结构化程度选自动化层级——本节点的”流程不配”病灶正是 p307 选层失败的组织前因：流程不可测，连 L1 都嵌不进去。
  • 与本专题同级节点的关系：本节点是 01 概念辨析层对”失败归因”的概念奠基，为后续讨论 Crossing the Chasm（鸿沟）、Kotter 八步、组织 AI literacy 的节点提供共同的归因语言——它们都是在回答”组织这一侧具体怎么修”，而 A05 先回答”为什么该往组织这一侧看”。

§9 关联节点

核心（必读）

延伸（可选）

修订日志

  • R1（2026-06-07）：首稿。建立”归因诊断学”主轴；四病灶（数据孤岛/流程不配/激励不对/无 owner）+ 因果链；调度社会心理学归因偏差（Ross 1977）、Argyris 组织防御、Reason 瑞士奶酪模型三个跨域框架；判断主轴四错位（demo≠能力验证 / 失败口径混用 / 不用≠体验差 / 无owner≠协调问题）各配四件套；对手框架接入 Andrew Ng（数据派）+ 引入未读框架康威定律与”组织归因被武器化”反向风险；标注 2 处 failure scenario（超 AI 能力边界、初创小团队）；接地 RAND RRA2680-1、BCG 10-20-70、Gartner 60%、IDC×Lenovo 12%、McKinsey 3x/2.8x、MIT NANDA 95% 及其口径争议；澄清”85% 失败”误引溯源。