Data Act e intelligenza artificiale: ecco i 7 impatti che i team AI devono gestire

Il Data Act (Reg. UE 2023/2854) è entrato ufficialmente in applicazione, quasi integrale (alcune parti lo saranno successivamente), il 12 settembre 2025 – venti mesi dopo l’entrata in vigore dalla pubblicazione in Gazzetta UE dell’11 gennaio 2024^[1]. Si affianca a un mosaico normativo che comprende tra l’altro il GDPR, l’AI Act e, da pochi giorni, persino la nuova Legge italiana n. 132/2025 sull’intelligenza artificiale.

Mentre l’attenzione di molte imprese è rivolta alle classiche questioni di data sharing fra produttori di device connessi e utilizzatori, l’impatto sui sistemi di AI – soprattutto quelli “high-risk” o “general-purpose” – rischia di essere sottovalutato. Di seguito, per cominciare a discutere di questi incroci di compliance che potranno essere piuttosto complessi, si vogliono proporre sette aspetti critici (e qualche scenario concreto) da tenere d’occhio. Per cominciare a meditare su aspetti e conseguenze che potrebbero dilagare anche in maniera critica, oltre che difficile da governare.

Oltretutto diversi Stati membri stanno orientando il proprio quadro sanzionatorio per il Data Act allineandolo alle pesanti ammende previste dal GDPR (fino al 4% del fatturato globale annuo). Se a ciò si sommano le sanzioni amministrative previste dall’AI Act (che possono raggiungere il 7% del fatturato globale), emerge un quadro di rischio finanziario esponenziale: un unico errore nella gestione di un dato, che porti a un output errato di un sistema AI, potrebbe teoricamente innescare una doppia sanzione, costando all’azienda o P.A. una fetta sensibile del proprio fatturato/bilancio.

Al momento in cui si scrive^[2] il quadro è reso ancora più incerto dal ritardo nell’adeguamento normativo nazionale: il termine per la notifica alla Commissione delle norme di competenza e delle sanzioni da parte degli Stati membri, come previsto dall’art. 40 del Data Act, era fissato per il 12 settembre 2025.

L’assenza di queste disposizioni nazionali di integrazione e recepimento lascia le aziende in una zona grigia, senza indicazioni precise su quali saranno le autorità di vigilanza designate e l’esatta entità delle sanzioni nel proprio paese.

1. Dati IoT come carburante “obbligatorio” e by design per i sistemi AI

Il centro del Data Act risiede negli articoli 3-5: questi articoli sanciscono un principio dirompente: i prodotti connessi (dall’elettrodomestico smart al macchinario industriale 4.0) devono essere progettati e fabbricati in modo tale che i dati (personali o meno) generati dal loro utilizzo siano, per impostazione predefinita, accessibili all’utente (sia esso un consumatore o un’azienda).

Per comprendere la portata di questo cambiamento, contestualizziamo alcuni concetti chiave:

• Dati del prodotto connesso (IoT Data): si tratta di qualsiasi dato generato dall’uso di un prodotto e che ne riflette le prestazioni, l’utilizzo o l’ambiente circostante. Parliamo di dati grezzi o pre-elaborati, come i log di un server, i valori di un sensore di temperatura, le coordinate GPS di un veicolo, i dati di telemetria di un robot industriale.
• Titolare dei dati (“data holder”): è l’entità (solitamente il produttore del dispositivo o fornitore del servizio correlato al dispositivo – visto che anche i servizi in tal senso sono ricompresi) che ha la capacità tecnica e contrattuale di accedere e controllare questi dati. Fino ad oggi il detentore ha operato in una condizione di quasi-monopolio su queste informazioni. Da non confondere con il titolare del trattamento in ambito GDPR per i dati personali, ben potrebbe differire dal titolare ai sensi del Data Act
• Utente: è la persona – fisica o giuridica – che possiede il prodotto o ne ha il diritto d’uso (contrattualmente o legalmente). Con il Data Act, l’utente diventa il vero “esercente” del diritto di accesso e utilizzo dei dati generati.
• Terza parte: qualsiasi entità, diversa dal detentore, a cui l’utente può chiedere di trasferire i dati. Può essere un fornitore di servizi di riparazione, una startup innovativa, un concorrente del produttore originale.

Fino ad oggi i dati generati da un macchinario industriale, per esempio, rimanevano quasi sempre confinati nell’ecosistema del produttore. Quest’ultimo li utilizzava per migliorare i propri prodotti, offrire servizi esclusivi di manutenzione predittiva e creare modelli di digital twin (gemelli digitali) a uso interno. Questo modello di business, basato sul cosiddetto vendor lock-in, forse sta per essere smantellato.

