AI Act in sanità: classificazione, obblighi della struttura e DPIA dopo il Digital Omnibus

Prima domanda: la struttura è fornitore o deployer?

L’AI Act distribuisce gli obblighi secondo il ruolo. Il fornitore sviluppa un sistema di AI (o lo fa sviluppare) e lo immette sul mercato o lo mette in servizio con il proprio nome o marchio, anche per uso proprio (art. 3, punto 3). Il deployer, termine che la versione italiana del regolamento lascia in inglese, è chi utilizza il sistema sotto la propria autorità nell’ambito di un’attività professionale (art. 3, punto 4). Un poliambulatorio che acquista un software di refertazione assistita è, di regola, un deployer. Lo è anche la casa di cura che adotta un sistema di triage per il proprio pronto soccorso. Gli obblighi più onerosi del Capo III gravano sul fornitore: sistema di gestione della qualità (art. 17), documentazione tecnica, valutazione di conformità.

Il ruolo può cambiare. L’art. 25, par. 1, considera fornitore il deployer in tre casi: se appone il proprio nome o marchio su un sistema ad alto rischio già immesso sul mercato, se vi apporta una modifica sostanziale che lo lascia ad alto rischio, se modifica la finalità prevista di un sistema non classificato ad alto rischio in modo da farlo diventare tale. Per una struttura sanitaria il caso concreto è il gruppo di lavoro interno che adatta un modello acquistato a un uso clinico diverso da quello dichiarato dal produttore. In quel momento la struttura assume gli obblighi del fornitore.

Quando un sistema di AI in sanità è ad alto rischio

La qualifica di alto rischio segue due percorsi distinti, con date di applicazione diverse.

Il primo è l’art. 6, par. 1, collegato all’Allegato I. È ad alto rischio il sistema di AI che è esso stesso un prodotto disciplinato dalla normativa di armonizzazione elencata nell’Allegato I, o ne costituisce un componente di sicurezza, quando quel prodotto deve essere sottoposto a una valutazione di conformità da parte di terzi. Fra quelle normative figurano il Regolamento (UE) 2017/745 sui dispositivi medici (MDR, Medical Device Regulation) e il Regolamento (UE) 2017/746 sui dispositivi medico-diagnostici in vitro (IVDR, In Vitro Diagnostic Regulation). Il software che fornisce informazioni per decisioni diagnostiche o terapeutiche rientra, secondo la regola 11 dell’Allegato VIII del MDR, almeno nella classe IIa, che richiede l’intervento di un organismo notificato. Il software di classe I, per il quale basta l’autocertificazione del fabbricante, resta fuori da questo percorso. Per i sistemi dell’Allegato I gli obblighi si applicano dal 2 agosto 2028.

Il secondo è l’art. 6, par. 2, che rinvia all’Allegato III. Per questi sistemi gli obblighi si applicano dal 2 dicembre 2027. In sanità rileva soprattutto il punto 5, lettera d).

La lettera a) dello stesso punto riguarda i sistemi usati dalle autorità pubbliche, o per loro conto, per valutare l’ammissibilità alle prestazioni di assistenza pubblica essenziali, compresi i servizi sanitari. Una struttura privata vi rientra solo se opera per conto di un’autorità pubblica in quella specifica valutazione.

L’art. 6, par. 3, prevede infine che un sistema dell’Allegato III non sia considerato ad alto rischio se non presenta un rischio significativo per la salute, la sicurezza o i diritti fondamentali, per esempio perché svolge un compito procedurale limitato. La valutazione spetta al fornitore, che deve documentarla prima dell’immissione sul mercato. L’esclusione non opera mai per i sistemi che effettuano profilazione di persone fisiche.

La nuova nozione di componente di sicurezza

