ISO/IEC 27090:2026 e la sicurezza dei sistemi di intelligenza artificiale: la norma tecnica come ponte fra l’art. 32 GDPR, l’art. 15 dell’AI Act e gli obblighi NIS2

Abstract

Nell’ottobre 2026 ISO e IEC hanno pubblicato, per il tramite del Joint Technical Committee ISO/IEC JTC 1/SC 27, la prima edizione della norma internazionale ISO/IEC 27090, dedicata alla gestione delle minacce di sicurezza e delle compromissioni specifiche dei sistemi di intelligenza artificiale. Lo standard non introduce requisiti certificabili, ma fornisce una tassonomia strutturata degli attacchi propri dei sistemi di IA — avvelenamento dei dati, attacchi di evasione, inferenza di appartenenza, inversione del modello, esfiltrazione del modello, prompt injection — e, per ciascuno, descrive conseguenze, tecniche di rilevazione e misure di mitigazione lungo l’intero ciclo di vita. Il presente contributo sostiene che il documento, pur privo di efficacia normativa diretta e privo — allo stato — della qualificazione di norma armonizzata ai sensi dell’art. 40 del Regolamento (UE) 2024/1689, costituisce un riferimento tecnico rilevante per assolvere agli obblighi di sicurezza dell’art. 32 del Regolamento (UE) 2016/679, 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. L’analisi è rivolta a chi deve tradurre in misure documentate la clausola dello “stato dell’arte”.

Premessa

In premessa va detto che il rapporto fra norme tecniche volontarie e obblighi giuridici cogenti è, nella materia della protezione dei dati e della cybersicurezza, un rapporto consolidato ma non lineare. Il legislatore europeo, tanto nel Regolamento (UE) 2016/679 quanto nelle discipline successive, ha scelto in larga misura la tecnica della norma elastica: l’art. 32 GDPR non prescrive misure determinate, ma impone misure “adeguate” al rischio, da individuare “tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche”. La medesima tecnica è impiegata dall’art. 21 della Direttiva (UE) 2022/2555, che richiede misure “adeguate e proporzionate” secondo un approccio multirischio, e dall’art. 15 del Regolamento (UE) 2024/1689, che impone ai sistemi di IA ad alto rischio livelli adeguati di accuratezza, robustezza e cybersicurezza senza indicare, se non per cenni, le soluzioni tecniche concrete.

Trattasi di una scelta deliberata, che consente alla norma giuridica di non invecchiare al ritmo della tecnologia, ma che scarica sul titolare del trattamento, sul fornitore del sistema di IA e sul soggetto essenziale o importante ai sensi della disciplina NIS2 l’onere di individuare — e di documentare — il contenuto concreto dell’obbligo. È in questo spazio che operano le norme tecniche: non come fonti del diritto, ma come criteri di riempimento della clausola generale, come riferimento per il giudizio di diligenza e, in alcune ipotesi espressamente previste dal legislatore, come strumenti di presunzione di conformità.

La pubblicazione della prima edizione di ISO/IEC 27090 — datata ottobre 2026 — si colloca esattamente in questo spazio. Il perimetro dell’analisi che segue è duplice: da un lato la ricostruzione del contenuto dello standard e della sua collocazione sistematica nella famiglia delle norme ISO/IEC in materia di sicurezza delle informazioni e di gestione dell’intelligenza artificiale; dall’altro la verifica di quali obblighi giuridici, nell’ordinamento europeo e nazionale, possano trovare in quel contenuto un supporto operativo. Resta fuori dal perimetro ogni valutazione sulla qualità tecnica delle singole contromisure descritte, che attiene al dominio dell’ingegneria della sicurezza e non a quello giuridico.

Che cosa è ISO/IEC 27090 e dove si colloca

Il documento è stato elaborato dal Joint Technical Committee ISO/IEC JTC 1, Information technology, Sottocomitato SC 27, Information security, cybersecurity and privacy protection. Si tratta del medesimo organismo responsabile della famiglia ISO/IEC 27000, e segnatamente di ISO/IEC 27001 — lo standard certificabile sui sistemi di gestione della sicurezza delle informazioni — e di ISO/IEC 27002, che ne costituisce il repertorio dei controlli.

Lo scopo dichiarato, riportato nella clausola 1, è “address security threats and compromises specific to artificial intelligence (AI) systems”, con l’obiettivo di aiutare le organizzazioni a comprendere le conseguenze delle minacce di sicurezza specifiche dei sistemi di IA lungo il loro ciclo di vita e le modalità per rilevarle e mitigarle. Il documento si dichiara applicabile a organizzazioni di ogni tipo e dimensione, incluse imprese pubbliche e private, enti governativi e organizzazioni senza scopo di lucro, che sviluppino o utilizzino sistemi di IA.

Due precisazioni preliminari si rendono necessarie, perché incidono sul valore giuridico del documento.

La prima riguarda la natura del testo. ISO/IEC 27090 è una guidance, non un requirements standard. Non contiene, se non in rarissimi passaggi, prescrizioni formulate con il verbo “shall” — si segnala, nella clausola 5.1, l’affermazione secondo cui i controlli di sicurezza delle informazioni, quali quelli descritti in ISO/IEC 27002, “shall be implemented” in funzione delle esigenze dell’organizzazione e dei rischi individuati, nonché l’indicazione che le compromissioni specifiche dell’IA “shall be taken into account” lungo tutto il ciclo di vita. Ma il corpo del documento è costruito in termini di raccomandazione e di descrizione. Di conseguenza, non si dà certificazione di conformità a ISO/IEC 27090: la certificazione resta ancorata a ISO/IEC 27001 per la sicurezza delle informazioni e a ISO/IEC 42001 per il sistema di gestione dell’intelligenza artificiale.

La seconda precisazione riguarda il rapporto con il sistema della normazione armonizzata europea. ISO/IEC 27090 è una norma internazionale, non una norma armonizzata ai sensi dell’art. 40 del Regolamento (UE) 2024/1689. Gli standard destinati a produrre la presunzione di conformità ai requisiti dell’AI Act sono quelli elaborati dagli organismi europei di normazione su mandato della Commissione, i cui riferimenti sono pubblicati nella Gazzetta ufficiale dell’Unione europea. Fino a quel momento, ISO/IEC 27090 non attribuisce alcuna presunzione. Può tuttavia costituire — e questa è la tesi che si intende argomentare — un elemento di prova della diligenza tecnica adottata, rilevante sia nel dialogo con le autorità di controllo sia nella costruzione dell’accountability documentale.