Ora immaginiamo una fabbrica che utilizza bracci robotici di un produttore “A”. Questi robot sono dotati di centinaia di sensori che generano terabyte di dati su vibrazioni, temperature, usura dei giunti e cicli di lavoro. Il produttore A è l’unico a poter analizzare questi dati. Offre al cliente un costoso pacchetto di manutenzione predittiva basato sui propri algoritmi di AI, sostenendo che solo lui ha la conoscenza per interpretare correttamente quei dati.

Ora, in forza del Data Act, il proprietario della fabbrica (l’utente, come visto) può esercitare il suo diritto di accesso. Può obbligare il produttore A a trasmettere, in tempo reale e in un formato interoperabile, l’intero flusso di dati a una startup “B”, specializzata in algoritmi di AI per l’ottimizzazione industriale. Questa startup B, forte dell’accesso a dati provenienti da macchinari di diversi produttori, potrebbe sviluppare un modello di manutenzione predittiva più efficiente, economico e agnostico rispetto alla tecnologia. Il vantaggio competitivo si sposta così dall’hardware e dal controllo dei dati alla qualità dell’algoritmo.

Il rischio degli “attacchi inversi”

Mentre i benefici in termini di concorrenza sono evidenti, le aziende (sia i detentori che le terze parti) devono considerare un rischio tecnico e legale spesso trascurato: gli attacchi inversi (c.d. “inversion attacks”). Un inversion attack è una tecnica di ingegneria inversa applicata ai modelli di machine learning, in parole semplici, analizzando l’output di un modello (le previsioni) e, soprattutto, i dati di input su cui si basa, è possibile ricostruire con un buon grado di approssimazione il modello stesso o, ancora, i segreti commerciali in esso contenuti.

Torniamo all’esempio del braccio robotico: il produttore A ha investito anni di ricerca e sviluppo per creare un algoritmo proprietario che correla specifiche micro-vibrazioni (un segreto commerciale) a un imminente guasto di un componente. Se è obbligato a condividere il flusso di dati grezzi sulle vibrazioni con la startup B, sta di fatto fornendo a un potenziale concorrente l’ingrediente chiave per replicare il suo modello predittivo.

Il confine tra il dato grezzo “condivisibile” e l’inferenza “proprietaria”

Questo scenario impone una riflessione strategica, nel punto di incontro tra Data Act e ciclo di vita dell’AI. Le aziende dovranno infatti definire – con precisione chirurgica – il confine tra il dato grezzo “condivisibile” e l’inferenza “proprietaria”, preparandosi a difendere tale distinzione in sede legale. Per chi sviluppa AI, questa non è una sfumatura, ma il fulcro della protezione del proprio vantaggio competitivo.

La distinzione è netta:

a) dato grezzo (da condividere), è l’input dei sensori, la materia prima (per un’auto connessa, sono i pixel grezzi di una telecamera o i punti di un LiDAR, il Data Act ne impone la condivisione);

b) dato inferito (proprietario), è l’output dell’algoritmo di AI, frutto di un investimento intellettuale (non è il pixel o un gruppo di pixel, è l’inferenza che quel gruppo di pixel sia un pedone; non è il dato di telemetria, è la previsione di “un guasto probabile al 75%” – il Data Act protegge questo risultato, escludendolo dall’obbligo di condivisione).

La sfida strategica per le aziende diventa quindi dimostrare questa differenza, non basta (auto)dichiararla, bisogna comprovarla. Ciò richiede:

1. “data lineage” rigorosa: tracciare e documentare l’intero percorso del dato, dalla sua acquisizione grezza alla trasformazione in output del sistema AI;
2. classificazione puntuale: etichettare ogni dato come “grezzo” o “inferenza AI” secondo criteri oggettivi e difendibili.

Per la Pubblica Amministrazione la prospettiva è duplice: come utente di tecnologie IoT (es. sensori per il monitoraggio del traffico), la P.A. può finalmente aprire il mercato a una pluralità di fornitori di servizi di analisi AI. Al contempo, deve acquisire le competenze per distinguere le offerte: capire chi fornisce vere inferenze di valore e chi rielabora semplicemente dati grezzi, orientando così la spesa pubblica verso l’innovazione reale e gestendo la governance di flussi di dati più complessi.

2. Trasparenza dell’AI Act vs. protezione dei segreti commerciali (trade secret) del Data Act

Se il primo impatto del Data Act riguarda “chi” può accedere ai dati, il secondo, altrettanto critico, riguarda “cosa” si può sapere su come questi dati vengono usati, specialmente per addestrare modelli di intelligenza artificiale. Qui si manifesta una delle tensioni normative più complesse del nuovo quadro digitale europeo: il conflitto tra gli obblighi di trasparenza dell’AI Act e la protezione dei segreti commerciali rafforzata dal Data Act.

