Pesquisa de IA do Google Cloud aponta modernização travada por software existente

O Google Cloud publicou descobertas em 9 de novembro mostrando que 49% dos tomadores de decisão pesquisados associaram o software local a iniciativas tecnológicas atrasadas ou reduzidas. Essas iniciativas incluíam IA, embora a descoberta não isole os projetos de IA. A pesquisa de IA do Google Cloud atribui um número concreto a um conflito empresarial conhecido: manter as operações existentes compete com a criação de novas capacidades.

A pesquisa, conduzida com o Hypothesis Group, consultou 1.250 tomadores de decisão empresariais de TI e negócios nos Estados Unidos. O Google usa as descobertas para defender maior liberdade arquitetural e menor dependência de fornecedores estabelecidos. Sua preocupação central é compreensível: agentes de IA, software capaz de executar tarefas por meio de ações sucessivas, herdam as limitações dos sistemas que acessam.

A Microsoft oferece uma comparação útil. Sua pesquisa enfatiza a preparação organizacional junto à adoção pelos funcionários, em vez de tratar a substituição da infraestrutura como a resposta central. A tensão presente em ambas as análises está entre ampliar o acesso à IA e preparar os processos de negócios para ela. Para líderes de tecnologia, isso direciona a discussão para integração, responsabilidade operacional e se novos investimentos de fato liberam a limitada capacidade de engenharia.

O que a pesquisa de IA do Google Cloud realmente mediu

A pesquisa mede as restrições relatadas pelos tomadores de decisão, em vez de demonstrar que uma estratégia específica de modernização as elimina.

Jeanette Manfra, chefe de risco e conformidade do Google Cloud, apresentou as descobertas em um anúncio sobre uma pesquisa de software legado. O relatório que a acompanha é datado de outubro de 2026, enquanto sua metodologia situa o trabalho de campo em agosto. A publicação, portanto, oferece um relato recente de experiências coletadas anteriormente, e não uma medição em tempo real das implantações de novembro.

Uma definição importante molda a interpretação. O estudo classifica como legado o software empresarial hospedado localmente ou on-premises, em contraste com software hospedado e gerenciado na nuvem. Essa definição diz respeito aos arranjos de implantação e gestão. Os leitores devem evitar supor que todo sistema abrangido seja obsoleto, sem suporte ou tecnicamente inadequado para IA.

A distinção importa porque localização e condição respondem a perguntas diferentes. Um aplicativo operado localmente pode ter interfaces claras e manutenção disciplinada. Um aplicativo em nuvem ainda pode conter registros confusos, permissões inconsistentes ou regras de negócios fortemente acopladas. Nenhuma das observações contradiz as experiências dos respondentes, mas ambas limitam as conclusões que compradores devem tirar.

Os 49% reportados também agrupam vários resultados: atrasos, escopo reduzido, pausas e cancelamentos. Eles representam diferentes graus de interrupção. Um ajuste temporário de cronograma não traz as mesmas consequências para os negócios que abandonar um projeto. Da mesma forma, a inclusão de outras iniciativas tecnológicas significa que o resultado não pode ser tratado como uma taxa de cancelamento de IA.

Essa ressalva preserva uma descoberta significativa. Os respondentes associam seus atuais arranjos de software a barreiras para mudanças planejadas. Para compradores empresariais, isso evidencia que o ambiente ao redor merece atenção junto ao produto de IA em avaliação.

No entanto, uma resposta de pesquisa não pode estabelecer toda a cadeia de responsabilidades. Uma iniciativa paralisada pode envolver limitações de aplicações, restrições de compras, falta de especialização, prioridades concorrentes ou uma justificativa de negócios pouco clara. Várias causas podem coexistir no mesmo projeto.

Consequentemente, a pesquisa de IA do Google Cloud é mais útil como diagnóstico de atrito organizacional percebido. Ela dá aos líderes um motivo para investigar suas próprias dependências. Não informa qual aplicativo substituir, qual fornecedor escolher ou se a migração deve preceder uma implantação específica.

Essa diferença separa um sinal de pesquisa útil de uma conclusão de compra excessivamente abrangente. A próxima pergunta é quem deve resolver o atrito e que trabalho essas pessoas deixariam de fazer.

A pressão de manutenção recai sobre as equipes encarregadas de entregar IA

