AI Red Teaming spiegato: cosa testa un Red Team e cosa lascia dietro di sé

La maggior parte degli incarichi di red teaming AI viene giudicata in base all'artefatto sbagliato. Una settimana di lavoro produce una presentazione, la presentazione dice che si può convincere l'assistente a scrivere un'email di phishing, e nessuno può dire in seguito se il comportamento era riproducibile, quanto fosse grave o quale controllo lo avrebbe fermato. La disciplina ha un output reale, e non è una presentazione: è un insieme di risultanze che restano valide se si ripete l'esecuzione, ciascuna legata a un confine superato e alle prove che lo hanno superato. Questa è anche la forma del registro che l'archivio degli incidenti AI conserva — 400 voci che coprono il periodo da dicembre 2024 a ottobre 2026, tratte da 743 fonti distinte, e un verdetto su ciascuna circa se qualcuno sia stato effettivamente danneggiato.

La confusione è comprensibile, perché il "red teaming" viene usato per due attività che condividono il vocabolario e poco altro. Questa è una guida a entrambe, alle prove che ciascuna dovrebbe produrre e ai quattro punti in cui il red teaming nell'IA si discosta davvero dalla versione di rete che la maggior parte dei team di sicurezza sa già come condurre.

La questione del framework: a chi appartiene il test

Prima dell'ambito, c'è la questione di chi conduce l'esercizio e contro cosa. Microsoft pubblica una delle posizioni pubbliche più complete al riguardo, e vale la pena leggerla come una mappa piuttosto che come una pagina di prodotto. Il suo hub AI Red Team separa il concetto di AI red teaming dal come-si-fa, e poi archivia la pratica in un ordine che è esso stesso un argomento: panoramica, poi una guida per costruire un red team per LLM, poi il materiale di riferimento — un bug bar per il triage degli attacchi ai sistemi di machine learning, una tassonomia dei guasti del machine learning, un modello di responsabilità condivisa e una guida per il threat modelling degli sviluppatori.

Leggi la sequenza e la metodologia ne consegue. Una tassonomia stabilisce cosa conta come fallimento. Una soglia dei bug stabilisce quali di quei fallimenti vale la pena correggere. Un modello di responsabilità condivisa stabilisce chi ne risponde una volta individuato. La modellazione delle minacce stabilisce dove cercare successivamente. Senza questi quattro elementi, un red team genera aneddoti con una colonna di gravità appiccicata, e la colonna di gravità è qualunque cosa il tester abbia provato quel pomeriggio.

Il framework di automazione aperto di Microsoft, PyRIT, è collocato sullo stesso scaffale, e proprio questa collocazione è la parte utile. Un kit di orchestrazione non è una metodologia; è ciò verso cui si punta un obiettivo una volta che esistono la tassonomia e la soglia di gravità dei bug. I team che partono dal framework tendono a ritrovarsi con un ampio corpus di prompt e nessun modo per classificare i risultati.

Due red team, due domande diverse

La distinzione più utile in questo campo è quella che quasi nessuno mette per iscritto: un red team che testa un modello e un red team che testa un sistema stanno rispondendo a domande diverse, con diverse unità sottoposte a test, diversi output e diversi responsabili. Confonderle è il modo in cui un jailbreak viene segnalato come una vulnerabilità di sicurezza, e in cui un vero bug di escalation dei privilegi viene archiviato come un reclamo sulla qualità del modello.

La valutazione della sicurezza a livello di modello è un problema di misurazione. Stai chiedendo se un modello produrrà una categoria di contenuti, e il modo onesto di rispondere è un campione abbastanza ampio da dire qualcosa su un tasso. L'unità sottoposta a test è il modello dietro una sottile API, il metodo è il prompting avversariale — jailbreak, attacchi basati su persona, pressione multi-turn — e ciò che ne esce è una trascrizione più un giudizio sul danno. Quando i pesi cambiano o il livello di sicurezza del fornitore si sposta, l'intero risultato è obsoleto. Ecco perché questo tipo di test è di solito eseguito da chi costruisce il modello o da un valutatore indipendente, e perché le sue conclusioni raramente corrispondono a una correzione specifica nella tua applicazione.

