AI Infinity

Por que o projeto de IA morre depois do piloto (e quem deveria mantê-lo vivo)

Por Pedro Gomes · 27 de outubro de 2026 · 10 min de leitura

O projeto de IA foi apresentado à diretoria com o gráfico subindo. No quarto mês, o agente ainda estava ligado, mas ninguém conferia mais o que ele fazia. Não houve pane, erro grave ou fornecedor sumido. Houve apenas silêncio, porque a reunião semanal saiu da agenda, o responsável voltou para a rotina antiga e a ferramenta ficou rodando sem dono.

Essa cena é mais comum do que parece. Uma pesquisa da Orgvue com 1.163 executivos de grandes empresas saiu em maio de 2026. De acordo com ela, 78% já viram iniciativas de IA travarem ou falharem na fase de piloto. Além disso, 43% dizem que continuam presos nela. A seguir, a autópsia desse tipo de morte e o que fazer para o projeto de IA continuar entregando depois do lançamento.

O projeto de IA raramente morre de falha técnica

Quando um piloto some, a explicação mais fácil é técnica: o modelo errou, a integração quebrou, a ferramenta era fraca. Na prática, porém, o motivo costuma ser outro. Em geral, o projeto de IA morre de abandono, porque ninguém ficou encarregado de cuidar dele depois da entrega.

Os números confirmam esse padrão. O estudo The Pulse of Agentic AI 2026, da Dynatrace, saiu em janeiro de 2026. De acordo com ele, cerca de metade dos projetos com agentes de IA ainda está em prova de conceito ou piloto. Entre as barreiras para chegar à operação, 51% dos líderes citam a dificuldade de acompanhar agentes em escala, enquanto 44% apontam falta de gente qualificada. Ou seja, o gargalo aparece depois da construção, na hora de cuidar.

As previsões do Gartner seguem a mesma lógica. Em junho de 2025, a consultoria previu o cancelamento de mais de 40% dos projetos com agentes de IA até o fim de 2027. Os motivos apontados são custo crescente, valor de negócio pouco claro e controle de risco insuficiente. Repare que nenhum deles diz "a tecnologia não funciona". Todos dependem, sobretudo, de alguém que meça o resultado e preste contas.

As cinco causas de morte de um projeto de IA

Os pilotos abandonados costumam ter uma destas cinco causas. Às vezes, duas ou três aparecem juntas.

1. O dono voltou para a função antiga

Durante o piloto, alguém da área de negócio virou o dono da iniciativa. Essa pessoa ajustou regras, respondeu dúvidas e defendeu o projeto na diretoria. Só que o piloto acabou e ela voltou a perseguir as metas da própria área. Uma vez que ninguém formalizou a função de cuidar da IA, a tarefa evaporou.

2. O mundo mudou e ninguém ajustou

Todo projeto de IA em operação depende de sistemas, regras e modelos que mudam o tempo todo. O ERP ganha uma versão nova, por exemplo, enquanto a diretoria revisa a política comercial e a tabela de preços. Até o modelo de linguagem pode sair do ar. De acordo com a VentureBeat (novembro de 2025), um modelo da OpenAI saiu da API em fevereiro de 2026 com cerca de três meses de aviso. Quem acompanha recebe o aviso e migra com calma. Quem não acompanha, porém, descobre o problema quando o atendimento começa a responder errado.

3. Ninguém mediu depois da apresentação

O piloto teve métrica porque precisava convencer a diretoria. Depois da aprovação, ninguém mais atualizou o painel. Sem número, ninguém percebe se o ganho continua, se caiu pela metade ou se virou custo. Por isso, iniciativa sem número costuma ser a primeira a sair na revisão do orçamento.

4. A equipe mudou e ninguém treinou quem chegou

Quem participou do piloto sabia quando confiar na IA e quando corrigir. Meses depois, no entanto, parte dessa equipe já mudou de área. Os novos não sabem o que o agente faz, desconfiam do resultado e voltam para a planilha. A IA continua ligada, mas o processo real passou a correr por fora dela.

5. O piloto rodou em condição de laboratório

