Data Act UE: perché il 2026 è l’anno chiave per dati industriali IoT e cloud switching

Se dovessi riassumere il Data Act con una frase, direi così: trasforma il dato generato dall’uso di un prodotto connesso da “accessorio” a “funzione”. Una funzione che l’utente può chiedere. E che tu devi saper erogare senza smontare mezzo impianto o aprire falle nella sicurezza.

Il 2026 è l’anno chiave perché è il primo in cui si vedono insieme tre effetti che normalmente viaggiano separati. Il legale entra nel prodotto, il prodotto entra nel procurement e il procurement entra nel cloud. Se sei un produttore di macchine connesse, nel 2026 devi decidere quale parte del valore vendi come servizio e quale parte è un accesso dovuto. Se sei un utilizzatore industriale, nel 2026 inizi a fare richieste che fino a ieri dipendevano dalla buona volontà del fornitore. Se sei un provider cloud o un SaaS industriale, nel 2026 il tema switching non è più una slide, è una clausola che compare nelle gare.

C’è un altro motivo più silenzioso. Il regolamento prevede un obbligo di progettazione specifico che scatta sui prodotti immessi sul mercato dopo il 12 settembre 2026. Significa che le roadmap che partono adesso hanno una scadenza scritta in calendario.

Quando si parla di normative europee, il rischio è sempre lo stesso: capire il principio e perdere i dettagli. Con il Data Act succede spesso perché i dettagli sono quelli che ti costringono a fare una scelta architetturale. Non si tratta solo di “aprire i dati”. Si tratta di decidere dove passa il confine fra accesso legittimo, segreto industriale e sicurezza operativa.

Sommario dei contenuti

• Cronologia: 2025, 2026 e 2027 senza confusione
• Chi chiede cosa: user, data holder e casi industriali reali
• Accesso ai dati dei prodotti connessi: cosa cambia nei sistemi IoT
• Condivisione con terze parti: il punto in cui nascono le frizioni
• Sicurezza e segreti commerciali: come proteggersi senza bloccare tutto
• Cloud switching: clausole, digital assets e fine delle switching charges
• Caso reale: la “porta dei dati” in una fabbrica
• Guida operativa 2026: cosa fare in azienda
• FAQ

Cronologia: 2025, 2026 e 2027 senza confusione

La timeline è più semplice se la trasformi in tre domande. Quando posso ricevere una richiesta formale di accesso ai dati? Dal 12 settembre 2025. Quando un prodotto nuovo deve nascere già “pronto” per l’accesso? Dal 12 settembre 2026 per i prodotti immessi sul mercato dopo quella data. Quando il tema costi di switching nel cloud cambia registro? Dal 12 gennaio 2027 perché le switching charges non sono più consentite.

Ecco perché il 2026 è l’anno che pesa di più. Hai già l’obbligo di gestire accessi e condivisione. Hai una scadenza di progettazione che entra nei cicli di R&D. Hai una negoziazione cloud che deve trasformarsi da promessa commerciale a requisito contrattuale e tecnico.

Chi chiede cosa: user, data holder e casi industriali reali

Nel mondo industriale la domanda vera non è “chi possiede il dato”. La domanda è “chi ha diritto di usarlo” e “chi ha il potere tecnico di erogarlo”. Il Data Act usa due parole che conviene imparare bene: user e data holder. Sembra teoria ma in fabbrica diventa subito pratica.

Un esempio concreto che descrive bene quello che succede quando i ruoli non sono chiariti. La macchina è formalmente di una società di leasing, l’impianto la usa un produttore e la manutenzione è in outsourcing. Tutti hanno credenziali da qualche parte. Se non costruisci un modello di autorizzazioni, ogni richiesta di accesso diventa una discussione su email con rischio di errore.

Nel 2026 vedremo crescere proprio questo tipo di situazioni perché gli utenti finali avranno un motivo in più per chiedere accesso e per delegarlo a terzi. La delega è il punto delicato. Se la gestisci male, esponi il dato. Se la gestisci troppo rigida, crei attrito e finisci per perdere clienti o gare.

Accesso ai dati dei prodotti connessi: cosa cambia nei sistemi IoT

Molti competitor riducono tutto a una frase: “devi dare i dati al cliente”. Nella realtà è più tecnico. Il regolamento parla di dati prontamente disponibili e di metadati necessari per interpretarli. Tradotto: non basta un CSV, serve contesto. Un timestamp senza unità di misura, un codice evento senza dizionario, un parametro senza versione firmware sono dati che sembrano disponibili ma in pratica sono inutilizzabili.

C’è un secondo aspetto che nel 2026 diventa inevitabile. L’accesso può essere “diretto” oppure “indiretto”. Nel mondo OT spesso il diretto è difficile per motivi di rete e di sicurezza. Il punto è costruire un indiretto robusto. Significa creare una zona di esposizione dati che vive fuori dalla rete di controllo. Un data broker read only in DMZ, un API gateway con policy chiare, un export schedulato che non tocca PLC e SCADA.

