vincenzo calabro'
  • computer engineer
  • cyber security analyst
  • digital forensics analyst
  • lecturer | speaker | trainer

Article. What i write

Generative Artificial Intelligence (GenAI): Valutazione dei Rischi nella IA Generativa

Pubblicato il 25 febbraio 2025 su ICTSecurityMagazine.com
Questo articolo fa parte di una serie dedicata al tema della IA Generativa, concentrandosi specificatamente sulla comprensione e valutazione dei rischi associati ai sistemi di Generative AI. Il testo esplora un framework analitico per la gestione del rischio dell’AI, attingendo alle metodologie consolidate nel campo della sicurezza informatica e introducendo prospettive innovative per comprendere le sfide uniche poste dai moderni sistemi di intelligenza artificiale.
Vincenzo Calabro' | Generative Artificial Intelligence (GenAI): Valutazione dei Rischi nella IA Generativa

Rischi dei Sistemi di IA Generativa

I sistemi di Generative Artifical Intelligence (GenIA) pongono nuovi tipi di rischi, diversi dai classici rischi informatici, molti dei quali sono consequenziali e poco noti. Nonostante ciò, stiamo assistendo a una forte crescita dell’implementazione e diffusione di nuovi sistemi basati sulla GenAI in qualsiasi ambito sociale e lavorativo. Questa criticità ha, di fatto, accelerato la ricerca e lo sviluppo di modelli efficaci per realizzare il test e la valutazione dei sistemi di AI.
In questo paragrafo proviamo a descrivere un framework per la gestione del rischio dell’AI seguendo il modello del rischio informatico. Nello specifico, sono illustrate alcune potenziali strategie per inquadrare le attività di T&E sulla base di un approccio olistico al rischio dell’AI. È opportuno basare lo sviluppo di questo framework sulle lezioni apprese nei decenni di ricerca per individuare soluzioni analoghe già implementate per la modellazione e la valutazione del rischio informatico. Le valutazioni del rischio informatico sono imperfette e continuano a evolversi, ma, comunque, forniscono vantaggi significativi, tant’è che sono divenute un obbligo normativo nei contesti delle infrastrutture critiche, nel settore finanziario, nell’ambito dei servizi pubblici essenziali, ecc.
La modellazione e la valutazione del rischio per l’AI sono poco comprese sia dal punto di vista tecnico, che legale; esiste, comunque, una domanda urgente sia da parte degli utilizzatori, che dei fornitori[1]. A riguardo, nel luglio del 2024 la Coalition for Secure AI[2] ha fornito un importante contributo a far avanzare le norme del settore relative al miglioramento della sicurezza delle moderne implementazioni dell’AI. Il NIST AI Risk Management Framework (RMF) è un primo esempio di questo apporto. Ad oggi, le metodologie proposte sono ancora in fase di sviluppo, con costi e benefici incerti; pertanto, le valutazioni del rischio dell’AI risultano meno applicate rispetto alle valutazioni del rischio informatico.
La modellazione e la valutazione del rischio sono importanti non solo per effettuare il T&E, ma anche per informare i processi di progettazione, come sta avvenendo nell’ingegneria della sicurezza informatica e nell’emergente ingegneria dell’AI. È importante ricordare che l’ingegneria dell’AI non comprende solo i singoli elementi dell’AI incorporati nei sistemi, ma anche la progettazione complessiva di sistemi resilienti basati sull’AI, insieme ai workflow e alle interazioni umane che consentono le attività operative.
La modellazione del rischio dell’AI può avere un’influenza positiva non solo nella fase di T&E, ma durante l’intero ciclo di vita dell’AI, che va dalle scelte di progettazione alle specifiche fasi di mitigazione del rischio. I punti deboli e le vulnerabilità correlate all’AI hanno caratteristiche uniche (vd. gli esempi nel paragrafo precedente), ma si sovrappongono anche ai rischi informatici. Dopotutto, gli elementi di sistema dell’AI sono componenti software, quindi presentano vulnerabilità non correlate alla loro funzionalità di AI. Tuttavia, le loro caratteristiche uniche e spesso non note, sia all’interno dei modelli, che nelle strutture software che le ospitano, possono renderli particolarmente attraenti per i cybercriminali.

Attributi Funzionali e Qualitativi della IA Generativa

