Impiego dell’Intelligenza Artificiale nei Dispositivi Medici: Regolamentazione e Conformità Normativa

“Without judgment, perception would increase a million times.”

— Death, “Without Judgment” ( album “Symbolic”)

Negli ultimi anni l’utilizzo dell’intelligenza artificiale (IA) nei dispositivi medici è cresciuto esponenzialmente, offrendo strumenti innovativi per diagnosi, monitoraggio e terapia. Ad esempio, negli Stati Uniti la Food and Drug Administration (FDA) ha autorizzato circa 950 dispositivi medici con funzionalità di IA entro agosto 2024, rispetto ai soli 6 dispositivi autorizzati nel 2015​

Questa rapida espansione evidenzia il potenziale dell’IA in ambito clinico, ma solleva anche importanti quesiti sulla sicurezza, efficacia e affidabilità di tali tecnologie. Per proteggere i pazienti e garantire qualità, i legislatori hanno introdotto nuovi quadri normativi sia in Europa sia negli USA, imponendo requisiti stringenti di regolamentazione e conformità per i dispositivi medici basati su IA.

Quadro Normativo Europeo: MDR e AI Act

In Europa, i dispositivi medici con funzionalità IA sono regolati principalmente dal Regolamento (UE) 2017/745 sui Dispositivi Medici (MDR), entrato pienamente in vigore nel 2021, e dal futuro Regolamento sull’Intelligenza Artificiale (AI Act) attualmente in fase di approvazione. Queste normative operano in parallelo: il MDR disciplina la sicurezza e la performance dei dispositivi medici in generale, mentre l’AI Act introdurrà requisiti specifici per i sistemi di IA, compresi quelli impiegati in dispositivi medici. Di seguito esaminiamo come entrambi impattano i produttori di dispositivi con IA.

MDR e Software Medico Basato su IA

Il MDR ha aggiornato in modo significativo le regole per i software medici, includendo esplicitamente le soluzioni basate su algoritmi intelligenti. Una novità chiave è la Regola 11 dell’Allegato VIII del MDR, che determina la classificazione del rischio dei software medici. In base a tale regola, la maggior parte dei software destinati a supportare decisioni diagnostiche o terapeutiche viene ora collocata in classi di rischio più elevate rispetto al passato​

In sintesi, secondo la Regola 11 del MDR:

• Un software che fornisce informazioni per prendere decisioni diagnostiche o terapeutiche è classificato almeno Classe IIa, a meno che un eventuale errore possa causare la morte o un deterioramento irreversibile della salute (in tal caso diventa Classe III) oppure possa causare un grave deterioramento della salute o richiedere un intervento chirurgico (allora diventa Classe IIb)
• Un software destinato a monitorare parametri fisiologici è in genere Classe IIa, a meno che monitori parametri vitali dove variazioni impreviste potrebbero mettere il paziente in pericolo immediato: in tal caso è Classe IIb​

Queste regole implicano che applicazioni IA molto diffuse – come strumenti di diagnostica per immagini, sistemi di supporto decisionale clinico o app per screening – difficilmente saranno classificate a basso rischio. Quasi ogni Software as Medical Device (SaMD) con IA ricade almeno in Classe IIa o superiore, laddove prima molti software venivano auto-classificati come Classe I (basso rischio)​

Il risultato è un innalzamento dell’asticella regolatoria: per dispositivi IA in Classe IIa, IIb o III, i produttori devono coinvolgere un Organismo Notificato per la valutazione di conformità, anziché autocertificare il prodotto. Ciò garantisce controlli indipendenti sul rispetto dei requisiti essenziali di sicurezza ed efficacia.

Oltre alla classificazione, il MDR prevede requisiti specifici per i software medici nell’Allegato I (Requisiti Generali di Sicurezza e Prestazione). Ad esempio, sono richieste misure appropriate di usabilità e riduzione dei rischi d’uso (Ann. I, sez. 14.2 e 14.5) e requisiti di affidabilità, ripetibilità e prestazioni per algoritmi che incorporano data analytics (Ann. I, sez. 17.1-17.4)​

I produttori di software con IA devono quindi implementare un rigoroso sistema di gestione della qualità (idealmente conforme alla ISO 13485) e seguire standard tecnici riconosciuti, come la IEC 62304 per il ciclo di vita del software medicale​e la ISO 14971 per la gestione del rischio. Anche la valutazione clinica è obbligatoria: bisogna fornire evidenze della performance clinica dell’algoritmo (es. accuratezza diagnostica) attraverso studi o letteratura scientifica, analogamente a quanto avviene per dispositivi tradizionali.

In pratica, ottenere la marcatura CE per un dispositivo medico basato su IA richiede:

1. Qualificazione – Verificare che il software rientri nella definizione di dispositivo medico in base allo scopo d’uso (criteri MDCG 2019-11)​
2. Classificazione – Determinare la classe di rischio secondo le regole del MDR (Regola 11 per i software)​
3. Sviluppo e Verifica – Progettare il dispositivo secondo uno standard di qualità, effettuare test di verifica/validazione su dataset adeguati e condurre una valutazione clinica.
4. Documentazione Tecnica – Preparare un fascicolo tecnico completo (incluse descrizione dell’algoritmo, analisi dei rischi, risultati di performance clinica, ecc.).
5. Valutazione di Conformità – Sottoporre il dispositivo all’esame di un Organismo Notificato (per classi > I). L’ON valuta la documentazione e il sistema qualità del fabbricante, rilasciando un certificato CE se tutti i requisiti sono soddisfatti.
6. Marcatura CE e Immissione sul mercato – Apporre il marchio CE e distribuire il prodotto.
7. Sorveglianza Post-Market – Monitorare continuamente le prestazioni in campo, raccogliere dati post-commercializzazione e gestire gli aggiornamenti. Il MDR richiede un Piano di Sorveglianza Post Commercializzazione (PMS) e, per classi IIa/IIb/III, relazioni periodiche di sicurezza (PSUR) e, se necessario, studi clinici post-market (PMCF) per confermare il mantenimento della sicurezza e performance nel tempo.

