ISO 27090 spiegata per i team di sicurezza dell'IA

La ISO/IEC 27090:2026 è uno standard internazionale che fornisce indicazioni sulle minacce alla sicurezza e sulle compromissioni che riguardano i sistemi di intelligenza artificiale. Pubblicata il 14 ottobre 2026, illustra come le organizzazioni possono comprendere, rilevare e mitigare tali minacce lungo l'intero ciclo di vita dell'IA. Il suo titolo formale è Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems. Scheda di pubblicazione ISO

Per un team di sicurezza la domanda pratica è semplice: che cosa potrebbe modificare o sottrarre un attaccante, o che cosa potrebbe indurre a fare un sistema di IA, e che cosa limiterebbe il danno che ne deriva?

Questa guida spiega l'ambito dello standard ISO 27090, le principali minacce alla sicurezza dell'IA, il suo rapporto con ISO 27001 e ISO 42001 e un modo pratico per tradurre le indicazioni in attività di sicurezza con responsabili, misure di salvaguardia ed evidenze. Le ricerche su cui si basa sono state verificate il 18 ottobre 2026.

Che cosa copre lo standard ISO 27090

La ISO 27090 si concentra sulla protezione dei sistemi di IA. Il suo oggetto va oltre l'IA generativa, i modelli linguistici di grandi dimensioni e i chatbot, e si estende ai sistemi di IA in senso più ampio. Spiegazione ISO della ISO 27090

Lo standard pubblicato collega pratiche consolidate di sicurezza delle informazioni con minacce specifiche dell'IA. I suoi contenuti trattano governance, sicurezza della supply chain, threat modelling e red teaming, seguiti dai tipi di compromissione, tra cui poisoning, evasione, esposizione di informazioni e prompt injection. Considera inoltre come le misure di mitigazione interagiscono tra loro e come restano efficaci nel tempo. Estratto pubblicato della ISO/IEC 27090

L'ambito comprende organizzazioni di qualsiasi dimensione che sviluppano o utilizzano l'IA, comprese imprese, enti pubblici e organizzazioni senza scopo di lucro. Acquistare un servizio di IA di terze parti, quindi, non pone un'organizzazione al di fuori del pubblico a cui lo standard si rivolge. Scheda di pubblicazione IEC

Un utile punto di partenza è una revisione congiunta che coinvolga sicurezza, engineering, dati, procurement e il responsabile di business. Ciascuno dovrebbe saper spiegare la parte del sistema che controlla e le decisioni per cui dipende da altri.

Perché i sistemi di IA richiedono un'analisi di sicurezza aggiuntiva

Un'applicazione di IA collega diversi elementi che meritano un esame distinto: software, dati, file o servizi del modello, istruzioni, utenti e azioni a valle.

Pensate a un assistente documentale collegato a una knowledge base interna. Una revisione convenzionale può esaminare autenticazione, cifratura e vulnerabilità del software. Una revisione della sicurezza dell'IA dovrebbe chiedersi anche che cosa accade se un documento recuperato tenta di modificare le istruzioni dell'assistente, se gli utenti possono recuperare materiale al di fuori dei propri permessi e quali azioni l'output generato può attivare.

Queste domande diventano più rilevanti quando un assistente può aggiornare record o richiamare strumenti esterni. Una risposta errata e un'azione non autorizzata hanno conseguenze diverse e richiedono misure di salvaguardia diverse.

Per la vostra prima revisione, mappate tre domande:

• Che cosa può influenzare il sistema? Includete dati di addestramento, contenuti recuperati, prompt, fornitori e aggiornamenti del modello.
• Che cosa può uscire dal sistema? Includete risposte, log, esportazioni e asset del modello.
• Che cosa può modificare il sistema? Includete file, ticket, account, transazioni e altri servizi collegati.

Si tratta di un metodo pratico per delimitare l'ambito degli esempi che seguono, non di una riproduzione delle clausole dello standard.

Le minacce alla sicurezza dell'IA da comprendere

Le spiegazioni che seguono utilizzano la terminologia del NIST sull'adversarial machine learning e le indicazioni dell'OWASP per le applicazioni LLM. Gli scenari sono illustrativi. Tassonomia NIST dell'adversarial machine learning Indicazioni OWASP sulla prompt injection Indicazioni OWASP sulla gestione dell'output

