EU AI Act per life sciences: quando l'IA è ad alto rischio

L'assunzione errata più diffusa sull'AI Act UE è la seguente: che un sistema di IA sia classificato come ad alto rischio dipenderebbe dalla complessità del modello o dal grado di autonomia decisionale. Nel settore life sciences questa premessa è sbagliata. Per l'IA in dispositivi medici e diagnostici in vitro non è la tecnologia a determinare la classificazione, ma il percorso regolatorio che il prodotto segue già. Chi non coglie questo meccanismo valuta il proprio sistema in modo intuitivo, e spesso si trova sul lato sbagliato del livello di regolamentazione più stringente.

Cosa determina lo status di alto rischio

L'AI Act UE (Regolamento (UE) 2024/1689) prevede due percorsi per la categoria ad alto rischio; per il settore life sciences il primo è quello prevalente.

Ai sensi dell'art. 6, par. 1 un'IA è classificata come IA ad alto rischio quando ricorrono due condizioni: il sistema di IA è una componente di sicurezza di un prodotto oppure è esso stesso un prodotto che rientra in uno degli atti normativi di armonizzazione elencati, tra cui MDR (EU 2017/745) e IVDR (EU 2017/746), e tale prodotto deve essere sottoposto a valutazione della conformità da parte di un organismo notificato. Proprio qui la classificazione MDR/IVDR diventa l'elemento determinante: il software classificato come dispositivo medico ai sensi della MDR tipicamente a partire dalla classe IIa è soggetto a valutazione della conformità da parte di un organismo notificato. Per gli IVD lo stesso meccanismo opera attraverso le classi di rischio della IVDR. La classificazione secondo la normativa di prodotto concorre quindi a determinare se l'AI Act si applica nella sua forma più stringente.

Il secondo percorso passa per l'art. 6, par. 2 e l'elenco dei casi d'uso dell'allegato III. Quest'ultimo riguarda l'IA in determinati ambiti applicativi indipendentemente dalla normativa di prodotto. Per i fabbricanti di dispositivi medici e IVD il percorso prodotto ai sensi del par. 1 è nella pratica quello dominante, poiché si collega direttamente alla valutazione della conformità MDR/IVDR già in corso.

Perché l'ordine della verifica è rilevante

La classe di rischio non è un'etichetta applicata a posteriori, ma il primo passaggio. Solo una volta accertato se un sistema è IA ad alto rischio è possibile stabilire se gli obblighi degli artt. 8-15 si applicano effettivamente. Chi salta questa classificazione va a vuoto in due direzioni: costruisce prove per un insieme di obblighi che non lo riguardano, oppure trascura requisiti che avrebbe già dovuto soddisfare.

Un errore ricorrente: la classificazione viene discussa internamente ma non viene formalizzata per iscritto. L'art. 9 AI Act richiede un sistema di gestione del rischio documentato. In sede di audit una classificazione non documentata equivale a un requisito non soddisfatto e impone un intervento correttivo prima che qualsiasi altro obbligo possa essere affrontato in modo produttivo. La motivazione della classe di rischio (quale percorso ai sensi dell'art. 6, quale classe di prodotto, quale organismo notificato) deve pertanto essere conservata per iscritto fin dall'inizio.

Quali obblighi si applicano all'IA ad alto rischio

Una volta stabilita la classificazione come IA ad alto rischio, si applicano i requisiti degli artt. 8-15 AI Act. I punti centrali per i sistemi life sciences:

• Gestione del rischio (art. 9): un sistema continuo e documentato sull'intero ciclo di vita, non una valutazione una tantum.
• Dati e data governance (art. 10): prove relative a fonti, revisione dei bias e rappresentatività dei dati di addestramento, validazione e test. Il livello richiesto è superiore alla normale prassi di sviluppo ML: rappresentatività e copertura demografica devono essere dimostrate, non semplicemente assunte.
• Documentazione tecnica (art. 11 + allegato IV): descrizione del sistema, documentazione dei dati di addestramento, metriche di performance, descrizione della supervisione umana e valutazione della robustezza. Questi contenuti specifici per l'IA vanno oltre la documentazione tecnica classica richiesta dalla MDR.
• Supervisione umana (art. 14): implementata come principio di progettazione e dimostrata attraverso la documentazione di design e UX. La mera possibilità teorica per un utilizzatore di intervenire non è sufficiente in assenza di un meccanismo documentato.
• Accuratezza, robustezza, cybersicurezza (art. 15): limiti di performance documentati e resistenza a errori e manipolazioni.
• Monitoraggio post-commercializzazione (art. 72): un sistema di post-market monitoring che rilevi le performance del modello, il concept drift e gli output indesiderati durante l'esercizio.

