Privacy e AI: come dimostrare il controllo nel tempo

Indice

• Privacy e AI come problema di prove nel tempo
• Mappa dei sistemi di AI e dei dati personali che trattano
  • Come leggere le righe
• Ruoli, responsabilità e segregazione tra proposta e approvazione
  • Il flusso in quattro passaggi
• Basi giuridiche, minimizzazione e quando serve la DPIA
  • Scraping e modelli di terzi
  • Quando la DPIA precede il go-live
• GDPR e AI Act sullo stesso sistema
• Trasparenza e monitoraggio continuo dopo l'approvazione
• Errori comuni che indeboliscono l'audit
• Domande frequenti sui casi limite operativi
  • Un prompt contiene dati particolari. Cosa si registra?
  • Il fornitore tratta in un Paese terzo. Quale prova basta?
  • L'output assegna un turno o esclude una persona. È una decisione automatizzata?
  • Il sistema può essere usato da minori. Cosa precede il lancio?
  • Un incidente emerge tra due cicli trimestrali. Si aspetta il monitoraggio?
• Verificare la prova prima dell'audit

Privacy e AI come problema di prove nel tempo

Il tema privacy e AI si gioca su questa differenza. Una policy descrive l'intenzione. L'audit chiede se il controllo ha girato, chi lo ha eseguito e quale evidenza, datata, lo dimostra. Questo testo ha un focus operativo, non legale, e non sostituisce il parere di un consulente.

La catena che regge un audit è sempre la stessa: requisito o policy, controllo operativo, owner del controllo, evidenza datata e verificabile, audit trail immutabile, eccezione o non conformità, remediation. Se un anello non ha data e responsabile, la catena si interrompe lì.

Tre distinzioni evitano la confusione più comune.

• Policy e prova. Avere il documento approvato non dimostra che il controllo abbia funzionato nel periodo.
• Eccezione e non conformità. Un'eccezione è autorizzata, motivata e a scadenza. Una non conformità è uno scostamento non coperto da quella autorizzazione.
• Incidente. Un incidente di sicurezza o operativo è un evento a sé, con valutazione e, se ricorre, notifica. Non si registra come eccezione né si chiude come finding di audit.

Il 30 marzo 2023 il Garante per la protezione dei dati personali ha disposto, con effetto immediato, la limitazione provvisoria del trattamento dei dati degli utenti italiani da parte di OpenAI, gestore di ChatGPT, e ha chiesto le misure entro 20 giorni, con un quadro sanzionatorio richiamato fino a 20 milioni di euro o al 4% del fatturato globale annuo. Il provvedimento ha reso operativi inventario, basi giuridiche, richieste degli interessati e prove verificabili, anche verso un fornitore extra-UE.

Il software ordina le prove. La responsabilità del rischio resta alle persone che approvano finalità, mezzi e chiusura dei rimedi. Di seguito la mappa dei sistemi, i ruoli, le basi giuridiche, il raccordo con l'AI Act, il monitoraggio, gli errori che indeboliscono l'audit, i casi limite e la verifica prima della revisione.

Mappa dei sistemi di AI e dei dati personali che trattano

L'inventario parte dai sistemi e dai flussi, non dal nome commerciale. Lo stesso fornitore, usato per rispondere alle email o per valutare le persone, genera obblighi diversi. Se un reparto adopera uno strumento non registrato, il registro è incompleto e l'auditor lo rileva dal confronto con gli accessi reali.

Come leggere le righe

Il chatbot di terze parti chiede di sapere chi è titolare e chi è responsabile, dove finiscono prompt e log, e per quanto restano. Il contratto o il DPA, da solo, non basta se il registro dei trattamenti indica ancora una finalità diversa da quella in produzione.

L'addestramento su contenuti pubblici sposta il peso sulle fonti. Serve l'elenco dei siti o dei dataset, i filtri di esclusione e, se la raccolta è massiva, la DPIA. La prova è il file dei filtri con data, non una frase generica sulla minimizzazione.

Turni e valutazioni di lavoratori producono effetti sulle persone. Qui la prova minima è il test di discriminazione datato, il log della decisione e l'esito di chi ha contestato. Un modello "accurato" in laboratorio non sostituisce quella traccia.

Il supporto documentale interno sembra basso rischio perché i file sono già in azienda. Il punto è chi può interrogarli, quali cartelle sono escluse e se i log mostrano accessi fuori perimetro.

L'uso sperimentale su dati reali è un trattamento, non una sandbox neutra. Senza approvazione del titolare, data di cancellazione e verbale di chiusura, la copia di produzione resta un trattamento non governato.

Nel gennaio 2025 il Garante ha disposto il blocco immediato del trattamento dei dati degli utenti italiani da parte dei fornitori cinesi di DeepSeek, dopo risposte ritenute insufficienti su dati raccolti, finalità, conservazione e trasferimento verso la Cina. La prova attesa copre il ciclo di vita: cosa inseriscono gli utenti, se serve all'addestramento, per quanto, chi accede e in quale Paese.

