Una guida per il fabbricante di dispositivi che acquista modelli con Ai generativa

Capita sempre più spesso di ricevere richieste di fabbricanti che intendono “arricchire” il proprio dispositivo medico con sistemi di AI generativa. Occorre tener conto che si sta acquistando un prodotto sottoposto all’AI Act e che, in qualità di fabbricante bisogna “garantire” la conformità dell’intero prodotto finale al momento della immissione sul mercato (o la messa in servizio). Senza entrare nel tema dell’eventuale cambio di classe di rischio del device, vediamo quali sono gli elementi essenziali da richiedere al fornitore (per lo più Usa o cinese), le clausole critiche da verificare nella licenza d’uso e i requisiti di trasparenza da pretendere per garantire la conformità del dispositivo medico.

Partiamo dunque da una analisi degli obblighi dei fornitori di modelli di AI per finalità generali (di cui l’AI generativa fa parte) per poi analizzare che cosa il fabbricante di dm può/deve chiedere al fornitore stesso.

Obblighi del fornitore

1. In primo luogo, i fornitori extra Ue quando “immettono sul mercato” o “mettono in servizio” sistemi di Ia o modelli GPAI (General Purpose Articial Intelligence) nell’Ue sono tenuti a rispettare l’AI Act (articolo 2 del regolamento). L’AI Act dedica poi un’intera sezione ai fornitori di modelli di GPAI: più esattamente l’articolo 53 stabilisce quattro obblighi fondamentali da rispettare.
2. La documentazione tecnica per le autorità. Innanzitutto, il fornitore del modello GPAI deve redigere e mantenere aggiornata una documentazione tecnica completa, che includa il processo di addestramento, i test effettuati e i risultati delle valutazioni. Questa documentazione – strutturata secondo l’Allegato XI dell’AI ACT – deve essere trasmessa su richiesta all’AI Office e alle autorità nazionali competenti. Tale obbligo ha ricadute dirette sul fabbricante del DM: infatti senza questa documentazione, il fornitore GPAI è in violazione dell’AI Act, e il dispositivo medico che integra quel modello rischia di non ottenere la certificazione.
3. Le informazioni per chi integra il modello. Più importante ancora per il fabbricante di dispositivi medici è il secondo obbligo: il fornitore GPAI deve elaborare e mettere a disposizione informazioni e documentazione specifiche destinate a chi intende integrare il modello nei propri sistemi AI. Queste informazioni, elencate nell’Allegato XII dell’AI ACT, devono consentire di comprendere le capacità e i limiti del modello e di adempiere ai propri obblighi normativi. Qui ovviamente si gioca la partita della compliance: senza queste informazioni, il fabbricante del dispositivo medico non può dimostrare di aver effettuato una corretta valutazione dei rischi né di aver implementato le misure di controllo necessarie.
4. Copyright e trasparenza sui dati di training. L’AI Act impone anche che il fornitore GPAI attui una politica di conformità al diritto d’autore, individuando e rispettando le riserve di diritti nei contenuti utilizzati per l’addestramento. Non è un mero adempimento formale: se il modello fosse stato addestrato su materiale protetto senza autorizzazione, il fabbricante del dm  potrebbe trovarsi coinvolto in controversie sulla proprietà intellettuale.
5. Sintesi dettagliata dei contenuti utilizzati per l’addestramento. Deve essere effettuata secondo il template fornito dall’AI Office (pubblicato il 24 luglio 2025). Questa sintesi deve essere pubblicamente disponibile e descrivere le principali fonti di dati – dataset pubblici, archivi privati, dati scraped dal web – e le misure adottate per rimuovere contenuti illegali e rispettare i diritti d’autore.

Per completezza va precisato che l’AI Act prevede un’eccezione per i modelli rilasciati con licenza libera e open source, che sono esentati dagli obblighi di documentazione tecnica e informativa se rendono pubblici parametri, pesi e architettura. Tuttavia, questa eccezione non copre gli obblighi relativi al copyright e alla sintesi dei contenuti di training, e viene meno completamente se il modello presenta rischi sistemici (come definiti dall’articolo 51).
Da ultimo va precisato che, per aiutare i fornitori di GPAI a rispettare gli obblighi di cui sopra, il 10 luglio 2025, la Commissione europea ha pubblicato il Code of Practice for General Purpose AI Models, approvato formalmente il 1° agosto 2025. Sebbene l’adesione sia volontaria, il Codice specifica in concreto come adempiere agli obblighi di trasparenza e costituisce il metro di riferimento per dimostrare la conformità.

I fornitori che non aderiscono devono comunque dimostrare “mezzi alternativi adeguati”: nella pratica rifiutare il Codice comporta un onere probatorio più gravoso e maggiori rischi di contestazioni da parte delle autorità.

Cosa chiedere al fornitore

Veniamo al dunque: cosa deve concretamente richiedere il fabbricante di dispositivi medici al fornitore del modello GPAI? Ecco una checklist operativa basata sui requisiti dell’Allegato XII dell’AI Act.

Descrizione generale del modello

Prima di tutto, serve una chiara descrizione dei compiti che il modello è destinato a eseguire e del tipo di sistemi in cui può essere integrato. Per un dispositivo medico, è essenziale verificare se il fornitore ha contemplato l’uso in ambito healthcare e se esistono limitazioni specifiche per applicazioni mediche.

Collegata a questo aspetto c’è la Acceptable Use Policy, ossia la politica di utilizzo accettabile. Molti fornitori internazionali includono clausole che vietano o limitano usi in ambito medico, richiedono supervisione umana obbligatoria, o escludono applicazioni “safety-critical”. Il fabbricante deve verificare attentamente che l’integrazione prevista non violi queste policy – pena la risoluzione del contratto o, peggio, contestazioni legali.

