L’EDPB ha adottato a marzo 2026 il primo modello armonizzato di DPIA, oggi ancora in consultazione e destinato a diventare il formato con cui le valutazioni d’impatto si scriveranno. Messo alla prova su un trattamento implementato con agenti di IA, il modello regge, ma su tre punti l’esito è diverso da quello atteso. Il pezzo verifica i tre punti e arriva alla condizione che il modello presuppone senza nominarla: la DPIA di un trattamento agentico comincia nel disegno del trattamento, non nel documento.
Il Template for Data Protection Impact Assessment, adottato dall’EDPB il 10 marzo 2026 e posto in consultazione pubblica, si presenta in un formato che tutte le autorità di controllo dovrebbero accettare senza particolari obiezioni. Un formato con questa vocazione non resta a lungo una delle opzioni disponibili, piuttosto diventa il modo in cui le valutazioni d’impatto vengono scritte. Vale allora la pena chiedersi come si comporti davanti ad uno dei banchi di prova più attuali, i trattamenti implementati con agenti di IA.
Il punto di partenza è anche quello su cui si sbaglia più spesso: l’agente non è un trattamento, è un mezzo per implementarlo. Lo stesso agente può eseguire operazioni di trattamenti diversi, e un trattamento può essere agentico soltanto in parte, per il resto affidato ad altri sistemi o a operatori umani. La valutazione resta quella del trattamento e la domanda riguarda ciò che cambia nel trattamento per il fatto di essere implementato con queste modalità.
La difficoltà attesa è che l’oggetto da descrivere decide in autonomia parte di ciò che il titolare dovrebbe dichiarare: in quali passi scomporre il compito, quali fonti consultare, cosa trattenere in memoria. Se ne potrebbe concludere che al template manchino dei campi. Percorrerlo campo per campo, con la guida dell’AEPD sull’IA agentica (versione 1.2, febbraio 2026) come termine di confronto, porta altrove, quasi tutti i campi si lasciano compilare, ma a una condizione che il modello presuppone e non dichiara.
Indice degli argomenti
La memoria dell’agente e il dato mai fornito
Il primo banco di prova è la memoria. Un agente conserva tra un compito e l’altro anche dati che l’interessato non ha mai fornito, sono le inferenze generate in esecuzione e trattenute per le risposte future. La guida AEPD mette in ordine distinguendo due memorie che il dibattito confonde: la memoria di lavoro, che alimenta l’agente, e la memoria di gestione, cioè i registri di attività (prompt, inferenze, tracce delle chiamate ai servizi) che ciascun componente accumula.
È la seconda a mettere in difficoltà il modello, questo perché è il mezzo a produrre quei dati nel corso dell’esecuzione. Il problema affiora nella sezione 2.2, che chiede di giustificare necessità e pertinenza di ciascun dato rispetto alla finalità dichiarata. Per la memoria di lavoro la giustificazione c’è, serve a produrre il risultato; per i registri no, perché servono a dimostrare come il caso è stato gestito e a rilevare abusi, cioè a una finalità diversa. Il modulo, indicizzato sulle finalità, non ha una casella per il dato trattato ma non necessario allo scopo dichiarato, e lungo il percorso di compilazione i registri si incontrano una volta sola, nella sezione 2.3.e, come misura di sicurezza. Eppure, non sono solo una garanzia, anzi, possono registrare sugli utenti più del necessario e, quando i componenti che li producono servono più trattamenti, diventano nodi trasversali di raccolta di dati personali[footnoteRef:1].
L’AEPD qualifica i registri di attività sotto tre profili che convivono: sono una misura di protezione fin dalla progettazione, perché permettono verificabilità e tracciabilità; sono un impatto che dipende da come il sistema è costruito, quando registrano sugli utenti più del necessario e scivolano nell’ipervigilanza; e sono un rischio in senso proprio, in caso di violazione o di riuso per altre finalità.
La risposta non è un campo in più. I registri si dichiarano, ma solo a condizione di dichiarare anche la finalità che li rende necessari, e non basta iscrivere la memoria fra gli asset della 1.3, che registra il contenitore e non il contenuto. Se il sistema è dedicato a un solo trattamento basta una finalità ulteriore, con base e conservazione proprie; ma quando è condiviso, ed è il caso frequente, ripetere gli stessi registri in ogni DPIA produrrebbe giustificazioni divergenti sul medesimo archivio. La via è un trattamento autonomo, che ha per oggetto la gestione, la sicurezza e la tracciabilità del sistema agentico: vi trovano posto una finalità nominabile, la sicurezza, che l’AEPD riconduce al legittimo interesse quando è necessaria e proporzionata, conservazioni differenziate per componente e una categoria di interessati che altrove non compare, i dipendenti che usano l’agente, di cui i registri possono ricostruire il comportamento nel rapporto di lavoro.
Resta fuori la cosa più insidiosa. Stabilire dove la memoria vive lascia impregiudicato ciò che accade quando la stessa memoria è attraversata da più trattamenti, questione che affronteremo nel paragrafo dedicato al perimetro.
Il ciclo di vita del dato: dove nasce il fraintendimento
La sezione 1.2 del modulo scompone il trattamento in fasi, ciascuna qualificata da cinque tipi di operazione: raccolta, uso, conservazione, condivisione e trasferimento, cancellazione e distruzione. Di qui l’obiezione: il campo presumerebbe un ciclo di vita lineare che nell’agente non esiste, perché il dato è recuperato di continuo nella finestra di contesto, ricombinato con il prompt di sistema e i documenti reperiti, passato dalle chiamate a strumenti in una stessa sessione; così, tra i contributi alla consultazione, il commento di Amine Raji, che propone di emendarla.
Il modulo, però, chiede «fasi o stadi» (Explainer, par. 18), e nulla impone che una fase sia un segmento temporale. Letta la fase come classe di operazione[footnoteRef:2], il campo si lascia compilare, e la compilazione resta vera per qualunque esecuzione: presa in carico dell’istanza; assemblaggio del contesto tra memoria e basi documentali; invocazione dei servizi esterni; generazione degli output; scrittura in memoria; registrazione nei log; cancellazione alla scadenza. Le classi restano quelle qualunque traiettoria l’agente scelga, e a variare è soltanto l’ordine in cui le attraversa.
Non un segmento temporale della singola esecuzione, ma un tipo di operazione che ricorre in ogni esecuzione.
La condizione è che il perimetro sia chiuso, cioè che il titolare abbia adottato un catalogo dei servizi invocabili e una lista bianca per ciascun trattamento. A vacillare, in mancanza, non è il campo, ma l’implementazione che non ha deciso i propri confini: la riga descrive allora un insieme aperto, che nessun terzo è in grado di verificare e che il titolare stesso non saprebbe delimitare se glielo si chiedesse.
Un agente, più trattamenti: il problema del perimetro
Dalla premessa iniziale, che lo stesso agente serve trattamenti diversi, discendono fenomeni ignoti all’implementazione tradizionale. I componenti condivisi accumulano dati di interessati coinvolti in trattamenti differenti e una memoria non compartimentata può generare degli effetti collaterali[footnoteRef:3]. Il componente condiviso è un punto unico di compromissione, la cui violazione investe tutti i trattamenti che vi si appoggiano.
Un esempio potrebbe essere che nella risposta resa in un trattamento può affiorare un dato che appartiene a un altro.
In parte il problema si governa compartimentando la memoria per trattamento, per caso, per utente (con una granularità che l’AEPD rimette alla politica del titolare). Per il resto si dichiara: la minaccia va iscritta nella valutazione del trattamento in cui può manifestarsi, la compartimentazione fra le misure che la mitigano, con il proprio stato di attuazione. Anche qui il modulo regge. Ciò che nessuno dei documenti registra è la loro interdipendenza: lo stesso rischio e la stessa misura compaiono in più valutazioni, la loro tenuta dipende da una configurazione unica, e quando un nuovo trattamento si appoggia al medesimo substrato il rischio dei precedenti cambia senza che nulla leghi fra loro quelle valutazioni né imponga di rivederle.
Sarebbe però un errore imputare la criticità al modello. L’unità di misura «trattamento» non l’ha scelta l’EDPB: è l’architettura del GDPR, che costruisce il registro sulle attività di trattamento (art. 30) e riferisce la valutazione a «un tipo di trattamento» (art. 35, par. 1); il modello la eredita perché è un modello di DPIA. Quello che l’uso agentico rende visibile è che l’oggetto tecnico, il sistema condiviso, è più largo dell’oggetto giuridico su cui la valutazione è tarata, e che nell’intercapedine fra i due resta scoperto un rischio che nessuna DPIA, redatta secondo qualunque modello, avrebbe modo di intercettare.
La condizione taciuta
In tutti e tre i casi la compilazione riesce alla stessa condizione e cioè che sul sistema siano già state assunte decisioni che il modello dà per scontate e non nomina. Queste decisioni consistono nella catalogazione dei dati e delle fonti non strutturate, senza la quale l’inventario della sezione 1.1 è un inventario soltanto di nome; nello stabilire il catalogo dei servizi con la relativa lista bianca, in mancanza del quale la descrizione funzionale non delimita alcun perimetro; nella compartimentazione della memoria, che fa coincidere l’ambito della DPIA con un confine reale.
Il modello presuppone tutte queste decisioni e non ne nomina nessuna, ciò genera un effetto asimmetrico. Chi ha governato il trattamento attraversa il modulo senza attriti, mentre chi non l’ha governato incontra campi che non sa riempire con verità, ma riesce comunque a riempirli perché quasi tutte le colonne sono a testo libero. È la differenza tra campi che reggono per struttura, perché un meccanismo del modello fa il lavoro, e campi che reggono per capienza, dove la colonna accoglie qualunque cosa vi si scriva. La minimizzazione riferita alla singola operazione, o la qualificazione dei ruoli dei servizi esterni, hanno lo spazio per essere dichiarate, ma solo chi conosce già la domanda vi scriverà la risposta.
L’accountability incorporata nel modello
Il meccanismo che regge per struttura, e che rende verificabile tutto il resto, è quello probatorio. Il modello fissa due definizioni: una misura è «implemented» solo quando opera nell’ambiente reale e vi è evidenza che il controllo funzioni come previsto (Explainer, par. 27); il rischio residuo è ciò che permane dopo aver valutato quanto le misure riducano effettivamente il rischio inerente (Explainer, par. 42). Letti insieme, i due passaggi implicano che una misura priva di evidenza non possa essere computata come implementata, ma resti parziale, e che il rischio residuo vada calcolato di conseguenza. Il modello converte così l’assenza di prova in rischio. Chi dichiara una lista bianca senza poterne dimostrare l’efficacia non ottiene un campo compilato, ottiene un rischio più alto. È accountability incorporata nel modello, ed è ciò che impedisce alla condizione taciuta di restare un’autodichiarazione.
I dati di terzi e il limite della giustificazione
E c’è un punto in cui il modulo semplicemente resiste. I dati di terzi che l’agente raccoglie frugando in archivi non strutturati non ammettono una giustificazione. Dichiararli nella sezione 1.1 obbliga, nella 2.2, a giustificarne necessità e pertinenza, e l’unica frase vera è che necessari non sono. Né soccorre la tentazione di coniare una finalità di «funzionamento dell’agente», questo perché l’impiego di un agente, avverte l’AEPD, non costituisce una finalità in sé. Il modulo, qui, si rifiuta di mettere a verbale un disegno illecito. Il rimedio sta a monte, nel filtraggio che impedisce a quei dati di entrare nel contesto, e nessuna riformulazione della sezione 1.1 può sostituirlo.
Ciò che nessuna DPIA può fare
Resta da dire che cosa il modello non possa fare: descrivere ex ante il comportamento emergente. L’AEPD chiama così le dinamiche imprevedibili proprie dei sistemi complessi, che non si possono anticipare né spiegare analizzando i singoli componenti: cicli di pianificazione che non terminano, traiettorie diverse a ogni esecuzione a parità di input, strategie che nessuno ha programmato. Non si tratta soltanto del fatto che l’agente fa cose inattese, il punto è che il comportamento non è spiegabile smontando il sistema.
Il template, per ragioni che appartengono alla struttura della valutazione del rischio, non ha una casella per fenomeni simili. La sezione 4.1 presuppone una deviazione da uno stato conforme, e qui nessuno ha deviato; la 3.1 chiede, per ogni minaccia, la fonte di rischio, e un comportamento emergente non ne ha una che si possa isolare.
La stessa fonte, però, toglie al rilievo la punta polemica, esplicitando come l’emergenza non è inerente all’IA agentica, ma risponde a implementazioni prive di un controllo adeguato del sistema, ottenibile con catene vincolate, limiti duri ai passi, cortocircuiti. Mantenere quel controllo è tanto più difficile quanto più il sistema è complesso, e ha un costo che cresce insieme a esso. La sezione 3.2, che esige evidenza del funzionamento del trattamento come previsto (Explainer, par. 33), è la sede in cui l’ingovernabilità viene alla luce. E un trattamento la cui efficacia non è dimostrabile non è da descrivere meglio, è da non approvare.
Le conseguenze, per chi compila e per la consultazione
Messo davanti a un trattamento agentico, il modello armonizzato risulta preparato in un modo che chiede al titolare più di quanto dichiari. Per chi dovrà usarlo, la conseguenza è invertire l’ordine dei lavori: catalogazione, liste bianche, compartimentazione, filtraggio, vincoli alla catena vengono prima del modello e ne condizionano la redazione. La DPIA di un trattamento agentico comincia nel disegno del trattamento, non nel documento.
Per la consultazione in corso ne discende una proposta, un Explainer che nomini le condizioni necessarie per la compilazione oggi taciute, indicando per ciascuna sezione quale decisione di progettazione la rende veritiera. Sarebbe coerente con la natura dello strumento, che i trattamenti non li descrive: pretende che siano descrivibili.
Partecipa alla community