Muitos pilotos usam dados limpos, volume pequeno e casos escolhidos a dedo. Na operação, em contrapartida, chegam exceções, picos de demanda e clientes que escrevem de qualquer jeito. Se ninguém previu essa diferença, a taxa de erro sobe na primeira semana real e a equipe conclui que a IA não serve. De fato, ninguém testou a ferramenta no mundo em que ela precisava trabalhar.

Sinais vitais: o que acompanhar toda semana

Um projeto de IA saudável tem sinais que qualquer diretor consegue ler, mesmo que não entenda de modelo. Cinco deles bastam para começar:

Uso real. Quantas tarefas a IA executou na semana, comparado com o volume do processo. Se o processo mantém o volume enquanto o uso cai, as pessoas estão contornando a ferramenta.

Taxa de correção humana. Quantas vezes alguém precisou refazer ou ajustar o que a IA entregou. Em geral, um aumento lento é o primeiro aviso de que algo mudou.

Exceções. Casos que a IA não soube tratar e mandou para uma pessoa. Sempre que uma exceção nova se repete, ela pede uma regra nova.

Tempo de resposta. Quanto a IA leva para concluir a tarefa. Lentidão crescente geralmente indica integração sobrecarregada ou sistema que mudou.

Custo por tarefa. O gasto com modelo, plataforma e horas de ajuste dividido pelo número de tarefas concluídas. É o número que a diretoria vai pedir na revisão do orçamento.

Para começar, uma planilha simples resolve, desde que alguém tenha a responsabilidade de olhar para esses números toda segunda-feira.

Quem cuida da IA quando o piloto termina

Manter um projeto de IA funcionando é trabalho fixo, com começo e sem data para acabar. Por isso, ele precisa de nome, rotina e métrica antes mesmo de o piloto terminar.

Na prática, três papéis dividem essa responsabilidade:

Dono do processo. É a pessoa da área de negócio que responde pelo resultado. Cabe a ela decidir o que muda na regra e aprovar os ajustes.

Gestor de automações. Cuida do dia a dia técnico. Acompanha os sinais vitais, atualiza integrações e troca o modelo assim que o fornecedor anuncia o desligamento.

Responsável por qualidade (QA). Antes de cada mudança, testa a IA com casos reais. Em seguida, confere por amostragem se as respostas continuam corretas.

A rotina também precisa estar no calendário. Toda semana, alguém revisa os sinais vitais e as exceções novas. Uma vez por mês, o dono do processo e o gestor de automações decidem os ajustes. Por fim, a cada trimestre, a diretoria olha o custo por tarefa e decide se a iniciativa cresce, se mantém ou sai do ar.

Esse desenho conversa com o relatório The State of AI, da McKinsey, de agosto de 2026. Segundo o levantamento, só 44% das empresas dizem que a IA já ganha escala na operação, contra 38% um ano antes. Além disso, apenas cerca de 6% atribuem à IA 5% ou mais do resultado operacional. Ou seja, entre testar e colher existe um trabalho menos visível, e é nele que muita empresa para.

Como a Infinity sustenta a IA dentro da operação

Na AI Infinity Global Company, essa função tem nome e lugar no método. Sustentar é a etapa do Ciclo Infinity que vem logo depois de Implementar. Ela existe para que a solução continue viva quando o entusiasmo inicial passa.

Por isso, o time que a Infinity instala dentro do cliente inclui um Gestor de Automações e um profissional de QA, além de quem constrói. Eles acompanham a operação com um painel de indicadores definido junto com a diretoria, a partir das métricas que a empresa já usa. Assim, quando um sistema muda ou um modelo sai do ar, a correção entra na rotina, sem virar um novo projeto de IA.

Uma automação que libera de 40 a 120 horas de trabalho manual por mês é o tipo de resultado que se perde quando ninguém sustenta. Um departamento de IA dentro da empresa existe, portanto, para dar dono a esse trabalho.

Do piloto à operação: o checklist antes do próximo projeto de IA

Antes de aprovar o próximo piloto, vale exigir respostas por escrito para seis perguntas. Se alguma ficar em branco, o projeto de IA ainda não está pronto para virar operação.

