IDC 调查结果让 AI 项目成效受到 CIO 审视
IDC 的研究引发了一场围绕 AI 项目失败的 google news 讨论,其中一则标题声称,45% 的项目没有产生任何成果。
但其背后的证据需要更谨慎地解读。与 IDC 相关的研究称,平均而言,只有 45% 的 AI 计划实现了可衡量的成果。根据组织对成功的定义,这一发现意味着实际的价值缺口可能比标题所暗示的更大。
这一区别至关重要,因为 CIO 受到评判的标准已不再是启动了多少 AI 试点项目。董事会如今期待看到可衡量的回报、安全的部署,以及能够在自主智能体投入生产后对其进行控制的治理机制。
这正是标题背后的真正冲突。企业领导者希望 AI 系统能够以更高自主性完成更多工作。然而,同样的自主性也让成本、决策、权限和故障更难受到约束。
因此,IDC 描述的不只是又一个令人失望的技术周期。它记录的是责任从实验性 AI 团队转移到 CIO 身上的过程——后者必须为业务成果和运营风险负责。
IDC Google News 报道实际表达了什么
报道中的 45% 衡量的是实现可衡量成果的计划,而非每个企业 AI 项目的普遍失败率。
最初的 google news 标题将 45% 的 AI 项目描述为未能取得成果。然而,与 IDC 相关的支持材料对这一统计数据给出了不同表述。
一篇 Fujitsu 分析引用了 IDC 于 2025 年 9 月发布的《Technology Investment and Innovation Monitor》。该分析称,全球平均有 45% 的 AI 计划实现了可衡量的成果。
根据 Fujitsu 的引用,该研究覆盖了 894 名受访者。研究还发现,只有 11% 的组织表示,其超过四分之三的 AI 项目取得了成功。
这些衡量结果并不能证明恰好有 45% 的项目失败。它们表明,45% 的项目产生了可衡量的成果,剩余 55% 则在该调查的衡量方法下未能展示出明确成果。
这一缺口可能包含多种情况。项目可能仍处于测试阶段,可能已投入生产却未产生可衡量价值,可能未达成原定目标,或可能缺乏足够数据进行评估。
这些是不同的结果。将它们合并为单一失败率,虽然能形成更简洁的标题,却无法准确反映企业实际表现。
现有证据也无法证明,底层 AI 模型导致了每一个表现不佳的结果。业务采用、工作流设计、数据质量、运营成本以及指标不明确,都可能阻碍价值实现。
这一区别将技术失败与组织失败区分开来。模型可以生成可接受的输出,但其所在的项目仍可能无法实现业务目标。
例如,一名内部助手或许能准确回答员工的问题。但如果员工不愿使用它、回答速度过慢,或支持成本超过节省的成本,它在商业层面仍然失败。
预测模型也可能在受控测试中表现出色。但如果管理者仍通过忽略其建议的旧流程作出决策,它带来的价值就十分有限。
IDC 更广泛的研究支持这一解读。该机构表示,组织很难将实验与可衡量的业务成果联系起来,尤其是在从未定义基线指标的情况下。
这也是为什么该标题值得审视,但不应被完全否定。准确的百分比仍取决于定义,但其背后的价值问题已有充分证据支持。
其他研究也指向相同方向。CIO.com 的 2026 年调查发现,只有 19% 的受访者表示,其 AI 计划达到了或超过了业务目标。
State of the CIO 研究覆盖了 662 名 IT 领导者和 249 名业务用户。研究发现,18% 的受访者表示,不到三分之一的用例达到了预期。
这些研究采用了不同的样本和定义,因此其百分比不应被视为直接对比。但它们共同表明,可衡量的企业价值仍不常见。
负责任的结论比病毒式传播的说法更为克制。许多组织无法证明大多数 AI 计划持续带来了回报,而 CIO 现在必须解释其中原因。
这一结论已经足够严肃,无须夸大数字。
AI 实验正让位于 ROI 任务
核心变化并非对 AI 的兴趣减退,而是不再为没有明确负责人、基线和业务成果的实验提供资金。
尽管回报仍难以证明,企业对 AI 的投资仍在继续。这一看似矛盾的现象反映的是竞争压力,而非对每个项目都充满信心。
董事会担心减少投资会让公司落后于竞争对手。同时,他们也希望 CIO 证明现有支出能够改善营收、成本、客户服务、韧性或决策速度。
这为技术领导者划出了一条更窄的道路。他们必须维持采用势头,同时终止那些无法证明其运营负担合理性的项目。
IDC 报告称,42% 的组织认为数字化和 AI 投资的 ROI 难以或根本无法评估。该机构认为,不一致的基线和有限的长期可见性是主要障碍。
其 智能体 ROI 框架认为,智能体系统让这些问题更加棘手。随着工作流、模型和使用模式的演变,它们的价值和成本也会发生变化。
传统软件通常支撑着相对稳定的商业案例。买方会在部署前估算实施成本、许可需求、预期用户数量和流程节省。
智能体 AI 的行为则不同。智能体是一种软件,能够规划步骤、使用工具,并在有限人工干预下朝着目标采取行动。
其运营成本会随模型调用、上下文规模、工具使用、重试和人工审核而变化。当业务条件或源数据发生变化时,其表现也可能随之改变。
因此,成功的试点只能提供不完整的证据。试点可能使用经过筛选的数据、较小的用户群体,以及生产团队无法长期维持的大量技术监督。
一旦广泛部署,同一系统就会面对不一致的输入、访问限制、罕见情况,以及以意外方式使用它的员工。
TIAA 高管 Sastry Durvasula 在 CIO.com 的报道中描述了这种矛盾。他表示,在组织将运营成本纳入考量后,一个成功的试点仍可能难以产生真正的 ROI。
这些成本包括 token 消耗、流量处理、集成维护、评估、安全审查和支持。它们很少会出现在早期演示中。
新的 CIO 任务始于在构建之前定义价值。项目需要一个可衡量的基线,以显示在没有 AI 的情况下该流程的表现。
它还需要一位能从结果中受益的业务负责人。当另一个部门控制采用和工作流变更时,技术团队无法独立认证业务价值。
CIO.com 发现,83% 的受访 IT 领导者已建立跨职能 AI 架构,或计划在当年内实施此类架构。然而,正式审批和衡量机制仍不够成熟。
只有 53% 的组织拥有正式的 AI 项目审批流程。另有 28% 计划在未来 12 个月内引入此流程。
47% 的受访组织已建立正式指标,34% 计划建立。这一缺口有助于解释为何部署与可衡量回报常常出现背离。
如果组织从未记录原始流程的成本、错误率、完成时间或客户结果,就无法证明改进。
结果是一次问责倒转。早期 AI 项目奖励试点规模和可见的实验活动。下一阶段则奖励严谨的筛选和可复制的价值。
这一转变也改变了与供应商的沟通方式。当买方无法将模型质量映射到运营结果时,关于模型质量的主张就不再那么重要。
CIO 越来越需要覆盖整个工作流的证据。他们必须衡量员工是否使用系统、输出质量是否保持稳定,以及成本是否维持在限额内。
他们还需要设定停止规则。持续未达到采用、质量或财务门槛的项目,应在成为永久性基础设施之前失去资金支持。
这种做法并不代表敌视 AI。它只是以同样的纪律对待 AI 支出和其他战略投资。
主要冲突在于 AI 承诺与运营现实之间
企业 AI 项目往往在令人信服的演示与真实工作所处的复杂环境之间的边界上失败。
这个故事中的主要对手并非某一家 AI 供应商与另一家供应商,而是快速实现 AI 价值的承诺与企业运营现实之间的矛盾。
演示通常会隔离一项狭窄任务。生产系统则必须应对权限、过时记录、相互冲突的政策、不完整的数据,以及多个相互依赖的应用程序。
每增加一项依赖,就增加一条故障路径。模型可以返回看似合理的答案,但不可用的工具、过时记录或错误权限仍可能阻止所需操作。
数据质量也带来类似问题。AI 系统可以总结、分类或检索信息,但无法修复分散在企业存储库中的每一处矛盾。
一名支持智能体可能遇到同一退款政策的三个版本。如果缺乏权威来源和版本历史,它可能会自信地选择错误规则。
知识工作也带来了另一项衡量挑战。如果员工需要花费节省下来的时间审查不可靠输出,更快地起草内容并不会自动创造财务价值。
项目必须衡量整个流程。这包括准备、生成、审核、纠正、升级,以及任何下游错误。
这正是 knowledge blending 方法可能变得相关的地方。将经批准的来源与工作上下文结合,能够减少检索缺口,但治理机制仍决定哪些材料值得信任。
工作流采用同样重要。当新系统增加步骤、要求使用不熟悉的界面,或无法处理罕见情况时,员工往往会绕过它。
这种行为在有赞助的试点期间可能仍不可见。参与者会获得培训和支持,而普通用户则面临相互竞争的优先事项。
因此,成功采用需要流程重构,而不只是获得模型访问权限。团队必须决定哪些任务发生变化、哪些审批仍然保留,以及由谁处理例外情况。
辅助与自主之间的区别进一步提高了风险。一名写作助手会提出供人审阅的文本。一名智能体则可以创建工单、修改记录、联系客户或触发交易。
不准确的建议会增加审核时间。不准确的自主操作则可能在人类察觉前改变真实系统。
IDC 的研究认为,组织不应将智能体技术应用于每一项任务。对于规则明确且稳定的流程,确定性自动化仍然更为合适。
当工作需要多个步骤、不断变化的上下文、判断,以及跨工具协调时,智能体系统更有意义。即便如此,自主性也必须产生足以证明额外风险合理性的价值。
这种用例纪律有助于解释 IDC 关于 AI 项目失败的争论。一些薄弱项目始于一项正在寻找问题的技术。
团队先选择模型或 agent 平台,然后再寻找能够支撑这项采购的工作流。
这种顺序往往会产生有趣的原型,但其运营重要性有限。由于项目并非源于经过衡量的需求,因此没有任何业务部门对结果负责。
更有力的顺序始于成本高昂或受限的工作流。团队记录其基线,识别其中涉及的决策,并测试 AI 是否能改善整体结果。
比较还应纳入传统软件和流程变更。AI 应当因适合该问题而胜出,而不是因为高管要求开展 AI 计划。
组织还必须区分生产率与可获取价值。为员工节省几分钟时间,并不自动具有财务意义。
只有当这些时间能提高产出、缩短客户响应时间、增加产能,或降低已识别的成本时,公司才能获取价值。
员工体验和韧性仍然可能很重要。然而,领导者必须定义如何衡量这些收益,而不是在财务目标未达成后将其当作方便的解释。
IDC 因此提出了更广泛的价值映射。其框架除了传统财务指标外,还包括客户信任、韧性、可持续性和时间维度。
这一更广泛的模型不应成为模糊成功主张的借口。每个维度仍需要负责人、基线、衡量方法和审查日期。
因此,实际运营情况不像模型崩溃那样戏剧化,但更难修复。它需要技术、财务、安全、法务和业务团队之间的协调。
任何模型更新都无法自动创造这种协调。
Agentic AI 治理将安全转化为业务约束
Agentic AI 治理决定了自主性能否安全扩展,因为 agent 会将不确定的输出转化为跨互联系统的行动。
安全始终会影响企业技术决策。Agentic 系统通过将模型不确定性与凭证、工具、记忆和运营访问权限结合起来,改变了问题的性质。
传统聊天机器人通常只返回信息。Agent 可以理解请求、制定计划、调用应用程序,并在收到新结果后继续采取行动。
这种能力扩大了攻击面。恶意内容可能影响 agent 的指令,而过度的权限可能将一次错误决策演变为更大的事件。
提示注入就是一个例子。攻击者将指令嵌入模型读取的内容中,试图将系统从其获授权的任务重定向出去。
当 agent 能够发送消息、修改数据库、检索机密记录或执行代码时,危险会进一步增加。误导性回应仅仅是可能的失败形式之一。
IDC 警告称,存在不受控制的决策级联、不透明行为和碎片化升级流程的风险。其治理分析将治理描述为运营基础设施,而不是最后的合规审查。
该机构预测,到 2030 年,多达 20% 的 Global 1000 组织可能面临诉讼、罚款或 CIO 被解职。IDC 将这一风险与 AI agent 治理薄弱导致的高调中断事件联系起来。
这是一项预测,而非已观察到的失败率。它表明潜在问责的规模,而非保证会出现的结果。
IDC 建议实现可追溯性、整合式治理和明确的问责闭环。这些控制措施有助于团队重建决策过程,并在行动越过既定边界前将其打断。
可追溯性意味着记录自主决策中涉及的数据、模型、指令、工具调用和输出。没有这些记录,团队便无法调查错误或为结果辩护。
整合式治理将安全、数据、法务、风险和业务所有权贯穿于系统的整个生命周期。仅审查模型的委员会无法治理完整工作流。
问责闭环定义了何时必须由人员批准、审查或停止一项行动。阈值应取决于可能造成的后果,而不仅仅是模型的置信度。
低风险行动可以获得更广泛的自主性。发送内部提醒与批准付款或更改客户账户,后果并不相同。
身份控制同样重要。每个 agent 都需要自己的身份、权限、负责人和用途,而不是借用开发人员或共享服务不受限制的凭证。
权限应遵循最小权限原则。agent 只能获得其指定工作流所需的访问权限,不应拥有更广泛的授权。
组织还需要可靠的清单。安全团队无法保护他们不知道存在的 agent,尤其是在部门能够在业务应用中配置它们时。
该清单应记录所有权、连接的系统、获批准的数据、模型提供商、评估结果和紧急控制措施。
上线后,持续评估变得必要。当模型更新、提示词演变、连接工具发生变化,或业务数据形成新的模式时,agent 的行为可能改变。
IDC 指出,随着上下文变化和边缘案例累积,性能可能下降。这使 agent 成为一项持续管理的服务,而非已完成的部署。
因此,安全与 ROI 交汇在一起。监控、评估、访问控制、事件响应和人工审查都会增加运营成本。
排除这些控制措施的商业案例会呈现出人为偏高的回报。为保护预测而移除它们,只是将财务压力转化为安全风险暴露。
这是 CIO 必须管理的核心权衡。更高的自主性可以提高速度和产能,但也会增加保障成本。
答案不是对每项行动进行无限制审查。那会抹去 agent 得以被采用的效率优势。
组织需要基于风险的自主性。它们可以自动化可逆、可观察的行动,同时要求对具有法律、财务或安全后果的决策进行人工批准。
Agentic AI 治理还必须涵盖停机程序。团队需要能够在事件期间撤销凭证、停止工作流、隔离记忆并保全证据。
如果没有这些能力,当多个团队争论所有权时,agent 仍可能继续运行。即便模型完全按设计运行,这也是组织控制的失败。
这些数字仍无法证明什么
现有统计数据表明存在广泛的价值问题,但并不支持一个适用于所有 AI 项目的统一失败率。
Google 新闻的叙事框架鼓励二元解读。一个项目要么成功,要么失败,用一个百分比概括整个市场。
企业部署很少符合这种模型。一个项目可能达到技术基准、未达到采用目标、保持在预算范围内,却仍未产生可衡量的收入。
另一个项目可能超出最初成本,却创造了具有战略重要性的知识或客户收益。它是否算成功取决于评估框架。
问卷措辞也会改变结果。“交付了可衡量的成果”不同于“符合预期”、“进入生产环境”或“产生财务回报”。
样本选择同样重要。针对技术领导者的调查可能会得出与针对业务用户、财务团队或单个项目的研究不同的结果。
分母还带来另一个问题。一些研究统计每一个原型,另一些则只包括生产部署或高级领导者知晓的计划。
时间跨度也不同。AI 系统可能需要数个季度的工作流重构和采用,收益才会显现。
在一个季度后就宣布其失败,可能为时过早。无限期继续却没有证据,可能浪费更多资本。
这些局限性并不会使 IDC 的发现失效。它们界定了读者能够从中负责任地得出的结论。
最有力的结论是,企业难以衡量和复制 AI 价值。最薄弱的结论则是,所有项目中有一个固定百分比都因同一原因而明确失败。
这种区分也会影响问责。如果模型被自动归咎,组织可能更换供应商,却保留导致结果不佳的工作流、数据和治理问题。
如果每个问题都被归咎于组织准备度,供应商就可以逃避对不可靠产品的责任。这两种叙事都值得审视。
模型质量仍然重要。幻觉、不一致的推理、延迟、有限上下文和工具使用错误,都可能使应用不适合生产环境。
供应商设计也很重要。买方需要可用的审计日志、权限控制、模型变更通知、评估工具和可预测的服务行为。
组织仍有责任选择合适的用例并安全地配置访问权限。供应商仍有责任准确描述能力与限制。
因此,IDC 关于 AI 项目失败的讨论应当带来更好的问题,而不是一个方便的单一罪魁祸首。
项目原本要改善什么基线?哪位业务负责人接受了目标?安全和运营成本是否在批准前就已纳入?
试点支持结束后,员工是否仍在使用该系统?在罕见案例和变化的数据中,输出质量是否仍可接受?
发生错误后,团队能否重建 agent 的行动?他们能否立即停止工作流,而不禁用无关系统?
这些问题将一条有争议的标题转化为运营审查。它们也比“试点是否按计划上线”更难回答。
一项独立比较进一步强化了保持谨慎的必要性。Gartner 报告称,45% 的高成熟度组织让 AI 项目至少持续运行了三年。
其AI 成熟度调查将长期运行与成熟实践联系起来,但长期运行本身并不能证明业务价值。
一个项目可能因战略或政治原因持续运行。一个项目也可能在成功将其能力转移至另一个平台后结束。
没有单一指标可以涵盖全部结果。组织需要投资组合视角,将技术性能、采用情况、财务影响、风险和战略价值区分开来。
该投资组合应包括未成功的项目。隐藏被放弃的试点会造成误导性图景,并阻碍团队识别反复出现的原因。
它还应区分健康的取消与失控的失败。及早终止一个薄弱项目,可以体现有纪律的治理,而非糟糕表现。
一位 CIO.com 消息来源将终止约三分之一已启动项目描述为健康做法。该组织采用阶段性资金投入和成果检查点,防止薄弱工作持续消耗长期资源。
这种方法重新定义了失败。危险的项目并不总是停止的那个。它也可能是在无人负责决策的情况下、没有证据却持续推进的那个。
CIO 接下来应关注的三个信号
下一项考验是,组织是否以成果报告、受控自主性以及员工在真实工作流中使用 AI 的证据,取代试点数量。
第一个信号是正式 AI 价值行动手册的采用。IDC 预计,到 2027 年,60% 的亚太地区 500 强 CIO 将被赋予制定此类手册的任务。
价值手册将用例选择、基线、成本模型、责任归属和审查阈值标准化,使领导者能够依据一致的证据比较项目。
如果企业开始关停缺乏可衡量成果的项目,这一信号将强化 IDC 的论点。若正式衡量范围扩大,却未能改善项目组合表现,则会削弱这一论点。
关键指标并不是发布了多少份手册,而是生产环境计划中拥有明确负责人、基线、完整运营成本和预定成果审查的比例。
董事会还应关注组织如何报告间接收益。客户信任、韧性和更快的决策都可能很重要,但每一项都需要可观察的衡量方法。
第二个信号是可执行的智能体控制措施的部署。仅靠政策无法治理持续跨业务系统行动的软件。
CIO 应追踪有多少智能体拥有专属身份、受限权限、完整操作日志、人工升级规则以及经过测试的停用程序。
安全团队还应按严重程度和根本原因报告事件。事件数量上升,既可能反映安全状况恶化,也可能说明此前隐藏的活动获得了更好的可见性。
更有意义的趋势是:随着智能体使用范围扩大,严重事件是否在减少。组织应将事件率与智能体操作次数、连接系统数量及风险等级进行对比。
IDC 对亚太地区的展望预测,智能体控制不足将带来严重后果,包括法律风险和高管问责。如果自主部署的扩张速度快于技术监督,这一预测会更具可信度。
如果组织证明基于风险的控制措施能够随使用规模同步扩展,这一预测的可信度则会降低。证据应包括审计结果、隔离处置时间、权限违规情况,以及成功的人工干预。
第三个信号是与工作流成果挂钩的生产环境采用。试点准确率和员工热情无法替代日常运营中的持续使用。
CIO 应监控活跃使用情况、完成率、异常发生频率、审查时间,以及生成工作成果达到有效结果的比例。
他们还应衡量部署支持减少后会发生什么。一个依赖创建者持续干预的系统,尚未达到可重复的生产运行水平。
业务部门需要报告 AI 是否缩短周期、扩展产能、减少错误或改善客户成果。财务团队应核实所有声称实现的节省。
如果使用量增长而可衡量价值依然疲弱,这一信号将强化 google news 的叙事。这将表明,采用本身无法解决 ROI 问题。
如果成熟项目在计入全部安全和运营成本后,能在多个工作流中展现可重复的收益,则会削弱这一叙事。
这三个信号彼此关联。更好的价值模型能够选择更强的用例,更强的控制措施允许安全的自主运行,而持续的工作流采用会产生可衡量的证据。
缺少任何一个要素,结果都会变得脆弱。没有控制措施的盈利系统会带来隐性风险;没有用户的安全系统则无法创造价值。
没有基线衡量的热门系统会产生令人印象深刻的活动量,却带来不确定的回报。
CIO 应抵制用另一个笼统百分比来回应这场争论的压力。他们自己的项目组合能提供比汇总式标题更有用的证据。
他们可以先选定少量重要工作流,并记录当前表现。每个项目都应配备业务负责人、技术负责人、风险分类和审查计划。
团队应计算超出初始开发范围的成本。这些成本包括模型使用、集成维护、监控、评估、安全、支持和人工审查。
在授予自主权之前,他们应界定不可接受的结果。这些边界可涵盖数据暴露、财务限额、客户影响和被禁止的工具操作。
最后,他们应公布内部结果,包括已取消的项目。透明报告会让弱势项目更难仅凭热情维持下去。
因此,存在争议的 45% 说法可作为警示,而非通用评分卡。它揭示了不精确的衡量如何轻易演变成笃定的 AI 标题。
更好的回应不是围绕某一个 google news 百分比争论,而是要求证据证明:每个 AI 系统在计入全部成本和风险后,确实创造了价值。
在你的组织内部,哪些项目能经受住这项检验?又有哪些项目仍在获得资金,只是因为从未有人定义成功意味着什么?



