AI nella valutazione del rischio macchine è arrivata in reparto con una promessa molto allettante: fare in pochi minuti ciò che prima richiedeva ore di Excel, sopralluoghi, discussioni con progettisti e tecnici di manutenzione, revisioni del documento e correzioni dell’ultimo minuto. Il punto è che una tabella ordinata non è ancora una valutazione del rischio macchine secondo ISO 12100. Può sembrare completa. Può suonare tecnica. Può perfino dare un senso di controllo. Ma se non si riesce a ricostruire perché è stata presa una certa decisione progettuale, quella non è sicurezza. È scenografia documentale.
Questo è il nodo vero. La valutazione del rischio non coincide con l’elenco dei pericoli. Non coincide nemmeno con la compilazione di caselle che parlano di pericolo, danno possibile, misure di protezione e rischio residuo. Il suo valore sta nella traccia decisionale: quali limiti della macchina sono stati considerati, quali compiti della persona sono stati analizzati, quali situazioni pericolose e quali eventi pericolosi sono stati individuati, e perché una certa riduzione del rischio è stata ritenuta adeguata. Qui si vede la differenza tra un documento e un processo. E la differenza, sul campo, conta parecchio.
AI nella valutazione del rischio macchine: il vero problema è scambiare il documento per il processo
Per anni molte valutazioni del rischio macchine sono state costruite sempre allo stesso modo: un file Excel, qualche riga copiata dal progetto precedente, pericoli generici, effetti generici, misure di protezione standard e alla fine l’immancabile riduzione del rischio. Il file c’era. Le colonne erano piene. I colori tornavano. Ma spesso mancava l’elemento più importante richiesto da ISO 12100: il legame reale tra il pericolo, il compito umano, la fase di vita della macchina, la situazione pericolosa e l’evento pericoloso.
Il pericolo è stato scritto? Bene. Il rischio iniziale è stato stimato? Bene. Dopo una barriera, una procedura e un po’ di formazione il rischio è sceso? Benissimo, almeno sulla carta. Ma qualcuno ha davvero guardato cosa fa l’operatore durante il cambio formato? Qualcuno ha osservato come viene rimossa una carta inceppata, come si pulisce una zona critica, come si regola un sensore, come si interviene in modo manuale, come si accede per manutenzione? Qualcuno ha considerato l’uso scorretto ragionevolmente prevedibile o ci si è limitati a chiudere la riga?
Il vecchio problema non era Excel. Excel è solo uno strumento. Il problema era usarlo come sostituto del ragionamento. Oggi AI permette di commettere lo stesso errore più velocemente, con una forma migliore e con un tono più convincente. Prima un brutto foglio copiato si tradiva da solo. Oggi una risposta generata può sembrare scritta da un esperto: frasi scorrevoli, terminologia giusta, struttura credibile. Ed è proprio questo che la rende pericolosa. L’apparenza di analisi non è ancora analisi.
Se si chiede ad AI di preparare una valutazione del rischio per una confezionatrice, il risultato sarà spesso plausibile: pericoli meccanici, elettrici, termici, ergonomici, rumore, pneumatica, ustione, cesoiamento, schiacciamento. Tutto corretto in generale. Ma quella risposta non riguarda una macchina specifica. Riguarda una macchina tipica immaginata in modo statistico. E tra una macchina tipica e la macchina reale c’è un abisso.
La macchina reale ha accessi reali, ingombri reali, sequenze reali, tempi di arresto reali, punti di inceppamento reali, persone reali e pressioni produttive reali. Ha protezioni che sulla carta funzionano e sul campo magari vengono lasciate aperte perché pesano troppo. Ha procedure che in istruzione richiedono due persone e in turno ne trovano una sola. Ha regolazioni dichiarate occasionali che in pratica si fanno cinque volte al giorno. AI non sa tutto questo, a meno che qualcuno glielo fornisca in modo preciso. Senza quel contesto non analizza: indovina.
ISO 12100 non parte dall’elenco dei pericoli
Uno degli errori più diffusi è partire dalla domanda sbagliata: quali pericoli ha questa macchina? Sembra una buona domanda. In realtà è troppo corta. Una macchina con organi in movimento avrà pericoli meccanici. Una macchina alimentata elettricamente avrà pericoli elettrici. Una macchina con elementi caldi avrà rischio di ustione. Tutto vero. Ma questo è solo un catalogo potenziale. Non è ancora una valutazione del rischio.
ISO 12100 non guarda la macchina come una vetrina di pezzi pericolosi. La guarda nella relazione con le persone che la trasportano, installano, avviano, usano, regolano, puliscono, manuteniscono, riparano, diagnosticano, dismettono. Il pericolo, da solo, non basta. Il rischio nasce quando una persona può trovarsi in una situazione pericolosa in una certa fase di vita della macchina, durante un compito concreto, in condizioni concrete.
La domanda utile quindi non è solo quali pericoli esistono, ma questa: chi, durante quale compito, in quale fase di vita della macchina e in quali condizioni può trovarsi in una situazione pericolosa?
Da lì si prosegue. Che cosa può innescare l’evento pericoloso? Un riavvio inatteso? La perdita di stabilità? L’accesso a parti in movimento? Un errore della logica di comando? Energia residua? Un inceppamento materiale? Una scarsa visibilità? Un’attività considerata impropriamente di manutenzione ma svolta ogni turno dall’operatore?
Qui serve una precisazione importante: la logica non è sempre lineare. A volte si parte dal compito umano, per esempio pulizia, cambio formato, regolazione, manutenzione. A volte si parte dall’evento, per esempio rottura di un tubo, perdita di alimentazione, caduta del carico, rilascio di energia, guasto di comando. Una buona valutazione del rischio macchine deve saper lavorare in entrambe le direzioni. Se costringi ogni scenario in una sola catena rigida, perdi pezzi per strada.
Approccio basato sul compito: chi è esposto, dove, quando e durante quale attività?
Approccio basato sull’evento: quale evento può verificarsi nella macchina, nell’impianto, nell’ambiente o nel sistema di comando e come può portare a un danno?
È qui che si separa la valutazione seria dalla compilazione di un modulo. La prima ricostruisce la logica del rischio. La seconda riempie celle.
AI nella valutazione del rischio macchine funziona solo con contesto reale
AI può essere utile, ma solo se lavora su dati reali della macchina reale. Non basta scrivere il nome dell’attrezzatura nel prompt e aspettarsi un risultato affidabile. Servono limiti della macchina, modi di funzionamento, fasi di vita, descrizione degli accessi, fonti di energia, compiti degli operatori, attività dei tecnici di manutenzione, punti di inceppamento, sequenze di movimento, vincoli ambientali, frequenza delle esposizioni, possibilità di uso scorretto ragionevolmente prevedibile.
Senza queste informazioni AI non sa, per esempio, che:
l’operatore deve infilare la mano più in profondità di quanto previsto dal progetto;
il pannello è dalla parte sbagliata e la macchina viene osservata da una posizione non prevista;
una protezione è così scomoda che dopo due settimane viene sistematicamente aggirata;
la pulizia richiede un utensile che nessuno usa perché fa perdere troppo tempo;
l’inceppamento considerato raro dal progettista è routine per i tecnici di manutenzione;
la regolazione definita saltuaria in realtà avviene più volte per turno.
Per questo l’uso buono di AI non comincia con la richiesta di generare una tabella. Comincia con la raccolta del contesto. AI può allora fare una cosa molto utile: costringere l’ingegnere a esplicitare ciò che spesso resta implicito. Ha considerato la pulizia? Ha considerato il modo manuale? Ha considerato l’accesso in caso di guasto? Ha valutato se la misura scelta riduce il rischio con progettazione intrinsecamente sicura, con misure di protezione oppure solo con informazioni per l’uso? Queste domande valgono molto più di una risposta automatica ben scritta.
Il prompt non è una metodologia
C’è un’altra tentazione molto comune: se il primo risultato è superficiale, allora basta scrivere un prompt migliore. Inserire ISO 12100. Chiedere tutte le fasi di vita. Pretendere pericoli, danni, misure di protezione, rischio iniziale e rischio residuo. Sì, così il testo può migliorare. Ma il prompt non diventa per questo una metodologia.
Se i dati in ingresso sono vaghi o staccati dalla macchina, il risultato resterà un’elaborazione elegante di ipotesi generiche. AI non può aggiungere fatti che non conosce. Può colmarli con assunzioni medie. E proprio nelle valutazioni del rischio i dettagli fuori media sono spesso decisivi.
Conta il fatto che un organo continui a muoversi qualche secondo dopo l’arresto. Conta il fatto che l’operatore debba guardare il materiale e premere un comando nello stesso tempo. Conta il fatto che, per pulire, sia necessario smontare un riparo. Conta il fatto che la manutenzione richieda l’accesso a una struttura mai pensata come posto di lavoro. Conta il fatto che l’ambiente sia umido, polveroso, freddo, stretto, rumoroso. Conta il fatto che la pratica di reparto smentisca l’istruzione.
Da dove dovrebbe ricavarlo AI, se nessuno lo ha descritto? Non dal nome della macchina. Non da un prompt scritto bene. Non da una frase che suona normativa. Per questo il rischio più subdolo non è che AI sbagli sempre. È che spesso sbagli in modo credibile.
La traccia decisionale vale più di una bella tabella
Una valutazione del rischio macchine seria deve poter essere riletta e ricostruita nel tempo. Non solo letta. Ricostruita. Deve essere chiaro perché una certa situazione pericolosa è stata ritenuta significativa, perché la gravità del danno è stata stimata in un certo modo, perché la frequenza di esposizione è stata considerata occasionale o frequente, perché è stata scelta una certa misura di protezione e perché il rischio residuo è stato giudicato accettabile.
Se la documentazione mostra solo il risultato finale e non il percorso, si entra nella nebbia. E quella nebbia diventa un problema quando arriva un audit, una modifica, un incidente, una contestazione del cliente o una domanda dopo un infortunio. Dire che lo ha scritto AI non è un argomento. Dire che era già nel vecchio Excel non lo è mai stato e non lo sarà neanche adesso.
La traccia decisionale serve proprio a questo. Se hai scelto una protezione interbloccata, devi poter spiegare quale accesso presidia, con quale logica, per quale compito, con quale tempo di arresto e con quali effetti collaterali sul lavoro reale. Se hai lasciato un rischio residuo, devi poter spiegare perché non era ragionevolmente possibile ridurlo ulteriormente con progettazione intrinsecamente sicura o con misure di protezione tecniche. Se hai scritto formazione, devi poter giustificare perché in quel caso la formazione è un supporto sensato e non un modo comodo per spostare il problema sull’operatore.
Qui AI può aiutare molto oppure fare danni seri. Se il processo è robusto, può rendere le motivazioni più coerenti, segnalare buchi, far emergere incoerenze tra misura scelta e rischio residuo. Se il processo non c’è, produrrà solo una nebbia più elegante. Più testo. Migliore stile. Zero sostanza in più.
Esempio pratico: sensore a forcella su una taglierina longitudinale
Prendiamo un caso semplice e molto concreto. Su una taglierina longitudinale un sensore a forcella rileva la posizione del nastro. Quando cambia la larghezza del materiale, l’operatore deve spostare il sensore. Il problema è che la regolazione si trova in una zona pericolosa. Per intervenire, la persona entra vicino a rulli, alberi, punti di trascinamento, parti in movimento o elementi di taglio.
Una risposta automatica generica probabilmente dirà questo: pericolo di accesso alla zona pericolosa durante il cambio formato, danno possibile da trascinamento, schiacciamento o taglio, misure di protezione raccomandate LOTO, formazione, segnaletica, istruzione operativa, arresto di emergenza, protezioni. Sembra tutto in ordine. Ma può essere la classica fuga documentale dal problema reale.
La domanda giusta non è come descrivere l’ingresso nella zona pericolosa. La domanda giusta è perché l’operatore deve entrare nella zona pericolosa per svolgere un’attività normale e ripetitiva di produzione.
Se il cambio larghezza è un compito ordinario, trattarlo come intervento eccezionale di manutenzione è un errore. Scrivere LOTO non basta. Bisogna chiedersi se quella procedura è davvero praticabile ogni volta. La macchina deve essere completamente ferma? Serve osservare il nastro durante la regolazione? Dopo la regolazione è necessario fare una prova con movimento? La protezione rende il compito impossibile o ragionevolmente eseguibile? L’assetto attuale incentiva l’aggiramento?
Ed è qui che ISO 12100 rimette ordine. Prima si guarda la progettazione intrinsecamente sicura. In questo caso la vera domanda è se la regolazione del sensore possa essere riprogettata in modo da evitare l’ingresso nella zona pericolosa. Per esempio:
spostamento del sensore da un punto accessibile dall’esterno;
guida meccanica con scala leggibile fuori dalla protezione;
posizionamento per ricetta senza intervento manuale nella zona pericolosa;
supporto ripensato per consentire regolazione sicura;
soluzione di rilevamento diversa che elimini la necessità di regolazione manuale in quel punto.
Solo se questa strada non è ragionevolmente praticabile si passa alle misure di protezione tecniche. E solo dopo si arriva alle informazioni per l’uso, alla formazione, alle procedure e ai dispositivi individuali. La gerarchia non è un dettaglio teorico. È il cuore della riduzione del rischio.
Un buon processo quindi non chiede solo quale pericolo c’è. Chiede anche:
questa regolazione è compito normale dell’operatore o intervento di manutenzione?
con quale frequenza avviene?
in quale modo di funzionamento si esegue?
serve osservare il materiale durante l’intervento?
esiste possibilità di riavvio inatteso o presenza di energia residua?
la soluzione attuale costringe a rimuovere o aggirare una protezione?
la modifica progettuale può eliminare la necessità di accesso?
Questo è il punto di rottura tra AI usata come generatore di frasi e AI usata come supporto al ragionamento. La prima scrive una misura standard. La seconda dovrebbe aiutarti a formulare la domanda che fa davvero la differenza.
AI nella valutazione del rischio macchine non sostituisce la responsabilità
Dire che AI è utile non significa darle il ruolo sbagliato. AI può essere un ottimo assistente dell’ingegnere. Può ordinare informazioni, proporre domande di controllo, segnalare scenari tipici trascurati, migliorare la coerenza del linguaggio tecnico, aiutare a preparare giustificazioni più leggibili. Tutto bene. Ma non è l’autore della responsabilità.
La responsabilità resta in capo al fabbricante, al progettista, all’integratore, al team che approva la soluzione, a chi firma la documentazione tecnica, a chi immette la macchina sul mercato o la mette in servizio e ne sostiene la marcatura CE. Sono loro che devono dimostrare che la valutazione del rischio non è un testo plausibile, ma l’esito di un processo concreto.
AI può suggerire una protezione interbloccata con bloccaggio. Ma qualcuno deve chiedersi perché proprio quella, per quale accesso, con quale tempo di arresto, con quale funzione di sicurezza, con quale frequenza di ingresso, con quale impatto sulla pulizia e sulla manutenzione. AI può suggerire formazione. Ma qualcuno deve verificare se la formazione è una misura sensata oppure un cerotto messo sopra un difetto di progetto. AI può proporre LOTO. Ma qualcuno deve avere l’onestà di domandarsi se stiamo parlando di manutenzione occasionale o di rimozione inceppamenti ripetuta più volte al giorno. Se la procedura non è realisticamente applicabile, non è una riduzione del rischio. È un desiderio scritto in una cella.
AI nella valutazione del rischio macchine non va confusa con AI nella funzione di sicurezza
Qui serve una distinzione netta. Un conto è usare AI come supporto alla valutazione del rischio. Altro conto è usare AI o modelli di apprendimento automatico nella macchina stessa per assicurare una funzione di sicurezza. Sono due piani diversi. E il secondo è molto più severo, sia tecnicamente sia dal punto di vista normativo.
Il Regolamento macchine (UE) 2023/1230 non chiede un documento che assomigli a una valutazione del rischio. Chiede di eseguire una valutazione del rischio per determinare i requisiti essenziali di salute e sicurezza applicabili e per definire le misure necessarie di riduzione del rischio. Quindi limiti della macchina, uso previsto, uso scorretto ragionevolmente prevedibile, identificazione dei pericoli, stima del rischio, valutazione del rischio, riduzione del rischio. Processo, non facciata.
Lo stesso regolamento tratta in modo specifico i componenti e i sistemi con comportamento totalmente o parzialmente autoevolutivo che assicurano funzioni di sicurezza tramite approcci di apprendimento automatico. Il motivo è semplice: opacità, dipendenza dai dati, autonomia e connettività possono aumentare probabilità e gravità del danno. Qui non basta dire che l’algoritmo funziona quasi sempre. Serve dimostrare conformità con un livello di rigore adeguato, incluso il coinvolgimento di una parte terza quando previsto.
Anche AI Act rafforza la stessa logica. Un sistema AI può essere considerato ad alto rischio, tra l’altro, quando è usato come componente di sicurezza di un prodotto soggetto alla normativa armonizzata dell’Unione e quel prodotto richiede una valutazione di conformità da parte terza. Tradotto in linguaggio di officina: se AI entra davvero nella catena della sicurezza macchina, non è più un dettaglio software alla moda. È un elemento che va trattato con disciplina tecnica e regolatoria pesante.
In più AI Act non si accontenta di una buona accuratezza media. Richiede gestione del rischio lungo l’intero ciclo di vita, sorveglianza umana efficace, robustezza, qualità dei dati, controllo delle anomalie, capacità di interpretare correttamente l’output e possibilità, quando serve, di non usarlo affatto o di portare il sistema in stato sicuro. È l’opposto della fiducia cieca nell’automazione.
Ed è qui che i numeri percentuali smettono di rassicurare. Novantacinque per cento di correttezza può sembrare eccellente in una presentazione commerciale. In una funzione di sicurezza la domanda cambia subito: cosa succede nel restante cinque per cento? Cosa accade se il sistema non rileva una persona? Cosa succede se l’ambiente cambia, se la lente si sporca, se il materiale riflette in modo diverso, se la vibrazione altera il segnale, se il comportamento appreso fuori produzione non regge in reparto? In sicurezza macchine non basta che il sistema sia intelligente. Deve essere difendibile.
La conclusione pratica
Usare AI in questo ambito ha senso solo se si accetta una verità semplice: la valutazione del rischio macchine è prima di tutto un processo di ingegneria, non un esercizio di scrittura tecnica. Il documento è il residuo visibile del processo. Non il suo sostituto.
Se AI viene usata per porre domande scomode, verificare la completezza, mettere ordine nella documentazione e rendere più solida la traccia decisionale, allora può far guadagnare tempo e qualità. Se invece viene usata per generare in automatico una tabella rassicurante a partire da pochi dati generici, allora accelera solo la produzione di apparenza.
E in sicurezza macchine l’apparenza regge fino al giorno in cui qualcuno chiede perché. Oppure fino al giorno in cui qualcosa va storto. In quel momento non serve una tabella che suona bene. Serve un processo che stia in piedi.