Dispositivi medici e IA: come arrivare pronti all’AI Act

Dispositivi medici e IA: come arrivare pronti all’AI Act

Dal 02/08/2027 nessun software medicale basato su intelligenza artificiale potrà stare sul mercato europeo senza dimostrare conformità simultanea a MDR/IVDR e AI Act. Per la maggior parte dei produttori questo vuol dire una cosa sola: o si integra la compliance fin da ora, oppure tra due anni ci si ferma.

Questo passaggio è cruciale soprattutto per chi sviluppa soluzioni di diagnostica per immagini, telemedicina, triage intelligente o supporto alle decisioni cliniche: esattamente il cuore della serie “IA nella Sanità Italiana: Innovazione Clinica”. La buona notizia? L’Europa non chiede di rifare tutto da zero, ma di costruire un unico sistema di governance che tenga insieme sicurezza clinica e rischio algoritmico.

In questo articolo vediamo, con un taglio molto operativo:

• come si intrecciano MDR/IVDR e AI Act per i dispositivi medici software;
• cosa cambia davvero per qualità, dati, valutazione clinica e post‑market;
• quali passi concreti può fare oggi un’azienda sanitaria o un produttore per arrivare pronta al 2027.

1. Quando un dispositivo medico con IA diventa “alto rischio”

Per i dispositivi medici, la regola è chiara: è MDR/IVDR che decide se il sistema di IA è ad alto rischio ai sensi dell’AI Act.

In pratica, un sistema di IA è classificato ad alto rischio quando:

1. è un prodotto, o un componente di sicurezza di un prodotto, coperto da una normativa di armonizzazione UE (tra cui MDR e IVDR);
2. quel prodotto richiede la valutazione di conformità da parte di un organismo notificato.

Nel mondo della sanità significa che:

• tutti i software destinati a supportare decisioni diagnostiche o terapeutiche sono almeno di classe IIa MDR, spesso IIb o III;
• per queste classi l’intervento dell’organismo notificato è obbligatorio;
• di conseguenza, quasi tutti i dispositivi medici software basati su IA rientrano tra i sistemi di IA ad alto rischio.

Solo una minoranza di strumenti – essenzialmente software di classe I o classe A non sterili IVDR, con funzioni limitate – sfugge a questa logica. Se lavori su intelligenza artificiale in radiologia, cardiologia, oncologia, laboratorio analisi o telemonitoraggio cronici, devi dare per scontato che il tuo sistema ricadrà nel perimetro ad alto rischio.

Cosa significa “alto rischio” in pratica

Essere ad alto rischio non è un’etichetta teorica: comporta obblighi precisi, tra cui:

• sistema di gestione della qualità che copra anche la dimensione algoritmica;
• documentazione tecnica specifica sulle caratteristiche del modello di IA;
• requisiti di dati rappresentativi, privi di bias e tracciabili;
• misure robuste di supervisione umana e trasparenza;
• monitoraggio continuo delle prestazioni e dei rischi post‑commercializzazione.

La difficoltà non è tanto rispettare questi requisiti uno per uno, quanto evitare sistemi paralleli: uno per il MDR, uno per l’AI Act. Il documento congiunto AIB/MDCG 2025‑6 insiste proprio su questo punto: serve un approccio unitario alla compliance.

2. Un unico sistema di qualità per MDR, IVDR e AI Act

Il modo più efficiente per affrontare il tema è considerare l’AI Act come estensione naturale del sistema qualità MDR/IVDR, non come regolamento a parte.

Estendere il sistema di gestione della qualità

Chi produce dispositivi medici ha già un sistema qualità che copre:

• progettazione e sviluppo del software;
• produzione e rilascio;
• gestione del rischio clinico;
• sorveglianza post‑market.

Per renderlo compatibile con l’AI Act occorre:

1. Integrare il risk management algoritmico

   • includere nel risk management i rischi tipici dell’IA: errori di generalizzazione, degradazione delle performance nel tempo, bias sui gruppi di pazienti, robustezza rispetto a dati incompleti o rumorosi;
   • definire metriche quantitative (es. sensibilità/specificità per sottogruppi, tasso di falsi positivi/negativi per età/genere/area geografica);
   • documentare come questi rischi vengono prevenuti, mitigati o accettati.

2. Adattare procedure di verifica e validazione

   • non basta provare che il dispositivo “funziona” clinicamente; bisogna provare che l’algoritmo è accurato, robusto e resiliente;
   • va descritto come sono stati creati i dataset di addestramento, validazione e test e come si evita l’overfitting;
   • servono protocolli chiari per i test di regressione ogni volta che il modello viene aggiornato.

