Red teaming IA: dall’esercizio tecnico alla prova

In sintesi

• Il red teaming ha smesso di essere facoltativo in Europa il 2 agosto 2025, quando l’articolo 55 del regolamento sull’IA ha iniziato ad applicarsi ai fornitori di modelli per finalità generali con rischio sistemico.
• L’applicazione è operativa: l’Ufficio per l’IA dispone dei poteri sanzionatori dal 2 agosto 2026, con multe fino a 15 milioni di euro o al 3 per cento del fatturato mondiale annuo.
• Il regime dei sistemi ad alto rischio si è mosso in direzione opposta. L’omnibus digitale approvato il 16 giugno 2026 rinvia gli obblighi dell’allegato III al 2 dicembre 2027.
• La maggior parte delle organizzazioni non è fornitrice di questi modelli: l’esposizione arriva per via contrattuale, tramite le verifiche sui fornitori e le richieste di garanzia dei clienti.
• Un esercizio non documentato non prova nulla. Ciò che un valutatore legge è il fascicolo: perimetro, modello di minaccia, registro dei test, criticità, responsabili della remediation e verifica successiva.

Che cosa è davvero il red teaming, e che cosa non è

Il red teaming consiste nel sottoporre un sistema di IA a un attacco strutturato, condotto da persone il cui compito, per la durata dell’esercizio, è farlo fallire. Il gruppo costruisce richieste pensate per aggirare le protezioni, contamina un indice documentale, concatena chiamate a strumenti che il progettista non aveva previsto, e registra il comportamento ottenuto. L’obiettivo non è un punteggio. L’obiettivo è l’elenco dei comportamenti che nessuno aveva previsto.

Chi legge la prima pagina dei risultati su questo tema ne ricava che si tratti di una disciplina di sicurezza e nulla più. Ogni pagina ben posizionata descrive vettori di attacco, fasi di metodo e strumenti. La descrizione è corretta e incompleta, perché omette ciò che oggi determina il budget: nell’Unione europea questa attività costituisce un obbligo giuridico documentato per una categoria di fornitori e un’aspettativa documentata per diverse altre.

Due distinzioni vanno poste prima di procedere.

Red teaming, benchmark e valutazioni sono tre cose diverse

I benchmark misurano capacità note su un insieme fisso di domande. Le valutazioni assegnano un punteggio rispetto a criteri definiti in anticipo. Entrambi rispondono alla domanda su quanto bene il sistema faccia ciò che gli è stato chiesto. Nessuno dei due risponde alla domanda su che cosa faccia d’altro.

Il red teaming esiste per questa seconda domanda. La ricerca di IBM lo formula senza giri di parole: l’esercizio serve a trattare ciò che non si sa di non sapere. Una batteria di benchmark non può rivelare una modalità di guasto per cui nessuno ha scritto un test, e proprio quella categoria produce gli incidenti.

Conseguenza pratica: gli approcci si completano, non si sostituiscono. Avere misurato una capacità non equivale ad avere sondato un danno.

Non è nemmeno un penetration test con un nome nuovo

Un penetration test colpisce l’infrastruttura: rete, gateway API, livello di identità. Quel lavoro resta necessario. Il red teaming colpisce il modello e il suo comportamento, che fallisce in modo diverso. Per un modello che si lascia convincere non esiste una patch. La remediation prende la forma di riaddestramento, filtraggio, politiche di rifiuto, riduzione dei privilegi o monitoraggio, mai di un salto di versione.

L’obbligo di cui i risultati di ricerca non parlano

L’articolo 55, paragrafo 1, lettera a) del regolamento sull’IA impone ai fornitori di modelli di IA per finalità generali con rischio sistemico di effettuare la valutazione del modello secondo protocolli e strumenti standardizzati che riflettono lo stato dell’arte, compresa l’esecuzione e la documentazione di test in condizioni avverse volti a individuare e attenuare i rischi sistemici. Il testo aggiunge che i test devono essere proporzionati al livello di rischio e allo stato dell’arte, e che possono coinvolgere esperti esterni indipendenti.

Tre termini reggono l’intero peso. L’esecuzione rende obbligatorio l’esercizio. La documentazione rende obbligatoria la traccia. La proporzionalità significa che un fornitore di dimensioni contenute non sarà misurato sul programma di un laboratorio di frontiera, e simmetricamente che un laboratorio di frontiera non assolve l’obbligo con un fine settimana di prove sulle richieste.