Le valutazioni funzionali e qualitative contribuiscono a garantire che i sistemi svolgano le attività in maniera corretta e affidabile. Tuttavia, correttezza e affidabilità non sono concetti assoluti, ma devono essere inquadrati nel contesto degli obiettivi specifici di un componente o di un sistema, compresi i limiti operativi che devono essere rispettati. Le specifiche comprendono necessariamente sia la funzionalità, ossia ciò che il sistema è destinato a realizzare, sia le qualità del sistema, ovvero il modo in cui il sistema intende funzionare. inclusi gli attributi relativi alla sicurezza e all’affidabilità. Queste peculiarità, o specifiche di sistema, possono riguardare sia il sistema che il suo ruolo nell’operatività, comprese le aspettative relative a fattori di stress da minacce avverse.
I sistemi basati sull’intelligenza artificiale presentano rilevanti sfide tecniche in ognuno dei seguenti aspetti: dalla formulazione delle specifiche alla valutazione dell’accettazione fino a comprendere il monitoraggio operativo. Per esempio, cosa occorre specificare, oltre a inventariare i dati di training e test, per implementare una rete neurale di ML?
In altre parole, è necessario considerare il comportamento di un sistema, o di un workflow associato, in base agli input previsti e imprevisti, dove tali input potrebbero risultare particolarmente critici per il sistema. Tuttavia, è difficile definire come occorre specificare i comportamenti per gli input previsti che non corrispondono esattamente al set di training. Un operatore umano potrebbe notare una somiglianza tra i nuovi input e quelli di training, ma non vi sarebbe alcuna garanzia che ciò corrisponda alle caratteristiche effettive, ovvero ai valori dei parametri salienti, all’interno di una rete neurale addestrata.
Inoltre, dobbiamo esaminare le valutazioni anche dal punto di vista della sicurezza informatica. Un utente malintenzionato informato e motivato potrebbe manipolare deliberatamente gli input operativi, i dati di training e gli altri aspetti del processo di sviluppo del sistema, per creare condizioni che compromettano il corretto funzionamento di un sistema o il suo utilizzo all’interno di un workflow. In entrambi i casi, l’assenza di specifiche modifica la nozione di comportamento “corretto”, complicando ulteriormente lo sviluppo di processi efficaci ed economicamente convenienti per il T&E. Questa criticità suggerisce un’altra comunanza con il rischio informatico: i movimenti laterali, che sono potenziali superfici di attacco accidentali all’implementazione, e potrebbero non rientrare in una specifica di sistema.

Tre dimensioni del Rischio Informatico

L’allineamento tra i requisiti emergenti per un T&E incentrato sull’AI e le tecniche per la valutazione della sicurezza informatica è evidente quando si confronta il NIST’s AI Risk Management Playbook[3] con il NIST Cybersecurity Framework[4], comprendente un’enorme varietà di metodi. Per semplificare, possiamo inquadrare questi metodi nel contesto delle tre dimensioni del rischio informatico.
  • Threat: la minaccia consiste nel potenziale accesso e nelle attività attuate dagli avversari contro il sistema e il suo più ampio ecosistema operativo.
  • Consequence: la conseguenza riguarda l’entità dell’impatto su un’organizzazione o su una mission specifica qualora un attacco a un sistema avesse successo.
  • Vulnerability: la vulnerabilità si riferisce alle debolezze intrinseche nella progettazione e ai difetti nell’implementazione di un sistema.
