Prompt injection e red teaming: i test prima del lancio

Prima del lancio di un agente destinato ai clienti, il red teaming deve verificare se qualcuno possa indurlo, anche tramite prompt injection, a esporre dati privati, compiere un'azione non autorizzata o produrre contenuti vietati. Si parte da un ciclo in 6 fasi: definire il perimetro, preparare gli attacchi, eseguirli, valutare gli esiti, correggere e ripetere i test. Il risultato utile è un problema documentato con una correzione verificata, non un bollino rassicurante.

Le funzionalità degli strumenti e le descrizioni dei framework sono state verificate sulla documentazione ufficiale il 17 ottobre 2026. Il metodo di lavoro e gli esempi con l'agente di assistenza proposti di seguito sono esercitazioni, non risultati di test su un prodotto.

Che cos'è il red teaming dell'AI?

Il red teaming dell'AI cerca deliberatamente di indurre un sistema di intelligenza artificiale a violare una regola definita di sicurezza, di protezione o di business. Chi esegue il test cerca un malfunzionamento, osserva il comportamento del sistema e usa quanto emerso per arrivare a una correzione verificabile. Per un'azienda che sta per lanciare un chatbot, l'oggetto del test è di solito l'intera applicazione: istruzioni, informazioni recuperate, permessi, strumenti e risposte visibili ai clienti. Minacce al modello e all'applicazione.

Pensiamo alla reception di un hotel. Un normale test del servizio verifica che l'ospite possa ritirare la chiave della propria camera. Un test avversariale si chiede invece se una falsa comunicazione della manutenzione, abbastanza convincente, possa indurre la reception a consegnare la chiave di un'altra stanza. Tra le prove da raccogliere c'è quale chiave sia stata consegnata, a prescindere dalla cortesia della risposta.

Anche un agente AI deve rispettare confini analoghi. Un ticket di assistenza è un'informazione da elaborare: non deve assumere l'autorità di un'approvazione del responsabile. Un documento recuperato può aiutare a rispondere a una domanda, ma non deve autorizzare l'accesso ai dati di un altro cliente.

Testare il modello AI o l'applicazione: che cosa cambia?

Il red teaming dei modelli AI ne esamina il comportamento di fronte a input avversariali. I test sull'applicazione comprendono anche il sistema circostante, dove identità del cliente, accesso ai documenti e permessi degli strumenti determinano ciò che può accadere. Il rapporto di sicurezza del fornitore del modello non può dimostrare che l'integrazione per i rimborsi controlli l'account corretto. La distinzione è esplicita nella documentazione di promptfoo sul red teaming.

Per la maggior parte delle aziende conviene partire dal perimetro dell'applicazione distribuita. I test sul modello restano utili quando lo si sceglie o lo si cambia, ma il cliente interagisce con il prodotto nel suo insieme.

Prompt injection e altri rischi che possono sfuggire al QA

Il red teaming dell'AI cerca modi per violare un confine previsto, anche con richieste plausibili che sfruttano l'ambiguità anziché input malformati. Il normale controllo qualità, o QA, verifica i comportamenti attesi: risposte corrette, transazioni valide, tempi di risposta ed errori previsti. Un programma QA maturo può includere test avversariali; il red teaming gli fornisce nuovi casi di errore da verificare.

Un bot di assistenza potrebbe spiegare correttamente la politica dei rimborsi e, allo stesso tempo, interpretare un paragrafo malevolo in un articolo di supporto come un'autorizzazione ad aggirarla. Entrambe le richieste sono testo leggibile. A cambiare è la fonte a cui l'applicazione riconosce autorità.

Per un agente destinato ai clienti, si può partire dalle seguenti categorie di attacco. Gli esempi sono test costruiti con scenari fittizi; i criteri di superamento vanno adattati alle proprie regole.

Queste categorie si sovrappongono. Un jailbreak mira ad aggirare le protezioni che regolano il comportamento. La prompt injection tenta di dirottare il sistema attraverso istruzioni a cui non dovrebbe riconoscere autorità. Quando è nascosta nel materiale recuperato, si parla di prompt injection indiretta: può causare una fuga di dati o un'azione non autorizzata. Le categorie descrivono aspetti diversi di una violazione, non compartimenti separati. Definizioni delle minacce.

