by

L’obbligo di Data Act access by design diventa applicabile il 12 settembre 2026 ai prodotti connessi e ai servizi correlati immessi sul mercato dopo tale data.

Impone ai fabbricanti di costruire i prodotti in modo che l’utente raggiunga i dati per impostazione predefinita, e non su richiesta. Da qui discendono questioni di architettura di prodotto, di coordinamento con il GDPR quando i dati riguardano soggetti diversi dall’utente e di individuazione del limite entro cui i trade secrets possono legittimamente restringere l’accesso.

Il cambiamento si coglie meglio nel confronto con il regime applicabile finora, perché la domanda che decide la conformità di un prodotto connesso non è più se il fabbricante sia in grado di estrarre i dati quando qualcuno glieli chiede, ma se l’utente possa raggiungerli senza doverli chiedere. Il Regolamento (UE) 2023/2854 è applicabile dal 12 settembre 2025 e agli obblighi divenuti efficaci a quella data abbiamo dedicato questo articolo. Quello che cambia adesso non è l’esistenza dell’obbligo, ma l’insieme dei prodotti che devono essere costruiti attorno ad esso.

Il calendario del Data Act in sintesi

Data Che cosa diventa applicabile
12 settembre 2025 Diritti di accesso, utilizzo e condivisione dei dati; obblighi di trasparenza precontrattuale; regole sullo switching dei servizi di trattamento dati
12 settembre 2026 Obbligo di access by design (art. 3, par. 1) per i prodotti connessi e i servizi correlati immessi sul mercato dopo tale data
12 settembre 2027 Estensione della disciplina sulle clausole contrattuali abusive ai contratti conclusi prima del 12 settembre 2025

Che cosa richiede realmente il Data Act access by design

L’articolo 3, paragrafo 1 richiede che i prodotti connessi e i servizi correlati siano progettati e fabbricati in modo che i dati del prodotto e i dati del servizio correlato, unitamente ai metadati necessari per interpretarli e utilizzarli, siano per impostazione predefinita accessibili all’utente in modo facile, sicuro e gratuito, in un formato completo, strutturato, di uso comune e leggibile da dispositivo automatico e, ove pertinente e tecnicamente fattibile, direttamente accessibili.

Ogni singolo elemento della previsione porta con sé una conseguenza progettuale.

  • L’accessibilità deve essere lo stato di default, non una funzione attivata su richiesta come accadeva fino a ieri.
  • Il formato deve essere machine-readable, quindi non un report che una persona possa leggere a video.
  • I metadati che rendono i dati intelligibili viaggiano insieme ai dati, perché un flusso di valori che nessuno è in grado di interpretare non soddisfa nulla.

Il perimetro è ampio e raggiunge comparti che non si percepiscono affatto come data business: veicoli, macchinari industriali e agricoli, dispositivi IoT, apparecchiature di monitoraggio, sistemi di smart home. Un ambito che la Commissione europea aveva già delineato nei propri chiarimenti sui prodotti connessi, di cui abbiamo scritto in questo articolo, e che abbiamo poi precisato nelle FAQ pubblicate successivamente. Rientrano nell’obbligo i dati grezzi e pre-elaborati prontamente disponibili sul prodotto e non, in linea di principio, le informazioni ulteriormente trattate o dedotte attraverso operazioni che producono dati significativamente arricchiti, tema su cui la Commissione è tornata con un aggiornamento delle FAQ e su cui si concentra buona parte del valore commerciale dei fabbricanti.

Perché è un problema ingegneristico prima che giuridico

Per i prodotti già sul mercato prima del settembre 2025 era sufficiente essere in grado di estrarre i dati a seguito di una richiesta. Per i nuovi non lo è più, perché l’accessibilità deve essere incorporata nell’architettura del prodotto o del servizio, attraverso interfacce, applicazioni, portali, funzioni di export o API.

Il Data Act access by design è dunque un requisito di ordine diverso. Una funzione compliance può scrivere in poche settimane una procedura di gestione delle richieste di accesso, mentre costruire un meccanismo di accesso dentro un prodotto significa intervenire sulla fase di progettazione, sul firmware, sull’architettura di connettività e, molto spesso, sui contratti di fornitura che regolano i componenti che generano i dati. La differenza è sostanziale. Le aziende che hanno trattato il Data Act come un progetto legale, e non come un progetto di prodotto, se ne accorgeranno nel momento in cui il primo utente chiederà qualcosa che il prodotto non è mai stato costruito per dare.