Va sottolineato che gli algoritmi di IA possono necessitare aggiornamenti frequenti (ad esempio per migliorare l’accuratezza o adattarsi a nuovi dati). In ambito MDR, ogni modifica significativa dell’algoritmo o dell’indicazione d’uso del software potrebbe richiedere una nuova valutazione da parte dell’Organismo Notificato (similmente a una ri-certificazione). Ciò può rappresentare una sfida per gli sviluppatori di IA “adattativa” o in continua evoluzione, spingendo spesso a mantenere gli algoritmi in una versione “bloccata” al momento della certificazione. Attualmente, la procedura europea non prevede un meccanismo formalizzato per gestire algoritmi auto-apprendenti post-market; pertanto, modifiche sostanziali richiedono iter regolatori aggiuntivi, mentre piccole ottimizzazioni possono essere gestite tramite il sistema qualità aziendale e notificate all’ON durante le sorveglianze periodiche.

L’AI Act e l’Impatto sui Dispositivi Medici

Accanto al MDR, l’Unione Europea sta definendo l’AI Act, un regolamento orizzontale dedicato ai sistemi di intelligenza artificiale in tutti i settori. L’AI Act adotta un approccio basato sul rischio, classificando i sistemi di IA in quattro categorie: rischio inaccettabile (proibiti), alto rischio, rischio limitato e minimo rischio. I sistemi di IA impiegati come dispositivi medici rientreranno quasi certamente nei “sistemi ad alto rischio”, in virtù del loro impatto potenziale su salute e sicurezza. Infatti, l’AI Act considera alto rischio qualsiasi sistema di IA che sia parte di un prodotto soggetto a certificazione di terza parte secondo legislazioni esistenti elencate nell’Allegato II – elenco che include il MDR e IVDR​

In altre parole, se un software medico con IA è di classe IIa, IIb o III (ossia richiede un Organismo Notificato secondo MDR), allora è automaticamente un IA ad alto rischio secondo l’AI Act​

Per tali sistemi, l’AI Act introdurrà obblighi specifici aggiuntivi rispetto al MDR. Tra i requisiti chiave proposti per le IA ad alto rischio vi sono:

• Sistema di gestione della qualità per l’IA: obbligo di implementare processi di progettazione e sviluppo ad hoc per l’IA, compreso il controllo delle versioni algoritmiche e la tracciabilità dei dati di addestramento​.
• Gestione del rischio AI: analogamente a quanto avviene per i dispositivi medici (ISO 14971), occorrerà effettuare analisi dei rischi specifiche dell’algoritmo, tenendo conto di aspetti come bias nei dati, possibili errori decisionali e misure di mitigazione.
• Qualità dei dataset: garantire che i dati utilizzati per addestrare, validare e testare l’IA siano appropriati, rappresentativi e privi di distorsioni che possano compromettere la sicurezza​. Ciò include documentare l’origine dei dati, la loro pulizia e la divisione in insiemi di training/validazione.
• Documentazione Tecnica sull’IA: predisporre un fascicolo dedicato con informazioni tecniche sull’algoritmo (architettura, logica, performance, limiti) e le prove di conformità ai requisiti dell’AI Act (es. risultati di valutazioni di accuratezza, robustezza, gestione bias).
• Trasparenza e informazione agli utenti: fornire adeguate informazioni all’utilizzatore circa il funzionamento dell’IA, la sua finalità, prestazioni attese e limiti. L’AI Act richiede che i sistemi ad alto rischio siano accompagnati da istruzioni d’uso chiare che includano, ad esempio, la spiegazione dei fattori considerati dall’algoritmo e le appropriate avvertenze per l’uso.
• Supervisione umana: prevedere misure che consentano all’uomo di supervisionare i risultati dell’IA e intervenire, prevenendo o mitigando rischi (ad esempio, interfacce che segnalano il livello di confidenza dell’algoritmo e permettono al clinico di ignorare/approvare le raccomandazioni).
• Cybersecurity e Robustezza: assicurare che l’IA sia robusta agli attacchi informatici e alle alterazioni dei dati, e che degradi in modo sicuro in caso di malfunzionamento.
• Registrazione: iscrivere il sistema di IA ad alto rischio in un registro UE (database pubblico) prima dell’immissione sul mercato, per aumentare la trasparenza e la sorveglianza.

Fortunatamente, per i produttori di dispositivi medici, molti requisiti dell’AI Act si sovrappongono a quelli del MDR o delle norme tecniche già seguite. Ad esempio, il MDR impone già gestione del rischio, un sistema qualità e documentazione tecnica dettagliata; l’AI Act aggiunge enfasi sulla qualità dei dati e sui controlli specifici dell’algoritmo. Per evitare duplicazioni inutili, la bozza di AI Act prevede che la certificazione possa essere svolta in modo congiunto: un Organismo Notificato designato sia secondo MDR sia secondo l’AI Act potrà eseguire una valutazione unica che verifichi contemporaneamente la conformità ai requisiti di entrambe le normative​

In pratica, si prospetta un “doppio marchio CE” per i dispositivi con IA (uno ai sensi del MDR e uno ai sensi dell’AI Act) ma ottenibile tramite un unico iter, evitando che il produttore debba rivolgersi separatamente a due enti notificati​

Dal punto di vista del rischio, l’AI Act suddivide i sistemi di IA in maniera diversa dal MDR: un dispositivo potrebbe essere, ad esempio, Classe I secondo MDR ma IA ad alto rischio secondo l’AI Act, oppure viceversa (anche se nella maggior parte dei casi i software medici saranno di fatto alto rischio su entrambe le scale)​

È importante notare che la classificazione MDR rimane determinante per stabilire le procedure di valutazione della conformità del dispositivo come prodotto, mentre la classificazione AI Act incide sui controlli specifici dell’algoritmo. Dunque, i fabbricanti dovranno soddisfare entrambi gli insiemi di requisiti. Ad esempio, un’app di diagnostica dermatologica potrà essere Classe IIa MDR per via della Regola 11, e contemporaneamente un sistema IA ad alto rischio: dovrà quindi ottenere la marcatura CE come dispositivo medico (con valutazione clinica, gestione rischi, ecc.) e dimostrare la conformità ai requisiti dell’AI Act su qualità dei dati, trasparenza, supervisione umana, ecc.

Esempio (EU): SkinVision, un’app per il riconoscimento di lesioni cutanee sospette, era inizialmente marcata CE in Classe I (basso rischio) secondo la vecchia Direttiva, ma studi indipendenti hanno dimostrato che poteva mancare melanomi pericolosi, sollevando critiche sulla sufficienza dei controlli​

Con l’introduzione del MDR, app del genere verranno riclassificate in Classe IIa o superiore, imponendo una rigorosa valutazione da parte di un Organismo Notificato e la necessità di prove cliniche di efficacia diagnostica​

