O agente de IA erra. A pergunta certa é onde ele não pode errar

A primeira conversa com um cliente sobre agentes de IA quase sempre começa no lugar errado: 'ele vai errar?' A pergunta certa é outra. Todo agente erra em algum momento, da mesma forma que todo funcionário humano erra. O que diferencia uma operação confiável de uma catástrofe é onde o sistema não permite que o erro se propague. Confiança não nasce de um agente perfeito. Nasce de um desenho que sabe exatamente em quais pontos uma confirmação humana precisa existir antes que qualquer ação irreversível aconteça.

Por que o agente vai errar, e por que isso é previsível

Modelos de linguagem são sistemas probabilísticos. Eles não executam uma sequência determinística de passos como um script de regras fixas: eles raciocinam, e raciocínio implica chance de desvio. Um agente que interpreta uma nota fiscal pode entender o campo de quantidade de forma errada. Um agente que cria um pedido de compra pode confundir unidades entre fornecedores com nomes parecidos. Isso não é falha de implementação: é a natureza do instrumento. O erro de expectativa acontece quando uma equipe contrata um agente esperando comportamento idêntico ao de um software determinístico. São ferramentas diferentes, com garantias diferentes, e a governança precisa refletir isso.

Quais erros são toleráveis e quais ameaçam a operação

A taxonomia mais útil não é 'o agente errou ou não errou'. É 'o erro causou efeito reversível ou irreversível?' Um agente que classifica um e-mail na pasta errada causou um inconveniente. Um agente que lança um pedido de compra duplicado no Protheus causou um problema financeiro real que pode levar horas ou dias para ser desfeito, quando pode ser desfeito. A linha não está na probabilidade do erro: está no custo de reverter. Quanto mais difícil ou caro desfazer, maior a necessidade de uma barreira humana antes da execução.

O custo de um erro de agente não é o erro em si. É o custo de reverter o que o sistema já executou antes que alguém percebesse.

O que significa, na prática, desenhar com confirmação humana

Human-in-the-loop não é um modo de operação que você liga quando está inseguro. É uma arquitetura de decisão que se projeta antes de escrever a primeira linha de código do agente. Na prática, isso significa mapear cada ação que o agente pode executar e separá-la em dois grupos: ações que o agente executa de forma autônoma porque o custo de erro é baixo e reversível, e ações que exigem que um humano veja o que o agente está prestes a fazer e aprove antes que qualquer gravação aconteça. O agente propõe. O humano confirma. O sistema executa.

Em uma operação de compras integrada ao Protheus que a nossa equipe construiu, o agente processa a solicitação, consulta o catálogo de fornecedores, verifica o orçamento disponível e monta o pedido completo. Mas não grava nada. Ele apresenta o pedido para o comprador, que revisa em segundos e aprova com um clique. O resultado: o tempo de cada pedido caiu de 30 para 5 minutos, chegamos a zero erros de lançamento no ERP, e a mesma equipe passou a operar 6 vezes o volume anterior. A velocidade veio do agente. A confiança veio do ponto de parada obrigatório.

Como classificar operações por nível de risco antes de automatizar

O mapeamento de risco precede qualquer decisão de arquitetura. A pergunta para cada operação é direta: se o agente executar essa ação com um dado errado, o que acontece nas próximas 24 horas? Algumas operações têm baixo risco de propagação: enviar um resumo por e-mail, atualizar um campo de status interno, gerar um rascunho de documento. Outras têm alto risco: criar ou modificar um pedido de compra, dar baixa em estoque, aprovar um pagamento, alterar cadastro de fornecedor. A regra que aplicamos: qualquer ação que toque em saldo financeiro, saldo de estoque ou cadastro mestre exige confirmação humana antes da gravação. Sem exceção, sem atalho de configuração.

Por que a maioria dos pilotos de IA não chega à produção

Segundo levantamentos recorrentes da McKinsey e da Deloitte, a maioria dos projetos de IA corporativos não escala para produção. Uma das causas mais comuns não é a qualidade do modelo: é a ausência de uma arquitetura de governança pensada desde o início. O piloto funciona em ambiente controlado, com dados limpos e supervisão constante da equipe técnica. Quando vai para produção, os dados são sujos, os casos de borda aparecem, e o agente comete erros que o piloto nunca cometeu. Se não há um sistema de confirmação nos pontos críticos, o primeiro erro sério em produção mata a confiança da equipe operacional, e recuperar essa confiança pode levar meses, mesmo que o erro técnico tenha sido corrigido em horas.

Um piloto de IA que não foi desenhado com governança desde o início não falha no modelo. Falha no primeiro erro que chega à operação sem um humano no caminho.

O que acontece quando o agente mexe em estoque sem supervisão

Estoque é um dos ambientes mais perigosos para automação sem barreiras. Uma divergência entre o estoque físico e o sistema causada por uma baixa errada de um agente cria efeitos em cascata: pedidos de reposição incorretos, atrasos na linha de produção, discrepâncias no inventário fiscal, problemas em auditorias. Em operações industriais, esse tipo de propagação pode paralisar um turno inteiro. A velocidade que o agente traz ao processo não compensa esse risco se não houver um ponto de verificação antes do lançamento. O agente processa a movimentação, calcula tudo, prepara o registro. A baixa no sistema exige uma confirmação antes de ser executada.

Como colocar confirmação humana sem travar o fluxo de trabalho

O argumento mais comum contra o human-in-the-loop é que ele elimina a agilidade. Se o humano precisa aprovar, onde está o ganho? A resposta está em entender que a confirmação humana não precisa ser uma fila de aprovação burocrática. O agente pode processar 95% do trabalho cognitivo, entregar uma tela já preenchida e pedir apenas um gesto final de confirmação. O humano não precisa entender, calcular nem consultar. Precisa verificar e aprovar. Esse modelo ainda entrega o salto de capacidade porque o tempo cognitivo pesado já foi feito pelo agente. A confirmação existe, mas ela é rápida porque o trabalho está pronto.

A nossa infraestrutura própria tem esse padrão embutido como primitivo de arquitetura. Toda ação classificada como crítica gera automaticamente uma etapa de revisão humana antes da execução, com o contexto completo da decisão visível para o revisor. O agente não pula essa etapa. Ela não é opcional e não pode ser desativada por configuração.

Confiança como propriedade do sistema, não do agente

A mudança de perspectiva que importa é esta: confiança em automação não é uma propriedade do modelo de linguagem. É uma propriedade do sistema em que o modelo opera. Um agente probabilístico dentro de uma arquitetura bem desenhada, com pontos de confirmação humana nos nós de maior risco, pode ser mais confiável do que um processo manual cheio de passos ad hoc e sem registro de auditoria. A pergunta que todo gestor deveria fazer antes de qualquer projeto de automação não é 'esse agente é confiável?'. É: 'onde o meu sistema não pode errar, e o que eu construí para garantir isso?'

Confiança não vem de um agente que nunca erra. Vem de um sistema desenhado para que o erro nunca chegue a uma gravação irreversível sem que um humano tenha visto antes.

Quer ler a sua operação a fundo?