Identificare i potenziali danni
La prima fase di un processo di intelligenza artificiale generativa responsabile consiste nell'identificare i potenziali danni che potrebbero influire sulla soluzione pianificata. Questa fase prevede quattro passaggi, come illustrato di seguito:
- Identificare i potenziali danni
- Classificare in ordine di priorità i danni identificati
- Testare e verificare i danni classificati in ordine di priorità
- Documentare e condividere i danni verificati
1: Identificare potenziali danni
I potenziali danni rilevanti per la soluzione di intelligenza artificiale generativa dipendono da più fattori, tra cui i servizi e i modelli specifici usati per generare l'output, nonché i dati di messa a punto o di messa a terra usati per personalizzare gli output. Alcuni tipi comuni di potenziali danni in una soluzione di intelligenza artificiale generativa includono:
- Generazione di contenuti offensivi, peggiorativi o discriminatori.
- Generare contenuti che contengono inesattezze fattuali.
- Generazione di contenuti che incoraggiano o supportano comportamenti o pratiche illegali o non etiche.
Per comprendere appieno le limitazioni e il comportamento noto dei servizi e dei modelli della soluzione, consultare la documentazione disponibile. Ad esempio, il Servizio OpenAI di Azure include una nota sulla trasparenza, che è possibile usare per comprendere considerazioni specifiche relative al servizio e ai modelli che include. Inoltre, i singoli sviluppatori di modelli possono fornire la documentazione, ad esempio la scheda di sistema OpenAI per il modello GPT-4.
Prendere in considerazione la possibilità di esaminare le indicazioni contenute nella Guida alla valutazione dell'impatto dell’intelligenza artificiale di Microsoft e di usare il modello di valutazione dell'impatto dell’intelligenza artificiale responsabile associato per documentare i potenziali danni.
2: Classificare i danni in ordine di priorità
Per ogni potenziale danno individuato, valutare la probabilità che si verifichi e il livello di impatto che ne deriverebbe, se del caso. Usare quindi queste informazioni per classificare i danni in ordine di priorità, dando la precedenza a quelli più probabili e impattanti. Questa definizione delle priorità consentirà di concentrarsi sulla ricerca e sulla mitigazione dei rischi più dannosi per la soluzione.
La definizione delle priorità deve tenere conto dell'uso previsto della soluzione e del potenziale di abuso e può essere soggettiva. Si supponga, ad esempio, di sviluppare un copilota di cucina intelligente che fornisca assistenza per le ricette a chef e cuochi amatoriali. I potenziali danni possono includere:
- La soluzione fornisce tempi di cottura imprecisi, generando cibi poco cotti che possono causare malattie.
- Quando richiesto, la soluzione fornisce una ricetta per un veleno letale che può essere prodotto con ingredienti di uso quotidiano.
Sebbene nessuno dei due risultati sia auspicabile, è possibile decidere che il potenziale della soluzione di supportare la creazione di un veleno letale abbia un impatto maggiore rispetto a quello di creare cibo poco cotto. Tuttavia, dato lo scenario di utilizzo principale della soluzione, è anche possibile supporre che la frequenza con cui vengono suggeriti tempi di cottura imprecisi sia molto più alta del numero di utenti che chiedono esplicitamente una ricetta velenosa. La determinazione della priorità finale è oggetto di discussione per il team di sviluppo, che può coinvolgere esperti di normative o legali al fine di stabilire una priorità sufficientemente adeguata.
3: Testare e verificare la presenza di danni
Una volta definito l'elenco delle priorità, è possibile testare la soluzione per controllare che i danni si verifichino e, in caso affermativo, in quali condizioni. Il test potrebbe anche rivelare la presenza di danni non identificati in precedenza che è possibile aggiungere all'elenco.
Un approccio comune per verificare la presenza di potenziali danni o vulnerabilità in una soluzione software è l'utilizzo di test "red team", in cui un team di tester esamina deliberatamente la soluzione alla ricerca di punti deboli e tenta di produrre risultati dannosi. Un esempio di test per la soluzione di copilota della cucina intelligente discussa in precedenza potrebbe essere la richiesta di ricette a base di veleno o di ricette veloci che includono ingredienti che devono essere ben cotti. I successi del red team devono essere documentati e esaminati per consentire di determinare la probabilità realistica che si verifichino risultati dannosi quando viene utilizzata la soluzione.
Nota
IlRed teaming è una strategia spesso usata per individuare vulnerabilità in materia di sicurezza o altri punti deboli che possono compromettere l'integrità di una soluzione software. Estendendo questo approccio alla ricerca di contenuti dannosi da parte dell'intelligenza artificiale generativa, è possibile implementare un processo di intelligenza artificiale responsabile che si basa sulle procedure di cybersecurity esistenti e le integra.
Per altre informazioni sul Red Teaming per le soluzioni di intelligenza artificiale generativa, vedere Introduzione al Red Teaming dei modelli linguistici di grandi dimensioni (LLM) nella documentazione del Servizio OpenAI di Azure.
4: Documentare e condividere i dettagli dei danni
Una volta raccolte le prove a supporto della presenza di potenziali danni nella soluzione, documentare i dettagli e condividerli con le parti interessate. L'elenco delle priorità relative ai danni deve essere mantenuto e integrato nel caso in cui vengano identificati nuovi danni.