Sia la minaccia che le conseguenze sono strettamente dipendenti dal contesto operativo di un sistema, sebbene possano essere in gran parte esterne al sistema stesso. La vulnerabilità è una caratteristica del sistema e comprende l’architettura e l’implementazione. La modellazione della superficie di attacco, ovvero le debolezze di un sistema esposte alle azioni avverse, comprende le minacce e le vulnerabilità, perché l’accesso alle vulnerabilità è una conseguenza dell’ambiente operativo. Questo rappresenta un elemento particolarmente utile nell’analisi del rischio informatico.
La modellazione del rischio informatico è diversa dalla tradizionale modellazione probabilistica del rischio attuariale[5]. Ciò è dovuto principalmente alla natura generalmente non stocastica di ciascuna delle tre dimensioni, soprattutto quando le minacce e le azioni sono consequenziali. Per esempio, la minaccia può essere determinata dall’importanza operativa del sistema e del suo workflow, nonché dalle potenziali intenzioni degli avversari e dallo stato delle loro conoscenze. Allo stesso modo, la conseguenza può essere determinata dalle scelte relative al posizionamento di un sistema nei workflow operativi. Gli adeguamenti ai flussi di lavoro e ai ruoli umani è una strategia di mitigazione del rischio nella dimensione delle conseguenze. I rischi possono aumentare quando esistono correlazioni nascoste.
Per quanto riguarda il rischio informatico, questi potrebbero includere elementi comuni con vulnerabilità comuni nascoste nelle catene di approvvigionamento. In merito al rischio legato all’intelligenza artificiale, questi potrebbero includere fonti comuni all’interno di grandi quantità di dati del training. Queste correlazioni rappresentano uno dei motivi per cui alcuni attacchi agli LLM sono trasferibili tra modelli e provider diversi.
I framework elaborati dal CISA[6], dal MITRE[7], dall’OWASP[8] offrono utili database di debolezze e vulnerabilità informatiche e, alcuni di questi, forniscono anche la soluzione di sicurezza. La maggior parte dei criteri di valutazione generalmente utilizzati derivano da questi framework con un approccio bottom-up. Per quanto riguarda i punti deboli e le vulnerabilità a livello di codifica, spesso gli ambienti di sviluppo software, gli strumenti automatizzati e i flussi di lavoro di integrazione/distribuzione continua includono la capacità di analisi, ovvero la possibilità di rilevare la codifica non sicura nel momento stesso in cui gli sviluppatori digitano o compilano i componenti eseguibili.
È importante sottolineare che il rischio informatico rappresenta solo un elemento nella valutazione complessiva dell’idoneità all’uso di un sistema, indipendentemente dal fatto che sia basato o meno sull’intelligenza artificiale. La valutazione dell’accettazione del rischio nei sistemi hardware-software integrati include anche le tradizionali analisi di affidabilità probabilistica che modellano:
  1. i tipi di guasti fisici (intermittenti, transitori, permanenti),
  2. come tali guasti possono innescare errori interni a un sistema,
  3. come gli errori possono propagarsi in vari tipi di guasti a livello di sistema
  4. quali tipi di pericoli o danni (alla sicurezza, alla protezione, al funzionamento efficace) potrebbero causare flussi di lavoro operativi.
Questo approccio all’affidabilità dei sistemi risale al lavoro di John von Neumann degli anni ‘50 sulla sintesi di meccanismi affidabili da componenti inaffidabili[9].
È interessante notare che von Neumann cita la ricerca sulla logica probabilistica che deriva da modelli sviluppati da McCulloch e Pitts, i cui modelli di rete neurale degli anni ‘40 sono precursori dei progetti di rete neurale centrali per l’intelligenza artificiale moderna.

Determinare il rischio dell’IA Generativa

