Data Act: cosa cambia per imprese, sviluppatori e fornitori

È importante precisare che questo obbligo si applica in pieno a tutti i nuovi prodotti immessi sul mercato dopo il 12 settembre 2026, dando così alle aziende il tempo necessario per adeguare i propri progetti. Durante il periodo transitorio (dal 2025 al 2026), e per i prodotti già commercializzati, resta comunque l’obbligo di fornire i dati su richiesta, anche se il dispositivo non è stato progettato per rendere i dati accessibili “by design”.

Facciamo un esempio concreto: un costruttore di macchine agricole smart dovrà assicurarsi che i sensori installati inviino i dati raccolti a un database accessibile dall’acquirente della macchina – ad esempio tramite una dashboard online oppure attraverso un’API REST documentata. Se il trattore raccoglie informazioni sul rendimento, sull’umidità del suolo o sulla posizione, l’azienda deve prevedere che l’agricoltore possa recuperare quei dati autonomamente, ad esempio scaricando un file in formato CSV o JSON, o integrando il proprio software gestionale.

Un altro caso potrebbe essere quello di una software house che sviluppa un gestionale HR in modalità SaaS. In questo caso, i clienti dovranno poter accedere e scaricare in autonomia i propri dati, come l’anagrafica dei dipendenti, i contratti, i turni o le buste paga. La piattaforma dovrà quindi offrire un pannello di export self-service con formati standard (CSV, JSON, XML) o fornire un’API ben documentata, ovvero corredata da:

• descrizione chiara delle funzionalità disponibili;
• elenco degli endpoint con metodi (GET, POST, ecc.);
• parametri richiesti e opzionali;
• struttura e formato delle risposte (es. schema JSON o XML);
• esempi di richieste e risposte;
• istruzioni per l’autenticazione (OAuth2, API key);
• indicazioni su sicurezza, rate limit e autorizzazioni;
• definizione compatibile con OpenAPI / Swagger, per favorire l’integrazione automatica.

Inoltre, se il cliente decide di chiudere il contratto o migrare verso un’altra piattaforma, l’azienda dovrà consentire l’esportazione completa dei dati e, idealmente, fornire strumenti per l’importazione su altri ambienti. Se il SaaS utilizza infrastrutture di grandi cloud provider (es. AWS S3 o Google Cloud Storage), sarà necessario prevedere meccanismi per la migrazione fluida verso altri ambienti cloud o soluzioni on-premise, evitando vincoli tecnici o costi occulti.

In aggiunta al design nativo, il Data Act stabilisce che, qualora l’utente non possa accedere direttamente ai dati, il produttore – o, più in generale, il detentore dei dati – deve comunque renderli disponibili senza ingiustificato ritardo e senza costi, su semplice richiesta. L’Art. 4(1) specifica che i dati devono essere forniti in formato comune e leggibile da macchina, comprensivi dei metadati necessari per l’interpretazione, con la stessa qualità dei dati detenuti dal produttore e, se tecnicamente possibile, in modo continuo e in tempo reale. Le aziende dovranno quindi predisporre procedure digitali efficienti per soddisfare queste richieste: login al proprio account, richieste via API, strumenti self-service. Il regolamento sottolinea che l’accesso deve avvenire tramite una semplice richiesta elettronica, senza meccanismi dissuasivi come moduli cartacei o attese ingiustificate. È inoltre vietato richiedere all’utente informazioni non necessarie per la verifica dell’identità o conservare tracce della richiesta oltre quanto indispensabile (ad esempio è ammesso un log tecnico, ma non la profilazione dell’utente in base alla frequenza delle richieste).

Infine, un altro aspetto centrale riguarda la trasparenza contrattuale. Prima ancora che l’utente acquisti o utilizzi un prodotto connesso, l’azienda deve informarlo in modo chiaro e accessibile su una serie di elementi: quali tipi di dati vengono generati, in quale formato, se la raccolta è continua o in tempo reale, dove sono conservati, per quanto tempo e in che modo potrà accedervi o richiederne la cancellazione. Similmente, chi offre un servizio correlato a un prodotto connesso (es. un servizio cloud) dovrà informare l’utente sulle categorie di dati raccolte, sulla frequenza di raccolta, sulle finalità d’uso e sull’eventuale condivisione con terzi, includendo l’identità di questi ultimi. Tutte queste informazioni dovranno essere fornite prima della conclusione del contratto (di vendita o di servizio) e in forma comprensibile. In concreto, sarà necessario aggiornare la documentazione tecnica, le condizioni d’uso e i contratti: ad esempio, una scheda informativa potrebbe includere una tabella riepilogativa dei dati generati e istruzioni per accedervi, mentre in un contratto SaaS sarà necessario dettagliare le modalità e i limiti di esportazione.

Tutto ciò però apre un nuovo mondo: se l’utente ha diritto ad accedere ai dati, può anche farli trasmettere a terzi? E se sì, a che condizioni? Quali sono i rischi per la sicurezza e la segretezza?

Quando ci si può rifiutare di fornire i dati?

