Agentes de IA para equipes de compras: fornecedores e cotações

Um agente de IA para compras lê o cadastro de fornecedores, compara as cotações recebidas com critérios que a sua equipe já definiu, redige cobranças para informações que faltam e encaminha cada compra para a pessoa autorizada a aprová-la. O agente só é útil na medida em que tem em que se apoiar: um histórico de fornecedores atualizado e com fontes, uma forma consistente de padronizar cotações e regras de aprovação escritas como limites que ele consegue verificar. Equipes que constroem esses três alicerces agora dão a qualquer agente futuro, mais capaz, um lugar seguro para trabalhar.

Principais pontos

• O histórico de fornecedores é a memória que um agente precisa, então comece definindo o que um cadastro completo deve conter e de onde veio cada informação.
• A comparação de cotações só é justa quando todas as propostas são convertidas para os mesmos campos antes de alguém ranquear preços.
• As regras de aprovação devem ser escritas como condições com resultados definidos, e não como orientações que o agente pode interpretar livremente.
• As ferramentas devem começar com permissões de leitura e rascunho, enquanto a execução da compra continua atrás de uma decisão humana explícita.
• O sucesso deve ser medido por um pequeno conjunto de verificações observáveis, revisadas em uma rotina fixa.

O que um agente de compras deve e não deve fazer

O trabalho de compras se divide em três tipos de tarefa: as que leem e organizam informações, as que recomendam uma ação e as que comprometem dinheiro ou alteram dados de um fornecedor. Um agente se adapta bem às duas primeiras. A terceira deve continuar sob decisão humana até que as regras que a cercam tenham sido testadas com casos reais.

Um primeiro papel útil é deliberadamente estreito. O agente recebe cotações de uma caixa de e-mail compartilhada ou de uma pasta de upload, associa cada uma a uma solicitação aberta, verifica os campos obrigatórios, pede ao fornecedor o que estiver faltando e produz uma comparação para o comprador. Emitir pedidos, assinar termos e editar dados mestres de fornecedores podem vir depois, se é que virão.

Um modelo mais capaz melhora o raciocínio sobre documentos confusos, como uma cotação escaneada com redação incomum. Ele não decide quem pode aprovar gastos, quais fornecedores estão homologados ou se um pedido de troca de dados bancários é legítimo. Essas respostas vêm da sua política e dos seus registros, então precisam existir em uma forma que o agente consiga ler e que limite o que ele pode fazer.

Como construir um histórico de fornecedores em que o agente possa confiar

O histórico de fornecedores é a memória da função de compras. Ele registra quem é o fornecedor, o que já entregou, quanto tempo as entregas realmente levaram, quais problemas de qualidade foram resolvidos, quais condições contratuais se aplicam e quem são os contatos de trabalho. Na maioria das empresas, esse histórico está espalhado entre threads de e-mail, uma planilha e a memória de um comprador experiente.

Comece com um modelo de cadastro de fornecedor que tenha campos fixos e uma coluna de fonte. Cada informação importante deve indicar de onde veio e quando alguém confirmou pela última vez. Um agente que busca fatos nesse repositório governado, em vez de adivinhar a partir do seu treinamento geral, consegue mostrar ao comprador o registro por trás de cada afirmação. Manter os fatos sobre fornecedores em um repositório separado do modelo também significa que um dado errado pode ser corrigido na origem, sem retreinar nada.

Marque com clareza os registros desatualizados. Um fornecedor cujo prazo de entrega foi confirmado há muito tempo deve ser sinalizado para revisão, e não tratado como confiável. Em uma primeira versão, uma lista curta de fornecedores homologados por categoria, cada um com um responsável nomeado, vale mais do que um banco de dados grande que ninguém mantém.

Como padronizar cotações para que a comparação seja justa

A maioria das comparações injustas acontece porque duas cotações não descrevem a mesma coisa. Um fornecedor inclui o frete e outro não. Uma proposta vale por uma semana e outra por um trimestre. Uma conta por embalagem e outra por unidade. Antes que qualquer pessoa ou agente ranqueie as cotações, cada uma deve ser convertida para a mesma estrutura.

