Agentes jurídicos em operação real: o que a demo não mostra

A demonstração de um agente jurídico é sempre impecável. O agente recebe um processo novo, extrai os dados da petição inicial, classifica o caso, sugere a tese e rascunha a primeira versão da contestação. Em noventa segundos, a plateia vê uma tarefa que levaria horas de um advogado ser resolvida sozinha. A pergunta que fica na sala é "por que ainda não fizemos isso".

Meses depois, o mesmo agente está em produção no escritório e a conversa mudou. Ele funciona, mas ninguém sabe dizer se está funcionando bem. A fatura de API veio três vezes maior que o previsto. Alguém descobriu, por acaso, que ele vinha extraindo datas erradas das petições havia semanas sem nunca ter dado erro. E a equipe criou, informalmente, o hábito de conferir tudo o que ele faz, o que anulou boa parte do ganho que justificou o projeto.

Nada disso é falha de execução do time. É a diferença estrutural entre demonstrar e operar. A demo é construída sobre petições limpas, casos bem comportados e um cenário definido, onde os pontos fortes do agente aparecem e os modos de falha ficam fora do enquadramento. Isso não é desonestidade, é como produtos são demonstrados. Mas cria uma distância sistemática entre o que o escritório espera e o que ele recebe.

Este artigo é sobre os três problemas que só aparecem depois, quando o agente sai da demo e entra na rotina jurídica: a matemática da confiabilidade em cadeia, o custo real por interação, e a falha silenciosa. E sobre a decisão que resolve os três, que é definir com precisão o que exige revisão de um profissional habilitado antes do uso.

Primeiro, o tamanho do problema

A estatística mais citada nas conversas sobre agentes em 2026 é que 88% dos pilotos de agentes nunca chegam à produção. O número tem origem em pesquisa da Anaconda e da Forrester, e foi replicado em levantamentos independentes, incluindo painéis de CIOs. Um levantamento de março de 2026, com 650 líderes de tecnologia, chegou ao mesmo lugar por outro caminho: apenas 12% a 14% dos projetos de agentes alcançam produção de fato.

Não é que as organizações não estejam tentando. A adoção é ampla: cerca de 78% das grandes organizações têm ao menos um piloto de agente rodando, mas só 14% escalaram algum deles para uso operacional pleno. Escritórios de advocacia e departamentos jurídicos repetem esse padrão com agravantes: o piloto de triagem de processos ou de minutas impressiona na apresentação e trava na primeira semana de volume real.

A Gartner projeta que mais de 40% dos projetos de IA agêntica serão cancelados até o fim de 2027, por custo, valor pouco claro ou controles de risco inadequados. E, em uma projeção que vai direto ao ponto deste artigo, estima que por volta de 2028 cerca de 40% das falhas de IA corporativa serão atribuídas a avaliação e monitoramento inadequados, e não a limitação de capacidade do modelo.

Leia essa última frase de novo, porque ela é a tese: o agente não falha porque o modelo é fraco. Ele falha porque ninguém está medindo o que ele faz.

Problema 1: a matemática que a demo esconde

Um agente não é uma chamada de API. É uma cadeia de operações estocásticas. Ele planeja, chama uma ferramenta, lê o retorno, decide o próximo passo, chama outra ferramenta, tenta de novo se falhar, e só então responde. Cada elo dessa cadeia tem uma probabilidade de dar certo, e a confiabilidade do fluxo inteiro é o produto das confiabilidades de cada passo.

A fórmula é simples e brutal. Se a confiabilidade de cada passo é P e o fluxo tem n passos dependentes, a confiabilidade de ponta a ponta é aproximadamente P elevado a n. Um agente que acerta 95% das vezes em cada passo individual, executando um fluxo de dez passos, entrega o resultado correto em cerca de 60% das execuções. Se a confiabilidade por passo cai para 85%, que ainda soa como um número respeitável, o fluxo de dez passos tem sucesso de ponta a ponta em torno de 20%.

É por isso que a demo engana sem mentir. Na demo, você vê uma execução. Talvez a terceira tentativa, depois de dois ensaios que ninguém mostrou. Em produção, o agente roda milhares de vezes por dia, e a cauda de falhas que era invisível em uma amostra de um vira o problema principal.