Per comprendere appieno il dilemma è necessario analizzare le richieste, apparentemente divergenti, dei due regolamenti:

• Il Data Act, pur promuovendo la condivisione dei dati, pone un’enfasi chiara sulla salvaguardia dei segreti commerciali (trade secrets: l’art.4.3, stabilisce che il detentore dei dati e l’utente possono concordare misure per preservare la riservatezza delle informazioni sensibili. Ancora più importante, la Commissione Europea è incaricata di sviluppare e raccomandare clausole contrattuali tipo (“Model Contractual Terms”) per aiutare le parti a gestire la condivisione dei dati. Le bozze di questi termini sono già pubbliche, però la versione definitiva era attesa entro il 12 settembre 2025, al momento si segnalano ritardi in merito. Una volta definitive, si potranno adottare per definire cosa costituisce una misura “ragionevole” per proteggere un segreto commerciale, senza però che questo diventi un pretesto per un rifiuto ingiustificato alla condivisione. L’obiettivo è creare un equilibrio, ma la tutela del know-how rimane un pilastro.
• Sul fronte opposto, l’AI Act introduce obblighi di trasparenza senza precedenti, in particolare per i modelli di AI per scopi generali (GPAI – General-Purpose AI), come i grandi modelli linguistici (LLM). L’art. 53.1 lett. d), impone ai fornitori di tali modelli di redigere e rendere pubblicamente disponibile “un sommario sufficientemente dettagliato dei contenuti utilizzati per l’addestramento” del modello.

Come un’azienda europea deve conformarsi all’AI Act

A questo punto immaginiamo un’azienda europea che abbia sviluppato un modello GPAI all’avanguardia per il settore manifatturiero, addestrandolo su un dataset unico e proprietario. Questo dataset potrebbe essere composto da:

1. dati ottenuti tramite il Data Act da centinaia di macchinari industriali;
2. manuali tecnici e procedure di manutenzione proprietarie;
3. dati sintetici generati internamente, frutto di anni di ricerca e sviluppo.

La combinazione e la “ricetta” con cui questi dati sono stati selezionati, puliti e ponderati costituiscono il segreto commerciale fondamentale dell’azienda, il suo vero vantaggio competitivo.

Ora l’azienda si trova di fronte a un bivio: per conformarsi all’AI Act, deve pubblicare un “sommario sufficientemente dettagliato” delle fonti di training.

Ma cosa significa “sufficientemente dettagliato”? Se il sommario è troppo generico (es. “dati di telemetria da macchinari industriali”), rischia di essere considerato non conforme e incorrere in sanzioni – per proteggere il proprio know-how, deve evitare di rivelare la sua “ricetta segreta”.

Se il sommario è troppo specifico (es. “dati di vibrazione da sensori del produttore X, correlati con i manuali di guasto del modello Y e dati sintetici che simulano la rottura del componente Z”), sta di fatto fornendo ai concorrenti una roadmap per replicare il suo modello, vanificando il proprio investimento.

Va segnalato che in merito andranno rispettati sia Template for the Public Summary of Training Content della Commissione UE (pubblicato a luglio 2025) sia il Code of practice per GPAI (pubblicato ad agosto 2025 )^[3].

Il rischio più sottile e strategico per le aziende include l’uso strumentale degli obblighi di trasparenza da parte dei concorrenti. Un competitor potrebbe sistematicamente contestare la genericità dei summary pubblicati da un’azienda leader, avviando procedure di reclamo presso le autorità di vigilanza del mercato. Questo potrebbe innescare un contenzioso normativo il cui scopo sarebbe costringere il concorrente a un bivio: se fornire dettagli aggiuntivi sul training set, erodendo il proprio vantaggio competitivo, oppure impiegare risorse legali e tecniche per difendere la propria posizione, con il rischio di sanzioni e danni reputazionali.

Per le aziende, e in particolare per le PMI e le startup innovative che non dispongono di grandi risorse legali, questo scenario rappresenta una minaccia da non sottovalutare. La strategia di compliance deve diventare proattiva, definendo a priori un “perimetro di divulgazione” che bilanci la trasparenza richiesta con la protezione del nucleo essenziale del proprio segreto industriale.

Sarà fondamentale documentare sia cosa si è usato per l’addestramento, sia perché certi dettagli non possono essere divulgati, preparando una solida argomentazione giuridica da usare sia nei contratti basati sul Data Act sia nelle informative richieste dall’AI Act.

3. Portabilità cloud e AI: la rivoluzione silenziosa dello switching e le sue implicazioni strategiche

Mentre gran parte dell’attenzione sul Data Act si concentra sull’accesso ai dati dei prodotti IoT, un’altra sezione del regolamento, dedicata ai servizi di trattamento dei dati (Capo VI), è destinata a innescare una trasformazione nelle fondamenta operative dell’intelligenza artificiale: il diritto al cambio di fornitore (switching) per i servizi cloud ed edge.

