Abstract

La sanità digitale non è più una somma di progetti informatici, né può essere governata attraverso una successione di adempimenti separati. Il dato sanitario è contemporaneamente presupposto della cura, documento, bene informativo, oggetto di tutela, risorsa per la ricerca, input per sistemi di intelligenza artificiale ed elemento probatorio della responsabilità clinica e organizzativa. Da questa convergenza nasce un ecosistema normativo nel quale GDPR, European Health Data Space, NIS2, eIDAS, Codice dell’amministrazione digitale, disciplina del Fascicolo sanitario elettronico, Data Act, Data Governance Act, MDR, IVDR, AI Act e legge italiana n. 132/2025 devono essere letti secondo una logica integrata. Il presente contributo si propone di fornire una mappa orientativa e operativa – aggiornata alla luce delle modifiche introdotte dal Regolamento (UE) 2026/1744, il Digital Omnibus on AI – rivolta in particolare a DPO e Responsabili della conservazione, ma anche a legali, CISO, risk manager e responsabili degli acquisti di strutture sanitarie. La tesi di fondo che ha guidato la stesura del presente contributo è che la compliance del futuro digitale per le organizzazioni sanitarie pubbliche e private non sarà la somma algebrica degli adempimenti contenuti in autonomi impianti normativi, ma la capacità di dimostrare che dati, documenti, infrastrutture, dispositivi, algoritmi e decisioni cliniche sono governati lungo l’intero ciclo di vita da team interdisciplinari[1].

---

[1] Il presente saggio è stato redatto attraverso una rielaborazione affidata a Copilot Microsoft 365 di una mia relazione sviluppata in data 22 luglio 2026 in favore di Polimi School of Management dal titolo “L’uso etico e giuridicamente corretto dell’IA nelle strutture sanitarie: i ruoli e le responsabilità mediche”. Naturalmente il testo è stato rivisto, completato e controllato in ogni dettaglio.

 

 

La sanità digitale come ecosistema di responsabilità

La digitalizzazione della sanità non può più essere letta come un mero processo di dematerializzazione documentale o di efficientamento amministrativo. Essa, infatti, modifica l’organizzazione della cura, il rapporto medico-paziente, la responsabilità professionale, la circolazione delle informazioni, la sicurezza dei servizi e, quindi, l’intera formazione della decisione clinica.

La struttura sanitaria contemporanea ormai non gestisce soltanto prestazioni di carattere medico: gestisce dati, cartelle cliniche elettroniche, fascicoli sanitari elettronici, dossier, repository, piattaforme di telemedicina, servizi cloud, dispositivi medici, soluzioni software di gestione informativa e documentale, sistemi di supporto decisionale e naturalmente strumenti di intelligenza artificiale generativa e agentica sino alla robotica.

La conseguenza è semplice da enunciare, ma difficile da tradurre in efficace organizzazione: non basta essere conformi, separatamente, a eIDAS, al GDPR, alla NIS2 o all’AI Act, oltre a tutto il resto. Occorre dimostrare che l’intero processo digitale sia giuridicamente fondato, clinicamente appropriato, tecnicamente sicuro, documentato, contrattualmente governato e verificabile.

Il dato sanitario è divenuto infrastruttura della cura. Se è incompleto, inesatto, non aggiornato, non reperibile o non interoperabile, in poche parole se non è di qualità, può compromettere la continuità assistenziale, generare duplicazioni, ritardi, errori e output algoritmici inaffidabili.

Un FSE (Fascicolo Sanitario Elettronico) incompleto non è quindi soltanto un disservizio informatico: in determinate condizioni può diventare un vero e proprio difetto organizzativo, capace di incidere sul diritto alla salute e sulla responsabilità della struttura[1].

È opportuno, perciò, abbandonare lo schema lineare privacy, sicurezza, digitalizzazione documentale e cura del paziente. La sequenza più aderente alla realtà è un’altra: governance del dato sanitario, governance del documento informatico, governance dell’algoritmo, governance del rischio clinico. Queste dimensioni non coincidono del tutto ovviamente, ma si condizionano reciprocamente. La protezione della persona/paziente non richiede soltanto che il dato non sia visionato da chi non ne ha diritto; richiede anche che il dato corretto sia disponibile e che sia anche integro, comprensibile a chi deve curare e interoperabile tra diversi sistemi informativi e di gestione documentale.

 

La mappa normativa: norme diverse, medesimo processo

Il GDPR resta il baricentro della protezione dei dati personali e della loro libera circolazione in ambienti controllati. I dati relativi alla salute sono categorie particolari ai sensi dell’art. 9 e il loro trattamento richiede una base giuridica e una condizione di liceità, oltre al rispetto dei principi di finalità, minimizzazione, esattezza, limitazione della conservazione, integrità, riservatezza e accountability. Il cd. “Codice privacy” completa il quadro nazionale, integrando il regolamento UE soprattutto in materia sanitaria e di ricerca.

