Si tratta di un avvertimento ex art. 58, par. 2, lett. a) del GDPR, ossia uno strumento prognostico che segnala un rischio di violazione futura. Dal caso possono ricavarsi due diversi — seppur in parte sovrapponibili — profili di interesse per le aziende, e in particolare sia per chi sviluppa software destinati ad interagire e trattare dati dei dipendenti di terzi sia per chi li acquista per utilizzarli verso i propri dipendenti.

Chi sviluppa: oneri e responsabilità

La Società, qualificatasi come titolare del trattamento dei dati degli utenti del servizio, riveste tale ruolo a prescindere dalla modalità di vendita ed erogazione del servizio. Il Garante ne ricava un messaggio per chi questi sistemi li progetta: la conformità dipende anche e soprattutto dalle scelte fatte in fase di sviluppo (Considerando 78 del GDPR). In concreto significa due cose:

1. definire correttamente i c.d. ruoli privacy, costruendo il servizio in modo che il fornitore resti l’unico titolare e che al datore di lavoro sia tecnicamente precluso l’accesso a tali tipologie di dati;

2. rinunciare alle funzioni prive di base giuridica o in contrasto con le norme di settore: qui, il riferimento è proprio alla funzione che fornisce al datore il report sullo stress dei propri dipendenti. Il Garante sottolinea che nella stessa direzione va anche l’art. 5 dell’AI Act sulle pratiche vietate, già in vigore, il quale vieta l’utilizzo di sistemi di IA che possano inferire le emozioni sul luogo di lavoro.

Chi adotta: limiti e obblighi

In linea di principio, acquistare un servizio per i propri dipendenti, senza ricevere alcun dato, è lecito e neutro: vale la logica dei contratti a favore di terzo (art. 1411 c.c.) con cui si attiva, ad esempio, una polizza sanitaria.

Il problema nasce quando, come potenzialmente nel caso in esame, il datore adotta strumenti che raccolgono informazioni personali e invasive sui propri dipendenti, come ad esempio un report sui livelli di stress. Le informazioni sulla sfera emotiva dei dipendenti rientrano nell’art. 113 del Codice Privacy, che rinvia allo Statuto dei lavoratori (e nello specifico all’art. 8 della L. 300/1970): la loro conoscibilità da parte del datore è preclusa, con una violazione per di più penalmente sanzionata (art. 171 del Codice Privacy).

Perché neanche il dato aggregato è sicuro

Si potrebbe pensare che, ricevendo solo un report aggregato, pseudonimizzato e generato con un numero considerevole di utenti attivi, il datore sia al riparo da queste contestazioni. Il Garante, però, la pensa diversamente. Pur dando atto che, nell’unico caso concreto, l’azienda destinataria non poteva re-identificare i propri dipendenti, l’Autorità ritiene impossibile escludere che, in futuro, un datore che richieda quel report risalga all’identità dei propri lavoratori, soprattutto nelle realtà piccole o con personale poco numeroso e caratterizzato.

In quei contesti l’aggregazione, da sola, non è misura sufficiente a impedire la re-identificazione per inferenza, e la sola trasmissione del report può verosimilmente integrare una violazione del quadro a tutela della dignità di chi lavora (artt. 5, 6, 9, 24, 25 e 88 del GDPR, 2-ter e 113 del Codice Privacy). Da qui l’avvertimento: la Società deve impedire qualsiasi forma di messa a disposizione di quei dati, anche indiretta o via report, in favore dei datori di lavoro.

Implicazioni pratiche

Per le aziende che sviluppano tecnologia, è bene tenere a mente che progettare un servizio in un’ottica di privacy by design include la rinuncia a funzioni che, pur tecnicamente possibili e magari appetibili sul mercato, espongono il provider stesso e il cliente-datore a un rischio significativo sotto il versante data protection e giuslavoristico.

Per le aziende che adottano la tecnologia, prima di acquistare un servizio o strumento che comporti una raccolta di dati dei propri dipendenti, specie se particolarmente invasivi o afferenti emozioni o stati d’animo nel contesto lavorativo, è necessaria una valutazione preventiva che tenga conto del GDPR, della normativa giuslavoristica e dell’AI Act. E questo vale anche quando i dipendenti attivano il servizio volontariamente e la finalità dichiarata è il benessere interno.

"Le informazioni riguardanti la sfera emotiva dei dipendenti costituiscono informazioni la cui conoscibilità è preclusa al datore di lavoro" - Garante per la protezione dei dati personali, provvedimento n. 342 del 14 maggio 2026

Fissa un momento di confronto con me

Il 17 aprile 2026 il Garante privacy ha adottato le linee guida italiane sull’uso dei tracking pixel nelle comunicazioni di posta elettronica. Il provvedimento n. 284, firmato dal presidente Stanzione, è in corso di pubblicazione in Gazzetta Ufficiale: da quel momento decorrono sei mesi per adeguarsi.

Contesto di riferimento e finalità perseguite

Tra la fine del 2025 e l’inizio del 2026, l’Autorità ha condotto una serie di accertamenti ispettivi, di carattere conoscitivo, rispettivamente presso provider di servizi di posta elettronica ed un fornitore di piattaforma cd. di marketing automation per la gestione professionale del servizio di inoltro comunicazioni di posta elettronica per conto di committenti. All’esito di tale attività ispettiva è stato possibile accertare, tra l’altro, che i tracking pixel vengono utilizzati pressoché nella totalità dei casi, sebbene per il conseguimento di molteplici scopi diversi: garantire la corretta ricezione delle e-mail (cd. deliverability), contrastare lo spam, misurare l’audience e le performance della comunicazione (intesa come apertura o lettura delle e-mail o download di allegati), ed anche per identificare attività di phishing o anche per esigenze di formattazione. Il loro impiego può quindi riguardare tanto le comunicazioni di tipo commerciale e promozionale quanto quelle più propriamente di servizio o a carattere istituzionale e informativo.

Cosa sono i tracking pixel

Un tracking pixel è un’immagine trasparente, grande un solo pixel, inserita nel corpo di una email. Nel momento in cui apri il messaggio, quell’immagine viene scaricata dal server del mittente, che in quel momento acquisisce informazioni quali: la conferma dell’apertura, l’indirizzo IP del destinatario, il tipo di dispositivo, i tempi e il numero di riaperture successive. Il meccanismo scatta solo se hai abilitato il download automatico delle immagini nel tuo client di posta. Qualora, invece, l’utente imposti la funzione di lettura dell’e-mail esclusivamente in formato testo, il tracking pixel, al pari di qualsiasi altra immagine, non sarà scaricato e dunque non potrà tracciare il comportamento del destinatario della comunicazione.

Il quadro normativo

Il Garante inquadra i tracking pixel nell’art. 122 del Codice Privacy, la norma che recepisce la direttiva e-Privacy e regola l’accesso al terminale dell’utente. La logica è la stessa dei cookie: inserire un elemento nel dispositivo di qualcuno, e poi leggerne le informazioni, è un’operazione che richiede consenso preventivo, salvo eccezioni. Le linee guida in oggetto confermano l’impostazione già espressa dall’EDPB nelle Linee Guida 2/2023 sull’art. 5, par. 3 della direttiva e-Privacy: i pixel rientrano in pieno in quella fattispecie, con piena applicabilità del Regolamento per gli aspetti non coperti dalla direttiva.

La novità più rilevante: il regime del consenso preventivo e dell’opt-out

Il caso tipico in cui è necessario richiedere un consenso all’utente sono le attività di DEM (Direct Email Marketing), specie laddove si misuri il tasso di apertura individuale per ottimizzare le campagne e profilare preferenze. In questi contesti, il Garante chiarisce che il consenso al tracciamento può essere incorporato nel consenso più generale alla ricezione delle comunicazioni promozionali, a condizione che la richiesta sia formulata in modo neutro, senza pressioni, e che l’informativa espliciti chiaramente l’uso dei pixel. Il consenso dovrà essere raccolto preferibilmente al momento stesso dell’acquisizione dell’indirizzo di posta elettronica in questione, dopo che - in ossequio alle regole di carattere generale - l’interessato sia stato debitamente informato. Sul piano operativo questo significa che il titolare che raccoglie il consenso al tracciamento via pixel deve tenere un registro delle preferenze espresse da ciascun utente, con timestamp, versione dell’informativa mostrata al momento della raccolta, e traccia delle eventuali revoche successive (comprese quelle granulari). È infatti necessario che l’utente che abbia acconsentito al trattamento possa successivamente revocare in modo agevole le scelte pregresse, anche in modo granulare: optando cioè per la revoca del consenso unico prestato, con l’effetto di impedire la futura ricezione di ulteriori messaggi, oppure revocandolo solo parzialmente, con esclusivo riferimento al tracciamento connesso alla ricezione di tracking pixel.

La richiesta di consenso potrebbe essere formulata come segue: “Acconsento a ricevere comunicazioni promozionali da [Azienda] via email. Le email potranno contenere pixel di tracciamento che rilevano l’apertura del messaggio e informazioni tecniche associate (indirizzo IP, dispositivo, orario). Puoi revocare questo consenso in qualsiasi momento, anche solo per il tracciamento. [Leggi l’informativa completa]“

Le eccezioni al consenso

Il provvedimento individua tre categorie di casi in cui il consenso non è, di norma, richiesto:

• Analisi statistiche aggregate: se il pixel è il medesimo per tutti i destinatari di una campagna - e non univoco per singolo utente - e risulti funzionale all’effettuazione di un conteggio di tipo statistico che misuri la percentuale globale di apertura dei messaggi, utilizzato anche al fine di migliorare la deliverability delle e-mail, come pure per contrastare fenomeni di spam;

• Misure di sicurezza: quando il pixel serve ad implementare misure di sicurezza che interessano il processo di autenticazione dell’utente, il reset password, la risposta a un esercizio di diritti, etc. - sia pure riferito al terminale riconducibile ad un singolo utente - il trattamento risulta giustificato dall’esigenza di sicurezza e di fornitura del servizio richiesto;

• Comunicazioni istituzionali o di servizio con obbligo giuridico di invio: laddove il pixel sia contenuto in messaggi istituzionali contenenti indicazioni utili su come prevenire azioni di phishing o frodi rispetto a minacce contingenti, modifiche contrattuali, scadenze contributive, campagne istituzionali, comunicazioni relative a incidenti di sicurezza. In questi casi l’interesse alla presa di conoscenza effettiva del destinatario è ritenuto prevalente e scisso dal presupposto di liceità del preventivo consenso dell’utente.

Chi deve raccogliere il consenso: piattaforme o aziende?

Questa è la domanda operativa più rilevante e la risposta dipende da chi decide se usare i pixel e per quale finalità. Come sempre, il ruolo va definito caso per caso in base al principio di accountability, con possibile applicazione dell’art. 26 del GDPR sulla contitolarità. Nel caso di piattaforme che mettono a disposizione il pixel come funzionalità tecnica, l’azienda cliente è responsabile dell’attivazione, selezionando per quale campagna, con quale finalità utilizzare lo strumento. In questo modello la piattaforma agisce tendenzialmente come responsabile del trattamento ex art. 28 del GDPR, mentre l’azienda cliente in qualità di titolare del trattamento, dovendo conseguentemente raccogliere e gestire la richiesta di consenso verso l’utente. Diverso è il caso, ad esempio, di chi non usa una propria lista ma “noleggia” liste di contatti da un provider che invia messaggi informativi o promozionali per conto del committente. Qui il provider gestisce direttamente l’invio ai destinatari e il conseguente tracciamento e dovrebbe aver raccolto un consenso a monte dall’utente - anche per quanto attiene all’utilizzo dei pixel. Ciò, fermo restando che la qualifica dei ruoli rilevanti ai fini della normativa data protection dovrà essere definita caso per caso in base al flusso sostanziale del trattamento e agli accordi negoziali intercorrenti tra le parti, anche con eventuale applicazione dell'art. 26 GDPR in materia di contitolarità.

I prossimi passi? Mappare i flussi email in uso e verificare se e dove sono presenti pixel di tracciamento. Per ciascuno, sarà da verificare se si rientra in una delle deroghe o se, invece, sia necessario richiedere un consenso all’utente. Bisognerà conseguentemente aggiornare l’informativa privacy con un riferimento esplicito ai pixel e alle finalità del loro utilizzo e implementare il meccanismo di revoca granulare, verificando con i fornitori delle piattaforme (Mailchimp, Brevo, HubSpot, etc.) se e quando rilasceranno le funzionalità necessarie sotto un profilo tecnico.

Prenota un momento di confronto

L’EDPB (European Data Protection Board) ha pubblicato il 10 marzo 2026 il proprio modello ufficiale di DPIA (Data Protection Impact Assessment), accompagnato da un documento esplicativo (explainer) che ne chiarisce la logica compilativa. Il pacchetto è aperto a consultazione pubblica fino al 9 giugno 2026.

Si tratta di una risposta a un problema reale legata a questo adempimento così centrale nell’ecosistema di compliance data protection di ciascuna organizzazione: la frammentazione metodologica. Ogni organizzazione, ogni consulente, ogni autorità di controllo nazionale ha finora lavorato con strumenti propri. Il template dell’EDPB punta a definire un minimo comune denominatore europeo, accettato da tutte le Autorità di controllo, che riduca l’incertezza applicativa senza precludere alle organizzazioni di utilizzare la metodologia di risk management che preferiscono.

Le organizzazioni rimangono infatti libere di condurre la propria DPIA con gli strumenti che preferiscono - ISO 31000, EBIOS RM, il tool PIA della CNIL, o qualsiasi altro metodo consolidato. Ciò che il template standardizza è il formato in cui i risultati vengono documentati e presentati alle autorità di controllo, non il percorso con cui ci si arriva.

La struttura: sette sezioni, cinquanta istruzioni operative

Il documento è articolato in una sezione introduttiva (sezione 0) e sei sezioni operative (da 1 a 6), ciascuna accompagnata nell’explainer da istruzioni numerate - cinquanta in totale - che spiegano con precisione cosa inserire in ogni campo. Non è un’introduzione teorica alla DPIA: è una guida operativa, pensata sia per i titolari che per le autorità di controllo.

