Sistema velho não é desculpa: IA em cima de ERP legado

A resposta direta: dá, sim, pra colocar IA em cima de um ERP legado sem API. Existem 3 rotas técnicas pra isso, computer use, RPA híbrido e camada de dados, cada uma com custo e nível de robustez diferente. “Meu sistema é antigo demais” parou de ser motivo suficiente pra travar o projeto.

Dá pra usar IA num ERP que não tem API?

Dá. Até pouco tempo atrás, “meu sistema não tem API” era o fim da conversa: sem endpoint documentado, sem token, sem jeito de conectar nada por fora. Isso mudou porque surgiram caminhos que não dependem do fornecedor liberar acesso nenhum.

Sistemas de nicho, instalações antigas de Protheus ou telas em Delphi e Clipper dos anos 2000 são comuns em indústria, distribuição e varejo brasileiro. Boa parte nunca teve API REST, e talvez nunca vá ter, porque o fornecedor descontinuou o desenvolvimento ou porque expor API exigiria reescrever o sistema inteiro.

O que mudou não foi o ERP. Foi a forma de contornar a ausência de API: hoje existem 3 rotas maduras o suficiente pra rodar em produção, com nível de esforço e custo bem diferente entre elas.

Quais são as 3 rotas pra conectar IA a um ERP legado?

A gente já tinha mapeado um problema parecido pro CRM nesse post sobre CRM sem API: camada intermediária, migração ou operar sem ferramenta formal. Pra ERP a lógica é a mesma, mas as ferramentas mudam porque o volume de tela e a complexidade do sistema costumam ser maiores.

As 3 rotas são computer use, RPA híbrido e camada de dados, e a escolha certa depende de volume de tarefa, se é leitura ou escrita, e quanto orçamento o projeto tem pra setup inicial.

• Computer use. O agente vê a tela do ERP por um print, move o mouse, clica e digita como uma pessoa faria. Não precisa de API nenhuma, mas cada ação leva segundos e custa mais por execução.
• RPA híbrido. Combina ferramenta clássica de automação de tela, tipo UiPath ou Automation Anywhere, com uma camada de IA por cima pra interpretar texto livre e decidir exceção. Mais barato que computer use puro em tarefa repetitiva agendada, mais rígido quando o layout muda.
• Camada de dados. Em vez de mexer na tela, a IA consulta uma cópia ou exportação do banco do ERP, via CSV agendado, view SQL de leitura ou réplica de banco. Não toca no sistema original, então não tem risco de clique errado.

Como funciona computer use num ERP antigo e quanto custa?

Computer use é a tecnologia que a Anthropic lançou em outubro de 2024, seguida pela OpenAI em janeiro de 2025 com o Operator: o modelo recebe um print da tela, decide a próxima ação e confere o resultado com outro print, num loop. A gente já detalhou esse loop nesse post anterior sobre computer use.

Aplicado a ERP legado, o ganho é direto: o agente entra no sistema do jeito que um funcionário entra, sem que o fornecedor libere endpoint nenhum. Hipotético pra deixar concreto: imagine uma indústria de médio porte com faturamento num ERP em Delphi de 2009, sem API, onde alguém copia manualmente o status de 30 pedidos toda manhã pra uma planilha. Um agente de computer use pode abrir o sistema, navegar até a tela certa e copiar os dados sozinho, todo dia.

O custo mora na velocidade: cada ação de tela consome um print de alta resolução e uma rodada de raciocínio do modelo, o que leva de alguns segundos a mais de um minuto por passo. Como estimativa conservadora, uma tarefa de poucas telas fica na faixa de poucos centavos de token por execução, mas escala pra um custo maior quando a tarefa tem dezenas de telas ou roda centenas de vezes por dia.

O que é RPA híbrido e quando ele bate computer use?

RPA híbrido combina ferramenta clássica de automação de tela, como UiPath ou Automation Anywhere, com uma camada de IA generativa que interpreta texto livre e decide o que fazer numa exceção. O RPA tradicional sozinho decora a posição de um botão (o selector) e quebra quando o layout muda um pixel; a IA por cima reduz essa fragilidade porque interpreta o que está na tela, não só a posição fixa.

Não acho que computer use deveria ser a rota padrão pra ERP legado com volume alto. Porque quando a tarefa é repetitiva e roda centenas ou milhares de vezes por mês, RPA híbrido tende a sair mais barato por execução, já que o robô segue um script pré-definido e só aciona a IA nas exceções, em vez de raciocinar do zero em cada ação.

O ponto fraco do RPA híbrido é a manutenção: ele ainda depende de um script inicial mapeado tela por tela, e uma atualização grande no ERP pode exigir remapear parte do fluxo. Faz mais sentido pra tarefa agendada e estável, tipo fechamento de mês ou extração de relatório diário, do que pra tarefa que muda de formato toda vez.

O que é camada de dados e por que ela costuma ser a rota mais robusta?

Camada de dados é conectar a IA direto numa cópia dos dados do ERP, sem passar pela tela nenhuma vez. Na prática, isso costuma sair de uma exportação agendada (CSV ou Excel gerado toda noite), de uma view SQL de leitura que o próprio ERP já expõe via ODBC, ou de uma réplica de banco montada com ferramenta de ETL.

