Chi produce o integra prodotti connessi IoT si trova davanti a un cambio profondo. Il Capo II del Regolamento UE 2023/2854 attribuisce agli utenti diritti di accesso, utilizzo e condivisione sui dati generati dai dispositivi, mentre il Capo III impone obblighi contrattuali e di trasparenza. Per produttori, fornitori di servizi digitali e startup hardware il punto di partenza è ridisegnare contratti, clausole e modelli di business intorno ai nuovi diritti dell’utente.

C’è una data che rende la questione immediata. Dal 12 settembre 2026 l’obbligo di accesso ai dati per impostazione predefinita si applica ai prodotti connessi e ai servizi correlati immessi sul mercato dopo quel giorno: non è più solo una questione di clausole, è una scelta di progettazione che va fatta prima del lancio.

1. Quando un dispositivo è un “prodotto connesso” ai sensi del Data Act

L’art. 2, n. 5 del Regolamento definisce prodotto connesso come un bene che ottiene, genera o raccoglie dati relativi al proprio utilizzo o all’ambiente circostante, che è in grado di comunicare tali dati tramite un servizio di comunicazione elettronica, una connessione fisica o l’accesso sul dispositivo, e la cui funzione primaria non è l’archiviazione, il trattamento o la trasmissione di dati per conto di una parte diversa dall’utente.

La definizione si regge su tre elementi tecnici da verificare.

Il primo è la generazione di dati. Sono prodotti connessi i dispositivi che producono dati attraverso sensori, sia in fase attiva sia in stand-by: smart speaker, smartwatch, termostati intelligenti, sensori industriali, collari per animali da allevamento, sensori per il monitoraggio del suolo. Il considerando 15 chiarisce che anche i dati relativi allo stato del dispositivo quando spento sono rilevanti.

Il secondo è la capacità di comunicare i dati all’esterno. La modalità è tecnologicamente neutrale: rete cellulare, Wi-Fi, Bluetooth, LoRa-WAN, cavi USB o HDMI, accesso diretto tramite chiavette o schede.

Il terzo è la funzione primaria: il dispositivo deve avere uno scopo diverso dalla mera archiviazione, trattamento o trasmissione di dati per conto di terzi. Server, router e infrastrutture di hosting puro sono generalmente esclusi, salvo che siano di proprietà dell’utente che li usa per sé. Questo è l’elemento più complesso da maneggiare, perché molti modelli di business IoT incrociano vendita del dispositivo e abbonamento al servizio.

2. La nozione di “servizio correlato” e i modelli di business

L’art. 2, n. 6 definisce il servizio correlato come un servizio digitale diverso da un servizio di comunicazione elettronica, anche software, connesso con il prodotto al momento dell’acquisto, della locazione o del noleggio in modo che la sua assenza impedirebbe al prodotto di svolgere una o più funzioni, oppure connesso successivamente al prodotto dal fabbricante o da un terzo per ampliarne, aggiornarne o adattarne le funzioni.

Il criterio che si usa in pratica per distinguere è la bidirezionalità: il servizio riceve dati dal prodotto e ne influenza il funzionamento. Va detto che questa parola nel Regolamento non c’è: è una lettura della definizione, non una sua formula, e discende dal fatto che la norma guarda ai servizi la cui assenza impedirebbe al prodotto di svolgere una funzione. L’esempio della Commissione è chiaro: un’applicazione che misura l’impatto ambientale del ciclo di una lavatrice basandosi sui sensori interni e che regola di conseguenza il ciclo è un servizio correlato. Un servizio che si limita a raccogliere dati senza incidere sul funzionamento del prodotto non rientra invece nella definizione.

Questa distinzione ha implicazioni pesanti sui modelli di business. Un produttore di sensori per il monitoraggio del suolo che vende l’hardware a prezzo simbolico e monetizza attraverso un abbonamento mensile per l’accesso ai dati ricade nel perimetro del Capo II, dove gli utenti hanno diritto sostanzialmente gratuito all’accesso e alla condivisione. Continuare a far pagare l’accesso ai dati grezzi e pretrattati può integrare una pratica elusiva.

