Comitê de automação reunido pra decidir o portfolio de processos do próximo ciclo. Conciliação bancária, triagem de e-mail jurídico, importação de NF-e, classificação de chamado de suporte, follow-up de cobrança. Cada um aparece com um adesivo colado: "isso é caso de RPA", "isso aqui já é IA". Quem colou os adesivos foi o último fornecedor que apresentou. E os adesivos estão metade certos.
A pergunta real que precisa ser respondida não é "RPA ou IA". É: dado este processo específico, com este tipo de input, esta tolerância a erro e esta frequência de mudança no sistema-alvo, qual abordagem técnica entrega o melhor custo total ao longo de três anos? Essa pergunta tem framework de decisão objetivo — não é gosto, e não é adesivo de fornecedor.
Principais pontos
- RPA tradicional ainda é a melhor escolha quando o processo é estável, o input é estruturado e a auditabilidade exigida é por regra explícita.
- Agente de IA com tools ganha quando o input varia, exige leitura de texto/documento ou classificação de intenção que regra não cobre.
- Quatro dimensões guiam a decisão: variabilidade do input, necessidade de raciocínio sobre conteúdo, criticidade do erro e frequência de mudança no sistema-alvo.
- Híbrido é o cenário mais comum em 2026 — o mesmo processo combina RPA na execução determinística e agente no parsing/decisão.
- MCP (Model Context Protocol) emerge como padrão de integração entre agentes LLM e tools/sistemas internos no ecossistema corporativo.
- Aprovação humana em ponto crítico é parte do desenho do agente, não detalhe operacional a resolver depois.
Pra empresas avaliando parceiro técnico pra construir esse tipo de automação, a pergunta não é "qual stack". É "esse parceiro entende quando uma decisão técnica é determinística e quando ela exige raciocínio sobre contexto?". É exatamente nesse tipo de avaliação que parceiros como a Vertis Tech entram em consideração.
O cenário atual de automação interna
O discurso público sobre automação corporativa amadureceu. Quem trabalha no espaço hoje raramente coloca RPA tradicional e agente de IA como concorrentes — coloca como camadas que se completam. RPA executa, agente raciocina. Não é frase de marketing: é como as arquiteturas estão sendo desenhadas em organizações que já ultrapassaram a fase de prova de conceito e estão escalando para mais processos.
Pesquisas recentes com executivos seniores de TI apontam intenção majoritária de expandir o uso de agentes de IA em 2026 — não como substituto do RPA existente, mas como camada nova sobre processos que o RPA não conseguia tocar. Processos que misturam dado estruturado com texto livre, exceção que regra não cobre, decisão que precisa de contexto além do que cabe em um if/else pré-escrito.
O ponto que esse discurso costuma esconder: a decisão entre as duas abordagens não é abstrata. Ela é processo a processo. E quem decide errado paga em duas frentes — ou implanta agente em processo que regra resolveria por uma fração do custo, ou força RPA em processo cheio de variabilidade e fica refatorando bot toda semana.
As duas abordagens explicadas sem hype
Como o RPA tradicional opera
RPA é roteiro determinístico. Um bot abre o sistema, clica em campos pré-mapeados, lê valores de posições conhecidas, escreve em outras posições, fecha. Internamente pode usar API quando disponível ou pode "ler" a tela via OCR e seletores quando não há API. O fluxo é o mesmo, sempre — entrada A produz saída B, sem desvio.
O ponto forte é previsibilidade e auditoria. O bot faz exatamente o que está escrito que ele faz. Falhou? Loga falha, dispara alerta, para. Não há "ele interpretou diferente dessa vez". O log é determinístico, a auditoria casa transação por transação, e o custo por execução costuma ser baixo porque não envolve chamada a modelo de IA a cada passo.
O ponto fraco é fragilidade. Se a tela muda, o seletor quebra. Se o input chega num formato levemente diferente do esperado, o bot rejeita ou processa errado. Se o processo tem dezenas de caminhos possíveis e a regra não consegue descrever todos, o RPA precisa de uma ramificação pra cada — e a complexidade do código explode.
Como o agente de IA com tools opera
Agente é um modelo de linguagem com acesso a um conjunto de ferramentas reais (functions). O modelo recebe a instrução, lê o contexto (e-mail, documento, mensagem, estado do sistema), decide qual ferramenta chamar com quais argumentos, recebe o resultado, decide o próximo passo. Pode chamar várias ferramentas em sequência. Pode escalar pra humano quando o nível de confiança cai. Pode resumir tudo no fim e gravar trilha completa do raciocínio.
As ferramentas podem ser literalmente qualquer função do seu sistema: "consultar pedido pelo número", "criar chamado no service desk", "agendar reunião no Google Calendar", "extrair dados desta NF-e PDF", "enviar mensagem pelo WhatsApp". A integração entre o LLM e essas ferramentas usa hoje cada vez mais o padrão MCP (Model Context Protocol) — uma forma padronizada de declarar tools pro modelo, com tração crescente no ecossistema de agentes corporativos.
O ponto forte é flexibilidade. O agente lida bem com input que varia, lê texto livre, classifica intenção, monta resposta contextual, escolhe entre caminhos sem precisar de if/else pré-escrito pra cada um. Em processo onde a entrada nunca é exatamente igual à anterior, o agente tende a se sair muito melhor que o bot.
O ponto fraco é probabilístico. O modelo decide com base em padrão estatístico, não em regra travada. Em processo regulado ou de alto valor, isso exige camada extra de governança — testes, monitoramento, aprovação humana em ponto crítico, auditoria de cada decisão. Não é razão pra não usar — é razão pra desenhar o agente com trilhos, não solto.
As quatro dimensões de decisão
Variabilidade do input
Pergunte do processo: o que entra hoje muda quanto?
- Entra sempre o mesmo CSV, com as mesmas colunas, no mesmo formato? RPA ganha. Roteiro determinístico, custo por transação trivial, auditoria limpa.
- Entra e-mail livre escrito por humano, com pedido em linguagem natural, anexo que pode ser PDF ou imagem? Agente ganha. Tentar regra aqui vira labirinto de exceções.
- Entra dado estruturado mas que vem de vários sistemas diferentes, cada um com leve variação no schema? Híbrido. Agente normaliza e classifica; RPA executa a ação determinística depois.
Como regra prática, quanto mais perto da fonte humana o input está (digitado, escrito, fotografado), mais o agente brilha. Quanto mais perto da fonte de máquina (relatório, exportação, integração padronizada), mais o RPA brilha.
Necessidade de raciocínio sobre texto ou documento
Pergunte: o processo exige ler conteúdo e tomar decisão a partir do que está escrito?
- "Leia este e-mail e responda apropriadamente conforme política da empresa": agente.
- "Leia este contrato e identifique cláusulas de rescisão e prazo": agente, com cuidado redobrado — jurídico é área YMYL e exige revisão humana antes da decisão sair pro mundo.
- "Receba este XML de NF-e, valide schema, grave no ERP": RPA.
- "Receba este PDF de boleto, extraia código de barras e agende pagamento": agente pra extrair (Vision/OCR), RPA pra executar o pagamento no internet banking.
Raciocínio sobre conteúdo é onde o LLM compete bem. Execução de ação determinística depois da decisão é onde o RPA continua eficiente.
Criticidade do erro e auditabilidade exigida
Pergunte: se essa automação errar uma vez, qual o custo?
- Erro de classificação de e-mail pra triagem interna: baixo. Agente decidindo sozinho, com humano revisando casos de baixa confiança, costuma funcionar bem.
- Erro em baixa de boleto, lançamento contábil, transferência financeira ou decisão de crédito: alto. Aqui o desenho precisa de aprovação humana no ponto crítico e auditoria append-only. Não significa "não usa agente" — significa "agente prepara, humano confirma, sistema registra quem confirmou e quando".
- Erro em processo regulado (LGPD, fiscal, trabalhista, saúde): muito alto. Aqui o agente entra no fluxo, mas com trilhos: cada decisão registrada com prompt, resposta, modelo usado, versão, timestamp. A auditoria precisa reconstruir a decisão depois.
O padrão que tende a funcionar bem em processo crítico é: agente decide, humano valida em ponto sensível, sistema registra. RPA puro também funciona aqui — mas só se o processo for determinístico o suficiente pra caber em regra explícita sem deixar exceções pra fora.
Frequência de mudança no sistema-alvo
Pergunte: com que frequência o sistema onde a automação opera muda?
- ERP estável, contrato de uso interno, sem atualização externa: RPA dura anos sem manutenção pesada. Custo de operação cai conforme o tempo passa.
- SaaS externo (banco, marketplace, portal governamental) que atualiza UI sem aviso: RPA tende a quebrar. Time gasta semanas mantendo seletor. Agente com tools que falam com a API quando ela existe se mantém mais estável. Agente que precisa "ver" a tela (Vision) se adapta melhor a mudança visual que seletor travado em XPath.
- Sistema legado sem API, com tela estável há anos: RPA é a escolha óbvia.
Mudança frequente no alvo deteriora RPA. Agente com tools de Vision ou agente que usa API direta degrada menos com o tempo.
Onde combinar as duas abordagens no mesmo processo
O cenário mais comum em automação interna que escala bem em 2026 não é "tudo RPA" nem "tudo agente". É camada:
- Agente faz parsing e classificação no topo — recebe input variável (e-mail, documento, mensagem), entende intenção, extrai dado estruturado.
- RPA executa ação determinística embaixo — pega o dado já estruturado e faz o lançamento, a integração, o registro, o cálculo.
- Humano aprova em ponto sensível — quando o agente sinaliza baixa confiança ou quando a regra de negócio exige aprovação por valor, tipo ou contraparte.
- Sistema registra tudo — append-only, com referência cruzada entre decisão do agente, ação do RPA e aprovação humana.
Esse desenho aproveita o que cada camada faz melhor. O agente não fica preso a regra explícita pra cada exceção. O RPA não precisa interpretar texto livre. O humano só é convocado quando faz diferença real. E a auditoria reconstrói o processo de ponta a ponta, sem caixa-preta no meio.
O que a governança de agente exige a mais que RPA
Um ponto que não pode ficar enterrado: agente exige governança que RPA não exigia. Quem implanta agente sem isso paga depois — em incidente, retrabalho, ou perda de confiança da equipe de negócio que opera junto.
O que entra na conta:
- Versionamento de prompt e modelo: cada decisão precisa registrar qual prompt foi usado, qual modelo, qual versão. Senão não há como reconstruir o porquê de uma decisão histórica meses depois.
- Testes de regressão semântica: quando o prompt muda, suíte de casos representativos roda pra garantir que o comportamento esperado se mantém. RPA tinha teste de fluxo; agente precisa de teste de comportamento sobre exemplos reais.
- Monitoramento de drift: o modelo evolui (o provider atualiza), o mundo muda (o input típico se desloca). Monitorar taxa de aprovação humana, taxa de exceção e latência média ajuda a detectar regressão antes do usuário reclamar.
- Ponto de escala pra humano explícito: quando o agente não tem confiança, ele não chuta — para e pede. Esse ponto precisa estar desenhado, não improvisado em runtime.
- Trilha de auditoria conectando agente, tools e humano: pra processo regulado, a trilha precisa mostrar não só "o que foi feito" mas "quem decidiu fazer, com base em quê, e quem aprovou".
Esse é o custo de admissão de IA no fluxo crítico. O time que ignora paga em incidente futuro. O time que internaliza desde o desenho entrega agente que escala — e que sobrevive à primeira auditoria séria.
Como a Vertis Tech ajuda em automação de processos com IA
A Vertis Tech é fábrica de software brasileira focada em CRM, automação e IA aplicada. Cada projeto de automação interna é dimensionado conforme variabilidade do input, criticidade do processo, tipo de sistemas-alvo envolvidos, exigências regulatórias e maturidade operacional do cliente. A depender do escopo, a implantação pode contemplar:
- Discovery técnico por processo, mapeando dimensão a dimensão (variabilidade, criticidade, frequência de mudança) antes de cravar abordagem RPA, agente ou híbrido.
- Agentes com tools reais via Claude Agent SDK + MCP, com cada ferramenta declarada explicitamente, argumentos validados em código e nenhuma "alucinação de função" possível no runtime.
- Aprovação humana em ponto sensível quando o processo exige — desenhada no fluxo, com fila auditada, não bolada no final como mitigação tardia.
- Processamento assíncrono em filas (padrão de execução robusto pra evitar travamento de UI, perda de evento e estado inconsistente em automação corporativa).
- Auditoria append-only conectando agente, tools e humano, com versionamento de prompt, modelo e decisão pra reconstruir qualquer caso histórico.
- Integração com sistemas legados sem reescrita, usando APIs onde existem e fallback controlado quando o único caminho disponível é tela.
- Governança LGPD desenhada desde o primeiro diagrama, com definição contratual de papéis (controlador, operador, subprocessadores) e rastreabilidade de acesso a dado pessoal em cada decisão automatizada.
Perguntas frequentes
Quando RPA tradicional ainda é a melhor opção em 2026?
Quando o processo é estável, o input é estruturado e padronizado, o sistema-alvo não muda com frequência e a auditoria exigida cabe em regra explícita. Conciliação entre planilha e ERP estável, geração de relatório mensal a partir de dado tabular, transferência de arquivo entre sistemas internos — RPA continua tendo o melhor custo total nesse perfil.
O agente de IA com tools precisa de RAG sempre?
Não. RAG entra quando o agente precisa responder com base em conteúdo proprietário (documentação interna, política da empresa, histórico do cliente). Pra agente que só precisa raciocinar sobre o input atual e chamar tools, RAG é opcional. Misturar os dois sem necessidade real aumenta complexidade e custo de operação.
Quanto de governança a mais um agente exige em relação a RPA?
Como referência inicial: planeje versionamento de prompt/modelo, suíte de testes de regressão semântica, monitoramento de drift, ponto de escala pra humano e trilha de auditoria conectada. Em processo crítico, a camada de governança costuma representar parte relevante do esforço total de implantação — e é o que separa agente em produção de demo bonita em apresentação comercial.
Dá pra começar híbrido ou tem que escolher uma abordagem antes?
Dá. O padrão recomendado é justamente híbrido — agente no parsing/decisão, RPA na execução determinística, humano em ponto sensível. O importante é mapear cada processo nas quatro dimensões antes, pra desenhar as camadas certas em vez de forçar tudo num lado só por inércia de fornecedor.
Faz sentido usar MCP em projeto interno pequeno?
Faz, especialmente se houver expectativa de adicionar tools com o tempo. MCP padroniza como o agente descobre e usa ferramentas — começar com esse padrão evita refactor doloroso quando o agente cresce e novos sistemas precisam ser plugados. Em projeto realmente pontual, function calling direto do provider também resolve sem perda relevante.
A escolha entre RPA tradicional e agente de IA com tools deixou de ser religiosa. Os times que estão tirando mais valor de automação em 2026 não escolheram um lado — escolheram uma forma rigorosa de avaliar cada processo nas dimensões certas e desenharam arquiteturas onde cada camada faz o que faz melhor. RPA continua imbatível em processo determinístico de alto volume. Agente com tools desbloqueia processo que regra nunca alcançou. Híbrido é o lugar onde a maior parte dos processos internos vai morar nos próximos anos.
A pergunta que vale fazer no comitê não é "RPA ou IA". É "este processo, neste ano, com este sistema-alvo, com esta tolerância a erro, pede qual desenho?". E o desenho precisa caber em quatro dimensões objetivas, não em adesivo colado por fornecedor.
