O que realmente vale a pena automatizar com IA numa fábrica

A maior parte do que decide um projeto de IA numa fábrica não é modelagem. É nomear que tipo de problema você tem, verificar se o seu dado de execução consegue sustentá-lo e desenhar o que acontece quando o modelo erra.

Regras, machine learning, otimização e modelos de linguagem: o que serve para qual problema

Regras e estatística vêm primeiro, e merecem mais respeito do que recebem. Se uma regra que um engenheiro consegue escrever entrega a maior parte do valor, a comparação honesta para qualquer modelo é contra essa regra, e não contra não fazer nada.

O machine learning ganha o seu lugar quando a relação entre entradas e resultado é real mas ninguém consegue escrevê-la: dezenas de variáveis de processo interagindo, um defeito que depende do lote de material, da umidade ambiente e da posição na cavidade. Ele conhece as condições que lhe foram mostradas e não diz nada de útil sobre condições que nunca viu.

A otimização é outra disciplina e é rotineiramente rotulada como IA. Programar uma fábrica com capacidade finita, sequenciar para minimizar trocas, atribuir operadores habilitados: são problemas de restrições com uma função objetivo. Não precisam de exemplos rotulados, mas precisam de tempos de processo e restrições honestos, que normalmente têm de ser medidos em vez de supostos. Para planejamento, um solver capaz de expressar as suas restrições reais de ferramental e de secagem é quase sempre a ferramenta certa, porque planejar é um problema de restrições e não de predição.

Os modelos de linguagem são a chegada mais recente e o encaixe deles é específico. Servem para trabalho com formato de documento e de conversa: ler uma consulta que chega e redigir uma versão estruturada dela, condensar um longo histórico de manutenção em algo que o técnico consiga ler antes de caminhar até a máquina, responder o que uma instrução de trabalho diz sobre um setup. Não são instrumentos de medição: pedir a um deles que preveja a falha de um rolamento a partir de dados de vibração é usar martelo em parafuso.

De que dado um projeto de IA numa fábrica realmente precisa

Um modelo precisa de exemplos que associem uma situação a um resultado, com contexto suficiente para distinguir uma situação da outra: um sinal ou conjunto de condições amarrado a uma ordem, a uma máquina, a uma ferramenta, a um lote de material, a um operador e a um timestamp que seja verdadeiro. O timestamp importa mais do que se imagina. Se os apontamentos são lançados em bloco no fim do turno, todos os eventos daquele turno compartilham uma hora aproximada, e tudo o que dependa de sequência ou de duração aprende o hábito de digitação em vez do processo.

O lado do resultado costuma ser pior. A manutenção preditiva precisa de falhas registradas como falhas, com causa e data, e não como uma parada não planejada com o campo de motivo em branco. A predição de qualidade precisa de refugo apontado contra a operação e contra o tipo de defeito que o causou, e não agregado num número mensal. A previsão precisa de histórico de consumo que não tenha sido reescrito em silêncio por ajustes de estoque. Na maioria das plantas as entradas moram no historian e os resultados moram num caderno da manutenção ou na planilha de uma pessoa.

O teste não é quantos gigabytes o historian guarda, e sim se você consegue extrair, para uma linha e uma família de produto, um ano de linhas em que cada linha carregue as condições e o resultado, e duas pessoas que conhecem o processo concordem que as linhas são verdadeiras. Se essa extração leva uma semana de conciliação manual, o projeto não é o modelo; é o registro. É por isso que a qualidade do dado do MES e do historian é a restrição que prende, e nenhuma sofisticação de modelagem recupera o que nunca foi capturado.

Previsão de demanda e de consumo, onde o retorno está mais perto

A previsão costuma ter o caminho mais curto até o dinheiro, porque a alternativa é visivelmente fraca: a maioria das fábricas pega o ano passado e soma um percentual, ou pede um número à área comercial que na verdade é uma meta. Um modelo que use histórico de pedidos, sazonalidade, mix de clientes, carteira em aberto e efeitos de calendário vence isso nos itens de demanda regular e repetitiva. Nos itens intermitentes e movidos a projeto, muitas vezes a maior parte dos códigos e uma fatia pequena do volume, normalmente não vence, e uma baseline ingênua ou do tipo Croston é difícil de superar. A versão honesta segmenta o catálogo primeiro e deixa esses itens para uma política de estoque e para o julgamento.

