Accessibilità dei dati, sicurezza e protezione delle persone devono essere governate nello stesso progetto. Dal 12 settembre 2026 il requisito di progettazione previsto dal Data Act assume rilievo per i prodotti connessi e i servizi correlati immessi sul mercato dopo tale data, ferme le esenzioni applicabili.
I dati generati da macchinari, veicoli ed elettrodomestici connessi sono stati spesso accessibili soprattutto al produttore o al fornitore del servizio. Questa disponibilità tecnica non equivale, tuttavia, a un diritto generale di proprietà sui dati. Il problema affrontato dal legislatore europeo è la possibilità dell’utente di accedere alle informazioni generate dall’uso del prodotto e di utilizzarle, anche attraverso fornitori indipendenti.
Indice degli argomenti
Data Act e prodotti connessi: obblighi dal 12 settembre 2026
Il Regolamento (UE) 2023/2854, il cosiddetto Data Act, ribalta questa impostazione. È in vigore dall’11 gennaio 2024 ed è applicabile in larga parte dal 12 settembre 2025. Ma la scadenza che interessa davvero gli uffici tecnici è un’altra: per i prodotti connessi e i servizi correlati immessi sul mercato dopo il 12 settembre 2026, l’accessibilità dei dati deve essere prevista già in fase di progettazione e fabbricazione (art. 3, par. 1, in combinato con l’art. 50).
Il requisito interessa direttamente le scelte di architettura e non può essere affrontato soltanto attraverso l’aggiornamento dei contratti. Nella prospettiva della consulenza privacy e del DPO, la questione è come rendere effettivo l’accesso mantenendo il controllo sui rischi per le persone, sulle autorizzazioni e sulla circolazione delle informazioni. Questo articolo si concentra sul regime dei prodotti connessi e dei servizi correlati, senza esaurire gli ulteriori ambiti del Data Act, tra cui il passaggio tra servizi di trattamento dei dati e la condivisione con soggetti pubblici in presenza di necessità eccezionali.
Prodotti connessi, servizi correlati e dati coperti dal Data Act
Il primo esercizio consiste nel distinguere prodotti e servizi interessati dai soggetti ai quali spettano diritti e obblighi. La stessa impresa può operare come fabbricante, fornitore di un servizio correlato, utente o titolare dei dati in rapporti diversi.
Un prodotto connesso ottiene, genera o raccoglie dati sul proprio uso o sull’ambiente ed è in grado di comunicarli mediante un servizio di comunicazione elettronica, una connessione fisica o l’accesso sul dispositivo; la sua funzione primaria non è archiviare, elaborare o trasmettere dati per conto di soggetti diversi dall’utente.
Gli esempi comprendono macchinari industriali, veicoli e contatori intelligenti. Il servizio correlato è un servizio digitale, diverso dalla connettività, collegato al prodotto al momento dell’acquisto, della locazione o del noleggio, senza il quale non sarebbe possibile svolgere una o più funzioni; può anche essere collegato successivamente per aggiungere, aggiornare o adattare funzioni. Un’app di regolazione della caldaia può rientrare nella definizione.
Una piattaforma di manutenzione predittiva va valutata in concreto: un servizio di sola analisi, senza incidenza sulle funzioni del prodotto, non è automaticamente un servizio correlato (art. 2, punti 5 e 6; considerando 17).
Chi sono utenti e titolari dei dati
L’utente è chi possiede il prodotto, o vi ha diritti d’uso contrattuali (per esempio in leasing o noleggio), oppure riceve il servizio correlato. Può essere un consumatore, ma anche un’impresa: il regime interessa quindi anche i rapporti B2B. Il titolare dei dati (data holder) è chi ha il diritto o l’obbligo di utilizzare e mettere a disposizione quei dati: di solito il produttore o il fornitore del servizio, ma non necessariamente.
Dati prontamente disponibili, metadati e dati derivati
Il regime riguarda dati personali e non personali. Occorre distinguere i dati del prodotto e del servizio correlato dai dati «prontamente disponibili», che il titolare ottiene o può ottenere legittimamente senza uno sforzo sproporzionato che vada oltre una semplice operazione. Gli obblighi degli articoli 4 e 5 si riferiscono a questi ultimi e ai metadati necessari a interpretarli e utilizzarli.
Il perimetro comprende dati grezzi e pretrattati, mentre le informazioni inferite o derivate mediante elaborazioni ulteriori sono, in linea generale, escluse. La presenza di un algoritmo proprietario non basta, da sola, a sottrarre un dato all’accesso: la classificazione deve riflettere la natura dell’elaborazione e non l’etichetta attribuita dal produttore (art. 2, punti 15-17; considerando 15).
Accesso ai dati by design per prodotti e servizi connessi
L’articolo 3 che stabilisce l’obbligo di “accessibilità dei dati per impostazione predefinita” (data access by design and by default) chiede che i prodotti connessi siano progettati e fabbricati, e i servizi correlati progettati e forniti, in modo che i dati, compresi i metadati necessari a interpretarli, siano accessibili all’utente per impostazione predefinita. L’accesso deve essere facile, sicuro, gratuito, in un formato completo, strutturato, di uso comune e leggibile da dispositivo automatico. Dove pertinente e tecnicamente possibile, l’accesso deve essere diretto.
Tradotto in linguaggio di progetto, significa che il requisito entra nel capitolato insieme a quelli funzionali e di sicurezza. Le domande da porsi in fase di design review sono molto concrete. Quali dati genera il prodotto e quali di questi sono davvero “prontamente disponibili”? L’utente vi accede localmente (porta fisica, interfaccia sul dispositivo) o tramite cloud? Esiste un’API documentata, con un formato standard e metadati sufficienti a rendere il dato comprensibile anche a un soggetto diverso dal produttore? Chi gestisce l’autenticazione dell’utente e come si distingue l’utente legittimo da chi non lo è?
Informazioni precontrattuali e inventario dei dati
Gli obblighi informativi precontrattuali dell’articolo 3, paragrafi 2 e 3, sono già applicabili dal 12 settembre 2025, nei limiti del relativo ambito. Per il prodotto, l’obbligo grava sul venditore, locatore o noleggiante, che può essere il fabbricante; per il servizio correlato, sul potenziale titolare dei dati.
Le informazioni differiscono nei due casi: comprendono caratteristiche dei dati e modalità di accesso e reperimento e, per il servizio, anche identità del titolare dei dati, finalità di utilizzo, condivisione con terzi e strumenti per esercitare i diritti. Schede prodotto, condizioni contrattuali e documentazione tecnica devono quindi essere coerenti con il funzionamento effettivo. Queste informazioni non sostituiscono le informative GDPR destinate agli interessati.
Sul piano operativo, è utile costruire un inventario dei dati per prodotto. Per ogni flusso si annotano origine, contenuto, frequenza, formato, destinazione, conservazione, natura personale o non personale ed eventuale presenza di segreti commerciali. L’inventario integra, senza sostituirlo, il registro dei trattamenti previsto dal GDPR e costituisce una base comune per la trasparenza, la gestione delle richieste e l’analisi dei rischi.
Diritti di utenti e terzi sui dati dei prodotti connessi
Quando i dati non sono direttamente accessibili dal prodotto, l’articolo 4 obbliga il titolare a metterli a disposizione dell’utente su semplice richiesta, anche per via elettronica: senza indebito ritardo, gratuitamente, con la stessa qualità di cui dispone il titolare e, se pertinente e tecnicamente possibile, in modo continuo e in tempo reale. L’articolo 5 aggiunge il diritto dell’utente di chiedere che i dati siano trasmessi a un terzo da lui scelto: un manutentore indipendente, un fornitore di software gestionale, una società di consulenza energetica.
Richieste, compensi ed esenzioni
Per il produttore serve un processo che permetta di ricevere e gestire le richieste, verificando la qualità di utente e l’eventuale mandato del terzo senza acquisire informazioni eccedenti. Il flusso dei diritti GDPR può offrire una base organizzativa, ma i due regimi devono rimanere distinguibili: cambiano beneficiari, oggetto e tempi. Il termine ordinario di un mese previsto dal GDPR non si trasferisce automaticamente alle richieste del Data Act, che devono essere soddisfatte senza indebito ritardo.
L’accesso è gratuito per l’utente. Nei rapporti tra imprese, il titolare dei dati può concordare con il destinatario un compenso ragionevole e non discriminatorio, anche comprensivo di un margine, nel quadro degli articoli 8 e 9. Per PMI e organizzazioni di ricerca senza fini di lucro, alle condizioni dell’articolo 9, paragrafo 4, il compenso non può superare i costi di messa a disposizione indicati al paragrafo 2, lettera a): non è un recupero indiscriminato di tutti gli investimenti nel prodotto. La condizione riguarda anche l’assenza di imprese associate o collegate non qualificabili come PMI.
L’articolo 7 prevede esenzioni riferite ai dati generati da prodotti fabbricati o progettati da microimprese e piccole imprese, o da servizi correlati da esse forniti, alle condizioni stabilite per imprese associate o collegate e subappalto. Per quest’ultimo profilo, la versione inglese richiede che l’impresa non operi in subappalto per fabbricare o progettare il prodotto o fornire il servizio.
Sono previste anche esenzioni temporanee per le medie imprese: nei casi indicati, per quelle divenute tali da meno di un anno e per i prodotti per un anno dopo l’immissione sul mercato. Il beneficio va verificato sul caso concreto; non è un’esenzione generale dal GDPR.
Il divieto di usare i dati per sviluppare un prodotto connesso concorrente non si estende alla concorrenza nei servizi correlati o nei servizi di assistenza e manutenzione. Restano i limiti sulla profilazione, sulla comunicazione ai gatekeeper designati ai sensi del Digital Markets Act e sugli altri usi vietati dagli articoli 4-6.
Il titolare può utilizzare i dati non personali prontamente disponibili soltanto sulla base di un contratto con l’utente e non può sfruttarli per ricavare informazioni che compromettano la posizione commerciale di quest’ultimo. Le finalità di utilizzo devono quindi essere definite in clausole trasparenti, che possono essere inserite nel contratto principale senza richiedere necessariamente un accordo separato.
Data Act e GDPR nell’ecosistema dei prodotti connessi
Il Data Act lascia impregiudicata la normativa sulla protezione dei dati personali, che prevale in caso di conflitto (art. 1, par. 5). Non legittima autonomamente la raccolta o la generazione di dati personali.
Va però distinta questa fase dalla successiva messa a disposizione: quando l’utente coincide con l’interessato, l’adempimento dell’obbligo di accesso può essere ricondotto all’articolo 6, paragrafo 1, lettera c), GDPR, nei limiti necessari all’obbligo. Quando l’utente non è l’interessato, il Data Act non fornisce, da solo, una base giuridica per comunicargli i dati personali o trasmetterli al terzo scelto: serve una base valida ai sensi del GDPR, con le ulteriori condizioni eventualmente applicabili (considerando 7; artt. 4, par. 12, e 5, par. 7).
Ruoli privacy, lavoratori e DPIA
Il «titolare dei dati» del Data Act è una figura distinta dal «titolare del trattamento» GDPR. La disponibilità tecnica delle informazioni non dimostra, da sola, che un soggetto determini finalità e mezzi del trattamento. I ruoli devono essere ricostruiti per ciascuna operazione, considerando anche il fornitore che opera per conto altrui. L’accesso Data Act, inoltre, integra ma non sostituisce i diritti degli interessati, compresi accesso e portabilità ai sensi degli articoli 15 e 20 GDPR.
Il caso di una società di logistica che richiede i dati dei propri camion è indicativo: posizione, orari e informazioni di guida possono riferirsi ai conducenti. La proprietà del veicolo non autorizza qualsiasi accesso ai dati dei lavoratori. Occorre valutare finalità, necessità, basi giuridiche, categorie particolari e, ove pertinente, la disciplina ePrivacy sull’accesso alle informazioni nei terminali. In Italia devono essere verificati anche i presupposti dell’articolo 4 dello Statuto dei lavoratori. Il consenso del dipendente non va assunto come soluzione ordinaria, considerato lo squilibrio del rapporto di lavoro.
La privacy by design e by default dell’articolo 25 GDPR deve essere integrata con l’accessibilità prevista dal Data Act. Sono centrali minimizzazione, selezione dei campi, autorizzazioni granulari e separazione dei flussi. Pseudonimizzazione e cifratura riducono alcuni rischi, ma non trasformano i dati personali in dati anonimi.
La DPIA non è automatica per ogni nuovo canale: deve essere svolta quando il trattamento può presentare un rischio elevato ai sensi dell’articolo 35 GDPR, tenendo conto anche delle liste dell’autorità di controllo. Geolocalizzazione e monitoraggio dei lavoratori richiedono particolare attenzione. Se esiste già una DPIA, va verificata la necessità di aggiornarla alla luce dei nuovi accessi.
Il ruolo del DPO e il quadro sanzionatorio
Il DPO deve essere coinvolto tempestivamente e adeguatamente, ai sensi dell’articolo 38 GDPR; presta consulenza e sorveglia la conformità, anche rispetto alla DPIA, secondo l’articolo 39. La responsabilità delle scelte e dell’attuazione delle misure rimane al titolare del trattamento. La mappatura deve inoltre chiarire se i destinatari operano come titolari autonomi, contitolari o responsabili: la qualifica di terzo nel Data Act non determina, da sola, il ruolo GDPR. Devono essere verificati trasparenza, tempi di conservazione e, se pertinenti, trasferimenti extra SEE.
Il profilo sanzionatorio va descritto con precisione. L’articolo 40, paragrafo 4, consente alle autorità di protezione dei dati, nei limiti delle proprie competenze, di sanzionare l’inosservanza degli obblighi dei capi II, III e V secondo l’articolo 83 GDPR, fino al massimale del suo paragrafo 5. Non si tratta di un automatismo sanzionatorio per ogni violazione del Data Act.
Sicurezza dell’accesso nei prodotti connessi
L’esposizione di API, portali o interfacce locali modifica la superficie di attacco e deve essere valutata insieme ai benefici dell’accesso. La risposta non consiste nel presumere che l’apertura sia incompatibile con la sicurezza, ma nel definire controlli verificabili, responsabilità e modalità di manutenzione delle interfacce.
Limiti per rischi gravi alla sicurezza
L’articolo 4, paragrafo 2, consente limitazioni o divieti contrattuali quando l’accesso, l’uso o l’ulteriore condivisione possano compromettere requisiti di sicurezza del prodotto previsti dal diritto UE o nazionale e comportare gravi effetti negativi per le persone. Non basta un rischio informatico generico. Se il titolare rifiuta la condivisione su questa base, deve notificare la decisione all’autorità competente; l’utente dispone degli strumenti di contestazione previsti dalla norma.
Autenticazione, autorizzazioni e separazione dei comandi
Le misure operative vanno commisurate al rischio. L’autenticazione dell’utente e dei terzi deve essere distinta dall’autorizzazione: OAuth 2.0 può supportare la gestione delle autorizzazioni, ma non garantisce da solo autenticazione forte o multifattore. OAuth 2.0 è un protocollo di autorizzazione, non di autenticazione. Il suo scopo principale è consentire a un’applicazione terza di accedere a risorse per conto di un utente senza che quest’ultimo debba condividere le proprie credenziali.
Sono utili permessi limitati ai prodotti e ai dati richiesti, token con durata e ambito controllati, canali cifrati, segregazione degli ambienti, monitoraggio e revoca degli accessi. I limiti di frequenza devono contrastare gli abusi senza rendere ineffettivo l’accesso dovuto. I registri degli accessi devono avere finalità e tempi di conservazione definiti, soprattutto quando contengono dati personali.
Come raccomandazione architetturale, l’accesso ai dati dovrebbe essere separato dalle funzioni di comando del dispositivo. Un diritto di lettura non deve attribuire implicitamente privilegi di controllo. La separazione va progettata secondo le caratteristiche del prodotto e dei servizi, evitando di presentarla come un divieto normativo assoluto di qualsiasi funzione di scrittura.
Prodotti connessi tra Cyber Resilience Act e NIS2
Il raccordo con le altre discipline richiede attenzione ai rispettivi ambiti e calendari. Il Cyber Resilience Act, regolamento (UE) 2024/2847, prevede l’applicazione dei principali obblighi dall’11 dicembre 2027; dall’11 settembre 2026 si applicano gli obblighi di segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi che incidono sulla sicurezza dei prodotti con elementi digitali. Non tutte le vulnerabilità sono quindi soggette alla medesima segnalazione.
Per i soggetti rientranti nella NIS2, recepita con il d.lgs. 138/2024, la gestione del rischio comprende anche la sicurezza della catena di fornitura, secondo le misure e le scadenze applicabili. Questi regimi devono essere coordinati, senza presumere che ogni prodotto o impresa ricada in tutti e tre.
Segreti commerciali e dati dei prodotti connessi
I dati tecnici possono consentire di ricostruire processi o caratteristiche riservate. Il Data Act affronta questo rischio distinguendo il diritto dell’utente di accedere ai dati dalla comunicazione al terzo scelto: i presidi sono contenuti nell’articolo 4, paragrafi 6-9, e nell’articolo 5, paragrafi 9-12.
L’Articolo 4, paragrafi 6-9 disciplina le tutele, i limiti e gli obblighi di riservatezza quando è l’utente stesso a richiedere l’accesso ai dati generati dal prodotto o dal servizio connesso. L’Articolo 5, paragrafi 9-12 regola le condizioni e le salvaguardie applicabili quando l’utente richiede che tali dati siano trasmessi direttamente a un terzo (es. un fornitore di servizi post-vendita o di manutenzione)
Tutele per utenti, terzi e informazioni riservate
Per l’accesso dell’utente, il titolare dei dati o il diverso detentore del segreto identifica le informazioni protette, anche nei metadati, e concorda misure tecniche e organizzative proporzionate. Per la comunicazione al terzo, la divulgazione dei segreti è limitata a quanto strettamente necessario alla finalità concordata tra utente e terzo; le misure devono essere concordate con il terzo. Se mancano accordi sulle misure, queste non vengono attuate o viene compromessa la riservatezza, è possibile trattenere o sospendere la condivisione secondo le condizioni della norma, motivando per iscritto e notificando la decisione all’autorità competente.
Rifiuto, classificazione e misure tecniche
È prevista anche un’ipotesi di rifiuto, ma in circostanze eccezionali: quando il titolare dimostra che, nonostante le misure, è altamente probabile che subisca un grave danno economico. La decisione va motivata sulla base di elementi oggettivi, come l’applicabilità della tutela del segreto in Paesi terzi, la natura e il livello di riservatezza dei dati, l’unicità del prodotto. Va notificata all’autorità, e l’utente può contestarla. Un generico richiamo al know-how non è sufficiente a giustificare il rifiuto.
La protezione va predisposta prima della richiesta. La classificazione deve essere coerente con i requisiti del segreto commerciale previsti dagli articoli 98 e 99 del Codice della proprietà industriale; non ogni informazione aziendale riservata è automaticamente un segreto commerciale. Accordi di riservatezza e controlli tecnici devono essere proporzionati. Filtraggio e aggregazione possono contribuire alla protezione soltanto se non sostituiscono arbitrariamente i dati dovuti con informazioni meno complete o meno utili. Il confine tra dati pretrattati e dati derivati va documentato, evitando che una diversa etichetta svuoti il diritto di accesso.
L’articolo 11 consente misure tecniche di protezione, anche mediante contratti intelligenti e cifratura, purché non discriminino i destinatari né ostacolino i diritti previsti. I rimedi contro l’uso o la divulgazione illeciti possono comprendere cancellazione dei dati, cessazione di determinate attività e risarcimento. Operano nelle fattispecie previste dai paragrafi 2-5 e con le condizioni richieste per ciascun rimedio; non autorizzano una cessazione indiscriminata della produzione per qualsiasi violazione.
Contratti del Data Act e clausole abusive tra imprese
Il capo IV disciplina le clausole abusive relative ai dati imposte unilateralmente nei rapporti tra imprese. Distingue clausole sempre abusive e clausole presunte abusive e rende la clausola abusiva non vincolante per l’impresa che l’ha subita. L’articolo 50 riferisce il regime ai contratti conclusi dopo il 12 settembre 2025. Dal 12 settembre 2027 si applica anche ai contratti conclusi il o prima del 12 settembre 2025, se a tempo indeterminato oppure con scadenza almeno dieci anni dopo l’11 gennaio 2024.
Modelli contrattuali e revisione degli accordi
È opportuno riesaminare condizioni generali, forniture, assistenza, leasing e noleggio, distinguendo diritti di accesso, finalità di utilizzo, compensi, segreti commerciali e responsabilità. La Commissione ha pubblicato modelli contrattuali non vincolanti per l’accesso e l’uso dei dati e clausole standard per il cloud: costituiscono strumenti di supporto, da adattare al rapporto concreto. Non sostituiscono gli accordi ex articoli 26 o 28 GDPR quando questi sono necessari, né costituiscono le clausole tipo per i trasferimenti internazionali di dati personali.
Come adeguare prodotti connessi e servizi al Data Act
Un percorso di adeguamento può essere organizzato nelle seguenti attività, da calibrare sul prodotto e sul ruolo dell’impresa.
- Definire responsabilità e gruppo di lavoro. Coinvolgere ingegneria, IT, sicurezza, legale, commerciale e funzione privacy. Coinvolgere tempestivamente il DPO, ove designato, nel rispetto della sua indipendenza e del ruolo consultivo e di sorveglianza.
- Mappare prodotti, servizi e ruoli. Verificare perimetro, date di immissione sul mercato ed esenzioni, senza dedurre l’esclusione soltanto dalle dimensioni dell’impresa.
- Inventariare i dati. Distinguere dati del prodotto e del servizio, dati prontamente disponibili, metadati, dati pretrattati e derivati; individuare dati personali e segreti commerciali.
- Progettare e verificare l’accesso. Definire interfacce, formati, autenticazione, autorizzazioni, registri e revoca. Valutare i rischi informatici e per le persone; svolgere o aggiornare la DPIA quando necessario.
- Proteggere i segreti commerciali. Documentare i requisiti di protezione, predisporre accordi e misure proporzionate e definire il processo per eventuali sospensioni o rifiuti motivati.
- Aggiornare documenti e contratti. Allineare informazioni precontrattuali, schede prodotto, clausole d’uso dei dati e accordi con terzi; verificare informative, ruoli e altri adempimenti GDPR.
- Gestire le richieste e monitorare il sistema. Predisporre un canale semplice, responsabilità, criteri di compenso e procedure di escalation; formare commerciale e assistenza e riesaminare gli accessi quando cambiano utenti, servizi o rapporti contrattuali.
Data Act e prodotti connessi: governance oltre la conformità
I prodotti immessi sul mercato prima della soglia dell’articolo 50 non sono automaticamente estranei alla disciplina: pur non essendo soggetti al nuovo obbligo di progettazione dell’articolo 3, paragrafo 1, possono essere interessati dagli obblighi di accesso e condivisione dei dati prontamente disponibili. Restano da verificare perimetro ed esenzioni.
Sarebbe un errore leggere il Data Act solo come un costo o come una minaccia al proprio patrimonio informativo. Le imprese utenti potranno finalmente usare i dati dei propri impianti per ottimizzare consumi, manutenzione e qualità, scegliendo liberamente i propri fornitori di servizi. I produttori più attenti potranno trasformare l’accesso ai dati in un elemento di valore dell’offerta, costruendo ecosistemi di partner e nuovi servizi a pagamento sopra il dato reso disponibile.
Per la consulenza privacy e per il DPO, il contributo consiste nel rendere leggibili i flussi e verificabili le condizioni di liceità, senza sostituirsi alle decisioni del titolare. Accesso, sicurezza, riservatezza e protezione delle persone devono essere valutati nello stesso progetto. Una governance efficace consente all’impresa di rendere disponibili i dati dovuti, documentare le limitazioni legittime e mantenere nel tempo il controllo sugli accessi.
Partecipa alla community