L’inquadramento del rischio legato all’AI può essere considerato analogo al rischio informatico, nonostante le differenze tecniche nei tre aspetti: minaccia, conseguenza e vulnerabilità.
Nei contesti in cui sono presenti utenti malevoli, le minacce all’AI possono includere la manomissione dei dati di training, gli attacchi di patch sugli input, gli attacchi del prompt e di messa a punto, etc.; per quanto riguarda le conseguenze dell’AI possiamo considerare i depistaggi, le ingiustizie e i pregiudizi, gli errori di ragionamento, etc. e, infine, in merito alle vulnerabilità e alle debolezze, come quelle elencate nelle categorie CIG, derivano generalmente dai limiti intrinseci dell’architettura e dell’addestramento delle reti neurali come i modelli derivati statisticamente. Si noti che possono verificarsi diverse conseguenze negative, anche in assenza di avversari, dovute alle particolari debolezze intrinseche dei modelli di reti neurali.
Dal punto di vista della modellazione del rischio tradizionale, vi è anche la difficoltà di scoprire correlazioni inattese tra modelli e piattaforme. Per esempio, possono esserci conseguenze simili dovute a LLM di provenienza diversa che condividono modelli o semplicemente hanno una sovrapposizione sostanziale nei dati di training. Queste correlazioni inaspettate possono ostacolare i tentativi di applicare tecniche come la “diversity by design”[10] come mezzo per migliorare l’affidabilità complessiva del sistema.
Dobbiamo considerare anche l’attributo specifico della resilienza. La resilienza è la capacità di un sistema che ha subito un attacco o un guasto a continuare comunque a funzionare in modo sicuro, anche se eventualmente in modo degradato. Questa caratteristica è talvolta chiamata “graceful degradation” o capacità di “operate through” (operare nonostante) gli attacchi e i guasti. In generale, è estremamente difficile, e spesso irrealizzabile, aggiungere resilienza a un sistema esistente. Questo perché la resilienza è una proprietà emergente conseguente alle decisioni architetturali a livello di sistema. L’obiettivo dell’architettura è ridurre la possibilità che gli errori interni, innescati da difetti interni, le compromissioni o le debolezze intrinseche del machine learning, causino guasti al sistema con conseguenze onerose.
La tradizionale ingegneria “fault-tolerant” è un esempio di progettazione per la resilienza. La resilienza è una proprietà sia per il rischio informatico che per il rischio dell’AI. Per esempio, nell’ambito dell’AI, la resilienza può essere migliorata attraverso scelte progettuali, a livello di sistema e di workflow, in grado di limitare l’esposizione delle superfici di attacco interne agli agenti esterni, come gli input al ML, potenzialmente più vulnerabili. Tali scelte possono includere l’imposizione di un controllo attivo, sia sull’input che sull’output, ai modelli di reti neurali costituenti un sistema.
Un’ulteriore minaccia alla resilienza dell’AI è rappresentata dalla difficoltà, o forse dall’incapacità, di dimenticare i dati di training[11]. Ipotizziamo che si scoprisse che un sottoinsieme di dati di training sia stato utilizzato per inserire una vulnerabilità o una backdoor nel sistema di AI, la rimozione di quel determinato comportamento conosciuto dal sistema di AI rappresenterebbe una grossa criticità perché la soluzione percorribile per eliminarla richiederebbe un nuovo training privo dei dati nocivi. Un problema correlato alla difficolta di dimenticare i dati indesiderati (c.d unwanted unlearning) è rappresentato dal fenomeno opposto denominato oblio catastrofico (c.d. catastrophic forgetting) che si verifica quando dei nuovi dati di training riescono a compromettere involontariamente la qualità delle previsioni basate sui dati di addestramento precedenti[12].
Nonostante si stia assistendo ad una rapida crescita economica dei settori correlati all’AI, tutti gli stakeholder concordano sul fatto che la misurazione e la valutazione del rischio dell’AI è un esercizio complesso e difficile. A riguardo sono stati pubblicati diversi studi di centri di ricerca finalizzati alla catalogazione dei rischi associati al ML e all’AI generativa[13] [14] [15].

Migliorare la gestione del rischio dell’AI