Va aggiunto che il documento si inserisce in un reticolo di riferimenti normativi tecnici piuttosto denso. Richiama in modo vincolante ISO/IEC 22989, sui concetti e la terminologia dell’intelligenza artificiale, e ISO/IEC 23053:2022, sul quadro di riferimento per i sistemi di IA basati su apprendimento automatico. Rinvia poi, a titolo informativo, a ISO/IEC 5338 per i processi del ciclo di vita, a ISO/IEC 23894 per la gestione del rischio connesso all’IA, a ISO/IEC 38507 per le implicazioni di governance dell’uso dell’IA da parte degli organi di direzione, a ISO/IEC 42001 per il sistema di gestione dell’IA e a ISO/IEC 5259-1 per la qualità dei dati. In termini più pragmatici: chi abbia già in esercizio un sistema di gestione certificato ISO/IEC 27001 e stia valutando l’adozione di ISO/IEC 42001 troverà in ISO/IEC 27090 il tassello che collega i due mondi, ossia la declinazione dei rischi di sicurezza sul terreno specifico dei modelli e dei dati di addestramento.

Il quadro normativo di riferimento

La disciplina europea in materia di protezione dei dati

L’ancoraggio principale resta l’art. 32 GDPR, che impone al titolare e al responsabile del trattamento di mettere in atto “misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio”. La disposizione, al paragrafo 1, menziona a titolo esemplificativo la pseudonimizzazione e la cifratura, la capacità di assicurare su base permanente la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento, la capacità di ripristinare tempestivamente la disponibilità e l’accesso in caso di incidente fisico o tecnico, e una procedura per testare, verificare e valutare regolarmente l’efficacia delle misure.

Appare chiaro allo scrivente che la triade riservatezza-integrità-disponibilità richiamata dall’art. 32 coincide con la triade CIA attorno alla quale è costruita la clausola 5.1 di ISO/IEC 27090 e che il riferimento alla verifica periodica dell’efficacia delle misure trova corrispondenza nelle clausole dedicate al deterioramento delle mitigazioni nel tempo e al red teaming. Non si tratta di una coincidenza casuale: la famiglia ISO/IEC 27000 ha storicamente fornito il vocabolario tecnico su cui il legislatore europeo ha costruito la disciplina della sicurezza.

Rilevano inoltre l’art. 5, paragrafo 1, lettere d) ed f), GDPR, in punto di esattezza e di integrità e riservatezza dei dati; l’art. 24, sulla responsabilizzazione del titolare; l’art. 25, sulla protezione dei dati fin dalla progettazione e per impostazione predefinita; l’art. 35, sulla valutazione d’impatto, che nel caso di trattamenti basati su sistemi di IA è spesso obbligatoria in ragione dell’uso di nuove tecnologie e della valutazione sistematica di aspetti personali. Vanno infine considerati gli artt. 33 e 34 in materia di notifica e comunicazione delle violazioni dei dati personali: la tassonomia offerta dallo standard è utile proprio perché aiuta a qualificare come data breach fenomeni — si pensi all’inferenza di appartenenza riuscita — che a una lettura superficiale potrebbero non apparire tali.

Sul piano interpretativo, si segnala il parere del Comitato europeo per la protezione dei dati n. 28/2024, dedicato al trattamento di dati personali nel contesto dei modelli di intelligenza artificiale, che affronta tra l’altro la questione dell’anonimia dei modelli e della possibilità di estrarre dati personali dai modelli stessi. Il parere non si occupa in via diretta di sicurezza, ma la premessa da cui muove — la non automatica anonimità di un modello addestrato su dati personali — è presupposto logico della rilevanza giuridica degli attacchi di inversione del modello e di inferenza di appartenenza descritti nelle clausole 6.4 e 6.6 di ISO/IEC 27090.

Il Regolamento (UE) 2024/1689 e l’art. 15

L’art. 15 dell’AI Act è la disposizione che più direttamente intercetta il contenuto dello standard. Il paragrafo 1 richiede che i sistemi di IA ad alto rischio siano progettati e sviluppati in modo da conseguire un livello adeguato di accuratezza, robustezza e cybersicurezza e da mantenere prestazioni coerenti sotto tali profili per l’intero ciclo di vita. Il paragrafo 4 si occupa della resilienza rispetto a errori, guasti e incoerenze, nonché dei rischi connessi ai sistemi che continuano ad apprendere dopo l’immissione sul mercato, con particolare riguardo ai circuiti di retroazione distorti. Il paragrafo 5 è, per quanto di stretto interesse in questa sede, la disposizione chiave: impone che i sistemi ad alto rischio siano resilienti ai tentativi di terzi non autorizzati di alterarne l’uso, gli output o le prestazioni sfruttandone le vulnerabilità, e richiede che le soluzioni tecniche siano adeguate alle circostanze e ai rischi, menzionando espressamente — fra le vulnerabilità specifiche dell’IA — l’avvelenamento dei dati di addestramento, l’avvelenamento dei modelli preaddestrati, gli input concepiti per indurre l’errore del modello e i difetti del modello.

La corrispondenza con la tassonomia della clausola 6 dello standard è pressoché puntuale: il data poisoning attack della clausola 6.2 e il direct model poisoning della clausola 6.7 coprono le prime due ipotesi; l’evasion attack della clausola 6.3 copre la terza; la clausola 6.5 sull’esfiltrazione del modello e le clausole 6.4 e 6.6 sugli attacchi alla riservatezza coprono il versante degli attacchi di confidenzialità. Si ritiene pertanto che ISO/IEC 27090 costituisca, allo stato, il più organico riferimento tecnico internazionale per dare contenuto all’art. 15, paragrafo 5, dell’AI Act, pur con l’avvertenza già formulata circa l’assenza di effetti di presunzione.