A livello europeo, il Regolamento (UE) 2025/327 sullo European Health Data Space (EHDS), entrato in vigore il 26 marzo 2025, non sostituisce ovviamente il GDPR, ma lo integra nello spirito legato alla libera circolazione dei dati, principio espresso già nell’intestazione dello stesso GDPR. L’EHDS costruisce un quadro settoriale per l’accesso e il controllo delle persone sui dati sanitari elettronici, per il loro uso primario nella cura, per il riuso secondario a beneficio della ricerca, dell’innovazione, delle politiche sanitarie e delle attività regolatorie, nonché per un mercato europeo più interoperabile dei sistemi di cartella clinica elettronica e FSE. La sua applicazione è progressiva: il regolamento si applica in via generale dal 26 marzo 2027, mentre nuclei importanti relativi alle categorie prioritarie di dati e al riuso secondario diverranno operativi secondo le scadenze del 2029 e del 2031. Questa gradualità non giustifica un’attesa per le strutture sanitarie, infatti le architetture informative, i contratti e i sistemi documentali acquistati oggi produrranno effetti proprio nel periodo di piena applicazione dell’EHDS. Inoltre, collegato funzionalmente al EHDS, il Data Governance Act disciplina, tra l’altro, il riutilizzo di alcune categorie di dati protetti detenuti da enti pubblici, i servizi di intermediazione e l’altruismo dei dati.

Il Data Act incide, invece, sull’accesso e sull’uso dei dati generati dai prodotti connessi e dai servizi correlati, con riflessi evidenti su wearable, sensori, apparecchiature sanitarie e dispositivi medici connessi. Non ogni dato generato da un dispositivo è personale, ma quando lo è resta necessario coordinare il Data Act con il GDPR.

La NIS2, recepita in Italia dal d.lgs. 4 settembre 2024, n. 138, in vigore dal 16 ottobre 2024, coinvolge il settore sanitario e rafforza la responsabilità degli organi di gestione, la gestione del rischio, la sicurezza della supply chain, la continuità operativa e la notifica degli incidenti. Non c’è contrapposizione o reale sovrapposizione NIS2 e GDPR. Il GDPR considera sicurezza e protezione dei dati in funzione dei diritti e delle libertà delle persone; la NIS2 tutela la resilienza delle reti, dei sistemi e dei servizi essenziali o importanti per il nostro Sistema Paese[2]. In un ospedale, tuttavia, l’indisponibilità di una cartella clinica può costituire contemporaneamente un incidente cyber, una violazione di dati personali, un rischio clinico e una disfunzione organizzativa.

Il Regolamento eIDAS, come modificato dal Regolamento (UE) 2024/1183, il CAD (Codice dell’amministrazione digitale) e le Linee guida AgID sulla formazione, gestione e conservazione dei documenti informatici presidiano identità digitale, firme, sigilli, riferimenti temporali, documenti informatici, gestione e conservazione.

MDR (Regolamento UE 2017/745 del 5 aprile 2017 relativo ai dispositivi medici), e IVDR (Regolamento UE 2017/746 del 5 aprile 2017, relativo ai dispositivi medico-diagnostici in vitro) governano i dispositivi medici e diagnostici in vitro, inclusi molti software con finalità medica. La legge n. 24/2017 e la legge n. 219/2017 restano centrali per responsabilità sanitaria e consenso informato.

L’AI Act e la legge italiana 23 settembre 2025, n. 132 aggiungono il “livello algoritmico”, pur se l’art. 22 del GDPR ne aveva già tracciato i principi giuridici fondamentali dal punto di vista della liceità nel trattamento dei dati.

Ebbene, il risultato appena descritto non è un mosaico da contemplare, ma un sistema da governare.

Dal consenso come feticcio alla responsabilità come metodo

Il consenso è uno dei concetti più fraintesi della sanità digitale. Consenso informato all’atto sanitario e consenso al trattamento dei dati sono istituti diversi, con funzioni e presupposti differenti. Il primo tutela autodeterminazione, libertà di cura e integrità psicofisica della persona. Il secondo costituisce una delle possibili basi giuridiche del GDPR, ma nel trattamento ordinario per diagnosi, cura, assistenza, medicina preventiva e gestione dei sistemi sanitari non rappresenta normalmente il fondamento principale.

L’errore culturale consiste nel pensare che ogni complessità possa essere risolta con un modulo burocratico. Un paziente può avere firmato il consenso informato e ricevuto un’informativa privacy astrattamente completa, ma essere ugualmente inserito in un ecosistema opaco, fondato su dati incompleti, accessi eccessivi e non ben presidiati, piattaforme insicure o algoritmi non ben governati.

La proliferazione dei consensi rischia così di diventare l’alibi di una cattiva organizzazione. La tutela deve spostarsi sul terreno più corretto: basi giuridiche precise, informazione effettiva, esattezza, minimizzazione, tracciabilità, sicurezza, controllo degli accessi, pseudonimizzazione, valutazioni d’impatto (lato GDPR o AI Act), quando necessarie, e responsabilità dimostrabili.

L’IA introduce, poi, una terza domanda. Non basta verificare se il paziente abbia accettato l’atto sanitario e se il trattamento dei dati personali sia lecito. Occorre chiedersi se sia appropriato affidarsi a quel sistema IA, verificare chi ne controlla gli output, controllare quali limiti siano noti, come il medico possa contestarne il risultato e chi debba rispondere di progettazione, integrazione, formazione, manutenzione e uso di tali sistemi o modelli di IA.

La trasparenza algoritmica non coincide né con il consenso informato né con l’informativa privacy. È conoscibilità da parte della struttura sanitaria con i suoi operatori del ruolo svolto dalla macchina nel processo di cura.

Uso primario e riuso secondario: il dato non è una zona franca

L’uso primario riguarda il trattamento dei dati per la cura della persona: prevenzione, diagnosi, terapia, riabilitazione, continuità assistenziale. Il riuso secondario riguarda finalità ulteriori, quali ricerca, innovazione, rilevazioni statistiche, gestione della programmazione sanitaria, valutazione della qualità, attività regolatorie e sviluppo o validazione di sistemi di IA.

