Questo articolo fa parte di una serie di approfondimenti dedicati all’evoluzione e alle sfide della GenAI. In questa puntata, esploreremo i meccanismi di sicurezza, protezione e gestione dei rischi nei sistemi basati sulla GenAI, offrendo una prospettiva tecnica e strategica sulle attuali complessità tecnologiche.

Tassonomia dei Rischi nella GenAI

In questo paragrafo si analizza il tema della sicurezza e della protezione nel contesto dell’AI, applicata allo sviluppo di sistemi critici, attraverso l’esame di specifici esempi di fragilità e vulnerabilità dell’AI generativa. I rischi a cui è esposta la GenAI sono organizzati seguendo una tassonomia analoga agli attributi di confidenzialità, integrità e disponibilità (CIA) adoperati nel contesto dei rischi informatici:

• rischi di confidenzialità: si palesano nel caso in cui i risultati di un modello di AI rivelano dati di input che i progettisti avevano intenzione di mantenere riservati.
• rischi di integrità: si presentano nel caso in cui i risultati di un modello di AI sono errati, involontariamente o tramite manipolazione deliberata da parte degli avversari.
• rischi di governance: si rivelano nel caso in cui i risultati di un modello di AI, o l’utilizzo di tale modello in un sistema, possono avere impatti negativi nel contesto delle applicazioni, spesso anche quando i risultati del modello sono corretti rispetto alla formazione.

Partiamo dall’assunto che la gestione del rischio per l’AI, compresa la modellazione e la valutazione, è distinguibile in tre livelli:

1. le capacità del “core AI” dei singoli modelli di reti neurali,
2. le scelte effettuate su come tali capacità siano incorporate nell’ingegneria dei sistemi basati sull’AI,
3. come tali sistemi siano integrati in workflow operativi incentrati sulle applicazioni.

Questi workflow possono includere sia applicazioni autonome, che applicazioni abilitate a interagire con soggetti umani. Questa ampia flessibilità è importante perché l’intelligenza artificiale generativa può portare non solo aumenti significativi della produttività e dell’efficacia della mission all’interno di processi organizzativi consolidati, ma può anche generare nuove capacità basate sulla reingegnerizzazione delle attività sul posto di lavoro incentrate sulla mission e sull’operatività.

Considerazioni sulla GenAI

La natura stocastica dei modelli di GenAI, combinata con una quasi totale assenza di trasparenza rispetto all’interrogazione e all’analisi, rende complessa la loro descrizione, il testing, l’analisi e il monitoraggio. Ciò che si percepisce come somigliante tra i vari input di un modello, non corrisponde necessariamente al modo in cui risponde il modello.

Durante l’addestramento, le differenziazioni possono essere effettuate in base a dettagli che normalmente consideriamo accidentali. Un esempio noto è quello in cui il lupo è distinto dagli altri cani non per la morfologia, ma perché c’è neve sullo sfondo, come rivelato dalle mappe di salienza[1]. Infatti, la metrologia[2] della GenAI è appena agli inizi.

Un altro esempio rappresentativo dell’aleatorietà del ML è quello che riguarda l’autonomia dei veicoli. In questo caso, la combinazione tra la scarsa capacità di valutazione dei test e le pressanti direttive aziendali ha portato alla produzione di intere flotte di autoveicoli a guida autonoma e al successivo ritiro dal mercato a causa di comportamenti inaspettati. Inoltre, sono stati individuati diversi bias negli algoritmi predittivi applicati alla stipula di contratti di credito, oppure al reclutamento del personale e all’elaborazione delle richieste di rimborso sanitario. Questi sono i motivi per cui è facilmente realizzabile l’”adversarial machine learning”[3].

Analizziamo i principali fattori che caratterizzano i sistemi basati sul GenAI.

Dal punto di vista della mission

Molto spesso i modelli di intelligenza artificiale generativi, addestrati sui dati, sono inclusi all’interno di “mission system”[4] sottoforma di componenti o servizi subordinati e, come già visto, spesso questi sistemi rappresentano dei componenti di workflow operativi che supportano un’applicazione all’interno di un determinato processo. Per tanto, affinché si possano misurare e valutare, occorre comprendere tutti e tre i livelli: componente, sistema e workflow.

Per esempio, i problemi dei “bias” (preconcetto/pregiudizio/parzialità) possono essere il risultato della mancata corrispondenza tra i dati utilizzati per addestrare il modello con i dati reali di input. Nel contesto del “Test and Evaluation (T&E)” significa che è fondamentale caratterizzare e valutare i tre livelli di classificazione indicati in precedenza:

