Agente de IA para compras: comparar cotações e pedir aprovação

Um agente de IA para compras recebe o pedido de cotação, consulta os fornecedores aprovados, organiza as propostas em uma base de comparação comum e registra cada interação no histórico. Quando o valor ou o risco da compra ultrapassa o limite definido pela empresa, o agente para e encaminha a decisão a uma pessoa identificada. O ganho está na padronização e na rastreabilidade, não em um sistema que escolhe fornecedor sozinho.

Principais pontos

• O agente organiza as cotações, mas o cálculo do custo total e as regras de aprovação ficam em código e em políticas escritas, não apenas no texto de um prompt.
• Cada proposta é convertida para os mesmos campos antes da comparação: preço unitário, frete, prazo, condição de pagamento, garantia e se os impostos estão incluídos.
• O histórico por fornecedor registra cotações, divergências, atrasos e decisões, o que dá à equipe dados concretos para as próximas negociações.
• Acima dos limites definidos pela diretoria, o fluxo pede aprovação humana com um resumo da comparação e as alternativas consideradas.
• A forma mais segura de começar é um piloto com uma categoria de compra, logs ativos e uma métrica de sucesso combinada antes da primeira execução.

Como o agente compara propostas sem perder critério

Comparar cotações parece simples até chegar a primeira planilha. Um fornecedor informa preço sem frete, outro cobra embalagem à parte, um terceiro tem prazo menor, mas exige pagamento antecipado. Antes de qualquer análise, o processo precisa de um modelo de dados único, com os campos que importam para a decisão de compra.

O agente pode extrair esses campos de PDFs, e-mails e mensagens de WhatsApp, o que reduz o trabalho de digitação. Já a conta do custo total deve ser feita por uma rotina determinística, com as mesmas fórmulas para todos os fornecedores. Assim, a mesma proposta gera sempre o mesmo resultado, e o financeiro consegue auditar o cálculo sem depender de como o modelo interpretou o texto naquele dia.

Quando uma informação está ausente ou é ambígua, o agente não deve preencher com suposição. O comportamento correto é marcar o campo como pendente e perguntar ao fornecedor. Comparar propostas que não são equivalentes é uma das formas mais comuns de decidir mal, e essa regra evita exatamente isso.

O que registrar no histórico de fornecedores

O histórico é o que transforma o agente em memória operacional. Sem ele, cada cotação começa do zero e a decisão depende de quem se lembra da última negociação. Um registro útil costuma conter:

• Data e canal de cada contato, ligados à solicitação de origem.
• Itens cotados, versão da especificação enviada e condições ofertadas.
• Resultado da comparação, com o motivo da escolha ou da recusa.
• Atrasos de entrega, não conformidades e reclamações registradas pelo recebimento.
• Quem aprovou, quando aprovou e com base em qual limite.

Registre apenas o necessário. Dados de contato de representantes comerciais são dados pessoais, e o acesso a eles deve ser restrito a quem precisa deles para comprar. Também vale definir por quanto tempo o histórico fica guardado e quem pode corrigi-lo.

Limites e aprovação acima do valor

Os limites devem ser definidos pela empresa antes da implantação e aplicados por regra, não pela expectativa de que o modelo vai "entender" a política. Um guia de decisão simples pode orientar o fluxo:

• Compra abaixo do limite de autonomia, com fornecedor homologado e especificação completa: o agente monta a comparação, recomenda uma opção e registra a recomendação.
• Compra acima do limite ou cotação de fornecedor novo: o agente prepara o resumo e envia para aprovação de um responsável nomeado.
• Divergência entre a proposta e a especificação, ou condição fora da política, como pagamento antecipado ou cláusula incomum: o agente pausa e sinaliza, sem sugerir aceitação.
• Proposta com dados faltantes ou conflitantes: o agente pergunta ao fornecedor e aguarda, sem concluir a comparação.
• Pedido do próprio solicitante para alterar um limite ou aprovar uma exceção: o fluxo nega a ação e registra a tentativa.

Quem pode aprovar precisa ser verificado pelo sistema, e não pelo texto da conversa. Uma pessoa que escreve "pode aprovar, sou o gerente" não deve ganhar permissão por isso. A boa prática de autorização separa quem solicita, quem recomenda e quem aprova, e cada ação verifica a permissão do usuário autenticado.

Cenário ilustrativo