La sezione 0 è dedicata alla panoramica del trattamento: titolare (con gestione esplicita dei contitolari), responsabili e sub-responsabili, denominazione del trattamento con raccordo al registro delle attività ex art. 30, pianificazione temporale, e una scheda tecnica della DPIA che include versioning, team coinvolto, perimetro della valutazione e data di validazione formale. Su quest’ultimo punto l’explainer è netto: la DPIA deve essere approvata da un responsabile designato dell’organizzazione (AD, CEO o equivalente) come documento completo e definitivo. Non è un adempimento del DPO: è un atto dell’organizzazione in qualità di titolare del trattamento.

La sezione 1 introduce la descrizione sistematica del trattamento, che si articola su quattro livelli. Il primo è la descrizione di alto livello: dati personali trattati con identificazione delle categorie particolari, finalità specifiche ed esplicite, usi secondari o compatibili, natura/portata/contesto. Il secondo livello è la descrizione funzionale: il trattamento va decomposto in fasi (raccolta, uso, conservazione, comunicazione e trasferimento, cancellazione e distruzione), documentando l’intera catena titolare-responsabile-sub-responsabile. Il terzo livello riguarda i mezzi di trattamento e gli asset di supporto: server, dispositivi, applicativi, API, modelli, personale, contratti con i responsabili. L’explainer precisa che vanno inclusi solo gli asset rilevanti per l’analisi del rischio - quelli la cui compromissione avrebbe un impatto non trascurabile sui diritti degli interessati. Il quarto livello, spesso trascurato, riguarda la conformità ai codici di condotta approvati.

La sezione 2 è l’analisi del trattamento. Copre la base giuridica - da analizzare per ciascuna finalità, incluse quelle secondarie o compatibili - e le deroghe ex art. 9(2) GDPR per le categorie particolari di dati. Segue la minimizzazione dei dati con giustificazione analitica per ciascun dato trattato, periodi di conservazione, destinatari, e metriche di qualità del dato. La parte più articolata è la sezione 2.3, dedicata alle misure a supporto della conformità: l’explainer distingue cinque sottocategorie - principi art. 5, diritti degli interessati, altri requisiti GDPR (consenso, responsabili del trattamento, trasferimenti internazionali), privacy by design e by default, sicurezza del trattamento - e per ciascuna richiede di indicare lo stato di implementazione con tre livelli: pianificato, parzialmente implementato, implementato. Non basta elencare le misure: bisogna discuterne l’adeguatezza e l’efficacia.

La sezione 3 affronta i requisiti di necessità e proporzionalità. È una delle sezioni più esigenti sul piano argomentativo, e l’explainer lo chiarisce senza ambiguità: la valutazione di necessità richiede di dimostrare che il trattamento sia efficace e il meno invasivo possibile per i diritti degli interessati, con evidenze sulle alternative considerate. La proporzionalità presuppone la necessità come condizione, e richiede un bilanciamento esplicito tra vantaggi del trattamento e gli impatti sui diritti fondamentali. Non è sufficiente affermare che il trattamento sia proporzionato: serve una valutazione realistica, motivata e costantemente aggiornata.

La sezione 4 è la valutazione e gestione del rischio, strutturata su due livelli distinti. Il primo - e questo è uno degli aspetti più originali del template - riguarda i rischi strutturali o “by design“: le minacce che esistono anche quando tutto funziona esattamente come progettato e tutti gli attori rispettano le regole. Sono rischi di fatto legati alle scelte progettuali stesse. Il secondo livello riguarda invece i rischi da eventi non ordinari, accidentali o illeciti: malfunzionamenti, errori operativi, attacchi esterni, abusi interni. L’explainer fornisce esempi precisi di fonti di rischio per questa seconda categoria: bug software, configurazioni errate, diritti di accesso sbagliati, mancata manutenzione, phishing, ransomware. Per entrambi i livelli la metodologia di calcolo è libera, ma deve essere documentata e applicata coerentemente. Il rischio inerente si calcola come funzione di probabilità e gravità, modulata da fattori aggravanti (numero elevato di interessati, presenza di soggetti vulnerabili, alta esposizione esterna) o mitiganti (misure della sezione 2.3). Il piano d’azione produce le misure aggiuntive non inizialmente previste, il cui effetto viene poi misurato nella valutazione del rischio residuo. Un rischio ad alta gravità può essere inaccettabile anche a bassa probabilità: l’explainer e le note esplicative al template lo contemplano esplicitamente.

La sezione 5 formalizza il coinvolgimento delle parti interessate. Il template introduce un campo dedicato in cui il titolare deve indicare non solo il parere del DPO (Data Protection Officer), ma come quel parere sia stato concretamente recepito nel processo - o, se non lo è stato, le ragioni della scelta. Per gli interessati, va spiegata la loro partecipazione al processo e, laddove non vi siano stati coinvolti, la motivazione della scelta.

La sezione 6, introduce la conclusione e decisione, che è forse l’innovazione più visibile per chi viene da approcci più informali. Il template prevede quattro esiti formali: respinto (il trattamento deve essere abbandonato), consultazione obbligatoria con l’autorità di controllo, approvato, approvato con condizioni. La decisione deve essere motivabile e tracciabile.

Due elementi che meritano attenzione specifica

Il primo è la distinzione netta tra rischi strutturali e rischi incidentali nella sezione 4. Nella pratica corrente, la valutazione del rischio nelle DPIA si concentra quasi sempre sui secondi - data breach, attacchi, errori umani. L’explainer introduce esplicitamente la categoria dei rischi “by design“, che esistono indipendentemente da qualsiasi malfunzionamento. È un cambio di prospettiva rilevante, perché sposta l’analisi a monte: non solo cosa può andare storto, ma anche cosa, anche andando tutto secondo i piani, produce impatti sui diritti degli interessati.

Il secondo è la sezione sugli usi secondari e compatibili (1.1.3), che nel template viene menzionata esplicitamente come sezione a sé: si chiede di indicare se e a quali condizioni i dati possono essere riutilizzati per finalità diverse da quella originaria, con esplicito riferimento al principio di limitazione della finalità. Nella pratica quotidiana questa voce viene sistematicamente ignorata o compilata in modo generico. La sua presenza nel template EDPB la porta al rango di elemento obbligatorio della documentazione. Il tema si inserisce in un contesto regolatorio più ampio: il considerando 50 del GDPR già ammette trattamenti ulteriori per finalità compatibili, e il pacchetto Digital Omnibus (COM(2025) 765) segnala una volontà di rendere questo snodo più operativo, con potenziali ricadute pratiche soprattutto nei settori della ricerca scientifica e della sanità.

Non è il primo modello europeo: la linea di continuità con CNIL e AEPD

Il template EDPB non nasce in un vuoto. Diverse autorità di controllo nazionali avevano già sviluppato propri strumenti metodologici per la conduzione delle DPIA, e chi lavora in questo ambito li conosce bene.

La CNIL (Garante privacy francese) è stata probabilmente la più sistematica: il suo strumento PIA (Privacy Impact Assessment), disponibile anche come software open source, ha rappresentato per anni il punto di riferimento pratico più utilizzato a livello europeo, con una struttura che copre descrizione del trattamento, analisi dei rischi e piano d’azione. L’AEPD (Garante privacy spagnolo) ha pubblicato a sua volta una guida articolata sulla gestione del rischio e la valutazione d’impatto, con un approccio particolarmente dettagliato sul raccordo tra risk assessment e misure tecniche e organizzative. Entrambi questi strumenti hanno contribuito a definire un lessico comune e una logica di lavoro condivisa, pur restando strumenti nazionali, pensati per i propri contesti regolativi e privi di un riconoscimento formale europeo.

Il template EDPB si pone esplicitamente in continuità con questa tradizione ma fa un passo ulteriore: non è lo strumento di una singola autorità nazionale, ma il formato adottato dal Board e accettato da tutte le Autorità degli Stati membri. Significa che un’organizzazione che utilizza questo template per documentare la propria DPIA produce un documento che ha valore uniforme in tutta l’Unione, indipendentemente da quale Autorità di controllo sia competente. È l’ambizione di un framework davvero armonizzato, che chiude - almeno nella forma - la stagione della frammentazione metodologica post-2018.

Resta aperta la questione sostanziale: la qualità di una DPIA dipende dalla serietà con cui viene condotta, non dal formato in cui viene documentata. Il template risolve il problema della standardizzazione, non quello della profondità analitica. Ma avere un riferimento comune riconosciuto è comunque un progresso, sia per le organizzazioni che devono produrre la documentazione, sia per le autorità che devono valutarla.

Il template in italiano

Per facilitare la lettura e l’uso operativo, ho predisposto una traduzione italiana del modello ufficiale. Non è una traduzione ufficiale, ma uno strumento di studio e lavoro che metto a disposizione liberamente.

Il documento è in consultazione pubblica fino al 9 giugno 2026: eventuali osservazioni possono essere inviate all’EDPB entro quella data. La versione definitiva potrà differire da quella attuale.

👉 Scarica il template DPIA in italiano (accessibile al presente link)

Lo scorso 4 marzo 2026 l’AgID ha adottato le relative Linee Guida in attuazione dell’articolo 21 del sopracitato decreto, le quali chiariscono il perimetro applicativo e gli obblighi concreti in capo ai fornitori di servizi privati.

Non si tratta di una novità per il settore pubblico: gli enti pubblici hanno obblighi di accessibilità digitale da oltre vent'anni, dalla Legge Stanca del 2004 in poi. La novità è che dal 2025 quegli obblighi si estendono ai privati — e l'estensione è tutt'altro che marginale.

Chi è coinvolto?

Il decreto si applica ai fornitori di servizi digitali diretti ai consumatori (intesa come la persona fisica che acquista al di fuori di attività professionale) che operano in sei categorie:

1. servizi di comunicazione elettronica;

2. piattaforme di accesso a media audiovisivi;

3. servizi di trasporto passeggeri (aereo, ferroviario, navale, bus, metro, tram);

4. servizi bancari al dettaglio;

5. e-book e software di lettura;

6. piattaforme e siti di e-commerce.

Rimangono escluse le microimprese (meno di 10 dipendenti e fatturato/totale attivo ≤ 2 milioni di euro), seppur incoraggiate all’adozione volontaria di standard inclusivi.

Nota operativa: se il servizio è rivolto sia a consumatori sia a professionisti — il caso tipico di un e-commerce che vende hardware sia a privati sia ad aziende — l’intero servizio deve essere conforme, senza possibilità di distinguere la parte “consumer” da quella “business”.

Cosa si chiede concretamente?

Il riferimento tecnico per la conformità è la norma EN 301 549 v.3.2.1, uno standard europeo armonizzato che definisce i requisiti di accessibilità per prodotti e servizi ICT — siti web, app mobili, software, piattaforme interattive. La norma incorpora le WCAG 2.1 (Web Content Accessibility Guidelines), lo standard internazionale del W3C per l’accessibilità dei contenuti web - aggiornato dalle successive WCAG 2.2: chi soddisfa i requisiti della EN 301 549 soddisfa, per la parte relativa ai contenuti web, le WCAG ai livelli A e AA, che sono i livelli minimi obbligatori. La norma va però oltre le WCAG, coprendo anche software, hardware e altri prodotti ICT.

In termini sostanziali, i servizi devono rispettare i quattro principi POUR: essere percepibili, operabili, comprensibili e robusti — ovvero fruibili da tecnologie assistive come screen reader e display braille. A questi requisiti generali si aggiungono obblighi specifici per categoria: per i servizi bancari le informazioni non devono superare il livello B2 del CEFR per complessità linguistica; per gli e-book, i sistemi DRM non possono bloccare le tecnologie assistive; per l’e-commerce, il flusso di identificazione e pagamento deve essere accessibile ai non vedenti.

Nota operativa: le Linee Guida introducono anche un obbligo che incrocia la privacy: i fornitori devono dichiarare espressamente di non utilizzare tecniche di tracciamento web — cookies, browser fingerprinting — dalle quali si possa desumere una condizione di disabilità dell’utente. Un’intersezione normativa concreta tra accessibilità e trattamento dei dati personali che vale la pena tenere presente.

Cosa significa concretamente per i fornitori?

Le Linee Guida non chiedono soltanto di rendere i servizi accessibili, ma di spiegare in modo trasparente come lo sono.

Un ulteriore profilo spesso trascurato riguarda proprio gli obblighi informativi: le Linee Guida in esame dedicano un allegato specifico a questo profilo, che chiarisce in modo vincolante cosa deve contenere la documentazione informativa verso l'utente.

Nelle condizioni generali del servizio, o in un documento equivalente, il fornitore deve infatti spiegare come il proprio servizio soddisfa i requisiti di accessibilità imposti dalla normativa vigente.

Nota operativa: il contenuto minimo della documentazione deve ricomprendere (i) una descrizione generale del servizio in formato accessibile, (ii) una spiegazione del suo funzionamento, e (iii) un'illustrazione puntuale di come vengono rispettati i requisiti applicabili. Queste informazioni si aggiungono - e non si sostituiscono - a quelle già dovute ai consumatori ai sensi della Direttiva 2011/83/UE.

Il regime delle esenzioni: quando e come si applica?

Il decreto prevede due casi in cui i requisiti di accessibilità non trovano applicazione in modo “pieno”: quando la conformità richiederebbe una modifica sostanziale del servizio — cioè ne altererebbe la natura stessa — oppure quando comporterebbe un onere sproporzionato rispetto alle dimensioni e capacità del fornitore, secondo i criteri previsti dall’Allegato V del d.lgs. 82/2022 (ad esempio, tenendo in considerazione il rapporto tra i costi netti di adeguamento e i costi totali di fornitura del servizio o, piuttosto, la stima costi/benefici).

Attenzione però: non si tratta di eccezioni automatiche. Entrambe devono essere valutate e documentate dal fornitore, e la documentazione va conservata per almeno cinque anni dall’ultima erogazione del servizio.

Nota operativa: c’è poi un regime transitorio: i contratti di servizi stipulati prima del 28 giugno 2025 possono essere mantenuti invariati fino alla loro scadenza, e comunque per un periodo non superiore a cinque anni da tale data. I terminali self-service già utilizzati per la fornitura dei servizi possono continuare ad essere impiegati fino alla fine della loro vita economica utile, ma non oltre vent’anni dalla loro messa in funzione.

