I gemelli digitali in sanità promettono di simulare la progressione delle malattie e di personalizzare le cure. Ma il gemello digitale di un paziente è, prima di tutto, un trattamento di dati sanitari su larga scala: quando i dati sintetici restano dati personali? Chi è titolare in un’architettura federata? E cosa accade ai dati dei defunti? Le riflessioni che seguono riprendono e sviluppano il nostro contributo, quale esperto AI & Data Protection, a un workshop europeo dello scorso marzo 2026 dedicato agli ambienti decentralizzati di gemelli digitali.
Nello scorso marzo 2026 abbiamo avuto il piacere di contribuire, quale esperto AI & Data Protection, a un workshop europeo dedicato all’etica e all’implementazione degli ambienti decentralizzati di gemelli digitali in sanità. Riteniamo utile condividere in questa sede, in forma rielaborata, alcune delle riflessioni svolte in quel contesto, poiché il c.d. Decentralised Digital Twin Environment – DDTE mette alla prova, in modo esemplare, l’intero diritto europeo del digitale: vi convergono, simultaneamente, GDPR, AI Act, NIS 2 e il Regolamento sullo Spazio europeo dei dati sanitari – EHDS.
Non potenza di calcolo, ma maturità di governance
La prima domanda posta dal progetto riguardava le capacità tecniche necessarie per aderire a un ambiente decentralizzato di gemelli digitali. La nostra risposta muove da una premessa: quando si discute dei requisiti per partecipare a una simile infrastruttura, la questione attiene meno alla potenza computazionale e più alla maturità di governance. Le infrastrutture di ricerca partecipanti, università, centri di ricerca, ospedali, devono poter dimostrare un impianto di trattamento dei dati conforme al GDPR, la capacità di conservare i dati localmente in ambienti sicuri, con controlli di accesso, logging e procedure aggiornate, e l’adozione di interfacce e formati standardizzati per l’interoperabilità: API documentate, metadati allineati ai principi FAIR, ontologie condivise. Non tutte le infrastrutture avranno il medesimo grado di preparazione, ed è fisiologico: ciò che serve è una definizione di requisiti minimi di ingresso e di percorsi di progressione, rispetto ai quali standard volontari quali lo Standard ISO/IEC 27001 e lo Standard ISO/IEC 42001 possono fungere da parametro di riferimento, senza che la certificazione divenga condizione obbligatoria di partecipazione.
Il nodo dei dati sintetici: quando l’anonimo non è anonimo
Il gemello digitale produce dati sintetici a partire da dati reali di pazienti. La domanda decisiva è se tali dati sintetici siano genuinamente anonimi ai sensi del Considerando 26 del GDPR, per il quale i principi di protezione dei dati non si applicano alle «informazioni anonime, vale a dire informazioni che non si riferiscono a una persona fisica identificata o identificabile o a dati personali resi sufficientemente anonimi da impedire o da non consentire più l’identificazione dell’interessato».
Infatti, se il modello generativo è stato addestrato su dati reali, il rischio di memorizzazione del modello potrebbe consentire di estrarre informazioni riconducibili a soggetti determinati: in tal caso i dati sintetici resterebbero, a tutti gli effetti, dati personali. Tra le tecniche di mitigazione vi è la differential privacy, che introduce rumore controllato nei dati di addestramento, ma comporta un trade-off con l’accuratezza del modello, circostanza che deve essere documentata nella valutazione d’impatto ex articolo 35 del GDPR.
A ciò si aggiunge il rischio di reidentificazione da fonti esterne. Esistono già in Europa infrastrutture federate di dati sanitari; se un sistema di IA sufficientemente sofisticato, e oggi si parla anche di agentic AI, sistemi autonomi capaci di interrogare più fonti e correlare dati, fosse in grado di incrociare il profilo di un gemello digitale con i dati disponibili in tali spazi, il rischio di ricostruire l’identità del paziente diverrebbe concreto. È il c.d. linkage attack della letteratura in materia di privacy: uno scenario che, a nostro avviso, deve entrare espressamente nella DPIA.
Locale e federato: il discrimine è giuridico, non tecnico
Quali informazioni devono rimanere locali e quali possono essere federate? La linea di demarcazione dovrebbe essere guidata dai principi di protezione dei dati, non dalla convenienza tecnica. Devono rimanere locali i dati sanitari in forma identificabile o pseudonimizzata, in ossequio al principio di minimizzazione ex articolo 5, paragrafo 1, lettera c), del GDPR, oltre a registri dei consensi, gestione delle identità, log di accesso e capacità di risposta agli incidenti, tenuto conto che l’articolo 33 del GDPR impone la notifica delle violazioni entro 72 ore, mentre la NIS 2 richiede un primo allertamento entro 24 ore. Possono invece essere federati i parametri aggregati dei modelli, i dataset genuinamente anonimizzati ai sensi del Considerando 26, i metadati di governance e la documentazione di conformità delle componenti di IA: l’architettura ad apprendimento federato, in cui a viaggiare sono i parametri del modello e non i dati grezzi, è intrinsecamente allineata a questa impostazione. Il punto critico resta, ancora una volta, il dato sintetico: se conserva una qualsiasi traccia di reidentificabilità, è dato personale e non può circolare come se fosse anonimo.
La catena delle responsabilità nell’architettura federata
Vi è poi il nodo dei ruoli. Il GDPR distingue titolare (articolo 24), contitolari (articolo 26) e responsabile del trattamento (articolo 28); ma in un’architettura federata, dove il dato non si muove e si muove il modello, le qualificazioni non sono affatto scontate. Se più infrastrutture di ricerca collaborano all’addestramento di un modello federato determinandone congiuntamente finalità e mezzi, si configura una contitolarità, che esige un accordo trasparente. L’AI Act, a sua volta, distingue gli obblighi del fornitore da quelli del deployer (articoli 16 e 26): in un progetto di ricerca tali ruoli spesso si sovrappongono, e il medesimo partner può essere, a un tempo, fornitore di dati, sviluppatore del modello e utilizzatore.
Sul piano delle garanzie e delle approvazioni, il quadro è denso: DPIA ex articolo 35 e, in caso di rischio residuo elevato, consultazione preventiva dell’autorità ex articolo 36 del GDPR; valutazione d’impatto sui diritti fondamentali ex articolo 27 dell’AI Act per i sistemi ad alto rischio; parere del comitato etico ove richiesto dal diritto nazionale; autorizzazione dell’organismo di accesso ai dati sanitari secondo il capo IV dell’EHDS per l’uso secondario dei dati sanitari elettronici. E ancora, sul piano contrattuale: accordi di contitolarità, accordi ex articolo 28 con i fornitori cloud, clausole su qualità dei dati, limitazione delle finalità e proprietà intellettuale del modello federato, frutto, per definizione, di contributi distribuiti.
Un punto di attenzione: i campioni biologici dei defunti
Desideriamo infine richiamare l’attenzione su un profilo spesso trascurato. Il GDPR, al Considerando 27, esclude dal proprio ambito i dati delle persone decedute, rinviando ai diritti nazionali. Tuttavia, i dati genetici ricavati da campioni biologici di defunti contengono informazioni sui familiari viventi, i quali sono pienamente protetti dal Regolamento. Il consenso originario copriva l’impiego per la generazione di gemelli digitali? I familiari viventi hanno un diritto di informazione o di opposizione? Sono interrogativi che, a nostro avviso, devono trovare risposta nei contratti e nella governance del progetto, prima che nei contenziosi.
Conclusioni
Il gemello digitale sanitario condensa in un solo oggetto tutte le tensioni del diritto europeo del digitale: la promessa della medicina personalizzata e il rischio della reidentificazione, la spinta alla condivisione federata e il principio di minimizzazione, la stratificazione di GDPR, AI Act, NIS 2 ed EHDS su un’unica infrastruttura. Trattare ciascun regolamento come un adempimento separato sarebbe un errore: serve un approccio modulare e integrato, fondato su una base comune e capace di mappare i requisiti nazionali aggiuntivi che l’articolo 9, paragrafo 4, del GDPR consente agli Stati membri per i dati genetici, biometrici e sanitari.
Alla luce di quanto esposto, ci si domanda se la fiducia del paziente, che è la vera infrastruttura critica di ogni ecosistema di dati sanitari, potrà fondarsi sul solo rispetto formale delle norme, o se non richieda piuttosto una trasparenza e un coinvolgimento effettivi. Governare il gemello digitale significa, in definitiva, tenere insieme la protezione della persona e quella della sua replica digitale, là dove l’una e l’altra toccano l’essenza stessa dell’identità.