Dispositivi medici connessi: obbligati ad aprirsi, obbligati a difendersi

Il 12 settembre 2025 è diventato pienamente applicabile il Regolamento (UE) 2023/2854, il Data Act che si inserisce nel più ampio contesto della European Strategy for Data. Undici mesi prima, il 16 ottobre 2024, era entrato in vigore il D.Lgs. 138/2024, che recepisce la NIS2. Un'azienda che produce o distribuisce dispositivi medici connessi si trova oggi a rispettare contemporaneamente due normative che, sullo stesso oggetto tecnico – il flusso di dati del dispositivo – chiedono cose diverse: una vuole che il dato esca facilmente attraverso una più equa distribuzione dei dati generati dai prodotti connessi, a beneficio di concorrenza, innovazione e crescita sostenibile; l'altra vuole che il sistema resti il più possibile chiuso. Non è un conflitto di leggi in senso tecnico, ma resta un problema concreto che nessuna guida ha ancora affrontato specificamente per il settore medicale.

Due logiche diverse, non due leggi in contraddizione

Il Data Act  è una legge potenzialmente applicabile a qualsiasi dispositivo medico che raccoglie dati sul proprio utilizzo e li trasmette. Tali dispositivi però non rientrano automaticamente nell’ambito di applicazione del Regolamento: occorre che rientrino nell’ambito di applicazione previsto dall’art. 1, lett. a), cioè quando mettono a disposizione dell’utente i dati del prodotto connesso o del servizio correlato.

Prodotto connesso e servizio correlato sono le due nozioni chiave del Data Act: il primo è un bene fisico che genera o raccoglie dati sul proprio utilizzo o ambiente, senza avere come funzione primaria l'archiviazione o il trattamento di dati per conto di terzi (dispositivi medici, veicoli, elettrodomestici rientrano tipicamente, i software standalone no); il secondo è il servizio digitale collegato al prodotto — al momento dell'acquisto o aggiunto dopo — che ne amplia o consente le funzioni, senza essere esso stesso un servizio di comunicazione elettronica (esempio tipico: l'app che regola una lampadina o un frigorifero).

La qualificazione conta perché da essa discendono obblighi concreti: sul fronte privacy, gli artt. 4-5 danno all'utente il diritto di accedere ai propri dati e condividerli con terzi, gratuitamente; dal 12 settembre 2026 questo dovrà essere garantito già in fase di progettazione.

Va detto però che il Data Act non ignora la sicurezza.

L'art. 11 autorizza il titolare dei dati ad adottare misure tecniche di protezione (cifratura, controllo degli accessi, smart contract) e l'art. 4, par. 2, consente di limitare l'accesso quando pregiudicherebbe gravemente la sicurezza del prodotto, a condizione che il requisito violato sia previsto da una norma UE o nazionale.

Il bilanciamento è già previsto dal testo.

Il problema riguarda chi deve costruirlo materialmente, senza ripartire da zero: la cybersicurezza dei dispositivi medici ha già una base nella MDCG 2019-16, ma quella guida è precedente al Data Act e non tratta l'obbligo di apertura verso terzi che il Regolamento introduce ex novo.

A questo si aggiunge la NIS2, che impone ai fabbricanti – soggetti "importanti" o "essenziali" a seconda della criticità – misure di gestione del rischio organizzativo (art. 24, D.Lgs. 138/2024), specificate dal 15 gennaio 2026 dalla Determinazione ACN n. 379907/2025. È un obbligo diverso, sul piano organizzativo, da quello di prodotto già imposto dal Regolamento (UE) 2017/745 (MDR) al Requisito 17.2 e 17.4 dell'Allegato I.

Ne risultano tre normative, su tre piani distinti, con nessun punto di raccordo esplicito tra loro.

A complicare il quadro, questi obblighi non sempre gravano sullo stesso soggetto: il fabbricante responsabile ai sensi dell'MDR può essere un'entità diversa dal fornitore di cloud e/o dal titolare dei dati ex Data Act, che la norma individua in base a chi controlla concretamente l'accesso ai dati, non in base a chi produce l'hardware, e che può quindi coincidere con il fornitore del servizio correlato (ad esempio una piattaforma di monitoraggio remoto gestita da un soggetto terzo).

Sul fronte NIS2, di regola entrambi possono essere soggetti autonomi (il fabbricante per il sottosettore dispositivi medici, il cloud provider per le infrastrutture digital) collegati dall'obbligo di sicurezza della catena di fornitura (art. 24, comma 2, lett. d, D.Lgs. 138/2024); solo se il fabbricante resta sotto le soglie dimensionali, l'obbligo NIS2 grava sul solo cloud provider. Lo strumento di coordinamento per il rapporto titolare/responsabile del trattamento dei dati sanitari esiste già, ed è la nomina ex art. 28 GDPR; quello che manca è un raccordo esplicito tra questa mappa dei ruoli e i nuovi ruoli introdotti da Data Act e NIS2. Si ritiene che le nomine già in essere andranno verificate, caso per caso, per accertare se coprano adeguatamente anche questi nuovi obblighi.

Un vuoto di coordinamento, non un'antinomia

Per i dispositivi indossabili o personali – diversamente dalle apparecchiature ospedaliere, dove l'"utente" ex Data Act è la struttura sanitaria – i dati generati sono quasi sempre dati sanitari ex art. 9 GDPR: in caso di sovrapposizione prevalgono le regole del GDPR, e la condivisione con terzi designati dal paziente non è mai automatica.

Il caso non è un'anomalia isolata, ma un esempio dell'accumulo di discipline europee sui dati che si sovrappongono senza un manuale di coordinamento unico. Il principio cardine resta l'accountability: occorre dimostrare di aver individuato consapevolmente il punto di equilibrio tra apertura, sicurezza organizzativa, sicurezza di prodotto e liceità del trattamento – e di aver verificato di conseguenza anche i contratti già in uso.

Per fabbricanti e vendor IT del settore, questo significa che coloro che si occupano di compliance sui dati e sicurezza informatica devono sedersi allo stesso tavolo fin dalla progettazione del prodotto.