Ho lavorato in ambito IT sia con enti pubblici sia con aziende private e, passando negli anni da infrastrutture, sistemi, sicurezza, utenti, applicazioni e inevitabili emergenze dell’ultimo minuto, ho imparato una cosa abbastanza semplice: i dati entrano in quasi tutto ciò che facciamo, anche quando non ce ne accorgiamo. Una nuova applicazione, una piattaforma cloud, un gestionale, un sistema di videosorveglianza, un servizio HR, una newsletter, un CRM, una soluzione di cybersecurity e oggi, naturalmente, qualsiasi strumento basato sull’intelligenza artificiale possono aprire questioni che non riguardano soltanto la tecnologia. Riguardano persone, informazioni, responsabilità e scelte.
È per questo che considero il DPO, il Data Protection Officer o Responsabile della Protezione dei Dati, una figura molto più interessante di quanto lasci pensare la definizione burocratica con cui spesso viene presentato. Il GDPR ne disciplina la presenza in maniera molto precisa e non tutte le aziende sono obbligate a nominarlo; personalmente, però, credo che ogni organizzazione dovrebbe almeno fermarsi a valutare seriamente se abbia bisogno di una figura con quelle competenze, al di là della semplice domanda “la legge mi obbliga oppure no?”.
Non perché serva aggiungere un’altra casella all’organigramma, ma perché nel 2026 i dati viaggiano letteralmente alla velocità della luce e spesso arrivano su servizi, sistemi e piattaforme prima ancora che qualcuno abbia avuto il tempo di chiedersi dove finiranno.
Il DPO non è “quello della privacy”
Una delle semplificazioni che mi convince meno è immaginare il DPO come la persona alla quale mandare l’informativa da controllare prima di pubblicarla sul sito. È una parte infinitesimale del problema.
Il GDPR assegna al DPO funzioni di informazione e consulenza verso l’organizzazione, monitoraggio della conformità, sensibilizzazione e formazione del personale, supporto nelle valutazioni d’impatto sulla protezione dei dati e rapporto con l’autorità di controllo. Deve inoltre essere coinvolto tempestivamente nelle questioni che riguardano i dati personali e operare con una reale indipendenza.
Questa impostazione mi piace perché colloca il DPO in un punto particolare dell’azienda: abbastanza vicino ai processi da comprenderli, ma sufficientemente indipendente da poter fare domande scomode.
E le domande scomode, in questo campo, servono.
Possiamo davvero caricare questi documenti su quel servizio? Per quanto tempo conserveremo quei dati? Chi vi accede? Perché li raccogliamo? Quel nuovo sistema registra più informazioni di quelle che ci servono? Il fornitore dove le tratta? Abbiamo valutato il rischio? Se introduciamo un nuovo strumento di AI generativa, sappiamo esattamente cosa gli utenti potrebbero incollare all’interno di un prompt?
Sono domande che raramente bloccano l’innovazione; quando poste nel momento giusto, spesso evitano semplicemente di doverla correggere dopo.
Quando il DPO è obbligatorio, e quando invece può essere una scelta
Qui è importante distinguere opinioni personali e normativa.
Il GDPR rende obbligatoria la designazione del DPO, tra gli altri casi, quando il trattamento è effettuato da un’autorità o organismo pubblico, quando le attività principali richiedono un monitoraggio regolare e sistematico degli interessati su larga scala oppure quando le attività principali comportano il trattamento su larga scala di categorie particolari di dati personali o dati relativi a condanne e reati. Negli altri casi la designazione può essere volontaria.
Ed è proprio qui che, secondo me, comincia la parte interessante.
Non essere obbligati a nominare formalmente un DPO non significa non avere bisogno di una governance della privacy. Lo stesso European Data Protection Board invita le organizzazioni che non rientrano nell’obbligo a valutare comunque una nomina volontaria oppure l’individuazione di una persona che, senza assumere formalmente il titolo di DPO, possa seguire la conformità e fungere da riferimento sui temi di protezione dei dati.
Questa distinzione è importante soprattutto per le aziende più piccole. A volte la soluzione corretta sarà un DPO vero e proprio, magari esterno; altre volte sarà più sensato costruire una responsabilità privacy chiara senza formalizzare una figura che il GDPR non richiede. Quello che eviterei è la terza possibilità, purtroppo ancora frequente: nessuno se ne occupa davvero finché non arriva un problema.
Il DPO non dovrebbe essere l’ennesimo cappello messo in testa all’IT
Da persona che lavora nell’ICT, questa è probabilmente la parte sulla quale tengo maggiormente a fare chiarezza.
Privacy, sicurezza informatica e infrastruttura tecnologica sono strettamente collegate, ma non sono la stessa cosa. Il reparto IT può sapere perfettamente dove si trovano i server, quali backup esistono, come viene effettuata l’autenticazione, quali log vengono prodotti e come sono configurati firewall, endpoint e servizi cloud; il DPO guarda anche a tutto questo, ma attraverso una prospettiva differente, che comprende liceità del trattamento, minimizzazione dei dati, diritti degli interessati, accountability, conservazione, valutazioni di impatto e governance complessiva.
Le due competenze devono parlarsi continuamente, non essere confuse.
C’è anche un motivo normativo molto concreto: il DPO deve poter lavorare senza conflitti di interesse. L’EDPB ricorda che chi ricopre ruoli attraverso i quali determina finalità e mezzi del trattamento può trovarsi in una posizione incompatibile con quella del DPO e cita esplicitamente, tra i ruoli tipicamente problematici, anche l’Head of IT.
È abbastanza intuitivo: sarebbe difficile chiedere alla stessa persona di decidere come un sistema debba trattare i dati e, contemporaneamente, controllare in modo indipendente se quella decisione sia corretta.
Per questo considero molto più sano un rapporto nel quale ICT e DPO lavorino fianco a fianco. L’IT porta conoscenza tecnica e comprensione dell’infrastruttura, il DPO introduce la prospettiva normativa e di tutela delle persone; cybersecurity, legal, HR, procurement e management completano il quadro. Nessuna di queste funzioni dovrebbe pensare di poter affrontare da sola un tema diventato ormai trasversale all’intera organizzazione.
Poi è arrivata l’intelligenza artificiale, e il confine è diventato ancora più sottile
Fino a qualche anno fa era relativamente semplice spiegare a un utente aziendale dove non dovesse mettere un file riservato: non inviarlo attraverso servizi personali, non copiarlo su dispositivi non autorizzati, non caricarlo su piattaforme sconosciute.
Con l’AI generativa il gesto è diventato quasi invisibile.
Si apre una finestra, si scrive una domanda e in pochi secondi un documento, una mail, un contratto, un curriculum, un report commerciale o una parte di codice possono essere copiati all’interno di un sistema esterno senza che chi lo sta facendo abbia necessariamente la percezione di aver appena trasferito informazioni aziendali.
È uno scenario nel quale il DPO, secondo me, acquista ancora più valore, perché il problema non si risolve semplicemente vietando strumenti o bloccando siti. Serve capire quali sistemi possono essere utilizzati, quali dati possono entrarvi, con quali configurazioni, quali contratti, quali garanzie e quale formazione debba ricevere chi li utilizza.
L’AI Act non sostituisce il GDPR. Il regolamento europeo sull’intelligenza artificiale precisa che gli obblighi esistenti sulla protezione dei dati continuano ad applicarsi quando progettazione, sviluppo o utilizzo di sistemi di AI comportano il trattamento di dati personali; richiama inoltre espressamente principi come minimizzazione e protezione dei dati fin dalla progettazione.
E questo oggi non è più un discorso teorico. L’AI Act è diventato applicabile dal 2 agosto 2026, pur con calendari differenziati per alcune categorie di sistemi ad alto rischio, mentre vari obblighi erano già entrati in applicazione precedentemente.
In pratica, la governance dei dati e la governance dell’AI stanno iniziando inevitabilmente a incontrarsi.
La privacy funziona meglio quando arriva all’inizio, non alla fine
Nella mia esperienza, questo è un principio che vale tanto per l’ICT quanto per la protezione dei dati: correggere una scelta sbagliata quando un sistema è già in produzione costa quasi sempre più tempo, più denaro e più fatica che porsi alcune domande prima di implementarlo.
Un DPO realmente integrato nei processi aziendali può contribuire proprio qui.
Non deve essere il controllore che compare il giorno prima del go-live per dire cosa non si può fare; dovrebbe partecipare abbastanza presto da aiutare l’organizzazione a capire come farlo correttamente.
È la logica della privacy by design applicata alla vita reale.
Se sto scegliendo un nuovo CRM, introducendo un software HR, installando un sistema di controllo accessi, migrando informazioni nel cloud o offrendo ai dipendenti una piattaforma AI, è molto più utile discutere dei dati durante la progettazione che scoprire sei mesi dopo che qualcosa andava impostato diversamente.
E questo è anche il motivo per cui credo che la presenza del DPO debba essere percepita come una risorsa e non come un freno. Un buon DPO non dice semplicemente “no”; dovrebbe aiutare a trasformare un “così non va bene” in un “possiamo farlo in questo modo”.
Sicurezza e privacy non sono sinonimi
Un sistema può essere tecnicamente molto sicuro e contemporaneamente trattare dati in maniera non corretta.
Possiamo avere MFA, cifratura, endpoint protection, firewall di ultima generazione, backup immutabili e procedure di incident response perfettamente organizzate, ma continuare a raccogliere informazioni che non ci servono, conservarle troppo a lungo oppure condividerle con un servizio esterno senza aver valutato adeguatamente il trattamento.
Viceversa, una documentazione GDPR impeccabile non servirà a molto se un account amministrativo utilizza Password123.
Mi piace pensare alla cybersecurity e alla privacy come a due prospettive sulla stessa realtà. Una domanda prevalentemente “come proteggo questi dati?”, l’altra anche “perché li possiedo, cosa ne sto facendo e dovrei averli?”. Quando entrambe funzionano bene, il risultato è una gestione dell’informazione decisamente più matura.
Una figura che parla anche di cultura aziendale
C’è infine un aspetto che considero persino più importante delle procedure.
Possiamo scrivere policy perfette, predisporre informative, registri, DPIA e documentazione impeccabile, ma poi arriva qualcuno che invia un Excel con dati personali al destinatario sbagliato oppure copia informazioni riservate dentro un chatbot perché “dovevo solo farmi riassumere il documento”.
La protezione dei dati è soprattutto cultura.
Un buon DPO dovrebbe contribuire anche a questa cultura, facendo formazione, aiutando le persone a capire il perché delle regole e creando un rapporto nel quale chiedere un parere prima di fare qualcosa non venga vissuto come una complicazione burocratica.
Il GDPR attribuisce infatti al DPO anche compiti di sensibilizzazione e formazione del personale coinvolto nei trattamenti, oltre al monitoraggio della conformità.
Ed è probabilmente proprio questa dimensione che oggi mi interessa di più: passare da una privacy vissuta come insieme di documenti da produrre a una privacy intesa come parte naturale del modo in cui un’organizzazione pensa.
Quindi tutte le aziende dovrebbero avere un DPO?
Formalmente, no… e sarebbe sbagliato sostenerlo.
Ma tutte le aziende dovrebbero almeno chiedersi chi, al proprio interno o all’esterno, stia guardando con competenza e indipendenza al modo in cui vengono trattati i dati.
Per alcune la risposta sarà un DPO obbligatorio; per altre un DPO nominato volontariamente; per altre ancora una struttura privacy proporzionata alle dimensioni e ai rischi dell’organizzazione. L’importante è che esista una risposta, perché siamo entrati in una fase nella quale parlare di dati personali come di qualcosa confinato all’amministrazione, all’ufficio legale o al modulo della cookie policy significa non aver compreso quanto profondamente la tecnologia abbia trasformato le aziende.
Cloud, smart working, piattaforme SaaS, cybersecurity, analisi dei dati e intelligenza artificiale hanno reso l’informazione uno degli elementi più mobili dell’intera organizzazione. I dati vengono creati, copiati, analizzati, sincronizzati e trasferiti continuamente e, mentre tutto questo accade, dietro quei dati continuano ad esserci persone.
Da sistemista e professionista ICT tendo naturalmente a guardare infrastrutture, processi e tecnologie; con gli anni, però, ho imparato che la domanda più importante non è sempre “funziona?”.
A volte è “dovremmo farlo in questo modo?”.
Ed è esattamente lì che una figura come il DPO può fare la differenza: non mettendosi tra l’azienda e l’innovazione, ma aiutandole a viaggiare insieme, possibilmente nella stessa direzione.
In un’epoca nella quale l’intelligenza artificiale è ormai ovunque e i dati si muovono più velocemente di quanto riusciamo spesso a rendercene conto, mi sembra un investimento di maturità prima ancora che di conformità.
Nota: questo articolo esprime una riflessione professionale sul ruolo del DPO e non costituisce consulenza legale; la necessità della nomina e la corretta organizzazione della funzione vanno valutate sul caso concreto.