Un modello rientra nella categoria del rischio sistemico quando la potenza di calcolo cumulata di addestramento supera 10^25 FLOPs, oppure quando l’Ufficio per l’IA lo designa sulla base di altri criteri. La soglia è deliberatamente alta: intercetta gli sviluppatori di modelli di frontiera, non l’impresa mediana.

Le scadenze sono l’elemento peggio compreso. Gli obblighi sui modelli per finalità generali si applicano dal 2 agosto 2025 ai modelli immessi sul mercato dopo tale data. I modelli già presenti dispongono di un termine che scade il 2 agosto 2027. E dal 2 agosto 2026 l’Ufficio per l’IA della Commissione dispone dei propri poteri di applicazione, con sanzioni fino a 15 milioni di euro o al 3 per cento del fatturato mondiale annuo, se superiore.

Nel frattempo il regime che tutti preparavano da due anni è arretrato. Il Parlamento europeo ha approvato il 16 giugno 2026 gli emendamenti dell’omnibus digitale, spostando gli obblighi dei sistemi ad alto rischio autonomi dell’allegato III dal 2 agosto 2026 al 2 dicembre 2027, e quelli dei sistemi integrati in prodotti al 2 agosto 2028. L’omnibus non ha toccato le scadenze relative ai modelli per finalità generali.

La situazione è quindi l’opposto di quanto presuppongono la maggior parte dei calendari di conformità. L’obbligo di test del regolamento esigibile oggi riguarda i modelli per finalità generali, e i test in condizioni avverse ne costituiscono il nucleo.

La via operativa passa dal codice di buone pratiche per i modelli per finalità generali. Il suo capitolo su sicurezza e protezione, pubblicato il 10 luglio 2025, definisce il dispositivo atteso: valutazioni dei modelli, red teaming, sorveglianza dopo l’immissione sul mercato, misure di cibersicurezza, notifica degli incidenti e responsabilità sul modello. La sottoscrizione resta volontaria, ma l’Ufficio per l’IA ha dichiarato che i firmatari sono considerati in buona fede e che i loro impegni pesano nel calcolo di una sanzione. È quanto di più vicino a un porto sicuro il regolamento offra, e poggia su prove di test.

Chi deve realmente fare red teaming

Per la maggior parte dei lettori la risposta onesta è: non voi, non direttamente. Va detto con chiarezza, perché i contenuti pubblicati dai fornitori di sicurezza su questa ricerca lasciano intendere un obbligo universale.

I fornitori di modelli per finalità generali con rischio sistemico. Vincolati dall’articolo 55, esigibile da subito, con sanzione. L’elenco è breve e gli interessati lo sanno.

I fornitori di sistemi ad alto rischio. L’articolo 9 impone un sistema di gestione dei rischi con test lungo l’intero ciclo di vita, e l’articolo 15 esige sistemi che funzionino in modo affidabile e resistano a errori, guasti e tentativi di alterarne l’uso o le prestazioni. Nessuno dei due impiega l’espressione red teaming. Entrambi impongono test in condizioni che mettono alla prova il funzionamento previsto, con metodo e risultati documentati. Applicabile dal 2 dicembre 2027 per i sistemi autonomi dell’allegato III.

I deployer. Nessun obbligo legale diretto di test. L’obbligo arriva dal contratto: questionari di acquisto, allegati di garanzia, diritti di audit, clausole di manleva. In pratica è per questa via che il red teaming raggiunge la maggioranza delle organizzazioni, e si presenta quasi sempre come una domanda a cui rispondere in trenta giorni. Strutturare quella risposta è prima di tutto un tema di governance, come mostra la nostra analisi delle sfide della governance dell’IA.

Tutti gli altri. Volontario, e sempre più atteso. Gli assicuratori lo chiedono. I grandi clienti anche. I consigli di amministrazione se ne occupano dopo il primo incidente pubblico nel loro settore.

Merita un nome un ultimo gruppo: le organizzazioni il cui parco di IA non è del tutto noto. Non si fa red teaming su ciò che non è stato inventariato, e gli usi non dichiarati spiegano perché molti programmi coprano solo una frazione della superficie reale. Le assunzioni offrono un esempio netto, come mostra la nostra analisi sull’intelligenza artificiale nelle assunzioni.

