Digital Omnibus: semplificazione del rulebook o nuovo sistema operativo della compliance?

1. Cosa il Digital Omnibus è, formalmente

Il pacchetto pubblicato il 19 novembre 2025 si articola in due proposte di regolamento distinte.

La prima, il Digital Omnibus, interviene su GDPR, ePrivacy, Data Act, NIS2 e DORA. Sul fronte dati, consolida la Data Governance Act, la direttiva Open Data e il regolamento sulla libera circolazione dei dati non personali all’interno del Data Act stesso, portando il quadro normativo sui dati da cinque atti applicabili a due (GDPR e Data Act). Sul fronte cybersicurezza, introduce un Single-Entry Point per le notifiche di incidente — gestito da ENISA — che accorpa gli obblighi di segnalazione oggi dispersi tra NIS2, DORA, eIDAS, CER e violazioni di dati personali ai sensi del GDPR, secondo una logica di "report once, share many", operativo 18 mesi dopo l’entrata in vigore (estendibili a 24 se la piattaforma non supera i requisiti di integrità e affidabilità).

La seconda proposta, il Digital Omnibus on AI — la denominazione usata dalla Commissione stessa per distinguerla dalla proposta più ampia sul digital rulebook — interviene sull’AI Act: rinvia alcuni obblighi per i sistemi ad alto rischio, rivede l’impianto dell’Art. 6(3) sull’auto-valutazione e tocca gli obblighi di registrazione connessi alle esenzioni — materia già discussa in un altro articolo a proposito del job matching e del Modello 231.

Le due proposte procedono a velocità diverse.

Il negoziato sull’AI Act ha già raggiunto, nel maggio 2026, un accordo politico tra Consiglio e Parlamento sulla semplificazione delle regole mentre quello su GDPR, ePrivacy e dati è invece ancora aperto: EDPB ed EDPS hanno pubblicato a gennaio 2026 il Joint Opinion 1/2026 sul Digital Omnibus on AI e, successivamente, il Joint Opinion 2/2026 sulla componente dati, con posizioni critiche nette, in particolare sulla proposta di modifica della definizione di dato personale.

Restano due proposte distinte — non due nomi per lo stesso testo — collocate dentro un’unica strategia dichiarata di semplificazione del "digital rulebook": è questa cornice comune, non una fusione dei testi, a giustificarne una lettura congiunta.

Fin qui, i fatti.

Non serve altro per inquadrare il pacchetto: è una semplificazione tecnica di un insieme di norme che restano, formalmente, distinte l’una dall’altra.

2. Perché non è (solo) semplificazione

Se il Digital Omnibus fosse soltanto un insieme di emendamenti tecnici — come lo definisce l’Explanatory Memorandum della Commissione, che parla di "sollievo immediato" per le imprese e di rimozione di regole obsolete, senza toccare gli obiettivi di fondo delle normative — l’articolo potrebbe fermarsi qui.

La lettura minimalista ha argomenti solidi: la Commissione stessa parla di targeted simplification e di riduzione delle sovrapposizioni, non di una nuova architettura della compliance.

Il pacchetto è presentato, e in parte è davvero, una riduzione di oneri amministrativi, non una rifondazione del diritto digitale europeo.

Tre elementi, però, la complicano senza smentirla.

Primo: il linguaggio con cui la Commissione stessa motiva le proposte.

La valutazione d’impatto non ragiona più norma per norma, ma parla esplicitamente di "digital rulebook", di "digital acquis" e di impatto cumulativo delle regole digitali sulle imprese. Chiamiamo questo, per precisione, interoperabilità operativa, distinta dalla convergenza normativa in senso proprio: le norme restano formalmente autonome, ma la valutazione della Commissione le tratta sempre più spesso come un unico corpus che grava sugli stessi processi.

Secondo: il Single-Entry Point è un indizio forte, non la prova di una fusione sostanziale delle norme.