Emulazione dell'avversario a livello di sistema è un problema di ingegneria. Ti stai chiedendo se un attaccante può far agire il sistema distribuito: leggere un file che non dovrebbe, chiamare uno strumento che non dovrebbe, spendere denaro che non dovrebbe. L'unità in prova è l'agente con i suoi strumenti, il recupero e le credenziali collegati. I metodi sono quelli noti, riadattati: iniezione tramite contenuto recuperato anziché tramite il turno dell'utente, abuso di strumenti, catene di privilegi assemblate a partire da autorizzazioni singolarmente ragionevoli, percorsi di dati che trapelano oltre il confine di un tenant. L'output è un riscontro con una riproduzione, un confine superato e un proprietario che può modificare la configurazione domani.

I due producono artefatti incompatibili, e tale incompatibilità è diagnostica anziché fastidiosa. Un risultato a livello di modello non può essere "corretto" dal tuo team se non cambiando modello. Un risultato a livello di sistema non può essere corretto affatto dal fornitore. Se un rapporto non dice quale dei due sia, non puoi assegnare nessuno dei suoi elementi.

Che cosa diventa la superficie di attacco una volta che il modello dispone di strumenti

La superficie che la maggior parte dei team testa ancora è il prompt. È anche la meno interessante, perché è quella su cui il fornitore del modello ha profuso il massimo sforzo di hardening e quella su cui un attaccante ha la minore leva. Le superfici che in realtà danno risultati sono quelle aggiunte dall'applicazione: gli strumenti che l'agente può chiamare, l'indice di recupero che legge, la memoria che conserva tra un turno e l'altro e il canale di output stesso.

Strumenti sono il punto in cui un modello linguistico diventa un attore, e la domanda interessante non è mai «può chiamare lo strumento» ma «qual è il privilegio minimo che questo strumento avrebbe potuto avere». Uno strumento di ricerca ticket che accetta una query in testo libero di solito può essere convinto ad accettare l'identificativo di un altro cliente. Il recupero è un canale di contenuti verso il contesto del modello, il che significa che chiunque possa scrivere nel corpus — un drive condiviso, una macro di supporto, una pagina web raggiunta dal fetcher — sta scrivendo nel prompt. La memoria trasforma un singolo turno in persistenza: un'istruzione impiantata nel secondo turno è ancora lì al quarantesimo turno. L'output è il punto in cui il testo del modello finisce in un luogo che lo interpreta, e rendering, markdown, anteprime dei link e pipeline vicine alla shell interpretano tutti il testo.

Un incarico che mette alla prova solo il prompt riporterà un risultato pulito e avrà ragione sulla cosa sbagliata.

Perché una trascrizione non è una scoperta

Un riscontro richiede tre proprietà che uno screenshot di una finestra di chat non possiede. La prima è riproducibilità: eseguilo di nuovo da uno stato pulito e si ripresenta. I modelli sono non deterministici, quindi la riproducibilità è un tasso, non un valore booleano — "nove tentativi su dieci" è un riscontro, "è successo una volta" è una voce. La seconda è un confine valicato: nomina la cosa che non sarebbe dovuta accadere nei termini dell'applicazione stessa, non del modello. Non "il modello è stato scortese", ma "l'agente ha letto un documento appartenente al tenant B". La terza è una gravità riconducibile all'impatto anziché all'intuizione del tester, ed è a questo che serve una soglia dei bug.

Tutto il resto — la trascrizione, il prompt, il ragionamento del modello — è prova a supporto di quei tre. Non è il risultato stesso, ed è per questo che un corpus di duemila prompt di jailbreak vale meno di cinque risultati di sistema riproducibili con controlli denominati allegati.

Quattro ambiti in cui il red teaming dell'IA diverge dal red teaming di rete

