Do RPA à hiperautomação: o que mudou e o que veio para ficar

Entre 2016 e 2020, RPA foi vendido como a resposta para praticamente qualquer processo manual. A promessa era sedutora: um robô grava o que o funcionário faz na tela e repete sozinho, sem tocar no sistema legado, sem projeto de TI. Muita empresa comprou. Uma parte considerável dessas automações não existe mais.

O termo hiperautomação apareceu depois, e o risco é tratá-lo como o mesmo produto com nome novo. Não é. A diferença é real e vale entender antes de assinar qualquer contrato.

O que RPA clássico faz e por que quebra

RPA opera na camada de interface. O robô localiza um campo pela posição ou pelo identificador do elemento, digita, clica, espera, lê o resultado. Do ponto de vista do sistema alvo, é um usuário humano muito rápido.

Essa é ao mesmo tempo a virtude e o defeito. A virtude: funciona em qualquer sistema, inclusive naquele ERP de 2004 sem documentação. O defeito: qualquer mudança visual quebra o robô.

Os modos de falha mais comuns na prática:

• Atualização do sistema alvo. Um campo muda de lugar e o fluxo inteiro para.
• Variação de tempo de resposta. O robô clica antes de a tela carregar e digita no lugar errado.
• Exceções não previstas. Um pop-up de aviso que aparece uma vez a cada duzentas execuções trava tudo.
• Autenticação. Verificação em duas etapas introduzida pelo fornecedor derruba automações inteiras da noite para o dia.
• Custo por robô. Licenciamento por execução simultânea faz o custo crescer bem mais rápido que o volume de valor.

Nada disso significa que RPA foi um erro. Significa que ele foi aplicado em casos onde havia caminho melhor.

O que a hiperautomação acrescenta

Hiperautomação não é uma ferramenta, é uma combinação de camadas. Um projeto maduro tem, tipicamente:

Camada	Função	Exemplo de tecnologia
Integração	Trocar dados direto entre sistemas	APIs REST, webhooks, filas
Orquestração	Coordenar passos, condições e esperas	n8n, Temporal, Camunda
Regras de negócio	Decidir sem código espalhado	Tabela de decisão, motor de regras
Inteligência	Lidar com dado não estruturado	Modelos de linguagem, OCR
Interface	Último recurso para sistemas fechados	RPA, automação de navegador
Observabilidade	Saber o que rodou e o que falhou	Logs estruturados, alertas, painel

A inversão de prioridade é o ponto central. No modelo antigo, a camada de interface era o começo. Agora ela é o último recurso, usado apenas quando as anteriores não são possíveis.

Critério de escolha em três perguntas

Antes de decidir a abordagem para qualquer processo, responda em ordem:

1. O sistema tem API ou acesso ao banco? Se sim, use integração direta. É mais barata de manter e não quebra com mudança de tela.
2. Existe exportação e importação de arquivo? Muitos sistemas sem API aceitam CSV. Um fluxo que gera arquivo, transfere e importa é bem mais estável que um robô de tela.
3. Nada disso existe? Aí sim RPA se justifica, e ainda assim com escopo mínimo: o robô deve fazer só o trecho impossível, com o resto do processo orquestrado fora dele.

Caso real: contas a pagar em uma distribuidora

Uma distribuidora de materiais elétricos com 80 funcionários recebia cerca de 900 notas fiscais de fornecedores por mês, por e-mail, em formatos variados. Duas pessoas do financeiro gastavam aproximadamente cinco horas por dia lançando dados no ERP e conferindo divergências com pedidos de compra.

A primeira tentativa, dois anos antes, tinha sido RPA puro: um robô abria o e-mail, salvava o anexo, abria o ERP e digitava. Durou quatro meses. Caiu quando o ERP recebeu uma atualização de layout e o custo de reprogramar não se pagou.

A segunda tentativa foi estruturada em camadas:

• Captura. Uma caixa de e-mail dedicada com regra que envia cada anexo para um armazenamento e dispara um webhook.
• Extração. Para XML de nota fiscal eletrônica, leitura direta do arquivo, sem IA, porque o formato é estruturado. Só os PDFs de fornecedores pequenos, cerca de 15% do volume, passam por um modelo de linguagem que devolve JSON com fornecedor, número, valor, vencimento e itens.
• Validação. Regras determinísticas comparam o total da nota com o pedido de compra correspondente, com tolerância de 2% para arredondamento de frete.
• Lançamento. O ERP tinha uma API de importação pouco documentada que ninguém havia investigado. Uma tarde de trabalho com o suporte do fornecedor resolveu o que dois anos de robô de tela não sustentaram.
• Exceção. Notas com divergência acima da tolerância ou extração incompleta vão para uma fila com interface simples, onde a pessoa do financeiro aprova ou corrige em poucos cliques.

