In sintesi
- La sicurezza dell’IA consiste nel proteggere i dati, i modelli, le pipeline e le interfacce di un sistema di IA lungo tutto il ciclo di vita. È una disciplina distinta dall’uso dell’IA a supporto delle operazioni di sicurezza.
- Con il regolamento europeo sull’IA, la sicurezza dell’IA non è più facoltativa: l’articolo 15 impone ai sistemi ad alto rischio un livello adeguato di accuratezza, robustezza e cibersicurezza, compresa la resistenza agli attacchi avversari e all’avvelenamento dei dati.
- Le minacce sono proprie dell’apprendimento automatico: esempi avversari, avvelenamento di dati e modelli, furto di modello, prompt injection e gestione non sicura degli output, censiti nella OWASP Top 10 per le applicazioni LLM e in MITRE ATLAS.
- Non si protegge ciò che non si è inventariato: il registro dei sistemi di IA e la scoperta dello shadow AI sono il primo controllo, non un dettaglio successivo.
- Le organizzazioni che riescono trattano la sicurezza dell’IA come un insieme di controlli governato, collegato al regolamento europeo, alla ISO/IEC 42001 e al NIST AI RMF, sorretto da prove che un revisore accetterà invece che da un cruscotto.
Che cos’è la sicurezza dell’IA?
La sicurezza dell’IA è la pratica di proteggere un sistema di IA e tutto ciò da cui dipende: i dati di addestramento e di inferenza, il modello stesso, le pipeline che lo costruiscono e lo erogano e le interfacce che lo espongono agli utenti e ad altri sistemi. Copre l’intero ciclo di vita, dalla raccolta dei dati all’addestramento, alla messa in esercizio, al monitoraggio, fino al ritiro.
Una distinzione confonde spesso le prime conversazioni, conviene enunciarla con chiarezza. Usare l’IA per la sicurezza significa applicare l’apprendimento automatico ad attività difensive, per esempio il rilevamento di anomalie o il triage degli allarmi. La sicurezza dell’IA, oggetto di questa guida, significa proteggere il sistema di IA stesso da attacchi e guasti. La distinzione conta, perché le due cose richiedono responsabili, controlli e prove differenti.
Perché questa distinzione pesa sulla conformità? Perché le autorità trattano ormai la sicurezza del sistema di IA come un obbligo esplicito. Il regolamento europeo unisce accuratezza, robustezza e cibersicurezza in un solo articolo per i sistemi ad alto rischio (articolo 15 del regolamento IA). Nel momento in cui la sicurezza diventa un requisito di legge e non una preferenza ingegneristica, essa richiede governance: controlli definiti, responsabilità assegnata e registrazioni che dimostrino il funzionamento dei controlli.
Perché la sicurezza dell’IA è oggi un requisito di conformità
Per un decennio, mettere in sicurezza un modello è stata una buona idea confinata all’ingegneria. Le cose sono cambiate. Tre strumenti rendono oggi la sicurezza dell’IA un obbligo documentato.
Anzitutto il regolamento europeo sull’IA. L’articolo 15 impone ai fornitori di sistemi ad alto rischio di progettarli in modo da raggiungere un livello adeguato di accuratezza, robustezza e cibersicurezza, e di mantenere tali proprietà lungo l’intera vita del sistema. Il testo nomina l’avversario in modo diretto: i sistemi devono resistere ai tentativi di terzi non autorizzati di alterarne l’uso, gli output o le prestazioni, compresi gli attacchi avversari e l’avvelenamento dei dati.
In secondo luogo la ISO/IEC 42001. La norma del 2023 è il primo sistema di gestione dell’IA certificabile, e i suoi controlli dell’allegato A raccolgono la sicurezza dell’IA, la governance dei dati e la mitigazione degli attacchi avversari in un sistema che un organismo esterno può verificare (ISO/IEC 42001). La sicurezza trova così una collocazione in un ciclo governato anziché in un arretrato di attività.
Infine il quadro di gestione del rischio dell’IA del NIST. Il NIST organizza il lavoro in quattro funzioni, Governare, Mappare, Misurare e Gestire, e nella funzione Gestire risiedono i controlli di sicurezza (NIST AI RMF). Letto insieme alla corrispondenza tra i quadri presentata nella nostra guida ai riferimenti, trasforma la sicurezza in una routine ripetibile e documentata.
Il divario tra obbligo e capacità resta ampio. In una valutazione di Microsoft su 28 organizzazioni, 25 non disponevano degli strumenti adatti a mettere in sicurezza i propri sistemi di IA. È la conformità a colmare quel divario, perché impone inventario, selezione dei controlli e prova, invece di affidare la sicurezza a chi si ricorda di chiederla.
Il panorama delle minacce all’IA
Proteggere un sistema di IA comincia dal sapere contro che cosa ci si difende. Gli attacchi all’IA non ricalcano la sicurezza applicativa classica, perché il modello, i dati e il prompt sono tutte superfici d’attacco. Conviene raggruppare le minacce per bersaglio. La base di conoscenza MITRE ATLAS censisce queste tecniche in una matrice ispirata ad ATT&CK, e la nostra guida a MITRE ATLAS percorre la corrispondenza tra tecnica e controllo.
Attacchi al modello
Gli esempi avversari sono input costruiti per indurre il modello a classificare in modo errato pur apparendo normali all’occhio umano. Gli attacchi per evasione li impiegano in fase di inferenza per aggirare un classificatore. L’estrazione di modello, ovvero il furto di modello, interroga un modello in esercizio un numero di volte sufficiente a ricostruirne una copia funzionante, sottraendo proprietà intellettuale e creando un modello ombra che l’attaccante può sondare offline.
Attacchi ai dati
L’avvelenamento corrompe il set di addestramento affinché il modello apprenda la cosa sbagliata, da un lieve degrado dell’accuratezza fino a porte di servizio nascoste che si attivano su un input scelto. Gli attacchi per inferenza di appartenenza procedono in senso opposto: verificano se un determinato record fosse presente nei dati di addestramento, cosa che può esporre informazioni personali o riservate.
Attacchi allo strato applicativo
Per i sistemi costruiti su grandi modelli linguistici, lo strato applicativo è oggi il bersaglio più morbido. La OWASP Top 10 per le applicazioni LLM pone in testa la prompt injection, con cui un attaccante nasconde istruzioni in un prompt, in un documento o nell’output di uno strumento per aggirare le protezioni del modello, sottrarre dati o innescare azioni tramite gli strumenti collegati. La gestione non sicura degli output, quando la risposta del modello viene propagata senza convalida, trasforma un difetto linguistico in una compromissione del sistema.
Catena di fornitura e rischi agentici
Modelli, set di dati e librerie provengono da terzi, perciò un modello a pesi aperti avvelenato o una dipendenza compromessa costituiscono un rischio di catena di fornitura. I sistemi agentici, capaci di invocare strumenti e di agire sui propri output, ampliano il raggio d’impatto: una sola injection riuscita può propagarsi in azioni reali. La nostra guida agli agenti di IA autonomi tratta i controlli di governance di cui questi sistemi hanno bisogno.
Non si protegge ciò che non si vede: inventario dell’IA e shadow AI
Ogni controllo che segue presuppone che sappiate quali sistemi di IA gestite. La maggior parte delle organizzazioni non lo sa. I team adottano copiloti, integrano modelli di terzi e collegano agenti più in fretta di quanto qualsiasi funzione centrale riesca a seguire, generando shadow AI: IA in uso che la governance non ha mai visto.
Lo shadow AI è un problema di sicurezza prima ancora che di conformità. Un modello non registrato non ha responsabile, né valutazione delle minacce, né monitoraggio, né percorso di gestione degli incidenti. Il primo controllo di un programma di sicurezza dell’IA non è quindi un firewall, ma un inventario. Un registro vivo dei sistemi di IA, dei loro dati, dei loro modelli e del loro livello di rischio è ciò che rende possibile ogni controllo successivo. La nostra guida allo shadow AI spiega come l’IA nascosta diventi una lacuna di governance e perché la scoperta sia il controllo zero.
Collegare la sicurezza dell’IA ai quadri: regolamento IA, ISO 42001, NIST AI RMF
La mossa che nessuna pagina concorrente compie consiste nel collegare ciascuna minaccia al controllo che le risponde e alla clausola che lo impone. È questo che trasforma la sicurezza dell’IA, da lista della spesa di strumenti, in una posizione di conformità difendibile.
| Obbligo | Che cosa richiede | Controllo che lo soddisfa |
|---|---|---|
| Articolo 15 (robustezza) | Resistenza a errori, guasti e manipolazione avversaria | Test avversari e red teaming, test fuori distribuzione |
| Articolo 15 (cibersicurezza) | Resistenza all’alterazione non autorizzata di uso, output o prestazioni | Controllo degli accessi, integrità di modello e dati, erogazione sicura |
| ISO/IEC 42001 allegato A | Controlli di sicurezza dell’IA gestiti in un sistema certificato | Insieme di controlli documentato, responsabile nominato, ciclo di riesame |
| NIST AI RMF (Gestire) | Trattamento prioritizzato dei rischi di IA individuati | Registro dei rischi, corrispondenza dei controlli, monitoraggio |
Costruite la corrispondenza una volta e ogni verifica diventa una consultazione invece che una corsa. La spiegazione della ISO 42001 e la guida al NIST AI RMF approfondiscono ciascun versante, e la guida operativa al regolamento IA colloca l’articolo 15 tra gli obblighi più ampi per i sistemi ad alto rischio.
Dalle minacce ai controlli verificabili
Una minaccia che non si può provare è una minaccia che non si può difendere in sede di verifica. Ogni classe di minaccia dovrebbe quindi risolversi in un controllo nominato, dotato di un responsabile e di una registrazione.
- Attacchi avversari e per evasione: test avversari e red teaming pianificati, con risultati registrati e rieseguiti a ogni evoluzione del modello.
- Avvelenamento dei dati: tracciabilità e provenienza dei dati, controlli di integrità sulla pipeline di addestramento.
- Furto di modello: limitazione della frequenza, monitoraggio delle interrogazioni e controllo degli accessi sugli endpoint di inferenza.
- Prompt injection e output non sicuri: convalida di input e output, elenchi di autorizzazione degli strumenti, isolamento tra il modello e le azioni a valle.
- Deriva e obsolescenza: monitoraggio continuo di prestazioni e comportamento, con soglie che generano un allarme.
Il senso di formulare i controlli in questo modo non è l’elenco, ma la prova. Un cruscotto mostra uno stato nell’istante presente; un revisore ha bisogno di una registrazione nel tempo. Ogni controllo dovrebbe produrre un artefatto datato: un rapporto di test, un registro di monitoraggio, una revisione degli accessi. La nostra guida alla verificabilità illustra che cosa rende verificabile un sistema di IA e come dimostrarlo, e il monitoraggio continuo della conformità è il modo in cui questi artefatti si accumulano senza corse manuali prima di ogni riesame.
Chi è responsabile della sicurezza dell’IA? Ruoli e governance
La sicurezza dell’IA fallisce quando ciascuno presume che se ne occupi qualcun altro. La cibersicurezza classica fa capo al CISO, ma la sicurezza dell’IA attraversa data science, MLOps e conformità, perciò la responsabilità deve essere esplicita.
Una ripartizione praticabile assegna la responsabilità a un referente o a un comitato di governance dell’IA, con il CISO responsabile dei controlli di sicurezza, la data science responsabile dei test sui modelli e la conformità responsabile delle prove e della corrispondenza ai quadri. Una breve matrice delle responsabilità, concordata una volta, previene il difetto comune per cui un modello viene rilasciato senza un responsabile della sua sicurezza. Questo strato di governance è oggetto della nostra guida al sistema operativo della governance dell’IA, che mostra come questi ruoli si colleghino all’ambiente di controllo più ampio.
Come rendere operativo un programma di sicurezza dell’IA
Tradurre queste idee in un programma in esecuzione è una sequenza, non un progetto con una data di fine.
- Inventariare ogni sistema di IA, shadow AI compreso, e assegnare a ciascuno un livello di rischio.
- Condurre una valutazione di minacce e rischi per ciascun sistema, usando la OWASP LLM Top 10 e MITRE ATLAS come liste di controllo.
- Selezionare i controlli dalla corrispondenza ai quadri e assegnare a ciascuno un responsabile.
- Testare i controlli: test avversari, red teaming e convalida, dimensionati al livello di rischio.
- Raccogliere le prove come artefatti datati per ciascun controllo.
- Monitorare in continuo deriva, abusi e nuove vulnerabilità.
- Integrare la gestione degli incidenti, compresa la segnalazione regolamentare ove richiesta. Il regolamento europeo fissa obblighi di segnalazione degli incidenti gravi, trattati nella nostra guida alla segnalazione ai sensi dell’articolo 73.
Eseguite la sequenza come un ciclo. Ogni nuovo modello rientra al passo uno, e ogni modifica sostanziale rilancia test e prova.
Domande frequenti
Che cos’è la sicurezza dell’IA, in parole semplici?
La sicurezza dell’IA è proteggere un sistema di IA, i suoi dati, il suo modello, le sue pipeline e le sue interfacce da attacchi e guasti lungo tutto il ciclo di vita. Si distingue dall’uso dell’IA per attività di sicurezza come il rilevamento delle minacce. In un contesto di conformità comprende anche obblighi espliciti, come il requisito dell’articolo 15 del regolamento europeo secondo cui i sistemi ad alto rischio devono mantenere accuratezza, robustezza e cibersicurezza.
Qual è la differenza tra sicurezza dell’IA e cibersicurezza?
La cibersicurezza classica protegge reti, applicazioni ed endpoint. La sicurezza dell’IA aggiunge superfici d’attacco che i controlli classici non coprono: i dati di addestramento, il comportamento appreso dal modello e il prompt. Un firewall non ferma né l’avvelenamento dei dati né la prompt injection. La sicurezza dell’IA estende quindi la cibersicurezza con controlli consapevoli del modello, come test avversari, tracciabilità dei dati e convalida degli output, e li collega ai quadri propri dell’IA.
Quali sono le principali minacce all’IA?
Le classi ricorrenti sono gli esempi avversari e gli attacchi per evasione sui modelli, l’avvelenamento di dati e modelli, il furto o l’estrazione di modello, l’inferenza di appartenenza, la prompt injection e la gestione non sicura degli output sullo strato applicativo, e i rischi di catena di fornitura legati a modelli e librerie di terzi. La OWASP Top 10 per le applicazioni LLM e MITRE ATLAS sono i due cataloghi di riferimento che la maggior parte dei team usa per verificare che non manchi alcuna categoria.
Il regolamento europeo sull’IA impone la sicurezza dell’IA?
Sì. L’articolo 15 impone ai fornitori di sistemi ad alto rischio di raggiungere e mantenere un livello adeguato di accuratezza, robustezza e cibersicurezza, stabile per tutta la vita del sistema. Nomina espressamente la resistenza agli attacchi avversari e all’avvelenamento dei dati. La sicurezza è quindi un obbligo documentato per i sistemi ad alto rischio, non una pratica ingegneristica facoltativa.
Come si collegano ISO 42001 e NIST AI RMF alla sicurezza dell’IA?
La ISO/IEC 42001 è un sistema di gestione dell’IA certificabile i cui controlli dell’allegato A includono la sicurezza dell’IA, dandole una sede governata e verificabile. Il NIST AI RMF organizza il lavoro in Governare, Mappare, Misurare e Gestire, con i trattamenti di sicurezza collocati nella funzione Gestire. Insieme, consentono di collegare ogni controllo di sicurezza a una clausola riconosciuta, il che rende la verifica una consultazione invece che una corsa.
Da dove far partire un programma di sicurezza dell’IA?
Dall’inventario. Non si può mettere in sicurezza, testare o attestare un sistema di IA che non si è registrato, e la maggior parte delle organizzazioni gestisce shadow AI che la governance non ha mai visto. Costruite un registro vivo dei sistemi di IA con i loro dati, modelli e livelli di rischio, quindi conducete le valutazioni delle minacce, selezionate controlli collegati ai quadri, testateli e raccogliete prove datate. L’inventario è il controllo zero; tutto il resto ne dipende.
Conclusione
La sicurezza dell’IA è passata da raffinatezza ingegneristica a obbligo di conformità esplicito, e le pagine che si posizionano sul termine non hanno tenuto il passo: descrivono minacce e vendono strumenti, senza collegare la sicurezza ai quadri che ora la impongono. Le organizzazioni che procedono bene trattano la sicurezza dell’IA come un insieme di controlli governato, collegato al regolamento europeo, alla ISO 42001 e al NIST AI RMF, partendo da un inventario onesto per arrivare a prove che un revisore accetterà. AI Sigil è costruito per eseguire esattamente questo ciclo, dalla scoperta dell’IA alla corrispondenza dei controlli fino alle prove pronte per la verifica. Scoprite come il sistema operativo della governance dell’IA rende la sicurezza dell’IA una capacità difendibile e continua.