Todas as semanas alguém anuncia que o RPA está morto e que os agentes de IA o reformaram. Bom título, má decisão de arquitetura. Porque quem mata o RPA por moda acaba a pedir ao agente que faça o trabalho de servente —mover um dado do sistema A para o sistema B, mil vezes, sem pensar— e isso é caro, lento e absurdo. E quem se agarra ao RPA por hábito pede-lhe que decida sobre uma fatura estranha, e o bot encrava. A pergunta útil não é qual ganha. É que parte do trabalho faz cada um.
Agentes de IA vs RPA: a luta está mal colocada
O RPA (Robotic Process Automation) é um robô que imita cliques e teclas sobre um ecrã. Gravas-lhe os passos e ele repete-os iguais, a toda a velocidade, sem se cansar nem improvisar. É determinista: mesmo input, mesmo output, sempre. Um agente de IA é outra coisa: lê texto sem estrutura, percebe a intenção, decide dentro de limites e adapta-se quando algo muda. Um é músculo. O outro é critério. Pô-los a competir é como perguntar se é melhor uma chave de fendas ou um eletricista: precisam um do outro.
A confusão vem de ambos "automatizarem", por isso parecem substitutos. Não são. Automatizam camadas diferentes do mesmo processo. E o erro caro —o que vemos vezes sem conta— é pôr um a fazer o trabalho do outro. Antes de decidir seja o que for, convém ter claro o que é mesmo automatizar um processo com agentes, porque metade dos projetos falhados não falha na ferramenta: falha na má divisão de quem faz o quê.
O que o RPA faz bem (e porque não está morto)
O RPA brilha onde o trabalho é repetitivo, estruturado e estável. Nada de nuances: regras fixas, zero exceções, o mesmo ecrã todos os dias. Nesse terreno é imbatível —barato, rápido, auditável— e nenhum agente o vai superar, porque não há nada para raciocinar. Casos onde o RPA continua a ser a resposta certa:
- Mover dados entre sistemas que não falam por API: copiar de uma folha para o ERP, do ERP para o portal do banco, sempre igual.
- Preencher formulários idênticos a partir de um modelo, em volume alto e complexidade zero.
- Gerar relatórios programados: extrair, colar, exportar, enviar. Sem decisões pelo meio.
- Reconciliações triviais onde a regra é «se o valor coincide, marca como pago» e não há zonas cinzentas.
O calcanhar de Aquiles do RPA é conhecido: é frágil. Como trabalha imitando o ecrã, no dia em que alguém move um botão, muda o nome de um campo ou o fornecedor atualiza o portal, o bot parte-se e há que repará-lo à mão. Essa manutenção não é anedótica. Sínteses de mercado que citam a Deloitte estimam que a manutenção come entre 70% e 75% do orçamento de RPA (Neomanex, 2025). Não é motivo para o deitar fora: é motivo para não lhe pedir o que não sabe fazer.
O que o agente faz bem (e onde o RPA parte)
O agente entra precisamente onde o RPA encrava: quando é preciso ler algo sem formato, perceber o contexto e decidir. Não segue um guião gravado; interpreta. Por isso aguenta a exceção, o email mal escrito, a fatura com a rubrica num sítio estranho. Terreno do agente:
- Dados sem estrutura: emails, PDFs, contratos, chats. O agente lê e extrai o que importa mesmo que cada documento venha diferente.
- Exceções com critério: uma discrepância numa fatura, uma encomenda estranha, um caso que não encaixa na regra. O agente raciocina dentro dos seus limites em vez de encravar.
- Coordenar vários sistemas pelo seu significado, não pelo seu ecrã: cruza CRM, ERP e caixa de entrada percebendo o que é cada coisa.
- Classificar e priorizar quando a resposta não está numa tabela: triagem de tickets, encaminhamento de leads, categorias que dependem do contexto.
O agente também tem o seu preço: custa mais por operação do que um bot, há que pôr-lhe guarda-corpos e supervisão, e não vais querer que decida sozinho sobre coisas sensíveis no primeiro dia. Montar um que aguente em produção —não uma demo— tem o seu ofício, e desmontamo-lo em como se cria um agente de IA que funcione a sério. A regra operativa: não uses um agente para o que uma regra fixa já resolve. É como contratar um advogado para fotocopiar.
| Dimensão | RPA | Agente de IA |
|---|---|---|
| Como trabalha | Imita cliques e teclas sobre um ecrã | Lê, raciocina e decide sobre o significado |
| Tipo de dado | Só estruturado (tabelas, campos fixos) | Estruturado + sem estrutura (emails, PDFs, chats) |
| Exceções | Encrava e escala para um humano | Raciocina dentro dos seus limites |
| Quando muda o ecrã | Parte-se, há que reparar | Adapta-se pelo contexto |
| Custo por operação | Muito baixo | Mais alto |
| O seu terreno | Repetitivo, estável, sem zonas cinzentas | Complexo, com exceções, multi-sistema |
O padrão que ganha em 2026: o híbrido
Aqui está a tese, e vai contra a corrente do título fácil: não escolhas um lado, combina-os. O padrão que compensa não é «agente em vez de RPA» nem «o RPA de sempre». É o híbrido, com uma divisão limpa: o agente lê e decide, o RPA executa o repetitivo. O critério em cima, o músculo em baixo. Cada um a fazer o que faz barato e bem.
Um exemplo que se percebe sozinho: extrair os dados de uma fatura e metê-los no teu sistema. A fatura chega em PDF, cada fornecedor maqueta-a à sua maneira, às vezes falta um campo ou o IVA está mal posto —isso é leitura e critério, terreno do agente—. Depois de o agente ter percebido e validado os dados, metê-los no ERP campo a campo, mil vezes igual, é puro músculo repetitivo —terreno do RPA ou de uma integração por API—. O agente faz a parte que pensa; o bot faz a parte que sua. O agente não gasta tokens a escrever, e o bot não encrava perante um PDF estranho.
Como decidir no teu caso, sem comprar fumo
Não precisas de um comité para escolher. Precisas de olhar para o processo e responder a estas perguntas por ordem:
- Os dados vêm arrumados ou uma trapalhada? Se tudo chega em tabelas limpas e estáveis, começa pelo RPA. Se chega em emails, PDFs e anexos, precisas de um agente que leia.
- Há exceções que exigem decidir? Se o processo é «sempre igual, sem zonas cinzentas», é RPA. Se há muitas vezes um «depende», é agente.
- O ecrã ou o formato mudam com frequência? Se o portal se atualiza a cada dois por três, um bot vai viver partido; aí o agente sai mais barato a longo prazo mesmo que custe mais por operação.
- Consegues partir o processo em duas camadas? Quase sempre sim: o pedaço que pensa e o pedaço que repete. É o momento híbrido, e costuma ser a resposta certa.
E um aviso para não tropeçar no do costume: a ferramenta não é o projeto. Escolher agente ou RPA é 10% do trabalho; os restantes 90% são perceber o processo, pôr-lhe limites e deixá-lo a correr com algo que se mede. Isso é automatização de operações sobre o que já tens, não uma compra de tecnologia. Quem te vende «agentes» sem te perguntar pelo teu processo está a vender-te a etiqueta da moda, tal como antes te vendia «RPA» sem olhar. A moda muda; o ofício de repartir bem o trabalho, não.