IA aplicada à gestão de stocks: do ERP à reposição automática sem rutura

Segunda-feira, 8h30. A responsável de planeamento de uma confecção no Vale do Ave com 120 colaboradores abre três folhas de cálculo. Duas horas e meia depois, tem uma visão do stock que já tem 48 horas de atraso. Isto não é um problema de tecnologia — é um problema de arquitetura de dados. E é exatamente aqui que a maioria dos projectos de IA em reposição automática falha: chegam antes de a casa estar arrumada.

A tese que os fornecedores evitam dizer

Reposição automática sem rutura não é um problema de algoritmo. É um problema de dados limpos e de integração entre sistemas. Qualquer modelo de Predictive Analytics aplicado a stocks vai falhar se o ERP tiver artigos duplicados, se o MES não comunicar consumos em tempo real, ou se as entradas de armazém forem registadas com dois dias de atraso.

Um modelo de reposição automática treinado sobre dados sujos vai automatizar ruturas, não evitá-las.

Segundo o INE (2025), apenas 9,4% das pequenas empresas portuguesas com 10 a 49 trabalhadores usam IA — contra 49,1% das grandes. A diferença não é de orçamento. É de maturidade de dados e de integração de sistemas. Uma PME industrial que queira saltar diretamente para reposição automática sem primeiro resolver a qualidade do seu ERP está a construir sobre areia.

O que mudou para isto ser relevante agora

O custo da rutura mudou de escala

Durante décadas, a rutura de stock era um custo aceitável. O cliente esperava, o comercial ligava, o armazém improvisava. Hoje, os compradores internacionais — Inditex, Decathlon, Mango — têm cláusulas de penalização por falha de entrega que transformam a rutura num evento financeiro, não apenas operacional. No setor do calçado, onde uma coleção de 800 a 1 200 SKUs com três eixos de variação — cor, tamanho, feitio — tem janelas de entrega de semanas, uma rutura de componente numa linha de montagem em Felgueiras pode comprometer uma ordem de vários milhares de pares. O comercial já não improvisa: paga.

Os modelos de previsão saíram dos laboratórios

Até há cinco anos, implementar previsão de procura com machine learning exigia uma equipa de data scientists e infraestrutura dedicada. Hoje, os principais ERPs industriais expõem APIs que permitem ligar modelos pré-treinados ou serviços cloud de forecasting sem reescrever o núcleo do sistema. O que antes era um projecto de 18 meses é agora uma integração de 8 a 12 semanas — desde que os dados estejam limpos. A condição é sempre a mesma.

A regulação construiu o dataset sem que ninguém pedisse

A obrigatoriedade de comunicação SAF-T mensal (Portaria 195/2020) e a certificação de software pela AT (DL 28/2019) forçaram as empresas a manter registos digitais estruturados de movimentos de stock. Esse histórico — que antes existia apenas em papel ou em folhas de cálculo — é agora o dataset de treino para qualquer modelo de previsão. Quem cumpriu a regulação tem, sem saber, construído o seu ativo de dados. É um dos poucos casos em que a burocracia fiscal gerou valor operacional real.

As quatro abordagens técnicas reais

Não existe uma única forma de ligar IA à reposição de stock. Existem quatro arquiteturas com perfis de custo, complexidade e adequação muito diferentes. A escolha errada — tipicamente escolher a mais sofisticada porque o fornecedor a apresentou primeiro — é a causa mais comum de projectos que ficam parados após a fase piloto.

A abordagem mais simples é o módulo nativo do ERP: ponto de encomenda, stock de segurança dinâmico, MRP com horizonte variável. Não é IA no sentido estrito, mas resolve 70% dos casos em PME com procura relativamente estável. O ERP MULTI cobre este nível de planeamento para indústria têxtil, calçado e metal. O erro habitual é subestimá-la porque não tem o nome "IA" na proposta.

A camada de forecasting via API é a abordagem com melhor relação custo/benefício para empresas entre 50 e 300 colaboradores com histórico de dois ou mais anos. Um serviço de forecasting consome o histórico de vendas e movimentos do ERP, gera previsões por artigo/localização/período e devolve sugestões de encomenda que o ERP converte em ordens de compra. A integração usa tipicamente Webhooks ou conectores REST. O risco está na qualidade da ligação: se o conector falhar silenciosamente, o modelo continua a recomendar com dados de há três semanas.

