Ottobre 2026: pubblicata la prima tassonomia internazionale degli attacchi ai sistemi di intelligenza artificiale, utile per concretizzare gli obblighi di sicurezza europei, ma senza effetti di presunzione normativa.
Cosa è ISO/IEC 27090 e perché conta
Il Joint Technical Committee ISO/IEC JTC 1/SC 27 ha pubblicato la norma tecnica ISO/IEC 27090 dedicata alla gestione delle minacce specifiche dei sistemi di intelligenza artificiale. Il documento non è un requirements standard, dunque non certificabile, ma una guida che descrive sei categorie di attacchi — avvelenamento dei dati, attacchi di evasione, inferenza di appartenenza, inversione del modello, esfiltrazione del modello, prompt injection — per ciascuna indicando conseguenze, tecniche di rilevazione e misure di mitigazione lungo l’intero ciclo di vita. Costituisce il primo riferimento tecnico internazionale strutturato sulla sicurezza dell’IA e offre un vocabolario condiviso per documentare la conformità agli obblighi europei.
Il ponte con gli obblighi giuridici europei
ISO/IEC 27090 non è una norma armonizzata ai sensi dell’AI Act e non attribuisce presunzione di conformità. Tuttavia, opera come criterio rilevante per assolvere all’obbligo di misure “adeguate” e di “stato dell’arte” previsto dall’art. 32 GDPR, ai requisiti di robustezza e cybersicurezza dell’art. 15 dell’AI Act e alle misure di gestione del rischio dell’art. 21 della Direttiva (UE) 2022/2555 sulla cybersicurezza. Il legislatore europeo ha deliberatamente scelto la tecnica della norma elastica, scaricando sul titolare del trattamento e sul fornitore l’onere di documentare il contenuto concreto dell’obbligo: è esattamente in questo spazio che operano le norme tecniche come elementi di prova della diligenza.
Le minacce che cambianoil profilo di rischio
L’inversione del modello e l’inferenza di appartenenza permettono all’attaccante di ricostruire dati personali utilizzati nell’addestramento interrogando il modello: non occorre rubare il database per violarne la riservatezza. L’avvelenamento dei dati consente la manipolazione progressiva tramite input legittimi immessi durante l’uso, rendendo il modello inesatto su persone fisiche: la violazione tocca simultaneamente l’art. 32 GDPR e l’art. 5 sulla qualità dei dati. La prompt injection attiva comportamenti non previsti dai creatori. Ciascuno di questi attacchi, al ricorrere dei presupposti, integra una violazione dei dati personali ai sensi dell’art. 4, numero 12, GDPR, con i conseguenti obblighi di notifica entro 72 ore.
Cosa devono fare le imprese
Il primo passaggio è censire ogni sistema che tratti dati personali, incluse le funzionalità incorporate in prodotti terzi: l’inventario dei sistemi di IA è presupposto della completezza del registro dei trattamenti e della corretta identificazione dei sistemi ad alto rischio. Occorre poi aggiornare la metodologia di risk assessment per includere esplicitamente gli scenari descritti nello standard, revisionare la valutazione d’impatto sulla protezione dei dati con la sezione dedicata alle contromisure specifiche dell’IA e, in particolare, esplicitare se il modello contiene dati personali. Va curata la qualificazione delle compromissioni dell’IA come violazioni di dati personali all’interno delle procedure di gestione degli incidenti, coordinando gli obblighi GDPR con quelli NIS2 e dell’AI Act.
I vincoli operativi irrisolti
Lo standard non elimina i conflitti fra mitigazioni: la differential privacy protegge dalla riservatezza ma degrada l’accuratezza, richiedendo un bilanciamento documentato fra due requisiti posti dall’art. 15 dell’AI Act. Il deterioramento del modello nel tempo — per deriva dei dati o evoluzione degli attacchi — lo rende progressivamente non conforme pur in assenza di modifiche, attivando l’obbligo di monitoraggio dell’art. 72 dell’AI Act e il riesame della valutazione d’impatto GDPR. La registrazione degli eventi per rilevare attacchi costituisce a sua volta un trattamento di dati personali, con base giuridica e limiti di conservazione propri. Secondo il parere di chi scrive, la soluzione consiste nel collegare esplicitamente i trigger di revisione della DPIA agli indicatori di deriva del modello e nel coordinare tutti gli obblighi di monitoraggio in un’architettura integrata dei rischi.
L’approfondimento completo di questo articolo è disponibile su 01magazine.it.