Mantenete chiare le distinzioni durante una valutazione del rischio. Un documento malevolo recuperato da un'applicazione di retrieval-augmented generation (RAG) non costituisce automaticamente un poisoning dei dati di addestramento: il recupero, di per sé, non aggiorna i pesi del modello. Può invece esporre l'applicazione a una prompt injection indiretta.

Per la sicurezza degli LLM, prompt più robusti da soli rappresentano una strategia di controllo incompleta. L'OWASP raccomanda misure di salvaguardia come privilegi limitati e approvazione per le azioni sensibili, mentre l'NCSC sottolinea la necessità di gestire la prompt injection come un rischio continuo attraverso la progettazione e l'esercizio del sistema. Indicazioni OWASP sulla prompt injection Indicazioni NCSC sul rischio di prompt injection

ISO 27090 a confronto con ISO 27001 e ISO 42001

Questi standard supportano parti diverse del lavoro di un'organizzazione in materia di sicurezza e di governance dell'IA.

Le distinzioni seguono le descrizioni degli editori di ISO 27001, ISO 27002 e ISO 42001.

Per un team che gestisce già un SGSI, un approccio pratico consiste nell'estendere le registrazioni esistenti. Aggiungete all'inventario degli asset i sistemi di IA pertinenti, valutatene i percorsi di attacco, assegnate i responsabili del trattamento e collegate le evidenze a supporto. Per un approfondimento su come organizzare questo lavoro, consultate la checklist per l'implementazione della ISO 27001.

Una checklist pratica per implementare la ISO 27090

I passaggi seguenti sono un approccio di implementazione costruito a partire dai temi dello standard e dalle indicazioni pubbliche sull'IA sicura. Non sono una checklist ufficiale ISO né un elenco di clausole obbligatorie.

1. Definite il sistema e il suo responsabile

Scegliete un caso d'uso dell'IA con una finalità di business chiara. Registrate il responsabile, gli utenti, il fornitore del modello, la modalità di hosting e i servizi collegati.

Tracciate poi il perimetro della revisione. Includete l'applicazione e le sue dipendenze, non solo l'endpoint del modello. Un assistente rivolto ai clienti con accesso a strumenti richiede una valutazione diversa da un sistema interno di riassunto dei testi senza alcun permesso di agire.

Output utile: una scheda del sistema che ne indica finalità, perimetro, dipendenze, azioni consentite e responsabile.

2. Tracciate la provenienza dei dati e del modello

Registrate da dove provengono i dataset e gli artefatti del modello, chi può modificarli e quali versioni sono distribuite. Includete gli input di fine-tuning, le raccolte usate per il retrieval, i prompt e i canali di feedback rilevanti per il sistema.

Le linee guida NCSC sullo sviluppo raccomandano di tracciare gli asset di IA e la loro provenienza, di proteggerli e di conservare le informazioni necessarie per ripristinare versioni affidabili. Linee guida NCSC sullo sviluppo sicuro dell'IA

Per un modello acquistato, chiedete al fornitore quali responsabilità si assume e quali informazioni mette a disposizione quando modelli o servizi cambiano.

Output utile: un inventario con versioni, fonti, regole di accesso, cronologia delle modifiche e responsabilità dei fornitori.

3. Eseguite il threat modelling del flusso di lavoro reale

Esaminate il sistema dal punto di vista di un attaccante. Individuate i punti di ingresso, gli asset sensibili, i permessi e le conseguenze di una compromissione riuscita. Le linee guida NCSC sulla progettazione sicura raccomandano il threat modelling e l'attenzione ai componenti di terze parti e al principio del privilegio minimo. Linee guida NCSC sulla progettazione sicura dell'IA

Descrivete scenari concreti. «Rischio IA» è troppo generico per orientare un'azione utile. «Un documento caricato da un soggetto esterno induce l'assistente a richiedere un file di evidenze riservato» offre al team qualcosa di specifico da analizzare.

Stabilite le priorità in base all'esposizione e al danno potenziale. Registrate chi accetta il rischio residuo e quando tale decisione dovrebbe essere riesaminata.