Servono anche informazioni pratiche: data di pubblicazione e versione del modello, modalità di distribuzione (API, download, licensing), interazione con hardware/software esterno, e soprattutto le versioni software delle librerie e framework necessari.

Dal punto di vista tecnico, occorre conoscere architettura e numero di parametri del modello (fondamentale per valutare la complessità computazionale), oltre alle modalità e formati di input/output – con particolare attenzione ai limiti dimensionali come la lunghezza della finestra contestuale per modelli linguistici.

Infine, naturalmente, serve chiarezza sulla tipologia di licenza applicabile: proprietaria, open source, o modelli ibridi.

Specifiche per l’integrazione tecnica

L’Allegato XII dell’AI act richiede poi la fornitura dei “mezzi tecnici necessari per integrare il modello”, il che significa in concreto: istruzioni tecniche d’uso complete su API e protocolli; requisiti infrastrutturali precisi (CPU, GPU, memoria); strumenti di integrazione (SDK, librerie, container).

Per un dispositivo medico, è cruciale verificare la compatibilità di questi requisiti con l’architettura prevista – specialmente se il dispositivo include componenti on-premise o edge computing per garantire bassa latenza o protezione dei dati sensibili dei pazienti.

Informazioni sui dati di addestramento

Passiamo allo spinoso tema dei dati. Il fabbricante di dm deve richiedere: tipo e provenienza dei dati (testi medici, immagini cliniche, dati sintetici?); metodologie di organizzazione (pulizia, filtraggio, annotazione); rappresentatività per la popolazione target; misure adottate per gestire potenziali bias.

La questione dei bias infatti non è accademica: un modello addestrato prevalentemente su popolazioni di origine caucasica potrebbe performare peggio su pazienti di altre etnie. Un sistema addestrato su dati provenienti da grandi ospedali universitari potrebbe non essere adatto a contesti di medicina di base. Queste limitazioni devono essere conosciute, documentate e gestite.

La licenza d’uso: clausole critiche da negoziare

Passiamo ora agli aspetti contrattuali. Una licenza standard, pensata per applicazioni generiche, raramente è adatta per l’integrazione in dispositivi medici.

Ecco le clausole che richiedono particolare attenzione.

• Diritti di integrazione e modifica. La licenza deve esplicitare chiaramente il diritto di integrare il modello GPAI nel dispositivo medico e di distribuirlo come componente del prodotto finale. Molte licenze API-based limitano l’uso a chiamate remote, impedendo l’embedding del modello nel dispositivo – una configurazione spesso incompatibile con requisiti di latenza, privacy o continuità operativa. Se il fabbricante intende effettuare fine-tuning o re-training del modello su dati proprietari, la licenza deve consentire esplicitamente tali modifiche. Inoltre, la Guidance on GPAI Obligations  (emanata dall Commissione UE 2 agosto 2025) introduce un criterio: modifiche che richiedono training compute superiore a un terzo di quello del modello originale costituiscono “modifiche sostanziali”, trasformando chi modifica in fornitore autonomo del nuovo modello.
• Acceptable Use Policy. Le Acceptable Use Policies meritano un’analisi attenta. Spesso contengono: divieti espliciti per applicazioni cliniche senza supervisione umana; restrizioni su categorie di utenti che potrebbero confliggere con l’intended use; esclusione di “safety-critical applications”. E attenzione: molte policy si riservano il diritto di modifiche unilaterali, potenzialmente rendendo non conforme un dispositivo già sul mercato.
• Responsabilità e garanzie: non accontentatevi delle clausole standard. Le licenze commerciali GPAI tipicamente includono clausole di esclusione di garanzie implicite e limitazioni di responsabilità. Per un fabbricante di dispositivi medici, che risponde di eventuali danni a pazienti, queste clausole sono inaccettabili. Se possibile (di solito molto difficile) occorre negoziare: garanzie specifiche sulle performance dichiarate e sulla conformità all’articolo 53 AI Act; livelli di responsabilità adeguati al profilo di rischio; obblighi di indennizzo per danni derivanti da violazioni di proprietà intellettuale, difformità dalla documentazione, o violazioni dell’AI Act che impediscano la certificazione. In ogni caso occorre almeno saperlo.

In conclusione

L’integrazione di modelli di AI generativa in dispositivi medici non è un’operazione plug-and-play. Richiede un approccio sistematico che parte dalla selezione del fornitore e attraversa ogni fase del ciclo di vita del prodotto.

Il fabbricante italiano deve verificare la conformità del fornitore GPAI agli obblighi dell’articolo 53 AI Act; se possibile negoziare clausole specifiche che garantiscano accesso alla documentazione e responsabilità adeguate; validare autonomamente l’idoneità del modello per l’intended use clinico; integrare nel QMS procedure dedicate per la gestione del ciclo di vita; preparare documentazione robusta per gli organismi notificati.

Sottovalutare questi aspetti in fase contrattuale può tradursi in blocchi della certificazione CE, ritardi nell’immissione sul mercato, costose rinegoziazioni, oppure nella necessità di cambiare fornitore con tutto ciò che ne consegue in termini di tempi e costi. Quindi: grandi opportunità, ma occorre prestare attenzione.

Rubrica "I DISPOSITIVI MEDICI TRA NORMATIVA E REGOLATORIO"

Leggi gli altri articoli presenti nella nostra rubrica in collaborazione con AboutPharma

VAI ALLA RUBRICA