Il meccanismo unifica il canale di notifica; la Commissione stessa chiarisce che non modifica gli obblighi di reporting esistenti, le soglie né le autorità destinatarie di ciascun regime. Quello che dimostra è che gli stessi eventi aziendali — un incidente di sicurezza, una violazione di dati — possono attivare più regimi di notifica insieme: una convergenza dei fatti aziendali, non ancora delle norme che li disciplinano.

Terzo — ed è la tensione più interessante, perché va contro la tesi appena esposta invece di confermarla, e merita di essere trattata come contro-tesi, non come semplice lettura alternativa: chi si oppone con più forza al pacchetto non lo legge affatto come "semplice riduzione di burocrazia".

EDPB ed EDPS, nel Joint Opinion 2/2026, sostengono che la proposta di restringere la definizione di dato personale (modifica dell’Art. 4(1) GDPR) vada "ben oltre un emendamento mirato o tecnico" e rischi di incidere sul diritto fondamentale alla protezione dei dati: per le due autorità, il punto centrale del pacchetto non è la governance organizzativa su cui si concentra questo articolo, ma il rischio di un arretramento sostanziale delle tutele; una tesi che qui non viene trattata come secondaria, ma come lettura concorrente, valida a prescindere dall’esito del negoziato.

Su un piano di advocacy, con una posizione più netta e non equiparabile per peso istituzionale a quella di EDPB, EDPS o Commissione, noyb — nella sua analisi del pacchetto pubblicata a novembre 2025 — lo ha definito "il più grande attacco ai diritti digitali degli europei degli ultimi anni".

Il punto non è schierarsi, ma osservare il paradosso: la Commissione minimizza la portata sistemica del pacchetto per giustificarne la rapidità di approvazione; chi lo contesta la massimizza per giustificarne l’opposizione.

I due livelli — quello degli obiettivi dichiarati della norma e quello dei processi aziendali che la norma finisce per attraversare — restano distinti: nessuna delle due letture istituzionali esaurisce da sola l’impatto organizzativo su cui questo articolo si concentra, e che si colloca deliberatamente su quel secondo livello, senza pretendere di risolvere il primo.

C’è infine un’ironia strutturale che indebolisce la metafora più comoda del "sistema operativo unico": la riforma pensata per superare la logica dei silos normativi è essa stessa organizzata in due proposte separate, con due iter legislativi e due tempistiche politiche autonome.

Distinguere i piani evita un equivoco ricorrente: il pacchetto produce soprattutto semplificazione procedurale e qualche apertura di interoperabilità operativa; non produce, di per sé, convergenza normativa né integrazione organizzativa.

Quest’ultima resta un compito delle imprese, non del legislatore.

3. Il dato come nuova soglia della compliance

Se il livello dell’atto giuridico smette di essere l’unità di analisi rilevante, quale prende il suo posto?

I materiali raccolti per questo articolo convergono su una risposta parziale, non esaustiva: il dato, seguito lungo il suo intero ciclo di vita, è l’unità narrativa più utile per raccontare la sovrapposizione, non l’unico criterio giuridico rilevante.

Ruolo dell’operatore, finalità, settore, funzione del sistema e resilienza restano criteri autonomi che una lettura centrata sul dato non esaurisce.

Il primo indizio viene dalla sentenza della Corte di Giustizia UE C-413/23 P (EDPS contro SRB, 4 settembre 2025).

Il caso riguardava commenti raccolti dall’SRB, pseudonimizzati e trasmessi a Deloitte per una valutazione; l’EDPS aveva contestato all’SRB di non aver informato gli interessati di quella trasmissione.

Il Tribunale UE aveva annullato la decisione dell’EDPS, ritenendo che si dovesse valutare se, dal punto di vista di Deloitte, i dati pseudonimizzati fossero identificabili.

La Corte di Giustizia ha cassato quella sentenza: per l’obbligo informativo del titolare originario, la prospettiva rilevante è quella del titolare stesso al momento della raccolta, non quella del destinatario a valle — l’obbligo dell’SRB di informare gli interessati sussisteva a prescindere dal fatto che, per Deloitte, i dati fossero o meno identificabili dopo la pseudonimizzazione.