Dove il Data Act incontra il GDPR, e dove si ferma

È la parte che genera il maggior numero di domande che ricevo, ed è anche quella in cui un’analisi sbagliata produce esposizione su entrambi i fronti.

I dati generati dai prodotti connessi includono frequentemente dati personali. Quando l’utente e l’interessato coincidono, Data Act e GDPR operano in modo complementare e l’analisi resta relativamente lineare. La difficoltà nasce quando i dati riguardano persone diverse dall’utente, ipotesi ricorrente nella pratica: il dipendente alla guida di un veicolo aziendale, oppure più familiari che utilizzano lo stesso dispositivo domestico.

In queste situazioni il Data Act non costituisce di per sé una base giuridica per la comunicazione dei dati personali all’utente. Occorre individuare una base giuridica ai sensi dell’articolo 6 del GDPR e, in presenza di categorie particolari di dati, deve trovare applicazione una delle deroghe dell’articolo 9, prima che la comunicazione avvenga e non dopo. Una tensione fra dispositivi connessi e protezione dei dati personali di cui abbiamo scritto tempo fa in questo articolo, e che il Data Act ha reso considerevolmente più concreta.

Ne discende che Data Act access by design e privacy by design and by default vanno progettati insieme, perché rendere i dati tecnicamente accessibili non equivale a renderli indiscriminatamente disponibili. I sistemi devono essere in grado di identificare e autenticare l’utente, di delimitare i dati che quell’utente può legittimamente raggiungere e di proteggere i dati riferibili a terzi, il che, in un veicolo o in un dispositivo condiviso, significa separare flussi che nessuno aveva progettato per essere separati.

I trade secrets sono una difesa, ma non una difesa generale

Un bilanciamento analogo riguarda la cybersecurity e i segreti commerciali. Qui osservo l’errore opposto, ossia il presupposto che la sensibilità commerciale costituisca una via d’uscita.

Il Data Act non consente al fabbricante di invocare genericamente il proprio know-how per sottrarsi alla condivisione, e una difesa costruita su questo presupposto tende a cedere alla prima verifica seria. Quello che il Regolamento prevede è un insieme di garanzie specifiche e, in circostanze definite, la possibilità di limitare o rifiutare l’accesso: è il bilanciamento che avevamo analizzato all’epoca dell’approvazione del Data Act in questo articolo sui trade secrets. La distinzione pesa moltissimo nella pratica, perché il primo approccio produce un contenzioso che il fabbricante ha buone probabilità di perdere, mentre il secondo produce una posizione documentata e difendibile.

Dove il Data Act access by design produrrà contenzioso

I settori che ne risentiranno per primi sono quelli in cui qualcun altro già vuole quei dati e ha un incentivo commerciale concreto a battersi per ottenerli.

1. Automotive. È il caso più evidente, perché i veicoli generano più dati di qualsiasi altro prodotto connesso di largo consumo ed esiste una catena consolidata di soggetti che ne vogliono l’accesso, dalle compagnie assicurative alle officine indipendenti agli operatori di flotta. L’accesso ai dati del veicolo è stato finora controllato dai costruttori in un modo che ne proteggeva l’aftermarket, ed è esattamente quel controllo che il Data Act mette in discussione. Una dinamica che ho discusso con l’Head of Data Protection and Governance di Mobilisights, la data company del gruppo Stellantis, in questa puntata del mio podcast.

2. Macchinari industriali e agricoli. Seguono a ruota, ed è il campo in cui la tensione fra accesso e trade secrets risulta più acuta, perché i dati di funzionamento e manutenzione hanno valore commerciale per il fabbricante e valore altrettanto elevato per l’operatore. È anche, e vale la pena tenerne conto nella pianificazione dei prossimi dodici mesi, la stessa popolazione di imprese raggiunta dal Cyber Resilience Act, come abbiamo esposto nell’analisi delle linee guida della Commissione. Due serie di obblighi di progettazione che atterrano sullo stesso ufficio tecnico nello stesso periodo.

3. Prodotti connessi con componenti di intelligenza artificiale. Si aggiunge un ulteriore livello, perché gli obblighi dell’AI Act e, in Italia, la rilevanza penale delle misure di sicurezza omesse e della supervisione umana si affiancano ai doveri di accesso qui considerati.

