Por que seu piloto de IA morre antes de produção

Matei mais de um piloto de IA. Não por falta de orçamento, nem porque o modelo era ruim. Matei no critério de sucesso que ninguém tinha escrito antes de a gente começar a construir. O que ficou pelo caminho foi sempre a mesma coisa: a demo bonita que impressionava o board numa terça e não resolvia nada na quarta.

A estatística que circulou em todo lugar esse ano dizia que a esmagadora maioria dos pilotos de agente não chega à produção. Virou manchete. A leitura que fizeram dela, quase sempre, foi a errada.

O modelo quase nunca é o réu

Quando um piloto morre, a autópsia padrão culpa o modelo. “Alucinou”, “não é confiável ainda”, “espera a próxima versão”. É uma explicação confortável porque terceiriza a culpa para fora do time.

Só que na maioria das mortes que acompanhei, o modelo estava entregando o que dava para esperar dele. O que faltava estava em três lugares sem nenhuma relação com a qualidade da saída:

Escopo: o piloto tentava resolver “atendimento” inteiro em vez de um fluxo com começo, meio e fim.
Posse: ninguém no negócio era dono do resultado. Era projeto do time de IA, não do time que sofria o problema.
Governança: não existia critério para dizer “funcionou” ou “não funcionou”. Sem esse critério, o piloto não termina. Ele só perde a novidade e some.

Trocar de modelo não conserta nenhum dos três.

O critério de sucesso vem antes do código

Hoje eu não deixo um piloto começar sem responder quatro perguntas. Não são burocracia. São o que separa um experimento de uma demo cara.

Qual é o número? Não “melhorar a experiência”. Algo como resolver 40% dos tickets da categoria X sem humano, com satisfação igual ou melhor.
Quem é o dono no negócio? Uma pessoa, com nome, que responde pelo resultado e tem autoridade para mudar o processo em volta.
O que a gente faz quando não funcionar? O caminho de degradação precisa existir no dia um, não depois do primeiro incidente.
Em quanto tempo a gente mata? Piloto sem data de morte não é piloto, é orçamento perpétuo com roupa de inovação.

Sem critério cravado antes de construir, você não tem piloto. Tem uma demo cara. Se as quatro perguntas não têm resposta, eu não dou green-light, e prefiro a conversa desconfortável no começo à autópsia educada seis meses depois.

Teatro de piloto

Existe um anti-padrão que aprendi a reconhecer de longe. Eu chamo de teatro de piloto: a energia toda vai para a demo, e quase nenhuma vai para o que vem depois dela.

A demo roda em dados escolhidos a dedo. O caminho feliz é ensaiado. O board aplaude. Aí alguém pergunta quando aquilo vai para produção, e o silêncio responde, porque ninguém desenhou a parte chata: monitoramento, custo por chamada, quem revisa as saídas, o que fazer quando o volume dobra.

Uma demo prova que a coisa pode funcionar uma vez. Um piloto prova que ela sobrevive ao segundo mês.

O teatro de piloto é sedutor porque dá resultado rápido no palco. Só que ele otimiza para o aplauso, não para a operação. E aplauso não escala.

O que eu passei a fazer

Inverti a ordem. O critério de sucesso, o dono e o plano de degradação entram no documento antes da primeira linha de prompt. Se o piloto for morrer, que morra na página, barato, e não seis meses depois com um time inteiro alocado nele.

O modelo vai continuar melhorando. Isso nunca salvou um piloto que nasceu sem saber o que era ganhar.