IA nei dispositivi medici: cosa fare per essere conformi

IA e dispositivi medici: chi non governa la compliance si ferma

Nel 2025 ogni nuovo progetto di sanità digitale in Italia che abbia un minimo di ambizione passa, prima o poi, da un algoritmo di intelligenza artificiale. Radiologia, triage in Pronto Soccorso, telemedicina, monitoraggio remoto, decision support per la terapia: tutto si appoggia a software che, molto spesso, sono dispositivi medici basati su IA.

La realtà? Se non governi bene la conformità a MDR, IVDR e AI Act, il progetto non arriva mai al letto del paziente. O si blocca nella fase di marcatura CE, o viene respinto dal comitato etico, o viene congelato dalla direzione sanitaria per timore di responsabilità.

In questa guida, parte della serie “IA nella Sanità Italiana: Innovazione Clinica”, metto in fila in modo pratico che cosa significa oggi, per un produttore o per una struttura sanitaria italiana, sviluppare o adottare un dispositivo medico con IA ad alto rischio in linea con le norme europee.

---

1. Capire l’incrocio tra MDR/IVDR e AI Act

La prima cosa da chiarire: un dispositivo medico che integra un sistema di IA ad alto rischio deve rispettare sia MDR/IVDR sia l’AI Act. Non si sceglie una strada o l’altra, le due normative vanno lette insieme.

MDR e IVDR: la base per chi fa medical device

Per il contesto sanitario italiano, i riferimenti restano:

• MDR (Regolamento UE 2017/745) per dispositivi medici “classici” e software di diagnostica, supporto decisionale, chirurgia, monitoraggio ecc.
• IVDR (Regolamento UE 2017/746) per i dispositivi medico-diagnostici in vitro, compresi quelli che elaborano dati di laboratorio con algoritmi.

In pratica MDR/IVDR chiedono di:

• classificare il rischio del dispositivo;
• definire intended purpose e specifiche cliniche;
• impostare un sistema di gestione della qualità (QMS);
• progettare, validare e sorvegliare il prodotto lungo tutto il ciclo di vita;
• dimostrare sicurezza, prestazioni e beneficio clinico.

AI Act: requisiti aggiuntivi per i sistemi ad alto rischio

Con l’AI Act (Regolamento UE 2024/1689), molti software di IA usati in sanità rientrano nella categoria “high-risk AI systems”. Questo significa requisiti ulteriori rispetto al MDR/IVDR, in particolare su:

• governance dei dati di addestramento e test;
• trasparenza e tracciabilità del modello e dei risultati;
• gestione del rischio specifico dell’IA (bias, errori sistematici, degradazione delle prestazioni nel tempo);
• sorveglianza umana (human oversight) chiara e documentata;
• robustezza, cybersecurity, gestione aggiornata delle versioni.

Il documento congiunto Artificial Intelligence Board + Medical Device Coordination Group va esattamente in questa direzione: aiutare i fabbricanti a costruire un unico percorso di conformità evitando duplicazioni e incoerenze.

Un solo dispositivo, due regimi normativi. L’obiettivo è avere un fascicolo tecnico unico che risponda a entrambe le logiche.

---

2. Quando l’IA diventa un “dispositivo medico” in Italia

Per chi lavora in ospedale o in un’azienda di software, la domanda pratica è: quando il mio algoritmo rientra nel perimetro del MDR e dell’AI Act?

Criterio chiave: lo scopo clinico (intended purpose)

Un sistema di IA è considerato dispositivo medico se il suo scopo è, ad esempio:

• diagnosticare o contribuire alla diagnosi (es. analisi immagini TAC, refertazione automatica di ECG);
• prevenire, monitorare, predire il decorso di una malattia (es. rischio di riammissione ospedaliera a 30 giorni);
• supportare decisioni terapeutiche (es. suggerimento del dosaggio di un farmaco in oncologia);
• gestire parametri vitali e allarmi in contesti critici (es. monitoraggio intensivo remoto).

Se l’algoritmo influenza direttamente una decisione clinica, con impatto su diagnosi o terapia, è quasi sempre in area medical device. E, se basato su tecniche di IA, molto probabilmente sarà anche AI ad alto rischio per l’AI Act.

Esempi concreti nel contesto italiano

