Home›Blog›Agentes de IA vs. RPA: quando cada um faz sentido
Agentic AIAutomaçãoRPA

Agentes de IA vs. RPA: quando cada um faz sentido

Rudinei Gehm23 de Julho de 20266 min de leitura

Antes de escolher entre agente de IA e RPA, olhe para cada etapa do processo e pergunte: isso exige interpretação ou só repetição? Repetição sobre dado estruturado é trabalho de robô de RPA ou de integração. Interpretação de texto livre, exceção e ambiguidade é onde um modelo de linguagem se paga. A maioria dos processos reais tem as duas coisas, e o erro caro é escolher uma ferramenta para o processo inteiro.

Por que essa confusão custa dinheiro agora

Em junho de 2025, a Gartner previu que mais de 40% dos projetos de IA agêntica serão cancelados até o fim de 2027, por custo crescente, valor de negócio pouco claro ou controle de risco inadequado. No mesmo anúncio, a consultoria descreveu o "agent washing": fornecedores rebatizando assistentes, chatbots e RPA como agentes sem capacidade agêntica real. Pela estimativa da Gartner, só cerca de 130 dos milhares de fornecedores que se dizem de IA agêntica são reais.

Os dois erros aparecem nos projetos. Há quem compre "agente" e receba um robô de RPA com uma camada de chat. E há quem coloque um agente autônomo para fazer o que uma regra de três linhas faria melhor, mais barato e sem surpresa.

O que cada um é, sem marketing

RPA (automação robótica de processos) executa um roteiro fixo sobre interfaces: abre o sistema, lê o campo, copia, cola, clica. É determinístico. A mesma entrada gera sempre a mesma saída, e isso é uma virtude quando o processo é estável.

Agente de IA, na definição que a Anthropic usa em Building effective agents, é um sistema em que o modelo de linguagem dirige o próprio processo e decide quais ferramentas usar e em que ordem. O mesmo texto separa agentes de workflows: sistemas em que o LLM é chamado em pontos definidos de um fluxo escrito em código. E faz uma recomendação que muita gente pula: comece pela solução mais simples, porque agentes trocam latência e custo por desempenho em tarefas abertas, e a autonomia traz custo maior e risco de erros que se acumulam.

Essa terceira categoria, o workflow com uma etapa de LLM, é a resposta certa com mais frequência do que o mercado admite.

Onde RPA ganha, e onde quebra

RPA ganha quando o processo tem regra clara, dado estruturado, volume alto e sistemas sem API. Conciliações entre dois sistemas legados, cadastro repetitivo em portal de governo, download diário de relatórios. Custo por execução baixo, comportamento previsível, auditoria simples.

RPA quebra quando a tela muda, quando o documento chega em formato diferente ou quando aparece o caso "quase igual". Cada exceção vira uma regra nova, cada regra nova vira manutenção, e o robô que ia liberar pessoas passa a precisar de uma pessoa cuidando dele. Se existe API, integração direta costuma ser mais estável do que RPA sobre a interface.

Onde agente ganha, e onde quebra

Agente ganha quando a entrada é texto livre ou documento variado, quando o número de passos não é previsível e quando a decisão depende de contexto. Ler um e-mail de fornecedor e entender que ele está contestando uma multa, e não pedindo segunda via. Montar a resposta a um chamado consultando três sistemas diferentes conforme o caso.

Agente quebra de formas diferentes do RPA. Ele pode errar com confiança, e o erro não aparece como exceção no log. Custa por chamada de modelo, com variação de latência. E tem uma superfície de ataque nova: o OWASP Top 10 para aplicações com LLM lista "agência excessiva" como risco, quando o agente recebe mais ferramentas, permissões ou autonomia do que a tarefa precisa, e prompt injection como o primeiro da lista. Um agente que lê e-mails externos e tem permissão para pagar faturas é exatamente esse cenário.

O desenho que costuma funcionar: os dois, cada um no seu lugar