O valor aparece a jusante e não na previsão em si: o estoque de segurança se move, o momento de compra dos itens de lead time longo muda, e as trocas emergenciais que destroem uma programação ficam mais raras. Um percentual de acurácia de previsão num slide não é um benefício; dias de estoque e número de pedidos em regime de urgência são.

Manutenção preditiva, só onde o modo de falha é de fato previsível

Tudo aqui depende de a falha se desenvolver gradualmente e deixar assinatura em algo que você consiga medir. Degradação de rolamento, desbalanceamento, desalinhamento, obstrução progressiva num filtro ou num circuito de refrigeração, deriva na pressão hidráulica, corrente do motor subindo aos poucos na mesma operação: essas se desenvolvem ao longo de semanas ou meses, ocasionalmente em apenas horas, o que normalmente é tarde demais para valer a instrumentação, e aparecem em vibração, corrente, temperatura ou pressão. Um modelo consegue enxergá-las, e muitas vezes um limite bem escolhido também, e é justamente por isso que a comparação contra estatística simples importa aqui.

Uma placa de controlador que morre, uma ferramenta quebrada por um inserto ruim, um dano causado por erro de operador: essas são efetivamente instantâneas, e nenhum modelo as prevê a partir de uma tendência que não existe.

A segunda condição é que o aviso precisa comprar um tempo que você consiga usar. Se a peça tem lead time longo e a linha não pode parar antes do fim de semana, o investimento que se paga é uma política de sobressalentes, não um modelo. Defina a janela de intervenção antes do orçamento de sensores.

Predição de qualidade e redução de refugo

Qualidade é onde normalmente está o maior dinheiro e onde as exigências de dado são mais duras. A versão atraente prevê, a partir das condições durante a rodada, quais peças ou lotes estão em risco, para que alguém ajuste antes de o refugo ser produzido em vez de encontrá-lo na inspeção final.

Funciona quando o processo está instrumentado na resolução daquilo que se quer prever, e quando o refugo carrega um código de causa real contra a operação. Falha em silêncio quando o refugo é apontado no fim da ordem contra a ordem inteira, porque aí o modelo não consegue dizer quais condições produziram qual falha.

Um passo sem glamour se paga antes de qualquer modelo: capturar motivos de refugo na máquina, no momento, a partir de uma lista curta de causas que o operador reconheça. Muitas plantas que pedem predição de qualidade descobrem só com esse dado que um pequeno número de causas responde pela maior parte da perda, e fecham a maior com uma mudança de engenharia. Isso é um bom desfecho, não um projeto fracassado.

IA para programação da produção: por que é um problema de otimização e não de predição

Se o plano escorrega toda semana, a causa raramente é falta de inteligência e normalmente é falta de restrições. O que muda isso é um programador que respeite ferramental compartilhado, famílias de setup, habilitações de operador, tempos de cura e as janelas de manutenção que você pretende manter.

O aprendizado ajuda aqui de um jeito estreito e real: os tempos de processo. Uma programação construída sobre tempos-padrão que ninguém remede há anos é precisa a respeito dos números errados, e as durações reais capturadas pelo MES podem atualizar aquilo com que o programador planeja. Julgue uma proposta de programação pelas restrições que ela consegue expressar e pela velocidade com que replaneja quando algo quebra; um plano que leva a noite inteira para ser regerado é sobrescrito à mão na reunião da manhã.

Detecção de anomalias em sinais de energia e de processo

A detecção de anomalias aprende como é o normal e sinaliza o desvio. Serve para sinais contínuos em que você tem bastante comportamento bom e poucas falhas rotuladas: consumo de energia por ciclo, consumo de ar comprimido, desempenho do chiller, um sinal de processo cuja forma é estável quando as coisas vão bem.

