logotipo

Os agentes falham exatamente onde a verdadeira empreitada começa: nas exceções.

26 de agosto de 2026

Os agentes de inteligência artificial funcionam bem em situações normais, mas falham em exceções, que é justamente onde reside a dificuldade de qualquer negócio. O pedido padrão é processado automaticamente; é no pedido com entrega parcial, no caso de um cliente com um problema em aberto e de um acordo comercial negociado por telefone que fica claro se a automação contribui ou atrapalha.

Nos processos que mapeamos, esse conjunto de casos "raros" normalmente representa entre 15% e 30% do volume. Não se trata de um resíduo: é um quarto da operação e geralmente concentra uma proporção muito maior do valor e do risco.

Por que as demonstrações nunca mostram exceções?

Porque não se aprende isso em vinte minutos. Uma demonstração precisa ser compreensível, e exceções são, por definição, aquilo que não é compreensível sem conhecimento do negócio.

Isso cria um viés sistemático nas decisões de compra. A ferramenta é avaliada com base no teste fácil 70%, é aprovada e o teste difícil 30% aparece em produção, quando já não se trata mais de uma decisão de compra, mas sim de um problema do projeto. É a mesma dinâmica que descrevemos ao falar sobre o purgatório do pilotoO projeto piloto evita, por definição, tudo o que possa dificultar a produção.

Há também uma razão técnica. Um modelo de linguagem não distingue entre "Eu não sei" e "Isso não corresponde ao que eu vi". Diante de um caso atípico, ele não para: preenche as lacunas. Produz uma resposta plausível construída a partir dos padrões que conhece, e essa resposta tem o mesmo tom de certeza que as respostas corretas. Em um processo automatizado, essa confiança indistinguível é o problema, não uma alucinação ocasional.

Os cinco tipos de exceções que precisam ser mapeados

Cara

Exemplo

Como tratar isso

Dados ausentes ou contraditórios

O cliente aparece com dois números de identificação fiscal diferentes.

Pare e suba: nunca escolha uma opção.

regra não escrita do negócio

Condição acordada verbalmente com o cliente.

Documente a regra ou exclua o cliente do fluxo.

Limite ultrapassado

Quantidade, volume ou desconto fora do intervalo

Validação humana obrigatória

Estado incompatível

Pedido para um cliente com pagamento pendente

Bloqueio com justificativa explícita

caso juridicamente sensível

Dados de saúde, menores, decisões sobre pessoas

Fora do alcance do agente

A utilidade desta tabela não é teórica: ela serve como roteiro para uma sessão de trabalho de duas horas com as pessoas que estão implementando o processo atualmente. A pergunta a ser feita a elas não é "como o processo funciona" — elas explicarão isso em sua versão ideal —, mas sim "como ele funciona". «"Conte-me sobre o último caso que lhe deu trabalho."». Três ou quatro pessoas respondendo a essa pergunta produzem o mapa completo de exceções em uma tarde.

A regra explícita do "Eu não sei"

O aspecto mais importante no projeto de um sistema automatizado é o que acontece quando há incerteza. E para que algo aconteça, deve haver a possibilidade de o sistema declarar incerteza.

Isso requer três decisões de projeto:

Defina o que é uma condição de parada. Não se trata de uma pontuação de confiança abstrata, mas sim de condições comerciais concretas: faltam estes dados, este valor ultrapassa o limite, este cliente encontra-se nesta situação. As condições que são compreensíveis para uma pessoa são aquelas que podem ser auditadas e discutidas em comissão.

Defina onde dimensionar. Uma fila específica, com um responsável e um prazo. Uma exceção que é encaminhada para uma caixa de correio genérica não foi resolvida: foi adiada.

Defina quais informações acompanham o escalonamento. O agente deve apresentar um caso preparado: o que encontrou, o que está faltando e quais opções considera viáveis. É aí que reside a maior parte da economia de tempo, que se mantém mesmo que a decisão final seja tomada por uma pessoa.

Um sistema projetado dessa forma não automatiza o 100% do processo. Ele automatiza todo o 70% e preparar os 30% restantes. Em quase todos os casos que medimos, isso gera mais economia líquida do que tentar automatizar os 100% e ter que revisar tudo devido à desconfiança.

O erro de tratar a exceção como uma falha do sistema.

Há uma consequência cultural que vale a pena antecipar. Quando o indicador apresentado ao comitê é a "porcentagem de automação", a equipe tem um incentivo para reduzir as escalações, e a maneira mais rápida de fazer isso é expandir o escopo do agente para casos que ele não deveria estar tratando.

Portanto, o indicador correto não é a porcentagem automatizada, mas sim o custo total por caso resolvido corretamente. Um sistema que automatiza o 70% e dimensiona bem o 30% geralmente é mais barato do que um que automatiza o 95% e gera retrabalho, reclamações e desconfiança no 25%, que não deveria ter sido afetado.

