Automação 7 min de leitura Fevereiro · 2026

RPA não é solução. É curativo bem aplicado.

Quando faz sentido automatizar uma tarefa em vez de reconstruir o processo. E quando isso só adia o problema.

O que RPA realmente é

RPA — Robotic Process Automation — é, no fundo, um robô que finge ser uma pessoa usando um computador. Ele clica em botões, lê telas, copia campos, abre o Excel. Não é inteligência artificial. É um macete sofisticado para automatizar o que deveria ter API e não tem.

UiPath, Automation Anywhere, Blue Prism vendem isso como transformação digital. Não é. É um curativo. Curativos têm seu lugar — quando o ferimento é pequeno, ou quando a cirurgia ainda não pode ser feita. O problema é quando a empresa esquece que está usando curativo e começa a tratar a improvisação como infraestrutura.

Quando RPA é a decisão certa

Existem três casos onde RPA é a resposta correta, sem desculpas:

  1. Sistema legado sem API, volume baixo, vendor pede absurdo. O sistema do governo, o portal do fornecedor antigo, o ERP da década passada. Construir uma integração proper custa R$ 200k. Um bot que entra, baixa o relatório e salva numa pasta custa R$ 8k e roda há três anos. Faz sentido.
  2. Ponte temporária durante migração. Você está saindo do sistema A para o B em 18 meses. Não vai gastar com integração de verdade no A. RPA segura a peteca até a migração terminar.
  3. Processo em vias de extinção. A área vai mudar de modelo em 2 anos. Automatiza o tédio agora, descontinua o bot quando o processo morrer.

Quando RPA está adiando o problema

E aqui mora a verdade desconfortável. Em média, 30% a 50% dos bots de RPA quebram nos primeiros 12 meses — não porque o bot é ruim, mas porque a tela que ele lê mudou. Botão de lugar, label novo, atualização de versão. O bot não "entende" o sistema. Ele decora a posição dos pixels.

Sinais de que sua RPA é um curativo virando gangrena:

  • Você tem mais de 20 bots rodando e ninguém na empresa consegue listar todos.
  • O time de manutenção de bots cresceu para 3+ pessoas.
  • Quando alguém pergunta "por que esse processo existe?", a resposta é "porque o bot faz isso há anos".
  • O bot está automatizando a saída de um sistema para a entrada do mesmo sistema, com uma volta no Excel pelo meio.
  • Você está automatizando relatório que ninguém lê.

A última é a pior. Acontece o tempo todo: alguém pediu o relatório em 2018, automatizaram em 2020 com RPA, hoje em 2026 ninguém abre, mas o bot roda toda quarta às 8h e gera 14 PDFs.

Para quem não é técnico: a analogia

Imagine que você contrata uma pessoa para abrir o portão da sua garagem, anotar a placa de cada carro que entra, e digitar essa placa num caderno. Funciona. É barato. Mas se você refez a entrada e mudou onde fica a portaria, a pessoa fica perdida três dias. E você nunca para pra perguntar: por que ainda anoto placa num caderno? Não era melhor uma câmera com leitura automática conectada ao sistema?

RPA é a pessoa anotando placa. Boa quando você não tem alternativa. Ruim quando virou solução permanente.

O lado técnico: por que screen scraping é frágil por natureza

RPA depende de identificar elementos na tela. Ferramentas modernas usam:

  • Seletores de DOM (em sistemas web): #botao-confirmar ou XPath.
  • Posição visual (em sistemas desktop): coordenadas de pixel, OCR, reconhecimento de imagem.
  • Acessibilidade (UIA, em apps Windows): mais robusto, mas raramente disponível em legados.

Qualquer um desses quebra com:

  • Atualização do sistema-alvo.
  • Mudança de resolução de tela.
  • Pop-up inesperado (modal de "novidades", aviso de manutenção).
  • Lentidão da rede que faz o bot tentar clicar antes do elemento carregar.

Comparado a uma API REST, onde você tem contrato versionado, resposta estruturada, códigos de erro e idempotência por design — o RPA é fundamentalmente menos confiável. A escolha entre os dois não é técnica. É política: quem manda no sistema que você precisa integrar.

A pergunta antes do bot

Antes de aprovar qualquer projeto de RPA, três perguntas:

  1. Esse processo deveria existir? Metade dos processos automatizáveis são burocracia herdada. Automatizar reduz dor sem questionar a fonte.
  2. Existe API que resolva isso por menos do que o RPA + manutenção em 3 anos? Faz a conta com manutenção, não só com desenvolvimento.
  3. O que acontece quando o bot quebrar? Se a resposta for "ninguém percebe na hora", você descobriu que o processo era opcional o tempo todo.

RPA tem seu lugar. Mas se você não consegue responder essas três perguntas, está comprando dívida com cara de modernização.