A pressão imediata recai sobre as equipes responsáveis tanto pela continuidade operacional quanto pela entrega de novas soluções de IA.

Uma organização de engenharia não pode tratar sua carga de trabalho existente como opcional apenas porque executivos estabelecem um prazo para IA. Correções de segurança, mudanças de acesso, resposta a incidentes e suporte a aplicações continuam necessários. Atribuir um objetivo adicional não cria automaticamente a capacidade necessária para cumpri-lo.

Isso gera um problema orçamentário que os números de quadro de funcionários, por si só, podem ocultar. Uma equipe pode parecer adequadamente dimensionada enquanto especialistas permanecem ocupados com sistemas que exigem seu conhecimento específico. A restrição relevante costuma ser a especialização disponível durante a janela de entrega, e não o total de funcionários.

Considere um agente interno ilustrativo que ajuda funcionários a resolver problemas de conta. Produzir uma resposta plausível é apenas parte da tarefa. O processo ao redor precisa identificar o funcionário, estabelecer o acesso permitido, recuperar informações atuais e encaminhar exceções a alguém responsável.

Se o agente puder alterar uma conta, a organização também precisará de regras de aprovação e de um registro da ação. Uma demonstração eficaz pode evitar grande parte desse trabalho operacional. Um serviço em produção não pode depender de alguém corrigindo manualmente cada caso incomum depois.

Essas exigências explicam por que desenvolvedores e equipes de segurança enfrentam pressão de direções diferentes. Líderes de negócios querem progresso visível. Equipes de operações precisam preservar a disponibilidade. Revisores de segurança necessitam de evidências suficientes para aprovar o acesso. Sem prioridades explícitas, o trabalho de integração pode se tornar uma dependência sem responsável entre esses grupos.

A manutenção também afeta o sequenciamento. Substituir um aplicativo pode eventualmente reduzir o esforço de suporte, mas exigir trabalho substancial antes que esse benefício apareça. Durante a transição, as equipes podem precisar dar suporte aos processos existentes enquanto aprendem a usar a substituição. Portanto, uma proposta de modernização precisa explicar a carga de trabalho temporária.

É nesse ponto que promessas amplas de liberar engenheiros merecem análise. A pergunta relevante é quais tarefas recorrentes desaparecem, quem as executa hoje e quando essas pessoas se tornam disponíveis. Transferir a responsabilidade para um fornecedor pode ajudar, mas o trabalho retido de integração e supervisão ainda precisa de um responsável.

As equipes de compras enfrentam um desafio relacionado. Elas devem distinguir a conveniência de adquirir um produto do esforço de operá-lo. Um contrato conhecido pode simplificar a compra sem resolver o acesso a dados. Um fornecedor desconhecido pode oferecer capacidades atraentes enquanto acrescenta outro conjunto de responsabilidades operacionais.

Para trabalhadores do conhecimento, as consequências aparecem como disponibilidade desigual. Um assistente pode resumir documentos com sucesso e ainda ser incapaz de usar os registros necessários para uma decisão relevante. A interface visível de IA então avança mais rápido do que o fluxo de trabalho por trás dela.

A pressão é, portanto, tão organizacional quanto técnica. A liderança precisa decidir quais dependências merecem investimento e quais projetos propostos devem esperar. Caso contrário, cada novo piloto disputa as mesmas pessoas sem alterar as condições que atrasaram seus antecessores.

Adicionar um agente não elimina o trabalho por baixo dele

A automação amplia a importância de interfaces de negócios confiáveis porque ações exigem limites mais claros do que sugestões.

O argumento do Google se torna mais persuasivo quando aplicado a um fluxo de trabalho específico do que quando aplicado apenas à localização do software. Um sistema que produz recomendações pode deixar a execução para uma pessoa. Um sistema autorizado a agir precisa encontrar regras que a organização tenha tornado explícitas.

Considere uma solicitação ilustrativa de compras. Um funcionário pode pedir a um agente que prepare um pedido usando um fornecedor aprovado. A tarefa linguística é simples de descrever. A tarefa de negócios inclui verificar a autorização, selecionar a conta correta, aplicar a política de compras e lidar com itens indisponíveis.

Cada etapa introduz uma pergunta que um texto fluente não consegue resolver de forma independente. Qual registro é a fonte oficial? O solicitante tem permissão? A compra proposta está dentro da política? O que acontece se o pedido for concluído, mas a confirmação falhar?