Si tratta di innovazione sostanziale per il modello di business dei grandi provider cloud, smantellando le barriere che oggi rendono la migrazione di infrastrutture complesse un’operazione costosa, rischiosa e spesso proibitiva. Per i team che sviluppano e gestiscono sistemi di AI, le implicazioni sono profonde e richiedono un ripensamento strategico dell’architettura tecnologica.

Difatti il regolamento affronta direttamente il problema del vendor lock-in nel settore cloud, agli articoli da 23 a 31 introducono un percorso a tappe forzate per eliminare gli ostacoli al cambio di fornitore:

• i tanto discussi costi di uscita (egress fees) che i provider addebitano per il trasferimento dei dati fuori dalla loro piattaforma dovranno essere ridotti del 50% dal 12 settembre 2025, del 75 % dal 12 settembre 2026 e azzerati dal 12 gennaio 2027;
• inoltre, i fornitori di servizi cloud ed edge dovranno adottare misure concrete per facilitare la portabilità. Questo include l’obbligo di fornire informazioni chiare e di offrire “equivalenza funzionale” quando un cliente migra verso un altro servizio;
• la Commissione Europea promuoverà lo sviluppo di standard europei e l’adozione di specifiche di interoperabilità aperte, per garantire che i dati e le applicazioni possano “parlare” tra loro senza attriti, indipendentemente dal provider sottostante.

Cosa significa questo per le aziende

Caliamo quanto sopra all’ambito AI: prendiamo per es. un’azienda che abbia costruito l’intera sua pipeline di MLOps (Machine Learning Operations) su un unico, grande provider cloud “A”. Includendovi probabilmente:

• un data lake (terabyte di dati di addestramento archiviati in formati proprietari del provider A);
• servizi di training (script che utilizzano le GPU e i servizi di machine learning specifici del provider A);
• un repository dove sono archiviate le diverse versioni dei modelli addestrati, con i loro “pesi” (i parametri numerici che costituiscono il cuore del modello);
• servizi di inferenza, cioè API per l’erogazione delle previsioni, strettamente integrate con l’ecosistema del provider A. Oggi migrare questa complessa architettura verso un provider “B” può rappresentare un incubo, tecnico e finanziario.

Domani, grazie al Data Act, l’azienda potrebbe sia spostare i suoi dati senza costi, sia rivendicare il diritto di esigere che il processo sia tecnicamente agevolato.

Nuove responsabilità per le aziende

Attenzione: questa nuova libertà introduce una nuova responsabilità: la migrazione non è un semplice “copia e incolla”, per un sistema di AI – specialmente se ad alto rischio secondo l’AI Act – è fondamentale preservare l’integrità e la tracciabilità dell’intero processo.

L’AI Act, infatti, impone obblighi stringenti di registrazione degli eventi (logging) e di governance dei dati. Un’azienda deve essere in grado di dimostrare, in qualsiasi momento, con quali dati è stato addestrato un modello, come è stato validato e come si sta comportando in produzione. Se la migrazione da A a B interrompe o corrompe questo audit trail, l’azienda si espone a gravi rischi di non conformità. Il modello potrebbe essere considerato non più affidabile o – peggio – in violazione delle prescrizioni normative.

In questo nuovo contesto, la scelta degli standard tecnologici diventa tanto cruciale quanto la scelta del framework di machine learning (per es. come TensorFlow o PyTorch), come costruire un modello portabile, verificabile e agnostico rispetto all’infrastruttura. Questo significa che le decisioni architetturali devono essere prese con una visione multi-cloud fin dal primo giorno:

• privilegiare formati aperti e standard (per es. Parquet, Avro) rispetto a quelli proprietari del singolo provider,
• fare un uso “massiccio” di container (per es. Docker) e orchestratori (per es. Kubernetes) per “impacchettare” l’ambiente di addestramento e inferenza, rendendolo astratto dall’hardware sottostante,
• adottare strumenti e standard aperti per la gestione del ciclo di vita del modello (per es. MLflow) che garantiscano la continuità dell’audit trail anche in caso di migrazione.

4. Dataset “on demand” per il settore pubblico

Il Data Act introduce un potere generale di accesso straordinario ai dati, a favore del settore pubblico, delineato nel Capitolo V. Questa sezione del regolamento conferisce alle Pubbliche Amministrazioni e alle istituzioni dell’Unione il diritto di richiedere e ottenere dati detenuti da imprese private, in due scenari specifici:

a) per rispondere a un’emergenza pubblica (es. calamità naturali, crisi sanitarie) oppure