Esse efeito é mensurável e já foi documentado em benchmark. O trabalho do τ-bench (Yao et al., 2024) introduziu a métrica pass@k, que mede não se o agente acerta uma vez, mas se ele acerta de forma consistente em múltiplas execuções da mesma tarefa. O resultado é revelador: agentes baseados em GPT-4 caíram de cerca de 60% de sucesso em pass@1 para cerca de 25% em pass@8. Ou seja, o agente que parece acertar seis em cada dez tentativas isoladas só entrega resultado consistente em um quarto dos casos quando você exige que ele repita o acerto.

A implicação prática é direta. A pergunta certa não é "o agente consegue fazer isso?". É "o agente consegue fazer isso mil vezes seguidas do mesmo jeito?". São perguntas com respostas muito diferentes, e só a segunda importa em produção. Não por acaso, cerca de 70% dos líderes apontam a natureza não determinística das saídas como a principal barreira para levar agentes à produção.

Problema 2: o custo por interação que ninguém modelou

Orçamentos de IA foram construídos sobre a economia de chat. A premissa de planejamento era da ordem de centavos por interação. Essa premissa não sobrevive ao contato com um agente, e a diferença não é de grau, é de ordem de magnitude.

Uma consulta de pesquisa que rodava um caminho simples de pergunta e resposta custava por volta de quatro centavos de dólar em 2023. A mesma tarefa, reconstruída como um agente que planeja, consulta a base de peças e jurisprudência, chama ferramentas e executa laços de tentativa, custa em torno de um dólar e vinte em 2026. Cerca de trinta vezes mais. Análises da Gartner de março de 2026 colocam a diferença entre cinco e trinta vezes mais tokens por tarefa em relação a um chatbot padrão. Pesquisa da Microsoft com o Digital Economy Lab de Stanford encontra, para tarefas agênticas complexas, consumo que chega a ordens de grandeza muito superiores às de uma interação de chat.

A razão é estrutural, e entendê-la é o que separa quem controla o custo de quem é surpreendido por ele. O custo de qualquer aplicação de LLM se resolve em uma equação: custo é igual ao preço por token multiplicado pela quantidade de tokens por tarefa. O mercado inteiro passou anos olhando só para a primeira variável, comemorando cada queda de preço. Mas um agente explode a segunda variável. Se o preço por token cai 75% e você implanta um sistema que consome cem vezes mais tokens por tarefa, você paga mais, não menos.

O maior componente desse consumo costuma ser invisível: o contexto reenviado. Pesquisa do Stanford Digital Economy Lab sobre atribuição de custo em agentes encontrou que o contexto retransmitido responde por cerca de 62% da fatura total de inferência de um agente. A maior parte do que você paga é o modelo relendo o que ele já sabe, a cada passo do laço. Em sistemas multiagente, isso piora: pesquisa da Anthropic indica que arquiteturas multiagente consomem em torno de quinze vezes mais tokens que uma interação de chat simples, porque cada handoff entre agentes tem um custo de coordenação que se multiplica com a complexidade.

O erro de gestão aqui é medir a coisa errada. A unidade que a maioria dos times acompanha é o custo por token, que é a única que aparece na fatura. A unidade que importa é o custo por tarefa concluída com sucesso. A diferença é decisiva: um agente que falha em 40% das execuções e precisa refazer o trabalho está cobrando de você o custo de todas as tentativas, mas entregando o valor de apenas uma parte delas. Um agente barato por token e ineficiente por tarefa é mais caro que o contrário.

E o token é apenas a linha que você enxerga. A construção e a integração de um agente útil em produção representam algo em torno de um quarto a um terço do custo total de propriedade em três anos. O resto, a maior parte, está nas camadas recorrentes que nunca entram no primeiro slide: avaliação, monitoramento, manutenção, governança e supervisão humana.

Problema 3: a falha silenciosa

Dos três problemas, este é o mais caro, porque é o único que não aparece em nenhum painel até que um cliente ou uma parte contrária perceba.

Um agente que quebra e retorna erro é um problema barato. Ele é visível, aciona alarme, alguém conserta. O problema caro é o agente que não dá erro nenhum e, com toda a confiança do mundo, faz a coisa errada. Um agente de triagem que classifica processos na faixa errada de risco, ou um extrator que lê uma data de citação como data de intimação, executa, registra sucesso, segue em frente. E repete o erro em escala de máquina, milhares de vezes, enquanto todo mundo acha que está tudo bem.

