Se hai mai guardato il pannello delle preferenze cookie di un sito e ti sei chiesto perché alcuni interruttori sono bloccati su "attivo" mentre altri si possono spegnere liberamente, la risposta sta in una distinzione giuridica precisa: cookie tecnici da un lato, cookie di profilazione dall'altro. Non è una sfumatura da addetti ai lavori. È la linea che decide se il tuo sito può installare quello strumento prima che l'utente dica sì, o se deve aspettare il suo consenso esplicito prima di farlo partire.

Sbagliare questa distinzione è uno degli errori più costosi che un sito italiano possa fare in materia di cookie, perché capita nei due sensi opposti e in entrambi i casi ha un prezzo. Chi classifica come "tecnico" qualcosa che in realtà profila l'utente sta raccogliendo dati senza base giuridica, esposto a sanzione del Garante. Chi invece blocca dietro consenso anche strumenti realmente tecnici sta rendendo il sito meno funzionale del necessario e complicando l'esperienza per nulla.

Questo articolo spiega cosa dice davvero la normativa italiana su questa distinzione, come riconoscere in pratica un cookie tecnico da uno di profilazione, dove si collocano i casi ambigui che generano più dubbi (analytics, funzionali, preferenze) e come una piattaforma di gestione del consenso gestisce questa classificazione senza che tu debba deciderla manualmente riga per riga.

La definizione di cookie tecnico non arriva dal GDPR, ma dall'articolo 122 del Codice in materia di protezione dei dati personali (il "Codice Privacy" italiano, D.Lgs. 196/2003, modificato per recepire la direttiva ePrivacy). Il Codice richiede il consenso per l'archiviazione di informazioni sul dispositivo dell'utente o l'accesso a informazioni già archiviate, salvo che l'operazione serva:

esclusivamente per effettuare la trasmissione di una comunicazione su una rete di comunicazione elettronica, oppure nella misura strettamente necessaria al fornitore di un servizio della società dell'informazione esplicitamente richiesto dal contraente o dall'utente per erogare tale servizio.

Due condizioni cumulative, non alternative: il cookie deve essere necessario, e deve servire un servizio che l'utente ha esplicitamente richiesto. Un cookie che rende un servizio "più comodo" o "migliora l'esperienza" non passa questo test se il servizio funzionerebbe comunque senza di esso. La soglia è alta di proposito: l'eccezione al consenso è pensata per essere stretta, non per diventare la scorciatoia con cui ogni fornitore etichetta il proprio strumento come "tecnico" a prescindere da cosa faccia davvero.

• Cookie di sessione del carrello. Senza di esso il sito non ricorderebbe cosa hai messo nel carrello da una pagina all'altra. Il servizio richiesto (comprare) non esiste senza quel cookie.
• Cookie di autenticazione. Tiene traccia del fatto che hai effettuato il login. Serve esattamente al servizio che hai chiesto: restare autenticato.
• Cookie di bilanciamento del carico o di sicurezza anti-frode. Non profila comportamenti di marketing; esiste per far funzionare l'infrastruttura o proteggerla da abusi.
• Cookie che memorizza la scelta di lingua o la scelta espressa sul banner cookie stesso. Paradossalmente, il cookie che ricorda "l'utente ha rifiutato" è lui stesso tecnico: serve a non rimostrare il banner ad ogni pagina.

• Analytics che identifica il singolo visitatore attraverso un identificativo persistente, anche solo per capire da dove viene il traffico e come si comporta nel tempo. Il sito funziona perfettamente senza: l'analisi non è "richiesta esplicitamente dall'utente", è richiesta dal titolare del sito per finalità proprie.
• Cookie di personalizzazione dei contenuti in base alla cronologia di navigazione. Personalizzare non è lo stesso di erogare il servizio base.
• Pixel pubblicitari e cookie di remarketing. Per definizione servono a costruire un profilo comportamentale per mostrare pubblicità mirata: è l'esempio da manuale di ciò per cui la profilazione esiste.

