Lo scopo del presente articolo è suggerire un approccio semplice e funzionale alla catalogazione dei rischi derivanti dall’implementazione dell’intelligenza artificiale all’interno delle organizzazioni.
Concetti preliminari
Negli ultimi anni i rischi cibernetici si sono evoluti a tal punto da divenire un vero e proprio elemento di preoccupazione e interesse a livello internazionale. La necessità di catalogarli secondo una specifica tassonomia è dipesa proprio da tale evoluzione che, nel tempo, ha portato alcune tipologie di attacco a sparire ed altre ad affermarsi. Sono state create categorie, sotto-categorie e specializzazioni per cercare di raccogliere le minacce in una struttura che fosse al contempo utile e comprensibile.
Lo stesso discorso vale per l’intelligenza artificiale ma con un indice di complessità maggiore: considerare l’implementazione dell’intelligenza artificiale all’interno di un’organizzazione come se fosse un processo meramente tecnico sarebbe un errore. Certamente implementare un modello algoritmico è, prevalentemente, un processo ingegneristico ma vi sono forti implicazioni anche nel mondo giuridico. Un modello algoritmico, di fatto, viene sviluppato da un fornitore e venduto ad un cliente, non molto differentemente da quanto avviene per un software qualsiasi. Tuttavia, mentre un normale software offre risultati statici e prevedibili, un algoritmo d’intelligenza artificiale ha un comportamento dinamico che potremmo definire, per certi aspetti, plastico perché esso muta nel tempo, al cambiare delle condizioni di utilizzo e d’interrogazione. È quindi un caso unico nella storia dell’informatica e, come tale, deve essere trattato.
Classificazione per fasi
La classificazione per fasi mira a collocare la minaccia (sia essa accidentale o deliberata) all’interno delle tre fasi principali della vita di un modello d’intelligenza artificiale.
Le tre fasi sono:
- ADDESTRAMENTO: intesa come la fase in cui il fornitore prepara il modello d’intelligenza artificiale per gli scopi per i quali è stato progettato e realizzato. È una fase normalmente di responsabilità del fornitore e restituisce un modello algoritmico quasi completo.
- AFFINAMENTO: intesa come la fase di perfezionamento del modello addestrato. Questa fase, chiamata anche “fine-tuning”, è un processo in cui un modello pre-addestrato viene ulteriormente addestrato su dati specifici dell’organizzazione per adattarlo meglio alle esigenze dell’utente. Questa fase è comune quando si vuole migliorare la qualità delle risposte del modello in un contesto particolare, correggere eventuali bias o adattarlo a un dominio specifico. Normalmente questa fase viene svolta in un contesto di utilizzo controllato, e può essere realizzata sia presso il fornitore sia sui sistemi del cliente (se ha l’infrastruttura adatta a supportarla).
- UTILIZZO: intesa come la fase d’impiego del modello da parte dell’utilizzatore, con monitoraggio delle risposte fornite dal modello e le eventuali correzioni da parte del fornitore.
Le fasi, in questo caso, suggeriscono anche una responsabilità primaria e una responsabilità secondaria.
| Fase | Responsabilità Primaria | Responsabilità secondaria |
|---|---|---|
| Addestramento | Fornitore | – |
| Affinamento | Fornitore | Cliente |
| Utilizzo | Cliente | Fornitore |
Come è possibile notare, vi è una letterale e comprensibile transizione della responsabilità primaria dal Fornitore al Cliente che dovrebbe rispecchiarsi anche all’interno dei contratti stipulati tra le parti. Questa transizione è fisiologica e piuttosto evidente: l’oggetto della fornitura (il modello) viene consegnato in uso dal fornitore al cliente che, di conseguenza, ne diviene il primo responsabile. Ma è altrettanto chiaro che i contratti che disciplinano la progettazione, la realizzazione, l’implementazione e l’uso dell’intelligenza artificiale, dovranno tenere in considerazione tali aspetti. Giova fare un esempio, nella fase di addestramento il modello algoritmico può essere esposto ad attacchi ben precisi tra cui quelli di avvelenamento:
- Targeted Poisoning: determinano una violazione dell’integrità del modello alterandone la previsione su un numero ridotto di sample mirati.
- Backdoor Poisoning: analogamente agli attacchi targeted poisoning determinano una violazione dell’integrità del modello, in questo caso tuttavia l’obiettivo è indurre in errore il modello in risposta a uno specifico sample di dati (denominato trigger).
La fase di addestramento, infatti, permette all’attaccante di accedere alla struttura del modello e ai dati di addestramento in modo diretto e con risultati decisamente più invasivi.
Aspetti di protezione del dato
La tipologia di attacco suggerisce un aspetto importante ossia il modo in cui il fornitore intende proteggere i dati del modello. Anche in fase di successivo utilizzo, infatti, se il modello non fosse adeguatamente protetto, si potrebbero raggiungere i dati di addestramento, con attacchi e tecniche offensive specifiche. La sicurezza imposta dal fornitore, di conseguenza, deve essere di alto livello ed il modello algoritmico dovrà necessariamente essere solido e garantire protezione verso l’architettura, le procedure, la configurazione e i dati di addestramento. Questo apre una riflessione sul ruolo dei contratti.
Sarà necessario stipulare contratti adeguati al fine di stabilire con precisione le responsabilità afferenti al fornitore e al cliente, sulla base di specifici aspetti di propria competenza. Ad esempio: il cliente non è il gestore dei dati di addestramento ma ne usufruisce durante il suo utilizzo e se un attacco alla sua infrastruttura riesce a raggiungere il modello algoritmico modificandolo, non è detto che sia sua la responsabilità complessiva della mancanza di sicurezza informatica. Sarà necessario distinguere le carenze che hanno permesso il data breach da quelle che hanno permesso di modificare il modello, in quanto il fornitore dovrebbe aver previsto una serie di misure per impedire tali cambiamenti. Attacchi come il Membership Inference Attack, il Data Extraction Attack o il Model Inversion Attack, possono sfruttare vulnerabilità presenti nel modello, che potrebbero essere sconosciuti all’utilizzatore. Questi attacchi, di conseguenza, potrebbero alterare il sistema di calcolo del modello, producendo un danno al cliente finale.
L’importanza dei contratti e la responsabilità dei fornitori
Disciplinare questo complicato insieme di equilibri è compito del contratto e ciò fa nascere la riflessione in merito all’importanza di avere professionisti competenti in materia, in grado di disciplinare situazioni complesse. Lo scenario si complica ulteriormente quando il modello acquisisce, come input, dati provenienti da altri sistemi.
In quel caso si sarebbe portati a credere che la gestione dell’alterazione riguardi il fornitore dei dati in ingresso ma non è detto. La perturbazione potrebbe non essere nella “modifica” dei dati in ingresso, bensì nell’aggiunta di un valore illecito al modello di calcolo che, come conseguenza, produrrà un errore nel risultato finale. In sostanza, insieme ai dati previsti, potrebbe essere inoculato un valore non previsto che induce in errore l’algoritmo. Anche in questo caso bisognerebbe valutare in che modo il fornitore dell’algoritmo ha protetto le procedure di input dei dati, anche al fine di evitare i cosiddetti attacchi di evasione.
Responsabilità nel modello, nel sistema e nell’ecosistema
La ISO 27005 (inclusa la versione 2022), differenzia il rischio in base al sistema e all’ecosistema. Tale differenziazione assume una particolare rilevanza quando lo si cala nel discorso dell’intelligenza artificiale.
Il modello algoritmico, come abbiamo spiegato in precedenza, deve avere specifiche misure di sicurezza a tutela dei dati e dei processi di elaborazione. Tali misure di sicurezza, per lo più imposte dal fornitore, hanno lo scopo di tutelarlo sia in fase di addestramento, che nelle successive fasi di affinamento ed utilizzo da parte degli utenti finali.
Il sistema può esser inteso come l’infrastruttura necessaria al modello per funzionare. Non è limitato ad un singolo computer, o ad una singola parte dell’infrastruttura, ma a tutte le risorse necessarie affinché il modello possa funzionare ed erogare le prestazioni per le quali è stato progettato e realizzato. Ciò colloca il sistema in una dimensione di risk management più complessa: bisogna, di fatto, tenere in considerazione tutti gli aspetti normalmente inclusi nella valutazione del rischio tra cui: personale, infrastruttura, attrezzature, informazioni, procedure, fornitori, banche dati, etc…
L’ecosistema è il contesto nel quale il sistema opera e con il quale scambia regolarmente informazioni. Non è detto che l’ecosistema esista solo nella fase di utilizzo: un modello che in fase di addestramento interroga banche dati esterne è già di per sé connesso ad un ecosistema. L’ecosistema presenta altre difficoltà di cui la maggiore, come è noto, è l’impossibilità di operare direttamente sui sistemi che lo compongono. L’ecosistema è, per definizione, dinamico e richiede approcci di cybersecurity adattivi e “plastici”. L’ecosistema può rappresentare una minaccia tanto per il sistema, quanto per il modello.
Il dimensionamento del rischio diviene quindi particolarmente rilevante, soprattutto quando il modello potrebbe essere esposto tanto ai rischi derivanti dal sistema, quanto a quelli derivanti dall’ecosistema.
Nella rappresentazione sintetica riportata sopra, è possibile notare i due momenti essenziali della gestione del rischio: il risk assessment e il risk treatment. Entrambi dovranno tenere presente i tre livelli presi in esame: modello, sistema ed ecosistema.
Una possibile suddivisione
Nell’articolo “Gestione del Rischio e Intelligenza Artificiale” sono state affrontate le tipologie principali di attacco. Sulla base di quelle tipologie, in modo estremamente semplificato, si è provato ad attribuire la responsabilità della cybersecurity a uno dei due soggetti.
- Il fornitore del modello è colui che produce il modello algoritmico e lo vende.
- L’azienda acquirente lo acquista per poterlo dare in uso al personale o agli utenti di riferimento.
| Tipo di Attacco | Fornitore del Modello | Azienda Acquirente |
|---|---|---|
| Evasion Attacks | X | |
| Availability Poisoning | X | X |
| Targeted Poisoning | X | X |
| Backdoor Poisoning | X | |
| Model Poisoning | X | X |
| Data Reconstruction | X | X |
| Membership Inference | X | X |
| Model Extraction | X | |
| Property Inference | X |
La tabella mostra essenzialmente due situazioni: ci sono casi dove la responsabilità è chiaramente imputabile a uno dei due attori coinvolti (si veda il caso del Model Extraction). Ci sono invece casi di co-responsabilità che devono per l’appunto essere disciplinati come fin qui affermato.
Conclusioni
Il contratto mantiene il suo ruolo centrale nel disciplinare ruoli, responsabilità, modalità di gestione e di comunicazione. In tal senso è bene ricordare quanto questo sia previsto da standard come la ISO 27001 o i CSC che, sebbene non utilizzino la parola “contratto” ma “accordo“, impongono la formalizzazione di tali aspetti. Ad esempio, nel caso della ISO 27001:2022 il paragrafo 4.2 sostiene che:
4.2 Understanding the needs and expectations of interested parties
The organization shall determine:
a) interested parties that are relevant to the information security management system;
b) the relevant requirements of these interested parties;
c) which of these requirements will be addressed through the information security management system.
The requirements of interested parties can include legal and regulatory requirements and contractual.
La sfida sarà quindi quella di avere una contrattualistica chiara ma anche ben definita, con un’attribuzione appropriata di responsabilità, procedure ed eventuali penali. Questo, però, richiederà anche una capacità tecnica raffinata al fine di capire senza dubbio alcuno natura, origine e dettagli degli incidenti. In buona sostanza è fondamentale avere la certezza dell’accaduto al fine di rendere applicabile il contratto che regola i rapporti tra le parti.
