RPA e um agente de AI diferem em uma única coisa: quem escolhe o caminho de execução, e quando. Com RPA, um humano escolhe o caminho em tempo de construção e o software o reproduz de forma idêntica para sempre. Com um agente de AI, o modelo escolhe o caminho em tempo de execução a partir de um objetivo que você declarou. Modelo de custo, modo de falha, trilha de auditoria e tolerância a mudança derivam todos dessa única diferença — é por isso que “qual é melhor” é a pergunta errada e “essa tarefa contém decisões?” é a certa.
Um agente de AI não é um bot de RPA mais inteligente, e RPA não é um agente obsoleto. RPA também não é AI de forma alguma: um robô clássico não contém modelo nenhum. É um script vinculado a seletores de UI, XPaths e object IDs nas telas de aplicações que você já tem, mais chamadas de API onde o fornecedor as expôs. Ele clica onde você mandou clicar. Um agente, por outro lado, não tem caminho fixo para reproduzir — o que significa que ele consegue lidar com um caso que você nunca previu, e também fazer algo que você nunca autorizou.
O que decorre dessa única diferença
A tolerância a mudança corre em direções opostas. RPA quebra quando a tela muda: o fornecedor publica um release, um nome de classe muda, o seletor deixa de resolver, o robô para. Agentes sobrevivem a essa mesma mudança de UI e, em vez disso, derivam — o modelo lê a tela nova, decide algo razoável e segue numa direção que ninguém revisou. Você está escolhendo entre um sistema que quebra de forma visível e um sistema que entorta de forma invisível.
Os modos de falha estão invertidos, e o desenho de QA também. Um robô quebrado lança uma exceção e cai numa fila; você descobre porque a contagem de execuções foi a zero. Um agente que falha produz um resultado completo, bem formado, confiante e errado, e reporta sucesso. Monitoramento de uptime pega o primeiro e é cego para o segundo. Se você move um processo de RPA para um agente e mantém o mesmo monitoramento, você não migrou o processo — você removeu o alarme.
A unidade de cobrança muda de capacidade para consumo. Um robô de RPA é licenciado como um assento de capacidade: você aluga o trabalhador e depois executa quanto quiser. Um agente é cobrado pelo que consome, então uma tarefa que ficou mais complexa fica mais cara sem ninguém mexer em licença. A variância orçamentária vai de zero a ilimitada, a menos que você imponha um teto.
A trilha de auditoria precisa ser reconstruída. Um script de RPA é sua própria trilha de auditoria — reprodução determinística significa que o código documenta exatamente o que aconteceu em cada execução, e foi por isso que processos regulados de back-office se padronizaram sobre ele. As ações de um agente só são reconstruíveis se o fornecedor registrar o raciocínio junto com as ações. Logs de ação sozinhos dizem o que mudou, não por quê, e “o modelo decidiu” não sobrevive a uma auditoria.
A aritmética do custo
A Microsoft publica os dois lados dessa troca numa mesma tabela de preços, o que a torna a comparação mais limpa disponível. Verificado em 2026-07-26: Power Automate Premium custa $15 por usuário/mês e inclui desktop flows atendidos; Power Automate Process custa $150 por bot/mês para desktop flows não atendidos; Power Automate Hosted Process custa $215 por bot/mês com uma VM gerenciada pela Microsoft. Copilot Studio custa $200/mês por 25.000 créditos. A UiPath publica um nível de entrada do Automation Cloud a partir de $25/mês e cota robôs não atendidos sob consulta.
A licença do bot não atendido é fixa, então seu custo por execução é apenas $150 dividido pela sua contagem mensal de execuções:
- 100 execuções/mês → $1,50 por execução
- 1.000 execuções/mês → $0,15 por execução
- 10.000 execuções/mês → $0,015 por execução
Então meça o custo real por execução do seu agente numa amostra de casos reais — chame de C — e o bot ganha acima de aproximadamente 150 / C execuções por mês. Um agente cuja execução custa $0,15 empata em 1.000 execuções/mês; um que custa $0,50 empata em 300. Abaixo desses volumes a licença fixa do bot é a opção cara e a flexibilidade do agente sai praticamente de graça. Bem acima deles, usar um modelo para rederivar o mesmo caminho determinístico milhares de vezes por mês é pagar por execução uma decisão que já estava tomada.
Como decidir
Classifique a tarefa em dois eixos — o quanto o caminho varia e com que frequência ele roda.
- Baixa variância, alto volume (digitação de notas fiscais, sincronização de status, montagem de relatórios): RPA, ou melhor, uma integração por API. Não compre julgamento para uma tarefa que não tem nenhum.
- Alta variância, volume baixo a moderado (tratamento de exceções, triagem de contratos, research inbound): agente. A fila de exceções é o custo que você está de fato atacando.
- Alta variância, alto volume: o agente decide, o robô ou a API executa. É o padrão composto descrito abaixo.
- Baixa variância, baixo volume: nenhum dos dois. Um humano fazendo isso 20 vezes por mês sai mais barato que qualquer uma das licenças.
A opção que os fornecedores dos dois lados pulam: se o sistema de destino tem uma API documentada, a camada de UI é um contorno para uma integração que você poderia simplesmente construir. RPA existe em boa parte porque software corporativo foi publicado sem APIs. Procure por uma antes de alugar um robô para digitar num formulário — e antes de alugar um modelo para fazer a mesma coisa de forma mais cara.
Eles se compõem mais do que competem
A posição dos fornecedores dos dois lados em 2026 é composição, não substituição. A UiPath apresenta sua plataforma como agentes, robôs e pessoas coordenados por uma camada de orquestração chamada Maestro, junto de Agent Builder e Autopilot, e resume a divisão de trabalho como: os agentes pensam, os robôs fazem e as pessoas lideram. A Automation Anywhere vende um sistema de Agentic Process Automation que orquestra agentes baseados em objetivos, bots de RPA, APIs e aprovações humanas em conjunto, e permaneceu Leader no Gartner Magic Quadrant for RPA de 2026.
Leia isso como padrão de projeto, não como marketing: o modelo é bom em decidir o que deve acontecer com um caso e ruim em executar as mesmas teclas de forma confiável 10.000 vezes; o robô é o inverso. Coloque o julgamento no agente, a repetição no robô ou na API, e o portão de aprovação entre os dois.
Perguntas de diagnóstico para um fornecedor
Estas separam um agente de verdade de um produto de RPA com um modelo de linguagem na frente — um conjunto distinto do de AI agent para ops, que testa autonomia em geral e não a decisão de migração.
- O caminho de execução é fixado em tempo de construção ou escolhido em tempo de execução? É a pergunta inteira. O resto é detalhe.
- Rode o mesmo input duas vezes — eu recebo o mesmo caminho? Caminhos idênticos significam que você está comprando RPA. É uma compra válida, a preço de RPA.
- Ele opera a UI ou a API? Produtos que operam sobre a UI herdam o perfil de quebra do RPA, independentemente do que o modelo faça.
- Qual é a unidade de cobrança — bot, execução ou token? A resposta diz qual orçamento absorve um processo que fica mais complexo.
- Quando a aplicação de destino publica uma mudança de UI, o que quebra e quem conserta? “Nada quebra” não é resposta; pergunte o que o modelo faz quando a tela não bate mais.
Erros comuns
Substituir RPA que funciona porque RPA soa datado. Um robô que roda há três anos um processo estável, de alto volume e sem julgamento não é dívida técnica. Migrá-lo compra variância e um custo por execução mais alto.
Proteção: Migre apenas processos onde a fila de exceções — não o caminho feliz — é para onde vai o trabalho. Se as exceções são menos de 5% do volume, deixe o robô em paz.
Tratar a flexibilidade do agente como gratuita. Flexibilidade é cobrada por execução, e casos complexos custam mais que casos simples, então a conta escala exatamente com os casos que você adotou o agente para resolver.
Proteção: Defina um teto rígido de custo por tarefa na plataforma antes do go-live, e volte a medir o custo por execução sobre tráfego real depois de 30 dias, não sobre a amostra da demo.
Manter o monitoramento da era RPA depois do corte. Dashboards de contagem de execuções e uptime reportam um agente que alucina como perfeitamente saudável.
Proteção: Substitua as checagens de uptime por revisão amostrada de saídas — um percentual fixo de execuções concluídas lido por um humano toda semana — mais uma métrica de taxa de reversão que conte com que frequência um humano desfez o que o agente fez.
Perder a trilha de auditoria determinística num processo regulado. Processos de Legal Ops e TA cobertos por NYC LL 144, pela EU AI Act ou por controles SOX internos precisam mostrar o que foi decidido e por quê.
Proteção: Exija registros de decisão estruturados — insumos consultados, regra aplicada, o que foi escalado — antes do corte, e mantenha o robô determinístico na perna regulada do processo enquanto o agente cuida da entrada e da triagem ao redor.
Relacionado
- AI agent para ops — o que qualifica como agente e os testes de autonomia para aplicar a qualquer fornecedor que diga ter um
- O que é um MCP server — a alternativa via API a operar uma UI, e como agentes se conectam a sistemas sem seletores
- n8n e Make — a camada de workflow que a maioria dos times de ops procura antes de RPA ou agentes
- GTM engineering — a disciplina dona dessa decisão de construir ou alugar em RevOps