Le Linee guida cookie e altri strumenti di tracciamento del Garante (10 giugno 2021) definiscono i cookie di profilazione come quelli finalizzati a ricondurre a soggetti determinati, identificati o identificabili, specifiche azioni o schemi comportamentali ricorrenti nell'uso delle funzionalità offerte, così da raggrupparli in profili di dimensione più o meno ampia, omogenei per intensità di interessi manifestati, abitudini di consumo, propensione all'acquisto e così via, allo scopo, ad esempio, di indirizzare messaggi pubblicitari mirati e coerenti con le preferenze mostrate dagli utenti durante la navigazione.

La chiave non è "il cookie legge dati", ma "il cookie costruisce (o alimenta) un profilo riconducibile a una persona che permette di prevedere o influenzare il suo comportamento". Ogni volta che uno strumento fa questo, l'eccezione dell'articolo 122 non si applica e il consenso preventivo diventa obbligatorio, che il cookie provenga dal titolare del sito o da un fornitore terzo.

Gli strumenti di analisi del traffico sono il terreno più controverso perché non sono chiaramente né tecnici né di profilazione secondo il senso comune. Le linee guida del Garante ammettono un'eccezione limitata: gli analytics di prima o terza parte possono essere trattati come assimilabili ai cookie tecnici (quindi senza consenso) solo se il titolare adotta misure di minimizzazione rigorose, in particolare il mascheramento di almeno l'ultimo ottetto dell'indirizzo IP, e a condizione che il fornitore terzo non incroci quei dati minimizzati con altre elaborazioni proprie né li trasmetta a soggetti ulteriori.

Questa eccezione è stretta e va verificata caso per caso: se lo strumento di analytics che usi conserva un identificativo univoco per utente su base persistente, o se il fornitore utilizza quei dati anche per finalità proprie (benchmark cross-cliente, ad esempio), l'eccezione decade e torna il consenso preventivo. Nella pratica, la maggior parte delle implementazioni standard di Google Analytics 4 non rientra in questa eccezione stretta, perché il servizio combina i dati con l'ecosistema pubblicitario di Google salvo configurazioni specifiche di limitazione.

Un cookie di profilazione installato prima del consenso, o mascherato dietro l'etichetta "tecnico" nella cookie policy, è una violazione diretta dell'articolo 122 e, a cascata, dell'articolo 6 del GDPR: il trattamento dei dati che ne deriva non ha base giuridica valida. Non è un tecnicismo formale: significa che ogni dato raccolto tramite quel cookie prima del consenso è stato raccolto illegittimamente, ed è esattamente il tipo di evidenza che un'ispezione del Garante o un reclamo di un utente controlla per primo, semplicemente aprendo gli strumenti di sviluppo del browser sulla home page del sito prima di cliccare qualunque pulsante.

Il rischio non è solo la sanzione diretta. È anche la responsabilità verso terzi: se il tuo sito trasmette dati a Google Ads o Meta prima che l'utente abbia acconsentito, e quella trasmissione viene contestata, la responsabilità di aver attivato lo strumento senza base giuridica ricade sul titolare del sito, non sul fornitore della piattaforma pubblicitaria.

Sapere teoricamente quali cookie sono tecnici e quali di profilazione non basta se il sito non applica quella distinzione a livello tecnico. Le linee guida del Garante sono chiare: la mera presenza di un banner non equivale a conformità se, dietro le quinte, gli script di profilazione partono comunque prima che l'utente scelga.

Una piattaforma di gestione del consenso come AdOpt risolve questo esattamente al livello richiesto dalla norma: scansiona periodicamente quali script sono realmente presenti sul sito, li classifica per categoria (tecnico, funzionale, analytics, profilazione) sulla base del loro comportamento reale e non solo del nome, e blocca tecnicamente l'esecuzione di tutto ciò che non è strettamente necessario finché l'utente non presta consenso esplicito per quella categoria specifica. Solo a quel punto lo script parte, e la piattaforma registra la prova verificabile di cosa è stato acconsentito, quando e per che cosa.