In più, sotto l’AI Act, tali strumenti saranno considerati IA ad alto rischio, obbligando i produttori a garantire e documentare che l’algoritmo sia stato addestrato su dataset ampi e rappresentativi (ad esempio diverse tonalità di pelle) per ridurre bias e falsi negativi. Questo caso evidenzia come il nuovo quadro normativo EU miri a colmare lacune precedenti, assicurando maggiore tutela per i pazienti che utilizzano dispositivi con IA.

Regolamentazione FDA negli Stati Uniti: AI/ML-Based Medical Devices

Negli Stati Uniti, la FDA inquadra i dispositivi medici con IA/ML all’interno della struttura normativa esistente, adattandola attraverso linee guida e politiche dedicate. Non esiste (al 2025) una legge specifica per l’intelligenza artificiale in sanità paragonabile all’AI Act europeo; la FDA utilizza il Federal Food, Drug, and Cosmetic Act e le relative normative per i dispositivi, integrandole con linee guida e un approccio orientato all’intero ciclo di vita (Total Product Life Cycle) dei software basati su IA. Gli elementi chiave della regolamentazione FDA in questo ambito includono: classificazione del rischio, percorsi di autorizzazione (510(k), De Novo, PMA) e raccomandazioni specifiche per lo sviluppo, l’aggiornamento e il monitoraggio dei dispositivi IA/ML.

Classi di Rischio e Percorsi di Autorizzazione FDA

La FDA classifica tutti i dispositivi medici in tre classi di rischio: Classe I, II, III. Questa classificazione determina il livello di controllo normativo: i dispositivi di Classe I sono a basso rischio (controlli generali sufficienti), quelli di Classe II a rischio moderato/alto (richiedono controlli speciali) e quelli di Classe III ad alto rischio (richiedono evidenze cliniche e approvazione pre-market approfondita). I software con IA rientrano tipicamente in Classe II – ad esempio, strumenti che analizzano immagini mediche (radiografie, TC, risonanze) e segnalano reperti al medico sono considerati di rischio moderato​

Molti dispositivi IA di Classe II vengono autorizzati tramite il processo di Premarket Notification 510(k), dimostrando sostanziale equivalenza con un dispositivo già presente sul mercato (detto “predicato”)​

Uno studio ha rilevato che la maggioranza dei dispositivi IA autorizzati dalla FDA fino al 2020 lo sono stati proprio attraverso la via semplificata del 510(k)​

Quando invece un dispositivo basato su IA è completamente novel – cioè non esiste un predicato appropriato – ma il rischio non è così elevato da richiedere un’approvazione completa di Classe III, il produttore può seguire il percorso De Novo. Il De Novo è un’autorizzazione di classificazione: la FDA esamina il dispositivo come nuovo e, se ne trova garantita la sicurezza ed efficacia per l’uso proposto, lo classificherà come Classe I o II, definendo al contempo eventuali controlli speciali applicabili a prodotti simili futuri. Diversi sistemi basati su IA hanno ottenuto l’immissione sul mercato tramite De Novo: tra i primi casi figurano IDx-DR, OsteoDetect e Viz.ai ContaCT, tutti dispositivi software diagnostici/di supporto alimentati da algoritmi di apprendimento automatico​

Questi esempi sono stati classificati come Classe II con controlli speciali, stabilendo i requisiti per successori che seguono via 510(k).

Infine, se il dispositivo IA svolge funzioni critiche per la salute (ad esempio supporta decisioni da cui dipende direttamente la vita del paziente, o fornisce diagnosi/terapie senza possibilità di intervento clinico in condizioni di pericolo imminente), può essere assegnato alla Classe III. I dispositivi di Classe III richiedono la presentazione di un Premarket Approval (PMA), con studi clinici che dimostrino che i benefici superano i rischi​

Ad oggi, la maggior parte delle soluzioni IA in campo medico non ricade in Classe III, in quanto spesso fungono da strumenti di supporto (anziché prendere decisioni autonome su terapie invasive). Tuttavia, esistono eccezioni: un esempio è un sistema di monitoraggio avanzato del glucosio con algoritmi predittivi (Guardian Connect) che la FDA ha approvato tramite PMA come dispositivo di Classe III​

In generale, la FDA valuta attentamente l’indicazione d’uso: se un algoritmo potrebbe, in caso di errore, portare a gravi conseguenze immediate senza mitigazione clinica, lo classificherà in Classe III.

Va notato che alcune applicazioni software, pur riguardando la salute, non sono affatto considerate dispositivi medici agli occhi della FDA, in virtù di eccezioni normative introdotte dal 21st Century Cures Act (2016). Ad esempio, sono escluse le app per il benessere generale (fitness, lifestyle) non legate a condizioni patologiche, i sistemi puramente amministrativi (gestione di cartelle cliniche, prenotazioni) e i software che fungono solo da archiviazione di dati sanitari senza interpretazione​

Queste categorie di software non richiedono approvazione FDA. Tuttavia, se l’applicazione incorpora algoritmi diagnostici o di supporto clinico rilevanti (come invece fanno le IA mediche di cui trattiamo), rientra nella definizione di dispositivo e segue le classi di rischio summenzionate.

Esempio (USA): Un software AI di imaging come AI-Rad Companion Prostate MR di Siemens, che assiste nell’interpretazione della risonanza magnetica prostatica, è stato classificato Classe II sia in UE che in USA. In Europa, secondo il MDR, è considerato un dispositivo di Classe IIb​

(poiché supporta una diagnosi di patologia potenzialmente severa), mentre la FDA lo ha autorizzato come dispositivo di Classe II​

In entrambi i casi viene ritenuto a rischio moderato: abbastanza da richiedere un controllo accurato (ON in UE, revisione 510(k) in USA) ma non così critico da necessitare studi clinici estesi come un PMA. Questo esempio illustra la sostanziale convergenza nella valutazione del rischio: pur con classificazioni nominali diverse, l’esito pratico – necessità di validazione e autorizzazione regolatoria – è analogo nei due sistemi.

Linee Guida FDA per Dispositivi IA/ML: “Total Product Life Cycle”

Riconoscendo le peculiarità dell’IA (in particolare la possibilità di continuo apprendimento e aggiornamento), la FDA ha sviluppato un approccio di supervisione basato sull’intero ciclo di vita dei dispositivi IA/ML. Nel 2019 l’agenzia ha pubblicato un documento di discussione proponendo un Quadro Regolatorio per le Modifiche dei Software di IA/ML e ha raccolto feedback dall’industria​

