Google Cloud AI 调查发现：现有软件阻碍现代化进程

Google Cloud 于 11 月 9 日发布的调查结果显示，49% 的受访决策者认为，本地部署的软件导致技术计划延期或缩减。这些计划包括 AI，但该结果并未单独统计 AI 项目。Google Cloud AI 调查为企业中一个常见的矛盾提供了具体数字：维持现有运营与构建新能力彼此竞争。

这项与 Hypothesis Group 共同开展的研究调查了美国 1,250 名企业 IT 和业务决策者。Google 借此主张应提供更大的架构选择自由，并减少对既有供应商的依赖。其核心担忧可以理解：能够通过连续行动完成任务的 AI 智能体，会继承其所访问系统的局限性。

Microsoft 提供了一个有益的对照。其研究在强调员工采用的同时，更关注组织准备程度，而非将基础设施替换视为核心答案。两种观点共同体现的张力，在于扩大 AI 使用范围与让业务流程为其做好准备之间的平衡。对技术领导者而言，这会将讨论转向集成、运营责任，以及新增投入是否真正释放了稀缺的工程能力。

Google Cloud AI 调查实际衡量了什么

该调查衡量的是决策者报告的约束，而非证明某种特定现代化战略能够消除这些约束。

Google Cloud 风险与合规负责人 Jeanette Manfra 在一篇关于遗留软件调查的公告中介绍了这些发现。配套报告的日期为 2026 年 10 月，而其方法说明显示调研工作在 8 月进行。因此，这次发布提供的是对较早收集的经验的近期描述，而非对 11 月部署情况的实时测量。

一个重要定义影响了对结果的解读。该研究将本地托管或本地部署的企业软件归为遗留软件，并将其与托管于云端且由云端管理的软件对比。这一定义关注的是部署和管理安排。读者不应据此认为所涵盖的每个系统都已过时、缺乏支持，或在技术上不适合 AI。

这一差异很重要，因为部署位置与系统状态回答的是不同问题。本地运行的应用可能拥有清晰的接口和规范的维护。云端应用也可能包含混乱的记录、不一致的权限，或紧密耦合的业务规则。这两种情况都不与受访者的体验相矛盾，但都会限制采购方应从中得出的结论。

报告中的 49% 还合并了多种结果：延迟、范围缩减、暂停和取消。这些代表着不同程度的干扰。临时调整排期，与放弃一个项目所带来的业务后果并不相同。同样，由于还纳入了其他技术计划，该结果不能被视为 AI 项目的取消率。

这一限定并未削弱一项有意义的发现。受访者将其现有的软件安排与计划变革的障碍联系在一起。对于企业采购方而言，这表明在评估 AI 产品时，也应关注其周边环境。

不过，调查回应无法确定完整的责任链条。一个停滞的计划可能涉及应用限制、采购约束、专业能力缺失、优先级竞争，或不清晰的商业理由。同一个项目中可能同时存在多项原因。

因此，Google Cloud AI 调查最适合作为对组织摩擦感知的诊断。它让领导者有理由审视自身的依赖关系。它并未告诉他们应替换哪一款应用、选择哪一家供应商，或迁移是否应先于某项具体部署。

这种区别将有价值的研究信号与过于宽泛的采购结论区分开来。接下来的问题是谁必须解决这些摩擦，以及他们原本会把时间投入到什么工作中。

维护压力落在被期待交付 AI 的团队身上

直接压力落在既要保障运营连续性、又要交付新 AI 能力的团队身上。

工程组织不能仅因管理层设定了 AI 截止日期，就将现有工作视为可有可无。安全修复、访问权限变更、事件响应和应用支持仍然不可或缺。增加一项新目标，并不会自动创造实现它所需的能力。

这会带来一个仅看人员编制数字难以察觉的预算问题。一个团队表面上可能人员充足，但专业人员仍在处理需要其特定知识的系统。真正的约束往往是交付窗口期内可用的专业能力，而不是员工总数。

以一个帮助员工解决账户问题的内部服务智能体为例。给出看似可信的回答只是任务的一部分。周边流程必须识别员工身份、确定其获准访问的内容、检索当前信息，并将例外情况转交给负责人员。

