MITRE ATLAS: dalle tecniche di attacco all’IA ai controlli di conformità

In sintesi

• MITRE ATLAS è una base di conoscenza aperta e in continuo aggiornamento su come i sistemi di IA vengono realmente attaccati: 16 tattiche e 84 tecniche tratte da incidenti reali e da attività di red team.
• Il framework estende la logica di MITRE ATT&CK alla superficie di attacco propria del machine learning, coprendo minacce come avvelenamento dei dati, evasione del modello e prompt injection che gli standard di sicurezza tradizionali non avevano mai nominato.
• ATLAS, la OWASP LLM Top 10 e il NIST AI RMF sono livelli complementari (minacce, vulnerabilità applicative, governance) e non standard concorrenti.
• Le classi di attacco catalogate da ATLAS sono esattamente quelle che il regolamento europeo sull’IA impone di contrastare per i sistemi ad alto rischio, il che rende ATLAS una fonte di prove di conformità.
• Il vantaggio concreto sta in una catena: collegare ogni tecnica ATLAS a un controllo e a una prova di audit all’interno del proprio programma di governance dell’IA.

Che cos’è MITRE ATLAS?

MITRE ATLAS è l’acronimo di Adversarial Threat Landscape for Artificial-Intelligence Systems. MITRE lo descrive come una base di conoscenza globale e viva delle tattiche e delle tecniche avversarie contro i sistemi basati sull’IA, costruita a partire da osservazioni di attacchi reali e da dimostrazioni condotte da team di red teaming specializzati. In parole semplici, è una mappa strutturata di come si attacca l’IA, alimentata da incidenti realmente accaduti anziché da timori teorici. Nella versione 5.4.0 (febbraio 2026), la matrice ATLAS conta 16 tattiche, 84 tecniche, 56 sotto-tecniche, 32 misure di mitigazione e 42 casi di studio documentati. Si tratta di casi concreti, non accademici: l’aggiramento della verifica di identità tramite deepfake, l’evasione di un modello di machine learning, agenti di IA dotati di backdoor o il dirottamento di transazioni finanziarie tramite assistenti di IA. Il framework esiste perché l’IA aggiunge una superficie di attacco che i modelli di sicurezza tradizionali non sono mai stati pensati per descrivere. Un modello può essere corrotto durante l’addestramento, ingannato in fase di inferenza oppure interrogato finché non rivela i dati da cui ha appreso. ATLAS offre ai team di sicurezza e di governance un vocabolario comune per questi modi di guasto, così che una scoperta di red team, un responsabile di controllo e un revisore possano indicare la stessa tecnica e intendere la stessa cosa. Per un’organizzazione regolamentata, questo linguaggio condiviso è il primo passo verso una sicurezza dell’IA trattata come disciplina di governance e non come progetto occasionale. È anche la ragione per cui AI Sigil colloca ATLAS come livello di riferimento sotto il proprio modello di rischi e controlli.

MITRE ATLAS a confronto con MITRE ATT&CK

Chi ha lavorato in un centro operativo di sicurezza ritroverà in ATLAS i propri punti di riferimento, e non per caso. Il framework si ispira direttamente alla metodologia MITRE ATT&CK: la stessa distinzione tra tattiche (l’obiettivo dell’attaccante in ciascuna fase) e tecniche (il modo in cui lo raggiunge), presentata come una matrice che si legge da sinistra a destra lungo il ciclo di vita dell’attacco. La differenza riguarda il bersaglio. ATT&CK descrive gli attacchi all’informatica tradizionale: endpoint, reti, identità. ATLAS descrive gli attacchi all’IA stessa: il modello, i suoi dati di addestramento, la sua pipeline di inferenza e gli agenti costruiti al di sopra. Diverse tattiche sono comuni a entrambi (ricognizione, accesso iniziale, esfiltrazione, impatto), perché un attaccante continua a condurre phishing, a muoversi lateralmente, a rubare credenziali. Ciò che ATLAS aggiunge è il nucleo proprio dell’IA: ottenere l’accesso a un modello, avvelenarne i dati, costruire input che lo ingannano oppure estrarlo per intero. Per un team di governance la conclusione non è scegliere tra i due. ATT&CK copre l’infrastruttura attorno al modello, ATLAS copre il modello. Un attacco serio all’IA percorre di norma entrambe le strade.