Nel 2021, la FDA ha rilasciato un Action Plan sull’AI/ML che delineava le azioni chiave per adattare la regolamentazione, tra cui: elaborare linee guida su come gestire gli aggiornamenti algoritmici, definire Good Machine Learning Practice (GMLP), incoraggiare la trasparenza dei dispositivi IA e sviluppare metodi di monitoraggio post-market specifici​​

Un concetto introdotto è il “Predetermined Change Control Plan (PCCP)” – in italiano, “piano di controllo del cambiamento predeterminato”. Si tratta di un meccanismo mediante il quale un produttore, al momento della domanda di autorizzazione, può proporre alla FDA un piano dettagliato delle potenziali modifiche future dell’algoritmo (ad esempio, riaddestramento periodico con nuovi dati, o miglioramenti di performance) e dei limiti entro cui tali modifiche avverranno. Il PCCP include anche i protocolli di verifica/validazione che saranno usati per garantire la sicurezza delle versioni aggiornate. Se la FDA approva il PCCP insieme al dispositivo, il produttore potrà implementare quelle modifiche pre-pianificate senza dover ogni volta presentare una nuova pratica 510(k)/De Novo, accelerando così l’implementazione di miglioramenti​

Ad aprile 2023, la FDA ha pubblicato una bozza di linea guida specifica su come presentare un PCCP in sede di domanda​, segno che presto tale approccio diverrà realtà regolatoria per gli AI/ML devices. Per le aziende ciò significa investire più lavoro upfront (definire a priori gli scenari di aggiornamento e relative evidenze), ma ottenere maggiore agilità post-mercato.

Un altro pilastro sono le Good Machine Learning Practice (GMLP): principi di buona pratica per lo sviluppo di IA in ambito medicale. FDA, insieme ad altri enti (ad es. IMDRF, e agenzie di Canada, UK), ha identificato linee guida non vincolanti che coprono aspetti quali: scelta e preparazione dei dataset, ingegneria delle feature, addestramento e tuning del modello, validazione indipendente, e gestione del ciclo di vita. L’obiettivo è fornire agli sviluppatori un framework di qualità simile alle buone pratiche di sviluppo software e manufacturing già note, ma adattato alle sfide specifiche dell’apprendimento automatico (es. prevenire overfitting, assicurare generalizzabilità, evitare bias). Sebbene non siano requisiti di legge, aderire ai GMLP facilita il percorso regolatorio poiché dimostra all’FDA una robustezza metodologica nel progetto dell’algoritmo.

La trasparenza verso utenti e pazienti è un ulteriore elemento sottolineato dalla FDA. Nel 2020 l’agenzia ha tenuto workshop pubblici sul tema della trasparenza delle “machine learning-enabled devices”, esplorando come meglio comunicare le informazioni chiave sull’IA ai utilizzatori finali (medici o pazienti). Una linea guida con principi sulla trasparenza è stata pubblicata in collaborazione con altri enti, raccomandando ad esempio di rendere noti: la destinazione d’uso precisa dell’algoritmo, le caratteristiche dei dati su cui è stato addestrato, le metriche di performance ottenute nei test clinici, e le limitazioni note del sistema​

Fornire queste informazioni aumenta la fiducia e permette agli operatori sanitari di utilizzare l’IA con maggiore consapevolezza.

In termini pratici, il percorso di conformità FDA per un dispositivo medicale con IA/ML può essere riassunto come segue:

1. Sviluppo secondo controlli di qualità – L’azienda adotta un sistema di gestione qualità conforme (p.es. ISO 13485 o 21 CFR 820) e applica buone pratiche di progettazione dell’IA (GMLP). Si curano in particolare la selezione dei dati di addestramento, l’annotazione corretta (se supervisato), e si prevengono bias assicurando diversità del dataset
2. Validazione pre-clinica – Si testa l’algoritmo su dati indipendenti da quelli di training, misurando performance come sensibilità, specificità, accuratezza, ecc. Se possibile, si confronta con standard di cura (ad es. con operatori umani o dispositivi esistenti). La FDA richiede evidenze che l’IA funzioni in modo affidabile sulla popolazione target e nelle condizioni d’uso previste, senza degrado significativo rispetto ai benchmark clinici esistenti.
3. Determinazione del percorso regolatorio – In base all’indicazione d’uso e al rischio, si stabilisce se procedere con un 510(k), una richiesta De Novo o un PMA. In molti casi di IA diagnostiche di media criticità, il 510(k) è percorribile se esiste un dispositivo predicato simile; altrimenti, se la tecnologia è nuova ma a rischio moderato, si prepara un dossier De Novo. Per tecnologie di frontiera e alta criticità (es. IA che direttamente somministra terapia o decide dosaggi critici) potrebbe servire un PMA con studi clinici prospettici.
4. Pre-Submission e dialogo con FDA – Spesso è consigliabile interagire con l’FDA tramite una riunione pre-sottomissione per discutere in anticipo la strategia di validazione dell’algoritmo, i requisiti di studio clinico e l’eventuale PCCP. Questo aiuta ad allinearsi con le aspettative dell’ente e riduce il rischio di obiezioni in fase di revisione formale.
5. Preparazione della domanda – Si compila un dossier tecnico (nel formato richiesto, ad es. per 510(k) uno 510(k) Summary e relativi allegati) includendo la descrizione del dispositivo, l’indicazione d’uso, il confronto con predicati (per 510k), i risultati di performance, l’analisi dei rischi e le mitigazioni, le procedure di produzione e controllo qualità, le etichette e istruzioni d’uso proposte, ecc. Per IA, particolare enfasi viene data a: descrizione dell’algoritmo e del suo “training”, metriche di accuratezza suddivise per sottogruppi (per verificare l’assenza di bias razziali, di genere, ecc.), e informazioni sull’interfaccia utente (come vengono presentati i risultati al medico).
6. Revisione FDA e Decisione – L’FDA esamina i materiali. Nel caso di 510(k) verifica la sostanziale equivalenza con dispositivi esistenti e può approvare con o senza limitazioni. Per De Novo, valuta rischio/beneficio e probabilmente emanerà una classificazione nuova con requisiti speciali (ad es. obbligo di avvertenze specifiche, o di studiare certi failure mode). Nel caso di PMA, viene valutato il trial clinico presentato; l’approvazione include tipicamente condizioni di post-market (es: registri di sorveglianza). Se tutto è soddisfacente, la FDA rilascia l’autorizzazione: cleared (nel caso di 510k), granted (De Novo) o approved (PMA).
7. Commercializzazione e Monitoraggio – Una volta sul mercato, il fabbricante deve rispettare le norme di sorveglianza post-vendita. Per dispositivi IA, questo comporta: raccogliere segnalazioni di malfunzionamenti o eventi avversi (Medical Device Reporting), effettuare eventuali studi post-approvazione richiesti, e in generale monitorare le prestazioni reali dell’algoritmo. La FDA incoraggia l’uso di Real-World Evidence e il monitoraggio continuo delle prestazioni degli AI/ML devices, specialmente se l’algoritmo potrebbe cambiare nel tempo.