La distinzione è decisiva perché mutano finalità, basi giuridiche, garanzie da predisporre, ruoli e modalità di accesso da organizzare.

L’EHDS istituzionalizza il riuso attraverso organismi di accesso ai dati sanitari, permessi e ambienti sicuri di trattamento. Non legittima, però, un libero prelievo di dati clinici. La formula del “miglioramento del servizio” non può essere considerata una base giuridica; l’“innovazione” non è una finalità sufficientemente determinata; l’anonimizzazione non può essere soltanto dichiarata, ma deve essere resa effettiva e verificabile nel tempo; la pseudonimizzazione riduce senz’altro i rischi del trattamento, ma non sottrae automaticamente i dati sanitari all’applicazione del GDPR.

Ogni progetto di innovazione digitale in sanità deve chiarire quali dati siano davvero necessari, se non indispensabili, chi li deve detenere, chi ne può chiedere l’accesso, per quale finalità, con quali garanzie, per quanto tempo e con quale possibilità di controllo.

La legge n. 132/2025 conferma una logica antropocentrica, trasparente e responsabile e disciplina, all’art. 8, specifiche ipotesi di trattamento e uso secondario dei dati nell’ambito della ricerca e della sperimentazione di sistemi di IA in sanità[3]. Anche quando l’ordinamento consente in qualche modo il trattamento per ricerca o interesse pubblico senza un nuovo consenso individuale, non scompare l’accountability. Al contrario, diviene fondamentale garantire i principi di proporzionalità e trasparenza, così come la predisposizione di misure di sicurezza adeguate, con segregazione degli ambienti, controllo accessi e valutazione dei rischi.

Come ho sostenuto a proposito della sperimentazione clinica, il problema di oggi nella sanità non è scegliere astrattamente tra privatizzazione della conoscenza e circolazione incontrollata, bensì costruire alleanze costituzionali capaci di conciliare protezione, ricerca e fondamentale diritto alla salute[4].

AI Act, legge italiana e Digital Omnibus: che cosa cambia davvero

L’AI Act adotta un approccio basato sul rischio. In ambito sanitario, non ogni software è IA e non ogni sistema di IA è ad alto rischio. La qualificazione richiede di verificare la definizione dell’art. 3, la destinazione d’uso, il contesto operativo e l’eventuale collegamento con prodotti soggetti alla normativa di armonizzazione. Molti sistemi diagnostici o di supporto clinico possono essere contemporaneamente sistemi di IA, dispositivi medici e sistemi ad alto rischio, soprattutto quando costituiscono un prodotto o un componente di sicurezza soggetto a valutazione di conformità da parte di terzi.

Occorre correggere due semplificazioni. La prima, secondo cui la marcatura CE esaurisce ogni verifica da parte della struttura sanitaria, deve essere sconfessata, in quanto, per garantire la conformità complessiva alle normative applicabili, restano da verificare la protezione dei dati, la sicurezza, l’idoneità al contesto clinico, la formazione, la sorveglianza umana, la gestione documentale e il rispetto degli obblighi gravanti sul deployer (ruolo normalmente proprio della struttura sanitaria). La seconda semplificazione ritiene che l’AI Act trasferisca la decisione alla macchina: al contrario, il regolamento pretende un’IA affidabile e antropocentrica. La legge italiana n. 132/2025, in vigore dal 10 ottobre 2025, conferma, in ambito sanitario, la funzione di supporto dell’IA e la permanenza della decisione in capo al professionista sanitario.

Il Regolamento (UE) 2026/1744, anche noto come Digital Omnibus on AI, è entrato in vigore il 27 luglio 2026. Ha differito l’applicazione del complesso degli obblighi relativi ai sistemi ad alto rischio dell’Allegato III al 2 dicembre 2027 e degli obblighi per i sistemi ad alto rischio incorporati nei prodotti dell’Allegato I al 2 agosto 2028. Inoltre, ha previsto un differimento mirato al 2 dicembre 2026 per determinati obblighi di marcatura dei contenuti generati o manipolati da sistemi già immessi sul mercato prima del 2 agosto 2026 e ha introdotto alcune semplificazioni, un maggiore sostegno a PMI e small mid-cap, possibilità più ampie di sperimentazione e ha altresì fornito alcuni chiarimenti di governance. Non ha però sospeso l’AI Act, né svuotato gli obblighi di trasparenza dell’art. 50 applicabili dal 2 agosto 2026, salvo lo specifico regime transitorio appena ricordato.

Per le strutture sanitarie, il rinvio non è una vacanza regolatoria. È tempo organizzativo da utilizzare per censire i sistemi, qualificare ruoli e rischi, negoziare contratti, formare gli operatori, predisporre logging e incident reporting, coordinare DPIA, FRIA, MDR e cybersecurity. Attendere passivamente fino al 2027 o al 2028 significherebbe arrivare alle nuove scadenze con tecnologie già integrate, dati già riutilizzati e rapporti contrattuali difficili da modificare, con il rischio da una parte di sanzioni per la struttura sanitaria, ma dall’altra parte, e soprattutto, di una gestione grossolana del proprio ecosistema digitale, esponendo i propri pazienti a pericoli elevatissimi.

Provider, deployer, titolare, responsabile: il rebus dei ruoli

Nel GDPR, i ruoli dipendono dalla determinazione effettiva di finalità e mezzi essenziali. Nell’AI Act il provider sviluppa o fa sviluppare il sistema e lo immette sul mercato o lo mette in servizio con il proprio nome; il deployer lo utilizza sotto la propria autorità.

