Por que o piloto de IA não vira produção

A maior parte dos pilotos de IA em empresa não morre por falha técnica. Morre porque ninguém decidiu, antes de começar, o que seria medido e o que contaria como sucesso. Sem essa decisão, o piloto roda, impressiona, e depois não sobrevive à primeira pergunta sobre retorno.

O relatório do projeto NANDA, do MIT, publicado em 2025, colocou número nisso: apontou que 95% dos projetos de IA generativa em empresas não produziram retorno mensurável, apesar de dezenas de bilhões de dólares investidos. O levantamento se apoia em 52 entrevistas com executivos, respostas de 153 líderes e a análise de 300 implantações públicas — vale ler o número como ordem de grandeza, não como medida exata. E o diagnóstico interessa mais que a cifra: a falha quase nunca está no modelo.

Os cinco motivos, em ordem de frequência

1. Ninguém definiu o que seria medido

O piloto começa com “vamos testar IA no atendimento”. Não com “queremos reduzir o tempo até a primeira resposta de 4 horas para 1 hora, medido na fila X, entre março e maio”.

A diferença aparece na reunião de orçamento. A primeira versão só permite responder “melhorou bastante”. A segunda permite responder com um número que alguém pode conferir.

2. O piloto foi feito num canto que não representa a operação

Escolhe-se a área mais receptiva, com as pessoas mais interessadas e os casos mais limpos. Funciona muito bem. E aí não escala, porque o resto da empresa tem dado sujo, processo diferente e gente que não pediu isso.

Piloto bom é feito no lugar chato, com o dado real.

3. O dado não estava pronto, e ninguém quis dizer

Esta é a causa mais cara. O modelo funciona; a informação que ele precisa está em quatro sistemas que não conversam, em planilha na máquina de alguém, ou num campo de texto livre preenchido de dez jeitos diferentes.

O piloto disfarça isso com uma base pequena e curada à mão. A produção não disfarça.

4. Não existia caminho de produção desde o começo

Piloto rodou numa ferramenta que não passa pela segurança da empresa, sem controle de acesso, sem registro, sem plano de suporte. Aprovar significa recomeçar. E recomeçar exige uma segunda aprovação que ninguém quer pedir.

5. O ganho ficou com a ferramenta, não com o processo

A equipe economiza vinte minutos por dia e usa esses vinte minutos para fazer mais do mesmo. O ganho é real e invisível: não aparece em custo, não aparece em receita, não aparece em nada que a diretoria acompanhe.

Ganho que não muda um número que alguém já olhava não sobrevive a corte de orçamento.

As quatro decisões do dia um

Todas cabem em uma página, e a página precisa existir antes da primeira linha de código.

Decisão	Formato da resposta
O que medimos	Uma métrica que a empresa já coleta hoje.
Qual é a linha de base	O valor dessa métrica nas últimas quatro semanas.
O que conta como sucesso	Um número e uma data, escritos antes.
O que acontece se não der	Desligamos, ajustamos ou continuamos? Decidido agora, não depois.

A quarta é a que ninguém escreve, e é a que mais protege. Um piloto sem critério de encerramento vira um custo permanente que ninguém tem coragem de matar.

O piloto que funciona parece pequeno demais

O padrão que o próprio relatório do MIT aponta é revelador: os projetos que dão retorno são operacionais e sem glamour. Automação de retaguarda, triagem, classificação, tarefa repetitiva de alto volume. Os que falham são os de vitrine.

Traduzindo para a prática: um piloto de seis semanas, numa tarefa chata, com uma métrica que o financeiro já acompanha, vale mais que um projeto de seis meses com nome de programa e slide de abertura.

Como saber se o seu piloto vai morrer

Três perguntas. Se alguma não tiver resposta em uma frase, ele vai morrer:

1. Qual número vai mudar, e quanto ele vale hoje?
2. Quem, com nome, vai olhar esse número na semana que vem?
3. Se ele não mudar até a data marcada, o que fazemos?

Responder às três custa uma hora de reunião. Não responder custa o projeto inteiro.