Regola pratica: uno strumento IA usato da un reparto e assente dal registro rende incompleto l'inventario, indipendentemente dalla qualità del modello.

Ruoli, responsabilità e segregazione tra proposta e approvazione

Il titolare del trattamento è la persona giuridica che decide finalità e mezzi e risponde dell'accountability ai sensi dell'articolo 5 del GDPR. Il DPO dà parere e sorveglia. Non approva al posto del titolare. L'owner del sistema propone il perimetro e presidia il controllo. Il fornitore è responsabile o titolare autonomo secondo il contratto, non secondo la slide commerciale. L'internal auditor, o l'OdV nel perimetro del D.Lgs. 231/2001, verifica senza eseguire il controllo che sta esaminando.

Il flusso in quattro passaggi

1. Proposta. L'owner presenta la scheda di sistema: finalità, dati, fornitore, popolazione di interessati, uso sperimentale o produttivo. Evidenza: scheda versionata, data, nome di chi propone.
2. Valutazione. Il DPO rilascia il parere. Se il rischio è elevato, la DPIA è parte del fascicolo, non un allegato successivo. Evidenza: parere datato e, se serve, DPIA con versione.
3. Approvazione. Firma chi ha i poteri per impegnare il titolare. Evidenza: approvazione con firma, data e versione del documento approvato. Una mail "ok procedete" senza versione non chiude il passaggio.
4. Esecuzione e verifica. Chi lancia il sistema e raccoglie i log non è la stessa persona che chiude un finding su quel sistema. Evidenza: report di test firmato da un revisore diverso dall'esecutore.

Chi propone non approva. Chi esegue il test non dichiara chiuso il rimedio. Questa segregazione è il motivo per cui un unico referente "che fa tutto" produce fascicoli fragili: l'auditor non trova un controllo indipendente, trova un'autodichiarazione.

L'organizzazione di compliance tiene registri, scadenze e prove. Il consulente legale interpreta la norma e, se richiesto, firma un parere. Confondere i due ruoli fa firmare al DPO decisioni che spettano al titolare, oppure fa trattare un parere legale come se fosse il log del controllo. La piattaforma può conservare firme e versioni. Non assume la decisione. Per il disegno dei ruoli tra DPO e process owner, il riferimento operativo è la governance privacy tra DPO e process owner.

Basi giuridiche, minimizzazione e quando serve la DPIA

Un dato visibile online non è una base giuridica. La pubblicazione non equivale a consenso, né rende compatibile uno scopo ulteriore come l'addestramento di un modello.

Per i dati comuni la base si individua nell'articolo 6 del GDPR e si scrive nel registro: contratto, obbligo legale, interesse pubblico, legittimo interesse o consenso. Il legittimo interesse resta utilizzabile solo con il test di bilanciamento conservato, non con una casella spuntata. Per i dati particolari serve una condizione dell'articolo 9, oltre alla base dell'articolo 6. Senza quella condizione il trattamento non parte, anche se il modello "migliora" con quei campi.

Scraping e modelli di terzi

Il Garante considera una criticità lo scraping indiscriminato di dati personali, da soggetti pubblici o privati, per addestrare modelli generativi. Il rischio operativo è la trasformazione di contenuti accessibili in dataset riusati per finalità ulteriori. Chi sviluppa o acquista il sistema tiene l'inventario delle fonti, documenta finalità e base, applica minimizzazione e, ove possibile, pseudonimizzazione, e conserva filtri, esclusioni e controlli di qualità.

Lo stesso vale se il modello è di un terzo. Il titolare verifica in contratto provenienza, responsabilità, conservazione, addestramento ulteriore e procedure di cancellazione o opposizione. Uso sperimentale e uso produttivo restano due righe distinte, con basi e scadenze proprie. I gestori di siti italiani, dal lato opposto, applicano limitazione della finalità, minimizzazione e integrità quando espongono contenuti che altri possono raccogliere.

Quando la DPIA precede il go-live

La DPIA serve prima dell'avvio quando il rischio è elevato: raccolta massiva, profilazione, dati particolari, valutazione di persone, tecnologie nuove nel contesto dell'organizzazione. Un documento redatto dopo il lancio non ricostruisce la decisione. La ricostruisce solo se esisteva, con data anteriore, parere e versione.

Campi minimi di ogni scheda di sistema, così il registro regge un audit:

• ID, sistema e perimetro, con owner nominativo.
• Finalità e base giuridica, categorie di interessati, fornitore e ruolo contrattuale.
• Periodo di conservazione, controlli compensativi, rischio residuo descritto in parole, non con un punteggio automatico.
• Data di riesame ed evidenza di chiusura del riesame precedente.

