Agentes de IA em produção — o que aprendi deployando LLMs num ambiente enterprise
Colocar um agente de IA em produção numa empresa com compliance, SLA e time de segurança é diferente de fazer um demo no notebook. Aqui está o que ninguém conta.
Demo de agente de IA funciona em 20 minutos. Deploy em produção funciona em 20 semanas.
Não porque o código é mais complexo. Porque o ambiente é.
Quando você coloca um agente em produção numa empresa com compliance, a primeira coisa que aparece não é um bug técnico — é uma pergunta do time de segurança: "que dados esse agente acessa e onde eles ficam?"
Essa pergunta parece administrativa. Não é. Ela define toda a arquitetura do sistema.
Se o agente acessa dados de usuário, precisa de isolamento por tenant. Se processa informação financeira, entra em escopo de compliance. Se chama APIs externas, precisa de aprovação de vendor. Se armazena contexto, precisa de política de retenção.
Cada resposta cria um requisito. Cada requisito cria uma constraint. E constraints são onde demos morrem.
O que aprendi sobre observabilidade de agentes:
Logs de LLM são diferentes de logs de API. Uma chamada de API tem request e response — o que entrou e o que saiu. Uma chamada de LLM tem prompt, contexto, temperatura, seed, modelo, latência, tokens usados, tokens de cache, custo por chamada, e a resposta que pode variar mesmo com input idêntico.
Se você não logar tudo isso, você não consegue debugar. E debugar um agente que "às vezes dá resposta errada" sem log completo é o inferno.
Construí um wrapper que serializa cada chamada com correlation ID — o mesmo ID que flui pelo trace distribuído do serviço. Quando aparece um comportamento inesperado, consigo reconstruir exatamente o que aconteceu, com qual modelo, qual contexto, qual temperatura.
Parece óbvio. Não é o que vejo na maioria dos projetos de IA que olho.
O segundo problema: avaliar qualidade em produção.
Com código tradicional, você tem testes: ou passa ou falha. Com agente, a resposta "correta" muitas vezes é subjetiva, depende de contexto, e só é avaliável por um humano ou por outro LLM.
O que funciona: golden set. Um conjunto de inputs com outputs esperados, avaliados manualmente uma vez, que roda automaticamente em cada deploy. Não é 100% da qualidade — mas é sinal estável de regressão.
O que não funciona: confiar que "parece bom" no staging representa produção. Distribuição de inputs em produção é sempre mais estranha do que você imagina.
O terceiro problema: custo.
LLM tem custo por token. Agente tem múltiplas chamadas por request. Sistema com 10k usuários fazendo 5 requests por dia = 50k chamadas. Com contexto médio de 2k tokens por chamada, são 100M tokens por dia.
Fiz essa conta tarde demais num projeto. Tivemos que redesenhar o fluxo de contexto depois do deploy.
Cache de prompt resolve parte — mas só para o prefixo fixo do sistema. A parte variável (contexto do usuário, histórico da conversa) não cacheia. É aí que o custo mora.
O que recomendo antes de qualquer deploy de agente:
Primeiro, mapeie os dados que o agente acessa e responda as perguntas de segurança antes de começar a construir. Descubrir isso depois é refactoring caro.
Segundo, construa o wrapper de observabilidade na semana um. Não semana oito.
Terceiro, calcule o custo de produção com a distribuição real de inputs antes do launch. Teste com carga.
Quarto, defina o que "errado" significa para esse agente. Sem essa definição, você não consegue medir qualidade nem melhorar.
Essa semana: se você tem um projeto de IA que "funciona", pergunte: como você saberia se ele deixou de funcionar em produção amanhã?