Il punto per questo articolo non è la relatività della pseudonimizzazione, che la Corte pure conferma in linea di principio — i dati pseudonimizzati non sono personali "in tutti i casi e per ogni persona" —, ma il cuore effettivo della sentenza: quella relatività non spezza la responsabilità del titolare originario né cancella retroattivamente i suoi obblighi di informazione e accountability.

Trasferire un dato pseudonimizzato a un fornitore non basta a scaricare su di esso la responsabilità di ciò che accade al dato a monte.

Il Digital Omnibus propone di intervenire sull’Art. 4(1) GDPR anche per la qualificazione del dato presso i destinatari successivi — un piano distinto da quello degli obblighi del titolare originario appena descritto; EDPB ed EDPS non lo leggono come una semplice stabilizzazione della giurisprudenza, ma come un tentativo di andare oltre la casistica della Corte, restringendo la nozione di dato personale.

Anche a prescindere dall’esito di quella modifica legislativa, il principio della C-413/23 P resta un punto di riferimento utile: la responsabilità di un titolare per il proprio trattamento non si esaurisce guardando a valle a ciò che un destinatario può o non può fare con il dato.

Il secondo indizio riguarda l’addestramento dei modelli.

L’EDPB, nell’Opinion 28/2024 (dicembre 2024), ha ammesso che il legittimo interesse (Art. 6.1.f GDPR) può costituire base giuridica per l’addestramento di modelli di AI generativa, ma solo a valle di un test in tre fasi:

• un interesse lecito, chiaramente e precisamente definito, reale e attuale e non speculativo;
• la necessità del trattamento rispetto a quell’interesse;
• un bilanciamento con i diritti e le libertà degli interessati.

Il Digital Omnibus, con la disposizione nota come Art. 88c, introduce un legittimo interesse esplicito per lo sviluppo e l’operatività di sistemi AI, comprensivo di raccolta, addestramento e fine-tuning ed esteso anche a categorie particolari di dati ex Art. 9(2)(k), con salvaguardie generiche.

La distanza tra i due approcci va misurata con cautela: EDPB ed EDPS, nel Joint Opinion 2/2026, contestano la necessità stessa di una disposizione ad hoc, ricordando che il legittimo interesse resta comunque soggetto al test in tre fasi appena descritto; la Commissione, dal canto suo, precisa che il trattamento per finalità di AI deve rispettare tutti i requisiti del GDPR.

Il rischio non è quindi un automatismo giuridico certo, ma interpretativo: che l’Art. 88c venga letto, nella prassi, come una legittimazione ex ante di un’intera classe di trattamenti anziché come una cornice che rinvia comunque a una valutazione caso per caso.

A quest’ultima domanda l’EDPB dà una risposta scomoda, anche se non automatica: se i dati personali restano incorporati in un modello, un trattamento illecito a monte — uno scraping senza base giuridica, ad esempio — può, in determinati scenari, inficiare la liceità dell’utilizzo successivo del modello.

L’EDPB colloca la cancellazione del dataset o del modello tra i poteri correttivi discrezionali delle autorità di controllo, non tra le conseguenze automatiche dell’illecito: una misura possibile e proporzionata al caso, da valutare insieme ad alternative meno drastiche, non un esito scontato.

Un modello addestrato con dati personali, per l’EDPB, non è anonimo per definizione: lo è solo se è altamente improbabile che quei dati possano essere estratti o inferiti tramite interrogazioni.

Resta comunque il punto in cui la tesi di questo articolo trova la conferma più diretta: valutare la conformità di un sistema guardando solo alla fase in cui viene utilizzato è insufficiente, perché il vizio di una fase — la raccolta — può riflettersi sulle fasi successive anche a distanza di tempo.

È lo stesso meccanismo già descritto in questa sede a proposito della compliance a estrazione manuale nel reporting CSRD e REACH: il problema non è mai il singolo output, ma l’infrastruttura di dati che lo produce.

4. AI Act e GDPR: non due binari, ma un incrocio

