DPIA per agenti AI: memoria, tool calling e autonomia

Fonti primarie: Art. 35 GDPR · Elenco DPIA del Garante Privacy · Provvedimento Character.AI del 3 luglio 2026 · Artt. 26 e 27 AI Act

La domanda corretta non è «questo software viene chiamato agente?», ma «quali trattamenti di dati personali compie il sistema reale e quali conseguenze può produrre?». Un agente può leggere email, interrogare un CRM, conservare memoria, scegliere un tool, trasmettere informazioni a un'API e modificare record. Ciascun passaggio può cambiare finalità, destinatari, tempi di conservazione e livello di rischio.

Quando scatta l'obbligo di DPIA per un agente AI?

L'Art. 35 GDPR richiede una valutazione d'impatto quando un trattamento, in particolare se utilizza nuove tecnologie, è suscettibile di presentare un rischio elevato considerando natura, ambito, contesto e finalità. Non esiste quindi una regola europea secondo cui ogni agente AI richiede sempre una DPIA.

In Italia, l'elenco adottato dal Garante ai sensi dell'Art. 35, par. 4, comprende i trattamenti effettuati mediante tecnologie innovative — inclusi i sistemi di intelligenza artificiale — quando ricorre almeno un altro criterio indicato nelle linee guida europee. Tra i criteri da verificare rientrano:

• valutazione o scoring delle persone;
• decisioni automatizzate con effetti giuridici o analogamente significativi;
• monitoraggio sistematico;
• dati particolari o altamente personali;
• trattamento su larga scala;
• persone vulnerabili, inclusi minori e lavoratori;
• confronto o combinazione di dataset;
• uso innovativo della tecnologia;
• trattamenti che impediscono di esercitare un diritto o accedere a un servizio.

Il provvedimento del Garante su Character.AI del 3 luglio 2026 mostra l'importanza di una valutazione tempestiva nei servizi di AI generativa che coinvolgono grandi volumi di dati e utenti vulnerabili. È un precedente utile, ma non trasforma ogni uso di AI generativa in un obbligo automatico: il caso concreto resta determinante.

Perché la DPIA deve seguire il workflow e non il solo modello

Un singolo modello può essere impiegato in sistemi con rischi molto diversi. Un assistente che riassume documenti già selezionati da un operatore non equivale a un agente che esplora autonomamente archivi, interroga servizi esterni e invia comunicazioni ai clienti.

La mappatura dovrebbe distinguere almeno questi componenti:

Questa scomposizione è una metodologia operativa, non una checklist normativa autonoma. Serve a soddisfare gli elementi richiesti dall'Art. 35, par. 7: descrizione sistematica, necessità e proporzionalità, rischi e misure previste.

Checklist DPIA per agenti AI in 8 passaggi

1. Definire il caso d'uso reale

Descrivere ciò che l'agente fa in produzione, non soltanto la finalità commerciale. Occorre chiarire quali persone sono coinvolte, quali risultati vengono prodotti e se l'output può incidere su lavoro, credito, accesso a servizi, prezzi, assistenza sanitaria o altri interessi rilevanti.

2. Seguire i dati in ogni stato

Per ogni fase, indicare categorie di dati, fonte, finalità, base giuridica, destinatari e retention. La memoria merita una voce autonoma: una conversazione destinata a durare pochi minuti non dovrebbe diventare, senza una giustificazione documentata, un profilo permanente dell'utente.

3. Ricostruire la catena dei fornitori

Il modello è spesso solo uno dei fornitori. Possono intervenire orchestratore, motore di ricerca, database vettoriale, sistema di tracing, provider cloud e servizi chiamati tramite tool. La DPIA deve permettere di capire chi tratta quali dati, in quale ruolo e in quale paese. La qualificazione come titolare, responsabile o altro soggetto dipende dal controllo effettivo su finalità e mezzi essenziali, non dall'etichetta contrattuale.

4. Valutare necessità e proporzionalità

Chiedere se l'agente abbia bisogno di accedere a tutti i record, di conservare l'intera conversazione o di utilizzare tool con permessi di scrittura. Se lo stesso risultato può essere ottenuto con un dataset ridotto, una memoria più breve o un'azione proposta ma non eseguita automaticamente, la scelta più invasiva richiede una giustificazione specifica.

5. Collegare rischi e conseguenze per le persone

La DPIA non è soltanto un penetration test. Deve descrivere le conseguenze possibili per gli interessati: divulgazione di informazioni, discriminazione, perdita di opportunità, decisioni errate, impossibilità di esercitare diritti, manipolazione, danno reputazionale o uso secondario inatteso dei dati.

6. Applicare il principio del minimo privilegio

OWASP definisce “excessive agency” la situazione in cui funzionalità, permessi o autonomia eccessivi consentono azioni dannose in risposta a output inattesi o manipolati. È una fonte tecnica, non una norma giuridica, ma offre indicazioni coerenti con la riduzione del rischio: limitare i tool disponibili, separare lettura e scrittura, restringere gli scope dei token e richiedere conferma per le azioni ad alto impatto. OWASP — Excessive Agency

7. Rendere verificabile il controllo umano