Il vero collo di bottiglia risiede nella parallelità. Il Software as Medical Device è soggetto contemporaneamente a MDR o IVDR e all'AI Act. Chi gestisce entrambi i quadri come progetti separati con propri set di documenti genera un onere di manutenzione ridondante e versioni contraddittorie. Il post-market monitoring ai sensi dell'art. 72, ad esempio, può essere integrato con la post-market surveillance MDR/IVDR esistente invece di essere condotto in parallelo. Quando l'IA è impiegata in processi GxP, ad esempio nella produzione farmaceutica, nel controllo qualità o nei sistemi di laboratorio, la bozza di GMP Annex 22 (in consultazione nel 2025, non ancora definitiva) aggiunge un ulteriore livello sopra il GMP Annex 11 sui sistemi computerizzati. Questi requisiti devono essere considerati tempestivamente, anche se l'annex non è ancora stato adottato.

Quali date di applicazione contano

L'AI Act UE è in vigore dall'agosto 2024 e si applica in modo scaglionato. Nel luglio 2026 i termini per l'alto rischio sono stati posticipati: il Regolamento (UE) 2026/1744 (Digital Omnibus sull'IA) è stato pubblicato nella Gazzetta Ufficiale il 24 luglio 2026 ed è entrato in vigore il 27 luglio 2026. Il quadro attuale:

• Il divieto di determinate pratiche di IA ai sensi dell'art. 5 è in vigore dal febbraio 2025.
• Gli obblighi di trasparenza ai sensi dell'art. 50 (informativa sull'interazione con l'IA, marcatura dei contenuti sintetici) si applicano dal 2 agosto 2026.
• Gli obblighi per l'IA ad alto rischio dei casi d'uso dell'allegato III si applicano ora dal 2 dicembre 2027, prima era il 2 agosto 2026.
• Per l'IA che in quanto prodotto o componente di sicurezza rientra in MDR o IVDR ai sensi dell'art. 6, par. 1 e per la cui conformità di prodotto è necessaria una valutazione di conformità da parte di terzi, vale ora il 2 agosto 2028, prima il 2 agosto 2027.

Per molti fabbricanti di dispositivi medici e IVD il 2 agosto 2028 è quindi la data determinante, poiché la loro IA segue il percorso prodotto. Ciò vale però solo alla condizione indicata: senza una valutazione di conformità da parte di terzi per la conformità del prodotto quel termine non si applica, e non ogni dispositivo medico basato su IA vi è soggetto. L'anno di rinvio dà respiro al calendario, non è un motivo per attendere. Non cambia l'approccio: classificazione, analisi dei gap e costruzione delle prove ai sensi dell'allegato IV richiedono un adeguato anticipo, tanto più che l'organismo notificato è coinvolto nella valutazione. Chi considera il termine lontano sottovaluta l'onere connesso alla data governance e alla documentazione tecnica.

Cosa fare

Il primo passo è la classificazione documentata ai sensi dell'art. 6: percorso prodotto ai sensi del par. 1 o elenco dei casi d'uso ai sensi del par. 2, con motivazione tracciabile. A questo si collega un'analisi dei gap rispetto agli artt. 8-15, e su questa base un modello di integrazione che riconduca le prove richieste dall'AI Act alla documentazione tecnica esistente, al QMS e al sistema post-market, invece di costruire un secondo archivio parallelo.

Entourage interviene esattamente in questo punto: nella classificazione ai sensi dell'art. 6, nell'analisi dei gap rispetto ai requisiti per l'alto rischio e nell'integrazione con MDR, IVDR e, ove applicabile, la bozza di Annex 22. L'obiettivo è un quadro probatorio in cui ogni requisito è documentato una sola volta e aggiornato in modo coerente.