Qui entra il pezzo che considero davvero inedito per molti: il Data Act costringe a pensare al dato come a un prodotto con una sua “supply chain”. Devi sapere da dove nasce, dove viene ripulito, dove viene arricchito e dove viene reso disponibile. Nel 2026 chi si muove bene non crea solo conformità. Crea anche un asset che rende più veloce integrare partner e cambiare piattaforma cloud senza rifare tutto.

Condivisione con terze parti: il punto in cui nascono le frizioni

Il passaggio più disruptive è questo: l’utente può chiedere che i dati arrivino a una terza parte. Nel B2B industriale la terza parte è spesso un fornitore di analytics, un manutentore predittivo, un energy manager, un integratore che costruisce un digital twin. È qui che cambia il mercato. Se prima il produttore poteva dire “solo tramite la mia dashboard”, ora entra la logica di interoperabilità.

Nella pratica si aprono due problemi. Il primo è la qualità: se dai al terzo un tracciato povero o in ritardo, quel servizio non funziona e il cliente te lo rinfaccia. Il secondo è la responsabilità: chi risponde se una condivisione male configurata espone dati sensibili dell’impianto? Nel 2026 la differenza fra aziende pronte e aziende in affanno sarà la presenza di un processo standard di onboarding per terze parti con controlli tecnici e clausole chiare.

Un dettaglio che merita attenzione è il perimetro. Non tutti i dati rientrano. Per esempio i dati generati durante fasi di test di un prodotto non ancora immesso sul mercato hanno un trattamento diverso. È un punto che incide su chi lavora con prototipi o con pre serie in stabilimento.

Sicurezza e segreti commerciali: come proteggersi senza bloccare tutto

Qui arriva la parte che quasi nessuno ama affrontare perché non è comoda. La tutela dei segreti commerciali è prevista e non è un dettaglio. Il regolamento consente misure per preservare segreti e per evitare danni seri, anche legati a safety e cybersecurity. La parola chiave però è “proporzionate”. Nel 2026 vedremo tanti casi in cui un produttore prova a usare il segreto industriale come freno generale. È rischioso perché può trasformarsi in conflitto con il cliente e in contestazione.

Quello che funziona di solito è un approccio a livelli. Prima identifichi quali dati possono davvero rivelare un know how critico. Poi scegli misure tecniche: mascheramento di campi, granularità ridotta, accesso in un ambiente controllato, rate limit, audit. Infine definisci misure contrattuali: riservatezza, limiti di uso, divieto di re identificazione.

E adesso il dettaglio che molti ignorano. Il Data Act entra anche nel design della tua interfaccia. Vieta pratiche di design che rendono più difficile per l’utente esercitare i suoi diritti. Se la richiesta dati è nascosta in un menu infinito o se l’utente deve superare passaggi inutili, questo non è solo un problema di esperienza. Diventa un potenziale punto di non conformità. Nel 2026 la UX dei portali IoT non sarà più solo marketing. Sarà anche compliance.

C’è anche una conseguenza tecnica che si vede subito: i log. Per sicurezza vuoi tracciare tutto. Per privacy e minimizzazione non puoi tracciare per sempre tutto. La soluzione pratica è definire un audit essenziale e temporizzato. Non serve inseguire l’onniscienza. Serve poter dimostrare chi ha fatto cosa senza trasformare i log in un nuovo archivio sensibile.

Cloud switching: clausole, digital assets e fine delle switching charges

Se mi chiedi dove il Data Act tocca davvero il nervo scoperto, io rispondo senza esitazione: il cloud switching. Non è detto che tutti cambieranno cloud domani. Dal 2026 però cambiano i rapporti di forza. Un cliente che ha un diritto di accesso ai dati IoT chiede anche un diritto di uscita dai servizi che li elaborano.

Il regolamento parla di servizi di data processing e chiede di ridurre gli ostacoli commerciali, tecnici e contrattuali allo switching. Nei contratti questo si traduce in punti molto concreti. Un esempio che fa sobbalzare chi scrive condizioni generali: il periodo massimo di preavviso per avviare lo switching non deve superare due mesi. Poi ci sono i digital assets. Non è solo “scaricare i dati”. Sono anche configurazioni, metadati, template e oggetti che servono per ricostruire un workload dall’altra parte.

Il pezzo economico è quello che nel 2026 diventa inevitabile in trattativa. Le switching charges possono essere ridotte e legate ai costi fino al 12 gennaio 2027. Dopo quella data non sono più consentite. Questo cambia come si impostano le gare e come si ragiona su egress fee. Nel 2026 ha senso chiedere ai provider trasparenza su cosa considerano switching e su quali costi vogliono imputare. Se non lo fai tu, lo farà chi arriva dopo con un procurement più aggressivo.

