Robô no portal ou integração por API: como escolher a automação certa

Toda empresa tem uma tarefa assim: alguém abre o portal do banco, do fornecedor ou de um órgão público, digita um CPF, espera a tela carregar, copia o resultado para a planilha e repete. Cinquenta vezes por dia. A pergunta que chega até nós quase sempre é a mesma: dá para automatizar isso?

Quase sempre dá. A pergunta é por qual porta. Um caminho é conversar com o sistema pela API, a porta que ele oferece para outros programas. O outro é um robô que opera a tela do portal como uma pessoa, clicando e digitando, o que o mercado chama de RPA. Este texto explica quando cada um faz sentido, o que pode dar errado e por que muitos projetos usam os dois.

As duas portas: API e interface

Pense no portal do seu fornecedor como uma loja. A interface é o balcão: feito para pessoas, com vitrine, botões e formulários. A API é a doca de carga nos fundos: feita para sistemas, com regras escritas sobre o que entra, o que sai e em que formato. Quando a doca existe e você tem acesso a ela, a integração troca dados estruturados, com contrato documentado, e não depende de onde o botão está na tela.

O robô de interface usa o balcão. Ele abre um navegador, faz login, preenche campos e lê o que aparece. A vantagem é que funciona onde não existe doca nenhuma, o que é comum em portal de banco para empresa, sistema de prefeitura, portal de convênio e extranet de fornecedor. A desvantagem é que o balcão foi feito para gente, e muda quando o dono quer, sem avisar quem automatizou em cima dele.

A própria documentação do Playwright, uma das ferramentas mais usadas para controlar navegador por código, resume o problema: a estrutura de uma página muda com facilidade, e automação que depende dela quebra. A recomendação é localizar elementos pelo que o usuário vê, como o nome do botão, em vez de caminhos internos do HTML. Isso reduz a fragilidade, mas não a remove.²

O que mudou com a IA operando o computador

O RPA clássico segue um roteiro fixo: "clique no campo X, digite Y, leia a célula Z". Se o campo X mudou de lugar, o roteiro falha. A novidade dos últimos anos são modelos de IA que olham a tela por captura de imagem e decidem a próxima ação. A Anthropic, por exemplo, oferece uma ferramenta de "computer use" em que o Claude recebe capturas de tela e devolve ações como clicar, digitar e rolar a página, num ciclo repetido até concluir a tarefa.¹

Isso deixa o robô mais tolerante a mudanças pequenas de layout. Mas cada ação passa por uma ida e volta ao modelo, e cada captura de tela consome tokens — por isso o processo tende a ser mais lento e mais caro por operação do que um roteiro fixo. E a mesma documentação traz avisos que todo dono de empresa deveria ler antes de aprovar um projeto desses.¹

Repare na tensão: a tarefa típica de portal exige login, e o fornecedor recomenda não entregar login ao modelo. Na prática, a saída é separar as funções. A autenticação e as credenciais ficam num componente de código tradicional, sob seu controle, e a IA entra só onde a tela é imprevisível. IA olhando a tela é um recurso para o trecho difícil, não o motor de todo o fluxo.¹

Quatro perguntas para decidir

No diagnóstico, a decisão costuma sair de quatro perguntas, nesta ordem. A primeira muitas vezes já decide o caminho; as outras dizem quanto cuidado o caminho escolhido vai exigir.

Os riscos que ninguém coloca no orçamento

Termos de uso do portal

Há portais que proíbem acesso automatizado nos termos de uso, e há os que detectam e bloqueiam robôs. Antes de qualquer linha de código, leia os termos ou pergunte ao fornecedor. Às vezes a resposta é uma surpresa boa: o fornecedor tem uma API que não divulga e libera para quem pede. Quando os termos proíbem, um robô em produção é um risco ao relacionamento comercial, não um detalhe técnico.

Credencial, sessão e 2FA

