Agente de superinteligência em manutenção

Um agente de superinteligência em manutenção é, na prática, um agente de IA que lê o histórico dos ativos e das ordens de serviço, sugere preventivas e propõe a prioridade dos chamados, enquanto o técnico e o planejador continuam decidindo. O termo superinteligência é mais rótulo comercial do que descrição técnica: o que a empresa opera é um sistema com dados, regras, ferramentas limitadas e registro de decisões. O ganho vem da qualidade do histórico e do desenho da decisão, não do nome.

Principais pontos

• O agente é tão útil quanto o histórico: ativos bem cadastrados, ordens com causa e ação registradas e peças consumidas.
• Ele sugere e justifica com evidência; o técnico ou o planejador aprova, ajusta ou recusa, e a recusa também vira dado.
• Preventiva boa nasce de falha repetida, uso e criticidade, não de um calendário genérico aplicado a todos os equipamentos.
• A priorização de chamados precisa de critérios escritos antes de qualquer modelo, e gatilhos de segurança devem escalar para uma pessoa por regra fixa.
• Comece por uma família de ativos e um fluxo, com log e métrica combinada, e só depois decida se expande, ajusta ou para.

O que esse agente faz de fato, e o que não faz

O agente recebe um chamado ou um pedido de revisão do plano, consulta o cadastro do ativo e as ordens anteriores, e devolve uma proposta com justificativa: qual a prioridade sugerida, o que checar primeiro, que peças costumam estar envolvidas e se o caso indica ajustar a preventiva. Quem lê a proposta vê de onde ela veio, com as ordens citadas.

O que ele não faz também precisa estar escrito. Ele não confirma diagnóstico, não libera equipamento para operar, não fecha ordem sozinho e não altera o plano de manutenção sem aprovação. Em segurança de pessoas, a decisão é sempre humana e imediata.

A documentação da Anthropic sobre construção de agentes eficazes distingue fluxos de trabalho previsíveis de agentes que decidem os próprios passos, e recomenda a solução mais simples que resolva o problema. Em manutenção isso se traduz bem: a maior parte do fluxo (receber chamado, identificar ativo, buscar histórico, registrar) é determinística. A IA entra onde há julgamento sobre texto livre e padrões, como interpretar a descrição de um sintoma ou comparar falhas parecidas. Para entender por que o rótulo engana, vale ler a diferença entre AGI e superinteligência.

Que dados alimentam o agente?

Três grupos de informação sustentam o agente, e o terceiro costuma ser o mais frágil.

• Cadastro do ativo: tag ou identificação, local, fabricante, modelo, data de instalação, criticidade para a operação e se existe equipamento reserva.
• Ordens de serviço: data de abertura, sintoma descrito, tipo (corretiva, preventiva, inspeção), causa encontrada, ação executada, peças usadas, tempo parado e quem executou.
• Plano atual: tarefas preventivas, periodicidade, responsáveis e o que cada tarefa pretende evitar.

Além disso entram manuais, procedimentos e eventuais leituras de campo, como horímetro ou resultado de inspeção. Sensores ajudam, mas não são pré-requisito para começar.

O texto livre é onde a IA mais ajuda: o mesmo sintoma aparece como barulho, ruído estranho, batendo ou vibrando, e o agente consegue agrupar essas descrições. Mas ele só agrupa o que está escrito. Ordens fechadas com a frase serviço realizado, sem causa nem ação, não ensinam nada a ninguém, humano ou máquina. Antes de qualquer piloto, vale olhar uma amostra de ordens e medir quantas têm causa e ação utilizáveis.

Na prática, o agente não precisa decorar o histórico. Ele busca as ordens relevantes no momento da consulta e trabalha só com elas, o que mantém o contexto enxuto e as respostas rastreáveis. A Anthropic descreve essa preocupação em seu material sobre engenharia de contexto para agentes.

Como o agente sugere preventivas

