O que é RPA: quando o robô de tela é a única saída e o que ele cobra depois

Toda empresa tem pelo menos um sistema que não deixa ninguém entrar: o portal do banco, o site do órgão público, o ERP antigo que o fornecedor não mexe mais. O dado precisa entrar ali e a única porta que existe é a tela. É nesse buraco que o RPA mora — e entender o que é RPA antes de contratar um robô é o que separa uma automação que se sustenta de uma que quebra na primeira atualização do sistema.

O que é RPA e o que um robô de tela realmente faz

*RPA é a sigla de Robotic Process Automation, automação robótica de processos: um software que opera a interface de outro sistema — abre a tela, clica, preenche campo, digita, lê o que apareceu e segue para o próximo passo, imitando o que uma pessoa faria com mouse e teclado.* Não existe robô físico nem braço mecânico. Existe um programa fingindo ser um usuário.

A consequência dessa definição é o artigo inteiro: o robô não conversa com o sistema, ele usa o sistema. Não há porta oficial, há imitação de uso. O sistema do outro lado não sabe que está sendo automatizado e nunca concordou com isso.

Vale separar dois termos que costumam ser vendidos como sinônimos. Automação de processos é o objetivo — fazer o trabalho acontecer sem redigitação. RPA é uma técnica entre outras para chegar lá, e é a técnica que se usa quando as portas oficiais não existem.

Também vale dizer o que o robô não faz:

• Não entende o processo. Ele repete um roteiro gravado por alguém.
• Não julga caso fora do padrão. O que não estava previsto vira erro ou vira lançamento errado.
• Não percebe que o número está errado. Se a origem veio torta, a tela recebe torta.

Robô assistido e não assistido: quem dispara e onde ele roda

Essa é a distinção que mais muda o desenho do projeto, e nem sempre aparece explicitada na proposta.

O não assistido é o que a maioria imagina quando ouve "robô", e é também o que carrega a conta escondida: exige máquina que fique ligada e logada, usuário próprio no sistema alvo e um plano para o que acontece quando ele falha fora do horário de expediente.

O assistido é mais barato de montar e mais limitado de escala. O ganho é o tempo daquela pessoa, e o processo continua preso à agenda dela — se ela está de férias, o robô está de férias junto.

A hierarquia de decisão: API, banco ou arquivo — e só então a tela

Antes de escolher a técnica, existe uma ordem para escolher o caminho por onde a informação passa:

1. API documentada. API é a porta oficial que um sistema oferece para outro sistema pedir e enviar dados, sem passar por uma pessoa. Quando existe, é contrato: muda com aviso e com versão.
2. Acesso ao banco de dados. Ler direto as tabelas do sistema. Funciona, mas o desenho do banco raramente é um compromisso do fornecedor — pode mudar em uma atualização. E gravar direto na base contorna as regras que o próprio sistema aplica.
3. Troca por arquivo. Exportação e importação de CSV, planilha ou arquivo posicional (texto com campos em posições fixas). Menos elegante, e normalmente o caminho mais estável entre os que o sistema já oferece pronto.
4. A tela. RPA.

A tela não é contrato. Ela muda quando o fornecedor quiser, sem avisar ninguém, porque mudar tela é decisão de produto e não quebra nada para o usuário humano — o humano olha, entende e clica no lugar novo. O robô não.

Por isso a diferença entre os caminhos não é de gosto técnico. Os três primeiros são caminhos previstos para máquinas trocarem dados. O quarto é o único desenhado para olhos humanos, e ninguém do outro lado se comprometeu a mantê-lo igual.

O mapa completo dos caminhos e das suas limitações está em integração de sistemas. O efeito disso no preço está em quanto custa automatizar um processo: o degrau escolhido move o orçamento de construção e move ainda mais o de manutenção.

Antes de contratar o robô: como confirmar que o sistema não tem outro caminho

Essa verificação é feita pelo gestor, sem depender de fornecedor de automação. São quatro checagens.

1. Pergunte ao fornecedor do sistema, com a pergunta certa e por escrito. "Esse sistema tem API para consultar e gravar [o dado X]? Existe documentação? Está incluída no meu plano?" Peça a resposta por e-mail, não por telefone — resposta verbal some na hora em que o projeto começa a custar dinheiro.
2. Procure a documentação sozinho. Busque o nome do sistema junto de "API", "documentação para desenvolvedores" ou "integração". Parte dos sistemas publica isso abertamente, e nem sempre o comercial que atende você sabe.
3. Olhe dentro do próprio sistema. Menu de exportação, relatório que sai em CSV ou Excel, importação por planilha, e a área de configurações procurando "chave de API" ou "token" — um código longo que identifica um sistema no lugar de uma pessoa.
4. Cheque o plano. Em alguns sistemas a API existe, mas só no plano superior. Compare o custo do upgrade com o custo de construir e manter um robô. Às vezes o upgrade é a decisão mais barata, e ninguém fez essa conta.