Resta legittimamente monetizzabile la fornitura di informazioni di secondo livello (analisi predittive, alert, dashboard avanzate, modelli AI) e la licenza d’uso del software che eroga tali servizi a valore aggiunto. I dati grezzi e pretrattati devono essere accessibili.

3. Dati grezzi, pretrattati e informazioni di secondo livello: la distinzione operativa

Il Capo II del Regolamento si applica solo a determinate categorie di dati. Comprenderle è essenziale per progettare correttamente l’accesso e i contratti.

I dati grezzi sono quelli generati automaticamente dal prodotto connesso o dal servizio correlato, senza ulteriori trattamenti. Sono comprensibili per la macchina ma non sempre per l’uomo.

I dati pretrattati hanno subito una forma minima di elaborazione per renderli comprensibili e utilizzabili. Il considerando 15 chiarisce che il titolare non è tenuto a investire in pulizia o trasformazione.

Le informazioni di secondo livello sono escluse dal perimetro del Capo II. Sono “informazioni dedotte o ricavate da tali dati, che sono il risultato di ulteriori investimenti nell’attribuzione di valori o informazioni derivanti dai dati”. Analisi predittive, alert intelligenti, dashboard di business intelligence e modelli AI restano nella disponibilità esclusiva del titolare e possono essere oggetto di servizi a pagamento.

Si aggiunge un ulteriore filtro: i dati devono essere «prontamente disponibili» ai sensi dell’art. 2, n. 17, cioè ottenibili legittimamente dal titolare «senza che ciò implichi uno sforzo sproporzionato che vada al di là di una semplice operazione». La soglia va valutata caso per caso, considerando aspetti tecnici, economici e organizzativi.

Il considerando 20 aggiunge un limite che vale la pena conoscere prima di riprogettare un prodotto, perché delimita l’obbligo dal lato dell’hardware. I dati prontamente disponibili non comprendono quelli che la progettazione del prodotto non prevede siano archiviati o trasmessi al di fuori del componente in cui vengono generati, o al di fuori del prodotto nel suo complesso. Il Regolamento, si legge, non va inteso nel senso di imporre l’obbligo di archiviare i dati nell’unità di calcolo centrale del prodotto connesso.

Non è un’esenzione da usare come scusa, e per due ragioni. La prima è che nulla vieta a fabbricante e utente di concordare volontariamente quegli adattamenti. La seconda è che una scelta progettuale fatta per rendere i dati irraggiungibili è esattamente ciò che il capo IV consente di contestare.

Lo stesso considerando chiarisce infine che gli obblighi di progettazione non pregiudicano il principio di minimizzazione dell’art. 5, par. 1, lett. c), GDPR: il Data Act non chiede di progettare prodotti che conservino dati personali ulteriori rispetto a quelli necessari alle finalità del trattamento.

I modelli della Commissione propongono una classificazione utile per raggruppare i dati quando se ne concorda l’uso: dati sullo stato del prodotto o del servizio (configurazione, versione, messaggi diagnostici, consumi, manutenzione), dati sull’utilizzo da parte del cliente (orari e tipi di attività, geolocalizzazione del prodotto), dati sull’ambiente dell’utente (condizioni del suolo, dimensione dell’area) e dati sull’ambiente generale (meteo), con i relativi metadati.

Il documento aggiunge un avvertimento che conviene riportare: i dati sull’utilizzo possono in certi casi essere dati personali, e in quel caso escono dalla clausola sull’uso dei dati non personali per ricadere nelle previsioni contrattuali dedicate e nel GDPR.

4. I diritti dell’utente: accesso, utilizzo, condivisione con terzi

Gli artt. 3, 4 e 5 del Regolamento attribuiscono all’utente del prodotto connesso tre diritti che ridisegnano l’equilibrio contrattuale.

