Portal do Supply Chain

IA preditiva em supply chain: por que pilotos não escalam

Escrito por Samuel Ribeiro Vasconcellos | 09/10/2026 21:05

Levantamento do setor mostra que quase todo piloto de IA preditiva em supply chain cumpre as metas definidas, mas poucos viram solução rodando em toda a rede. O gargalo não está no modelo: está em dados sujos, decisões sem dono e indicadores que ainda recompensam o mundo reativo.

Faz cerca de três anos que empresas de supply chain testam IA preditiva: demand sensing, estoque de segurança dinâmico, detecção de ruptura, torres de controle simuladas. Em artigo publicado em 9 de outubro na Supply Chain Management Review, o comprador Kishan Kumar descreve um padrão incômodo: quase todo piloto bate a meta que foi definida para ele, e mesmo assim a maioria nunca vira operação em escala.

O modelo que previu risco de ruptura continua rodando num dashboard isolado. A iniciativa de demand sensing que subiu a acurácia de previsão em mais de dez pontos ainda não foi expandida para as outras doze linhas do portfólio. Na leitura de quem acompanha planejamento de demanda no dia a dia, um salto de dez pontos de acurácia normalmente é a forma de dizer que o MAPE caiu dez pontos percentuais num recorte controlado: SKU certo, região certa, dado limpo. O problema é que essa conta não se repete quando o piloto vira projeto corporativo.

O artigo de Kumar explica por que a maioria das empresas não segue um caminho de expansão disciplinada e onde a conta trava.

O gargalo não é a precisão do modelo

Fornecedores de solução preditiva costumam provar que o modelo funciona no ambiente de piloto, e isso é verdade na maior parte dos casos. O problema aparece depois: incorporar a recomendação à rotina de planejamento, decidir quem manda quando o planejador discorda do algoritmo, e sair de uma linha de produto ou região para sustentar a rede inteira.

Kumar cita estudos do setor mostrando que a maior parte dos pilotos de IA em operações reporta resultado positivo, mas só uma fração pequena chega a virar solução corporativa dentro de doze meses. A distância entre prova de conceito e solução enterprise é onde o projeto costuma morrer, mesmo quando o modelo nunca foi o problema.

Causa 1: o dado do piloto é limpo, o da empresa não é

Piloto tolera dado sujo porque alguém arruma à mão. Um único grupo de negócio, um dataset curado, meses de limpeza manual feita pela equipe de ciência de dados: o resultado costuma ser ótimo, e é exatamente aí que mora a armadilha. Alimentar o mesmo modelo com dado vindo de uma dúzia de ERPs diferentes, hierarquia de SKU que muda por região e cadastro de fornecedor nunca normalizado depois de anos de fusão e aquisição derruba a performance.

Para ilustrar com um número hipotético, mas plausível para quem já migrou modelo de forecast entre sistemas: um MAPE de 15% medido num piloto de uma região pode saltar para a casa dos 30% a 35% quando o mesmo modelo passa a rodar sobre doze ERPs sem master data unificado. O modelo não piorou; o dado que ele recebe é que ficou pior.

Segundo Kumar, as empresas que conseguem escalar tratam a infraestrutura de dados como um resultado do piloto, não como pré-requisito dele. Elas usam o piloto para mapear onde a base falha e financiam o trabalho chato de criar master data limpo e pipeline de integração antes de declarar vitória e partir para a escala.

Causa 2: ninguém é dono da decisão que o algoritmo sugere

O modelo recomenda adicionar duas semanas de estoque de segurança para uma peça específica. Testar essa recomendação num piloto é simples. Colocá-la em produção exige responsabilidade clara: alguém precisa responder quando a previsão sai errada, e hoje isso raramente existe.

Kumar chama esse vácuo de "ownership gap": compras acha que planejamento é dono do problema, planejamento acha que finanças deveria estar na mesa por causa do capital de giro envolvido, e finanças nunca participou da construção do modelo. O ponto central da citação do autor resume bem onde está o verdadeiro obstáculo:

Isso não é um problema de ciência de dados e, portanto, não tem solução de ciência de dados: é uma questão de direitos de decisão e governança que determina quais recomendações podem ser executadas automaticamente, quais exigem aprovação humana e quem é dono do resultado dessas decisões. (original, en) This is not a data science issue and therefore doesn't have a data science solution; this is about decision rights and governance that determines which recommendations may be executed automatically, which require human approval, and who owns the resulting decisions. (autor) Kishan Kumar, comprador na Pearse Bertram e autor do artigo na Supply Chain Management Review

Regra de decisão e escalada precisam existir antes da recomendação entrar em produção, não depois da primeira crise causada por uma previsão errada sem dono.

Causa 3: o scorecard ainda mede o mundo reativo

A maioria das organizações de supply chain avalia planejador, comprador e gerente de logística por indicador operacional e reativo: nível de serviço (OTIF), custo por unidade, giro de estoque. IA preditiva existe para agir antes da ruptura acontecer, o que pede um scorecard diferente e mais difícil de medir: não é "quanto tempo levou para resolver", é "quantas vezes a ação preventiva evitou o problema que nunca chegou a aparecer no indicador tradicional".

Sem incentivo novo, o comportamento não muda. Reescrever a métrica de desempenho do time de planejamento dá tanto trabalho quanto escrever o código do modelo preditivo, e é tão parte do projeto de escala quanto a infraestrutura de dados.

O que funciona: expansão, não transformação

As empresas que saíram do piloto para a operação em escala, segundo o levantamento de Kumar, não fizeram uma reforma ampla de uma vez. Elas seguiram uma progressão mais estreita:

  1. Começar pequeno, num conjunto limitado de problemas com valor demonstrável, em vez de prometer revolucionar a área inteira de uma vez.
  2. Orçar a limpeza de dado e a integração de sistema como parte do piloto desde o início, entendendo que resolver esse problema é o projeto de verdade, e o modelo é só o que expõe onde ele existe.
  3. Definir regra de governança e dono da decisão antes da implantação, não depois da primeira crise.
  4. Revisar meta e remuneração para premiar quem age sobre a recomendação do modelo, e não só quem cumpre o indicador antigo.
  5. Expandir um caso de uso já provado para outros sites, linhas de produto ou regiões antes de adicionar uma aplicação nova e diferente.

Piloto aprovado não é sinônimo de solução pronta para escalar

Vale separar dois conceitos que o mercado trata como sinônimos e não são. Piloto bem-sucedido significa que o modelo bateu a meta de acurácia ou de redução de ruptura num recorte controlado de dado e processo. Solução escalável significa que a mesma meta se sustenta quando o recorte vira a rede inteira, com todo ERP, toda exceção de cadastro e toda disputa de quem decide o quê.

A primeira é métrica de ciência de dados. A segunda é métrica de governança, dado mestre e incentivo. Confundir as duas é o motivo pelo qual tanto projeto com resultado de piloto ótimo nunca vira solução rodando em escala.

Como isso aparece no seu dia a dia

Se você coordena ou analisa planejamento de demanda, vale perguntar três coisas antes de aprovar a expansão do próximo piloto de IA: quem é o dono da decisão quando o modelo e o planejador discordam, que parte do ganho de acurácia do piloto depende de um dado que só está limpo porque alguém arrumou à mão, e se a meta do seu time hoje premia agir sobre a previsão ou só premia resolver o problema depois que ele já virou ruptura. Sem resposta clara para as três, o próximo piloto corre o risco de virar mais um dashboard esquecido.

Fonte: Kishan Kumar, "Beyond the pilot: Why most predictive AI investments in supply chain still fail to scale", Supply Chain Management Review, 9 de outubro de 2026.