IA em produção vs IA em demo: por que 80% dos projetos morrem no piloto

Toda semana eu vejo o mesmo padrão. Empresa contrata consultoria de IA, faz três workshops, sai com diagnóstico bonito e arquitetura desenhada no Miro. Seis meses depois, a IA que ia "transformar a operação" virou um endpoint esquecido, com 4 reclamações no Slack e uma fatura mensal de R$ 12 mil que ninguém sabe por que está ativa.

Não é exceção. É a regra. Pesquisa recente da McKinsey aponta que mais de 80% dos projetos de IA corporativa não passam do piloto. E quando você olha de perto, o motivo nunca é o modelo. É o que aconteceu (ou não aconteceu) antes do build.

A diferença entre IA em demo e IA em produção

Uma IA em demo funciona em um happy path controlado. Você escolhe 5 exemplos curados, mostra o agente respondendo bem, todo mundo bate palma. Uma IA em produção precisa sobreviver a:

• Input do usuário real (curto, com erros de digitação, em português coloquial)
• Carga concorrente (dezenas de requisições simultâneas)
• Mudança de modelo (o LLM que você usou hoje pode ser deprecated em 8 meses)
• Auditoria (quando o compliance pergunta "por que essa decisão?")
• Crescimento de tráfego (10x em um mês pode te quebrar se a arquitetura não for pensada)

A demo não treina nada disso. E é por isso que tantos projetos morrem na primeira semana de produção real.

Três decisões técnicas que precisam acontecer antes do build

Em todos os projetos que entreguei como IA viva em operação, três decisões aconteceram no sprint 1, não no sprint 5. Quem inverte essa ordem paga caro.

1. Definir o indicador antes da arquitetura

Pergunta simples: como vamos saber que essa IA está funcionando?

Se a resposta é "vamos ver depois", o projeto já começou errado. Indicador não é métrica de vaidade ("90% das conversas tiveram resposta"). É métrica de valor: conversão, tempo economizado, ticket fechado, erro evitado.

Em um projeto recente de conciliação financeira, definimos no primeiro dia: divergências não-detectadas no fechamento mensal. Esse era o número que o board iria olhar. Toda decisão técnica depois disso passou a ter critério: "isso melhora ou piora esse número?"

Sem indicador, qualquer escolha técnica é defensável. Com indicador, virou ciência.

2. Escolher o stack pela explicabilidade, não pela sofisticação

Vendedor de IA adora vender complexidade. Multi-agente, fine-tuning, embeddings vetoriais customizados, RAG hierárquico. Tudo isso tem lugar, mas raramente é o primeiro passo.

A pergunta certa é: se essa IA errar amanhã, eu consigo explicar por quê?

Modelo de risco de crédito com XGBoost + SHAP é menos "sexy" que um LLM ajustado, mas você consegue defender cada negativa em PROCON e BACEN. Em ambiente regulado, isso vale mais que precisão marginal de 2%.

O melhor stack é o mais simples que resolve o problema. Toda complexidade adicional precisa pagar conta de manutenção, observabilidade e auditoria depois.

3. Construir o guardrail antes do agente

Em produto regulado — financeiro, saúde, jurídico — o sucesso da IA é definido pelo que ela NÃO faz, mais do que pelo que faz.

Em um projeto recente de SDR para crédito PJ, antes de escrever uma linha do agente, escrevemos a lista do que ele nunca pode dizer: nunca prometer aprovação, nunca dar prazo, nunca antecipar taxa. Esse guardrail virou parte do prompt principal, e é testado a cada release.

Em 90 dias de operação, zero ocorrência de promessa indevida. Não porque o modelo é mágico — porque o limite foi desenhado antes do escopo.

O custo de pular essas três decisões

Quando você pula essas três decisões, o que acontece é previsível:

• Sem indicador, ninguém sabe se o projeto foi bem ou mal. Aí ele é "descontinuado por reorganização" no Q seguinte.
• Sem stack defensável, a primeira auditoria do BACEN ou da OAB derruba o projeto.
• Sem guardrail, basta o primeiro print de uma resposta inadequada virar viral pro projeto morrer.

E o que dá raiva é que nada disso é caro de fazer. Definir indicador é uma reunião de 2h com o sponsor. Escolher stack defensável é uma decisão de arquitetura, não de orçamento. Construir guardrail é trabalho de prompt, não de modelo.

Mas precisa acontecer antes. Depois do build, é caro.

Conclusão

A diferença entre uma IA que vira ativo e uma que vira fatura esquecida não está no modelo. Está nas três decisões que precisam acontecer no sprint 1: indicador documentado, stack defensável, guardrail antes do agente.

Quem inverte essa ordem paga em retrabalho, multas e cinismo do board sobre o próximo projeto de IA. Quem respeita essa ordem entrega no dia 1 — e o segundo projeto fica muito mais fácil de vender internamente.

Outros posts