Resultados após quatro meses de operação: 83% das notas processadas sem toque humano, tempo médio de lançamento caiu de 4 minutos para 12 segundos nas automáticas, e a equipe passou de dez horas diárias combinadas para cerca de duas, concentradas na fila de exceção. O custo mensal de plataforma e modelo ficou em torno de R$ 420.

O detalhe mais importante: a automação sobreviveu a duas atualizações do ERP, porque não dependia da tela.

Onde a IA ajuda e onde atrapalha

Existe uma tentação forte de colocar modelo de linguagem em todo passo. É caro e frágil. A regra que funciona:

Use IA quando a entrada é não estruturada e a variação é alta. Leitura de PDF sem padrão, classificação de e-mail de cliente, extração de intenção em texto livre, resumo de chamado longo.

Não use IA quando existe regra determinística. Comparar valores, verificar prazo, aplicar desconto por faixa, decidir aprovação por limite. Uma condição em código é instantânea, gratuita, auditável e nunca muda de opinião.

Um padrão que evita muita dor de cabeça é forçar saída estruturada e validar antes de usar:

const schema = z.object({
  fornecedor_cnpj: z.string().regex(/^\d{14}$/),
  numero_nota: z.string().min(1),
  valor_total: z.number().positive(),
  vencimento: z.string().date(),
});

const parsed = schema.safeParse(JSON.parse(resposta));
if (!parsed.success) {
  await enviarParaFilaDeExcecao(documento, parsed.error);
  return;
}

Qualquer coisa que o modelo devolva fora do formato esperado vira exceção humana, nunca dado gravado por engano.

O que mede um projeto saudável

Automação sem métrica vira folclore interno. Quatro números bastam:

• Taxa de conclusão automática. Percentual de execuções que terminam sem intervenção. Abaixo de 60% depois de três meses, o processo foi mal escolhido.
• Tempo de ciclo. Do gatilho ao resultado final, incluindo o tempo parado em fila de exceção.
• Custo por execução. Plataforma, chamadas de modelo e tempo humano residual divididos pelo volume.
• Taxa de retrabalho. Quantas execuções automáticas precisaram ser corrigidas depois. Esse é o número que mais engana quando ignorado.

Erros que se repetem

1. Automatizar um processo ruim. Se o fluxo tem três aprovações desnecessárias, automatizar preserva a burocracia em velocidade maior. Simplifique antes.
2. Começar pelo processo mais complexo. O primeiro projeto deve ser pequeno o bastante para entregar em três semanas e visível o bastante para gerar apoio interno.
3. Ignorar o caminho de exceção. Todo fluxo precisa de uma saída digna para o caso que não se encaixa. Sem isso, a exceção volta para o e-mail e ninguém sabe onde parou.
4. Nenhum dono. Automação precisa de uma pessoa responsável por olhar o painel toda semana. Sem dono, a primeira falha silenciosa vira três meses de dados errados.
5. Depender de conhecimento de uma pessoa só. Fluxos precisam estar versionados e documentados em texto, não só na cabeça de quem construiu.

Por onde começar nesta semana

Liste os processos manuais recorrentes da empresa e classifique cada um em duas dimensões: volume mensal e grau de padronização. O que tem volume alto e padrão claro entra primeiro. O que tem volume baixo e muita exceção fica de fora, mesmo que incomode.

Para o primeiro escolhido, investigue se os sistemas envolvidos têm API antes de qualquer outra coisa. Essa única verificação define se você vai construir algo que dura anos ou algo que quebra no próximo trimestre.

Conclusão

A mudança do RPA para hiperautomação não é sobre trocar de ferramenta. É sobre parar de tratar automação como um truque em cima da tela e passar a tratá-la como parte da arquitetura de sistemas da empresa, com integração, regras, tratamento de exceção e monitoramento.

O robô que clica continua existindo e tem seu lugar. Só não deveria mais ser o primeiro item da lista.