3. Incorporare trasparenza e supervisione umana

   • definire chi, nella pratica clinica, è responsabile dell’uso del sistema di IA (medico radiologo, specialista, MMG, ecc.);
   • descrivere come il professionista può comprendere, controllare e – se necessario – disattivare il suggerimento dell’algoritmo;
   • documentare l’interfaccia utente con messaggi comprensibili su limiti e condizioni d’uso.

L’obiettivo è arrivare, entro il 02/08/2027, a un’unica documentazione tecnica con cui l’organismo notificato possa rilasciare un certificato che copre contemporaneamente MDR/IVDR e AI Act.

3. Governance dei dati: il vero punto debole dei progetti IA

La maggior parte dei progetti di IA clinica in Italia si arena non sulla tecnologia, ma sui dati. Con l’AI Act questa debolezza diventa un problema regolatorio, non solo organizzativo.

Requisiti simultanei: qualità clinica + rappresentatività

Da un lato, MDR/IVDR chiedono dati clinici:

• accurati, completi, verificabili;
• idonei a dimostrare sicurezza e prestazioni;
• disponibili per la sorveglianza post‑market.

Dall’altro, l’AI Act impone che i dataset di un sistema di IA ad alto rischio siano:

• sufficientemente rappresentativi della popolazione target;
• gestiti per ridurre bias ingiustificati;
• tracciabili e utilizzati in condizioni di sicurezza e trasparenza.

Per un produttore che opera in sanità italiana questo si traduce in alcune scelte concrete:

• Progettare il dataset con la clinica in mente: non basta avere “tante immagini” o “tante cartelle cliniche”. Serve copertura per fasce d’età, generi, condizioni cliniche e – se rilevante – variabilità territoriale del SSN.
• Allineare governance dati e GDPR: pseudonimizzazione robusta, minimizzazione dei dati, regole chiare di accesso e log degli utilizzi.
• Tracciare l’intero ciclo di vita del dato: da dove arriva, come è stato pulito, quali trasformazioni sono state applicate, quali subset sono stati usati per training, validation e test.

Un esempio tipico: diagnostica per immagini

Prendiamo un software di IA per la diagnostica TAC polmonare installato in una grande azienda ospedaliera italiana:

• se il dataset storico proviene quasi solo da pazienti adulti fumatori, il modello rischia di essere meno accurato nei giovani o in pazienti con comorbidità diverse;
• l’AI Act chiederà al produttore di dimostrare come ha valutato e corretto questi sbilanciamenti;
• il MDR/IVDR pretende che tali limiti siano noti, documentati e presi in considerazione nella valutazione clinica.

Chi oggi struttura una data governance condivisa tra R&D, ufficio qualità, DPO e direzioni sanitarie avrà un vantaggio competitivo enorme nel 2027.

4. Valutazione clinica e modifiche del modello: niente aggiornamenti “silenziosi”

Per i dispositivi con IA, la valutazione clinica non è più un dossier statico: deve dialogare con il comportamento del modello nel tempo.

Integrare evidenze cliniche e test sull’algoritmo

Il produttore deve dimostrare due cose in modo coordinato:

• sicurezza e prestazioni cliniche dle dispositivo (MDR/IVDR: studi clinici, letteratura, esperienza post‑market);
• prestazioni tecniche dell’IA (AI Act: accuratezza, robustezza, resilienza, supervisione umana).

La strada più solida è creare un unico piano di valutazione clinica che preveda:

• endpoints clinici collegati a metriche algoritmiche (per es. riduzione dei tempi di refertazione, variazione di sensibilità diagnostica rispetto allo standard);
• analisi per sottogruppi che permettano di evidenziare e monitorare possibili bias;
• una strategia chiara per gli aggiornamenti futuri del modello.

Modifiche sostanziali e cambiamenti significativi

L’AI Act introduce la nozione di “modifica sostanziale” del sistema di IA dopo l’immissione sul mercato. Se una modifica non era stata prevista nella valutazione iniziale e può impattare la conformità, serve una nuova procedura di valutazione di conformità.

MDR e IVDR già parlano di “cambiamenti significativi” che richiedono un nuovo intervento dell’organismo notificato (per es. ampliamento della destinazione d’uso, modifiche importanti alla logica decisionale, nuovi gruppi di popolazione target).

Nel contesto di IA sanitaria, i casi tipici sono:

• cambio del modello (es. passaggio da una rete neurale a un’architettura diversa);
• uso di nuovi dataset di training che modificano sostanzialmente il comportamento del sistema;
• introduzione di nuove funzionalità cliniche (per es. da semplice classificazione a triage con priorità di urgenza).

Come gestire l’apprendimento continuo

Per i sistemi che continuano ad apprendere dopo la messa sul mercato, il documento AIB/MDCG apre una strada sensata: il produttore può predeterminare le modifiche attese:

