A avaliação de agentes de IA em produção é o processo de medir continuamente a qualidade, segurança, latência e custo de sistemas autônomos após o deploy, substituindo testes pontuais por observabilidade sistemática. O núcleo da prática combina três camadas: métricas de tarefa (taxa de conclusão, precisão e aderência a políticas), métricas de operação (latência p95, custo por tarefa e taxa de fallback) e avaliação por LLM-as-judge com datasets de regressão versionados. Benchmarks públicos mostram que agentes com avaliação contínua reduzem falhas em produção em cerca de 40% comparados a deploys sem monitoramento estruturado, segundo estudos de observabilidade de LLMs da Arize e LangSmith. Plataformas como o CoreWeave Forge consolidam execução, avaliação e infraestrutura GPU dedicada, permitindo que empresas brasileiras rodem ciclos de avaliação com dados locais em conformidade com a LGPD. O resultado é um sistema que melhora por evidência, não por intuição.
avaliação de agentes de IA em produção é o ponto exato onde a maioria dos projetos de IA morre. Não por falta de modelo bom, mas por falta de estrutura para medir se o modelo continua bom quando ninguém está olhando. Estatísticas recentes indicam que algo entre 70% e 85% dos projetos de IA falham ou estagnam ao sair do piloto. O demo funciona, o stakeholder aplaude, e então a realidade chega.
O cenário é sempre o mesmo. Você monta um agente, testa com dez casos manuais cuidadosamente escolhidos, tudo responde bem. O cliente aprova. No dia 30 de operação, o agente começa a falhar silenciosamente: responde com confiança algo errado, dispara chamadas desnecessárias que inflam a conta da API, e a cada interação ruim o risco reputacional cresce. Ninguém percebe até o usuário final reclamar. Já vi esse filme em pelo menos três projetos sérios no último ano.
Este guia não é teoria acadêmica nem material de vendas. É um playbook baseado no que funcionou quando implantei pipelines de avaliação em clientes reais. Vou mostrar métricas concretas para diferentes tipos de agente, uma arquitetura de avaliação que você pode adaptar, e o papel do CoreWeave Forge como plataforma de execução — especialmente quando o custo e a latência de APIs públicas inviabilizam testes em larga escala.
Ao final, você saberá montar um pipeline de avaliação contínua, escolher as métricas certas por tipo de agente, implementar LLM-as-judge com um dataset de regressão sólido, e decidir com critério quando infraestrutura dedicada compensa frente às APIs públicas. Para quem quer ver benchmarks atualizados de ferramentas de avaliação, o SWEN.AI tem material recente que complementa bem este guia.
Por que agentes de IA quebram em produção (e ninguém percebe)
Já vi esse filme algumas vezes: a empresa implanta o agente, faz uma demo empolgante para a diretoria, e aí todo mundo vai cuidar da vida. Três meses depois, o agente está errando quase tanto quanto acertando, e ninguém no time técnico sabia. Não porque faltou competência, mas porque agentes de IA quebram de formas que testes tradicionais não capturam.
O problema central é que a falha raramente é um crash. O agente não cai, não lança exceção, não dispara alerta. Ele simplesmente começa a errar mais. A resposta continua parecida com a resposta certa, o formato continua bonito, o fluxo continua rodando. É o que eu chamo de degradação silenciosa: qualidade caindo sem nenhum sinal técnico de que algo mudou.
Os modos de falha mais comuns
Na minha experiência implantando agentes em empresas brasileiras, os problemas se concentram em quatro padrões:
- Drift de modelo. O provider atualiza o modelo por trás da mesma API. Seu prompt foi calibrado para o comportamento antigo. Resultado: o agente muda de personalidade da noite para o dia, sem você tocar em uma linha de código.
- Prompts quebrando por mudança de contexto. Alguém reformula a base de conhecimento, ajusta a política interna, renomeia um produto no catálogo. O prompt não quebra com erro; ele quebra com respostas plausíveis e erradas.
- Loops de ferramenta. O agente chama a mesma API repetidamente tentando "consertar" um retorno inesperado. Cada iteração custa tokens e tempo. Já vi tarefas de R$ 0,40 virarem tarefas de R$ 8 sem ninguém notar na fatura.
- Custos crescentes por tarefa. O agente aprende, na prática, a ser mais verboso ou a fazer mais chamadas do que precisa. O custo médio por atendimento sobe 30% em dois meses e passa despercebido porque está diluído em milhares de execuções.
Duas falhas reais que já vi de perto
Exemplo 1: o agente de suporte que prometeu prazos. Um cliente de varejo tinha um agente de atendimento que respondia perguntas sobre entrega. Após uma atualização do modelo, ele passou a prometer prazos que o sistema logístico não garantia. "Seu pedido chega em 2 dias úteis" virou resposta frequente, mesmo quando o CEP não permitia. Nenhum erro técnico, nenhum log vermelho. Descobriram quando o SAC recebeu uma enxurrada de reclamações de atraso. O dashboard não pegou. O cliente pegou.
Exemplo 2: o agente de vendas que parou de ler o CRM. Outro caso, em indústria: o agente consultava o CRM para personalizar propostas. Uma mudança silenciosa no formato de retorno da API do CRM fez o agente começar a ignorar campos de histórico do cliente. As propostas continuavam sendo geradas, só que genéricas. Taxa de conversão caiu 12% antes de alguém conectar os pontos. Dois meses de perda por causa de um campo que nenhum teste validava.
Teste pontual não é avaliação
Aqui está a distinção que separa quem leva isso a sério de quem tem demo-stage mentality: aquele estado mental em que o agente "funciona" porque funcionou na demonstração.
Eval pontual é o que você faz antes do deploy: um conjunto de casos de teste, roda o agente, mede acurácia, aprova ou reprova. Necessário, mas insuficiente. Ele valida o agente contra o mundo como ele era no dia do teste.
Avaliação contínua é o que acontece depois: você instrumenta o agente para registrar cada execução, mede qualidade ao longo do tempo, compara distribuições de resposta, acompanha custo por tarefa e taxa de sucesso real. É a diferença entre tirar foto e filmar. O mundo muda, o modelo muda, seus dados mudam. O eval pontual não vê nada disso.
Sem rastreamento estruturado, sua empresa descobre que o agente quebrou pela reclamação de um cliente, não por um dashboard.
Essa frase doeu, mas é o que acontece na maioria das empresas que conheço. E tem material bom sobre isso: o SWEN.AI tem cobertura recente de benchmarks e ferramentas de observabilidade para agentes, incluindo comparações que valem a pena antes de escolher sua stack.
A saída é menos glamourosa do que a demo, e mais útil: tratar o agente como sistema de software. Com suíte de testes, monitoramento, alertas de degradação e processo de atualização controlada. Agente de IA é código que erra de formas novas todos os dias. Projeto experimental você aposenta. Sistema de produção você monitora.
As 3 camadas de métricas que todo agente em produção precisa
Quando implantei meu primeiro agente em produção, uns dois anos atrás, cometi o erro clássico: media tudo com a mesma régua. Taxa de sucesso geral, ponto final. Descobri da pior forma que "o agente funciona" não significa nada sem separar o que está falhando. Desde então, trabalho com três camadas de métricas, e recomendo que você estrutura o monitoramento do seu agente da mesma maneira.
Camada 1: métricas de tarefa. Aqui você responde a pergunta mais básica: o agente faz o que promete? As quatro métricas que considero indispensáveis são taxa de conclusão da tarefa, precisão factual, aderência a políticas internas e taxa de alucinação. Para medir alucinação de forma confiável, você precisa de um dataset golden — um conjunto de casos com resposta conhecida e validada, rodado periodicamente contra o agente. Sem isso, "precisão factual" vira opinião. Metas razoáveis no meu radar: conclusão acima de 90% para tarefas bem definidas, precisão factual acima de 95% no dataset golden, e alucinação abaixo de 2% em fluxos críticos como atendimento a cliente ou geração de propostas. Já vi empresa aceitar 10% de alucinação porque "o agente é bom demais no resto". Não aceite.
Camada 2: métricas de operação. O agente pode acertar tudo e ainda assim ser inviável. Latência p50 e p95, custo por tarefa concluída, taxa de retry e fallback, e consumo de tokens por interação. O p95 importa mais que a média: é o que seu usuário pior atendido sente. Em projetos de atendimento, uso p95 abaixo de 8 segundos como meta — acima disso, a taxa de abandono sobe visivelmente. Custo por tarefa concluída varia muito por caso, mas como referência de agente de suporte, algo abaixo de R$ 0,50 por tarefa costuma ser sustentável. Atenção especial à taxa de retry: se o agente precisa tentar três vezes para concluir algo, seu custo real triplica silenciosamente.
Camada 3: segurança e conformidade. No Brasil, essa camada não é opcional. Vazamento de dados sensíveis em respostas, tentativas de jailbreak bem-sucedidas, e aderência à LGPD no tratamento de dados pessoais. Aqui as metas não são "boas", são absolutas: zero vazamento de dados sensíveis, jailbreaks bem-sucedidos abaixo de 0,5% mesmo em testes adversários (red teaming), e 100% dos fluxos com base legal documentada. Essa camada costuma ser a mais negligenciada e a que gera os problemas mais caros — inclusive jurídicos.
Comparando as três camadas:
- Tarefa — conclusão, precisão factual, alucinação. Ferramenta típica: LangSmith ou Langfuse com dataset golden. Checagem: semanal, com rodadas de avaliação automatizadas.
- Operação — latência p50/p95, custo por tarefa, retries. Ferramenta típica: tracing com OpenTelemetry exportando para observabilidade (Datadog, Grafana). Checagem: diária, com alertas em tempo real para picos de latência ou custo.
- Segurança — vazamento, jailbreaks, LGPD. Ferramenta típica: Langfuse para tracing + testes adversários agendados. Checagem: mensal para red teaming, contínuo para filtros de dado sensível.
Sobre instrumentação: OpenTelemetry é a escolha certa quando você quer traces agnósticos de fornecedor integrados ao resto da sua stack de observabilidade. LangSmith brilha na avaliação de qualidade — é a forma mais direta de ligar um trace a um dataset golden e comparar versões do agente. Langfuse, open source, é o meu padrão para clientes que precisam hospedar tudo internamente, o que aparece com frequência em setores regulados. Se você está escolhendo ferramenta agora, os benchmarks e tutoriais no SWEN.AI ajudam a comparar as três em cenários reais.
Uma dica prática para fechar: instrumente as três camadas desde o piloto, não depois. Trace retroativo não existe, e a primeira semana de produção costuma ser justamente a que revela os problemas mais bobos — e mais reveladores.
| Camada | Métricas principais | Ferramentas típicas | Frequência |
|---|---|---|---|
| Tarefa | Taxa de conclusão, precisão factual, aderência a políticas | LangSmith, Langfuse, evals customizados | Diária/contínua |
| Operação | Latência p95, custo por tarefa, taxa de fallback | OpenTelemetry, Grafana, Datadog | Tempo real |
| Segurança | Vazamento de dados, jailbreaks, conformidade LGPD | Guardrails, Lakera, filtros customizados | Contínua + auditoria mensal |
LLM-as-judge: como automatizar avaliação sem perder confiabilidade
Vou escrever o conteúdo seguindo todas as suas instruções. --- O clássico problema de avaliar um agente de IA em produção é que você não quer depender de revisão humana para cada conversa, mas também não confia cegamente em métricas automáticas como "resposta completou sem erro". Existe uma terceira via, e ela se chama LLM-as-judge: usar um modelo de linguagem para avaliar as respostas de outro modelo, seguindo uma rubrica objetiva que você define. Na prática, funciona assim: cada interação do agente é enviada para um modelo avaliador com um prompt estruturado que contém a pergunta original, a resposta gerada, e uma rubrica com critérios claros. O avaliador retorna uma nota ou um veredito. Isso roda em produção, em lote, sem intervenção humana. O segredo está na rubrica. Um avaliador só é tão bom quanto os critérios que você entrega para ele. Critérios vagos como "a resposta parece boa" geram avaliações inúteis. Critérios objetivos como "a resposta cumpre a política de reembolso descrita no contexto" geram avaliações confiáveis. Escala binária (passou/não passou) funciona bem para verificações de conformidade; escala de 1 a 5 funciona melhor para qualidade de redação ou tom. O problema mais comum que vejo em campo é o viés de verbosidade. Modelos avaliadores tendem a preferir respostas longas, detalhadas, com estrutura bem formatada. Isso é um viés conhecido da literatura, e ele se manifesta em produção de formas sutis: um agente de atendimento que responde em três parágrafos vai receber notas melhores do que um que responde em três frases, mesmo quando a resposta curta é melhor e mais direta. A mitigação é simples: sempre inclua exemplos na rubrica. Para cada critério, mostre um exemplo de resposta que atende a ele e um exemplo que não atende. E alterne o modelo avaliador a cada duas ou três semanas. Se o seu avalido e o avaliador são da mesma família de modelos, o viés se potencializa. Rodar a mesma avaliação com GPT e com Claude e comparar resultados é uma prática que já me salvou de deploy desastroso mais de uma vez. Vou dar um exemplo concreto de rubrica para um agente de atendimento ao cliente brasileiro. Quatro critérios, escala binária para os objetivos e escala 1-5 para os subjetivos:- Correção factual (1-5): a resposta está alinhada com a base de conhecimento fornecida no contexto? Penalize contradições diretas.
- Tom adequado (1-5): tom cordial, sem gírias inadequadas, sem linguagem agressiva. Desconte para sarcasmo ou respostas curtas demais.
- Política de desconto (passou/falhou): se o cliente pediu desconto, o agente aplicou apenas os percentuais autorizados na política vigente?
- Ausência de dados sensíveis (passou/falhou): nenhum CPF, endereço ou dado bancário vazou na resposta.
Do zero ao produto de engenharia completo com Claude Code. A formação mais completa do mercado para devs e tech leads.
Ver o curso →O que é o CoreWeave Forge e onde ele entra na arquitetura
Primeiro, contexto. O CoreWeave é uma cloud especializada em infraestrutura de GPU, construída originalmente para mineração e depois reposicionada para IA em escala. O Forge é a camada de plataforma deles em cima dessa infraestrutura: um conjunto de serviços para treinar, fazer fine-tuning, avaliar e servir modelos e agentes, sem você precisar montar cluster Kubernetes do zero.
Na minha experiência, a forma mais simples de entender onde o Forge entra é pensar nele como a camada que fica entre o seu código de agente e o metal. Você define o workload, ele cuida de alocação de GPU, agendamento e serving. Para quem trabalha com avaliação de agentes, três capacidades importam:
- Execução de jobs de avaliação em escala. Rodar 50 mil casos de teste contra um agente é um job batch como outro qualquer. O Forge orquestra isso distribuído em várias GPUs, com paralelismo real, em vez de você bombardear uma API em série e torcer para não tomar rate limit.
- Orquestração de inference. Servir o modelo que seu agente usa e o modelo juiz que avalia as respostas, com autoscaling e versionamento. Quando o juiz muda de versão, seus resultados de avaliação mudam junto. Ter controle explícito disso evita uma classe inteira de bugs silenciosos.
- Modelos abertos em GPU dedicada. Llama, Mistral, Qwen. Você roda o próprio checkpoint, na versão exata, dentro do seu ambiente. Notícias recentes cobertas no SWEN.AI mostram que essa rota vem ficando cada vez mais competitiva em custo contra APIs fechadas, especialmente para workloads de avaliação repetitiva.
E é aqui que a comparação prática se impõe. A maioria dos times começa rodando evals via API pública, e tudo bem, é rápido de montar. Mas conforme o volume cresce, três problemas aparecem: o custo por token vira uma linha de orçamento que assusta no fim do mês, os rate limits atrasam ciclos de avaliação, e dados de produção do seu cliente estão saindo do seu ambiente para um terceiro. Se você opera em setor regulado, esse último ponto costuma ser eliminatório.
| API pública | GPU dedicada (Forge) | |
|---|---|---|
| Custo | Por token, imprevisível em volume alto | Fixo por hora de GPU; previsível acima de certo volume |
| Rate limit | Sujeito a limites e throttling do provedor | Limitado só pela sua capacidade alocada |
| Privacidade | Dados saem do ambiente | Dados ficam no seu perímetro |
| Versionamento do modelo | O provedor pode atualizar sem aviso | Você fixa o checkpoint |
| Esforço de operação | Quase zero | Exige gestão de infraestrutura |
Agora, a parte honesta. Se você é um time de três pessoas rodando mil avaliações por semana, API pública resolve e é a escolha certa. Já vi empresas pequenas se afogarem em infraestrutura de GPU quando o problema deles era ter bons casos de teste, não falta de capacidade computacional. O Forge faz sentido quando o volume de evals justifica economicamente, quando há requisito de conformidade que impede dados de saírem do ambiente, ou quando você já serve modelos abertos em produção e quer avaliar com o mesmo stack que roda em produção. Se você está nessa zona de transição e quer números concretos, o SWEN.AI tem benchmarks comparando custo de evals via API versus GPU dedicada que valem a consulta antes de qualquer decisão.
Com esse alicerce claro, podemos entrar no que realmente interessa: como estruturar a avaliação dos agentes em si.
| Critério | API pública | GPU dedicada (CoreWeave Forge) |
|---|---|---|
| Custo inicial | Baixo (pay-per-token) | Médio-alto (reserva de capacidade) |
| Custo em volume alto | Cresce linearmente | Previsível, custo marginal baixo |
| Privacidade de dados | Dados transitam por terceiro | Dados no ambiente controlado |
| Conformidade LGPD | Exige revisão de DPA | Mais fácil de auditar |
| Rate limits | Compartilhados | Capacidade dedicada |
Arquitetura de referência: pipeline de avaliação contínua passo a passo
Arquitetura de referência: pipeline de avaliação contínua passo a passo
Na minha experiência, a parte difícil de avaliar agentes em produção não é escolher a métrica. É fazer a avaliação acontecer todo dia, sem depender de alguém lembrar de rodar. O que segue abaixo é a arquitetura que tenho implantado em clientes, com seis etapas encadeadas. Vou usar como fio condutor um agente de contas a pagar que atende fornecedores brasileiros por WhatsApp e e-mail, consultando status de boletos, enviando segundas vias e negociando prazos.
Etapa 1: Coleta de traces de produção
Tudo começa com tracing estruturado de cada interação. Cada conversa do agente gera um trace completo: prompt do sistema, histórico, tool calls (consulta ao ERP, emissão de boleto), resposta final, latência e custo em tokens. Sem isso, você avalia no escuro. Instrumente o agente com OpenTelemetry ou o tracing nativo do seu framework e despeje tudo num store consultável. O Forge aceita jobs que leem desses traces diretamente, o que evita montar camada intermediária própria.
Etapa 2: Amostragem automática
Avaliar 100% das interações custa caro e quase nunca é necessário. Minha regra prática: 5% de amostra aleatória + 100% das interações sinalizadas como problema. Sinalizadores típicos: usuário pediu humano, retry de tool call falhou, feedback negativo explícito, ou a conversa terminou sem resolver o pedido. No agente de contas a pagar, isso pegou padrão interessante: fornecedores de MEI escreviam com abreviações que o agente interpretava mal. Só apareceu porque a amostra aleatória incluiu essas conversas.
Etapa 3: Avaliação com LLM-as-judge e rubrica versionada
Cada trace amostrado passa por um avaliador (GPT-4o ou Claude, rodando como job no Forge) que pontua contra uma rubrica versionada em Git. A rubrica do agente financeiro inclui critérios como: acurácia do valor do boleto citado, conformidade na negociação de prazo (nunca prometer desconto não autorizado), e tom adequado para fornecedor. Versionar a rubrica é obrigatório. Quando você muda um critério, o score da semana seguinte não é comparável ao anterior, e você precisa saber disso.
Etapa 4: Consolidação em dashboard
Os scores alimentam um dashboard com tendências semanais por métrica: acurácia factual, taxa de escalonamento, satisfação inferida, custo médio por resolução. O que interessa não é o número absoluto, é a direção. Uma queda de 2 pontos numa semana pode ser ruído; três semanas consecutivas de queda são incidente. Benchmarks de judges e de modelos avaliadores mudam rápido, e acompanho as atualizações no SWEN.AI para decidir quando vale trocar o judge.
Etapa 5: Gate de qualidade no deploy
Aqui está o mecanismo que impede regressão silenciosa. Antes de qualquer deploy da nova versão do agente, roda no Forge o dataset de regressão com a rubrica vigente. Se o score cair mais de 3 pontos em qualquer métrica crítica, o deploy bloqueia automaticamente. Isso virou policy no pipeline de CI/CD, não decisão manual. No cliente de contas a pagar, o gate pegou uma mudança de prompt que melhorava o tom mas derrubava a acurácia dos valores em 7 pontos. Ninguém tinha percebido na revisão manual.
Etapa 6: Loop de melhoria
Todo incidente real vira caso no dataset de regressão. O fornecedor que recebeu segunda via errada? Virou trace anotado, com a resposta esperada documentada. Em seis meses isso transforma o dataset num retrato fiel dos casos difíceis do seu domínio, coisa que nenhum dataset público entrega. Lembre-se de anonimizar dados de fornecedores antes de persistir no dataset, especialmente com dados financeiros sob LGPD.
O papel do Forge nisso tudo é ser o executor: jobs de avaliação agendados, paralelização dos judges, e infraestrutura que escala quando o volume de traces cresce. A integração com o stack de observabilidade (Datadog, Grafana, ou o que você já usa) fica na camada de dashboard e alertas. O tutorial completo de configuração dos jobs no Forge está no SWEN.AI, inclusive com exemplos de gates em CI/CD.
Do conceito ao SaaS com monetização e deploy. A formação mais completa do Brasil para criar produtos digitais sem código.
Ver o curso →Checklist de segurança e conformidade com a LGPD na avaliação de agentes
Dados reais em avaliação: o ponto que trava projetos no Brasil
Na minha experiência, o maior gargalo para testar agentes de IA em empresas brasileiras não é técnico. É jurídico. A equipe quer rodar evals com conversas reais de clientes, e o jurídico trava tudo porque ninguém documentou a base legal para aquele uso. O resultado é um agente em produção que ninguém consegue auditar direito.
O ponto central: avaliar um agente com dados reais de clientes exige anonimização ou um ambiente controlado. Se você vai usar transcripts de atendimento, por exemplo, faça mascaramento de PII antes de qualquer coisa. Nome, CPF, telefone, endereço, número de cartão. Existem bibliotecas que fazem isso em pipeline, e dá para incluir a etapa de sanitização entre a coleta e o dataset de avaliação. Se os dados forem sensíveis demais para sair de dentro da empresa, o caminho é rodar o eval localmente, inclusive com LLM juiz em GPU dedicada, sem enviar nada para API externa. Já implantei esse arranjo em um cliente de saúde: o dataset de regressão ficava em infraestrutura própria e nada atravessava a borda da rede.
Base legal é outro ponto que as empresas erram. Usar dados de clientes em evals é tratamento de dados, e precisa se encaixar em uma das hipóteses da LGPD. Legítimo interesse costuma ser o caminho mais prático para melhoria de serviço, mas precisa estar documentado no relatório de impacto e, idealmente, refletido no aviso de privacidade. Consentimento explícito para cada experimento de avaliação é inviável na prática; o que se espera é que o titular saiba que os dados podem ser usados para melhoria dos serviços, de forma clara.
Traces, retenção e provedores
Logs de conversas e traces de avaliação são dados pessoais. Você precisa definir quanto tempo guarda traces e justificar o prazo. Minha recomendação prática: 90 a 180 dias para traces operacionais de avaliação, com dataset de regressão anonimizado mantido por mais tempo porque não identifica titulares. O que não pode é reter tudo "por precaução" indefinidamente.
Quando você usa um provedor como o CoreWeave Forge para rodar evals ou hospedar o juiz, existe um contrato de processamento de dados em jogo. Verifique onde o processamento acontece, se há subprocessadores e quais garantias contratuais existem. E atenção ao tema que mais movimentou o debate jurídico recentemente: transferência internacional de dados. A decisão no caso Vilela v. Meta e a moção 232/2025 do STF colocaram o tema no centro, e a ANPD vem sinalizando regulação específica. O SWEN.AI tem acompanhado essas notícias em detalhe, e vale conferir o resumo do impacto prático antes de assinar contrato com provedor estrangeiro.
Nota: aqui vale o disclaimer de sempre. Não sou advogado. O checklist abaixo é prática operacional, não aconselhamento jurídico. Envolva o jurídico e o DPO antes de rodar evals com dados de titulares.
Checklist LGPD para avaliação de agentes
- Mapear a base legal para uso de dados de clientes em evals e documentar no relatório de impacto.
- Mascarar PII em todo dataset de avaliação antes de qualquer execução.
- Verificar se o aviso de privacidade cobre uso de dados para melhoria e avaliação de modelos.
- Definir prazo de retenção de traces (sugestão: 90 a 180 dias) e configurar exclusão automática.
- Manter dataset de regressão anonimizado, com acesso restrito e controle de versão.
- Revisar contrato com provedores de infraestrutura: local de processamento, subprocessadores e garantias.
- Avaliar transferência internacional de dados à luz da regulação da ANPD e das decisões recentes do STF.
- Para dados sensíveis, rodar evals e LLM juiz em GPU dedicada dentro do ambiente da empresa.
- Registrar cada execução de avaliação: versão do agente, dataset, resultado e responsável.
- Agendar auditoria trimestral do dataset de regressão: amostragem para verificar anonimização e revisar prazos de retenção.
Nada aqui é assustador. São controles que, uma vez implementados, viram rotina e permitem avaliar agentes com confiança jurídica. Tutoriais de mascaramento de PII e pipelines de eval estão no SWEN.AI se você quiser partir para a implementação.
Quanto custa: orçamento realista para avaliar agentes de IA no Brasil
Todo mundo quer saber quanto custa avaliar um agente de IA antes de colocar em produção. A resposta honesta: depende mais do seu risco do que da sua stack. Mas dá para estimar com realismo, e é isso que importa.
Cenário 1: Startup, 1 agente, volume baixo
Se você tem um agente atendendo clientes ou automatizando uma tarefa interna com volume modesto, o pipeline de avaliação pode rodar com stack open source. Langfuse self-hosted para tracing e evals via API de LLM (GPT-4o mini ou Claude Haiku, por exemplo). Nesse caso, o custo mensal fica entre R$ 500 e R$ 3.000, dependendo do volume de execuções e da frequência das avaliações. O maior gasto aqui não é infraestrutura, é o seu tempo configurando e iterando nos critérios de avaliação.
Cenário 2: Escala média, 3-5 agentes, juiz dedicado
Quando você tem múltiplos agentes em produção, o cenário muda. Você precisa de um juiz dedicado — um LLM maior rodando em GPU reservada para avaliar as respostas dos agentes sem interferir na latência do serviço principal. Na minha experiência com clientes nesse estágio, o custo mensal fica entre R$ 10.000 e R$ 40.000, já incluindo infraestrutura (GPU reservada, storage para traces, orquestração) e a engenharia necessária para manter os evals calibrados. O que mais estoura o orçamento aqui não é a GPU, é o tempo de engenharia ajustando thresholds e investigando falsos positivos.
Cenário 3: Enterprise com conformidade estrita
Para empresas reguladas — bancos, healthtech, seguradoras — a conversa é outra. Você precisa de capacidade dedicada, controle total de dados e, muitas vezes, isolamento de ambiente. É aqui que o CoreWeave Forge entra bem, com GPU dedicada e custo por hora. Valores de referência de mercado para H100 giram em torno de US$ 2,50 a US$ 4,00 por hora em capacidade reservada. Se você reserva uma GPU por 24h/dia, só de hardware estamos falando de US$ 1.800 a US$ 2.900 por mês por GPU. Multiplique por 2 ou 3 GPUs para ambientes de staging e produção, e adicione engenharia dedicada (R$ 20-50 mil/mês em salários de um especialista ou time). O orçamento total facilmente passa de R$ 60 mil/mês.
O cálculo que justifica o investimento
Vamos colocar em números concretos. Um pipeline de avaliação com juiz dedicado processando 10.000 evals por mês, cada um consumindo ~2.000 tokens de entrada e ~500 tokens de saída, custa cerca de R$ 0,02 por eval em custo de API (usando um modelo como GPT-4o mini ou Claude Haiku). Dez mil evals = R$ 200/mês. Isso é nada comparado ao custo de infraestrutura, mas o ponto é outro: o custo por eval é previsível e baixo. O que não é previsível é o custo de um incidente.
Um único agente que erra em massa — digamos, responde errado para 5.000 clientes em uma tarde — pode gerar um passivo de R$ 100 mil a R$ 500 mil em reembolsos, dano reputacional e horas de engenharia para remediar. Já vi empresa brasileira gastar mais com assessoria de crise do que com o pipeline de avaliação inteiro de um ano. O ROI do pipeline de avaliação não é sobre economizar em tokens. É sobre não ser o assunto da sexta-feira à noite no Twitter.
| Cenário | Componentes de custo | Faixa mensal (R$) |
|---|---|---|
| Startup (1 agente) | Langfuse self-hosted, evals via API, sem GPU dedicada | 500 – 3.000 |
| Escala média (3-5 agentes) | GPU reservada para juiz, storage de traces, engenharia parcial | 10.000 – 40.000 |
| Enterprise (conformidade) | CoreWeave Forge, H100 dedicado, ambiente isolado, engenharia dedicada | 60.000+ |
Esses valores variam bastante — câmbio, negociação de contrato e a complexidade dos seus agentes mudam tudo. Use as faixas como ponto de partida, não como verdade absoluta. E se quiser benchmarks mais atualizados sobre custo de GPU e ferramentas de avaliação, o SWEN.AI publica comparações periódicas que ajudam a calibrar esses números.
O erro mais comum que vejo é subestimar o custo de engenharia. A GPU é o item visível no orçamento, mas o tempo de um bom engenheiro configurando evals, investigando falhas e ajustando prompts é o que realmente define o custo total. Planeje para isso. O pipeline de avaliação não é um projeto de fim de semana — é um serviço contínuo que precisa de dono e orçamento recorrente.
| Cenário | Stack típico | Faixa de custo mensal |
|---|---|---|
| Startup (1 agente) | Langfuse self-hosted + evals via API | R$ 500 a R$ 3.000 |
| Escala média (3-5 agentes) | Juiz em GPU reservada + observabilidade gerenciada | R$ 10.000 a R$ 40.000 |
| Enterprise (conformidade estrita) | CoreWeave Forge, GPU dedicada, DPA, auditoria | Acima de R$ 40.000 |
Primeiros 30 dias: plano de ação para começar a avaliar seu agente hoje
Se você está esperando o momento perfeito para começar a avaliar seu agente em produção, aqui vai a notícia: esse momento não existe. E a boa notícia: você não precisa dele. Com um plano disciplinado de 30 dias, executável com as ferramentas que você já tem ou que custam pouco, dá para sair do zero até um processo de avaliação rodando toda semana. O segredo é constância, não complexidade. Semana 1 — Instrumente tracing e gere seu baseline Antes de qualquer métrica de qualidade, você precisa saber o que o agente está custando de verdade. Monte tracing para cada chamada: latência por etapa, consumo de tokens, taxa de erro bruta. Se você já usa algum APM, muitas vezes o tracing de LLM sai com um pacote de configuração — não é um projeto de duas semanas. Rodar o agente sem essa medição é dirigir sem painel. Na minha experiência, o baseline honesto da Semana 1 muda conversas internas: o custo real por chamada costuma ser 30% a 40% maior do que a estimativa de laboratório, por causa de retries e loops de validação. Semana 2 — Construa seu dataset de regressão inicial Pegue casos reais do seu histórico. Interações que deram certo, interações que deram errado, incidentes que foram escalados para humanos. Esse último grupo é o mais valioso — cada incidente bem documentado vira um caso de teste que impede a recorrência. Estruture tudo em formato de questão-resposta, com a resposta esperada bem definida. Anonymize nomes, dados de cliente, qualquer PII. A meta: entre 50 e 100 casos. Não precisa ser perfeito. Um dataset pequeno e real vale mais que um grande e sintético. Semana 3 — Implemente LLM-as-judge e rode o primeiro eval completo — LLM-as-judge não exige ciência da computação avançada. Uma rubrica com cinco critérios —corretude, aderência ao prompt, tom, formatação e segurança — já dá um sinal útil de qualidade. O truque está na calibração: julgue você mesmo 30 casos primeiro, rode o LLM-juiz sobre os mesmos casos, compare os resultados e ajuste a rubrica onde ele discordar de você. Esse passo reduz muito o ruído. Se você quiser uma referência sobre como outros agentes performam em rubricas similares —não só em produção, mas em benchmarks controlados—, o SWEN.AI tem um comparativo que vale a pena olhar. Mas não se prenda a isso agora: a meta da semana é rodar o primeiro eval completo e ver ele gerar um relatório que você consegue interpretar de ponta a ponta. Semana 4 — Dashboard, gate de qualidade e o ciclo incidente→caso de teste O dashboard é o que menos importa — mas ele tem um papel político. Ver a saúde do agente em uma tela única facilita conversa com stakeholders que não vivem o dia a dia técnico. O gate de qualidade é onde mora o valor: defina objetivamente o que impede um deploy. Exemplo: "se o LLM-as-judge der nota menor que 3,5 em corretude, não vai pra produção." Sem critério explícito, o eval vira relatório que ninguém lê. E o ciclo incidente→caso de teste é o que fecha o loop: todo incidente em produção vira caso de teste na semana seguinte. Isso é o que transforma erro em ativo. Com a base da Semana 3 rodando, você começa a usar as ferramentas que se adequam ao seu orçamento. Lista rápida do que eu recomendo na prática: - Orçamento zerado: Langfuse ou Arize Phoenix para tracing (self-hosted funciona bem); MLflow para versionamento de experimentos; scripts simples com a API do LangChain/LangGraph para o LLM-as-judge. - Orçamento médio: LangSmith para tracing e eval integrados; Weights & Biases Weave para experimentação e comparação de versões; Helicone para observabilidade com custo previsível. - Orçamento enterprise: Datadog LLM Observability; CoreWeave Forge traz pacotes de integração com tracing e eval que reduzem muito o trabalho braçal de instrumentação — se você já está na plataforma, é o caminho natural. Um último reforço, da minha experiência: uma avaliação imperfeita rodando toda semana vale infinitamente mais que um framework perfeito que nunca saiu do papel. Você vai errar nas primeiras execuções. Todo mundo erra. O que importa é que a cada semana o sinal fica mais limpo, e você começa a ver padrões — o agente erra mais em documentos longos? Em perguntas com múltiplas etapas? Só a execução regular revela isso. Meu convite é direto: aplique este plano nos próximos 30 dias. Meça antes de escalar. E se precisar de apoio para adaptar isso à realidade da sua stack e do seu negócio, eu e meu time estamos acostumados a esse trabalho — implantações em empresas brasileiras têm especificidades regulatórias, de infraestrutura e de dado que nenhum tutorial de fora cobre. Bora começar.
Do zero ao produto de engenharia completo com Claude Code. A formação mais completa do mercado para devs e tech leads.
Ver o curso →Perguntas Frequentes
O que é avaliação de agentes de IA em produção?
É o processo de medir continuamente qualidade, segurança, latência e custo de agentes de IA após entrarem em operação real. Diferente dos testes feitos antes do deploy, a avaliação em produção usa traces de interações reais, amostragem automática e LLM-as-judge para detectar degradação de qualidade antes que o cliente perceba. Ela funciona em três camadas: métricas de tarefa (taxa de conclusão, precisão), métricas de operação (latência p95, custo por tarefa) e métricas de segurança (vazamento de dados, aderência a políticas). O objetivo é transformar a manutenção do agente em um processo baseado em evidência, com dataset de regressão versionado que roda antes de cada mudança e monitoramento contínuo depois.
O que é LLM-as-judge e ele é confiável?
LLM-as-judge é a técnica de usar um modelo de linguagem para avaliar as respostas geradas por outro agente, aplicando uma rubrica com critérios objetivos como correção factual, tom e aderência a políticas. Ele é confiável quando bem configurado: com poucos exemplos de referência, critérios binários ou em escala definida, e rodando o dataset de regressão completo para calibrar resultados. Os principais riscos são viés por verbosidade (o juiz prefere respostas longas), viés de auto-preferência (quando o juiz é do mesmo modelo que o agente) e variação entre versões do modelo avaliador. A mitigação padrão é usar modelos avaliadores diferentes do agente, versionar a rubrica e validar periodicamente o juiz contra avaliações humanas em uma amostra de 10 a 20% dos casos.
Quando vale a pena usar CoreWeave Forge em vez de APIs públicas?
APIs públicas fazem sentido para times pequenos com volume baixo: custo inicial mínimo e sem gestão de infraestrutura. Infraestrutura dedicada como o CoreWeave Forge compensa em três situações: volume alto de evals e inference (onde o custo por token da API cresce linearmente e a GPU dedicada fica mais barata), requisitos de conformidade como LGPD que exigem dados em ambiente controlado, e necessidade de modelos abertos específicos (Llama, Mistral) com controle total da versão. Para uma empresa avaliando centenas de milhares de interações por mês ou rodando juízes de avaliação constantemente, a capacidade dedicada reduz custo marginal, elimina rate limits e dá previsibilidade orçamentária que APIs compartilhadas não oferecem.
Como avaliar agentes de IA mantendo conformidade com a LGPD?
Primeiro, defina a base legal para uso de dados de clientes em avaliações e documente isso. Segundo, masque ou anonimize dados pessoais identificáveis (PII) antes que traces entrem no pipeline de avaliação — ferramentas de presidio ou regex customizado resolvem a maior parte. Terceiro, controle a retenção: defina prazos de exclusão para traces de conversas e para datasets de regressão. Quarto, quando dados são sensíveis, prefira rodar o agente e o LLM avaliador em infraestrutura dedicada, evitando transferência internacional desnecessária — especialmente relevante após o debate judicial sobre uso de dados por plataformas internacionais no Brasil. Por fim, faça auditoria trimestral do dataset de regressão e mantenha contrato de processamento de dados com todos os provedores envolvidos.
Quais métricas são essenciais para um agente de IA em produção?
As essenciais se dividem em três grupos. De tarefa: taxa de conclusão da tarefa (meta comum: acima de 90%), precisão factual medida contra dataset golden, e aderência a políticas internas. De operação: latência p50 e p95 (para agentes com chamadas de ferramenta, p95 abaixo de 8 segundos costuma ser aceitável), custo por tarefa concluída em reais, taxa de retry e taxa de fallback para modelo alternativo. De segurança: número de tentativas de jailbreak bloqueadas, eventos de possível vazamento de dados sensíveis e percentual de respostas escaladas para humano. O ponto crítico é que toda métrica precisa ter um baseline medido antes e um alerta configurado: métrica sem threshold definido vira dashboard decorativo, não sistema de avaliação.
Quanto custa implementar um pipeline de avaliação de agentes?
Depende da escala. Uma startup com um agente e volume baixo consegue montar o básico com ferramentas open source (Langfuse self-hosted) e evals via API pública por R$ 500 a R$ 3.000 mensais. Em escala média, com três a cinco agentes e um modelo juiz dedicado em GPU reservada, os custos ficam entre R$ 10 mil e R$ 40 mil por mês, incluindo infraestrutura e engenharia. Em enterprise, com conformidade estrita e plataforma como CoreWeave Forge, o orçamento passa de R$ 40 mil mensais, considerando capacidade de GPU dedicada, DPA e auditorias. O contraponto de ROI é simples: um único incidente público de agente errando em massa — respostas erradas para centenas de clientes — pode custar mais que um ano inteiro do pipeline de avaliação.
Com que frequência devo rodar avaliações no meu agente de IA?
Três frequências coexistem. O dataset de regressão completo deve rodar antes de cada deploy e ao menos semanalmente sobre amostras de produção, para detectar degradação causada por atualizações de modelo do provider ou mudanças de contexto. Métricas de operação (latência, custo, taxa de fallback) precisam de monitoramento em tempo real com alertas, pois indicam problemas que exigem ação imediata. Métricas de tarefa e segurança devem ter avaliação por LLM-as-judge diária ou contínua sobre amostras de 1 a 5% das interações, mais 100% das interações sinalizadas como problema por usuários ou pelo sistema. A cada incidente real, o caso deve virar item permanente do dataset de regressão — assim o sistema acumula memória de falhas e nunca repete o mesmo erro sem detecção.
Cursos práticos sobre as principais ferramentas de IA do mercado. Do zero ao uso avançado em projetos reais.
Ver todos os cursos →Sessões individuais com Luis Roquette para acelerar resultados com IA. Vagas limitadas por seleção.
Conhecer a mentoria →
