Il consenso e il diritto all'oblio

🌐 Disponibile anche in 28 lingue

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Immagine generata con l'IA

Tradotto con l'IA. Non ancora rivisto dalla comunità. Leggi in inglese

Modulo 5 di 6 del capitolo Qualità e governance dei dati, capitolo 5 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Le leggi sulla privacy danno forma al progetto · Successivo: Proteggere, conservare e dimostrare

La domanda a cui risponde questo modulo: Come si progetta per il consenso, e per la cancellazione di una persona?

Steve Trucking ha il numero di telefono di un Destinatario. Domanda semplice: possiamo mandargli un SMS? Forse. Sulla consegna di oggi? Su quella di domani? Possiamo usare il numero per una promozione? E se ha detto niente SMS, o sì agli aggiornamenti sulla consegna ma no al marketing, e poi ha cambiato idea?

Ora l’altra direzione. Il Destinatario dice: cancellate le mie informazioni personali. Dove sono? In Salesforce, probabilmente, ma abbiamo imparato che non è tutta la risposta. Sono arrivate da un Partner retail. Potrebbero essere in una piattaforma di dati dei clienti (CDP), nella cronologia dei campi, in un archivio, in una nota di consegna, in un’esportazione, nel log di un’integrazione, nella conversazione di un agente. Consenso e cancellazione sembrano domande di policy, ma prima o poi è il sistema a dover rispondere. Questa è architettura.

Il consenso è un dato

Il primo principio: il consenso è un dato. Non ridurlo a Has_Opted_In__c = true. La vera domanda non è mai solo “ha dato il consenso?”. È consenso a cosa, attraverso quale canale, a quale indirizzo o numero, per quale finalità, quando, è cambiato, e possiamo dimostrarlo? Se il business prende decisioni in base a quelle risposte, vanno memorizzate come dati strutturati. Un paragrafo in un’informativa sulla privacy non basta, e nemmeno una casella in un modulo web: la casella registra un evento; l’architettura deve conservare cosa significa quell’evento.

Usa il modello che Salesforce ha già costruito

La mia posizione: usa il modello di consenso standard ovunque puoi, invece di ricostruire la stessa cosa con campi personalizzati. Il modello dati del consenso di Salesforce gestisce il consenso su quattro livelli, ognuno una domanda più specifica (Understand the Salesforce Consent Data Model (opens in a new tab)):

• Consenso globale, sull’Individuo (Individual): chi è questa persona, e ha detto no a tutto?
• Consenso per canale di engagement (Contact Point Type Consent): possiamo usare questo tipo di canale, come SMS o email?
• Consenso per punto di contatto: e per questo specifico numero di telefono o indirizzo email?
• Finalità di utilizzo dei dati (Data Use Purpose): per quale motivo: notifiche di consegna, assistenza, marketing?

Messi insieme, l’architettura può rispondere a “possiamo usare le informazioni di questa persona, attraverso questo punto di contatto, per questa finalità?”, il che è molto più utile di “consenso = sì”. Qualsiasi record collegato a un individuo può partecipare: lead, contatti, account personali, utenti.

Click to enlarge

Quattro domande, ognuna più ristretta della precedente. Un unico flag di opt-in non risponde bene a nessuna.

La finalità conta

Un Partner retail invia a Steve Trucking il numero di un Destinatario perché la squadra possa coordinare la consegna. Questo non fa del Destinatario un lead di marketing. Gli stessi dati possono avere usi consentiti diversi: coordinamento della consegna, assistenza successiva, marketing, personalizzazione tramite IA. Se la policy o la legge li trattano in modo diverso, il modello deve distinguerli. La domanda non è abbiamo il numero di telefono? È cosa siamo autorizzati a farci?

E il consenso non è sempre la base giuridica. Alcuni usi si fondano su altre basi previste dalla legge, e questo lo stabilisce l’ufficio legale. Non costruire un’architettura che dia per scontato che ogni decisione sulla privacy sia una casella di consenso. Sostieni ciò che dice la policy: se un uso dipende dal consenso, modella e fai rispettare il consenso; se si applica un’altra base, memorizza comunque ciò che serve per decidere se l’uso è consentito.

Il consenso ha un ciclo di vita e un’autorità

Le persone danno il consenso, lo revocano, cambiano preferenze, cambiano numero. Il business aggiunge nuove finalità; le leggi cambiano. Quindi progetta il ciclo di vita: cosa è stato scelto, quando, come, per quale finalità, e cosa succede alla revoca. Ed ecco dove si fa interessante: quando un Destinatario revoca il consenso, Salesforce lo sa. Lo sa la piattaforma di messaggistica? Le analisi? L’agente? Un consenso che vive in un sistema mentre altri agiscono su un permesso non aggiornato non è un gran controllo.

