Dal 02/08/2027 i software medici con IA dovranno rispettare insieme MDR/IVDR e AI Act. Ecco come strutturare qualità, dati, valutazione clinica e sorveglianza.
IA e dispositivi medici: guida pratica all’AI Act UE
Dal 2 agosto 2027 nessun software medico basato su intelligenza artificiale potrà entrare (o restare) sul mercato europeo senza dimostrare conformità contemporanea a MDR/IVDR e AI Act. Per chi sviluppa soluzioni di diagnostica per immagini, telemedicina o supporto alle decisioni cliniche in Italia, questo non è un dettaglio burocratico: è la linea che separa un progetto pilota da un prodotto realmente utilizzabile in corsia.
Nel percorso della serie “IA nella Sanità Italiana: Innovazione Clinica”, questo tassello è decisivo: senza una strategia regolatoria solida, le applicazioni di IA in ospedale, nei territori PNRR e nella medicina personalizzata restano sulla carta. Qui vediamo come impostare in concreto la conformità per i dispositivi medici basati su IA, alla luce del documento congiunto AIB/MDCG 2025, e cosa significa per produttori, CIO sanitari e direzioni sanitarie italiane.
1. Perché MDR/IVDR e AI Act vanno gestiti come un unico sistema
La regola di base è semplice: per i dispositivi medici, l’AI Act “si appoggia” a MDR e IVDR. Non crea una seconda classificazione parallela, ma usa quella esistente per decidere se un sistema IA è ad alto rischio.
In pratica:
- se il tuo software è un dispositivo medico o un IVD;
- e per quella classe è necessario un organismo notificato (quasi sempre, dalla classe IIa / A sterile in su),
allora il sistema di IA è automaticamente “high-risk AI” ai sensi dell’AI Act.
Questo è il motivo per cui:
- quasi tutti i software medici con IA (diagnostica per immagini, triage, supporto alla prescrizione, monitoraggio fisiologico) rientrano nella categoria ad alto rischio;
- l’idea di “fare prima MDR e poi, magari, più avanti l’AI Act” è fuorviante. Le due cose vanno pensate e documentate insieme.
Per chi lavora nella sanità italiana, questo significa rivedere il modo classico di sviluppare software clinico:
non basta dimostrare che il dispositivo è sicuro e performante, bisogna anche dimostrare che l’algoritmo è governato, tracciabile, non discriminatorio e sotto controllo umano.
2. Primo passo: classificare correttamente il software medico
La classificazione MDR/IVDR è il punto di partenza di tutto. È da lì che discende l’etichetta “alto rischio” dell’AI Act.
Per il software medicale (MDR, Allegato VIII, regola 11), la situazione reale è questa:
- software che fornisce informazioni usate per decisioni diagnostiche o terapeutiche → di norma classe IIa o superiore;
- se da quelle decisioni può derivare decesso o danno irreversibile → classe III;
- se può derivare grave deterioramento delle condizioni o un intervento chirurgico → classe IIb;
- software che monitora processi fisiologici → almeno classe IIa, con passaggio a IIb se i parametri sono vitali con pericolo immediato.
Nella pratica di mercato, questo porta a una conseguenza chiara:
un dispositivo medico software con IA in classe I è l’eccezione, non la regola.
Esempio concreto (radiologia)
Un software di diagnostica per immagini con IA che suggerisce la probabilità di una lesione polmonare su TAC o RX:
- fornisce informazioni usate per decisioni diagnostiche;
- può influenzare la diagnosi di tumore o di patologie gravi.
È quindi molto difficile che resti in classe I: di fatto verrà inquadrato almeno in classe IIa/IIb, con AI ad alto rischio.
Per i team R&D e regolatori il messaggio è netto: la classificazione conservativa per “restare bassi” di classe è un boomerang. Ritarda l’ingresso sul mercato quando poi si scopre che serviva un ON e che il sistema IA era high-risk.
3. Sistema qualità unico per MDR/IVDR e AI Act: come strutturarlo
La soluzione proposta da AIB e MDCG è molto pragmatica: un solo sistema di gestione della qualità e un solo corpus di documentazione tecnica, esteso per coprire anche i requisiti dell’AI Act.
3.1 Cosa aggiungere al sistema qualità esistente
Se hai già un QMS conforme a MDR/IVDR (ISO 13485, risk management ISO 14971, ecc.), non devi reinventare tutto. Devi estenderlo sui punti chiave dell’IA:
-
Risk management algoritmico:
- rischi da errori di predizione (falsi positivi/negativi);
- rischi da bias nei dati (es. performance peggiori su determinate fasce d’età o gruppi etnici);
- rischi da mancata robustezza (modello che degrada con dati reali diversi dai dati di training);
- rischi da mancata trasparenza: l’utente non capisce limiti e condizioni di uso del modello.
-
Verifica e validazione del modello IA:
- protocollo dei test di accuratezza, sensibilità, specificità;
- validazione su dataset indipendenti e, quando possibile, multicentrici;
- verifica della supervisione umana (come e quando il clinico interviene, come può ignorare o correggere l’output IA).
-
Processi di sviluppo del modello:
- controllo delle versioni del modello e dei pesi;
- tracciabilità tra dati usati per il training, data cleaning e modello finale;
- criteri per approvare o bloccare nuove versioni.
L’AI Act consente espressamente di effettuare la valutazione di conformità IA all’interno della procedura MDR/IVDR. Tradotto: l’organismo notificato che già valuta sicurezza e prestazioni del tuo dispositivo valuterà anche conformità AI Act. Ma solo se trova un sistema qualità che tiene insieme, in modo coerente, prodotto medico e algoritmo.
3.2 Documentazione tecnica integrata
Per ridurre tempi e costi di audit, conviene strutturare la documentazione tecnica in modo integrato:
- una Technical Documentation MDR/IVDR che includa sezioni dedicate ai requisiti AI Act;
- un unico risk management file che copra rischi clinici e rischi IA;
- una sezione chiara su supervisione umana, trasparenza, gestione dei dati richiesta dall’AI Act.
La logica è:
un solo dossier tecnico ben strutturato, invece di due fascicoli separati che dicono (quasi) le stesse cose.
4. Dati, bias e rappresentatività: dove molti progetti IA sanitari falliscono
Nel contesto italiano – con forti differenze regionali, popolazione che invecchia e variabilità di organizzazione tra ospedali grandi e piccoli – la governance dei dati è il punto critico.
4.1 Cosa chiedono MDR/IVDR e AI Act sui dati
- MDR/IVDR vogliono dati clinici affidabili per dimostrare sicurezza e prestazioni: registri, studi clinici, studi post-market.
- L’AI Act aggiunge vincoli stringenti su:
- rappresentatività dei dataset rispetto alla popolazione target;
- riduzione dei bias (es. non addestrare un modello di triage cardiologico quasi solo su pazienti uomini di 50–70 anni);
- tracciabilità dei dati lungo tutto il ciclo di vita;
- sicurezza e conformità a GDPR e norme nazionali.
4.2 Esempio pratico (telemedicina territoriale PNRR)
Pensa a un sistema IA che, integrato in una piattaforma di telemedicina per pazienti cronici, segnala in anticipo scompensi o peggioramenti. Se il dataset di training proviene quasi solo da una grande azienda ospedaliera del Nord:
- il modello potrà funzionare bene in quel contesto,
- ma rischia di performare peggio su pazienti con profilo socio-economico diverso o con pattern di comorbidità tipici di altre regioni.
Per essere conforme all’AI Act – e davvero utile alla sanità italiana – bisogna:
- progettare da subito una strategia dati multicentrica e nazionale, dove possibile;
- documentare come si è valutata la rappresentatività con indicatori quantitativi (es. distribuzioni per età, sesso, patologie chiave);
- prevedere nel PMS meccanismi per rilevare differenze di performance tra sottogruppi di pazienti.
Questo non è solo un obbligo di legge. È anche ciò che evita che l’IA in sanità crei nuove disuguaglianze, ad esempio fra grandi hub metropolitani e ospedali periferici.
5. Valutazione clinica e test IA: un processo unico, non due studi separati
Per un dispositivo medico basato su IA non esistono “studi clinici da MDR” e “test algoritmici da AI Act” separati. Devono confluire in un’unica strategia di valutazione clinica.
5.1 Cosa deve dimostrare il fabbricante
-
Sicurezza e prestazioni cliniche secondo MDR/IVDR:
- disegno di studio appropriato (retrospettivo/prospettico, singolo centro o multicentrico);
- endpoint clinici chiari (diagnosi corretta, riduzione errori, tempi di refertazione, ecc.);
- confronto con standard of care o con il giudizio di esperti.
-
Prestazioni IA secondo AI Act:
- metriche di accuratezza, robustezza e resilienza del modello;
- analisi delle prestazioni per sottogruppi (età, sesso, eventuali gruppi rilevanti);
- descrizione concreta della supervisione umana (workflow clinico reale).
5.2 Come strutturare la documentazione
L’approccio che funziona meglio è:
-
un solo Clinical Evaluation Report (CER) che includa:
- evidenze cliniche tradizionali;
- risultati dei test IA e delle analisi di bias;
- descrizione di come il sistema viene usato in pratica (integrazione in PACS/RIS, cartella clinica, piattaforme di telemedicina).
-
un collegamento chiaro con:
- il risk management file;
- il piano di sorveglianza post-market.
In altre parole, l’IA non è un “di più tecnologico”: è parte integrante del razionale clinico del dispositivo. E va dimostrato.
6. Modelli che si aggiornano da soli: come evitare di rifare la certificazione ogni volta
Per molti produttori italiani il tema più spinoso è quello dei modelli con apprendimento continuo (continual learning). L’AI Act introduce il concetto di “modifica sostanziale”: ogni cambiamento che incide sulla conformità del sistema richiede una nuova valutazione.
La buona notizia è che il documento AIB/MDCG chiarisce una via praticabile:
se il fabbricante predetermina e documenta le modifiche previste già in fase iniziale, queste non sono considerate modifiche sostanziali.
6.1 Cosa significa nella pratica
Per un sistema IA che aggiorna periodicamente i propri modelli, è essenziale:
-
descrivere in anticipo:
- frequenza e modalità di aggiornamento (es. retraining trimestrale);
- limiti quantitativi accettabili di variazione delle prestazioni;
- controlli automatici e manuali prima del rilascio della nuova versione.
-
integrare questi elementi in:
- documentazione tecnica;
- processo di gestione delle modifiche del QMS;
- valutazione dei rischi.
Se il comportamento del sistema resta dentro il perimetro previsto, non serve rifare da zero la certificazione. Se invece un aggiornamento introduce nuove funzionalità, nuove categorie di pazienti o modifica profondamente le prestazioni, siamo di fronte a un cambiamento significativo (MDR/IVDR) e a una probabile modifica sostanziale (AI Act): lì servirà tornare dall’organismo notificato.
Per chi progetta piattaforme di IA in sanità è il momento di passare da “aggiorniamo il modello quando ci pare” a un ciclo di vita controllato dell’algoritmo, con ruoli, soglie e responsabilità chiare.
7. Sorveglianza post-market e monitoraggio IA: un solo cruscotto
La fase post-market è dove molti progetti di IA clinica si fermano: il sistema viene installato, ma manca un vero monitoraggio strutturato.
MDR/IVDR chiedono:
- un Piano di Sorveglianza Post-Market (PMS);
- rapporti periodici di sicurezza (PSUR) per dispositivi di classe più alta;
- gestione attiva di incidenti, reclami, segnali di rischio.
L’AI Act aggiunge l’obbligo di un monitoraggio continuo dei sistemi IA ad alto rischio, per rilevare:
- malfunzionamenti;
- bias emergenti;
- problemi di trasparenza;
- interazioni inattese con altri sistemi.
7.1 Come integrare PMS e monitoraggio IA
Per evitare un doppio sistema ingestibile, conviene costruire un unico cruscotto di sorveglianza che registri:
- performance cliniche reali (es. tassi di errore, tempo di refertazione, outcome);
- performance del modello IA (accuratezza nel mondo reale vs dati di validazione);
- segnalazioni da parte degli utenti clinici (feedback sull’utilità degli output, casi di mancata fiducia nel sistema);
- eventi che attivano una revisione del modello o del dispositivo.
Nella sanità italiana, dove i data warehouse regionali e le infrastrutture PNRR stanno crescendo, chi saprà integrare PMS e monitoraggio IA in modo smart avrà un vantaggio competitivo enorme: prodotti più sicuri, meno richiami, relazioni più solide con aziende sanitarie e Regioni.
Conclusioni: dall’adempimento regolatorio alla strategia di innovazione
L’interazione tra MDR/IVDR e AI Act non è un nodo burocratico da sciogliere a fine progetto. È il telaio su cui costruire l’intera strategia di IA nella sanità italiana: dalla diagnostica per immagini alla telemedicina, dalla medicina personalizzata alla gestione dei percorsi clinici.
Chi progetta oggi dispositivi medici basati su IA dovrebbe chiedersi:
- il mio QMS è pronto per integrare davvero l’AI Act o sto accumulando debito regolatorio?
- sto raccogliendo dati rappresentativi della popolazione italiana o sto costruendo algoritmi che funzionano solo in un singolo centro?
- ho definito un piano chiaro per aggiornamenti e sorveglianza post-market del modello?
Chi inizia ora a strutturarsi su questi punti arriverà al 02/08/2027 con dispositivi pronti, certificabili e credibili agli occhi di clinici, direzioni sanitarie e autorità. Gli altri rischiano di vedere i propri progetti di IA restare nello spazio dei pilot, senza mai diventare davvero parte dell’innovazione clinica quotidiana.
Per la serie “IA nella Sanità Italiana: Innovazione Clinica”, questo è il messaggio chiave: senza una governance regolatoria robusta, l’IA non entra in corsia. Il momento giusto per costruirla è adesso.