Rilevano inoltre l’art. 9 dell’AI Act, sul sistema di gestione dei rischi, che richiede un processo iterativo continuo lungo tutto il ciclo di vita; l’art. 10, sulla governance dei dati di addestramento, validazione e prova, che impone requisiti di pertinenza, rappresentatività e — nella misura del possibile — assenza di errori e completezza, oltre all’esame di possibili distorsioni; l’art. 12, sulla registrazione automatica degli eventi, che trova diretto riscontro nella clausola 7.5 dello standard dedicata a logging and monitoring; l’art. 17, sul sistema di gestione della qualità. Per i modelli di IA per finalità generali con rischio sistemico, l’art. 55 impone esplicitamente di garantire un livello adeguato di protezione della cybersicurezza del modello e della relativa infrastruttura fisica. Infine, l’art. 42, paragrafo 2, prevede che i sistemi ad alto rischio certificati nell’ambito di un sistema europeo di certificazione della cybersicurezza adottato ai sensi del Regolamento (UE) 2019/881 siano presunti conformi ai requisiti di cybersicurezza dell’art. 15 nella misura in cui il certificato li copra: si tratta dell’unico canale di presunzione specificamente dedicato alla sicurezza, e non passa per le norme ISO.

La disciplina della cybersicurezza

La Direttiva (UE) 2022/2555 — recepita in Italia con il decreto legislativo 138/2024 — impone ai soggetti essenziali e importanti, all’art. 21, misure tecniche, operative e organizzative adeguate e proporzionate per gestire i rischi posti alla sicurezza dei sistemi informatici e di rete. Il paragrafo 2 elenca gli ambiti minimi, fra cui le politiche di analisi dei rischi, la gestione degli incidenti, la sicurezza della catena di approvvigionamento, la sicurezza dell’acquisizione, sviluppo e manutenzione dei sistemi, le strategie e procedure per valutare l’efficacia delle misure, l’uso della crittografia, la sicurezza delle risorse umane e il controllo degli accessi. Laddove il soggetto NIS2 sviluppi o utilizzi sistemi di IA in funzioni rilevanti per la continuità dei servizi, l’ambito applicativo dell’art. 21 si estende naturalmente a tali sistemi, e la clausola 5.5 di ISO/IEC 27090 sulla gestione della catena di fornitura specifica dell’IA offre un contributo mirato all’adempimento della lettera d) del citato paragrafo 2.

Va considerato altresì il Regolamento (UE) 2024/2847, il cosiddetto Cyber Resilience Act, che introduce requisiti essenziali di cybersicurezza per i prodotti con elementi digitali, categoria nella quale rientrano a pieno titolo i prodotti software che incorporano modelli di IA. Per il settore finanziario, il Regolamento (UE) 2022/2554 (DORA) detta un quadro autonomo di resilienza operativa digitale, con obblighi di gestione del rischio informatico, di test e di governo dei fornitori terzi critici che si intersecano con le problematiche descritte dallo standard quando l’entità finanziaria impieghi modelli di IA in processi rilevanti.

Il quadro nazionale

Sul versante interno, oltre al già citato decreto legislativo 138/2024 e al decreto legislativo 196/2003 come modificato dal decreto legislativo 101/2018, rileva la legge 132/2025, recante disposizioni e deleghe al Governo in materia di intelligenza artificiale, che ha definito l’assetto delle autorità nazionali competenti e ha affidato all’Agenzia per la cybersicurezza nazionale compiti in materia di vigilanza sui profili di sicurezza dei sistemi di IA. Si ritiene che l’interazione fra Agenzia per la cybersicurezza nazionale, Agenzia per l’Italia digitale e Garante per la protezione dei dati personali costituisca uno dei terreni più delicati dell’applicazione pratica dell’AI Act in Italia, e che l’adozione di riferimenti tecnici condivisi — fra i quali ISO/IEC 27090 può collocarsi — contribuisca a ridurre il rischio di valutazioni disomogenee.

L’architettura dello standard e la logica della tassonomia

La struttura del documento è articolata in sette clausole sostanziali e tre allegati informativi.

La clausola 5, intitolata Application of information security, svolge la funzione di raccordo con la sicurezza delle informazioni tradizionale. L’assunto di fondo, enunciato nell’introduzione, è che i sistemi di IA siano soggetti a tutte le vulnerabilità, agli exploit e agli attacchi tradizionali della cybersicurezza, e che le preoccupazioni aggiuntive “do not supersede conventional cybersecurity concerns”. In sostanza: la sicurezza dell’IA non sostituisce la sicurezza informatica, la presuppone. Il punto, apparentemente ovvio, ha una ricaduta giuridica non trascurabile, perché evita che l’adozione di contromisure esotiche contro attacchi adversariali possa essere spesa come surrogato di misure di base carenti. Lo standard, anzi, nella clausola 5.1 osserva che mettere in sicurezza lo stack software del sistema può essere un punto di partenza più efficiente: se la preoccupazione è la perdita di riservatezza del modello, proteggere lo stack contro il furto diretto del modello è verosimilmente più efficace di controlli ad alta intensità di risorse volti a contrastare tentativi di esfiltrazione via prompt o via API.

La medesima clausola 5 affronta poi, in sottosezioni distinte, il programma di governance dell’IA, i principi zero trust, l’applicazione delle buone pratiche di ingegneria del software, la gestione della catena di fornitura, la modellazione delle minacce e il red teaming.

La clausola 6 contiene la tassonomia vera e propria. Per ciascuna tipologia di compromissione lo standard adotta uno schema quadripartito costante: descrizione, fallimenti che ne derivano, rilevazione, mitigazione. Trattasi di una struttura che, dal punto di vista di chi deve costruire un registro dei rischi, ha un pregio notevole: consente di passare dalla minaccia astratta all’evento dannoso concreto e da questo alla misura, rendendo tracciabile la catena logica che l’art. 9 dell’AI Act e l’art. 32 GDPR richiedono di documentare.

La clausola 7 affronta un tema che la letteratura tecnica tende a trascurare e che invece ha rilievo giuridico diretto: l’interazione fra le mitigazioni. Vi si tratta dei conflitti fra contromisure, della continuità delle mitigazioni lungo il ciclo di vita, del deterioramento del modello e delle mitigazioni nel tempo, della registrazione e del monitoraggio, della protezione dell’ambiente di sviluppo, del rilevamento e filtraggio degli input malevoli, della limitazione della frequenza di utilizzo del modello e dell’ottimizzazione della dimensione del modello.

