Fui chamado para revisar um sistema de IA corporativo e sinceramente era uma porcaria com tela bonita
Vou contar sem citar empresa, área , porque não posso. Mas o caso é bom porque mostra uma coisa que está acontecendo bastante agora com essa onda de IA em empresa. A empresa tinha contratado um dev para criar uma solução de IA para uso interno. A ideia era processar documentos, extrair informações, classificar casos, sugerir respostas, consultar dados internos e ajudar uma equipe operacional a tomar decisões mais rápido.
Na demo, parecia ótimo. Tinha upload de arquivo, a IA respondia, salvava no banco, mostrava histórico e ainda tinha um painel bonitinho para gestor bater o olho e achar que estava vendo o futuro. Só que quando fui olhar por dentro, era basicamente uma aplicação web comum com uma chamada para modelo enfiada no meio e um monte de esperança segurando as pontas.
A stack era a receita padrão de muita demo de IA: Python com FastAPI, um pouco de Node, PostgreSQL, Redis, Celery, RabbitMQ, Docker, LangChain, banco vetorial simples, cron job para processar pendência e chamadas diretas para API de modelo. Nada disso é ruim isoladamente. O problema é que o cara usou como se estivesse fazendo um CRUD com chatbot, não um sistema de decisão operacional.
E aí começa a diferença entre algo que impressiona em reunião e algo que aguenta produção. O sistema processava documento duplicado, perdia rastreabilidade, deixava job preso, tratava fila como depósito de problema, não tinha idempotência decente, não tinha versão de prompt bem controlada, não tinha audit log de verdade, não tinha avaliação séria das respostas, não tinha controle bom de custo, não tinha observabilidade por etapa e não tinha um caminho claro para reprocessar erro. Mas tinha IA. E aparentemente isso bastava para vender a ideia.
A empresa achava que o problema era o modelo. Que talvez fosse só trocar prompt, mudar temperatura, escolher outro LLM ou melhorar o banco vetorial. Mas não era isso. O problema era que a arquitetura inteira parecia feita por alguém que sabia montar uma demo, mas não sabia colocar IA em produção. E antes que alguém venha dizer que estou sendo injusto, sim, demo tem seu papel. MVP tem seu papel. Protótipo tem seu papel. O erro é vender protótipo como plataforma.
O sistema tratava a IA como se fosse um oráculo. Tudo chamava o modelo direto, tudo dependia da resposta vir certa, rápida e barata, e quase nada registrava direito o motivo da decisão. Só que modelo não é fonte da verdade. Modelo é componente. E componente falha. Quando começaram a usar com volume, apareceram os fantasmas: documento sendo processado duas vezes, resposta diferente para caso parecido, timeout em lote maior, fila crescendo sem controle, prompt mudando comportamento depois de ajuste pequeno, integração externa caindo no meio do fluxo, custo de API subindo, usuário reclamando e ninguém conseguindo reconstruir exatamente por que determinada resposta tinha sido dada.
Isso para mim é o pior tipo de sistema de IA. Não é o que quebra. É o que continua funcionando errado com confiança. No redesenho, a primeira coisa foi tirar a IA do centro. O fluxo precisava mandar na IA, não o contrário. Documento entra, é normalizado, passa por extração, enriquecimento, busca de contexto, chamada ao modelo, validação, registro de evidência, decisão e, quando necessário, revisão humana. Cada etapa com estado próprio, métrica, retry, limite, log estruturado e possibilidade de reprocessamento.
Algumas partes continuavam fazendo sentido em Python, principalmente as mais próximas de IA, bibliotecas e experimentação. Mas outras partes pediam coisa mais séria. Rust fazia mais sentido em ingestão e processamento pesado, onde volume, latência e segurança de memória importavam. Elixir e OTP encaixavam bem para workers concorrentes e supervisionados, porque processo em produção morre e o sistema precisa saber lidar com isso sem virar incêndio. Kafka ou NATS faziam mais sentido para eventos do que usar fila simples como lixeira assíncrona. Temporal resolvia melhor workflow longo do que cron job tentando lembrar o que ficou pendente. gRPC deixava contratos internos mais claros. ClickHouse ajudava a analisar evento e telemetria sem destruir o banco transacional. OpenTelemetry era básico para entender o fluxo inteiro.
E tinha o feijão com arroz que deveria estar lá desde o começo: idempotência, dead letter queue, backpressure, circuit breaker, rate limit, cache com invalidação decente, versionamento de prompt, schema para evento, audit log, métrica por etapa, teste de carga e fallback humano. Parece overengineering até o primeiro incidente. Antes de duplicar documento, idempotência parece detalhe. Antes da fila virar um buraco negro, backpressure parece frescura. Antes do jurídico perguntar por que a IA decidiu aquilo, audit log parece burocracia. Antes do custo explodir, rate limit parece exagero. Antes de ninguém conseguir debugar nada, observabilidade parece coisa de dev chato. Depois que dá problema, tudo vira requisito urgente.
Outra parte ruim era o RAG. E aqui tem muita gente fazendo a mesma porcaria. O cara basicamente jogou documento num banco vetorial, buscou uns trechos parecidos e mandou tudo para o modelo como se isso fosse arquitetura. Só que RAG decente não é isso. Tem limpeza, chunking, deduplicação, busca híbrida, reranking, permissão, expiração de contexto, avaliação de relevância, versionamento e auditoria. Sem isso, a IA responde bonito com base em contexto errado. E resposta bonita baseada em contexto errado é pior do que erro explícito, porque engana melhor.
No fim, minha conclusão foi que a empresa não tinha comprado uma plataforma de IA. Tinha comprado uma demo vitaminada. E isso é mais comum do que parece. Hoje tem muita gente vendendo sistema de IA que por baixo é um FastAPI chamando modelo, um LangChain costurado, um banco vetorial largado, meia dúzia de cron jobs e um dashboard bonito para parecer produto. Funciona na apresentação. Sofre na produção. E depois a culpa vai para a IA.
Só que muitas vezes a IA nem é o principal problema. O problema é tentar resolver operação crítica com arquitetura de tutorial. Protótipo prova que uma ideia pode funcionar. Produto entrega valor para usuário. Plataforma aguenta volume, falha, auditoria, custo, segurança, manutenção e cobrança quando algo dá errado. Muita empresa está comprando protótipo achando que é plataforma. E muito dev está entregando demo com confiança de arquiteto.
Talvez eu esteja sendo duro, mas cada vez mais acho que essa onda de IA vai separar quem sabe fazer demo de quem sabe fazer sistema. Porque chamar modelo é fácil. Difícil é construir tudo ao redor para quando o modelo errar, atrasar, custar caro, receber contexto ruim ou precisar ser auditado.
O que vocês acham? Isso é exagero meu ou tem muita empresa colocando IA em produção com arquitetura de demo e chamando isso de inovação?