Quem é o dono do processo depois da entrega, com nome e sobrenome? Quem acompanha os sinais vitais toda semana, e quantas horas por mês isso vai tomar? Qual métrica prova o resultado, e qual era o número antes da IA? O piloto passou por volume, exceções e dados reais, ou só por casos escolhidos? O que acontece se o fornecedor do modelo avisar que vai desligar a versão atual? Qual verba fica reservada para manutenção ao longo do primeiro ano?

Essas perguntas tomam uma reunião, mas evitam que o piloto entre para a estatística dos que não saíram do lugar. Se a sua empresa tem um piloto parado ou vai aprovar o próximo, o Diagnóstico Infinity mostra se existe estrutura para sustentar o que você vai construir.

Perguntas frequentes

Quais sinais mostram que um agente está piorando aos poucos, antes que algum cliente reclame?

O sinal mais confiável é a taxa de correção humana subindo devagar. A equipe passa a ajustar mais respostas por semana, sem registrar isso como problema. Outros avisos costumam aparecer ao mesmo tempo. O volume de exceções enviadas para pessoas cresce, surgem tipos de pedido que a IA nunca tinha visto e o tempo de resposta aumenta. Também vale olhar o uso, porque um processo com o mesmo volume e menos tarefas feitas pela IA indica que as pessoas estão contornando a ferramenta. Por isso, o ideal é revisar uma amostra de respostas toda semana e comparar com o padrão aprovado no piloto.

Quem deve ser o dono da sustentação quando o projeto de IA foi construído por um fornecedor externo?

O dono do resultado continua sendo a empresa. O fornecedor pode executar a manutenção técnica, mas alguém da área de negócio precisa responder pelo processo, aprovar mudanças de regra e cobrar os indicadores. O erro mais comum, contudo, é tratar a entrega do fornecedor como o fim do projeto. Antes de assinar, defina em contrato quem acompanha os sinais vitais e em que prazo o fornecedor corrige uma falha. Defina também o que acontece com prompts, regras e integrações se a parceria terminar. Dessa forma, a empresa evita depender de terceiros para entender o que ela mesma usa.

Como decidir entre consertar, refazer ou desligar um projeto de IA abandonado?

Comece medindo o estado atual: uso real, taxa de correção e custo por tarefa nas últimas semanas. Conserte quando o processo ainda existe, o volume justifica e os erros têm causa identificável. É o caso, por exemplo, de uma integração quebrada ou de uma regra desatualizada. Por outro lado, se o processo mudou tanto que a lógica original não serve mais, refaça a partir de um novo mapeamento. Desligue quando o custo de manter supera o ganho medido ou quando a área já resolveu o problema de outro jeito. Em qualquer caso, registre o motivo da decisão, porque ele orienta o próximo piloto.

Qual critério objetivo separa um piloto pronto para virar operação de um que precisa de mais teste?

São três condições, todas verificáveis com dados. Primeiro, o piloto rodou com volume e exceções reais por tempo suficiente para pegar a variação normal do processo, como um fechamento de mês. Depois, a taxa de correção humana ficou estável ou caiu nas últimas semanas, em vez de oscilar. Por fim, existem dono, rotina e métrica definidos para depois da entrega. Se as duas primeiras estão boas e a terceira não, o piloto funciona tecnicamente, mas ainda não tem como sobreviver. Nesse caso, o próximo passo é organizar a sustentação antes de ampliar o uso.

Quanto do orçamento do projeto de IA deveria ir para a manutenção, e por que esse número costuma ficar de fora?

Não existe um percentual universal, já que tudo depende do número de integrações, da frequência com que as regras mudam e do volume processado. O que vale como regra é prever, desde o início, verba para horas de acompanhamento, ajustes, testes e migração de modelo ao longo do primeiro ano. Esse número costuma ficar de fora porque o projeto de IA chega à diretoria como algo com começo e fim. Sem a linha de manutenção, o primeiro ajuste necessário vira um pedido extra, que disputa espaço com outras prioridades e geralmente perde. É assim que muitos pilotos param de funcionar.

Leia também

Operação First Class

Para organizações que precisam ter Inteligência Artificial para continuarem competitivas no mercado