In sintesi
- L’IA avversaria è la manipolazione deliberata di un modello di machine learning, tramite i suoi input, i suoi dati di addestramento o i suoi parametri, per farlo sbagliare, indurlo a divulgare dati o imporgli un output scelto dall’attaccante.
- Le principali famiglie di attacco sono l’evasione, il poisoning dei dati e gli attacchi alla riservatezza (estrazione), a cui si aggiungono prompt injection e jailbreak contro i modelli generativi.
- La robustezza non è più facoltativa: l’articolo 15 del regolamento europeo sull’IA impone accuratezza, robustezza e cybersicurezza ai sistemi ad alto rischio dal 2 agosto 2026.
- Una difesa efficace unisce controlli tecnici (addestramento avversario, filtraggio degli input, red teaming) e controlli di governance (un responsabile designato, evidenze documentate, un riesame periodico).
- Tratta l’IA avversaria come un rischio governato all’interno del tuo sistema di gestione dell’IA, non come un acquisto di sicurezza una tantum.
Cos’è l’IA avversaria?
L’IA avversaria raccoglie gli attacchi che colpiscono i sistemi di machine learning sfruttando il loro modo di apprendere e di decidere. L’attaccante non forza un server: presenta al modello dati dall’aspetto ordinario che lo orientano verso un risultato errato o pericoloso. La ricerca parla anche di apprendimento avversario (adversarial machine learning), e le due espressioni indicano lo stesso campo. L’esempio avversario ne è l’illustrazione più chiara. Pochi adesivi su un segnale di stop, o una manciata di pixel modificati in un’immagine, bastano perché un modello di visione molto accurato legga il segnale come un limite di velocità. La modifica sfugge spesso all’occhio umano, ma ribalta l’output del modello. È proprio questo scarto tra percezione umana e percezione della macchina che ogni attacco avversario sfrutta. Ciò che distingue questi attacchi dall’hacking classico è il bersaglio. La cybersicurezza tradizionale protegge codice, reti e credenziali. L’IA avversaria colpisce la logica statistica del modello: i dati da cui ha imparato, i confini che traccia tra le classi, la fiducia che ripone nelle proprie risposte. Per un’organizzazione che usa l’IA in selezione del personale, credito, triage medico o rilevamento delle frodi, quella logica concentra insieme il valore e il rischio. Il campo ha ora un riferimento ufficiale. La pubblicazione NIST AI 100-2e2025, del marzo 2025, è la tassonomia di riferimento degli attacchi e delle mitigazioni nell’apprendimento avversario. Se stai costruendo un programma di gestione del rischio IA, è il documento su cui allineare i controlli.
Come funzionano gli attacchi di IA avversaria
La maggior parte degli attacchi segue una traiettoria riconoscibile. Prima l’attaccante studia il sistema bersaglio per capire cosa fa e come reagisce. Poi confeziona un input, un campione di addestramento avvelenato o un prompt manipolato, progettato per innescare il guasto voluto. Infine consegna il carico e osserva il risultato, prima di affinare l’attacco o cancellare le tracce. La tassonomia del NIST classifica gli attacchi lungo alcune dimensioni pratiche, ognuna delle quali cambia la difesa. La prima è l’obiettivo: compromettere l’integrità del modello (forzare una risposta sbagliata), la sua disponibilità (degradare le prestazioni) o la sua riservatezza (estrarre dati o il modello stesso). La seconda è l’accesso: l’attaccante può solo inviare input, oppure raggiungere anche la pipeline di addestramento. La terza è la conoscenza. In un attacco white-box l’avversario conosce architettura e pesi, il che facilita la costruzione di input avversari. In un attacco black-box non sa quasi nulla e deve sondare il modello dall’esterno. L’ultima dimensione è il momento nel ciclo di vita. Gli attacchi in addestramento corrompono i dati o il processo mentre il modello viene costruito. Gli attacchi in produzione manipolano gli input una volta che il modello è in esercizio. Governare il rischio avversario significa coprire entrambe le estremità del ciclo, il che rende l’inventario dei sistemi di IA e delle loro fonti di dati un prerequisito, non un extra.
I principali tipi di attacco avversario
Quattro famiglie coprono la gran parte dei casi odierni. L’evasione avviene in fase di inferenza. L’attaccante perturba un input legittimo perché il modello in produzione lo classifichi male, mentre resta normale per una persona. Uno spam che supera il filtro, un malware regolato per sembrare innocuo o il segnale di stop manomesso sono attacchi di evasione. Il poisoning avviene in addestramento. L’attaccante inietta dati corrotti o mal etichettati nel set di addestramento, o altera il modello durante il fine-tuning, così che il modello finito porti un difetto nascosto. Una backdoor che si comporta normalmente fino a incontrare un innesco preciso è un attacco di poisoning. Gli attacchi alla riservatezza e all’estrazione puntano al segreto. La membership inference rivela se un record specifico era nei dati di addestramento. L’estrazione di modello ne ruba una copia funzionante a forza di query. L’inversione ricostruisce input sensibili a partire dagli output. L’IA generativa aggiunge una categoria propria. Il NIST AI 100-2e2025 estende la tassonomia a prompt injection (diretta e indiretta), jailbreak e compromissione della catena di fornitura dei modelli di base. L’injection indiretta è particolarmente difficile da governare, perché l’istruzione malevola si nasconde in contenuti che il modello recupera, non in ciò che l’utente ha digitato. Per un catalogo completo, MITRE ATLAS documenta quattordici categorie di tattiche e oltre ottanta tecniche contro i sistemi di IA.
Esempi concreti di IA avversaria
L’IA avversaria non è una curiosità da laboratorio. I ricercatori hanno mostrato più volte che piccole alterazioni fisiche sui segnali stradali possono ingannare i modelli di percezione dei sistemi di assistenza alla guida, trasformando uno stop in un segnale ignorato. Le conseguenze di un’evasione in quel contesto sono evidenti. Il poisoning ha una storia altrettanto lunga. Chatbot pubblici che imparano dalle interazioni sono stati spinti verso comportamenti offensivi nel giro di ore da input malevoli coordinati, prova che un ciclo di feedback aperto è una superficie d’attacco. L’IA generativa ha ampliato il bersaglio. Ricercatori di sicurezza hanno divulgato EchoLeak, una prompt injection indiretta contro Microsoft 365 Copilot capace di esfiltrare dati senza azioni insolite dell’utente, mostrando che gli assistenti basati sul recupero ereditano la fiducia riposta nel contenuto che leggono. Ed è ormai questione di scala: il CrowdStrike 2026 Global Threat Report rileva che nel 2025 gli attaccanti hanno abusato di strumenti di IA generativa legittimi in oltre novanta organizzazioni. Queste tecniche vanno sullo stesso registro dei rischi di qualsiasi altra minaccia rilevante.
Perché l’IA avversaria è un problema di governance, non solo di sicurezza
La maggior parte degli articoli si ferma alle difese tecniche. È un errore, perché la robustezza avversaria è passata dalla buona pratica all’obbligo di legge. L’articolo 15 del regolamento europeo sull’IA impone ai sistemi ad alto rischio un livello adeguato di accuratezza, robustezza e cybersicurezza, mantenuto per tutto il ciclo di vita. Il considerando 76 nomina esplicitamente il data poisoning, gli esempi avversari, l’evasione del modello e gli attacchi alla riservatezza come rischi che il fornitore deve affrontare. Questi obblighi si applicano dal 2 agosto 2026. La domanda si sposta, quindi. Non conta più solo se un modello può essere ingannato, ma se puoi dimostrare, a un revisore o a un’autorità, di aver individuato il rischio, applicato controlli proporzionati e provato la loro efficacia. L’articolo 15 chiede inoltre ai fornitori di dichiarare le metriche di accuratezza e robustezza nella documentazione tecnica: la prova deve esistere su carta. In Italia, il Garante per la protezione dei dati personali e l’AgID pubblicano indicazioni che vanno nella stessa direzione sulla sicurezza e sulla protezione dei dati dei sistemi di IA. Altri quadri indicano la stessa strada. Il NIST AI Risk Management Framework chiede di misurare e gestire i rischi in modo continuo, e la norma ISO/IEC 42001 definisce un sistema di gestione dell’IA con controlli e un inventario degli asset. Il filo conduttore è la responsabilità: un titolare nominato, un controllo documentato, un riesame ripetibile. Il divario è reale: nel 2025 circa l’83 per cento delle organizzazioni prevedeva di adottare l’IA agentica, ma solo il 29 per cento si riteneva pronto a farlo in sicurezza.
Come difendersi dall’IA avversaria
Una difesa efficace unisce due livelli che molti team trattano separatamente. Il livello tecnico riduce la superficie d’attacco del modello. L’addestramento avversario espone il modello a esempi avversari durante lo sviluppo perché impari a resistervi. Il preprocessing e la sanificazione degli input rimuovono le perturbazioni probabili prima che raggiungano il modello. I test di robustezza e il red teaming, compresi i test avversari documentati per i sistemi generativi, sondano il modello come farebbe un attaccante. Il monitoraggio delle anomalie osserva input e punteggi di confidenza in tempo reale, e un controllo degli accessi rigoroso limita chi può interrogare o mettere a punto il modello. Il livello di governance decide se questi controlli sono davvero applicati, provati e mantenuti. La mappatura dei controlli di AI Sigil formula ogni rischio come prevenzione, rilevamento e risposta. Per gli input avversari significa prevenzione con addestramento avversario e red teaming, rilevamento con monitor di anomalie e di confidenza, risposta con allarmi, contenimento e patch del modello. Collegando queste azioni alle mitigazioni del NIST AI 100-2e2025 e alle tecniche di MITRE ATLAS, una lista di minacce diventa un insieme di controlli verificabili ospitato nella tua piattaforma di governance. Nessuno strumento singolo risolve il problema: la robustezza si governa e si riesamina come ogni altro controllo.
Integrare l’IA avversaria nel programma di governance
In pratica, si tratta di dare all’IA avversaria un posto nel modello operativo invece di una menzione in una slide. Inizia iscrivendo il rischio avversario nel registro dei rischi IA e valutandolo secondo la criticità di ciascun sistema: un modello antifrode o di triage merita più attenzione di un chatbot interno. Nomina un unico responsabile e collegaci i controlli di prevenzione, rilevamento e risposta, con i test che ogni sistema deve superare. Raccogli le evidenze mano a mano: risultati dei test avversari, metriche di robustezza, log di monitoraggio e incidenti, esattamente la documentazione che l’articolo 15 si aspetta. Fissa infine una cadenza di riesame, perché un modello robusto al lancio va alla deriva, e nuove tecniche compaiono di continuo. È qui che un sistema di gestione dell’IA mostra il suo valore. Farlo in fogli di calcolo sparsi su decine di modelli non scala e lascia lacune che un revisore troverà. Una piattaforma che tiene inventario, rischi, controlli ed evidenze in un’unica struttura collegata è ciò che permette di dimostrare, su richiesta, che l’IA avversaria è governata e non solo notata.
Domande frequenti
Cos’è l’IA avversaria? L’IA avversaria è la manipolazione deliberata di un modello di machine learning per farlo fallire o piegarlo a vantaggio di un attaccante. Questi confeziona input, avvelena dati o sfrutta prompt perché il modello classifichi male, divulghi informazioni o produca output dannosi, di solito senza segni visibili per un osservatore umano. Cos’è un esempio avversario? Un esempio avversario è un input modificato quel tanto che basta per ingannare un modello pur restando normale agli occhi umani. Una foto con pixel leggermente alterati, o un segnale di stop con piccoli adesivi, può portare un modello molto accurato a una risposta sbagliata. È la forma classica di un attacco di evasione. In cosa un attacco di poisoning differisce da un’evasione? La differenza è nel momento. Il poisoning corrompe i dati o il modello durante la costruzione, piantando un difetto che viene consegnato con il modello finito. L’evasione lascia il modello intatto e manipola invece un input in produzione per innescare una classificazione errata. Si possono prevenire del tutto gli attacchi avversari? No. Nessun controllo singolo elimina il rischio avversario, perché difese e attacchi evolvono insieme. L’obiettivo realistico è aumentarne il costo e ridurne l’impatto con controlli a più livelli, addestramento avversario, monitoraggio, red teaming e un processo di governance che rileva, tratta e impara dagli incidenti. L’IA avversaria rientra nel regolamento europeo sull’IA? Sì. L’articolo 15 impone ai sistemi ad alto rischio di essere accurati, robusti e cybersicuri per tutto il ciclo di vita, e il considerando 76 nomina esplicitamente data poisoning, esempi avversari ed evasione del modello. Questi obblighi si applicano dal 2 agosto 2026. Che differenza c’è tra IA avversaria e apprendimento avversario? Nell’uso comune nessuna. L’apprendimento avversario è il termine tecnico del campo di ricerca, l’IA avversaria l’etichetta più ampia usata nei contesti aziendali e di sicurezza. Entrambi indicano attacchi che sfruttano il modo in cui i modelli apprendono e prevedono.
Conclusione
L’IA avversaria è il punto in cui la cybersicurezza incontra la governance dell’IA. Le famiglie di attacco, evasione, poisoning, estrazione e prompt injection, sono ben documentate, e le difese tecniche sono note. Ciò che separa le organizzazioni esposte da quelle resilienti è il governo del rischio: un responsabile, dei controlli, evidenze opponibili a un revisore. Con l’articolo 15 del regolamento europeo applicabile da agosto 2026, è diventato un requisito di conformità oltre che di sicurezza. Tratta l’IA avversaria come un rischio gestito nella tua piattaforma di governance dell’IA, e trasformerai una minaccia mobile in un rischio controllato.