A sugestão de preventiva segue um raciocínio que um planejador reconheceria. O agente agrupa falhas por ativo e por componente, observa o intervalo entre ocorrências, compara com o que o plano já prevê e propõe uma de quatro ações: criar uma tarefa, antecipar uma existente, adiar ou revisar o escopo, ou sugerir a retirada de uma tarefa que nunca encontra problema.

Cada proposta deve separar três tipos de informação, em linha com a política de autoria que adotamos:

• Documentação oficial: o que o manual do fabricante recomenda para aquele modelo.
• Experiência da planta: o que o histórico de ordens mostra naquele equipamento específico.
• Hipótese do agente: a interpretação dele sobre a relação entre os dois, marcada como hipótese.

Essa separação evita um erro comum: tratar uma correlação do histórico como se fosse regra do fabricante. Se três ordens de desarme do mesmo motor tiveram a troca do mesmo contator, isso é um indício forte para investigar, não uma causa comprovada. O planejador decide se a evidência justifica uma nova tarefa, e a decisão fica registrada junto da proposta.

Como o agente prioriza chamados

Priorizar é aplicar critérios que a empresa precisa ter definido antes. O agente aplica esses critérios com consistência e explica o resultado, mas não inventa critério novo. Um guia de decisão simples, em ordem de peso:

• Segurança de pessoas e meio ambiente: vazamento, fumaça, risco elétrico, falha em equipamento de proteção. Regra fixa, escala para um responsável sem esperar o modelo.
• Criticidade do ativo: a parada derruba a operação, o atendimento ao cliente ou a conformidade?
• Existência de reserva: há outro equipamento cobrindo enquanto este é reparado?
• Histórico recente: o ativo falhou de forma parecida há pouco tempo?
• Disponibilidade: peça em estoque, técnico habilitado e janela de parada.
• Compromissos externos: prazo contratual ou acordo de nível de serviço com cliente.

O agente devolve uma prioridade sugerida com os critérios que a motivaram. O responsável pode manter, subir ou baixar, e o motivo da mudança fica no log. Com o tempo, essas correções mostram onde o critério escrito está ambíguo e onde o agente erra.

Um cuidado importante: chamados chegam por WhatsApp, e-mail ou formulário, e o texto é livre. Esse texto pode conter instruções que não vieram da empresa, por engano ou de propósito. A lista OWASP Top 10 para aplicações com LLM trata esse risco, e a regra prática é simples: o conteúdo do chamado é dado a ser interpretado, nunca comando a ser obedecido.

Cenário ilustrativo: chamado de compressor com desarme

Este é um cenário ilustrativo, sem relação com cliente real. Uma indústria de alimentos tem câmaras frias atendidas por dois compressores. Um operador envia no WhatsApp: compressor dois fazendo barulho e desarmando.

O fluxo determinístico identifica o ativo pela tag e abre um rascunho de chamado. O agente então consulta o histórico: duas ordens anteriores de desarme registraram troca de contator, e uma terceira registrou substituição de rolamento. O compressor um está operando como reserva.

A proposta que chega ao técnico responsável diz: prioridade alta, porque o ativo é crítico para a câmara e a reserva já está em carga. Sugere verificar corrente e ruído do rolamento antes de religar. Cita as três ordens. Por fim, como hipótese e não como fato, indica que a recorrência pode justificar uma tarefa preventiva de inspeção de contatores e análise de vibração.

O técnico verifica no local e discorda da hipótese: o desarme foi causado por falta de fase na alimentação. Ele registra a causa real. O agente guarda a correção, a sugestão de preventiva é descartada pelo planejador com o motivo anotado, e a ordem é fechada pelo técnico. Nenhuma ação foi executada pelo agente, e a próxima consulta ao histórico já terá a causa correta.

Como começar: um plano em quatro passos

O método que aplicamos em projetos de IA segue quatro movimentos: mapear, limitar, pilotar e transferir. Em manutenção, ele fica assim.