Dentro la matrice MITRE ATLAS: le 16 tattiche

La matrice si legge al meglio come un ciclo di vita. L’avversario parte dalla ricognizione (studia il vostro modello, la sua API, la sua documentazione pubblica), attraversa lo sviluppo di risorse e l’accesso iniziale, quindi raggiunge le fasi proprie dell’IA: accesso al modello, preparazione dell’attacco, esecuzione, persistenza, esfiltrazione e impatto. Ogni tattica raccoglie tecniche che descrivono una mossa precisa. Quattro famiglie di tecniche contano in modo particolare per la governance, poiché si sovrappongono a rischi espressamente nominati dalla normativa:

• Avvelenamento dei dati. Manipolare i dati di addestramento affinché il modello apprenda la cosa sbagliata, sia essa una backdoor nascosta o un generale degrado dell’accuratezza.
• Evasione del modello (esempi avversari). Costruire input pensati per indurre in errore un modello in produzione, ad esempio un’immagine alterata in modo impercettibile o un prompt di aggiramento che sconfigge un filtro di sicurezza.
• Estrazione e inversione del modello. Interrogare un modello finché non lo si può ricostruire o recuperare i dati riservati su cui è stato addestrato: un attacco alla riservatezza.
• Prompt injection e jailbreak. Dirottare un modello linguistico o un agente di IA tramite istruzioni ostili nascoste nel contenuto che esso elabora.

Queste famiglie si allineano con precisione alla tassonomia ufficiale statunitense. Il NIST AI 100-2 E2025, tassonomia federale del machine learning avversario, classifica gli attacchi all’IA predittiva in evasione, avvelenamento e violazioni della riservatezza, e gli attacchi all’IA generativa in prompt injection, jailbreak e compromissione della catena di fornitura. ATLAS fornisce le tecniche collaudate sul campo, il NIST fornisce la terminologia formale. Usarli insieme restituisce sia il cosa sia il come.

ATLAS, la OWASP LLM Top 10 e il NIST AI RMF

Una delle domande più frequenti riguarda il rapporto tra ATLAS e gli altri framework di sicurezza e governance dell’IA. La risposta breve è che operano ad altitudini diverse e sono stati concepiti per essere usati insieme.

• MITRE ATLAS è un modello dell’avversario. Risponde alla domanda «come verrebbe attaccato questo sistema?» ed è pensato per la modellazione delle minacce, il red teaming e l’ingegneria del rilevamento.
• La OWASP LLM Top 10 è un modello di vulnerabilità. Risponde a «che cosa tende a non funzionare nelle applicazioni LLM?» (prompt injection, gestione non sicura degli output, avvelenamento dei dati di addestramento) ed è pensata per lo sviluppo sicuro e la revisione del codice.
• Il NIST AI RMF è un modello di governance. Le sue quattro funzioni (Governare, Mappare, Misurare, Gestire) rispondono a «come la nostra organizzazione sorveglia il rischio dell’IA?» e si rivolgono ai responsabili del rischio e della conformità.

Questi sono livelli, non alternative: la minaccia (ATLAS), la debolezza che essa sfrutta (OWASP) e la supervisione che decide come agire (NIST). La ragione pratica è di costo. Secondo l’analisi della matrice pubblicata da Vectra, circa il 70% delle misure di mitigazione di ATLAS corrisponde a controlli di sicurezza già in uso nelle organizzazioni. Raramente si parte da zero: si collega una minaccia dell’IA a un controllo che già si possiede e se ne dimostra il legame. Le risorse di governance di AI Sigil trattano i tre framework come un’unica pila coerente anziché come elenchi rivali.

Perché MITRE ATLAS conta per la conformità, non solo per la sicurezza