Quasi ogni conversazione sulla classificazione dei cookie finisce per parlare di Google Analytics, perché è lo strumento più diffuso e perché Google stesso lo presenta a volte come "analytics", termine che suona neutro e tecnico. Nella configurazione predefinita, GA4 non rientra nell'eccezione di minimizzazione rigorosa per almeno tre motivi concreti.

Primo, GA4 assegna un identificativo del client persistente (_ga) che permette di ricostruire il comportamento dello stesso visitatore su più sessioni e più giorni, un comportamento tipico di profilazione anche se la finalità dichiarata è "solo statistica". Secondo, salvo disattivazione esplicita del Google Signals e della condivisione dati per prodotti Google, GA4 collega di default i dati di navigazione all'ecosistema pubblicitario di Google, il che rompe immediatamente la condizione "nessun incrocio con altre elaborazioni del fornitore". Terzo, l'IP masking in GA4 non è più configurabile manualmente come nelle versioni precedenti di Universal Analytics: Google dichiara di anonimizzare gli IP di default nell'Unione Europea, ma questa dichiarazione non equivale automaticamente al soddisfacimento della condizione di minimizzazione richiesta dal Garante, perché la minimizzazione richiesta riguarda l'intera catena del trattamento, non solo il campo IP.

La conseguenza pratica: se usi GA4 nella sua configurazione tipica, trattalo come cookie che richiede consenso, punto. Se vuoi tentare la strada dell'eccezione (rara, e quasi sempre sconsigliata per un sito commerciale), servono una configurazione documentata di disattivazione di Google Signals, la disattivazione della pubblicità personalizzata nelle impostazioni della proprietà, e una valutazione legale specifica prima di dichiararlo esente da consenso nella cookie policy. Per la maggior parte dei siti, il tempo speso a inseguire quell'eccezione costa più della semplice implementazione corretta del consenso.

La classificazione tecnico vs profilazione non vive solo nel banner: deve comparire, per ogni singolo cookie o script, nella cookie policy del sito. Per ciascuna voce, la prassi che regge a un controllo richiede almeno: il nome tecnico del cookie, il fornitore (prima o terza parte), la finalità dichiarata in linguaggio comprensibile, la durata di conservazione e la categoria (tecnico, funzionale, analytics, profilazione).

Questa stessa classificazione è anche ciò che rende possibile rispondere correttamente quando un utente esercita i propri diritti previsti dal GDPR, ad esempio chiedendo quali dati sono stati raccolti su di lui e da chi: senza sapere quale categoria di cookie ha generato quale dato, il portale dei diritti dell'interessato non può rispondere in modo completo. Una tabella scritta a mano e aggiornata "quando qualcuno se ne ricorda" è la causa più comune di cookie policy disallineate dalla realtà del sito: il team marketing installa un nuovo pixel di remarketing e nessuno aggiorna il documento legale. È esattamente il motivo per cui una scansione automatica e periodica, non un elenco statico, è lo standard che protegge davvero l'azienda: se lo strumento nuovo non è ancora stato classificato, resta bloccato di default finché qualcuno non lo categorizza, invece di partire silenziosamente senza consenso e senza essere mai documentato.

Il team marketing tende a vedere ogni pixel come "necessario per fare il proprio lavoro", ma necessario per il marketing non è lo stesso di necessario per il servizio richiesto dall'utente ai sensi dell'articolo 122. La distinzione tecnica va spiegata in questi termini per evitare attriti: non è un blocco arbitrario del legale, è un requisito che decide se quel dato raccolto è utilizzabile legalmente o è un rischio silenzioso.

Il team di sviluppo spesso implementa script di terze parti (mappe, video embeddati, chat widget) senza sapere che quello script porta con sé cookie di tracciamento del fornitore esterno. Ogni integrazione di terze parti andrebbe verificata prima del deploy, non scoperta mesi dopo durante un audit.

