Non vi è alcun dubbio che la sanità sia uno dei settori in cui l’utilizzo di sistemi di intelligenza artificiale sia in forte crescita.
Come non vi è dubbio che si ha piena consapevolezza circa il fatto che tale crescita presenti grandi potenzialità ma, anche, grandi rischi.
Sotto questo profilo, la recente Proposta di Regolamento della Commissione UE sulla Intelligenza artificiale (che al momento è in discussione al Consiglio UE e che dovrà passare ora in prima lettura al Parlamento Europeo), rappresenta senza dubbio un un framework legislativo che potrà aumentare la fiducia e la sicurezza nell’utilizzo di queste tecnologie nella cura dei pazienti.
Indice degli argomenti
Intelligenza artificiale e software medicali: il quadro normativo
E’, però, di assoluto rilievo evidenziare che già l’attuale quadro normativo applicabile ai software medicali appare piuttosto strutturato e, quindi, in grado sin da ora – ove correttamente applicato – di fornire un buon livello di sicurezza ed affidabilità sia a chi produce sistemi di AI che a chi li utilizza.
I tre grandi temi da affrontare sono, infatti:
- sicurezza ed affidabilità del software
- corretta gestione dei dati
- eticità delle funzionalità del software
Temi, questi, che trovano già oggi una loro prima disciplina nei seguenti Regolamenti, Linee Guida e Documenti:
- MDR – Reg. Ue 2017/745 sui dispositivi medici (2017)
- GDPR –Reg. Ue 2016/679 sulla protezione dei dati (2016)
- Linee Guida Ethics Guidelines for Trustworthy Artificial Intelligence (2019) del “High-Level Expert Group on AI”
- Documento Oms Ethics and governance of artificial intelligence for health (28 giugno 2021).
Si tratta, in sostanza, di un primo framework normativo sul quale andrà ad “appoggiarsi” il futuro Regolamento sull’Intelligenza Artificiale.
Vediamo, allora, quali sono i profili più rilevanti di tali discipline in relazione ai software di AI utilizzati in sanità.
Quando un software è classificato come dispositivo medico
Il recente MDR (Reg. Ue 2017/745 sui dispositivi medici) – che introduce una nuova disciplina in materia di dispositivi medici – impatta fortemente nell’ambito dei software di area medicale.
In primo luogo, il MDR meglio definisce quando un software rientra nella nozione di medical device (Software As Medical Device – SAMD), chiarendo che tutti i software che hanno finalità di diagnosi e cura e altresì i software che supportano l’operatore sanitario ad assumere una decisione terapeutica oppure aiutano l’erogazione della prestazione stessa devono farsi rientrare nella nozione di dispositivo medico (art. 2 lett. a e Allegato VIII regola 11).
Sulla nuova classificazione del software è stata poi emanata una specifica linea guida dal Medical Device Coordination Group (la “MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745”).
SAMD: quasi sempre, non basta la Dichiarazione di Conformità
Mentre, in vigenza della precedente dir 93/42/CEE, i software rientravano per lo più nella Classe di Rischio I (e, quindi, venivano immessi in commercio solo con la Dichiarazione di Conformità del fabbricante – che è un’autodichiarazione), oggi le nuove regole di Classificazione introdotte dal MDR spostano quasi tutti i SAMD nelle Classi IIa, IIb e III: ne consegue che il processo per l’apposizione della marcatura CE, obbligatoria per l’immissione in commercio, deve passare attraverso il vaglio di un Organismo Notificato (c.d. NB) che controlla il rispetto da parte del software dei Requisiti Generali di Sicurezza e Prestazione (RGSP), indicati nell’Allegato I del MDR.
Software di AI in ambito sanitario: i profili da migliorare
In ragione di tale allargamento dell’attività degli NB e dell’importante crescita di software di AI in ambito sanitario, la European Association Medical Devices – Notified Bodies ha emanato il 6 ottobre 2021 un Position Paper nel quale si suggerisce al Legislatore del nuovo Regolamento AI il miglioramento di alcuni profili oggi in discussione.
In particolare:
- un corretto coordinamento tra requisiti del MDR e quelli del Regolamento AI;
- la necessità di adattare le norme armonizzate o le specifiche comuni per garantire che gli organismi notificati siano in grado di attuare un processo di valutazione della conformità equo e trasparente;
- l’emanazione di una guida specifica per l’industria per l’implementazione del regolamento sull’IA in coordinamento al quadro esistente in materia di New Legislative;
- in relazione all’art. 10 della Proposta AI “Dati e governance dei dati”, si richiede che i dati siano “completi, accurati e sufficientemente giustificati”, tenuto conto che i Real World Data (fondamentali per l’AI) sono, nella maggior parte dei casi, poco precisi e non privi di errori.
Infine, il MDR prevede, in via generale, che il rispetto dei RGSP dell’Allegato I sia provato attraverso una Valutazione Clinica (art. 61 e seg. MDR) idonea a dimostrare non solo la sicurezza del medical device ma, anche, il suo beneficio clinico.
Per quanto riguarda, nello specifico, la valutazione clinica del software, il MDCG ha emanato le seguenti due apposite linee guida:
- MDCG 2019-16 Guidance on Cybersecurity for medical devices
- MDCG 2020-1 Guidance on Clinical Evaluation (MDR)/Performance Evaluation (IVDR) of Medical Device Software.
GDPR e sistemi di intelligenza artificiale
Seppure l’applicazione del GDPR (Reg. Ue 2016/679 sulla protezione dei dati) ai sistemi di AI presenti aree critiche (si veda da ultimo EDPB-EDPS Joint Opinion 5/2021 on the proposal of Regulation on artificial intelligence), è altrettanto vero che l’impianto generale del GDPR fornisce già una serie di possibili risposte.
Cardine dell’intero GDPR è l’art. 5 sui principi di trattamento.
Tale articolo prevede che i dati debbano essere trattati in modo “corretto” e “trasparente” nei confronti dell’interessato (art. 5 lett. a) e che i dati debbano essere “esatti” ed “aggiornati” (art. 5 lett. d) .
Nell’ambito dell’Intelligenza Artificiale, tali principi – correttezza, trasparenza ed esattezza dei dati – dovranno essere letti in strettissima connessione tra loro.
Vediamo come interpretare al meglio ognuno di questi principi.
Il principio di esattezza del dato
Tale principio impone (in generale) che ogni dato trattato sia esatto e che siano adottate tutte le misure ragionevoli e necessarie per la rettifica dei dati inesatti. Nel campo dell’AI, l’esattezza del dato deve essere vista come necessità iniziale e obiettivo finale, così che l’esattezza rappresenti la caratteristica fondamentale dell’intero percorso del dato stesso.
L’ “intelligenza” di una macchina dipende, infatti, dalle informazioni con cui essa è alimentata e che la stessa processa: se, quindi, si forniscono alla macchina dati scorretti o non precisi, questa restituirà risultati scorretti e non precisi. Ciò sia nel caso in cui il sistema si limiti a restituire dati mediante un processo di input–output, sia, a maggior ragione, ove il sistema sia in grado di imparare ed evolvere sulla base dei dati che conosce e tratta.
Il principio di correttezza
Tale principio coinvolge, invece, il processo di trattamento stesso che, nei sistemi di AI, deve coprire anche gli aspetti di natura etica.
Molto correttamente l’ICO (Information Commisioner’s Office) – nella Guidance on AI e data protection (parte relativa a How do the principles of lawfulness, fairness and transparency apply to AI?), afferma testualmente:
“… if you use an AI system to infer data about people, in order for this processing to be fair, you need to ensure that:
- the system is sufficiently statistically accurate and avoids discrimination; and
- you consider the impact of individuals’ reasonable expectations.”
I due semplici richiami all’evitare discriminazioni e al rispetto della “ragionevole aspettativa” dell’interessato sembrano racchiudere molti degli aspetti relativi all’eticità del software di AI. Ne deriva che il pieno rispetto del principio di correttezza dei dati di cui all’art. 5 GDPR comporta – in sostanza – il rispetto dei principi di eticità del trattamento.
Il principio di trasparenza
L’intero processo deve poi essere trasparente, nel senso che l’interessato dovrebbe essere nelle condizioni di potere capire come i dati e le informazioni vengono processati.
Per quanto riguarda l’AI, l’art. 13 comma 2 lett. f) sancisce l’obbligo in capo al titolare di fornire informazioni in relazione alla “esistenza di un processo decisionale automatizzato, compresa la profilazione di cui all’articolo 22, paragrafi 1 e 4, e, almeno in tali casi, informazioni significative sulla logica utilizzata, nonché l’importanza e le conseguenze previste di tale trattamento per l’interessato”.
Senza sminuire la difficoltà applicativa della norma, è chiaro che già il GDPR si è posto l’obiettivo di stabilire regole di trasparenza molto chiare nel caso di sistemi complessi come quelli di Intelligenza Artificiale, ritenendo che solo ciò che è trasparente è valutabile e, quindi, passibile di fiducia e di affidamento da parte del singolo interessato e della collettività.
Privacy by design e by default
L’intero processo poi – non solo la progettazione del sistema di AI ma anche il suo utilizzo – deve essere realizzato sotto l’ombrello di un’altra norma cardine del GDPR: l’art. 25 GDPR sui principi di privacy by design e by default.
Vale a dire che, ancor prima dell’inizio del trattamento e già in fase di progettazione del sistema, occorre pensare e definire finalità ed obiettivi del trattamento, individuando i dati che occorrono per raggiungere tali finalità, stabilendo quali dati sono indispensabili, nonché prevedendo il funzionamento del sistema e definendo le regole di comportamento dell’uomo che opera sul sistema.
Ne consegue che i concetti di privacy by design e by default precedono ed accompagnano (in termini concettuali e temporali) il rispetto dei principi di esattezza, correttezza e trasparenza.
Il confronto tra rischi e benefici del trattamento
L’art. 35 – inoltre – prevede l’obbligo di effettuare una Valutazione d’Impatto sulla protezione dei dati (c.d. DPIA), ossia un’ analisi del rischio che può comportare quel trattamento di dati ed una valutazione di proporzionalità tra rischi esistenti e benefici dal trattamento.
I criteri di misurazione del rischio dovranno poi tenere in considerazione non solo i parametri RID (Riservatezza, Integrità e Disponibilità), ma anche il possibile impatto sugli altri diritti fondamentali delle persona fisica, tutelati dalla Costituzione e dalle fonti europee e sovranazionali (si veda, sul punto: Guidelines on Data Protection Impact Assessment (DPIA).
Nel caso di un sistema di AI, un esempio potrebbe essere il principio di non discriminazione che dovrà essere valutato in fase di test e programmazione dell’algoritmo per verificare che non siano stati rivenuti valori discriminatori embedded nel codice stesso, indicando le eventuali misure correttive ove tale rischio si presentasse in fase di utilizzo del sistema di IA (si veda anche, per un approfondimento: The Data Protection Impact Assessment as a Tool to Enforce Non-Discriminatory AI).
Etica ed Intelligenza Artificiale
Quanto detto fino ad ora si collega al tema del rapporto tra etica ed Intelligenza Artificiale: questo sarà, come sappiamo, il punto focale di tutta la futura attività regolatoria dell’UE in materia di IA.
Lo sviluppo di sistemi di IA dovrà quindi rispettare una serie di principi di natura etica, tra cui, ad esempio, l’assenza di discriminazioni e di distorsioni.
La Data Protection Impact Assessment (DPIA), quindi, può rappresentare uno strumento utile, sin da ora, anche per misurare l’eticità del software in relazione alle attuali indicazioni del “High-Level Expert Group on Artificial Intelligence” (AI HLEG) che, tra l’altro, ha fornito un tool di self-assessment sull’affidabilità dell’Intelligenza Artificiale.
Si tratta di una checklist che è stata ideata per fornire un aiuto pratico a tutti i soggetti che operano nel mercato dello sviluppo di sistemi di IA sulla base dei principi contenuti nelle sopracitate linee guida “Ethics Guidelines for Trustworthy Artificial Intelligence”.
