Credibilità, attendibilità e affidabilità dei modelli ML: la vera sfida dell’intelligenza applicata all’industria è sapere quando usarla, come qualificarla, e fare in modo che la responsabilità operativa resti in mano a chi conosce davvero il processo.
Di Micaela Caserza Magro – Presidente GISI
Intelligenza artificiale (IA) e machine learning (ML) per il controllo di processo: se ne parla ormai da anni, nelle fiere, nei convegni, nelle brochure dei vendor. Le promesse sono note (modelli capaci di ottimizzare variabili in tempo reale, sistemi che anticipano anomalie, algoritmi che imparano la dinamica di impianti complessi) e in molti casi sono promesse fondate. Applicazioni concrete esistono e funzionano.
Eppure chi lavora sul campo conosce bene la distanza che separa una dimostrazione in sala riunioni, dall’esercizio reale di un impianto. Quella distanza ha un nome: credibilità del modello. Non è un problema risolvibile con più dati o con algoritmi più sofisticati. È una questione di metodo, che riguarda come questi sistemi vengono costruiti, messi in servizio e mantenuti nel tempo, e quali conseguenze comporta fidarsi di loro quando le cose si complicano.
Un modello di machine learning è costruito su correlazioni estratte da dati storici. A machine learning model is built on correlations extracted from historical data.
CONTROLLORI CLASSICI E MODELLI ML: UNA DIFFERENZA CHE CONTA
Chi ha dimestichezza con il controllo di processo sa cosa significa mettere a punto un PID o tarare un controllore predittivo. I parametri hanno un significato fisico, la risposta del sistema è prevedibile, i margini di stabilità si calcolano. Se qualcosa non va, si capisce dove guardare. Un modello di machine learning funziona in modo diverso.
Non è costruito sulla fisica del processo, ma su correlazioni estratte da dati storici. Questo lo rende capace di catturare comportamenti complessi e non lineari che un modello classico faticherebbe a rappresentare,
ma introduce anche una fragilità che non va sottovalutata: il modello è affidabile nelle condizioni che ha “visto” durante l’addestramento, e può comportarsi in modo imprevedibile fuori da quelle condizioni.
In pratica, questo significa che un modello validato su sei mesi di dati storici può funzionare bene per un certo periodo, e poi cominciare a degradare silenziosamente, non perché il modello si sia “rotto”, ma perché il
processo è cambiato: è cambiata la materia prima, è stata fatta una modifica di impianto, è intervenuto un diverso regime stagionale.
Il modello non lo sa, e non lo segnala. Continua a produrre output che sembrano plausibili ma non sono più affidabili. Questo è il rischio operativo principale, ed è anche quello meno visibile.
IL PROBLEMA DELLA SCATOLA NERA IN SALA CONTROLLO
Un operatore di impianto esperto accumula nel tempo una comprensione del processo che va ben oltre i manuali. Sa che un certo andamento della pressione anticipa una variazione di composizione a valle.
Sa riconoscere la firma di un’incipiente inefficienza di scambio termico, o i sintomi di un inizio di fouling. Questa conoscenza è difficile da formalizzare, ma è preziosa e concreta.
Quando un sistema basato su ML produce un’indicazione che contrasta con questa esperienza (per esempio, suggerendo un setpoint che all’operatore sembra sbagliato) si crea una situazione di conflitto. L’operatore non ha modo di capire il ragionamento del modello, perché quel ragionamento non esiste in forma esplicita, è codificato in migliaia di parametri numerici che non hanno un significato leggibile.
La scelta è obbligata: mi fido del modello o della mia esperienza?
Questo non è un problema secondario. In ambito di sicurezza funzionale e di responsabilità operativa, la fiducia nel sistema di controllo è un requisito, non un’opzione.
Un operatore che non capisce perché il sistema sta facendo quello che fa, non è nelle condizioni di intervenire in modo efficace quando qualcosa va storto.
Esistono strumenti per rendere i modelli più trasparenti (tecniche che cercano di spiegare quali variabili hanno influenzato maggiormente una certa previsione), ma nella pratica operativa la loro utilità è limitata.
Spiegare statisticamente una correlazione non equivale a spiegare una causa fisica.
E in sala controllo, la distinzione conta.
MONITORAGGIO CONTINUO PER CAPIRE QUANDO I MODELLI INVECCHIANO
Un impianto industriale non è mai fermo. Cambia la qualità delle materie prime, cambiano le condizioni operative, si fanno interventi di manutenzione, si sostituiscono componenti.
Ogni modello ML addestrato in un certo momento storico incorpora una fotografia di come il processo si comportava in quel periodo. Quando il processo cambia, e cambia sempre, il modello rischia di restare ancorato a una realtà che non esiste più.
Il problema è che questa deriva non si manifesta con un allarme.
Non c’è un segnale che avvisa che il modello ha perso aderenza con il processo reale.
Le previsioni continuano ad arrivare, numericamente coerenti, apparentemente plausibili, ma progressivamente distaccate dalla realtà.
È un degrado silenzioso, e può andare avanti per settimane prima che qualcuno se ne accorga attraverso un’anomalia operativa concreta. La risposta a questo problema non è tecnologica ma organizzativa: richiede di definire fin dall’inizio una strategia di monitoraggio continuo delle performance del modello, basata sul confronto sistematico tra le sue previsioni e misure reali indipendenti (analisi di laboratorio, misuratori ridondanti, bilanci di processo).
Quando lo scarto supera una soglia definita, il modello deve essere riesaminato e, se necessario, riadattato. E deve essere previsto esplicitamente un sistema di fallback su un controllore classico nel frattempo. Chi non pianifica questa fase, di fatto sta accettando che il modello sia considerato affidabile fino a prova contraria. In un impianto industriale, aspettare la prova contraria può avere un costo molto alto.
IL MODELLO NON SA DI NON SAPERE: COME EVITARE PREVISIONI SBAGLIATE
C’è un aspetto dei sistemi ML che chi li utilizza in produzione impara presto ad apprezzare nel modo sbagliato: questi sistemi producono sempre una risposta, in qualsiasi condizione.
Non hanno un modo nativo per dire “questa situazione è al di fuori di quello che conosco, non mi fiderei di me stesso in questo momento”.
Per un sistema di supporto alle decisioni, questo è un limite gestibile. Per un sistema che agisce direttamente sul processo (che muove una valvola, che modifica un setpoint) è un rischio concreto. Una previsione sbagliata
applicata senza alcuna misura della sua affidabilità può portare il processo in condizioni che nessuno aveva previsto, e farlo in modo abbastanza graduale da non innescare allarmi immediati.
La soluzione più pragmatica,
adottata nelle implementazioni più mature, è quella di accoppiare il modello ML a un sistema di verifica basato su bilanci di processo o su misure ridondanti. Se la previsione del modello è fisicamente inconsistente (viola un bilancio di massa, produce una stima incompatibile con una misura diretta), il sistema lo segnala e passa in modalità sicura.
Non è una soluzione elegante, ma è robusta e comprensibile per chi opera l’impianto.
I modelli ibridi vanno nella stessa direzione: invece di affidare tutto all’algoritmo di apprendimento, mantengono una struttura basata sulla fisica del processo (bilanci, vincoli termodinamici, relazioni causali note), e usano il componente ML per correggere gli scarti fra il modello fisico e il comportamento reale.
Questo approccio limita il rischio di previsioni fisicamente assurde, e rende il sistema molto più controllabile.
LA QUESTIONE DELLA QUALIFICA: CERTIFICARE UN MODELLO CHE IMPARA
In settori regolati come la farmaceutica, la chimica fine o l’alimentare, qualsiasi sistema software che partecipa al controllo del processo deve essere qualificato. Questo significa dimostrare, con documentazione tracciabile, che il sistema fa quello che deve fare, nelle condizioni in cui è previsto che operi, in modo ripetibile.
Qualificare un controllore PID o un sistema SCADA è un processo consolidato, con procedure standardizzate. Qualificare un modello ML è un’altra cosa. Il comportamento del modello dipende dai dati di addestramento,
che cambiano nel tempo se il modello viene aggiornato.
Una rete neurale non ha specifiche funzionali nel senso tradizionale del termine: la sua “specifica” è l’insieme dei dati su cui è stata addestrata, che non si può leggere, né verificare nella forma in cui si verifica il codice di un PLC.
Le autorità regolatorie stanno cominciando ad affrontare il problema, sia in ambito farmaceutico che, più in generale, nell’applicazione dell’AI Act europeo ai sistemi industriali ad alto rischio, ma il quadro normativo è ancora in costruzione. In questo contesto, la scelta più difendibile dal punto di vista della responsabilità operativa è quella di usare i modelli ML come strumenti di supporto alla decisione, mantenendo il controllo effettivo del processo su sistemi qualificati con metodi tradizionali.
Non è la soluzione più ambiziosa, ma è quella che tiene in piedi la responsabilità in caso di problemi.
DOVE I RISULTATI CI SONO DAVVERO
Detto tutto questo, sarebbe sbagliato concludere che l’IA applicata al controllo di processo sia sopravvalutata in assoluto.
Ci sono ambiti in cui i benefici sono concreti, documentati e accessibili anche senza dover gestire i rischi più complessi. Il soft sensing è l’applicazione più consolidata.
Stimare in tempo reale variabili di qualità (composizione, viscosità, indice di ottano, umidità) che normalmente richiederebbero un’analisi di laboratorio con tempi di risposta di ore, è un problema in cui i modelli ML danno risultati eccellenti.
Il controllore classico rimane responsabile del processo, mentre il modello ML fornisce una stima della variabile di qualità che permette di agire in modo più tempestivo. Il rischio è limitato, il valore è alto, e la tecnologia è matura: i principali vendor di automazione la propongono da anni con risultati verificabili in campo.
Il rilevamento anomalie è un altro ambito in cui l’applicazione è efficace e il profilo di rischio è accettabile. Un modello addestrato sul comportamento normale dell’impianto può identificare pattern anomali (vibrazioni insolite, derive lente di temperatura, correlazioni che si rompono) con un anticipo che i sistemi di allarme tradizionali basati su soglie fisse non riescono a garantire.
L’operatore riceve un segnale di attenzione prima che la situazione diventi critica, ma resta lui a valutare e a decidere. Alcune esperienze in ambito petrolchimico e di generazione di energia documentano riduzioni significative degli interventi non pianificati grazie a sistemi di questo tipo.
L’ottimizzazione del punto di funzionamento è una terza area di applicazione concreta, soprattutto in processi dove le condizioni cambiano lentamente, e l’obiettivo è trovare il setpoint che massimizza la resa o minimizza i consumi energetici.
In questi contesti, il modello ML opera su un orizzonte temporale lento, con un loop di feedback che permette di verificare i risultati prima di applicare la correzione successiva. Il rischio operativo è basso, e il valore economico, in termini di efficienza energetica e di qualità del prodotto, può essere molto significativo.
COSA SERVE PERCHÉ TUTTO FUNZIONI
Le esperienze più positive nell’applicazione di ML al controllo di processo hanno alcune caratteristiche in comune, che vale la pena esplicitare. La prima è la chiarezza sul ruolo del modello.
C’è una differenza importante tra un modello che supporta una decisione, e un modello che esegue un’azione. Nel primo caso, l’operatore resta nel loop e la responsabilità è distribuita.
Nel secondo, i requisiti di affidabilità e le procedure di gestione dei guasti devono essere molto più rigorosi. Confondere i due casi è una delle cause principali di implementazioni problematiche.
La seconda caratteristica è la qualità dei dati.
Un modello non può essere più affidabile dei dati su cui è stato costruito. Dati di processo raccolti con strumenti non calibrati, con gap temporali, con valori anomali non gestiti, producono modelli che sembrano funzionare in addestramento ma deludono in esercizio.
La qualità della strumentazione di misura (la sua calibrazione, la sua manutenzione, la gestione dei segnali degradati) è la fondamenta su cui tutto il resto si regge. Chi conosce il settore sa che questo è spesso il collo di bottiglia reale, molto più che la scelta dell’algoritmo. La terza caratteristica è il coinvolgimento di chi conosce il processo.
I modelli migliori non sono quelli costruiti da data scientist che ottimizzano metriche su dataset, ma quelli sviluppati in collaborazione con gli ingegneri e gli operatori che conoscono il processo nel profondo.
Quella conoscenza serve a scegliere le variabili giuste, a interpretare le anomalie nei dati, a capire quando il modello sta producendo qualcosa di fisicamente inconsistente. Senza di essa, il modello è cieco rispetto a tutto ciò che i dati non riescono a catturare.
LE VERE SFIDE DA AFFRONTARE
In sintesi, l’IA applicata al controllo di processo non è una moda destinata a passare, né una soluzione universale applicabile senza distinguere. È uno strumento potente, con ambiti di applicazione maturi e ben definiti, e con limiti altrettanto reali che vanno conosciuti e gestiti.
La credibilità di un sistema di controllo (la sua capacità di comportarsi in modo prevedibile, di essere compreso da chi lo opera, di degradare in modo controllato quando qualcosa va storto) non è una proprietà automatica, ma va progettata, verificata e mantenuta nel tempo. Vale per i controllori classici, e vale a maggior ragione per i sistemi che incorporano componenti ML.
Chi opera nel settore della strumentazione e del controllo ha gli strumenti culturali per affrontare queste questioni con il rigore che meritano. La sfida non è imparare a usare l’IA, quella parte è relativamente semplice.
È sapere quando usarla, come qualificarla, e fare in modo che la responsabilità operativa resti in mano a chi conosce davvero il processo.