Le qualificazioni tra le varie normative non si sovrappongono automaticamente. Una software house può essere provider ai sensi dell’AI Act e responsabile del trattamento per talune operazioni, titolare autonomo per altre, oppure contitolare in un progetto di sviluppo congiunto. La struttura sanitaria sarà spesso titolare del trattamento e deployer, ma il quadro deve essere sempre e costantemente verificato sul processo concreto di innovazione digitale.

Il fornitore è responsabile ex art. 28 GDPR quando tratta i dati per conto della struttura sanitaria secondo istruzioni documentate. Diviene, invece, titolare autonomo quando usa dati o metadati per proprie finalità, per esempio addestramento proprietario, benchmarking commerciale o sviluppo del prodotto non richiesto dal committente. Può emergere contitolarità quando finalità e mezzi essenziali sono determinati congiuntamente, come in alcune sperimentazioni o validazioni. Sono frequenti anche rapporti misti, nei quali la stessa parte svolge ruoli diversi per attività diverse, come peraltro chiarito dall’EDPB nelle sue Linee Guida sui ruoli del titolare e del responsabile. Il contratto non può appiattire questa realtà con una definizione di comodo.

Il medico, all’interno della struttura, è normalmente autorizzato al trattamento per operare sui sistemi informativi della struttura, ma può essere considerato titolare autonomo, oltre che sul piano clinico e deontologico, anche nel trattamento dei dati personali dei pazienti per il perseguimento di quelle finalità che gli competono. Non è di regola il deployer organizzativo, ma è il presidio umano che incontra l’output algoritmico. Deve quindi comprenderne il significato clinico, valutarne la plausibilità, riconoscere i limiti e potersi discostare dalla decisione della macchina. L’automation bias, cioè la tendenza ad attribuire alla macchina una correttezza presunta, è uno dei rischi più insidiosi dell’applicazione dell’IA nell’analisi clinica.

Più cresce il supporto algoritmico, più diventano necessarie competenza critica e tracciabilità della decisione umana.

DPIA e FRIA: dal rischio sul dato al potere dell’algoritmo

La DPIA, prevista dall’art. 35 GDPR, e la FRIA, disciplinata dall’art. 27 AI Act, sono strumenti distinti e complementari.

La prima valuta necessità, proporzionalità e rischi di un trattamento di dati personali, con particolare rilevanza per nuove tecnologie, dati sanitari su larga scala, monitoraggi e profilazioni automatizzate. In ambito sanitario, la DPIA è spesso necessaria per progetti di telemedicina, per la gestione del FSE, per sviluppare monitoraggio remoto, triage algoritmico, sistemi predittivi e piattaforme che elaborano dati clinici. La FRIA riguarda determinati deployer e sistemi di IA ad alto rischio e considera il modo in cui l’uso concreto può incidere sui diritti fondamentali.

La formula più utile per gestire questi fondamentali adempimenti è questa: la DPIA domanda che cosa accade ai dati personali minimizzando i rischi per gli interessati; la FRIA domanda che cosa accade alla persona a causa dell’algoritmo.

L’errore operativo per una struttura sanitaria sarebbe quello di produrre due documenti isolati nel momento in cui le due normative GDPR e AI Act si dovessero incrociare. Una valutazione integrata dovrebbe condividere descrizione del sistema, flussi, popolazioni interessate, scenari di danno, dati di input e output, supervisione, misure di sicurezza, log, reclami, incidenti e riesame. Va evitata, tuttavia, la fusione indistinta: finalità, basi normative, destinatari e obblighi delle due valutazioni restano differenti.

Il Data Protection Officer, ad esempio, deve essere coinvolto tempestivamente nella DPIA e offrire la propria consulenza, ma non può essere trasformato nel responsabile esclusivo della conformità dell’IA. La decisione e la responsabilità organizzativa restano in capo all’intera struttura sanitaria, che deve dotarsi di team interdisciplinari per organizzare questi adempimenti e renderli utili allo scopo per cui GDPR e AI Act li hanno previsti.

Conservazione digitale: la memoria del processo di cura

Per DPO e Responsabili della conservazione vi è un punto decisivo: nella sanità digitale la documentazione gestita nei fascicoli e correttamente conservata non è soltanto parte integrante della cura, ma è utile anche a produrre prove digitalmente rilevanti, anche dal punto di vista dell’accountability nella gestione documentale.

Cartelle cliniche, referti, log di accesso, consensi informati, output algoritmici rilevanti, annotazioni di medici e altri operatori sanitari, istruzioni d’uso, verbali di audit, ticket di anomalie, contratti e valutazioni d’impatto concorrono a ricostruire il processo documentale. Quindi, autenticità, integrità, affidabilità, leggibilità e reperibilità devono essere garantite fin dalla formazione e gestione di dati e documenti sanitari e non recuperate artificialmente alla fine. Il Responsabile della conservazione non decide la base giuridica ai fini privacy né la correttezza clinica dell’algoritmo, ma deve contribuire a definire quali evidenze vadano conservate, con quali metadati, per quali tempistiche di conservazione, in quali formati e con quali responsabilità all’interno delle varie fasi documentali. Il DPO, a sua volta, deve verificare che la conservazione non diventi accumulo indiscriminato e quindi deve contribuire a verificare che tempi, accessi e finalità del sistema documentale siano coerenti.