Che cosa chiede davvero ciascun quadro di riferimento

I quadri convergono sull’attività e divergono nettamente sulla forza vincolante.

Quadro di riferimento	Che cosa richiede	Termine impiegato	Vincolante?
Regolamento IA art. 55, par. 1, lett. a)	Valutazione del modello con test in condizioni avverse, documentati e proporzionati al rischio	Test in condizioni avverse	Sì, per i modelli con rischio sistemico, esigibile dal 2 agosto 2026
Regolamento IA art. 9 e art. 15	Test sul ciclo di vita in condizioni impegnative, metodo e risultati documentati	Test	Sì, per l’alto rischio, dal 2 dicembre 2027
Codice di buone pratiche, capitolo sicurezza e protezione	Valutazioni dei modelli, red teaming, sorveglianza post mercato, notifica degli incidenti	Red teaming	Volontario, ma rilevante in sede sanzionatoria
NIST AI RMF, Measure 1.1	Squadre avversarie e test avversi per far emergere capacità pericolose e proprietà emergenti	Red teaming	Volontario
NIST AI 600-1, profilo IA generativa	Red teaming prima e dopo il rilascio, su dodici categorie di rischio	Red teaming	Volontario
ISO/IEC 42001	Nessuna clausola dedicata; le registrazioni dei test sostengono il sistema di gestione	Test e valutazione	Certificabile
Guida OWASP GenAI Red Teaming	Test per fasi: modello, implementazione, sistema, esecuzione	Red teaming	Standard di pratica
Guida CSA e OWASP sull’IA agentica	Dodici categorie di minacce agentiche sul modello MAESTRO	Red teaming	Standard di pratica

Dalla tabella discendono due osservazioni.

Primo, ISO/IEC 42001 non pronuncia mai il termine, cosa che sorprende chi arriva cercando una clausola. La norma richiede la prova che i rischi siano stati individuati, i trattamenti testati e i risultati riesaminati. Un rapporto di red teaming con una traccia di remediation soddisfa quel requisito, un semplice benchmark di prestazione no.

Secondo, gli strumenti americani ed europei descrivono la stessa pratica con forza diversa. Il profilo di Berkeley per i modelli per finalità generali colloca il red teaming sotto Measure 1.1 del NIST AI RMF, per far emergere capacità pericolose, vulnerabilità e proprietà emergenti, e lo ripropone come controllo di ciclo di vita sotto Manage 1.3, 2.3 e 2.4. NIST AI 600-1 raccomanda di praticarlo prima e dopo il rilascio su dodici categorie di rischio. Nessuno dei due prevede sanzioni. Entrambi costituiscono ciò che un valutatore europeo accetterà come stato dell’arte quando l’articolo 55 chiederà rispetto a quale standard i test siano stati condotti.

Sul piano nazionale, la legge italiana sull’intelligenza artificiale ha designato AgID e l’Agenzia per la Cybersicurezza Nazionale come autorità competenti, la seconda con un mandato esplicito sul versante della sicurezza. Non introducono un obbligo nuovo di red teaming, ma definiscono l’interlocutore davanti al quale la diligenza andrà dimostrata.

Definire il perimetro perché i rilievi reggano

La maggior parte dei rapporti fallisce sul perimetro, non sul test. L’esercizio individua problemi reali, e poi nessuno sa più a quale versione del sistema si riferissero.

Nominare l’obiettivo con precisione. Modello di base, variante specializzata, livello di recupero documentale, superficie di strumenti e agenti, applicazione rilasciata. Indicare che cosa rientra nel perimetro, che cosa ne resta fuori, e perché. Testare il modello di base non copre il prodotto costruito sopra.

Fissare tutte le versioni. Build del modello, versione dell’istruzione di sistema, istantanea dell’indice documentale, configurazione delle protezioni, permessi degli strumenti. Un rilievo riferito a una build senza nome non può essere riverificato, e un rilievo non verificabile non è una prova.

Definire i danni dalla propria tassonomia. Gli elenchi generici producono rilievi generici. Se il registro dei rischi indica l’impegno finanziario non autorizzato e la divulgazione di dati dei clienti come esposizioni principali, sono quelle a entrare per prime nel perimetro, e il rapporto deve spiegare perché le altre siano state rinviate. Quel ragionamento rende visibile la vostra propensione al rischio agli occhi di un valutatore.