Il Regolamento 2026/1744 ha riscritto la definizione dell’art. 3, punto 14. Un componente svolge una funzione di sicurezza quando la sua finalità prevista è prevenire o attenuare i rischi per la salute e la sicurezza di persone o beni. Il nuovo art. 6, par. 1 bis, esclude dalla nozione i sistemi usati esclusivamente per aspetti non legati alla sicurezza, come l’assistenza all’utente, l’ottimizzazione delle prestazioni o il controllo di qualità. Il par. 1 ter mantiene comunque la qualifica quando il guasto o il malfunzionamento del sistema metterebbe in pericolo la salute e la sicurezza. Su un’apparecchiatura diagnostica, a mio avviso, la funzione di AI che si limita a ridurre i tempi di acquisizione può uscire dal perimetro. Resta dentro quella da cui dipende la qualità dell’immagine su cui il medico formula la diagnosi, perché un suo errore si traduce in un rischio per il paziente.

Cosa deve fare la struttura che usa un sistema ad alto rischio

Gli obblighi del deployer sono nell’art. 26 e sono in larga parte organizzativi. Il Digital Omnibus ne ha spostato l’applicazione insieme al resto del Capo III e ne ha lasciato invariato il contenuto.

A questi obblighi si aggiunge il diritto alla spiegazione dell’art. 86. Lo ha la persona oggetto di una decisione presa dal deployer sulla base dell’output di un sistema dell’Allegato III, quando la decisione produce effetti giuridici o incide in modo analogo significativamente su di lei e la persona ritiene che abbia un impatto negativo sulla sua salute, sulla sicurezza o sui diritti fondamentali. Può ottenere “spiegazioni chiare e significative sul ruolo del sistema di IA nella procedura decisionale e sui principali elementi della decisione adottata”. Il diritto si applica solo se non è già previsto da un’altra norma dell’Unione (par. 3). Per l’AI integrata nei dispositivi medici valgono gli obblighi informativi del GDPR e della legge italiana.

La formazione del personale

Il Regolamento 2026/1744 ha riformulato l’obbligo di alfabetizzazione dell’art. 4. Fornitori e deployer adottano misure per sostenere lo sviluppo delle competenze sull’AI del proprio personale, tenendo conto delle conoscenze tecniche, dell’esperienza e del contesto d’uso. La norma non impone di garantire un livello determinato di competenza a ciascuna persona. Per chi esercita la sorveglianza su un sistema ad alto rischio il riferimento resta l’art. 26, par. 2, rimasto invariato: la formazione di quelle persone è un requisito per usare il sistema.

DPIA e valutazione d’impatto sui diritti fondamentali

L’uso clinico di un sistema di AI richiede di regola una valutazione d’impatto sulla protezione dei dati ai sensi dell’art. 35 GDPR. Le linee guida WP248 rev.01, fatte proprie dall’EDPB, considerano di norma necessaria la DPIA quando ricorrono almeno due criteri di rischio. In questo caso ne ricorrono almeno due: dati relativi alla salute e uso di tecnologie innovative. L’elenco dei trattamenti da sottoporre a DPIA adottato dal Garante con il provvedimento n. 467 dell’11 ottobre 2018 cita espressamente, al punto 7, i sistemi di intelligenza artificiale. Se il trattamento è su larga scala, si applica direttamente l’art. 35, par. 3, lett. b). L’AI Act collega espressamente i due adempimenti.

In pratica la DPIA si costruisce a partire dalle istruzioni per l’uso del fornitore: finalità prevista, livello di accuratezza dichiarato, limiti noti, popolazioni su cui il sistema è stato addestrato e validato, misure di sorveglianza umana previste. Se il fornitore non consegna queste informazioni, la struttura non è in grado di valutare il rischio e deve chiederle prima dell’acquisto.