La DPIA misura l'impatto sui diritti prima che il trattamento esista. Non è un allegato da produrre quando arriva la richiesta dell'autorità.

GDPR e AI Act sullo stesso sistema

Il GDPR resta la disciplina dei dati personali. L'AI Act aggiunge obblighi sul sistema secondo la classe di rischio. Non sostituisce base giuridica, informativa o diritti degli interessati. Tenerli nello stesso fascicolo senza distinguerli produce un documento che non soddisfa né l'auditor privacy né chi verifica il sistema.

Il raccordo pratico sta in cinque mosse.

Classificare l'uso, non il marchio. Pratica vietata, alto rischio, obbligo di trasparenza o rischio minimo. La classe si annota accanto al trattamento, nello stesso registro, con la data della classificazione.

Due fascicoli, un ID. Per un sistema ad alto rischio che tratta dati personali, la valutazione di conformità e la documentazione tecnica dell'AI Act stanno da una parte. DPIA, base giuridica e registro dei trattamenti stanno dall'altra. Lo stesso identificativo li collega. Nessuno dei due fascicoli cita l'altro solo "a parola".

Non scambiare le valutazioni. La DPIA guarda l'impatto sui diritti. La valutazione di conformità guarda i requisiti del sistema. Usarne una al posto dell'altra lascia un buco che l'auditor vede al primo confronto tra indici.

Owner distinti. Il titolare approva il trattamento. Il fornitore o il deployer documenta il ruolo previsto dall'AI Act. Il DPO dà parere sulla DPIA. L'auditor controlla le evidenze e non le produce.

Campi del raccordo: ID sistema, classe di rischio, ruolo deployer o provider, versione del modello, DPIA collegata, controlli umani, log, data di riesame.

Un chatbot di terze parti e un sistema di turni non condividono classe né prova. Il primo può ricadere su obblighi di trasparenza verso l'utente. Il secondo può incidere su persone in un contesto di lavoro e chiedere verifica umana, contestazione e test. Il modulo di governance tiene i due fascicoli e l'audit trail. Non classifica il rischio al posto dell'organizzazione. Il perimetro funzionale è descritto nella gestione del framework EU AI Act.

Trasparenza e monitoraggio continuo dopo l'approvazione

L'approvazione fotografa il sistema in un giorno. Il giorno dopo il fornitore pubblica una versione, cambia una fonte o un reparto incolla nel prompt dati che la scheda escludeva. Il rischio si sposta. La policy approvata no, finché qualcuno non riesamina.

La trasparenza verso gli interessati segue gli articoli 13 e 14 del GDPR: informativa adeguata e, quando il sistema incide sulle persone, indicazione della logica e possibilità di intervento umano. Sul sistema si registrano versione del modello, fonti o dataset, parametri rilevanti per l'uso, utenti autorizzati, output contestati e correzioni umane. Accesso, rettifica e opposizione si collegano al ticket di risposta, non a una casella "gestito".

Il Garante richiama, anche nell'evoluzione dell'AI Act, trasparenza, base giuridica, controllo degli algoritmi e correzione degli errori lungo tutta la catena, dall'input alla conservazione dei prompt, dall'inferenza agli incidenti. In pratica: ambienti separati, accessi controllati, log degli eventi critici, test di accuratezza e bias, soglie di escalation umana, riesame della necessità del trattamento.

Le frequenze sono un ciclo interno da fissare per iscritto, non un termine di legge. La notifica di un incidente segue il suo termine e non aspetta il ciclo trimestrale. Il monitoraggio continuo dei controlli si appoggia a un ciclo di continuous controls monitoring, con owner e scadenza su ogni evidenza.

Errori comuni che indeboliscono l'audit

Quello che indebolisce un audit è quasi sempre un atto datato male, o un atto che non esiste. La prova datata è l'unità di controllo: ogni errore sotto leva data, versione o verificatore a una prova.

Approvazioni retroattive. La firma porta una data successiva al go-live. Per l'auditor quel controllo risulta assente nel periodo di riferimento, qualunque sia la ragione del ritardo. La correzione è bloccare il lancio finché firma, versione e data sono anteriori all'uso.

Eccezioni senza fine. Una deroga di trenta giorni rinnovata a ogni scadenza diventa, di fatto, una non conformità non dichiarata. Si corregge con un limite di rinnovi e con la conversione automatica in finding alla terza proroga, o alla data che il regolamento interno fissa.

Prove sparse. Email, chat e cartelle personali non ricostruiscono la sequenza. Si corregge spostando nello stesso archivio solo ciò che ha timestamp, sistema e versione. Uno screenshot senza orario e senza ID di sistema non è evidenza.

Chiusure non verificate. Il finding risulta chiuso perché l'owner ha scritto "fatto". Manca il controllo di una persona che non ha eseguito il rimedio. La correzione è un'evidenza di chiusura firmata da chi verifica, distinta da chi rimedia.