Gli allegati informativi mappano gli attacchi sul ciclo di vita del sistema di IA e sugli asset (Allegato A), descrivono le versioni specifiche per l’IA degli attacchi convenzionali (Allegato B) e trattano l’apprendimento federato (Allegato C).

Le minacce specifiche e la loro rilevanza giuridica

L’avvelenamento dei dati fra sicurezza ed esattezza

Lo standard definisce il data poisoning attack come l’attacco in cui l’attaccante “manipulates data to affect the artificial intelligence system’s behaviour”. La definizione va letta insieme all’avvertenza, contenuta nell’introduzione, secondo cui nella fase operativa i sistemi di IA raccolgono dati per supportare futuri aggiornamenti del modello, e tale processo può essere vulnerabile all’introduzione di dati corrotti; laddove vi sia apprendimento continuo o iterativo, gli input forniti in esercizio possono diventare dati di addestramento, sicché input corrotti diventano a loro volta un vettore di avvelenamento.

In termini più concreti: un sistema di raccomandazione o di scoring che si riaddestri periodicamente sui dati raccolti in produzione può essere progressivamente manipolato da un attaccante che inietti, attraverso l’uso legittimo del servizio, campioni costruiti ad arte. Il punto di contatto con la disciplina dei dati personali è immediato. L’art. 5, paragrafo 1, lettera d), GDPR impone che i dati personali siano esatti e, se necessario, aggiornati, e che siano adottate tutte le misure ragionevoli per cancellare o rettificare tempestivamente i dati inesatti rispetto alle finalità del trattamento. Un modello avvelenato produce inferenze inesatte su persone fisiche: la violazione si colloca quindi, simultaneamente, sul piano della sicurezza (art. 32) e su quello della qualità dei dati (art. 5). Oltre a ciò, l’art. 10 dell’AI Act, nel richiedere pratiche di governance dei dati che includano l’esame di possibili distorsioni e l’adozione di misure per individuarle, prevenirle e attenuarle, offre un ulteriore aggancio.

Lo standard, per questa categoria, dedica sottosezioni autonome alla rilevazione e alla mitigazione. Il dato interessante, per il giurista, è che la rilevazione sia trattata come problema distinto e non banale: l’introduzione al documento osserva che per alcune minacce ai sistemi di IA la rilevazione è difficile e che “developing controls without effective threat detection would not be useful or adequate”. Si ritiene che questa affermazione meriti attenzione nella prospettiva dell’art. 33 GDPR: un titolare che non sia in grado di rilevare l’avvelenamento difficilmente sarà in grado di rispettare il termine di settantadue ore dalla conoscenza della violazione, e la carenza di capacità di rilevazione è essa stessa, secondo il parere di chi scrive, una carenza di misure di sicurezza valutabile ai sensi dell’art. 32.

Inferenza di appartenenza e inversione del modello

La membership inference è definita come l’attacco che consente all’attaccante di determinare se un dato campione sia stato utilizzato o meno nel dataset di addestramento del modello. La model inversion è l’attacco con cui l’attaccante ricostruisce i dati di addestramento originali, o parti significative di essi, fornendo input al sistema e osservando i corrispondenti output.

Si tratta delle due fattispecie a maggiore densità giuridica dell’intero documento, perché incidono direttamente sulla riservatezza dei dati personali contenuti nel training set e, a monte, sulla stessa qualificazione del modello come dato anonimo o meno. Un attacco di inferenza di appartenenza riuscito su un modello addestrato, ad esempio, su una coorte clinica rivela che una determinata persona appartiene a quella coorte: un’informazione che, a seconda del contesto, può integrare un dato relativo alla salute ai sensi dell’art. 9 GDPR, anche in assenza di qualsiasi esfiltrazione del dataset originario. In termini più pragmatici: non occorre rubare il database per violarne la riservatezza; è sufficiente interrogare abbastanza volte il modello.

Lo standard introduce, nella clausola 3, anche le nozioni di direct training data leak, definito come compromissione della riservatezza dei dati di addestramento, di model input leak, ossia compromissione della riservatezza dei dati immessi nel modello durante l’esercizio, e di sensitive model output, definito come la compromissione, attraverso l’output del modello, della riservatezza di una porzione dei precedenti input del modello, quali dati di addestramento o prompt degli utenti. Quest’ultima categoria è particolarmente insidiosa nei sistemi conversazionali multiutente, dove il contenuto immesso da un utente può riaffiorare nelle risposte fornite a un altro.

Dal punto di vista della qualificazione giuridica, appare chiaro allo scrivente che ciascuna di queste ipotesi integri, al ricorrere dei presupposti, una violazione dei dati personali ai sensi dell’art. 4, numero 12, GDPR, trattandosi di divulgazione non autorizzata di dati personali. Ne discendono gli obblighi degli artt. 33 e 34. Si ritiene che l’inclusione esplicita di queste fattispecie nel registro delle violazioni potenziali e nelle procedure di incident response sia un adempimento tutt’altro che scontato e, allo stato, non diffuso: non si ha evidenza di una prassi consolidata in tal senso presso le organizzazioni italiane, benché il tema sia maturo.

Fra le mitigazioni, lo standard richiama la differential privacy, inserita fra i termini abbreviati come DP, e in generale le tecniche di limitazione dei dati, oggetto della clausola 6.11.2 intitolata Reduce impact by data limitation. Vi è qui una convergenza evidente con il principio di minimizzazione dell’art. 5, paragrafo 1, lettera c), GDPR e con l’art. 25, paragrafo 2, sulla protezione dei dati per impostazione predefinita: meno dati personali entrano nel modello, minore è la superficie di attacco per inferenza e inversione. La minimizzazione, in questo contesto, cessa di essere un vincolo formale e diventa una misura di sicurezza in senso proprio.

Esfiltrazione del modello e furto diretto

Il model exfiltration attack è definito come l’attacco in cui l’attaccante ricrea un modello con funzionalità simili a quelle dell’originale, attraverso l’uso ripetuto di input da lui forniti e l’osservazione dei corrispondenti output. Si distingue dal direct model theft, che consiste invece nell’ottenimento dei parametri riservati del modello.