Questo significa chiedersi quale sistema è autorevole per il consenso. Salesforce, una piattaforma per le preferenze, qualcos’altro? Qualunque sia la risposta, non lasciare che cinque sistemi decidano ciascuno per conto suo se la stessa persona ha acconsentito allo stesso uso. Il consenso ha bisogno di ciò che serve a qualsiasi dato governato: un responsabile, un record autorevole, un modo per sincronizzarsi, e l’applicazione.

Ora la persona dice: dimenticatemi

Il primo istinto è eliminare il contatto e considerare chiusa la questione. Ma i dati della persona potrebbero stare su un contatto, una consegna, una nota di consegna, un caso, una foto, nella cronologia dei campi, in Snowflake, in un archivio, nel log di un’integrazione, in un indice di ricerca o nella cronologia delle conversazioni di un agente. Ecco perché la mia posizione sulla cancellazione comincia prima: in pratica la cancellazione è rara e difficile, quindi controlla prima dove vanno i dati personali. Progetta in modo che finiscano nel minor numero possibile di posti. Poi, quando arriva una richiesta, offuscali o scollegali dove questo soddisfa la policy, e stana ogni copia: cronologia dei campi, archivi, Data 360, e ora indici di ricerca e conversazioni degli agenti.

Non iniziare la caccia quando arriva la richiesta. A quel punto è troppo tardi per cominciare a capire il panorama. Dizionario, lineage e classificazione del modulo 3 non erano burocrazia; sono ciò che rende possibile tutto questo. Sai già quali campi contengono dati personali e dove sono andate le copie.

Click to enlarge

Una richiesta di oblio è una decisione per ogni copia.

Il tempo stringe

Queste richieste hanno delle scadenze. Con il GDPR, il titolare del trattamento deve dare seguito alla richiesta dell’interessato senza ingiustificato ritardo e, comunque, al più tardi entro un mese dal ricevimento; per richieste complesse o numerose il termine può essere prorogato di due mesi, ma l’interessato deve esserne informato entro il primo mese, con i motivi del ritardo (articolo 12, paragrafo 3, Regolamento (UE) 2016/679 (opens in a new tab)). Altre leggi fissano scadenze proprie; l’ufficio legale ti dirà quali si applicano. In ogni caso, un mese non basta per scoprire il panorama. È questa la scadenza che la mappa delle copie deve battere.

Cancellare, de-identificare o conservare?

Una richiesta non significa necessariamente che tutto sparisca ovunque. Alcuni record devono o possono essere conservati; alcuni record operativi possono restare ma smettere di identificare la persona; alcuni dati possono essere de-identificati. Decidono la policy e la legge applicabili; l’architettura sostiene ogni esito, posto per posto: cancellarli, de-identificarli, o conservarli in base a un requisito approvato (e allora chi può vederli, per quanto tempo, perché?).

Ricorda la distinzione del modulo 4. Scollegare conta come dimenticare solo quando la persona non può più essere ragionevolmente reidentificata. I dati pseudonimizzati sono ancora dati personali. Non usare l’offuscamento come scorciatoia per aggirare un requisito legale.

Non puoi cancellare ciò che non trovi

Prima di poter cancellare qualcuno, devi trovarlo. La richiesta arriva da un indirizzo email. Un Partner retail ha inviato “Jane Smith”, un altro “J. Smith”, e il numero di telefono è cambiato. Il Destinatario non è affatto un contatto; i suoi dati stanno su ogni consegna. La stessa persona ha ricevuto consegne per due partner diversi. Un sistema la conosce per email, un altro per un ID esterno. La cancellazione dipende dall’identità, e non vuoi cancellare i dati di qualcun altro perché il tuo abbinamento era troppo aggressivo. L’architettura dell’identità fa parte dell’architettura della privacy.

Steve Trucking rende tutto ancora più difficile. Un Partner retail non deve mai vedere le consegne o i Destinatari di un altro. Se la stessa persona ha ricevuto consegne per due partner, le operazioni devono tenere separate quelle relazioni, mentre la privacy potrebbe comunque dover trovare la persona in entrambe. Non risolvere la privacy rompendo il confine di sicurezza, e non proteggere il confine rendendo impossibili le richieste di privacy. L’architettura deve fare entrambe le cose.

Anche le foto e il testo libero sono dati

È facile pensare alla privacy in termini di campi: nome, email, telefono, indirizzo. Ma Steve Trucking scatta milioni di foto delle consegne all’anno, e alcune mostrano persone o l’interno di una casa. Una politica di conservazione o di cancellazione che guarda solo i campi strutturati è incompleta; lo è anche una che ignora file, documenti, trascrizioni, log, e prompt e risposte dell’IA.