Lo sviluppo di best-practice per un sistema di gestione del rischio per l’AI deve necessariamente tenere conto dei diversi aspetti del rischio e della fattibilità dei vari approcci alla mitigazione. Le valutazioni devono essere eseguite a più livelli di astrazione e di struttura, nonché in più fasi all’interno dei vari cicli di vita della pianificazione, della progettazione architetturale, dello sviluppo dei sistemi, della distribuzione e dell’evoluzione. Questa complessità può rendere difficile il processo di gestione.
Nel livello più alto identifichiamo i workflow, la progettazione dell’interazione umana e i progetti architetturale del sistema. Le scelte effettuate riguardo ciascuno di questi aspetti influenzano direttamente i fattori di rischio: l’attrattività per gli attori malevoli, la natura e l’entità delle conseguenze dei potenziali danneggiamenti e il potenziale di vulnerabilità dovuto alle decisioni in fase di progettazione.
Occorre poi considerare l’architettura e la formazione dei singoli modelli di rete neurale, la messa a punto e il prompt dei modelli generativi e la potenziale esposizione delle superfici di attacco di questi modelli. Nello strato sottostante ci sono, per esempio, gli algoritmi matematici e le singole linee di codice. Infine, quando le superfici di attacco sono esposte all’esterno, possono presentarsi dei rischi associati alle scelte nel firmware o all’hardware di supporto.
Sebbene il NIST abbia compiuto i primi passi verso la codifica di un framework e all’elaborazione di playbook per gestire i rischi dell’AI, resterebbero ancora molte criticità irrisolte nel ciclo di sviluppo degli elementi comuni dell’ingegneria per l’AI (progettazione, implementazione, test e valutazione, evoluzione) che potrebbero evolversi in nuovi standard guidati da metriche convalidate e utilizzabili per un ritorno sugli sforzi effettuati.
Probabilmente, adesso c’è una buona opportunità per sviluppare rapidamente un approccio integrato e completo del ciclo di vita che consenta di associare la progettazione e l’implementazione del sistema ad un processo di T&E di tipo “shift-left” supportato dalla produzione di prove. Ciò contrasta con i recenti metodi per la codifica sicura. Quest’ultima ha fornito un efficiente metodo di analisi e alcuni strumenti efficaci nei moderni linguaggi “memory-safe”. Si tratta di grandi opportunità, ma l’arrivo tardivo della codifica sicura non ha evitato la presenza di codice non sicuro e spesso vulnerabile il cui aggiornamento rappresenta un onere troppo elevato.
È importante notare che la persistente difficoltà di valutare la sicurezza di un insieme di codice ostacola non solo l’adozione di best practice, ma anche la creazione di fiducia per il suo utilizzo. Gli sviluppatori e i valutatori prendono decisioni in base alla loro esperienza, per esempio il fuzzing è correlato a un miglioramento della sicurezza.
In molti casi gli approcci più utili alla valutazione del codice non si riferiscono all’effettivo grado di sicurezza, ma si concentrano sulla portata della conformità con un determinato processo applicativo di varie tecniche di progettazione e sviluppo. In pratica, i risultati effettivi restano difficili da valutare. Di conseguenza, l’aderenza a procedure codificate, come il “secure development lifecycle (SDL)”[16] e la conformità al “Federal Information Security Modernization Act (FISMA)”[17], sono diventate essenziali per la gestione del rischio informatico.
L’adozione può anche essere guidata da motivi non correlati, ma allineati. Per esempio, esistono progetti avanzati relativi a linguaggi e strumenti per il miglioramento della sicurezza, la cui adozione è guidata dall’interesse a migliorare la produttività, senza necessità di una formazione approfondita o una configurazione preliminare.
Un esempio è rappresentato dal linguaggio open source “TypeScript”[18] come alternativa sicura a JavaScript. TypeScript è quasi identico nella sintassi e nelle prestazioni di esecuzione a JavaScript, ma supporta il controllo statico, che può essere eseguito nello stesso istante in cui gli sviluppatori scrivono il codice, è quindi in grado di far emerge un errore prima che arrivi in esecuzione. Quindi, gli sviluppatori possono adottare TypeScript per migliorare la produttività e, contestualmente, ottenere vantaggi in termini di sicurezza.
Date le difficoltà riscontrate nello sviluppo di metriche per molti fattori di rischio dell’AI, è importante sfruttare l’allineamento positivo delle motivazioni progettuali per migliorare la sicurezza dell’AI. È complesso sviluppare misure specifiche per casi generali, quindi è opportuno utilizzare metodi o soluzioni alternative, ovvero best practice derivate dall’esperienza. Le soluzioni alternative possono riguardare: il grado di aderenza alle best practice dell’ingegneria del software, le strategie di formazione, l’implementazione di test e analisi, la scelta di strumenti e così via. È importante sottolineare che queste tecniche ingegneristiche includono lo sviluppo e la valutazione di architetture e di modelli progettuali che consentono la creazione di sistemi più affidabili partendo da elementi meno affidabili.
L’ambito del rischio informatico offre un approccio ibrido di sostituzione e misurazione diretta selettiva tramite i “National Information Assurance Partnership (NIAP) Common Criteria”[19]: i progetti vengono valutati in modo approfondito, ma l’analisi sul codice di livello inferiore non vengono eseguite in modo esaustivo, ma tramite campionamento. Un altro esempio è rappresentato dal progetto “Building Security In Maturity Model (BSIMM)”[20] che include un processo di miglioramento continuo delle sue best practice. Naturalmente, qualsiasi utilizzo di metodi alternativi deve essere accompagnato da una ricerca approfondita, sia per valutarne costantemente la validità, sia per sviluppare metodi specifici.

Criteri di valutazione

Impiego di un AI Red Team