L’IA rende questa funzione più importante. Un output senza contesto, un log privo della versione del modello o una decisione senza traccia della supervisione umana possono risultare inutili o anche semplicemente non dimostrabili. La memoria deve documentare non solo il risultato, ma le condizioni nelle quali esso è stato prodotto. Senza memoria documentale non vi è accountability; senza accountability non vi è responsabilità effettiva in qualsiasi organizzazione pubblica o privata.

In un qualsiasi processo di innovazione digitale in ambito sanitario, il collegamento di GDPR e AI Act con eIDAS è, in questa prospettiva, strutturale. Il Regolamento (UE) 2024/1183 ha introdotto nel quadro eIDAS, infatti, il servizio fiduciario di archiviazione elettronica.

La disciplina europea definisce l’archiviazione elettronica come il servizio che assicura ricezione, conservazione, reperimento e cancellazione di dati e documenti elettronici, preservandone durabilità, leggibilità, integrità, riservatezza e prova dell’origine durante il periodo di conservazione.

Per i documenti e i dati sanitari conservati mediante un servizio qualificato opera una presunzione di integrità e correttezza dell’origine per la durata della conservazione. Non si tratta, dunque, di una semplice estensione dello spazio disponibile in un cloud, ma di un servizio fiduciario destinato a rendere affidabile nel tempo la memoria digitale della struttura sanitaria[5].

Nel sistema italiano, questa prospettiva europea deve essere coordinata con gli artt. 43 e 44 del CAD e con le Linee guida AgID sulla formazione, gestione e conservazione dei documenti informatici. Il sistema di conservazione garantisce autenticità, integrità, affidabilità, leggibilità e reperibilità dei documenti e delle aggregazioni documentali, insieme ai metadati associati. Questi requisiti non sono estranei alla qualità dei dati: ne costituiscono la dimensione documentale e temporale. Un dato clinico può essere formalmente corretto al momento della generazione, ma perdere affidabilità se non è più possibile ricostruirne origine, contesto, versione, autore, sequenza e modifiche[6].

Per questo la gestione documentale e la conservazione non devono essere collocate a valle del progetto di innovazione digitale in sanità. Devono entrare nella progettazione del processo: prima di adottare un sistema, DPO e Responsabile della conservazione dovrebbero verificare insieme quali oggetti abbiano rilevanza clinica, giuridica o probatoria; quali metadati siano necessari; quali eventi debbano essere registrati; quali formati garantiscano leggibilità e interoperabilità; quali tempi derivino da obblighi normativi, finalità di cura, difesa dei diritti e minimizzazione; come siano governati riversamenti, migrazioni, scarti ed esibizioni; quale continuità vada assicurata in caso di cessazione o sostituzione del fornitore.

Nell’IA sanitaria il punto diventa ancora più delicato. Non è utile conservare indiscriminatamente ogni dato tecnico, ma è necessario individuare le evidenze indispensabili per ricostruire una decisione: versione del sistema e del modello, istruzioni d’uso in vigore, input clinicamente rilevanti, output proposto, alert, intervento umano, eventuale dissenso del professionista, aggiornamenti, incidenti e misure correttive. La qualità del dato non coincide quindi con la sola esattezza semantica, essa deve comprendere provenienza, integrità, contestualizzazione, attualità, leggibilità, reperibilità e possibilità di dimostrarne l’affidabilità nel tempo.

Il DPO e il Responsabile della conservazione hanno funzioni diverse e non sovrapponibili. Il DPO sorveglia e consiglia in materia di protezione dei dati, valuta il rapporto tra tempi di conservazione, finalità, minimizzazione, diritti e sicurezza, e deve mantenere indipendenza nello sviluppo autorevole del suo ruolo. Il Responsabile della conservazione definisce e attua le politiche complessive del sistema di conservazione e ne governa la gestione secondo il modello organizzativo applicabile. La collaborazione tra le due figure, necessaria per coordinare la disciplina della protezione dei dati con le responsabilità organizzative delineate dal CAD e dalle Linee guida AgID, non significa confusione dei ruoli: significa impedire che la minimizzazione produca cancellazioni premature o che la conservazione si trasformi in accumulo indefinito.

La domanda corretta non è e non deve essere solo “conservare o cancellare?”, ma “quale evidenza conservare, perché, per quanto tempo, con quali garanzie e con quale possibilità di accesso?”.

NIS2 e continuità della cura

La cybersecurity sanitaria non è una funzione ancillare dell’IT. È continuità della cura. Ransomware, manipolazione dei dati, indisponibilità delle immagini diagnostiche o compromissione dei sistemi di telemedicina possono causare danni diretti e indiretti alle persone/pazienti. Il d.lgs. n. 138/2024 richiede ai soggetti rientranti nel perimetro NIS misure proporzionate, gestione del rischio, sicurezza della catena di fornitura, continuità, gestione degli incidenti e responsabilità degli organi di amministrazione e direzione.

Sul piano operativo, registro degli incidenti, piano di risposta, business impact analysis, backup, disaster recovery, gestione delle vulnerabilità, controllo degli accessi e formazione devono dialogare con il registro GDPR, la DPIA, la gestione dei data breach e la sorveglianza sui dispositivi medici e sui sistemi di IA.

Non tutti gli incidenti NIS sono data breach secondo gli artt. 33 e 34 del GDPR e non tutti i data breach sono incidenti significativi NIS, ma la prima valutazione deve essere coordinata, tempestiva e documentata.

Nei contratti, i tempi di comunicazione del fornitore devono consentire alla struttura di rispettare tutti i termini applicabili e non soltanto quello delle 72 ore previste dal GDPR.

Contratti: il luogo dove la compliance diventa concreta