Vigilanza e reclami, come funziona?

AgID è l’autorità di vigilanza per la maggior parte dei servizi in perimetro (con competenze ripartite con AGCOM per le telecomunicazioni e ART per i trasporti). I fornitori con fatturato medio superiore a 500 milioni di euro negli ultimi tre anni sono esposti a sanzioni fino al 5% del fatturato in caso di violazione degli obblighi su siti web e app mobili.

L’utente che riscontra un’inaccessibilità può presentare reclamo ad AgID. L’Agenzia avvia una prima valutazione formale e poi coinvolge il fornitore per l’approfondimento sostanziale — un meccanismo di risoluzione alternativa delle controversie reso obbligatorio dalla direttiva, prima di adire rimedi formali.

In caso di verifica o reclamo, il fornitore deve essere in grado di trasmettere ad AgID la documentazione tecnica di conformità, le schede di controllo (WCAG, EN 301 549), le evidenze di test e collaudi, le valutazioni interne e, se invocate, le giustificazioni per modifica sostanziale o onere sproporzionato. Tutta la documentazione deve essere in formato digitale, firmata con firma digitale e marcata temporalmente.

Nota operativa: il parallelismo con la normativa data protection (e in particolare con il GDPR) è evidente: l’accessibilità entra pienamente nella logica dell’accountability documentata. Non è sufficiente essere “conformi”, ma occorre poterlo dimostrare, con evidenze datate e sottoscritte dall’organizzazione.

Con l’entrata in vigore del D. Lgs. 4 settembre 2024, n. 138 (attuativo della Direttiva Network and Information Security - NIS), l’Italia ha aggiornato il proprio quadro di regolazione della cybersicurezza, estendendo obblighi e responsabilità a una platea più ampia di soggetti pubblici e privati e introducendo un regime sanzionatorio rigoroso.

Quali le recenti novità e gli obblighi per le aziende?

1. Aggiornamento dei dati o registrazione ex novo: entro domani 28 febbraio 2026 tutti i soggetti NIS obbligati devono completare la registrazione o l’aggiornamento delle proprie informazioni sulla piattaforma ACN tramite il servizio “Registrazione” o Aggiornamento delle informazioni”.

La scadenza del 28 febbraio 2026 ha natura diversa a seconda della posizione del soggetto: per chi è già registrato costituisce un adempimento annuale di conferma e aggiornamento dei dati per mezzo di una scheda precompilata basata sui dati dell’anno precedente, mentre per chi non è ancora registrato rappresenta l’atto di ingresso nel perimetro NIS, dal quale – solo in caso di successiva inclusione nell’elenco notificata ad aprile – decorreranno gli obblighi strutturali previsti dal D. Lgs. 4 settembre 2024, n. 138.

La mancata registrazione, comunicazione o aggiornamento entro i suddetti termini - come previsto dall’art. 38, comma 11, del d.lgs. 138/2024 - espone a sanzioni amministrative, e nello specifico:

• per i soggetti essenziali: fino a 0,1 % del fatturato mondiale totale dell’esercizio precedente;

• per i soggetti importanti: fino a 0,07 % del fatturato mondiale totale dell’esercizio precedente;

• per pubbliche amministrazioni e soggetti sotto controllo pubblico: da €10.000 a €50.000 (con riduzioni se identificati come importanti).

Per chi, invece, non rientra nel perimetro NIS, resta comunque buona prassi tenere la PEC istituzionale sempre monitorata, per ricevere comunicazioni ufficiali ed essere pronti in caso di possibili cambiamenti nel perimetro di applicazione della normativa, fermo restando il potere dell’Autorità di individuare e designare autonomamente i soggetti rientranti nell’ambito di applicazione della normativa in oggetto.

2. Tassonomia degli incidenti: è stata pubblicata in Gazzetta Ufficiale la determinazione dell’Agenzia per la Cybersicurezza Nazionale che definisce la tassonomia degli incidenti informatici soggetti a obbligo di segnalazione e notifica ai sensi dell’art. 1, comma 1, della Legge 28 giugno 2024, n. 90 (“Disposizioni in materia di rafforzamento della cybersicurezza nazionale e di reati informatici”). E’ bene notare che tale obbligo di segnalazione e notifica riguarda, in particolare, un perimetro di soggetti delineato direttamente dalla legge, che include amministrazioni e operatori pubblici locali con servizi essenziali e impatto territoriale significativo e anche società “in house” che forniscono servizi informatici o servizi pubblici correlati per i soggetti ricompresi.

La tassonomia è allineata alle fattispecie di “incidenti significativi di base” già individuate dalla determinazione ACN n. 379907 del 19 dicembre 2025, adottata in attuazione del D. Lgs. 4 settembre 2024, n. 138. In questo contesto, l’elemento pratico più rilevante per tali soggetti nel perimetro NIS, è la logica di riduzione degli oneri: la determinazione afferma che, in caso di “prenotifica e notifica” effettuata ai sensi dell’articolo 25 del D. Lgs. 4 settembre 2024, n. 138, può considerarsi assolto anche l’obbligo previsto dalla legge 90/2024. Per tali soggetti, è dunque stata prevista la possibilità di effettuare un’unica comunicazione tramite il portale ACN.

3. Adempimenti rilevanti - un recap complessivo: il D. Lgs. 4 settembre 2024, n. 138 prevede obblighi per gli organi di amministrazione e direttivi (articolo 23), la gestione dei rischi per la sicurezza informatica (articolo 24) e le notifiche di incidente (articolo 25). In fase di prima applicazione, per assicurare la conformità dei soggetti essenziali e importanti a tali obblighi, sono state stabilite le misure di sicurezza e le notifiche di incidente di base.

Rispetto al passato, la normativa NIS amplia significativamente il perimetro di applicazione: non si limita più solo ad alcune reti e servizi essenziali, ma copre tutta l’infrastruttura ICT dei soggetti obbligati, distinguendo tra soggetti essenziali e importanti in base ai criteri dimensionali previsti e alla criticità delle attività svolte e del settore di riferimento, richiedendo alle organizzazioni un approccio multi-rischio e multi-livello alla sicurezza informatica e alla resilienza operativa.

Oltre ai già citati obblighi di registrazione e/o aggiornamento annuale, è bene tenere a mente che dal 1° gennaio 2026 sono entrati in vigore gli obblighi di notifica degli incidenti significativi, mentre entro ottobre 2026 tutti i soggetti NIS dovranno aver adottato le misure minime di sicurezza previste (sviluppo di policy ad hoc, piani di risposta agli incidenti, presidi tecnici coerenti con il livello di rischio individuato, supervisione della supply chain, ecc.).

Il 2026 segna il passaggio alla piena operatività del regime NIS: registrazione, notifica degli incidenti e adozione delle misure minime di sicurezza non sono adempimenti isolati, ma elementi di un sistema di governance tecnologica e di cybersecurity più ampio che le organizzazioni - sia quelle direttamente impattate, che quelle indirettamente coinvolte nella catena di fornitura - sono chiamate ad implementare e garantire.

Il dato comune che emerge è che il Garante non si accontenta più di verificare la presenza formale di consensi o informative, ma analizza il flusso sostanziale dei meccanismi di raccolta e utilizzo dei dati, misurandoli sulle aspettative concrete dell’utente e sul principio di “responsabilizzazione” del titolare.

1. Come si raccoglie un consenso valido: errori di design che diventano violazioni

Nel provvedimento Aimag, il Garante interviene in modo molto netto sulla modalità di raccolta del consenso al marketing tramite area riservata. La presenza di checkbox preselezionati su “SI” e di formule sovrapponibili per finalità promozionali e di customer satisfaction viene considerata incompatibile con i requisiti di libertà e specificità del consenso. Il problema non è solo giuridico, ma esperienziale: l’utente non è messo in condizione di comprendere chiaramente cosa sta accettando e per quali finalità.

Nel caso Verisure, il tema assume una declinazione diversa ma convergente. Qui il consenso al marketing viene di fatto incorporato nella richiesta di preventivo o di ricontatto commerciale, creando una situazione in cui l’interessato non può realmente scegliere se essere o meno contattato per finalità promozionali senza rinunciare al servizio richiesto. Il Garante ribadisce che un consenso così costruito non può essere considerato libero.

Il messaggio per le aziende è chiaro: la progettazione dei form e dei flussi di acquisizione di lead, prospect non è un tema meramente tecnico. Checkbox, testi e percorsi devono essere pensati per consentire una scelta reale e separata, non per “ottimizzare” la raccolta dei consensi a scapito della chiarezza.

2. Base giuridica e trasparenza: evitare sovrapposizioni e ambiguità

Entrambi i provvedimenti mostrano una forte attenzione del Garante alla coerenza tra finalità dichiarate e basi giuridiche utilizzate.

Nel caso Aimag, l’Autorità censura il ricorso poco chiaro al legittimo interesse, richiamato in modo generico e non coerente con le modalità concrete del trattamento. L’assenza di una spiegazione puntuale del bilanciamento e delle aspettative dell’interessato rende la base giuridica di fatto indimostrabile.

Nel caso Verisure, il tema centrale è la distinzione – spesso trascurata nella pratica – tra contatto finalizzato a dare seguito a una richiesta dell’utente e marketing successivo. Il Garante chiarisce che il primo può, in alcuni casi, poggiare su misure precontrattuali, mentre il secondo richiede una base giuridica autonoma: normalmente il consenso. Sovrapporre i due piani, sia a livello informativo che operativo, espone le aziende a rilievi e possibili contestazioni (come nei due casi in esame).

La lezione è evidente: le informative non devono solo “coprire” il trattamento, ma raccontarlo in modo coerente. Dove la base giuridica è confusa o contraddittoria, la violazione non è solo nella formale, ma anche e soprattutto nella sostanza.

3. Conservazione dei dati e marketing: il limite delle giustificazioni “di default”

La conservazione dei dati per finalità di marketing è uno dei punti più critici affrontati in entrambi i provvedimenti.

Nel caso Aimag, il Garante ritiene non proporzionata una retention di cinque anni giustificata richiamando la durata media dei contratti o i termini di prescrizione. L’Autorità chiarisce che esigenze difensive o contrattuali non possono essere automaticamente traslate - e anzi sono nettamente distinte - da attività di marketing e promozionali.

Nel provvedimento Verisure il tema della retention assume un ruolo centrale, perché viene utilizzato dal Garante come vero e proprio criterio di qualificazione del trattamento. L’Autorità smonta in modo molto chiaro l’assunto secondo cui il teleselling svolto dalla Società costituirebbe una naturale prosecuzione della richiesta di contatto dell’interessato, evidenziando come un termine di conservazione dei dati pari a 12 (dodici) mesi faccia venir meno qualsiasi reale continuità cronologica con l’attività di telebooking.

Secondo il Garante, un arco temporale così ampio non è compatibile con la logica di un contatto funzionale alla richiesta dell’utente, ma rivela piuttosto l’esistenza di un autonomo trattamento per finalità di marketing. La durata della conservazione diventa così un indicatore sostanziale della finalità perseguita: se i dati restano utilizzabili per mesi, il trattamento non può più essere ricondotto a una mera risposta alla richiesta dell’interessato, ma si colloca a pieno titolo nell’ambito del marketing diretto. D’altra parte, la scelta di una retention così estesa finisca per eludere la necessità di acquisire un consenso autonomo al marketing, aggravando ulteriormente il quadro delle violazioni.

Il Garante ribadisce inoltre la censura verso l’uso di formulazioni generiche nelle informative, come il riferimento alla conservazione “per il periodo strettamente necessario”, ritenendole inidonee a soddisfare gli obblighi di trasparenza. Tali espressioni, rimesse alla discrezionalità del titolare, non consentono all’interessato di comprendere quando i propri dati verranno effettivamente cancellati e non integrano un criterio di calcolo certo, come richiesto dal Regolamento.

Il principio che emerge è che la retention marketing deve essere pensata e motivata come tale, sulla base del ciclo di vita del contatto, delle aspettative dell’utente e della reale utilità del dato. Utilizzare modelli standard o formule generiche espone a rilievi difficilmente difendibili.

4. Diritti degli interessati: il Garante guarda all’effettiva attuazione

Nel provvedimento Verisure, il Garante dedica particolare attenzione alla gestione dei diritti, soprattutto al diritto di opposizione e cancellazione. L’Autorità chiarisce che una risposta formale all’interessato non è sufficiente se, sul piano operativo, la richiesta non viene effettivamente eseguita su tutti i sistemi e lungo tutta la catena del trattamento.

La prosecuzione dei contatti promozionali, anche a seguito di richieste di opposizione già accolte, viene letta come un sintomo di carenze organizzative e di governance, non come un semplice errore occasionale. In questo contesto, il titolare resta pienamente responsabile anche per le attività svolte da partner commerciali, agenti o fornitori.

Per le aziende questo implica una riflessione profonda sull’architettura dei sistemi di marketing e CRM: i diritti previsti dal GDPR (accesso, cancellazione, opposizione, portabilità) devono essere gestiti in modo centralizzato, tempestivo e verificabile.

5. Il rischio reputazionale che si aggiunge alla sanzione pecuniaria

Un ultimo elemento, comune a entrambi i provvedimenti, è la combinazione tra sanzione pecuniaria e pubblicazione della decisione sul sito web dell’Autorità. Non si tratta di un profilo accessorio: alla rilevanza economica della multa si affianca un’esposizione reputazionale permanente, resa ancora più incisiva dalla facile accessibilità dei provvedimenti da parte di clienti, partner e concorrenti.

Il messaggio che il Garante sembra voler trasmettere è chiaro: le violazioni in materia di marketing incidono direttamente sulla fiducia degli interessati e, proprio per questo, meritano una risposta che vada oltre la mera sanzione economica.

In sintesi

In conclusione, i provvedimenti del Garante confermano che il marketing è diventato uno dei principali terreni su cui si misura la reale maturità privacy di un’organizzazione. Consensi, retention e gestione dei diritti non sono più elementi accessori, ma componenti strutturali della strategia commerciale e della visione aziendale che si vuole trasmettere verso l’esterno.

