IA para supermercados: por que os pilotos não chegam à produção

O setor supermercadista brasileiro faturou R$ 1,145 trilhão em 2025, segundo o Ranking ABRAS, e opera com margem historicamente apertada. Nesse cenário, IA não é assunto de inovação: é assunto de margem. E o padrão nas redes que já tentaram repete o de outros setores: o piloto impressiona, a diretoria aprova, e um ano depois o sistema continua rodando em três lojas.

Onde a IA paga a conta no supermercado

Antes de discutir por que os projetos travam, vale nomear o que está em jogo.

A Pesquisa de Eficiência Operacional da ABRAS mede o setor em 98,18% de eficiência na edição de 2026, o que deixa perto de 1,8% do faturamento se perdendo no caminho. A composição diz mais do que o total: na edição anterior, a quebra operacional saltou de 59% para 68% do total das perdas, enquanto furto e erro de inventário recuaram. A perda que mais cresce é a que nasce dentro da própria operação.

A conta em dinheiro vem da Abrappe: R$ 42,1 bilhões perdidos pelo varejo brasileiro em 2025, ou 1,65% das vendas, contra 1,51% no ano anterior. As perdas cresceram 15,3% num ano em que o faturamento do setor cresceu 6,4%.

Em perecível a distância é maior. A quebra brasileira de FLV ronda 6%, cerca de quatro vezes a média europeia de 1,5%, segundo Gustavo Porpino, pesquisador da Embrapa Alimentos e Territórios. Tomate, banana, cebola e batata concentram o descarte. E a gôndola vazia cobra do outro lado: a ruptura média ficou em 11,5% em junho de 2026, pelo índice da Neogrid, o que significa venda perdida no dia e cliente perdido no mês.

São problemas com três características que interessam a um projeto de IA: acontecem todos os dias, têm dado histórico abundante (PDV, ERP, programa de fidelidade) e o resultado é medível em reais. Previsão de demanda por loja e por SKU, reposição automática, precificação de perecíveis e detecção de ruptura são os casos que já mostraram resultado. O Carrefour Brasil divulgou, em julho de 2025, redução de cerca de 30% nas perdas de FLV ao aplicar IA na gestão de estoque, em iniciativa que se estendeu a mais de 300 lojas.

A pergunta, portanto, não é se IA funciona para supermercado. É por que tão pouco disso chega à operação inteira.

O piloto otimiza a variável errada

Um piloto de previsão de demanda em cinco lojas é avaliado por uma pergunta: o sistema acerta? É a pergunta certa para decidir se vale continuar, e a errada para decidir se está pronto.

Produção, numa rede com dezenas ou centenas de lojas, pergunta outra coisa:

• O que acontece quando o ERP manda o cadastro de um SKU com unidade de medida errada?
• Qual o custo por execução quando o sistema roda para 30 mil SKUs em 200 lojas, todos os dias?
• Como o comercial descobre que a qualidade caiu antes de o pedido superdimensionado virar quebra?
• Quem responde quando o sistema sugere volume errado de perecível na véspera de feriado?

Nenhuma dessas perguntas aparece na demonstração. Todas aparecem na primeira semana de operação real, e é por isso que tantos pilotos morrem exatamente na transição.

Três lacunas que se repetem nas redes

Rastro de decisão tratado como registro de sistema

Guardar o que entrou e o que saiu não é rastreabilidade. Se um sistema de reposição gera um pedido 40% acima do padrão para uma categoria, a investigação precisa reconstruir a decisão: qual histórico ele considerou, qual previsão usou, qual regra de estoque de segurança aplicou. Sem esse rastro, o comprador para de confiar no sistema na segunda semana e volta para a planilha.

Custo descoberto tarde demais

No piloto, o custo por execução é irrelevante porque o volume é irrelevante. Em produção, a multiplicação é brutal: SKUs vezes lojas vezes frequência. A conta de quanto custa rodar um agente em escala precisa ser feita antes de construir, porque ela muda decisões de arquitetura, como reservar a tecnologia cara para as exceções e resolver a rotina com o que é barato.

Nenhuma prova prática

Quase todo piloto é validado por alguém olhando alguns exemplos e achando bom. No supermercado isso é ainda mais traiçoeiro, porque a sazonalidade esconde a piora: o sistema que ia bem em março pode errar feio na Páscoa, e ninguém percebe até a quebra aparecer. Sem uma prova prática com casos reais da operação, guardada e repetida a cada mudança, com casos de pico, de promoção e de feriado, toda atualização do fornecedor vira aposta.

O que muda quando se projeta para produção

A ordem se inverte. Em vez de provar que o sistema acerta e depois industrializar, define-se primeiro o contrato: qual entrada ele aceita, qual saída entrega, qual o teto de custo por execução, qual o critério de qualidade por categoria, e o que acontece na falha. No caso da reposição, por exemplo: pedido acima de um limiar vai para aprovação de gente, categoria perecível tem trava própria, e indisponibilidade de dado derruba o sistema para uma regra simples em vez de deixá-lo improvisar.

Piloto prova viabilidade. Produção exige contrato.

A tecnologia por trás passa a ser um detalhe substituível dentro de um sistema que sabe dizer, a qualquer momento, se está funcionando, quanto está custando e quando precisa de gente. É a mesma lógica que separa um agente de um chatbot: quanto mais autonomia o sistema tem sobre a operação, mais o controle precisa estar fora dele, instrumentado no que executa a decisão.

Por onde começar sem repetir o ciclo

O primeiro caso de uso não deve ser o mais visível, e sim o que reúne três condições: frequência diária, resultado medível em reais e dado histórico já disponível no ERP e no PDV. Reposição de categoria seca, precificação de perecível próximo do vencimento e alerta de ruptura costumam atender às três. Antes do piloto, registra-se a linha de base: quebra atual da categoria, índice de ruptura, horas gastas hoje no processo. Sem esse antes, nem o sucesso convence a diretoria a expandir.

Esse caminho é mais lento nas primeiras semanas e substancialmente mais rápido do terceiro mês em diante. Para a operação de um supermercado, em que a margem se decide em ponto percentual, a diferença entre um piloto eterno e um sistema em produção não é técnica: é a diferença entre apresentar IA na convenção anual e reduzir quebra no fechamento do mês.