如果该智能体能够修改账户，组织还需要审批规则和操作记录。一次有效的演示可以避开大量此类运营工作。生产级服务则不能依赖某人在事后手动修复每一个异常案例。

这些要求解释了开发人员和安全团队为何面临来自不同方向的压力。业务领导者希望看到可见的进展。运营团队必须维持可用性。安全审查人员需要足够的证据来批准访问权限。如果没有明确的优先级，集成工作可能会成为这些团队之间无人负责的依赖项。

维护也会影响推进顺序。替换一个应用最终或许能减少支持工作，但在收益出现前可能需要大量投入。过渡期间，团队可能既要支持现有流程，也要学习替代方案。因此，现代化提案需要说明临时工作负担。

这正是对“释放工程师”的宏大承诺应当受到审视的地方。关键问题在于，哪些重复性任务会消失、目前由谁完成，以及这些人员何时能够腾出时间。将责任转移给供应商可能有所帮助，但保留的集成和监督工作仍需要明确负责人。

采购团队面临相关挑战。他们必须区分采购产品的便利性与运营产品所需的投入。一份熟悉的合同可以简化采购，却未必能解决数据访问问题。一家不熟悉的供应商可能提供有吸引力的能力，同时也会增加另一套运营责任。

对知识工作者而言，后果表现为能力覆盖不均。某个助手或许能成功总结文档，却仍无法使用作出重要决策所需的记录。可见的 AI 界面发展速度，因而可能快于其背后的工作流程。

因此，压力既是组织层面的，也是技术层面的。领导层必须决定哪些依赖关系值得投入，以及哪些拟议项目应当等待。否则，每一个新试点都会争夺同一批人员，却无法改变拖慢此前项目的条件。

加入智能体并不会消除其底层工作

自动化提升了可靠业务接口的重要性，因为行动比建议需要更清晰的边界。

与其仅从软件部署位置出发，Google 的论点在具体工作流中更具说服力。一个提供建议的系统可以将执行交给人。获得行动授权的系统，则必须面对组织已明确规定的规则。

以一个采购申请为例。员工可能要求智能体使用获批供应商准备订单。描述这项语言任务很简单。业务任务则包括核验授权、选择正确账户、应用采购政策，以及处理缺货项目。

每个阶段都会引出流畅文本无法独立解决的问题。哪条记录具有权威性？申请人是否拥有权限？拟议采购是否符合政策？如果订单成功但确认失败，会发生什么？

这些问题揭示了生成答案与完成交易之间的差异。组织需要了解其系统中实际发生了什么，包括部分完成的情况。自信的对话式回应无法替代这类证据。

现有应用有时会编码员工通过经验理解、却未形成文档的规则。部署智能体可能会暴露这些隐性知识。表面上的集成问题，实际上可能涉及对政策、例外情形或责任归属尚未解决的决策。

替换应用未必能解决这些决策。它可以提供一个更好的表达场所，但仍需有人确定预期行为。这正是为什么现代化提案应明确其改善的业务边界，而不是仅依赖底层软件的年代来论证。

Google 自身关于客户服务部署的说明提供了一个具体例子。2025 年 4 月，该公司称 Wendy’s FreshAI 正在处理得来速点餐业务，并扩展至 24 个州。这些是公司报告的部署主张，而非对智能体普遍可靠性的独立证明。

尽管如此，这一例子仍说明了明确定义任务的价值。点餐具有可识别的输入、菜单限制，以及必须传递至餐厅运营环节的交易。其价值取决于与实际服务流程的连接，而不只是对话质量。

内部企业工作流同样需要类似的清晰度，即使其边界不那么明显。调查合同、准备续约或解决访问问题的请求，都需要一个明确约定的终点。否则，当智能体生成文本而下游员工仍需完成实质性工作时，团队仍可能宣称成功。

这使集成成为一个责任归属问题。必须有人负责从建议到获批行动、从行动到经验证结果的转换。没有这种责任归属，自动化可能重新分配工作量，却让业务流程基本维持不变。