Essas perguntas expõem uma distinção entre gerar uma resposta e concluir uma transação. A organização precisa saber o que ocorreu em seus sistemas, incluindo conclusões parciais. Uma resposta conversacional confiante não pode substituir essa evidência.

Aplicações existentes às vezes codificam regras que os funcionários entendem pela experiência, e não pela documentação. A implantação de um agente pode revelar esse conhecimento oculto. O que parece ser um problema de integração pode, na verdade, envolver decisões não resolvidas sobre política, exceções ou responsabilidade.

Substituir a aplicação não resolverá necessariamente essas decisões. Isso pode criar um lugar melhor para expressá-las, mas alguém ainda precisa determinar o comportamento pretendido. É por isso que propostas de modernização devem identificar o limite de negócios que aprimoram, em vez de se basear na idade do software subjacente.

O relato do próprio Google sobre a implantação de atendimento ao cliente oferece um exemplo concreto. Em abril de 2025, a empresa descreveu o FreshAI da Wendy’s processando pedidos no drive-thru e expandindo-se por 24 estados. Essas são alegações de implantação reportadas pela empresa, e não uma prova independente da confiabilidade geral dos agentes.

Ainda assim, o exemplo ilustra o valor de uma tarefa definida. Pedir comida tem entradas reconhecíveis, restrições de cardápio e uma transação que precisa chegar às operações do restaurante. Sua utilidade depende de conexões com o processo real de atendimento, e não apenas da qualidade da conversa.

Um fluxo de trabalho empresarial interno precisa de clareza comparável, mesmo quando seus limites são menos visíveis. Uma solicitação para investigar um contrato, preparar uma renovação ou resolver um problema de acesso exige um destino acordado. Caso contrário, uma equipe pode declarar sucesso quando o agente produz texto enquanto funcionários posteriores ainda concluem o trabalho substancial.

Isso torna a integração uma questão de responsabilidade. Alguém precisa assumir a transição da recomendação para a ação aprovada e da ação para o resultado verificado. Sem essa responsabilidade, a automação pode redistribuir esforço enquanto deixa o processo de negócios praticamente inalterado.

O caso mais sólido para modernização identifica essas transições e demonstra que elas melhoram. Suas evidências devem mostrar menos transferências não resolvidas, conclusão confiável e recuperação administrável quando algo dá errado.

Google e Microsoft enfatizam rotas diferentes para a preparação

Os fornecedores diferem em ênfase, mas ambas as análises tornam a preparação organizacional central para uma implantação útil de IA.

A posição do Google dá destaque à liberdade arquitetural. A pesquisa da Microsoft sobre preparação organizacional para IA dá mais ênfase à gestão, ao desenho do trabalho e à avaliação. Seu relatório de maio de 2026 se baseia em uma pesquisa com 20.000 trabalhadores que usam IA em 10 mercados.

A Microsoft afirma que as condições organizacionais estão fortemente associadas ao valor que os respondentes relatam obter da IA. Sua metodologia distingue explicitamente associação estatística de causalidade. Essa cautela é importante ao comparar as conclusões com o relato do Google: nenhuma das pesquisas estabelece uma receita universal para uma implementação bem-sucedida.

A comparação também reflete posições comerciais distintas. O Google tem interesse em incentivar compradores a reconsiderar relações empresariais já estabelecidas. A Microsoft tem interesse em tornar os ambientes de trabalho existentes produtivos para a IA. Esses incentivos ajudam a explicar as ênfases sem invalidar automaticamente as conclusões de nenhuma das empresas.

Para os compradores, a escolha envolve compensações práticas. Estender um ambiente já estabelecido pode preservar uma administração familiar e reduzir parte do trabalho de transição. Introduzir uma alternativa pode ampliar as opções de negociação ou atender a uma exigência específica de fluxo de trabalho. Qualquer uma das rotas pode decepcionar se a organização ignorar a avaliação de integração.

A pesquisa Google Cloud AI deve, portanto, estimular o escrutínio da dependência, e não a rejeição automática de um fornecedor já estabelecido. A dependência torna-se relevante quando alterar um componente exige uma interrupção inaceitável, resulta na perda de informações essenciais ou deixa a empresa incapaz de operar de forma independente.