Un primo esempio di metodologia per la valutazione del rischio dell’AI può essere rinvenuto nell’Executive Order 14110 “on the Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence” [21], emanato dal Governo americano nell’ottobre 2023, in cui questo rischio è stato considerato ad alto potenziale e, pertanto, si è deciso di utilizzare il modello del red teaming per attuarne la valutazione.
I red team nascono in ambito militare e vengono utilizzati per simulare attacchi di avversari sempre più evoluti e pericolosi. Nel contesto dei rischi informatici o dei rischi legati all’AI, i red team operano, invece, durante l’intero ciclo di vita del sistema, dalla definizione dell’ambito di utilizzo, alla predisposizione dei requisiti, alla progettazione architetturale, fino allo sviluppo e al deployment del sistema, comprendendo anche la successiva fase evolutiva.
Questa integrazione non è facilmente realizzabile perché le competenze dell’AI non sono ancora sufficientemente mature. Le lezioni apprese in tale ambito suggeriscono che è meglio integrare le competenze dei team di sviluppo in tema di sicurezza, piuttosto che imporre l’attenzione ai problemi di sicurezza.
Ciò suggerisce la presenza di un gruppo di esperti multidisciplinari in grado di individuare le potenziali debolezze e vulnerabilità e misurare lo stato di avanzamento delle misure di contenimento, delle azioni di mitigazioni, degli strumenti utilizzati e delle best practice associate. Questi esperti dovrebbero essere inseriti in team agili in modo da poter influenzare le scelte operative e le decisioni progettuali. Il loro obiettivo si concretizza nell’ottimizzazione dei benefici derivanti dall’uso dell’AI e nella diminuzione dei rischi.
I red team dell’AI devono affrontare, oltre ai rischi e alle minacce poste dagli avversari, anche i rischi associati alle debolezze specifiche dell’AI, comprese le categorie di debolezze e vulnerabilità relative alla confidenzialità, all’integrità e alla governance. Il successo dipenderà dalla piena consapevolezza di tutte le dimensioni del rischio e dall’accesso a strumenti e capacità adeguati a supportare assesment efficaci ed economicamente convenienti.
Allo stato attuale, non esiste ancora una prassi standardizzata per i red team dell’AI; infatti, non sono stati definiti e resi operativi gli strumenti, la formazione e le attività da espletare, perché è un settore in rapida evoluzione tecnologia. Il questo senso, l’AI Risk Management Framework del NIST rappresenta un primo passo importante nel definire questa dimensionalità.

Metodi per la valutazione del rischio dell’AI

L’approccio del red teaming richiede la disponibilità e l’uso di un’ampia gamma di metodologie e tecniche; pertanto, è possibile seguire dei metodi alternativi in grado di effettuare la valutazione basandosi sull’acquisizione delle conformità dei processi e/o della valutazione dei prodotti, come avviene nelle classiche valutazioni di sicurezza e qualità.
A riguardo, possono essere presentate diversi tipi di evidenze che vanno dalla trasparenza, concretizzabile attraverso una serie di schede tecniche dettagliate, all’acquisizione di autocertificazioni sulla qualità dei prodotti fornite dai fornitori, nei limiti delle considerazioni legali relative alla proprietà intellettuale e alla responsabilità sul prodotto. Tutto ciò si potrebbe estende alla gestione della supply chain per sistemi integrati, in cui potrebbero esserci vari livelli di trasparenza. Nell’ambito della sicurezza informatica, la responsabilità è un tema in continua evoluzione e, possiamo aspettarci, che lo sarà anche per l’AI.
Analizziamo i due metodi:
  • La conformità dei processi, per il rischio legato all’AI, può riguardare l’aderenza alle best practice nella progettazione dell’AI. Queste conformità possono spaziare dalle valutazioni effettuate a livello di progettazione, per esempio su come i modelli di AI vengono incapsulati all’interno di un’architettura di sistema, alla conformità con le best practice per la gestione e la formazione dei dati. Inoltre, possono includere l’uso di strumenti per il monitoraggio dei comportamenti sia di sistema, che degli operatori. Si evidenzia che i metodi incentrati sui processi del rischio informatico, come il NIST Cybersecurity Framework[22], possono interessare centinaia di criteri che, a loro volta, possono essere applicati nello sviluppo e nella valutazione di un sistema. I progettisti e i valutatori devono selezionare e stabilire le priorità tra i numerosi criteri per sviluppare una strategia che garantisca l’allineamento con l’obiettivo del progetto. Si presuppone che, con la maturazione delle tecniche per lo sviluppo delle capacità dell’AI, emergeranno processi proattivi che tenderanno a sfruttare la capacità operativa basata sull’intelligenza artificiale per ridurre al minimo le principali variabili del rischio. In questo contesto, è solitamente più vantaggioso utilizzare i prototipi di conformità già convalidi, anziché effettuare l’analisi e i test specifici per un processo. Però questa strategia può essere rischiosa nel contesto dell’intelligenza artificiale. Per esempio, le nozioni di copertura dei test e i criteri di somiglianza degli input, molto utilizzati dagli sviluppatori di software, non si trasferiscono bene ai modelli basati su rete neurale.
  • La valutazione del prodotto può porre notevoli difficoltà tecniche, soprattutto con l’aumento della scalabilità, della complessità e dell’interconnessione. Inoltre, può creare problemi legali al tema della proprietà intellettuale e della responsabilità. Nell’ambito della sicurezza informatica, alcune caratteristiche dei prodotti stanno diventando facilmente accessibili per realizzare una valutazione diretta. Ciò è una conseguenza della scelta di aumentare la trasparenza, come è indicato nelle metodologie software bills of materials (SBOM) e nelle architetture Zero Trust (ZT).
