Quanto custa rodar um agente de IA na operação de um supermercado

Multiplicar SKU por loja por dia transforma centavos em milhões. A conta que decide se o projeto sobrevive ao primeiro trimestre precisa ser feita antes de construir, não depois.

ARTIGO6 MIN DE LEITURAGABRIEL ALONSO

A conta que quase ninguém faz antes de construir é a mais simples de todas: quanto custa uma execução, multiplicado pelo número de execuções por mês. No varejo alimentar, essa multiplicação é impiedosa, porque o setor tem duas dimensões que crescem juntas: quantidade de itens e quantidade de lojas.

A multiplicação que assusta

A conta a seguir é ilustrativa. Ela serve para mostrar ordem de grandeza, não para prever a fatura de ninguém, e as premissas ficam à vista justamente para você trocar pelas suas.

Uma rede de porte médio opera perto de 200 lojas e um sortimento na casa dos 30 mil SKUs. Se a arquitetura escolhida rodar uma execução por SKU, por loja, por dia, o volume é de 6 milhões de execuções diárias, ou 180 milhões por mês. A R$ 0,05 por execução, a conta fecha em R$ 9 milhões mensais. Nenhum ganho de quebra sustenta isso.

Agora troque a unidade de execução. Em vez de olhar todo SKU todo dia, o sistema é acionado apenas para o que fugiu do padrão: ruptura projetada, desvio de venda contra a previsão, validade próxima, divergência de estoque. Se isso representa 2% do universo, são 120 mil execuções por dia, 3,6 milhões por mês, e a conta cai para cerca de R$ 180 mil mensais. Mesma tecnologia, mesmo preço unitário, custo cinquenta vezes menor.

A decisão que mais pesa no custo não é a tecnologia escolhida, é a unidade de execução. Esse é o ponto que quase nunca aparece na proposta do fornecedor, e é o primeiro que a arquitetura precisa responder.

Por que a estimativa erra por uma ordem de grandeza

A IA cobra por volume de texto: o que ela lê para decidir e o que ela escreve como resposta. Quem estima custo pensando num sistema que responde perguntas conta uma leitura por tarefa. Não é assim que um agente funciona.

Para resolver uma reposição, o sistema consulta o estoque e lê o resultado, pede a previsão e lê de novo, checa o prazo do fornecedor e lê mais uma vez. São seis idas e voltas para uma decisão só. E em cada uma delas ele relê boa parte do que já tinha lido, porque precisa do assunto inteiro na cabeça para escolher o passo seguinte.

Na prática, o custo real de uma execução costuma dar seis vezes o que a estimativa ingênua previu. Se o sistema for construído acumulando tudo a cada passo, em vez de carregar só o necessário, passa de vinte vezes. Mesmo trabalho, mesma decisão no fim, conta completamente diferente.

Onde o custo escapa

O contexto que só cresce

O padrão mais caro é acumular todo o histórico a cada volta. Na sexta consulta, o sistema está relendo tudo que veio antes. O custo cresce mais rápido que o número de passos, não junto com ele. Num agente de análise de quebra, que percorre categoria, loja, período e fornecedor, isso aparece rápido.

Consulta que devolve demais

Uma consulta que retorna 500 linhas quando 5 bastariam custa leitura em toda chamada seguinte que carregar aquele resultado. No varejo isso é regra, não exceção: pedir "as vendas da categoria" e receber o extrato item a item dos últimos 90 dias é o caminho natural de quem integra com ERP sem projetar a consulta. Devolver o número agregado que o sistema precisa, em vez do dado bruto que o banco tem, costuma cortar mais custo do que trocar de tecnologia.

A tentativa repetida que ninguém contabiliza

Uma consulta que falha e é refeita dobra o custo daquele trecho. Integração com ERP e com sistema de fornecedor falha mais do que a estimativa supõe, principalmente em janela de fechamento e em pico de movimento. Sem contabilizar as repetições, a projeção fica sistematicamente otimista. Vale lembrar que repetir é comportamento normal de um agente, e não de um sistema que só responde: quem estima custo com a régua errada erra por construção.

Pico sazonal tratado como média

O varejo alimentar não tem volume constante. Véspera de feriado, Páscoa, Natal e início de mês concentram movimento, e é justamente quando o sistema é mais acionado. Uma estimativa feita sobre a média mensal subestima o pico, que é onde o orçamento estoura e onde o limite de chamadas por minuto que o fornecedor impõe costuma aparecer pela primeira vez.

O que reduz custo sem reduzir qualidade

  1. Reaproveitar o que não muda. Instruções, regras de negócio e contexto estável podem custar uma fração do preço quando o sistema é construído para não reenviá-los toda vez. É a otimização de maior retorno e a mais simples de fazer.
  2. Processar por exceção. Acionar o sistema apenas quando um sinal barato indica desvio. Um cálculo estatístico simples filtra o que merece decisão cara.
  3. Tecnologia menor onde cabe. Classificar, rotear e extrair campo de documento raramente precisam do recurso mais caro. Reserve o caro para a exceção e para a decisão de fato.
  4. Cortar o histórico. Manter os últimos passos mais um resumo, em vez do registro inteiro.
  5. Agregar antes de devolver. Trazer só os campos usados e limitar o tamanho do retorno das consultas.
  6. Agrupar por lote. Uma execução que avalia a categoria inteira de uma loja custa menos que trinta execuções item a item, quando a decisão é a mesma.

A métrica que decide é por resultado

Custo por execução é diagnóstico. A métrica de decisão é custo por resultado útil, ou seja, o custo por execução dividido pela taxa de acerto. Um sistema de R$ 0,40 por execução com 60% de acerto custa R$ 0,67 por resultado; um de R$ 0,55 com 95% custa R$ 0,58. O segundo é mais barato, apesar de parecer mais caro na fatura.

No supermercado, esse cálculo tem um segundo andar. Um pedido de reposição errado não custa apenas a execução do sistema: custa a quebra do perecível que sobrou ou a venda perdida do item que faltou. Quando o erro carrega custo operacional, a diferença entre 60% e 95% de acerto deixa de ser detalhe de qualidade e vira a variável dominante da conta.

Sem medir a taxa de acerto, essa comparação é impossível, que é a razão para a prova prática existir desde o primeiro dia. E como o teto de custo precisa ser aplicado por quem executa, e não pedido ao sistema, ele acaba sendo também um instrumento de governança, não só uma linha de orçamento.

A conclusão prática é desconfortável e barata de aplicar: antes de aprovar qualquer projeto de IA para a rede, peça a estimativa de execuções por mês e o custo unitário. Se o fornecedor não souber responder, o número que ele não calculou vai aparecer na fatura do terceiro mês.