Per evitare rimproveri, sanzioni e impatti reputazionali, le aziende devono ripensare il marketing in chiave di accountability concreta, dimostrando non solo di rispettare la norma nella forma, ma di aver costruito processi coerenti, trasparenti e orientati alla tutela effettiva degli interessati. È su questo terreno che, oggi, si misura la conformità la fiducia di un business.

Fissiamo un momento di confronto insieme

Condividi DPO News

Anthropic ha appena presentato Anthropic Interviewer, un agente AI progettato non per generare output, ma per fare domande a persone reali su come vivono e utilizzano l’intelligenza artificiale nel lavoro quotidiano. Il risultato è interessante: entusiasmo diffuso e benefici concreti, ma anche timori profondi legati a controllo, fiducia e identità professionale.
👉 https://www.anthropic.com/news/anthropic-interviewer

Su un piano più prospettico, il report AI 2027 descrive uno scenario ravvicinato in cui l’AI evolve rapidamente in agenti autonomi, capaci di perseguire obiettivi, prendere decisioni e operare su larga scala, con impatti rilevanti su modelli di business, governance e sicurezza geopolitica.
👉 https://ai-2027.com/

Tra ciò che l’AI è oggi nelle organizzazioni e ciò che potrebbe diventare nel giro di pochi anni esiste un vuoto progettuale che le aziende non possono permettersi di ignorare. Secondo alcuni, quel vuoto non si colma “solo” con la tecnologia, ma con visione e design consapevole.

In questa puntata di DPO News Podcast ne parlo con Dario Torrisi, service & strategic designer e venture builder, per esplorare come design dei servizi, costruzione di nuovi business e compliance digitale stiano convergendo.

Quando l’AI smette di essere un semplice tool e inizia ad agire come un agente, diventano ancora più centrali le interfacce, la trasparenza, i confini operativi e la capacità di rendere visibili decisioni, limiti e responsabilità.

Per le aziende, la vera sfida non è adottare l’AI più velocemente degli altri, ma progettare sistemi affidabili, comprensibili e governabili, in cui requisiti normativi, fiducia degli utenti e valore di business siano integrati fin dall’inizio.

Perché l’AI del futuro non si governa a valle, ma si progetta già adesso.

Benvenuti al Podcast DPO News, uno spazio di mezz’ora in cui proviamo a mettere ordine nel caos della regolazione digitale (e non solo).

Ogni settimana raccontiamo in modo semplice e pratico cosa sta cambiando tra privacy, AI, cybersecurity e nuove norme europee — con un occhio molto concreto alle ricadute per aziende e professionisti.

In alcune puntate saremo in compagnia di colleghi, imprese e ospiti che stanno vivendo queste sfide dall’interno: storie, casi reali, errori da evitare e idee che funzionano davvero.

Oggi, per la prima puntata, ho invitato un amico di lunga data e collega, @Matteo Squeo, avvocato esperto in sostenibilità, governance ed ESG.

Negli scorsi giorni eravamo entrambi a Bruxelles e abbiamo seguito da vicino la presentazione del Digital Omnibus, il nuovo pacchetto con cui la Commissione Europea prova a rimettere mano — di nuovo — al quadro normativo digitale e di sostenibilità.

La domanda che ci siamo fatti è semplice, ma centrale per chi fa impresa: si tratta davvero di semplificazione o si tratta di una forma di deregolamentazione “mascherata”?

In questo episodio proviamo a rispondere senza giri di parole, partendo da ciò che abbiamo osservato sul campo:

• una frammentazione crescente tra Stati membri che frena competitività e investimenti;

• normative accelerate, spesso approvate con grande slancio politico, ma con atti di implementazione lenti o incompleti;

• mancanza di prevedibilità per aziende e operatori, che devono muoversi tra linee guida aggiornate di continuo;

• la tentazione di “semplificare” a valle quello che è stato sovra-regolato a monte.

Io porto la prospettiva privacy, AI e governance digitale. Matteo porta quella sostenibilità e trasparenza ESG. Il risultato è un confronto molto pratico: come cambia davvero la vita alle imprese?

Qualche spunto che troverete nell’episodio:

• cosa succede a normativa privacy e AI, gestione della cybersecurity e ricerca scientifica;

• perché privacy e sostenibilità stanno vivendo la stessa “montagna russa” normativa;

• quali rischi reali stanno emergendo (e quali opportunità);

• quando la compliance smette di essere un costo e diventa un investimento strategico.

1. Email? Sì, ma non basta: servono misure tecniche aggiuntive

Il Garante è chiaro: la posta elettronica, anche via PEC, non è di per sé adeguata a garantire la riservatezza del segnalante. Il motivo è semplice: genera log, tracce e metadati che possono rendere identificabile chi segnala.

Questo non significa che l’email sia vietata, ma che può essere utilizzata solo se l’azienda è in grado di applicare una serie di contromisure ben precise.

Cosa implica, nella pratica?

La casella dedicata alle segnalazioni (es. whistleblowing@…) deve essere isolata dal resto dell’infrastruttura IT, non deve finire in sistemi di ticketing o monitoraggio automatico, e può essere accessibile soltanto al gestore del canale. Vanno inoltre ridotti al minimo i log tecnici, disattivate registrazioni non necessarie e configurati firewall, proxy e sistemi di sicurezza in modo da non raccogliere informazioni che possano far risalire all’identità del segnalante. Per le segnalazioni gestite con strumenti tradizionali, rimane valido il principio della “doppia busta”: separare identità e contenuto, mantenendo la massima riservatezza.

In sintesi: se la tua azienda non è in grado di implementare queste misure, meglio utilizzare una piattaforma dedicata.

2. Piattaforme di whistleblowing: meglio se cifrate end-to-end e con non-tracciabilità di rete

Le nuove indicazioni premiano l’utilizzo di piattaforme informatiche specializzate, che permettono un livello di protezione più elevato e coerente con i requisiti del D.lgs. 24/2023 e del GDPR.

Cosa deve assicurare una piattaforma di whistleblowing adeguata?

• cifratura dei dati a riposo e in transito;

• possibilità per il segnalante di comunicare senza essere tracciato (no IP o user session logging riconducibile);

• separazione chiara dei ruoli e accesso consentito solo al personale strettamente autorizzato;

• cancellazione automatica dei dati allo scadere dei cinque anni, come previsto dalla normativa.

In sintesi: l’azienda che implementa il proprio canale deve verificare quanto sopra in fase di onboarding del fornitore, tramite un’attenta analisi della documentazione tecnica condivisa da quest’ultimo, e riflettere queste garanzie all’interno del contratto di servizi e nell’atto di nomina a responsabile del trattamento conforme ai requisiti di cui all’art. 28 GDPR.

3. Valutazione d’impatto obbligatoria

Il Garante lo ribadisce: la valutazione di impatto è necessaria. Non basta dichiarare che il canale è ”sicuro” o affidarsi alla compliance dichiarata dal fornitore della piattaforma. Va dimostrato, per mezzo di una valutazione d’impatto (DPIA) conforme ai requisiti dell’art. 35 del GDPR, che le misure tecniche e organizzative adottate siano idonee a proteggere i dati delle persone nel corso del processo di acquisizione e gestione della segnalazione.

Cosa deve includere la DPIA?

• mappatura dei flussi;

• mitigazione dei rischi per la riservatezza dell’identità del segnalante;

• informazioni tecniche sulla configurazione degli apparati di rete (firewall, proxy, mail server);

• verifica delle misure garantite del fornitore, se la gestione è esternalizzata;

• valutazione circa i principi applicabili al trattamento, le basi giuridiche richiamate, la proporzionalità e adeguatezza della soluzione adottata.

In sintesi: non serve una DPIA “enciclopedica”, ma serve che sia specifica per il canale e per i flussi reali implementati dall’azienda. Spesso è imprescindibile un coordinamento con il fornitore della piattaforma, specie per gli aspetti di sicurezza e di natura tecnica.

4. Condivisione del canale tra più società del gruppo? Attenzione al c.d. “ruolo privacy”

Il Garante corregge un punto cruciale: la capogruppo, quando gestisce il canale per le altre società, di norma svolge il ruolo di responsabile del trattamento, e non di contitolare - come erroneamente rappresentato all’interno dello schema di Linee guida ANAC.

Quali sono gli impatti pratici?

• va stipulato un atto di nomina a responsabile del trattamento conforme ai requisiti di cui all’art. 28 GDPR tra società del gruppo;

• ogni società deve comunque nominare il proprio gestore interno della segnalazione;

• la piattaforma deve garantire che ciascuna società possa vedere solo le segnalazioni di propria competenza attraverso un processo di segregazione mirato e documentato.

In sintesi: la capogruppo che gestisce il canale per le società controllate opera come responsabile del trattamento (al pari di un service provider). Serve quindi una nomina intercompany ex art. 28 GDPR, un gestore interno per ciascuna società e una piattaforma che garantisca una separazione delle segnalazioni tra le diverse entità del gruppo.

5. Segnalazione non rilevante? La riservatezza va garantita comunque

Anche se una segnalazione non ricade nel perimetro whistleblowing (es. lamentela HR, richiesta personale, segnalazione anonima non pertinente), la riservatezza del segnalante va comunque protetta.

Cosa significa all’atto pratico?

• niente inoltri impropri;

• niente protocollazioni aperte;

• gestione riservata anche quando non si tratta di una “segnalazione rilevante”.

In sintesi: anche le segnalazioni non “rilevanti” devono essere gestite con riservatezza: niente inoltri indiscriminati, niente protocolli visibili e trattamento comunque protetto dell’identità del segnalante.

6. Tempi di conservazione: massimo 5 anni dall’esito

Il Garante conferma la regola relativa alla gestione e conservazione delle segnalazioni ricevute: i documenti relativi alla segnalazione devono essere conservati per non oltre cinque anni dall’esito della procedura. Sono esclusi solo atti con finalità ulteriori (disciplinari, giudiziari, investigativi), ma anche questi non dovrebbero contenere l’identità del segnalante salvo casi espressamente previsti dalla legge.

In sintesi: le aziende devono quindi allineare procedure, policy di retention e sistemi di cancellazione, assicurandosi che eventuali documenti ulteriori non contengano l’identità del segnalante, salvo eccezioni di legge.

Perché è importante?

Perché qui il rischio non arriva da un unico fronte. Quando un’azienda gestisce in modo non conforme un canale di whistleblowing non rischia solo un “richiamo” da un’autorità, ma una serie di problemi che si sommano.

Da una parte c’è ANAC, che vigila proprio sul funzionamento dei canali di segnalazione: se il canale non è attivo, non è protetto, non è riservato o – peggio – se chi segnala subisce anche solo un accenno di ritorsione, la sanzione viene comminata proprio ai sensi del D.lgs. 24/2023.

Dall’altra parte c’è il Garante Privacy, che interviene su tutto ciò che riguarda dati personali e riservatezza. Se il segnalante è tracciabile, se non ci sono misure adeguate, se la DPIA manca o se la piattaforma non è configurata correttamente, scatta il profilo attinente alla privacy e alla violazione del GDPR e del Codice in materia di protezione dei dati personali.

Infine, oltre alle autorità, c’è il rischio più sottovalutato: il contenzioso interno. Un dipendente che ritiene violata la propria riservatezza o che subisce ritorsioni può rivolgersi al giudice del lavoro. Qui non si parla solo di sanzioni, ma di danni reputazionali e perdita di fiducia.

Un sistema di whistleblowing progettato con cura diventa un vero strumento di governo aziendale, capace di prevenire rischi, intercettare criticità e proteggere tanto l’azienda quanto le persone che vi lavorano. Un valore strategico che va ben oltre la semplice conformità.

Condividi DPO News

Lascia un commento

Prendiamo un caffè digitale

Bruxelles, 19 novembre: la Commissione europea presenta ufficialmente il Digital Omnibus, un pacchetto di semplificazione che interviene su una parte estesa del quadro normativo digitale dell’Unione Europea. Non si tratta di un singolo atto, ma di due proposte legislative coordinate che passeranno adesso al processo legislativo ordinario (Parlamento europeo e Consiglio dell’Unione Europea), dove potranno essere modificate anche in maniera significativa.

Le due iniziative condividono una logica comune - la semplificazione - ma perseguono questo obiettivo su piani diversi e complementari. La direzione politica della Commissione è infatti chiara: semplificare senza però ridurre (almeno questo il tentativo) il livello di tutela dei diritti dei cittadini europei, rafforzando al contempo la competitività del mercato unico.

L’iniziativa si inserisce in una più ampia strategia della Commissione orientata alla competitività. Non a caso lo stesso 19 novembre la Commissione ha presentato anche la 2030 Consumer Agenda, che mira a ridurre le complessità regolatorie e ad allineare le norme del mercato unico a un contesto sempre più digitale e transfrontaliero.

Da Bruxelles, il clima è divisivo: se da un lato Schrems/Noyb.eu parlano di “deregulation mascherata”, dall’altro vari accademici - tra cui Mark Leiser - leggono il pacchetto come una manutenzione tecnica necessaria del digitale europeo, con l’obiettivo di ridurre sovrapposizioni e aumentare coerenza normativa.

Indipendentemente dalle interpretazioni, il dato oggettivo è chiaro: il Digital Omnibus avvia una revisione strutturale del diritto digitale europeo. E per le imprese, al di là del dibattito, è utile capire quali sono le novità e che impatti concreti portano con sé.

Cosa comprende il Digital Omnibus

Il Digital Omnibus non è un unico atto normativo, ma un pacchetto composto da due proposte legislative distinte, presentate simultaneamente dalla Commissione europea per rendere più coerente e sostenibile l’intero quadro digitale dell’Unione. Le due iniziative agiscono su piani diversi ma complementari: da un lato introducono correttivi mirati all’AI Act per facilitarne l’attuazione; dall’altro razionalizzano diversi elementi del quadro regolatorio digitale vigente, con l’intento di semplificare procedure, eliminare duplicazioni e aggiornare disposizioni che oggi risultano - almeno in parte - frammentate. Nel loro complesso, queste due proposte rappresentano l’avvio di una strategia volta a ridurre la complessità regolatoria digitale europea e a rendere maggiormente prevedibile l’applicazione delle norme in un contesto economico sempre più integrato e transfrontaliero.

