Agentes de IA para compras: memória de fornecedores e limites

Agentes de IA para compras são funções de software que leem registros de fornecedores, contratos e gastos, preparam o trabalho de rotina em torno deles e pedem a uma pessoa que aprove tudo o que compromete dinheiro ou altera condições. Eles ganham valor à medida que os modelos melhoram, mas só quando a memória de fornecedores, os dados de contratos e os limites de aprovação ao redor deles estão em ordem. Um modelo mais forte precisa de material melhor e de fronteiras mais claras, não de menos delas.

Principais pontos

• Um agente de compras cuida do trabalho de rotina com fornecedores e gastos: cobrança de cotações, acompanhamento, conferência de notas e pedidos, e resumos de status. As pessoas mantêm as decisões que comprometem dinheiro ou mudam condições.
• A memória de fornecedores é o ativo que se acumula. Um registro mantido de contatos, prazos reais de entrega, problemas anteriores e exceções acordadas torna útil qualquer modelo futuro.
• Os dados de contrato devem ser lidos na fonte, com referência à cláusula, para que o agente diga o que foi acordado e admita o que está faltando.
• Os limites de aprovação devem ser explícitos, aplicados por meio de permissões e ligados à função. Só amplie esses limites quando os logs e as avaliações justificarem.
• Comece por uma categoria ou um fluxo, defina um critério de sucesso observável e revise os resultados antes de expandir.

O que um agente de compras faz no dia a dia?

A maior parte do trabalho de compras não é negociação. É o trabalho de ligação ao redor dela: cobrar uma cotação que não chegou, conferir se a nota fiscal bate com o pedido de compra, descobrir qual fornecedor concordou com quais condições de entrega e explicar ao solicitante por que um pedido está parado. É aí que o agente ajuda primeiro, porque o trabalho é repetitivo, cheio de documentos e fácil de esquecer quando a semana aperta.

Um agente útil tem uma função definida, por exemplo acompanhamento de fornecedores e conferência de gastos de uma categoria. Dentro dessa função, ele pode:

• redigir e enviar pedidos de cotação a partir de modelos aprovados
• cobrar confirmações atrasadas e registrar o que o fornecedor respondeu
• comparar as cotações recebidas com o pedido original e apontar lacunas
• conferir notas e pedidos com as condições do contrato e sinalizar diferenças
• preparar um resumo semanal de compromissos em aberto, itens atrasados e riscos

O que ele não faz por padrão é assinar, aceitar condições, cadastrar um fornecedor ou alterar dados de pagamento. Isso fica com pessoas nomeadas. Se a sua primeira dor são cotações e cobrança de fornecedores, o artigo Agentes de IA para compras: cotações e acompanhamento de fornecedores trata desse fluxo com mais detalhe.

Por que a memória de fornecedores importa mais do que o próximo modelo?

Um modelo novo melhora o raciocínio, a escrita e o uso de ferramentas. Ele não sabe que o seu fornecedor de embalagens só atende por telefone às segundas, que determinado contato saiu da empresa na primavera passada, ou que um atraso na safra anterior foi resolvido com um crédito e não com multa. Alguém precisa registrar isso, e o agente precisa conseguir encontrar a informação na hora do trabalho.

Isso é mais um problema de recuperação de informação do que de treinamento. O agente lê os registros relevantes do fornecedor quando precisa, em vez de carregá-los dentro do modelo. A AWS publica uma comparação útil entre recuperação (RAG) e fine-tuning, e, para fatos da empresa que mudam com frequência, a recuperação costuma ser a melhor escolha, porque o registro pode ser corrigido em um único lugar. Isso também significa que a memória pertence à sua empresa e sobrevive à troca de modelo. Quando um modelo melhor chega, ele lê os mesmos registros com mais critério.

Um registro de fornecedor que vale a pena manter contém:

• os contatos certos, suas funções e o canal em que cada um realmente responde
• prazos de entrega como são vividos na prática, e não só como foram cotados
• problemas anteriores, como foram resolvidos e quem aprovou a solução
• exceções e acordos paralelos, com data e quem os aprovou
• a referência do contrato e a categoria para a qual o fornecedor está homologado
• idioma e preferências de comunicação

