{"id":1484,"date":"2026-11-11T10:54:42","date_gmt":"2026-11-11T09:54:42","guid":{"rendered":"https:\/\/sites.unica.it\/ict4lawforensics\/?p=1484"},"modified":"2026-11-11T10:54:43","modified_gmt":"2026-11-11T09:54:43","slug":"data-act-dopo-il-12-settembre-2026-laccesso-ai-dati-diventa-requisito-di-progettazione","status":"publish","type":"post","link":"https:\/\/sites.unica.it\/ict4lawforensics\/2026\/11\/11\/data-act-dopo-il-12-settembre-2026-laccesso-ai-dati-diventa-requisito-di-progettazione\/","title":{"rendered":"Data Act: dopo il 12 settembre 2026, l\u2019accesso ai dati diventa requisito di progettazione"},"content":{"rendered":"\n

Dal 12 settembre 2026 il Data Act<\/em> ha raggiunto una nuova soglia applicativa. Il Regolamento (UE) 2023\/2854 si applica, nel suo impianto generale, gi\u00e0 dal 12 settembre 2025; l\u2019art. 50 ha per\u00f2 differito di un anno l\u2019operativit\u00e0 dell\u2019obbligo previsto dall\u2019art. 3, par. 1, per i prodotti connessi e i servizi correlati immessi sul mercato dopo il 12 settembre 2026. Restano ferme le esclusioni e le disposizioni transitorie previste dall\u2019art. 7. La disposizione interessa direttamente il modo in cui questi prodotti e servizi vengono progettati. I dati del prodotto, quelli del servizio correlato e i metadati necessari a interpretarli e utilizzarli devono essere, per impostazione predefinita, facilmente e sicuramente accessibili all\u2019utente, gratuitamente, in formato completo, strutturato, di uso comune e leggibile da macchina. L\u2019accesso deve essere diretto quando ci\u00f2 sia pertinente e tecnicamente possibile. \u00c8 soprattutto quest\u2019ultimo elemento a meritare attenzione. Non perch\u00e9 il Data Act<\/em> inauguri, dal 12 settembre 2026, un generale diritto dell\u2019utente sui dati generati dagli oggetti connessi: la disciplina dell\u2019accesso era gi\u00e0 parte essenziale del Regolamento. Ci\u00f2 che cambia \u00e8 il momento nel quale il problema giuridico deve essere affrontato. L\u2019accessibilit\u00e0 del dato entra ora fra i vincoli che accompagnano la costruzione del prodotto. La formula data access by design<\/em> non compare nel testo normativo e sarebbe improprio presentarla come una nuova categoria legislativa. Pu\u00f2 tuttavia descrivere efficacemente questa anticipazione della tutela: il diritto di accesso non opera soltanto a valle, quando l\u2019utente chiede il dato, ma condiziona alcune delle decisioni tecniche assunte prima che il prodotto venga immesso sul mercato.<\/p>\n\n\n\n

Sommario:<\/strong> 1. Quando una scelta tecnica condiziona l\u2019esercizio di un diritto. <\/a>\u2013 2. Accessibilit\u00e0 non significa apertura indiscriminate. <\/a>\u2013 3. Se il dato \u00e8 personale, l\u2019utente pu\u00f2 non essere l\u2019interessato.<\/a> \u2013 4. Data Act<\/em> e cybersecurity<\/em>: due esigenze che arrivano nello stesso Progetto. <\/a>\u2013 5. La conformit\u00e0 si sposta a monte.<\/a><\/p>\n\n\n\n

1. Quando una scelta tecnica condiziona l\u2019esercizio di un diritto<\/strong><\/strong><\/h2>\n\n\n\n

Il considerando 20 del Data Act<\/em> parte da un dato molto concreto. Il controllo esercitato dal fabbricante sulla progettazione consente spesso di determinare quali dati siano generati dal prodotto e, soprattutto, in quale modo possano essere raggiunti dall\u2019utente. La disponibilit\u00e0 giuridica del dato rischia cos\u00ec di dipendere da una decisione architetturale assunta da chi progetta il sistema.<\/p>\n\n\n\n

L\u2019art. 3, par. 1, interviene proprio su questo punto. Se il dato deve risultare accessibile \u00abper impostazione predefinita\u00bb, alcune scelte che potrebbero sembrare esclusivamente tecniche acquistano una rilevanza giuridica: dove il dato viene conservato, attraverso quale interfaccia pu\u00f2 essere recuperato, in quale formato viene esportato, quali procedure di autenticazione consentono l\u2019accesso.<\/p>\n\n\n\n

L\u2019art. 4, par. 1, conferma che il modello non \u00e8 rigidamente costruito attorno all\u2019accesso diretto. Quando l\u2019utente non possa ottenere i dati direttamente dal prodotto o dal servizio correlato, il titolare dei dati deve rendere accessibili quelli \u00abprontamente disponibili\u00bb, insieme ai metadati necessari, senza indebito ritardo, sulla base di una richiesta semplice e, quando tecnicamente possibile, mediante strumenti elettronici.<\/p>\n\n\n\n

Ne emerge un sistema pi\u00f9 articolato di quanto possa suggerire la sola espressione access by design<\/em>. La progettazione deve favorire l\u2019accessibilit\u00e0, ma il legislatore non impone un\u2019unica architettura tecnica e neppure stabilisce che ogni dato generato da un dispositivo debba necessariamente essere conservato per poter essere successivamente estratto. Il considerando 15 distingue inoltre i dati grezzi e pretrattati dalle informazioni ulteriormente dedotte o ricavate, escluse dall\u2019obbligo di messa a disposizione salvo diverso accordo.<\/p>\n\n\n\n

Il considerando 20 lo chiarisce espressamente: la disciplina non impone di memorizzare nell\u2019unit\u00e0 di calcolo centrale dati che il prodotto non prevede di archiviare o trasmettere al di fuori del componente in cui sono generati, n\u00e9 di trattare dati personali ulteriori rispetto a quelli necessari secondo il principio di minimizzazione del GDPR.<\/p>\n\n\n\n

\u00c8 una precisazione importante. Altrimenti l\u2019obbligo di rendere il dato accessibile rischierebbe, paradossalmente, di incentivare la produzione o la conservazione di informazioni che non vi sarebbe ragione di trattare.<\/p>\n\n\n\n

2. Accessibilit\u00e0 non significa apertura indiscriminata<\/strong><\/strong><\/h2>\n\n\n\n

Il dato accessibile resta inserito in una trama di altri interessi giuridicamente protetti. Il Data Act<\/em> non risolve questa compresenza stabilendo una prevalenza generalizzata dell\u2019accesso.<\/p>\n\n\n\n

Un primo limite emerge sul terreno della sicurezza. L\u2019art. 4, par. 2, consente all\u2019utente e al titolare dei dati di limitare o vietare contrattualmente l\u2019accesso, l\u2019uso o l\u2019ulteriore condivisione quando tali attivit\u00e0 possano compromettere requisiti di sicurezza del prodotto stabiliti dal diritto dell\u2019Unione o nazionale e determinare gravi conseguenze negative per la salute, l\u2019incolumit\u00e0 o la sicurezza delle persone fisiche. Non basta, quindi, invocare genericamente la cybersecurity<\/em> per sottrarsi all\u2019obbligo: la restrizione \u00e8 collegata a condizioni precise e, quando il titolare dei dati rifiuta la condivisione, deve comunicarlo all\u2019autorit\u00e0 competente.<\/p>\n\n\n\n

Una tensione analoga riguarda i segreti commerciali. Il Regolamento prevede misure tecniche e organizzative per proteggerne la riservatezza. La condivisione pu\u00f2 essere bloccata o sospesa quando manca un accordo su tali misure, quando non vengono rispettate o quando la riservatezza \u00e8 compromessa; soltanto in circostanze eccezionali pu\u00f2 essere rifiutata rispetto a specifici dati. Quest\u2019ultima possibilit\u00e0 richiede che il titolare dei dati, quando \u00e8 anche detentore del segreto commerciale, dimostri, sulla base di elementi oggettivi, l\u2019elevata probabilit\u00e0 di subire un grave danno economico nonostante le misure di protezione adottate.<\/p>\n\n\n\n

Il problema progettuale cambia cos\u00ec fisionomia. Non si tratta di costruire il sistema tecnicamente pi\u00f9 aperto possibile, bens\u00ec di rendere l\u2019accesso effettivo senza neutralizzare le altre tutele che l\u2019ordinamento continua a riconoscere.<\/p>\n\n\n\n

3. Se il dato \u00e8 personale, l\u2019utente pu\u00f2 non essere l\u2019interessato<\/strong><\/strong><\/h2>\n\n\n\n

Il rapporto con il GDPR rende ancora pi\u00f9 evidente la necessit\u00e0 di evitare letture automatiche.<\/p>\n\n\n\n

I dati prodotti dall\u2019uso di un oggetto connesso possono riferirsi all\u2019utente, ma anche ad altre persone. Una vettura utilizzata da pi\u00f9 conducenti, un dispositivo domestico condiviso o un sistema che registra informazioni relative a soggetti diversi da chi ha acquistato il prodotto mostrano immediatamente il problema.<\/p>\n\n\n\n

Il Data Act<\/em> non sostituisce la disciplina della protezione dei dati personali e non crea, da solo, una base giuridica per trattare dati riferiti a un altro interessato. Quando l\u2019utente non coincide con l\u2019interessato, l\u2019art. 4, par. 12, richiede una valida base giuridica ai sensi dell\u2019art. 6 GDPR e, quando pertinente, il rispetto delle condizioni dell\u2019art. 9 e della disciplina ePrivacy<\/em>. La medesima logica opera, ai sensi dell\u2019art. 5, par. 7, quando i dati vengono messi a disposizione di un terzo scelto dall\u2019utente.<\/p>\n\n\n\n

Qui l\u2019architettura di accesso deve compiere un lavoro meno visibile ma essenziale. Autenticare chi formula la richiesta, distinguere i dati ai quali pu\u00f2 legittimamente accedere, evitare che l\u2019esercizio del diritto di un soggetto comporti la divulgazione indebita di informazioni relative ad altri.<\/p>\n\n\n\n

Non \u00e8 difficile vedere come un accesso tecnicamente semplice possa essere giuridicamente mal progettato. La disponibilit\u00e0 immediata del dato, considerata isolatamente, non costituisce quindi una misura sufficiente della conformit\u00e0.<\/p>\n\n\n\n

4. Data Act<\/em> e cybersecurity<\/em>: due esigenze che arrivano nello stesso progetto<\/strong><\/strong><\/h2>\n\n\n\n

La data del 12 settembre 2026 presenta anche una coincidenza interessante. Dal giorno precedente, 11 settembre 2026, \u00e8 applicabile l\u2019art. 14 del Regolamento (UE) 2024\/2847, il Cyber Resilience Act<\/em> (CRA), relativo agli obblighi di segnalazione delle vulnerabilit\u00e0 attivamente sfruttate e degli incidenti gravi. Il CRA sar\u00e0 applicabile nel suo complesso dall\u201911 dicembre 2027; il legislatore ha anticipato, tra l\u2019altro, proprio il regime di reporting<\/em>.<\/p>\n\n\n\n

Il Laboratorio ha gi\u00e0 esaminato questo passaggio nell\u2019articolo Segnalare senza esporre. Il Cyber Resilience Act<\/em> e la nuova governance europea delle vulnerabilit\u00e0, pubblicato l\u201911 settembre 2026.<\/p>\n\n\n\n

La vicinanza temporale non deve essere caricata di un significato che i due regolamenti non le attribuiscono. Data Act<\/em> e CRA hanno oggetto, presupposti e ambiti applicativi differenti. Quando per\u00f2 le due discipline interessano il medesimo prodotto, finiscono inevitabilmente per incidere su alcune delle stesse decisioni progettuali, pur con tempi di applicazione diversi.<\/p>\n\n\n\n

Un\u2019interfaccia che consente di estrarre dati, un\u2019API, un sistema di autenticazione o un meccanismo di accesso remoto possono realizzare l\u2019obiettivo di rendere il dato effettivamente utilizzabile dall\u2019utente; possono anche aumentare, se progettati male, la superficie di attacco del prodotto. La sicurezza non interviene allora come limite esterno da applicare dopo avere soddisfatto il Data Act<\/em>. Fa parte del problema progettuale sin dall\u2019inizio.<\/p>\n\n\n\n

\u00c8 forse questo il punto nel quale la nuova soglia applicativa mostra meglio la propria rilevanza per l\u2019informatica giuridica. Norme diverse, portatrici di interessi diversi, convergono su un medesimo oggetto tecnico. La soluzione concreta non pu\u00f2 essere ricavata integralmente n\u00e9 dal testo normativo n\u00e9 dalla sola competenza ingegneristica.<\/p>\n\n\n\n

5. La conformit\u00e0 si sposta a monte<\/strong><\/strong><\/h2>\n\n\n\n

L\u2019art. 3, par. 1, non consegna ai fabbricanti e ai fornitori di servizi correlati un progetto tecnico gi\u00e0 definito dal legislatore. Rimangono spazi di valutazione: quali dati siano effettivamente interessati, quando l\u2019accesso diretto sia pertinente e tecnicamente possibile, quali modalit\u00e0 garantiscano la sicurezza, come debbano essere protetti dati personali e segreti commerciali.<\/p>\n\n\n\n

Ci\u00f2 che cambia dal 12 settembre 2026 \u00e8 il momento nel quale tali questioni devono essere affrontate.<\/p>\n\n\n\n

Una parte della conformit\u00e0 al Data Act<\/em> precede ormai l\u2019immissione del prodotto sul mercato. Questo spostamento a monte rende particolarmente evidente un fenomeno che attraversa una parte crescente della regolazione digitale europea: alcune garanzie giuridiche possono essere effettive soltanto se trovano una corrispondenza nell\u2019architettura tecnica.<\/p>\n\n\n\n

In questo senso \u2014 e soltanto in questo senso \u2014 parlare di data access by design<\/em> appare utile. Non perch\u00e9 il Data Act<\/em> abbia introdotto una nuova formula destinata ad affiancare il data protection by design<\/em> del GDPR, ma perch\u00e9 la disciplina mostra quanto il confine tra configurazione tecnica e conformit\u00e0 giuridica sia diventato difficile da tracciare.<\/p>\n\n\n\n

Il diritto di accedere a un dato pu\u00f2 essere riconosciuto dalla norma. La possibilit\u00e0 di esercitarlo, per\u00f2, dipende anche da ci\u00f2 che \u00e8 stato deciso molto prima della richiesta dell\u2019utente: quando quel prodotto era ancora un progetto.<\/p>\n\n\n\n

Fonti e riferimenti essenziali<\/strong><\/strong><\/h2>\n\n\n\n
    \n
  • Regolamento (UE) 2023\/2854 del Parlamento europeo e del Consiglio, del 13 dicembre 2023, riguardante norme armonizzate sull\u2019accesso equo ai dati e sul loro utilizzo e che modifica il regolamento (UE) 2017\/2394 e la direttiva (UE) 2020\/1828 (Data Act<\/em>), in particolare artt. 2, 3, 4, 5, 7 e 50 e considerando 15, 20, 31 e 34.<\/li>\n\n\n\n
  • Commissione europea, Frequently Asked Questions about the Data Act<\/em>, versione 1.4, 22 gennaio 2026.<\/li>\n\n\n\n
  • Regolamento (UE) 2024\/2847 del Parlamento europeo e del Consiglio, del 23 ottobre 2024, relativo a requisiti orizzontali di cibersicurezza per i prodotti con elementi digitali e che modifica i regolamenti (UE) n. 168\/2013 e (UE) 2019\/1020 e la direttiva (UE) 2020\/1828 (Cyber Resilience Act<\/em>), in particolare artt. 14 e 71.<\/li>\n\n\n\n
  • Regolamento (UE) 2016\/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonch\u00e9 alla libera circolazione di tali dati, e che abroga la direttiva 95\/46\/CE (GDPR), in particolare artt. 5, 6, 9 e 25.<\/li>\n\n\n\n
  • Direttiva 2002\/58\/CE del Parlamento europeo e del Consiglio, del 12 luglio 2002, relativa al trattamento dei dati personali e alla tutela della vita privata nel settore delle comunicazioni elettroniche, in particolare art. 5, par. 3.<\/li>\n\n\n\n
  • M. Farina, Segnalare senza esporre. Il Cyber Resilience Act<\/em> e la nuova governance europea delle vulnerabilit\u00e0, ICT4Law&Forensics, 11 settembre 2026.<\/li>\n<\/ul>\n\n\n\n

    Di Massimo Farina<\/strong>
     Professore Associato di Informatica Giuridica presso il Dipartimento di Ingegneria Elettrica e Elettronica (DIEE) dell\u2019Universit\u00e0 di Cagliari. Responsabile della protezione dei dati personali (RPD), ai sensi dell\u2019articolo 37 del Regolamento UE 2016\/679, dell\u2019Ateneo Cagliaritano e Coordinatore del \u201cICT4Law&Forensics Lab\u201d. Abilitato alle funzioni di Professore di prima fascia per il settore concorsuale 12 H3 (Filosofia del diritto \u2013 GIUR-17\/A ). Avvocato del Foro di Cagliari abilitato al patrocinio davanti alle Giurisdizioni Superiori.<\/p>\n\n\n\n

    <\/p>\n","protected":false},"excerpt":{"rendered":"

    Dal 12 settembre 2026 il Data Act ha raggiunto una nuova soglia applicativa. Il Regolamento (UE) 2023\/2854 si applica, nel suo impianto generale, gi\u00e0 dal 12 settembre 2025; l\u2019art. 50 ha per\u00f2 differito di un anno […]<\/p>\n","protected":false},"author":9973,"featured_media":1485,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_coblocks_attr":"","_coblocks_dimensions":"","_coblocks_responsive_height":"","_coblocks_accordion_ie_support":"","footnotes":""},"categories":[50],"tags":[173,175,71,169,177,171,62],"class_list":["post-1484","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-approfondimenti","tag-access-by-design","tag-accesso","tag-data","tag-data-act","tag-design","tag-eu","tag-governance"],"_links":{"self":[{"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/posts\/1484","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/users\/9973"}],"replies":[{"embeddable":true,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/comments?post=1484"}],"version-history":[{"count":1,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/posts\/1484\/revisions"}],"predecessor-version":[{"id":1486,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/posts\/1484\/revisions\/1486"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/media\/1485"}],"wp:attachment":[{"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/media?parent=1484"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/categories?post=1484"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/tags?post=1484"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}