Google e Gmail: il consenso non racconta dove finiscono i dati

Una prenotazione d’albergo arriva nella casella email. Un assistente AI la legge, con il tuo permesso, per suggerirti cosa fare vicino all’hotel. Fin qui il vantaggio è evidente: non devi copiare date, indirizzi e dettagli in un’altra applicazione. Ma se quella stessa informazione contribuisse anche a scegliere quale annuncio mostrarti, sapresti indicare il momento esatto in cui hai autorizzato il secondo utilizzo?

È questa la domanda interessante dietro l’aggiornamento delle norme sulla privacy di Google, in vigore dal 16 ottobre 2026. Non la caricatura secondo cui Google avrebbe improvvisamente deciso di leggere tutte le email per venderle agli inserzionisti. Quella ricostruzione è sbagliata. La modifica riguarda un’eccezione condizionata: dati provenienti da Gmail, Drive e Google Foto possono contribuire alla personalizzazione pubblicitaria quando l’utente sceglie di renderli disponibili ad altri servizi Google che supportano annunci personalizzati.

La questione, per chi costruisce software, non è soltanto giuridica. È architetturale. Perché il confine di accesso a un dato e il confine di utilizzo delle informazioni che da quel dato derivano non coincidono necessariamente.

Una frase cambia. Il perimetro cambia con lei

La formulazione precedente escludeva i contenuti di Gmail, Drive e Foto dalla personalizzazione degli annunci. Quella attuale mantiene l’esclusione, ma aggiunge una condizione: non vale quando scegli di mettere i dati di quei servizi a disposizione di altri prodotti Google che supportano pubblicità personalizzata. Nello stesso documento Google chiarisce che servizi come Search e le app Gemini possono, in base alle impostazioni, accedere a informazioni di altri servizi per personalizzare l’esperienza; nel caso di Search questa personalizzazione può comprendere gli annunci.

È una differenza sostanziale, non un dettaglio lessicale. Prima la promessa descriveva un confine più netto rispetto al contenuto di tre applicazioni. Adesso il confine dipende anche dalle connessioni che l’utente decide di attivare. Non significa che ogni account sia automaticamente coinvolto: serve la scelta di collegare i servizi pertinenti, e contano le funzionalità effettivamente disponibili.

Google ha inoltre dichiarato ad Ars Technica che non sta scandagliando indistintamente l’intera posta per arricchire i profili pubblicitari e che la precisazione non modifica il modo in cui condivide dati con i partner pubblicitari. Sono distinzioni importanti. Fare critica tecnica non richiede di trasformare un’eccezione documentata in un’accusa più grande delle prove.

Dal messaggio all’annuncio: il viaggio del dato

Prendiamo un esempio ipotetico, coerente con il funzionamento descritto da Google. Un’email contiene la conferma di una prenotazione. Hai collegato la casella a una funzione di Search che usa Personal Intelligence. Quando chiedi consigli per il viaggio, il servizio può ricavare una sintesi della prenotazione, riconoscere la destinazione e proporre attività nelle vicinanze. Il contenuto originale è rimasto nella posta, ma la sua informazione utile è entrata in un altro contesto.

A questo punto conviene distinguere quattro oggetti che troppo spesso vengono confusi:

• Dato sorgente: l’email, il file o la fotografia custoditi nell’applicazione originale.
• Dato derivato: un estratto, un riassunto o un’inferenza ricavati dal contenuto.
• Contesto operativo: la risposta personalizzata che Search costruisce usando quei derivati.
• Segnale pubblicitario: l’informazione che può influire sulla selezione di un annuncio nel servizio che supporta pubblicità.

La guida ufficiale di Google Search dice espressamente che gli annunci non sono basati direttamente sulla casella Gmail o sulla libreria Foto, ma che riepiloghi, estratti e inferenze provenienti dalle app collegate possono personalizzare l’esperienza e che quelle stesse informazioni possono essere usate per mostrare annunci. È la differenza tra il contenuto originale e il risultato di una trasformazione.

Un progettista riconosce subito il problema: cambiare rappresentazione non elimina automaticamente il significato. Se una sintesi rivela dove dormirai domani, non diventa innocua soltanto perché non contiene il messaggio completo. E se un’inferenza descrive una preferenza, non smette di essere informazione su di te perché non è stata digitata esplicitamente in un campo.

Il dato non smette di essere personale quando cambia formato. E il permesso di leggerlo non spiega, da solo, tutti gli utilizzi successivi.

Non direttamente: una risposta corretta a una domanda incompleta

Google precisa anche che gli inserzionisti non ricevono accesso alla casella Gmail o alla libreria Google Foto. La policy esclude l’uso delle categorie sensibili indicate dall’azienda, come salute, religione, origine etnica e orientamento sessuale, per la personalizzazione degli annunci. Sono protezioni dichiarate e vanno riportate, non ignorate per rendere il titolo più rumoroso.

Ma qui convivono due domande differenti. La prima è: un inserzionista può aprire la mia email? Secondo la documentazione citata, no. La seconda è: un servizio Google che ho autorizzato può utilizzare informazioni derivate dalla mia email anche per decidere quali annunci mostrarmi? Nelle condizioni descritte, sì, può accadere. Rispondere correttamente alla prima non risolve la seconda.

Lo stesso ragionamento vale per molti sistemi AI aziendali. Un assistente può non esporre mai un documento originale all’utente finale e, contemporaneamente, trasferire nella risposta dettagli riservati, una classificazione sensibile o una conclusione non autorizzata. Il rischio non vive soltanto nell’accesso al file: vive nelle trasformazioni e nei destinatari delle informazioni risultanti. È un tema vicino a quello affrontato parlando di chiavi regionali e confini reali dei dati: una protezione locale non racconta necessariamente l’intero percorso.

