IA não substitui automação — ela amplia o que pode ser automatizado

Com a popularização da inteligência artificial generativa, uma pergunta começou a aparecer com frequência:

IA vai substituir RPA?

Eu acho que essa pergunta parte de uma comparação errada.

RPA, APIs, modelos de linguagem, OCR e agentes não são versões sucessivas da mesma tecnologia.

Eles resolvem tipos diferentes de problema.

E, na prática, uma das possibilidades mais interessantes não é substituir automação por IA.

É usar IA para ampliar aquilo que conseguimos automatizar.

Automação tradicional gosta de regras claras

Imagine um processo:

Receber dados
Validar campos
Consultar sistema
Aplicar regra
Enviar informação
Registrar resultado

Se as regras são determinísticas, não precisamos de um modelo de linguagem para executar isso.

Um if continua sendo uma excelente tecnologia.

Se:

valor > 1000

então determinada ação acontece.

Não existe motivo para perguntar a uma IA qual deveria ser a resposta.

Quanto mais determinística a tarefa, mais interessante tende a ser usar lógica determinística.

É previsível.

Testável.

Reproduzível.

O problema aparece com informação não estruturada

Agora imagine que o processo receba um e-mail escrito livremente.

Precisamos descobrir:

• qual é a intenção do usuário;
• qual produto ele está mencionando;
• qual problema está relatando;
• qual informação deve ser extraída.

Esse tipo de tarefa é muito mais difícil de resolver apenas com regras.

Poderíamos criar regex, palavras-chave e dezenas de condições.

Funcionaria até certo ponto.

Mas linguagem natural possui variação demais.

É nesse tipo de cenário que IA pode ampliar a automação.

IA como componente, não necessariamente como processo inteiro

Eu gosto de pensar em uma arquitetura assim:

Entrada
  ↓
Automação
  ↓
IA interpreta ou classifica
  ↓
Automação valida
  ↓
Regra de negócio
  ↓
API ou sistema
  ↓
Resultado

A IA resolve a parte em que existe ambiguidade.

A automação continua controlando o processo.

Isso é diferente de entregar toda a decisão para um modelo e esperar que ele faça tudo sozinho.

Um exemplo simples

Suponha que recebemos mensagens como:

"Não consigo acessar minha conta desde ontem."

"Quero atualizar meu endereço."

"Meu pagamento foi recusado."

Um modelo pode classificar:

{
  "categoria": "acesso"
}

ou:

{
  "categoria": "atualizacao_cadastral"
}

Depois disso, a automação segue um fluxo determinístico.

Por exemplo:

categoria = acesso
      ↓
executar fluxo de suporte de acesso

A IA ajudou a transformar linguagem natural em um dado estruturado.

O restante continua controlado.

Structured Output muda bastante essa integração

Modelos de linguagem não precisam retornar apenas texto livre.

Quando conseguimos exigir uma estrutura, a integração fica muito mais interessante.

Em vez de receber:

Parece que o usuário está solicitando uma atualização cadastral.

podemos trabalhar com algo semelhante a:

{
  "categoria": "atualizacao_cadastral",
  "confianca": 0.94,
  "motivo": "Usuário solicitou alteração de endereço."
}

A automação consegue validar os campos e tomar decisões objetivas.

Essa combinação aproxima LLMs do restante de uma arquitetura de software.

IA não elimina validação

Esse ponto é fundamental.

Um modelo pode produzir uma resposta plausível e ainda assim estar errado.

Por isso, em processos reais, não gosto da ideia de tratar a saída da IA automaticamente como verdade.

Dependendo do risco, podemos usar:

• schema de saída;
• validação;
• listas de valores permitidos;
• confidence score;
• regras complementares;
• consulta a fontes;
• revisão humana;
• fallback.

Quanto maior o impacto da decisão, maior deve ser o controle.

Nem todo processo precisa de IA

Existe também um problema de moda tecnológica.

Como IA está em evidência, pode surgir a vontade de colocá-la em qualquer solução.

Mas imagine uma automação que precisa verificar:

status == "ATIVO"

Não precisamos de IA.

Ou somar valores de uma planilha.

Também não.

Ou chamar uma API com parâmetros conhecidos.

Novamente, não.

Nesses casos, IA provavelmente adicionaria:

• custo;
• latência;
• incerteza;
• dependência externa;
• complexidade.

Sem resolver um problema real.

Onde eu vejo mais valor

Algumas tarefas combinam muito bem com IA dentro de automações.

Classificação

Determinar categoria, intenção ou tipo de documento.

Extração

Transformar texto não estruturado em campos.

Resumo