La valutazione d’impatto sui diritti fondamentali (FRIA, Fundamental Rights Impact Assessment) dell’art. 27 riguarda i sistemi dell’Allegato III. Sono tenuti a svolgerla i deployer che sono organismi di diritto pubblico o enti privati che forniscono servizi pubblici, oltre ai deployer dei sistemi per il merito creditizio e per le assicurazioni vita e malattia. Il considerando 96 cita espressamente l’assistenza sanitaria fra i servizi di natura pubblica che possono essere forniti da soggetti privati. Ne ricavo che una casa di cura accreditata con il Servizio sanitario nazionale, se adotta un sistema di triage per il pronto soccorso, deve considerarsi tenuta. È una lettura prudente, in attesa di indicazioni delle autorità. La valutazione va svolta prima del primo uso e i risultati vanno notificati all’autorità di vigilanza del mercato con il modello che l’Ufficio per l’IA deve predisporre (art. 27, parr. 3 e 5).

L’art. 27, par. 1, elenca il contenuto minimo: descrizione dei processi in cui il sistema è usato, periodo e frequenza d’uso, categorie di persone interessate, rischi specifici di danno per quelle categorie, misure di sorveglianza umana, misure da adottare se i rischi si concretizzano, compresi la governance interna e i meccanismi di reclamo.

Dati sanitari per correggere le distorsioni

Il Regolamento 2026/1744 ha introdotto l’art. 4 bis, che riprende e amplia la deroga prima contenuta nell’art. 10, par. 5. I fornitori di sistemi ad alto rischio possono trattare in via eccezionale categorie particolari di dati, compresi i dati relativi alla salute, per rilevare e correggere le distorsioni. Il par. 2 estende la possibilità ai fornitori e deployer degli altri sistemi e ai deployer dei sistemi ad alto rischio, quando il trattamento è strettamente necessario. Le condizioni sono rigorose. L’obiettivo non deve essere raggiungibile con altri dati, compresi quelli sintetici o anonimizzati. I dati vanno protetti con limitazioni al riutilizzo e controlli degli accessi, non possono essere trasmessi a terzi e vanno cancellati una volta corretta la distorsione. Una struttura che vuole verificare se un algoritmo funziona peggio su alcune categorie di pazienti trova qui un fondamento espresso. Deve comunque dimostrare la stretta necessità e documentarla nella DPIA.

Decisioni automatizzate e informazione al paziente

Per i dati sanitari l’art. 22, par. 4, è ancora più restrittivo: una decisione di quel tipo basata su categorie particolari di dati è ammessa solo con il consenso esplicito o per motivi di interesse pubblico rilevante, sempre con misure adeguate. La Corte di giustizia ha dato una lettura ampia della nozione di decisione nella sentenza SCHUFA Holding (C-634/21, 7 dicembre 2023): vi rientra anche il calcolo automatizzato di un valore da cui la decisione finale di un terzo dipende in modo determinante. Un punteggio di priorità che l’operatore di triage recepisce senza vaglio critico rischia di ricadere nell’art. 22. La sorveglianza umana dell’art. 14 AI Act protegge dal rischio solo se l’intervento del professionista è effettivo.

Sul piano informativo, gli artt. 13, par. 2, lett. f), 14, par. 2, lett. g) e 15, par. 1, lett. h) GDPR richiedono informazioni significative sulla logica utilizzata nei processi decisionali automatizzati. Nella sentenza Dun & Bradstreet Austria (C-203/22, 27 febbraio 2025) la Corte ha chiarito che l’interessato ha diritto a una spiegazione della procedura e dei principi concretamente applicati, in una forma che gli consenta di capire quali dati sono stati usati e in che modo. La legge 23 settembre 2025, n. 132, all’art. 7, comma 3, riconosce inoltre all’interessato il diritto di essere informato sull’impiego di tecnologie di intelligenza artificiale in ambito sanitario. L’informativa della struttura va aggiornata di conseguenza.

Supervisione umana in reparto

