Le leggi sulla privacy danno forma al progetto
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)
Modulo 4 di 6 del capitolo Qualità e governance dei dati, capitolo 5 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Conosci i tuoi dati · Successivo: Il consenso e il diritto all’oblio
La domanda a cui risponde questo modulo: Cosa chiedono a un progetto Salesforce le normative sulla privacy e quelle di settore?
Quando lavoravo in Australia, ho incontrato molti aspiranti architetti che non avevano mai sentito parlare del GDPR. Chi lavora in Europa spesso non ha mai sentito parlare della legge sulla privacy della California, o di quella del Canada, o del Brasile. È naturale: conosci le regole del posto in cui lavori. Ma queste leggi superano i confini, e danno forma alla progettazione dei sistemi anche se nessuna parla di Salesforce. Quindi appartengono a un corso di architettura dei dati.
Non devi diventare avvocato. Devi però vedere che una normativa può cambiare dove vengono memorizzati i dati, cosa raccogli, chi li vede, perché puoi usarli, per quanto tempo li conservi, dove li invii, se puoi cancellarli, quale storico conservi e cosa puoi dimostrare in seguito. Non sono solo domande legali. Sono domande di architettura dei dati.
Questo modulo è una guida di architettura, non una consulenza legale. Sono i team legali e di conformità a decidere quali leggi si applicano e cosa richiedono. L’architetto trasforma quei requisiti in un progetto applicabile.
Le leggi non si fermano al confine
Sezione intitolata “Le leggi non si fermano al confine ”Prima il malinteso più grande: “non siamo in Europa, quindi il GDPR non si applica”. Forse sì, forse no. L’ambito di applicazione territoriale del GDPR raggiunge le organizzazioni fuori dall’UE che offrono beni o servizi a persone nell’UE, o ne monitorano il comportamento lì (articolo 3, Regolamento (UE) 2016/679 (opens in a new tab)). Quindi dove ha sede la tua azienda non chiude la questione. Dove sono i tuoi clienti, i dipendenti, le persone di cui detieni i dati, i tuoi sistemi, i tuoi responsabili del trattamento? Dove viaggiano i dati? È di nuovo il panorama del capitolo 4. Non puoi prendere buone decisioni sulla privacy senza sapere dove vanno i dati.
Le normative che dovresti riconoscere
Sezione intitolata “Le normative che dovresti riconoscere ”Ecco i nomi che un architetto dovrebbe conoscere, con ciò che copre ciascuno. È una tabella per riconoscerle, non una matrice di applicabilità: non leggerla per decidere “abbiamo clienti in California, quindi si applica il requisito X”. Quella è una decisione dell’ufficio legale. Il tuo compito è saperne abbastanza da porre la domanda prima che il sistema venga costruito.
| Legge o standard | Dove o cosa | Perché un architetto dovrebbe riconoscerla |
|---|---|---|
| GDPR (opens in a new tab) | Unione europea | Dati personali, trattamento lecito, diritti degli interessati, conservazione, trasferimenti, protezione dei dati fin dalla progettazione |
| CCPA, come modificato dal CPRA (opens in a new tab) | California | I diritti dei consumatori sulle informazioni personali che le aziende raccolgono su di loro |
| PIPEDA (opens in a new tab) | Canada | Come le organizzazioni del settore privato trattano le informazioni personali |
| LGPD (opens in a new tab) | Brasile | La legge generale brasiliana sulla protezione dei dati personali |
| Privacy Act 1988 (opens in a new tab) | Australia | Come le organizzazioni trattano le informazioni personali, secondo gli Australian Privacy Principles |
| HIPAA (opens in a new tab) | Sanità negli Stati Uniti | Informazioni sanitarie protette nei contesti coperti |
| PCI DSS (opens in a new tab) | Carte di pagamento | La protezione dei dati dei conti delle carte di pagamento |
| Sarbanes-Oxley (SOX) (opens in a new tab) | Società quotate negli Stati Uniti | I controlli e le prove dietro la rendicontazione finanziaria |
| COPPA (opens in a new tab) | Stati Uniti, minori online | Le informazioni personali raccolte online dai minori |
L’elenco cresce (sempre più stati americani hanno leggi proprie), e le leggi cambiano. Ecco perché non voglio che tu memorizzi una tabella pensando di aver imparato l’architettura della privacy. Impara i nomi, poi impara le domande che durano più di loro.
Cosa hanno in comune le leggi
Sezione intitolata “Cosa hanno in comune le leggi ”I dettagli cambiano, ma le grandi leggi sulla privacy tornano sempre alle stesse poche cose, e ognuna ricade sull’architettura.
Diritti. Le persone possono chiedere di accedere ai propri dati, di rettificarli, di cancellarli e di portarli con sé; con le leggi della California e del Brasile possono anche opporsi alla loro vendita. Ognuna di queste richieste significa trovare i dati della persona, tutti.
Trasferimenti. Il GDPR e la LGPD controllano i dati personali che escono dalla loro giurisdizione e chiedono un livello di protezione adeguato là dove arrivano; la PIPEDA si aspetta lo stesso livello di protezione quando un terzo tratta i dati, ovunque si trovi. È di nuovo il panorama: quali frecce attraversano un confine?
Notifica delle violazioni. Quando i dati personali vengono esposti, le leggi si aspettano che tu lo comunichi alle autorità, e a volte agli interessati, entro un termine che varia da legge a legge. Non puoi notificare una violazione di dati che non sapevi di avere, né dire cosa è stato esposto se non trovi le copie.
Responsabilizzazione. Devi essere in grado di dimostrare la conformità: registri di cosa tratti e perché, valutazioni d’impatto per i trattamenti ad alto rischio e, con il GDPR e la LGPD, un responsabile della protezione dei dati. L’architettura deve produrre quei registri.
Parti da ciò che è personale
Sezione intitolata “Parti da ciò che è personale ”Prima di proteggere le informazioni personali, trovale. Alcune sono ovvie: nome, indirizzo di casa, telefono, email. Altre no: posizione, identificatori dei dispositivi, indirizzi IP, immagini, dati comportamentali, tutto ciò che si può ricondurre a una persona. E il contesto conta. Una consegna di Steve Trucking porta il nome, l’indirizzo, il numero di telefono, le note di consegna e le foto del Destinatario. Una foto potrebbe mostrare un pacco sotto un portico, o una persona, o l’interno di una casa. La consegna è un dato operativo, ma alcuni dei suoi attributi sono personali. Ecco perché il modulo 3 ha classificato i campi: la privacy comincia dal sapere cosa detieni.
Dove risiedono?
Sezione intitolata “Dove risiedono? ”“In Salesforce.” Probabilmente non solo in Salesforce. Sono arrivati da un Partner retail? Sono stati copiati in Snowflake, acquisiti da Data 360, scritti nel log di un’integrazione, esportati da un utente, lasciati nella cronologia dei campi, archiviati, copiati in una sandbox, passati a un partner, usati nella conversazione di un agente? I dati personali si diffondono. Quindi quando l’ufficio legale chiede “dove conserviamo le informazioni di questa persona?”, “sappiamo dov’è il valore attuale” non è una risposta. Voglio il panorama e la lineage: dove sono andate le copie.
Un numero di telefono, molte copie. La privacy si applica anche alle copie.
Perché sei autorizzato a usarli?
Sezione intitolata “Perché sei autorizzato a usarli? ”Avere dei dati ed essere autorizzati a usarli non sono la stessa cosa. Steve Trucking ha il numero di telefono di un Destinatario per coordinare la consegna di oggi. Questo ne fa una lista di marketing? No. La base giuridica dipende dalla giurisdizione e dalla situazione, e a guidarla è l’ufficio legale, ma l’architettura deve portare la risposta: perché sono stati raccolti, quale uso è stato autorizzato, se serviva il consenso, se è stato dato, se è stato revocato, e per quale canale, indirizzo e finalità. Il permesso di usare i dati deve essere rappresentabile come dato, perché un documento di policy non può prendere una decisione in fase di esecuzione. Il prossimo modulo lo modella.
Raccogliere meno è una decisione di architettura
Sezione intitolata “Raccogliere meno è una decisione di architettura ”Uno dei controlli sulla privacy più forti è non raccogliere i dati, o non copiarli dove non servono. Snowflake ha bisogno del numero di telefono del Destinatario? Le analisi hanno bisogno dell’indirizzo completo? La sandbox ha bisogno di foto vere delle consegne? Un agente ha bisogno dei dati personali del Destinatario per rispondere a questa domanda? Se no, il controllo più forte potrebbe essere non metterli lì. Ogni copia che non fai è una copia che non devi proteggere, conservare, cancellare, tracciare per il consenso, sottoporre ad audit o segnalare in caso di violazione. I dati sensibili più economici da governare sono quelli che non hai mai copiato.
La conservazione fa parte del modello
Sezione intitolata “La conservazione fa parte del modello ”“Per ora conserviamo tutto” è una politica di conservazione. Solo che è una cattiva politica. Per i dati importanti voglio sapere già in fase di progettazione per quanto tempo ci servono e perché; se una normativa fissa un minimo o un’altra un massimo; quando parte il conteggio; e cosa succede alla fine: cancellare, archiviare, de-identificare, e dove sono le copie? I documenti finanziari potrebbero dover restare per un periodo stabilito. Il codice del cancello di un Destinatario non ha alcuno scopo anni dopo la consegna. Queste decisioni non aspettano che il database sia grande.
Anonimizzato, pseudonimizzato, crittografato, mascherato
Sezione intitolata “Anonimizzato, pseudonimizzato, crittografato, mascherato ”Sostituisci “Jane Smith” con 7F92A1. Jane è anonimizzata? No, se un’altra tabella dice ancora 7F92A1 = Jane Smith. Quella è pseudonimizzazione: l’identificatore diretto è sostituito, ma i dati si possono ricollegare usando informazioni conservate separatamente, e secondo il GDPR i dati pseudonimizzati sono ancora dati personali (articolo 4, punto 5). L’anonimizzazione va oltre: i dati non si possono più ragionevolmente ricollegare alla persona (considerando 26). Quindi quando qualcuno dice “non dobbiamo cancellarli, togliamo solo il nome”, fai attenzione. Se la persona può ancora essere ragionevolmente identificata, non hai superato quella linea. Se un risultato soddisfa la legge lo decide l’ufficio legale; il compito dell’architetto è dire esattamente cosa fa il sistema: si può ricollegare, quali chiavi restano, dove sono le mappature?
Usa le parole con precisione, perché risolvono problemi diversi. La crittografia protegge i dati dalla divulgazione non autorizzata; un utente autorizzato può comunque decifrarli. Il mascheramento cambia ciò che vedono determinati utenti o ambienti. La pseudonimizzazione separa l’identità diretta mantenendo una via di ritorno. L’anonimizzazione elimina la ragionevole possibilità di identificare la persona. Solo l’ultima fa uscire i dati dalla categoria dei dati “personali”.
La normativa diventa requisiti
Sezione intitolata “La normativa diventa requisiti ”L’ufficio legale non deve dirmi di creare un set di autorizzazioni; quello sta dal mio lato della linea. L’ufficio legale potrebbe dire “solo i dipendenti con una legittima esigenza di business possono accedere a questa categoria di informazioni personali”. Allora traduco: chi sono, come identifichiamo la categoria, come si concede l’accesso, cosa succede quando qualcuno cambia lavoro, un’integrazione può leggerla, un agente può farlo, si può esportare, e come dimostriamo chi l’ha vista? I responsabili fissano le politiche; gli architetti le fanno rispettare. Ufficio legale e conformità stabiliscono l’obbligo, i responsabili dei dati fissano la politica di business, e l’architetto progetta l’applicazione.
Dalla normativa alla prova: l’ufficio legale interpreta, il responsabile fissa la politica, l’architetto la fa funzionare e la rende dimostrabile.
E la conformità non è un prodotto. Non puoi comprare “conformità: attiva”. La crittografia può sostenere un requisito, le funzionalità di audit forniscono prove, gli strumenti di conservazione eseguono la politica, i dati sul consenso sostengono l’uso consentito, ma acquistare la licenza di una funzionalità non rende conforme un’architettura. La conformità viene dall’intero progetto: persone, politiche, processi, dati, controlli e prove. Salesforce ne fa parte, non ne è il tutto. E se una politica conta abbastanza da farla rispettare, chiediti se conta abbastanza da dimostrarla: chi ha avuto accesso a questo record il 17 marzo, chi ha modificato questo campo, cosa conteneva quell’esportazione? Il modulo 6 tratta le prove.
La privacy cambia il panorama
Sezione intitolata “La privacy cambia il panorama ”In Steve Trucking, i dati personali del Destinatario arrivano attraverso tre integrazioni con i partner. Salesforce ne ha bisogno per gestire le consegne; le squadre ne hanno bisogno in parte, solo per le proprie tappe, solo quel giorno; Snowflake vuole le analisi sulle consegne; la finanza ha bisogno di abbastanza per fatturare, ma non di ciò che vede la squadra. E un Partner retail non deve mai vedere i Destinatari di un altro. La privacy cambia le frecce: certi campi non vanno a Snowflake, le analisi ricevono una versione meno identificabile, le squadre vedono solo le proprie tappe, la conservazione a valle è diversa da quella operativa. Il requisito di privacy non sta accanto al diagramma del panorama. Lo cambia.
Domande che durano più delle normative
Sezione intitolata “Domande che durano più delle normative ”Le normative cambiano, quindi porta con te un insieme durevole di domande per ogni dato sensibile o regolamentato:
- Che cos’è? Personale, sensibile, finanziario, sanitario, di pagamento, relativo a minori o altrimenti regolamentato?
- Dove risiede? Ogni copia: integrazioni, cronologia, analisi, archivi, sandbox, log, uso da parte dell’IA.
- Perché possiamo usarlo? Quale finalità e quale base giuridica si applicano? C’entra il consenso?
- Chi può usarlo? Persone, sistemi, partner, integrazioni, agenti.
- Per quanto tempo lo conserviamo, e cosa succede alla fine?
- La persona può esercitare i propri diritti su di esso? Accesso, rettifica, cancellazione, portabilità, opposizione, come previsto dalla legge.
- Possiamo dimostrare cosa è successo? Accessi, modifiche, esportazioni, consenso, cancellazione, conservazione.
La governance dell’IA sta diventando legge
Sezione intitolata “La governance dell’IA sta diventando legge ”L’IA aggiunge un altro consumatore di dati governati. Un sistema di IA può usare questi dati, per quale finalità, come grounding, combinati con cosa, ripetuti nel suo output, registrati dove, per quanto tempo? La governance dell’IA si sta spostando dalla policy aziendale alla legge: il regolamento sull’IA dell’Unione europea (AI Act, Regolamento (UE) 2024/1689 (opens in a new tab)) è il primo esempio di ampia portata. Cosa richiede dipende dal sistema e dall’uso. La direzione per gli architetti è chiara: l’IA non sta fuori dalla governance; è un altro consumatore di dati governati.
Cosa decide qui un architetto
Sezione intitolata “Cosa decide qui un architetto ”- Dove i dati regolamentati o sensibili entrano, risiedono, si muovono e vengono copiati nel panorama.
- Come le politiche legali e di conformità diventano requisiti applicabili, senza che sia l’architetto a interpretare la legge.
- Se ogni sistema che riceve dati sensibili ne ha davvero bisogno, o basterebbe una versione meno identificabile.
- Come conservazione, cancellazione, anonimizzazione, pseudonimizzazione, protezione e prove danno forma al ciclo di vita dei dati.
- Quali prove devono esistere per mostrare che i controlli importanti hanno funzionato davvero.
Le normative non diventano architettura mettendo i loro nomi su una slide. Diventano architettura quando cambiano il modo in cui i dati vengono raccolti, classificati, spostati, protetti, conservati, cancellati e dimostrati.
Per approfondire
Sezione intitolata “Per approfondire ”- Le fonti ufficiali delle normative sono collegate nella tabella qui sopra (in inglese o nella lingua originale), consultate il 2026-10-14.
- Regolamento (UE) 2016/679 (GDPR) (opens in a new tab): articolo 3 (ambito di applicazione territoriale), articolo 4, punto 5 (pseudonimizzazione), considerando 26 (informazioni anonime).
- Regolamento (UE) 2024/1689 (regolamento sull’IA) (opens in a new tab), EUR-Lex.