Le strutture sanitarie non possono accettare condizioni standard che trasferiscano il rischio tecnologico sull’utilizzatore lasciando al fornitore il controllo dei dati, degli aggiornamenti e gli indicatori di performance. Il contratto deve partire dalla destinazione d’uso e dal processo clinico, non dal listino delle funzionalità del prodotto software che si intende acquistare.

Occorre disciplinare nei contratti ad oggetto informatico utilizzati nel contesto sanitario almeno: qualificazione privacy dei ruoli; descrizione di oggetto, natura e finalità; divieto di usi ulteriori non autorizzati; eventuale ricerca o training; subfornitori e localizzazione; trasferimenti extra SEE; sicurezza; incidenti; audit; continuità; portabilità e cancellazione; qualificazione del sistema di IA; classificazione come dispositivo medico; documentazione tecnica; limiti della destinazione d’uso; requisiti dei dati di input; accuratezza, robustezza e bias noti; human oversight; logging; aggiornamenti, modifica sostanziale e retraining; monitoraggio post-market; responsabilità, manleve, assicurazioni, sospensione e recesso.

Particolare diffidenza meritano espressioni utilizzate in determinate condizioni generali di sviluppo/utilizzo di sistemi/modelli di IA come improvement of services, product development, analytics, benchmarking, aggregated insights e AI training. Possono nascondere finalità proprie incompatibili con il ruolo di responsabile del trattamento o riusi non valutati. Anche i dati aggregati meritano attenta verifica da parte della struttura sanitaria: l’etichetta commerciale non garantisce l’anonimato in punto di diritto.

Gli aggiornamenti dei sistemi di IA sono un altro snodo critico. Possono modificare performance, popolazioni di riferimento, accuratezza e rischio. Il contratto dovrebbe prevedere preavviso, documentazione, testing, ambiente di prova, possibilità di rifiuto o sospensione, riesame di DPIA e FRIA e conservazione delle versioni. Un algoritmo che cambia senza una governance delle versioni rende fragile ogni ricostruzione successiva.

 

Un fascicolo di governance per ogni sistema rilevante

La soluzione pratica è quella di predisporre un fascicolo di governance del sistema digitale o di IA, non come nuovo adempimento autoreferenziale, ma come punto di raccordo tra le diverse funzioni e strumento di governo del processo di innovazione digitale in un contesto tanto delicato. Dovrebbe contenere, in modo proporzionato: scheda del sistema e destinazione d’uso; owner interno; classificazione AI Act e MDR/IVDR; mappa dei trattamenti; ruoli GDPR e AI Act; basi giuridiche; flussi e trasferimenti; DPIA ed eventuale FRIA; valutazione clinica e organizzativa; misure NIS2 e piano incidenti; documentazione del fornitore; contratto e allegati; piano di conservazione; requisiti di logging; modello di supervisione umana; formazione; audit; monitoraggio; modifiche e versioni; reclami e incidenti.

Il fascicolo deve essere vivo. Va aggiornato quando cambiano modelli, dataset, destinazioni, contesti clinici, fornitori, basi giuridiche o livelli di rischio. La sua utilità consiste nel rendere sempre leggibile, trasparente e monitorabile la scelta organizzativa: perché è stato adottato il sistema, quali alternative sono state considerate, quali rischi sono stati accettati, quali misure li presidiano e chi interviene quando qualcosa non funziona.

La governance dovrebbe essere affidata a un gruppo stabile e interdisciplinare. Direzione sanitaria, IT, DPO, Responsabile della conservazione, CISO, risk manager, ingegneria clinica, responsabile qualità, legale, procurement e professionisti sanitari devono avere responsabilità definite. Il DPO mantiene indipendenza e funzione consultiva e di sorveglianza; il Responsabile della conservazione presidia il sistema di conservazione; il CISO governa il rischio cyber; la direzione sanitaria valuta appropriatezza e impatto clinico; il procurement traduce i requisiti in capitolati e contratti.

Nessuna di queste funzioni, da sola, può garantire la conformità integrata.

Glossario orientativo per non perdersi

Di seguito un glossario da utilizzare per orientarsi all’interno di questa guida operativa:

Accountability: capacità dell’organizzazione di conformarsi e dimostrare le ragioni delle proprie scelte, i rischi valutati e i controlli attuati.

Uso primario: uso dei dati sanitari elettronici per erogare assistenza alla persona.

Uso secondario: riuso regolato per ricerca, innovazione, statistiche, politiche e attività ulteriori ammesse.

Titolare e responsabile: ruoli GDPR da qualificare sulla realtà delle finalità e dei mezzi, non sulla denominazione contrattuale. Il titolare determina le finalità e i mezzi del trattamento, mentre il responsabile agisce per conto del titolare e sulla base delle istruzioni da questo impartite.

Provider e deployer: ruoli AI Act relativi, rispettivamente, alla messa sul mercato o in servizio e all’uso sotto la propria autorità.

Sistema ad alto rischio: sistema che ricade nelle categorie e condizioni dell’AI Act; in ambito sanitario è frequente il collegamento con dispositivi medici soggetti a valutazione di conformità di terzi.

DPIA: valutazione preventiva del rischio elevato derivante dal trattamento di dati personali.

FRIA: valutazione dell’impatto sui diritti fondamentali dell’uso concreto di determinati sistemi ad alto rischio.

Human oversight: insieme di competenze, poteri, interfacce e procedure che consentono a persone adeguatamente formate di comprendere, controllare, contestare o interrompere il sistema.

Logging e audit trail: registrazione coerente degli eventi necessari per sicurezza, controllo e ricostruzione, con integrità e tempi di conservazione definiti.

