AI red teaming: testare un’AI non è fare un penetration test
AI red teaming è il nome che ha preso una disciplina nata da una scoperta scomoda: i sistemi basati su modelli linguistici falliscono in modi che il collaudo di sicurezza tradizionale non sa nemmeno cercare. Una applicazione classica si rompe in modo deterministico, e un penetration test la sonda di conseguenza: dato un input, esiste o non esiste una vulnerabilità. Un modello generativo, invece, risponde allo stesso prompt in modi diversi a seconda del contesto, della formulazione, persino del caso. La domanda non è più se sia vulnerabile, ma con quale frequenza un certo attacco riesce. Questo cambia tutto: il metodo, gli strumenti, il senso stesso del risultato.
Conviene dirlo subito per sgombrare un equivoco diffuso. L’AI red teaming non è un penetration test applicato a un modello, e non è nemmeno la versione AI dell’emulazione avversaria che la sicurezza offensiva pratica da anni sull’infrastruttura. Condivide con quelle discipline la postura, pensare come un attaccante, ma cambia il bersaglio e la natura della prova. Si collauda un comportamento probabilistico, non una logica fissa, e il verdetto non è binario.
Perché un modello non si collauda come un’applicazione
La differenza di fondo è statistica. Quando si verifica una applicazione tradizionale, una falla c’è o non c’è, e una volta trovata si corregge. Quando si verifica un modello, lo stesso attacco può riuscire una volta su dieci o nove volte su dieci, e quel tasso è esso stesso il risultato. Per questo nell’AI red teaming non si parla di vulnerabilità presente o assente, ma di tasso di successo di un attacco misurato su una categoria di tentativi. Una difesa che blocca il 70 per cento dei jailbreak non è sicura né insicura: è descritta da quel numero, che va confrontato nel tempo e contro nuove varianti.
C’è poi una differenza di superficie. Il penetration test sonda reti, applicazioni, configurazioni. L’AI red teaming sonda qualcosa che quegli strumenti non vedono: il comportamento del modello sollecitato in modo ostile. Le tecniche che cataloga sono specifiche, e molte non hanno equivalente nel mondo tradizionale, dalla manipolazione dei dati di addestramento all’estrazione di informazioni dal modello, dall’aggiramento delle protezioni alla manipolazione dei sistemi AI tramite input costruiti ad arte. Sono attacchi al modo in cui il modello ragiona, non al server che lo ospita.
Il bersaglio non è solo il prompt, è il loop
Per un po’ l’AI red teaming ha coinciso con la ricerca di prompt malevoli isolati: una frase che induce il modello a violare le proprie regole. È una parte del lavoro, ma è la parte facile, e oggi è la meno rappresentativa. Con la diffusione dei sistemi agentici, dove il modello non si limita a rispondere ma pianifica, invoca strumenti e agisce in più passaggi, il bersaglio si è spostato dal singolo prompt all’intero ciclo di esecuzione.
Testare un agente significa attaccarne il loop. Le sonde più serie non si fermano alla prompt injection diretta, ma esercitano la prompt injection indiretta, nascosta dentro un documento o una pagina web che l’agente leggerà, l’avvelenamento delle basi di conoscenza usate per il recupero, la manomissione della memoria conversazionale, le chiamate a strumenti non sicure, l’abuso dei protocolli di integrazione con sistemi esterni, fino all’esfiltrazione di dati attraverso catene di più passi. È il terreno su cui si misura la sicurezza reale dei sistemi di AI agentica, e dove una singola prova isolata non dice quasi nulla: ciò che conta è cosa l’agente fa quando un’istruzione ostile entra a metà di un compito legittimo.
L’AI red teaming ha già i suoi framework
La novità del biennio è che questa disciplina ha smesso di essere artigianato individuale e ha acquisito riferimenti condivisi. Nel gennaio 2025 il progetto OWASP dedicato alla sicurezza dell’AI generativa ha pubblicato la sua guida al red teaming GenAI, una metodologia strutturata e basata sul rischio che copre l’intero spettro, dalle vulnerabilità del modello come tossicità e bias ai problemi di integrazione di sistema come l’uso improprio delle API e l’esposizione dei dati. È costruita sopra la lista OWASP Top 10 per le applicazioni LLM, dove la prompt injection figura come prima minaccia.
Sul versante della conoscenza degli attacchi, il riferimento è MITRE ATLAS, l’equivalente del framework ATT&CK calato sui sistemi di intelligenza artificiale: una base di conoscenza di tattiche e tecniche avversarie tratte da osservazioni reali e da dimostrazioni dei red team, che a inizio 2026 raccoglie oltre ottanta tecniche distribuite su quattordici categorie tattiche. ATLAS dà ai team un vocabolario per tradurre rischi astratti in tecniche concrete da simulare, e copre superfici tipiche dell’AI: pipeline di addestramento, API di inferenza, file dei modelli, vector store, modelli di embedding. A completare il quadro istituzionale, nel marzo 2025 il NIST ha aggiornato la propria tassonomia degli attacchi ML, distinguendo gli attacchi all’AI predittiva, evasione, avvelenamento, violazioni della riservatezza, da quelli specifici dell’AI generativa, dove rientrano la compromissione della catena di fornitura, la prompt injection diretta e indiretta, l’uso improprio e la sicurezza degli agenti.
Jailbreak e prompt injection non sono la stessa cosa
Vale la pena fissare una distinzione che il linguaggio comune confonde di continuo. Il jailbreak punta a far cadere le protezioni di sicurezza del modello, convincendolo a produrre ciò che dovrebbe rifiutare, spesso con espedienti di gioco di ruolo o istruzioni codificate. La prompt injection punta invece a scavalcare le istruzioni di sistema, facendo eseguire al modello comandi dell’attaccante al posto di quelli legittimi. La stessa OWASP riconosce che i due termini, pur correlati, vengono spesso usati in modo intercambiabile, ed è proprio per questo che una campagna di AI red teaming seria li tiene distinti: colpiscono bersagli diversi e vanno misurati con metriche separate. A dare scala al lavoro contribuiscono strumenti aperti ormai maturi, da Garak a PyRIT a Promptfoo, che automatizzano la generazione di attacchi e ne misurano la copertura, rendendo ripetibile ciò che altrimenti dipenderebbe dall’inventiva del singolo.
Una disciplina continua, non un esame da superare
L’errore più costoso sarebbe trattare l’AI red teaming come una certificazione da ottenere una volta. La guida OWASP lo dice senza giri di parole: nessun modello è mai davvero finito o sicuro. Un modello viene aggiornato, un prompt di sistema viene riscritto, un nuovo strumento viene collegato all’agente, e ogni cambiamento può riaprire una falla che si credeva chiusa o introdurne una inedita. Per questo il collaudo avversario dell’AI ha senso solo se continuo, integrato nei flussi di sviluppo, capace di misurare i tassi di successo nel tempo e di segnalare le regressioni come farebbe una suite di test.
C’è infine una dimensione che distingue questo lavoro da qualunque collaudo precedente: è insieme tecnica e sociale. Un AI red teaming completo non cerca solo la falla che esfiltra dati, ma anche il comportamento dannoso, la risposta tossica, la discriminazione, l’allucinazione pericolosa in un contesto critico. Sono rischi che non si esauriscono nel codice e che la pressione normativa, dall’AI Act alle linee guida sui modelli di frontiera, sta trasformando da buona pratica a requisito. L’AI red teaming, in definitiva, non è un esame che un sistema supera e archivia: è la capacità permanente di chiedere a un’AI, in modo ostile e ripetuto, cosa fa davvero quando qualcuno prova a piegarla, e di misurare quanto spesso ci riesce. In un mondo in cui questi sistemi decidono e agiscono, è la differenza tra fidarsi per fede e fidarsi per prova.
