RPA ou integração de sistemas: qual escolher

RPA automatiza uma tarefa clicando na tela como se fosse uma pessoa, e integração de sistemas resolve a mesma tarefa conversando direto com o software, sem tela nenhuma no meio. Os dois entregam o mesmo resultado no primeiro mês, e é depois do terceiro que eles se separam de vez. A diferença aparece no custo de manutenção, não no preço da entrega.

Este texto compara os dois caminhos pelo que quebra em cada um, mostra a demanda medida por trás dessa busca e entrega a régua de escolha que você aplica sem depender de fornecedor. Se você já recebeu uma proposta de robô e outra de integração para o mesmo processo, leia com as duas abertas. Cada seção aponta uma linha que costuma ficar de fora de uma delas.

Qual é a diferença real entre RPA e integração de sistemas?

O robô de RPA opera a interface gráfica do jeito que um funcionário opera, abrindo janela, procurando campo, digitando e clicando em botão. Ele não sabe o que está fazendo, ele repete um caminho visual que alguém gravou uma vez. A integração por interface de programação faz o contrário, porque ela fala com o sistema na linguagem que o próprio sistema usa por baixo. Não existe tela envolvida, não existe posição de botão para mudar de lugar, e o contrato entre as duas pontas é explícito e versionado.

Vale separar isso de um vizinho barulhento antes de seguir. RPA é robô de escritório, que mexe em sistema administrativo e financeiro, e não tem relação nenhuma com robô de chão de fábrica, que é engenharia de controle e vive em outro mundo. Como as duas áreas usam a palavra automação, vale confirmar com o fornecedor de qual delas ele está falando antes de comparar preço ou prazo.

Onde o robô de tela quebra depois do primeiro trimestre?

O robô de RPA depende de a tela continuar exatamente igual, e tela é a parte do software que mais muda. Uma atualização do fornecedor que troca um campo de lugar derruba o robô inteiro, e a falha costuma ser silenciosa, porque o robô continua rodando e só para de acertar. Por isso a pergunta certa para o fornecedor do robô não é se ele funciona hoje. É como você fica sabendo no dia em que ele parar de acertar.

Existe uma segunda categoria de quebra que assusta mais, e ela é a de dado errado sem erro visível. O robô encontra um campo parecido no lugar do certo, preenche, salva, e ninguém descobre até o fechamento do mês não bater com o extrato. Os pontos de falha típicos aparecem quase sempre nesta ordem, e nenhum deles é culpa de quem construiu:

• Atualização do sistema de origem que muda posição, nome ou ordem de um campo na tela.
• Janela de confirmação nova, que o robô não conhece e que trava o fluxo inteiro no meio.
• Sessão que expira ou exige segundo fator, e o robô fica parado esperando alguém perceber.
• Volume que cresce e o robô não escala, porque ele é limitado pela velocidade da própria tela.
• Exceção de negócio que ninguém gravou, e o robô segue o caminho feliz aplicando a regra errada.

Quanto custa manter cada caminho ao longo de três anos?

O erro de orçamento clássico aqui é comparar o preço da primeira entrega, que é onde o RPA sempre ganha. A comparação honesta é a de três anos, porque é nesse prazo que a manutenção acumulada aparece e inverte o resultado na maioria dos casos. Para fazer essa conta, peça às duas propostas o custo da entrega e o custo anual de manutenção. Peça também o que acontece com o fluxo quando um dos sistemas envolvidos é atualizado.

A linha que decide quase todas as discussões é a de custo de manutenção. RPA transfere para você o risco de todas as atualizações de todos os sistemas que ele toca, e esse risco não aparece em nenhuma proposta comercial no dia da assinatura. Pergunte quem paga o ajuste do robô quando o sistema de origem muda a tela, e se isso está no contrato de manutenção ou é cobrado por chamado. Pergunte também qual é o prazo de correção.

O que a demanda medida diz sobre quem procura RPA hoje?