Output utile: un breve registro dei rischi che collega gli scenari di attacco ad asset, conseguenze, misure di salvaguardia e responsabili.

4. Collocate le misure di salvaguardia sui confini pertinenti

Selezionate i controlli in funzione dello scenario che state affrontando. Per gli asset del modello, ciò può comportare archiviazione protetta, restrizioni di accesso e controlli di integrità. Per i servizi distribuiti, considerate l'autenticazione, la separazione tra ambienti e i controlli che riducono gli accessi non autorizzati o l'esfiltrazione. Sono temi trattati nelle linee guida NCSC sul deployment. Linee guida NCSC sul deployment sicuro dell'IA

Per l'output generato, convalidate e codificate il contenuto in funzione della sua destinazione prima che un altro sistema agisca su di esso. Le indicazioni OWASP sulla gestione dell'output spiegano perché l'output del modello non dovrebbe acquisire autorità solo perché proviene dal modello. Indicazioni OWASP sulla gestione dell'output

Output utile: una scheda del controllo che indica il confine che protegge, il suo responsabile e le evidenze usate per verificarlo.

5. Testate l'applicazione completa

Progettate i test intorno alle conseguenze individuate nel vostro threat model. Per un assistente RAG, utilizzate documenti avversari e utenti con permessi diversi. Per un agente, verificate che cosa accade quando un contenuto recuperato gli chiede di andare oltre le azioni consentite.

Definite il risultato atteso prima di eseguire il test. Un esempio: l'applicazione deve negare la richiesta di un file riservato anche se il modello tenta di effettuarla.

Registrate la configurazione dell'applicazione, la versione del modello, gli input del test, il risultato ed eventuali interventi correttivi. Scegliete dati di test che non espongano inutilmente informazioni riservate reali.

Output utile: test di sicurezza ripetibili collegati a rischi specifici e a decisioni di rilascio.

6. Monitorate le modifiche e preparate una risposta

Valutate l'effetto degli aggiornamenti di modelli, dati e prompt. Monitorate input e output rilevanti proteggendo al tempo stesso le informazioni sensibili nei log. Le linee guida operative NCSC evidenziano il monitoraggio del comportamento e le implicazioni di sicurezza delle modifiche durante tutto l'esercizio. Linee guida NCSC sull'esercizio sicuro dell'IA

Decidete in anticipo chi può disattivare uno strumento, revocare una credenziale, isolare un'integrazione o annullare un rilascio. Stabilite eventi che attivano un riesame, come un nuovo fornitore, permessi ampliati, un aggiornamento sostanziale del modello o un incidente di sicurezza.

Output utile: responsabilità di monitoraggio, criteri di riesame delle modifiche, una procedura di risposta agli incidenti e un percorso di ripristino testato.

Trasformare i rischi per la sicurezza dell'IA in evidenze

La tabella seguente è un modello di lavoro suggerito. Gli esempi di evidenze sono raccomandazioni pratiche, non un elenco di documenti richiesti dalla ISO 27090.

Immaginate, per esempio, un team di sicurezza che utilizza un assistente per riassumere le evidenze dei clienti. Un documento di un fornitore contiene istruzioni per caricare le evidenze a un indirizzo esterno.

Il test del team dovrebbe seguire l'azione tentata attraverso l'applicazione. L'assistente dispone di uno strumento in grado di caricare file? Quello strumento applica i permessi dell'utente? Le destinazioni sono limitate? È richiesta l'approvazione del trasferimento da parte di una persona responsabile?

Una registrazione utile della revisione identificherebbe lo scenario, il confine che impedisce il trasferimento, l'esito del test e la persona che ha approvato il rischio residuo. Se il sistema cambia, quella registrazione indica al revisore successivo che cosa deve essere verificato di nuovo.

Questo approccio dà a una valutazione più sostanza di un'affermazione secondo cui il sistema utilizza un'«IA responsabile». Collega la decisione di sicurezza a qualcosa che un'altra persona può esaminare. Per saperne di più su come organizzare il materiale a supporto, consultate come strutturare la preparazione all'audit.

Certificazione e requisiti ISO 27090