最有力的现代化论证会识别这些转换环节，并证明其得到改善。其证据应显示未解决的交接更少、完成过程可靠，以及在发生问题时具备可控的恢复机制。

Google 和 Microsoft 强调了不同的就绪路径

两家供应商的侧重点不同，但两种观点都将组织准备视为有价值 AI 部署的核心。

Google 的立场将架构自由置于突出位置。Microsoft 关于组织 AI 就绪度的研究，则更强调管理、工作设计和评估。其 2026 年 5 月的报告基于对 10 个市场中 20,000 名 AI 使用者的调查。

微软表示，组织条件与受访者所称从 AI 中获得的价值高度相关。其方法论明确区分统计相关性与因果关系。将这些发现与 Google 的说法进行比较时，这种谨慎尤为重要：两项调查都没有确立一套放之四海而皆准的成功部署方案。

这种比较也反映了不同的商业立场。Google 有动力鼓励买方重新审视既有的企业关系。微软则有动力让现有工作环境成为 AI 的高效应用场景。这些动机有助于解释各自的侧重点，但并不会自动否定任何一方的发现。

对买方而言，这一选择涉及实际权衡。扩展既有环境可以保留熟悉的管理方式，并减少部分迁移工作。引入替代方案则可能增加谈判选择，或满足特定工作流需求。如果组织跳过集成评估，无论采取哪条路径都可能令人失望。

因此，Google Cloud AI 调查应促使人们审视依赖关系，而非自动拒绝现有供应商。当更换某个组件会造成不可接受的中断、丢失关键信息，或使企业无法独立运营时，这种依赖就会产生实质影响。

这一担忧对新供应商与既有供应商同样适用。企业可能以一种不熟悉的约束取代熟悉的约束。一份不同的合同本身并不代表拥有更大的自由度。

有意义的选择需要运营层面的证据。买方需要了解，记录是否能在产品之外继续使用，权限是否能够重建，以及已完成的工作是否仍可审查。这些问题比菜单中可选模型的数量更具说明力。

选择 AI 模型与替换工作流平台也存在区别。模型负责生成或解读信息。平台则可能承载指令、连接、记录和审批历史。更换前者的影响可能相对可控，而更换后者则会影响整个流程。

这使采购讨论的要求更高。买方应评估完整的工作安排，包括持续承担的义务和退出条件。便捷的演示对于关键连接中断或业务部门改变流程时会发生什么，能提供的洞见十分有限。

知识管理提供了一个较小规模的类似案例。当人们能在语境中检索到相关材料时，可搜索的知识库才有价值。企业自动化还提出了更多要求，因为检索到的信息可能会影响具有组织层面后果的行动。

因此，Google 与微软之间最有力的比较，在于各自提出的环境如何支持实际工作。与其审视竞争方案中相同的流程、权限和验收标准，品牌偏好是一个较弱的替代品。

该调查仍留下重要的因果与安全问题

报告所称的维护摩擦值得进一步调查，但并不能证明云迁移会为每一种工作负载带来更好的结果。

随附的企业准备度报告介绍了一项时长 20 分钟的在线调查，并辅以定性访谈。其美国决策者样本提供了明确视角。在讨论其他地区的企业，或采购和技术领导层之外的员工时，读者应保留这一范围意识。

该报告还称，78% 的受访者认为技术维护会分散 AI 资源，而 48% 认为其技术栈已准备好进行规模化部署。这些是对能力和准备度的评估，并非迁移后实际收回工程工时的直接测量。

受访者可以准确描述挫败感，却未必能识别最佳补救方案。一个难以应对支持需求的团队，可能会受益于替换方案、更好的配置、额外专业能力，或更有限的 AI 范围。在这些应对方式之间做出选择，需要来自受影响环境的证据。

出于同样原因，商业赞助也值得关注。Google 销售的服务与其提出的方向一致。恰当的回应是审视定义并比较替代方案，同时保留那些经受审查后仍具价值的发现。

该调查以部署方式作为定义的做法尤其关键。将本地管理的软件视为遗留系统，从一开始就使云端比较成为核心。买方仍需单独评估可维护性、安全性、集成质量和业务适配性。