Il diritto di accesso (art. 3) deve essere garantito per progettazione e per impostazione predefinita. Per i prodotti immessi sul mercato dopo il 12 settembre 2026, l’accesso deve essere integrato nella progettazione: facile, sicuro, gratuito, in formato strutturato leggibile da dispositivo automatico. Anche un’impresa cliente, un noleggiatore o una società di leasing rientrano nella definizione di utente.

Il diritto di utilizzo (art. 4) consente all’utente di usare i dati per qualsiasi finalità lecita. L’art. 4, par. 13 stabilisce che il titolare può utilizzare i dati non personali prontamente disponibili solo sulla base di un contratto stipulato con l’utente: senza autorizzazione contrattuale specifica nessun uso è legittimo, nemmeno per il miglioramento del prodotto. Lo stesso paragrafo gli vieta di usare quei dati per ricavare informazioni sulla situazione economica, sulle risorse o sui metodi di produzione dell’utente, o comunque in modo da comprometterne la posizione commerciale.

L’art. 4, par. 14 aggiunge un divieto distinto e spesso trascurato: il titolare non mette i dati non personali del prodotto a disposizione di terzi per finalità commerciali o non commerciali diverse dall’esecuzione del proprio contratto con l’utente, e dove occorre vincola contrattualmente quei terzi a non ricondividerli.

Il diritto di condivisione con terzi (art. 5) è la dimensione più dirompente: un’azienda agricola può chiedere al fabbricante del trattore di trasmettere i dati a un fornitore indipendente di manutenzione predittiva. I destinatari devono essere imprese (non consumatori) e non possono essere gatekeeper individuati ai sensi del DMA.

C’è poi un divieto che viene attribuito al soggetto sbagliato con una certa frequenza, e conviene fissarlo: il divieto di sviluppare un prodotto concorrente non grava sul titolare, che quel prodotto lo fabbrica, ma su chi i dati li ottiene.

• L’art. 4, par. 10 lo impone all’utente: non può usare i dati ottenuti per sviluppare un prodotto in concorrenza con quello da cui provengono, né condividerli con un terzo a quel fine, né ricavarne informazioni sulla situazione economica, sulle risorse e sui metodi di produzione del fabbricante o del titolare.
• L’art. 6, par. 2, lett. e) impone lo stesso divieto al terzo destinatario che riceve i dati su richiesta dell’utente.

L’art. 4, par. 11 sancisce infine il principio del no right to hack: l’utente non ricorre a mezzi coercitivi né abusa di lacune nell’infrastruttura tecnica del titolare per ottenere accesso ai dati.

5. Le informazioni precontrattuali obbligatorie

L’art. 3, parr. 2 e 3 del Regolamento impone obblighi informativi nei confronti dell’utente prima della conclusione del contratto, sia in rapporti B2C sia B2B.

Per il venditore, locatore o noleggiatore del prodotto connesso, l’art. 3, par. 2 richiede di indicare almeno: tipo, formato e volume stimato dei dati generati; se sono prodotti in tempo reale; se sono accessibili direttamente dal dispositivo o vanno richiesti al titolare; modalità di esercizio dei diritti dell’utente.

Per il fornitore del servizio correlato, l’art. 3, par. 3 richiede informazioni più estese: tipologia e volume dei dati; finalità di utilizzo da parte del titolare; identità e mezzi di contatto del titolare; modalità di richiesta di condivisione con terzi; presenza di segreti commerciali e identità del detentore.

Queste informazioni si traducono in clausole contrattuali obbligatorie. Il considerando 24 ammette che l’obbligo possa essere soddisfatto mantenendo un URL stabile o un codice QR, purché l’utente possa archiviare il contenuto su un supporto durevole.

Una sovrapposizione importante riguarda l’art. 13 del GDPR: gli obblighi informativi privacy si integrano con quelli del Data Act, ma non sono sostituibili. L’utente Data Act è più ampio dell’interessato GDPR (include persone giuridiche) e copre anche dati non personali.

6. I quattro modelli di contratto della Commissione