L’art. 14 si rivolge al fornitore, che deve progettare il sistema in modo da rendere possibile la sorveglianza. Il par. 4 descrive ciò che la persona incaricata deve essere messa in grado di fare. Deve comprendere capacità e limiti del sistema e interpretarne correttamente l’output. Deve restare consapevole della “distorsione dell’automazione”, cioè della tendenza ad affidarsi al risultato della macchina più del dovuto. Deve poter decidere di non usare il sistema, ignorarne o ribaltarne l’output e interromperlo con un pulsante di arresto o una procedura analoga. Al deployer spetta organizzare il lavoro in reparto perché queste possibilità siano esercitate davvero.

La legge n. 132/2025 aggiunge un principio proprio dell’ordinamento italiano. L’art. 7, comma 5, stabilisce che i sistemi di AI 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”. Il comma 6 richiede che i sistemi e i dati impiegati siano affidabili, verificati e aggiornati periodicamente.

Per i sistemi di imaging questo significa validazione locale prima dell’uso e monitoraggio delle prestazioni nel tempo. Lo raccomanda la dichiarazione congiunta pubblicata nel 2024 da cinque società di radiologia, fra cui la European Society of Radiology (ESR), dedicata all’acquisto, all’introduzione e al monitoraggio degli strumenti di AI. Le prestazioni misurate dal produttore su un certo insieme di dati possono non ripetersi con le apparecchiature e la popolazione di pazienti della singola struttura.

Se la struttura sviluppa in proprio

Alcune strutture, soprattutto quelle con attività di ricerca, sviluppano algoritmi al proprio interno. Finché il sistema serve solo alla ricerca scientifica, l’AI Act non si applica (art. 2, par. 6). Quando lo stesso sistema entra nella pratica clinica, la struttura diventa fornitore e si applicano gli obblighi del Capo III: gestione dei rischi (art. 9), governance dei dati di addestramento, convalida e prova (art. 10), documentazione tecnica (art. 11), registrazione degli eventi (art. 12), sistema di gestione della qualità (art. 17). Se il software è un dispositivo medico, si aggiungono gli obblighi del MDR, compreso l’art. 5, par. 5, per i dispositivi fabbricati e utilizzati all’interno della stessa istituzione sanitaria.

Il Regolamento 2026/1744 prevede una razionalizzazione del doppio regime. Il nuovo art. 2, par. 13, consente di limitare l’applicazione di specifici requisiti degli artt. da 9 a 15 e da 17 a 25 per i sistemi dell’art. 6, par. 1, quando la normativa settoriale dell’Allegato I, sezione A, fra cui MDR e IVDR, garantisce un livello di protezione equivalente o superiore. La Commissione deve adottare i relativi atti delegati entro il 2 agosto 2027. Fino ad allora la struttura deve pianificare entrambe le conformità.

Resta aperto il tema della capacità di certificazione. Nella proposta del novembre 2025 la Commissione aveva indicato fra le ragioni del rinvio la lentezza nella designazione delle autorità nazionali e degli organismi notificati e il ritardo nelle norme armonizzate. È prevedibile che le richieste di valutazione si concentrino a ridosso delle nuove scadenze. Chi sviluppa o commissiona sistemi destinati a diventare dispositivi medici ha interesse ad avviare subito il dialogo con l’organismo notificato.

Sanzioni

L’art. 99 AI Act gradua le sanzioni. La violazione dei divieti dell’art. 5 è punita fino a 35 milioni di euro o, per le imprese, fino al 7% del fatturato mondiale annuo, se superiore. Per la violazione degli obblighi di fornitori e deployer, compresi quelli dell’art. 26, il massimo è di 15 milioni di euro o del 3% del fatturato. Per le informazioni inesatte, incomplete o fuorvianti fornite alle autorità o agli organismi notificati il massimo è di 7,5 milioni di euro o dell’1%. Per le PMI (piccole e medie imprese) si applica l’importo inferiore fra i due. Se il sistema tratta dati personali, alle sanzioni dell’AI Act possono aggiungersi quelle del GDPR.

Conclusioni