• Mapear: descrever como o chamado nasce, quem prioriza, onde a ordem é registrada e como a preventiva é revisada hoje. Medir a linha de base: tempo até a primeira resposta, retrabalho, ordens sem causa registrada.
• Limitar: escolher uma família de ativos e um fluxo (por exemplo, triagem de chamados corretivos). Definir o que o agente lê, o que pode escrever (apenas rascunhos e comentários) e quais gatilhos escalam direto para uma pessoa.
• Pilotar: rodar com ordens reais, com log de cada sugestão, decisão humana e motivo. Antes disso, testar com ordens passadas em ambiente separado, como descrito em como testar agente de IA com mocks e sandbox. Combinar a métrica de sucesso antes de começar.
• Transferir: entregar à equipe o procedimento de revisão, a lista de critérios e o painel de logs, e decidir com base nos dados se expande, ajusta ou encerra.

Para quem ainda está escolhendo por onde começar na operação industrial, o texto sobre IA na indústria, começando por manutenção e qualidade ajuda a situar este caso. Para a avaliação do piloto, o guia da Anthropic sobre avaliações de agentes de IA mostra como transformar casos reais em testes repetíveis.

Riscos e controles que não podem faltar

O primeiro risco é dado ruim produzindo confiança falsa. Se o histórico é pobre, o agente deve dizer que a evidência é fraca em vez de preencher a lacuna. Isso se configura nas instruções e se confere nos testes.

O segundo é autonomia excessiva. Permissões mínimas resolvem boa parte: leitura do histórico, escrita só de rascunho, nenhuma ação sobre o equipamento. Qualquer ampliação passa por aprovação explícita e por revisão do log.

O terceiro é o uso dos dados das pessoas. Ordens de serviço trazem nome de técnico, horários e, às vezes, localização e fotos. Pela LGPD, o uso deve ter finalidade clara e dados limitados ao necessário; a página da ANPD reúne as orientações oficiais. O agente serve para apoiar o trabalho, não para ranquear técnicos. Se a empresa quer indicadores de equipe, o texto sobre medir produtividade com IA sem virar vigilância traz limites úteis.

Por fim, o gerenciamento de risco precisa ser contínuo, não pontual. O AI Risk Management Framework do NIST oferece uma estrutura de referência para mapear, medir e tratar riscos de sistemas de IA, e pode servir de roteiro para a revisão periódica do piloto.

Perguntas frequentes

Preciso de sensores e IoT para usar um agente de manutenção? Não para começar. Cadastro de ativos e ordens de serviço com causa e ação registradas já permitem sugerir preventivas e priorizar chamados. Sensores podem enriquecer as sugestões depois, mas sem histórico organizado eles só aumentam o volume de dados sem melhorar a decisão.

O agente funciona se nosso histórico está em planilhas? Funciona, desde que as planilhas tenham estrutura mínima: identificação do ativo, data, sintoma, causa e ação. Se cada pessoa registra de um jeito, a primeira etapa do projeto é padronizar e limpar uma amostra, e isso costuma trazer benefício mesmo sem IA.

O agente pode abrir e fechar ordens de serviço sozinho? No começo, recomendamos que ele apenas crie rascunhos e comentários, e que o fechamento seja sempre do técnico. Se a equipe quiser ampliar a autonomia em tarefas de baixo risco, isso deve ser decidido depois do piloto, com base nos logs e com regras de escalonamento claras.

O agente substitui o planejador ou o técnico de manutenção? Não. Ele reduz o trabalho de buscar histórico, comparar falhas e organizar a fila, mas a decisão sobre o que fazer no equipamento depende de inspeção, experiência e responsabilidade que continuam com as pessoas. O desenho correto devolve tempo a elas para decidir melhor.

Fontes

• Anthropic: Building effective agents
• Anthropic: Effective context engineering for AI agents
• OWASP Top 10 for LLM Applications
• NIST AI Risk Management Framework