Grazie al lavoro di alcuni esperti esterni, il Comitato Europeo per la Protezione dei Dati (“EDPB”, consesso delle autorità privacy dell’Unione) ha recentemente pubblicato, in libero accesso, due vademecum formativi, tra loro complementari, per colmare il divario tra requisiti legali, implementazione tecnica e loro comprensione e conoscenza della spinosa e complessa materia dell’intelligenza artificiale, ormai ineludibile e pervadente.
Documenti che rappresentano una sorta di “manuale” formativo per i professionisti tech e uno per i legali, per navigare la complessità di AI Act e GDPR lungo l’intero ciclo di vita dei sistemi di AI.
Indice degli argomenti
AI generativa e privacy: un quadro giuridico complesso
Difatti l’intelligenza artificiale è ormai una realtà pervasiva che sta trasformando aziende, pubbliche amministrazioni e la società nel suo complesso: dall’ottimizzazione dei processi di business alla creazione di nuovi servizi per i cittadini, le opportunità sono immense.
Con l’adozione su larga scala di queste tecnologie, immensi sono anche le sfide e i rischi, in particolare per quanto riguarda la protezione dei dati personali e la conformità normativa.
Con l’entrata in vigore dell’AI Act, che si affianca al GDPR, aziende e P.A. si trovano di fronte a un quadro giuridico complesso, il quale richiede un approccio strutturato e multidisciplinare per innovare in modo responsabile.
In questo scenario, orientarsi non è semplice. La domanda che ogni DPO, manager e sviluppatore si pone è: come tradurre i principi legali in pratiche tecniche concrete e viceversa?
A questa esigenza fondamentale rispondono due esperti, facenti parte del Support Pool of Experts dell’EDPB, un programma che commissiona report e strumenti di approfondimenti e compliance su temi specifici.
Ne fanno parte i due recenti documenti “gemelli”, di rilevante valore strategico e formativo, pensati per creare un ponte tra il mondo legale e quello tecnologico. Si tratta di due percorsi formativi complementari:
- “Fundamentals of Secure Al Systems with Personal Data”, a cura di Enrico Glerean (ricercatore scientifico), è un percorso formativo rivolto a un’audience tecnica: professionisti della cybersecurity, data scientist, amministratori di sistema e ingegneri ML. L’obiettivo è fornire le competenze pratiche per creare e implementare sistemi di AI sicuri che trattano dati personali, in linea con gli obblighi legali ed etici;
- “Law & Compliance in Al Security & Data Protection”, a cura di Marco Almada (ricercatore giuridico), è invece progettato per i professionisti della privacy e della protezione dei dati, diciamo più di formazione legale e gestionale, come DPO, privacy manager, ecc. Questo manuale non presuppone competenze tecniche avanzate, fornisce gli strumenti concettuali per comprendere le implicazioni legali delle scelte tecnologiche, dialogare efficacemente con gli esperti tecnici e governare la compliance in ambito AI.
Conformità dei sistemi di AI: un compito legal e tech
La peculiarità di questi due documenti risiede proprio nella loro complementarità: essi riconoscono che la conformità dei sistemi di AI non può essere un compito relegato ai soli uffici legali, né la sicurezza un’incombenza esclusiva dei team tecnici.
Al contrario, è il risultato di una collaborazione e di un vocabolario condiviso tra diverse figure professionali.
Ecco perché ci si sente di poter affermare che tutti i destinatari delle due guide, in realtà, dovrebbero leggere e studiare entrambi i testi, parimenti accessibili. E costruiti, peraltro, con domande di test a fine capitoli, onde verificare la comprensione, utile così anche per la formazione professionale.
Coprendo l’intero ciclo di vita di un sistema di AI – dall’ideazione (inception) fino al monitoraggio e al ritiro (decommissioning) – questi documenti offrono un approccio olistico indispensabile per implementare i principi di privacy by design e security by design richiesti dal GDPR e dall’AI Act.
Veri e propri manuali operativi che ogni organizzazione, pubblica o privata, dovrebbe considerare come uno strumento strategico per affrontare la rivoluzione dell’AI in modo sicuro, etico e conforme.
Altresì, non da ultimo, per integrare la formazione in tema AI richiesta dall’art. 4 dell’AI Act — e dalla relativa definizione di “AI literacy” contenuta nell’art. 3 n. 56 —, ove impone a provider e deployer di “adottare misure idonee a garantire, per quanto possibile, un adeguato livello di alfabetizzazione in materia di AI per il personale e per chiunque utilizzi i sistemi per loro conto”, tenendo conto di competenze pregresse, contesto d’uso e categorie di persone coinvolte.
In assenza di uno “standard unico” su come soddisfare tale requisito, l’adozione di percorsi strutturati e verificabili come i due vademecum dell’EDPB costituisce una risposta immediata e pragmatica: offre contenuti calibrati sulle diverse professionalità, integra momenti di auto-valutazione e, soprattutto, crea quel vocabolario condiviso che il legislatore europeo considera la condizione minima per assicurare trasparenza (art. 13 AI Act) e supervisione umana (art. 14 AI Act) lungo l’intero ciclo di vita del sistema.
Vediamo di seguito come tuffarci in una breve panoramica dei due documenti, per giustificare quanto detto.
La guida tecnica: “Fundamentals of Secure Al Systems”
La prima guida è un vero e proprio percorso formativo per professionisti con un background tecnico informatico.
Il suo scopo è fornire gli strumenti pratici per progettare, sviluppare, implementare e mantenere sistemi di intelligenza artificiale che trattino dati personali in maniera il più possibile sicura e conforme.
Il documento segue l’intero ciclo di vita di un sistema di AI così come definito dallo standard internazionale ISO 5338 (definisce i processi e i concetti per descrivere il ciclo di vita AI, estendendo e modificando i processi dei cicli di vita tradizionali del software e dei sistemi per includere specificità dell’AI, come il continuo aggiornamento dei modelli di machine learning con nuovi dati).
Il percorso si articola lungo le fasi chiave dello sviluppo software applicate all’AI, mappandole su un moderno framework di MLOps (Machine Learning Operations), con un’attenzione specifica alla sicurezza (“secMLOps”). I capitoli guidano il lettore attraverso:
- i concetti fondamentali di AI, data protection e cybersecurity;
- la gestione e la preparazione del dato (Data Engineering), incluse le tecnologie specifiche per la privacy (“PETs”, Privacy Enhancing Technologies);
- lo sviluppo sicuro del codice e dei modelli:
- le pratiche di test e validazione per resistere agli attacchi:
- il deployment, il monitoraggio e la dismissione sicura dei sistemi;
- gli strumenti pratici per l’auditing dei sistemi di AI.
In sostanza, è un manuale che circoscrive il know-how dal punto di vista del design di prodotto. Nonostante il target primario sia tecnico (ingegneri, data scientist, professionisti della cybersecurity), il documento è stato deliberatamente reso accessibile a un’audience più vasta.
L’autore sottolinea strategicamente che il testo non contiene formule matematiche né esempi di codice: l’obiettivo non è solo formare i tecnici, è anche stimolare e facilitare il dialogo tra i diversi esperti coinvolti in un progetto di AI, inclusi legali, DPO e manager. Fornisce un vocabolario comune e una comprensione condivisa delle sfide tecnologiche, permettendo anche a figure non tecniche di comprendere i processi, porre le domande giuste e valutare i rischi in modo più consapevole.
Pertanto, la sua lettura è fortemente consigliata anche a DPO e figure legali che desiderano capire “cosa c’è sotto il cofano” senza doversi addentrare nei dettagli implementativi.
Alcuni focus: pipeline di trasformazione dei dati e supply chain
Un aspetto di grande interesse, spesso sottovalutato nelle discussioni manageriali, è la granularità con cui la guida affronta il trattamento del dato prima ancora che questo venga utilizzato per l’addestramento.
Il Capitolo 4 mostra come il “dato grezzo” (Raw Data) subisca una serie di trasformazioni critiche, ognuna delle quali è un punto di controllo per la compliance:
- acquisizione del dato: il manuale distingue tra raccolta di dati di prima parte, di terza parte e tramite interrogazione (querying), evidenziando per ciascuna le implicazioni legali;
- pre-processing e sanitizzazione: qui avvengono le operazioni cruciali di minimizzazione e pseudonimizzazione, attraverso tecniche come la generalizzazione (sostituire un’età con una fascia d’età), la soppressione (rimuovere un identificativo), la perturbazione (aggiungere “rumore” statistico) e la data anatomization (separare gli identificativi dai dati particolari/sensibili, mantenendo legami di gruppo, quale variante della bucketization);
- analisi e arricchimento: il dato viene poi ulteriormente lavorato tramite estrazione di feature, etichettatura (labeling) e data augmentation per migliorare le performance del modello.
Questa visione a pipeline è altrettanto fondamentale per un DPO, perché chiarisce come la protezione del dato sia un processo continuo con molteplici punti di vulnerabilità e altrettante opportunità di intervento.
La guida sottolinea anche la necessità di una gestione del consenso (consent management) differenziata per le varie categorie di interessati coinvolti: non solo i soggetti dei dati originali, si aggiungono gli utenti finali del sistema e persino gli “annotatori” umani che contribuiscono a perfezionare i modelli.
Un altro punto non banale è l’enfasi posta sui rischi della supply chain del software, un tema cruciale nell’era dell’AI “componibile“, dove i sistemi sono spesso un assemblaggio di componenti di terze parti.
Il Capitolo 6 va oltre la sicurezza del codice scritto in-house e mette in guardia contro tre rischi specifici e concreti:
- librerie di machine learning vulnerabili: strumenti di uso comune come TensorFlow, PyTorch o Scikit-learn possono contenere vulnerabilità. La guida raccomanda di usare strumenti di scansione per monitorare costantemente queste dipendenze;
- modelli pre-addestrati riutilizzati: l’uso di modelli scaricati da repository come Hugging Face – una pratica comunissima per risparmiare tempo e risorse – introduce rischi significativi. Un modello pre-addestrato potrebbe contenere backdoor nascoste o essere stato vittima di “data poisoning” (avvelenamento dei dati di training), inducendo comportamenti anomali o dannosi che persistono persino dopo il fine-tuning;
- librerie di serializzazione insicure: questo è un rischio tecnico molto specifico ma di grande impatto. La guida avverte che l’uso di librerie standard – come Pickle in Python – per salvare e caricare modelli è pericoloso. Un file malevolo, se de-serializzato, può portare all’esecuzione di codice arbitrario sul sistema, compromettendolo completamente. Il caso reale della vulnerabilità “ShellTorch” viene citato come esempio emblematico di questo pericolo.
Questo approccio sposta l’attenzione dalla sicurezza del singolo modello alla sicurezza dell’intera catena di sviluppo e deployment, un cambio di prospettiva essenziale per chiunque voglia costruire o utilizzare sistemi di AI robusti e affidabili.
La guida legale: “Law & Compliance in Al Security & Data Protection”
Se la prima guida è il “come” tecnico, la seconda ne è il “cosa” e il “perché” dal punto di vista legale e di compliance. Questo secondo percorso è speculare al primo, progettato specificamente per professionisti della privacy, DPO, avvocati e responsabili della compliance.
L’obiettivo è fornire una solida comprensione del quadro giuridico che governa l’intelligenza artificiale nell’Unione Europea, con un focus sull’intersezione tra il nuovo AI Act e il GDPR.
Il percorso segue lo stesso ciclo di vita dei sistemi di AI, analizzando ogni fase attraverso la lente della legge. Partendo dai concetti fondamentali, la guida illustra:
- i rischi e le opportunità dell’AI, introducendo la logica e la struttura dell’AI Act;
- i concetti tecnici di base dell’AI, spiegati in modo astratto e funzionale alla comprensione legale;
- le implicazioni legali per ogni fase del ciclo di vita: inception, progettazione, sviluppo, validazione, deployment e monitoraggio;
- approfondimenti su temi avanzati e cruciali come la “fairness” (correttezza, equità), la trasparenza (incluso il discusso e tuttora incerto “diritto alla spiegazione“), la responsabilità e le sfide specifiche poste dai Large Language Models (LLM).
In sintesi, si tratta di una bussola legale minima, indispensabile per orientarsi nelle complesse acque tempestose della regolamentazione dell’AI.
Questa guida si rivolge – primariamente ma non solo – a un’audience legal e presuppone una familiarità di base con i concetti chiave del GDPR, come “interessato” o “trattamento”.
Il suo più grande pregio è la sua accessibilità anche per un pubblico non tecnico: l’autore chiarisce che il manuale non presuppone alcuna esperienza pregressa con gli aspetti tecnici dell’AI.
I concetti tecnologici sono introdotti a un livello di astrazione sufficiente a fornire ai legali il vocabolario necessario per una comunicazione efficace con sviluppatori e ingegneri. Questo rende la guida uno strumento prezioso anche per i team tecnici, che possono utilizzarla per comprendere il “perché” dietro ai requisiti di conformità che sono chiamati a implementare, facilitando un approccio alla sicurezza e alla privacy che sia realmente “by design”.
Alcuni focus: mappatura dei ruoli nell’AI e opacità come rischio
Un punto di forza della seconda guida è la chiarezza con cui mappa i ruoli consolidati del GDPR (titolare e responsabile del trattamento, in particolare) sui nuovi ruoli dell’AI Act (fornitore, distributore, utilizzatore/deployer). L’analisi non è banale perché evidenzia come questi ruoli non siano statici, possono cambiare dinamicamente a seconda delle azioni intraprese.
La guida sottolinea un’eventualità cruciale che può rappresentare una vera e propria “trappola” per la compliance: un utilizzatore (deployer) può diventare a tutti gli effetti un fornitore (provider).
Questo accade per es. se un’organizzazione prende un sistema di AI e ne modifica sostanzialmente la finalità, facendolo ricadere in una categoria ad alto rischio non prevista dal fornitore originale. Immaginiamo un’azienda che adatta un chatbot generico per il servizio clienti (a rischio limitato) per fare lo screening dei CV dei candidati (un’applicazione ad alto rischio): in quel momento, l’azienda eredita tutti i pesanti obblighi di un fornitore di sistemi ad alto rischio.
Allo stesso modo, il documento analizza la complessità della contitolarità (joint controllership) quando lo sviluppo di un modello viene commissionato a terzi, chiarendo come la responsabilità dipenda dal grado di discrezionalità tecnica lasciata allo sviluppatore rispetto alle istruzioni fornite dal committente.
Questa mappatura dinamica dei ruoli è uno strumento essenziale per ogni DPO per allocare correttamente le responsabilità nei contratti e nei processi interni.
Un ulteriore concetto disaminato nella seconda guida è l’opacità non già come una semplice caratteristica tecnica dell’AI, bensì come un rischio di compliance in sé (Cap. 4.3). La guida distingue utilmente tra due fonti di opacità:
- opacità tecnica: è il classico problema della “black box“, derivante dalla complessità matematica di modelli basati sulle reti neurali, i cui meccanismi interni sono difficili da interpretare persino per gli esperti;
- opacità legale/strategica: questa è la fonte più insidiosa, si tratta della deliberata volontà di non divulgare informazioni per proteggere segreti commerciali, proprietà intellettuale o, nel caso di enti pubblici, per evitare che i sistemi vengano “aggirati” (per es. algoritmi antifrode).
Il punto cruciale è l’interazione tra le due tipologie di opacità: un’organizzazione (l’utilizzatore) può essere legalmente responsabile per gli output di un sistema di AI e quindi tenuta a fornire una “spiegazione significativa” agli interessati.
Tuttavia, potrebbe trovarsi contrattualmente “bloccata” dal fornitore a monte, il quale per proteggere la propria proprietà intellettuale può negare l’accesso alle informazioni necessarie per formulare tale spiegazione.
Questo crea un cortocircuito di responsabilità in cui l’utilizzatore finisce stretto tra gli obblighi di legge e le limitazioni contrattuali. Comprendere questa duplice natura dell’opacità è fondamentale per chiunque si occupi di acquistare o integrare tecnologie di AI di terze parti.
AI generativa e privacy: abbattere i silos tra legal e tech
In un dominio così scivoloso e in divenire come l’AI – dove i veri esperti con una visione a 360° si contano sulle dita di una mano e, di fatto, tutti noi “operativi” siamo in un processo di apprendimento continuo e quotidiano, oltre che di mutamento tecnologico e di mercato senza pause – il merito principale delle due guide pubblicate dall’EDPB è quello di fornire un ponte, un vocabolario comune per abbattere i silos tra il mondo legale e quello tecnologico.
Non si tratta di documenti isolati, esistono altrettanto valide e autorevoli risorse formative, come l’AI Risk Management Framework del NIST statunitense, i corsi di AI Governance sulla ISO 42001 o di enti come AIPP, o ancora vari e validi percorsi accademici offerti da numerose università.
E non si dimentichi la precedente guida sui rischi dell’AI generativa, di ottimo livello, pubblicata nel 2023 sempre da EDPB e curata dall’esperta Isabel Barberà, intitolata “Large Language Models”.
Va aggiunto che nel proliferare di materiale e la sua specifica complessità tecnica non è sempre facile capire dove e come aggiornarsi e chiarirsi le idee, specie quando non si ha tanto tempo a disposizione al netto della propria attività lavorativa.
Serve un’attività di formazione aziendale continua
La vera sfida non è la disponibilità di materiale, lo è la sua concreta adozione e assimilazione utile da parte di chi dovrebbe farlo. Questi documenti dell’EDPB, strutturati come veri e propri “curricula formativi”, potrebbero diventare la base per un’attività di formazione aziendale continua.
Purtroppo, specialmente nel contesto italiano, l’alta formazione professionale, su temi strategici come questo, viene spesso disattesa per una mancanza di lungimiranza e (spesso presunte) carenze di budget, privilegiando l’implementazione immediata rispetto alla gestione del rischio a lungo termine.
La formazione, per essere efficace, non può essere un evento sporadico: deve essere un processo continuo, multidisciplinare e pratico, capace di riunire attorno a un tavolo interdisciplinare DPO, ingegneri, manager e responsabili di prodotto per analizzare casi concreti, proprio come le guide incoraggiano a fare.
Ignorare la necessità di una formazione profonda e trasversale espone l’intera organizzazione a rischi concreti e potenzialmente devastanti, che si manifestano in modo diverso per le diverse figure professionali.
Un comprensione tecnica di base per DPO e team legali
Per i DPO e i team legali, la mancanza di una comprensione tecnica di base significa anzitutto l’impossibilità di effettuare una valutazione d’impatto (DPIA) efficace: non si possono valutare i rischi di un trattamento se non si comprende come il dato viene processato, trasformato e utilizzato per addestrare un modello.
Inoltre, può significare essere in balia dei fornitori: un DPO senza competenze tecniche non può contestare efficacemente un fornitore che nega l’accesso a informazioni cruciali invocando il “segreto commerciale”, perché non saprebbe distinguere ciò che è essenziale per la compliance da ciò che non lo è.
Il DPO e i vari referenti privacy aziendali rischiano così di ridursi a un “timbrificio”, approvando progetti di AI sulla base di documentazione superficiale o incomprensibile o fuorviante, venendo meno al proprio ruolo di supervisore e garante della protezione dei dati.
Un solida cultura legale e di compliance per i team tecnici
Per i team tecnici (ingegneri, data scientist), l’assenza di una solida cultura legale e di compliance comporta l’alto rischio di progettazione e costruzione di prodotti e servizi nativamente non conformi (non-privacy by design).
Un ingegnere può creare un modello dalle performance eccezionali, intrinsecamente illecito perché addestrato su dati senza idonea base giuridica – oppure perché le sue caratteristiche tecniche rendono impossibile l’esercizio dei diritti degli interessati, come il diritto alla cancellazione.
Inoltre, uno sviluppatore potrebbe riutilizzare un modello pre-addestrato senza conoscerne i rischi di “data poisoning” o integrare una libreria per la serializzazione come Pickle senza essere consapevole che essa può consentire l’esecuzione di codice arbitrario, aprendo una falla di sicurezza per l’intera azienda.
In definitiva, si tratta di sprecare immense risorse nello sviluppo di sistemi che, una volta giunti alla fase di audit, si rivelano non conformi e devono essere ritirati o riprogettati da capo, con un enorme danno economico e reputazionale.
Un riflessione laterale sullo sviluppo dei sistemi di AI
Per chiudere, un’ultima, laterale riflessione: c’è qualcosa di ironico nello sforzo titanico che traspare da queste centinaia di pagine.
Costruiamo architetture logiche di una complessità inaudita, reti neurali con miliardi di parametri capaci di processare l’intero scibile umano disponibile su Internet, le addestriamo con una potenza di calcolo che fino a ieri apparteneva alla fantascienza.
Poi passiamo il nostro tempo a cercare di insegnare a queste super-macchine le basi della convivenza civile: non discriminare, essere trasparenti, non dire il falso (le “allucinazioni”), chiedere il permesso, ecc. Poi a cercare di (re)insegnare a noi stesse come capire se e come questi strumenti hanno o meno imparato anche questo.
Queste guide, con la loro meticolosa elencazione di rischi, controlli e procedure, sono il diario della nostra forse goffa – ma necessaria – impresa di trasferire secoli di diritto e di etica dentro un algoritmo e, soprattutto, dentro la nostra capacità e volontà di gestirlo.
Forse alla fine il vero scopo dell’AI è costringerci a sederci attorno a un tavolo per decidere, una volta per tutte, cosa intendiamo per “giusto”.
I documenti dell’EDPB possono essere le prime, indispensabili pagine dei compiti a casa.