L’interruttore esiste. Ma non è il diagramma del sistema

La connessione delle app è facoltativa. È un elemento centrale, perché qui non stiamo descrivendo un uso generalizzato dei contenuti di tutti gli utenti. Però la parola opt-in viene spesso trattata come una soluzione completa, quando in realtà è soltanto una decisione all’ingresso di un flusso.

La documentazione di Search descrive controlli distinti per collegare le applicazioni, personalizzare le raccomandazioni e gestire la pubblicità. Aggiunge un dettaglio ancora più importante: scollegare un’app, o cancellare informazioni nell’app originale, non elimina automaticamente i dati già salvati nella Search Services History. Per quelli esiste un controllo separato. La guida spiega inoltre che, se scegli di collegare le app, riepiloghi, estratti e inferenze pertinenti possono essere utilizzati anche per migliorare i servizi e addestrare modelli generativi; in alcuni casi una sintesi può coincidere con un’email breve o particolarmente rilevante.

Attenzione a non mischiare tutto: l’uso per annunci, l’uso per addestramento e l’eventuale revisione umana sono trattamenti differenti, descritti in sezioni differenti della guida, con condizioni e controlli che vanno letti separatamente. Proprio questa separazione dimostra perché un solo pulsante non basta a rappresentare la storia del dato.

E in Italia? La policy non equivale a un rilascio della funzione

C’è un’altra distinzione che evita allarmismi inutili. Le norme sulla privacy sono pubblicate globalmente, ma non tutte le funzioni descritte sono disponibili ovunque. Alla data del 26 ottobre 2026, nella lista ufficiale dei paesi in cui è possibile collegare le content app a Search non compare l’Italia, né risultano elencati Stati dell’Unione europea. Anche la pagina ufficiale dedicata a Personal Intelligence in Gemini segnala un rollout beta che esclude lo Spazio economico europeo.

Questo non rende irrilevante il cambiamento contrattuale, ma impedisce di sostenere che oggi qualunque utente italiano possa attivare esattamente quel percorso Search-Gmail-annunci. Le disponibilità possono cambiare; una verifica seria deve sempre distinguere ciò che il testo permette, ciò che il prodotto implementa e ciò che è accessibile in una determinata area geografica.

Come si progetta un consenso che abbia davvero un significato

Se stessi disegnando un’integrazione AI che accede a documenti, posta o dati dei clienti, non mi fermerei alla schermata di autorizzazione. Pretenderei una mappa dei passaggi successivi, comprensibile a chi sviluppa e a chi deve governare il sistema. Non perché ogni trasformazione sia illecita, ma perché un’architettura che non sa spiegare il proprio flusso di dati è difficile da controllare, anche quando tutte le checkbox sono state selezionate.

1. Separare accesso, elaborazione e riutilizzo

Un permesso per leggere una prenotazione allo scopo di rispondere a una domanda non dovrebbe essere confuso, nella documentazione del prodotto, con l’autorizzazione a riutilizzarne una sintesi per un altro scopo. Sono fasi differenti e meritano nomi, limiti e verifiche differenti.

2. Tracciare le derivazioni, non solo i file

Nei log di un sistema complesso è relativamente facile sapere quale API ha letto un documento. È più difficile ricostruire quali estratti siano stati prodotti, in quali contesti siano finiti e per quanto tempo siano rimasti disponibili. Serve una politica di provenienza del dato derivato, non soltanto una tabella degli accessi.

3. Progettare la revoca prima dell’attivazione

Se una connessione viene disabilitata, che cosa succede alle copie logiche, alla cronologia, ai riassunti e alle inferenze già generati? Non esiste una risposta universale: dipende dal servizio, dai tempi di conservazione e dai controlli documentati. La revoca deve avere una semantica esplicita e verificabile, invece di essere lasciata all’interpretazione dell’utente.

4. Verificare separatamente le destinazioni

Risposta AI, miglioramento del prodotto, addestramento e pubblicità sono finalità diverse. Un sistema maturo deve poter dire quali dati attraversano ciascun percorso, con quali impostazioni e con quali eccezioni. È lo stesso principio che rende insufficiente un chatbot aziendale apparentemente utile se non sono chiari i suoi confini di responsabilità: ne ho scritto parlando di assistenti che rispondono a nome dell’azienda.

5. Mostrare il risultato del consenso, non soltanto la sua etichetta

L’utente non ha bisogno di leggere un diagramma UML. Ha però bisogno di capire, con esempi concreti, che cosa un collegamento permette di fare oggi, quali usi secondari abilita e dove intervenire per limitarli. Una promessa generica di personalizzazione non equivale a una spiegazione del percorso.

Il problema non è che l’AI usi contesto. È che il contesto cambia mestiere

Un assistente che non può usare informazioni pertinenti rischia di essere poco utile. Sarebbe facile trasformare questa vicenda nell’ennesimo sermone contro l’intelligenza artificiale, ma sarebbe anche una lettura pigra. Il valore di collegare sistemi esiste: riduce lavoro manuale, ricostruisce contesti e permette risposte che prima richiedevano cinque applicazioni aperte.

La contropartita è una responsabilità progettuale più grande. Quando un dato passa dalla posta a una risposta e da quella risposta a un possibile segnale pubblicitario, il problema non è il singolo trasferimento preso isolatamente. È la catena delle trasformazioni, con le sue condizioni, la sua memoria e i suoi punti di controllo.

La modifica di Google rende visibile una regola generale: un consenso è un evento; il trattamento dei dati è un processo. Se sappiamo documentare soltanto il primo, non abbiamo ancora progettato il secondo. Abbiamo semplicemente costruito un pulsante e sperato che il resto del sistema fosse comprensibile da solo.