Un modello linguistico che assiste un clinico sui dati di un paziente eredita due regimi normativi in una volta sola: l’EU AI Act, che lo classifica ad alto rischio quando è un dispositivo medico o un componente di sicurezza di un dispositivo, e il GDPR, che colloca i dati sanitari fra le categorie particolari dell’Articolo 9. I due regimi non si sostituiscono a vicenda: si sommano. È questo vincolo, più della scelta del modello, a dettare come va costruita un’architettura che mette un LLM (Large Language Model) a contatto con cartelle cliniche, referti e immagini diagnostiche.

Contesto e perimetro

Il dato clinico ha una proprietà che il dato qualunque non ha: non può lasciare il perimetro in cui è stato raccolto senza una base giuridica esplicita. L’Articolo 9 GDPR vieta in via generale il trattamento dei dati sanitari, con deroghe solo a condizioni tassative — consenso esplicito, finalità di cura o di sanità pubblica con base nel diritto, ricerca con base nel diritto. L’Articolo 32 chiede misure di sicurezza proporzionate alla sensibilità del dato e nomina espressamente cifratura e pseudonimizzazione.

La conseguenza pratica è che l’inferenza non si può delegare a un endpoint remoto che spedisca il prompt — e con esso il contenuto clinico — fuori dall’infrastruttura controllata. Una chiamata a un servizio gestito esterno trasferisce i dati a un responsabile del trattamento terzo, riapre la valutazione della base giuridica e, se il fornitore è fuori dall’UE, anche il capitolo dei trasferimenti internazionali. Per questo i sistemi che lavorano su dati clinici gravitano verso modelli eseguiti in locale: l’inferenza resta dove i dati hanno il diritto di stare.

Architettura

Lo schema ricorrente è fatto di tre piani. Il primo è l’accesso ai dati strutturati: HL7 FHIR R4 per i record clinici, DICOM per le immagini diagnostiche. FHIR espone risorse interrogabili via API REST; DICOM gestisce gli studi radiologici e i metadati collegati. Un sistema che recupera il contesto per il modello legge da un server FHIR e, per la parte di imaging, da metadati DICOM normalizzati — esistono risorse FHIR nate proprio per rappresentare i metadati di imaging e riportarli nel repository clinico.

Il secondo piano è la pipeline RAG (Retrieval-Augmented Generation): il modello non viene riaddestrato sui dati del paziente, ma a runtime riceve i frammenti pertinenti pescati da un indice vettoriale costruito su linee guida, protocolli e dati specifici del caso. Così la superficie di esposizione si riduce — i dati non finiscono nei pesi del modello — e diventa tracciabile la provenienza di ciò che il modello ha visto. Lavori come FHIR-RAG-MEDS descrivono esattamente questo accoppiamento: recupero patient-specific da un server FHIR più linee guida cliniche da un database vettoriale.

Il terzo piano è il modello eseguito su infrastruttura locale, dietro la rete dell’ente. Qui si concentra il costo della sovranità: GPU on-premise, gestione del ciclo di vita del modello, monitoraggio. In cambio, nessun frammento di prompt clinico oltrepassa il confine dell’infrastruttura.

Il punto critico: governance nei due sensi e logging

A separare un prototipo da un sistema che regge la produzione è il piano di governance applicato sia in ingresso sia in uscita. In ingresso, la redazione delle PII (Personally Identifiable Information) deve avvenire prima che il testo arrivi all’indice o al modello: gli identificativi diretti — nome, codice fiscale, recapiti — vanno individuati e neutralizzati a monte, perché una volta entrati nel contesto del modello o nei log diventano un trattamento in più da giustificare. In uscita, l’output va ispezionato prima di mostrarlo, perché un modello può ricostruire o far emergere informazioni che non dovrebbero comparire.

Sul logging l’EU AI Act diventa vincolante in modo misurabile. L’Articolo 12 impone ai sistemi ad alto rischio la registrazione automatica degli eventi lungo tutto il ciclo di vita, con conservazione di almeno sei mesi (allineata al periodo più lungo quando altri obblighi, come quelli GDPR, lo richiedono). L’Articolo 9 impone un sistema di gestione del rischio continuo e iterativo, non una valutazione fatta una volta sola. Sul piano dell’architettura significa che ogni decisione del piano di governance — cosa è stato redatto, cosa bloccato, quale frammento recuperato — deve lasciare una traccia conservata e verificabile. Una catena di hash sui record di audit rende l’integrità della traccia controllabile a posteriori, cosa che un log modificabile non garantisce.

Implicazioni: la classificazione del rischio non è facoltativa

Un sistema che entra in una decisione clinica è raramente a basso rischio sotto l’EU AI Act. La classificazione segue l’Articolo 6: se l’AI è essa stessa un dispositivo medico, o un componente di sicurezza di un dispositivo regolato da MDR (Medical Device Regulation) o IVDR (In Vitro Diagnostic Regulation), ricade in automatico nell’alto rischio dell’Articolo 6(1). Il calendario qui è preciso: per i sistemi ad alto rischio in quanto incorporati nei prodotti regolati dell’Allegato I gli obblighi scattano il 2 agosto 2027, mentre per i sistemi dell’Allegato III non soggetti a valutazione di conformità da organismo notificato la data è il 2 agosto 2026.

Vuol dire che la classificazione del rischio va fatta in fase di progetto, non a valle del deployment, perché decide quali obblighi documentali e di gestione del rischio si applicano. Un classificatore che mappa il sistema sugli Articoli 9–15 e segnala le lacune serve più come strumento di progettazione che come adempimento finale: dice cosa manca finché l’architettura si può ancora cambiare.

Limiti

Tenere modello e dati nel perimetro non basta da solo a garantire la conformità. La pseudonimizzazione a monte riduce ma non azzera il rischio di reidentificazione, soprattutto quando il contesto recuperato è ricco e il caso clinico è raro. Il logging immutabile va in tensione con il diritto alla cancellazione: una catena di hash di audit per definizione non si tocca, e va progettata tenendo separati i metadati di governance dai contenuti soggetti ai diritti dell’interessato. La valutazione del rischio sotto MDR richiede competenze cliniche che non si esauriscono nel software. E il modello eseguito in locale resta esposto agli stessi errori di un modello remoto: l’inferenza dentro il perimetro protegge i dati, non la correttezza della risposta, che in ambito clinico va validata da chi ha la responsabilità della decisione.

Una traduzione concreta di questi vincoli in una suite di supporto clinico — RAG su dati FHIR/DICOM, architettura on-premise, percorso MDR — è descritta da noze nell’insight su AgenticHealth: https://www.noze.it/insights/open-intelligence-secure-governance/.

Immagine di copertina: Un radiologo seduto a una postazione clinica interpreta immagini di risonanza magnetica del cervello visualizzate su un monitor di livello clinico — foto di The Medical Futurist editors, CC BY 4.0 — https://commons.wikimedia.org/wiki/File:Radiologist_interpreting_MRI.jpg