I team che arrivano dalla sicurezza di rete o delle applicazioni portano buoni istinti e quattro presupposti sbagliati.

• Non c'è un perimetro da difendere. Un engagement di rete ha un elenco di target; un engagement con un agente ha una finestra di contesto assemblata al momento della richiesta da fonti che potresti non aver inventariato. L'ambito deve essere espresso in termini di fonti di dati e autorizzazioni degli strumenti, non nomi host.

• Il target è non deterministico. Lo stesso input può riuscire martedì e fallire mercoledì. Questo infrange lo standard di evidenza della "singola riproduzione pulita" e ti costringe a riportare i tassi.

• L'exploit è il linguaggio, e il linguaggio non ha patch. Puoi correggere un controllo di autorizzazione mancante. Non puoi mettere una pezza a "il modello si può persuadere". La mitigazione per una debolezza a livello di linguaggio è un controllo situato altrove — un filtro, un limite di ambito, un confine di permessi — ed è per questo che i risultati devono indicare il controllo, non solo il comportamento.

• Il fornitore è parte del processo. Il tuo target cambia quando qualcun altro rilascia una versione. Un risultato a livello di modello è valido solo per la build che hai testato, e se non hai registrato la versione e la data, non hai un risultato.

Come definire l'ambito di un primo incarico

Gli incarichi che vanno male sono quasi sempre impostati come "testare l'AI". Un perimetro che sopravvive al contatto con un programma assomiglia più a questo: un agente, in un ambiente di staging, con dati e permessi modellati sulla produzione; un elenco dei cinque confini che contano (isolamento tra tenant, accesso alle credenziali, spesa, egress dei dati, ambito degli strumenti); regole di ingaggio che indicano ciò che è fuori perimetro; condizioni di arresto che stabiliscono chi può interrompere l'esecuzione; e un formato di evidenza definito concordato prima del primo tentativo, così che il rapporto sia assemblato da artefatti anziché ricostruito a memoria.

L'autorizzazione merita una frase a sé, perché è l'unico elemento che i team saltano quando il bersaglio è il proprio prodotto e gli strumenti sono di qualcun altro. Testare un modello che non gestisci, su un'infrastruttura che non possiedi, con prompt progettati per aggirare un livello di sicurezza, è un'attività diversa dal testare la propria implementazione — ed è l'ambito scritto a separare le due cose. Il gate di verifica utilizzato dal nostro stesso tier cyber esiste per la stessa ragione: il lavoro di sicurezza autorizzato a livello di modello richiede una parte identificata e responsabile da entrambi i lati.

Che cosa aggiunge il registro dell'incidente

Un'esercitazione di red team ti dice cosa fa il tuo target. Non può dirti cosa accade sul campo, e il campo è il luogo in cui si costruisce davvero l'argomentazione a favore di un controllo. È questo il vuoto che un registro degli incidenti colma — e la disciplina che impone è la parte utile: un record senza almeno una fonte non esiste, e un record senza un verdetto di danno non è un incidente.

Leggi i due artefatti insieme e il ciclo si chiude. Il red team produce un riscontro riproducibile e indica il controllo che l’avrebbe bloccato. Il registro ti dice se qualcuno sul campo ha già incontrato quel limite, quale sia stato il danno e se il controllo abbia tenuto altrove. Un riscontro senza precedenti sul campo è un’ipotesi che vale la pena correggere; un incidente sul campo senza un riscontro riproducibile è un bug che non puoi ancora chiudere. I team che fanno bene questo smettono di considerare "abbiamo fatto red teaming del modello" un deliverable e iniziano a considerarlo un input per un registro proprio.

Il che lascia la nota conclusiva onesta. Il red teaming AI non produce una garanzia di sicurezza, e qualsiasi incarico venduto come tale sta vendendo la cosa sbagliata. Produce un insieme di confini che ora sai essere superati, con prove che puoi rieseguire, ordinati in base a ciò che accade quando vengono superati. È sufficiente per prendere decisioni — e considerevolmente più di una presentazione.