La ISO 27090 fornisce indicazioni di sicurezza anziché requisiti di certificazione per un sistema di gestione. La spiegazione dell'ISO distingue il suo scopo dai requisiti per l'AIMS della ISO 42001. Spiegazione ISO della ISO 27090

Definite innanzitutto il tipo di assurance di cui avete bisogno: una revisione di sicurezza, una risposta di assurance per un cliente, una gap analysis interna o una certificazione rispetto a uno standard di sistema di gestione applicabile.

Chiedete a chiunque offra una valutazione di indicarne ambito, criteri e schema di assurance. In questo modo il risultato è più facile da interpretare e si evita di confondere una revisione delle pratiche di sicurezza dell'IA con la certificazione di un sistema di gestione.

Per un progetto di implementazione, procuratevi lo standard pubblicato, confrontate le indicazioni con i vostri sistemi e registrate perché determinate misure di salvaguardia sono appropriate. Gli esempi di questo articolo offrono una struttura di partenza per questo lavoro.

ISO 27090 e l'AI Act dell'UE

Applicare uno standard internazionale non stabilisce automaticamente la conformità all'AI Act dell'UE. L'articolo 40 collega una presunzione di conformità alle norme armonizzate i cui riferimenti sono stati pubblicati nella Gazzetta ufficiale dell'UE, e solo nella misura in cui coprono i requisiti o gli obblighi pertinenti. Articolo 40 dell'AI Act dell'UE

Utilizzate una revisione di sicurezza secondo la ISO 27090 come uno degli input di una valutazione di conformità con un ambito definito separatamente. Registrate l'obbligo giuridico valutato, le evidenze che lo supportano ed eventuali lacune residue.

Domande frequenti sulla ISO 27090

Qual è la data di pubblicazione della ISO 27090?

La prima edizione, ISO/IEC 27090:2026, è stata pubblicata il 14 ottobre 2026. Verificate la scheda aggiornata dell'editore quando materiale meno recente fa riferimento a una bozza o a un anno precedente. Scheda di pubblicazione IEC

La ISO 27090 copre l'IA generativa e la sicurezza degli LLM?

I suoi contenuti pubblicati includono la prompt injection e gli output sensibili dei modelli, il che la rende pertinente per la sicurezza dell'IA generativa. Il suo ambito comprende anche altri sistemi di IA. Estratto pubblicato della ISO/IEC 27090 Spiegazione ISO della ISO 27090

Un'azienda che utilizza IA di terze parti può applicare lo standard?

Sì. Il pubblico dichiarato comprende le organizzazioni che utilizzano l'IA, oltre a quelle che la sviluppano. Partite dai rischi e dalle responsabilità che rientrano nel vostro controllo e individuate che cosa dovete sapere sui vostri fornitori. Scheda di pubblicazione IEC

La certificazione ISO 27001 significa che un sistema di IA è sicuro?

La certificazione di un sistema di gestione non garantisce che una singola applicazione resista a ogni attacco. Utilizzate il sistema di gestione per organizzare le decisioni sui rischi e valutate la progettazione, la configurazione e il comportamento effettivi del sistema di IA. La ISO 27090 può contribuire a orientare questo lavoro di sicurezza.

Dove posso ottenere il PDF della ISO 27090?

Utilizzate il catalogo ufficiale ISO o l'IEC Webstore per lo standard pubblicato e le opzioni di licenza. Verificate che la designazione sia ISO/IEC 27090:2026. Un articolo o un'anteprima forniscono solo una parte del materiale.

Rendere revisionabile il lavoro sulla sicurezza dell'IA

Iniziate da un caso d'uso dell'IA con conseguenze rilevanti. Individuate come potrebbe essere compromesso, scegliete misure di salvaguardia per i confini pertinenti e definite le evidenze che dimostreranno che tali misure funzionano. Assegnate a ogni azione un responsabile e un evento che ne attiva il riesame.

Secani collega requisiti, rischi, controlli, evidenze, responsabili e decisioni di riesame in uno spazio di lavoro condiviso per la sicurezza e la compliance. Parlate con Secani di come organizzare il vostro lavoro sulla sicurezza dell'IA, in modo che i team possano vedere che cosa è stato valutato, che cosa richiede attenzione e chi ne è responsabile.