L’introduzione del documento svolge su questo punto un ragionamento che merita di essere riportato: modelli e proprietà intellettuale possono essere sottratti anche in presenza di misure di sicurezza convenzionali efficaci, poiché l’attacco di esfiltrazione si realizza attraverso interrogazioni legittime del modello. Fra le mitigazioni convenzionali utili è indicata la limitazione della frequenza delle richieste, trattata anche nella clausola 7.8 come throttling model use.

Sul piano giuridico, la fattispecie interessa meno il GDPR e più la tutela del segreto commerciale e, per i soggetti NIS2, la protezione di asset rilevanti per la continuità del servizio. Resta tuttavia un profilo di protezione dei dati non marginale: un modello esfiltrato è un modello su cui l’attaccante può condurre, in ambiente controllato e senza limiti di interrogazione, attacchi di inversione volti a ricostruire i dati di addestramento. L’esfiltrazione del modello, in altri termini, è spesso il primo stadio di una catena che si conclude con la compromissione di dati personali.

Prompt injection e injection negli output

Il prompt injection attack è definito come l’attacco in cui l’attaccante confeziona contenuto fornito come istruzione di input al sistema di IA, o incorporato in essa, innescando un comportamento del sistema non previsto dai suoi creatori. La clausola 6.10 tratta poi l’ipotesi speculare in cui sia l’output del modello a contenere attacchi di injection, ossia il caso in cui il testo generato venga passato a un componente a valle che lo interpreti come codice o come comando.

Questa seconda ipotesi è, a giudizio di chi scrive, quella di maggiore impatto pratico nei contesti aziendali, perché si verifica tipicamente quando un modello linguistico viene integrato in flussi automatizzati — generazione di query, invocazione di API, produzione di contenuti poi renderizzati in pagine web — senza che l’output sia trattato come input non fidato. La raccomandazione tecnica è antica quanto la sicurezza applicativa, ma la sua applicazione ai sistemi generativi non è ancora prassi.

Il collegamento con la clausola 5.3, dedicata ai principi zero trust, è esplicito nel documento. Nella parte relativa ai sistemi ad agenti, lo standard osserva che per gli agenti di IA dotati di capacità di innescare azioni esterne ciascuna azione va verificata e autorizzata in modo indipendente, anziché concedere all’agente permessi ampi, e che va implementato un accesso just-in-time con ambito appropriato, assicurando che le autorizzazioni scadano al completamento del compito. Si tratta, tradotto nel linguaggio della protezione dei dati, dell’applicazione dei principi di limitazione delle finalità e di minimizzazione sul piano dei privilegi di accesso, nonché di un’attuazione dell’art. 25 GDPR sul versante architetturale.

La catena di fornitura dell’intelligenza artificiale

La clausola 5.5 dedica alla catena di fornitura cinque sottosezioni, distinguendo le minacce specifiche dell’IA, le catene complesse, i vettori di attacco specifici e le strategie di mitigazione. Il rilievo pratico del tema è considerevole: la quasi totalità delle organizzazioni italiane che adottano sistemi di IA non addestra modelli propri, ma integra modelli preaddestrati, pesi scaricati da repository pubblici, librerie di terze parti e servizi erogati in modalità as a service.

Da ciò discendono conseguenze giuridiche su più piani. Sul piano del GDPR, viene in rilievo l’art. 28, con l’obbligo di ricorrere unicamente a responsabili che presentino garanzie sufficienti per mettere in atto misure tecniche e organizzative adeguate, e il relativo contenuto contrattuale minimo, nonché l’art. 32 nella sua dimensione di estensione lungo la filiera. Sul piano NIS2, l’art. 21, paragrafo 2, lettera d), impone misure specifiche sulla sicurezza della catena di approvvigionamento, tenendo conto delle vulnerabilità specifiche di ciascun fornitore diretto e della qualità complessiva dei suoi prodotti e delle sue pratiche di cybersicurezza. Sul piano dell’AI Act, l’art. 25 disciplina le ipotesi in cui un distributore, un importatore, un deployer o un altro terzo sia considerato fornitore di un sistema ad alto rischio, e l’art. 26 individua gli obblighi dei deployer, fra cui l’uso conforme alle istruzioni e il monitoraggio del funzionamento. Per i modelli per finalità generali, l’art. 53 prevede obblighi di documentazione tecnica e di informazione ai fornitori a valle, che costituiscono il presupposto informativo senza il quale la valutazione del rischio di filiera resta un esercizio astratto.

L’avvertenza contenuta nell’introduzione dello standard — secondo cui la scelta di utilizzare dati non vagliati o non verificati per l’addestramento aumenta i rischi connessi all’avvelenamento dei dati e agli attacchi che sfruttano i flussi di dati e di controllo dell’apprendimento automatico — si traduce, in termini contrattuali, nella necessità di pretendere dal fornitore informazioni sulla provenienza dei dati. Lo standard definisce la data provenance come l’informazione sul luogo e sul tempo di origine, derivazione o generazione di un dataset, la prova di autenticità del dataset o la registrazione della titolarità passata e presente dello stesso, e vi dedica la clausola 6.11.4. Si ritiene che la clausola sulla provenienza dei dati e dei modelli debba diventare un elemento standard della contrattualistica di approvvigionamento di soluzioni di IA, al pari delle clausole sulla localizzazione dei dati e sulla gestione dei sotto-responsabili.

Governance, zero trust e il raccordo con i sistemi di gestione

La clausola 5.2 raccomanda l’istituzione e l’attuazione di un programma di governance dell’IA, che comporta l’assunzione di responsabilità organizzativa mediante il mantenimento di un inventario dei sistemi di IA e dei relativi usi, l’esecuzione di analisi del rischio su di essi e la gestione di tali rischi, con rinvio a ISO/IEC 38507 e, per l’implementazione, a ISO/IEC 42001.