L’art. 41 del Regolamento imponeva alla Commissione, «prima del 12 settembre 2025», di elaborare e raccomandare clausole contrattuali tipo non vincolanti per l’accesso ai dati e il loro utilizzo, comprese le clausole su un compenso ragionevole e sulla protezione dei segreti commerciali.

Il lavoro preparatorio è dell’Expert Group on B2B Data Sharing and Cloud Computing Contracts, che ha pubblicato il proprio Final Report il 2 aprile 2025. Su quella base, il 19 novembre 2025, la Commissione ha approvato un progetto di raccomandazione che raccoglie i modelli negli allegati da II a V.

È un progetto e non una raccomandazione adottata: il documento porta l’intestazione «draft», il blocco della firma è in bianco, e la pagina istituzionale della Commissione dedicata al Data Act lo elenca ancora come tale. Il termine dell’art. 41 è quindi scaduto senza che la raccomandazione sia stata formalmente adottata. I modelli restano pienamente utilizzabili: sono non vincolanti per definizione, e la loro utilità è di offrire un testo già calibrato sul Regolamento a chi deve negoziare.

6.1 I quattro modelli, come li nomina il documento ufficiale

• Allegato II: il contratto fra l’utente di un prodotto connesso o di un servizio correlato e il titolare dei dati.
• Allegato III: il contratto fra l’utente e un destinatario dei dati.
• Allegato IV: il contratto fra titolare e destinatario, per il caso in cui il titolare abbia un obbligo legale di mettere i dati a disposizione di un terzo indicato dall’utente.
• Allegato V: il contratto fra imprese che condividono dati su base volontaria, soggetto al controllo di abusività del capo IV.

Nella pratica professionale questi quattro modelli circolano ancora con le sigle del gruppo di esperti, H2U, U2R, H2R e S2R, che restano comode. Vale però la pena sapere che il documento della Commissione non le usa: se si cita un modello in un contratto o in una lettera, il riferimento che regge è il numero dell’allegato.

Il modello dell’allegato II è quello più frequente e più articolato, ed è al centro del capitolo che segue.

Gli allegati sono pensati per rapporti B2B. Per i contratti con i consumatori servono adattamenti che rispettino la disciplina consumeristica, più stringente su limitazioni d’uso e modifica unilaterale.

7. I contenuti critici del contratto fra titolare e utente

Il contratto fra titolare dei dati e utente, l’allegato II, è quello su cui si concentrano le maggiori complessità operative. Cinque aree meritano un’attenzione specifica.

7.1 Perimetro dei dati oggetto di condivisione

Il contratto deve identificare in modo puntuale quali dati sono inclusi, distinguendo dati grezzi, pretrattati e metadati pertinenti ed escludendo le informazioni di secondo livello. La genericità è il principale rischio: una clausola che parli di “dati generati dal prodotto” senza specificare formato, frequenza, volume e categorie espone il titolare a contestazioni sia per eccesso sia per difetto.

7.2 Utilizzo dei dati non personali da parte del titolare

L’art. 4, par. 13 è categorico: il titolare può utilizzare i dati non personali solo sulla base di un contratto con l’utente. Senza pattuizione esplicita, qualsiasi uso è illegittimo. Le finalità tipiche da contrattualizzare sono esecuzione del contratto, garanzia e assistenza post-vendita, monitoraggio e miglioramento del prodotto, controllo qualità, sviluppo di nuovi prodotti, aggregazione e condivisione di dati derivati con terzi nei limiti dell’art. 4, par. 14.

7.3 Protezione dei segreti commerciali

L’art. 4, parr. 6-8 disciplina il bilanciamento tra accesso ai dati e tutela del know-how. Il titolare non può rifiutare l’accesso solo perché alcuni dati costituiscono segreti commerciali, ma può imporre misure tecniche e organizzative proporzionate per preservarne la riservatezza: identificazione puntuale dei segreti, cifratura, segregazione, NDA, controllo accessi, audit. Va prevista anche una clausola di “freno di emergenza” che consenta la sospensione dell’accesso in caso di violazione documentata, e la possibilità di diniego in “circostanze eccezionali” con prova di danno economico grave (art. 4, par. 8).