• Software di triage radiologico che priorizza le immagini sospette di ictus: DM di classe IIa/IIb, AI ad alto rischio.
• Algoritmo che nel telemonitoraggio PNRR segnala peggioramenti dei parametri di un paziente cronico: DM + AI high-risk se supporta decisioni cliniche.
• Strumento di “analytics” puramente statistico per report gestionali, senza impatto diretto sulla cura del singolo paziente: spesso fuori perimetro MDR e AI high-risk.

Capire fin dall’inizio se si è in ambito MDR/IVDR + AI Act evita mesi persi e progetti sperimentali che non potranno mai scalare a uso routinario.

---

3. Come armonizzare i requisiti: una roadmap operativa

Per un fabbricante – ma anche per una struttura sanitaria che co‑sviluppa algoritmi con partner tecnologici – la domanda pratica è: da dove parto?

La risposta più efficace è impostare un percorso integrato di compliance organizzato in fasi.

3.1 Analisi iniziale: scopo, rischio, ruoli

1. Definizione chiara dello scopo clinico (intended use) e del contesto d’uso (ospedale, territorio, domicilio).
2. Classificazione MDR/IVDR del software come dispositivo medico (classe I, IIa, IIb, III) o IVD (classi A-D).
3. Valutazione della probabilità che il sistema sia AI “high-risk” (spoiler: nella quasi totalità dei DM con IA).
4. Definizione dei ruoli: chi è fabbricante? chi è fornitore del modello? chi integra? Nelle gare PNRR questo punto è spesso sottovalutato.

3.2 Sistema di gestione qualità che parli “medico” e “AI”

Serve un QMS unico che tenga conto sia del MDR/IVDR sia dell’AI Act. Gli elementi critici:

• processi documentati di sviluppo software e gestione del ciclo di vita;
• procedure per la gestione dei dati (raccolta, anonimizzazione/pseudonimizzazione, consenso, qualità);
• regole per addestramento, validazione, test e re‑training dei modelli;
• workflow di change management per ogni modifica dell’algoritmo, con valutazione d’impatto clinico e regolatorio;
• integrazione con i requisiti di cybersecurity in sanità (NIS2, misure minime, policy aziendali).

Chi lavora in ospedale spesso scopre tardi che ogni update “minore” del modello può richiedere una rivalutazione ai fini MDR e AI Act. Meglio prevederlo nella governance fin dall’inizio.

3.3 Data governance e gestione del bias

L’AI Act insiste in modo molto esplicito su qualità e rappresentatività dei dati. In sanità italiana questo aspetto è delicato:

• dataset spesso sbilanciati geograficamente (Nord molto rappresentato, Sud meno);
• scarsa rappresentanza di alcune fasce di età o di specifiche condizioni cliniche;
• dati non strutturati (referti testuali, immagini, pdf storici).

Per essere conformi e – soprattutto – clinicamente affidabili, i fabbricanti dovrebbero:

• documentare l’origine dei dati (Fascicolo Sanitario Elettronico, database ospedalieri, studi clinici);
• descrivere criteri di inclusione/esclusione e tecniche di pulizia dei dati;
• effettuare analisi di bias e adottare misure correttive;
• prevedere monitoraggi periodici delle prestazioni del modello per fasce di popolazione.

In un Paese con forti differenze territoriali come l’Italia, dichiarare apertamente per quale popolazione il modello è validato è una scelta onesta e conforme.

---

4. Human oversight, trasparenza e responsabilità clinica

Uno dei punti più fraintesi dai clinici è la relazione tra algoritmo di IA e responsabilità del medico. L’AI Act e il documento AI Board/MDCG puntano molto su questo aspetto.

4.1 Sorveglianza umana: chi controlla cosa

Un sistema di IA ad alto rischio in sanità deve sempre prevedere:

• ruoli clinici chiari: chi utilizza l’output? radiologo, cardiologo, infermiere?
• indicazione di quando l’algoritmo può essere ignorato o superato dal giudizio clinico;
• limiti d’uso (es. non usare su pazienti pediatrici se non validato);
• interfaccia che consenta al professionista di comprendere il livello di confidenza dell’algoritmo e le possibili incertezze.

Non è un dettaglio grafico: è un requisito di compliance e una barriera contro un uso “automatico” del referto IA.

4.2 Informazione al paziente e trasparenza

