Agentes de IA para supermercados: por que não é a mesma coisa que um chatbot

O fornecedor abre a demonstração numa tela de conversa. Você digita uma pergunta sobre um produto, a IA responde certo, e a sala aprova. Na semana seguinte chega a proposta seguinte: a mesma IA emitindo o pedido de reposição das trinta lojas. A tela é parecida e a tecnologia por trás é a mesma, então parece a evolução natural do que já foi aprovado. Não é. Um responde perguntas e o outro assina cheque, e as duas coisas não se contratam do mesmo jeito.

A diferença é quem decide o próximo passo

O sistema que responde tem caminho fixo. Chega a pergunta, ele monta a resposta, devolve. Pode errar a resposta, mas nunca erra o caminho, porque o caminho quem definiu foi você. Quando ele erra, o custo é uma informação errada.

Um agente decide o próximo passo sozinho. Agente, aqui, é um sistema que decide e executa uma tarefa, não um chat que responde perguntas. Aplicado à reposição de uma loja, ele consulta o estoque, olha a previsão de venda, checa o prazo do fornecedor, decide a quantidade e emite o pedido. Ninguém desenhou essa sequência passo a passo: ele escolhe o que fazer a cada etapa, e escolhe quando parar. Quando ele erra, o custo é caminhão parado no CD ou gôndola vazia no sábado.

Vale a comparação com gente, que é como a rede já pensa. O sistema que só responde é o funcionário do balcão de informações: responde o que perguntam, e o pior que acontece é responder errado. Um agente é o comprador júnior: ele decide, assina, e o dinheiro sai. Nenhuma rede contrata os dois com o mesmo processo, e nenhuma deveria comprar os dois com o mesmo contrato.

O que muda quando o sistema passa a agir

Três coisas deixam de ser detalhe técnico e viram condição de contrato. Todas têm equivalente exato na forma como a rede já trata gente.

O limite tem que estar no cartão, não no pedido

Pedir ao sistema que "não emita pedido acima de R$ 50 mil" é a mesma coisa que pedir ao comprador júnior que não gaste demais. Funciona na maioria das vezes, e falha justamente no dia atípico. O que funciona sempre é o limite estar no cartão: quando o valor passa do teto, a operação é recusada, e ninguém precisa lembrar da regra na hora certa.

No supermercado, três limites costumam bastar para começar:

• valor máximo do pedido sem aprovação de uma pessoa
• variação máxima sobre o histórico da categoria, em percentual
• trava separada para perecível, onde o erro não tem volta

Se o fornecedor responder que o limite está "configurado na instrução do sistema", esse limite é uma sugestão, não um controle.

Cada acesso deve ser uma tarefa com nome

A saída mais fácil, do lado de quem constrói, é dar ao sistema acesso amplo ao banco de dados e deixar que ele se vire. É o equivalente a entregar a chave do cofre e confiar no bom senso.

O certo é o contrário: cada coisa que o sistema pode fazer corresponde a uma tarefa que um analista saberia nomear. "Consultar o estoque desta categoria nesta loja" é uma tarefa. "Acessar o banco" não é. A diferença aparece no dia em que uma consulta mal formulada varre a base inteira no horário de pico, ou apaga um registro que ninguém mandou apagar. Com acesso amplo, evitar isso depende de o sistema não errar. Com tarefas nomeadas, fica impossível por construção.

O sistema precisa ser seguro para repetir

Um agente repete tentativas. Repete por queda de conexão, por concluir que a primeira resposta veio incompleta, por tentar de novo automaticamente. Se a função que emite pedido de compra não estiver preparada para isso, a repetição vira pedido duplicado, e pedido duplicado vira estoque parado com capital de giro dentro.

A prática humana já resolveu esse problema: se a ligação cai no meio do pedido ao fornecedor, ninguém repete o pedido sem antes conferir se o primeiro entrou. O sistema faz igual, com um identificador montado a partir de loja, fornecedor, data e categoria. A segunda tentativa com o mesmo identificador devolve o pedido que já existe, em vez de criar outro.

É barato de fazer, e a pergunta cabe em qualquer reunião: o que acontece se a mesma ordem sair duas vezes?

Onde cabe cada coisa

Nem todo processo precisa de agente

A pergunta útil não é "isso poderia ser feito com IA?", porque quase tudo poderia. É outra: este processo varia o suficiente para valer a pena abrir mão da previsibilidade?

Reposição de categoria seca, com giro estável e fornecedor único, raramente varia. Uma regra bem escrita resolve, custa quase nada e nunca inventa. Já a investigação de por que a quebra de uma categoria estourou no mês passa por um caminho diferente a cada vez: às vezes é fornecedor, às vezes é exposição na loja, às vezes é cadastro errado. É aí que o agente ganha, porque ninguém consegue escrever de antemão todas as sequências possíveis.

Colocar agente onde bastava uma regra é desperdício. O contrário é pior.

O erro que custa mais caro

O erro caro é tratar como chatbot algo que decide e executa. Acontece quando a rede liga o sistema direto no ERP com acesso amplo, sem tarefas nomeadas, com o limite escrito na instrução e sem registro de como cada decisão foi tomada.

Isso funciona por algumas semanas. Funciona porque os casos fáceis dominam o volume: a categoria seca, o fornecedor de sempre, a semana normal. E falha no primeiro caso incomum, que costuma ser também o mais caro: a véspera de feriado, a promoção que quebrou o histórico, o produto novo sem referência.

Vale registrar o que a autonomia carrega junto. Quanto mais o sistema decide sozinho, mais a conta por execução muda de figura, mais a prova prática precisa cobrir o caso que ninguém previu, e mais o controle precisa estar em quem executa, e não na instrução. É a mesma exigência que separa um piloto de IA de um sistema que roda na rede inteira.

Para quem está decidindo agora onde aplicar IA na rede, a pergunta que economiza mais dinheiro não é qual tecnologia usar. É quanta autonomia o processo aguenta, e quais travas precisam existir antes de conceder essa autonomia.