L’inventario dei sistemi di IA è, secondo il parere di chi scrive, l’adempimento a più alto rapporto fra utilità e costo dell’intero impianto. Esso costituisce il presupposto fattuale di una pluralità di obblighi eterogenei: la mappatura dei trattamenti ai fini del registro dell’art. 30 GDPR, l’individuazione dei sistemi che ricadono nelle categorie ad alto rischio dell’Allegato III dell’AI Act, la verifica degli obblighi di trasparenza dell’art. 50, la valutazione della necessità di una valutazione d’impatto ai sensi dell’art. 35 GDPR e, per i sistemi ad alto rischio utilizzati da organismi pubblici o da soggetti privati che forniscono servizi pubblici, della valutazione d’impatto sui diritti fondamentali prevista dall’art. 27 dell’AI Act. Non si ha evidenza, nella prassi osservabile, che l’inventario dei sistemi di IA sia oggi diffuso con la stessa capillarità del registro dei trattamenti; eppure il primo è, in larga misura, condizione di completezza del secondo.

Quanto ai principi zero trust, lo standard li richiama rinviando alla clausola 8.27 di ISO/IEC 27002:2022 e li riassume nell’assunzione che i sistemi informativi dell’organizzazione siano già compromessi, nell’approccio “never trust and always verify” per l’accesso ai sistemi, nella cifratura end-to-end delle richieste, nella verifica di ogni richiesta come se provenisse dall’esterno, nell’uso del controllo degli accessi a privilegio minimo — incluso l’accesso all’interazione con il modello — e nell’autenticazione costante dei richiedenti con validazione delle autorizzazioni. Lo standard declina poi tali principi sul ciclo di vita dell’IA: protezione dei dati di addestramento con verifica della provenienza e dell’integrità prima dell’inserimento nelle pipeline, controlli di accesso granulari sulle interazioni con il modello, confini applicativi rigidi fra applicazioni di IA e fonti dati sottostanti — con autenticazione e autorizzazione indipendenti di ciascuna richiesta di recupero documentale nei sistemi di retrieval augmented generation —, verifica delle azioni degli agenti e monitoraggio continuo con definizione di linee di base comportamentali.

Il punto relativo ai sistemi RAG merita una sottolineatura, perché risolve sul piano architetturale un problema che molte organizzazioni affrontano sul piano puramente informativo: l’assistente conversazionale aziendale che attinga a un repository documentale deve ereditare i permessi dell’utente finale, non quelli del servizio. In difetto, il sistema diventa un canale di aggiramento della segregazione degli accessi e, di conseguenza, una misura di sicurezza preesistente viene neutralizzata dall’introduzione della nuova tecnologia. Trattasi, con ogni probabilità, della più frequente fra le criticità riscontrabili nei progetti di IA generativa interna.

Profili critici

Un primo profilo critico attiene, come anticipato, all’assenza di valore di presunzione. L’organizzazione che allinei i propri controlli a ISO/IEC 27090 non acquista per ciò solo una posizione di conformità opponibile all’autorità di controllo. Il GDPR, agli artt. 40 e 42, riconosce rilievo probatorio ai codici di condotta approvati e ai meccanismi di certificazione approvati, non alle norme tecniche internazionali in quanto tali. L’AI Act, agli artt. 40 e 41, riserva l’effetto di presunzione alle norme armonizzate e alle specifiche comuni. Lo standard può dunque operare come elemento di valutazione della diligenza, non come fondamento di una presunzione di conformità. Si suggerisce, di conseguenza, di evitare che nella documentazione interna la conformità allo standard venga rappresentata come conformità normativa: sarebbe una rappresentazione imprecisa e, in sede di accertamento, controproducente.

Un secondo profilo riguarda l’accessibilità del documento. ISO/IEC 27090, come tutte le norme ISO, è un documento a pagamento e soggetto a licenza d’uso. La nota di copyright riportata nel documento precisa che il contenuto è fornito in licenza e non venduto, e che la riproduzione, distribuzione, modifica, uso o messa a disposizione in qualunque forma sono vietati al di fuori di quanto richiesto per l’implementazione o espressamente consentito. Per le organizzazioni di minori dimensioni — che pure lo standard dichiara di voler servire — il costo di acquisizione della normativa tecnica rilevante, moltiplicato per il numero di standard richiamati per rinvio, costituisce una barriera non trascurabile. Non si ha evidenza, allo stato, di iniziative che ne rendano disponibile il contenuto a condizioni agevolate per le piccole e medie imprese, al di fuori dei consueti canali di adesione agli enti nazionali di normazione.

Un terzo profilo è di natura sostanziale e riguarda il rapporto fra mitigazioni. Lo standard dedica alla questione la clausola 7.2, intitolata Conflicting interactions of mitigations, riconoscendo dunque che le contromisure possono confliggere fra loro. L’esempio più evidente, ancorché non necessariamente quello sviluppato nel documento, è il rapporto fra tecniche di tutela della riservatezza — quali la differential privacy — e accuratezza del modello: l’introduzione di rumore riduce la ricostruibilità dei dati di addestramento ma degrada le prestazioni. Il che, nella prospettiva dell’art. 15 dell’AI Act, pone un problema di bilanciamento fra due requisiti posti dalla medesima disposizione, accuratezza da un lato e cybersicurezza dall’altro. Si ritiene che la soluzione non possa che essere documentale: il bilanciamento va esplicitato, motivato e verbalizzato nell’ambito del sistema di gestione dei rischi dell’art. 9, perché in sede di controllo la domanda non sarà se il trade-off sia stato risolto nel modo migliore, ma se sia stato consapevolmente affrontato.

Un quarto profilo attiene al deterioramento nel tempo, oggetto della clausola 7.4. Un modello le cui prestazioni degradino per effetto della deriva dei dati, o le cui mitigazioni perdano efficacia rispetto a tecniche di attacco evolute, diventa progressivamente non conforme pur in assenza di qualsiasi modifica. Il punto interseca l’obbligo di monitoraggio successivo all’immissione sul mercato previsto dall’art. 72 dell’AI Act, l’obbligo di segnalazione degli incidenti gravi dell’art. 73 e, sul versante della protezione dei dati, l’obbligo di riesame periodico della valutazione d’impatto previsto dall’art. 35, paragrafo 11, GDPR. Si suggerisce di collegare esplicitamente i trigger di riesame della DPIA agli indicatori di deriva del modello.

