Pianificazione del red teaming di intelligenza artificiale

Il processo di red teaming è una procedura consigliata per lo sviluppo responsabile di applicazioni e sistemi che usano Modelli di linguaggio di grandi dimensioni (LLM). Il red teaming integra il lavoro sistematico di misurazione e mitigazione svolto dagli sviluppatori e aiuta a individuare e identificare i danni. I team rossi aiutano anche ad abilitare le strategie di misurazione per convalidare l'efficacia delle mitigazioni.

Quando si pianifica un approccio al red teaming di LLM e alle applicazioni abilitate all'intelligenza artificiale, prendere in considerazione gli obiettivi seguenti:

• Assicurarsi che vengano seguiti protocolli di sicurezza software appropriati per l'applicazione. L'intelligenza artificiale non esenta dalle procedure di sicurezza tradizionali
• Testare il modello di base LLM e determinare se esistono lacune nei sistemi di sicurezza esistenti, in base al contesto dell'applicazione
• Fornire commenti e suggerimenti sugli errori rilevati dai test per favorire i miglioramenti

Il processo di red teaming per intelligenza artificiale prevede quattro fasi: reclutamento del team, progettazione di test con gli avversari, esecuzione dei test e segnalazione dei risultati.

Reclutare il red team

Il successo del red teaming di intelligenza artificiale dipende dalle persone reclutate. Quando si selezionano membri red team, attenersi ai principi seguenti:

• Selezionare per esperienza e competenze diverse: cercare membri del red team con background, aree di competenza e casi d'uso diversi per il sistema di destinazione. Ad esempio, se si esegue un'analisi su un chatbot del settore sanitario, un'infermiera professionale ha un approccio diverso rispetto a un amministratore di sistemi che si occupa dell'infrastruttura del chatbot.
• Includere mentalità antagoniste e benevole: a differenza dei tradizionali team rossi composti esclusivamente da professionisti della sicurezza, i team rossi di intelligenza artificiale devono includere anche utenti normali. Gli utenti regolari possono individuare comportamenti dannosi tramite modelli di interazione naturali che i professionisti della sicurezza potrebbero non pensare di testare. Ad esempio, un infermiere potrebbe convincere un chatbot a rilasciare dati riservati dei pazienti in un modo che non verrebbe in mente a un professionista della sicurezza.
• Assegnare membri del team a rischi e funzionalità specifici: assegnare membri con competenze specifiche per indagare su tipi specifici di rischi, ad esempio esperti di sicurezza indagano su jailbreak ed estrazione di metaprompt. Per più turni, prendere in considerazione la rotazione delle assegnazioni per portare prospettive nuove, dando il tempo per adattarsi.
• Fornire obiettivi chiari: fornire a ogni membro del team istruzioni chiare relative all'obiettivo, alle funzionalità del prodotto da testare, ai tipi di problemi da analizzare, alle aspettative temporali e a come registrare i risultati.

Fornire un modo coerente per registrare i risultati, tra cui la data, un identificatore univoco per la riproducibilità, la richiesta di input e una descrizione o uno screenshot dell'output.

Progettare test antagonisti

Poiché un'applicazione viene compilata usando un modello di base, eseguire il test a entrambi i livelli:

• Il modello di base LLM con il sistema di sicurezza in uso, in genere tramite un endpoint API, per identificare le lacune che devono essere affrontate nel contesto dell'applicazione
• L'applicazione abilitata per l'intelligenza artificiale tramite l'interfaccia utente, per testare il sistema completo, inclusi i meccanismi di sicurezza a livello di applicazione

I Red Team devono eseguire test su entrambi i livelli sia prima che dopo l'implementazione delle mitigazioni.

Eseguire test

Per iniziare, testare il modello di base per comprendere la superficie di rischio e guidare lo sviluppo della mitigazione. Testare in modo iterativo con e senza mitigazioni per valutarne l'efficacia. Utilizzare sia il red teaming manuale sia le misurazioni sistematiche e testare l'interfaccia utente di produzione quanto più possibile per replicarne l'utilizzo nel mondo reale.

Strutturare i test in base a queste attività:

Determinare l'ambito del danno

Iniziare con i criteri dell'organizzazione sulla fiducia e sulla sicurezza o sull'IA responsabile, insieme alle normative di conformità. Collaborare con i team legali e delle politiche per identificare i danni più importanti per questa applicazione. Il risultato è un elenco prioritario di danni con esempi.

I creativi delle red team spesso trovano danni che non sono stati previsti dalle politiche dell'organizzazione. Più organizzazioni hanno subito danni alla reputazione quando il pubblico ha scoperto risultati problematici dell'IA che non sono stati testati per. È più probabile che un red team creativo rilevi questi problemi prima del rilascio.

Estendere l'elenco tramite test aperti

Integrare l'elenco guidato dai criteri con danni rilevati tramite l'esplorazione creativa. Classificare in ordine di priorità i danni per i test iterativi in base alla gravità e al contesto in cui sono probabilmente visibili. Aggiungere ogni nuovo danno individuato all'elenco master per i successivi round di test.

Eseguire nuovamente il test dopo l'applicazione delle mitigazioni

Testare l'elenco completo dei danni noti con le mitigazioni in atto. È possibile individuare nuovi danni o scoprire che le mitigazioni esistenti non sono sufficienti. Aggiornare l'elenco dei danni ed essere aperti al cambiamento delle priorità in base ai risultati.

Automatizzare su larga scala

Il red teaming manuale è fondamentale ma difficile da ridimensionare. Integrarlo con strumenti di red teaming automatizzati, ovvero framework che automatizzano l'analisi antagonista dei modelli e delle applicazioni di intelligenza artificiale. Ad esempio, il Python Risk Identification Tool (PyRIT) fornisce:

1. Analisi automatizzate: simulano test di penetrazione utilizzando prompt di partenza selezionati in base alla categoria di rischio, con strategie di attacco che aggirano i meccanismi di sicurezza
2. Assegnazione dei punteggi: genera un tasso di successo degli attacchi (ASR) , ovvero la percentuale di attacchi riusciti, offrendo una postura di rischio quantificabile
3. Creazione di report: produce schede di valutazione delle tecniche d'attacco e delle categorie di rischio, che vengono monitorate nel tempo per garantire la conformità e un monitoraggio continuo

Per gli agenti di intelligenza artificiale in particolare, gli strumenti automatizzati possono testare le categorie di rischio difficili da raggiungere solo tramite test manuali delle richieste, incluse azioni vietate, perdite di dati sensibili tramite chiamate di strumenti e conformità alle attività.

Eseguire strumenti automatizzati in un ambiente non di produzione configurato con risorse simili alla produzione. Usarli come complemento ai test manuali: l'automazione presenta rischi su larga scala, mentre gli esperti umani forniscono un'analisi più approfondita.

Risultati del rapporto

Essere strategici con la raccolta dei dati per evitare di sovraccaricare i membri del team rosso durante l'acquisizione di informazioni critiche. Per esercizi più piccoli, un foglio di calcolo condiviso funziona bene. Per i test sistematici su larga scala, gli strumenti automatizzati forniscono metriche e raccolte di risultati strutturate.

Condividere report regolari con gli stakeholder chiave che includono:

• I principali problemi identificati
• Collegamento ai dati non elaborati
• Piano di test per i prossimi round
• Conferma dei membri del Red Team

Chiarire che il red teaming mette in luce e favorisce la comprensione dell'esposizione al rischio, ma non sostituisce una misurazione sistematica e un rigoroso lavoro di mitigazione. I lettori non devono interpretare esempi specifici come una metrica per la diffusione di quel danno.