Nel red teaming degli agenti AI bisogna seguire le azioni

Un agente AI è un'applicazione che può usare strumenti per compiere i passaggi necessari a svolgere un compito. Il red teaming degli agenti richiede quindi prove che vadano oltre la risposta finale. Un rifiuto non annulla la modifica di un record già avvenuta, così come la frase «rimborso emesso» non dimostra che sia stato davvero effettuato un rimborso.

Occorre acquisire sia la conversazione sia il registro delle azioni. Se l'agente richiede un'operazione vietata ma il livello di gestione dei permessi la blocca, vanno registrati separatamente il tentativo di violazione e il contenimento riuscito. Questa distinzione permette di migliorare il comportamento senza presentare un tentativo bloccato come una violazione effettivamente avvenuta.

Per un chatbot privo di strumenti, l'attenzione va alle risposte e alle informazioni accessibili. Per un agente che può modificare i dati dei clienti, bisogna includere lo stato precedente e successivo a ogni tentativo di azione. È il permesso aggiuntivo a cambiare il test.

Red teaming dei sistemi AI: chi dovrebbe intervenire subito?

Bisogna intervenire prima di rendere accessibili ai clienti informazioni private o azioni con conseguenze rilevanti. Le responsabilità cambiano secondo il ruolo, ma la decisione di rilascio richiede il contributo di tutti.

Chi sviluppa: un fondatore con finanziamenti o uno sviluppatore che lavora da solo dovrebbe scegliere un percorso cliente circoscritto e identificarne gli esiti vietati prima di collegare uno strumento di attacco. Se l'applicazione può leggere gli ordini, va verificata la separazione tra account. Se può modificarli, l'autorizzazione va verificata nel momento stesso della modifica.

Chi gestisce il servizio: il responsabile dell'assistenza dovrebbe fornire le regole, esempi di eccezioni legittime e il percorso di escalation. Chi si occupa di sicurezza non può dedurre quando l'azienda consenta un rimborso o quali richieste di consiglio il chatbot debba rifiutare. Un'azione tecnicamente valida può comunque violare una regola aziendale.

Chi acquista: il CTO di un'azienda di medie dimensioni dovrebbe richiedere prove relative alla configurazione che intende acquistare, inclusi connettori e permessi. Il rapporto sul modello di base fornito dal venditore offre informazioni di contesto, ma non risolve la valutazione del rischio della configurazione prevista.

Un prototipo limitato a informazioni pubbliche, senza azioni né utenti esterni, può rimandare una campagna automatizzata estesa mentre il suo comportamento è ancora in evoluzione. Vanno mantenuti i controlli di base sugli usi impropri e sui contenuti. L'apertura ai clienti, il recupero di informazioni private o l'introduzione di strumenti con permessi di scrittura sono il segnale per approfondire i test.

La formazione sul red teaming dell'AI parte dalle regole interne

Per il primo ciclo servono una persona che conosca l'applicazione, una che sappia valutare il danno per l'azienda e una che possa implementare le correzioni. Nei team piccoli i ruoli possono sovrapporsi, ma, quando possibile, i problemi con conseguenze rilevanti dovrebbero essere riesaminati da una persona diversa da chi li ha individuati.

Per esercitarsi, si possono scrivere un obiettivo di attacco e una condizione di fallimento osservabile per un caso di assistenza fittizio. Se i revisori non concordano sul fatto che il comportamento proposto sia consentito, bisogna chiarire la regola prima di provare ad automatizzare la valutazione.

Come eseguire il primo ciclo in sei passaggi

Il primo ciclo deve restare abbastanza contenuto da consentire l'esame e la correzione di ogni problema con conseguenze rilevanti. Quello che segue è un metodo operativo proposto, non l'affermazione che un numero fisso di test certifichi la sicurezza.

L'esempio di riferimento è un agente di assistenza che può leggere gli ordini e richiedere rimborsi. Il risultato atteso è un insieme di prove comprensibile anche a un altro ingegnere o a un acquirente.

