Compras no piloto automático: como automação de compras com IA vira sistema de agentes

Compras é uma das operações mais repetitivas de qualquer empresa industrial: cotação, aprovação, lançamento no ERP, conferência de nota. Cada pedido segue o mesmo rito. E é exatamente por isso que ela concentra tanto desperdício de tempo humano qualificado, e tanto espaço para automação de compras com IA que realmente funcione em produção. A questão não é se os agentes conseguem executar o fluxo. A questão é se o sistema foi construído para sobreviver à segunda-feira de uma operação real.

O ritual invisível de cada pedido

Antes de qualquer pedido ser lançado no ERP, existe um caminho que a maioria dos executivos nunca viu de perto. O comprador recebe a solicitação, verifica o histórico do fornecedor, confere se há contrato vigente, abre a nota fiscal ou o pedido do fornecedor, preenche os campos no sistema, confere os valores e, só então, salva. Se der erro, volta. Se o sistema travar, começa de novo. Em empresas com volume alto, esse processo acontece dezenas de vezes por dia, por comprador. O tempo acumulado não aparece em nenhum relatório, mas está lá: embutido no custo de cada pedido processado.

O problema não é que as pessoas façam isso mal. O problema é que elas fazem isso bem, e poderiam estar fazendo outra coisa: negociação, análise de mercado, homologação de fornecedores, revisão de contratos. O trabalho que exige julgamento. O que não exige julgamento fica preso na rotina, e a rotina consome capacidade produtiva de quem deveria estar resolvendo problemas maiores.

Quando agentes entram na linha de montagem

A lógica de um sistema multi-agente aplicado a compras é direta: cada etapa do fluxo vira responsabilidade de um agente especializado. Um lê a nota fiscal ou o pedido recebido. Outro busca o histórico do fornecedor e verifica se os dados batem com o cadastro. Um terceiro preenche os campos do pedido no sistema, seguindo as regras de lançamento da empresa. Um quarto confere os valores contra a política de compras vigente. No final, um agente de orquestração monta o resumo e apresenta ao comprador: 'isso está pronto para gravar, confirma?'

O comprador não desaparece do fluxo. Ele migra de executor de cada micro-etapa para validador final, o que significa ganho de julgamento e perda de rotina. Ele vê o que os agentes prepararam, confere o que precisa conferir, e decide se grava ou devolve para revisão. Esse design preserva a cadeia de responsabilidade enquanto elimina o trabalho mecânico de preparar o lançamento.

O caso que virou referência interna

Em uma operação de mineração que acompanhamos sob contrato de confidencialidade, o fluxo de compras operava com um tempo médio de trinta minutos por pedido. Esse tempo incluía a abertura da nota, a busca no ERP, o preenchimento dos campos, a conferência e o lançamento. Nada extraordinário para o setor. Era simplesmente o padrão aceito como natural.

Depois de implantar o sistema de agentes integrado ao Protheus, esse tempo caiu para cinco minutos por pedido. O comprador passou a confirmar o lançamento em vez de executá-lo. O volume que a equipe conseguia processar subiu seis vezes sem aumento de headcount. E o índice de erros de lançamento no ERP chegou a zero no período monitorado.

Vale detalhar o que significa zero erros no ERP para quem já viveu uma conciliação de fim de mês num ambiente industrial. Cada erro de lançamento gera um ciclo de correção: quem errou, como corrigir, o que reprocessar, o que comunicar para as áreas afetadas. Em volume alto, esses ciclos consomem um tempo desproporcional. Eliminá-los não é só eficiência operacional. É uma redução real de custo, de risco e de desgaste entre as equipes.

Em vez de automatizar para substituir o comprador, construímos para liberar o comprador. A diferença está em quem confirma antes de gravar.

A integração com o ERP não é detalhe técnico

Falar em automação de compras com IA sem falar em integração com o ERP é falar de metade do problema. O lançamento no sistema é o momento de verdade. É onde os dados precisam estar corretos, na sequência certa, no formato que o ERP aceita. Sistemas como o Protheus têm suas regras de campo, suas validações internas, seus fluxos de aprovação configurados ao longo de anos de operação. Um agente que não entende essas regras vai criar mais problemas do que resolve.

