Il 29 luglio 2026 abbiamo tolto da questo sito la CMP commerciale che gestiva il consenso ai cookie e l’abbiamo sostituita con una soluzione sviluppata internamente. Non è una scelta che consigliamo a tutti — e la parte utile di questo articolo è capire quando non conviene.
Perché il risparmio di canone è la ragione peggiore per farlo, e la funzione che si perde senza accorgersene può costare molto più della licenza.
Le tre condizioni che l’hanno resa praticabile
Non l’abbiamo fatto perché sappiamo scrivere codice. L’abbiamo fatto perché ricorrevano tre condizioni insieme, e se ne manca una il conto cambia segno:
- Un solo servizio terzo richiede il consenso. Su questo sito è Google Analytics 4, e nulla più. Cloudflare Turnstile, che protegge il form di contatto, è una misura strettamente necessaria e non richiede consenso. Con dieci script di terze parti, la mappatura e il blocco preventivo di ognuno diventano il lavoro, e una CMP commerciale lo fa già.
- La cookie policy è contenuto nostro, una pagina che scriviamo e manteniamo, non un documento generato e ospitato dal fornitore. Chi usa l’informativa generata dalla CMP, sostituendola, perde anche quella.
- Il codice resta manutenibile da noi. Una CMP non è un progetto che si chiude: cambiano le indicazioni delle autorità, cambiano gli script del sito. Se non c’è chi la segue nei prossimi tre anni, è un debito.
Se queste tre non ci sono, una CMP commerciale costa meno del lavoro che evita. È il caso della maggior parte dei siti aziendali, e vale la pena dirlo chiaramente prima di raccontare la parte tecnica.
La funzione che abbiamo dovuto ricostruire da zero
Qui sta l’unica lezione davvero trasferibile di tutta la migrazione, e la abbiamo capita progettando, non dopo.
Il cookie di consenso non è una prova del consenso.
L’art. 7, par. 1 del GDPR chiede al titolare di essere in grado di dimostrare che il consenso è stato prestato. Il cookie risiede sul dispositivo dell’utente: è sotto il suo controllo, non sotto il nostro. Può cancellarlo, modificarlo, cambiare dispositivo. Come prova non vale nulla.
Le CMP commerciali questa cosa la fanno, e la fanno in silenzio: conservano i record di consenso sui propri server. Sostituendole senza ricostruire quella capacità, la si perde — e non c’è nessun errore, nessun avviso, nessun test che fallisce. Il banner funziona perfettamente, l’azienda semplicemente non è più in grado di dimostrare nulla.
Per questo la parte più delicata del lavoro non è stata il banner: è stato un registro delle prove lato server.
Come si progetta un registro delle prove senza costruire un profilo
Un registro dei consensi è un archivio che nasce per dimostrare la conformità. È perciò il posto più imbarazzante in cui violare il principio di minimizzazione — e la tentazione c’è, perché “più dati, più prova” sembra ragionevole.
Non lo è. Serve dimostrare che il consenso è stato dato e su quali finalità, non chi l’ha dato. Le nostre scelte:
| Registriamo | Non registriamo |
|---|---|
| identificativo casuale della scelta | l’indirizzo IP in chiaro |
| momento della scelta | |
| versione dell’informativa a cui si riferisce | dati identificativi diretti (nome, email) |
| esito per categoria | |
| percorso della pagina in cui è stata espressa | |
| lo user agent del browser | |
| un’impronta dell’IP, calcolata con hash |
L’identificativo casuale è il punto che regge tutto: non identifica la persona, serve solo a collegare il cookie presente sul dispositivo alla riga nel registro. Se domani qualcuno contesta di non aver acconsentito, il confronto fra i due valori è la verifica — e non richiede di sapere chi fosse.
L’impronta dell’IP è un hash troncato con un sale: consente due cose legittime — limitare gli abusi sull’endpoint e correlare più record della stessa origine in caso di contestazione. Non è anonimizzazione, ed è il punto che abbiamo capito riguardandolo. Un hash protegge un segreto solo se lo spazio degli input è troppo grande per essere enumerato: un IPv4 può essere solo una di 4,3 miliardi di cose, e chi conosce il sale ricostruisce la tabella inversa in minuti — un singolo blocco /16 in una frazione di secondo. L’impronta resta quindi un dato personale (art. 4, punto 5 GDPR: la pseudonimizzazione presuppone che le informazioni aggiuntive siano conservate separatamente), va dichiarata nell’informativa e il sale va tenuto fuori dal codice sorgente, in una variabile d’ambiente.
Tre dettagli che si scoprono solo implementando:
- Il percorso del file di log va fuori dalla cartella dell’applicazione. Se sta dentro, il primo deploy che sovrascrive quella directory azzera l’archivio delle prove. Vale per qualsiasi dato persistente in un’app che si aggiorna sostituendo i file.
- Un endpoint pubblico di logging senza limiti è un modo per far crescere i log all’infinito. Serve un rate limit, con soglie larghe: una persona esprime la scelta una volta e la cambia raramente.
- Se l’archivio non è scrivibile, la richiesta non deve fallire. La scelta dell’utente è già stata applicata sul client: far vedere un errore per un problema di scrittura sarebbe il comportamento sbagliato. Va segnalato nei log — è una condizione da correggere, non da ignorare.
I requisiti del Garante che si sbagliano facilmente
Le linee guida del Garante sui cookie del 10 giugno 2021 sono precise su alcuni punti che in un banner scritto in casa è facile mancare:
- Nessun dark pattern. “Accetta” e “Rifiuta” devono avere lo stesso peso visivo e stare al medesimo livello. Il rifiuto nascosto in un secondo passaggio, o reso graficamente meno evidente, è precisamente ciò che l’autorità contesta.
- Nessun consenso da scroll o da navigazione continuata. Chi scorre la pagina non ha acconsentito.
- Revoca sempre disponibile, quindi un elemento persistente su tutte le pagine — non un link sepolto in fondo alla cookie policy.
- Non riproporre il banner prima di sei mesi, salvo cambi delle condizioni. La nostra scelta si conserva 180 giorni.
Su quest’ultimo punto abbiamo aggiunto una cosa che le CMP gestiscono e che va replicata: lo schema di consenso è versionato. Se cambiano le categorie o le finalità, incrementare la versione fa ricomparire il banner a tutti — perché il consenso raccolto sulle vecchie finalità non copre le nuove. Senza quel meccanismo, un giorno si aggiunge uno script e si continua a considerare valido un consenso che non lo è.
Nota tecnica sul comportamento di GA4: resta caricato anche prima della scelta, ma con Consent Mode v2 in stato negato per impostazione predefinita, che invia soltanto segnali anonimi senza cookie. È lo stesso schema che usava la CMP precedente. Le categorie pubblicitarie restano negate in ogni caso, perché il sito non ospita advertising.
Il vincolo da verificare prima di tutto il resto
C’è una condizione che va controllata all’inizio della valutazione, perché rende la scelta reversibile solo a un costo.
Per pubblicare annunci Google o usare AdSense nello Spazio economico europeo, Google richiede una CMP certificata da Google. Non è un requisito tecnico né normativo: è una policy del fornitore, e non si aggira scrivendo codice migliore. L’elenco delle CMP certificate lo pubblica Google, e una soluzione sviluppata internamente non vi entra per il solo fatto di essere conforme al GDPR.
La conseguenza pratica: se fate advertising Google, o pensate di farlo, la sostituzione della CMP non è sul tavolo — o meglio, lo è al prezzo di rinunciare a quel canale. È la prima domanda da farsi, non l’ultima: chi investe in Google Ads e cambia CMP per risparmiare un canone scopre il vincolo nel momento peggiore, cioè quando la campagna viene bloccata.
Quando invece è la scelta giusta
Riassumendo il criterio, senza vendere nulla: la sostituzione ha senso quando pochi vendor richiedono consenso, l’informativa è già contenuto proprio, non c’è advertising Google in gioco e c’è chi mantiene il codice. In quel quadrante si ottiene un banner che non fa nessuna richiesta a domini esterni, un cookie di prima parte, un controllo completo su testi e comportamento, e nessuna dipendenza da un servizio terzo per una funzione che è in mezzo fra l’utente e ogni pagina del sito.
Fuori da quel quadrante, la risposta onesta è che una CMP commerciale fa il suo lavoro e costa meno del vostro tempo.
Stato delle informazioni: aggiornate al 14 agosto 2026. I riferimenti sono le linee guida del Garante sui cookie e altri strumenti di tracciamento del 10 giugno 2021 e l’art. 7 del GDPR sulla dimostrabilità del consenso. Questo articolo descrive scelte progettuali fatte su un caso concreto — il nostro — e non è una consulenza legale: la valutazione va fatta con chi assiste l’azienda sulla privacy.
Se state ragionando sulla stessa decisione, o se avete un’applicazione in cui il consenso va gestito insieme ad altre logiche, è il tipo di lavoro che facciamo nei progetti web application e backend e API. E se il tema è il tracciamento in senso più ampio, la novità di quest’anno sono le linee guida sul tracking pixel nelle email, con scadenza a fine ottobre: scriveteci se vi serve una mano su entrambi.
Domande frequenti
Conviene sostituire una CMP commerciale con una soluzione propria?
Nella maggior parte dei casi no. Diventa una scelta ragionevole solo quando ricorrono tre condizioni insieme: pochissimi servizi terzi che richiedono consenso, una cookie policy che è contenuto proprio e non un documento generato dal fornitore, e la disponibilità interna a mantenere il codice nel tempo. Se manca una delle tre, una CMP commerciale costa meno del lavoro che evita.
Il cookie di consenso è una prova del consenso?
No, e ignorarlo è l’errore più costoso in questa migrazione. L’art. 7, par. 1 del GDPR chiede al titolare di essere in grado di dimostrare che il consenso è stato prestato, mentre il cookie risiede sul dispositivo dell’utente ed è sotto il suo controllo, non sotto quello dell’azienda. Serve una registrazione lato server: è la funzione che le CMP commerciali forniscono e che va ricostruita se le si sostituisce.
Che cosa si può registrare nel registro delle prove senza esagerare?
Serve dimostrare CHE il consenso è stato dato e su quali finalità, non costruire un profilo di chi l’ha dato. Nel nostro registro finiscono un identificativo casuale della scelta, il momento, la versione dell’informativa, l’esito per categoria, il percorso della pagina, lo user agent e un’impronta dell’indirizzo IP calcolata con hash. L’IP in chiaro non viene memorizzato, ma l’impronta ne deriva e resta quindi un dato personale: per questo la dichiariamo nell’informativa invece di presentarla come anonima.
Ogni quanto si può riproporre il banner a chi ha già scelto?
Il Garante indica di non riproporlo prima di sei mesi, salvo cambi delle condizioni. La nostra implementazione conserva la scelta per 180 giorni. C’è però un caso in cui il banner deve ricomparire subito a tutti: quando cambiano le categorie o le finalità. Per questo lo schema di consenso è versionato, e un incremento della versione invalida le scelte raccolte sulle finalità precedenti.
Una CMP sviluppata internamente va bene per Google Ads?
In generale no, ed è il vincolo da verificare per primo. Per pubblicare annunci Google o usare AdSense nello Spazio economico europeo, Google richiede una CMP certificata da Google, scelta da un elenco che pubblica Google stessa. Non è una questione tecnica né normativa ma di policy del fornitore: essere conformi al GDPR non basta a entrare in quell’elenco. Se fate advertising Google, verificatelo prima di valutare qualsiasi sostituzione.
Quali requisiti del Garante sono facili da sbagliare in un banner fatto in casa?
Tre. Il peso visivo di Accetta e Rifiuta deve essere lo stesso e i due pulsanti devono stare al medesimo livello, altrimenti si ricade nei dark pattern. Il consenso non si può ricavare dallo scroll né dalla navigazione continuata. E la revoca deve essere sempre disponibile, quindi serve un elemento persistente su tutte le pagine, non un link sepolto nella cookie policy.
Dove va salvato il file del registro dei consensi?
Fuori dalla cartella dell’applicazione. È un dettaglio operativo che si paga caro: se il percorso sta dentro la directory del sito, il primo deploy che sovrascrive quella cartella azzera l’archivio delle prove. Vale la stessa attenzione per qualsiasi dato persistente in un’applicazione che si aggiorna sostituendo i file.