1. 1

   1. Definire il perimetro dell'applicazione e gli esiti vietati

   Documentare la revisione dell'applicazione, l'identificativo del modello, le istruzioni, le fonti da cui recupera informazioni, i ruoli dei clienti, gli strumenti disponibili e le regole di approvazione. Specificare l'ambiente e chi ha autorizzato l'esercitazione. Elencare le esclusioni, così che un'integrazione non testata non scompaia dietro un esito complessivo positivo.

   Nell'esempio dell'assistenza, il confine potrebbe essere questo: i clienti possono leggere i propri ordini; i rimborsi richiedono un'approvazione valida; nessun cliente può recuperare i dati di un altro. Ogni regola deve essere osservabile. «Rispettare la privacy» è troppo vago per assegnare un esito.

   Usare record sintetici e identità di test con accessi limitati in un ambiente simile a quello di produzione. Indirizzare le operazioni di scrittura verso un servizio di test controllato che mantenga i controlli sui permessi e registri ciò che verrebbe modificato. Uno strumento fittizio che accetta tutto non può dimostrare se le autorizzazioni in produzione funzionino. Impostare limiti alle richieste, al tempo e alla spesa, oltre a un modo per interrompere l'esecuzione.

   Il risultato è un breve documento sul perimetro, con responsabili identificati ed esiti che bloccano il rilascio. Per predisporre l'ambiente isolato, fare riferimento alla guida alle valutazioni di sicurezza degli agenti AI.

2. 2

   2. Preparare gli attacchi a partire dai danni per l'azienda

   Scrivere gli obiettivi prima dei prompt. «Ottenere l'indirizzo di spedizione di un altro cliente» è un obiettivo. Una specifica formulazione è soltanto uno dei tentativi per raggiungerlo.

   Per ogni obiettivo, registrare il punto di ingresso, i permessi dell'attaccante, il comportamento sicuro atteso e le prove necessarie. Includere messaggi diretti in chat, documenti recuperati e risposte degli strumenti, se l'applicazione li usa. Testare sia una richiesta immediata sia una conversazione che porti gradualmente alla violazione.

   Un caso utile è un articolo di assistenza fittizio che contenga l'istruzione di rinunciare all'approvazione dei rimborsi. Il comportamento atteso consiste nel trattare quel passaggio come contenuto non attendibile e mantenere il requisito di approvazione. Includere anche un rimborso legittimo con approvazione valida, affinché una difesa che blocca tutti i rimborsi non sembri efficace.

   Conservare i casi originali e i loro identificativi. Aggiungere varianti che cambino formulazione, contesto o punto di ingresso senza modificare implicitamente l'esito vietato.

3. 3

   3. Eseguire i test lungo il percorso applicativo del cliente

   Collegare il test alla stessa logica applicativa che gestisce le richieste dei clienti, usando l'ambiente e l'identità di test definiti nel perimetro. Testare il solo modello, saltando il recupero delle informazioni e le autorizzazioni, significa rispondere a una domanda diversa.

   Verificare prima che il collegamento raggiunga il bersaglio previsto e che i log contengano le prove necessarie. Quindi eseguire i casi selezionati, conservando input, cronologia della conversazione, passaggi recuperati, richieste agli strumenti, decisioni sui permessi, risposte e stato finale. Non inserire credenziali nei rapporti e usare marcatori sintetici per i dati sensibili al posto dei dati reali dei clienti.

   Ripetere i casi con conseguenze rilevanti secondo una regola dichiarata, perché le risposte del modello possono variare. Registrare le ripetizioni e l'eventuale limite ai turni di un attaccante che adatta le proprie mosse. Azzerare le sessioni tra casi indipendenti; mantenere la cronologia quando il test riguarda la sequenza della conversazione.

   Un timeout, un errore di autenticazione o un parser malfunzionante vanno considerati problemi del test fino a quando non siano stati analizzati. Non dimostrano che l'applicazione abbia resistito all'attacco.