Para operações de maior complexidade — múltiplas fábricas, múltiplos armazéns, cadeias de subcontratação extensas — plataformas como o QAD Adaptive ERP integram capacidades de machine learning diretamente no motor de planeamento, com configuração low-code. O custo de implementação é superior, mas a manutenção do modelo é feita dentro do próprio ERP, sem dependência de sistemas externos. A vantagem não é o algoritmo — é a governação: tudo está num sítio só.

A quarta arquitetura é a mais exigente e a mais poderosa: MES ligado ao ERP com IA alimentada por dados de chão-de-fábrica em tempo real. Para indústrias com consumo de componentes por ordem de produção — têxtil de malha, injecção plástica, metalomecânica — a integração do KORA Productivity com o ERP permite alimentar o modelo com consumos reais, não apenas com saídas de armazém. A diferença é crítica: o armazém pode mostrar stock disponível enquanto o chão-de-fábrica já consumiu esse material em ordens ainda não fechadas. É o cenário que destrói os modelos que só lêem o ERP.

Os trade-offs que a proposta não mostra

O custo que ninguém orça na primeira reunião

O custo de licença ou subscrição é a parte visível. O que fica de fora é o custo de limpeza de dados: artigos duplicados, unidades de medida inconsistentes, fornecedores sem lead time registado, movimentos de stock sem causa associada. Em empresas com ERPs com mais de oito anos e sem higiene de dados sistemática, este trabalho representa 30 a 40% do esforço total do projecto. Não é estimativa — é o padrão que vemos repetido. Orce-o antes de assinar qualquer proposta.

O histórico mínimo que o modelo precisa — e o que fazer quando não existe

Modelos de forecasting precisam de histórico suficiente para aprender sazonalidade, picos de campanha e efeitos de promoção. Para a maioria dos setores industriais portugueses, 24 meses de histórico limpo é o mínimo operacional. Com menos do que isso, o modelo vai recomendar stocks de segurança excessivos — melhor do que ruturas, mas não é o objetivo. Se o histórico disponível for inferior, a decisão correta é implementar primeiro o stock de segurança dinâmico parametrizado no ERP e acumular histórico durante seis a doze meses antes de avançar para forecasting.

O problema dos eixos de variação que os ERPs generalistas não modelam

No calçado, um artigo não é uma referência — é uma combinação de modelo × cor × tamanho × feitio. Uma coleção de 200 modelos pode gerar 8 000 SKUs ativos. Modelos de forecasting generalistas tratam cada SKU como independente e produzem previsões com variância enorme nas referências de baixa rotação. Os melhores tratam a hierarquia: preveem ao nível do modelo e desagregam por variante com base em curvas históricas de distribuição. Antes de avaliar qualquer solução para o setor do calçado ou para vestuário com coleções extensas, verifique se suporta esta hierarquia. Se não suportar, o modelo vai errar sistematicamente nas variantes menos vendidas — que são frequentemente as que causam ruturas de linha.

O risco que ninguém menciona: a confiança cega no modelo

Quando a reposição é automática, o comprador deixa de rever as sugestões individualmente. É o objetivo — mas é também o risco. Um evento não previsto no histórico — uma greve portuária, uma rutura de matéria-prima global, uma mudança de coleção antecipada pelo cliente — pode gerar ordens de compra erradas em volume antes de alguém perceber. A salvaguarda não é técnica: é um limiar de aprovação manual para ordens acima de um valor ou quantidade definidos. Sem este limiar, a automatização transforma um erro de previsão num problema de tesouraria.

O que funciona na prática industrial portuguesa

Comece pelo stock de segurança dinâmico, não pelo forecasting

A maioria das empresas industriais portuguesas tem stock de segurança definido manualmente, por intuição do responsável de compras, e nunca revisto desde que foi parametrizado. Antes de implementar qualquer modelo de IA, calcule o stock de segurança correto com base no lead time real do fornecedor e na variabilidade histórica da procura. Este passo — que o ERP já suporta com parametrização adequada — reduz ruturas de forma significativa sem nenhum investimento adicional. É o passo que os fornecedores de IA nunca sugerem porque não lhes gera receita.

Alimente o modelo com encomendas confirmadas, não só com histórico

Numa empresa de distribuição no corredor Lousada/Paços de Ferreira, o modelo de forecasting baseado em histórico de saídas de armazém subestima sistematicamente picos de procura porque não vê as encomendas confirmadas dos clientes que ainda não foram expedidas. O histórico diz que a semana passada saíram 400 unidades. A carteira de encomendas diz que esta semana vão sair 900. O modelo não sabe. A solução é alimentá-lo não só com histórico, mas também com a carteira de encomendas em aberto — dados que o ERP tem, mas que muitas integrações de forecasting não consomem por omissão de configuração. A KORA Inventory Suite expõe estes dados em tempo real para camadas de análise externas.