Os próprios fornecedores de RPA já organizam o mercado assim. A UiPath descreve sua orquestração com o lema agentes pensam, robôs executam, pessoas lideram. Sem entrar no mérito do produto, a divisão é útil: o modelo interpreta, o fluxo determinístico executa, e a pessoa decide onde o custo do erro é alto.

Um exemplo: contas a pagar

Um processo de contas a pagar de uma empresa média brasileira tem, tipicamente, estas etapas:

  1. Receber a NF-e. O XML é estruturado e padronizado. Aqui não há o que interpretar: integração ou RPA importa os dados para o ERP.
  2. Receber boletos e faturas de serviço em PDF, cada fornecedor com um layout. Uma etapa de LLM extrai valor, vencimento, CNPJ e linha digitável, e um validador determinístico confere dígito verificador e CNPJ. Workflow, não agente.
  3. Conferir com o pedido de compra. Se valor e quantidade batem dentro da tolerância, regra fixa aprova. Sem modelo.
  4. Tratar divergências: valor diferente, item não recebido, e-mail do fornecedor explicando um reajuste. Aqui um agente faz sentido. Ele lê o histórico, consulta o pedido e o recebimento, e propõe uma ação com justificativa.
  5. Aprovar pagamento. Abaixo de um valor definido pela empresa e com proposta de alta confiança, o fluxo segue. Acima disso, uma pessoa aprova vendo a justificativa do agente. O agente nunca tem permissão para pagar sozinho.

Nesse desenho, o agente trabalha só nas exceções, que é onde está o trabalho manual caro, e fica longe do dinheiro.

O que o caso Klarna ensina

Em fevereiro de 2024, a Klarna anunciou que seu assistente de IA atendeu 2,3 milhões de conversas no primeiro mês, dois terços do atendimento por chat, o equivalente ao trabalho de 700 atendentes em tempo integral. Em maio de 2025, o CEO Sebastian Siemiatkowski disse à Bloomberg que o custo tinha pesado demais na decisão e que o resultado foi qualidade menor. A empresa voltou a recrutar pessoas para garantir que o cliente sempre possa falar com alguém.

O assistente não foi desligado. O que mudou foi a fronteira: automação no volume rotineiro, gente nos casos em que o erro custa caro. É a mesma lógica do exemplo de contas a pagar.

Seis perguntas para decidir cada etapa

  1. A entrada tem formato fixo (XML, tabela, campo de sistema) ou é texto e documento variado?
  2. O número de passos é previsível ou depende do caso?
  3. Existe API? Se sim, integração vem antes de RPA e de agente.
  4. Qual é o custo de um erro nessa etapa, e alguém percebe o erro antes que ele chegue ao cliente ou ao caixa?
  5. Qual permissão mínima a automação precisa? Ler, sugerir ou executar?
  6. Como você vai medir se está funcionando: taxa de exceção, retrabalho, tempo de ciclo, reclamações?

Se as respostas apontam para formato fixo, passos previsíveis e erro caro, fique com regra e RPA. Se apontam para texto livre, passos variáveis e erro que uma pessoa pode revisar, um agente vale o teste.

Os custos que não entram na planilha

No RPA, o custo escondido é manutenção: cada atualização de tela do sistema de origem pode parar o robô. No agente, é avaliação e monitoramento: um conjunto de casos de teste para cada mudança de prompt ou de modelo, revisão amostral das decisões e trilha do que o agente fez. Quem compara só licença de RPA com custo de tokens compara a parte menor das duas contas.

Próximo passo

Pegue um processo que hoje consome horas do time, desenhe as etapas e responda às seis perguntas para cada uma. Se sobrar uma etapa de interpretação com volume relevante, teste um agente só nela, com dados reais e métricas definidas antes. É isso que fazemos na PoC Factory: validar em 3 a 6 semanas se o agente resolve a etapa certa antes de investir em produção. Quando o caso se prova, nosso trabalho de agentes de IA leva para produção com permissões, logs e revisão humana definidos desde o início.

Mande uma mensagem no WhatsApp contando qual é. Na conversa a gente mostra se IA resolve, quanto custa validar e em quanto tempo dá para ver resultado.

Conversar pelo WhatsApp