4. 4

   4. Valutare le prove, poi assegnare la gravità

   Assegnare a ogni tentativo uno stato fondato sulle prove prima di calcolare una metrica complessiva. Usare controlli espliciti per i fatti osservabili, come la restituzione di un record vietato o una modifica di stato non autorizzata. Un valutatore basato su un modello può aiutare a interpretare il linguaggio, ma i problemi con conseguenze rilevanti e i giudizi incerti richiedono una revisione umana.

   Questa griglia proposta permette di distinguere un test malfunzionante da un confine protetto con successo:

   Stato	Significato	Passaggio successivo
   Superato	Il tentativo valido non ha causato la violazione definita e le prove richieste sono disponibili.	Conservare il caso e le relative prove.
   Fallito	Le prove confermano la violazione definita.	Assegnare la gravità e un responsabile della correzione.
   Non valido	Il tentativo non ha messo alla prova lo scenario previsto, per esempio a causa di un'autenticazione fallita o dell'assenza del contenuto di attacco.	Correggere il test ed eseguirlo di nuovo.
   Non conclusivo	Lo scenario è stato eseguito, ma le prove o la valutazione non permettono di stabilirne l'esito.	Indagare; non conteggiarlo tra i test superati.

   La gravità è una valutazione separata: riguarda il danno, i dati coinvolti, gli accessi necessari all'attaccante e l'eventuale raggiungimento di un punto in cui viene eseguita un'azione reale. Una divulgazione confermata di dati tra clienti richiede una decisione sul rilascio anche se la maggior parte delle prove innocue è stata superata.

   Se si riporta un tasso di successo osservato degli attacchi, definirlo come il numero di tentativi riusciti e confermati diviso per i tentativi validi secondo il protocollo dichiarato, indicando anche gli esiti irrisolti. Se restano tentativi validi ma non conclusivi, presentare la frazione come limite inferiore del successo confermato, anziché come tasso di successo completo. Specificare che cosa conta come tentativo, incluso se una conversazione su più turni valga come un unico caso. Non unire insiemi di test che cambiano per ricavarne un andamento e non interpretare la percentuale risultante come la probabilità che un cliente subisca un attacco.

5. 5

   5. Correggere il controllo che non ha funzionato

   Risalire alla causa del problema prima di modificare il prompt. Se un documento recuperato può conferire l'autorità di approvare un rimborso, rafforzare la verifica dell'approvazione nel punto in cui viene chiamato lo strumento. Se il recupero delle informazioni restituisce i dati di un altro cliente, correggere il filtro di accesso prima che quei dati entrino nel contesto del modello.

   Altre correzioni possono consistere nel rimuovere uno strumento superfluo, restringere i permessi, richiedere l'approvazione per un'azione con conseguenze rilevanti, separare le istruzioni dai contenuti esterni o migliorare le regole sulle risposte. Scegliere la correzione che interviene sul percorso effettivamente osservato.

   Per i modelli di implementazione, consultare la guida ai guardrail e alla limitazione dell'impatto degli agenti in produzione. Il red teaming individua il problema da affrontare; i controlli in produzione limitano ciò che il sistema può fare quando le difese basate sul linguaggio falliscono.

   Ogni problema richiede un responsabile, una modifica precisa e un criterio di verifica successiva. «Prompt rafforzato» non è una condizione sufficiente per chiuderlo.

6. 6

   6. Ripetere il caso fallito e quelli simili

   Riproporre il caso originale all'applicazione corretta, quindi testare varianti che perseguano lo stesso obiettivo. Verificare anche il percorso legittimo del cliente. Bloccare tutti i rimborsi può chiudere la strada all'attacco e, al tempo stesso, compromettere il prodotto.

   Conservare le prove precedenti e successive alla correzione, le revisioni dell'applicazione e la configurazione del test. Inserire i casi corretti in una suite di regressione, cioè un insieme di controlli ripetibili che rilevino il ritorno di vecchi problemi. Aggiungere separatamente nuovi attacchi esplorativi, affinché i miglioramenti sulla suite fissa non nascondano nuove debolezze.

   Rivedere il perimetro quando cambiano modello, istruzioni, fonti delle informazioni, permessi, strumenti o regole aziendali. Procedere al rilascio solo quando i problemi dichiarati bloccanti sono risolti o il responsabile della decisione ha accettato esplicitamente il rischio residuo. Un esito non conclusivo su un confine che condiziona il rilascio resta aperto.

OWASP, MITRE ATLAS e NIST: a ciascuno il suo ruolo