1) Digital Omnibus on AI Regulation Proposal

Con la proposta COM(2025) 836 del pacchetto Digital Omnibus, la Commissione interviene con una serie di misure correttive e di semplificazioni tecniche e operative, volte a garantire un’applicazione più fluida e proporzionata del regolamento in materia di intelligenza artificiale: meno incertezze interpretative, maggiore prevedibilità nelle scadenze, e un allineamento più chiaro tra standard tecnici, obblighi di conformità e capacità operative delle aziende.

Negli ultimi mesi era infatti emerso in modo evidente che l’impianto dell’AI Act, pur solido, rischiava di generare oneri e tempistiche difficilmente gestibili per molte imprese - europee in primis, soprattutto nei settori con sistemi ad alto rischio, nelle filiere complesse e nelle realtà che sviluppano modelli generativi.

2) Digital Omnibus Regulation Proposal

La proposta COM(2025) 837 del pacchetto Digital Omnibus ha un ambito di applicazione molto più esteso rispetto a quella dedicata all’AI Act (Reg. UE 2024/1689). Si tratta di un intervento di natura sistemica, che mira a riorganizzare e rendere più coerenti diverse normative del panorama digitale europeo, oggi distribuite in testi separati e talvolta caratterizzate da sovrapposizioni o disallineamenti.

L’armonizzazione prevista dalla proposta si traduce, innanzitutto, nel ricondurre discipline oggi distribuite in testi diversi all’interno di un unico quadro normativo più coerente. Un esempio è l’integrazione della disciplina ePrivacy (Direttiva 2002/58/CE) nelle disposizioni del GDPR (Reg. UE 2016/679) dedicate al tracciamento, così come la riunificazione delle norme del Data Governance Act (Reg. UE 2022/868), il Regolamento sul libero flusso dei dati non personali (Reg. UE 2018/1807) e la Open Data Directive (Dir. 2019/1024) all’interno del Data Act (Reg. UE 2023/2854), che diventa il riferimento principale per il data sharing e per i nuovi ecosistemi di dati.

Accanto a questi accorpamenti, la proposta prevede anche abrogazioni puntuali, quando una disciplina risulta ormai superata da strumenti più recenti. È il caso del Regolamento Platform-to-Business (P2B) del 2019: negli ultimi anni gran parte delle materie che disciplinava - in particolare la trasparenza nei rapporti tra piattaforme online e utenti commerciali - è già stata assorbita dal Digital Services Act (DSA) e dal Digital Markets Act (DMA), che oggi costituiscono il riferimento principale per obblighi, divieti e responsabilità delle piattaforme online.

Le novità più rilevanti per le aziende

a) Dati personali e non personali: verso una definizione dei criteri

La proposta contenuta nel Digital Omnibus chiarisce che la natura personale di un’informazione non dipende da una possibilità astratta di identificazione, ma dai mezzi ragionevolmente disponibili all’entità che tratta i dati. A ben vedere, si tratta di un’impostazione che ricalca il solco tracciato da alcuni recenti orientamenti della Corte di giustizia (si veda, ad esempio, la sentenza C-413/23 P – EDPS v SRB), che in tale contesto ha valorizzato un approccio concreto e contestuale all’identificabilità, aprendo al concetto di “assenza di una ragionevole possibilità di reidentificazione” da parte del soggetto che riceve o utilizza i dati.

Risvolto concreto per le aziende: sul piano operativo, si apre una valutazione più flessibile in alcuni contesti, come la ricerca scientifica e applicata, i modelli di condivisione dei dati o scenari in cui un’organizzazione riceve dataset pseudonimizzati senza avere mezzi realistici per reidentificarli. Lo stesso approccio può incidere sulle valutazioni relative ai trasferimenti di dati verso Paesi non coperti da decisioni di adeguatezza, quando il destinatario non risulta ragionevolmente in grado di associare i dati a persone identificate o identificabili.

b) Sviluppo di sistemi di AI: “legittimo interesse” delle aziende, uso dei dati e nuove tempistiche di attuazione

La proposta di Digital Omnibus chiarisce, innanzitutto, che le attività di sviluppo, addestramento, testing e miglioramento dei sistemi di AI possono, in determinati contesti previsti dalla proposta del nuovo articolo 88c del GDPR, fondarsi sul legittimo interesse del titolare. Non si tratta di una nuova base giuridica, ma di una specificazione del modo in cui l’art. 6(1)(f) del GDPR può essere utilizzato quando sono rispettate misure di tutela adeguate. L’obiettivo è evitare che ogni trattamento a fini di training richieda il consenso esplicito, pur mantenendo un presidio sostanziale sulle tutele degli interessati. In continuità con questa impostazione, il trattamento di categorie particolari di dati per finalità di sviluppo o miglioramento dell’AI viene ammesso solo in forma residuale e con cautele elevate, come tecniche avanzate di protezione, segregazione dei dataset e limiti rigorosi agli accessi e ai riusi rispetto alle finalità originarie.

Per altro verso, un ruolo centrale nel pacchetto dedicato alla revisione dell’AI Act, è assegnato agli standard armonizzati, che diventano la via preferenziale per dimostrare la conformità tecnica dei sistemi. La Commissione, attraverso l’AI Office e gli organismi europei di normazione, dovrà definire standard per i sistemi ad alto rischio -riguardanti gestione del rischio, qualità dei dati, documentazione tecnica e tracciabilità - e standard specifici per i sistemi di AI general purpose, inclusi i profili di content labelling e watermarking. Le stesse linee guida dovranno chiarire le responsabilità lungo la catena del valore, così da evitare che gli oneri regolatori si concentrino impropriamente su un solo anello (fornitori di modelli di base, integratori o deployer).

Sul versante delle tempistiche di attuazione, la proposta introduce margini più ampi per l’adeguamento dei sistemi di AI ad alto rischio, in particolare nei settori più sensibili come occupazione, credito, sanità, biometria e law enforcement. Alcuni requisiti potrebbero entrare in piena applicazione solo nel 2027 (rispetto alla scadenza iniziale prevista per agosto 2026), per consentire alle imprese di sviluppare e implementare soluzioni tecnologiche conformi in tempi non eccessivamente compressi. A ciò si affiancano misure specifiche per PMI e small mid-caps, che potranno fare ricorso in modo esteso a schemi semplificati di valutazione di conformità, linee guida e modelli europei, oltre a un ridimensionamento della frequenza e della granularità di alcuni obblighi documentali in funzione del rischio effettivo dei sistemi sviluppati o implementati. Ne è un esempio la proposta di modifica dell’art. 11 dell’AI Act, proprio in tema di documentazione tecnica.

Risvolto concreto per le aziende: i team AI potranno contare su un quadro giuridico più prevedibile, soprattutto per fasi di training e testing, nonché di retraining dei modelli di AI, fermo restando il rispetto delle garanzie poste dal GDPR in tema di minimizzazione, trasparenza e tutela dei diritti. Per le imprese significa poter pianificare lo sviluppo dell’AI con maggiore continuità, contando su percorsi di conformità più lineari, integrati e proporzionati al rischio dei sistemi impiegati.

c) Decisioni automatizzate: definizione armonizzata

Il Digital Omnibus interviene anche sul tema delle decisioni automatizzate di cui all’art. 22 del GDPR, rimuovendo il divieto generale di cui al primo paragrafo dell’articolo in questione.

Il testo specifica che una decisione basata solo su trattamento automatizzato può essere “necessaria” ai fini dell’esecuzione o della conclusione di un contratto anche se, in teoria, potrebbe essere presa da un operatore umano, purché l’automazione rappresenti la soluzione più proporzionata e meno invasiva per raggiungere il risultato atteso.

Viene infatti chiarito il significato del requisito di “necessità” quando una decisione automatizzata viene adottata nell’esecuzione di un contratto. La proposta specifica che la necessità può ricorrere anche quando la stessa decisione potrebbe, in astratto, essere presa da un operatore umano, purché l’automazione rappresenti la soluzione più proporzionata e meno invasiva, a parità di risultato atteso. In questo modo si supera l’interpretazione più rigida secondo cui l’automazione sarebbe “necessaria” soltanto se non esistesse un’alternativa manuale.

La proposta introduce inoltre una definizione più chiara di “decisione interamente automatizzata”, così da evitare approcci divergenti tra Stati membri e rendere più stabile l’applicazione del GDPR nei casi in cui coesistono componenti automatiche e verifiche umane.

Risvolto concreto per le aziende: per le aziende ciò si traduce in una maggiore certezza giuridica nell’implementazione di workflow automatizzati - ad esempio nei sistemi di scoring, nella valutazione del rischio o nei processi di onboarding - e nella possibilità di progettare soluzioni decisionali ibride con criteri più uniformi e prevedibili.

d) Gestione dei data breach: verso un unico canale europeo

Il Digital Omnibus introduce una modifica rilevante nella gestione degli incidenti di sicurezza e dei data breach, intervenendo sulla NIS2 (Direttiva UE 2022/2555) con l’inserimento di un nuovo articolo 23a. La norma attribuisce a ENISA il compito di progettare e mantenere un portale digitale unico europeo attraverso il quale inoltrare le notifiche di incidente. Una comunicazione trasmessa tramite questo canale diventa valida contemporaneamente per tutti i regimi applicabili: NIS2, GDPR per i data breach, DORA, CER ed eIDAS, incluse le attività legate ai trust services. L’infrastruttura sarà interoperabile con le European Business Wallets, lo strumento europeo di identità e attestazioni digitali per imprese e operatori, destinato a fungere da meccanismo comune di autenticazione nei rapporti transfrontalieri con la PA e tra soggetti privati.

Il nuovo sistema si basa su alcuni principi chiave: la notifica del data breach all’autorità sarà richiesta solo in caso di rischio elevato per i diritti e le libertà degli interessati; la finestra temporale per la comunicazione viene estesa a 96 ore; e viene introdotto un modello “report once, share many”, che consente di effettuare un’unica notifica valida per più obblighi regolatori. Questo approccio mira a ridurre la frammentazione attuale, in cui organizzazioni soggette contemporaneamente a GDPR, NIS2 o DORA si trovano spesso a dover gestire flussi duplicati di segnalazioni verso autorità diverse.

Risvolto concreto per le aziende: per le aziende, l’impatto sarà duplice: da un lato una significativa riduzione delle duplicazioni di reporting e una gestione più efficiente degli incidenti; dall’altro la necessità di adeguare i workflow interni, rivedere i processi di escalation e allineare i sistemi tecnici e le procedure interne al funzionamento del single entry point europeo. Il nuovo modello richiederà quindi un adattamento organizzativo, ma promette di razionalizzare nel medio periodo uno degli ambiti più complessi della conformità digitale europea.

e) Tracking technologies: regime unico sotto il GDPR

Il Digital Omnibus interviene in modo strutturale sulla disciplina del tracciamento online, spostando definitivamente sotto il perimetro del GDPR tutto ciò che oggi ricade nella normativa ePrivacy: cookie, fingerprinting, tecniche di cross-device tracking e sistemi di rilevazione integrati nei veicoli. La logica è quella di eliminare la sovrapposizione tra fonti normative e riportare in un unico testo gli obblighi legati all’acquisizione del consenso, alle eccezioni e alle modalità con cui gli utenti possono esprimere opposizione.

Il contenuto dell’ePrivacy viene trasferito nel GDPR attraverso l’introduzione del nuovo articolo 88a, mentre il nuovo articolo 88b disciplina i segnali di consenso e opposizione in formato machine-readable, destinati a essere integrati nei browser e nei dispositivi. Questi segnali avranno valore giuridico vincolante e dovranno essere automaticamente accettati dai siti, segnando il passaggio da un sistema frammentato basato sui banner a un modello più standardizzato, in cui la scelta dell’utente viene registrata a livello di sistema operativo o browser. L’obiettivo dichiarato è quello di superare l’attuale proliferazione di interfacce di scelta, ridurre la cosiddetta cookie fatigue e rendere più trasparenti e verificabili le preferenze dell’utente.

La proposta chiarisce inoltre il perimetro delle eccezioni: restano ammesse le operazioni strettamente necessarie alla trasmissione della comunicazione, all’erogazione del servizio richiesto, alla sicurezza e all’audience measurement in forma aggregata. Contestualmente viene introdotto un periodo di cooling-off di sei mesi successivo al rifiuto, durante il quale non sarà possibile riproporre richieste di consenso analoghe, a meno che non intervengano elementi nuovi o modifiche sostanziali al trattamento.

Risvolto concreto per le aziende: per le aziende digitali il cambiamento è significativo: i meccanismi di gestione del consenso dovranno essere ripensati alla luce di segnali tecnici standardizzati a livello europeo, con un impatto diretto sulle CMP, sui flussi interni e sull’esperienza utente. Il risultato atteso è una riduzione dei banner e una maggiore automazione nella gestione delle preferenze. Per gli editori è inoltre previsto un regime dedicato, che tiene conto delle specificità del settore e del ruolo dei media service provider.

f) Oneri di trasparenza e valutazione d’impatto: cosa cambia

Il Digital Omnibus interviene anche sul sistema degli obblighi di trasparenza e sulle valutazioni d’impatto privacy, con modifiche che hanno un impatto diretto sia sulle imprese multinazionali sia sulle organizzazioni che operano su scala transfrontaliera. Una novità importante riguarda l’armonizzazione europea delle liste dei trattamenti che richiedono una valutazione d’impatto (DPIA) ai sensi dell’art. 35 del GDPR e di quelli che ne sono esclusi, accompagnata dall’introduzione di template e metodologie standard da utilizzare in tutta l’Unione. Questo intervento punta a superare una delle criticità più evidenti degli ultimi anni: la moltiplicazione di interpretazioni divergenti sulla necessità di porre in essere o meno una valutazione d’impatto documentata prima che si inizi un trattamento.