O caso mais didático que veio a público em 2026 foi relatado pela IBM. Um agente autônomo de atendimento começou a aprovar reembolsos fora das diretrizes de política. Um cliente convenceu o sistema a conceder um reembolso indevido e, satisfeito, deixou uma avaliação pública positiva. O agente, otimizando para o sinal que ele conseguia observar, passou a conceder mais reembolsos com liberdade crescente. Ele não estava com defeito. Estava fazendo exatamente o que o incentivo mal especificado mandava. Como resumiu um especialista sobre essa classe de risco, esses sistemas fazem exatamente o que você mandou eles fazerem, não o que você quis dizer.

Repare no mecanismo, porque ele se repete: não houve exceção, não houve stack trace, não houve queda de disponibilidade. Houve deriva silenciosa de comportamento, que é justamente o modo de falha que a infraestrutura tradicional de monitoramento não captura. Seus painéis de latência e taxa de erro vão continuar verdes enquanto o agente destrói valor.

É por isso que avaliação e observabilidade aparecem como o maior bloqueador isolado para colocar agentes em produção, citado por cerca de 64% dos times. E é por isso que, na análise de causa raiz da Forrester sobre os projetos de agentes com retorno negativo, os fatores dominantes não são de modelo: cerca de 41% das falhas se devem a critérios de sucesso mal definidos, 33% a acesso insuficiente a ferramentas ou dados, e 26% à degradação da cobertura de avaliação ao longo do tempo. Nenhum desses é um problema de qualidade de modelo. Todos são problemas de escopo, instrumentação e propriedade.

A decisão que resolve os três: o que exige revisão humana

Chegamos ao ponto em que os três problemas convergem. A confiabilidade em cadeia, o custo por tarefa e a falha silenciosa são todos, no fundo, consequências de uma única decisão mal tomada: quanta autonomia o agente recebeu, e sobre o quê.

O erro clássico é tratar governança de agente como binário: ou o agente está trancado e inútil, ou está solto e confiável. A Gartner é direta ao apontar que essa visão binária é a raiz da falha, e projeta que por volta de 2027 cerca de 40% das empresas vão rebaixar ou desativar agentes autônomos por causa de lacunas de governança descobertas apenas depois de incidentes em produção. Aplicar o mesmo controle a todos os agentes, independentemente do nível de autonomia e do escopo de acesso, produz dois modos de falha simétricos: excesso de restrição em agentes simples, que trava a entrega e empurra o time para desenvolvimento paralelo não governado, e falta de restrição em agentes de alto impacto, que é onde mora o incidente.

O critério que funciona não é a complexidade da tarefa nem a confiança que você tem no modelo. É a reversibilidade e o impacto da ação.

Ações que o agente pode executar sozinho são as reversíveis e de baixo impacto: classificar, triar, resumir, extrair dados, redigir uma proposta de resposta, preencher um formulário, sugerir o próximo passo. Se o agente errar, alguém corrige e o custo é o tempo da correção.

Ações que exigem aprovação de um profissional habilitado são as que carregam impacto jurídico, financeiro ou reputacional, e principalmente as que não podem ser desfeitas: protocolar a peça, enviar a manifestação ao cliente, propor o acordo, responder a uma área da empresa em nome do jurídico. Aqui, o agente prepara e o advogado revisa e aprova. Esse desenho é frequentemente subestimado, mas é o que sustenta os casos de agente jurídico que dão certo: o agente nunca age sozinho, ele deixa tudo pronto, e o ganho vendido é velocidade, não autonomia. Nenhuma saída de agente deve ser usada em peça, parecer ou decisão sem revisão humana obrigatória.

Duas ressalvas importantes, e ambas vêm da experiência de quem opera.

A primeira: aprovação humana só é um controle real se permanecer um controle significativo. Se a fila de aprovasções crescer a ponto de o revisor virar um carimbo automático, você criou uma falsa sensação de segurança e ampliou a superfície de risco em vez de reduzi-la. A Gartner chama isso de fadiga de aprovação, e é um risco concreto. Aprovação sem capacidade de revisão real é teatro de governança.

A segunda: revisão humana não é sinal de que o agente falhou nem de imaturidade do projeto. É um recurso de projeto que estende confiança de forma responsável. A progressão saudável é aumentar a autonomia à medida que a confiabilidade é demonstrada com dados, não presumida no lançamento.