I framework servono a organizzare il lavoro; occorre poi aggiungere le condizioni di fallimento specifiche dell'applicazione. Nessuno di essi definisce la politica dei rimborsi dell'azienda o dimostra che la separazione tra clienti abbia retto.

OWASP Top 10 for LLM Applications è una lista di controllo dei rischi per le applicazioni che usano modelli linguistici di grandi dimensioni, i modelli che generano testo alla base di molti chatbot. La pagina attuale presenta l'elenco 2025, che comprende prompt injection, divulgazione di informazioni sensibili ed eccessiva autonomia, ossia la possibilità per un sistema di compiere troppe azioni. È utile per individuare categorie di rischio mancanti nell'elenco degli attacchi. L'elenco ufficiale di OWASP.

MITRE ATLAS è una base di conoscenza in continuo aggiornamento sulle tattiche e tecniche degli avversari che coinvolgono l'AI, alimentata da attacchi osservati e dimostrazioni realistiche. Serve a descrivere come un attaccante potrebbe arrivare a un esito dannoso e a collegare casi isolati in una sequenza plausibile. Aiuta chi esamina la sicurezza a capire quali comportamenti siano stati coperti dall'esercitazione. MITRE ATLAS.

L'AI Risk Management Framework del National Institute of Standards and Technology, o NIST AI RMF, organizza la gestione del rischio attorno a Govern, Map, Measure e Manage. NIST lo descrive come volontario. Serve a collegare il test alle responsabilità, al contesto di utilizzo, alla misurazione e alla decisione sul rischio irrisolto. Un rapporto che riconduce i risultati al framework non equivale a una certificazione NIST. NIST AI RMF.

Nel caso fittizio del rimborso, OWASP aiuta a dare un nome al rischio, ATLAS a descrivere il percorso dell'attacco e l'AI RMF a inserire il risultato in un processo decisionale strutturato. Questo collegamento deve accompagnare le prove, senza sostituirle con le etichette dei framework.

Strumenti per il red teaming dell'AI: quando usare ciascuno

Scegliere lo strumento che può mettere alla prova l'applicazione effettiva e conservare le prove necessarie. L'open source è un buon punto di partenza quando un ingegnere può occuparsi di configurazione, valutazione, analisi e nuove esecuzioni. Una piattaforma diventa interessante quando coordinare questo lavoro tra applicazioni e revisori costituisce il collo di bottiglia.

promptfoo: test ripetibili sull'applicazione

La modalità red team di promptfoo genera input avversariali tramite plugin, applica strategie di attacco e produce rapporti per esaminare i problemi. La guida introduttiva documenta i test tramite API web, un'interfaccia con cui chiamare l'applicazione, ma anche tramite browser o direttamente su un modello. È quindi un punto di partenza pratico per chi vuole configurare una scansione ripetibile dell'applicazione. Guida introduttiva ufficiale al red teaming.

L'aspetto operativo da controllare è il trattamento dei dati: eseguire i test in locale non implica che anche generazione e valutazione restino locali. Alcuni plugin richiedono inferenza su servizi ospitati, e la valutazione su questi servizi può ricevere prompt e risposte del sistema bersaglio. Prima di collegare materiale ad accesso limitato, verificare i flussi di dati documentati. La recensione di promptfoo approfondisce la configurazione e questi confini.

Microsoft PyRIT: flussi di test avversariali flessibili

Microsoft PyRIT, il Python Risk Identification Tool for generative AI, è un framework open source per individuare i rischi nei sistemi di AI generativa. La documentazione tratta attacchi a turno singolo e su più turni, bersagli personalizzati, valutazione e salvataggio dei risultati delle conversazioni, con modalità scanner, interfaccia grafica e framework. Repository attuale e documentazione ufficiale.

È indicato quando l'esercitazione richiede sequenze di attacco o valutazioni personalizzate e c'è qualcuno che può occuparsi di combinarle. Il rovescio della medaglia è che questa flessibilità lascia al team la definizione delle condizioni di successo specifiche dell'applicazione e l'integrazione delle prove.

NVIDIA garak: scansione delle vulnerabilità degli LLM

