Le nuove coordinate europee per un uso legittimo dei dati analitici tra privacy by design, AI trasparente e fiducia digitale
Gli analytics sono diventati una componente ordinaria dei servizi digitali. Servono per capire come gli utenti usano una piattaforma, migliorare interfacce e processi, misurare prestazioni, prevenire anomalie, ottimizzare servizi pubblici e costruire modelli predittivi o sistemi di intelligenza artificiale. Ma proprio perché gli analytics sono ormai ovunque, il loro trattamento non può più essere gestito come una raccolta indistinta di dati “perché potrebbero servire”. Il quadro europeo più recente spinge invece verso un principio molto più esigente: trattare solo ciò che è realmente necessario, con una base giuridica chiara, in modo trasparente, documentato e proporzionato.
È importante chiarire un punto preliminare. Ad oggi non esiste una singola linea guida dell’EDPB interamente dedicata a tutti gli usi degli analytics. L’evoluzione più rilevante deriva dall’incrocio di documenti recenti che incidono direttamente su questo ambito: gli orientamenti sul legittimo interesse, quelli sull’articolo 5(3) della direttiva ePrivacy, le linee guida sulla pseudonimizzazione e il parere sui modelli di intelligenza artificiale. Letti insieme, questi documenti mostrano una traiettoria chiara: l’analytics legittimo non coincide con la raccolta massiva, ma con un trattamento mirato, spiegabile, verificabile e progettato fin dall’inizio secondo il principio di protezione dei dati.
- Perché l’EDPB sta cambiando il modo di leggere gli analytics
- Basi giuridiche: consenso, legittimo interesse e vincoli ePrivacy
- Minimizzazione, pseudonimizzazione e qualità del dato
- Privacy by design: progettare analytics meno invasivi e più utili
- AI trasparente e analytics avanzati: dove cresce l’accountability
- Cosa devono fare imprese e PA: governance, documentazione e controlli
- Una prospettiva di lungo periodo per la fiducia digitale
Perché l’EDPB sta cambiando il modo di leggere gli analytics
L’evoluzione recente dell’EDPB è importante perché sposta il baricentro del dibattito. Per anni molte organizzazioni hanno trattato gli analytics come una funzione “tecnica” separata dalla protezione dei dati: un insieme di log, cookie, identificatori, dati di navigazione e metriche di performance raccolti quasi automaticamente per finalità di misurazione, marketing, personalizzazione o miglioramento dei servizi. Oggi questa impostazione è molto più difficile da sostenere.
Le indicazioni più recenti dell’EDPB mostrano infatti che la domanda corretta non è soltanto “quali dati posso tecnicamente raccogliere?”, ma “quali dati sono davvero necessari rispetto a una finalità definita, con quale base giuridica, con quali aspettative ragionevoli dell’interessato e con quali garanzie di riduzione del rischio?”. Questa è una differenza sostanziale: l’analytics non viene più visto come un’area neutra del digitale, ma come un trattamento che deve essere letto dentro tutti i principi del GDPR.
In particolare, gli orientamenti sul legittimo interesse chiariscono che questa base giuridica non è né una soluzione residuale da usare all’ultimo momento né una scorciatoia automaticamente disponibile perché ritenuta meno onerosa del consenso. Per il Comitato, ogni uso del legittimo interesse richiede una valutazione preventiva, documentata e concreta, che tenga insieme finalità, necessità del trattamento e impatto sui diritti e sulle libertà delle persone. Per consultare il documento di riferimento: Orientamenti EDPB 1/2024 sul trattamento basato sul legittimo interesse
Questa lettura è particolarmente rilevante per gli analytics perché costringe a distinguere meglio tra misurazione strettamente funzionale al servizio, monitoraggio interno, personalizzazione, profilazione, pubblicità, sviluppo di modelli AI e riuso dei dati per scopi ulteriori. L’etichetta “analytics” non basta più a giustificare pratiche molto diverse tra loro.
Basi giuridiche: consenso, legittimo interesse e vincoli ePrivacy
Il primo punto da chiarire sul piano giuridico è che per gli analytics non esiste una base legale unica valida in ogni situazione. Il quadro va letto su due livelli: da un lato il GDPR, dall’altro la direttiva ePrivacy, quando il trattamento comporta archiviazione o accesso a informazioni sul terminale dell’utente.
Questo significa che, in molti casi di analytics web o app-based, la sola discussione sulla base giuridica GDPR è insufficiente. Se la misurazione usa cookie, pixel, identificatori persistenti, lettura di informazioni dal browser o altre tecniche che ricadono nell’articolo 5(3) ePrivacy, occorre verificare prima di tutto se serve il consenso oppure se si possa applicare una delle eccezioni previste dalla disciplina nazionale di recepimento. Qui il punto essenziale è che l’EDPB ha chiarito il perimetro tecnico di questa norma, mostrando che l’accesso al terminale può rilevare anche oltre i cookie tradizionali.
Quando invece il trattamento non ricade in quell’accesso al terminale, o quando il livello ePrivacy è già stato correttamente gestito, torna centrale la scelta della base giuridica GDPR. Il consenso resta la base più lineare quando l’analytics eccede ciò che è strettamente atteso dall’utente o quando il trattamento ha una dimensione marcata di tracciamento, personalizzazione o riuso non necessario. Il legittimo interesse può essere preso in considerazione, ma solo per trattamenti proporzionati, realmente necessari, compatibili con le aspettative ragionevoli degli interessati e adeguatamente mitigati.
Per imprese e PA questo comporta una conseguenza pratica molto importante: non basta scrivere nell’informativa che l’analytics serve a “migliorare il servizio”. Occorre distinguere se si tratta di misurazione essenziale, di analisi di prodotto, di sicurezza, di benchmarking, di marketing o di addestramento di sistemi più avanzati. Ogni finalità può cambiare la base giuridica, il perimetro dei dati e il livello di trasparenza richiesto.
Minimizzazione, pseudonimizzazione e qualità del dato
Uno dei messaggi più forti che emerge dall’evoluzione dell’EDPB è il ritorno del principio di minimizzazione al centro del trattamento. Questo vale in modo particolare per gli analytics, dove la tentazione di raccogliere il massimo numero possibile di dati è storicamente molto forte. Il GDPR, invece, chiede che i dati siano adeguati, pertinenti e limitati a quanto necessario rispetto alle finalità dichiarate.
In termini pratici, minimizzare non significa solo ridurre il numero dei campi raccolti. Significa anche limitare la granularità, la frequenza, la durata della conservazione, la possibilità di collegare eventi tra loro, la riconducibilità a una persona, l’accessibilità ai team interni e il riuso successivo per scopi diversi. Un analytics davvero conforme non è quello che conserva “tutto, nel dubbio”, ma quello che è progettato per rispondere a domande precise con il minor livello di invasività possibile.
In questo contesto la pseudonimizzazione assume un ruolo molto importante. Le nuove linee guida EDPB del 2025 chiariscono che i dati pseudonimizzati restano dati personali, ma confermano anche che la pseudonimizzazione può ridurre i rischi, rafforzare la protezione dei dati fin dalla progettazione e facilitare, in alcuni casi, l’uso del legittimo interesse. Per gli analytics, questo vuol dire che identificatori diretti, tabelle di corrispondenza e chiavi di re-identificazione dovrebbero essere separati, protetti e accessibili solo dove realmente necessario.
Il punto decisivo è che minimizzazione e pseudonimizzazione vanno pensate insieme. Un dataset enorme, ricco di dettagli e conservato troppo a lungo non diventa “leggero” solo perché è stato pseudonimizzato. La qualità della protezione dipende dalla combinazione tra riduzione del dato, separazione dei domini, limitazione delle finalità e sicurezza organizzativa.
Privacy by design: progettare analytics meno invasivi e più utili
Nel quadro dell’EDPB, la protezione dei dati by design e by default non è una fase finale di controllo, ma una logica progettuale che dovrebbe guidare le scelte fin dall’inizio. Per gli analytics, questo comporta un cambio di metodo molto concreto.
La prima implicazione riguarda l’architettura. Un sistema di analytics progettato bene dovrebbe chiedersi sin dall’inizio se sia possibile privilegiare aggregazione, eventi ridotti, server-side measurement meno invasiva, tempi di conservazione brevi, disattivazione delle funzioni non essenziali per default e separazione tra analisi statistica, sicurezza e personalizzazione. Non tutto ciò che è tecnicamente possibile è necessario per il servizio.
La seconda implicazione riguarda i default. Le linee guida EDPB sull’articolo 25 ricordano che la minimizzazione by default si applica alla quantità di dati raccolti, all’estensione del trattamento, al periodo di conservazione e all’accessibilità. Per gli analytics questo significa che la configurazione iniziale dovrebbe essere la più prudente: raccolta ridotta, retention breve, accessi limitati, attivazione esplicita delle funzioni aggiuntive e documentazione chiara di ogni estensione del trattamento.
La terza implicazione è organizzativa. Privacy by design vuol dire anche progettare workflow, ruoli e controlli. Chi può vedere i dati grezzi? Chi può collegarli ad altri archivi? Chi approva nuove finalità? Chi verifica che le dashboard non reintroducano, per combinazione, un livello eccessivo di identificabilità? Senza questa disciplina, la conformità resta formale e non diventa governo reale del rischio.
AI trasparente e analytics avanzati: dove cresce l’accountability
Il confine tra analytics tradizionale e intelligenza artificiale è sempre più sottile. Molti sistemi di analytics non si limitano a descrivere il passato: segmentano utenti, prevedono comportamenti, ottimizzano offerte, rilevano anomalie, suggeriscono azioni o alimentano modelli di AI. È qui che il quadro EDPB più recente, incluso il parere sui modelli AI, diventa particolarmente utile.
Il Comitato richiama che il GDPR supporta un’innovazione responsabile e che, nel contesto dei modelli AI, trasparenza, limitazione della finalità, minimizzazione e accountability devono essere valutate in modo distinto per le diverse fasi del trattamento. Applicato agli analytics, questo significa che non basta dire che i dati servono “per migliorare i servizi”: bisogna distinguere se servono a reportistica descrittiva, addestramento di modelli, inferenze, personalizzazione o decision support.
La trasparenza qui assume una qualità diversa. L’EDPB insiste sul fatto che le informazioni fornite alle persone devono essere accessibili, comprensibili e user-friendly, soprattutto quando la tecnologia è complessa. Nel caso degli analytics avanzati, questo implica spiegare non solo quali dati si raccolgono, ma anche per quale logica di analisi, con quali effetti pratici, con quali categorie di output e con quali eventuali impatti su utenti, clienti, cittadini o dipendenti.
Questo è il punto in cui l’analytics incontra davvero l’accountability. Più l’analisi è sofisticata, più diventa necessario documentare scelte, basi giuridiche, misure di minimizzazione, separazione delle finalità, ruolo dei fornitori, valutazioni di impatto e controlli umani. L’AI trasparente non nasce da una nota in fondo all’informativa, ma da una progettazione che rende il trattamento spiegabile fin dall’origine.
Cosa devono fare imprese e PA: governance, documentazione e controlli
Per organizzazioni pubbliche e private, il primo passo non è adottare una nuova piattaforma, ma mappare con precisione quali analytics stanno già eseguendo. In molte realtà esistono strumenti accumulati nel tempo: web analytics, SDK, strumenti di heatmapping, log estesi, dashboard interne, sistemi antifrode, moduli di personalizzazione, modelli predittivi e riusi dei dati per scopi di business intelligence. Senza una mappa chiara, la conformità è difficilmente governabile.
Il secondo passo è distinguere i trattamenti in blocchi omogenei e verificare per ciascuno: finalità, base giuridica, eventuale impatto ePrivacy, categorie di dati, retention, ruoli dei destinatari, trasferimenti, misure di sicurezza, possibilità di pseudonimizzazione e necessità di una DPIA nei casi ad alto rischio. Questo lavoro è particolarmente importante per la PA, dove gli analytics possono incidere anche su trasparenza amministrativa, proporzionalità e fiducia nei servizi pubblici digitali.
Il terzo passo è introdurre una governance ordinaria: LIA quando si valuta il legittimo interesse, policy di minimizzazione, catalogo dei trattamenti, revisione periodica delle dashboard, controlli sugli accessi, contratti con i fornitori e criteri di approvazione per nuove finalità analitiche. Quando gli analytics alimentano modelli AI o processi decisionali rilevanti, questa governance deve essere ancora più rigorosa.
In altre parole, l’analytics conforme non è un semplice tema da banner cookie o da informativa privacy. È un tema di architettura dei dati, cultura organizzativa e responsabilità documentata.
Una prospettiva di lungo periodo per la fiducia digitale
L’evoluzione recente dell’EDPB mostra che il futuro degli analytics in Europa non sarà fondato sulla raccolta indiscriminata, ma su un equilibrio più maturo tra conoscenza del servizio e tutela delle persone. Questo equilibrio non è un ostacolo all’innovazione. Al contrario, può renderla più credibile, più robusta e meno esposta a pratiche opache che nel medio periodo erodono fiducia, qualità del dato e legittimazione sociale.
Per imprese e pubbliche amministrazioni la lezione è chiara. Gli analytics utili non sono quelli che accumulano più dati, ma quelli che sanno trasformare un trattamento ben delimitato in decisioni migliori, con meno rumore, meno rischio e più trasparenza. È qui che si incontrano privacy by design, AI trasparente e accountability: non come obblighi separati, ma come tre lati della stessa qualità digitale.
Nel lungo periodo, la vera differenza non la farà la sofisticazione dello strumento analitico, ma la capacità di trattare il dato come una risorsa da governare con rigore. In un ecosistema digitale europeo sempre più attento a fiducia, diritti e innovazione responsabile, questo è il passaggio che separa l’analytics opportunistico dall’analytics realmente sostenibile.
