Dati dei pazienti in una IA non autorizzata: le domande che un ospedale deve porsi dopo il caso Johns Hopkins

I fatti, come riportati

La fonte è il comunicato diffuso dall'ospedale il 23 ottobre 2026 e ripreso da Becker's Hospital Review il 26 ottobre. Secondo quella ricostruzione, un membro del personale ha caricato per errore il 21 settembre, durante una verifica interna, un foglio di calcolo su uno strumento di IA pubblico. L'ospedale ne ha avuto notizia lo stesso giorno.

Il file riguardava ricoveri e trattamenti da maggio a settembre 2026 e poteva contenere nomi, date di ricovero e di trattamento, numeri di cartella clinica e di conto, reparto, farmaci somministrati e nomi dei sanitari. L'ospedale esclude numeri di previdenza sociale e dati finanziari.

La struttura ha fatto cancellare al dipendente prompt, conversazione e documento dalla cronologia dello strumento, ha chiesto all'azienda che lo gestisce di eliminare le informazioni e ha avviato misure correttive. Ai pazienti sono offerti 12 mesi di monitoraggio del credito e un call center dedicato.

Il punto giuridico: un incidente di governance dei dati

Chiamarlo incidente di IA descrive il canale, non la causa. Per il GDPR la divulgazione non autorizzata di dati personali è una violazione di sicurezza (art. 4, n. 12), e qui i dati sono relativi alla salute (art. 4, n. 15, e art. 9). Nome, numero di cartella, reparto e farmaci somministrati bastano a rendere gli interessati identificabili.

Che il file non contenesse dati finanziari riduce il rischio di frodi, ma non quello principale. Nella valutazione richiesta dal GDPR pesano soprattutto la natura sanitaria dei dati e la facilità di identificare i pazienti (considerando 75 e 85 GDPR; Linee guida EDPB 9/2022). Tre domande guidano l'analisi di un caso analogo in una struttura europea.

Il rischio non è lo strumento di IA. È non averlo governato.

1. Che ruolo ha il fornitore dello strumento?

Se agisce come responsabile del trattamento serve un contratto conforme all'art. 28 GDPR. Se invece, come accade spesso nelle versioni consumer, tratta i dati per finalità proprie, è un titolare autonomo e la comunicazione dei dati dell'ospedale non ha alcuna base giuridica. Il ruolo si accerta sui fatti e sui termini d'uso, secondo le Linee guida EDPB 07/2020. Se il fornitore ha sede fuori dallo Spazio economico europeo si aggiunge il Capo V (artt. 44 ss.). Se è negli Stati Uniti, la decisione di adeguatezza sul Data Privacy Framework copre solo le imprese che vi aderiscono.

2. Notifica o no, e con quali tempi?

L'art. 33 impone di notificare al Garante entro 72 ore da quando il titolare ne è venuto a conoscenza, salvo che sia improbabile un rischio per i diritti e le libertà degli interessati. L'art. 34 richiede la comunicazione agli interessati quando il rischio è elevato. La valutazione si fa con i criteri delle Linee guida EDPB 9/2022: natura e sensibilità dei dati, facilità di identificazione, gravità delle conseguenze, numero di persone.

La cancellazione richiesta al fornitore rientra tra le misure attenuanti, ma pesa solo se è verificabile. Anche quando si decide di non notificare, l'art. 33, par. 5, impone di documentare la violazione e la valutazione fatta.

3. Perché è potuto succedere?

Davanti a un caso come questo, un'autorità di controllo non si fermerebbe al gesto del dipendente ma guarderebbe all'organizzazione: quali regole erano state date al personale, quali strumenti erano a disposizione, quali controlli avrebbero potuto intercettare il file. Nessuno pretende che un ospedale azzeri il rischio di errore umano; si pretende che lo abbia previsto e gestito. Se le misure non erano adeguate, la responsabilità resta della struttura, anche quando a sbagliare è stato un singolo (artt. 5, par. 1, lett. f), 24, 29 e 32 GDPR; art. 2-quaterdecies Codice privacy).

C'è poi la minimizzazione (art. 5, par. 1, lett. c). Una verifica interna richiede davvero nomi e numeri di cartella? Pseudonimizzare il file prima dell'analisi (artt. 25 e 32, par. 1, lett. a) avrebbe reso l'upload molto meno grave.

AI Act e NIS2: le norme che di solito si dimenticano

AI Act, art. 4. Il Regolamento (UE) 2026/1744 (Digital Omnibus sull'IA), in vigore dal 27 luglio 2026, ha riscritto l'obbligo di alfabetizzazione in materia di IA: da un dovere di assicurare un livello sufficiente a un dovere di adottare misure che ne sostengano lo sviluppo. L'obbligo riguarda fornitori e deployer di qualsiasi sistema, a prescindere dalla classe di rischio, quindi anche l'ospedale che usa un chatbot generico. È un punto aperto se l'uso non autorizzato da parte di un dipendente renda l'organizzazione deployer ai sensi dell'AI Act: non risultano orientamenti consolidati, e conviene trattarlo in via prudenziale come se lo fosse.

NIS2. Per le strutture sanitarie rientranti nell'ambito di applicazione, l'art. 24, co. 2, lett. g), del D.Lgs. 138/2024 (che recepisce l'art. 21 della Direttiva (UE) 2022/2555) include tra le misure di gestione dei rischi le pratiche di igiene di base e di formazione in materia di sicurezza informatica. L'art. 23, co. 2, lett. b), chiede inoltre agli organi di amministrazione di promuovere una formazione periodica per i dipendenti. Se un singolo upload configuri un incidente significativo da notificare al CSIRT Italia ai sensi dell'art. 25 va valutato caso per caso: non è automatico.

Dal divieto al presidio

Action items

1. Censire l'uso reale. Una rilevazione anonima tra il personale fa emergere gli strumenti di IA usati davvero, che l'elenco di quelli autorizzati non mostra. I controlli tecnici sul traffico rientrano nel punto 4, con le cautele dello Statuto dei lavoratori.
2. Offrire un'alternativa approvata. Contratto ex art. 28, nessun riuso dei dati per addestrare il modello, conservazione definita, localizzazione nello Spazio economico europeo o garanzie del Capo V.
3. Minimizzare a monte. Pseudonimizzazione dei dataset prima di ogni analisi e valutazione d'impatto (art. 35) per i casi d'uso di IA approvati.
4. Controlli tecnici con regole chiare. Gli strumenti di prevenzione della fuga di dati possono comportare un controllo a distanza dei lavoratori: serve il percorso dell'art. 4 dello Statuto dei lavoratori (L. 300/1970), oltre all'informativa ai dipendenti.
5. Aggiornare il piano di risposta ai data breach. L'IA come canale di fuga, richiesta e prova di cancellazione al fornitore, termine di 72 ore, registro delle violazioni (art. 33, par. 5).
6. Formare per ruolo, con scenari. Simulazioni su casi come questo, con verifica dell'apprendimento. Le sanzioni disciplinari richiedono un codice disciplinare adeguatamente pubblicato (art. 7 L. 300/1970).