IA em produção não morre no modelo. Morre na segunda semana.

Todo projeto de IA tem uma demo que funciona.

O modelo responde bem, o fluxo faz sentido, a sala aprova. O problema quase nunca está ali. Ele aparece quando o piloto encontra o sistema real da empresa — e isso raramente acontece no primeiro dia. Acontece na segunda semana.

Os quatro lugares onde ele morre

O código legado

A demo roda sobre um caso limpo. A operação real roda sobre anos de decisões acumuladas: regras de negócio que só existem dentro de uma função de 800 linhas, exceções que ninguém lembra por que foram criadas, um campo com três significados diferentes dependendo do fluxo.

Nenhum modelo entende isso sozinho. Ele precisa de contexto que não está no código — está na história do código.

A integração que ninguém documentou

Todo sistema em produção tem pelo menos uma. O endpoint que só funciona se você mandar o header numa ordem específica. O job que roda às 3h e assume que a tabela já foi populada. A fila que engasga com um payload acima de determinado tamanho.

O piloto não encosta nisso. A implementação real, sim — e é aí que o cronograma dobra.

O custo que ninguém mediu

Na demo, cada chamada custa frações de centavo e ninguém olha. Em produção, com volume real, retries, contexto grande e um agente que decide chamar o modelo mais caro porque a tarefa "pareceu difícil", a conta muda de ordem de grandeza.

Custo de IA não é uma linha de orçamento. É uma decisão de arquitetura: quem pode chamar o quê, com qual teto, e o que acontece quando o teto estoura.

O contexto que se perde

Entre uma conversa e outra, o sistema esquece. O que foi decidido ontem não influencia o que ele propõe hoje. Cada interação começa do zero — e a pessoa do outro lado paga o custo de reexplicar tudo.

Isso é tolerável numa demo de cinco minutos. É inviável numa operação que roda todo dia.

O que precisa existir antes do modelo

A pergunta certa não é "qual modelo usar". É o que precisa estar de pé para que qualquer modelo seja útil:

• Arquitetura — onde a IA entra no fluxo, o que ela pode e não pode decidir sozinha, e o que acontece quando ela erra.
• Contexto — uma forma de o sistema saber o que já foi decidido, não só o que está na tela agora.
• Governança de custo — limite por chamada, por tarefa e por agente, medido antes de virar fatura.
• Determinismo onde importa — nem todo passo pode ser improviso do modelo. Alguns precisam ser fluxo, com controle explícito.

Nada disso é glamouroso. É o que separa um piloto de um sistema.

Dia 200

A pergunta que a gente faz em todo projeto não é "isso funciona na demo?". É: isso ainda vai estar funcionando no dia 200?

Porque no dia 200 o time que construiu já mudou de foco, o volume triplicou, apareceram três casos de borda que ninguém previu e alguém precisa entender por que o sistema tomou a decisão que tomou.

É exatamente aí que a gente entra. Não construímos demos — construímos sistemas que continuam funcionando depois que a novidade passa.