Conservazione digitale: sistema organizzato destinato a mantenere nel tempo documenti e aggregazioni documentali autentici, integri, affidabili, leggibili e reperibili.

Automation bias: affidamento eccessivo sull’output della macchina, che può indebolire il giudizio professionale.

Digital compliance integrata: metodo di governo che coordina protezione dei dati, sicurezza, documentazione, dispositivi, algoritmi, contratti e responsabilità clinica.

Checklist essenziale prima dell’adozione

Prima di adottare una soluzione digitale o di IA all’interno di una struttura sanitaria, risulta necessario poter rispondere in modo documentato alle seguenti domande:

• qual è la reale destinazione d’uso e quale processo sanitario modifica?
• il prodotto contiene un sistema di IA e, se sì, con quale classificazione?
• è anche un dispositivo medico o diagnostico in vitro?
• chi sono provider, deployer, titolare, responsabile e gli eventuali altri soggetti coinvolti nel processo di innovazione?
• quali dati entrano nel sistema, da dove provengono e con quale qualità?
• vi sono riusi per ricerca, analytics, benchmarking, addestramento o retraining?
• Il trattamento richiede una DPIA e la struttura rientra tra i deployer tenuti a effettuare una FRIA ai sensi dell’art. 27 AI Act? Quali informazioni e valutazioni sono necessarie per i due adempimenti?
• come è garantita la supervisione umana e come si documenta il dissenso clinico?
• quali log sono generati, chi vi accede e per quanto tempo sono conservati?
• come vengono gestiti incidenti, malfunzionamenti, bias e reclami?
• quali obblighi NIS2, GDPR, MDR/IVDR ed EHDS sono rilevanti?
• il contratto permette audit, sospensione, portabilità e recesso?
• gli aggiornamenti possono cambiare destinazione d’uso, rischio o performance?
• il personale è formato sul sistema concreto, non soltanto sull’IA in generale?
• la direzione è in grado di motivare e dimostrare la scelta tecnologica?

Conclusioni. La salute non è un output

La sanità digitale non può essere governata con acquisti frammentati, informative standard e dichiarazioni di conformità ricevute dal fornitore. Ogni piattaforma, fascicolo, dispositivo e soluzione IA modificano il modo in cui la cura è organizzata e resa conoscibile. La responsabilità della struttura consiste nel ricomporre tre dimensioni: cura e responsabilità clinica; dato e responsabilità informativa (e cyber); algoritmo e responsabilità sui diritti fondamentali.

Il problema non è più soltanto chi accede al dato, ma chi lo trasforma in una previsione o raccomandazione e chi controlla il potere che quella raccomandazione esercita sulla persona. È qui che GDPR, EHDS, NIS2, eIDAS, MDR e AI Act devono essere letti insieme.

Come ho già osservato riflettendo sull’ecologia della responsabilità digitale, le nuove regole acquistano senso soltanto se ricondotte a un’organizzazione capace di evitare la deresponsabilizzazione prodotta dalla frammentazione[7].

La salute non è un output. Il paziente non è un dataset. Il medico non è un validatore passivo. La struttura sanitaria non è un semplice acquirente di tecnologia. Il DPO non è un compilatore di informative e il Responsabile della conservazione non è l’archivista di documenti ormai deceduti. Tutti partecipano, con ruoli distinti, a una responsabilità collettiva: garantire che l’aumento tecnologico non produca una diminuzione dell’umano.

La compliance integrata non deve essere avvertita quindi come un nuovo fascicolo burocratico da completare. È un metodo di governo. La struttura sanitaria del futuro sarà valutata non soltanto per la qualità delle cure, ma anche per la qualità della governance digitale attraverso la quale quelle cure verranno rese possibili.

 

---

[1] Per un approfondimento si suggerisce la lettura di A. Lisi, “Fascicolo sanitario incompleto: quando il cittadino può chiedere i danni”, AgendaDigitale.eu, 29 luglio 2026.

[2] Per un approfondimento si consiglia la lettura di A. Lisi “Data breach tra privacy e security: una proposta di sopravvivenza normativa, etica, logica e organizzativa in caso di violazioni nel trattamento dei dati” pubblicato su Rivista elettronica di Diritto, Economia, Management N. 1 – 2025 – pp. 26-36.

[3] Art. 7 Uso dell’intelligenza artificiale in ambito sanitario e di disabilità:

“1. L’utilizzo di sistemi di intelligenza artificiale contribuisce al miglioramento del sistema sanitario, alla prevenzione, alla diagnosi e alla cura delle malattie, nel rispetto dei diritti, delle libertà e degli interessi della persona, anche in materia di protezione dei dati personali.

2. L’introduzione di sistemi di intelligenza artificiale nel sistema sanitario non può selezionare e condizionare l’accesso alle prestazioni sanitarie secondo criteri discriminatori.
3. L’interessato ha diritto di essere informato sull’impiego di tecnologie di intelligenza artificiale.
4. La presente legge promuove lo sviluppo, lo studio e la diffusione di sistemi di intelligenza artificiale che migliorano le condizioni di vita delle persone con disabilità, agevolano l’accessibilità, la mobilità indipendente e l’autonomia, la sicurezza e i processi di inclusione sociale delle medesime persone anche ai fini dell’elaborazione del progetto di vita di cui all’articolo 2, comma 1, lettera n), del decreto legislativo 3 maggio 2024, n. 62.
5. I sistemi di intelligenza artificiale in ambito sanitario costituiscono un supporto nei processi di prevenzione, diagnosi, cura e scelta terapeutica, lasciando impregiudicata la decisione, che è sempre rimessa agli esercenti la professione medica.
6. I sistemi di intelligenza artificiale utilizzati in ambito sanitario e i relativi dati impiegati devono essere affidabili, periodicamente verificati e aggiornati al fine di minimizzare il rischio di errori e migliorare la sicurezza dei pazienti”.