Essa preocupação se aplica tanto a um novo fornecedor quanto a um já existente. Uma empresa pode substituir uma limitação familiar por outra menos familiar. Um contrato diferente não estabelece, por si só, maior liberdade.

Uma escolha significativa exige evidências operacionais. O comprador precisa entender se os registros permanecem utilizáveis fora do produto, se as permissões podem ser reconstruídas e se o trabalho concluído continua inspecionável. Essas perguntas revelam mais do que a quantidade de nomes de modelos disponíveis em um menu.

Também há uma diferença entre escolher um modelo de IA e substituir uma plataforma de fluxo de trabalho. O modelo gera ou interpreta informações. A plataforma pode conter instruções, conexões, registros e histórico de aprovações. Alterar o primeiro pode ser relativamente delimitado, enquanto alterar o segundo afeta todo o processo.

Isso torna a discussão de compras mais exigente. Os compradores devem avaliar todo o arranjo operacional, incluindo obrigações mantidas e condições de saída. Uma demonstração conveniente oferece uma visão limitada do que ocorre quando uma conexão crítica falha ou uma unidade de negócios altera seu processo.

A gestão do conhecimento oferece um paralelo menor. Uma base de conhecimento pesquisável é útil quando as pessoas conseguem recuperar material relevante em contexto. A automação empresarial acrescenta outros requisitos porque as informações recuperadas podem influenciar ações com consequências organizacionais.

A comparação mais sólida entre Google e Microsoft, portanto, diz respeito a como cada ambiente proposto apoia o trabalho real. A preferência de marca é um substituto frágil para examinar o mesmo processo, as mesmas permissões e os mesmos critérios de aceitação em abordagens concorrentes.

A pesquisa deixa importantes questões causais e de segurança em aberto

A fricção de manutenção relatada justifica investigação, mas não comprova que a migração para a nuvem gere melhores resultados para toda carga de trabalho.

O relatório de prontidão empresarial que acompanha a pesquisa descreve uma pesquisa online de 20 minutos, complementada por entrevistas qualitativas. Sua amostra de tomadores de decisão americanos oferece uma perspectiva definida. Os leitores devem manter esse escopo em mente ao discutir empresas de outros lugares ou funcionários fora das áreas de compras e liderança de tecnologia.

O relatório também afirma que 78% dos respondentes acreditam que a manutenção de tecnologia desvia recursos da IA, enquanto 48% consideram sua pilha pronta para uma implementação em escala. Essas são avaliações de capacidade e prontidão. Não são medições diretas das horas de engenharia recuperadas após uma migração.

Os respondentes podem descrever com precisão a frustração sem identificar a melhor solução. Uma equipe que enfrenta exigências de suporte pode se beneficiar de substituição, melhor configuração, conhecimento adicional ou um escopo de IA mais restrito. Escolher entre essas respostas exige evidências do ambiente afetado.

O patrocínio comercial merece atenção pelo mesmo motivo. O Google vende serviços alinhados à direção que propõe. A resposta adequada é examinar definições e comparar alternativas, preservando ao mesmo tempo as conclusões que permanecem úteis sob escrutínio.

A definição de implantação adotada pela pesquisa é particularmente relevante. Tratar softwares gerenciados localmente como legados coloca a comparação com a nuvem no centro desde o início. Os compradores ainda precisam de uma avaliação separada de capacidade de manutenção, segurança, qualidade de integração e adequação ao negócio.

A segurança introduz outro limite para uma narrativa simples de migração. Um serviço gerenciado pode mudar quem cuida da manutenção da infraestrutura. Ele não elimina a necessidade de decidir quais informações um agente pode acessar ou quais ações exigem revisão.

A estrutura de governança de agentes do Gartner aborda essa distinção. O analista Shiva Varma argumenta que controles uniformes podem restringir excessivamente agentes simples e, ao mesmo tempo, restringir insuficientemente os mais autônomos. A estrutura diferencia observação, aconselhamento e ação que exige aprovação.

Essa perspectiva complica a suposição de que aumentar a autonomia sempre representa progresso. Um agente restrito a preparar uma recomendação pode ser apropriado para um fluxo de trabalho com consequências relevantes. Exigir aprovação é uma decisão de design cujo valor depende da ação e de seus efeitos potenciais.

Por consequência, um comprador empresarial cauteloso deve distinguir melhoria de infraestrutura de melhoria de autorização. Uma hospedagem melhor pode apoiar disponibilidade e manutenção. Uma autorização melhor define o que o sistema tem permissão para fazer. Ambas merecem atenção, e nenhuma deve substituir a outra.

