Nei grandi cantieri navali sono in uso sistemi di computer vision per la sicurezza sul lavoro: telecamere collocate in punti strategici dell’area, un modello di deep learning che analizza il flusso video e riconosce situazioni di rischio predefinite. Assenza dei dispositivi di protezione individuale, accessi ad aree interdette, prossimità pericolosa fra persone e macchinari in movimento, cadute e posture compatibili con un infortunio in atto. Al rilevamento il sistema genera un allarme verso il responsabile di cantiere e, nelle configurazioni più avanzate, arresta automaticamente il macchinario coinvolto.

È quest’ultima funzione a cambiare la natura del problema. Finché il sistema segnala, la sicurezza resta affidata a chi riceve l’allarme; quando ferma una gru, l’integrità e la disponibilità di un software diventano condizioni della sicurezza fisica di chi lavora sotto quella gru. La discussione su questi impianti si concentra di solito sui presidi giuridici che ne rendono legittimo l’uso — l’articolo 4 dello Statuto dei Lavoratori, l’AI Act e il GDPR — e sono presidi necessari. Il versante di sicurezza informatica riceve meno attenzione, e riguarda l’incolumità delle stesse persone.

Segnalare e fermare

Un sistema che segnala e un sistema che agisce hanno modelli di guasto diversi. Nel primo caso fra il rilevamento e l’intervento c’è una persona, che può verificare, ignorare o sbagliare, e la latenza è quella umana. Nel secondo l’autorità sul mondo fisico sta nel codice e nei pesi del modello, e la latenza scende a quella della macchina.

Il diritto arriva allo stesso punto da un’altra strada. Il blocco automatico di un macchinario costituisce una decisione basata unicamente sul trattamento automatizzato con effetti significativi sulla persona ai sensi dell’articolo 22 del GDPR, e richiede quindi le garanzie della norma, a partire dall’intervento umano nella gestione dell’evento. La norma chiede un intervento umano proprio nel punto in cui la funzione di sicurezza richiede tempi di reazione da macchina. Sono due vincoli reali che tirano in direzioni opposte, e la loro composizione è una scelta di progetto da documentare.

Alla stessa scelta appartiene il comportamento in caso di guasto. Una funzione di sicurezza che fallisce in stato sicuro ferma la macchina e ferma la produzione; una che fallisce lasciando proseguire il lavoro toglie la protezione senza che nessuno se ne accorga. Le due opzioni hanno costi molto diversi, e la scelta fra loro va presa in progettazione invece che al primo guasto.

Il precedente: Triton

Che un sistema pensato per impedire alle persone di morire sia un bersaglio è documentato dal 2017. In un impianto petrolchimico in Arabia Saudita fu trovato un malware, chiamato Triton da Mandiant, TRISIS da Dragos e HatMan dall’ICS-CERT statunitense, che prendeva di mira il sistema strumentato di sicurezza Triconex di Schneider Electric — lo strato che porta l’impianto in stato sicuro quando i parametri escono dai limiti.

La sequenza è istruttiva. I primi segni risalgono al giugno 2017, quando il sistema di sicurezza scattò e l’impianto si fermò; una seconda fermata in agosto portò all’indagine e alla scoperta del malware, resa pubblica a dicembre. L’attribuzione arrivò molto dopo: nel marzo 2022 gli Stati Uniti resero pubblico l’atto d’accusa contro un dipendente dell’istituto di ricerca russo TsNIIKhM e l’FBI diffuse una nota in cui avvertiva che il gruppo continuava a operare contro il settore energetico globale.

Triton è il primo caso pubblicamente documentato di malware costruito per agire su un sistema strumentato di sicurezza. Chi lo ha scritto ha dovuto conoscere il protocollo proprietario dei controller e riprogrammarli. Il precedente riguarda un settore esposto ad avversari di livello statale e non descrive la situazione di un cantiere navale. Quello che stabilisce è che lo strato di sicurezza, quando è software, rientra fra le cose che qualcuno prova a modificare. È lo stesso ragionamento applicato al contenimento dei modelli in un articolo precedente: un confine realizzato in software eredita i modi di guasto del software.

Integrità, disponibilità, autenticità

In un sistema informatico ordinario integrità, disponibilità e autenticità sono proprietà di servizio. In una funzione di sicurezza diventano condizioni dell’incolumità fisica, e vanno trattate con lo stesso rigore delle protezioni meccaniche.

  • Integrità. Una soglia modificata, un modello sostituito, una classe rimossa dall’elenco di ciò che il sistema riconosce: l’impianto continua a funzionare e smette di vedere una categoria di pericolo. Il guasto non produce sintomi visibili.
  • Disponibilità. Un sistema fermo non protegge nessuno. La domanda da sciogliere in progettazione è cosa succede al cantiere nei minuti in cui il sistema è indisponibile, e chi decide se le lavorazioni proseguono.
  • Autenticità del segnale. Telecamere, rete e flusso video sono la percezione del sistema. Un fotogramma congelato o ritrasmesso mostra un’area sgombra.
  • Asimmetria del guasto silenzioso. Un allarme che non scatta è indistinguibile dall’assenza di pericolo. Per provocare un danno è sufficiente sopprimere un allarme vero, senza bisogno di generarne uno falso, che è l’effetto a cui puntava Triton sul sistema strumentato di sicurezza.

L’ultimo punto è la ragione tecnica per cui una funzione di sicurezza deve sorvegliare sé stessa: verifiche di vitalità, allarme sull’assenza di segnale, prove periodiche di copertura sul campo. Sono controlli noti nella sicurezza funzionale e ricompaiono qui perché il problema è lo stesso.