Paradossalmente, anche la totale trasparenza di un modello di AI con miliardi di parametri potrebbe fornire poche informazioni. Ciò è correlato alla fusione del codice e dei dati nei moderni modelli di intelligenza artificiale. Esiste, tuttavia, una importante ricerca in grado di estrarre da un LLM le mappe associative, esaminando i pattern di attivazione dei neuroni. Al contrario, i modelli di intelligenza artificiale black boxed potrebbero rivelare più di quanto i loro creatori abbiano potuto elaborare in merito alla loro progettazione e realizzazione. La riservatezza percepita dei dati di training può essere violata tramite attacchi di inversione del modello per ML e output memorizzati del LLM.
In sintesi, la valutazione diretta dei modelli di reti neurali rimane un traguardo importante e sfidante. Ciò fornisce un ulteriore impulso all’espansione dell’ingegneria dell’AI e all’applicazione di principi specifici per lo sviluppo e la valutazione dei sistemi basati sull’AI e dei work-flow che li utilizzano.

Criterio basato sugli incentivi

I citati criteri di valutazione, incentrati sui processi e sui prodotti, possono apparire una criticità per chi cerca di massimizzare i benefici dell’applicazione dell’AI, operando in maniera efficiente ed efficace. In tal senso, le scelte tecniche effettuate in merito alla progettazione e allo sviluppo di un sistema basato sull’intelligenza artificiale devono necessariamente controbilanciare le opzioni connesse alle circostanze operative e di contesto. Una valida alternativa è rappresentata dal criterio basato sugli incentivi. In effetti, questo approccio offre un maggiore grado di libertà e, contestualmente, consente una riduzione del rischio attraverso adeguamenti ai workflow e ai sistemi progettati.
Gli incentivi possono essere sia positivi che negativi, per esempio potrebbero essere offerti incentivi positivi nei contratti di implementazione nel caso in cui le asserzioni relative ai rischi dell’AI siano supportate da evidenze o da dichiarazioni di responsabilità. Le evidenze potrebbero riguardare un’ampia gamma di scelte progettuali che spaziano dall’architettura dei sistemi e dei workflow, alla predisposizione del modello e delle misure di protezione.
Questo approccio, basato sui principi emergenti dell’ingegneria dell’intelligenza artificiale, consente di realizzare sistemi affidabili e in grado di evolversi in determinati contesti, anche mentre operano per far progredire lo sviluppo di tecniche più generali.
Di seguito sono indicate le principali metodologie di valutazione dei rischi dell’AI:
  • Stabilire la priorità dei rischi. Questo metodo consente di identificare e di priorizzare i potenziali punti deboli e le vulnerabilità di un sistema sulla base di uno specifico obiettivo. Questo processo andrebbe eseguito prima possibile, teoricamente prima che sia avviata la progettazione e la realizzazione dei sistemi.
  • Identificare gli obiettivi correlati al rischio. Questa metodologia si concentra sull’identificazione degli obiettivi di sistema, insieme alle relative misure a livello di sistema, esclusivamente connessi ai rischi ritenuti rilevanti.
  • Mettere insieme le misure tecniche e di mitigazione. Questa tecnica permette di identificare le misure tecniche e le potenziali azioni di mitigazione, con le relative procedure e gli strumenti associati, comuni per gli stessi rischi. Inoltre, è in grado di tenere traccia dello sviluppo delle capacità tecniche emergenti.
  • Adeguare le scelte operative e progettuali di alto livello. Questa procedura individua le correzioni alle scelte operative e progettuali di alto livello per i rischi con priorità più elevata che potrebbero consentire probabili riduzioni del rischio. Questa procedura può riguardare l’adeguamento dei workflow operativi e limitare le conseguenze potenziali, per esempio elevando il ruolo umano oppure riducendo la superficie di attacco. Inoltre, potrebbe valutare anche l’adattamento dell’architettura di sistema per consentire una riduzione delle superfici di attacco interne e limitare l’impatto delle vulnerabilità connesse alla capacità del ML.
  • Identificare i metodi per valutare i punti deboli e le vulnerabilità. Quando non è possibile individuare misure dirette, devono essere impiegate soluzioni alternative. Questi metodi possono spaziare dall’uso di checklist, in stile NIST-playbook, all’adozione di best practices, come le“DevSecOps for IA”[23]. Inoltre, potrebbero includere valutazioni a livello di specifiche o di progetto analoghi ai “Common Criteria”[24].
  • Ricerca di attributi allineati. Questo metodo di basa sulla ricerca di consensi positivi per la mitigazione del rischio attraverso attributi, potenzialmente non correlati, che offrono misure migliorative. Per esempio, la produttività o l’adozione di altri tipi di incentivi possono guidare l’adozione di procedure favorevoli alla riduzione di determinate categorie di rischi. Nel contesto dei rischi legati all’intelligenza artificiale, questo approccio potrebbe includere l’uso dei modelli progettuali per la resilienza delle architetture come metodo per la localizzazione di eventuali effetti negativi delle debolezze del machine learning.