Ecco il punto che la maggior parte delle presentazioni di ATLAS tralascia. Di solito lo si presenta come uno strumento per il centro operativo di sicurezza. Per un’organizzazione regolamentata è anche uno strumento di conformità, perché gli attacchi che esso cataloga sono gli attacchi che la legge ora nomina. L’articolo 15 del regolamento europeo sull’IA richiede che i sistemi di IA ad alto rischio conseguano «un adeguato livello di accuratezza, robustezza e cibersicurezza». Al paragrafo 5 si spinge oltre: tali sistemi «sono resilienti per quanto riguarda i tentativi di terzi non autorizzati di modificarne l’uso, gli output o le prestazioni sfruttando le vulnerabilità del sistema». Lo stesso paragrafo nomina poi le minacce per categoria. Le soluzioni tecniche devono, ove opportuno, affrontare gli «attacchi che tentano di manipolare il set di dati di addestramento (data poisoning), o i componenti preaddestrati utilizzati nell’addestramento (model poisoning), gli input progettati per indurre il modello di IA a commettere errori (adversarial examples o model evasion), gli attacchi alla riservatezza o i difetti del modello». Rileggete questo elenco accanto alle famiglie di tecniche ATLAS viste sopra: sono le stesse minacce. Il regolamento enuncia l’obbligo, ATLAS fornisce il catalogo operativo che permette di dimostrare come vi si adempie. Quando un valutatore chiede come trattate gli esempi avversari o l’avvelenamento dei dati, «abbiamo collegato le tecniche ATLAS pertinenti a controlli e le abbiamo testate» pesa assai più di una dichiarazione di principio. La stessa logica vale a monte: il codice di condotta per i modelli di IA per finalità generali attende test avversari per i modelli con rischio sistemico, e ATLAS è una fonte naturale di casi di prova. In Italia tale aspettativa prolunga indirizzi già sostenuti dal Garante per la protezione dei dati personali e dall’AgID in materia di robustezza e sicurezza dei sistemi. È proprio questo cambio di prospettiva a fare la differenza. ATLAS non è soltanto un modo per rilevare gli attacchi: è un modo per dimostrare di averli anticipati.

Rendere operativo ATLAS in un programma di governance dell’IA

Portare ATLAS dal poster di riferimento a ingranaggio operativo della governance si riduce a una catena: minaccia, controllo, prova. Minaccia. Per ogni sistema di IA nel vostro inventario, selezionate le tecniche ATLAS realmente applicabili. Un assistente LLM esposto al pubblico affronta prompt injection e jailbreak; un modello antifrode addestrato su dati di terzi affronta l’avvelenamento; un modello esposto tramite API affronta l’estrazione. Non servono tutte le 84 tecniche, ma solo quelle che la vostra architettura richiama. Controllo. Collegate ogni tecnica selezionata a un controllo di sistema. Poiché la maggior parte delle mitigazioni di ATLAS corrisponde a controlli di sicurezza esistenti, si tratta per lo più di ricondurre una minaccia dell’IA alla gestione degli accessi, alla convalida degli input, al monitoraggio, alle verifiche della catena di fornitura o ai test di red team che già potete esibire. Dove permane un divario reale, avete appena individuato un controllo da costruire. Prova. Allegate la dimostrazione che il controllo funziona: un rapporto di red team contro la tecnica, l’esito di un test di rilevamento dell’avvelenamento, un registro degli accessi, un’approvazione firmata. È ciò che trasforma un controllo dichiarato in un artefatto di audit. Questa catena è esattamente ciò che richiedono le funzioni Misurare e Gestire del NIST AI RMF, e si accorda con i controlli dell’allegato A della norma ISO 42001, lo standard certificabile di sistema di gestione dell’IA. Essa chiarisce inoltre le responsabilità: ai sensi del regolamento sull’IA il fornitore risponde della robustezza integrata nel modello, mentre il deployer risponde delle condizioni d’uso; una stessa tecnica ATLAS può dunque generare obblighi per entrambe le parti. Una piattaforma come AI Sigil serve proprio a custodire questa mappatura (minacce, controlli, prove e obblighi) in un unico luogo, affinché la catena resti verificabile invece di essere ricostruita a memoria al momento della valutazione.

Come iniziare con MITRE ATLAS

Non serve un programma imponente per cominciare. Un primo passaggio si presenta così:

