Agentes de IA vs RPA: a diferença que decide se o seu projeto vai para produção

Toda semana, alguma empresa chega até nós descrevendo o que quer automatizar com inteligência artificial. A conversa começa com ambição: reduzir erros, liberar equipe, escalar sem contratar. E então, no detalhe, aparece o projeto real: 'a gente quer que o sistema pegue o XML da nota fiscal, valide os campos e grave no ERP.' Isso não é um agente de IA. É RPA. E a diferença entre os dois não é terminológica: ela determina se o projeto vai para produção ou vai para a gaveta.

O que o RPA realmente faz

RPA (Robotic Process Automation) é uma tecnologia de automação por regras. Um robô de RPA percorre uma sequência de passos definidos por um humano: clica aqui, lê aquilo, grava lá. A lógica é explícita, determinística e frágil. Frágil porque qualquer variação fora do script quebra o fluxo: o campo mudou de lugar na tela, o arquivo chegou com uma coluna a mais, o fornecedor enviou o PDF em vez do XML. O robô para. Um humano precisa intervir.

A tecnologia tem seu lugar: processos repetitivos, de baixa variabilidade, onde o custo de manutenção do script é menor do que o custo do trabalho manual. Para esse tipo de problema, RPA é uma solução adequada e madura. O problema começa quando se aplica a mesma lógica a processos que têm variabilidade real.

O que um agente de IA realmente faz

Um agente de IA não segue um script. Ele recebe um objetivo, observa o ambiente, decide qual ação tomar a seguir e age. A diferença está no ciclo: perceber, raciocinar, agir, observar o resultado, decidir de novo. Esse ciclo se repete até o objetivo ser atingido ou até o agente concluir que não pode atingi-lo com as ferramentas disponíveis.

Isso tem consequências práticas imediatas. Um agente pode receber um pedido de compra escrito em linguagem natural, classificar se ele se encaixa na política de compras da empresa, identificar que falta uma aprovação, solicitar essa aprovação pelo canal correto, aguardar, e só então registrar o pedido no Protheus. Nenhuma dessas etapas é codificada como regra explícita. O agente infere, a partir do contexto, qual é a ação certa.

Em uma operação real que acompanhamos, o tempo de processamento de um pedido caiu de 30 para 5 minutos. Não porque o agente é mais rápido do que um humano clicando: mas porque ele não precisa esperar a fila, não comete os erros de digitação que geram retrabalho, e não para quando o documento chega em formato inesperado.

Um agente de IA não executa o processo: ele navega o processo. A distinção parece sutil até o dia em que o processo muda e o RPA para completamente.

Por que a confusão acontece

A linguagem do mercado não ajuda. Fornecedores de RPA adicionaram módulos de 'IA' aos seus produtos. Plataformas de automação chamam qualquer chatbot de 'agente'. O termo se esvaziou de sentido técnico e ficou com apenas o apelo de marketing.

Mas há uma razão mais profunda para a confusão: a maioria dos gestores nunca precisou pensar na diferença entre seguir uma regra e tomar uma decisão. Para um humano, as duas coisas parecem iguais, porque o cérebro faz as duas com o mesmo esforço aparente. Para um sistema de software, são arquiteturas completamente diferentes. RPA precisa que alguém, antes, tenha mapeado cada variação possível e escrito a regra correspondente. Um agente precisa que alguém tenha definido o objetivo e dado acesso às ferramentas. O trabalho humano não desaparece: ele se desloca. Em vez de escrever regras, você escreve contexto.

Os sinais de alerta no diagnóstico do projeto

Quando avaliamos uma operação para saber se agentes fazem sentido, procuramos sinais específicos. Se a resposta para 'o que acontece quando o documento chega diferente do esperado?' é 'um humano verifica e decide', esse processo tem variabilidade real. RPA vai quebrar ali. Um agente pode navegar.

Se o processo envolve julgamento, classificação ou priorização, mesmo que simples, RPA não resolve de forma sustentável. Scripts de exceção vão se multiplicar, a manutenção vai crescer, e em 18 meses o custo do robô vai superar o custo do trabalho manual que ele substituiu. Pesquisas de consultorias como McKinsey e Deloitte já documentaram que a maioria dos pilotos de IA não chega à produção. Uma parte significativa desse fracasso está aqui: projetos desenhados como RPA que tentam incorporar 'inteligência' através de regras adicionais, até o ponto em que a complexidade colapsa.

