Quando un’azienda mi chiede di integrare un chatbot sui dati dei clienti, un agente che legge le email o un sistema che analizza i CV, la prima domanda che faccio non è “quale modello usiamo?”, ma “abbiamo fatto la DPIA per l’intelligenza artificiale?”. La valutazione d’impatto sulla protezione dei dati (DPIA, art. 35 GDPR) è spesso vista come un adempimento burocratico da delegare al consulente privacy. In realtà, per i progetti AI è uno strumento di progettazione: ti costringe a capire quali dati entrano nel sistema, dove finiscono e cosa può andare storto, prima di scrivere una riga di codice.
In questo articolo spiego, da tecnico che costruisce automazioni e agenti AI, quando la DPIA è obbligatoria, come impostarla in modo pratico e quali misure tecniche la rendono credibile davanti a un Garante o a un cliente attento.
Quando serve una DPIA per l’intelligenza artificiale
Il GDPR richiede la DPIA quando un trattamento “può presentare un rischio elevato per i diritti e le libertà delle persone”. Le linee guida europee e l’elenco del Garante italiano indicano alcuni criteri: uso di tecnologie innovative, valutazione o profilazione, decisioni automatizzate con effetti significativi, trattamento su larga scala, dati particolari (salute, dati biometrici), monitoraggio sistematico. Se due o più criteri sono presenti, la DPIA è di norma necessaria.
Un sistema di intelligenza artificiale spunta quasi sempre la casella “tecnologia innovativa”. Basta aggiungerne un’altra per rientrare nel perimetro. Alcuni esempi tipici nelle PMI:
- un agente AI che smista le candidature e assegna un punteggio ai CV (valutazione + possibili effetti significativi);
- un assistente clienti che accede allo storico ordini e ai ticket (larga scala + tecnologia innovativa);
- un sistema che analizza le chiamate registrate per misurare la qualità degli operatori (monitoraggio sistematico dei dipendenti);
- un motore di scoring per il credito o per il rischio di insoluto (profilazione + decisioni con effetti economici).
Nel dubbio, il mio consiglio è semplice: falla. Una DPIA ben fatta per un progetto piccolo richiede poche giornate di lavoro e diventa documentazione riutilizzabile anche per gli obblighi dell’AI Act per le PMI, che chiede a sua volta gestione del rischio e trasparenza.
Le domande tecniche che una DPIA deve chiarire
La parte giuridica (base giuridica, informative, diritti degli interessati) è compito del DPO o del consulente privacy. Ma una DPIA su un progetto AI regge solo se la parte tecnica è descritta con precisione. Queste sono le domande a cui rispondo sempre insieme al cliente:
1. Quali dati entrano nel modello e da dove?
Prompt, documenti caricati, contesto recuperato da un database vettoriale, risposte degli strumenti chiamati dall’agente: tutto è trattamento di dati. Serve una mappa dei flussi, anche un semplice diagramma, che mostri le fonti e le categorie di dati coinvolte.
2. Dove vengono elaborati e conservati?
Un’API di un fornitore extra-UE comporta un trasferimento di dati con relative garanzie (clausole contrattuali standard, valutazione del trasferimento). Un modello ospitato in un datacenter europeo o un LLM self-hosted riduce questo rischio in modo drastico. Bisogna anche verificare se il fornitore conserva i prompt, per quanto tempo e se li usa per addestrare i propri modelli.
3. Il sistema prende decisioni o supporta le persone?
L’art. 22 GDPR limita le decisioni basate unicamente su trattamenti automatizzati. Progettare un flusso in cui l’AI propone e un operatore conferma cambia profondamente il profilo di rischio, ed è la stessa logica dell’approccio human-in-the-loop per gli agenti AI.
4. Cosa succede se il modello sbaglia o viene manipolato?
Allucinazioni, output discriminatori, fuga di dati attraverso le risposte, prompt injection: sono rischi concreti che vanno elencati, valutati per probabilità e gravità, e collegati a una misura di mitigazione.
Misure tecniche che rendono la DPIA credibile
Una DPIA che elenca rischi senza misure concrete è carta. Nei progetti che realizzo, queste sono le contromisure che uso più spesso e che si possono documentare con precisione:
- Minimizzazione a monte: l’agente riceve solo i campi che servono. Se deve rispondere sullo stato di una spedizione, non ha bisogno del codice fiscale del cliente.
- Pseudonimizzazione prima del modello: nomi, email e numeri di telefono vengono sostituiti da segnaposto prima dell’invio al LLM e reinseriti solo nella risposta finale. Esistono librerie open source per il riconoscimento delle entità che si integrano facilmente in una pipeline.
- Hosting in UE o self-hosted: per dati sensibili preferisco modelli ospitati su infrastruttura europea o su server del cliente, gestiti con Docker, così i dati non lasciano il perimetro aziendale.
- Controllo degli accessi e permessi degli strumenti: ogni tool dell’agente ha permessi minimi, credenziali separate e, per le azioni irreversibili, una richiesta di conferma.
- Log e tracciabilità: registro di chi ha chiesto cosa, quali dati sono stati recuperati e quale risposta è stata data, con tempi di conservazione definiti. Serve sia per gli audit sia per rispondere a una richiesta di accesso dell’interessato.
- Retention esplicita: conversazioni, embedding e file temporanei hanno una scadenza, e un job automatico li elimina davvero.
- Test prima del rilascio: casi di prova su dati fittizi per verificare che l’agente non riveli informazioni di altri clienti e resista ai tentativi di manipolazione.
Molte di queste misure coincidono con le buone pratiche già descritte nella guida su AI e GDPR in azienda: la DPIA è il documento che le mette in fila e dimostra che sono state applicate.
Un processo pratico in cinque passi
Per non trasformare la DPIA in un progetto infinito, lavoro con uno schema snello che si integra nello sviluppo:
- Descrizione del trattamento: scopo, utenti, dati, fornitori coinvolti, architettura in una pagina.
- Necessità e proporzionalità: perché serve l’AI e perché con quei dati; se si può ottenere lo stesso risultato con meno dati, si riprogetta.
- Registro dei rischi: una tabella con rischio, impatto sulle persone, probabilità, gravità.
- Misure e rischio residuo: per ogni rischio, la contromisura tecnica o organizzativa e la valutazione dopo la mitigazione.
- Revisione periodica: la DPIA va aggiornata quando cambia il modello, il fornitore o si aggiungono nuovi strumenti all’agente.
L’ultimo punto è quello che più spesso viene dimenticato. Nei progetti AI le cose cambiano in fretta: si passa a un modello più economico, si collega un nuovo database, si aggiunge un’automazione. Ogni modifica rilevante è un buon momento per riaprire il documento. Se l’azienda adotta anche un sistema di gestione come la ISO 42001, la DPIA si inserisce naturalmente nel ciclo di revisione.
Il valore per il business, non solo per la compliance
Una DPIA fatta bene non protegge soltanto da sanzioni. Nella mia esperienza porta tre vantaggi concreti: chiarisce l’architettura prima dello sviluppo (e quindi riduce i rifacimenti), accelera le trattative con clienti strutturati che chiedono garanzie scritte sulla gestione dei dati, e aumenta la fiducia interna, perché dipendenti e responsabili sanno cosa fa il sistema e con quali limiti.
È anche un antidoto alla shadow AI: quando esiste un percorso chiaro e documentato per adottare strumenti AI in sicurezza, le persone hanno meno motivi per usare servizi non autorizzati.
Progettiamo insieme un’AI conforme fin dall’inizio
Progetto e realizzo agenti AI, automazioni e integrazioni per aziende in Italia e in Europa, con un’attenzione particolare a privacy, sicurezza e hosting controllato. Posso affiancare il tuo DPO o consulente privacy fornendo la documentazione tecnica per la DPIA: flussi dei dati, architettura, misure di sicurezza e registro dei rischi.
Se stai valutando un progetto di intelligenza artificiale e vuoi partire con il piede giusto, contattami per una prima analisi. Trovi i miei progetti e servizi su cornelcaba.com.