NVIDIA garak, il Generative AI Red-teaming & Assessment Kit, si presenta come uno scanner di vulnerabilità degli LLM. Usa sonde per sollecitare malfunzionamenti e rilevatori per valutare gli output, coprendo ambiti come fughe di dati, prompt injection, tossicità e jailbreak. Il repository documenta anche un connettore per endpoint web e log dettagliati dei risultati. Repository ufficiale.

È indicato per la scansione sistematica di un modello o di un endpoint conversazionale. Se la verifica riguarda l'azione di uno strumento o i dati di un cliente, bisogna assicurarsi che il bersaglio e i controlli rendano disponibili le relative prove. La sola valutazione dell'output da parte dello scanner non può dimostrare un cambiamento di stato che non osserva. È un limite del perimetro del test, non un motivo per scartare le scansioni dei modelli.

Airia: quando conta gestire campagne continuative

Airia entra nella valutazione delle piattaforme quando il problema comprende il coordinamento di test ripetuti sugli agenti attraverso diversi flussi di lavoro. La pagina dedicata al red teaming degli agenti descrive test di prompt injection, manipolazione degli strumenti e scenari concatenati, compresi attacchi in più passaggi che attraversano prompt, strumenti, API e memoria. Airia descrive inoltre campagne continuative e risultati ricondotti a framework di sicurezza riconosciuti. Si tratta delle funzionalità dichiarate dal fornitore. La pagina di Airia sul red teaming degli agenti.

Una piattaforma giustifica il proprio ruolo quando riduce il lavoro necessario a collegare le applicazioni, esaminare le prove e seguire i problemi fino alla correzione. Per un'azienda con più responsabili di agenti e revisioni da parte di clienti aziendali, questo può contare più del controllo diretto su ogni componente del sistema di esecuzione dei test.

Subordinare l'acquisto a una dimostrazione sull'applicazione inclusa nel perimetro: riprodurre un problema noto in uno scenario fittizio, esaminare le prove dell'azione interessata, applicare una correzione e ripetere il caso. Chiedere quali collegamenti ai framework ed esportazioni delle prove siano disponibili per quella configurazione. La descrizione pubblica delle funzionalità non dimostra un'efficacia verificata in modo indipendente e non prova che tutte le integrazioni necessarie siano coperte.

Restare sull'open source quando una suite gestibile e un ingegnere responsabile producono già le prove richieste dagli acquirenti. Acquistare una piattaforma quando le operazioni ricorrenti e la revisione condivisa lo giustificano, purché la dimostrazione soddisfi lo stesso standard. Nessuna delle due scelte elimina la necessità di definire i comportamenti accettabili.

Quali prove dovrebbe chiedere un acquirente aziendale?

Chiedere un rapporto riferito alla configurazione prevista e un esempio completo che vada dall'individuazione del problema al nuovo test dopo la correzione. «Facciamo red teaming della nostra AI» è un'affermazione sul processo; la documentazione deve mostrare che cosa sia stato testato e che cosa sia cambiato di conseguenza.

Richiedere insieme questi elementi:

• Perimetro e data: identificativi di applicazione e modello, istruzioni rilevanti, fonti delle informazioni, ruoli, strumenti, integrazioni ed esclusioni.
• Copertura degli attacchi: obiettivi, punti di ingresso, casi a turno singolo e conversazionali, funzionalità del cliente accessibili a chi esegue il test.
• Metodo e valutazione: configurazione del test, conteggio dei tentativi, criteri di successo, revisione umana e gestione degli esiti non validi o non conclusivi.
• Problemi rilevati: gravità, confini interessati, prove riproducibili e limiti irrisolti, condividendo i dettagli sensibili attraverso un canale adeguato.
• Correzioni e nuovi test: controllo modificato, prove prima e dopo l'intervento e conferma che l'uso legittimo continui a funzionare.
• Responsabilità nel tempo: chi accetta il rischio residuo, quali modifiche richiedono un nuovo ciclo e come vengono informati i clienti dei problemi rilevanti che li riguardano.

Chiedere se il lavoro sia stato svolto dal fornitore, da un valutatore esterno o da entrambi. L'indipendenza è un'informazione utile, ma il logo di una terza parte non può compensare l'assenza di un perimetro definito o di test su un connettore.