Duas regras mantêm essa memória confiável. Toda entrada carrega uma fonte (um e-mail, uma nota de ligação, uma cláusula de contrato) e um responsável que pode corrigi-la. E, quando duas entradas entram em conflito, o agente aponta o conflito a uma pessoa em vez de escolher uma delas em silêncio. Memória desatualizada é pior do que nenhuma memória, porque soa confiante.

Como os dados de contrato mantêm o agente preciso?

Um agente deve ler o contrato, não lembrar dele. Isso significa manter o documento original junto com um pequeno conjunto de campos estruturados extraídos dele, cada um apontando para a cláusula de origem. Campos úteis incluem referência e validade de preço, condições de entrega, condições de pagamento, data de renovação, prazo de aviso, penalidades por atraso e se o fornecedor está homologado para a categoria.

Quando o agente responde a uma pergunta sobre condições, ele deve citar a cláusula. Quando um campo está faltando ou o documento é ambíguo, ele deve dizer isso e encaminhar a dúvida ao responsável pelo contrato. Um agente que admite uma lacuna é mais útil do que um que a preenche com um palpite plausível.

Os dados de gastos completam o quadro. Pedidos de compra, recebimentos e notas fiscais permitem que o agente perceba quando o que foi pedido, entregue e cobrado não corresponde ao que foi acordado. Essa conferência é simples de descrever e cansativa de fazer com consistência, e é justamente por isso que ela combina com um agente. Equipes que compram em outros países vão reconhecer o mesmo padrão em Agentes de IA para empresas de comércio exterior: documentos e status.

Uma ressalva importante: e-mails de fornecedores e anexos são entrada não confiável. Uma mensagem que pede para atualizar a conta bancária ou para ignorar instruções anteriores é um dado a ser reportado, não uma instrução a ser seguida. As orientações da OWASP sobre prevenção de prompt injection são uma boa referência para projetar contra isso, e esse é um dos motivos pelos quais a alteração de dados de pagamento nunca deve estar dentro da autoridade do próprio agente.

Onde os limites de aprovação devem ficar?

Os limites de aprovação são o que permite dar trabalho real a um agente sem perder o controle. Eles devem estar escritos, ser aplicados pelas permissões que o agente de fato possui e estar ligados à função, e não deixados ao julgamento do agente. As orientações de autorização da OWASP descrevem os princípios: conceder o menor acesso que cumpre a tarefa, negar por padrão e verificar permissões em cada requisição.

Um guia de decisão simples para uma função de compras:

• Ler registros, resumir e comparar: o agente age livremente, e as ações ficam registradas em log.
• Redigir mensagens e pedidos de cotação a partir de modelos aprovados: o agente prepara e só envia dentro do fornecedor e da categoria que lhe foram atribuídos.
• Qualquer coisa que aceite condições, comprometa gasto, cadastre um fornecedor novo ou altere um existente: uma pessoa nomeada aprova antes de qualquer ação.
• Mudanças em dados bancários ou de pagamento: uma pessoa verifica por um canal já cadastrado, sempre, independentemente de como o pedido chegou.
• Qualquer coisa fora da função ou fora dos dados que o agente enxerga: o agente para e repassa com uma explicação curta.

É aqui também que o argumento dos modelos que melhoram fica prático. À medida que os modelos evoluem, o agente acertará mais casos, e a tentação será afrouxar os limites. Faça isso com base em evidência, não em impressão. Revise as ações registradas e os resultados das avaliações recorrentes, depois amplie um limite por vez, para uma categoria, mantendo a possibilidade de voltar atrás. O limite se move porque o registro sustenta a mudança.

Como isso funciona na prática?

Este é um cenário ilustrativo, não um caso real. Uma indústria compra embalagens de vários fornecedores. Um deles confirma uma data de entrega posterior à permitida pelo contrato.

O agente percebe a divergência entre a confirmação e as condições de entrega. Ele busca o registro do fornecedor, que indica que esse fornecedor já atrasou antes e que um atraso anterior foi resolvido por acordo com um comprador identificado. Ele encontra a cláusula de entrega e a penalidade acordada, e identifica um segundo fornecedor homologado para a mesma categoria.