1. le caratteristiche delle capacità di intelligenza artificiale integrate,
2. il modo in cui tali capacità vengono utilizzate nei sistemi basati sull’intelligenza artificiale,
3. il modo in cui tali sistemi sono destinati a essere integrati nei workflow operativi.

L’UK National Cyber Center ha pubblicato le “Guidelines for secure AI system development”[5], a cui ha aderito anche l’Agenzia per la cybersicurezza nazionale, che si concentrano sulla sicurezza, intesa come resilienza, privacy, correttezza ed affidabilità, della progettazione, dello sviluppo, della distribuzione, del funzionamento e della manutenzione dei sistemi di AI.

Fusione di Codice e Dati: Nuove Vulnerabilità

La tecnologia su cui si basa l’attuale AI non è come quella del software tradizionale. La tipica separazione tra codice e dati, fondamentale per valutare la sicurezza del software, è assente nei modelli di intelligenza artificiale e, al contrario, tutti i dati elaborati possono fungere da istruzioni, analogamente al “code injection” nella sicurezza del software.

Le centinaia di miliardi di parametri che controllano il comportamento dei modelli di intelligenza artificiale spesso sono derivate dai dati di addestramento, ma in una forma generalmente opaca all’analisi. Per esempio, la pratica che introduce questa separazione per realizzare l’allineamento degli LLM, si è dimostrata inadeguata in presenza di avversari. Attualmente, i sistemi di intelligenza artificiale possono essere controllati da input malevoli. Infatti, le barriere di sicurezza di un LLM possono essere “jailbroken” dopo solo 10 esempi di tuning.

Gli sviluppatori non hanno ancora adottato una modalità rigorosa per correggere queste vulnerabilità, e tanto meno per identificarle in maniera affidabile; quindi, è fondamentale misurare l’efficacia delle misure di sicurezza “best-effort” a livello di sistema e a livello operativo. La prassi dell’ingegneria dell’intelligenza artificiale offre stime di progettazione per sistemi e workflow per mitigare queste criticità.

Questa attività è simile a quella utilizzata nell’ingegneria dei sistemi altamente affidabili, che sono inevitabilmente costruiti da componenti meno affidabili, ma occorre tenere presente che i modelli di ingegneria incentrati sull’intelligenza artificiale sono molto diversi dalle tradizionali metodologie di progettazione fault-tolerant.

Infatti, gran parte della progettazione fault-tolerant si basa su ipotesi di indipendenza statistica rispetto ai guasti (p.e. transitori, intermittenti, permanenti) e, in genere, si impiega la ridondanza degli elementi del sistema, per diminuire le probabilità di guasto, e il controllo interno, per rilevare gli errori prima che diventino guasti, al fine di ridurre le conseguenze o il pericolo.

Interazione Uomo-Sistema: Rischi e Percezioni

Attualmente molti processi coinvolgono i sistemi basati sull’intelligenza artificiale esclusivamente per svolgere ruoli di supporto o di consulenza nei confronti degli operatori del processo stesso.

Per esempio, da molto tempo i radiologi, i patologi, i gruppi antifrode e gli analisti delle immagini, fruiscono dell’ausilio dell’intelligenza artificiale. Poi, vi sono altri casi in cui i sistemi basati sull’intelligenza artificiale operano in maniera semi-autonoma (per esempio, nello screening delle candidature ad una posizione lavorativa). Questi modelli che comprendo l’interazione umana possono introdurre rischi specifici (per esempio, il sistema di screening potrebbe essere più autonomo nella realizzazione delle esclusioni e rimanere consultivo per le accettazioni e, di conseguenza, eliminare candidature con ottimi requisiti).

In altre parole, esiste uno spettro di gradi di controllo condiviso e, pertanto, la natura di tale condivisione deve essere essa stessa un obiettivo del processo di valutazione del rischio. A riguardo, una soluzione potrebbe considerare il coinvolgimento degli esseri umani nel processo di valutazione delle proposte di esclusione e di accettazione, nonché nell’impiego di uno schema di monitoraggio, per migliorare la responsabilità e fornire un riscontro al sistema e ai progettisti.