Pergunte também se existe banco de dados acessível ou uma pasta de troca de arquivos com o sistema.

A regra de fechamento: só depois que essas respostas forem todas "não" é que a tela entra na conversa. Isso encaixa no mapeamento do processo, que já pede o levantamento do que cada sistema permite de entrada e de saída.

O que o robô cobra depois de pronto

Um robô entregue e funcionando não é um projeto encerrado. É um compromisso recorrente, e os modos de falha são específicos da automação de tela.

Fragilidade a mudança de tela

Layout novo, campo que trocou de lugar, fluxo de login com uma etapa a mais, mensagem de erro com texto diferente. O robô não erra com elegância: ele clica no lugar errado ou trava esperando algo que não vai aparecer.

Dependência de máquina ligada e logada

O computador ou servidor precisa estar ligado, logado e com a sessão aberta. Uma atualização automática que reinicia a máquina de madrugada derruba a execução da noite — e ninguém fica sabendo até a manhã seguinte.

Credencial nominal no sistema alvo

O robô precisa de um usuário e uma senha no sistema. Se usar o login de uma pessoa, o log de auditoria vai mostrar aquela pessoa fazendo lançamentos que ela não fez, e a senha dela passa a viver dentro de um arquivo de configuração.

O caminho correto é usuário próprio do robô, com permissão mínima e identificável no log. Junto disso, é preciso um plano para quando a política de segurança obrigar troca periódica de senha ou exigir segundo fator — o código extra pedido no login, geralmente por aplicativo ou SMS. É aí que robôs param de rodar sem explicação aparente.

Sistema lento ou fora do ar

Quando o robô é construído com espera fixa — "aguarde cinco segundos e digite" — em vez de esperar pela confirmação de que a tela carregou, qualquer lentidão vira erro. Ele digita em cima de uma página que ainda não terminou de abrir, e o resultado é um lançamento parcial em vez de um erro claro. Exija espera por condição, não por relógio.

Ponto de parada seguro

O pior cenário do RPA não é parar — é parar no meio, deixando meio lançamento gravado no sistema. Exija que cada execução trate uma unidade completa (um pedido, uma nota) e saiba retomar sem duplicar o que já entrou.

Para o orçamento, a consequência é uma só: manutenção de robô não é acionamento de garantia, é linha fixa da conta. Quem vende sem colocar isso na proposta está apenas adiando a conversa.

Quando o RPA vale a pena e quando é a escolha errada

Vale a pena quando:

• O sistema é legado — antigo, ainda em uso e sem evolução do fornecedor —, não tem API e não há previsão de ganhar uma.
• É portal de terceiro onde a empresa é só usuária e não manda nas regras: site de banco, órgão público, portal de cliente.
• O volume é alto e o layout está estável há bastante tempo.
• É ponte temporária até a troca de sistema — com data para morrer combinada desde o início.

Sobre portal de terceiro, além da fragilidade técnica existe um ponto que não é técnico: os termos de uso. Alguns portais proíbem acesso automatizado. Ler esses termos e decidir é da empresa, não do fornecedor de automação.

É a escolha errada quando:

• O fluxo do processo muda toda hora — cada mudança vira reprogramação.
• A entrada não é estruturada e exige interpretar documento ou texto livre. Aí o problema é outro, e o caminho passa por IA aplicada ao processo.
• Existe API e ninguém perguntou. É a hipótese mais barata de descartar e a mais cara de descobrir depois.

RPA substitui sistema? Não. Ele cobre a distância entre sistemas que não conversam. Quando o robô vira a única forma de a operação funcionar, o que a empresa tem é um problema de sistema adiado com software em cima.

E o critério de volume merece reforço: robô frágil sobre volume pequeno raramente se paga, porque a manutenção custa o mesmo quer ele processe dez itens por mês ou dez mil.

O que exigir de quem vende RPA

Três exigências verificáveis na proposta, antes da assinatura:

1. Tratamento de falha. O que o robô faz quando a tela não carrega, quando o login falha e quando o sistema devolve erro. Quem é avisado, por qual canal e em quanto tempo. Robô que falha em silêncio é pior que o processo manual, porque ninguém está mais conferindo.
2. Registro do que foi executado. Log legível por gente, dizendo o que entrou, o que foi lançado e o que ficou pendente — para conferência diária e para auditoria depois.
3. Plano de manutenção escrito. O que está incluído quando a quebra vem de mudança do sistema de terceiro, qual o prazo de resposta e como é cobrado o que não está incluído.

E uma pergunta final, que separa fornecedor de solução de fornecedor de ferramenta: "você verificou se esse sistema tem API antes de propor o robô?". Quem não verificou está vendendo a técnica que sabe aplicar, não a solução do seu problema.

A posição da Projask é diagnosticar o processo e os caminhos disponíveis antes de escolher a técnica, e propor RPA só quando os outros caminhos realmente não existem. Se você está nessa decisão, descreva pelo WhatsApp o processo e os sistemas envolvidos — a leitura começa por quais portas cada sistema oferece.