Uma lista prática de padronização inclui estes campos:

• Razão social do fornecedor, associada ao cadastro na sua lista de fornecedores
• Descrição do item, vinculada ao código interno do produto ou serviço
• Quantidade, unidade de medida e a base de embalagem usada no preço
• Base do preço, indicando se impostos, frete, tributos de importação e taxas estão incluídos ou excluídos
• Moeda e, se a cotação estiver em outra moeda, a data em que a base de câmbio foi definida
• Prazo de entrega contado a partir do pedido confirmado, com a fonte dessa estimativa
• Data de validade da cotação
• Condições de pagamento e de entrega que diferem das suas condições padrão
• Exclusões, regras de pedido mínimo e quaisquer condições ligadas ao preço

Qualquer campo que não possa ser preenchido deve aparecer como ausente, nunca como zero ou como um valor presumido. O agente redige a pergunta ao fornecedor, e o comprador decide se um campo ausente desqualifica a cotação. Mantenha a redação original ao lado dos valores padronizados no resumo da comparação, para que um revisor possa conferir a interpretação. Uma divergência entre o resumo e o documento de origem é exatamente o sinal que você quer que um revisor enxergue.

Como escrever regras de aprovação que uma máquina consegue verificar

Uma regra como «compradores devem usar bom senso em compras maiores» não pode ser cumprida por ninguém, nem por pessoas nem por software. Escreva as regras como condições com um resultado definido, usando limites que a liderança financeira e a de operações estabelecem. Os valores pertencem à sua organização. A estrutura é o que torna essas regras utilizáveis por um agente.

O guia de decisão a seguir é um ponto de partida viável:

• Se a compra está abaixo do limite da sua categoria, o fornecedor está na lista homologada e a cotação passa nas verificações de padronização, o agente pode preparar uma solicitação de compra para que o comprador nomeado a envie.
• Se o fornecedor é novo na lista, o agente encaminha a cotação ao responsável de compras com o checklist de homologação anexado, e não discute condições comerciais.
• Se a compra está acima do limite, o agente prepara a comparação e a solicitação de aprovação, e o aprovador toma a decisão.
• Se a cotação vencer antes de encerrar a janela de aprovação, o agente sinaliza o vencimento e pode pedir ao fornecedor uma prorrogação, sem aceitar novas condições.
• Se um fornecedor pedir alteração de dados bancários ou das informações de remessa, o agente para e encaminha o pedido a uma pessoa que o verifique por meio de um contato já cadastrado.

A última regra é a mais importante. Trocas de dados de pagamento são uma rota comum para desvio de dinheiro, e nenhum agente de software deve ser a única barreira contra esse risco. Nesse caso, o papel do agente é parar e escalar, não decidir.

Documentos de fornecedores também são entradas não confiáveis. Um PDF ou um e-mail pode conter texto que tenta dar instruções ao agente, por exemplo pedindo que ele pule uma verificação ou trate um preço como já aprovado. A orientação da OWASP sobre injeção de prompt explica por que instruções encontradas dentro de dados devem ser tratadas como dados. Na prática, o status de aprovação deve vir do sistema de aprovação, nunca do texto de uma cotação.

Permissões, ferramentas e um cenário ilustrativo

Dê ao agente uma lista curta de ferramentas e somente as permissões que cada uma exige. Uma primeira versão razoável pode ler o repositório de cadastros de fornecedores e a caixa de cotações, escrever rascunhos de notas de comparação e incluir itens em uma fila de solicitações de compra propostas. Ela não deve enviar pedidos nem alterar dados mestres de fornecedores. O acesso deve ser negado por padrão e concedido de forma restrita, que é o princípio central da orientação de autorização da OWASP.

Quando a criação de pedidos for conectada, as novas tentativas precisam de um desenho cuidadoso. Um timeout de rede pode deixar o agente sem saber se um pedido foi feito, e uma nova tentativa cega pode criar uma duplicata. Algumas plataformas de pagamento e comércio documentam chaves de idempotência por esse motivo: cada ação pretendida carrega uma chave única, então uma requisição repetida devolve o resultado original em vez de criar um segundo pedido. Pergunte se a sua plataforma de compras suporta um padrão semelhante antes de conectar um agente a ela.