Decidere consapevolmente sull’indipendenza. L’articolo 55 contempla esplicitamente il ricorso a esperti esterni indipendenti. Le squadre interne conoscono meglio il sistema e costano meno. Le squadre esterne sono più difficili da liquidare e pesano di più sul piano probatorio. La scelta va messa per iscritto e motivata, perché sarà discussa.

Estendere il perimetro ai sistemi agentici. I test su singolo turno diventano insufficienti quando un sistema dispone di autonomia, memoria e strumenti. La guida della Cloud Security Alliance e di OWASP organizza questo lavoro attorno al modello di minaccia MAESTRO e a dodici categorie, tra cui la sottrazione delle autorizzazioni e del controllo dell’agente, l’aggiramento del punto di controllo umano, la manipolazione dell’obiettivo, la manipolazione di memoria e contesto, lo sfruttamento multi-agente, il raggio di impatto e la tracciabilità dell’agente. Quest’ultimo punto pesa più di quanto sembri: se le azioni di un agente non sono imputabili a posteriori, il guasto è prima di tutto un guasto di responsabilità, e solo dopo un problema di sicurezza.

Le prove che il red teaming deve lasciare

È la parte che i risultati di ricerca ignorano del tutto, ed è quella che decide se la spesa sia stata giustificata. Immaginate il fascicolo che un valutatore aprirà tra diciotto mesi.

La nota di perimetro. Datata, versionata, con le esclusioni e la loro motivazione.

Il modello di minaccia. Il riferimento adottato nominato esplicitamente: MITRE ATLAS, MAESTRO, la tassonomia OWASP GenAI, oppure il vostro, mappato su uno di questi.

Il registro dei test. Che cosa è stato tentato, da chi, con quali strumenti, in quale data, contro quale build. Delle campagne automatiche si registra la configurazione, non solo l’esito.

I rilievi con criticità e motivazione. La motivazione pesa più del punteggio. Un valutatore può contestare un livello alto e accettare comunque il fascicolo se il ragionamento è leggibile.

Le decisioni di remediation con responsabile e scadenza. Ogni rilievo riceve uno stato: risolto, mitigato, accettato, oppure rinviato con data di riesame.

Il rischio residuo accettato al livello giusto. Una persona con l’autorità necessaria firma che l’esposizione residua è tollerabile rispetto a una soglia scritta.

La prova della verifica successiva. La dimostrazione che il correttivo funziona, sullo stesso test, contro la build nominata. Senza di essa la colonna della remediation resta un’affermazione.

Due situazioni vanno nominate. Un red teaming non documentato non prova nulla, per quanto buoni siano stati i test. E un rapporto con rilievi privi di traccia di remediation è peggio di nessun rapporto, perché stabilisce in modo durevole che sapevate. Autorità e ricorrenti lo leggono allo stesso modo.

Dove il red teaming si innesta nel resto del fascicolo di governance

Un red teaming che si esaurisce in un PDF ha fallito, quali che siano stati i rilievi. Quattro innesti lo rendono operativo.

Il registro dei rischi. I rilievi diventano voci con responsabile e data di riesame, nello stesso sistema di ogni altro rischio. Se vivono in un tracciamento di sicurezza separato, il fascicolo di governance presenta un vuoto nel punto del collegamento.

La notifica degli incidenti. Un rilievo che poi si materializza in produzione diventa una questione ai sensi dell’articolo 73, e la prima domanda sarà se ne eravate a conoscenza.

La sorveglianza dopo l’immissione sul mercato. Il red teaming è una sonda puntuale. La sorveglianza ne è la metà continua, e il codice di buone pratiche le nomina entrambe. Un programma che ne comprende una sola è mezzo programma.

La rendicontazione di trasparenza. Il profilo di Berkeley convoglia i risultati nelle schede di modello e di sistema, omettendo in modo responsabile i dettagli che aumenterebbero il potenziale di abuso. Quella riserva non è facoltativa: pubblicare un aggiramento funzionante è un errore di divulgazione, non trasparenza.

Cinque difetti che annullano la prova

Testare una build e rilasciarne un’altra. Il difetto più comune. Il rapporto descrive un sistema che non esiste più.

