La scatola e il cervello: integrare IEC 62443 e ISO 42001 nei prodotti industriali intelligenti
Mettere un modello di machine learning dentro un dispositivo di controllo industriale è ormai una scelta di prodotto normale. Manutenzione predittiva, visione, ottimizzazione in tempo reale: il “cervello” entra nella macchina. Ma con il cervello entra anche un rischio che il tuo processo di cybersecurity OT, da solo, non è in grado di vedere.
Se progetti prodotti industriali conosci già la IEC 62443. Hai un ciclo di sviluppo sicuro, requisiti sui componenti, gestione delle patch, logging per la rilevazione delle intrusioni. La 62443 mette in sicurezza la scatola e i canali attraverso cui comunica. Ma chi garantisce che il cervello dentro la scatola decida in modo corretto, tracciabile, e senza degradare in silenzio?
È la domanda a cui risponde la ISO/IEC 42001. E la risposta non è “aggiungi un secondo sistema di gestione accanto al primo”: è innestare l’AIMS dentro l’ISMS/CSMS che già hai. La 42001 non sostituisce la 62443 — ci si appoggia sopra. Vediamo dove, in concreto. Sei punti.
Il rischio non si somma, si fonde
Il primo errore è trattare il rischio AI e il rischio OT come due elenchi separati. Non lo sono.
Un attacco avversario a un modello — input costruiti apposta per ingannarlo — appartiene formalmente al dominio della governance dell’AI. Ma se quel modello pilota un attuatore, l’effetto non resta nel software: diventa un movimento sbagliato, una pressione fuori soglia, un danno fisico. Il rischio “qualità dell’AI” e il rischio “sicurezza OT” sono lo stesso rischio visto da due lati.
La conseguenza pratica è precisa: le valutazioni d’impatto dell’AI richieste dalla 42001 non possono restare documenti a sé. Devono tradursi in requisiti di sicurezza OT nel linguaggio della 62443. Se l’analisi dei rischi dei due mondi non si fonde in un’unica valutazione, hai due mappe parziali di un territorio solo — e i punti ciechi stanno proprio sui confini.
Il ciclo di vita è uno solo (62443-4-1)
La 62443-4-1 definisce il ciclo di sviluppo sicuro del prodotto: requisiti, progettazione, implementazione, verifica, gestione delle modifiche. È la disciplina con cui un produttore dimostra di costruire in sicurezza, non per caso.
Quando nel prodotto c’è un modello AI, il suo addestramento, il suo testing e la sua validazione non sono un binario parallelo gestito dal team data science con regole proprie. Vanno dentro lo stesso ciclo. Un modello validato su un dataset ma fuori dai gate di verifica del prodotto è un componente non tracciato dentro un sistema che dovrebbe esserlo per intero. La 42001 porta la disciplina del ciclo di vita del modello; la 4-1 è il posto dove la incardini.
Il componente intelligente ha due fronti (62443-4-2)
La 62443-4-2 fissa i requisiti di sicurezza a livello di componente. Per un device edge che ospita un modello significa, come sempre, resilienza contro attacchi di rete e manomissioni.
Ma un componente intelligente ha un secondo fronte che un componente “muto” non ha: l’input. Un modello decide a partire dai dati dei sensori. Se quei dati sono corrotti — per guasto, rumore o manipolazione — il modello può decidere in modo perfettamente “sicuro” dal punto di vista di rete, e perfettamente sbagliato nel merito. La robustezza dell’input sensoriale diventa così un requisito di sicurezza a tutti gli effetti. È il punto in cui la qualità del dato (42001) e la sicurezza del componente (62443) smettono di essere due temi e diventano lo stesso requisito.
Due tipi di log, due domande diverse
Entrambi gli standard chiedono di registrare. Ma rispondono a domande diverse, e confonderle è un errore.
Il logging della 62443 serve a rilevare: intrusioni, anomalie di rete, comportamenti fuori norma. Risponde a “qualcuno o qualcosa ha attaccato il sistema?”.
Il logging della 42001 serve a rendere conto: tracciabilità delle decisioni del modello, registrazione di input e output, explainability. Risponde a “perché il sistema ha deciso così?”.
In un prodotto intelligente ti servono entrambi, e devono parlarsi. Quando una decisione anomala del modello coincide con un’anomalia di rete, è la sovrapposizione dei due log a dirti se hai davanti un guasto, un drift o un attacco. Progettarli separati significa rinunciare proprio all’informazione che conta nei casi peggiori.
Aggiornare il cervello è critico quanto patchare la scatola
Qui sta il punto più OT-specifico, e il meno raccontato.
Aggiornare un sistema OT è notoriamente delicato: richiede finestre di manutenzione, validazione, procedure di patch management rigorose, perché un aggiornamento sbagliato ferma una linea o mette a rischio le persone. È il cuore operativo della 62443.
Un modello AI introduce una seconda ragione per aggiornare, che prima non esisteva: il drift. Il modello non viene “bucato” — semplicemente smette di essere accurato perché il mondo è cambiato rispetto ai dati su cui è stato addestrato. Quando accade, serve riaddestrarlo o aggiornarne i pesi: un intervento della 42001.
Ma il rilascio di quell’aggiornamento nel field non può seguire le regole rilassate di un deploy software qualsiasi. Deve passare per le stesse finestre di manutenzione e la stessa validazione di una patch di sicurezza 62443. Cambiare il cervello di un sistema in produzione non è meno critico che chiudere una vulnerabilità nella scatola. Spesso è di più — perché il drift è invisibile: nessun alert ti avverte che il modello sta sbagliando sempre più spesso.
Un solo sistema, per un solo mercato
Mettiamo insieme i pezzi. Un produttore di sistemi di controllo embedded intelligenti che vuole vendere nel mercato unico europeo si trova davanti due fronti normativi convergenti: il Cyber Resilience Act sul lato sicurezza del prodotto, l’AI Act sul lato AI. Né la 62443 né la 42001 sono obbligatorie per legge — ma sono i riferimenti pratici con cui dimostri di aver fatto le cose per bene su entrambi i fronti.
La mossa giusta non è gestire due sistemi di gestione in parallelo. È integrare l’AIMS (Artificial Intelligence Management System) della 42001 dentro l’ISMS/CSMS della 62443 che — se fai prodotti industriali seri — già esiste o sta nascendo.
Perché il principio, alla fine, è quello da cui siamo partiti: la 62443 garantisce che la scatola e i suoi canali siano impermeabili e sicuri. La 42001 garantisce che il cervello dentro la scatola operi in modo equo, trasparente, controllato e senza degradare in modo invisibile. Ti servono entrambe le cose. E ti serve che siano una cosa sola.
Se stai mettendo — o stai per mettere — un modello AI dentro un prodotto OT, il punto difficile non è scegliere lo standard. È capire dove i due mondi si toccano nel tuo prodotto specifico, e dove hai punti ciechi sui confini.
Il Regulatory Spark è una call di 45 minuti per mappare proprio questo: dove AI e sicurezza OT si intersecano nel tuo prodotto, e da dove conviene partire. Esci con una sintesi scritta e una direzione. Senza fuffa.