IA Industrial · 6 min de leitura
A IA industrial está deixando de aconselhar e começando a agir. As arquiteturas sérias trazem uma salvaguarda: quando a incerteza do modelo sobe, o sistema cai para modo seguro e devolve o controle às pessoas. Falta instrumentar a pergunta seguinte, a que decide o que fazer depois: por que a incerteza subiu?
Dos sistemas que aconselham aos sistemas que agem
Os relatórios do ano sobre IA na indústria colocam manutenção e troubleshooting entre os principais casos de uso. A mudança de fundo é de papel: o sistema que antes sugeria um ajuste agora executa o ajuste, dentro de limites definidos. Isso muda o custo do erro, e por isso as arquiteturas responsáveis incluem um mecanismo de recuo.
O mecanismo é simples no conceito. O modelo estima o próprio grau de confiança em cada saída. Enquanto a confiança está alta, ele age; quando cai abaixo de um limiar, ele para de agir, sinaliza e entrega a decisão a um operador ou engenheiro. É uma salvaguarda correta e necessária.
O problema é o que acontece depois do recuo. O operador recebe o controle e uma informação incompleta: o modelo não está seguro. Ninguém diz a ele por quê. E a resposta certa depende inteiramente dessa causa.
Duas causas possíveis para a mesma incerteza
A primeira causa é o processo ter mudado de regime. Matéria-prima de outro fornecedor, trocador de calor sujando, variação sazonal de temperatura ou umidade. O modelo foi treinado em um regime e agora está vendo outro. A incerteza sobe porque a realidade saiu da região que ele conhece.
A segunda causa é as entradas terem mudado porque a rede degradou. O processo está igual, mas o dado que chega ao modelo não representa mais o processo com a mesma fidelidade. A incerteza sobe porque o modelo está olhando através de um vidro sujo.
Do ponto de vista do modelo, os dois casos podem ser indistinguíveis. Nos dois, as entradas deixaram de se parecer com o que ele viu no treinamento. A diferença está fora do modelo, no caminho físico que o dado percorreu até ele.
Como uma rede degradada engana o modelo sem apagar o dado
Um enlace degradando raramente apaga de vez. O que ele produz primeiro são retries, pacotes atrasados e frames perdidos. Em redes industriais cíclicas, o dado continua chegando na maior parte dos ciclos, e a falha aparece como irregularidade, não como ausência.
Muitos sistemas de aquisição mantêm o último valor válido até estourar o timeout da conexão. É um comportamento sensato para o controle, porque evita que um ciclo perdido vire um salto de variável. Mas o efeito colateral é que o historiador registra uma linha plausível, com pequenos degraus onde deveria haver variação contínua. Olhando a tendência, ninguém vê problema.
O modelo vê. Ele recebe variáveis que deveriam mudar juntas chegando desalinhadas no tempo: uma temperatura atualizada, uma pressão congelada por alguns ciclos, uma vazão com atraso. Para um algoritmo que aprendeu correlações entre essas grandezas, isso parece exatamente uma mudança de comportamento do processo. A incerteza sobe, e a causa está em um conector.
Respostas opostas, e o custo de trocar uma pela outra
Se o processo mudou de regime, a resposta é do lado dos dados e do modelo: retreinar, re-sintonizar, ampliar a base com o novo regime. Se a rede degradou, a resposta é do lado físico: mandar um técnico com instrumento a um conector, a uma emenda, a uma porta de switch.
As duas respostas não se complementam; elas se anulam quando aplicadas no caso errado. Retreinar o modelo quando a rede degradou significa ensinar a ele que o dado corrompido é o novo normal, e o modelo passa a acertar sobre uma realidade que não existe. Tratar como problema de rede uma deriva real de processo significa perseguir um defeito que não está lá, enquanto o processo continua mudando.
Em campo, o segundo erro é o mais caro, porque é silencioso. Um modelo retreinado sobre entradas degradadas volta a mostrar confiança alta. A salvaguarda deixa de disparar exatamente quando deveria.
A pergunta a fazer para qualquer fornecedor de IA
Antes de aceitar um sistema que age sobre a planta, vale fazer ao fornecedor uma pergunta direta: quando o modelo perde confiança, como ele sabe se o processo mudou ou se o caminho do dado mudou? A resposta revela muito sobre a arquitetura.
Se o sistema depende só do dado que o modelo já vê, ele não sabe. A própria variável suspeita não pode ser a testemunha de que está íntegra. Separar as duas causas exige uma segunda fonte de evidência, independente do valor de processo: o estado do caminho que esse valor percorreu.
Na prática, isso significa ter a saúde da rede medida e registrada no mesmo eixo de tempo das variáveis de processo. Contadores de CRC e de frames descartados por porta, retransmissões, estado das conexões cíclicas, eventos de reconfiguração de anel. Quando a incerteza do modelo sobe e esses indicadores estão estáveis, a hipótese de processo ganha força. Quando sobem juntos, o primeiro passo é físico.
O que muda para quem decide o investimento
Para a gestão, a consequência é de escopo. Um projeto de IA que age sobre a planta não é só um projeto de dados e algoritmo. Ele herda a confiabilidade da rede que alimenta o modelo, e essa rede precisa estar medida antes do go-live, não depois do primeiro recuo inexplicado.
Na prática, três coisas deveriam constar do projeto desde o início. Um baseline da rede nos segmentos que carregam as variáveis do modelo, para saber o que é normal ali. Um critério escrito para separar deriva de processo de degradação de rede quando a confiança cair. E um responsável por cada lado da resposta, porque o cientista de dados não vai a campo com instrumento, e o técnico de rede não retreina modelo.
Artigo desenvolvido a partir das publicações de Darwin Anastacio Junior no LinkedIn.