Reduzir grandes volumes de texto antes de uma etapa humana.

Geração

Criar uma resposta inicial, descrição ou conteúdo.

Interpretação

Entender solicitações escritas de formas diferentes.

Normalização

Converter texto livre para um formato esperado.

Essas capacidades podem entrar dentro de processos já automatizados.

OCR e IA não são a mesma coisa

Outro ponto interessante é diferenciar tecnologias.

OCR tradicional responde principalmente:

Que texto existe nesta imagem?

Um modelo multimodal pode tentar responder:

O que este documento significa?

São níveis diferentes.

Em um documento, podemos ter:

Imagem
  ↓
OCR
  ↓
Texto

Depois:

Texto
  ↓
IA
  ↓
Classificação / extração / interpretação

Em algumas soluções modernas, essas etapas podem até estar combinadas.

Mas conceitualmente continuam resolvendo problemas diferentes.

RPA ainda possui espaço

Existem muitos sistemas sem APIs adequadas.

Aplicações desktop.

Portais antigos.

Sistemas internos.

Processos que exigem interação com interface.

Enquanto essas situações existirem, automação de interface continua tendo utilidade.

IA não cria magicamente uma API onde ela não existe.

Ela pode até ajudar um agente a interpretar uma tela.

Mas isso continua sendo interação com interface, com várias das mesmas fragilidades.

APIs continuam importantes

Quando existe uma API adequada, ela continua sendo uma excelente forma de integração.

Uma arquitetura pode combinar:

LLM
 ↓
Automação
 ↓
API

A IA interpreta.

A automação decide.

A API executa.

Cada componente faz aquilo para o qual é mais adequado.

Esse é, para mim, um cenário muito mais interessante do que tentar transformar tudo em um único “agente inteligente”.

E os agentes?

Agentes representam uma evolução interessante porque permitem que modelos escolham ferramentas e executem sequências de ações.

Mas autonomia também aumenta risco.

Quanto mais liberdade damos ao sistema, mais precisamos pensar em:

• permissões;
• validação;
• limites;
• rastreabilidade;
• custo;
• segurança;
• observabilidade;
• aprovação humana.

Um agente capaz de consultar informações é uma coisa.

Um agente capaz de executar operações irreversíveis em produção é outra.

A arquitetura precisa refletir essa diferença.

Determinístico por fora, probabilístico por dentro

Uma ideia que considero interessante é manter o processo externo o mais previsível possível.

Por exemplo:

1. receber entrada;
2. validar;
3. chamar IA para uma tarefa específica;
4. validar saída;
5. aplicar regra;
6. executar operação;
7. registrar resultado.

A parte probabilística fica delimitada.

Isso ajuda a testar e entender o sistema.

Em vez de:

"IA, resolva o processo."

temos:

"IA, execute esta tarefa específica e retorne neste formato."

É uma diferença arquitetural importante.

IA amplia o que antes era difícil automatizar

Durante muito tempo, algumas tarefas eram caras demais para automatizar porque exigiam interpretação.

Textos.

Documentos variados.

Solicitações humanas.

Conteúdo não estruturado.

Hoje, modelos conseguem participar dessas etapas.

Isso faz com que processos antes parcialmente automatizáveis possam ganhar novas possibilidades.

Mas o restante dos fundamentos continua existindo.

Ainda precisamos pensar em:

• logs;
• retries;
• filas;
• APIs;
• autenticação;
• segurança;
• idempotência;
• monitoramento;
• tratamento de exceções.

IA não remove engenharia.

Em muitos casos, exige ainda mais.

O futuro provavelmente é combinado

Não vejo uma disputa entre:

• RPA;
• APIs;
• IA;
• agentes.

Vejo uma caixa de ferramentas maior.

Um processo pode usar:

OCR → LLM → regra → API → fila → RPA

Outro pode precisar apenas de:

API

Outro:

RPA

E outro:

LLM + revisão humana

A melhor arquitetura depende do problema.

Conclusão

IA não precisa substituir automação para transformar a área.

Ela já amplia o conjunto de problemas que conseguimos atacar.

Principalmente quando entra em pontos onde regras tradicionais têm dificuldade: linguagem natural, documentos, classificação e interpretação.

Mas isso não elimina os fundamentos.

Quando existe regra clara, regra clara continua sendo melhor.

Quando existe API, API continua sendo valiosa.

Quando só existe interface, RPA continua tendo espaço.

E quando existe ambiguidade, IA pode adicionar uma capacidade que antes não tínhamos.

O futuro da automação provavelmente não pertence a uma única tecnologia.

Pertence à capacidade de combinar as ferramentas certas para cada parte do problema.