Às 7h15 de uma segunda-feira, o planeador de uma fábrica de confeção no Vale do Ave abre o ERP e vê 23 ordens de produção para a semana. Doze têm matéria-prima em falta. Três conflituam na mesma linha de costura. O prazo para o cliente alemão é sexta-feira. Nenhum algoritmo o avisou na sexta anterior — quando ainda havia tempo para agir.
A tese deste artigo é desconfortável: o problema não é a falta de IA. É que a maioria das fábricas industriais portuguesas está a tentar implementar IA sobre dados que nunca foram recolhidos com rigor suficiente para alimentar um modelo. Resolver isso primeiro — antes de escolher qualquer plataforma — é o que separa os projetos que funcionam dos que ficam numa apresentação de PowerPoint. O resto são detalhes de arquitetura.
O problema não é falta de dados — é falta de dados de execução real
A maioria das fábricas tem dados. Têm registos de ordens, tempos de ciclo, paragens de linha, devoluções, histórico de fornecedores. O que não têm é um mecanismo que sintetize esses dados em decisões de planeamento antes de o turno começar — e, mais importante, têm dados de plano onde precisavam de dados de execução real.
Segundo o INE, em 2025 apenas 9,4% das pequenas empresas portuguesas (10-49 trabalhadores) usavam tecnologias de inteligência artificial — e mesmo nas médias (50-249 trabalhadores), a adoção não chegava a 18,2%. A indústria transformadora portuguesa, maioritariamente composta por PME, está ainda na fase em que o ERP regista o passado mas não projeta o futuro.
Um ERP sem IA é um livro de atas. Regista o que aconteceu. A IA é o que transforma esse registo em instrução para amanhã. Mas só se o registo for verdadeiro.
O salto conceptual que este artigo desenvolve é este: a IA aplicada ao WIP e ao planeamento não substitui o planeador. Retira-lhe a parte mais ingrata do trabalho — a conciliação manual de variáveis que o cérebro humano não consegue processar em simultâneo a velocidade industrial. Mas exige, em troca, que os dados de entrada sejam dados de execução real — não os valores teóricos que alguém inseriu no ERP em 2018 e nunca mais actualizou.
O que mudou para isto ser relevante agora
Dados estruturados em volume suficiente
Durante anos, o argumento contra a IA em planeamento era simples: "não temos dados suficientes". Hoje, qualquer fábrica com dois anos de ERP ativo tem histórico de ordens, tempos de setup, taxas de refugo por referência, lead times reais de fornecedores e disponibilidade de máquinas. Esse volume — mesmo imperfeito — já é suficiente para treinar modelos de previsão de capacidade e deteção de conflitos. O que ainda falta, na maioria dos casos, não é quantidade: é qualidade. Especificamente, a distinção entre o que o plano dizia e o que a linha realmente fez.
Modelos pré-treinados acessíveis via API
Não é necessário construir um modelo de raiz. Plataformas de ML como Azure Machine Learning, AWS SageMaker ou Google Vertex AI disponibilizam modelos de séries temporais e otimização combinatória que se ligam via API ao ERP. O custo de infraestrutura caiu dramaticamente. O que permanece caro é a integração e a qualidade dos dados — não o modelo em si. Um fornecedor que apresente o modelo como o investimento principal está a inverter as prioridades.
Pressão regulatória e de clientes internacionais
Marcas como Inditex, Decathlon ou Mango exigem cada vez mais rastreabilidade de lote e cumprimento de prazos documentado. A EU Strategy for Sustainable and Circular Textiles adiciona pressão de conformidade que obriga a registar e justificar decisões de produção. Um planeamento assistido por IA produz um rasto de decisão auditável — o que o planeamento manual em Excel nunca conseguiu, por mais competente que fosse o planeador.
Regulamento (UE) 2024/1689 — AI Act em vigor
O AI Act está em vigor desde agosto de 2024, com as proibições aplicáveis desde fevereiro de 2025 e as regras sobre modelos de uso geral desde agosto de 2025. Sistemas de IA que influenciam decisões de produção com impacto em trabalhadores podem ser classificados como risco limitado ou alto risco, dependendo da autonomia do sistema. Qualquer implementação de IA em planeamento deve ser avaliada neste quadro antes de entrar em produção — não depois de o sistema estar a correr em modo autónomo.
As opções técnicas reais: quatro arquiteturas distintas
1. Previsão de procura integrada no ERP
O modelo mais comum. O ERP analisa o histórico de vendas, sazonalidade, carteira de encomendas e gera uma previsão de necessidades que alimenta o MRP. A IA aqui é um módulo de séries temporais — ARIMA, Prophet, LSTM — que substitui a previsão linear do MRP clássico.
Funciona bem quando o mix de produtos é estável, o histórico tem pelo menos 18-24 meses, e a procura tem padrão sazonal identificável. Falha quando há muitas referências novas por coleção (calçado, vestuário), quando o cliente é um único comprador internacional com comportamento errático, ou quando a carteira de encomendas é firme e a previsão estatística é simplesmente redundante — porque o futuro já está confirmado em sistema.
2. Otimização de sequenciamento de ordens
Dado um conjunto de ordens confirmadas, a IA determina a sequência ótima de produção minimizando tempos de setup, conflitos de recursos e atrasos. É o problema clássico de job-shop scheduling — NP-hard na teoria, resolúvel com heurísticas (algoritmos genéticos, simulated annealing, reinforcement learning) para horizontes de 5-10 dias.
Este é o módulo com retorno mais rápido em fábricas com múltiplas linhas e setups longos. Uma fábrica têxtil com tingimento pode reduzir significativamente o número de purgas de cor por semana com sequenciamento inteligente — sem alterar um único processo de produção. O ganho é puro: menos purgas, menos desperdício de água e químicos, menos paragens não planeadas. Qualquer chefe de produção do Vale do Ave percebe o argumento em 30 segundos.
3. Deteção de anomalias e alertas preventivos
Modelos de deteção de anomalias monitorizam em tempo real os dados de IIoT — sensores de máquina, contadores de peças, temperaturas de processo — e comparam com padrões históricos. Quando o desvio excede um limiar, gera um alerta antes de a paragem acontecer. Não é manutenção preditiva clássica: é mais simples e mais imediato. Detecta que a linha 3 está a produzir 12% abaixo do ritmo esperado às 9h, quando o plano pressupunha 100% de capacidade. O planeador recebe o alerta e redistribui carga antes do fim do turno — ainda dentro do mesmo dia, quando a decisão ainda tem valor.
4. Planeamento autónomo com feedback em loop fechado
O nível mais avançado. O sistema gera ordens de produção, monitoriza a execução em tempo real via KORA Productivity, compara com o plano, ajusta automaticamente e regera ordens para o turno seguinte. O planeador valida — não constrói. Requer integração profunda entre ERP, MES e sensores de chão-de-fábrica. Para a maioria das PME industriais portuguesas, este nível é uma aspiração de médio prazo, não um ponto de partida. Quem o apresenta como primeira fase está a vender o projecto errado.
Comparação de arquiteturas: trade-offs por dimensão
| Arquitetura | Custo de implementação | Tempo até valor | Complexidade de integração | Risco operacional | Adequação PME industrial PT |
|---|---|---|---|---|---|
| Previsão de procura no ERP | Baixo-médio | 3-6 meses | Baixa (módulo nativo) | Baixo | Alta (distribuição, retalho) |
| Sequenciamento de ordens | Médio | 2-4 meses | Média (requer dados de capacidade limpos) | Médio | Alta (têxtil, calçado, metal) |
| Deteção de anomalias IIoT | Médio-alto | 4-8 meses | Alta (sensores + integração MES) | Médio | Média (requer infraestrutura IIoT) |
| Loop fechado autónomo | Alto | 12-24 meses | Muito alta (ERP + MES + IIoT + IA) | Alto | Baixa (grandes grupos industriais) |
Matriz de decisão: que arquitetura escolher
| Critério da empresa | Previsão de procura | Sequenciamento | Anomalias IIoT | Loop fechado |
|---|---|---|---|---|
| Mix de produto estável (<200 referências ativas) | ✓ Forte | ✓ Forte | Neutro | Possível |
| Alta rotação de coleção (>600 SKUs/ano) | ✗ Fraco | ✓ Forte | Neutro | ✗ Prematuro |
| Setups longos e custosos | Neutro | ✓ Muito forte | Neutro | Possível |
| Máquinas com sensores instalados | Neutro | Neutro | ✓ Forte | ✓ Necessário |
| ERP com histórico <18 meses | ✗ Insuficiente | ✓ Funciona | ✗ Insuficiente | ✗ Inviável |
| Equipa de IT interna <3 pessoas | ✓ Gerível | ✓ Gerível | ✗ Exige suporte externo | ✗ Inviável sem parceiro |
| Encomendas firmes >80% da capacidade | ✗ Redundante | ✓ Muito forte | Neutro | Possível |
Trade-offs que nenhum fornecedor menciona na apresentação
O problema da qualidade dos dados de capacidade
Qualquer modelo de sequenciamento pressupõe que o ERP tem dados de capacidade fiáveis: tempo de ciclo por operação, disponibilidade de máquina, número de operadores qualificados por turno. Na prática, estes dados estão frequentemente desatualizados ou simplesmente ausentes. Uma fábrica que nunca registou tempos de operação no ERP não pode implementar sequenciamento por IA em 8 semanas — precisa primeiro de 3-6 meses de recolha de dados via KORA Productivity ou equivalente. Este é o erro mais comum que vemos em projetos que começam pelo modelo e não pelos dados.
Há um detalhe ainda mais subtil que os manuais não referem: os tempos de ciclo no ERP foram muitas vezes inseridos pelo engenheiro de processo na fase de arranque da fábrica, com base em tempos-padrão teóricos. Depois, ninguém os actualizou quando a máquina envelheceu, quando o operador mudou, ou quando a referência ficou mais complexa. O modelo de IA vai aprender esses tempos teóricos como se fossem reais — e vai gerar ordens sistematicamente optimistas. A fábrica não cumpre, o planeador culpa a IA, e o projecto morre. Não por falha do algoritmo, mas por falha de dados que existia antes de o projecto começar.
O paradoxo do calçado em Felgueiras
Uma fábrica de calçado em Felgueiras com uma coleção de 900 referências, três eixos de variação (cor, tamanho, fôrma) e dois momentos de apresentação por ano — compradores de calçado masculino em agosto, feminino em fevereiro — tem um perfil de procura que derrota qualquer modelo de séries temporais clássico. Não há sazonalidade estável: há picos de amostras, depois silêncio, depois explosão de ordens confirmadas em janelas de 3-4 semanas.
Para este perfil, a IA mais útil não é a previsão de procura. É o sequenciamento de ordens confirmadas com restrições de capacidade e de rastreabilidade de lote de materiais. O modelo lê a carteira firme e otimiza a sequência — não tenta adivinhar o futuro. E o agrupamento por família de fôrma — colocar em sequência todas as referências que partilham o mesmo molde antes de mudar — é o ganho mais imediato e menos explorado neste cluster.
Em calçado, prever a procura com IA é o problema errado. Sequenciar 400 ordens confirmadas em 3 semanas com 12 linhas de montagem e 6 fornecedores de sola — esse é o problema certo.
Resistência operacional: o chefe de produção como variável de risco
O maior risco de implementação não é técnico. É o chefe de produção que leva 20 anos a sequenciar ordens de cabeça e que vê o sistema como uma ameaça à sua autoridade. Se o sistema gerar uma sequência que ele considera errada — mesmo que seja matematicamente ótima — e não houver um mecanismo de override documentado e respeitado, o projecto falha por abandono silencioso. Não há reunião de encerramento. O sistema simplesmente deixa de ser aberto.
Configure sempre um modo de sugestão com override manual. O sistema propõe, o planeador valida ou ajusta, e o sistema aprende com o ajuste. Sem este ciclo, a adoção colapsa em semanas. E documente cada override com motivo — não para controlar o planeador, mas porque esses motivos são os dados de treino mais valiosos que o modelo vai receber.
O que funciona na prática: três padrões do setor
Padrão 1 — Começar pelo sequenciamento, não pela previsão
Em fábricas com carteira de encomendas firme superior a 70% da capacidade semanal, a previsão de procura tem pouco valor marginal — o futuro já está confirmado em sistema. O que gera retorno imediato é otimizar a sequência das ordens já existentes. Uma fábrica têxtil de acabamentos no Vale do Ave pode, por exemplo, reduzir o número de mudanças de cor por semana em 30-40% com sequenciamento inteligente, sem alterar um único processo de produção. O ganho é puro: menos purgas, menos desperdício de água e químicos, menos paragens não planeadas. E é um ganho que o chefe de produção consegue ver e medir no próprio dia.
Padrão 2 — Integrar alertas de desvio antes de integrar previsão
Antes de implementar previsão de procura, implemente deteção de desvio em tempo real. Um sistema que alerta quando a linha está a produzir 15% abaixo do ritmo planeado às 10h da manhã tem valor imediato e mensurável: o planeador age ainda dentro do turno. Este padrão é compatível com qualquer ERP que tenha integração com IIoT ou com terminais de registo de produção — e prepara os dados para modelos mais complexos no futuro, porque começa a acumular dados de execução real com timestamp e contexto.
Padrão 3 — Alimentar o modelo com dados de execução real, não de plano
O erro mais subtil, e o mais frequente: treinar o modelo de IA com os dados do plano em vez dos dados de execução real. O plano diz que a operação de costura demora 4 minutos. A execução real, registada em KORA Productivity, mostra 5,3 minutos em média, com desvio padrão de 1,2 minutos. Um modelo treinado com o plano vai gerar ordens sistematicamente optimistas. Um modelo treinado com a execução real vai gerar ordens que a fábrica consegue cumprir. Esta distinção — plano vs. execução — é a diferença entre um projecto de IA que funciona e um que é abandonado ao fim de três meses com a conclusão errada de que "a IA não funciona para o nosso setor".
Como medir o sucesso pós-implementação
Métricas de primeiro nível (operacionais)
- Taxa de cumprimento de prazo (OTD — On-Time Delivery): percentagem de ordens entregues na data confirmada ao cliente. Estabeleça a linha de base antes da IA, meça mensalmente após.
- Número de conflitos de capacidade detetados pelo sistema vs. detetados manualmente: o sistema deve detetar mais, mais cedo.
- Tempo médio de sequenciamento semanal pelo planeador: deve reduzir. Se não reduzir, o sistema não está a ser usado — e isso é informação, não falha técnica.
- Taxa de override manual das sugestões do sistema: acima de 60% indica que o modelo não está calibrado ou que a resistência operacional não foi resolvida.
Métricas de segundo nível (financeiras e de qualidade)
A variação do WIP médio semanal é o indicador financeiro mais direto: um planeamento mais eficiente reduz o trabalho em curso, o que liberta capital de exploração. O custo de setups por semana — mensurável em horas de paragem e consumo de materiais de limpeza ou purga — é o segundo. O terceiro, e o mais ignorado, é a taxa de refugo por ordem correlacionada com a sequência gerada pelo sistema: se certas sequências produzem mais refugo, o modelo precisa de incorporar essa restrição.
Métricas de adoção (as que os projetos ignoram e não deviam)
- Percentagem de planeadores que usam o sistema diariamente sem intervenção de IT.
- Número de pedidos de suporte relacionados com o módulo de IA por mês: deve decrescer após os primeiros 60 dias.
- Satisfação da equipa de produção com a qualidade das ordens geradas: uma pergunta direta, feita mensalmente, vale mais do que qualquer dashboard de KPIs.
O procedimento de implementação: do dado histórico à primeira ordem real
- Audite a qualidade dos dados de capacidade no ERP. Verifique se os centros de trabalho têm tempos de ciclo reais registados, disponibilidade de máquina por turno e operadores qualificados associados. Se estes campos estiverem vazios ou com valores teóricos, inicie a recolha de dados reais antes de avançar para o modelo. Planeie 3-6 meses para esta fase — não 3-6 semanas.
- Defina o horizonte de planeamento e a granularidade. Planeamento diário por turno? Semanal por linha? A IA precisa de saber o que está a otimizar. Horizontes demasiado longos com granularidade fina geram modelos instáveis. Comece com horizonte de 5 dias úteis e granularidade de meio turno.
- Extraia e limpe o histórico de execução real. Mínimo 12 meses de dados de ordens concluídas com tempos reais de início e fim por operação. Elimine outliers com causa conhecida — paragens por avaria, ausências massivas, semanas de Natal. Este passo demora mais do que o esperado: planeie 4-6 semanas, não 4-6 dias.
- Treine o modelo em ambiente de teste com dados históricos. Corra o modelo sobre os últimos 3 meses de histórico e compare as ordens que o modelo teria gerado com as ordens que foram realmente executadas. Meça o desvio. Se o desvio médio for superior a 20%, o modelo precisa de mais dados ou de ajuste de parâmetros antes de entrar em produção.
- Lance em modo de sugestão com override obrigatório durante 60 dias. O sistema gera a sequência, o planeador valida ou ajusta, e cada ajuste é registado com motivo. Este período é de aprendizagem mútua: o modelo aprende com os overrides, e o planeador aprende a confiar no modelo onde ele é consistentemente correto.
- Avalie e decida sobre autonomia parcial. Após 60 dias, analise a taxa de override. Se for inferior a 25% e os overrides se concentrarem em situações específicas — cliente prioritário, avaria pontual, ausência imprevista — configure regras de exceção e passe essas situações para gestão manual. O restante pode correr em modo autónomo com validação diária.
Integração com o ERP e conformidade regulatória
O ERP como fonte de verdade — e os seus limites
O ERP MULTI e o QAD Adaptive ERP são as plataformas onde os dados de ordens, capacidade e materiais residem. A IA de planeamento não substitui o ERP — consome os seus dados e devolve ordens otimizadas que o ERP executa. A integração deve ser bidirecional: o modelo lê do ERP, escreve no ERP, e o ERP regista a execução que alimenta o modelo no ciclo seguinte.
Qualquer integração que passe por exportação manual para Excel e importação manual de volta é um antipadrão. Não escala, não é auditável, e falha precisamente quando a pressão é maior — no fim do mês, quando o prazo de entrega aperta e o planeador já não tem tempo para alimentar ficheiros.
SAF-T e rastreabilidade de decisão
A Portaria 195/2020 obriga à comunicação mensal do SAF-T de faturação. Há uma consequência menos óbvia para o planeamento assistido por IA: as ordens de produção geradas automaticamente têm de ser rastreáveis até à decisão que as originou. Se a AT ou um auditor questionar por que razão uma ordem foi criada com determinada data, a resposta "o sistema gerou" não é suficiente. O sistema tem de registar os parâmetros de entrada — carteira de encomendas, capacidade disponível, restrições de material — que justificam cada ordem. A maioria das soluções de mercado não produz este rasto de decisão por defeito. Verifique antes de assinar o contrato, não depois de o sistema estar em produção. Leia também SAF-T em produção industrial: erros de extracção que o ERP não avisa para entender onde os dados de produção falham antes de chegarem à AT.
AI Act: classificação de risco para sistemas de planeamento
Um sistema de IA que gera ordens de produção e influencia a carga de trabalho de operadores pode ser classificado como risco limitado ao abrigo do Regulamento (UE) 2024/1689. Não é risco alto — mas exige transparência: os utilizadores têm de saber que estão a interagir com um sistema de IA. Configure o interface de forma a que a origem da sugestão seja sempre visível. Não é uma exigência estética — é uma obrigação regulatória que está em vigor desde fevereiro de 2025.
O AI Act não proíbe IA em planeamento industrial. Exige que quem usa saiba que está a usar. Parece óbvio. Não é — especialmente quando o sistema está integrado num ERP que o operador usa há dez anos sem pensar nisso.
Contexto setorial: onde a IA de planeamento tem mais impacto em Portugal
Têxtil e vestuário — Vale do Ave e arredores
No setor têxtil, o planeamento de produção é complicado por três fatores simultâneos: subcontratação extensa (parte da produção sai da fábrica e volta como semiacabado), variabilidade de qualidade de matéria-prima (lotes de fio com variação de título ou cor) e pressão de prazos de marcas internacionais que não aceitam atrasos. A IA de sequenciamento com restrições de subcontratação — que inclui os lead times reais dos subcontratados no modelo, não os lead times nominais do contrato — é o módulo com maior retorno neste cluster.
No setor do vestuário, a variável crítica é a mão de obra: operadores com diferentes níveis de qualificação por operação, absentismo variável, e rotação elevada em certas funções. Um modelo que não inclua a disponibilidade real de operadores qualificados vai gerar ordens que o chão-de-fábrica não consegue executar. Integrar dados de pplPortal — assiduidade, competências por operação — no modelo de planeamento é uma configuração não-óbvia mas determinante. É também a configuração que mais frequentemente fica de fora do âmbito inicial do projecto por ser "demasiado complexa", e que depois explica 40% dos desvios de execução.
Calçado — Felgueiras e Guimarães
No setor do calçado, o problema central é a complexidade de SKU. Uma coleção
Perguntas frequentes
O que é que a IA realmente resolve no planeamento de produção?
A IA não substitui o planeador, mas retira-lhe a conciliação manual de variáveis que o cérebro humano não consegue processar simultaneamente à velocidade industrial. Transforma dados históricos em instruções para o dia seguinte, permitindo que o planeador se foque em decisões estratégicas em vez de cálculos repetitivos.
Por que é que muitos projetos de IA em fábricas portuguesas falham?
Porque tentam implementar IA sobre dados nunca recolhidos com rigor suficiente. O problema não é falta de dados — é falta de dados de execução real. A maioria das fábricas tem registos teóricos no ERP, mas não mecanismos que sintetizem esses dados em decisões de planeamento antes do turno começar.
Qual é a diferença entre dados de plano e dados de execução real?
Dados de plano são valores teóricos inseridos no ERP e raramente atualizados — por exemplo, tempos de ciclo de 2018 que já não refletem a realidade. Dados de execução real são o que a linha realmente fez: tempos efetivos, paragens, refugo, disponibilidade de máquinas. A IA só funciona bem com dados de execução real.
Qual é o módulo de IA com retorno mais rápido em fábricas?
A otimização de sequenciamento de ordens. Determina a sequência ótima de produção minimizando tempos de setup e conflitos de recursos. Em fábricas têxteis com tingimento, por exemplo, reduz significativamente o número de purgas de cor por semana — menos desperdício de água, químicos e paragens não planeadas.
É necessário construir um modelo de IA do zero?
Não. Plataformas como Azure Machine Learning, AWS SageMaker ou Google Vertex AI disponibilizam modelos pré-treinados de séries temporais e otimização que se ligam via API ao ERP. O custo de infraestrutura caiu dramaticamente. O investimento principal está na integração e qualidade dos dados, não no modelo.
Como é que o AI Act português afeta a implementação de IA em planeamento?
O Regulamento (UE) 2024/1689 está em vigor desde agosto de 2024. Sistemas de IA que influenciam decisões de produção com impacto em trabalhadores podem ser classificados como risco limitado ou alto risco. Qualquer implementação deve ser avaliada neste quadro antes de entrar em produção, não depois de estar em modo autónomo.
Um ERP tradicional sem IA consegue fazer planeamento eficaz?
Um ERP sem IA é um livro de atas — regista o que aconteceu. Não projeta o futuro. A IA transforma esse registo em instrução para amanhã. Sem IA, o planeamento fica dependente de previsões lineares e conciliação manual de variáveis que o cérebro humano não consegue processar simultaneamente.
Fontes
- Instituto Nacional de Estatística (INE) — Estatísticas sobre adoção de tecnologias de inteligência artificial em empresas portuguesas (2025)
- Regulamento (UE) 2024/1689 — AI Act (Lei da Inteligência Artificial), em vigor desde agosto de 2024
- Comissão Europeia — EU Strategy for Sustainable and Circular Textiles
- Norma ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system
- ENISA (Agência da União Europeia para a Cibersegurança) — Guidelines on AI Cybersecurity and Safety