Il Regolamento Macchine e l’AI Act

Il Regolamento (UE) 2023/1230 sulle macchine, che si applica dal 20 gennaio 2027 al posto della Direttiva 2006/42/CE, ha recepito questa convergenza in modo esplicito. Il software rientra nella definizione di componente di sicurezza e compare nell’elenco indicativo dei componenti di sicurezza, che ora possono essere fisici o digitali. Nell’Allegato III, fra i requisiti essenziali di sicurezza e di tutela della salute, il punto 1.1.9 è dedicato alla protezione contro la corruzione, e si lega al punto 1.2.1 sulla sicurezza e affidabilità dei sistemi di comando.

La collocazione conta più della formulazione: la protezione da alterazioni intenzionali sta fra i requisiti essenziali di salute e sicurezza, allo stesso livello dei ripari e dell’arresto di emergenza. Il regolamento prevede inoltre che le macchine certificate nell’ambito di un sistema di certificazione della cibersicurezza adottato ai sensi del Regolamento (UE) 2019/881 siano considerate conformi ai punti 1.1.9 e 1.2.1. La norma tecnica di supporto è in scrittura: il progetto europeo prEN 50742 affronta l’alterazione accidentale o intenzionale di software, dati e configurazioni quando può compromettere la sicurezza, e a metà luglio 2026 resta un progetto, non uno standard applicabile.

Sull’AI Act la classificazione più immediata è quella dell’Allegato III, punto 4: un sistema impiegato per monitorare e valutare il comportamento delle persone nel rapporto di lavoro è ad alto rischio, con gli obblighi applicabili dal 2 dicembre 2027 dopo il Digital Omnibus. Vale la pena considerare una seconda via di classificazione: l’articolo 6, paragrafo 1, qualifica ad alto rischio un sistema di IA destinato a essere usato come componente di sicurezza di un prodotto coperto dalla normativa di armonizzazione elencata nell’Allegato I, quando quel prodotto è soggetto a valutazione di conformità da parte di terzi. Il Regolamento Macchine è normativa di quel tipo e copre i componenti di sicurezza basati su IA. Se una singola installazione ricada in questa via dipende da come il sistema è immesso sul mercato e dalla valutazione di conformità richiesta, ed è una verifica da fare caso per caso.

Gli effetti a valle: gli ospedali

Il settore sanitario mostra cosa produce il fermo di un sistema informatico su persone che non erano il bersaglio. Uno studio di Christian Dameff e colleghi pubblicato su JAMA Network Open l’8 maggio 2023 ha misurato l’effetto di un attacco ransomware durato un mese contro un sistema ospedaliero di San Diego sui due pronto soccorso adiacenti, che non erano stati attaccati: i pazienti con ictus trattati sono passati da 60 nelle quattro settimane precedenti a 103 nelle quattro settimane dell’attacco, con un aumento degli accessi e delle persone che se ne andavano senza essere visitate. È una misura sottoposta a revisione fra pari e documenta la propagazione del disservizio, non decessi.

Sulla mortalità l’evidenza è più fragile e va presentata come tale. Una stima su dati Medicare colloca la mortalità intraospedaliera dei pazienti già ricoverati quando l’attacco comincia attorno a 3 su 100, in aumento verso 4 su 100, con un numero di decessi aggiuntivi stimato fra 42 e 67 nel periodo 2016-2021. Quella stima proviene da un working paper non sottoposto a revisione fra pari e limitato ai pazienti Medicare, e va citata con questi limiti.

Limiti

Quanto descritto qui è una classe di sistemi e non un’installazione specifica con risultati pubblicati. L’efficacia dichiarata dai fornitori non sostituisce la verifica sul campo, e gli indicatori vanno definiti prima dell’adozione invece che ricavati dopo. La letteratura sull’efficacia di questi sistemi nel ridurre gli infortuni è in larga misura prodotta da soggetti interessati, e nessuno dei numeri citati qui la riguarda.

Aggiungere uno strato di sicurezza connesso in rete aggiunge superficie d’attacco: un sistema in più da aggiornare, con le sue credenziali e i suoi accessi remoti. Il bilancio fra il rischio che riduce e quello che introduce va fatto sul campo, e dipende da come è isolato dal resto della rete di cantiere.

Nulla di quanto sopra sostiene che i cantieri navali siano oggi bersaglio di attacchi della classe di Triton, che è avvenuto in un settore con avversari di livello statale. La rilevanza per un cantiere sta nella domanda di progetto, non nel livello di minaccia.

Resta poi la questione della sorveglianza, che non è secondaria: la stessa telecamera che ferma la gru osserva le persone che lavorano. L’articolo 4 della legge 300/1970 consente gli impianti audiovisivi anche per la sicurezza del lavoro, ma subordina l’installazione all’accordo con le rappresentanze sindacali o all’autorizzazione dell’Ispettorato Nazionale del Lavoro, e quel passaggio viene prima di tutto il resto.

Prima di installare un sistema di questo tipo le domande da porre sono due e sono separate: se funziona quando tutto è in ordine, e cosa succede al cantiere quando smette di funzionare. La seconda domanda include chi, dall’esterno, può farlo smettere di funzionare.

Immagine di copertina: una saldatrice nei cantieri navali del Tyneside, 1943 — foto di Cecil Beaton, collezione Imperial War Museums, pubblico dominio — https://commons.wikimedia.org/wiki/File:Cecil_Beaton_Photographs-_Tyneside_Shipyards,_1943_DB68.jpg