Uma taxa de crescimento saudável não é uma taxa baixa. É uma taxa estável e explicável.

O que fazer se o sistema já estiver em produção sem isso?

Não há necessidade de reescrevê-lo. O caminho usual tem três etapas e pode ser executado sem interromper a operação:

  1. Implemente primeiro a entrada e a ação. Essas são as duas camadas que nos permitem reconstruir um incidente. Com isso, podemos responder à pergunta "o que aconteceu".
  2. Adicione o registro de validação. Isso requer uma pequena alteração na interface de revisão e produz os dados de qualidade mais valiosos.
  3. Defina o limite de alerta antes de obter os dados. Qual taxa de correção ou custo por caso desencadearia uma revisão? Definir isso após analisar os números garante que seja ajustado para que nunca desencadeie uma revisão.

O erro a evitar é tentar implementar tudo de uma vez. Um sistema com duas camadas bem alinhadas é infinitamente mais gerenciável do que um com cinco camadas parcialmente alinhadas.

Como isso se traduz em design de processos?

O mapeamento de exceções não é uma etapa preliminar em um projeto de IA; ele é o próprio projeto. Quando bem executado, produz quatro entregáveis que se sustentam por si só, independentemente de serem automatizados posteriormente ou não:

  1. O mapa real do processo, Incluindo o que realmente acontece e não o que o manual diz.
  2. As regras não escritas dos negócios, Finalmente, o documento está escrito. Normalmente, este é o documento que gera o maior impacto a curto prazo, pois reduz a dependência de pessoas específicas.
  3. A classificação dos casos por risco, que determina o que pode ser automatizado e o que nunca deve ser alterado.
  4. O projeto de escala, É isso que torna o sistema resultante operacional.

Este é exatamente o trabalho que fazemos antes de propor qualquer automação, e a razão pela qual insistimos que Primeiro, o processo é definido e, em seguida, é automatizado. . Não se trata de uma preferência metodológica: é a única maneira de saber qual parte do processo pode ser automatizada sem precisar descobrir isso em produção.

A comprovação que você deve exigir antes de assinar.

Quando um fornecedor apresentar uma solução baseada em agentes, peça uma coisa específica: que a demonstração inclui o caso raro de sua escolha.

Não se trata de um caso genérico ou raro. É um caso como o seu, com seus dados incompletos e sua regra de negócio não escrita. A resposta a essa solicitação diferencia alguém que construiu um sistema de alguém que criou uma apresentação.

Se a resposta for que este caso será tratado numa fase posterior, você já sabe onde estará o estouro de orçamento do projeto.

Perguntas frequentes

Por que os agentes de IA falham em casos de exceção?

Porque um modelo de linguagem não distingue entre "Eu não sei" e "Isso não condiz com o que eu vi": diante de um caso atípico, ele não para, ele completa o processo. Ele produz uma resposta plausível com o mesmo tom de certeza das respostas corretas, tornando o erro difícil de detectar em um processo automatizado.

Nos processos que mapeamos, esses eventos normalmente ocorrem entre 15% e 30% do volume, embora concentrem uma proporção maior do valor e do risco. Isso não é um resíduo estatístico: é uma parte substancial da operação em si.

Em vez de pedir que descrevam o processo, pergunte a quem implementa o sistema sobre o último caso problemático. Com três ou quatro pessoas, é possível obter um panorama completo em uma única sessão. Os tipos de problemas mais comuns são: dados ausentes ou contraditórios, regras não escritas, limite excedido, status incompatível e casos juridicamente sensíveis.

Parar e subir, com três elementos definidos previamente: condições de parada expressas em termos comerciais, uma fila específica com responsável e prazo, e um pacote de informações que inclui o que foi encontrado, o que está faltando e quais opções estão sendo consideradas.

Normalmente não. Automatizar todo o formulário 70% e preparar o restante (30%) geralmente resulta em uma economia líquida maior do que automatizar o formulário 95% e gerar retrabalho, reclamações e desconfiança em casos que não deveriam ser automatizados. O indicador correto é o custo por caso resolvido com sucesso, não a porcentagem de casos automatizados.

Inclua um estudo de caso raro escolhido pelo cliente, com seus dados incompletos e regras de negócio não escritas. Se o fornecedor adiar esse caso para uma fase posterior, é aí que o estouro de orçamento do projeto aparecerá.

Antes de automatizar, mapeamos. Identificamos o processo real, as regras não escritas e as exceções que impediriam qualquer automação, e indicamos quais partes merecem ser automatizadas. Duas horas de análise sem compromisso. Vamos conversar →

Agentes de Inteligência Artificial gerenciando exceções em processos de negócios
Agentes de Inteligência Artificial integrados em processos e sistemas de negócios
Gerenciamento de permissões e acesso para agentes de Inteligência Artificial em sistemas corporativos