Un altro rischio connesso all’interazione uomo-sistema, legato a una debolezza umana piuttosto che a una debolezza del sistema, consiste nella tendenza ad antropomorfizzarne l’utilizzo sulla base dell’uso del linguaggio e della voce umana. Un noto esempio è il programma Eliza [6] scritto negli anni ‘60 al MIT da Joseph Weizenbaum. Eliza “conversava” con il suo utente umano attraverso la digitazione di un testo. Le 10 pagine di codice di Eliza facevano principalmente tre cose: rispondere in modo strutturato ad alcune parole “trigger”, riflettere occasionalmente sugli input che gli venivano passati e invertire i pronomi.

Sembrava, quindi, che Eliza capisse e, di conseguenza, le persone trascorrevano ore a conversare con lei nonostante il suo funzionamento fosse estremamente semplice. Esempi più recenti sono rappresentati da Siri, Alexa e Gemini, che, nonostante i nomi umani e le voci amichevoli, sono principalmente gateway di pattern-matching per la ricerca sul Web. Tuttavia, gli attribuiamo proprietà relative alla personalità e pronomi di genere per renderli più human friendly. Il punto è che gli esseri umani tendono a conferire ai testi significati e profondità, mentre i testi LLM sono una sequenza, statisticamente derivata, di previsioni delle parole successive.

Superfici di Attacco e Innovazione nella GenAI

Un’altra serie di minacce che mina lo sviluppo dei sistemi di AI sicuri e protetti è rappresentata del ricco e diversificato set di superfici di attacco associate agli attuali modelli di AI. L’esposizione di queste superfici di attacco è determinata, da un lato, dalle scelte ingegneristiche dell’AI e, dall’altra, dalla realizzazione di nuove interazioni Uomo-Macchina e, più in generale, dalla progettazione dei workflow operativi. In questo contesto, è opportuno definire l’ingegneria dell’AI non solo come l’ambito di progettazione, sviluppo, test e valutazione dei componenti di AI, ma anche dei sistemi che li contengono e dei workflow che incorporano le capacità dell’AI nelle principali attività.

A seconda del tipo di applicazione a cui sono adibiti i sistemi basati sull’intelligenza artificiale, e di come vengono progettati, le azioni avversarie possono manifestarsi sottoforma di input diretti da utenti malevoli, oppure sotto forma di “training cases” e “retrieval augmentations” (per esempio, sottoforma di file caricati, di siti web recuperati o di risposte da un plug-in o da uno strumento subordinato come la ricerca web).

Possono essere forniti anche come parte di una query, sottoforma di dati non destinati ad essere interpretati come istruzioni (per esempio un documento fornito dall’utente per essere riassunto o elaborato). Nei fatti, queste superfici di attacco sono molto simili ad altre tipologie di minacce informatiche, solo che nel contesto dell’intelligenza artificiale è più difficile prevedere l’impatto di piccoli cambiamenti negli input nei confronti dei risultati, attraverso una qualsiasi di queste superfici di attacco. Infatti, c’è un’asimmetria informatica, adattata alle peculiarità dei modelli a rete neurale, in cui i difensori cercano una prevedibilità completa nell’intero dominio di input, mentre l’avversario necessita di prevedibilità solo per piccoli segmenti.

Fortunatamente, la tecnica dell’adversarial ML consente di realizzare una specifica prevedibilità con più facilità e ciò conferisce un vantaggio per gli aggressori. Paradossalmente, questi attacchi sono ottenuti tramite l’utilizzo di altri modelli ML costruiti allo scopo di prevederli.

Inoltre, esistono diverse opportunità di attacco alla supply chain in grado di sfruttare la sensibilità dei risultati di training nelle scelte effettuate nella preferenza dei dati utilizzati per il processo di training. La robustezza di un modello, e delle relative misure di sicurezza, deve essere commisurata in relazione a ciascuno delle diverse tipologie di attacco. A riguardo, ognuno di questi tipi di attacco richiede nuovi metodi di analisi, di testing e una metrica specifica.

È importante che sia raggiunto l’obiettivo di progettare schemi di valutazione ampiamente onnicomprensivi, anche in relazione allo stato dell’arte (in rapida evoluzione) e di ciò che è noto sui diversi metodi di attacco. È probabile che la completezza di questo traguardo rimanga inafferrabile, poiché continuano a svelarsi nuove vulnerabilità, debolezze e vettori di attacco.

Velocità dell’Innovazione e Sfide di Valutazione

