Em 2025, apenas 9,4% das pequenas empresas portuguesas com 10 a 49 trabalhadores usavam inteligência artificial — contra 49,1% das grandes (INE, 2025). A diferença não é de ambição nem de orçamento. É de arquitetura de dados. A maioria das PME industriais portuguesas tem os dados todos: ordens de fabrico, tempos de ciclo, devoluções, absentismo, consumos de matéria-prima. O que não têm é a camada que transforma esse ruído em sinal acionável. E aqui está a tese que este artigo defende: o principal obstáculo à IA na indústria portuguesa não é tecnológico — é a ilusão de que os dados já estão prontos. Não estão. E começar pelo algoritmo antes de resolver essa ilusão é o erro mais caro e mais repetido que vemos no terreno.
O problema não é falta de dados — é falta de dados limpos
Quem já entrou num armazém de distribuição no corredor Lousada-Paços de Ferreira sabe: os dados existem em três sítios diferentes e nenhum concorda com os outros dois. O ERP diz uma coisa, a folha Excel do chefe de armazém diz outra, e o sistema de picking tem um terceiro número. Aplicar IA a esta realidade sem resolver a camada de dados é como instalar câmeras de vigilância apontadas para o chão.
IA aplicada à gestão industrial não começa num modelo de machine learning. Começa na decisão de qual tabela do ERP é a fonte de verdade para o stock.
Antes de avaliar qualquer plataforma, audite quatro dimensões — e seja honesto nos resultados, porque é aqui que a maioria dos projetos falha antes de começar.
Completude. Que percentagem dos registos de produção têm todos os campos preenchidos? Em fábricas têxteis do Vale do Ave, é comum encontrar ordens de fabrico sem tempo real de conclusão: o operador fechou no turno seguinte, a hora ficou errada, e o histórico fica irrecuperável. Um campo em branco não é um dado em falta — é um dado envenenado, porque o modelo vai imputar um valor e ninguém vai saber.
Consistência. O código de artigo no ERP é o mesmo que no sistema de qualidade e no ficheiro de expedição? Em calçado de Felgueiras, é frequente o mesmo SKU ter três nomenclaturas diferentes consoante o sistema — uma herdada do cliente, uma interna, uma do fornecedor de componentes. Divergências de nomenclatura matam qualquer modelo preditivo antes de ele correr a primeira vez.
Granularidade. Tens dados ao nível da operação individual ou só ao nível da ordem? Para prever avarias, precisas de leituras de sensor — não de totais diários. Um total diário de consumo energético não diz nada sobre o padrão de degradação de uma prensa de injeção. Diz apenas que a fábrica consumiu X kWh.
Latência. Os dados chegam em tempo real, em batch diário ou em ficheiro semanal? Um modelo de planeamento de produção alimentado por dados de ontem tem valor limitado quando o cliente liga a pedir adiantamento de entrega. A latência não é um detalhe técnico — é a diferença entre uma decisão e uma reconstituição histórica.
Só depois deste inventário é que a conversa sobre algoritmos faz sentido. O artigo IA aplicada INFOS: transformar dados em decisões automatizadas aprofunda a arquitetura de dados necessária para este passo.
O que mudou para isto ser relevante agora
Três coisas convergiram entre 2022 e 2025 que não existiam antes em simultâneo. Os custos de computação em cloud caíram a ponto de um modelo de previsão de procura ser acessível a uma PME com 40 colaboradores — o que era um projeto de 80 000 euros em infraestrutura própria cabe hoje numa subscrição mensal. Os ERPs verticais passaram a expor APIs REST nativas que permitem integrar camadas analíticas sem projetos de integração de seis meses. E a proliferação de IIoT baixou o custo de instrumentação de máquinas antigas para valores que cabem num orçamento de manutenção normal — um kit de sensores de vibração e temperatura para uma prensa de 20 anos custa hoje o equivalente a dois dias de paragem não planeada.
O que não mudou: a qualidade dos dados históricos. E é por isso que a convergência tecnológica não se traduz automaticamente em adoção. O Eurostat (2025) aponta a falta de competências e conhecimento como o principal obstáculo à adoção de IA em 70,9% das empresas da UE — mas no terreno português, o que vemos é que a competência falta precisamente na gestão dos dados, não na compreensão dos algoritmos.
O papel do AI Act na decisão de arquitetura
O Regulamento (UE) 2024/1689 — AI Act — está em vigor desde agosto de 2024. As proibições de sistemas de alto risco aplicam-se desde fevereiro de 2025. Isto tem consequências práticas que raramente aparecem nas propostas dos fornecedores.
Sistemas de IA que tomam decisões sobre trabalhadores — turnos, avaliação de desempenho, seleção — são classificados como alto risco e requerem documentação técnica, registo no repositório da UE e supervisão humana obrigatória. Modelos de previsão de procura ou de manutenção preditiva aplicados a máquinas, sem decisão sobre pessoas, ficam tipicamente em risco baixo ou mínimo. A distinção parece clara no papel; na prática, um sistema de otimização de turnos que usa dados de produtividade individual está numa zona cinzenta que o vosso jurídico precisa de classificar antes de qualquer RFP.
A escolha entre um modelo desenvolvido internamente e uma solução de um fornecedor certificado tem também implicações de conformidade: quem é o responsável pelo sistema de IA perante o regulador? O fornecedor SaaS que vende o modelo, ou a empresa que o integra nos seus processos de decisão? A resposta afeta o contrato, não apenas a arquitetura. O RGPD (e a Lei 58/2019, que o executa em Portugal) acrescenta uma camada adicional quando os dados processados incluem informação de trabalhadores — o que é quase sempre o caso em sistemas de produção.
Opções técnicas reais: o mapa honesto
Há quatro abordagens distintas para aplicar IA à gestão industrial. Não são fases de maturidade — são opções com trade-offs diferentes. Escolher a errada para a dimensão certa é o erro mais caro que vemos repetido.
| Abordagem | O que faz | Custo de arranque | Tempo até valor | Risco principal | Adequada para |
|---|---|---|---|---|---|
| BI com alertas automáticos | Dashboards com thresholds e notificações | Baixo | 4–8 semanas | Fadiga de alertas se mal configurado | Qualquer dimensão; ponto de partida |
| Modelos preditivos em cloud | Previsão de procura, manutenção, absentismo | Médio | 3–6 meses | Qualidade dos dados históricos | Empresas com 2+ anos de dados limpos no ERP |
| IA embebida no ERP/MES | Sugestões automáticas dentro do fluxo de trabalho | Médio-alto | 6–12 meses | Dependência do roadmap do fornecedor | Empresas com ERP vertical consolidado |
| Plataforma de ML própria | Modelos customizados, MLOps, retreino contínuo | Alto | 12–24 meses | Requer data scientists internos ou parceiro dedicado | Grupos industriais com IT estruturado e >500 colaboradores |
Porque é que a maioria das PME começa pelo sítio errado
O padrão que vemos repetido: a empresa compra uma plataforma de ML porque o concorrente "já tem IA", sem ter resolvido a integração entre o ERP e o sistema de qualidade. Seis meses depois, o projeto está parado à espera de dados que nunca chegam limpos. O investimento certo para uma fábrica com 60 colaboradores e dois anos de histórico no ERP é quase sempre a segunda linha da tabela — modelos preditivos em cloud — alimentados por um Qlik Sense bem configurado como camada de visualização e validação.
Há um erro ainda mais subtil que raramente aparece nas retrospetivas: comprar a abordagem certa, mas para o problema errado. Uma PME de vestuário no Norte que implementa previsão de procura com base em histórico de vendas próprio, sem integrar os dados de sell-through do cliente final, está a prever a sua própria produção com base em encomendas passadas — não em procura real. O modelo vai ser preciso e inútil ao mesmo tempo.
Trade-offs por dimensão de empresa
Dimensão importa — mas não da forma que se pensa. O problema das pequenas empresas não é o custo dos modelos. É o custo de manutenção: quem retreina o modelo quando a linha de produto muda? Quem valida os resultados quando o modelo começa a derivar? Numa PME sem IT dedicado, a resposta honesta é "ninguém" — e um modelo não supervisionado é pior do que uma folha Excel bem mantida.
| Dimensão | Colaboradores | Abordagem recomendada | Pré-requisito crítico | Risco a gerir |
|---|---|---|---|---|
| Micro-industrial | 10–30 | BI com alertas + ERP vertical | ERP com dados consistentes ≥18 meses | Nenhum recurso para manutenção de modelos |
| PME pequena | 30–100 | Modelos preditivos SaaS (procura, absentismo) | Integração ERP-MES funcional | Qualidade de dados históricos; mudança de produto |
| PME média | 100–250 | IA embebida no ERP + MES com OEE preditivo | IT dedicado (1–2 pessoas); dados em tempo real | Dependência do fornecedor; AI Act se envolve RH |
| Grande empresa / grupo | >250 | Plataforma ML própria ou híbrida | Data engineer interno; MLOps; governança de dados | Complexidade de integração multi-site; NIS2 |
O fator que ninguém mete na proposta: o custo de retreino
Um modelo de previsão de procura treinado com dados de 2022–2024 numa fábrica de vestuário do Norte vai começar a errar quando a marca-mãe muda a coleção ou quando entra uma nova referência de tecido. O retreino não é automático na maioria das implementações SaaS de entrada de gama. Pergunte ao fornecedor: quem retreina, com que frequência, e a que custo? Se a resposta for vaga, o custo total de propriedade — o ROI real — está subestimado na proposta.
Há um detalhe operacional que os manuais de implementação raramente referem: o modelo degrada-se mais depressa em empresas com sazonalidade dupla. Uma fábrica de calçado que serve compradores de homem em agosto e de mulher em fevereiro tem dois ciclos de coleção com padrões de procura distintos. Um modelo treinado num ciclo completo de 12 meses pode ter bom desempenho médio anual e erros sistemáticos nos picos — que são precisamente os momentos em que o planeamento mais importa.
Casos de uso com maior retorno na indústria portuguesa
Previsão de procura e planeamento de produção
No calçado de Felgueiras, o planeamento de uma coleção envolve 800 a 1 200 SKUs com três eixos — cor, tamanho, fôrma. Um modelo de previsão que integre histórico de vendas, dados de sell-through do cliente e sazonalidade reduz o erro de previsão e liberta capital em stock. O pré-requisito é ter a rastreabilidade de lote implementada no ERP — sem ela, não há histórico de consumo fiável por referência, e o modelo vai prever com base em agregados que escondem a variabilidade real por eixo de produto.
Manutenção preditiva via IIoT
Numa fábrica de injeção plástica no corredor Aveiro-Marinha Grande, as prensas têm sensores de vibração e temperatura instalados. Integrar esses dados via OPC-UA numa plataforma de análise permite detetar padrões de degradação antes da avaria. O valor não está no algoritmo — está na redução de paragens não planeadas, que em produção por série têm impacto direto no OEE. O KORA Productivity captura estes dados em tempo real e alimenta os dashboards de eficiência operacional. O que raramente se diz: a manutenção preditiva só funciona se a manutenção corretiva estiver bem registada. Se as ordens de trabalho de manutenção não tiverem causa raiz documentada, o modelo não tem sinal — tem ruído com datas.
Gestão de absentismo e turnos com IA preditiva
O absentismo na indústria têxtil e de vestuário do Norte é um problema estrutural — mão de obra envelhecida, trabalho por turnos, sazonalidade. Modelos preditivos de absentismo, quando treinados com histórico de 24 ou mais meses, conseguem antecipar picos com duas a três semanas de antecedência, permitindo ajustar escalas antes do problema. O pplPortal inclui IA preditiva para rotatividade e absentismo — mas só gera valor se os registos de assiduidade estiverem digitalizados e consistentes.
O modelo preditivo de absentismo mais sofisticado do mercado falha se o registo de ponto ainda for feito em papel e introduzido no sistema às sextas-feiras à tarde.
O que funciona na prática: três padrões do setor
Padrão 1 — BI primeiro, IA depois
O padrão mais consistente nas implementações bem-sucedidas que acompanhamos: a empresa começa por consolidar os dados num BI industrial bem configurado, define os KPIs que quer monitorizar, e só depois — com 12 a 18 meses de dados limpos — avança para modelos preditivos. A tentação de saltar esta fase é grande quando o fornecedor de IA promete resultados em oito semanas. Na prática, as oito semanas são de setup; os resultados fiáveis chegam quando os dados chegam. E a fase de BI não é um pré-requisito burocrático — é o momento em que a empresa aprende quais os dados que realmente usa para decidir, o que é diferente dos dados que recolhe por hábito.
Padrão 2 — Caso de uso único, bem definido
Uma fábrica têxtil de média dimensão no Vale do Ave que queira aplicar IA deve começar por um único caso de uso: previsão de consumo de fio por referência de malha, integrada com o planeamento de compras do ERP. Não um projeto de "transformação digital com IA" — um problema específico, com uma métrica de sucesso clara (redução de rutura de matéria-prima), e um dono interno que responde pelos resultados. Este foco é o que separa os projetos que chegam a produção dos que morrem em piloto. O dono interno não precisa de saber machine learning. Precisa de saber o que é uma rutura, quando acontece, e quanto custa — e de ter autoridade para mudar o processo quando o modelo sugere uma compra antecipada.
Padrão 3 — Supervisão humana estruturada
Os projetos que falham silenciosamente têm um traço comum: o modelo começa a produzir sugestões, ninguém as valida sistematicamente, e ao fim de três meses ninguém sabe se o modelo ainda está a funcionar bem. Configure um processo de revisão mensal — o gemba digital: o responsável de produção compara as sugestões do modelo com o que realmente aconteceu, identifica desvios, e escala para retreino quando necessário. Sem este ciclo, a IA degrada-se em silêncio. E quando alguém finalmente repara, o dano já está feito em decisões de compra, de stock ou de planeamento que ninguém questionou porque "o sistema disse".
Como medir o sucesso pós-implementação
Defina as métricas antes do arranque — não depois. As mais relevantes para IA aplicada à gestão industrial são quatro.
O erro de previsão (MAPE) mede a precisão dos modelos de procura e planeamento. Um MAPE abaixo de 15% em categorias estáveis é um bom referencial para a maioria dos setores industriais portugueses — mas em calçado com 800 SKUs e sazonalidade dupla, exija o MAPE por cluster de produto, não o agregado, que pode esconder erros sistemáticos nas referências de maior volume.
A taxa de adoção das sugestões diz o que o MAPE não diz: se os operadores confiam no modelo. Abaixo de 40% de aceitação, o modelo não é confiável — ou a interface é má, ou os operadores sabem algo que o modelo não sabe. Ambas as hipóteses merecem investigação antes de retreino.
O tempo entre anomalia e deteção é o indicador central para manutenção preditiva: com quantos dias de antecedência o sistema deteta o padrão de degradação antes da paragem efetiva. Este número deve ser comparado com o tempo médio de reparação — se o sistema deteta 6 horas antes e a reparação demora 8 horas, o valor é limitado.
A variação do OEE é o indicador agregado que capta o efeito combinado de disponibilidade, desempenho e qualidade. Acompanhe-o no Qlik Sense com os KPIs industriais certos — e compare sempre com o período homólogo, não com o mês anterior, para isolar o efeito da sazonalidade.
O erro de medição mais comum
Medir o sucesso do projeto de IA pelo número de modelos em produção. Não é isso. É pelo impacto nas métricas operacionais que existiam antes do projeto. Se o OEE não melhorou, se o stock de matéria-prima não reduziu, se o absentismo não foi antecipado com mais eficácia — o projeto não foi bem-sucedido, independentemente de quantos dashboards estão a correr.
Conformidade e cibersegurança: o que não pode ignorar
A Diretiva NIS2 (Diretiva (UE) 2022/2555, transposta para Portugal pelo DL 65/2025) classifica operadores de infraestrutura industrial crítica como entidades sujeitas a requisitos reforçados de cibersegurança. Sistemas de IA ligados a redes de produção ampliam a superfície de ataque — um modelo de manutenção preditiva que comunica com PLCs via rede industrial é um vetor de entrada potencial para ransomware. Verifique com o responsável de cibersegurança a segmentação de rede antes de ligar qualquer sistema de IA à rede de OT.
Há um ponto que raramente aparece nas avaliações de risco: os modelos de IA treinados com dados de produção são, eles próprios, ativos de informação sensível. Um modelo de previsão de procura treinado com três anos de histórico de encomendas de um cliente internacional contém informação estratégica sobre a relação comercial. A política de retenção e acesso a esses modelos deve estar coberta pela política de segurança da informação — não apenas o acesso aos dados brutos.
A segurança de um sistema de IA industrial não se avalia pelo modelo — avalia-se pela rede em que corre e pelos acessos que tem ao chão de fábrica.
Próximos passos: o que fazer esta semana
- Audite a qualidade dos dados no ERP: selecione uma entidade — ordens de fabrico ou movimentos de stock — e verifique a taxa de completude dos campos críticos nos últimos 24 meses. Se for abaixo de 85%, o projeto de IA começa aqui, não nos algoritmos.
- Identifique um caso de uso com dono: escolha um problema operacional com uma métrica clara e uma pessoa responsável pelo resultado. Sem dono, não há projeto — há piloto eterno.
- Classifique o risco AI Act: determine se o sistema que quer implementar envolve decisões sobre trabalhadores. Se sim, envolva o jurídico antes de avançar para RFP.
- Verifique a integração ERP-MES: confirme que o ERP expõe os dados necessários via API ou ficheiro estruturado. Um ERP MULTI bem configurado ou um QAD Adaptive ERP com as integrações ativas é o pré-requisito técnico para qualquer camada de IA.
- Defina o processo de supervisão: antes de colocar qualquer modelo em produção, documente quem valida as sugestões, com que frequência, e o que acontece quando o modelo erra. Este documento é mais importante do que a escolha da plataforma.
Para o contexto mais amplo de como a IA se integra na estratégia digital industrial, leia o artigo IA aplicada à gestão empresarial: guia para começar com casos de uso reais. Para a perspetiva operacional de automação de processos no contexto português, o guia operacional de automação de processos em indústria portuguesa complementa o que aqui ficou por desenvolver. E para os KPIs que o diretor de operações deve monitorizar diariamente, o artigo respetivo dá o quadro de medição em que os modelos de IA devem ser avaliados.
A diferença entre uma empresa que "tem IA" e uma que usa IA para decidir melhor é, quase sempre, a qualidade do trabalho feito antes de o primeiro modelo correr. E esse trabalho não é glamoroso: é limpar tabelas, alinhar nomenclaturas, convencer o chefe de armazém a fechar as ordens no turno certo. Quem faz esse trabalho primeiro chega ao modelo mais depressa — e com resultados que duram.
Fontes
- INE — Instituto Nacional de Estatística. Inquérito à Utilização de Tecnologias da Informação e da Comunicação nas Empresas 2025. Lisboa: INE, 2025.
- Eurostat. ICT usage in enterprises — Artificial intelligence. Luxemburgo: Comissão Europeia, 2025.
- Comissão Europeia. Regulamento (UE) 2024/1689 do Parlamento Europeu e do Conselho — AI Act. Jornal Oficial da União Europeia, 12 de julho de 2024.
- Parlamento Europeu e Conselho da UE. Diretiva (UE) 2022/2555 — NIS2. Jornal Oficial da União Europeia, 27 de dezembro de 2022.
- McKinsey & Company. The State of AI: How organizations are rewiring to capture value. McKinsey Global Survey, 2025.
Perguntas frequentes
Por que razão a maioria das PME industriais portuguesas não consegue implementar IA com sucesso?
O principal obstáculo não é tecnológico, mas a qualidade dos dados. A maioria das PME tem dados dispersos em múltiplos sistemas (ERP, Excel, sistemas de picking) que não coincidem entre si. Sem resolver esta camada de dados — completude, consistência, granularidade e latência — qualquer modelo de IA falha antes de começar.
O que significa "dados envenenados" no contexto da IA industrial?
São campos em branco ou preenchidos incorretamente nos registos de produção. Um operário que fecha uma ordem de fabrico no turno seguinte com hora errada cria um dado envenenado. O modelo de IA vai imputar um valor arbitrário, comprometendo toda a previsão. Um campo vazio não é apenas uma falta — é um erro ativo.
Como auditar a qualidade dos dados antes de implementar IA?
Avalie quatro dimensões: Completude (que percentagem de registos tem todos os campos?), Consistência (o código de artigo é igual em todos os sistemas?), Granularidade (tem dados ao nível da operação ou apenas totais diários?) e Latência (os dados chegam em tempo real ou em batch semanal?). Esta auditoria determina se o projeto viável ou condenado.
Qual é a diferença entre um modelo de previsão de procura e um sistema de avaliação de desempenho segundo o AI Act?
Um modelo de previsão de procura é classificado como risco baixo ou mínimo. Um sistema que toma decisões sobre trabalhadores — turnos, avaliação de desempenho — é alto risco e requer documentação técnica, registo no repositório da UE e supervisão humana obrigatória. A distinção afeta conformidade legal e contratação.
Por que razão a latência dos dados é crítica para decisões de produção?
Um modelo alimentado por dados de ontem não consegue responder a pedidos de adiantamento de entrega feitos hoje. A latência não é um detalhe técnico — é a diferença entre uma decisão acionável e uma reconstituição histórica. Para planeamento dinâmico, os dados precisam de estar disponíveis em tempo real ou batch diário máximo.
O que mudou entre 2022 e 2025 que torna a IA viável para PME industriais?
Três convergências: custos de computação em cloud caíram drasticamente (modelos de previsão agora cabem em subscrições mensais); ERPs verticais expõem APIs REST nativas (sem projetos de integração de seis meses); e sensores IIoT ficaram acessíveis (instrumentação de máquinas antigas cabe no orçamento de manutenção). Mas a qualidade dos dados históricos não melhorou.
Quem é responsável pela conformidade de um sistema de IA segundo o AI Act — o fornecedor ou a empresa?
Depende do contrato e da arquitetura. Se é uma solução SaaS de um fornecedor certificado, há responsabilidades partilhadas. Se desenvolveu internamente, a empresa é responsável. Esta distinção afeta não apenas a conformidade legal, mas também o contrato, o seguro e a auditoria. Deve ser clarificada antes de qualquer RFP.