Em seguida, prepara um pacote curto para o comprador: a confirmação, a cláusula, o histórico, um rascunho de resposta ao fornecedor citando o contrato e um pedido de cotação opcional ao fornecedor alternativo. Ele não envia a resposta nem faz nenhum pedido. O comprador edita o rascunho, aprova, e o agente envia e registra o resultado no cadastro do fornecedor.

Agora imagine que um modelo mais forte seja adotado depois. O fluxo, os registros e os limites continuam iguais. O que melhora é a qualidade do rascunho, a forma como o agente pesa as alternativas e a capacidade de perceber uma divergência sutil. Esse é o padrão a buscar: o modelo melhora, e a estrutura ao redor permite aproveitar essa melhora com segurança. Para a mesma ideia aplicada a entregas e atrasos, veja Agentes de IA para empresas de logística: exceções e avisos. Para equipes de planejamento que vivem de anotações sobre fornecedores, o artigo IA para equipe de planejamento da cadeia de suprimentos: alertas e notas de fornecedores segue a mesma lógica.

Como começar, e como a operação gerenciada ajuda?

Um primeiro projeto deve ser pequeno o bastante para ser concluído e específico o bastante para ser avaliado. Um plano viável:

• Escolha uma função, como o acompanhamento de fornecedores de uma categoria, e escreva o que ela cobre e o que ela nunca faz.
• Defina um critério de sucesso observável, por exemplo que toda confirmação atrasada seja sinalizada e respondida no mesmo dia, com a cláusula do contrato anexada.
• Reúna as fontes: os contratos, a lista de contatos de fornecedores, registros recentes de pedidos e notas, e as conversas de e-mail em que os compradores já confiam.
• Monte os registros de fornecedores com fontes e responsáveis, e extraia os campos dos contratos com referência às cláusulas.
• Defina os limites de aprovação e conecte apenas as ferramentas e permissões de que a função precisa.
• Rode primeiro em modo de revisão, em que uma pessoa aprova cada ação de saída, e compare o trabalho do agente com o que um comprador teria feito.
• Revise os logs em um ritmo regular, corrija a memória e amplie um limite por vez.

A Be Human projeta, implementa e opera esse tipo de estrutura para empresas. Um primeiro projeto define a função, a memória e as ferramentas de que ela precisa, as fronteiras de aprovação e o critério de sucesso. A operação gerenciada pode então incluir monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões, resposta a incidentes e melhorias controladas, como a migração para um modelo mais novo depois de testado com os seus próprios casos. O agente mantém identidade, memória, canais e permissões sob controle humano o tempo todo.

Se você quer descobrir qual é a primeira tarefa que vale a pena entregar a um agente, faça o diagnóstico de IA gratuito da Be Human.

Perguntas frequentes

Um agente de IA vai substituir nossos compradores? Não. O agente assume o acompanhamento, a conferência e a preparação que consomem o tempo dos compradores, enquanto as pessoas mantêm o relacionamento com fornecedores, a negociação e toda decisão que compromete a empresa. O objetivo é que os compradores dediquem mais da semana ao julgamento e menos à cobrança.

De quais dados um agente de compras precisa para ser útil? No mínimo, dos contratos, de uma lista de fornecedores mantida com os contatos e dos pedidos de compra e notas recentes. A memória de fornecedores, como problemas passados e exceções acordadas, é o que agrega mais valor ao longo do tempo. Os dados não precisam estar perfeitos no início, mas cada registro deve ter uma fonte e um responsável.

Como evitamos que o agente cometa um erro caro? Limite o que ele pode fazer, e não apenas o que deveria fazer. Dê a ele acesso de leitura e direito de redigir primeiro, exija um aprovador nomeado para tudo o que compromete dinheiro ou muda condições e registre cada ação em log. Rode em modo de revisão antes de deixá-lo enviar qualquer coisa por conta própria.

Precisamos trocar de agente quando sai um modelo melhor? Não, se a memória, os dados de contrato e os limites de aprovação ficam fora do modelo. Um modelo novo pode ser testado com os seus próprios casos registrados e colocado no lugar quando tiver desempenho melhor, enquanto os registros e as fronteiras permanecem exatamente como estavam.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.