E il testo libero è pericoloso. Togli nome, telefono e indirizzo, poi trovi questa nota di consegna: “Chiamare Jane al 602-555-0198. Codice del cancello 4821. C’è un cane in giardino.” Eccoli lì. Classificare le note di consegna come sensibili ti dice che potrebbe esserci un problema; non trova né rimuove i dati personali dentro il testo. A volte la risposta migliore è impedire che dettagli personali non necessari finiscano lì. Controlla prima dove vanno i dati personali.

Privacy Center è uno strumento, non l’intera architettura

Privacy Center di Salesforce aiuta a gestire questi processi. Le sue policy per il diritto all’oblio si costruiscono oggetto per oggetto, per raccogliere tutto ciò che vuoi rimuovere, e si eseguono su un record cliente specifico (Delete Data with Right to Be Forgotten Policies (opens in a new tab)). È utile. Ma “abbiamo comprato Privacy Center, quindi abbiamo finito” non è un’architettura. I dati della persona possono vivere fuori dalla portata di un singolo strumento: Data 360, il data warehouse, i sistemi dei partner, gli archivi, i log, la ricerca, i file, le conversazioni degli agenti. L’azienda ha comunque bisogno di una risposta aziendale, e devi verificare cosa copre davvero ogni strumento prima di farci affidamento.

Portabilità e prova

Alcune leggi danno anche alle persone il diritto di ricevere una copia dei propri dati. Nota che è lo stesso problema di individuazione: la cancellazione chiede dove sono i dati di questa persona, per poter agire? La portabilità chiede dove sono, per poterli fornire? Entrambe si fondano su identità, classificazione, lineage, l’inventario dei sistemi e la responsabilità.

E poi: come dimostri di averlo fatto? Richiesta ricevuta, identità verificata, sistemi esaminati, azioni intraprese, eccezioni registrate, dati conservati giustificati, completamento registrato. C’è una vera tensione qui: stai rimuovendo i dati personali di qualcuno conservando abbastanza prove da mostrare di aver gestito correttamente la richiesta. È proprio per questo che gli architetti non dovrebbero inventarsi da soli le regole di conservazione. Ufficio legale e conformità decidono quali prove devono restare; l’architettura le conserva senza conservare i dati che doveva rimuovere.

Oltre l’esame: cosa cambia l’IA. L’IA crea nuove finalità e nuove copie. Il permesso di usare i dati per fornire un servizio non copre automaticamente il grounding di un agente, la personalizzazione o l’addestramento; la finalità di utilizzo dei dati (Data Use Purpose) è il posto naturale per distinguerli. E i dati personali possono sopravvivere in prompt, contesto di grounding, conversazioni, riepiloghi, indici di ricerca e vettoriali, e log. “Abbiamo eliminato il record di origine” non è una risposta completa se il livello dell’IA ricorda ancora.

Cosa decide qui un architetto

• Come vengono modellati il consenso e l’uso consentito, perché i sistemi possano rispondere a chi, quale canale, quale punto di contatto e quale finalità.
• Quale sistema è autorevole per il consenso, e come le revoche raggiungono ogni sistema che agisce su di esso.
• Dove possono diffondersi i dati personali: campi, testo libero, file, cronologia, analisi, archivi, integrazioni, ricerca e IA.
• Come una richiesta trova la persona giusta e guida, in ogni posto, la cancellazione, la de-identificazione o la conservazione approvata.
• Quali prove restano per dimostrare che consenso e richieste di privacy sono stati gestiti.

Consenso e cancellazione sembrano opposti (possiamo usare questi dati? possiamo smettere e rimuoverli?) ma si fondano sulle stesse basi: identità, finalità, classificazione, lineage, responsabilità, applicazione e prove. Usa il modello di consenso standard, controlla dove vanno i dati personali, sappi dove sono le copie, e progetta il processo di cancellazione prima che arrivi la prima richiesta. Quando qualcuno chiede “potete dimenticarmi?”, l’architettura ha bisogno di una risposta migliore di “pensiamo di sì”.

Per approfondire

• Guida di Salesforce, Understand the Salesforce Consent Data Model (opens in a new tab) (in inglese), consultato il 2026-10-14.
• Regolamento (UE) 2016/679 (GDPR) (opens in a new tab), articolo 12, paragrafo 3, il termine per dare seguito a una richiesta, consultato il 2026-10-14.
• Guida di Salesforce, Delete Data with Right to Be Forgotten Policies (opens in a new tab) (Privacy Center, in inglese), consultato il 2026-10-14.