Un quinto profilo, infine, riguarda la sovrapposizione dei quadri di gestione. Lo standard stesso, nella clausola 5.1, raccomanda diligenza nel navigare fra standard di sistema di gestione per la sicurezza e per l’IA e standard di sicurezza dell’IA. L’avvertenza è fondata: un’organizzazione può trovarsi a gestire contemporaneamente un sistema di gestione della sicurezza delle informazioni, un sistema di gestione dell’IA, un modello di organizzazione e gestione ai sensi del decreto legislativo 231/2001, un sistema di gestione del rischio ai sensi di DORA e gli adempimenti NIS2. Il rischio di duplicazione documentale e di dispersione delle responsabilità è concreto, e secondo il parere di chi scrive va affrontato con un’architettura integrata dei processi di risk assessment, non con la giustapposizione di procedure parallele.

Indicazioni operative per il DPO e per l’impresa

Il primo passaggio operativo consiste nel costruire o aggiornare l’inventario dei sistemi di intelligenza artificiale, censendo non soltanto le applicazioni acquistate come tali, ma anche le funzionalità basate su modelli incorporate in prodotti di terze parti e gli usi spontanei di strumenti generativi da parte del personale. Tale inventario va riconciliato con il registro dei trattamenti dell’art. 30 GDPR, poiché ogni sistema che tratti dati personali deve trovare corrispondenza in una o più attività registrate, e va arricchito con l’indicazione del ruolo dell’organizzazione — fornitore, deployer, importatore o distributore — ai sensi degli artt. 25 e 26 dell’AI Act, perché da tale qualificazione discendono obblighi profondamente diversi.

Sulla base dell’inventario si procede all’estensione dell’analisi dei rischi alle minacce specifiche descritte nella clausola 6 dello standard. In concreto, si tratta di verificare se la metodologia di risk assessment già in uso — tipicamente quella del sistema di gestione della sicurezza delle informazioni — contempli scenari di avvelenamento dei dati, di evasione, di inferenza di appartenenza, di inversione del modello, di esfiltrazione del modello e di prompt injection. Nella prassi di audit si osserva che tali scenari sono spesso assenti, per la semplice ragione che le librerie di minacce comunemente adottate precedono la diffusione dei modelli generativi. L’aggiornamento della libreria di minacce è dunque, logicamente e cronologicamente, il primo intervento tecnico da programmare.

Segue la revisione della valutazione d’impatto sulla protezione dei dati per i trattamenti che impiegano sistemi di IA. La DPIA deve dare conto, nella sezione dedicata alle misure di sicurezza, delle contromisure specificamente adottate contro gli attacchi alla riservatezza dei dati di addestramento, e deve esplicitare il ragionamento che ha condotto a ritenere, o a non ritenere, il modello addestrato come contenente dati personali — questione sulla quale il parere EDPB n. 28/2024 fornisce criteri di analisi. Laddove la valutazione concluda per la permanenza di un rischio elevato non adeguatamente mitigato, si ricorda che l’art. 36 GDPR impone la consultazione preventiva del Garante.

Va poi curata la qualificazione delle compromissioni specifiche dell’IA come violazioni dei dati personali all’interno delle procedure di gestione degli incidenti. In termini più pragmatici, la procedura di data breach deve contemplare espressamente, fra gli eventi rilevanti, la sottrazione di dati di addestramento tramite inversione del modello, l’emersione di dati di un utente nell’output destinato ad altri e la compromissione dell’integrità del modello che determini decisioni inesatte su persone fisiche. Al medesimo tempo, per i soggetti rientranti nell’ambito del decreto legislativo 138/2024, occorre raccordare tale procedura con gli obblighi di notifica all’Agenzia per la cybersicurezza nazionale, che seguono tempistiche e soglie proprie, e per i fornitori di sistemi ad alto rischio con l’obbligo di segnalazione degli incidenti gravi dell’art. 73 dell’AI Act.

Sul versante contrattuale si impone la revisione degli accordi con i fornitori di soluzioni di IA, con particolare attenzione a tre contenuti. Il primo è l’informazione sulla provenienza dei dati di addestramento e sull’eventuale ricorso a dati non vagliati, perché da essa dipende la valutazione del rischio di avvelenamento a monte. Il secondo è l’obbligo di notifica tempestiva al cliente delle vulnerabilità e degli incidenti che interessino il modello o l’infrastruttura, con tempistiche compatibili con i termini di notifica che gravano sul cliente stesso. Il terzo è il diritto di audit o, in subordine, l’impegno a fornire evidenze documentali delle misure adottate, dato che la mera dichiarazione di conformità a uno standard non soddisfa l’onere di verifica che l’art. 28 GDPR pone in capo al titolare.

Si rende inoltre necessaria la definizione di controlli architetturali sull’accesso ai modelli e alle fonti dati, secondo i principi zero trust richiamati dallo standard. Il presidio minimo consiste nel garantire che i sistemi di retrieval augmented generation propaghino i permessi dell’utente finale alle fonti documentali interrogate, che ogni azione eseguita da agenti autonomi verso sistemi esterni sia autorizzata singolarmente e con privilegi a scadenza, e che gli output dei modelli destinati a essere consumati da componenti a valle siano trattati come input non fidati e sottoposti a validazione. Si tratta, va detto, di misure che ricadono nel perimetro dell’art. 25 GDPR e che vanno pertanto decise in fase di progettazione, non aggiunte a valle.

Quanto alla verifica di efficacia, l’art. 32, paragrafo 1, lettera d), GDPR richiede una procedura per testare e valutare regolarmente le misure. Nel contesto dei sistemi di IA ciò si traduce nell’introduzione di attività di red teaming e di test avversariali periodici, raccomandate dalla clausola 5.7 dello standard, i cui esiti vanno documentati e collegati al piano di trattamento del rischio. Si suggerisce di prevedere che la periodicità di tali attività non sia soltanto calendariale ma anche condizionata da eventi — riaddestramento del modello, modifica sostanziale del dataset, aggiornamento del modello di base fornito da terzi — poiché ciascuno di essi può invalidare le risultanze dei test precedenti.