• definendo in anticipo il perimetro di aggiornamento (es. fino a quali variazioni di performance, su quali dati, con quali controlli);
• descrivendo i meccanismi di controllo (human in the loop, soglie di sicurezza, rollback);
• inserendo tutto questo nella documentazione tecnica iniziale.

In questo modo, gli aggiornamenti che rientrano nel perimetro pre‑definito non saranno considerati “modifiche sostanziali” e non richiederanno ogni volta un nuovo iter di certificazione. È l’unico approccio sostenibile per applicazioni di medicina personalizzata e telemonitoraggio che vivono di dati aggiornati.

5. Sorveglianza post‑market: un unico cruscotto per rischio clinico e rischio IA

Una delle innovazioni più interessanti del documento congiunto è la spinta verso una sorveglianza post‑market integrata.

MDR (artt. 83 ss.) e IVDR (artt. 78 ss.) impongono:

• un piano di sorveglianza post‑commercializzazione (PMS);
• rapporti periodici di sicurezza (PSUR) o rapporti di PMS semplificati;
• raccolta e analisi sistematica di incidenti, quasi‑incidenti e reclami.

L’AI Act, all’art. 72, chiede per i sistemi di IA ad alto rischio un monitoraggio continuo capace di intercettare:

• malfunzionamenti dell’algoritmo;
• drift dei dati e degradazione delle performance;
• nuove forme di bias o problemi di trasparenza;
• interazioni inattese con altri sistemi informatici o clinici.

Come unificare PMS e monitoraggio IA

In pratica, un produttore può strutturare un unico sistema post‑market che:

• raccoglie indicatori clinici (es. tassi di eventi avversi, re‑ospedalizzazioni, modifiche della strategia terapeutica) e indicatori algoritmici (accuratezza, tempi di risposta, errori per sottogruppi);
• integra nel PSUR sezioni dedicate al comportamento dell’IA, con trend e analisi di drift;
• definisce soglie di intervento chiare: quando un calo di performance algoritmica diventa un problema di sicurezza del paziente.

Per le strutture sanitarie italiane questo ha un impatto diretto sulla governance interna:

• i risk manager clinici dovranno lavorare fianco a fianco con i responsabili ICT/AI;
• i comitati etici e le direzioni sanitarie dovranno leggere report che uniscono outcome clinici e performance di modelli;
• le gare e gli accordi quadro dovranno chiedere ai fornitori piani di PMS integrati e accesso ai log del sistema.

Chi oggi sta sperimentando IA in diagnostica per immagini, CUP intelligenti o sistemi di prioritizzazione in pronto soccorso può usare queste linee guida per disegnare da subito cruscotti e KPI conformi al futuro quadro normativo.

Cosa fare ora: una roadmap pratica al 2027

Per chi sviluppa o utilizza dispositivi medici con IA in Italia, la priorità nei prossimi 18‑24 mesi dovrebbe essere costruire un ponte stabile tra innovazione clinica e conformità normativa.

Una roadmap realistica potrebbe prevedere:

1. Assessment congiunto MDR/IVDR + AI Act

   • mappare per ogni prodotto classe di rischio, necessità di organismo notificato e funzioni di IA;
   • identificare i sistemi che ricadranno sicuramente nell’alto rischio.

2. Revisione del sistema qualità

   • integrare nel SGQ procedure specifiche per sviluppo, validazione e aggiornamento di modelli di IA;
   • definire ruoli e responsabilità (R&D, qualità, clinici, DPO, IT).

3. Piano di data governance clinicamente orientato

   • rivedere accordi con strutture sanitarie e data provider;
   • progettare dataset rappresentativi della popolazione del SSN;
   • allineare policy privacy e sicurezza con gli standard richiesti dall’AI Act.

4. Ridefinizione della valutazione clinica

   • aggiornare piani di valutazione clinica inserendo metriche algoritmiche;
   • progettare fin da ora il perimetro di eventuale apprendimento continuo.

5. PMS integrato

   • mettere a punto un sistema di monitoraggio unico per performance cliniche e IA;
   • costruire dashboard leggibili anche da direzioni sanitarie e risk manager.

Chi si muove ora non solo evita un “muro normativo” nel 2027, ma si posiziona meglio nelle gare PNRR, nelle partnership pubblico‑privato e nei percorsi di innovazione clinica basata su IA di lungo periodo.

La realtà è che dispositivi medici e intelligenza artificiale in sanità non sono solo una questione di modelli o hardware: sono una questione di fiducia regolata. Le aziende che sapranno dimostrare, dati alla mano, di saper tenere insieme beneficio clinico, sicurezza del paziente e controllo dell’algoritmo saranno quelle che guideranno la trasformazione digitale della sanità italiana nei prossimi dieci anni.