Nel prossimo articolo di questa serie, approfondiranno le potenziali strategie di mitigazione, concentrandosi sull’audit dei Bias e sulle tecniche di Machine Unlearning. Per un’analisi più dettagliata, invitiamo i lettori a scaricare il white paper “Generative Artificial Intelligence: punti di forza, rischi e contromisure”, che offre una panoramica esaustiva sulle sfide e le soluzioni nel campo della Generative AI.

Note bibliografiche

[1] AI in 2024: McKinsey Report Reveals Value Generation & AI Adoption Spike: https://www.switchsoftware.io/post/ai-in-2024-gen-ai-rise-and-business-impact, 2024
[2] Making AI Systems Secure for All: https://www.coalitionforsecureai.org/
[3] NIST’s AI risk management playbook: https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook
[4] NIST Cybersecurity Framework: https://www.nist.gov/cyberframework
[5]The Roles of the Actuary in the Selection & Application of Actuarial Models: https://www.actuary.org/sites/default/files/2023-02/01_Models2.9.23.pdf
[6] Cybersecurity & Infrastructure Security Agency: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
[8] Open Web Application Security Project: https://owasp.org/www-community/attacks/
[9] J. von Newmann, Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components: https://web.mit.edu/6.454/www/papers/pierce_1952.pdf, California Institute of Technology, 1952
[10] AA.VV., Systems of Systems Engineering: Basic Concepts, Model-Based Techniques, and Research Directions: https://dl.acm.org/doi/abs/10.1145/2794381, 2015
[11] Snyder, Machine forgetting: How difficult it is to get AI to forget: https://www.axios.com/2024/01/12/ai-forget-unlearn-data-privacy, 2024
[12] AA.VV., An Empirical Study of Catastrophic Forgetting in Large Language Models During Continual Fine-tuning: https://arxiv.org/abs/2308.08747, School of Engineering, Westlake University, 2024
[13] T. Hagendorff, Deception abilities emerged in large language models: https://www.pnas.org/doi/10.1073/pnas.2317967121, 2024
[14] AA.VV., AI-Related Risks Test the Limits of Organizational Risk Management: https://sloanreview.mit.edu/article/ai-related-risks-test-the-limits-of-organizational-risk-management/, 2024
[15] AA.VV., Artificial Intelligence Index Report 2024: https://aiindex.stanford.edu/wp-content/uploads/2024/05/HAI_AI-Index-Report-2024.pdf, Stanford University, 2024
[16] Microsoft Security Development Lifecycle (SDL): https://www.microsoft.com/en-us/securityengineering/sdl
[17] Federal Information Security Modernization Act (FISMA): https://security.cms.gov/learn/federal-information-security-modernization-act-fisma
[19] National Information Assurance Partnership (NIAP) Common Criteria: https://www.niap-ccevs.org/
[20] Building Security In Maturity Model (BSIMM) project: https://www.synopsys.com/glossary/what-is-bsimm.html
[21] Executive Order on the Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence del 30/10/2023: https://www.whitehouse.gov/briefing-room/presidential-actions/2023/10/30/executive-order-on-the-safe-secure-and-trustworthy-development-and-use-of-artificial-intelligence/