A força dela é reagir ao que ninguém antecipou. A fraqueza é que ela diz apenas que algo está incomum, nunca o que está errado, e uma planta que recebe alertas inexplicados aprende a ignorá-los. O trabalho de projeto não é o detector, é o roteamento: quais alertas vão para quem, qual é a primeira verificação, e como a resposta é registrada para que o próximo alerta do mesmo formato chegue com histórico anexado.

IA em vendas e no atendimento a clientes, onde o trabalho tem formato de documento

O lado comercial de uma indústria roda sobre documentos e conversas: consultas, especificações, propostas, confirmações de pedido, dúvidas de entrega, reclamações. É aqui que os modelos de linguagem genuinamente encaixam, porque o trabalho é ler, extrair, redigir e resumir.

Concretamente: uma consulta que chega interpretada em item, quantidade, data solicitada e requisitos especiais, com as propostas anteriores abertas ao lado. Uma thread de e-mail condensada num registro de CRM que carrega o compromisso assumido e a próxima ação.

Duas regras impedem que isso dê errado. O modelo redige e uma pessoa envia, pelo menos até a taxa de erro ser conhecida naquele fluxo. E tudo o que é factual, preço, lead time, estoque, data prometida, vem do sistema de registro e não do modelo, que deve estar citando um valor consultado e nunca gerando um. Uma automação de CRM que inventa um lead time é pior do que nenhuma, porque compromete a empresa.

Dimensionar o ganho antes de comprar qualquer coisa

Nomeie a perda em unidades que a sua planta já acompanha: custo de refugo por mês na família de produto em questão, horas de parada não planejada na máquina restrição multiplicadas pelo que uma hora ali vale em margem de contribuição e não em taxa-máquina, frete expresso, estoque parado nas peças que uma previsão moveria, horas por semana gastas redigitando entre sistemas.

Depois estime, de forma pessimista, que fatia dessa perda a aplicação poderia plausivelmente atacar. A manutenção preditiva não elimina parada; na melhor das hipóteses converte algumas paradas não planejadas em planejadas, para os modos de falha que ela cobre. Um modelo de qualidade não remove refugo; encurta o tempo entre um processo sair do rumo e alguém perceber.

Se esse número honesto, colocado contra um custo total ao longo da vida que você de fato planejaria, incluindo integração e as pessoas que vão operá-lo, não passa no critério que a sua área financeira aplica a qualquer outro investimento daquele porte, o projeto é um experimento científico. Isso é permitido, mas deve ser financiado e julgado como tal.

Quanto a integração realmente custa

O modelo costuma ser a parte barata; o custo mora nas costuras. Tirar sinal das máquinas vem primeiro, e uma planta real é um parque misto: alguns ativos falam OPC UA, outros Modbus ou um protocolo serial, alguns oferecem um contato seco, e alguns controladores fechados exigem sensor de retrofit no fuso, no circuito hidráulico ou na linha de alimentação. Depois a saída precisa aterrissar em algum lugar que provoque uma ação: uma tela que o operador já olha, uma ordem de serviço aberta na manutenção, uma restrição alimentada ao programador, um bloqueio aplicado na qualidade.

Em seguida vem a conciliação de cadastro mestre que ninguém coloca no escopo. Códigos de peça que diferem por um sufixo entre sistemas, unidades de medida que não batem, uma BOM mantida em dois lugares, identificadores de máquina que mudaram quando a linha foi rearranjada. Nada disso é difícil e tudo isso leva mais tempo que o software. Uma proposta que precifica o modelo e deixa as costuras como "integração a escopar" não é um preço.

Quem opera o modelo, e o que acontece quando ele erra

Todo modelo implantado precisa de um dono com nome, e a pergunta de compra é quem na sua organização será esse dono. Essa pessoa precisa saber com o que ele foi treinado, quais condições ficam fora disso, por que ele produziu uma determinada saída, e como tirá-lo do circuito sem parar a produção. Um modelo que para de responder tem de voltar para o que controlava o processo antes dele, o plano de amostragem, o limite, a verificação do operador, e não para um portão aberto nem para uma linha travada. Decida qual delas é antes do go-live.