O que muda na arquitetura quando você passa para agentes

A diferença não é só conceitual. Ela aparece na estrutura técnica do sistema. Um processo de RPA é linear: entrada, etapas, saída. Um sistema de agentes é um grafo: cada nó é um agente especializado, cada aresta é uma passagem de contexto. Há um agente que classifica o tipo de documento. Há um agente que valida as regras de negócio. Há um agente que decide se precisa de aprovação humana. Há um agente que faz a escrita no ERP. Cada um tem uma responsabilidade delimitada, e o sistema inteiro consegue lidar com variações porque o raciocínio está distribuído.

Isso também muda o que acontece quando algo dá errado. Em RPA, o erro é um crash: o robô para e alerta. Em um sistema de agentes bem desenhado, o agente que encontra um caso ambíguo pode escalar para revisão humana sem parar o restante do fluxo. O processo continua. A exceção é tratada em paralelo. Em uma operação de compras que acompanhamos em mineração, chegamos a zero erros de lançamento no ERP depois da implantação. Não porque o sistema é perfeito, mas porque os casos onde o agente não tem certeza suficiente são redirecionados para revisão humana antes de qualquer escrita. O sistema sabe o que não sabe.

O papel da infraestrutura na diferença

Construir um agente de IA que funcione em produção demanda muito mais do que reconfigurar uma ferramenta de RPA com um novo nome. Requer infraestrutura para orquestrar múltiplos modelos, gerenciar memória de contexto entre etapas, garantir que falhas em um agente não contaminem o estado dos outros e registrar cada decisão para auditoria.

Nós construímos essa infraestrutura ao longo de vários projetos porque as soluções genéricas disponíveis no mercado não entregavam a confiabilidade que operações reais exigem. A nossa fábrica de agentes é o que permite que um novo sistema entre em produção em semanas, porque os padrões de orquestração, monitoramento e fallback já estão resolvidos. O que varia de cliente para cliente é a lógica de negócio, não a engenharia de base. Projetos que tentaram construir tudo do zero quase sempre esbarraram no mesmo problema: a equipe adaptou padrões de RPA ou de microsserviços para um problema diferente, e o resultado foi um sistema que funcionou no demo e quebrou no primeiro mês de uso real.

Todo projeto de automação chega a um ponto de verdade: o sistema lida com o que não esperava, ou para. Agentes navegam. RPA trava.

Quando o RPA ainda é a resposta certa

Seria desonesto sugerir que agentes substituem RPA em todo cenário. Há processos onde a variabilidade é baixa, o volume é alto, e o custo de manutenção de um script é aceitável. Reconciliação de planilhas com formato fixo, extração de dados de sistemas legados sem API, preenchimento de formulários com campos previsíveis: esses são casos onde RPA continua sendo a ferramenta mais simples e mais barata.

A pergunta mais útil tem outra forma: este processo tem variabilidade suficiente para que regras explícitas sejam insustentáveis a médio prazo? Se a resposta for sim, agentes são a arquitetura adequada. Se a resposta for não, RPA resolve com menos complexidade. O problema é que poucas organizações fazem esse diagnóstico antes de escolher a tecnologia. Escolhem pelo nome, pelo fornecedor conhecido, pelo deck mais bonito. E descobrem a diferença quando o projeto falha.

O que fazer com esse diagnóstico

Quando chegamos a um projeto, a primeira conversa gira em torno do processo: onde estão as exceções, com que frequência elas aparecem, quem decide quando o fluxo normal não resolve. Esse mapa de variabilidade é o que determina a arquitetura.

Se o mapa mostra alta variabilidade com decisões frequentes, o projeto vai para agentes. Se mostra fluxo linear com poucas exceções, RPA pode resolver e o custo de implementar agentes não se justifica. Se mostra um híbrido, a solução é híbrida: agentes nas etapas de classificação e decisão, automação simples nas etapas de execução determinística. Equipes que chegam com a tecnologia decidida antes do diagnóstico quase sempre chegam com o projeto errado. A distinção entre agentes de IA vs RPA é, antes de tudo, uma questão de engenharia: confundi-la com diferença de nomenclatura é o que produz sistemas que não chegam à produção.

Quer ler a sua operação a fundo?