A resposta curta
As aplicações de IA que funcionam numa PME industrial são pequenas, resolvem uma tarefa que já existe e usam dados que a fábrica já regista. Não começam por “onde podemos usar IA?”, mas por “que tarefa nos custa tempo ou dinheiro todas as semanas?”.
Há muita conversa sobre inteligência artificial na indústria, e pouca sobre o que cada aplicação exige. Neste artigo descrevo seis aplicações que vejo fazerem sentido numa PME, cada uma com o que precisa para funcionar e o que pode correr mal. Depois conto um caso real e proponho uma forma simples de escolher o primeiro caso de uso.
Para o enquadramento geral (o que é preciso ter antes de começar, riscos e confidencialidade, quando a IA não é a resposta), o guia inteligência artificial na indústria é o ponto de partida.
Seis aplicações, com o que cada uma exige
Cada aplicação tem um custo escondido: os dados de que precisa e a pessoa que a mantém. É isso que convém avaliar antes de começar, mais do que a tecnologia.
1. Ler relatórios de qualidade e avisar quando algo sai dos limites
A ferramenta lê os relatórios de controlo à medida que chegam, calcula médias, desvio padrão e índices de capacidade como o Cp e o Cpk, e avisa quando uma variável sai dos limites ou se aproxima deles.
- Exige: relatórios com estrutura estável, ligados à ordem de fabrico, e limites definidos por variável.
- Pode correr mal se: os limites forem mal definidos (alertas a mais acabam ignorados) ou se ninguém tiver a responsabilidade de reagir ao alerta.
2. Comparar o consumo teórico com o real
A ferramenta compara o material que cada ordem devia consumir com o que consumiu de facto, por máquina, e mostra onde está a diferença: excesso de material por peça (giveaway), purgas, arranques, sobras.
- Exige: consumos teóricos por produto (a receita ou a ficha técnica) e registo do material realmente consumido.
- Pode correr mal se: o consumo real for estimado e não medido. Nesse caso, a ferramenta só compara duas estimativas.
3. Relatório semanal automático, com resumo em texto
O relatório que alguém monta à mão todas as semanas passa a sair sozinho, a partir das fontes que já existem. A IA ajuda a escrever e testar o código da automação e, se for útil, a redigir um parágrafo de resumo a partir dos números.
- Exige: fontes de dados acessíveis e com estrutura estável.
- Pode correr mal se: a IA for usada para calcular os números. Os números calculam-se com regras fixas; a IA só escreve sobre eles, e o resumo é verificado. Desenvolvo este caso no artigo sobre como automatizar o relatório semanal de produção.
4. Arrumar registos escritos em texto livre
Muitas fábricas têm anos de registos de paragens ou de defeitos escritos à mão, cada pessoa à sua maneira. Um modelo de linguagem consegue ler essas descrições e propor uma classificação numa lista fechada de causas, o que permite fazer um Pareto com dados que antes eram ilegíveis em conjunto.
- Exige: uma lista de causas definida por quem conhece o processo e uma amostra classificada à mão para comparar.
- Pode correr mal se: a classificação for aceite sem verificação. Convém rever uma amostra e corrigir as regras antes de confiar no resultado.
5. Apoio a instruções de trabalho e formação
Um assistente de texto ajuda a passar a escrito o que a equipa já sabe: instruções de trabalho, checklists, perguntas de verificação para a formação, versões simplificadas para quem chega de novo.
- Exige: alguém que conheça a operação e reveja tudo o que é produzido.
- Pode correr mal se: a instrução for publicada sem revisão. Os assistentes escrevem com confiança mesmo quando estão errados.
6. Pequenas ferramentas internas, feitas mais depressa
Com assistentes de programação, uma pessoa que conhece o processo consegue construir uma aplicação de registo, um painel ou um cálculo em muito menos tempo do que antes.
- Exige: regras do processo claras e alguém que saiba testar se a ferramenta faz o que deve.
- Pode correr mal se: a ferramenta ficar a depender de uma só pessoa, sem documentação. Uma ferramenta que ninguém percebe torna-se um risco no dia em que falha.
Um caso real: a ferramenta de qualidade dimensional
Numa fábrica de cabos, desenvolvi com apoio de IA uma ferramenta que lê os relatórios de qualidade das linhas de extrusão e avisa quando algo precisa de atenção. Antes, os relatórios (diâmetros, espessuras, excentricidades) eram guardados e só consultados depois de um defeito ou de uma reclamação. Os dados existiam. Faltava lê-los.
O primeiro passo não teve IA nenhuma: normalizar a forma como os relatórios eram gerados, para cada um ficar ligado à sua ordem de fabrico. Sem isso, não havia análise possível.
Depois, a ferramenta passou a seguir este fluxo:
- O relatório chega a uma pasta partilhada, já ligado à ordem de fabrico.
- A ferramenta deteta sozinha o ficheiro novo.
- Identifica a estrutura, trata os cabeçalhos e normaliza os dados.
- Calcula médias móveis, desvio padrão e Cp/Cpk.
- Compara com os limites de cada variável e classifica a produção: conforme, alerta de sobreconsumo ou não conforme.
- Atualiza os indicadores e emite um alerta quando algo precisa de atenção.
Com a mesma lógica, uma segunda ferramenta compara o consumo teórico de material com o real em cada máquina, calcula o giveaway e as purgas e mostra num Pareto onde estão as maiores perdas.
As duas ferramentas foram feitas com apoio de assistentes de programação (Lovable e Claude Code). Não usam aprendizagem automática nem tomam decisões sozinhas: aplicam regras e limites definidos a partir do processo, e por isso percebe-se sempre porque é que cada alerta aparece.
A IA encurtou muito o tempo entre a ideia e a ferramenta. Mas os indicadores, os limites e os critérios de alerta vieram de quem conhece o processo. A IA escreve o código; o processo define as regras. O caso completo está em ferramentas de análise de dados de qualidade, desenvolvidas com IA.
Como escolher o primeiro caso de uso
Escolha a tarefa que poupa mais tempo com os dados que já tem, com risco baixo e um resultado fácil de medir. Uma grelha simples, preenchida com quem conhece a fábrica, ajuda a decidir sem discussões intermináveis.
Dê a cada candidato uma nota de 1 (mau) a 3 (bom) em quatro critérios. Um exemplo ilustrativo, com notas inventadas para mostrar o método:
| Candidato | Tempo ou dinheiro poupado | Dados já disponíveis | Risco baixo | Fácil de medir | Total |
|---|---|---|---|---|---|
| Relatório semanal automático | 2 | 3 | 3 | 3 | 11 |
| Alertas de qualidade | 3 | 2 | 2 | 2 | 9 |
| Classificar registos em texto livre | 2 | 2 | 3 | 2 | 9 |
| Prever avarias de uma máquina | 3 | 1 | 1 | 1 | 6 |
Neste exemplo, o relatório automático ganha: poupa menos do que os alertas de qualidade, mas os dados já existem, o risco é baixo e o ganho mede-se em horas por semana. A previsão de avarias, que costuma ser a primeira ideia, fica em último, porque não há histórico de dados suficiente para a sustentar.
Os critérios podem mudar de fábrica para fábrica. O que importa é decidir com critérios escritos, e não pela aplicação que parece mais impressionante.
O que muda no dia a dia de quem usa
Uma ferramenta de IA bem feita tira trabalho repetitivo, mas acrescenta uma responsabilidade nova: alguém tem de reagir ao que ela mostra e mantê-la a funcionar. Convém decidir isso antes, e não depois.
Três perguntas que faço sempre antes de construir uma ferramenta:
- Quem olha para o resultado, e quando? Um alerta que chega a uma caixa de correio que ninguém lê não serve para nada.
- O que se faz quando há um alerta? Se não há uma reação definida, o alerta vira ruído.
- Quem trata da ferramenta quando uma fonte de dados muda? Os relatórios mudam de formato, as máquinas mudam, as pessoas mudam. Alguém na empresa tem de saber o que fazer, com documentação simples.
Durante as primeiras semanas, a ferramenta nova corre lado a lado com o processo antigo. Só se desliga o antigo quando os resultados batem certo.
No caso real que descrevi acima, as ferramentas ficaram prontas e funcionais, mas a utilização corrente dependia de dois passos da organização: definir no sistema os limites de cada variável e encaminhar automaticamente os relatórios das máquinas para a pasta de entrada. A disponibilidade técnica de uma ferramenta não chega para ela entrar no dia a dia. Hoje combino esses passos, e quem os faz, logo no arranque do projeto.
Erros comuns
O erro mais comum é começar pela tecnologia em vez de começar pela tarefa, e o segundo é tentar usar IA antes de arrumar os dados.
- Começar pela ferramenta da moda. Um projeto que começa com “temos de usar IA” acaba muitas vezes à procura de um problema para resolver.
- Saltar o passo zero. Sem dados ligados à máquina, à ordem e ao turno, a melhor IA não tem nada para ler.
- Pôr dados confidenciais em ferramentas externas sem regras. Desenhos, receitas, preços e dados de clientes não devem sair da empresa sem uma decisão explícita.
- Confiar sem verificar. O que a IA produz é revisto por quem conhece o processo, sobretudo no início.
- Deixar a ferramenta sem dono. Uma ferramenta que só uma pessoa percebe é um risco.
Por onde começar
Comece por uma tarefa concreta que custe tempo hoje e que use dados já registados; quase sempre, é um relatório ou um indicador. É um primeiro caso de uso com retorno visível e risco baixo, e ensina o que é preciso para o seguinte.
A automação de relatórios é muitas vezes o primeiro passo, seguida de dashboards e KPIs de produção que se atualizam sozinhos. Para as chefias usarem IA no dia a dia com regras claras sobre os dados, a formação in-company inclui Excel e IA aplicados ao trabalho de cada um.