Va parimenti disciplinata la registrazione degli eventi e il monitoraggio comportamentale, che lo standard tratta nella clausola 7.5 e che l’art. 12 dell’AI Act impone come requisito per i sistemi ad alto rischio. Il DPO dovrà qui vigilare su un profilo delicato: la registrazione delle interrogazioni e degli output, necessaria per rilevare pattern anomali indicativi di tentativi di esfiltrazione o di inferenza, costituisce a sua volta un trattamento di dati personali, che richiede base giuridica, limiti di conservazione e informativa adeguati. Laddove gli utenti del sistema siano lavoratori, occorre inoltre valutare l’applicabilità dell’art. 4 della legge 300/1970, poiché il monitoraggio dell’uso di strumenti di IA può integrare un controllo a distanza dell’attività lavorativa, con i conseguenti adempimenti di accordo sindacale o autorizzazione amministrativa, salvo che non ricorra l’ipotesi degli strumenti utilizzati per rendere la prestazione.

Infine, si raccomanda la formazione mirata delle funzioni coinvolte, distinta per destinatari. Il personale tecnico necessita di consapevolezza sulla tassonomia degli attacchi e sulle relative mitigazioni; le funzioni di acquisto necessitano di criteri per la qualificazione dei fornitori di IA; il management necessita di comprendere che l’introduzione di un sistema di IA modifica il profilo di rischio dell’organizzazione e può attivare obblighi nuovi. L’art. 4 dell’AI Act impone del resto ai fornitori e ai deployer di adottare misure per garantire un livello sufficiente di alfabetizzazione in materia di IA del proprio personale: si tratta di un obbligo autonomo, la cui attuazione può utilmente essere integrata nei piani formativi già previsti in materia di protezione dei dati e di sicurezza delle informazioni.

Conclusioni

La pubblicazione di ISO/IEC 27090 colma un vuoto nel panorama della normazione tecnica: fino ad oggi la sicurezza dei sistemi di intelligenza artificiale era trattata o all’interno di quadri generali di gestione del rischio, privi di granularità sulle minacce specifiche, o in documenti settoriali di provenienza accademica e industriale, privi dell’autorevolezza e della stabilità proprie di una norma internazionale. Il documento offre un vocabolario condiviso e una struttura analitica — minaccia, fallimento, rilevazione, mitigazione — che si presta a essere riversata nella documentazione di conformità.

Restano aperte alcune questioni di non poco momento. La prima riguarda il raccordo con la normazione armonizzata europea: se e in quale misura i lavori del comitato tecnico europeo competente recepiranno i contenuti di ISO/IEC 27090 ai fini dell’art. 40 dell’AI Act è, allo stato, non determinabile; non si ha evidenza di decisioni formali in tal senso. Dall’esito di tale raccordo dipende se lo standard resterà uno strumento di diligenza o acquisterà rilievo presuntivo.

La seconda questione aperta attiene all’onere probatorio. Né il GDPR né l’AI Act chiariscono quale peso debba essere riconosciuto, in sede di accertamento della violazione o di quantificazione della sanzione, all’allineamento a norme tecniche non armonizzate. L’art. 83, paragrafo 2, lettera d), GDPR menziona il grado di responsabilità del titolare tenendo conto delle misure tecniche e organizzative adottate ai sensi degli artt. 25 e 32, e la lettera j) considera l’adesione a codici di condotta e meccanismi di certificazione: si ritiene plausibile che l’adozione documentata di uno standard internazionale rilevi nell’ambito della prima, ma non si ha evidenza di orientamenti consolidati del Garante o del Comitato europeo su questo specifico punto.

La terza questione riguarda la sostenibilità dell’impianto per le organizzazioni di dimensioni medio-piccole, che costituiscono la parte prevalente del tessuto produttivo nazionale e che si trovano ad affrontare, nel medesimo arco temporale, l’adeguamento NIS2, l’applicazione progressiva dell’AI Act e, per i produttori di prodotti con elementi digitali, il Cyber Resilience Act. Il rischio, a giudizio di chi scrive, non è tanto l’inadempimento quanto l’adempimento formale: la produzione di documentazione conforme nella struttura e disallineata rispetto alla realtà operativa. Il contributo che norme come ISO/IEC 27090 possono offrire dipende, in ultima analisi, dalla capacità delle organizzazioni di utilizzarle come strumenti di analisi e non come indici di una documentazione da compilare.

La quarta e ultima questione è di prospettiva. Lo standard descrive un panorama di minacce che evolve con rapidità superiore a quella del ciclo di revisione delle norme tecniche, il quale si misura in anni. Il documento ne è consapevole, laddove osserva nell’introduzione che l’emergere di nuove vulnerabilità può richiedere una valutazione continua degli obiettivi di sicurezza. Ne discende che l’allineamento a ISO/IEC 27090 non può essere concepito come adempimento puntuale, ma come adozione di un metodo: quello che lega l’inventario dei sistemi alla libreria delle minacce, la libreria delle minacce al piano di trattamento del rischio e il piano di trattamento alla verifica periodica di efficacia. È questo metodo, e non la conformità a una lista di controlli, che l’art. 32 GDPR e l’art. 9 dell’AI Act, letti insieme, richiedono.

Riferimenti normativi

• Regolamento (UE) 2016/679 (GDPR)
• Regolamento (UE) 2019/881 (Cybersecurity Act)
• Regolamento (UE) 2022/2554 (DORA)
• Regolamento (UE) 2024/1689 (AI Act)
• Regolamento (UE) 2024/2847 (Cyber Resilience Act)
• Direttiva (UE) 2022/2555 (NIS2)
• Legge 20 maggio 1970, n. 300 (Statuto dei lavoratori)
• Decreto legislativo 8 giugno 2001, n. 231
• Decreto legislativo 30 giugno 2003, n. 196 (Codice in materia di protezione dei dati personali)
• Decreto legislativo 10 agosto 2018, n. 101
• Decreto legislativo 4 settembre 2024, n. 138
• Legge 23 settembre 2025, n. 132
• Parere del Comitato europeo per la protezione dei dati n. 28/2024
• ISO/IEC 27090:2026
• ISO/IEC 27001:2022
• ISO/IEC 27002:2022
• ISO/IEC 22989
• ISO/IEC 23053:2022
• ISO/IEC 23894
• ISO/IEC 5338
• ISO/IEC 5259-1:2024
• ISO/IEC 38507
• ISO/IEC 42001:2023