A queste misure si affianca un intervento sull’art. 13 GDPR. La proposta chiarisce che gli obblighi informativi possono essere alleggeriti nei contesti in cui il trattamento avviene all’interno di una relazione chiara e circoscritta con l’interessato, in assenza di attività ad alto rischio o di informazioni rilevanti mancanti. Quando il trattamento è poco “intensivo” e il titolare può ragionevolmente presumere che l’interessato sia già a conoscenza delle informazioni principali, alcune delle prescrizioni dell’art. 13 possono non applicarsi; restano invece pienamente operative in caso di:

• trasmissione a destinatari ulteriori;

• trasferimenti verso Paesi terzi;

• decisioni automatizzate ad alto rischio; o

• trattamenti che comportano un rischio significativo per i diritti e le libertà degli interessati.

Risvolto concreto per le aziende: per le imprese - in particolare per i gruppi multinazionali che operano in più Stati membri - l’adozione di criteri uniformi per le DPIA riduce in modo significativo le incertezze interpretative e le duplicazioni documentali, mentre l’approccio più proporzionato alla trasparenza consente di evitare obblighi ridondanti nei trattamenti ordinari e a basso rischio. L’impatto è però significativo anche per startup e PMI, che beneficiano di un alleggerimento concreto degli oneri informativi quando il rapporto con l’interessato è circoscritto, il trattamento è limitato e il rischio, conseguentemente, risulta contenuto.

e) Focus sulla ricerca scientifica

La proposta del Digital Omnibus interviene anche sulla disciplina della ricerca scientifica, introducendo chiarimenti rilevanti per università, enti pubblici, ospedali, imprese e soggetti che sviluppano tecnologie data-driven e sistemi di intelligenza artificiale. In primo luogo viene aggiornata la definizione di “ricerca scientifica” contenuta nella proposta di modifica all’art. 4 GDPR, ampliandone la portata e ricomprendendo non solo le attività accademiche tradizionali, ma anche quelle che contribuiscono allo sviluppo tecnologico, alla dimostrazione e all’applicazione innovativa della conoscenza. La definizione chiarisce inoltre che la ricerca può essere svolta anche in contesti non accademici e che la finalità commerciale non ne esclude la qualificazione come ricerca scientifica, purché siano rispettati gli standard etici previsti per il settore.

In parallelo, la modifica all’art. 5 GDPR specifica che l’ulteriore trattamento dei dati per finalità di ricerca scientifica può essere considerato compatibile con la finalità iniziale, indipendentemente dalle condizioni previste dall’art. 6(4). Questo chiarimento rafforza la certezza giuridica per i progetti in cui dati raccolti per finalità primarie - ad esempio assistenza sanitaria, erogazione di un servizio o gestione amministrativa - devono essere successivamente riutilizzati per attività di ricerca. Il riuso è ammesso nell’ambito delle garanzie dell’art. 89 GDPR, e consente una gestione più lineare dei flussi informativi tra ospedali, centri di ricerca, università e imprese.

Risvolto concreto per le aziende: nel complesso, gli interventi sugli artt. 4 e 5 del GDPR rendono più lineare la valutazione della compatibilità dei trattamenti per finalità di ricerca e forniscono un perimetro più definito per il riuso dei dati in contesti scientifici e industriali. Per le organizzazioni che conducono progetti di ricerca applicata o sviluppano sistemi di AI nel contesto della ricerca scientifica, ciò significa poter operare con un quadro regolatorio più prevedibile, in un contesto storicamente caratterizzato da incertezza interpretativa.

Cosa aspettarsi nei prossimi mesi

Con la presentazione del Digital Omnibus, le due proposte legislative avviano ora il loro percorso nell’ambito del procedimento legislativo ordinario. Durante questa fase, Parlamento europeo e Consiglio potranno intervenire in modo significativo sui testi, con la possibilità di:

• introdurre emendamenti;

• modificare o alleggerire alcune parti;

• irrigidire determinati obblighi; oppure

• riscrivere intere sezioni qualora lo ritengano necessario.

Il risultato finale potrà quindi differire anche in misura rilevante rispetto alle bozze attualmente pubblicate.

Sul piano economico, la Commissione stima che il pacchetto possa generare risparmi amministrativi fino a circa 1 miliardo di euro l’anno, con un effetto cumulato potenziale di circa 5 miliardi di euro entro il 2029, in funzione dell’esito del processo legislativo e delle modalità attuative negli Stati membri.

Si tratta di valori previsionali che sintetizzano l’obiettivo dichiarato del Digital Omnibus: ridurre la complessità amministrativa e migliorare l’efficienza complessiva del sistema regolatorio europeo.

Alcune riflessioni finali

Il Digital Omnibus si propone di intervenire su più livelli del quadro digitale europeo con un obiettivo comune: allineare le norme esistenti, chiarirne l’applicazione e concentrare in un insieme più coerente discipline oggi distribuite in testi normativi diversi, nel tentativo di ridurre la frammentazione che negli anni ha contribuito ad aumentare la complessità regolatoria per aziende e istituzioni europee.

In questa prospettiva, il Digital Omnibus rappresenta un passaggio significativo all’interno della strategia europea dedicata allo shaping Europe’s digital future: un lavoro di riallineamento e integrazione delle regole che mira a renderne più lineare e interoperabile l’applicazione pratica, consentendo alle imprese di operare con maggiore prevedibilità in un contesto sempre più interconnesso. Si tratta infatti di una proposta mirata alla semplificazione dell’ecosistema normativo europeo, con l’intento di creare le condizioni più favorevoli allo sviluppo di servizi e tecnologie digitali nel mercato unico.

Per le aziende il messaggio è chiaro: la direzione non è “meno regole” tout court, ma regole più leggibili e integrate, che permettono di innovare riducendo la complessità e gli oneri amministrativi. Una sfida che apre a nuove possibilità, purché affrontata con consapevolezza, capacità di adattamento e una visione strategica.

Condividi

Lascia un commento

Prendiamo un caffè digitale

Dati utilizzati

LinkedIn potrà raccogliere e utilizzare per l’addestramento del suo sistema di IA generativa tutti i contenuti pubblici, tra cui:

• Dati del profilo: nome, foto, posizione lavorativa attuale, esperienza professionale, formazione, località, competenze, certificazioni, licenze, esperienze di volontariato, pubblicazioni, brevetti, conferme di competenze e referenze

• Dati relativi alle offerte di lavoro: risposte a domande per la selezione e curriculum vitae

• Dati di gruppo: attività e messaggi di gruppo

• Contenuti: post, articoli, risposte a sondaggi, contributi e commenti (in tutti i formati) degli utenti

• Feedback: dati relativi a feedback e miglioramenti, che possono includere richieste di supporto da parte di utenti, reazioni con pollice in su/giù ai suggerimenti generati dall’IA, nonché segnalazioni di problemi relativi ai contenuti di IA generativa

• Dati di interazione con le funzionalità dell’IA generativa: contenuti che gli utenti immettono nelle funzionalità di IA generativa (ad esempio testo delle ricerche, richieste e domande)

Dati protetti

Esistono categorie di dati che rimangono escluse dall’utilizzo per scopi di addestramento IA, garantendo in ogni caso una tutela “base” della privacy degli utenti. LinkedIn ha infatti dichiarato che, per addestrare i propri modelli di IA generativa, non intende utilizzare:

• Messaggi privati e conversazioni dirette degli utenti

• Credenziali di accesso delle utenze

• Dati relativi a metodi di pagamento e carte di credito

• Dati sulla retribuzione forniti dagli utenti e i dati relativi alle candidature attribuibili a un utente specifico

I servizi basati su IA che LinkedIn mette a disposizione degli utenti

La raccolta di queste informazioni consente a LinkedIn di alimentare alcune funzionalità di intelligenza artificiale generativa, finalizzate a migliorare l’esperienza professionale sulla piattaforma. Tra queste rientrano:

• Funzionalità di supporto all’utente: gli utenti possono fornire dati personali come input in strumenti di IA generativa (es. Suggerimenti di scrittura o Suggerimenti di scrittura per il profilo). L’IA elabora questi dati per proporre testi o contenuti che l’utente può rivedere, modificare e approvare prima della pubblicazione

• Suggerimenti di lavoro e strumenti di recruiting: LinkedIn può trattare informazioni come qualifica, anni di esperienza, curriculum o risposte a candidature per generare contenuti personalizzati e migliorare funzionalità come la ricerca e i suggerimenti di offerte di lavoro, strumenti di selezione per i recruiter (es. Hiring Assistant) o post e profili consigliati

• Interazioni e miglioramento dei modelli: quando l’utente interagisce con una funzionalità di IA (input, output, preferenze linguistiche, feedback), tali dati possono essere raccolti per analisi e ottimizzazione del servizio

La facoltà di opt-out: come opporsi

L’impostazione “Dati per migliorare l’IA generativa” risulta attiva per impostazione predefinita, poiché LinkedIn fonda tale trattamento sulla base giuridica del legittimo interesse. Di conseguenza, i dati personali degli utenti vengono automaticamente utilizzati per l’addestramento e il miglioramento dei modelli di intelligenza artificiale, salvo che l’utente eserciti il proprio diritto di opposizione.

Esercitando tale diritto, l’utente può impedire che i propri dati personali presenti su LinkedIn vengano utilizzati per addestrare o perfezionare sistemi di IA generativa.

Per farlo, LinkedIn offre due modalità di opposizione:

1. Toogle switch: il link, una volta effettuato l’accesso, reindirizza l’utente alla sezione delle impostazioni sulla privacy di LinkedIn, dove è possibile disattivare l’opzione tramite l’apposito pulsante

2. Modulo online: il link rimanda alla pagina dedicata predisposta da LinkedIn per l’esercizio del diritto di opposizione. All’interno del modulo online, nel menu a tendina posto sotto la voce “Selezionare il tipo di richiesta di opposizione o restrizione”, è necessario selezionare l’opzione “Opposizione al trattamento per l’addestramento dei modelli di IA finalizzati alla creazione di contenuti”. La richiesta può essere inviata senza l’obbligo di fornire alcuna motivazione aggiuntiva

Per maggior informazioni e per approfondire l’IA generativa applicata (d)a LinkedIn, suggerisco un’occhiata alle FAQ in materia.

In un ecosistema digitale sempre più guidato dall’intelligenza artificiale, la trasparenza sull’uso dei dati resta il presupposto essenziale per garantire fiducia, responsabilità e controllo dell’utente. Le nuove tecnologie possono infatti semplificare il modo in cui comunichiamo e lavoriamo, ma non devono mai farci dimenticare che l’innovazione è sostenibile solo se rimane sotto il nostro controllo.

Lascia un commento

Chi sono

Prendiamo un caffè digitale

Tra un mese, a partire dal 20 novembre ed entro il 31 dicembre 2025, ogni organizzazione soggetta alla normativa NIS dovrà infatti designare il proprio referente CSIRT, figura distinta dal Punto di Contatto già nominato in fase di registrazione, attraverso l’apposita procedura telematica sul Portale ACN.

👤 Chi è e cosa fa

Il referente CSIRT è una persona fisica designata dal Punto di Contatto NIS, incaricata di rappresentare l’organizzazione nei rapporti con il CSIRT Italia, l’organo tecnico nazionale che coordina la risposta agli incidenti informatici.
Svolge in particolare:

• la notifica degli incidenti significativi e rilevanti di cui agli artt. 25 e 26 del decreto NIS;

• il coordinamento operativo con il CSIRT Italia per la gestione e il follow-up degli incidenti.

🤝 Sostituti e requisiti

Per garantire la tempestività delle comunicazioni, possono essere nominati uno o più sostituti del referente CSIRT, che lo supportano e possono agire in sua vece.
Sia il referente sia i sostituti devono possedere almeno:

• competenze di base in sicurezza informatica e incident management;

• conoscenza approfondita dei sistemi informativi e delle reti dell’organizzazione per cui operano.

  

⚙️ Implicazioni pratiche

La nuova figura mira a rafforzare la capacità di risposta agli incidenti nelle varie organizzazioni e a semplificare la gestione degli adempimenti NIS, creando un canale di comunicazione stabile tra ogni soggetto NIS e il CSIRT Italia.

Quest’ultima diventerà il punto di riferimento per tutte le notifiche di incidenti significativi e rilevanti, assicurando tracciabilità, uniformità e maggiore coordinamento tecnico tra gli operatori, l’ACN e le Autorità competenti. Si tratta, in sostanza, di un presidio operativo che contribuisce a “professionalizzare” e rendere più prevedibile la gestione delle crisi cyber.

Per le PMI, spesso prive di strutture informatiche interne, la possibilità di nominare un referente (anche esterno) rappresenta una semplificazione concreta: consente di centralizzare gli adempimenti e gestire in modo più efficace i rapporti con l’ACN e il CSIRT Italia.

Sotto il profilo organizzativo, le organizzazioni dovranno avviare un’attività di revisione interna delle policy e dei flussi di incident management, assicurando il coordinamento tra referente CSIRT e punto di contatto NIS, nonché con il DPO, il CISO, l’IT manager e il management aziendale.

🧠 Perché è rilevante

L’introduzione del referente CSIRT semplifica la gestione degli adempimenti per le organizzazioni soggette alla normativa NIS, ma impone un coordinamento interno e un allineamento procedurale e operativo ed anche una maggiore attenzione ai profili contrattuali nel caso di referenti esterni: serve disciplinare con precisione responsabilità, riservatezza, accesso ai sistemi e tempi di risposta, assicurando un flusso comunicativo stabile con il punto di contatto interno.

Ottobre chiude un mese di passaggi cruciali per la regolazione digitale.
La rubrica “DPO News” continuerà a seguirne gli sviluppi, con l’obiettivo di restare un punto di orientamento affidabile in un panorama in continua evoluzione.

Lascia un commento

Chi sono

Prendiamo un caffè digitale

prima di chiudere i laptop e mettere via il badge aziendale, un ultimo aggiornamento – ma niente paura, questa volta niente pipponi su nuove linee guida o maxi sanzioni!

Sì, lo so, in queste settimane si è parlato di tutto: codice di condotta sui modelli di AI Generativi dell’AI Office, nuove indicazioni del Garante in materia di c.d. double opt-in, il solito fermento attorno all’EDPB… tutto molto interessante, ma onestamente, non so quante energie vi e ci rimangono per digerire ancora le tante news che si susseguono nel variegato panorama del diritto del digitale :)