A pesquisa Google Cloud AI não resolve o equilíbrio entre esses investimentos. Ela identifica limitações percebidas que os líderes podem investigar. O erro analítico seria converter esse sinal em prova de que uma arquitetura, fornecedor ou nível de autonomia é inerentemente preferível.

Há outro problema de medição após a implantação. Os funcionários podem gastar menos tempo iniciando o trabalho, mas mais tempo verificando resultados incertos. Uma alegação de produtividade precisa levar em conta esse esforço de revisão, juntamente com suporte e recuperação. Caso contrário, a automação aparente pode ocultar trabalho transferido para outra equipe.

Observe fluxos de trabalho concluídos, evidências de troca e recuperação

As próximas evidências úteis conectarão decisões de modernização a resultados operacionais que os compradores podem inspecionar.

Nos próximos meses, o primeiro sinal a observar são os relatos de clientes sobre fluxos de trabalho concluídos. Divulgações úteis distinguirão uma demonstração do uso recorrente e explicarão o que conta como conclusão bem-sucedida. Elas também devem identificar onde a intervenção humana continua necessária.

Essa evidência fortaleceria o argumento do Google se a modernização eliminar limitações identificáveis e produzir melhorias operacionais repetíveis. Enfraqueceria uma alegação ampla de migração se os projetos ainda exigissem reparos manuais extensos, apesar da substituição do ambiente subjacente.

A conclusão por si só é insuficiente quando o processo produz erros inaceitáveis. Os compradores precisam de evidências sobre correção e sobre o esforço necessário para resolver exceções. Um fluxo de trabalho que termina rapidamente, mas cria disputas posteriores, deslocou o problema em vez de resolvê-lo.

O segundo sinal é a troca demonstrada. Anúncios de produtos sobre conectores ou escolha de modelos merecem análise mais atenta quando os clientes mostram que um processo em funcionamento sobrevive a uma mudança de componente. Preservar permissões, critérios de avaliação e registros utilizáveis forneceria evidências significativas de flexibilidade.

Uma troca que exige reconstrução extensa conta uma história diferente. Ela sugere que existe escolha nominal ao lado de dependência operacional substancial. Essa distinção será importante à medida que os compradores compararem plataformas de trabalho já estabelecidas com ambientes alternativos de agentes.

O terceiro sinal é a recuperação sob falha controlada. Relatos de clientes e avaliações técnicas devem explicar o que ocorre quando o acesso expira, uma aplicação conectada fica indisponível ou uma ação é concluída apenas parcialmente. As evidências de recuperação revelam como o sistema se comporta além da demonstração favorável.

Uma responsabilidade clara fortaleceria a confiança. Uma equipe deve conseguir identificar o último estado verificado, determinar quais ações ocorreram e decidir como o trabalho será retomado. Se essas respostas exigem investigação informal todas as vezes, a carga operacional permanece sem solução.

Esses sinais também ajudam a separar limitações de infraestrutura de limitações de processo. Uma conexão com falha pode indicar uma dependência técnica. Uma disputa de aprovação não resolvida aponta para governança. Ambas podem bloquear a entrega, mas exigem respostas diferentes.

A pesquisa Google Cloud AI dá aos líderes empresariais um motivo para examinar para onde vai a capacidade de engenharia. Suas conclusões são mais valiosas quando traduzidas em perguntas sobre um serviço específico, suas dependências e as pessoas responsáveis por mantê-lo útil.

Para os leitores que planejam um investimento em IA, acompanhem o trabalho além da resposta do assistente. Perguntem qual resultado de negócio precisa ocorrer, quais registros comprovam a conclusão e quem lida com exceções. Comparem propostas com base nesse mesmo resultado, incluindo o esforço de migração e a revisão contínua. Mantenham os critérios de aceitação consistentes ao avaliar uma plataforma já estabelecida ou uma alternativa. Exijam que alegações de manutenção reduzida identifiquem as tarefas eliminadas e as responsabilidades mantidas. Em seguida, busquem evidências de clientes de que essas mudanças persistem durante operações comuns e falhas controladas. Qual dependência atualmente impede sua equipe de concluir um trabalho valioso e quais evidências mostrariam que o investimento proposto realmente a elimina?