Existem dois caminhos principais para automatizar a troca de informação entre sistemas, e escolher o errado gera um custo de manutenção que ninguém previu. A integração via API conversa com o sistema pela porta oficial. O robô de automação de processos, conhecido como RPA, opera a tela como se fosse uma pessoa: abre o programa, clica, digita e lê o que aparece. Os dois resolvem o mesmo problema aparente e têm perfis de risco completamente diferentes. Este artigo apresenta os critérios para decidir e os casos em que cada um é a resposta correta.

A diferença fundamental

Integração via API — dois sistemas trocam dados de forma estruturada, por um canal que o fornecedor projetou para isso. O contrato é explícito: quais informações, em qual formato, com qual autenticação.

RPA — um robô simula uma pessoa usando o sistema. Ele depende da posição dos elementos na tela, dos textos exibidos e da sequência de cliques.

A consequência prática dessa diferença é a estabilidade. Uma API muda quando o fornecedor decide mudar, com aviso prévio e versionamento. Uma tela muda a qualquer atualização, sem aviso — e o robô simplesmente para de funcionar, às vezes de forma silenciosa.

Quando a integração via API é a escolha

Sempre que existir. Não é exagero: quando o sistema oferece uma interface oficial, usá-la é quase sempre mais barato no total, mesmo que o desenvolvimento inicial pareça mais trabalhoso.

Vantagens que se acumulam:

  • Estabilidade — não quebra com mudança visual
  • Velocidade — troca direta de dados, sem esperar telas carregarem
  • Confiabilidade — retorna erros claros que podem ser tratados
  • Volume — processa muito mais registros por minuto
  • Rastreabilidade — cada chamada fica registrada
  • Segurança — autenticação e permissões próprias, sem precisar guardar senha de usuário

Esse último ponto é frequentemente ignorado: um robô costuma precisar da senha de um usuário real para operar, o que cria um problema de controle de acesso e de auditoria.

Quando o RPA é a resposta certa

Há situações legítimas:

  • Sistema legado sem API — software antigo, muitas vezes sem fornecedor ativo, que não pode ser modificado
  • Sistema de terceiro que não expõe interface — e trocar de fornecedor não é viável
  • Portal externo — sites de governo, bancos e órgãos reguladores onde o acesso é apenas pela tela
  • Solução temporária — enquanto uma integração adequada é desenvolvida
  • Processo de baixo volume e alta estabilidade — algo que roda poucas vezes por mês numa tela que raramente muda
  • Validação rápida — provar que a automação gera valor antes de investir em integração

Nesses casos o RPA resolve um problema real que não teria outra solução viável.

O custo escondido do RPA

O RPA costuma ser vendido como mais barato e mais rápido de implantar. A primeira parte é verdadeira; a segunda depende do horizonte.

Os custos que aparecem depois:

  • Manutenção frequente — cada atualização do sistema alvo pode quebrar o robô
  • Falha silenciosa — o robô "funciona" e faz a coisa errada, o que é pior que parar
  • Monitoramento obrigatório — alguém precisa verificar se rodou e se rodou certo
  • Ambiente dedicado — uma máquina precisa ficar disponível com o sistema aberto
  • Licenças — plataformas de RPA costumam cobrar por robô
  • Gestão de credenciais — senhas de usuário que precisam ser mantidas e rotacionadas
Cenário hipotético: escritório contábil

Um robô extraía informações de um portal fiscal e alimentava o sistema interno. Funcionou bem até o portal mudar o layout, quando passou a capturar dados do campo errado sem gerar erro — a inconsistência só foi percebida no fechamento do mês. A correção incluiu uma verificação de sanidade nos dados capturados, algo que deveria existir desde o início em qualquer automação de tela.

Como decidir, na prática

Uma sequência de perguntas:

  1. Existe API? Se sim, use. Encerre a discussão.
  2. Existe possibilidade de exportação e importação de arquivos? Se sim, costuma ser mais estável que RPA.
  3. O fornecedor pode disponibilizar uma API? Vale perguntar — às vezes existe e não está contratada.
  4. É viável trocar o sistema? Se o sistema é fechado e essencial, isso vira uma decisão estratégica.
  5. Não havendo alternativa, o processo é estável e vale o custo de manutenção? Se sim, RPA.

E, ao adotar RPA, trate-o como solução com prazo: registre por que foi necessário e reavalie periodicamente se a alternativa apareceu.

Boas práticas quando o RPA for inevitável

  • Verificação de sanidade — o robô deve conferir se o que capturou faz sentido antes de gravar
  • Registro detalhado — o que fez, quando, com qual resultado
  • Alerta em caso de falha — silêncio não pode ser interpretado como sucesso
  • Usuário próprio para o robô — nunca a conta pessoal de um funcionário
  • Documentação do fluxo — para que outra pessoa consiga corrigir
  • Teste após toda atualização do sistema alvo
  • Plano de contingência — como o processo é feito manualmente enquanto o robô está parado

Conclusão

A regra é direta: existindo API, use API. RPA é ferramenta legítima para contornar sistemas que não oferecem outro caminho, e nesse papel resolve problemas reais.

O erro caro é adotar RPA por parecer mais rápido, ignorando sistemas que já têm interface oficial. Você troca um desenvolvimento único por uma manutenção permanente — e por um robô que pode falhar em silêncio, entregando dado errado sem que ninguém perceba.