L’esperta legale internazionale di diritto dell’intelligenza artificiale e diritto digitale pubblica «The Privacy by Design Audit»: un metodo operativo per trasformare l’articolo 25 del GDPR da principio astratto a pratica documentabile
L’articolo 25 del GDPR — la «privacy by design» — è legge dal 2018, eppure la maggior parte delle organizzazioni non è in grado di dimostrare di rispettarlo. È da questo paradosso che parte The Privacy by Design Audit, il libro di Turan Sadigi in uscita su Amazon il 15 luglio, con un’edizione italiana in preparazione. Esperta legale con formazione specialistica al King’s College London e certificazione CIPP/E, Sadigi è la fondatrice dello studio 21 Blackstone Legal, con cui assiste multinazionali, investitori ed enti pubblici sulla conformità GDPR, la governance dell’intelligenza artificiale e l’ingresso nel mercato europeo.
Il suo è un profilo atipico nel panorama legale: prima di dedicarsi alla consulenza strategico-legale ha costruito una carriera ultra-decennale in ruoli esecutivi — tra cui Global HR Director e Vice President — in multinazionali e gruppi d’investimento dei settori tecnologico, finanziario e manifatturiero, e ha operato come Angel Investor per uno dei fondi più importanti d’Italia. Lavora in cinque lingue, tra Roma, Londra, New York e Baku. L’abbiamo intervistata.
Partiamo dalle basi: cosa significa «privacy by design» e perché nel suo libro sostiene che, nella pratica, fallisce?
«Privacy by design significa una cosa semplice: la protezione dei dati personali va progettata dentro il prodotto fin dall’inizio, non aggiunta alla fine come un cerotto. È quello che richiede l’articolo 25 del GDPR. Il problema è che la legge dice cosa ottenere, ma non dice come: non nomina responsabili, non stabilisce ogni quanto verificare la conformità, non definisce quale documentazione sia sufficiente. Il risultato è che nella maggior parte delle aziende, se si chiede “chi, esattamente, è responsabile delle implicazioni privacy delle decisioni di progettazione del vostro prodotto?”, la stanza tace. Non per malafede: nessuno ha mai dato loro un metodo per rispondere. Il libro nasce per colmare esattamente questo vuoto».
Il GDPR è in vigore dal 2018, con sanzioni miliardarie e una vasta produzione di linee guida. Perché le organizzazioni non riescono ancora ad adeguarsi?
«Perché il divario non è di comprensione, è strutturale. Nel libro lo scompongo in tre debolezze precise. La prima: l’articolo 25 si rivolge ai titolari del trattamento, ma le decisioni di progettazione le prendono ingegneri, product owner e architetti software, che non hanno alcun obbligo GDPR diretto. La seconda: la legge tratta la progettazione come un momento, mentre un prodotto digitale moderno cambia a ogni sprint, a ogni integrazione, a ogni aggiornamento — una verifica fatta al lancio e mai più rivista diventa finzione nel giro di settimane. La terza: l’articolo 5, paragrafo 2, impone di dimostrare la conformità, ma l’intento progettuale interno è invisibile dall’esterno. Tre problemi: WHO, WHEN, PROVE IT. Nessuna linea guida, da sola, li risolve».
La sua risposta è il «Triangle Framework». Ce lo spiega in parole semplici?
«Sono tre audit che lavorano insieme. Il WHO Audit mappa ogni decisione di progettazione che tocca dati personali su una persona con nome e cognome — non su un team, non su un ruolo. Il WHEN Audit definisce gli “eventi trigger”: le categorie di cambiamento — una nuova integrazione, un nuovo mercato, il riaddestramento di un modello di IA — che fanno scattare automaticamente una revisione privacy obbligatoria. Il PROVE IT Audit impone la regola d’oro: documentare nel momento in cui si decide, non quando arriva la domanda del Garante. Documentazione creata a posteriori è ricostruzione, e la ricostruzione non è prova».
«Nominare una persona, non un ruolo» è l’idea più provocatoria del libro. Perché è così importante?
«Perché i team non prendono decisioni: le persone sì. Quando “tutti” sono responsabili della privacy di un prodotto, nessuno lo è. E quando un’autorità di controllo chiede chi ha deciso di raccogliere quel dato, con quale base giuridica e quali alternative sono state considerate, “il team di sviluppo” non è una risposta. Aggiungo un punto che nel libro dedico agli ingegneri, perché è la loro paura più frequente: nominare una persona non trasferisce la responsabilità giuridica dall’azienda all’individuo. Le sanzioni dell’articolo 83 colpiscono il titolare, cioè l’entità giuridica. La firma dell’ingegnere certifica un fatto tecnico — chi ha fatto quella scelta, quando, perché — esattamente come un commit firmato nel codice. Protegge, non espone».
Lei definisce l’intelligenza artificiale «lo stress test» dell’articolo 25. In che senso?
«Ogni norma rivela le sue debolezze davanti al caso più difficile, e per la privacy by design quel caso è l’IA. Nei sistemi tradizionali una decisione di progettazione è riconducibile a una persona; in un sistema di IA le decisioni più rilevanti le prende, di fatto, il processo di addestramento. Il problema WHEN diventa acuto: un modello riaddestrato oggi non è il sistema di ieri, e non esiste un momento stabile in cui certificare la conformità una volta per tutte. E il problema PROVE IT tocca il suo estremo con la “scatola nera”: come documenti l’intento progettuale di un sistema di cui nemmeno chi l’ha costruito sa spiegare pienamente il comportamento? A questo si aggiunge l’AI Act europeo, che per i sistemi ad alto rischio si applica insieme al GDPR. L’IA non crea nuovi obblighi ai sensi dell’articolo 25: rivela quanto i nostri sistemi di conformità fossero inadeguati anche prima».
Cosa rischia concretamente un’azienda che non riesce a dimostrare la propria conformità?
«Tre cose, in ordine crescente di frequenza. La prima, la più visibile, sono le sanzioni: l’articolo 25 rientra nella fascia fino a 10 milioni di euro o al 2% del fatturato mondiale, e le autorità europee — CNIL, Garante, ICO — ne hanno fatto una priorità di enforcement. La seconda, meno raccontata ma più frequente, è commerciale: sempre più contratti enterprise si perdono in due diligence, quando il cliente chiede la documentazione dell’articolo 25 e l’azienda non ha nulla da produrre. Nel libro lo ripeto come un mantra: una conformità genuina che non può essere dimostrata è, giuridicamente e commercialmente, indistinguibile dalla non conformità. La terza è la più sottile: quando l’ispezione arriva, la differenza tra un richiamo formale e una sanzione pesante la fa spesso la qualità — e l’onestà — della documentazione che riesci a mettere sul tavolo».
Il libro promette strumenti «utilizzabili da lunedì mattina». Perché questa scelta così marcatamente operativa?
«Perché un framework giuridicamente perfetto ma organizzativamente disabitato non protegge nessuno. La stragrande maggioranza dei testi legali è scritta da giuristi che non hanno mai vissuto un giorno dentro i flussi di un’azienda, che non sanno cosa sia uno sprint planning o come si gestisca il budget di un reparto produttivo. Avendo costruito la mia carriera per anni come direttrice d’impresa, manager internazionale ed esperta nei processi di investimento di grandi fondi, conosco i problemi aziendali dal punto di vista del business, delle finanze e del management, non solo della legge. So bene che se un obbligo legale rallenta lo sviluppo o crea attrito nei team, l’organizzazione troverà un modo per bypassarlo. Il Triangle Framework nasce proprio da questa mia doppia anima: è rigoroso dal punto di vista del GDPR, ma è progettato per parlare la stessa lingua degli ingegneri, dei product owner e dei direttori finanziari. Risolve il problema del business, integrando la conformità direttamente nei processi operativi quotidiani».
La sua attività si divide da sempre tra hub come Roma, Londra, Baku e New York. In che modo questa visione globale influenza il suo approccio alla privacy aziendale?
«Muoversi stabilmente tra mercati così diversi — da quello europeo fortemente regolamentato, a quello dinamico del Regno Unito, fino al cuore finanziario di New York — ti costringe ad abbandonare ogni approccio puramente teorico alla legge. Le aziende globali e gli investitori non cercano lunghi pareri accademici che complicano i processi. Cercano soluzioni di management e di mitigazione del rischio che sblocchino il business. Avendo vissuto la realtà aziendale sia dal punto di vista istituzionale sia da quello degli investimenti, so che il tempo è la risorsa più preziosa; per questo il percorso che propongo, ad esempio per le aziende extra-UE, è un piano operativo pragmatico che punta a ridurre il rischio delle transazioni e a integrarsi fluidamente con le strategie di crescita aziendali».
Nella parte finale il libro avanza due proposte di riforma. Cosa chiede, in sostanza, al legislatore europeo?
«Due cose, e le presento onestamente per quello che sono: contributi originali al dibattito, non diritto vigente. La prima: standard tecnici vincolanti per l’articolo 25, sul modello dell’AI Act — sostituire obblighi soggettivi e interpretabili con specifiche oggettive e verificabili. La seconda, che chiamo Adequacy Enforcement Bridge, riguarda l’applicazione extraterritoriale: estendere le decisioni di adeguatezza con impegni vincolanti di mutua esecuzione, così che una sanzione GDPR contro un titolare extra-UE diventi effettivamente riscuotibile nel suo Paese. Oggi ogni DPO che implementa seriamente la privacy by design sta facendo, di fatto, il lavoro che la Commissione non ha completato. Sarebbe ora che la Commissione ricambiasse il favore».
Metà del volume è dedicata non al diritto ma all’implementazione: modelli di maturità, resistenze culturali, persino i copioni per rispondere alle obiezioni degli ingegneri. Perché un libro giuridico ha bisogno di tutto questo?
«Perché la domanda che ricevevo più spesso non era “cosa dice la norma?” ma “ho costruito il sistema, ho capito il metodo, e i miei ingegneri continuano a non usarlo”. Quella domanda meritava una risposta seria, e non è una risposta giuridica: è una risposta su come cambiano davvero le organizzazioni. Per questo il libro affronta le due resistenze tipiche — quella alla velocità (“ci rallenterete”) e quella alla responsabilità individuale (“non metto il mio nome su quel documento”) — con strumenti concreti: automazione dei controlli nella pipeline di sviluppo, politiche scritte di tutela per chi firma, e un modello di maturità per misurare i progressi trimestre dopo trimestre. La privacy by design che non si può provare è privacy per aspirazione; la privacy by design che non viene adottata è privacy per circolare interna. Il libro esiste per chiudere entrambi i divari».
A chi si rivolge il libro, e dove sarà disponibile?
«A tre lettori: i DPO e i professionisti della compliance che devono rispondere “entro venerdì” alla domanda del proprio CTO; i responsabili tecnici e di prodotto che vogliono capire cosa la legge chiede davvero al loro lavoro quotidiano; e le aziende extra-europee che stanno entrando nel mercato UE. È scritto in inglese, con modelli, checklist e casi di studio pronti all’uso. Sarà disponibile su Amazon dal 15 luglio, e un’edizione italiana è in preparazione».