RPA ou integração por API: qual resolve o seu caso, e qual vai te dar dor de cabeça

A conversa costuma começar errada: "queremos automatizar com RPA". RPA é uma das respostas possíveis, e nem sempre a melhor. A pergunta certa é por onde os sistemas deveriam conversar, e o robô é só um dos caminhos.

A diferença, em uma frase: RPA imita uma pessoa usando a tela; API conversa com o sistema por dentro. Tudo o mais decorre disso.

O que cada um custa de verdade

A linha que decide quase tudo é a terceira. RPA é barato de construir e caro de manter — e o custo de manutenção não aparece no orçamento do projeto, aparece no ano seguinte, diluído em "o robô parou de novo".

Quando o RPA é a escolha certa

O sistema do outro lado não tem API. Sistema legado, portal de órgão público, software de terceiro que não expõe nada. Aqui RPA não é a melhor opção — é a única.

Você não controla o sistema e ele não vai mudar tão cedo. Portal da Receita, site de banco, sistema do cliente. Não dá para pedir uma API.

O volume é baixo e o processo é estável. Cinquenta lançamentos por dia numa tela que não muda há três anos. O robô se paga e quase não dá trabalho.

Você precisa de resultado em três semanas. Às vezes a resposta certa é a rápida, com a dívida assumida e um plano de substituição. Dívida consciente é decisão; dívida esquecida é acidente.

Quando o RPA vai te dar dor de cabeça

Quando existe API e alguém escolheu o robô por ser mais rápido. É o caso mais comum e o mais caro no longo prazo. O robô vira a integração oficial, ninguém volta para fazer direito, e três anos depois existe um processo crítico dependendo de uma tela.

Quando o volume é alto. Robô processa em velocidade de gente. Dez mil registros por noite é terreno de integração, não de automação de tela.

Quando o dado é sensível e precisa de trilha. O robô digita; ele não registra intenção. Em processo que vai ser auditado, a integração deixa log do que entrou, quando e por quê.

Dentro do SAP, quando existe BAPI ou OData. Automatizar uma transação SAP por robô, tendo BAPI disponível, é trocar algo estável e suportado por algo frágil. Já escrevemos sobre isso em detalhe.

O teste de três perguntas

1. Quem controla a tela do outro lado? Se é você ou a sua empresa, provavelmente existe um caminho melhor. Se é um terceiro, RPA passa a fazer sentido.

2. Isso precisa funcionar daqui a cinco anos? Se sim, e existe API, a integração se paga. Se é um processo que vai morrer na próxima migração, o robô resolve.

3. O que acontece às três da manhã quando quebrar? Robô quebra em silêncio e o erro aparece no fechamento do mês. Se a resposta for "ninguém percebe", o problema não é a tecnologia — é a falta de monitoramento, e aí nenhuma das duas opções é segura.

O caminho do meio, que quase ninguém propõe

Existe uma terceira resposta, e às vezes é a certa: robô agora, API depois, com data marcada.

Funciona quando o processo é urgente e a API é viável mas demorada. O robô entra como ponte, com prazo escrito e o projeto de integração já orçado. O erro é não marcar a data — aí a ponte vira a estrada definitiva.

E existe uma quarta, mais desconfortável: não automatizar. Processo que roda vinte vezes por mês, leva três minutos e tem exceção em metade dos casos não compensa robô nem integração. Compensa um checklist e meia hora de alguém. Automatizar exceção é a forma mais cara de resolver um problema pequeno.

Como decidimos na prática

Mapeamos o processo, contamos o volume real — não o estimado — e perguntamos quem é dono de cada sistema envolvido. Com isso a escolha quase sempre se resolve sozinha.

Quando a resposta é RPA, entregamos com monitoramento desde o primeiro dia: robô que ninguém observa é robô que já parou e você ainda não sabe.