Exemplo ilustrativo: um comprador recebe quatro cotações para um pedido recorrente de embalagens. Duas chegam como arquivos PDF, uma no corpo de um e-mail e uma em planilha. O agente associa cada cotação à solicitação aberta e preenche o checklist de padronização. Em uma delas, marca como ausentes as condições de frete e a data de validade, e redige uma pergunta para o fornecedor, que o comprador aprova antes do envio. Ele coloca a comparação na fila de aprovação, com um link de origem para cada valor. O comprador aprova a cotação padronizada de menor valor com uma nota curta, e o agente registra essa decisão. O agente não fez o pedido.

Como saber se a configuração está funcionando

Defina o sucesso antes de o agente começar, usando critérios que você consiga observar. Exemplos úteis incluem quantas cotações precisaram de correção humana na revisão semanal, se cada recomendação remete aos registros de origem, se as escalações chegaram à pessoa certa e se o agente permaneceu dentro das suas permissões. Evite metas vagas, como «compras mais rápidas», a menos que você tenha medido a linha de base atual.

Monte um pequeno conjunto de avaliação com cotações passadas cujos resultados já são conhecidos, incluindo casos difíceis com campos ausentes e condições conflitantes. Rode o agente nesse conjunto sempre que suas instruções, ferramentas ou dados mudarem. O NIST AI Risk Management Framework oferece um vocabulário útil para mapear e medir esses riscos, e trata a governança como uma atividade contínua, e não como uma configuração única. Mantenha registros de entradas, fontes e decisões para que um incidente possa ser reconstituído depois. A mesma lógica aparece em agentes para auditoria interna, onde o valor vem de uma trilha que alguém consegue conferir.

A Be Human trata isso como um projeto gerenciado. A primeira etapa define um papel útil, como a entrada de cotações de uma única categoria, junto com a memória e as ferramentas que esse papel precisa, seus limites de aprovação e um critério de sucesso observável. Depois, a Be Human opera a configuração com monitoramento, avaliações recorrentes, manutenção das integrações, revisão de permissões, resposta a incidentes e melhorias controladas, entregues remotamente em inglês ou em português. Se você não sabe qual tarefa de compras deve vir primeiro, o diagnóstico gratuito de IA da Be Human pode ajudar a identificar a primeira tarefa que vale entregar a um agente.

Perguntas frequentes

Precisamos de um modelo mais avançado antes de começar? Não. O trabalho descrito aqui depende de registros, regras e permissões, e é possível construir isso com os modelos disponíveis hoje. Um modelo mais forte adicionado depois deve caber dentro dos mesmos limites, e essa é a principal razão para construir os limites primeiro. Equipes que pulam essa etapa costumam ter de refazer dados e permissões quando trocam de modelo.

O agente pode enviar pedidos de compra aos fornecedores? Em uma primeira versão, não deveria. O agente pode preparar solicitações de compra e comparações, enquanto uma pessoa nomeada envia o pedido depois da aprovação. O envio de pedidos pode ser conectado mais tarde, depois que permissões, comportamento de novas tentativas e registros de auditoria tiverem sido testados em casos reais.

E se um documento de fornecedor contiver um texto que pareça uma instrução para o agente? Trate-o como dado, não como comando. O agente não deve ter nenhuma permissão que um documento possa convencê-lo a usar, e o status de aprovação deve vir apenas do seu sistema de aprovação. Qualquer documento que peça alteração de dados de pagamento deve ser encaminhado a uma pessoa para verificação por um contato conhecido.

Os dados dos nossos fornecedores são desorganizados. Devemos limpá-los antes? Você não precisa limpar tudo antes de começar. Comece com uma categoria de produtos e os fornecedores que a atendem, marque cada fato com sua fonte e data, e sinalize o que estiver desatualizado. O subconjunto limpo se torna a memória de trabalho do primeiro papel, e você pode ampliá-lo quando as comparações estiverem confiáveis.

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