IA na manutenção industrial só pode ser avaliada depois que o problema operacional está definido. Programar ordens contra capacidade, consultar conhecimento técnico e estimar uma condição futura são trabalhos diferentes, com dados, riscos e critérios de validação próprios. Colocar os três sob o mesmo rótulo de IA esconde justamente o que o comprador precisa comparar.
Este guia organiza a decisão por caso de uso, mostra o que deve ser demonstrado antes da contratação e separa o escopo documentado da PM Run das aplicações especializadas que exigem outro projeto de engenharia.
Comece pelo trabalho que a IA precisa melhorar
Uma avaliação técnica começa com uma tarefa observável e uma medida de resultado. “Usar IA na manutenção” não define nenhuma das duas. “Reduzir o tempo de programação semanal sem alocar uma operação a alguém sem a habilidade exigida” já define o trabalho, a restrição e parte do teste.
O AI Risk Management Framework do NIST recomenda avaliar sistemas de IA no contexto específico de uso, com validação, monitoramento, transparência e possibilidade de intervenção humana proporcionais ao risco. Na manutenção, esse contexto inclui criticidade do ativo, consequência de uma decisão errada, qualidade do dado disponível e quem responde pela decisão final.
Na prática, três problemas aparecem com frequência nas conversas de manutenção. Eles não devem ser comprados nem validados da mesma forma.
1. Programação e alocação de ordens
O problema é combinatório: existem ordens com duração, prioridade, janela e habilidade exigida, enquanto a equipe tem turnos, ausências, capacidade e qualificações diferentes. Uma ferramenta pode sugerir uma distribuição que respeite essas restrições e deixar a decisão final com o planejador.
Este é o uso de IA documentado na PM Run. No Planejamento, a função “Alocar com a Manu” sugere a alocação das ordens com base em habilidade, capacidade e disponibilidade. O planejador define o período, analisa o resultado, ajusta o que for necessário e só integra a programação ao SAP depois da confirmação. O escopo é sugestão de alocação, sem previsão de falha e sem decisão autônoma sobre o ativo.
Uma demonstração séria precisa usar um recorte de ordens e recursos que contenha conflitos reais. O teste deve responder:
- A sugestão respeitou habilidade, turno, ausência e capacidade disponível?
- O planejador consegue identificar por que uma pessoa recebeu determinada operação?
- Uma restrição descumprida fica visível antes da integração?
- O usuário consegue alterar a sugestão e manter a responsabilidade pela programação?
- O resultado confirmado chega ao SAP pelo fluxo documentado?
Quem quer ver o escopo funcional dessa aplicação encontra os detalhes na página da PM Run Planejamento.
2. Assistentes para consultar conhecimento
Um assistente pode reduzir o tempo de busca em procedimentos, manuais e bases internas. O valor depende menos da fluência da resposta e mais da origem que ela consegue mostrar. Em manutenção, uma resposta plausível sem referência pode levar a uma intervenção inadequada ou ao uso incorreto de um requisito normativo.
O teste precisa usar perguntas cuja resposta já seja conhecida e documentada. Para cada resposta, verifique se o assistente:
- aponta o documento e o trecho que sustentam a orientação;
- distingue procedimento interno, manual do fabricante e requisito normativo;
- declara quando a base não contém informação suficiente;
- respeita versão, unidade, planta e perfil de acesso;
- não transforma conteúdo geral em autorização para executar uma tarefa crítica.
O assistente apoia a consulta. A aprovação de procedimento, a interpretação normativa e a decisão sobre o ativo continuam com os responsáveis técnicos definidos pela empresa.
3. Detecção de anomalia e previsão de condição
Este caso exige um projeto próprio. Antes de falar em modelo, a engenharia precisa definir a função do ativo, o modo de falha, a variável capaz de indicar degradação, a técnica de medição, o histórico disponível e o tempo necessário para reagir. Vibração, óleo, ultrassom, temperatura e variáveis de processo enxergam fenômenos diferentes. Um conjunto de ordens encerradas no SAP, sozinho, não substitui esses sinais quando o objetivo é detectar a condição física de um componente. O guia de manutenção preditiva detalha essa disciplina.
O guia de manutenção centrada em confiabilidade da NASA trata inspeção preditiva como seleção de tarefas aplicáveis aos modos de falha e às suas consequências. A técnica e o intervalo dependem do equipamento, da aplicação, do ambiente e da capacidade de detectar a degradação com antecedência útil.
Por isso, “preditiva pronta para instalar” é uma descrição insuficiente. O fornecedor precisa declarar:
- qual modo de falha o modelo tenta detectar;
- quais sinais entram e com qual frequência;
- como foi estabelecida a condição de referência;
- qual taxa de falso alarme e de falha não detectada apareceu no teste;
- quanto tempo útil existe entre o alerta e a intervenção;
- quem valida o alerta e qual ação operacional ele dispara.
A PM Run não oferece IA preditiva, sensor ou gêmeo digital como módulo documentado. Quando a planta tem um projeto especializado de monitoramento de condição, a ordem, a programação e o registro da intervenção continuam precisando entrar na rotina de manutenção e no SAP PM.
Análise de histórico não vira IA por usar um algoritmo
Ordens, notas, causas, sintomas, tempos e custos permitem análises importantes: recorrência por classe de equipamento, desvio de tempo de reparo, concentração de retrabalho e backlog por criticidade. Muitas dessas perguntas são atendidas com estatística, regras e analytics bem construído. Chamar toda análise de IA dificulta entender qual decisão melhorou e como o resultado foi validado.
A PM Run entrega os dados de manutenção preparados e automatizados para que a empresa construa o próprio painel de indicadores. Isso sustenta análise de MTTR, MTBF, backlog, custo, ocupação e produtividade, conforme a necessidade da operação. Esse painel personalizável não deve ser confundido com um modelo que prevê falha.
Para organizar a base antes de escolher qualquer camada analítica, veja o guia de gestão da manutenção.
O dado necessário muda conforme o caso de uso
Não existe um único “dado para IA”. A alocação precisa de ordens, duração, habilidade, capacidade, turno e disponibilidade. Um assistente precisa de documentos íntegros, versionados e autorizados. Um modelo de condição precisa dos sinais físicos relevantes ao modo de falha, além do contexto de operação.
O apontamento de campo continua central porque fecha o ciclo de execução: registra quando o trabalho ocorreu, quem executou, o que foi encontrado e qual ação foi realizada. Ele melhora indicadores e permite comparar a sugestão com o resultado. Isso não significa que todo modelo precise ser treinado no histórico de ordens da planta.
Se a ordem é confirmada de memória no fim do turno, causa e tempo deixam de representar o trabalho real. Antes de procurar uma aplicação de IA, vale corrigir esse fluxo dentro da rotina de Planejamento e Controle da Manutenção.
Roteiro de validação antes da compra
- Defina a decisão. Escreva qual tarefa será apoiada, quem decide e qual erro seria inaceitável.
- Nomeie as entradas. Liste campos, sinais, documentos, frequência, origem e responsável pela qualidade.
- Estabeleça uma referência. Compare o resultado com o processo atual e com casos cuja resposta seja conhecida.
- Teste exceções. Inclua ausência, dado faltante, ordem urgente, equipamento fora do padrão e conflito de restrição.
- Meça o erro relevante. Tempo economizado não compensa alocação inválida, alerta perdido ou orientação sem fonte.
- Defina supervisão e retorno. Determine quem confirma, como corrige e como o desempenho será acompanhado depois da implantação.
O documento completo do NIST AI RMF 1.0 reforça que validade e confiabilidade precisam ser verificadas no contexto de uso e monitoradas ao longo do ciclo de vida. Uma demonstração genérica confirma apenas que a interface funciona no cenário preparado pelo fornecedor.
Perguntas Frequentes
A PM Run tem IA preditiva?
Não como módulo documentado. A aplicação de IA documentada na PM Run é a Manu, que sugere a alocação de ordens no Planejamento com base em habilidade, capacidade e disponibilidade. Sensor, previsão automática de falha e gêmeo digital exigem soluções e projetos específicos.
A Manu decide a programação sozinha?
Não. O planejador seleciona as ordens e o período, recebe a sugestão, analisa o resultado e pode ajustá-lo. As atividades só seguem para o SAP quando o usuário aciona a integração.
Um histórico de ordens é suficiente para prever falha?
Não em todos os casos. O histórico ajuda a analisar recorrência, tempos, causas registradas e resultado das intervenções. Prever a condição física de um componente pode exigir vibração, óleo, ultrassom, temperatura ou outra variável ligada ao modo de falha.
Como comparar dois fornecedores de IA para manutenção?
Compare o mesmo caso de uso, com as mesmas entradas, restrições e critérios de erro. Exija o escopo documentado, a origem dos dados, o comportamento diante de exceções, a forma de supervisão humana e a medição do resultado no contexto da sua planta.
Por onde começar?
Escolha uma decisão delimitada, confirme que os dados necessários existem e monte um teste com resultado conhecido. Para programação de ordens, o recorte pode ser uma semana real com conflitos de habilidade e capacidade. Para condição de ativo, o recorte começa num modo de falha e numa técnica de detecção definidos pela engenharia.
Grupo de Estudos Avançados da PM Run
O GEA, Grupo de Estudos Avançados da PM Run, reúne encontros exclusivos para convidados, com foco em clientes e parceiros. Clientes e parceiros garantem o convite com o executivo de contas. Quem ainda não é cliente pode procurar o time comercial para conhecer a iniciativa.