Cenário ilustrativo: uma empresa de manutenção predial recebe pedidos de peças elétricas de vários técnicos. O agente agrupa os pedidos por item, envia a solicitação de cotação aos fornecedores homologados e recebe respostas em formatos diferentes. Uma das propostas traz preço competitivo, mas não tem garantia escrita e condiciona o prazo a um pagamento antecipado. O agente monta a tabela, marca essas condições como fora da política e encaminha ao comprador. O comprador decide, registra a justificativa, e o histórico do fornecedor é atualizado. Nenhum valor foi inventado e a decisão continuou com uma pessoa.

Plano para um piloto controlado

Um piloto deve ser pequeno o bastante para ser observado de perto e real o bastante para ensinar alguma coisa. Uma sequência prática:

• Escolher uma categoria de compra recorrente, de risco baixo e com especificação clara.
• Mapear o processo atual: quem pede, quem cota, onde estão as planilhas e em que ponto a decisão costuma travar.
• Definir o modelo de dados das propostas e as fórmulas de custo total, validadas por quem cuida do financeiro.
• Registrar por escrito os limites de autonomia e os responsáveis por cada nível de aprovação.
• Testar com propostas antigas, já conhecidas, em um ambiente separado, antes de conectar fornecedores reais.
• Ativar logs em cada etapa e combinar uma métrica de sucesso, como tempo até a decisão ou proporção de propostas corretamente sinalizadas, antes de começar.

Aplicamos aqui o método que usamos nos projetos: mapear o processo e a linha de base, limitar dados e ações, pilotar um fluxo real com logs e uma métrica combinada, e então transferir a operação e decidir se o fluxo será expandido, ajustado ou encerrado. Como esse trabalho costuma ser conduzido na prática, o consultor de IA Juan Carlo explica o formato de atuação.

Dados, LGPD e riscos de segurança

Propostas de fornecedores chegam em texto livre, e esse texto pode conter instruções inesperadas, como pedidos para ignorar regras ou para enviar uma ordem de compra sem aprovação. A orientação prática é tratar todo conteúdo externo como dado a ser analisado, nunca como comando. Ações como emitir pedido, liberar pagamento ou alterar cadastro de fornecedor devem ficar fora do alcance do modelo, acessíveis apenas por rotinas com permissão explícita. O OWASP documenta esse tipo de risco em suas diretrizes sobre injeção de prompt.

Quando o contato envolve pessoas físicas, a empresa deve tratar os dados com finalidade clara e necessidade mínima, conforme a LGPD. Se a ferramenta processa dados em serviços hospedados fora do país, o tema da transferência internacional também precisa entrar na análise antes do piloto.

O que o agente não deve fazer

O agente de compras não negocia fora das faixas aprovadas, não assina contratos, não libera pagamentos e não decide sobre penalidades a fornecedores sem revisão humana. Ele também não deve ser vendido como algo além do que é. Na mídia, o termo superinteligência aparece com frequência, mas um agente de compras é um sistema com tarefas delimitadas, dados conhecidos e regras escritas. Essa distinção é útil para a conversa com a diretoria, como explica o texto sobre o que o ChatGPT é e o que não é.

Se o fluxo passar a recusar ou penalizar fornecedores de forma automática, é preciso revisar as obrigações sobre decisões automatizadas, como as previstas no artigo 20 da LGPD, que tratam do direito de revisão.

Perguntas frequentes

Um agente de IA para compras substitui o comprador? Não. Ele reduz o trabalho de organizar cotações, padronizar dados e registrar histórico, mas a decisão de compra e a responsabilidade por ela continuam com pessoas. O papel do comprador tende a mudar para a análise das exceções e para a negociação.

Quais dados são necessários para o agente comparar cotações? São necessários a especificação do item, as propostas recebidas, as condições de frete, prazo, pagamento e garantia, e as fórmulas de custo total definidas pelo financeiro. Dados pessoais de contato devem ser reduzidos ao mínimo e tratados com finalidade clara.

Como definir o limite para aprovação humana? O limite deve ser uma decisão da diretoria ou de quem responde pelo orçamento, registrada por escrito antes do piloto. Ele pode considerar o valor total, o fornecedor (novo ou homologado), o tipo de item e o nível de risco da compra. Ajuste o limite com base nos registros das primeiras semanas, não em suposições.

É preciso usar um sistema específico ou basta uma planilha? Uma planilha pode servir como base do modelo de dados, mas o fluxo com agente exige integração, permissões e logs, o que costuma pedir uma ferramenta de orquestração. Comparar opções de plataformas ajuda a escolher a mais adequada para a equipe, como mostra o texto sobre Dify, Flowise ou Langflow.

Fontes

• Anthropic: Building effective agents
• OWASP: Authorization Cheat Sheet
• OWASP: LLM Prompt Injection Prevention Cheat Sheet