A vantagem central: sem tela envolvida, não tem risco de clique errado, popup travando o fluxo ou layout mudando de lugar. O agente de IA consulta um banco de dados normal, do jeito que consultaria qualquer sistema moderno, enquanto o trabalho de sincronizar com o ERP acontece numa camada separada, isolada do uso do dia a dia.

O contraponto é o esforço inicial. Levantar quais tabelas o ERP expõe, decidir a frequência de exportação e montar o pipeline, com ferramenta como n8n ou Make, leva mais tempo de setup do que ligar computer use direto na tela. Depois de pronto, porém, o custo de rodar uma consulta na camada de dados é uma fração do custo de repetir a mesma tarefa via tela.

Qual das 3 rotas escolher pro meu ERP legado?

A escolha depende de 3 perguntas: é leitura ou escrita, qual o volume mensal, e quanto o projeto pode investir de setup inicial.

• Leitura de baixo volume, tarefa única ou rara: computer use resolve rápido, sem setup pesado, mesmo custando mais por execução.
• Tarefa repetitiva, alto volume, layout estável: RPA híbrido costuma sair mais barato por execução no médio prazo, porque roda script fixo e só aciona IA na exceção.
• Consulta frequente de dado, relatório, dashboard: camada de dados é a rota mais robusta, porque tira o ERP do caminho crítico depois que a exportação está rodando.

Sendo bem sincero: a maioria das empresas que travam nesse tipo de projeto não escolhe a rota errada, elas simplesmente não escolhem nenhuma e ficam esperando o fornecedor lançar uma API que talvez nunca saia. Pra escala de comparação, uma operação comercial de ponta a ponta como o Super SDR tem setup de R$8 mil a R$15 mil e infraestrutura de R$550 a R$650 por mês; automatizar um fluxo dentro de um ERP legado fica numa fração desse esforço, mais perto de projeto pontual do que de operação inteira.

Sistema velho não é motivo pra esperar. As 3 rotas existem, rodam em produção e custam menos do que parece à primeira vista. O que trava a maioria dos projetos não é o ERP, é a decisão de escolher uma rota e começar.

FAQ

Preciso trocar de ERP pra usar IA? Não. As 3 rotas, computer use, RPA híbrido e camada de dados, foram desenvolvidas justamente pra evitar troca de sistema. Trocar de ERP é um projeto grande, caro e arriscado, geralmente maior do que o problema que motivou a pergunta original. Só faz sentido migrar de ERP se o sistema atual já causa outras dores, tipo fornecedor sem suporte, ninguém na empresa que saiba mexer nele ou performance ruim, e a falta de API é só mais um item na lista de motivos.

Quanto custa integrar IA num ERP legado? Varia bastante com a rota e o volume de tarefa. Computer use custa mais por execução, mas quase nada de setup; camada de dados custa mais setup e menos por consulta depois de pronta; RPA híbrido fica no meio. Como escala, uma operação comercial completa como o Super SDR tem setup de R$8 mil a R$15 mil e infraestrutura de R$550 a R$650 por mês; automatizar um fluxo específico de ERP costuma ficar numa fração desse valor.

Computer use é seguro pra mexer no módulo financeiro do ERP? Pra leitura e consulta, sim, com risco parecido com dar acesso de tela pra um estagiário treinado. Pra escrita que afeta faturamento, cadastro fiscal ou qualquer lançamento financeiro, o recomendado é manter um humano revisando antes de confirmar, porque uma ação de tela pode parar no meio, preenchendo 3 de 5 campos e travando, sem a garantia de tudo ou nada que uma API bem feita costuma oferecer.

RPA clássico já não fazia isso? Qual a diferença pro RPA híbrido? RPA clássico, tipo UiPath ou Automation Anywhere, decora a posição de um botão ou campo na tela e executa sempre o mesmo script. Funciona bem enquanto a tela não muda, mas quebra fácil quando o layout se altera um pouco. RPA híbrido junta esse motor de execução com uma camada de IA generativa que interpreta o que está na tela e decide o que fazer numa exceção, reduzindo a fragilidade sem perder a velocidade de rodar um script já pronto.

Quanto tempo leva pra colocar IA rodando em cima de um ERP antigo? Depende da rota. Computer use costuma sair funcionando em poucos dias de configuração e teste, porque não exige mapear banco nem script fixo. Camada de dados leva mais tempo inicial, de alguns dias a poucas semanas, porque precisa levantar quais tabelas o ERP expõe e montar o pipeline de exportação. RPA híbrido fica entre os dois, com o tempo variando conforme quantas telas o fluxo percorre até completar a tarefa.

Meu ERP nem exporta CSV, e agora? Se não tem exportação nem view SQL disponível, montar a camada de dados fica mais difícil, e computer use ou RPA híbrido tendem a ser o caminho mais direto pra começar. Vale perguntar pro fornecedor do ERP se existe um banco de relatório separado do banco de produção, prática comum mesmo em sistema antigo, porque isso pode liberar a camada de dados sem tocar no banco principal nem correr risco de travar a operação.