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:
- Qual número vai mudar, e quanto ele vale hoje?
- Quem, com nome, vai olhar esse número na semana que vem?
- 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.
A DCODER começa todo projeto de IA pelas quatro decisões do dia um, escritas em contrato. Converse com o estúdio em dcoder.io.