💡 E quindi?

Vi accompagno con una newsletter dal tono più vacanziero, per raccontarvi anche un po’ il lato umano dell’avvocato della privacy e DPO – sì, anche noi andiamo in ferie (o almeno ci proviamo!).

Quest’anno mi dividerò tra la mia base estiva nelle location di Montalbano (nel ragusano), qualche passeggiata vista mare e incursioni gastronomiche sicule, con qualche tappa pugliese/salentina nel mezzo per non farci mancare nulla.

📸 Vi carico anche una foto dalla mia postazione “smart working con vista” per ricordarvi che il GDPR non va in ferie…

Verso fine agosto prenderò il volo per un viaggio con direzione Australia per andare a trovare una coppia di amici con base nei dintorni di Sydney e girare un pò (sperando di non beccare animali troppo “esotici” a farci compagnia…..).

L’occasione è ghiotta per sondare contestualmente il terreno rispetto ad alcune recenti novità normative locali che hanno introdotto proprio nella “terra dei canguri” l’obbligo di denuncia per i pagamenti effettuati a seguito di attacchi ransomware o estorsioni informatiche - introdotto nell'ambito del Cyber Security Act 2024 con le Cyber Security (Ransomware Payment Reporting) Rules 2025. Un precedente che in effetti potrebbe risultare interessante anche per l’Italia…

Dalla seconda settimana di settembre tornerò ufficialmente operativo e pronto per nuove avventure! :)

Resterò comunque reperibile per le urgenze, i soliti dubbi dell’ultimo minuto e anche per chi vorrà organizzare le attività d’autunno con anticipo – perché sì, settembre arriverà più veloce di quanto pensiamo!

📩 Quindi scrivetemi/chiamatemi pure, alla peggio mi troverete con un arancino (rigorosamente al maschile!) in mano.

Buone vacanze a tutti! 🌊🍹

Il documento offre spunti interessanti per organizzazioni, istituzioni e imprese, nonché per noi professionisti a “contatto” con il digitale. In questo episodio della rubrica “DPO News” analizziamo i passaggi più rilevanti e gli aspetti operativi da gestire nell’implementare o adottare sistemi basati su intelligenza artificiale.

⭕Un passo indietro: cos’è l’AI Act e perché ci riguarda da vicino?

Approvato definitivamente a metà 2024 e pubblicato nella Gazzetta Ufficiale dell’UE il 12 luglio 2024, l’AI Act (che introduce obblighi differenziati in funzione del rischio e specifici requisiti per i sistemi utilizzati) è la prima normativa orizzontale al mondo sull’intelligenza artificiale.

Nasce per:

• migliorare il funzionamento del mercato unico europeo;

• garantire uno sviluppo dell’IA centrato sull’uomo e affidabile;

• tutelare i diritti fondamentali;

• promuovere l’innovazione responsabile.

Il regolamento si applica tanto agli sviluppatori quanto agli utilizzatori di sistemi di IA, con attenzione crescente verso i modelli di IA generativa e general-purpose (GPAI), come ChatGPT o Claude.

⭕ Una roadmap a più velocità: le scadenze ufficiali

Il regolamento è entrato in vigore nel 2024, facendo scattare i primi obblighi in tema di alfabetizzazione digitale e pratiche vietate a decorrere del 2 febbraio 2025, prevede adesso un’ulteriore fase di attuazione graduale. Secondo la timeline ufficiale:

• 2 agosto 2026: è la data generale di applicazione, a partire dalla quale si applicheranno tutte le disposizioni principali, incluse quelle sanzionatorie e di enforcement (Cap. 9).

• Alcuni obblighi, in particolare quelli legati ai modelli GPAI e agli standard armonizzati, saranno attivati prima o dopo, con strumenti di soft law in corso di definizione (codici di condotta, linee guida, standard tecnici).

• L’attuazione completa dell’AI Act è prevista entro il 2027.

L’AI Act prevede infatti anche strumenti di soft law a supporto dell’applicazione:

• Art. 56 – Codice di condotta GPAI: per promuovere l’autoregolamentazione dei fornitori di modelli general-purpose.

• Art. 95 – Codici di condotta settoriali: per facilitare la compliance nei diversi settori.

• Art. 96 – Linee guida della Commissione: documenti interpretativi per chiarire l’applicazione pratica del regolamento.

⭕ Il ruolo degli standard armonizzati (Art. 40 AI Act)

Gli standard armonizzati sono strumenti tecnici, sviluppati da organismi europei di normazione su richiesta della Commissione europea, che offrono una presunzione di conformità a chi li adotta.

➡️ Cosa vuol dire in concreto?
Che se un sistema di IA ad alto rischio è progettato, sviluppato e valutato in conformità agli standard armonizzati pubblicati nella Gazzetta Ufficiale, allora si presume conforme all’AI Act. Questo riduce i rischi legali, facilita gli audit e “alleggerisce” l’onere probatorio in caso di verifica delle Autorità.

⭕ Il JRC: chi è e cosa dice

Il documento dell’EPRS cita l’analisi del JRC – Joint Research Centre, ossia il Centro Comune di Ricerca della Commissione Europea, organo scientifico interno alla Commissione che supporta le politiche pubbliche con evidenze scientifiche.

Il JRC ha sottolineato che è essenziale che gli standard armonizzati siano pubblicati prima dell’agosto 2026, cioè prima che entrino in vigore gli obblighi per i sistemi ad alto rischio (es. strumenti HR per selezione CV, credit scoring, ambiti sanitari o educativi).

🛑 Tuttavia, ci sono ritardi: gli standard sono stati richiesti a CEN e CENELEC (i principali enti europei di normazione tecnica) a maggio 2023 con scadenza aprile 2025, ma i lavori proseguiranno oltre il 2026. Si discute di soluzioni temporanee, tra cui specifiche tecniche provvisorie o interpretazioni ufficiali, per evitare un vuoto normativo.

⭕ Cosa fare oggi?

La prima attività da svolgere è certamente un censimento e una mappatura dei sistemi di AI all’interno delle aziende.

Questa prima fondamentale operazione non può trascendere da un’analisi, caso per caso, dei sistemi di intelligenza artificiale da adottare o integrare all’interno di ciascuna organizzazione.

Da questo primo assessment, che può essere svolto tramite apposite checklist o con il parziale ausilio di alcuni tool come questo, dovranno essere ricostruiti:

• il ruolo di ciascuna organizzazione, tanto sotto il profilo definitorio dettato dall’AI Act (provider, deployer, importatore, etc.), quanto sotto quello data protection (titolare, responsabile, contitolare, etc.);

• la finalità e le modalità di utilizzo del modello di AI, per valutare il livello di rischio associato e le operazioni conseguenti (addestramento del modello, attività di retrieval augmented generation, operazioni di fine-tuning, retraining, etc.), con tutte le conseguenze del caso;

• la base di liceità a fondamento delle attività di arricchimento, addestramento e/o fine-tuning, retraining dei modelli di AI che, ove individuata nel legittimo interesse ai sensi dell’articolo 6, paragrafo 1, lett. f) del GDPR, dovrebbe prevedere un test tripartito (c.d. Legitimate Interest Assessment) come evidenza documentale.

Per gestire queste attività, un primo spunto pratico è contenuto all’interno dell’Opinion 28/2024 dell’European Data Protection Board on certain data protection aspects related to the processing of personal data in the context of AI models che detta istruzioni utili su come gestire gli aspetti di conformità rispetto all’AI Act e di trattamento dei dati sottostante i modelli di AI - specie ove questi mirino ad essere considerati come anonimi.

Tra questi, al paragrafo 58 dell’Opinion, viene definito un iter, come di seguito articolato:

1. DPIA o motivazione dell’assenza
   Il titolare dovrebbe stendere una DPIA oppure una valutazione ragionata che giustifichi la non necessità di effettuarla, in linea con l’art. 35 GDPR.

2. Contributo del DPO
   Deve esserci evidenza di un coinvolgimento effettivo del DPO (ove nominato), come previsto dagli articoli 38–39 GDPR.

3. Misure in fase di progettazione dell’IA
   Le misure tecniche e organizzative adottate ex ante per evitare la reidentificazione (es. pseudonimizzazione, riduzione granularità dei dati), basate su un threat model e analisi dei rischi. Devono essere tracciabili le fonti dei dataset di training (URL, descrizione, misure attuate anche da fornitori terzi).

4. Misure lungo tutto il ciclo di vita del modello
   Occorre documentare i controlli e i meccanismi implementati per evitare che il modello apprenda o restituisca dati personali, lungo tutte le fasi del suo sviluppo e utilizzo.

5. Test di resistenza alla c.d. re-identificazione
   Serve dimostrare:

   • l’analisi teorica del rischio di re-identificazione;

   • i test effettuati (da chi, quando, come);

   • le metriche utilizzate (es. rischio di membership inference, regurgitation, ecc.);

   • il rapporto tra dimensione dei dati e numero di parametri del modello (indicatore critico nei foundation model).

6. Informazioni agli interessati
   La documentazione fornita a chi utilizza il modello (o ai soggetti interessati) deve esplicitare:

   • le misure per ridurre il rischio di identificazione;

   • i rischi residui, se presenti.

   ---

Lascia un commento

Chi sono

Prendiamo un caffè digitale

In particolare, gli aspetti che seguono sono stati oggetto di ispezione da parte dell’Autorità:

⭕metadati di posta elettronica,

⭕log di navigazione in Internet,

⭕dati conservati nei sistemi di ticketing,

⭕perimetro delle nomine a responsabile del trattamento.

Le principali criticità rilevate

1. Controlli a distanza per mezzo dei metadati relativi alle caselle email: la Regione conservava per 90 (novanta) giorni i metadati delle email raccolti su Microsoft 365. A tal riguardo, in sede di istruttoria, il Garante ha rilevato la presenza, in relazione ai trattamenti in questione, di un accordo collettivo con le competenti parti sindacali per quanto concerne sia il personale dirigenziale che non dirigenziale. In tale contesto, l’Autorità ha ribadito l’approccio restrittivo con cui deve applicarsi la deroga prevista dall’art. 4, comma 2, della l. n. 300/1970 (Statuto dei Lavoratori), potendosi ricomprendere solo servizi, software o applicativi strettamente funzionali alla prestazione lavorativa. Al contrario, nel caso di sistemi che agiscano con modalità non percepibili dal lavoratore e in modo del tutto indipendente rispetto alla normale attività dello stesso oppure in presenza di sistemi che non sono solo funzionali alla prestazione ma consentono anche ulteriori elaborazioni da parte del datore di lavoro per il perseguimento di proprie finalità e specie nei casi in cui tali funzionalità non possano essere disabilitate dal dipendente, si rischia di sfociare in un indiretto controllo a distanza dell’attività lavorativa, ricadendo nel comma 1 dell’art. 4 dello Statuto dei Lavoratori e richiedendo pertanto l’attivazione dei relativi presidi (accordo sindacale o istanza autorizzativa all’Ispettorato del Lavoro territorialmente competente).

   Pertanto:

   ⭕l’attività di raccolta e conservazione dei soli metadati necessari ad assicurare il funzionamento delle infrastrutture del sistema della posta elettronica e il soddisfacimento delle più essenziali garanzie di sicurezza informatica, all’esito di valutazioni tecniche e nel rispetto del principio di responsabilizzazione, potrà essere effettuata, di norma e come già sancito all’interno del Documento di indirizzo “Programmi e servizi informatici di gestione della posta elettronica nel contesto lavorativo e trattamento dei metadati”, per un periodo limitato a pochi giorni, comunque non superiore ai 21 (ventuno) giorni, salvo che il titolare, comprovi adeguatamente la ricorrenza in concreto di particolari condizioni che ne rendano necessaria l’estensione in ragione delle specificità della propria realtà tecnica e organizzativa. In tal caso, di norma non sarà necessario attivare le garanzie previste dallo Statuto dei Lavoratori, essendo improbabile che da tale attività possa scaturire un controllo anche indiretto dell’attività lavorativa;

   ⭕la generalizzata raccolta e la conservazione dei metadati di posta elettronica, per un lasso di tempo più esteso, in presenza di esigenze comunque riconducibili alla sicurezza e alla tutela del patrimonio anche informativo del datore di lavoro, potendo comportare un indiretto controllo a distanza dell’attività dei lavoratori, richiede invece l’esperimento delle garanzie previste dall’art. 4, comma 1, del predetto Statuto dei Lavoratori. Nel caso in esame, nonostante la Regione avesse adottato tali presidi (e nello specifico, l’accordo con le rappresentanze sindacali, nonché ulteriori misure di mitigazione e minimizzazione, come l’accesso ai report risalenti di 7 giorni “attraverso un report in formato CSV”) è stata valutata come sanzionabile in quanto, le misure adottate, non risultavano comunque idonee con riferimento all’arco temporale anteriore alla stipula dei predetti accordi collettivi.

   ---

2. Controlli a distanza per mezzo dei log di navigazione: la Regione ha conservato per una tempistica pari a 12 (dodici) mesi i log di navigazione. In particolare, la Regione raccoglieva e conservava i log di navigazione in Internet - consistenti in informazioni inerenti ai siti web visitati dai dipendenti, inclusi quelli relativi ai tentativi falliti di accesso ai siti censiti in una apposita black list - entrando in possesso di informazioni non attinenti all’attività lavorativa e relative alla sfera privata dei dipendenti. Ciò, seppur in presenza di un accordo sindacale, come richiesto dall’art. 4, comma 1, dello Statuto dei Lavoratori, non è risultato conforme ai principi di minimizzazione, limitazione della finalità e della conservazione, in particolare per l’arco temporale pregresso alla sottoscrizione dei suddetti accordi.

   ---