Il punto più operativo di questo articolo è anche il più semplice da enunciare e il più difficile da governare: un sistema può non essere high-risk ai sensi dell’AI Act e restare comunque problematico ai sensi del GDPR. Le due valutazioni non sono in sequenza. Sono in parallelo, e a tratti si sovrappongono senza coincidere.

Il caso già discusso in questa sede a proposito del job matching resta l’esempio più chiaro.

Un sistema di pre-screening dei CV può legittimamente qualificarsi come "compito preparatorio" ai sensi dell’Art. 6(3) dell’AI Act, se la decisione finale resta umana.

Ma se quello stesso sistema assegna punteggi di compatibilità basati su inferenze o su caratteristiche personali — non su un semplice conteggio di parole chiave — sta probabilmente effettuando profilazione ai sensi dell’Art. 4(4) GDPR, con le tutele dell’Art. 22 GDPR che si attivano a prescindere dalla classificazione ottenuta sotto l’AI Act.

L’esenzione da una norma non è un’uscita dal perimetro regolatorio complessivo: è, al più, un’uscita da una delle due strade che si incrociano sullo stesso processo.

Questo incrocio è reso ancora più stretto dalla convergenza — non parallelismo, intersezione — tra DPIA (Art. 35 GDPR) e FRIA (Art. 27 AI Act).

Vale la precisazione: la FRIA non è obbligatoria per tutti i sistemi AI né per tutti i deployer, ma solo per specifiche categorie di deployer di sistemi high-risk — tipicamente enti pubblici o soggetti che erogano servizi essenziali.

Dove entrambe si applicano, condividono in parte l’oggetto — il trattamento di dati personali — ma non la tassonomia del rischio: la FRIA guarda la non discriminazione, l’accesso alla giustizia, gli effetti su categorie vulnerabili, mentre la DPIA resta ancorata a minimizzazione e proporzionalità.

Condotte da funzioni diverse, con calendari diversi e senza un punto di raccordo esplicito, le due valutazioni rischiano di produrre conclusioni non coordinate sullo stesso sistema o, peggio, contraddittorie.

Su questo punto, la direzione presa dal negoziato sull’AI Act aggiunge un elemento di frizione, non di sollievo.

Nel Joint Opinion 1/2026, EDPB ed EDPS si sono opposti alla proposta di eliminare l’obbligo di registrazione per i provider che, in base a un’auto-valutazione ex Art. 6(3), concludono che il proprio sistema non è ad alto rischio: l’eliminazione ridurrebbe la tracciabilità esterna del processo di classificazione e la capacità di intervento tempestivo delle autorità di vigilanza.

Se confermata, il punto di intersezione tra AI Act e GDPR diventerebbe meno visibile dall’esterno proprio nel momento in cui, per governarlo, servirebbe più visibilità, non meno.

5. L’impatto organizzativo: chi possiede il rischio?

La domanda che circola nelle aziende — "chi deve occuparsi del Digital Omnibus, il DPO, il Compliance Officer, l’OdV, il CTO o il CISO?" — è mal posta.

Non è un problema di attribuzione di una delega, ma di progettazione di un modello in cui funzioni diverse leggano lo stesso rischio da angolazioni diverse, senza che nessuna resti isolata dalle altre.

Il Single-Entry Point rende visibile questo problema più di quanto lo risolva.

Il meccanismo standardizza il canale di uscita verso le autorità, ma la Commissione è esplicita: non modifica "i requisiti giuridici sottostanti" — termini di notifica, soglie, contenuto informativo restano diversi tra NIS2, GDPR, DORA, eIDAS e CER.

Va detto con precisione, perché è facile darlo per scontato: un incidente NIS2 non è automaticamente un data breach GDPR; un data breach GDPR non è automaticamente un evento rilevante ai sensi di DORA; un malfunzionamento di un sistema AI non rientra automaticamente nel perimetro dell’AI Act.

Il punto non è che questi eventi coincidano sempre, ma che quando si sovrappongono — un’evenienza tutt’altro che rara per un incidente che coinvolge dati personali trattati da un sistema AI — l’azienda deve produrre più qualificazioni in parallelo, con il CISO che legge l’evento secondo NIS2, il DPO secondo il GDPR e il Compliance Officer secondo l’AI Act, ciascuno con la propria finestra temporale e i propri criteri di materialità, a partire dalla stessa base fattuale.