安全性也为简单的迁移叙事带来另一层限制。托管服务可以改变由谁负责基础设施维护，但并不能免除对以下问题的判断：代理可以访问哪些信息，以及哪些操作需要审查。

Gartner 的代理治理框架正是针对这一差异。分析师 Shiva Varma 认为，统一控制可能会对简单代理施加过度限制，同时对自主性更高的代理限制不足。该框架区分了观察、建议以及需要审批的行动。

这一视角使“提升自主性始终代表进步”的假设变得更复杂。对于具有重要后果的工作流，被限制为仅准备建议的代理可能是合适的。是否要求审批是一项设计决策，其价值取决于行动本身及其潜在影响。

因此，谨慎的企业买方应区分基础设施改进与授权改进。更好的托管可以支持可用性和维护性。更好的授权则界定系统被允许执行什么操作。两者都值得关注，且任何一者都不应替代另一者。

Google Cloud AI 调查并未解决这些投资之间如何平衡的问题。它识别出领导者可以调查的感知限制。分析上的错误在于，将这一信号转化为某一种架构、供应商或自主性水平天生更优的证据。

部署后还存在进一步的衡量问题。员工可能花更少时间发起工作，却花更多时间核查不确定的结果。生产力主张需要将这种审查投入与支持和恢复工作一并纳入考量。否则，表面上的自动化可能掩盖了被转移给另一团队的工作。

关注已完成的工作流、切换证据与恢复能力

下一类有用证据将把现代化决策与买方可以检验的运营结果联系起来。

未来数月，第一个值得关注的信号是客户对已完成工作流的报告。有价值的披露将区分演示与经常性使用，并说明何为成功完成。它们还应指出何处仍需人工介入。

如果现代化消除了可识别的限制，并带来可重复的运营改进，这类证据将增强 Google 的论点。若项目即使更换了底层环境，仍需要大量人工修复，那么这将削弱广泛迁移的主张。

当流程产生不可接受的错误时，仅仅完成并不够。买方需要关于正确性以及解决例外情况所需工作量的证据。一个快速完成却引发后续争议的工作流，只是转移了问题，而没有解决问题。

第二个信号是经证明的切换能力。当客户展示一个正常运作的流程能够在组件变更后继续存续时，关于连接器或模型选择的产品公告就值得更仔细审视。保留权限、评估标准和可用记录，将构成灵活性的有意义证据。

需要大规模重建的切换则讲述了另一种情况。它表明，名义上的选择与重大的运营依赖并存。当买方比较既有工作场所平台与替代性代理环境时，这一区别将十分重要。

第三个信号是在受控故障下的恢复能力。客户案例和技术评估应说明，当访问权限到期、所连接的应用不可用，或某项操作仅部分完成时会发生什么。恢复证据揭示了系统在有利演示之外的运行方式。

清晰的责任归属会增强信心。团队应能够识别最后一个已验证状态，确定哪些行动已经发生，并决定如何恢复工作。如果每次都需要非正式调查才能回答这些问题，运营负担就仍未得到解决。

这些信号也有助于区分基础设施约束与流程约束。连接失败可能表明存在技术依赖。未解决的审批争议则指向治理问题。两者都可能阻碍交付，但需要不同的应对方式。

Google Cloud AI 调查让企业领导者有理由审视工程能力流向何处。当其发现被转化为关于特定服务、其依赖关系及负责保持其可用性的人员的问题时，才最具价值。

对于计划进行 AI 投资的读者，请把关注点放在助手回应之外的实际工作上。询问必须实现什么业务结果、哪些记录可以证明完成，以及谁来处理例外情况。根据同一结果比较各项方案，包括迁移投入和持续审查。无论评估现有平台还是替代方案，都应保持验收标准一致。要求有关减少维护的主张明确说明被移除的任务和保留的责任。然后寻找客户证据，证明这些变化能在日常运营和受控故障中持续存在。目前是哪一种依赖关系阻碍了你的团队完成有价值的工作？又需要什么证据，才能证明拟议投资确实消除了它？