Definizione in una frase
Evaluación intencional de fallos mediante entradas, escenarios o actores que intentan romper las garantías del sistema.
Definizione: valutare intenzionalmente i possibili fallimenti
I test avversariali, spesso chiamati red teaming nel contesto dell’intelligenza artificiale, sono una pratica di valutazione e sicurezza che mette deliberatamente un sistema di IA alla prova con input ostili o scenari concepiti per farlo fallire. L’obiettivo è individuare vulnerabilità, distorsioni o comportamenti indesiderati. A differenza dei normali test funzionali, che verificano se il sistema opera secondo le specifiche, i test avversariali cercano di capire come possa essere manipolato o ingannato da un avversario competente.
È importante distinguere la tecnica di valutazione, cioè il test avversariale, dalla proprietà del sistema, cioè la robustezza. Il test è un processo attivo che sottopone il sistema a prove ostili; la robustezza indica quanto il modello riesca a mantenere il comportamento previsto in quelle condizioni. La valutazione può includere la sicurezza informatica dell’infrastruttura che ospita il modello e la sicurezza specifica del modello, che considera le vulnerabilità legate ai dati, agli algoritmi e al comportamento appreso. Il red teaming dell’IA non si limita quindi a cercare prompt che aggirino un filtro: può riguardare sistemi di visione, agenti e altre componenti dell’intero sistema.
Come si svolgono: il ciclo tecnico di valutazione
Un test avversariale strutturato parte dalla pianificazione e dalla definizione del modello delle minacce. Si stabiliscono l’ambito della prova, gli avversari plausibili, gli obiettivi che potrebbero perseguire e gli asset da proteggere. Un assistente collegato a documenti interni, per esempio, presenta rischi diversi da quelli di un classificatore di immagini. La definizione del perimetro chiarisce anche quali ambienti si possono testare, quali strumenti sono collegati e quali azioni richiedono un’autorizzazione o una conferma.
Si generano poi gli input ostili: possono essere prompt, immagini modificate o sequenze di dati progettate per sollecitare un comportamento specifico. Il gruppo di valutazione li applica al sistema e registra le risposte e le condizioni dell’esperimento. L’analisi può combinare regole lessicali, valutazioni semantiche e segnali comportamentali; nei sistemi non deterministici, le prove rilevanti possono essere ripetute per verificare se il risultato ricompare. Infine, si documentano i risultati, si valuta la loro gravità e si individuano possibili mitigazioni.
L’attività può essere condotta manualmente da specialisti, automatizzata o organizzata combinando i due approcci. L’automazione può generare varianti, eseguire molti test e aiutare a coprire più categorie di minaccia. Un modello linguistico può anche essere usato come generatore di input avversariali per testare un altro modello; questo non rende però automaticamente valide le sue valutazioni. La qualità dei risultati dipende dai criteri di rilevamento e dalla verifica delle evidenze. La creatività e il giudizio umano restano utili per riconoscere fallimenti contestuali o concatenazioni di azioni che una suite automatica potrebbe non cogliere.
Fasi di un test avversariale
Una procedura organizzata rende più chiari l’ambito, i risultati e i limiti della valutazione.
- 01Definire perimetro e regole: stabilire quali sistemi e ambienti si possono testare, con quali autorizzazioni e con quali criteri di arresto.
- 02Modellare le minacce: individuare avversari plausibili, obiettivi, asset critici e modalità d’interazione con il sistema.
- 03Generare gli attacchi: preparare prompt, immagini o altri input ostili, manualmente o con strumenti automatici.
- 04Eseguire e registrare: sottoporre gli input al sistema documentando configurazione, risposte e condizioni della prova.
- 05Analizzare i risultati: verificare i comportamenti con criteri dichiarati, valutare gravità e ripetibilità e distinguere i fallimenti dagli artefatti del test.
- 06Riferire e mitigare: descrivere le evidenze e i limiti della copertura, assegnare priorità ai problemi e definire interventi correttivi.
Tre esempi in ambiti diversi
Nei modelli linguistici di grandi dimensioni (LLM), i test possono esaminare l’iniezione di prompt e la divulgazione di informazioni. Un valutatore prova, per esempio, a inserire istruzioni che contraddicono quelle del sistema o a indurre il modello a rivelare dati a cui non dovrebbe dare accesso. Il risultato va interpretato nel contesto dell’applicazione: ciò che il modello può vedere, i filtri presenti e le autorizzazioni delle eventuali integrazioni influiscono sul rischio.
Nella visione artificiale, l’attenzione può concentrarsi sulle perturbazioni avversariali: modifiche all’immagine che inducono un classificatore a produrre un’etichetta errata. Un test può verificare se variazioni limitate dell’input cambino la classificazione di un segnale stradale. Questo esempio descrive un obiettivo di valutazione, non garantisce che una perturbazione specifica funzioni in ogni modello o in condizioni reali.
Gli agenti di IA aggiungono un’altra dimensione perché possono leggere contenuti e usare strumenti, come API o sistemi di posta elettronica. Un test può verificare se istruzioni malevole inserite in un documento o in un messaggio riescano a influenzare l’agente e a fargli tentare un’azione non autorizzata. L’esito dipende anche dai permessi degli strumenti, dalla separazione tra istruzioni e dati e dalla presenza di conferme umane.
Vettori di attacco in tre ambiti
Esempi schematici: le tecniche e i criteri di successo dipendono dalla configurazione del sistema valutato.
| Ambito | Vettore di attacco | Obiettivo della prova | Esempio |
|---|---|---|---|
| LLM | Iniezione di prompt o jailbreak | Verificare se istruzioni ostili aggirano le regole o inducono a divulgare informazioni | Provare una conversazione in più turni per verificare se il modello riveli istruzioni riservate. |
| Visione artificiale | Perturbazione avversariale | Verificare se una modifica dell’input cambia la classificazione | Controllare se variazioni dell’immagine alterino la classificazione di un segnale stradale. |
| Agenti di IA | Iniezione indiretta e uso improprio degli strumenti | Verificare se contenuti malevoli influenzino azioni o chiamate a strumenti | Inserire istruzioni ostili in un documento e controllare se l’agente tenti di inviare un messaggio senza autorizzazione. |
Confusioni frequenti: red teaming, pentesting e risultati
Il red teaming dell’IA non è sinonimo di pentesting tradizionale. Il pentesting cerca, tra l’altro, vulnerabilità nel codice, nella configurazione e nell’infrastruttura, come errori di controllo degli accessi o difetti di un’applicazione. I test avversariali sull’IA possono invece indagare come il modello reagisce a input manipolati, come tratta istruzioni inserite nei dati che legge o come usa gli strumenti collegati. Le due attività possono sovrapporsi nello stesso progetto, ma richiedono domande di valutazione e rimedi diversi.
Non è corretto neppure ridurre il red teaming dell’IA ai jailbreak dei chatbot. Concentrarsi soltanto sui prompt lascia fuori, tra gli altri casi, i modelli non linguistici, la manipolazione dei dati e i rischi di sicurezza dell’applicazione che incorpora il modello. Una valutazione utile specifica quali componenti e comportamenti include, invece di usare l’etichetta «red team» come se descrivesse un metodo uniforme.
Infine, un attacco riuscito non dimostra che il sistema sia insicuro in ogni circostanza; mostra però che una certa configurazione e un certo input hanno prodotto un fallimento da esaminare. Allo stesso modo, non trovare fallimenti non prova che il sistema sia sicuro. Il significato del risultato dipende dal perimetro, dai criteri di successo, dai metodi usati e dalla copertura raggiunta.
Limiti: copertura, automazione e riproducibilità
Lo spazio degli input possibili è vasto e spesso ad alta dimensionalità. Non è realistico provare ogni prompt, ogni immagine o ogni sequenza di interazioni; la copertura resta quindi incompleta. Un sistema che supera una serie di test può ancora fallire con una variazione non inclusa, con un diverso contesto o attraverso una sequenza di azioni più lunga. Una valutazione ben progettata documenta cosa è stato provato e non trasforma i test eseguiti in una garanzia generale.
La qualità del risultato dipende anche dall’avversario e dal metodo di valutazione. Input troppo semplici o ripetitivi possono non individuare problemi rilevanti. D’altra parte, un sistema automatico può generare molte varianti senza che tutte rappresentino fallimenti reali: i rilevatori lessicali o semantici possono classificare male una risposta, perciò i risultati importanti vanno controllati con criteri espliciti e, quando necessario, con revisione umana.
La riproducibilità può essere difficile quando le risposte variano tra esecuzioni, cambiano i modelli o intervengono elementi casuali nella generazione degli attacchi. Registrare input, configurazione, versione del modello, impostazioni e criteri di valutazione aiuta a interpretare e ripetere i test, ma non garantisce che un sistema non deterministico restituisca sempre lo stesso esito. Anche i risultati positivi hanno una portata circoscritta: descrivono ciò che è stato osservato con quel metodo, in quel momento e nel perimetro esaminato. Per questo la valutazione avversariale va ripetuta quando cambiano il modello, i dati, gli strumenti o il contesto d’uso.
Concetti collegati e come leggere la valutazione
La robustezza è la capacità di un sistema di mantenere il comportamento atteso in condizioni difficili o davanti a input avversariali. È una proprietà che si può valutare, non un sinonimo del processo di valutazione. I guardrail sono meccanismi progettati per limitare comportamenti o azioni indesiderati; provarli sotto attacco non dimostra da solo che tutte le protezioni del sistema siano efficaci.
L’iniezione di prompt è una tecnica che cerca di influenzare un modello attraverso istruzioni inserite nell’input o in contenuti che il modello elabora. Le valutazioni dell’IA sono più ampie dei test avversariali: possono includere qualità, prestazioni, equità e affidabilità in condizioni ordinarie. I benchmark avversariali offrono prove standardizzate per confrontare comportamenti, ma non sostituiscono l’analisi di un’applicazione specifica. Anche la supervisione umana conta: può limitare o verificare azioni ad alto impatto, ma la sua efficacia dipende da come è integrata nel processo.
Per interpretare una valutazione, è utile chiedere quale sistema sia stato testato, quali minacce siano state considerate, quali input e strumenti siano stati usati, come sia stata verificata la gravità e quanto siano ripetibili i risultati. Un rapporto chiaro presenta anche le aree non esaminate. La combinazione di prove automatiche e manuali può aumentare ampiezza e profondità, ma non elimina i limiti di copertura: la conclusione deve restare proporzionata alle evidenze raccolte.