Il punto di ingresso è unico; il lavoro di ricostruzione a monte, per ora, resta frammentato quanto prima.

Un CISO o un DPO pragmatici potrebbero leggere questo stesso punto come la conferma che il Single-Entry Point non produce alcuna integrazione reale: sposta solo, dalle autorità alle imprese, il costo di coordinare regimi che restano distinti — un portale in più, non un cambio di paradigma.

È una contro-tesi che questo articolo non liquida: la assume, anzi, come punto di partenza del blocco successivo.

Se l’integrazione non arriva dal legislatore, l’alternativa non è aspettarla: è costruirla internamente, perché il costo di coordinamento — spostato o no — resta comunque a carico di chi deve rispondere dell’evento. Senza un proprietario interno capace di assemblare un’unica narrazione coerente prima che l’evento raggiunga il canale unico, quel canale rischia di diventare un imbuto che riceve informazioni scoordinate da fonti diverse, invece di un presidio di governance.

Le linee guida del CNDCEC per gli Organismi di Vigilanza (Allegato 6) vanno nella stessa direzione da un altro angolo: chiedono all’OdV di valutare congiuntamente intelligenza artificiale e cybersicurezza, verificando l’interazione tra GDPR, normativa cyber (NIS2, DORA) e AI Act, per prevenire la "colpa d’organizzazione".

È una richiesta coerente con quanto già emerso a proposito dell’Art. 6(3), ma va formulata con prudenza: non ogni difetto di compliance digitale genera automaticamente una colpa d’organizzazione ai sensi del D.Lgs. 231/01, che dipende da elementi propri del singolo caso — reato presupposto, modello adottato, elusione fraudolenta dei presidi, vantaggio o interesse dell’ente.

Quando però il self-assessment su una singola norma diventa l’unico presidio attivato — senza flussi verso l’OdV, senza trigger che colleghino le modifiche di un sistema al riesame delle valutazioni collegate — l’assenza di quei presidi pesa nella valutazione complessiva come indice di inadeguatezza organizzativa, accanto agli altri elementi che il singolo caso richiede.

Va detto con la stessa prudenza che questo non equivale a sostenere che serva un’unica funzione che "possieda" tutto. Un modello in cui DPO, Compliance, CTO/CISO, OdV e procurement si limitano a duplicare gli stessi controlli non riduce il rischio: lo nasconde dietro un costo più alto.

Il problema resta di interfaccia, non di accentramento.

6. L’implicazione manageriale: da checklist a infrastruttura

La compliance digitale non può più essere trattata come una somma di pareri legali, informative, checklist e vendor assessment prodotti e archiviati separatamente.

Deve diventare un’infrastruttura: mappa dei dati, ruoli, basi giuridiche, fornitori, valutazioni d’impatto, incident reporting, accountability e tracciabilità delle decisioni collegati tra loro.

Questo non significa lo stesso modello per tutti: significa un presidio proporzionato alla complessità dei dati trattati, dei sistemi utilizzati, dei fornitori coinvolti e dei regimi applicabili — un’impresa a basso rischio, con pochi fornitori e sistemi non critici, può presidiare questa integrazione con strumenti molto più leggeri di quelli di un gruppo bancario o di un ospedale.

È la stessa tesi già argomentata a proposito del reporting CSRD e REACH: i report falliscono non perché scritti male, ma perché i dati che li alimentano sono dispersi e non riusabili da un ciclo all’altro.

Il Digital Omnibus estende quella logica dal reporting di sostenibilità all’intero perimetro della compliance digitale.

Non che il GDPR, preso da solo, non ponga già domande su base giuridica, finalità, minimizzazione o destinatari: le pone.

Ma nessuna norma, presa singolarmente, è costruita per chiedere se lo stesso dato, lungo l’intero percorso, resti coerente con basi giuridiche, finalità e classificazioni di rischio diverse che si applicano nello stesso momento: dove risiede questo dato, chi lo ha reso disponibile ed è stato usato per addestrare un sistema il cui output oggi incide su una persona reale?