Nel contesto GDPR e consenso informato, è sempre più difficile sostenere l’uso di IA “nascosta”. Per essere allineati alle migliori pratiche:

• informare il paziente quando la sua diagnosi/terapia è supportata anche da un sistema di IA;
• spiegare in modo comprensibile i benefici e i limiti (es. riduzione tempi di refertazione, ma non sostituzione del medico);
• indicare se l’algoritmo è in fase di valutazione clinica o già parte della pratica standard.

Questa trasparenza non è solo un obbligo etico: riduce il rischio di contenziosi quando qualcosa va storto.

4.3 Chi risponde se l’IA sbaglia?

La ripartizione delle responsabilità richiede coordinamento tra:

• produttore del dispositivo (difetti di progettazione, training dati insufficienti);
• struttura sanitaria (uso fuori indicazione, mancata formazione dei clinici);
• singolo professionista (mancato controllo critico dell’output algoritmico).

Chi sta progettando soluzioni IA per la sanità italiana dovrebbe integrare, nei contratti e nelle policy interne, clausole chiare su:

• ambito d’uso ammesso;
• requisiti minimi di formazione degli operatori;
• modalità di segnalazione e gestione degli incidenti e quasi‑incidenti;
• aggiornamenti e manutenzione del sistema.

---

5. Consigli pratici per aziende sanitarie e fornitori

Per chi lavora in una ASL, AO, IRCCS o policlinico universitario, e per i fornitori di soluzioni IA, il modo più efficiente di affrontare MDR/IVDR + AI Act è trasformare la compliance in un pezzo strutturale della strategia di innovazione clinica.

5.1 Per le strutture sanitarie

• Creare un gruppo interno multidisciplinare (direzione sanitaria, ICT, ingegneria clinica, privacy, risk management, clinici) dedicato ai progetti con IA.
• Inserire nei capitolati di gara requisiti chiari su:
  • marcatura CE MDR/IVDR;
  • classificazione come sistema di IA ad alto rischio;
  • disponibilità di documentazione tecnica AI Act‑ready;
  • piano di formazione e supporto agli utenti clinici.
• Integrare i flussi di post‑market surveillance del fornitore con quelli di incident reporting aziendali.

5.2 Per i produttori e gli sviluppatori di IA in sanità

• Coinvolgere esperti regolatori e clinici già nelle fasi di design, non alla fine.
• Documentare sin dall’inizio:
  • dataset usati, versioni del modello, metriche di performance;
  • scenari d’uso clinici e limitazioni;
  • decision log delle scelte architetturali e dei trade‑off.
• Pensare in ottica scalabilità nazionale: un’IA validata solo su un singolo ospedale rischia di non reggere il confronto quando si passa a una Regione o a un programma PNRR multi‑azienda.

Chi farà per bene questi passi avrà un vantaggio competitivo enorme: i progetti pronti alla compliance verranno scelti prima, perché permettono alle direzioni sanitarie di ridurre tempi, rischi e frizioni con i controllori.

---

6. Perché la compliance è una leva di innovazione, non un freno

Nel percorso “IA nella Sanità Italiana: Innovazione Clinica” questo tema torna continuamente: la regolazione europea non è solo un insieme di paletti, è anche un framework di qualità.

Un dispositivo medico con IA che rispetta MDR/IVDR e AI Act:

• ha dati tracciabili, meno bias e risultati più affidabili;
• si integra meglio in contesti complessi come telemedicina, Fascicolo Sanitario Elettronico e piattaforme regionali;
• dà più tutele ai professionisti e ai pazienti;
• ha molte più chance di essere adottato stabilmente, non solo in progetti pilota.

Chi opera oggi nella sanità italiana – che sia un CTO di azienda medtech, un direttore sanitario o un clinico innovatore – ha davanti una scelta netta:

trattare la compliance come un ostacolo burocratico oppure usarla come spina dorsale di una innovazione clinica robusta e scalabile.

Se punti alla seconda opzione, il passo successivo è fare un check concreto sui tuoi progetti IA: sono davvero allineati a MDR/IVDR e AI Act, o vivono ancora in una “zona grigia” sperimentale? Più in fretta risponderai a questa domanda, più velocemente l’IA entrerà nella pratica quotidiana, in sicurezza, nei reparti italiani.