Uso non censito. Un assistente attivato da un team e assente dall'inventario fa fallire il campione. La correzione è un censimento periodico degli accessi agli strumenti, confrontato con il registro.

DPIA tardiva. Una DPIA scritta dopo il lancio, o che non copre le popolazioni vulnerabili e la fase di pre-addestramento dove quel rischio esiste, è una debolezza che l'auditor rileva. La correzione è datare la DPIA prima del go-live, riesaminarla a ogni cambio di modello o di popolazione e conservare parere del DPO, versione ed esito.

Sul lavoro, il provvedimento su Deliveroo Italia ha riguardato un sistema di assegnazione turni per circa 8.000 rider e una sanzione di 2,5 milioni di euro. Incidevano trasparenza, correttezza, qualità dei dati, comprensione della logica e possibilità di contestare. Nel registro HR vanno sistema, finalità, interessati, dati, ruolo del fornitore, conseguenze dell'output, test sulla discriminazione, verifica umana e procedura di contestazione.

Eccezione, non conformità e incidente hanno registri e scadenze distinti. Mischiarli fa sembrare risolto ciò che è solo rinviato.

Domande frequenti sui casi limite operativi

Un prompt contiene dati particolari. Cosa si registra?

Si blocca l'invio al fornitore. Sul ticket si annotano categoria, condizione dell'articolo 9 se un trattamento resta necessario, e la decisione di cancellazione o pseudonimizzazione, con owner e data. Senza quella riga il prompt è un trattamento non tracciato.

Il fornitore tratta in un Paese terzo. Quale prova basta?

Non basta il Paese scritto in brochure. Servono strumento di trasferimento, chi accede, dove sono conservati i dati e per quanto. È lo stesso ordine di domande rimasto senza risposta sufficiente nel caso del chatbot cinese all'inizio del 2025.

L'output assegna un turno o esclude una persona. È una decisione automatizzata?

Si distingue una raccomandazione, con verifica umana documentata prima dell'effetto, da una decisione che produce l'effetto senza intervento. In entrambi i casi si conservano logica, contestazione ed esito. Manca uno dei tre, e il fascicolo HR non regge.

Il sistema può essere usato da minori. Cosa precede il lancio?

La DPIA precede l'uso e copre la popolazione, il pre-addestramento e le misure di esclusione. L'informativa, da sola, non chiude quel perimetro.

Un incidente emerge tra due cicli trimestrali. Si aspetta il monitoraggio?

No. La valutazione di notifica parte subito e segue il termine proprio dell'incidente. Il ciclo trimestrale registra il riesame successivo, non sostituisce la decisione del CISO. In tutti e cinque i casi restano ID, owner, scadenza ed evidenza di chiusura.

Verificare la prova prima dell'audit

Prima della revisione si percorrono sei controlli, in ordine. Saltarne uno a metà rende inutile il successivo.

1. Inventario. Ogni sistema di AI che tratta dati personali ha owner e perimetro. Un accesso attivo senza scheda è un buco, non un'eccezione.
2. Approvazioni. Firma, data e versione sono anteriori all'uso. Nessuna retrodatazione.
3. DPIA. Se è richiesta, precede il trattamento ed è riesaminata a variazioni di modello, fonti o interessati.
4. Registri distinti. Ogni eccezione ha motivazione, scadenza e rimedio. Non conformità e incidente stanno altrove, con la loro scadenza.
5. Archivio unico. Le evidenze hanno timestamp e versione. Non vivono in email o chat. Per ciascuna si tengono periodo di conservazione, scadenza ed eventuale legal hold.
6. Chiusura verificata. Ogni finding chiuso, da audit, incidente, test, privacy o inserimento manuale, ha severità, responsabile, intervento ed evidenza di chiusura controllata da chi non ha eseguito il rimedio.

Il passo successivo è riunire inventario, basi giuridiche, DPIA, log di monitoraggio e chiusure in un pacchetto e farlo leggere da un revisore interno, prima che lo legga un esterno.

AuditReady può centralizzare quelle evidenze con tracciabilità delle operazioni critiche, richieste ai fornitori tramite link pubblici con token dedicato e scadenza configurabile, finding con severità e responsabile, remediation ed export dell'Audit Day Pack. Non valuta la conformità giuridica, non dà pareri legali e non assegna un punteggio di rischio. Non promette governance automatica né responsabilità delegate al software.

Se il controllo sul chatbot esiste solo come policy, il passo utile è mettere owner, data e evidenza nello stesso fascicolo. AuditReady riunisce registri privacy, sistemi di AI, finding e remediation in un unico ambiente, con responsabilità e scadenze leggibili senza ricostruire le email. Puoi vedere come funziona su AuditReady.