Ci sono circostanze eccezionali in cui l’accesso ai dati può essere limitato: se la condivisione di certi dati rischia di compromettere la sicurezza, salute o incolumità delle persone (ad esempio esponendo vulnerabilità di sicurezza del prodotto), l’azienda può temporaneamente rifiutare o limitare l’accesso, a patto che ciò sia necessario e proporzionato e derivante da obblighi di legge in materia di sicurezza. Questa clausola evita che il diritto ai dati confligga con, ad esempio, normative sulla sicurezza dei dispositivi medici o aeronautici. In tali casi, però, il produttore deve notificare l’autorità competente spiegando il rifiuto, e l’utente ha comunque diritto di ricorrere, presentando reclamo all’autorità o chiedendo un arbitrato.

Un tema delicato è la protezione dei segreti industriali. Il Data Act non obbliga a rivelare formule segrete o know-how: prima di condividere i dati, l’azienda e l’utente devono adottare misure per salvaguardare la riservatezza di eventuali segreti industriali. Tali misure possono includere accordi di riservatezza (NDA), protocolli di accesso limitato, filigrane digitali, e simili. Solo se, nonostante queste precauzioni, il rischio per l’azienda di subire un danno economico serio dalla divulgazione resta altissimo, il detentore può rifiutare di fornire quei dati specifici, invocando l’eccezione del segreto industriale. Anche questo rifiuto va motivato per iscritto e notificato alle autorità. In breve: open data non significa scoprirsi completamente. L’azienda deve condividere il necessario, ma può negoziare misure di tutela, come mascherare parti sensibili del dataset o imporre vincoli contrattuali sul loro uso.

Il Data Act pone inoltre paletti sull’uso improprio dei dati, sia per l’utente che per l’azienda. L’utente che ottiene i dati non può impiegarli per copiare il prodotto originale o condividerli con competitor al fine di sviluppare un prodotto concorrente. Questo per evitare che, ad esempio, un’azienda acquisti il macchinario di un concorrente, ne scarichi tutti i dati di funzionamento e li usi per clonarlo.

Simmetricamente, il produttore (data holder) non può utilizzare i dati generati dall’utente per trarne vantaggi competitivi a scapito dell’utente stesso, se non nei limiti di quanto contrattualmente concordato. Ad esempio, se un agricoltore usa un trattore connesso di una certa marca, i dati sull’attività di quell’azienda agricola non possono essere usati dal produttore (senza accordo) per trarre informazioni sul business dell’agricoltore o avvantaggiare altri attori sul mercato. Questo protegge le imprese utilizzatrici dal diventare trasparenti ai propri fornitori.

In sintesi, per i team tecnici ciò si traduce subito in alcune azioni chiave: progettare API e interfacce per l’export dei dati utente, predisporre database e formati standard per i dataset da condividere, implementare controlli di accesso e logging appropriati, aggiornare la documentazione e le interfacce utente per spiegare come accedere ai dati.

Ma se l’utente vuole condividere i propri dati con una terza parte di sua fiducia? Il Data Act disciplina anche questa possibilità. Vediamo come.

Il fornitore non può tenere in ostaggio né i dati né il cliente

Oltre all’accesso diretto, l’utente ha il diritto di far condividere i propri dati a un servizio o terza parte di sua scelta. Questo apre scenari di portabilità dei dati verso altri fornitori: ad esempio, un proprietario di auto connessa potrebbe voler inviare i dati del veicolo a un’officina terza per la diagnostica; oppure un’azienda potrebbe voler trasferire i dati di un macchinario industriale a un servizio cloud di analisi diverso da quello del produttore. Il Data Act tutela espressamente questa possibilità: su richiesta dell’utente, il detentore dei dati deve trasmettere i dati (con i relativi metadati) direttamente a un terzo indicato dall’utente, in condizioni analoghe a quelle dell’accesso diretto, cioè senza ritardi ingiustificati, gratuitamente e in formato interoperabile.

Ciò equivale a estendere il principio di portabilità (già noto per i dati personali nel GDPR) anche ai dati non personali, contestualizzando un diritto simile: i dati generati dall’utente possono “viaggiare” su sua istruzione. Per esempio, un’azienda che utilizza una piattaforma CRM SaaS può chiedere che i dati dei propri clienti vengano inviati periodicamente a un sistema terzo di marketing automation, senza doverli esportare e importare manualmente. L’azienda fornitrice del CRM dovrà quindi predisporre meccanismi (API, webhook, integrazioni) per abilitare questo flusso automatico di dati verso l’esterno, su autorizzazione dell’utente.

Per evitare abusi, il Data Act introduce alcuni vincoli di sicurezza nella condivisione a terzi:

• La terza parte che riceve i dati non deve essere un “gatekeeper” digitale già dominante secondo la definizione del Digital Markets Act (DMA). In altre parole, i big tech in posizione di forza non potranno usare questo canale per drenare dati, evitando che i benefici della normativa vengano sfruttati solo dai player dominanti.
• La terza parte è tenuta al rispetto delle stesse condizioni previste per l’utente: non può abusare di eventuali falle tecniche per estrarre più dati del consentito e deve rispettare gli accordi di riservatezza su eventuali segreti industriali. Il data holder può sospendere la trasmissione se rileva che il terzo non rispetta tali misure.
• Se i dati includono dati personali, questi possono essere trasferiti al terzo solo in presenza di un’idonea base giuridica (consenso, contratto, legittimo interesse, ecc., ai sensi dell’art. 6 GDPR). Inoltre, se si tratta di categorie particolari (es. dati sanitari o sensibili), si applicano le tutele aggiuntive previste dal GDPR. Ad esempio, una flotta aziendale connessa potrebbe generare dati di geolocalizzazione dei dipendenti: in tal caso, l’azienda dovrà avere una base legale adeguata per trasmetterli a un terzo e rispettare il principio di finalità.

Un altro aspetto rilevante riguarda l’equo compenso e il divieto di clausole vessatorie. Il Data Act consente al data holder di richiedere un compenso ragionevole per la condivisione dei dati verso terzi in determinati casi (ad esempio, verso aziende di grandi dimensioni). Tuttavia, il compenso deve rispettare condizioni e tariffe eque, che saranno ulteriormente definite dalle linee guida UE. Inoltre, sono vietate clausole contrattuali che ostacolino l’esercizio di questi diritti: qualunque disposizione che limiti il diritto dell’utente a condividere i dati con terzi, in violazione del Capo II del Regolamento, è nullo di diritto.

Dal punto di vista tecnico, per gli sviluppatori ciò implica la necessità di implementare funzionalità sicure di “Connect with Third-Party”. Ad esempio, offrire all’utente un pannello dove inserire le credenziali o l’API key del servizio terzo e gestire il flusso dati continuo verso quell’endpoint, mantenendo log minimali e senza conservare i dati oltre il necessario.

Un’attenzione particolare va data anche al formato dei dati condivisi: se il terzo accetta uno specifico standard (es. un’API JSON conforme a uno schema OpenAPI), il produttore dovrebbe allinearsi a quello standard. La standardizzazione gioca qui un ruolo cruciale: il Data Act incoraggia l’uso di API aperte e specifiche tecniche comuni per garantire interoperabilità e semplificare lo scambio. Le best practice prevedono l’utilizzo di formati diffusi (JSON, CSV, XML) e di vocabolari condivisi per i dataset, ad esempio standard ISO/IEC o ETSI nel caso di sensori IoT.

Ma cosa succede quando la condivisione dei dati è tra imprese di dimensioni molto diverse? Il Data Act affronta anche queste ipotesi di squilibrio contrattuale.

Le clausole abusive nei contratti di servizio

Il Capo IV del Data Act introduce tutele contro gli squilibri contrattuali nei rapporti tra imprese relativi all’accesso e all’uso dei dati. In sintesi: se un’azienda – soprattutto se PMI – stipula un contratto con un’altra in posizione significativamente più forte, eventuali clausole inique o sproporzionate a suo svantaggio saranno considerate nulle.

Sono nulle, ad esempio, le clausole che esonerano completamente la parte forte da responsabilità, oppure che le consentano di revocare unilateralmente l’accesso ai dati senza giustificazione né rimedi. Il legislatore ha previsto questa tutela proprio per impedire che i grandi operatori impongano condizioni contrattuali sbilanciate, sfruttando la propria forza negoziale.

Pensiamo a una PMI che firma un contratto con un big player per accedere a certi dati e si ritrova vincolata da clausole che “tolgono con una mano ciò che concedono con l’altra”: ad esempio, autorizzazioni solo formali all’uso dei dati, oppure la possibilità per il partner di interrompere l’accesso in qualsiasi momento, senza motivo. Oggi, clausole di questo tipo non producono più effetti legali. Il risultato è un contesto più favorevole per la partecipazione delle PMI all’economia dei dati.

Per i reparti legali delle software house, ciò comporta una revisione attenta dei contratti standard. L’articolo di riferimento è il 13. Chi fornisce dati o API alle PMI dovrà evitare condizioni squilibrate, mentre le PMI beneficiarie possono invocare una protezione normativa esplicita come base per rinegoziare termini più equi.

A rafforzare questo quadro, la Commissione Europea – come previsto dall’art. 41 – ha effettivamente sviluppato modelli di clausole contrattuali (Model Contractual Terms, MCTs) e clausole standard per il cloud (Standard Contractual Clauses, SCCs), condivisi con l’EDPB nel maggio 2025. Anche se non ancora pubblicati ufficialmente, questi modelli sono in fase avanzata e verranno raccomandati entro settembre 2025, in vista dell’entrata in applicazione del Regolamento.

Dal punto di vista tecnico, l’impatto è indiretto ma rilevante. Se la vostra piattaforma SaaS si basa sull’accesso a dati forniti da terzi, è essenziale garantire che le PMI clienti non subiscano limitazioni arbitrarie. Le condizioni di accesso ai dati dovranno rispettare il principio FRAND: fair, reasonable and non-discriminatory. Un principio che da oggi entra ufficialmente nel lessico contrattuale e tecnico dell’economia digitale.