Limitare il perimetro alla prompt injection. La prompt injection è la modalità di guasto famosa, non la più costosa. Sono i permessi sugli strumenti e l’autonomia degli agenti a produrre gli incidenti con conseguenze finanziarie.

Nessuna scala di criticità. Quando tutto è medio, nulla è prioritizzato, e la motivazione che un valutatore vuole leggere non esiste.

Rilievi senza responsabile. Un rilievo non assegnato è un appunto. Sarà ancora aperto al riesame successivo, e le date lo dimostreranno.

Nessuna verifica successiva. Il correttivo è affermato e non dimostrato. È la lacuna più frequente in programmi di red teaming per il resto seri, e la meno costosa da colmare.

Domande frequenti

Il red teaming è obbligatorio per legge?

Nell’Unione europea sì, per un gruppo preciso. L’articolo 55, paragrafo 1, lettera a) del regolamento sull’IA impone ai fornitori di modelli per finalità generali con rischio sistemico di eseguire e documentare test in condizioni avverse, obblighi esigibili dal 2 agosto 2026. Per i fornitori di sistemi ad alto rischio, gli articoli 9 e 15 impongono test documentati in condizioni impegnative dal 2 dicembre 2027, senza impiegare il termine. Per tutti gli altri l’obbligo è contrattuale più che legale.

Chi è tenuto a farlo in base al regolamento sull’IA?

I fornitori di modelli per finalità generali la cui potenza di calcolo cumulata di addestramento supera 10^25 FLOPs, o che l’Ufficio per l’IA designa come portatori di rischio sistemico. Si tratta di una popolazione ristretta di sviluppatori di modelli di frontiera. I deployer di quei modelli ereditano le aspettative per via contrattuale, ed è così che il requisito raggiunge la maggior parte delle organizzazioni.

Che differenza c’è con un penetration test?

Un penetration test attacca l’infrastruttura e produce vulnerabilità con relative patch. Il red teaming attacca il comportamento del modello e produce modalità di guasto senza patch. La remediation consiste in riaddestramento, filtraggio, politica di rifiuto, riduzione dei privilegi o monitoraggio. Servono entrambi, nessuno sostituisce l’altro.

Con quale frequenza va condotto?

Legate la cadenza al cambiamento anziché al calendario. Un nuovo modello di base, una specializzazione, un nuovo strumento o una nuova integrazione, una modifica sostanziale dell’istruzione di sistema, un nuovo contesto di rilascio: ciascuno giustifica un nuovo esercizio. Aggiungete una linea di riferimento periodica, annuale per la maggior parte dei sistemi, e trattate i test successivi al rilascio separatamente da quelli che lo precedono.

Si può automatizzare il red teaming?

In parte, e la ripartizione conta ai fini della prova. Le sonde automatiche danno ampiezza, ripetibilità e il meccanismo per la verifica successiva, esattamente ciò di cui la documentazione ha bisogno. Gli operatori umani trovano il percorso inedito che nessuna libreria di sonde contiene. Un programma interamente automatizzato produrrà un fascicolo ordinato con un punto cieco prevedibile.

Che cosa chiede un revisore dopo l’esercizio?

La nota di perimetro con le versioni, il modello di minaccia e il suo riferimento, il registro dei test, i rilievi con criticità e motivazione, responsabili e scadenze della remediation, l’accettazione del rischio residuo e la relativa firma, e la prova della verifica successiva. Il revisore valuta la catena documentale, non l’esercizio, perché è l’unica parte che sopravvive.

Conclusione

I risultati di ricerca trattano il red teaming come un servizio di sicurezza; in quella lettura la decisione si riduce a una voce di budget di una squadra tecnica. La posizione regolamentare dice altro. I test in condizioni avverse sono l’obbligo del regolamento sull’IA esigibile oggi, mentre il regime dell’alto rischio che tutti preparavano si colloca a più di un anno di distanza, e ciò che assolve l’obbligo non è l’esercizio ma la traccia che lascia.

Questo spostamento cambia la titolarità del tema. I test restano nelle mani di chi sa rompere i sistemi. La nota di perimetro, la motivazione delle criticità, il registro della remediation e la firma sul rischio residuo appartengono alla governance, perché sono gli unici documenti che qualcuno leggerà. Partite dal fascicolo che dovreste produrre, poi commissionate il red teaming che lo riempie. La nostra piattaforma di governance dell’IA mostra come questi elementi stiano nello stesso posto.