La pervasiva introduzione di sistemi di intelligenza artificiale in pratica in ogni settore, pubblico e/o privato, è un dato che possiamo dare come acquisito, così come anche la grande profusione di sforzi e risorse per l’evoluzione e il miglioramento dei modelli. Così come anche si deve registrare la rapidità con cui la complessità e l’ampiezza di questi sistemi sta crescendo.
Per quanto sia una tecnologia frutto di una ricerca pluridecennale, le sue ulteriore evoluzioni e possibili sviluppi sono ancora difficilmente prevedibili, rappresentando un caso, forse IL caso di ignoto tecnologico.
Nel frattempo, mentre ancora se ne mappano e registrano i rischi intrinsechi, sviluppare ed adottare sistemi di IA è divenuto un fattore competitivo discriminante che a diversi livelli “obbliga” all’adozione di queta tecnologia, sia per ottimizzare processi (ridurre tempi e consti) ma anche per rispondere alle richieste del mercato e delle scelte dei “consumatori”.
Appare intuitivo che questa adozione precoce di una tecnologia che ha ancora molteplici elementi “incogniti”, presenti livelli di rischio più o meno rilevanti in dipendenza della sensibilità del settore di applicazione.
L’IA in Sanità: vantaggi e rischi
Una delle applicazioni che certamente può definirsi sensibile è quella nel settore sanitario.
Affrontare correttamente la questione dei rischi (e della gestione di questi) delle applicazioni dei sistemi di IA in sanità, rende necessario alcune precisazioni preliminari.
Il sistema sanitario, è un sistema sociotecnico complesso che ha come punto di emersione le erogazioni di prestazioni di assistenza sanitaria verso il pubblico, ma che, al contempo, non si esaurisce esclusivamente in quella.
Il sistema sanitario per attuarsi include: la scoperta e sviluppo del farmaco, le fasi di validazione clinica, logistica, stoccaggio, distribuzione, vigilanza sui farmaci, l’erogazione delle prestazioni, i processi di immissione sul mercato, pagamento e rimborso nonché “in esteso” anche il sistema di qualificazione delle professionalità impiegate, considerato l’impatto che la formazione ha sulla qualità delle prestazioni sanitarie erogate dal e nel sistema.
Ognuno di questi elementi è parte essenziale di quello che si definisce sistema sanitario ed ognuno di questi vede, con livelli diversi, applicazioni di Intelligenza Artificiale che parimenti ai vantaggi promessi, presentano specifici rischi che impattano sul sistema sanitario nel suo complesso.
La qualità (e la sicurezza) delle prestazioni erogate da un sistema sanitario, dipende dalla qualità di medicinali e terapie, dalla disponibilità di questi, dalla preparazione del personale medico e sanitario, incluso quello applicato alle attività amministrative.
L’intelligenza artificiale è già largamente utilizzata in ogni parte degli anelli della catena del valore in ambito sanitario, e, ovviamente, promette di esserlo esponenzialmente in futuro (non remoto)[1].
L’AI Act europeo (ma chiamiamolo “Regolamento”)
A fronte di questa “constatazione della realtà”, il Legislatore europeo ha avanzato per primo un quantomeno coraggioso approccio regolamentare del fenomeno dell’ Intelligenza Artificiale, o almeno di parti di esso, elaborando ed approvando il testo del Regolamento sulla Intelligenza Artificiale, noto comunemente come AI ACT.
Per quanto riferirsi al provvedimento di cui sopra come, appunto, all’AI ACT è certamente sintetico (e forse anche “catchy”), ad avviso di chi scrive appare più corretto (ontologicamente) mantenerne la dizione di Regolamento e non di ACT.
L’uso, infatti, del termine qui posto in critica, conduce, ad esempio, alla tanto erronea quanto fuorviante traduzione di AI ACT in “Legge sulla Intelligenza Artificiale”. Senza affrontare un approfondimento sulla “gerarchia delle fonti del diritto” è di per sé intuitivo che un Regolamento della Unione Europea non sia (e non possa essere) una Legge, tant’è che il “vecchio e caro” GDPR, mai è stato nominato il Personal data protection Act e men che meno tradotto in “legge sulla protezione dei dati personali”. Inoltre, il Governo ha proprio in queste ore promosso una DDL sulla Intelligenza Artificiale che sarà (quello sì) un Legge sulla Intelligenza Artificiale e ci troveremo ad avere “due provvedimenti” (di fonte diversa) con lo stesso nome.
Per scongiurare quello che a nostro avviso non è solo fonte equivoci, qui ci si riferirà al provvedimento come al Regolamento sulla Intelligenza Artificiale, in breve RIA.
La classificazione dei rischi operata dal RIA
La classificazione dei rischi operata dal RIA, fornisce dei criteri di valutazione ex ante, precedenti alla immissione in commercio ( o messa in servizio) dei sistemi di IA, valutando il rischio intrinseco di ledere diritti fondamentali, la libertà, la sicurezza e, certamente, la salute.
Per “scongiurare” il verificarsi di questi rischi, il Regolamento produce un elenco nel quale considera applicazioni di IA in settori in cui possono effettivamente concretizzarsi tali rischi e introduce una serie di adempimenti per quella che definisce la catena del valore della IA (rif. art. 25 RIA), individuando come soggetti: fornitori, deployer, distributori, importatori e rappresentanti di sistemi di IA, appunto, “ad alto rischio”.
Assunta (e condivisa) la preoccupazione del Legislatore unionale, in quanto “advisors” in ambito di compliance, ai fini di assumere le misure adeguate e attenersi ai dovuti adempimenti, ci si pone la domanda di quando e in che modo, concretamente, il rischio oggetto del RIA si concretizza.
L’attualizzazione dell’evento rischioso (in termini di conseguenze) è connesso ad un errore e/o ad un malfunzionamento del sistema.
L’errore può essere umano o tecnico, può dipendere da un uso “scorretto” oppure da un “difetto di progettazione” o (spesso) di “organizzazione”. Il malfunzionamento può, a sua volta dipendere da un errore oppure derivare da azioni “esterne” (che a sua volta però possono anche essere “favorite” da un errore di progettazione, organizzazione, ecc). è il cd. Ciclo dell’errore[2].
Il RIA, appare concentrarsi sul fornire elementi al fine di scongiurare l’errore umano, tanto in fase di progettazione quanto in fase di utilizzo, al fine di evitare ovviamente il malfunzionamento del sistema e il verificarsi dell’evento che sarebbe poi causa di quella lesione a diritti fondamentali, libertà, sicurezza e salute, che il regolamento vuole scongiurare nell’adozione di sistemi di IA. Il pericolo, qui, è nel possibile difetto di “diligenza” che l’agente umano è invece tenuto a prestare quando “fornisce” (progetto e/o sviluppa) o adotta (utilizza, importa, distribuisce) strumenti di IA.
È assumibile come massima di scienza, che il livello di sicurezza complessivo di un sistema è dato dal livello di sicurezza dell’elemento più vulnerabile.
Il rischio informatico, il cyber-risk, è un rischio diffuso e distribuito, in quanto rischio. È la sua manifestazione, la concreta manifestazione del rischio, il punto di emersione, a risultare locale.
La concatenazione di soggetti nella catena di produzione di sistemi ICT (o TIC secondo la dizione nazionale) qualifica il rischio che ne deriva come una (potenziale) sequenza di cosiddetti “rischi ereditati”, in cui ogni soggetto posto operativamente, funzionalmente e logicamente all’anello seguente, eredita il rischio da quello precedente e lo trasmette al successivo. A titolo di chiarimento, un software di sicurezza che presenti delle “vulnerabilità” (ad esempio per un difetto nella catena di controllo in sviluppo), installato su un firewall, poi inserito in un Network potrebbe permettere oltre che accessi non autorizzati, anche di installare applicazioni malware su altri dispositivi connessi o collegati a tale network, inoculando altre reti ed altri sistemi, facendo ereditare “il rischio” a cascata a tutta la catena.
Appare evidente, credo, da questo esempio, che il rischio cibernetico sia un “problema” di gestione della supply chain, e che per essere affrontato validamente non possa essere trattato in modo “isolato”. Considerazione che appare ancora maggiormente vera in relazione ai sistemi di IA, data la “lunga” catena di sviluppo che vedono modelli, algoritmi, dati di addestramento, utilizzo e convalida, interfacce utente, connessioni ad altri sistemi e eventuali integrazioni con altri software e/o dispositivi.
La Cybersecurity nell’AI Act
Il RIA, come detto, non si occupa “verticalmente” della cybersecurity dei sistemi di IA, ma ne rileva comunque la fondamentale importanza. Al Considerando 76 (51 nella proposta), infatti espressamente si afferma che «la cibersicurezza svolge un ruolo cruciale nel garantire che i sistemi di IA siano resilienti ai tentativi compiuti da terzi con intenzioni malevole che, sfruttando le vulnerabilità del sistema, mirano ad alterarne l’uso, il comportamento, le prestazioni o a comprometterne le proprietà di sicurezza».
In questo breve statement, il considerando introduce alcuni elementi fondamentali. Il primo, è quello della “resilienza”. Si deve annotare che il provvedimento non fornisce indicazioni su cosa intendere e come realizzare tale “resilienza” e approfondire la portata operativa dell’applicazione di questo principio sarebbe esorbitante rispetto agli obiettivi di queste riflessioni. Affermare, però, che i sistemi di IA debbano essere resilienti rispetto ai tentativi di terzi compiuti con intenzioni malevoli, implica l’ovvia constatazione che i i sistemi sono vulnerabili, che rappresentano un obiettivo (per i terzi malevoli) e che questa circostanza fattuale è data per assunta. Il richiamo alla resilienza, assunto quanto detto sopra, impone che l’impatto di questi rischi siano minimizzati e il richiamo alla cibersicurezza come elemento cruciale per l’attuazione del richiesto livello di resilienza descrive in modo chiaro il ruolo e “il perimetro” che le misure di sicurezza cibernetica devono assumere rispetto ai sistemi di IA.
Le misure tecniche e organizzative proprie della cybersecurity devono essere pensate e implementate affinché sia “minimizzato” il rischio di manomissioni compiute, impendendo che questi “tentativi” sfruttino le vulnerabilità del sistema e/o alterino l’uso, il comportamento o le prestazioni.
Come si può osservare, non limita questa prescrizione alla sola resilienza digitale[3], ma si rivolge alla resilienza tout court, includendo implicitamente anche eventi “fisici” verso i quali il sistema deve essere comunque resiliente.
Il (fondamentale) considerando 76, poi, precisa che gli attacchi informatici contro i sistemi di IA possono far leva sulle risorse specifiche dell’IA, quali i set di dati di addestramento (ad esempio il data poisoning, “avvelenamento dei dati”) o i modelli addestrati (ad esempio gli adversarial attacks, “attacchi antagonisti” o la membership inference, “attacchi inferenziali”), o sfruttare le vulnerabilità delle risorse digitali del sistema di IA o dell’infrastruttura TIC sottostante.
Infine, invita al fine di garantire un livello di cibersicurezza adeguato ai rischi, che i fornitori di sistemi di IA ad alto rischio adottino misure adeguate, come controlli di sicurezza, anche tenendo debitamente conto dell’infrastruttura TIC sottostante.
Il JRC, nel 2023 ha pubblicato un rapporto[4] contenente alcuni elementi di interesse per poter interpretare e gestire correttamente gli aspetti di cibersicurezza connessi all’adozione di sistemi di IA.
Alcuni punti risultano di particolare interesse. Innanzitutto, il rilievo che il requisito di cybersecurity dell’AI Act si applica al sistema di IA nel suo complesso e non direttamente ai suoi componenti interni. Per garantire la conformità, è necessario condurre una valutazione del rischio di sicurezza tenendo conto della progettazione del sistema, per identificare i rischi e implementare le misure di mitigazione necessarie.
Il rapporto del JRC, avverte che è importante comprendere comunque che esistono limitazioni nello stato dell’arte della sicurezza dei modelli di IA. I sistemi di IA ad alto rischio possono raggiungere la conformità se mitigano adeguatamente i rischi complessivi di cybersecurity del sistema attraverso altre misure complementari, seguendo un approccio integrato che combina pratiche e procedure di cybersecurity ben consolidate con misure specifiche per l’IA.
Il RIA, precisa il rapporto, mira a stabilire un quadro orizzontale per sistemi di IA affidabili, sicuri e conformi ai diritti e ai valori fondamentali europei. Il Regolamento sull’IA è stato concepito per affrontare i rischi per la salute, la sicurezza e i diritti fondamentali specificamente associati alle tecnologie di IA, stabilendo requisiti giuridicamente vincolanti per i sistemi di IA ad alto rischio.
I requisiti di cybersicurezza, accuratezza e robustezza sono legati alla dimensione tecnica dei sistemi di IA e richiedono una profonda comprensione del funzionamento interno dei sistemi di IA, delle pratiche tecniche e degli standard consolidati.
La cybersecurity dell’IA è contemplata nell’articolo 15 del RIA, anche se non come requisito individuale, ma congiuntamente all’accuratezza e alla robustezza.
Il requisito della cybersecurity, come visto, è ulteriormente esplicitato nel Considerando 76. Sulla base dell’articolo 15 e del considerando 76, la richiesta di standardizzazione, allegato II (2.8), fornisce poi ulteriori dettagli operativi sul requisito di sicurezza informatica.
Dal punto di vista operativo il requisito di sicurezza informatica comprende quattro elementi principali:
- I sistemi di IA ad alto rischio devono essere garantiti e progettati per essere resistenti ai tentativi di alterarne l’uso, il comportamento e le prestazioni e di comprometterne le proprietà di sicurezza da parte di terzi malintenzionati.
- Per raggiungere questi obiettivi saranno implementate soluzioni organizzative e tecniche.
- Per i sistemi di IA ad alto rischio deve essere effettuata una valutazione del rischio di cybersecurity.
- Le soluzioni tecniche devono essere adeguate alle circostanze e ai rischi pertinenti.
Dopo l’entrata in vigore del RIA, tutti i sistemi di IA ad alto rischio, così come definiti dalla normativa, dovranno essere sottoposti a una valutazione di conformità e rispettare i requisiti di sicurezza informatica prima di poter essere utilizzati o messi in servizio nel mercato dell’UE.
Un sistema di IA, definito formalmente all’articolo 3, paragrafo 1 del RIA, deve essere inteso come un software che include uno o più modelli di IA come componenti chiave insieme ad altri tipi di componenti interni come interfacce, sensori, database, componenti di comunicazione di rete, unità di calcolo, software di preelaborazione o sistemi di monitoraggio.
Ad esempio, un chatbot basato sull’IA si basa su modelli linguistici di grandi dimensioni, ma ovviamente (e necessariamente) anche su un’infrastruttura cloud tradizionale a cui accedere tramite Internet e gestire l’hardware necessario per eseguire l’applicazione.
La conformità dei sistemi ad alto rischio
Per garantire la conformità di un sistema di IA ad alto rischio al RIA, il requisito di cybersecurity deve essere mappato dal sistema ai singoli componenti nel contesto del sistema di gestione del rischio descritto nell’articolo 9 del Regolamento sulla IA.
In particolare, nell’ambito di applicazione del RIA, devono essere considerati due livelli di valutazione del rischio:
A. La valutazione del rischio di livello normativo superiore che comprende tutti gli altri requisiti descritti nell’articolo 9.
B. Una valutazione del rischio di cybersecurity per determinare le misure di sicurezza adeguate ai rischi specifici del sistema di IA e dei suoi componenti, siano essi IA o meno, come descritto nel considerando 76 della legge sull’IA e nell’allegato II (2.8) della richiesta di standardizzazione.
Ciò implica che, sebbene l’uso di un sistema di IA in un determinato contesto specifico possa essere considerato ad alto rischio dal punto di vista normativo (Allegato III della RIA), il sistema potrebbe presentare rischi limitati di cybersecurity a causa del modo in cui è progettato e funziona, come anche potrebbe, di contro, non essere alto rischio normativo ma presentare severi rischi di cybersecurity.
Per tali ragioni la sicurezza informatica dei sistemi di IA dovrebbe basarsi su una combinazione di controlli esistenti per i sistemi software e di controlli specifici per l’IA sui singoli modelli. Questo dovrebbe essere applicato a diversi livelli del sistema durante tutto il suo ciclo di vita, seguendo un approccio olistico basato sui principi di security-in-depth e security-by-design.
In generale, e per quanto possibile, i sistemi di intelligenza artificiale non dovrebbero essere trattati in modo diverso da altre architetture software complesse conosciute
IA e cyber-risk in sanità
Se non chiarito, almeno circoscritto l’ambito e il ruolo della cybersecurity dei sistemi IA, è ora possibile iniziare a “riconciliarlo” con la sua applicazione in ambito sanitario e con il rischio cibernetico di settore.
Il rapporto ENISA, Health Threat Landscape[5], del 05.07.23, segnala che dal 01/2021 al 03/2023 il 53% degli incidenti ha riguardato EU healthcare providers (42% ospedali, 14% ad autorità, agenzie, corpi, 9% a aziende farmaceutiche).
Questo dato, si traduce nel rilievo che l’ambito sanitario è un ambito a elevato livello di esposizione (al rischio).
L’espansione dell’utilizzo dell’IA in ambito «sanitario», comporta, come osservato già ut supra, un necessario incremento della quantità e qualità (tipologia) di dati raccolti allo scopo di erogare i servizi della Healtchare Supply Chain. Ne consegue che non solo gli obiettivi diventano «più interessanti», nel senso di attrazione per i cybercriminali, ma gli esiti degli attacchi diventano anche maggiormente «pericolosi».
È possibile affermare che è il primo rischio dell’adozione di sistemi di IA ambito sanitario e, quindi, che incrementa i rischi esistenti. Le IA necessitano di grandi quantità di dati per produrre risultati utili, e tanto più precisi (affidabili) devono essere i dati dell’output, tanto maggiore dovrà essere la quantità di dati che dovranno essere forniti al sistema. Questo comporta anche un aumento dei “punti di raccolta”, che richiedono sensori distribuiti per la collezione di dati “attuali e contestuali” (quindi validi). Sensori che noi definiamo dispositivi «indossabili», la cui diffusione, in sintesi, amplia i punti di ingresso per attacchi informatici. Questa necessità di quantità crescenti di dati, inoltre, incrementa il monitoraggio (o la sorveglianza) diretto e indiretto degli individui, con i rischi paventati dal RIA, aumenta la connessione a “servizi in cloud” quindi l’esposizione ai relativi rischi. Risalendo la catena del rischio, l’IA, permette di poter falsare i risultati di una ricerca, con conseguenze per lo sviluppo di un farmaco, di falsificare i dati salute e gli esiti di esami clinici, “avvelenando” l’intero ciclo del dato di cui vive la IA.
Rischio a cui si aggiunge anche quello di decisioni cliniche viziate da pregiudizi, di errate diagnosi, che si traducono poi in rischi sia di ordine etico che legale (responsabilità, IP, competizione).
Da questa sommaria indicazione di potenziali rischi, appare opportuno porre alcuni assunti per, in qualche misura, facilitare, la verticalizzazione della gestione del rischio cibernetico della IA applicata al settore sanitario.
- Il settore sanitario è un settore «Altamente Critico», per il sistema di sicurezza delle reti e delle informazioni, rientrante a pineo titolo nelle cd. disposizioni NIS (sia prima versione[6] quanto che nella nuova[7]). I soggetti che erogano prestazioni sanitarie sono quindi ipso facto sottoposti a dettagliati adempimenti in materia di cybersecurity in quanto soggetti «essenziali o importanti».
- I sistemi di IA sono sistemi informatici. Affermazione che appare banale ma che è rilevante per l’adozione di “strumenti” di analisi e gestione del rischio ad essa associato.
- Tutti i sistemi informatici presentano rischi di natura tecnica (intrinsechi o connessi alle modalità di utilizzo) e rischi funzionali (di relazione con obblighi di legge, deontologici, di impatto degli esiti, ecc.).
- La gestione del rischio, perché sia efficace, deve tener conto di tutti questi fattori, con un approccio “olistico”
- Il rischio «cyber» è un rischio differente ma concorrente da quello oggetto del RIA.
- La cybersecurity è un «processo di governance» e non una «soluzione tecnica.
La compliance dei sistemi IA nella prestazione di assistenza sanitaria
È stato anticipato che per una valutazione puntuale, occorre circoscrivere in quale ambito del(vasto) settore sanitario si vuole compiere la valutazione[8]. In quanto punto di contatto diretto con il pubblico e per la peculiarità della natura dei soggetti e del servizio prestato, appare di particolare interesse ed utilità, porre in analisi l’ambito dei soggetti prestatori di assistenza sanitaria, come definito dall’art.3 lett.g) della dir. 2011/24/CE, ovvero qualsiasi persona fisica o giuridica o qualsiasi altra entità che presti legalmente assistenza sanitaria nel territorio di uno Stato membro.
In pratica, si pone in analisi a quali adempimenti si debba attenere una struttura sanitaria che si voglia dotare di uno o più sistemi IA a supporto della erogazione delle proprie prestazioni.
Tali soggetti, come anticipato, operano in uno dei settori ad alta criticità come definiti dalla direttiva NIS2 (v. all.1, pt.5, primo trattino), sono quindi soggetti cd. essenziali (se identificati tali) o importanti, comunque sottoposti alle misure di gestione della cybersicurezza e a agli obblighi di segnalazione previsti dalla Dir.(UE) 2022/2555.
I soggetti essenziali e importanti dovrebbero, infatti, garantire la sicurezza dei sistemi informatici e di rete che utilizzano nelle loro attività.(considerando83).
Ai sensi del paragrafo 1, dell’art. 21 della NIS2 questi soggetti devono:
- adottare misure tecniche, operative e organizzative adeguate e proporzionate per :
- gestire i rischi posti alla sicurezza dei sistemi informatici e di rete che tali soggetti utilizzano nelle loro attività o nella fornitura dei loro servizi
- prevenire o ridurre al minimo l’impatto degli incidenti per i destinatari dei loro servizi e per altri servizi.
In tali adempimenti devono tenere conto delle conoscenze più aggiornate in materia (…), delle pertinenti norme europee e internazionali, (…), ovviamente valutando i relativi costi di attuazione.
Inoltre, nel valutare la proporzionalità di tali misure, tenere debitamente conto delle dimensioni del soggetto e della probabilità che si verifichino incidenti, nonché il grado di esposizione del soggetto a rischi della loro gravità, compreso il loro impatto sociale ed economico.
La prima, quasi ovvia, considerazione che si pone in evidenza è che un soggetto che eroga prestazioni sanitarie, che sia essenziale o importante (o comunque critico ai sensi della dir.(UE) 2022/2557) che voglia adottare un sistema di IA deve attenersi a quanto qui descritto. Nel valutare quanto adeguate e quanto proporzionali siano le misure tecniche, operative e organizzative terrò conto della probabilità, del grado di esposizione, gravità e impatto sociale ed economico. Abbiamo menzionato che il 53% degli attacchi informatici valutati nel rapporto ENISA riguardano il settore sanitario e che sono soggetti altamente esposti. Inoltre, si deve considerare che ogni “malfunzionamento” o “errore” di sistemi informatici utilizzati per l’erogazione di prestazioni sanitari è potenzialmente in grado di causare danni alla salute (anche fatali) e di rappresentare una lesione ad un diritto fondamentale quale è quello alla salute. Per tanto, il livello di gravità è elevato così come anche lo è il livello di impatto sociale (ed economico).
Secondo le prescrizioni della NIS2 questo comporta un giudizio di “proporzionalità” che impone il massimo livello di adesione e diligenza da parte del soggetto obbligato, anche in una valutazione che richieda un impegno economico rilevante. La norma in esame ai fine degli adempimenti richiama all’adozione anche delle “più recenti norme europee e internazionali”. Nel caso in esame, di adozione di IA, crea la necessaria integrazione di quelle misure (e valutazioni di conformità e di rischio) che sono contenute nel RIA.
L’approccio multirischio
Il Paragrafo 2 dell’art.21, poi, precisa che le misure del paragrafo 1 devono essere basate su un approccio multirischio che miri a proteggere i sistemi informatici e di rete e il loro ambiente fisico da incidenti.
Cosa si debba intendere per approccio multirischio, lo chiarisce il Considerando 79 della Direttiva. Qui il legislatore europeo precisa che, poiché le minacce alla sicurezza dei sistemi informatici e di rete possono avere origini diverse, le misure di gestione dei rischi di cibersicurezza dovrebbero essere basate su un approccio multirischio mirante a proteggere i sistemi informatici e di rete e il loro ambiente fisico da eventi quali furti, incendi, inondazioni, problemi di telecomunicazione o interruzioni di corrente, o da qualsiasi accesso fisico non autorizzato nonché dai danni alle informazioni detenute dai soggetti essenziali o importanti e agli impianti di trattamento delle informazioni di questi ultimi e dalle interferenze con tali informazioni o impianti che possano compromettere la disponibilità, l’autenticità, l’integrità o la riservatezza dei dati conservati, trasmessi o elaborati o dei servizi offerti da tali sistemi informatici e di rete o accessibili attraverso di essi.
Le misure di gestione dei rischi di cybersicurezza dovrebbero pertanto affrontare anche la sicurezza fisica e dell’ambiente dei sistemi informatici e di rete includendo misure volte a proteggere detti sistemi da guasti del sistema, errori umani, azioni malevole o fenomeni naturali. Una copertura da rischi a spettro molto ampio.
Chiarito cosa si debba intendere per approccio multirischio, il par.2 dell’articolo 21 menziona alcuni contenuti minimi, tra cui, rilevano ai fini di questa disamina: a) politiche di analisi dei rischi e di sicurezza dei sistemi informatici; b) gestione degli incidenti; c) continuità operativa, come la gestione del backup e il ripristino in caso di disastro, e gestione delle crisi; d) sicurezza della catena di approvvigionamento, compresi aspetti relativi alla sicurezza riguardanti i rapporti tra ciascun soggetto e i suoi diretti fornitori o fornitori di servizi; e) sicurezza dell’acquisizione, dello sviluppo e della manutenzione dei sistemi informatici e di rete, compresa la gestione e la divulgazione delle vulnerabilità; f) strategie e procedure per valutare l’efficacia delle misure di gestione dei rischi di cibersicurezza; g) pratiche di igiene informatica di base e formazione in materia di cibersicurezza.
AI procurement: un rischio di supply chain
Al considerando 78, la direttiva precisa che le misure di gestione dei rischi dovrebbero tenere conto del grado di dipendenza del soggetto essenziale o importante dai sistemi informatici e di rete e comprendere misure per individuare eventuali rischi di incidenti, per prevenire e rilevare incidenti, nonché per rispondervi, riprendersi da essi e attenuarne l’impatto.
La sicurezza dei sistemi informatici e di rete dovrebbe comprendere la sicurezza dei dati conservati, trasmessi e elaborati. Le misure di gestione dei rischi di cibersicurezza dovrebbero prevedere un’analisi sistemica, tenendo sistemica, tenendo conto del fattore umano, onde avere un quadro completo della sicurezza del sistema informatico e di rete.
Affrontare i rischi derivanti dalla catena di approvvigionamento di un soggetto e dalla sua relazione con i fornitori, ad esempio i fornitori di servizi di conservazione ed elaborazione dei dati o di servizi di sicurezza gestiti e gli editori di software, è particolarmente importante data la prevalenza di incidenti in cui i soggetti sono stati vittime di attacchi informatici e in cui i responsabili di atti malevoli sono stati in grado di compromettere la sicurezza dei sistemi informatici e di rete di un soggetto sfruttando le vulnerabilità che interessano prodotti e servizi di terzi.
Secondo quanto previsto dalla direttiva NIS2, i soggetti essenziali e importanti dovrebbero pertanto valutare e tenere in considerazione la qualità e la resilienza complessive dei prodotti e dei servizi, delle misure di gestione dei rischi di cibersicurezza in essi integrate e delle pratiche di cibersicurezza dei loro fornitori e fornitori di servizi, comprese le loro procedure di sviluppo sicuro.
Di particolare rilievo operativo è quanto poi previsto dal Considerando 85, laddove precisa che, in particolare, i soggetti essenziali e importanti dovrebbero essere incoraggiati a integrare misure di gestione dei rischi di cibersicurezza negli accordi contrattuali con i loro fornitori e fornitori di servizi diretti..
Il contratto come strumento di gestione del cyber-risk
Riportando quel contenuto necessario che integra il richiesto approccio multirischio, del par.2 dell’Art.21, con i termini espressi dai considerando 78 e 85, emerge chiaro che il primo strumento di compliance per la gestione del cyber-risk della IA (e di qualsiasi altro sistema informatico, in verità), è dato dal processo di acquisizione e della contrattualizzazione che lo realizza, dalla scelta del fornitore sino al deployment e al mantenimento del sistema.
Valutando ad esempio i requisiti di gestione degli incidenti; la garanzia di continuità operative, il ripristino in caso di disastro, la gestione delle crisi; questo saranno necessariamente aspetti che, nell’ipotesi di un sistema IA dovranno essere integrati in quel punto che prevede la sicurezza dell’acquisizione, dello sviluppo e della manutenzione dei sistemi informatici e di rete, compresa la gestione e la divulgazione delle vulnerabilità (rif. Lett.e). Il che si traduce, tecnicamente ed operativamente, nell’inserimento di opportune previsioni contrattuali che diano al soggetto utilizzatore, che gli incidenti possano essere adeguatamente gestiti, stabilendo anche ruoli e responsabilità, ad esempio, per servizi in cloud, così come anche ei termini di “ripristino” e le soglie di tollerabilità di interruzioni di servizio. Nello strumento negoziale potranno poi essere inseriti anche eventuali strategie e procedure per valutare l’efficacia delle misure di gestione dei rischi di cibersicurezza (previste alla lett.f); e pratiche di igiene informatica di base e formazione in materia di cibersicurezza (di cui alla lett.g); che ad esempio possono richiedere il coinvolgimento del fornitore del sistema o del servizio, e quindi essere elemento di espressa pattuizione contrattuale.
Il fatto di voler adottare idonei strumenti contrattuali, oltre che richiamare il considerando 85 menzionato, integrando anche l’attuazione di quelle politiche di analisi dei rischi e di sicurezza dei sistemi informatici (ci cui alla lett.a) e l’implementazione della sicurezza della catena di approvvigionamento, compresi aspetti relativi alla sicurezza riguardanti i rapporti tra ciascun soggetto e i suoi diretti fornitori o fornitori di servizi (di cui alla lettera d).
Ecco che inizia a emergere sempre più chiaramente che il procurement e la corretta prassi contrattuale assume il contorno di strumento di attuazione della compliance operativa. Occorre, però, oltre una profonda conoscenza degli adempimenti normativi, anche una altrettanto profondo livello di comprensione degli aspetti tecnici del “sistema da acquisire” e del sistema in cui viene inserito, includendo anche valutazioni di carattere organizzativo
A titolo esemplificativo si può immaginare il caso in cui una struttura sanitaria (pubblica) si appresti ad acquisire un sistema di IA. In ottemperanza a quell’approccio multirischio che prevede di porre in essere politiche di analisi dei rischi e di sicurezza dei sistemi informatici Art. 21, par.2, lett.a), potrà preliminarmente riferirsi alle “Azioni Generali da compiersi prima di acquisire un sistema TIC” (inclusa AI, nda) previste dall’AGID[9]. Quindi come azioni generali (AG):
- Promuovere competenza e consapevolezza
- Raccogliere buone prassi ed esperienze
- Stabilire ruoli e responsabilità
- Effettuare una ricognizione dei beni informatici e dei servizi
- Classificazione di beni e servizi sotto il profilo della sicurezza
- Definire una metodologia di audit e valutazione del fornitore in materia di sicurezza
- Definire una metodologia di audit interno in materia di sicurezza
Questi punti, applicati al caso concreto consentono di raggiungere alcuni livelli di compliance e di “gestire” quella componente di rischio che possa derivare da aver sottovalutato gli aspetti organizzativi, non avendo definito ruoli e responsabilità, oppure di non aver adeguatamente valutato e classificato gli asset della infrastruttura dal punto di vista di sicurezza e, decisamente impattante, quello di non aver adeguatamente valutato il fornitore in materia di sicurezza, che in caso di fornitore di IA implica la valutazione in termini di “safety” del prodotto o servizio come prescritto dal RIA.
Per quanto visto al par.2, si troverà in effetti a dover valutare la sicurezza della catena di approvvigionamento, compresi aspetti relativi alla sicurezza riguardanti i rapporti tra ciascun soggetto e i suoi diretti fornitori o fornitori di servizi; nonché la sicurezza dell’acquisizione, dello sviluppo e della manutenzione dei sistemi informatici e di rete, compresa la gestione e la divulgazione delle vulnerabilità.
Tanto l’utilizzo quanto delegarne lo sviluppo implica l’introduzione di un «fornitore» (di un servizio critico) all’interno della catena del valore. È un problema di gestione della supply chain.
Sempre attingendo alle richiamate linee guida dell’AGID, potrà implementare le previste Azioni di procurement (AP)[10], che includono:
- Analizzare la fornitura e classificarla in base a criteri di sicurezza
- Scegliere lo strumento di acquisizione più adeguato, tenendo conto della sicurezza
- Scegliere i requisiti di sicurezza da inserire nel capitolato[11]
- Garantire competenze di sicurezza nella commissione di valutazione
Classificazione del rischio
Oltre valutazioni di carattere «generale», è in questa fase dovrò essere valutata operativamente se il sistema di IA che intendo acquisire, ad esempio, verrà utilizzato:
« (…) per valutare l’ammissibilità delle persone fisiche alle prestazioni e ai servizi di assistenza sanitaria, nonché per concedere, ridurre, revocare o recuperare tali prestazioni e servizi[12];
o
« (…) per valutare e classificare le chiamate di emergenza effettuate da persone fisiche o per inviare servizi di emergenza di primo soccorso o per stabilire priorità in merito all’invio di tali servizi (…) nonché per i sistemi di selezione dei pazienti per quanto concerne l’assistenza sanitaria di emergenza[13];
Nel caso in cui una delle due circostanze riflettesse la finalità di uso del sistema di IA che si intende acquisire, si ricadrebbe nella classificazione di “Sistema ad Alto Rischio” secondo il Regolamento sulla Intelligenza Artificiale e quindi nelle connesse prescrizioni.
Valutazione della posizione
Per la corretta prospettazione del rischio, degli adempimenti e delle relative responsabilità deve essere valutata la posizione assunta rispetto al sistema di IA. Il Regolamento per quanto qui di interesse, infatti prevede due figure fondamentali a cui sono associati precisi adempimenti.
- “deployer”: persona fisica o giuridica, autorità pubblica, agenzia o altro organismo che utilizza un sistema di IA sotto la propria autorità, tranne nel caso in cui il sistema di IA sia utilizzato nel corso di un’attività personale non professionale[14]
- “fornitore”: una persona fisica o giuridica, un’autorità pubblica, un’agenzia o un altro organismo che sviluppa un sistema di IA o un modello di IA per finalità generali o che fa sviluppare un sistema di IA o un modello di IA per finalità generali e immette tale sistema o modello sul mercato o mette in servizio il sistema di IA con il proprio nome o marchio, a titolo oneroso o gratuito[15]
Obblighi del fornitore (rif Art. 16 RIA)
Nel caso la struttura sanitaria sviluppasse od anche «facesse sviluppare» il sistema IA, ricadrebbe nella definizione di Fornitore, e nel caso il sistema fosse ad alto rischio si troverebbe a dover rispettare imporrebbe i seguenti obblighi:
- Garantire la conformità ai requisiti in Sez.2 (v. in particolare art 15 RIA)
- Identificabilità del fornitore sui documentazione e imballaggi
- Essersi dotata di un Sistema di gestione qualità (v. art. 17 RIA)
- Conservazione della documentazione (art.18 RIA) – 10 anni (inclusa documentazione tecnica e gestione della qualità RIA)
- Conservazione delle registrazioni (log) art.19 RIA log sono conservati per un periodo adeguato alla finalità prevista del sistema di IA ad alto rischio, della durata di almeno sei mesi, salvo diversamente disposto
- Produrre una Garanzia di conformità (43-47-48 RIA)
- Effettuare la Registrazione obbligatoria (art 49 RIA)
- Adottare misure correttive e adempiere obbligo informativo (art. 20 RIA).
- dimostrare la conformità ai requisiti della sezione 2 del RIA (rif. pr. di accountability)
- Garantire l’accessibilità ( rif. alle direttive 2016/2102 – 2019/882).
Obblighi del deployer (Art. 26 RIA)
Nel caso in cui, invece, la struttura acquisisse un Sistema di IA sviluppato da terza parte autonomamente, senza indicazioni o customizzazioni, la struttura dovrà comunque:
- Adottare idonee misure tecniche e organizzative per garantire di utilizzare tali sistemi conformemente alle istruzioni per l’uso che accompagnano i sistemi
- Affidare la sorveglianza umana a persone fisiche che dispongono della competenza, della formazione e dell’autorità necessarie nonché del sostegno necessario
- Garantire che tali dati di input siano pertinenti e sufficientemente rappresentativi alla luce della finalità prevista del sistema di IA ad alto rischio
- Monitorare il funzionamento del sistema di IA, con obblighi informativi e di segnalazione a fornitore e autorità competenti.
- Conservare i log generati automaticamente (se sotto il mio controllo) per almeno sei mesi
Dovrà inoltre informare i rappresentanti dei lavoratori e i lavoratori interessati che saranno soggetti all’uso del sistema di IA ad alto rischio, prima di mettere in servizio o utilizzare un sistema di IA ad alto rischio sul luogo di lavoro. Questo punto, si collega alla Azione Generale 1 nelle linnee guida di procurement, ad esempio che, come visto, prevede la promozione di competenza e consapevolezza come azione preliminare al procurement del sistema TIC.
Se il sistema di IA ad alto rischio utilizza per il suo funzionamento dati personali, sarà poi necessario compiere una DPIA a norma dell’articolo 35 del regolamento (UE) 2016/679 .
Il deployer dovrà informare le persone soggette alla IA che interagiscono con o che sono sottoposte ad un sistema IA. Inoltre, ex art 86 RIA, dovrà predisporre un sistema che consenta la spiegabilità di quanto compiuto dalla IA.
Valutazione d’impatto sui diritti fondamentali per i sistemi di IA ad alto rischio (art.27 RIA)
Prima di utilizzare un sistema di IA ad alto rischio, il la struttura sanitaria deployer , in quanto organismo di diritto pubblico ( o ente privato che fornisce servizi pubblici) dovrà anche effettuare una valutazione dell’impatto sui diritti fondamentali che l’uso di tale sistema può produrre, includendo:
… se il sistema non è ad alto rischio per il RIA?
I fornitori e i deployer dei sistemi di IA adottano misure per garantire nella misura del possibile un livello sufficiente di alfabetizzazione in materia di IA del loro personale nonché di qualsiasi altra persona che si occupa del funzionamento e dell’utilizzo dei sistemi di IA per loro conto, prendendo in considerazione le loro conoscenze tecniche, la loro esperienza, istruzione e formazione nonché il contesto in cui i sistemi di IA devono essere utilizzati, e tenendo conto delle persone o dei gruppi di persone su cui i sistemi di IA devono essere utilizzati (Art.4 RIA).
Deve essere sempre e comunque rispettato quanto disposto dal Reg. (UE) 2016/679, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, della Direttiva 2002/58/CE del Parlamento europeo e del Consiglio, relativa al trattamento dei dati personali e alla tutela della vita privata nel settore delle comunicazioni elettroniche (direttiva relativa alla vita privata e alle comunicazioni elettroniche), e come qui in analisi, se soggetto essenziale o importante, applicare le disposizioni della Dir. (UE) 2022/2555.
In tutti i casi deve essere garantita sempre e comunque la catena di Confidenzialità, Integrità e Disponibilità del dato.
Questi elementi dovranno trovare opportuna previsione e adeguata sistemazione tanto nei “capitolati” quanto nei contratti di procurement di beni o servizi .
Le insidie nascoste
L’adeguata conoscenza sia del framework normativo quanto della concreta applicazione del sistema al contesto di uso, è importante anche per non incorre in qualche “insidia” che si cela tra le pieghe della norma.
Ad esempio, se un deployer appone il proprio «nome o marchio» o apporta un modifica sostanziale o modifica la finalità prevista di un Sistema IA già immesso sul mercato, assume qualifica e obblighi di fornitore.
Inoltre, se la modifica interessa un sistema che originariamente non era da alto rischio, che a seguito della modifica diventa tale, il fornitore originale non ha alcun «obbligo di collaborazione» (rif. Art. 25 RIA).
Qualsiasi persona fisica o giuridica che abbia motivo di ritenere che vi sia stata una violazione delle disposizioni RIA può presentare un reclamo motivato alla pertinente autorità di vigilanza del mercato (Art.85 RIA).
La direttiva (UE) 2019/1937 si applica alla segnalazione di violazioni del RIA e alla protezione delle persone che segnalano tali violazioni (art.87 RIA). Questo rende importante l’implementazione di un sistema di formazione e informazione, sia di operatori che di utenti, che venga adottata la massima trasparenza possibile in tutte le operazioni e attività che vede impiegata la IA e, ovviamente, che vengano puntualmente garantiti gli adempimenti previsti. In ultimo, risulta fondamentale che l’impalcatura contrattuale sia stata progettata e attuata ponendo chiaramente in evidenza gli obblighi per le parti e assicurandosi il giusto riparto delle responsabilità.
Conclusioni
Nella procedura di qualificazione dei sistemi si dovrà prestare attenzione alla «finalità prevista», per qualificare correttamente il profilo di sicurezza e l’impatto organizzativo.
Nella qualificazione del fornitore, la procedura dovrà tenere conto della qualificazione del sistema di IA e delle misure alla cui osservanza è tenuto il fornitore.
È opportuno considerare la localizzazione geografica del fornitore del sistema IA e dei eventuali aspetti consessi al trasferimento dei dati e ai dati utilizzati in addestramento.
È importante che via stata adeguata informazione e informazione, e che siano applicate adeguate (e comprovate) competenze all’utilizzo della IA.
E’ importante che vi sia un corretto e puntuale flusso informativo con il fornitore in tutte le fasi contrattuali; non utilizzare il sistema di IA oltre «le finalità previste» e non apportare modifiche che ne mutino sostanzialmente le caratteristiche o che se “geograficamente limitato” lo utilizzino fuori dall’area prevista dalla sua condizione di conformità , che vi siano chiare previsioni in relazione alle modalità di trasmissione/accesso/conservazione di dati utilizzati e prodotti dai sistemi IA.
Inoltre, per evitare “difetti di resilienza”, è opportuno avere «strategie di uscita» rispetto al fornitore selezionato e strategie di backup per garantire che il i servizi abbiano continuità operativa anche in caso di cambio di fornitore ed in tempi “compatibili” con il grado di impatto sociale ed economico del servizio.
Note
[1] Ai è usata per scoprire nuovi “farmaci”, https://insilico.com/; inventare nuovi composti, https://www.nature.com/articles/d41586-023-02227-y; https://news.mit.edu/2023/ai-system-can-generate-novel-proteins-structural-design-0420; individuare il cancro, https://www.thelancet.com/journals/landig/article/PIIS2589-7500(21)00252-1/fulltext; Il gestire il triage dei pazienti, https://www.optum.com/; fornire indicazioni terapeutiche, https://www.sciencedirect.com/science/article/pii/S0923753419350720; svolgere (e in prospettiva sostituire) sperimentazioni cliniche. https://www.unlearn.ai/
[2] Per Maggiore precisione, a rischio di apparare superflui, occorre distinguere tra rischio e pericolo. Laddove il rischio è la probabilità che un pericolo produca danni. Ciò che posso gestire, salvo errori, è appunto il rischio. Così anche un evento di forza maggiore o naturale, come un “terremoto” rappresenta un pericolo, i cui rischi sono chiamato a mitigare. Per un richiamo al Ciclo errore, vedi Cook, Richard I. & Woods, David. (1994). Operating at the Sharp End: The Complexity of Human Error. Human Error in Medicine. 255-310.
[3] Come, ad esempio, il legislatore europeo di premura di fare nel Reg.(UE) 2022/2554 (il cd. DORA).
[4] https://publications.jrc.ec.europa.eu/repository/handle/JRC134461
[5] https://www.enisa.europa.eu/publications/health-threat-landscape.
[6] Dir. (UE) 2016/1148 (NIS)
[7] Dir.(UE) 2022/2555 (NIS2)
[8] Alla categoria settore sanitario l’Allegato.1 al punto 5 la dir. (UE) 2022/2555 include infatti —Prestatori di assistenza sanitaria quali definiti all’articolo 3, lettera g), della direttiva 2011/24/UE del Parlamento europeo e del Consiglio —Laboratori di riferimento dell’UE quali definiti all’articolo 15 del regolamento (UE) 2022/2371 del Parlamento europeo e del Consiglio — Soggetti che svolgono attività di ricerca e sviluppo relative ai medicinali quali definiti all’articolo 1, punto 2), della direttiva 2001/83/CE del Parlamento europeo e del Consiglio — Soggetti che fabbricano prodotti farmaceutici di base e preparati farmaceutici di cui alla sezione C, divisione 21, della NACE Rev. 2 — Soggetti che fabbricano dispositivi medici considerati critici durante un’emergenza di sanità pubblica (elenco dei dispositivi critici per l’emergenza di sanità pubblica) di cui all’articolo 22 del regolamento (UE) 2022/123 del Parlamento europeo e del Consiglio
[9] https://docs.italia.it/AgID/documenti-in-consultazione/lg-procurement-ict/it/bozza/indicazioni-per-le-amministrazioni.html#azioni-da-svolgere-prima-della-fase-di-procurement
[10] https://docs.italia.it/AgID/documenti-in-consultazione/lg-procurement-ict/it/bozza/indicazioni-per-le-amministrazioni.html#azioni-da-svolgere-durante-la-fase-di-procurement.
[11] Potrà qui richiamare le clausole standard per il procurement di IA proposte dalla Commissione Europea nel 2023: https://www.dataguidance.com/news/eu-commission-publishes-updated-draft-model-contractual.
[12] Rif . RIA, All.III pt.5, lett.a).
[13] Rif . RIA, All.III pt.5, lett.d).
[14] Rif. RIA art, 3, n.3
[15] Rif. RIA art, 3, n.4