Medi esse mercado no Keyword Planner do Google Ads, pelo DataForSEO, com recorte de Brasil e português. O contraste entre volume e custo por clique conta uma história bem específica sobre o momento do comprador. Os volumes são médias de pesquisas mensais de um período de doze meses, e o custo por clique indica quanto os anunciantes pagam por uma visita vinda de cada termo.

O termo genérico tem 27.100 buscas e um clique de R$ 1,02, ou seja, muita gente estudando o assunto e quase ninguém pronto para comprar. Já as variantes específicas custam de R$ 3,26 a R$ 7,62 por clique com uma fração do volume, e é ali que está quem tem problema real e orçamento. Na hora de pedir proposta, descreva o processo pelo nome específico, como integração do pedido com o financeiro, e não apenas como RPA. Assim os orçamentos chegam comparáveis.

Repare também que nenhuma das seis linhas está acima da própria média de doze meses no mês mais recente, e cinco delas estão abaixo. O assunto continua grande, só que ele saiu do pico de curiosidade e entrou na fase em que quem busca já está tentando resolver alguma coisa concreta. Isso favorece quem chega com o processo descrito em números, como volume mensal e sistemas envolvidos, porque a conversa já começa pelo que interessa.

Quando o RPA continua sendo a escolha certa mesmo assim?

Existe um caso em que RPA ganha sem discussão, e ele é bem definido. Quando o sistema do outro lado simplesmente não tem interface de programação e o fornecedor não pretende criar uma, operar a tela é a única porta que existe. Existe um segundo caso, que é o de prazo curto com data de validade conhecida. Se você precisa cobrir seis meses até a troca de um sistema que já está contratada, gravar um robô é mais barato do que integrar algo que vai ser jogado fora.

O que não funciona é adotar RPA como arquitetura permanente para uma operação que cresce. Nesse desenho você acumula robôs frágeis, cada um dependente da tela de um fornecedor diferente, e o time acaba passando o mês inteiro consertando robô em vez de melhorar processo. Se o robô entrar como solução temporária, coloque no contrato a data de desligamento e o plano de integração que vai substituí-lo. Assim o provisório não vira permanente.

Onde entra o agente de IA nessa conta, e onde ele não entra?

Agente de IA resolve a parte que nem RPA nem integração resolvem sozinhas, que é decidir o que fazer quando o caso não é padrão. Fluxo fixo segue sempre o mesmo caminho, e o agente escolhe o caminho a partir do objetivo que você deu para ele. Só que o agente precisa das mesmas portas que a integração usa, porque ele também não deveria estar clicando em tela para trabalhar. Na prática o desenho que se sustenta é integração como base, e agente por cima dela para as decisões que exigem julgamento.

O que separa demo de produção nesse ponto é limite explícito no que o agente pode fazer, validação da saída, retorno seguro quando a confiança cai e transferência para humano. Sem essas quatro peças, o que você tem é uma demonstração cara com risco de escrever besteira no seu banco de dados. Peça ao fornecedor que mostre cada uma dessas quatro peças funcionando com um caso fora do padrão, e não com o exemplo da demonstração.

Como escolher entre os dois sem depender do fornecedor?

Responda três perguntas antes de pedir qualquer proposta, porque elas resolvem a decisão sozinhas na maioria dos casos. A primeira é se o sistema do outro lado tem interface de programação documentada, e a segunda é quantas vezes por ano a tela dele muda. A terceira é quanto custa uma hora de erro silencioso na sua operação, contando retrabalho e o que você deixa de faturar. Quando essa hora vale caro, o modelo que falha em silêncio deixa de ser uma opção, e o preço menor da entrega inicial vira uma armadilha.

Na SyntaxLab a integração e o agente saem em código de verdade, versionado, com o repositório ficando seu no fim, e o número final vem do discovery, que é etapa obrigatória e blinda o orçamento. Leve as respostas das três perguntas para essa conversa, porque elas encurtam o discovery. Veja como funcionam agentes e automação ou, se o que você precisa é o sistema inteiro, comece por software sob medida.