b) per adempiere a un compito specifico di interesse pubblico previsto dalla legge, quando i dati non sono altrimenti ottenibili.

Questa previsione – nota come B2G (Business-to-Government) data sharing – crea un’interfaccia diretta tra la P.A. e i sistemi di intelligenza artificiale privati, con implicazioni operative, legali e strategiche di vasta portata per le aziende che li sviluppano e li gestiscono.

Il diritto di accesso è però strettamente circoscritto: la richiesta deve essere motivata da una situazione eccezionale e dimostrare che i dati richiesti sono indispensabili per gestire l’emergenza o svolgere il compito istituzionale; se la richiesta non è legata a un’emergenza, il detentore dei dati ha diritto a una compensazione “ragionevole”. In caso di emergenza, l’accesso è gratuito; la P.A. ricevente è tenuta a implementare misure tecniche e organizzative per proteggere la riservatezza dei dati e dei segreti commerciali in essi contenuti, distruggendoli una volta raggiunto lo scopo.

Un esempio concreto

Se poniamo il caso nel settore agritech e dell’applicazione all’ambito AI, potrebbe darsi un’azienda del settore agritech che offre un sofisticato servizio basato su AI, tramite una piattaforma che raccoglie dati in tempo reale da una vasta rete di sensori IoT (stazioni meteo, sonde di umidità del suolo, droni, ecc.) installati presso migliaia di aziende agricole clienti. Alimentando un complesso modello di AI che fornisce previsioni micro-climatiche, stime sulla resa dei raccolti e allerte fitosanitarie. Il valore di questo servizio risiede evidentemente nel dataset aggregato e normalizzato e, soprattutto, nel modello predittivo che l’azienda ha addestrato con anni di dati storici.

In caso di una grave siccità che colpisca una Regione, la Protezione Civile – invocando lo stato di emergenza pubblica (art. 15) – ben potrebbe emettere una richiesta formale all’azienda agritech per ottenere l’accesso in tempo reale a tutti i dati di umidità del suolo e di evapotraspirazione della zona colpita.

In questo caso, ai sensi del Data Act andrà fornito un flusso di dati in tempo reale a un ente terzo che richiede la creazione di API dedicate, un aumento del carico sui server e un potenziale impatto sulle prestazioni del servizio erogato ai clienti paganti.

Gli SLA (Service Level Agreement), ovvero le garanzie contrattuali di performance, potrebbero essere messi a rischio.

Inoltre, sebbene i dati richiesti possano essere anonimizzati, la loro granularità potrebbe, in alcuni casi, permettere di re-identificare le aziende agricole coinvolte, sollevando questioni soprattutto di riservatezza contrattuale (si pensi poi se si trattasse di dati personali, il caso sarebbe esponenziale…).

Sebbene l’accesso sia limitato nel tempo e nello scopo, si aumenta la superficie di rischio per la potenziale fuoriuscita di know-how.

L’implicazione strategica più profonda è che i sistemi di AI privati – quando raggiungono una certa scala e pervasività – possono essere considerati de facto (tramite i dati ivi processati) delle infrastrutture di rilevanza pubblica, rientrando nell’alveo appena esemplificato del Data Act.

L’azienda agritech dell’esempio non sarebbe più solo un fornitore di servizi, mutando in una sorta di gestore di un sistema di monitoraggio ambientale la cui utilità sociale travalica gli interessi commerciali.

Le architetture software e i modelli di governance dei dati devono prevedere, “by design”, la possibilità di dover rispondere a richieste B2G. Questo significa predisporre API di emergenza, protocolli di anonimizzazione robusti e procedure per isolare e condividere specifici sottoinsiemi di dati in modo sicuro e controllato. Invece di subire passivamente le richieste, le aziende più lungimiranti possono avviare un dialogo con le istituzioni per definire in anticipo formati di dati, standard di condivisione e protocolli di emergenza.

Questo non solo semplifica la compliance, può posizionare l’azienda come un partner strategico e affidabile per la P.A.

5. Data Act e AI Act: la nuova catena della responsabilità e la sfida del risk management

Altro, e forse più complesso, impatto del Data Act sull’intelligenza artificiale è l’effetto a catena che la condivisione dei dati innesca sulla gestione del rischio e sulla ripartizione della responsabilità, così come previsto dall’AI Act. I due regolamenti, insieme, creano un’architettura di compliance interconnessa, dove le azioni (o le omissioni) di un attore della filiera si ripercuotono inevitabilmente su tutti gli altri.

Per i sistemi di AI classificati come ad alto rischio (high-risk), l’AI Act impone un rigoroso sistema di gestione del rischio che copre l’intero ciclo di vita del sistema.