Chi decide la conformità (DPO, responsabile privacy o titolare stesso in una piccola impresa) ha bisogno di visibilità continua, non di un audit annuale: gli strumenti cambiano più spesso della cadenza con cui qualcuno rilegge manualmente il sito.

Per ogni script o cookie presente sul sito, rispondi in ordine a queste tre domande:

1. Il servizio richiesto dall'utente funzionerebbe senza questo cookie? Se sì, non è strettamente necessario: passa alla profilazione o al consenso.
2. Questo strumento costruisce, alimenta o consulta un profilo riconducibile a una persona identificabile nel tempo? Se sì, è profilazione, punto.
3. Se è un analytics, rispetta la minimizzazione rigorosa richiesta dall'eccezione (IP mascherato, nessun incrocio con altre elaborazioni del fornitore)? Solo se rispetti tutte le condizioni puoi trattarlo come assimilato al tecnico; in caso di dubbio, il consenso è la scelta sicura.

E-commerce. Il cookie di sessione del carrello è tecnico. Il pixel di Meta che ricostruisce chi ha abbandonato il carrello per mostrargli un annuncio di retargeting è profilazione pura, e senza consenso preventivo quell'annuncio è già una violazione, indipendentemente da quanto sia efficace commercialmente.

Blog o media editoriale. L'embed di un video di YouTube porta con sé cookie del fornitore che, nella modalità standard, costruiscono profilo pubblicitario; esiste la modalità "privacy avanzata" di YouTube che riduce (non elimina) questo tracciamento, ma va comunque dichiarata e nella maggior parte dei casi resta soggetta a consenso.

SaaS B2B. Il cookie di autenticazione della dashboard del cliente è tecnico al cento per cento. Lo strumento di product analytics che segue il comportamento dell'utente dentro il prodotto per capire quali funzioni usa di più è, quasi sempre, profilazione se l'identificativo è persistente e riconducibile alla singola persona, anche in ambito B2B.

No. È esso stesso un cookie tecnico: la sua unica funzione è evitare di rimostrare il banner ogni volta che l'utente naviga, il che rientra pienamente nell'eccezione dell'articolo 122 del Codice Privacy.

Dipende dalla configurazione. È assimilabile al tecnico solo con misure di minimizzazione rigorose (mascheramento di almeno l'ultimo ottetto dell'IP e nessun incrocio dei dati con altre elaborazioni del fornitore). La configurazione standard, integrata con Google Ads, non soddisfa questa condizione e richiede consenso.

No. Le linee guida del Garante richiedono che l'utente possa esprimere scelte granulari per categoria di finalità, non solo un accetta/rifiuta globale indistinto, ed è comunque obbligatorio informare su ogni categoria nella cookie policy.

Non automaticamente, ma la maggior parte lo è nella pratica, perché il fornitore terzo (rete pubblicitaria, piattaforma social) tipicamente usa quei dati per costruire profili propri attraverso più siti. Vedi anche il nostro approfondimento sui cookie di terze parti.

Sanzioni del Garante per trattamento senza base giuridica valida, oltre al danno reputazionale di un'ispezione pubblica. Le sanzioni effettivamente comminate sono catalogate nel nostro approfondimento su cosa fa il Garante e quali sanzioni applica.

Serve una scansione tecnica periodica, non una lista scritta a mano una volta e mai aggiornata: gli script cambiano ogni volta che marketing o sviluppo aggiungono un nuovo strumento. È esattamente la funzione dello scanner automatico di una CMP come AdOpt.

• Scroll e consenso ai cookie: perché scorrere la pagina non basta
• Cookie di terze parti: cosa sono e quando servono con consenso

Se gestisci un sito che usa strumenti di marketing, analytics o pubblicità, il primo passo pratico non è leggere ancora un'altra guida: è scoprire cosa sta effettivamente installando il tuo sito in questo momento. Prova AdOpt gratis e scansiona il tuo sito in pochi minuti.