7.4 Limitazioni all’uso dei dati da parte dell’utente

Il considerando 25 prevede limitate possibilità di restringere contrattualmente l’uso dei dati da parte dell’utente, principalmente per evitare lo sviluppo di prodotti concorrenti, l’ingegneria inversa volta a scopi diversi dalla riparazione, e per il principio del “no right to hack”. Divieti generici di riuso possono essere considerati abusivi ai sensi del Capo IV.

7.5 Sub-utenti

Il considerando 18 chiarisce che, quando lo stesso prodotto è usato da più sub-utenti, ognuno gode dei diritti del Regolamento. Il caso tipico è il car sharing, dove la compagnia di noleggio è “utente iniziale” e ciascun automobilista è “sub-utente”. Il titolare può adottare due strategie: interagire direttamente con ciascun sub-utente, o riconoscere all’utente iniziale un ruolo di intermediario (assimilabile al mandato con rappresentanza) che gestisce i diritti per conto dei sub-utenti.

8. Errori frequenti e rischi pratici

Cinque errori ricorrono nei contratti IoT analizzati dopo il 12 settembre 2025.

Il primo è la confusione tra dati grezzi/pretrattati e informazioni di secondo livello, che porta a includere nei servizi a pagamento dati che dovrebbero essere accessibili gratuitamente.

Il secondo è l’informativa precontrattuale incompleta: la mancata indicazione del titolare dei dati, dei mezzi di contatto, delle modalità di esercizio dei diritti rende difficile dimostrare la conformità all’art. 3.

Il terzo è la gestione approssimativa dei segreti commerciali: senza mappatura dei trade secret e misure tecniche proporzionate, il titolare si trova a scegliere tra rivelare il know-how o subire contestazioni di rifiuto immotivato.

Il quarto è l’assenza di clausole su sub-utenti in modelli multi-utente, con esposizione a richieste contemporanee da soggetti diversi.

Il quinto è la mancata distinzione tra obblighi B2C e B2B: la disciplina consumeristica rende inefficaci molte clausole pensate per il B2B, in particolare su limitazioni d’uso e modifica unilaterale del contratto.

I rischi pratici sono significativi: nullità delle clausole non conformi, responsabilità contrattuale verso utenti e destinatari, perdita di legittimazione a usare i dati non personali per le proprie finalità, contestazioni di abusività ex Capo IV, sanzioni amministrative una volta operativo il decreto attuativo italiano.

Conclusioni

Il capo II del Data Act è la parte del Regolamento che tocca il prodotto e non solo la carta, e per questo è la più costosa da ignorare. Un contratto sbagliato si riscrive; un prodotto progettato in modo che i dati non escano dal componente in cui nascono non si corregge con un allegato.

La scadenza del 12 settembre 2026 è il momento in cui questa differenza diventa operativa. Da quel giorno l’accesso per impostazione predefinita vale per ciò che si immette sul mercato, e la domanda che un fabbricante deve porsi non è più «cosa scrivo nel contratto» ma «cosa fa il mio dispositivo».

C’è poi il punto che nella nostra esperienza genera più errori, ed è una questione di soggetti. Il Regolamento distribuisce i divieti in modo asimmetrico: l’utente e il terzo destinatario non possono usare i dati per costruire un prodotto concorrente; il titolare non può usarli fuori da un contratto con l’utente né passarli a terzi oltre l’esecuzione di quel contratto. Confondere queste posizioni porta a scrivere clausole che vietano la cosa sbagliata alla persona sbagliata, e quelle clausole il capo IV le tratta come abusive.

La nostra raccomandazione, dichiarata come valutazione: la mappatura dei dati va fatta prima della stesura del contratto, e la mappatura dei segreti commerciali prima di entrambe. Un titolare che arriva alla richiesta di accesso senza sapere quali dati contengano know-how si trova davanti a due sole opzioni, e sono entrambe cattive: rivelare più di quanto vorrebbe, oppure rifiutare senza poter dimostrare il perché.

Punti chiave

Fonti