È qui che l’interazione con il Data Act diventa critica e potenzialmente esplosiva. Difatti l’art. 9 dell’AI Act stabilisce che i fornitori di sistemi ad alto rischio devono implementare un sistema di gestione del rischio che sia un processo iterativo e continuo. Questo processo prosegue per tutta la durata di vita del sistema, tra i suoi pilastri fondamentali troviamo:

• governance e qualità dei dati (art. 10): i dataset utilizzati per l’addestramento, la validazione e il test devono essere “pertinenti, rappresentativi, privi di errori e completi”;
• sorveglianza umana (art. 14): il sistema deve essere progettato per poter essere efficacemente supervisionato da persone fisiche;
• registrazione degli eventi (“logging” – art. 12): il sistema deve essere in grado di registrare automaticamente gli eventi (“log”) per garantire un livello di tracciabilità del suo funzionamento;
• monitoraggio post-mercato (art. 72): il provider deve raccogliere e analizzare attivamente i dati sulle prestazioni del sistema una volta che è operativo.

Un doppio scenario

Data la complessità, giova immaginare un doppio scenario, nel caso per es. di un’azienda che sviluppa un sistema di AI ad alto rischio per la gestione del traffico aereo, il cui scopo è ottimizzare le rotte in tempo reale per ridurre consumi e ritardi. Prima dell’applicazione del Data Act, l’azienda poteva addestrare il suo modello usando dati proprietari o acquistati da fornitori qualificati, sui quali ha pieno controllo e può effettuare tutte le verifiche di qualità richieste dall’AI Act.

Dopo tale data di entrata in applicazione, lo scenario si complica: l’aeroporto (l’utente) che utilizza il sistema AI, esercitando i suoi diritti, può obbligare i produttori di aerei, i fornitori di servizi a terra e le compagnie aeree a condividere flussi di dati in tempo reale con il fornitore del sistema AI. Quest’ultimo si trova quindi a dover integrare nel suo modello dati “ereditati” da terze parti, sui quali non ha un controllo diretto.

Un esempio concreto

Supponiamo che i dati provenienti dai sensori di un aereo di un certo produttore siano sistematicamente imprecisi (un bias nascosto) o che il formato fornito da un servizio di handling a terra sia incompleto. Il fornitore del sistema AI si trova di fronte a diversi dubbi applicativi, per es.: se integra questi dati “difettosi” nel suo modello, viola direttamente l’art. 10 dell’AI Act, il quale richiede dati privi di errori e rappresentativi (l’output del suo sistema potrebbe diventare inaffidabile, e in caso di incidente, la sua responsabilità sarebbe quasi certa); se rifiuta di integrare i dati, potrebbe scatenare una controversia contrattuale con il suo cliente (l’aeroporto), che si aspetta che il sistema utilizzi tutti i dati disponibili per massimizzare le performance. La responsabilità, quindi, si propaga a cascata. Il fornitore del sistema AI diventa responsabile anche della qualità e dell’idoneità dei dati che riceve da terzi, in virtù del Data Act.

