MDR incontra EU AI Act: il trilemma per il software IA

Il software IA in ambito medico viene spesso trattato come una questione di pura autorizzazione: prima soddisfare la MDR (Regolamento (UE) 2017/745), poi verificare se l'EU AI Act (Regolamento (UE) 2024/1689) richiede qualcosa in aggiunta. Proprio questa sequenza conduce nella direzione sbagliata. I due regolamenti non si applicano uno dopo l'altro, ma contemporaneamente sullo stesso prodotto. Chi li imposta come progetti separati con team propri e fascicoli propri costruisce la variante più costosa: due universi documentali che divergono, si contraddicono a vicenda e risultano entrambi problematici in sede di audit.

Perché da due regolamenti nasce un trilemma

Il problema ha tre poli. La MDR chiede se il vostro software è un dispositivo medico e in quale classe di rischio rientra. L'AI Act chiede come il sistema di IA viene costruito, addestrato e monitorato. Ed entrambi richiedono alla fine una prova sullo stesso artefatto: il software che arriva al paziente.

La leva si trova nell'Art. 6 Par. 1 EU AI Act: un sistema di IA è considerato ad alto rischio se è componente di sicurezza di un prodotto o costituisce esso stesso un prodotto soggetto a valutazione della conformità da parte di un organismo notificato ai sensi della legislazione di armonizzazione, come la MDR o l'IVDR (Regolamento (UE) 2017/746). La classificazione MDR o IVDR è quindi il fattore scatenante per la classificazione AI Act. Il software che deve essere sottoposto a un organismo notificato come dispositivo medico rientra generalmente in modo automatico nel livello più rigoroso dell'AI Act. La classificazione regolamentare secondo il diritto di prodotto non determina quindi solo gli obblighi MDR, ma apre al contempo la porta a un secondo catalogo di obblighi.

Cosa richiede l'AI Act oltre alla MDR

Una volta stabilita la classificazione come IA ad alto rischio, si applicano i requisiti degli Art. 8-15 EU AI Act. Molti hanno una corrispondenza nella MDR, ma non sono identici:

• Gestione del rischio (Art. 9): Un sistema di gestione del rischio continuo che si sovrappone alla gestione del rischio MDR secondo ISO 14971:2019, ma deve affrontare esplicitamente rischi specifici dell'IA come il model drift e il comportamento errato in presenza di input atipici.
• Data governance (Art. 10): Qui la situazione si stringe per molti produttori. L'AI Act richiede rappresentatività documentata dei dati di addestramento, validazione e test, nonché un bias review. Questo supera il livello abituale dello sviluppo ML e non ha un corrispettivo diretto nella documentazione tecnica MDR classica.
• Documentazione tecnica (Art. 11 + Allegato IV): Un catalogo documentale proprio che si sovrappone alla documentazione tecnica MDR, ma richiede contenuti aggiuntivi su descrizione del sistema, dati di addestramento e metriche di prestazione.
• Supervisione umana (Art. 14): Deve essere implementata e dimostrata come principio di progettazione. Il fatto che un utente potrebbe teoricamente intervenire non è sufficiente senza un meccanismo documentato.
• Accuratezza, robustezza, cybersicurezza (Art. 15): Strettamente correlato ai requisiti MDR e alla visione del software secondo IEC 62304, ma con un focus proprio sulle prestazioni statistiche del modello.

Il punto decisivo: non si tratta di due mondi completamente estranei, bensì di requisiti fortemente sovrapposti con accenti diversi. Proprio questa sovrapposizione rappresenta l'opportunità, e al contempo la trappola se viene ignorata.

Le insidie tipiche all'interfaccia

Nella pratica questi progetti falliscono raramente a causa di un singolo requisito, ma a causa dell'organizzazione dell'interfaccia:

• Doppia gestione dei fascicoli. AI Act e MDR vengono gestiti come iniziative separate, ognuna con un proprio set di documenti. Il risultato è un onere di manutenzione ridondante e versioni che divergono. Un rischio che nel fascicolo MDR risulta "mitigato" appare invariato come aperto nel fascicolo AI Act, e entrambe le versioni vengono presentate all'organismo notificato.
• Classificazione senza documentazione. La classificazione come alto rischio viene discussa internamente ma non formalizzata. Art. 9 EU AI Act richiede un sistema di gestione del rischio documentato; una classificazione solo discussa è considerata non soddisfatta in sede di audit.
• Data governance a livello ML. I dati di addestramento vengono trattati come in un normale progetto ML, senza documentazione delle fonti, bias review e prova di rappresentatività secondo Art. 10. Questo lascia aperto un requisito centrale di alto rischio, anche se il modello funziona.
• Mancanza di coordinamento nel post-market. Il monitoraggio dell'IA secondo Art. 72 EU AI Act viene gestito separatamente dalla Post-Market Surveillance MDR. Le osservazioni sulle prestazioni del modello e sugli output indesiderati non confluiscono quindi nella stessa valutazione degli altri dati di campo.

Si aggiunge il disallineamento temporale. Per l'IA che, come prodotto o componente di sicurezza, rientra nella MDR o IVDR (IA ad alto rischio secondo l'Allegato I), si applica il periodo di transizione più lungo dell'AI Act. Nel corso dei recenti adeguamenti all'AI Act, questa scadenza per i casi dell'Allegato I è stata spostata in avanti. Non si tratta di un classico margine di tempo: parti del quadro regolatorio, come le norme armonizzate e le linee guida, non sono ancora completamente definite in questa fase. Chi aspetta la chiarezza definitiva perde il tempo necessario per l'integrazione nello sviluppo in corso.

Cosa fare

La via d'uscita dal trilemma non è un terzo fascicolo, ma un framework integrato. Tre passi sono fondamentali:

1. Prima classificare. La classe di rischio MDR/IVDR determina la classificazione AI Act tramite Art. 6 Par. 1. Entrambe devono essere documentate prima che si possa derivare l'ambito degli obblighi.
2. Mappare i requisiti invece di duplicarli. Gli obblighi degli Art. 8-15 vengono mappati sulla documentazione tecnica MDR esistente, sul QMS e sul ciclo di vita del software secondo IEC 62304. Ogni requisito viene dimostrato una volta e mantenuto in modo coerente. Un sistema di gestione dell'IA secondo ISO/IEC 42001:2023 può fornire il quadro organizzativo.
3. Coordinare il post-market. Il monitoraggio secondo Art. 72 viene integrato nella Post-Market Surveillance MDR/IVDR, in modo che model drift e dati di campo confluiscano in un'unica valutazione.

Entourage interviene esattamente a questa interfaccia: classificazione secondo il diritto di prodotto e AI Act, mapping dei requisiti senza documentazione duplicata e integrazione nel QMS esistente. In questo modo, da due regolamenti rimane una prova per requisito invece di due universi documentali divergenti.