La norma ISO/IEC 27000 definisce il rischio come l’effetto dell’incertezza sugli obiettivi, mentre la UNI/ISO 31000 precisa che la gestione del rischio è fatta di attività coordinate per guidare e tenere sotto controllo un’organizzazione con riferimento al rischio.
Sono aspetti su cui sei strumenti normativi convergono: Cyber Resilience Act, GDPR, ISO/IEC 27001, NIS2, AI Act e ISO/IEC 42001 impongono infatti, tutti, una valutazione e una gestione del rischio.
Ma nessuno le applica allo stesso oggetto, nessuno segue la stessa sequenza operativa e in un solo caso, quello tra AI Act e GDPR, esiste un ponte normativo esplicito tra questi mondi. Gli altri restano isolati.
Indice degli argomenti
La valutazione cambia oggetto a seconda di chi lo misura
Il Cyber Resilience Act guarda al prodotto. L’articolo 13 impone al fabbricante di individuare i rischi rilevanti per il prodotto, valutarne il potenziale impatto e attuare misure conformi ai requisiti essenziali dell’Allegato I: superficie di attacco, componenti integrati, ambiente operativo, uso ragionevolmente prevedibile.
Le linee guida della Commissione sul CRA, seppur non ancora definitive, distinguono due obblighi distinti, la valutazione del rischio globale sull’intero prodotto (inclusi i componenti di terze parti e l’ambiente in cui opererà) e la verifica delle dipendenze, cioè la due diligence sui componenti hardware e software esterni.
Il criterio di giudizio è regolamentare, non interno all’azienda: la propensione al rischio del fabbricante non determina se i requisiti essenziali sono soddisfatti.
Il GDPR sposta il rischio sulle persone
Il GDPR sposta l’oggetto sulle persone. Gli articoli 24 e 32 chiedono misure tecniche e organizzative proporzionate al rischio per i diritti e le libertà degli interessati; l’articolo 35 impone, quando il rischio è elevato, una valutazione d’impatto da condurre prima di iniziare il trattamento.
È una sequenza preventiva per costruzione: la valutazione precede l’attività, non la accompagna.
La ISO/IEC 27001 ha un altro obiettivo: l’oggetto della valutazione è l’informazione: i rischi rilevanti sono quelli della perdita di riservatezza, integrità e disponibilità, entro il perimetro del sistema di gestione per la sicurezza delle informazioni. Non il prodotto, non la persona: l’informazione e le tre proprietà (RID) che la rendono affidabile.
La NIS2 guarda alla continuità del servizio. Il testo della direttiva descrive il rischio come la potenziale perdita o perturbazione causata da un incidente, espressa come combinazione tra l’entità di quella perdita e la probabilità che l’incidente si verifichi.
L’oggetto non è il dato né il prodotto: è la capacità del soggetto essenziale o importante di continuare a operare sotto attacco.
L’AI Act distingue categorie di rischio e FRIA
L’AI Act aggiunge due livelli distinti. Il primo è la classificazione per categorie di rischio, dal rischio inaccettabile (sistemi vietati) all’alto rischio, fino al rischio limitato, minimo e al regime a parte per i modelli per finalità generali (GPAI): una tassonomia che condiziona quali obblighi si applicano, non una valutazione caso per caso. Il secondo livello è la FRIA, la valutazione d’impatto sui diritti fondamentali dell’articolo 27, distinta dalla conformità tecnica del sistema e con una propria sequenza interna.
La ISO 42001, infine, capovolge l’ordine che le altre norme danno per scontato. Come precisato da autorevoli esperti, la norma richiede infatti di identificare i rischi che favoriscono o impediscono il raggiungimento degli obiettivi del sistema di intelligenza artificiale: una logica non troppo distante da quella della ISO/IEC 27001, ma con gli obiettivi del sistema al posto della riservatezza dell’informazione.
Ma la norma impone anche altro e lo impone come sequenza obbligata: l’organizzazione deve prima stabilire un processo per valutare le potenziali conseguenze del sistema IA su individui, gruppi di individui e società lungo l’intero ciclo di vita del sistema e soltanto dopo identificare i rischi rispetto agli obiettivi. L’ordine non è una raccomandazione: è imposto dal testo.
La differenza pratica è sostanziale. Le altre cinque norme partono dal rischio e, se necessario, arrivano all’impatto sulle persone come una delle variabili di gravità. La ISO/IEC 42001 impone il percorso opposto: prima le conseguenze su chi subisce il sistema, poi il rischio rispetto agli obiettivi tecnici.
Chi deve applicarle tutte non trova un ordine scritto da nessuna parte. Un fabbricante che produce un dispositivo connesso con funzioni di intelligenza artificiale integrate, tratta dati personali degli utenti finali, opera in un settore che la NIS2 qualifica come essenziale ed è già certificato ISO/IEC 27001 deve condurre, in teoria, sei valutazioni del rischio distinte: quella del prodotto per il CRA, quella sui diritti e libertà per il GDPR, quella sull’informazione per la ISO/IEC 27001, quella sulla continuità del servizio per la NIS2, quella per categorie più la FRIA per l’AI Act, quella sugli obiettivi del sistema con la sequenza vista sopra prevista dalla ISO/IEC 42001.
C’è una eccezione che riguarda il rapporto tra FRIA e GDPR, perché l’AI Act consente di integrare una FRIA con elementi di una DPIA già eseguita. Il Digital Omnibus, di prossima pubblicazione, prevede che la Commissione sviluppi un modello comune e uno strumento automatizzato per facilitare proprio questo raccordo e sposta l’obbligo FRIA al 2 dicembre 2027, insieme al resto del calendario sui sistemi ad alto rischio.
La somma delle conformità non è una governance del rischio
Un’azienda già certificata ISO/IEC 27001, conforme al GDPR, pensa spesso di aver già risolto il problema. Non è così. Ogni adeguamento nasce quasi sempre da una valutazione fatta per conto proprio, con il proprio registro dei rischi, la propria soglia di allarme, il proprio responsabile e le proprie scadenze. Raramente sono messe in correlazione.
Un esempio rende il problema meno astratto. Un’azienda usa uno strumento di intelligenza artificiale per selezionare le candidature ricevute per una posizione aperta.
Il GDPR guarda ai candidati: lo strumento profila automaticamente le persone che si candidano, quindi l’azienda deve valutare se serve una DPIA ai sensi dell’articolo 35, per capire se il rischio per i loro diritti è elevato e gestire la profilazione.
La ISO/IEC 27001 guarda invece ai curriculum come informazione: la valutazione del rischio verifica che quei dati restino riservati, integri e disponibili solo a chi deve trattarli, dentro il perimetro del sistema di gestione.
L’AI Act guarda al sistema: la selezione del personale rientra tra i casi d’uso ad alto rischio dell’Allegato III; lo strumento richiede quindi un sistema di gestione del rischio e una governance dei dati di addestramento conforme. Se il datore di lavoro è un ente pubblico, o un soggetto che fornisce un servizio pubblico essenziale, si aggiunge anche la FRIA.
Tre valutazioni sullo stesso strumento, con tre oggetti diversi.
Nessuna delle tre esclude le altre e nessuna basta da sola.
Come possiamo coordinare le norme?
Il primo passo potrebbe essere una tassonomia esplicita che mappi, per ciascuna delle valutazioni, l’oggetto specifico che tutela: il prodotto, le persone, l’informazione, il servizio, il sistema IA per categorie, gli obiettivi del sistema IA con l’impatto a monte.
Il secondo passo una sequenza operativa aziendale: quando un sistema è insieme prodotto connesso e sistema IA, l’organizzazione deve decidere se e come far precedere la valutazione d’impatto richiesta dalla ISO/IEC 42001 rispetto alla valutazione tecnica del prodotto richiesta dal CRA, mantenendo entrambe le sequenze interne intatte.
Il terzo passo è, anche qui probabilmente, un registro dei rischi unico, con campi che tracciano la provenienza normativa, l’oggetto specifico e il responsabile di ciascuna voce, per rendere visibili e gestibili le sovrapposizioni.
Un altro passo riguarda l’individuazione delle responsabilità: DPO, CISO, responsabile di conformità di prodotto e, dove esiste, AI Officer restano titolari delle rispettive valutazioni, ma senza un punto di raccordo unico potrebbero continuare a procedere in parallelo senza incontrarsi.
Infine è necessaria una revisione periodica che allinei le scadenze dei riesami, che è anche un modo per accorgersi in tempo utile che un cambiamento rilevante per un framework (una nuova funzione IA integrata nel prodotto, ad esempio) ha conseguenze anche sugli altri.
L’effetto dell’incertezza sugli obiettivi sembra essere l’unica premessa condivisa tra sei norme che è compito, e onere delle aziende, coordinare.
Partecipa alla community