Questa nuova e complessa catena di responsabilità crea un’esigenza strategica spesso sottovalutata: la necessità di verificare e “certificare” la qualità dei dati lungo la filiera, aspetto che va dimostrato. Questo apre la strada a inaugurare o sviluppare un potenziale nuovo mercato e a nuove funzioni aziendali di cui si comincia a parlare, come per es. un “Data Quality Officer” (il cui compito sarebbe validare i flussi di dati in ingresso da terze parti, verificandone la conformità ai requisiti dell’AI Act (rappresentatività, accuratezza, completezza), oppure servizi di Audit e certificazione dei Dati (“certificazioni di qualità” che il fornitore del sistema AI può usare per dimostrare la propria diligenza), oltre a clausole contrattuali di garanzia, nei rapporti tra il fornitore del sistema AI, l’utente e le terze parti che forniscono i dati (si dovranno includere clausole specifiche di garanzia sulla qualità dei dati e meccanismi di indennizzo in caso di non conformità).

In conclusione, la gestione del rischio non riguarda più solo il proprio modello AI, si deve alzare lo sguardo all’intero ecosistema di dati in cui opera. Le aziende che per prime svilupperanno metodologie e strumenti per governare questa complessità costruiranno un fondamentale vantaggio competitivo, basato sull’affidabilità e la fiducia.

6. La nuova frontiera “user-centric” dell’AI: diritti dei consumatori e obblighi aziendali

Se finora abbiamo analizzato gli impatti del Data Act negli scenari B2B e B2G, è nel rapporto con il consumatore finale (B2C) che la sinergia con l’AI Act e l’ambito AI manifesta il suo potenziale più trasformativo. Il Data Act, infatti, è anche una norma che pone l’utente (consumatore, eventualmente) al centro dell’economia dei dati generati dai prodotti che acquista e utilizza ogni giorno.

Difatti dal 12 settembre 2025 chiunque acquisti o noleggi un dispositivo connesso – dall’auto elettrica al termostato smart, dallo smartwatch all’elettrodomestico intelligente – acquisisce un pacchetto di diritti concreti e azionabili. Il consumatore-utente potrà:

1. accedere in autonomia al flusso di dati grezzi (raw data) generati dal suo utilizzo (anche se il dispositivo è in stand-by!);
2. ordinare al produttore di inoltrare tali dati a un terzo, ad esempio una startup che offre un servizio innovativo basato su un algoritmo di intelligenza artificiale;
3. pretendere che i contratti di licenza non contengano clausole “scorrette” (unfair) che limitino o vanifichino questi diritti.

Ma c’è un presupposto ancora più fondamentale, spesso dato per scontato: per poter utilizzare i dati generati dal prodotto, anche per i propri scopi interni (come migliorare i servizi o addestrare i propri modelli di AI), il titolare dei dati (solitamente il produttore) deve avere un accordo contrattuale con l’utente che lo autorizzi a farlo.

Il Data Act ribalta la prospettiva: i dati sono dell’utente, e il titolare, per accedervi, deve avere una base contrattuale chiara e trasparente. Senza questo accordo, i dati rimangono semplicemente inaccessibili al produttore stesso.

Per le aziende che progettano e commercializzano modelli di AI rivolti al mercato consumer, questo si traduce nella necessità di rivedere tre ambiti operativi fondamentali, creando un ponte diretto con gli obblighi di trasparenza e governance dell’AI Act.

Nuovi rischi operativi e di responsabilità

L’applicazione pratica di questi diritti genera nuovi rischi operativi e di responsabilità che le aziende spesso ignorano o sottovalutano, per menzionare alcuni casi:

• se un utente esporta dati provenienti da un sensore mal calibrato del suo dispositivo e la startup AI, basandosi su questi dati errati, fornisce raccomandazioni sbagliate o dannose, di chi è la colpa? La catena di accountability tra il produttore dell’hardware IoT e il fornitore del servizio AI deve essere chiarita meticolosamente nei Termini di Servizio, per evitare costosi contenziosi;
• un eccesso di pop-up e richieste di consenso può portare a un’accettazione meccanica da parte degli utenti, simile a quanto accaduto con i cookie banner (peraltro sotto la lente di una revisione critica in sede europea…). Questo fenomeno, noto come “consent fatigue”, erode la fiducia e mina la validità di consensi e accettazioni contrattuali. Le aziende che, al contrario, investiranno in una UX che spiega in modo semplice e trasparente il valore della condivisione dei dati trasformeranno un obbligo di compliance in un potente asset reputazionale e competitivo;
• ogni aggiornamento del firmware di un dispositivo IoT che modifica il formato o la semantica dei dati generati deve essere gestito con cura. Il produttore dell’hardware ha l’obbligo di notificare con adeguato preavviso i partner AI che ricevono quei dati, altrimenti i loro modelli rischiano di subire un data drift improvviso – con conseguenti malfunzionamenti o degrado delle performance. Una robusta governance della filiera tecnologica diventa essenziale.

7. Il concetto di “fairness”: l’anello mancante tra Data Act, AI Act e diritto della concorrenza

Al di là dei singoli obblighi tecnici, la nuova architettura normativa europea (da intendere composta da Data Act, AI Act e Digital Markets Act) introduce e ripete con insistenza un concetto tanto fondamentale quanto scivoloso: la “fairness”, ovvero l’equità. Questa nozione rappresenta un vero e proprio criterio giuridico che dovrebbe guidare l’accesso ai dati, la progettazione degli algoritmi e la struttura dei mercati digitali.

Tuttavia, come evidenziato da recenti analisi accademiche, emerge una criticità di fondo: mentre questi nuovi regolamenti elevano la “fairness” a principio cardine, non ne forniscono una definizione chiara e operativamente univoca. L’AI Act la lega alla non-discriminazione e all’assenza di bias; il Data Act la applica alle clausole contrattuali per l’accesso ai dati; il DMA la usa per definire mercati “contestabili ed equi”. Questa frammentazione crea incertezza giuridica soprattutto per le imprese.

Il diritto della concorrenza dell’Unione Europea

L’aspetto strategico sottovalutato è che la soluzione a questa ambiguità potrebbe già esistere nel nostro ordinamento, precisamente nel diritto della concorrenza dell’Unione Europea. Da decenni, infatti, il diritto antitrust si occupa di “pratiche sleali” e, in particolare, l’art.102 del Trattato sul Funzionamento dell’UE vieta esplicitamente l’imposizione di “prezzi non equi” da parte di un’impresa in posizione dominante. La giurisprudenza europea ha sviluppato test e criteri per determinare, in modo oggettivo, quando un prezzo è talmente sproporzionato rispetto al valore economico del bene da essere considerato “iniquo”.

L’argomentazione è che – per dare concretezza e certezza giuridica alla “fairness” nel contesto dell’AI e dei dati – le aziende e le autorità dovrebbero ispirarsi proprio a questo approccio consolidato. Invece di perdersi in definizioni astratte si potrebbero applicare per analogia i principi del diritto della concorrenza a nuovi fenomeni, come la collusione tramite prezzi algoritmici, dove l’assenza di intervento umano porta a un aumento ingiustificato dei prezzi, oppure il rifiuto di concedere l’accesso a dati essenziali per addestrare un modello AI concorrente, oppure il “prezzo” implicito che paghiamo con i nostri dati personali per usare un servizio.

Va dato atto che vi sarà un coordinamento tecnico-normativo affidato in parte al nuovo Data Innovation Board istituito dall’art. 35 del Data Act, destinato a emanare linee guida e standard settoriali.

Ancorare la fairness del Data Act e dell’AI Act alla solida tradizione del diritto della concorrenza potrebbe significare fornire alle imprese uno strumento pratico per autovalutare la propria conformità e alle autorità un metro di giudizio coerente, riducendo il rischio di interpretazioni arbitrarie e garantendo un’applicazione armonizzata delle regole in tutta l’Unione.

Conclusioni: una prima cassetta degli attrezzi

L’intreccio tra Data Act e AI Act ridisegna le fondamenta del mercato e dei servizi. Affrontarlo con un approccio “a silos” – i legali da una parte, i tecnici dall’altra – potrebbe essere la peggior ricetta. La governance del dato diventa un asset strategico a tutti gli effetti, sempre più, e vanno costituiti team interdisciplinari per poter arrivare a garantire una compliance sempre più complessa e trasversale.

Se dobbiamo quindi distillare una cassetta degli attrezzi minima, alla luce di quanto sopra, diciamo una prima lista di cose da fare subito per governare l’impatto del Data Act sui sistemi di intelligenza artificiale, ecco cinque punti da cui partire e sui cui interrogarsi:

• Data Export by Design, non per finta: la “funzione di portabilità” non può essere una voce nascosta in un menù. Deve essere una feature vera, semplice, testata da utenti reali e inserita nel backlog di prodotto fin dal primo giorno;
• contratti pronti al cambiamento: non aspettate, preparate un’architettura contrattuale modulare. Quando la Commissione pubblicherà le Clausole Contrattuali Tipo definitive, si dovrà essere pronti a integrarle per gestire quella terra di nessuno che sta tra la difesa dei segreti commerciali e l’obbligo di trasparenza, soprattutto;
• una dashboard, due prospettive: pensate a una console unica. Da un lato, il cliente-utente vede dove vanno i suoi dati, in modo chiaro e semplice. Dall’altro, il team di compliance traccia come quegli stessi dati finiscono nel training summary dell’AI. Trasparenza fuori, controllo dentro;
• la prova del nove sulla fiducia (UX Review): fate controllare le interfacce da un occhio esterno, periodicamente. L’obiettivo è stanare ed evitare i dark patterns e unificare le informative (Data Act, AI Act, DSA) in un’esperienza che crei fiducia, non la depauperi;
• un allarme per il “data drift”: i dati che ricevete da terzi cambieranno, è inevitabile. Mettere in piedi un sistema di monitoraggio automatico che suoni un campanello d’allarme non appena lo schema o la qualità di quei dati degrada, potrebbe essere l’unico modo per evitare che il sistema AI inizi a dare i numeri e se ne perda il controllo.

Questi sono alcuni dei nuovi pilastri per costruire un sistema, le realtà che sapranno integrare questi punti nella loro operatività guideranno la prossima fase dell’economia dei dati.

Note

1.ll Digital Services Act vieta i dark patterns e prevede sanzioni fino al 6 % del fatturato per le big platforms. ↑

2. Ciò solo i diritti di accesso ai dati; gli obblighi di re-design “data-export-by-default” scatteranno dal 12 settembre 2026. ↑

3. Si permette di rinviare per approfondimenti, in generale sul Data Act, alla recente pubblicazione del volume “Data act: Regolamento europeo sui dati”, a cura di Luca Bolognini, Enrico Pelino, Marco Scialdone, uscito per Giuffré Francis Lefebvre [qui] – ove è altresì presente un contributo del sottoscritto sul tema dei diritti e doveri di titolari e utenti del Data Act. ↑

4. Gli obblighi di trasparenza per GPAI già sul mercato scattano entro il 2 agosto 2027; per i modelli nuovi valgono da subito. ↑