Un problema peculiare è come gestire gli aggiornamenti dell’IA: senza un PCCP, ogni modifica significativa del software (ad esempio, una nuova versione dell’algoritmo con sensibilità migliorata) deve essere valutata per capire se impatta la sicurezza/efficacia; se sì, in genere richiede una nuova sottomissione (un nuovo 510(k) per modifica di dispositivo già commercializzato, oppure un PMA supplement se era PMA)​

Questo può rallentare l’implementazione di miglioramenti. Con l’approccio PCCP in via di definizione, invece, l’azienda potrebbe avere libertà di iterare l’IA entro limiti pre-approvati senza rifare l’iter autorizzativo ogni volta​

Classificazione del Rischio: Confronto tra UE e USA

Sebbene l’obiettivo finale sia comune – garantire che i dispositivi medici basati su IA siano sicuri ed efficaci in rapporto ai rischi – il framework di classificazione UE e quello USA presentano differenze e somiglianze che è utile evidenziare per i professionisti del settore:

• Struttura delle Classi: L’UE adotta quattro classi (I, IIa, IIb, III) mentre la FDA ne adotta tre (I, II, III). Le classi I di entrambi i sistemi indicano basso rischio e generalmente non richiedono valutazione pre-market approfondita (autocertificazione in UE per Classe I non sterile/non misura; esenzione 510(k) per molti Classe I in USA). L’alto rischio è rappresentato da Classe III in entrambi i sistemi, implicando scrutinio massimo (PMA in USA, certificazione + possibili esami addizionali in UE). La differenza maggiore è la suddivisione di Classe II in IIa/IIb in UE: in pratica, UE fornisce un livello intermedio in più che distingue tra rischio moderato (IIa) e moderato-alto (IIb), mentre la FDA raggruppa tutto in Classe II. Questa granularità fa sì che in UE certi dispositivi IA vengano classificati IIb (richiedendo sorveglianza rafforzata e magari interventi più estesi dell’ON) laddove in USA sarebbero comunque II ma con “controlli speciali”. Ad esempio, un software IA diagnostico che in caso di errore può portare a un serio deterioramento della salute (ma non direttamente alla morte) potrebbe essere Classe IIb in UE, mentre resta Classe II in USA; tuttavia la necessità di dimostrarne la sicurezza risulterà stringente in entrambi i casi.
• Criteri di Classificazione: In UE, la classe si determina in base a regole predeterminate (nel caso dei software, la Regola 11​. In USA, la classe di un dispositivo è storicamente legata al tipo di dispositivo e al suo intended use: la FDA ha normative specifiche (regulations e product code) per categorie di dispositivi. Molti software di imaging con IA, per esempio, rientrano nei product code della radiologia assistita dal computer, che sono generalmente Classe II con requisiti di accuratezza. La FDA valuta nuovi dispositivi IA case-by-case: se analoghi a quelli esistenti, ne ereditano la classe; se completamente nuovi, attraverso il De Novo si assegna la classe appropriata. In generale, il principio guida della FDA è molto simile al MDR: se il dispositivo fornisce informazioni per decisioni cliniche ma non controlla direttamente interventi critici, tende ad essere di rischio moderato (Classe II); se un malfunzionamento potrebbe avere conseguenze catastrofiche immediate, è Classe III​
• Coinvolgimento di Enti terzi: In UE, dalla Classe IIa in su entra in gioco l’Organismo Notificato per certificare il dispositivo. Negli USA, l’FDA stessa (un ente governativo) rivede le domande per Classe II e III; per i dispositivi di Classe II esistono percorsi accelerati se sono “510(k) exempt” (non comuni per IA) o se rientrano in pilot program (ad es. il programma FDA Pre-Cert in passato testato per software, oggi evoluzione ferma). In sostanza, sia un dispositivo Classe IIa UE che un Classe II USA subiranno una revisione esterna qualificata prima di entrare sul mercato.
• Requisiti di Evidenza Clinica: Il MDR richiede valutazione clinica per tutti i dispositivi, proporzionata al rischio. Ciò significa che anche per un software Classe IIa o IIb è necessario raccogliere dati clinici (che possono essere studi retrospettivi, pubblicazioni, oppure trial prospettici) per dimostrare le prestazioni dichiarate. La FDA, dal canto suo, per i 510(k) spesso accetta dimostrazioni di performance su dataset di validazione in laboratorio e confronti con letture di esperti (non sempre richiede uno studio clinico prospettico, a meno che il dispositivo sia di nuova categoria o comporti quesiti clinici aperti). Tuttavia, la distinzione non è netta: la FDA può richiedere studi clinici anche per un software di Classe II se ritiene che i dati esistenti non bastino, e l’UE può accettare evidenze cliniche indirette purché solide. Il punto chiave è che per dispositivi IA critici (es. diagnostica autonoma) in entrambi i sistemi servono sperimentazioni rigorose. Nel caso di IDx-DR, come vedremo, l’FDA ha valutato uno studio clinico su 900 pazienti per accertarne l’accuratezza prima di autorizzarlo​
• Aggiornamenti normativi in corso: L’UE, con l’AI Act, sta di fatto aggiungendo una “doppia classificazione”: il rischio del dispositivo (MDR) e il rischio del sistema IA (AI Act). Negli USA, la FDA sta lavorando su linee guida (non leggi) per coprire situazioni nuove (ad es. IA adattativa). Entrambi quindi stanno evolvendo: l’UE tramite un nuovo regolamento che affiancherà il MDR, gli USA tramite policy interne e guidance. In prospettiva, i produttori dovranno osservare da vicino gli sviluppi: ad esempio, un domani la FDA potrebbe introdurre requisiti obbligatori per documentare la riduzione di bias algoritimico, simili a quelli dell’AI Act, anche se attualmente restano raccomandazioni.

Casi di Studio Reali e Sfide Regolatorie

Per comprendere in concreto come si applicano queste normative e quali sfide emergono, esaminiamo alcuni casi studio di dispositivi medici basati su IA che hanno affrontato l’iter regolatorio in USA e UE.

Caso 1: IDx-DR – Diagnosi Autonoma della Retinopatia Diabetica

​

Il dispositivo IDx-DR (ora denominato LumineticsCore) in uso presso uno studio di cura primaria: un operatore esegue la scansione della retina del paziente con un retinografo Topcon, mentre il software IA analizza l’immagine. IDx-DR è stato il primo sistema diagnostico autonomo basato su IA approvato dalla FDA​

IDx-DR è un software progettato per analizzare immagini del fondo oculare e rilevare segni di retinopatia diabetica (DR) in pazienti diabetici. La sua particolarità è di fornire un referto automatico: dopo che una foto della retina viene caricata, l’IA determina se vi sono lesioni più che lievi da DR e genera direttamente una raccomandazione (“refer to specialist” oppure “rescreen in 12 months”)​

​

Non richiede dunque che un oculista interpreti le immagini; può essere usato in ambulatori di medicina generale per lo screening. Nel 2018 la FDA ha autorizzato IDx-DR, segnando la prima approvazione di un dispositivo diagnostico basato su IA che non necessita di supervisione clinica diretta per il suo responso​

Dal punto di vista regolatorio, la sfida era duplice: dimostrare che l’algoritmo fosse sufficientemente accurato e sicuro da operare in autonomia, e definire chiaramente i limiti d’uso per mitigare i rischi.

Per l’approvazione, IDx-DR è stato esaminato tramite il percorso De Novo (numero di richiesta DEN180001) come dispositivo di Classe II. La FDA ha valutato uno studio clinico prospettico condotto su 900 pazienti diabetici in 10 centri di primary care, confrontando i risultati dell’IA con il gold standard (valutazione fatta da specialisti su fotografie retiniche)**​

I risultati mostrarono che IDx-DR identificava correttamente la presenza di retinopatia più che lieve nell’87.4% dei casi e i pazienti liberi da retinopatia nel 89.5% dei casi​

Questi livelli di sensibilità e specificità, considerati accettabili e comparabili a screening umani, sono stati cruciali per ottenere il via libera. La FDA ha comunque imposto alcune limitazioni nell’uso: ad esempio, IDx-DR non deve essere utilizzato su pazienti con patologie oculari pregresse (laserterapia, chirurgia o iniezioni intravitreali) o condizioni concomitanti che possono confondere l’analisi (edema maculare, retinopatia avanzata, occlusioni venose retiniche, etc.), né su donne in gravidanza, perché la retinopatia diabetica può progredire molto rapidamente in gravidanza​

Tali esclusioni, riportate nelle istruzioni d’uso, riducono il rischio di falsi negativi in situazioni dove l’IA non è stata addestrata o potrebbe non essere affidabile. Inoltre, l’algoritmo è limitato alla sola retinopatia diabetica: non tenta di diagnosticare altre malattie dell’occhio​, e infatti l’etichetta avverte che i pazienti necessitano comunque di esami oculari completi periodici per altre condizioni.

In Europa, IDx-DR ha ottenuto la marcatura CE inizialmente sotto la Direttiva Dispositivi Medici (MDD) e successivamente – con il nome commerciale LumineticsCore – è in fase di certificazione MDR. Secondo le regole MDR, un software che emette diagnosi autonoma su una malattia che, se non rilevata, può portare a grave deterioramento (cecità) rientra almeno in Classe IIb (grave deterioramento) e potrebbe essere argomentato come Classe III se si considerasse il rischio di non trattare tempestivamente una condizione potenzialmente prevenibile. In pratica, molti si aspettano che strumenti come IDx-DR vengano certificati come dispositivi di Classe IIb in UE. La sfida in UE consisterà nel soddisfare le aspettative di robustezza clinica (il trial USA potrà essere usato come evidenza principale anche per la marcatura CE) e nell’ottemperare ai requisiti aggiuntivi dell’AI Act. Per esempio, il produttore (Digital Diagnostics) dovrà documentare approfonditamente il processo di addestramento dell’IA, garantire la trasparenza sull’algoritmo e probabilmente implementare misure di sorveglianza continua: un algoritmo come IDx-DR potrebbe essere influenzato dall’evoluzione delle popolazioni (nuove tecniche di fotografia, diversità etnica dei pazienti, etc.), quindi il fabbricante dovrà monitorare costantemente le prestazioni sul campo e segnalare all’ON eventuali necessità di aggiornamento.

Il caso IDx-DR dimostra come un’IA può essere integrata nel flusso clinico in modo responsabile: grazie alla regolamentazione, è stato immesso sul mercato solo dopo rigorosa verifica, con indicazioni d’uso precise. Oggi consente di ampliare lo screening della retinopatia diabetica a contesti prima scoperti (ambulatori di base), migliorando l’accesso alle cure oculistiche. Per i produttori, IDx-DR è stato un apripista, ma ha implicato investimenti ingenti in sperimentazioni cliniche e interazioni ravvicinate con enti regolatori per soddisfare gli standard di sicurezza.

Caso 2: Viz.ai ContaCT – Triage Ictus con Intelligenza Artificiale

Viz.ai ContaCT (ora parte della suite Viz.ai) è un software basato su IA progettato per assistere nel triage dei pazienti con ictus. In caso di sospetto ictus ischemico grave, il tempo di intervento è critico: il software analizza in tempo reale le immagini di una tomografia computerizzata (CT) cerebrale alla ricerca di segni di occlusione di grandi vasi cerebrali (LVO) e, se li riscontra, invia immediatamente una notifica allo specialista (neurologo/radiologo interventista) sullo smartphone, allertandolo che potrebbe esserci un paziente da trattare urgentemente. Non fornisce una diagnosi definitiva, ma funge da sistema di allerta precoce integrato nel workflow ospedaliero.

Nel febbraio 2018, la FDA ha autorizzato la commercializzazione di Viz.AI ContaCT come software di supporto decisionale clinico per l’individuazione di potenziali ictus​

È stato il primo strumento di questo tipo ad ottenere l’approvazione, di nuovo tramite percorso De Novo (DEN170073) e classificato come Classe II. La giustificazione per non considerarlo Classe III risiedeva nel fatto che il software non sostituisce la valutazione medica ma la anticipa: se anche l’IA mancasse un caso, il paziente verrebbe comunque valutato dal radiologo secondo il protocollo standard, magari con un piccolo ritardo. Tuttavia, se l’IA funziona bene, può far guadagnare minuti preziosi per iniziare la terapia (trombolisi o trombectomia). In termini regolatori, la FDA ha definito il dispositivo come Computer-Aided Triage (CADt) software per immagini TC, ed ha pubblicato anche un comunicato stampa sottolineando il beneficio di “notificare prima lo specialista, riducendo il tempo al trattamento e potenzialmente limitando i danni da ictus”​

Le sfide affrontate da Viz.ai per l’approvazione riguardavano la validazione clinica dell’algoritmo e l’integrazione nel flusso di cura: l’azienda ha dovuto dimostrare che il suo algoritmo di visione artificiale individuava con alta sensibilità gli LVO sulle scansioni TC senza generare troppi falsi allarmi. Probabilmente la FDA ha esaminato studi retrospettivi comparando le notifiche dell’IA con le letture radiologiche convenzionali e il risultato clinico. Inoltre, trattandosi di un sistema che comunica informazioni cliniche (immagini e alert) via rete a diversi operatori, sono stati considerati aspetti di cybersecurity e privacy (essenziali per software in rete ospedaliera). Viz.ai ha anche dovuto definire chiaramente il contesto d’uso: ad esempio, specificare che il software non interpreta altri tipi di patologie sulla TC oltre l’ictus, e che l’alert serve a priorizzare i casi ma la diagnosi definitiva spetta al medico. Queste distinzioni consentono di mantenere il dispositivo in Classe II, poiché il medico rimane “in the loop”.

Dopo l’approvazione iniziale, Viz.ai ha ampliato la sua piattaforma con algoritmi aggiuntivi (per emorragie cerebrali, aneurismi, perfusione, ecc.), molti dei quali autorizzati via 510(k) usando ContaCT come predicato. Ciò illustra un vantaggio del De Novo: una volta stabilita una “famiglia” di dispositivi simili, i successivi miglioramenti o estensioni possono arrivare sul mercato più facilmente. In UE, soluzioni come Viz.ai rientrano nel MDR come software per la diagnosi/monitoraggio di una condizione pericolosa (ictus); con la Regola 11, probabilmente verrebbero classificati in Classe IIb o III. Si potrebbe argomentare Classe IIb se si ritiene che l’IA supporti il processo decisionale ma l’intervento umano è comunque presente (quindi rischio mitigato di grave danno diretto), oppure Classe III qualora si considerasse che un mancato allarme di LVO potrebbe portare a morte/disabilità non prevenuta. In ogni caso, serve un Organismo Notificato e una valutazione rigorosa. Un aspetto interessante è che, mentre negli USA i software di triage come Viz.ai sono stati rapidamente adottati con l’ok FDA, in UE all’inizio del MDR c’è stata scarsità di Organismi Notificati specializzati in software, causando qualche ritardo nelle certificazioni di soluzioni analoghe. Tuttavia, col tempo, anche in Europa prodotti di triage AI per ictus e altre emergenze (ad esempio Aidoc per embolia polmonare su TAC) hanno ottenuto marcatura CE, confermando che i requisiti possono essere soddisfatti.

In termini di sfide normative, Viz.ai mette in luce l’importanza di: (a) dimostrare il valore clinico aggiunto – la FDA ha chiaramente valutato positivamente il fatto che l’IA porti benefici in termini di tempi di intervento​; (b) mantenere l’IA come assistiva e non autonoma, per rimanere in un regime regolatorio più snello; (c) prepararsi a gestire la responsabilità condivisa: i medici dovevano essere istruiti che l’alert è un ausilio, non infallibile, e i protocolli clinici vanno adattati di conseguenza (questi aspetti ricadono più nella gestione del rischio da parte del produttore, che deve fornire opportune avvertenze e training agli utilizzatori). Dal punto di vista post-market, un sistema di triage deve monitorare le proprie prestazioni. Ad esempio, se in un ospedale l’IA segnalasse troppi falsi positivi, i medici potrebbero cominciare a ignorarla – il produttore deve raccogliere feedback e potenzialmente aggiornare l’algoritmo. Con l’approccio MDR + AI Act, questo aggiornamento andrebbe pianificato e certificato; con la FDA, idealmente l’azienda avrebbe predisposto un PCCP per migliorare sensibilità/specificità col tempo senza risubmission.

Caso 3: Altri Esempi e Tendenze

Oltre ai due casi pionieristici sopra, vale la pena menzionare altre tipologie di dispositivi IA e le rispettive sfide normative:

• Imaging diagnostico multiscansione: Molte applicazioni IA supportano la radiologia identificando lesioni in immagini di diverso tipo (TC, RM, radiografie). Ad esempio, OsteoDetect è un algoritmo che individua fratture ossee nel radiogramma del polso. È stato autorizzato via De Novo nel 2018 come Classe II, con l’indicazione d’uso di assistenza al radiologo ortopedico. La sfida qui fu provare che l’algoritmo migliorasse l’accuratezza o la velocità diagnostica senza introdurre rischi (ad es. senza che i medici affidandosi troppo all’IA ignorassero fratture che l’IA mancava). La FDA ha approvato OsteoDetect imponendo che l’output venisse usato solo con conferma clinica, definendolo un CAD (Computer-Aided Detection) tradizionale. In UE, rientra in Classe IIa o IIb a seconda dell’impatto (probabilmente IIa se considerato un puro assistente di immagine).
• Dispositivi indossabili con IA: Un esempio è la funzione di notifica di apnea notturna introdotta su uno smartwatch (Apple) che, tramite algoritmi di IA sui segnali, rileva pattern compatibili con apnee nel sonno. La FDA l’ha autorizzata come novità nel 2024 (510(k)), Classe II, riconoscendo il beneficio di uno screening passivo. La sfida era validare l’algoritmo contro polisonnografie standard e minimizzare falsi allarmi che possano causare ansia o intasare i medici di segnalazioni inutili. In UE, funzioni di questo tipo sarebbero dispositivi medici (rientrano nella definizione di monitoraggio di parametri fisiologici – Regola 11, quindi almeno Classe IIa). I fabbricanti consumer che entrano nel settore medicale con funzioni IA (come Apple, Fitbit, etc.) devono implementare per la prima volta sistemi qualità e soddisfare normative prima estranee alla loro tradizione, segno che la compliance è diventata un fattore competitivo anche per aziende tech.
• App terapeutiche con AI: Ad oggi meno comuni, ma emergenti. Un caso è DigiCare (ipotetico) che aggiusta dinamicamente il dosaggio di insulina di una pompa in base a un modello predittivo ML del glucosio. Questo sarebbe chiaramente Classe III per FDA (controlla direttamente erogazione di farmaco vitale) e Class III per MDR (dispositivo attivo somministrante terapia con possibile rischio vita). La sfida qui è enorme: servono trial clinici robusti perché l’algoritmo prende decisioni terapeutiche. L’FDA e l’UE tratterebbero un tale sistema come un “closed-loop insulin delivery”, richiedendo evidenze che l’IA sia almeno altrettanto sicura ed efficace di un controllo standard (es. algoritmo PID tradizionale o gestione manuale). Inoltre, ogni aggiornamento dell’algoritmo necessiterebbe quasi certamente di una nuova approvazione (a meno di PCCP) proprio perché la posta in gioco è altissima.
• Bias e validità su popolazioni diverse: Un aspetto trasversale emerso in vari casi è il rischio di bias algoritmico. Ad esempio, se un’IA per radiologia toracica è addestrata solo su pazienti adulti, potrebbe non funzionare bene nei bambini. O se un algoritmo dermatologico ha visto poche immagini di pelle scura, rischia di fallire nel diagnosticare lesioni su quei pazienti. I regolatori stanno spingendo i produttori ad affrontare questi temi: la FDA, nelle sue linee guida draft 2022-2023, raccomanda di presentare dati sulla diversità del dataset e, se necessario, condurre studi aggiuntivi su sottogruppi​ In Europa, l’AI Act codificherà l’obbligo di usare dataset rappresentativi e mitigare i bias​. Un esempio reale: un algoritmo di screening oncologico addestrato su immagini di ospedali occidentali potrebbe performare male su immagini di cliniche in Asia per differenze tecniche o demografiche – un produttore potrebbe dover raccogliere dati internazionali o giustificare la generalizzabilità con analisi statistiche approfondite.
• Trasparenza vs segreto industriale: Molte IA (specie deep learning) sono “scatole nere”. I regolatori non chiedono di rivelare tutto il codice, ma vogliono capire il funzionamento e avere garanzie. Nei casi IDx-DR e Viz.ai, le aziende hanno dovuto fornire alla FDA informazioni dettagliate sugli algoritmi, ma nelle pubblicazioni e documenti pubblici, naturalmente, non sono divulgati tutti i dettagli proprietari. Il bilanciamento tra trasparenza e proprietà intellettuale è delicato: l’AI Act potrebbe obbligare a fornire spiegazioni più comprensibili anche agli utenti, mentre la FDA con i suoi Summary of Safety and Effectiveness pubblica solo riassunti. Le aziende devono prepararsi a documentare internamente l’IA in modo che gli auditor (della FDA o degli ON) possano valutarla a porte chiuse, anche se l’algoritmo in sé resta protetto. Un caso problematico fu quello di un produttore che non voleva condividere certi dettagli di feature engineering per timore di perdere il vantaggio competitivo – la FDA ha comunque il potere di richiederli, altrimenti può rifiutare l’approvazione.

Conclusioni

L’impiego dell’intelligenza artificiale nei dispositivi medici offre opportunità straordinarie per migliorare la cura dei pazienti, ma porta con sé la responsabilità di governare tecnologia complessa in modo sicuro. Il quadro normativo europeo e statunitense si sta rapidamente evolvendo per tenere il passo con queste innovazioni. In Europa, il MDR ha già stretto le maglie sulla classificazione e certificazione dei software medici, assicurando che anche le IA a scopo diagnostico/terapeutico siano sottoposte a verifica indipendente e rigorosa​

L’imminente AI Act aggiungerà un ulteriore livello di garanzia, focalizzandosi sulla qualità algoritmica, la gestione dei dati e la trasparenza​

Negli Stati Uniti, la FDA continua ad adattare i suoi meccanismi: pur non avendo una “legge IA” dedicata, sta sfruttando la flessibilità delle proprie procedure (510(k), De Novo, PMA) e introducendo linee guida innovative (PCCP, GMLP, ecc.) per gestire sia le IA statiche che quelle in divenire​​

Per gli addetti ai lavori – ingegneri biomedici, responsabili di conformità, produttori – ciò significa muoversi in un panorama normativo in continua definizione. Alcune best practice emergono chiaramente: coinvolgere precocemente gli enti regolatori (es. attraverso incontri pre-sottomissione o dialoghi informali con ON) per allineare gli approcci di validazione; investire in sistemi qualità robusti che integrino sia gli aspetti medicali sia quelli di data science; mantenere una documentazione completa e aggiornata dell’algoritmo e dei suoi dati di addestramento; preparare piani di sorveglianza post-market orientati all’IA (monitoraggio delle prestazioni con metriche statistiche, raccolta di feedback dagli utenti clinici, pronti a implementare correzioni se emergono problemi).

È importante anche gestire le aspettative interne: la compliance con MDR/FDA richiede tempo e risorse significative. Studi citano che una certificazione MDR per un software può richiedere 12-24 mesi per essere ottenuta​ e la FDA spesso richiede mesi di revisione per i primi dispositivi nel loro genere. Tuttavia, la ricompensa è duplice: non solo l’accesso al mercato globale, ma anche un dispositivo la cui qualità è comprovata, elemento essenziale per conquistare la fiducia di medici e pazienti. I casi studio discussi dimostrano che superare le sfide normative è possibile – e quando avviene, questi dispositivi diventano riferimenti nel settore (benchmark regolatori per chi segue).

In definitiva, la regolamentazione dell’IA in sanità non va vista come un freno, bensì come un enabler responsabile: attraverso standard elevati, si crea un ambiente in cui l’innovazione algoritmica può prosperare senza compromettere la sicurezza. Il mix tra approfondimento teorico normativo e applicazione pratica, come illustrato, è fondamentale per sviluppare dispositivi medici con IA che siano all’avanguardia e conformi. Man mano che l’IA Act entrerà in vigore e la FDA implementerà i suoi nuovi guidances, i produttori dovranno continuare ad aggiornare le proprie strategie di conformità. Chi riuscirà a integrare fin dall’inizio i requisiti normativi nel design dei propri algoritmi – dal risk assessment alla bias mitigation – avrà un vantaggio competitivo nel portare soluzioni IA sul mercato in modo efficiente e sicuro. In un settore così dinamico, rimanere informati e proattivi sul fronte regolatorio diventerà parte integrante del lavoro quotidiano per chiunque sviluppi o immetta in commercio dispositivi medici basati su intelligenza artificiale.