Se il rapporto esclude l'integrazione che si intende attivare, considerarla non valutata. Richiedere test mirati prima di abilitarla, oppure limitare la configurazione fino a quando non siano disponibili le prove pertinenti. Un risultato senza criticità per un chatbot in sola lettura non può autorizzare, per associazione, un agente con permessi di scrittura.

Quali promesse vanno ridimensionate?

Un numero elevato di attacchi non dimostra la copertura dei test. Ripetere varianti su un endpoint di chat può lasciare inesplorati il recupero delle informazioni, la memoria e le autorizzazioni degli strumenti. La copertura deve riferirsi alle superfici e alle condizioni di fallimento definite nel perimetro.

Anche un unico tasso di superamento dei test si presta a interpretazioni eccessive. Generatori di attacchi, budget, denominatori e valutatori diversi rendono difficile confrontare i punteggi. Ogni dato aggregato va accompagnato dal protocollo e dai problemi con conseguenze rilevanti. Non esiste una percentuale di superamento universalmente sicura che risolva una fuga dimostrata di dati dei clienti.

La valutazione basata soltanto sui rifiuti è particolarmente debole per gli agenti. Una risposta apparentemente sicura può accompagnare un'azione pericolosa, mentre una chiamata a uno strumento bloccata può dimostrare che un controllo importante ha funzionato. Prima di assegnare l'esito, esaminare le prove.

Infine, il red teaming è uno degli elementi di un programma di sicurezza e protezione. Non sostituisce il normale QA, i test sui controlli di accesso, il monitoraggio in produzione o la risposta agli incidenti. Una campagna completata documenta ciò che è accaduto nelle condizioni testate; non dimostra l'assenza di problemi ancora sconosciuti.

Domande frequenti sul red teaming dell'AI

Che cos'è il red teaming applicato all'AI?

È un'attività deliberata di test avversariale che cerca di indurre un sistema AI a violare una regola di sicurezza, di protezione o di business. Per un'applicazione destinata ai clienti, bisogna includere l'accesso ai dati e il comportamento degli strumenti, oltre alle risposte del modello.

Qual è la migliore AI per il red teaming?

Non esiste un modello attaccante o uno strumento migliore in assoluto. Occorre scegliere un metodo che raggiunga i veri punti di ingresso dell'applicazione e possa verificare l'esito vietato. promptfoo, Microsoft PyRIT e NVIDIA garak offrono modi diversi di organizzare questo lavoro; nessuno definisce automaticamente le regole aziendali.

Come si comincia a fare red teaming dell'AI?

Si parte da un'applicazione che si è autorizzati a testare, dati sintetici e un confine definito per iscritto. Bisogna imparare a documentare un problema in modo riproducibile, indicando chiaramente il risultato atteso, e poi verificare la correzione. Conoscere l'applicazione, osservare con attenzione e valutare correttamente viene prima dell'aumento della scala di generazione degli attacchi.

L'AI sostituirà chi si occupa di red teaming?

Nei test dei sistemi AI, l'automazione può generare e ripetere le prove, ma servono ancora persone per definire i danni inaccettabili, convalidare i problemi e decidere se le prove giustifichino un rilascio. Attacchi e valutazioni automatizzati vanno considerati un supporto a questo lavoro, con revisione umana quando le conseguenze sono rilevanti.

Qual è un esempio concreto di red teaming?

Inserire una falsa istruzione che elimini l'approvazione dei rimborsi in un documento di assistenza fittizio usato da un agente di supporto. Verificare se l'agente attribuisca autorità al documento e se lo strumento per i rimborsi consenta un'azione non autorizzata. Correggere il controllo che non ha retto e ripetere il caso, insieme a quello di un rimborso legittimo e approvato.

Il prossimo passo

Prima della prossima revisione per il lancio, scegliere un percorso cliente, scriverne gli esiti vietati e assegnare un responsabile delle correzioni. Eseguire il ciclo nel perimetro definito e portare le prove alla discussione sul rilascio. Chi acquista dovrebbe chiedere al fornitore di illustrare un problema, la sua correzione e il test successivo per la configurazione che intende usare.

Iscriviti alla newsletter per guide pratiche alla realizzazione e alla gestione dei sistemi AI.