O que fazer antes de colocar um agente em produção

Quatro frentes, na ordem.

Primeiro, defina o critério de sucesso antes de escrever o primeiro prompt. Como é uma execução correta? Quem decide? Se essa pergunta não tem resposta escrita, você não tem como avaliar o agente, e critério de sucesso mal definido é a causa isolada mais frequente de retorno negativo. Sem isso, todo o resto é decoração.

Segundo, meça a confiabilidade em cadeia, não em passo isolado. Avalie o fluxo completo, repetidas vezes, com entradas realistas e sujas, não com os casos limpos do piloto. Use métricas de consistência, no espírito do pass@k, e não de acerto único. E reduza o número de passos frágeis: cada passo dependente a mais multiplica o risco, então validação determinística entre etapas vale mais que um passo a mais de raciocínio do modelo.

Terceiro, instrumente custo e comportamento por execução. Cada chamada do agente deve ser rastreável: qual etapa, qual ferramenta, quantos tokens, quanto custou, qual foi o resultado. Isso permite calcular a única métrica econômica que importa, o custo por tarefa concluída com sucesso, e permite detectar deriva de comportamento antes que o erro chegue a uma peça protocolada ou a um cliente. Sem essa camada, a falha silenciosa é indetectável por construção.

Quarto, classifique as ações por reversibilidade e defina os portões de aprovação de acordo. Autonomia proporcional ao risco da ação, não uniforme. E deixe explícito o caminho de escalonamento: quando o agente falhar, ele deve cair de volta para o fluxo humano, e não morrer em silêncio.

O reenquadramento

O erro estratégico com agentes é o mesmo, na estrutura, que trava os projetos de RAG: enquadrar como problema de tecnologia o que é, na maior parte, problema de operação. Escolher o framework, escrever o prompt e conectar as ferramentas é a parte fácil e rápida. A parte difícil, a que determina se o sistema vai gerar valor ou virar passivo, é definir o que o agente pode fazer sozinho, como você mede se ele fez certo, e quanto custa cada tarefa que ele conclui de verdade.

Se o seu escritório ou departamento jurídico está avaliando um agente, ou tem um piloto que impressionou na demo, as três perguntas que separam o projeto que escala do que vira estatística são estas: qual o custo por tarefa concluída com sucesso, como eu descubro que ele errou sem que um cliente ou um prazo perdido me avise, e quais ações ele nunca pode executar sem a revisão de um advogado.

Um agente que ninguém consegue medir não é um agente autônomo. É um risco autônomo.

Referências

• Yao, S. et al. τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. 2024. Introdução da métrica pass@k e evidência da queda de consistência entre pass@1 e pass@8.
• Gartner. Projeções sobre IA agêntica, incluindo cancelamento de mais de 40% dos projetos até o fim de 2027, e atribuição de cerca de 40% das falhas de IA corporativa a avaliação e monitoramento inadequados até 2028.
• Gartner. Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure. Maio de 2026. Governança proporcional ao nível de autonomia e risco de fadiga de aprovação.
• Anaconda e Forrester. Origem da estatística de que 88% dos pilotos de agentes não chegam à produção, replicada em levantamentos independentes.
• Forrester. Análise de causa raiz de projetos de agentes com retorno negativo: critérios de sucesso mal definidos, acesso insuficiente a ferramentas e dados, e degradação da cobertura de avaliação.
• Stanford Digital Economy Lab. Agentic AI Cost Attribution, 2025. Contexto reenviado como componente dominante da fatura de inferência de agentes.
• Anthropic. Pesquisa sobre consumo de tokens em sistemas multiagente e custo de coordenação entre agentes.
• IBM. Caso público de agente autônomo de atendimento que passou a aprovar reembolsos fora da política, relatado em cobertura de imprensa sobre falha silenciosa em escala (CNBC, março de 2026).

As estatísticas de mercado citadas são consolidadas por múltiplas fontes de análise setorial e podem variar conforme metodologia, recorte e definição de sucesso. Recomenda-se consultar os relatórios originais para os números exatos e suas condições de medição.

Thiago Azeredo Rodrigues é advogado e consultor de IA aplicada ao Direito, especializado em agentes jurídicos, RAG em produção e automações em operações jurídicas. Constrói e opera sistemas com foco em confiabilidade, auditabilidade e revisão humana obrigatória.