Segmente antes de automatizar

Automatizar a reposição de todos os artigos ao mesmo tempo é o erro mais comum. Os artigos A — alto valor, alta rotação — merecem revisão humana mesmo com sugestão automática. Os artigos C — baixo valor, baixa rotação — podem ser totalmente automatizados com risco mínimo. Os artigos B ficam no meio: sugestão automática com aprovação simplificada. Esta segmentação reduz o volume de decisões humanas necessárias em 60 a 70% sem eliminar o controlo onde ele importa.

Automatizar os artigos C liberta o comprador para pensar os artigos A. Esse é o verdadeiro ganho de produtividade.

Matriz de decisão: qual a abordagem certa para o seu contexto

Como medir o sucesso pós-implementação

Os indicadores que importam — e os que enganam

A taxa de rutura é o indicador óbvio. Mas há três métricas que a maioria das empresas não mede e que revelam se o modelo está realmente a funcionar. A primeira é a precisão de previsão por família de artigos: o modelo acerta mais nos artigos A do que nos C? Se não, o problema é de dados, não de algoritmo. A segunda é a rotação de stock por categoria: a reposição automática pode eliminar ruturas aumentando stocks — se a rotação cair, o custo financeiro do stock subiu e o ganho foi ilusório. A terceira é a taxa de aprovação manual de sugestões: se o comprador rejeita mais de 20% das sugestões automáticas, o modelo não está calibrado para o contexto real da empresa e está a gerar trabalho em vez de o eliminar.

Há ainda uma quarta métrica que quase ninguém monitoriza: o desvio entre o lead time registado no ERP e o lead time efetivo do fornecedor. A diferença entre os dois é frequentemente a causa principal de ruturas. O modelo prevê corretamente a procura, mas o fornecedor entrega mais tarde do que o sistema assume — e o ERP nunca foi atualizado porque ninguém tem tempo para isso ao fim do mês.

O dashboard que o Qlik Sense deve mostrar

Não construa um dashboard de stocks genérico com semáforos de nível. Construa um dashboard de desvios: artigos onde a previsão errou mais de 20%, fornecedores com lead time real superior ao registado, referências com stock abaixo do ponto de encomenda há mais de 48 horas. O objetivo é tornar visível o que o modelo não consegue resolver sozinho — para que a intervenção humana seja cirúrgica, não sistemática. Um dashboard que mostra tudo não ajuda ninguém a decidir.

O que o AI Act muda neste contexto

O Regulamento (UE) 2024/1689 — AI Act — está em vigor desde agosto de 2024, com as proibições aplicáveis desde fevereiro de 2025. Os sistemas de reposição automática de stock que tomam decisões com impacto financeiro significativo sem intervenção humana podem enquadrar-se em categorias de risco que exigem documentação técnica e registo de logs de decisão. Não é uma ameaça à operação — é uma disciplina que as boas práticas já impunham. Documente o modelo, os dados de treino, os limiares de aprovação manual e os procedimentos de revisão periódica. Quem já o faz por rigor operacional está em conformidade sem esforço adicional. Para o contexto mais amplo desta obrigação, leia Governance de IA em PME industrial: o que documentar antes do AI Act.

O AI Act não proíbe a reposição automática. Exige que saiba explicar por que o modelo decidiu encomendar 500 unidades numa sexta-feira à tarde.

Sequência operacional de implementação

1. Audite a qualidade dos dados do ERP — artigos duplicados, unidades de medida inconsistentes, lead times em falta, movimentos de stock sem causa registada. Este passo revela o esforço real do projecto antes de assinar qualquer contrato.
2. Defina o perímetro de automatização — segmente os artigos em A/B/C e decida quais serão automatizados na primeira fase. Comece pelos C: risco mínimo, aprendizagem máxima.
3. Valide o histórico disponível — confirme que tem pelo menos 24 meses de movimentos limpos. Se não, implemente primeiro o stock de segurança dinâmico e acumule histórico durante seis a doze meses.
4. Integre dados de procura futura — encomendas confirmadas, previsões de vendas, calendário de campanhas. O modelo de forecasting deve ver o futuro conhecido, não apenas o passado.
5. Configure limiares de aprovação manual — defina valores e quantidades acima dos quais qualquer sugestão automática requer aprovação humana antes de gerar ordem de compra.
6. Monitorize os desvios semanalmente durante os primeiros três meses — recalibre o modelo com base nos erros de previsão reais. Nenhum modelo está calibrado na semana um. Os fornecedores que dizem o contrário nunca implementaram nada numa fábrica a funcionar.