Un ultimo elemento che spesso resta fuori dai pezzi divulgativi è la differenza fra IaaS e servizi più alti. Alcuni obblighi tecnici sono pensati in modo diverso a seconda del livello di servizio. Per chi compra piattaforme e SaaS la conseguenza è semplice: non basta leggere un documento di marketing, serve capire cosa è portabile e con quali strumenti.

Caso reale: la “porta dei dati” in una fabbrica

Ti racconto un caso reale, anonimizzato. Un produttore italiano di macchine per il packaging aveva una piattaforma di teleassistenza venduta come servizio premium. I dati della linea arrivavano in cloud e venivano usati per manutenzione e per reportistica. Un cliente ha voluto condividere gli stessi dati con un fornitore esterno di ottimizzazione energetica.

La prima reazione interna è stata tipica: “gli diamo un export mensile”. Peccato che il servizio esterno funzionasse con finestre di cinque minuti. Il vero problema non era tecnico, era di governance. Mancava un punto unico in cui esporre i dati con un perimetro chiaro. Ogni team aveva un pezzo: OT aveva la sorgente, IT gestiva il cloud, il prodotto aveva la dashboard, il legale aveva i contratti.

La svolta è arrivata quando hanno smesso di ragionare per eccezioni e hanno costruito una porta unica dei dati. Un layer di accesso con autenticazione e policy. Un dizionario eventi pubblicabile. Una distinzione netta fra ciò che è telemetria del cliente e ciò che è know how del produttore. Con quel layer in piedi, la richiesta del cliente è diventata un flusso: autorizzazione, token, endpoint, audit essenziale.

La parte che quasi nessuno aveva previsto era il tema “utente”. In quel caso il cliente finale non era proprietario di tutte le macchine perché alcune erano in noleggio. Hanno dovuto gestire deleghe e durata. È qui che si capisce perché il 2026 è l’anno chiave: non basta aggiungere un export, serve un sistema di entitlement che vive nel tempo.

Guida operativa 2026: cosa fare in azienda

Se vuoi un percorso realistico, ti propongo di ragionare per blocchi di lavoro che parlano tra loro. Il primo è inventario e data mapping. Il secondo è interfaccia e sicurezza. Il terzo è contrattualistica e procurement. Se li fai in parallelo risparmi mesi perché eviti che il legale definisca clausole che la piattaforma non può rispettare o che l’IT costruisca API che nessuno sa governare.

Se produci prodotti connessi

Nel 2026 guarderei prima di tutto la roadmap. Se hai un nuovo modello di macchina o una nuova versione del servizio pronta per l’autunno, devi chiederti se rientra nel perimetro della progettazione obbligatoria. Poi farei un audit sui metadati. È la cosa che manca più spesso. Infine costruirei un processo standard per la condivisione con terze parti.

Se sei un utilizzatore industriale

Nel 2026 la tua leva è la richiesta strutturata. Chiedi accesso ai dati che ti servono davvero e chiedili nel formato e nella frequenza che rende possibile il tuo caso d’uso. Poi metti il cloud switching nei requisiti di procurement. Non come slogan ma come lista di elementi portabili e tempi di uscita verificabili.

Se sei un provider cloud o un SaaS industriale

Nel 2026 la priorità è evitare sorprese. Rivedi i contratti per includere perimetro di portabilità e tempi. Allinea pricing e processi alla progressiva eliminazione delle switching charges. Preparati a richieste di exit drill da clienti strutturati. Chi risponde bene nel 2026 si posiziona come fornitore affidabile, non come fornitore che trattiene.

Ti dico una cosa che emerge guardando progetti IoT in contesti diversi. Quasi tutti pensano che il problema sia “dare i dati”. In realtà il problema è decidere un confine. Il Data Act mette quel confine sotto stress perché introduce nuovi attori legittimi. L’utente non è più solo un destinatario, diventa un regista.

Nel 2026 la tentazione più grande sarà rispondere con workaround. Un export qui, un accesso manuale lì, un’eccezione gestita in ticket. Funziona finché le richieste sono poche. Quando diventano frequenti, il workaround diventa debito. A quel punto ogni richiesta costa tempo e crea rischio. È qui che una data access interface fa la differenza. È il pezzo che ti permette di essere conforme e di essere efficiente nello stesso momento.

Sul cloud switching, l’errore che vedo più spesso è confondere la portabilità dei dati con la portabilità del servizio. Portare via un bucket non significa ricostruire un’applicazione. Se nel 2026 fai un exit drill anche piccolo scopri subito se hai dipendenze nascoste, formati proprietari o automazioni non replicabili. Ed è molto meglio scoprirlo con un test che scoprirlo durante una crisi o durante una gara persa.

A cura di Junior Cristarella.