Explicabilidade não é uma preocupação filosófica no chão de fábrica, é um requisito de adoção. Uma recomendação que diz qual sinal se moveu, quanto, e contra qual referência, é levada a sério. Um score sem raciocínio é sobrescrito, e quando sobrescrever vira rotina o sistema é decoração.

Alertar demais destrói a confiança mais rápido do que deixar passar, pelo mesmo motivo que rejeitar demais destrói numa estação de inspeção: o alarme falso é visível na hora e para todo mundo, o escape fica invisível até a falha chegar. Dimensione a taxa de alertas em torno da atenção realmente disponível no chão de fábrica, e encaminhe a faixa duvidosa para uma pessoa, não para a linha.

Governança, deriva e o esforço de manutenção que ninguém orça

Um modelo é um retrato do seu processo no momento em que foi treinado, e o seu processo se mexe: um fornecedor novo, um ferramental recuperado, uma revisão de peça, um rearranjo de linha, um mix de produto alterado, um sensor trocado por outro ligeiramente diferente. Cada um pode deslocar as entradas o bastante para que o modelo de ontem esteja silenciosamente errado hoje, e o modo de falha não é uma mensagem de erro, é um conselho cada vez pior.

Monitore as entradas além das saídas, porque a deriva de entrada aparece antes da degradação do resultado. Mantenha um conjunto de teste reservado com casos reais, inclusive os de fronteira, para que um modelo novo possa ser comparado honestamente com o atual. Versione o modelo e registre qual versão produziu qual recomendação; depois de um retreino, as saídas de ontem vieram de outro juiz.

E orce o esforço contínuo. Um modelo em produção é um ativo mantido, mais próximo de um equipamento de processo do que de um relatório comprado. Se ninguém tem tempo alocado para retreinar, revisar alertas e conferir se o dado continua chegando, ele vai se degradar até as pessoas pararem de usá-lo.

Um primeiro projeto realista, com critérios de aceitação

Escolha uma perda nomeada, numa linha ou numa família de produto, enunciada como uma frase com um número dentro: refugamos tanto nesta operação, perdemos tantas horas de restrição nesta máquina, carregamos tanto estoque porque não conseguimos prever esta família. Se o projeto não pode ser enunciado assim, ele não está pronto.

Antes de comprar qualquer coisa, faça a extração de dados. Um ano, uma linha, condições e resultados nas mesmas linhas, duas pessoas que conhecem o processo confirmando que as linhas são verdadeiras. Depois compare com a alternativa simples: um limite, uma carta de controle ou o julgamento do programador atual.

Escreva os critérios de aceitação em unidades da planta antes do go-live, em pares, para que o trade-off fique explícito. Para manutenção preditiva, um número declarado de modos de falha cobertos e pegos com pelo menos uma semana de aviso, contra um teto de alertas falsos por mês. Para previsão, uma redução declarada em dias de estoque nas famílias modeladas sem aumento de ruptura. Para qualidade, uma redução declarada de refugo na operação alvo contra os mesmos meses do ano anterior, com as mudanças de processo registradas ao lado.

Nomeie o dono, o comportamento em caso de falha e o cronograma de retreino no mesmo documento, e marque uma data de revisão com a opção honesta de parar. Um primeiro projeto que termina numa decisão de não expandir, tomada com evidência, é um sucesso. Um piloto que vira demonstração permanente não é.

Onde a Meta Smart Factory entra

A Meta Smart Factory é modular, e isso importa aqui porque o módulo de IA e machine learning fica em cima da camada de execução, e não ao lado dela. O MES fornece os eventos e o contexto, a conectividade IIoT e o OPC UA fornecem os sinais de máquina, a Qualidade fornece refugo com causas, a Manutenção fornece histórico de falhas, e o APS consome a saída quando a resposta é uma programação em vez de uma predição.

Dá para começar com um módulo contra uma restrição nomeada e acrescentar o próximo quando o primeiro estiver em uso. O que nenhuma plataforma elimina é a parte difícil: combinar o que os números significam, conseguir causas capturadas na máquina e decidir quem é dono de um modelo quando ele erra. Conversar sobre esse sequenciamento para uma planta específica é uma primeira conversa mais útil que uma demonstração, porque uma demonstração sempre vai funcionar.