1. Inventariate i vostri sistemi di IA e annotate, per ciascuno, il tipo di modello, le fonti dei dati e la modalità di esposizione.
2. Per ogni sistema, preselezionate le tecniche ATLAS plausibili data quell’architettura.
3. Valutate l’attuale copertura dei controlli rispetto a tale preselezione e registrate dove siete solidi e dove esposti.
4. Date priorità ai divari per impatto, partendo dai sistemi ad alto rischio ai sensi del regolamento sull’IA o critici per il business.
5. Documentate le prove dei controlli già efficaci, per non perdere nulla prima del prossimo audit.
6. Riesaminate ogni trimestre, perché ATLAS è un framework vivo e il vostro parco di modelli cambia.

Per i team regolamentati, aggiungete una colonna all’esercizio: l’obbligo che ciascuna tecnica contribuisce a soddisfare. Questo singolo collegamento, dalla tecnica ATLAS al dovere normativo, è ciò che trasforma un elenco di sicurezza in governance.

Domande frequenti

Che cos’è MITRE ATLAS? MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) è una base di conoscenza aperta e viva delle tattiche e delle tecniche usate dagli attaccanti contro i sistemi di IA, fondata su osservazioni reali e dimostrazioni di red team. La matrice attuale conta 16 tattiche e 84 tecniche, organizzate come MITRE ATT&CK ma incentrate sul machine learning. Qual è la differenza tra MITRE ATLAS e MITRE ATT&CK? ATT&CK descrive gli attacchi ai sistemi informatici tradizionali (endpoint, reti, identità). ATLAS descrive gli attacchi ai sistemi di IA stessi: il modello, i suoi dati di addestramento e la sua pipeline di inferenza. ATLAS riutilizza la struttura di ATT&CK e condivide alcune tattiche, ma aggiunge tecniche proprie dell’IA come l’avvelenamento dei dati, l’evasione del modello e l’estrazione del modello. Qual è la differenza tra MITRE ATLAS e la OWASP LLM Top 10? Risolvono problemi diversi. ATLAS è un modello dell’avversario usato per la modellazione delle minacce e il red teaming. La OWASP LLM Top 10 è un elenco delle vulnerabilità più comuni nelle applicazioni LLM, usato per lo sviluppo sicuro. ATLAS dice come potreste essere attaccati, la OWASP dice dove di solito si trovano le debolezze. Sono complementari. Quante tattiche ha MITRE ATLAS? Nella versione 5.4.0 (febbraio 2026) la matrice ATLAS conta 16 tattiche, oltre a 84 tecniche, 56 sotto-tecniche, 32 misure di mitigazione e 42 casi di studio. Le fonti che citano 14 tattiche sono precedenti agli aggiornamenti recenti: verificate sempre la matrice aggiornata su atlas.mitre.org. MITRE ATLAS è richiesto dal regolamento europeo sull’IA? Il regolamento non nomina ATLAS, che quindi non è obbligatorio. Tuttavia l’articolo 15 impone ai sistemi ad alto rischio di essere resilienti all’avvelenamento dei dati, all’avvelenamento del modello, agli esempi avversari e agli attacchi alla riservatezza, cioè esattamente le minacce che ATLAS cataloga. ATLAS è un modo pratico per ordinare e dimostrare le soluzioni tecniche attese. Che rapporto c’è tra MITRE ATLAS e il NIST AI RMF? Agiscono a livelli diversi. ATLAS è un catalogo di minacce, il NIST AI RMF è un framework di governance imperniato su Governare, Mappare, Misurare e Gestire. In pratica ATLAS alimenta le funzioni Misurare e Gestire: fornisce le minacce concrete che valutate e trattate, mentre il RMF fornisce la struttura di supervisione attorno a esse.

Conclusione

La maggior parte dei team incontra MITRE ATLAS come artefatto di sicurezza, una matrice di attacchi che il red team studia. È una visione corretta ma incompleta. Per qualsiasi organizzazione che gestisce IA sotto regolamentazione, ATLAS è il ponte tra due mondi che spesso si ignorano: il team di sicurezza che sa come l’IA viene attaccata e il team di conformità che deve dimostrare la robustezza del sistema. Le sue tecniche sono le minacce nominate dal regolamento sull’IA rese concrete, e collegarle a controlli e prove è esattamente ciò che un audit vuole vedere. Cominciate in piccolo, con un sistema e le sue tecniche plausibili, poi ampliate la mappatura. Affinché tale mappatura viva in un unico luogo verificabile, scoprite come AI Sigil collega minacce, controlli e obblighi dell’IA.