Art. 8 Ricerca e sperimentazione scientifica nella realizzazione di sistemi di intelligenza artificiale in ambito sanitario:

“1. I trattamenti di dati, anche personali, eseguiti da soggetti pubblici e privati senza scopo di lucro, dagli Istituti di ricovero e cura a carattere scientifico (IRCCS), di cui al decreto legislativo 16 ottobre 2003, n. 288, nonché da soggetti privati operanti nel settore sanitario nell’ambito di progetti di ricerca a cui partecipano soggetti pubblici e privati senza scopo di lucro o IRCCS, per la ricerca e la sperimentazione scientifica nella realizzazione di sistemi di intelligenza artificiale per finalità di prevenzione, diagnosi e cura di malattie, sviluppo di farmaci, terapie e tecnologie riabilitative, realizzazione di apparati medicali, incluse protesi e interfacce fra il corpo e strumenti di sostegno alle condizioni del paziente, salute pubblica, incolumità della persona, salute e sicurezza sanitaria nonché studio della fisiologia, della biomeccanica e della biologia umana anche in ambito non sanitario, in quanto necessari ai fini della realizzazione e dell’utilizzazione di banche di dati e modelli di base, sono dichiarati di rilevante interesse pubblico in attuazione degli articoli 32 e 33 della Costituzione e nel rispetto di quanto previsto dall’articolo 9, paragrafo 2, lettera g), del regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016.

2. Ai medesimi fini, fermo restando l’obbligo di informativa in favore dell’interessato, che può essere assolto anche mediante un’informativa generale messa a disposizione nel sito web del titolare del trattamento e senza ulteriore consenso dell’interessato ove inizialmente previsto dalla legge, è sempre autorizzato l’uso secondario di dati personali privi degli elementi identificativi diretti, anche appartenenti alle categorie indicate all’articolo 9 del regolamento (UE) 2016/679, da parte dei soggetti di cui al comma 1, salvi i casi nei quali la conoscenza dell’identità degli interessati sia inevitabile o necessaria al fine della tutela della loro salute.
3. Negli ambiti di cui al comma 1 o per le finalità di cui all’articolo 2-sexies, comma 2, lettera v), del codice in materia di protezione dei dati personali, di cui al decreto legislativo 30 giugno 2003, n. 196, è sempre consentito, previa informativa all’interessato ai sensi dell’articolo 13 del regolamento (UE) 2016/679, il trattamento per finalità di anonimizzazione, pseudonimizzazione o sintetizzazione dei dati personali, anche appartenenti alle categorie particolari di cui all’articolo 9, paragrafo 1, del medesimo regolamento (UE) 2016/679. È consentito altresì il predetto trattamento finalizzato allo studio e alla ricerca sui gesti atletici, sui movimenti e sulle prestazioni nell’attività sportiva in tutte le sue forme, nel rispetto dei principi generali di cui alla presente legge e dei diritti di sfruttamento economico dei dati relativi alle attività agonistiche che spettano a chi le organizza.
4. L’Agenzia nazionale per i servizi sanitari regionali (AGENAS), previo parere del Garante per la protezione dei dati personali, tenendo conto di standard internazionali e dello stato dell’arte e della tecnica, può stabilire e aggiornare linee guida per le procedure di anonimizzazione di dati personali, di cui al comma 3, e per la creazione di dati sintetici, anche per categorie di dati e finalità di trattamento.
5. I trattamenti di dati di cui ai commi 1 e 2 devono essere comunicati al Garante per la protezione dei dati personali con l’indicazione di tutte le informazioni previste dagli articoli 24, 25, 32 e 35 del regolamento (UE) 2016/679, nonché con l’indicazione espressa, ove presenti, dei soggetti individuati ai sensi dell’articolo 28 del medesimo regolamento (UE) 2016/679, e possono essere avviati decorsi trenta giorni dalla predetta comunicazione se non sono stati oggetto di provvedimento di blocco disposto dal Garante per la protezione dei dati personali.
6. Restano fermi i poteri ispettivi, interdittivi e sanzionatori del Garante per la protezione dei dati personali”.

[4] A. Lisi, “L’enigma del pensiero aumentato nella sanità digitale e nella sperimentazione clinica. Tra diritti frammentati e nuove alleanze costituzionali”, Rivista Digeat, 19 giugno 2026, https://digeat.info/articolo-rivista/digeat32026-lisi/.

[5] Regolamento (UE) 2024/1183 dell’11 aprile 2024, che modifica il Regolamento (UE) n. 910/2014 e introduce, tra i servizi fiduciari, l’archiviazione elettronica; Commissione europea, “eArchiving White Paper on eIDAS2”, 28 maggio 2024.

[6] AgID, Linee guida sulla formazione, gestione e conservazione dei documenti informatici; art. 44 del d.lgs. n. 82/2005. Il sistema di conservazione garantisce autenticità, integrità, affidabilità, leggibilità e reperibilità degli oggetti conservati.

[7] A. Lisi, “GDPR, NIS2 e AI Act: verso un’ecologia della responsabilità digitale”, Rivista Digeat, 19 giugno 2026; vedere scheda autore e indice dei contributi