4. Sanità e dispositivi medici. Pongono la questione GDPR nella sua forma più acuta, dato che quasi ogni dato è una categoria particolare e l’analisi ex articolo 9 diventa la regola anziché l’eccezione.

5. Elettronica di consumo e smart home. È la categoria di imprese che verrà colpita senza saperlo, perché un numero elevato di fabbricanti non si percepisce affatto come produttore di prodotti connessi.

Che cosa fare adesso

L’esercizio che non può essere rinviato è quello di classificazione: stabilire quali prodotti e servizi correlati rientrino nel perimetro, quali fra questi saranno immessi sul mercato dopo il 12 settembre 2026 e quali dati generati si qualifichino come dati grezzi o pre-elaborati prontamente disponibili.

Accanto a questo, l’architettura di accesso va definita e non presunta. Significa decidere attraverso quale interfaccia l’utente raggiungerà i dati, in quale formato, con quale meccanismo di autenticazione e con quale filtro sui dati di terzi, e poi verificare che la risposta sia tecnicamente realizzabile all’interno della roadmap di prodotto, anziché descritta in modo aspirazionale dentro una policy.

Il terzo tassello riguarda i contratti. I dati coperti dall’obbligo sono spesso generati da componenti forniti da terzi, e un fabbricante il cui obbligo di accesso dipende da un fornitore che non si è impegnato a supportarlo è un fabbricante con un’esposizione che non ha prezzato.

Le aziende che vogliono capire dove si collocano rispetto al Data Act access by design partono di norma da una mappatura congiunta di prodotti, dati e meccanismi di accesso: un esercizio circoscritto, con un perimetro definito, e considerevolmente meno costoso della scoperta del gap nel momento in cui a indicarlo sono un utente, un concorrente o un’autorità.

Di seguito alcune FAQ utili a inquadrare meglio gli obblighi previsti dal Data Act.

Che cos’è il Data Act access by design?

È l’obbligo, previsto dall’articolo 3, paragrafo 1 del Data Act, di progettare e fabbricare prodotti connessi e servizi correlati in modo che i dati del prodotto e del servizio, insieme ai metadati necessari a interpretarli, siano per impostazione predefinita accessibili all’utente in modo facile, sicuro e gratuito, in un formato strutturato, di uso comune e leggibile da dispositivo automatico, e direttamente accessibili ove pertinente e tecnicamente fattibile.

Da quando si applica?

Il Data Act è applicabile dal 12 settembre 2025, mentre l’obbligo di access by design si applica ai prodotti connessi e ai servizi correlati immessi sul mercato dopo il 12 settembre 2026.

Quali prodotti sono interessati?

L’obbligo raggiunge un’ampia gamma di prodotti connessi, fra cui veicoli, macchinari industriali e agricoli, dispositivi IoT, apparecchiature di monitoraggio e sistemi di smart home, insieme ai servizi ad essi correlati.

Quali dati rientrano nell’obbligo?

I dati grezzi e pre-elaborati prontamente disponibili generati dal prodotto o dal servizio correlato, unitamente ai metadati necessari per interpretarli e utilizzarli. Le informazioni ulteriormente trattate o dedotte attraverso operazioni che producono dati significativamente arricchiti restano di norma fuori dal perimetro.

Il Data Act consente al fabbricante di comunicare dati personali di soggetti diversi dall’utente?

No. Quando i dati riguardano persone diverse dall’utente, il Data Act non costituisce di per sé una base giuridica per la comunicazione: occorre individuare una base giuridica ai sensi dell’articolo 6 del GDPR e, in presenza di categorie particolari di dati, applicare una delle deroghe dell’articolo 9.

Il fabbricante può rifiutare l’accesso invocando i trade secrets?

Non attraverso un richiamo generico al know-how. Il Regolamento prevede garanzie specifiche e, in circostanze definite, la possibilità di limitare o rifiutare l’accesso, ma richiede una posizione documentata e puntuale anziché un’obiezione generica.

Qual è la prima cosa che un fabbricante dovrebbe fare?

Classificare prodotti e servizi che rientrano nel perimetro, individuare quali dati generati ricadano nell’obbligo, definire l’architettura di accesso insieme all’autenticazione e al filtro sui dati di terzi, e verificare che i contratti di fornitura sostengano gli obblighi che dipendono da componenti realizzati da altri.

(Visited 7 times, 7 visits today)
Close Search Window