L’immagine del "sistema operativo aziendale" resta utile come angolo manageriale, non come conclusione giuridica, ma va corretta per non attribuire alla Commissione un’intenzione più forte di quella che i fatti raccontano: non è la Commissione ad aver riscritto l’architettura delle imprese europee.

È l’effetto combinato di SEP, consolidamento degli atti sui dati, convergenza DPIA-FRIA e centralità del deployer a rendere sempre meno sostenibile continuare a "installare" AI Act, GDPR, Data Act e NIS2 come applicazioni indipendenti sopra un’organizzazione pensata per silos.

Le imprese che scelgono di investire per prime in questa architettura interna — non perché la norma lo impone esplicitamente, ma perché è l’unico modo per rispondere in modo coerente a più regimi che insistono sugli stessi processi — non fanno necessariamente la scelta più economica nel breve periodo: integrare compliance che prima viaggiavano separate può aumentare, all’inizio, costi, tempi di decisione e attriti tra funzioni abituate a lavorare per conto proprio.

Hanno però una buona ragione manageriale, più che una garanzia dimostrata, per attendersi di ridurre, nel tempo, il rischio di dover ricostruire ex post, a ogni ciclo di audit, un’evidenza che un’infrastruttura ben progettata avrebbe già prodotto.

C’è infine un effetto rete che spesso sfugge nella lettura interna dell’azienda: la conformità di un’impresa dipende dalla postura di conformità dei suoi fornitori.

Il principio della C-413/23 P sulla responsabilità del titolare, quella del deployer per sistemi sviluppati da terzi, la necessità di dimostrare l’anonimizzazione effettiva di un modello acquistato da un vendor: in tutti questi casi, il rischio dell’azienda supera il perimetro dei suoi sistemi e si estende alla catena del valore digitale.

Il procurement non diventa, con il Digital Omnibus, uno strumento di compliance, lo era già.

Diventa però il luogo dove si giocano clausole prima marginali: provenienza e base giuridica dei dati di addestramento del vendor AI, diritti di audit sul modello, obblighi di notifica in caso di modifica sostanziale, documentazione tecnica opponibile in caso di contestazione.

Conclusioni: meno adempimenti, non meno responsabilità

Il nodo di tensione che attraversa questo articolo va lasciato aperto, non risolto in favore della tesi: l’Europa dichiara di voler semplificare il digital rulebook, ma la semplificazione normativa, per essere gestita in modo affidabile, richiede alle imprese una governance più sofisticata, non più semplice.

Non è detto che questo sia un esito voluto dal legislatore — l’Explanatory Memorandum della Commissione parla esplicitamente di sollievo amministrativo, non di riprogettazione organizzativa.

Ma è l’esito con cui le imprese, in pratica, devono fare i conti, indipendentemente dalle intenzioni dichiarate.

Chi legge il Digital Omnibus solo come "meno carta da compilare" rischia di ripetere, su scala più ampia, lo stesso errore già diagnosticato a proposito delle esenzioni Art. 6(3): scambiare l’esenzione da un singolo obbligo per un’uscita dal sistema.

Meno adempimenti non significa meno responsabilità.

Significa, più precisamente, meno alibi: meno margine per giustificare, con la conformità a una norma isolata, un trattamento che un’altra norma — o la stessa norma letta insieme alle altre — continua a rendere problematico.

La versione più difendibile della tesi di questo articolo non è che il Digital Omnibus sia il nuovo sistema operativo della compliance. È più modesta: il Digital Omnibus non crea un sistema operativo unico della compliance, ma rende sempre meno sostenibile gestire AI Act, GDPR, Data Act, NIS2 e DORA come applicazioni isolate dentro organizzazioni ancora costruite per silos.

La semplificazione promessa dalla Commissione funziona, per le imprese, solo a valle di una condizione che nessuna norma può imporre per decreto: cambiare l’architettura interna con cui l’azienda governa dati, sistemi e responsabilità.