3. Tempistiche di conservazione dei dati sul sistema di ticketing: l’Autorità ha rilevato come la conservazione dei dati relativi alle richieste di assistenza tecnica di cui al dismesso sistema “OTRS” risulta essersi protratta per un periodo temporale particolarmente esteso. In particolare, dalla documentazione acquisita in sede ispettiva è emerso come le richieste di assistenza tecnica del personale dipendente di cui la Regione conservava ancora traccia risalivano al 2016 - nonostante le politiche adottate dalla Regione prevedessero un periodo massimo complessivo di 78 mesi. Non rinvenendosi adeguate ragioni che potessero giustificare una conservazione tanto prolungata dei dati in questione, il Garante ha concluso nella direzione per cui il trattamento dei dati relativi alle richieste di assistenza tecnica di cui al dismesso sistema “OTRS” è stato effettuato in contrasto con i principi di limitazione della conservazione e di protezione dei dati personali fin dalla progettazione e per impostazione predefinita, in violazione degli artt. 5, par. 1, lett. e), e 25 del GDPR.

   ---

4. Difetto di DPIA: mancata valutazione d’impatto (DPIA) ex art. 35 GDPR sui trattamenti svolti, considerati come ad alto rischio da parte del Garante, tenuto conto della riferibilità a categorie vulnerabili di soggetti, quali sono considerati i dipendenti nel contesto lavorativo, e della possibile attività di monitoraggio sistematico sottostante.

   ---

5. Responsabili del trattamento: il Garante ha riscontrato anche un’inadeguata formalizzazione del perimetro contrattuale con i fornitori, in particolare per i dati gestiti nel sistema di ticketing OTRS, successivamente dismesso dalla Regione, che non risultava disciplinato all’interno degli atti di nomina ex art. 28 del GDPR con i fornitori.

   ---

Le sanzioni irrogate: multa pecuniaria e misure correttive
Il Garante, oltre alla sanzione amministrativa pecuniaria pari a 50 mila euro, ha ingiunto una serie di misure correttive alla Regione, tra cui:

• l’anonimizzazione dei log relativi ai tentativi di accesso falliti ai siti web censiti nella black-list;

• la cifratura del dato concernente i nomi dei dipendenti assegnatari dei pc portatili;

• la riduzione da 365 a 90 (novanta) giorni del termine di conservazione dei log di navigazione in Internet, con possibilità di conservazione per un periodo ulteriore previa anonimizzazione degli stessi, in modo da non consentire l’identificabilità del dipendente, e ferma restando la cancellazione dei dati personali presenti nei log di navigazione web registrati nei sistemi da oltre 90 giorni;

• in caso di anomalie di sicurezza, l’imposizione di verifiche graduali e progressive, a livello di singole strutture organizzative e non invece a livello individuale, limitando la possibilità di interventi granulari e puntuali sulla singola postazione di lavoro ai soli casi di previo e infruttuoso esperimento di verifiche a livello aggregato;

• la cifratura del dato concernente i nomi dei dipendenti assegnatari della macchina, fornendo a tal riguardo specifiche istruzioni documentate al fornitore che, in qualità di responsabile del trattamento, tratta tali dati per conto e nell’interesse della Regione medesima.

La Regione, in un’ottica proattiva, ha inoltre proposto l’adozione delle seguenti misure, accolte positivamente dallo stesso Garante:

• aggiornamento del decreto interno infotelematico;

• predisposizione un addendum contrattuale con i fornitori del sistema di ticketing per regolare il perimetro del trattamento e degli strumenti adoperati;

• introduzione di un sistema di conservazione dei ticket con anonimizzazione post 12 mesi.

  ---

Spunti operativi
Il provvedimento in oggetto rappresenta un riferimento concreto per i DPO, gli uffici compliance e i privacy manager di organizzazioni pubbliche e private, circa:

• la corretta mappatura dei trattamenti interni nel contesto lavorativo, e in particolare riferiti ai metadati delle caselle di posta elettronica e log di navigazione, nonché dei relativi limiti, sia di natura temporale, che in base alla finalità perseguita;

• la corretta applicazione delle garanzie previste dall’art. 4 della L. 300/1970 in caso di trattamento di metadati e dati di navigazione riferiti ai dipendenti nel contesto lavorativo. Nel caso si opti per lo strumento dell'accordo sindacale, occorrerà rappresentare preliminarmente alle RSU gli aspetti vincolanti derivanti dalle licenze con i provider dei sistemi di posta elettronica che in alcuni casi non consentono una personalizzazione delle tempistiche di retention dei metadati raccolti (es. Microsoft);

• la tendenziale necessità di una DPIA anche per trattamenti apparentemente potenzialmente “meno invasivi”;

• la formalizzazione contrattuale di tutti i dettagli del trattamento, sistemi e strumenti che i fornitori possano adoperare per conto del titolare nelle operazioni di trattamento dati di titolarità di quest’ultimo nell’ambito della gestione dei dati dei dipendenti nel contesto lavorativo (es. sistemi di ticketing).

L’Autorità ha richiamato l’importanza di adottare misure “by design e by default” ex art. 25 GDPR, specialmente per trattamenti che, pur finalizzati alla sicurezza, possono facilmente sconfinare in attività di controllo sistematico.

Lascia un commento

Chi sono

Prendiamo un caffè digitale

Questa scelta si inserisce in un contesto normativo in forte fermento, in cui le piattaforme digitali si muovono con crescente cautela a fronte delle normative europee, in primis GDPR e AI Act, e della sensibilità sempre più crescente da parte di utenti e aziende in materia di trasparenza, controllo e accountability.

Cosa prevede Meta?

Meta chiarisce che utilizzerà alcune informazioni pubbliche come i commenti e post pubblici degli account di persone di almeno 18 (diciotto) anni e le interazioni con le funzioni di IA in Meta, provenienti dai propri Prodotti (Facebook, Instagram, etc.) per migliorare le funzionalità dell’IA generativa interna (es. Meta AI, strumenti creativi, chatbot). Nello specifico, si tratta di:

⭕Nome e informazioni sul profilo (utente di Facebook e Instagram)

⭕ Immagine del profilo

⭕ Attività su gruppi pubblici, pagine Facebook e canali Meta

⭕ Attività su contenuti pubblici, come ad esempio: commenti, valutazioni o recensioni su Marketplace, o su un account Instagram pubblico

⭕ Avatar

Non saranno invece utilizzati i messaggi privati, salvo esplicito consenso espresso nella chat.

Tempistiche da conoscere: oggi è l’ultima chiamata

Il termine per impedire l’uso retroattivo dei propri contenuti pubblici è oggi, lunedì 26 maggio 2025. Dopo questa data, Meta potrà utilizzare i post, foto e commenti pubblici reperibili online sulle proprie piattaforme (Facebook, Instagram).

L'opposizione inviata dopo il 26 maggio sarà valida solo per i contenuti successivi.

Una questione (anche) aziendale

Se da un lato questa possibilità riguarda gli utenti nella loro veste personale, dall’altro implica una riflessione importante per aziende, enti e istituzioni che utilizzano i canali Meta per la comunicazione digitale. Le pagine ufficiali, i profili business, i contenuti sponsorizzati, potrebbero rientrare infatti nella definizione di “informazioni pubbliche” ed essere dunque trattati per finalità di addestramento IA.

Cosa fare concretamente

Gli utenti possono compilare il modulo di opposizione ed esercitare il proprio opt out tramite:

• Facebook (mobile)

• Instagram (web)

L’opposizione si applica anche ad altri account gestiti tramite lo stesso centro account, ma occorre ripetere l’operazione per account non collegati.

In caso di opposizione, Meta invia un’email di conferma e garantisce che i dati non saranno usati per il futuro training dei modelli.

Lascia un commento

Ecco le principali novità introdotte nella proposta di modifica al GDPR avanzata il 21 maggio 2025 dalla Commissione Europea:

⭕Vengono aggiunte due nuove definizioni:

• "microimprese, piccole e medie imprese";

• "imprese a media capitalizzazione di piccole dimensioni”.

⭕ Registro delle attività di trattamento:
Si propone di abolire l'obbligo di predisposizione e tenuta del registro delle attività di trattamento per le organizzazioni che impiegano meno di 750 dipendenti, salvo che il trattamento effettuato sia suscettibile di presentare un rischio elevato ai sensi dell’articolo 35 del GDPR. In questo modo si innalza la soglia di esenzione di tenuta del registro, da 250 dipendenti a 750.

⭕ Codici di condotta:
Viene aggiunto un riferimento proprio alle SMC. La norma diventerebbe quindi: "Gli Stati membri, le autorità di controllo, il comitato e la Commissione incoraggiano l'elaborazione di codici di condotta destinati a contribuire alla corretta applicazione del presente regolamento, in funzione delle specificità dei vari settori di trattamento e delle esigenze specifiche delle micro, piccole e medie imprese, 𝒏𝒐𝒏𝒄𝒉é 𝒅𝒆𝒍𝒍𝒆 𝒊𝒎𝒑𝒓𝒆𝒔𝒆 𝒂 𝒎𝒆𝒅𝒊𝒂 𝒄𝒂𝒑𝒊𝒕𝒂𝒍𝒊𝒛𝒛𝒂𝒛𝒊𝒐𝒏𝒆 𝒅𝒊 𝒑𝒊𝒄𝒄𝒐𝒍𝒆 𝒅𝒊𝒎𝒆𝒏𝒔𝒊𝒐𝒏𝒊".

⭕ Certificazioni:
Operazione identica a quella effettuata sull'Art. 40.1 del GDPR in merito ai Codici di condotta. La norma diventerebbe quindi: "Gli Stati membri, le autorità di controllo, il comitato e la Commissione incoraggiano, in particolare a livello di Unione, l'istituzione di meccanismi di certificazione della protezione dei dati nonché di sigilli e marchi di protezione dei dati allo scopo di dimostrare la conformità al presente regolamento dei trattamenti effettuati dai titolari del trattamento e dai responsabili del trattamento. Sono tenute in considerazione le esigenze specifiche delle micro, piccole e medie imprese, 𝒏𝒐𝒏𝒄𝒉é 𝒅𝒆𝒍𝒍𝒆 𝒊𝒎𝒑𝒓𝒆𝒔𝒆 𝒂 𝒎𝒆𝒅𝒊𝒂 𝒄𝒂𝒑𝒊𝒕𝒂𝒍𝒊𝒛𝒛𝒂𝒛𝒊𝒐𝒏𝒆 𝒅𝒊 𝒑𝒊𝒄𝒄𝒐𝒍𝒆 𝒅𝒊𝒎𝒆𝒏𝒔𝒊𝒐𝒏𝒊".

Questa proposta di semplificazione, ancora soggetta ad iter di approvazione legislativa e dunque suscettibile di modifiche e/integrazioni, si colloca nel solco del principio di proporzionalità previsto dal GDPR, introducendo una distinzione operativa tra grandi aziende e SMC nel rispetto degli obblighi di accountability. Per le organizzazioni che contano tra i 250 e i 749 dipendenti, si aprono dunque nuove possibilità di ottimizzazione della compliance.

La proposta segue la procedura legislativa ordinaria ed entrerà in vigore il ventesimo giorno successivo alla pubblicazione nella Gazzetta ufficiale dell’UE.

Tuttavia:

• alcune misure specifiche (es. modifiche settoriali ai regolamenti 2016/1036, 2016/1037 e 2017/1129) prevedono un’applicazione differita, in raccordo con l’entrata in vigore del regolamento (UE) 2024/2809 sul listino delle borse europee e con le strategie ESG.

• in concreto, l’applicazione effettiva delle semplificazioni GDPR per le SMC è attesa per il 2026, salvo anticipazioni dovute a iter accelerati.

  ---

Lascia un commento

Struttura e governance del sistema

⭕ Titolare del trattamento: Ministero della Salute

⭕ Responsabile operativo: Agenzia Nazionale per i Servizi Sanitari Regionali (AGENAS)

Alimentazione del sistema

L’EDS sarà alimentato da dati provenienti da:

⭕ Strutture sanitarie e sociosanitarie

⭕ Enti del Servizio Sanitario Nazionale Sistema Tessera Sanitaria (TS)

⭕ Anagrafe Nazionale Assistiti (ANA)

Servizi attivati tramite EDS

Tra i servizi principali, è prevista l’attivazione del dossier farmaceutico, che integrerà le informazioni relative a prescrizioni ed erogazioni di farmaci contenute nei documenti del Fascicolo Sanitario Elettronico (FSE), nonché dai dati resi disponibili da TS e ANA.

Tempistiche

L’attuazione concreta del sistema è fissata entro il 31 marzo 2026, subordinatamente al completamento delle attività previste nell’ambito del progetto FSE 2.0.

Ruoli e responsabilità dei soggetti coinvolti

L’art. 17 dell’ EDS, disciplina l’accesso ai dati anonimizzati da parte di:

• Personale del Ministero della Salute

• AGENAS

• Regioni e Province autonome

• Enti pubblici e privati con finalità istituzionali di ricerca medica, biomedica ed epidemiologica

Tali soggetti potranno presentare ad AGENAS apposite richieste, corredate da un progetto di ricerca conforme ai requisiti metodologici, etici e deontologici, con riferimento alle Prescrizioni del Garante Privacy per il trattamento dei dati a fini di ricerca scientifica (cfr. Autorizzazione Generale n. 9/2016), nonché alle recenti prescrizioni relative al trattamento di categorie particolari di dati di cui al Provvedimento 13 febbraio 2025 del Garante privacy, in osservanza delle recenti novità introdotte dalla novellata riforma dell’art. 110 e seguenti del Codice Privacy proprio in materia di ricerca scientifica

Si rileva, a tal proposito, una presunta imprecisione nel testo normativo, che fa riferimento all’Allegato A5 del Codice Privacy, impropriamente associato al contesto sanitario.

Modalità di accesso ai dati

• I dati estratti tramite EDS, resi accessibili ad Agenas, saranno anonimizzati secondo le tecniche indicate nell’Allegato B del decreto

• I dati anonimizzati non saranno conservati all’interno dell’ecosistema

• È previsto un successivo decreto attuativo per l’abilitazione di servizi che consentano il trattamento di dati personali a fini di ricerca, nel rispetto delle garanzie di cui all’art. 89 GDPR

• Per un’analisi più di dettaglio sui contenuti, servizi e tipologie di dati trattati per mezzo dell’EDS, l’Allegato A contiene una sintesi completa.