Gli obiettivi di un progetto IT spesso si trovano in uno stato di rapida evoluzione, in parte guidata dai cambiamenti dell’ambiente operativo/strategico e dallo sviluppo di nuove tecnologie, tra cui gli algoritmi di intelligenza artificiale e le relative infrastrutture informatiche. Questa continua evoluzione crea ulteriori minacce sotto forma di pressione continua nell’effettuare l’aggiornamento degli algoritmi, delle infrastrutture informatiche, dell’immissione dei dati di training e degli altri elementi relativi alle potenzialità dell’intelligenza artificiale. Molto spesso, l’evoluzione accelerata anticipa le fasi di testing e valutazione, perché gli stakeholder vengono coinvolti nella fase iniziale della sequenza temporale del processo (c.d. “move to the left”) e in modo continuato.

Ciò consente, da un lato, di selezionare i progetti di sistema per migliorare la testabilità e, dall’altro, di configurare processi e strumenti in grado di produrre non solo modelli distribuibili, ma anche dataset di prova destinati a supportare un processo di testing e valutazione continuo e affidabile. È risaputo che un coinvolgimento anticipato delle attività di T&E nel ciclo di vita del sistema comporta notevoli benefici e ricadute in termini di efficienza e sicurezza.

Questo approfondimento ha esplorato le complesse sfide di sicurezza e gestione dei rischi nei sistemi GenAI, evidenziando la necessità di approcci dinamici e multidimensionali. Nel prossimo articolo, approfondiremo le prospettive future della GenAI, analizzando le traiettorie di sviluppo e le potenziali soluzioni alle criticità emerse. Per una comprensione più dettagliata, invitiamo i lettori a scaricare il nostro white paper dedicato alle strategie di sicurezza in relazione dal titolo “Generative Artificial Intelligence: Punti di forza, rischi e contromisure”.

Note bibliografiche

[1]Le mappe di salienza sono stabilite sulla base di proprietà visive come le discontinuità dell’immagine. Così, per esempio, le discontinuità cromatiche, un oggetto in movimento su uno sfondo statico o le zone più luminose spiccano e catturano l’attenzione.

[2] La metrologia è la scienza che si occupa della misurazione e delle sue applicazioni.

[3] L’Adversarial machine learning (Apprendimento automatico antagonistico) è una serie di tecniche volte a compromettere il corretto funzionamento di un sistema informatico che faccia uso di algoritmi di apprendimento automatico, tramite la costruzione di input speciali in grado di ingannare tali algoritmi: più nello specifico, lo scopo di tali tecniche è quello di causare la classificazione errata in uno di questi algoritmi.

[4] Per mission system si intende uno strumento sviluppato per, o utilizzati in, programmi e progetti per un obiettivo ovvero strutture tecniche critiche specificamente sviluppate o significativamente modificate per sistemi specifici.

[5] Guidelines for secure AI system development, https://www.ncsc.gov.uk/files/Guidelines-for-secure-AI-system-development.pdf, NCSC, 2023

[6] J. Weizenbaum, ELIZA – a computer program for the study of natural language communication between man and machine, https://dl.acm.org/doi/10.1145/365153.365168, MIT, 1966

Profilo Autore

È laureato in Ingegneria Informatica ed in Sicurezza Informatica presso le Università di Roma La Sapienza e di Milano. Ha indirizzato la sua formazione nei settori della Cyber Security e Digital Forensics ottenendo i diplomi di perfezionamento in Data Protection e Data Governance; Criminalità Informatica e Investigazioni Digitali e Big Data, Artificial Intelligence.

Ha, altresì, conseguito l’Advanced Cybersecurity Graduate Certificate alla School of Engineering della Stanford University; Professional Certificates in Information Security; Incident Response Process; Digital Forensics e Cybersecurity Engineering and Software Assurance presso il Software Engineering Institute della Carnegie Mellon University.

Dal 1992 è nei ruoli del Ministero dell’Interno ove ricopre lincarico di Funzionario alla Sicurezza CIS. In tale veste contribuisce alla valutazione dei rischi cyber, all’implementazione delle misure di sicurezza e la risoluzione di incidenti informatici. Inoltre, offre consulenza tecnica nel campo della Digital Forensics per l’Autorità giudiziaria, la Polizia giudiziaria e gli Studi legali.

Dal 2017 è Professore a contratto di Tecnologie per la Sicurezza Informatica presso alcune Università ove sviluppa le tematiche di Attack and Defense Strategies quali il penetration testing, la risk analysis, l’information security assessment, l’incident response e la digital forensics. Infine, è Autore di alcuni articoli e saggi sui temi della Sicurezza Informatica e
dell’Informatica Giuridica consultabili su https://www.vincenzocalabro.it

https://www.ictsecuritymagazine.com/articoli/sicurezza-genai/