Para aprofundar

A reposição automática é apenas uma das aplicações da IA sobre o ERP industrial. O artigo Automação de processos industriais: onde a IA começa a pagar mapeia as áreas com retorno mais rápido. Para a camada de previsão de procura que alimenta a reposição, leia IA aplicada à previsão de procura: do ERP à ordem de compra automática. E se o seu ERP ainda não comunica corretamente com o SAF-T, resolva primeiro o problema descrito em SAF-T em produção industrial: erros de extracção que o ERP não avisa — porque os mesmos dados que alimentam o SAF-T são os que o modelo de forecasting vai consumir.

A questão que fica: a sua empresa tem dados suficientemente limpos para que um modelo de IA seja melhor do que o comprador experiente que já lá está há doze anos? Se a resposta for incerta, comece pela auditoria de dados — não pelo algoritmo. O algoritmo é a parte fácil.

Fontes

• INE — Inquérito à Utilização de Tecnologias da Informação e da Comunicação nas Empresas, 2025. Disponível em: ine.pt
• Eurostat — ICT usage in enterprises: Artificial Intelligence, 2025. Disponível em: ec.europa.eu/eurostat
• Comissão Europeia — Regulamento (UE) 2024/1689 do Parlamento Europeu e do Conselho (AI Act), publicado no Jornal Oficial da UE em agosto de 2024. Disponível em: eur-lex.europa.eu
• Portaria n.º 195/2020, de 13 de agosto — comunicação mensal do ficheiro SAF-T (PT) à Autoridade Tributária e Aduaneira. Disponível em: dre.pt
• Decreto-Lei n.º 28/2019, de 15 de fevereiro — requisitos de faturação eletrónica e certificação de software pela AT. Disponível em: dre.pt

Perguntas frequentes

O que causa o fracasso da maioria dos projectos de IA em reposição automática?

A maioria falha porque implementam IA sem antes resolver a qualidade dos dados e a integração entre sistemas. Um modelo treinado sobre dados sujos — artigos duplicados no ERP, consumos não comunicados em tempo real, ou registos atrasados — automatiza ruturas em vez de as evitar. O problema não é o algoritmo, é a arquitetura de dados.

Qual é a diferença entre as pequenas e grandes empresas na adoção de IA?

Segundo o INE (2025), apenas 9,4% das pequenas empresas com 10 a 49 trabalhadores usam IA, contra 49,1% das grandes. A diferença não é orçamentária, mas de maturidade de dados e integração de sistemas. Uma PME que salte diretamente para reposição automática sem resolver a qualidade do ERP está a construir sobre areia.

Por que é que a rutura de stock se tornou um problema financeiro crítico?

Os compradores internacionais — Inditex, Decathlon, Mango — incluem cláusulas de penalização por falha de entrega nos contratos. No calçado, uma rutura de componente numa linha de montagem pode comprometer encomendas de milhares de pares. A rutura deixou de ser um incómodo operacional para ser um evento financeiro grave.

Qual foi o impacto da regulação SAF-T e da certificação de software na IA?

A obrigatoriedade de comunicação SAF-T mensal e certificação pela AT forçou as empresas a manter registos digitais estruturados de movimentos de stock. Esse histórico tornou-se o dataset de treino para modelos de previsão. Quem cumpriu a regulação construiu, sem saber, um ativo de dados valioso para IA.

Qual é a abordagem mais adequada para uma PME com 80 colaboradores?

Para empresas entre 50 e 300 colaboradores com histórico de dois ou mais anos, a camada de forecasting via API oferece a melhor relação custo/benefício. Um serviço consome o histórico do ERP, gera previsões por artigo e devolve sugestões de encomenda. A implementação demora 8 a 14 semanas.

Qual é a diferença entre um ERP com IA nativa e forecasting via API?

O forecasting via API liga um serviço externo ao ERP através de conectores REST. A IA nativa (low-code) integra capacidades de machine learning diretamente no motor de planeamento. A vantagem da IA nativa é a governação: tudo está num único sistema, sem dependência de plataformas externas.

Por que é que ligar o MES ao ERP com IA é crítico para indústrias de transformação?

O MES fornece dados de consumo real do chão-de-fábrica em tempo real. O armazém pode mostrar stock disponível enquanto a produção já consumiu esse material em ordens não fechadas. Modelos que lêem apenas o ERP falham porque não vêem este consumo real, destruindo a precisão da reposição automática.