A integração que construímos para o caso da mineração não foi feita por conector genérico. Foi mapeada campo a campo, regra a regra, com os analistas que conhecem o sistema por dentro. Esse trabalho de mapeamento é invisível para quem vê o resultado final, mas é o que garante que o lançamento automatizado seja um lançamento confiável. A nossa infraestrutura própria de agentes foi projetada especificamente para esse tipo de integração com sistemas legados de ERP, onde a margem para erro de campo é zero.

Por que a maioria dos pilotos não chega à produção

Consultorias como McKinsey e Deloitte já documentaram que a maioria dos projetos de IA corporativos não passa da fase piloto. Os motivos variam, mas há um padrão recorrente: o piloto foi construído para impressionar em demonstração, e demonstração é um ambiente controlado. Dados organizados, fluxo limpo, caso representativo. O agente executa as etapas. Funciona. Na demonstração.

Operar em produção é diferente. Os dados chegam sujos. Os fornecedores mudam o formato da nota sem avisar. O ERP vai a janela de manutenção no meio do turno. O comprador tem uma exceção que o fluxo padrão não cobre. Um sistema que não foi construído para lidar com variação vai quebrar. E quando quebra em produção, a desconfiança é difícil de recuperar.

O que diferencia um sistema que sobrevive à produção é a camada de tratamento de exceção. Não só 'o que fazer quando funciona', mas 'o que fazer quando não funciona'. Quando o agente não consegue casar a nota com o cadastro do fornecedor, o que acontece? Ele alerta o comprador com contexto suficiente para que a decisão seja rápida. Não tranca o fluxo. Não silencia o erro. Escala com clareza para quem tem autoridade para resolver.

Humano no loop como princípio de design, não como concessão

Existe uma tensão falsa que aparece toda vez que se fala em automação: a ideia de que automatizar é tirar o humano da cadeia. Em operações críticas, como compras em indústrias com volumes altos e contratos complexos, essa ideia é perigosa. A responsabilidade pela decisão precisa continuar com quem tem autoridade para tomá-la. Os agentes preparam. O humano decide. Essa distinção não é fraqueza do sistema; é a arquitetura correta.

O design de humano no loop com intenção significa que o comprador aparece no fluxo no momento certo: depois que o trabalho mecânico foi feito, antes que o dado seja gravado no sistema. Ele vê o resumo preparado pelos agentes. Confere o que precisa conferir. Grava ou devolve. O que ele não faz mais é abrir nota, copiar campo, preencher formulário, conferir valor manual. Esse tempo voltou para ele como capacidade de pensar.

O que é necessário para escalar esse modelo

O caso da mineração não é um caso isolado. É um modelo replicável. Mas replicar não é copiar: cada operação tem seu ERP, seu fluxo de aprovação, suas exceções próprias, seus campos obrigatórios, suas regras de alçada. O que se replica é a arquitetura: agente de leitura, agente de verificação, agente de lançamento, agente de conferência, orquestrador, interface de confirmação para o comprador.

O que muda de empresa para empresa é o mapeamento. Quais campos. Quais regras. Quais exceções. Quais integrações. Esse mapeamento leva tempo e precisa ser feito com os analistas que operam o sistema dia a dia. Não existe atalho aqui. O atalho é exatamente o que faz o piloto não chegar à produção, porque o atalho sempre pula as exceções, e as exceções são onde o sistema real vive.

Quando o mapeamento é feito com rigor, o resultado aparece em semanas. Trinta para cinco minutos por pedido. Seis vezes a capacidade da mesma equipe. Zero erros no ERP. Esses números não são projeção nem promessa de consultoria. São o que acontece quando a automação de compras com IA é construída para operar de verdade, em produção, com os dados reais, nas condições reais de uma operação industrial que não para.

A pergunta não é 'a IA consegue fazer isso?'. A pergunta é 'esse sistema foi construído para sobreviver à segunda-feira de uma operação real?'. São perguntas muito diferentes, e só a segunda importa.

Quer ler a sua operação a fundo?