“Human in the loop” non è sufficiente se l'operatore approva sistematicamente senza comprendere contesto e limiti. La DPIA dovrebbe indicare quali azioni richiedono approvazione, quali informazioni riceve il revisore, come può correggere l'output e come viene impedita l'esecuzione quando il controllo non è disponibile.

8. Riesaminare quando cambia il rischio

L'Art. 35, par. 11, richiede il riesame almeno quando cambia il rischio rappresentato dalle operazioni di trattamento. Per un agente AI, possono essere trigger rilevanti:

• nuovo modello o nuova versione con comportamento differente;
• aggiunta di memoria persistente;
• nuovo tool o ampliamento dei permessi;
• nuove categorie di dati o persone;
• passaggio da supporto informativo ad azione automatica;
• modifica di provider, paese o retention;
• incidente, prompt injection riuscita o anomalia significativa;
• data drift o aumento del tasso di errore su gruppi specifici.

Rischi tipici e misure da valutare

Il NIST AI Risk Management Framework può sostenere la gestione tecnica attraverso le funzioni Govern, Map, Measure e Manage. È un framework volontario e non sostituisce l'analisi richiesta dal GDPR.

Come si coordinano GDPR e AI Act?

La classificazione di un sistema come “ad alto rischio” ai sensi dell'AI Act non rende automaticamente obbligatoria la DPIA in ogni caso. L'Art. 26, par. 9, stabilisce che, quando l'obbligo di DPIA è applicabile, il deployer utilizzi le informazioni fornite ai sensi dell'Art. 13 AI Act per adempiervi.

La FRIA dell'Art. 27 AI Act è una valutazione distinta, prevista per specifici deployer e casi d'uso. Può condividere dati e governance con la DPIA, ma non va descritta come una semplice “DPIA ampliata”. Per il confronto operativo si veda la guida su DPIA e FRIA per sistemi AI.

Quando entra in gioco l'Art. 22 GDPR?

Occorre una verifica specifica quando l'agente adotta o determina, senza un intervento umano sostanziale, una decisione che produce effetti giuridici o incide in modo analogo significativamente sulla persona. L'etichetta “raccomandazione” non è decisiva: conta il modo in cui l'output viene effettivamente utilizzato.

Nella DPIA vanno quindi descritti il peso dell'output, la possibilità concreta di discostarsene, la competenza del revisore e le modalità con cui l'interessato può ottenere informazioni, contestare il risultato o richiedere l'intervento umano nei casi applicabili.

Quali documenti raccogliere dal provider?

Il set dipende dal servizio e dal ruolo contrattuale, ma può comprendere:

• descrizione del servizio e delle finalità del trattamento;
• categorie di dati ammesse e vietate;
• politica su training e uso secondario degli input;
• retention di prompt, output, memoria e log;
• elenco di sub-responsabili e localizzazione;
• misure di sicurezza e gestione degli incidenti;
• istruzioni d'uso, limiti, metriche e condizioni di supervisione;
• procedure per accesso, cancellazione ed esportazione;
• configurazioni enterprise rilevanti e responsabilità del cliente.

Per i sistemi ad alto rischio, le informazioni fornite ai sensi dell'Art. 13 AI Act assumono rilievo anche per il coordinamento previsto dall'Art. 26, par. 9. Non ne deriva necessariamente il diritto del deployer a ricevere l'intera documentazione tecnica interna del provider prevista dall'Art. 11.

Domande frequenti

Ogni agente AI richiede una DPIA?

No. È necessaria quando il trattamento di dati personali è suscettibile di presentare un rischio elevato. L'autonomia, la memoria e i tool sono fattori da valutare perché possono ampliare dati, destinatari, conseguenze e superficie di attacco.

La memoria persistente fa scattare automaticamente la DPIA?

No, ma può aumentare il rischio e deve essere documentata. Sono rilevanti contenuto, durata, separazione tra utenti, riuso per ulteriori finalità e possibilità effettiva di cancellazione.

Un agente con soli permessi di lettura è a basso rischio?

Non necessariamente. Il read-only limita alcune conseguenze, ma l'agente potrebbe comunque accedere, combinare o comunicare dati personali in modo esteso. Vanno valutati scope, fonti, output, destinatari e scala.

Tool calling e browser vanno inseriti nella DPIA?

Sì, quando partecipano al trattamento. Per ciascun tool occorre indicare dati accessibili, operazioni consentite, destinatari, autorizzazioni, log e controlli.

DPIA e penetration test sono equivalenti?

No. Il test tecnico può fornire evidenze sulle vulnerabilità, mentre la DPIA valuta anche necessità, proporzionalità e conseguenze per diritti e libertà. I due strumenti possono integrarsi ma hanno finalità diverse.

Quando bisogna consultare preventivamente il Garante?

Quando la DPIA indica che, in assenza di misure sufficienti, il trattamento presenterebbe ancora un rischio elevato. L'uso di un agente AI non determina, da solo, la consultazione preventiva.

Articolo aggiornato al 1° agosto 2026. Le indicazioni sono generali e richiedono adattamento a finalità, dati, ruoli, scala e architettura del singolo trattamento.