RPA ou integração por API: quando o robô de tela vira dívida

A automação robótica de processos tem uma má reputação que ela merece pela metade. A tecnologia está bem. O problema é que ela costuma ser escolhida pelo motivo errado: é a coisa mais rápida de demonstrar, e não depende da cooperação de ninguém.

Essa segunda propriedade é o apelo real. Uma integração por API exige que o fornecedor tenha API, que o jurídico aprove o acesso e que alguém do outro lado responda e-mail. Um robô dirigindo a interface não exige nada disso. Você entrega em duas semanas sem pedir licença.

Aí o fornecedor muda um botão de lugar.

O que você está escolhendo de fato

A distinção que importa não é "robô ou API". É qual contrato você está passando a depender.

Uma integração por API depende de um contrato que o fornecedor publica, versiona e tem vergonha de quebrar. A automação de tela depende do layout de uma página, que não é contrato nenhum. É um detalhe de implementação que o fornecedor muda sem avisar ninguém, porque do lado dele nada quebrou.

Todo o resto decorre disso.

Situação	Escolha	Raciocínio
Fornecedor tem API documentada	API	O robô economiza semanas agora e as devolve a cada release.
Tem API, mas o acesso está travado internamente	API, depois de escalar	Isso é problema de processo. Resolver com robô o torna permanente.
Sem API, fornecedor sai em até um ano	RPA	Uso correto de ferramenta descartável. Registre a data de retirada.
Sem API, sistema é estratégico e fica	Nenhum dos dois ainda	Você precisa de um caminho real: troca de arquivos, réplica de leitura ou pressão no fornecedor.
Aplicação legada interna, com código-fonte	API	Acrescentar um endpoint costuma custar menos do que manter um robô por um ano.
Processo com 5+ telas e julgamento humano	Nenhum dos dois	Automatizar processo ruim o torna mais rápido, não melhor. Redesenhe antes.

O custo que não aparece na estimativa

Uma estimativa de RPA cobre construir o robô. Raramente cobre o que ele custa para se manter vivo.

• Todo release de interface do fornecedor é uma possível parada, e você descobre por uma execução que falhou, não por um changelog.
• O robô precisa de credenciais que normalmente são de uma pessoa, o que significa uma conta de serviço com as permissões de alguém real, ou pior, a senha de alguém real.
• Falhas são silenciosas por padrão. Um robô que clica na coisa errada não lança exceção. Ele conclui com sucesso e faz algo errado.
• Ele só roda onde existe sessão. Autenticação em dois fatores, expiração de sessão e restrição de IP viram tarefas operacionais.

Nada disso é motivo para nunca usar RPA. São motivos para precificar como compromisso operacional contínuo, e não como projeto.

Se RPA for a única opção

Às vezes é mesmo. Nesse caso, quatro práticas separam um robô com o qual dá para conviver de um que vira passivo.

Verifique resultados, não passos. Depois que o robô terminar, confirme o resultado de forma independente: consulte o registro, confira o total, veja se o status mudou. Um robô que só sabe "cliquei nas coisas" não consegue dizer que falhou.

Torne cada execução idempotente e retomável. Robôs morrem no meio o tempo todo: sessão expirada, navegador travado, máquina reiniciada. Uma execução que não pode ser repetida com segurança transforma toda interrupção em limpeza manual.

Dê a ele identidade própria. Uma conta de serviço dedicada, só com as permissões do processo, e credenciais num cofre em vez de dentro do script. Isso importa tanto para auditoria quanto para segurança, e faz parte do que cobrimos nas nossas práticas de segurança.

Marque uma data de revisão, não uma esperança de aposentadoria. Coloque no calendário, daqui a seis meses, uma pergunta: esse fornecedor já tem API? Robôs sobrevivem à sua justificativa porque ninguém revisita a decisão.

Onde a IA muda o quadro, e onde não muda

Automação baseada em visão, que "entende" a tela, sobrevive melhor a pequenas mudanças de layout do que scripts baseados em seletor. Isso é uma melhoria real para um problema real.

Não muda a questão de fundo. Você continua dependendo de uma camada de apresentação em vez de um contrato, e acrescentou um componente cujo comportamento é probabilístico. Um robô 97% certo num processo financeiro não é 97% bom. É um sistema que produz registros errados a uma taxa constante, e agora os registros errados são mais difíceis de prever.

Se você for colocar um modelo num laço operacional, o limiar de confiança e o caminho de revisão humana importam mais do que o modelo, que é o tema de colocar um LLM em produção.

O resumo honesto

RPA é uma resposta correta quando o sistema alvo não tem interface e tem data para acabar. É uma resposta ruim quando é escolhida para evitar uma conversa com um fornecedor ou com outro time, porque aí o robô vira permanente e a conversa nunca acontece. Esse julgamento faz parte do que trabalhamos em projetos de IA e automação.

Se o que você move é dado, e não uma interface, a pergunta é outra: veja ETL ou ELT.