Por Que os Projetos de IA Falham Após a Demo

A demo foi um sucesso. Geralmente é.

O catálogo de produtos do cliente foi lido perfeitamente. A IA mostrou níveis de estoque precisos, resumiu pedidos recentes e respondeu dúvidas complexas sem pestanejar. Vinte minutos impecáveis. Seis semanas depois, em produção, o mesmo sistema travava em cada três requisições, inventava especificações de produtos inexistentes e já tinha custado mais em chamadas de API do que todo o projeto de desenvolvimento.

Nada mudou no código. O sistema estava fazendo exatamente o que fez na demo.

Esse é o padrão de erro mais comum no mercado de IA hoje.

A Demo Não Testa o Que a Produção Quebra

O primeiro problema é estrutural. Uma demo é construída sobre o "caminho feliz". Você escolhe dados limpos, escreve prompts para cenários previsíveis e apresenta o sistema para alguém que já quer acreditar que vai funcionar.

A produção é o mundo real: entradas malformadas, requisições simultâneas de madrugada quando o servidor está no limite, ou um cliente que sobe um PDF de 2009 com três colunas e espera que a IA extraia dados perfeitos. O LLM não "avisa" que não consegue — ele improvisa.

Quando um sistema não tem um mecanismo para dizer "eu não sei", ele preenche a lacuna com algo plausível. Isso não é um bug do modelo, é uma falha de design do sistema que o envolve.

O Custo que Ninguém Coloca na Planilha

Demos rodam em escala de teste. Dez perguntas não estressam uma API. Dez mil perguntas em uma semana de produção, sim.

Existe um padrão documentado: um workflow que processou 1.000 documentos no piloto (custo de R$ 250) saltou para R$ 60.000 na segunda semana ao rodar contra o volume real de 50.000 documentos por dia. O código era o mesmo. A diferença estava nos casos de borda e no volume, que fazem a contagem de tokens disparar.

É por isso que o semantic caching e o roteamento inteligente de modelos são cruciais antes de ir para a produção, e não depois que a primeira conta chega. Usar um modelo topo de linha para tarefas simples que um modelo mais barato resolveria é desperdício puro.

A Ilusão dos Dados Limpos

Demos rodam nos dados que você preparou com carinho. A produção roda nos dados acumulados há anos por pessoas que tinham outras prioridades.

Já conectei sistemas de IA a lojas WooCommerce onde metade das descrições de produtos estava vazia ou com eventos de conversão disparando em dobro. O modelo de IA trata tudo como verdade absoluta e produz resultados enviesados. Sem um pipeline que valide e limpe os dados antes de chegarem ao modelo, a saída será tão confiável quanto o pior registro do seu banco de dados. E demos raramente contêm o pior registro.

O Problema das Permissões

Este erro é menos técnico e mais perigoso.

Recentemente escrevi sobre um agente de IA com acesso total à stack de e-commerce que, ao seguir instruções vagas, acabou deletando listas de e-mail e quebrando o checkout. O agente não deu erro; ele apenas fez o que foi mandado com permissões de escrita ilimitadas.

Chaves de API com acesso mínimo, ambientes de staging e revisão humana são o básico. Nada disso aparece na demo, porque demos não precisam disso para impressionar.

O Que o RAG Realmente Resolve

Fala-se muito em RAG (Retrieval-Augmented Generation) como um termo da moda. Na prática, ele é o que separa o "parece certo" do "está certo". Conectar o modelo a uma base de dados vetorial com seus documentos e políticas reais é o que garante a precisão.

Além disso, a produção exige uma camada de avaliação: um segundo passo que audite as respostas da IA antes que o usuário as veja. Pode ser um agente revisor ou um gatilho de escalação para um humano quando a confiança do modelo cai.

Conclusão

A demo de IA é feita para gerar uma decisão: "vamos fechar o contrato?". Mas o trabalho real de construir algo que sobreviva ao contato com o mundo real só começa depois disso.

Antes da demo acabar, vale a pena perguntar: quem será o responsável pelo que acontecer na sexta semana de produção?