IA Industrial · 7 min de leitura
O mercado de IA industrial mudou de patamar: a ferramenta que avisava virou a ferramenta que decide e executa, com supervisão leve. Manutenção e troubleshooting aparecem como caso de uso líder dessa IA agêntica. Um sistema que sugere e erra custa uma viagem ao enlace errado; um sistema que age e erra custa outra coisa, e isso muda o que perguntar antes de assinar.
Da IA que avisa para a IA que age
Até pouco tempo atrás, a IA aplicada à manutenção era essencialmente um sistema de recomendação. Ela olhava os dados, apontava uma anomalia e sugeria onde procurar. Quem decidia era a equipe, e o custo de um erro era limitado: um técnico ia ao lugar errado, perdia algumas horas e voltava.
A IA agêntica muda essa conta. O sistema não só identifica o problema; ele abre a ordem de serviço, reconfigura um parâmetro, isola um segmento, prioriza uma fila de trabalho. A supervisão humana existe, mas é leve, e a velocidade é justamente o argumento de venda.
Quando o sistema age, o erro deixa de custar uma viagem e passa a custar uma decisão errada executada em produção. Por isso a pergunta sobre a qualidade da saída deixa de ser técnica e passa a ser de gestão de risco.
Onde a análise automatizada faz sentido em rede industrial
Não há razão para ceticismo generalizado sobre IA em manutenção de rede. Há pelo menos três problemas reais em que análise automatizada resolve o que a disciplina manual não consegue resolver em escala, e eles são conhecidos de quem trabalha com auditoria.
O primeiro é a janela cega entre auditorias: meses em que a rede muda e ninguém mede. O segundo é saber o que é normal em uma rede específica, porque um mesmo contador tem significados diferentes em plantas, trechos e dias diferentes. O terceiro é transformar medições avulsas em série histórica, que é o que permite ver tendência em vez de foto.
Nos três casos, o valor da ferramenta depende de uma coisa só: a confiança que a equipe pode ter na saída. E é aí que as demonstrações costumam ser mais convincentes do que os produtos.
O modo de falha que aprendi na Johns Hopkins
Em 2026 cursei o programa de IA aplicada da Johns Hopkins, e a lição mais útil veio do projeto final. Quando a camada de recuperação de dados ficava levemente errada, trazendo documentos-fonte inadequados, o sistema continuava produzindo respostas fluentes, confiantes e erradas. Nada na saída indicava o problema.
Esse é o mesmo modo de falha que vejo em campo: uma saída bem estruturada, com boa aparência, construída sobre a fonte errada. A forma da resposta não diz nada sobre a qualidade da entrada. Um relatório bonito sobre o dado errado é mais perigoso do que um relatório feio, porque ninguém desconfia dele.
Na planta, esse modo de falha tem duas consequências práticas. A primeira é a equipe indo ao enlace errado, confiante na recomendação. A segunda é mais sutil: a equipe ignorando um alarme correto porque os três anteriores eram falsos. Em OT, a tolerância a falso positivo é baixa exatamente para preservar a credibilidade do alarme, e a credibilidade, uma vez perdida, não volta com uma atualização de software.
As quatro perguntas
Antes de contratar IA para manutenção ou troubleshooting de rede, faça ao fornecedor quatro perguntas e peça respostas por escrito. Cada uma cobre um ponto em que demonstração e produto costumam se separar:
- Qual é a taxa de falso positivo e de falso negativo, e como ela foi medida?
- Contra qual conjunto de dados essa taxa foi medida, e quem classificou o que era certo e o que era errado?
- Quanto tempo o sistema precisa observar a minha planta antes de a saída ser confiável?
- O que ele faz sozinho quando conclui que há um problema, e o que continua exigindo um humano?
O que cada resposta revela
A primeira pergunta separa quem mede o próprio erro de quem só mede acerto. Um número de acurácia sem as duas taxas de erro não diz quanto alarme falso a equipe vai receber, nem quantas falhas reais vão passar em silêncio.
A segunda expõe a base da métrica. Uma taxa medida em dado de laboratório, ou classificada pelo próprio fornecedor, diz pouco sobre uma rede com Profibus, PROFINET e EtherNet/IP convivendo na mesma planta. A terceira reconhece que o normal de cada planta é dela: um sistema que promete saída confiável no primeiro dia está usando o normal de outra rede.
A quarta define o risco operacional. Ela obriga o fornecedor a desenhar a fronteira entre o que o sistema executa e o que exige decisão humana, e permite à planta avaliar se essa fronteira é compatível com a sua gestão de mudanças e com a criticidade de cada segmento.
Produto ou demonstração
Se as quatro respostas vierem claras, com método, dados e limites explícitos, você está diante de um produto. Se alguma vier vaga, genérica ou em forma de promessa, você está diante de uma demonstração, por melhor que ela tenha parecido na reunião.
Vale fazer as perguntas antes da prova de conceito, e não depois. Um piloto escolhido pelo fornecedor, em um segmento limpo e por poucas semanas, quase sempre vai bem. O que a planta precisa saber é como o sistema se comporta no segmento problemático, no mês em que a produção muda de regime, na semana em que uma célula nova entra no anel. As respostas por escrito viram critério de aceite do piloto, e o piloto passa a testar o que importa.
A pergunta certa nunca foi o que a IA detecta. É como você sabe quando ela está errada. Um sistema que não consegue responder a isso não está pronto para agir sobre a sua planta, com ou sem supervisão leve.
Artigo desenvolvido a partir das publicações de Darwin Anastacio Junior no LinkedIn.