Robô de portal precisa de usuário e senha, e isso precisa ser tratado como dinheiro. O ideal é um usuário exclusivo para o robô, com o mínimo de permissão, nunca o login pessoal do diretor. A documentação do Playwright alerta que o arquivo onde a sessão do navegador fica salva pode conter cookies e cabeçalhos sensíveis, capazes de permitir que alguém se passe pela conta, e desaconselha guardá-lo em repositório de código. Sessões também expiram, o que exige rotina de reautenticação.³

Dois fatores e captcha são o ponto mais sensível. Se o portal manda código por SMS a cada login, o fluxo precisa de uma pessoa no circuito ou de uma conversa com o fornecedor. Contornar captcha transforma automação útil em violação de termos de uso.

LGPD e dado de terceiros

A LGPD chama de tratamento toda operação com dado pessoal, como coleta, utilização, acesso, armazenamento e transmissão. Um robô que lê a lista de funcionários, consulta cada CPF no portal e grava o resultado numa planilha está tratando dados pessoais em cada etapa. A lei exige uma base legal para isso e pede que o tratamento se limite ao mínimo necessário para a finalidade.⁴

Também exige medidas de segurança técnicas e administrativas para proteger esses dados de acesso não autorizado e de perda. Na prática: a planilha de saída não circula por e-mail e os registros de execução não despejam CPF em texto aberto. Quando a GoDEV opera o robô para o cliente, o cliente é o controlador e nós somos operador, tratando os dados segundo as instruções dele, como define a lei.⁴

Vale ainda olhar se o seu setor já tem um caminho oficial. No sistema financeiro, o Open Finance, regulado pelo Banco Central e pelo Conselho Monetário Nacional, é definido como compartilhamento padronizado de dados e serviços por meio de abertura e integração de sistemas. As instituições participantes precisam oferecer interfaces dedicadas e padronizadas, e o compartilhamento depende de consentimento do cliente para finalidades determinadas.⁵

Isso não significa que qualquer empresa pode plugar direto na API de qualquer banco: o circuito é entre instituições participantes, listadas na própria resolução. Mas vale perguntar ao seu banco ou parceiro financeiro qual caminho oficial existe antes de automatizar o portal.⁵

Manutenção: o custo que aparece depois

Integração por API costuma ser revisitada quando o fornecedor publica nova versão. Robô de tela precisa de supervisão contínua. O portal muda um botão, troca o texto de um campo, acrescenta um aviso de cookies, e o robô para ou, pior, segue em frente lendo o campo errado.

Por isso um robô de portal sério tem três coisas que não aparecem na demonstração: verificação de que cada tela é a esperada antes de agir, alerta quando algo sai do padrão e um relatório por execução dizendo o que foi processado, o que falhou e por quê. Sem isso, o erro silencioso é o resultado mais provável, e ele é pior que a falha visível.²

O caminho híbrido, que é o mais comum

Na maioria dos projetos a resposta não é uma ou outra. É API onde existe, robô onde não existe, e código comum no meio. Um desenho típico: a planilha de entrada chega por upload; o robô entra no único portal sem API e faz as consultas; o resultado é gravado e enviado ao ERP pela API do ERP; e uma pessoa aprova o que tem consequência financeira antes do envio.

Um caso nosso ilustra o formato. No site descrevemos assim: "Robô de consulta de crédito consignado: CSV entra, o robô autentica no portal do banco, consulta pessoa a pessoa e devolve a planilha." O resultado registrado foi "Consulta em lote no lugar de horas de trabalho manual em portal". A consulta em si passa pela tela do portal; a entrada e a saída são arquivos estruturados, e é isso que permite encaixar o processo no resto da operação.

Também vale lembrar o que a IA não resolve aqui. Ela deixa o robô mais tolerante a mudanças de tela, mas não cria permissão de acesso que você não tem, não dispensa base legal para tratar dado pessoal e não substitui a confirmação humana nas decisões que mexem com dinheiro ou contrato.¹

Resumo para decidir na reunião