Privacy e intelligenza artificiale: controlli e prove

La domanda non è se l'organizzazione ha una posizione sull'uso dell'IA. La domanda è quale versione del modello girava in una certa data, chi ha approvato quel caso d'uso e dove è conservata la prova che i controlli descritti siano stati eseguiti davvero. Privacy e intelligenza artificiale, viste da chi deve dimostrare un controllo, sono la stessa disciplina: una sequenza di decisioni datate.

Questo articolo ha un taglio operativo, non legale. Non spiega come interpretare il GDPR davanti a un'autorità, ma come organizzare controlli e prove che un revisore interno, un DPO o un Organismo di Vigilanza possano verificare senza doversi fidare di una dichiarazione.

Indice

• Perché la prova conta più della policy nei progetti IA
• Rischi per gli interessati lungo il ciclo di vita dell'IA
  • Le tre fasi che producono più esposizione
• Ruoli e basi giuridiche nella privacy e intelligenza artificiale
  • Il coordinamento tra GDPR e AI Act produce obblighi, non principi
  • La base giuridica si sceglie per finalità
  • Segregazione dei compiti
• Quando serve la DPIA e come documentarla
  • Come si costruisce la DPIA in otto passaggi
  • Interessati senza account e richieste di accesso
• Dati dei dipendenti nei chatbot IA aziendali
  • Dalla classificazione dei prompt ai controlli periodici
• Output generati e dati personali di terzi
  • Quattro verifiche prima di pubblicare un output
• Registro degli usi IA ed evidenze da mostrare
  • I campi minimi del registro
• Errori comuni e verifica prima dell'audit
  • Gli errori che aprono un finding
  • Sei domande da porre a un caso d'uso reale

Perché la prova conta più della policy nei progetti IA

L'auditor non contesta la policy. Chiede chi ha eseguito il controllo descritto nel paragrafo quattro, in quale data, e dove è archiviata la prova. Chiede come è stata gestita la non conformità aperta sei mesi fa e chi ne ha verificato la chiusura. Se il registro non risponde, la discussione finisce lì.

Il quadro non è teorico. Nel 2024 il Garante per la protezione dei dati personali ha chiuso l'istruttoria su ChatGPT imponendo a OpenAI una sanzione di 15 milioni di euro e l'obbligo di realizzare una campagna informativa sul trattamento dei dati. Trasparenza, base giuridica, correttezza del trattamento e tutela dei diritti degli interessati sono diventati requisiti applicati a un sistema di IA usato su larga scala, e quindi verificabili con documenti.

Da qui deriva la catena che regge o fa cadere ogni verifica: requisito o policy, controllo operativo, control owner con nome e cognome, evidenza datata e verificabile, audit trail, gestione del finding, remediation con chiusura verificata. Se un anello manca, il controllo esiste solo sulla carta. La catena vale per ogni trattamento che l'IA tocca, dai prompt scritti dai dipendenti agli output che riportano dati di terzi: ogni anello deve indicare chi presidia quel passaggio e cosa lo dimostra.

Regola di lettura: un controllo senza owner, data e prova allegata non è un controllo eseguito. È un'intenzione documentata.

Quattro distinzioni evitano la maggior parte delle discussioni inutili durante una revisione:

• Policy contro esecuzione. Avere scritto che i prompt vanno classificati non dimostra che qualcuno li abbia classificati. La prova è il registro compilato, non il paragrafo.
• Eccezione contro non conformità contro incidente. Un'eccezione autorizzata, motivata e con scadenza è una scelta governata. Una non conformità è uno scostamento dal requisito. Un incidente è un evento che ha prodotto un impatto. Confonderli rende il registro inutilizzabile.
• Software contro responsabilità. Uno strumento registra, versiona e collega. Non decide, non approva e non si assume il rischio al posto di chi firma.
• Compliance operativa contro parere legale. L'organizzazione dimostra che il controllo ha funzionato. Il consulente legale interpreta la norma. Le due cose si incontrano, ma non si sostituiscono.

L'adozione corre più veloce della documentazione in ogni settore. Nel commercio al dettaglio gli strumenti entrano nei processi di vendita e assistenza prima che i controlli siano formalizzati: si può scopri l'AI nel retail milanese per vedere il divario in un contesto reale. La differenza tra una verifica superata e una contestazione sta quasi sempre in un registro tenuto con continuità, non nell'ultima versione della policy.

Rischi per gli interessati lungo il ciclo di vita dell'IA

Il rischio per le persone cambia natura mentre il sistema avanza. Trattarlo come una voce unica nel registro rischi produce controlli generici e prove inutili. La tabella va letta riga per riga, perché ogni fase richiede un controllo diverso e un'evidenza diversa.

Raccolta e addestramento è la fase che condiziona tutte le altre. Se il modello è stato addestrato su dati acquistati, raccolti dal web o forniti da terzi, la scheda delle fonti deve dire da dove arrivano, su quale base giuridica e con quale informativa. Senza quel documento, ogni valutazione successiva poggia su un presupposto che nessuno può verificare.

Le tre fasi che producono più esposizione

Input e prompt genera più incidenti reali di qualsiasi attacco. Un dipendente che incolla una cartella clinica per farsi spiegare un referto non sta violando una procedura per negligenza: sta usando lo strumento che l'azienda gli ha messo a disposizione senza una regola chiara su cosa può contenere.

Output e generazione sposta il problema su persone che non hanno mai interagito con il sistema. Un video sintetico, una voce clonata, un'immagine costruita da un prompt: l'interessato è terzo rispetto al trattamento e spesso non sa che esiste.

La modifica di modello o dataset, infine, è il punto in cui la maggior parte delle organizzazioni perde la tracciabilità. Cambiare fornitore o passare a una versione nuova del modello riattiva il rischio, ma raramente riattiva la valutazione, perché nessuno collega la release alla DPIA.

Il Garante chiede che la protezione dati entri nella progettazione, con classificazione del rischio, accesso alla documentazione tecnica e ai dati di addestramento, audit algoritmici e team interdisciplinari, oltre a test registrati di accuratezza, bias, affidabilità e gestione degli errori. Sull'articolo 22 GDPR la posizione è netta: una decisione esclusivamente automatizzata con effetti giuridici o significativamente analoghi non è semplice automazione operativa e richiede garanzie, supervisione e possibilità effettiva di contestazione.

Chi deve costruire la matrice completa per caso d'uso trova un riferimento operativo in questa analisi dei rischi dell'intelligenza artificiale, utile per passare dalla fase al controllo senza reinventare la struttura ogni volta.

Ogni fase senza owner, data e prova è una fase non controllata, anche quando la policy la descrive in dettaglio.

Ruoli e basi giuridiche nella privacy e intelligenza artificiale

La domanda che blocca più progetti non è tecnica. È chi risponde di cosa. Un fornitore che dichiara di trattare i dati "secondo il GDPR" non ha detto nulla su subfornitori, trasferimenti extra UE e stabilimento principale nell'Unione.

Il responsabile ai sensi dell'articolo 28 GDPR merita una riga a parte nel fascicolo, perché tratta dati solo entro un contratto e istruzioni documentate. Se le istruzioni non esistono o sono un allegato generico scaricato dal sito del fornitore, la catena delle responsabilità si interrompe nel punto in cui servirebbe.

Il coordinamento tra GDPR e AI Act produce obblighi, non principi

Il Garante ha ricordato che l'AI Act si fonda sull'articolo 16 del Trattato sul funzionamento dell'Unione europea, la stessa base giuridica della normativa sui dati personali, e prevede il coinvolgimento delle autorità di protezione dati nei processi algoritmici che trattano dati personali. Per chi gestisce controlli questo si traduce in quattro obblighi operativi, ognuno con la sua prova: classificazione del rischio, documentazione tecnica, controllo umano, monitoraggio post-utilizzo.

La conseguenza pratica è che l'adozione non si esaurisce nel verificare se esiste una base giuridica per raccogliere i dati. Bisogna poter dimostrare come il sistema è stato selezionato, valutato, configurato e sorvegliato.

La base giuridica si sceglie per finalità

Articolo 6 GDPR per i dati comuni, articolo 9 per le categorie particolari. Nel rapporto di lavoro il consenso è una base fragile, perché la disparità tra le parti rende difficile sostenerne la libera prestazione: va valutata caso per caso e quasi mai è la scelta più solida. Chi vuole verificare come si documenta questa scelta trova un utile approfondimento sul principio di liceità, da leggere prima di firmare la delibera e non dopo.

Segregazione dei compiti

Chi propone un uso IA non può essere l'unico ad approvarlo e l'unico a verificarne l'esecuzione. La sequenza difendibile è: proposta documentata dal business owner, approvazione del titolare con parere del DPO, esecuzione del control owner, verifica indipendente da audit interno o OdV. Il software registra le decisioni e le rende ricostruibili, ma non le assume.

Quando serve la DPIA e come documentarla

Il criterio è uno: la DPIA serve quando il trattamento presenta un rischio elevato per i diritti e le libertà delle persone, come prevede l'articolo 35 GDPR. Il criterio però non dice quando il rischio è elevato, e qui i team sbagliano, perché rimandano la valutazione al momento in cui il sistema è già in produzione.

Il Garante ha sanzionato Character Technologies Inc., gestore di Character.AI, con 158.000 euro, per un servizio conversazionale accessibile anche a minorenni. Il caso è istruttivo perché non riguarda un uso aziendale interno: riguarda un prodotto aperto al pubblico, dove verifica dell'età, trasparenza sulle fonti, conservazione delle conversazioni e protezione dei dati dei minori andavano risolte prima del rilascio.

Come si costruisce la DPIA in otto passaggi

1. Descrivi il caso d'uso con finalità, sistema, fornitore e versione del modello. Senza la versione, la valutazione non è riconducibile a ciò che gira davvero.
2. Mappa le categorie di interessati, compresi dipendenti, candidati, clienti e terzi che non hanno un rapporto diretto con il servizio.
3. Elenca dati e fonti, incluse le informazioni acquisite da fonti esterne o presenti nei documenti caricati nel sistema.
4. Valuta necessità e proporzionalità, applicando minimizzazione e retention limitata invece di dichiararle.
5. Individua i rischi per diritti e libertà e le misure di mitigazione corrispondenti, con riferimento esplicito al rischio che ciascuna misura riduce.
6. Registra i test su accuratezza, bias, resilienza, filtri e meccanismi di escalation umana, con data e autore.
7. Raccogli approvazione del titolare e parere del DPO in forma scritta e datata, allegati alla valutazione.
8. Riesamina quando cambia qualcosa, cioè al cambio di modello, dataset, fornitore o finalità. La versione nuova non eredita la valutazione della precedente.

Per i dati sanitari, finanziari o identificativi nei prompt servono regole di esclusione esplicite, pseudonimizzazione dove possibile e retention definita. Ogni eccezione o incidente va poi collegato a sistema, fornitore, versione del modello, utenti coinvolti, tempi di notifica e piano correttivo.

Interessati senza account e richieste di accesso

C'è un passaggio che quasi nessuno inserisce nella DPIA: le persone i cui dati entrano nel sistema senza aver mai creato un account. Nel caso ChatGPT il Garante ha richiesto un'informativa rivolta anche ai non utenti e uno strumento che consentisse agli interessati collegati dall'Italia di opporsi al trattamento dei dati ottenuti da terzi, come ricostruito nel provvedimento sul diritto di opposizione.

La stessa logica vale dove i dati arrivano da chi non ha accettato condizioni d'uso: gestire i dati degli ospiti richiede che la valutazione spieghi quali canali permettono a una persona di opporsi o chiedere cancellazione. La DPIA deve quindi indicare come una richiesta arriva al registro dei trattamenti, chi la prende in carico e con quale prova si dimostra che è stata evasa nei termini.

Dati dei dipendenti nei chatbot IA aziendali

Un contratto di fornitura incollato in una chat per chiedere un riassunto. È il modo più comune in cui i dati escono dall'azienda, e non richiede nessuna violazione: basta un dipendente che vuole finire prima.

Il rischio principale non è il modello, è il comportamento ordinario. Per questo la raccomandazione "non inserire dati personali" non è un controllo: non ha un owner, non è verificabile e non produce evidenza. Un controllo è un registro degli strumenti autorizzati, con approvazione prima dell'uso e una lista di ciò che dentro quegli strumenti non può entrare.

La questione pesa sulle PMI, che secondo il Garante costituiscono oltre il 98% delle imprese italiane: molte non hanno un team privacy-tecnico dedicato, quindi il registro deve essere semplice da mantenere e difficile da aggirare.

Dalla classificazione dei prompt ai controlli periodici

Cinque controlli reggono l'intero impianto: divieto contrattuale di riutilizzo dei dati per l'addestramento, log di accesso conservati, procedura documentata per cancellazione e rettifica, formazione con evidenza di partecipazione, verifica periodica degli strumenti in uso. Si controllano in un'ora se esiste un registro. Non si controllano in nessun modo se il registro non esiste.

Un chiarimento sul formato della formazione, che è il punto in cui molti si fermano: l'evidenza non è il foglio firma scansionato, è la presa visione tracciata con data e contenuto. In AuditReady la conferma di lettura avviene tramite link sicuro e genera automaticamente un'evidenza, con o senza documento allegato.

Il collegamento che chiude il cerchio è tra uso dello strumento, registro dei trattamenti e fornitori ICT. Ogni applicazione autorizzata è un fornitore con un contratto, un eventuale trasferimento e un referente interno. Se questa corrispondenza non esiste, l'auditor trova un registro dei trattamenti che descrive un'organizzazione diversa da quella che i dipendenti usano ogni giorno.

Output generati e dati personali di terzi

"Posso usare una voce o un volto generato dall'IA?" La risposta sì o no non esiste, e chi la fornisce sta creando un rischio per chi la riceve. Il Garante ha segnalato che i dati artificiali prodotti da strumenti AI possono essere impiegati per frode, diffamazione o sostituzione di persona, e che il trattamento della voce o dell'immagine di soggetti terzi può violare gli articoli 5 e 6 del GDPR, con conseguenze sanzionatorie.

Quattro verifiche prima di pubblicare un output

Il punto di partenza è sempre l'identificabilità. Una voce sintetica che nessuno riconduce a una persona reale non è lo stesso caso di un volto riconoscibile in un video aziendale.

• Provenienza. Da quali dati di addestramento o di input nasce l'output? Se la risposta è "non lo sappiamo", la verifica è già fallita.
• Diritti e consenso. Esiste una base giuridica per trattare l'immagine o la voce di quella persona, e il consenso dove richiesto è documentato?
• Finalità e aspettative. La persona si aspetterebbe di essere rappresentata in quel contesto? Un uso interno e una pubblicazione sul sito hanno aspettative diverse.
• Tracciabilità. L'output ha una data, un autore e un'autorizzazione registrata? Senza questi tre elementi non è difendibile a distanza di mesi.

Il caso DeepSeek aggiunge una prospettiva che molti trascurano: un fornitore globale può contestare l'applicabilità della normativa europea pur trattando dati di utenti italiani, e questo non sospende la verifica del titolare. La domanda non è se il fornitore accetta il quadro europeo. È se l'organizzazione italiana può dimostrare su quali dati ha costruito l'output e chi lo ha autorizzato.

Quando arriva una contestazione o una richiesta di cancellazione, la sequenza è meccanica: identificare il contenuto, bloccarne la diffusione, rispondere in modo motivato e lasciare traccia nel registro. Un video rimosso senza una traccia che documenti chi ha deciso, quando e perché non protegge nessuno in una verifica successiva.

Registro degli usi IA ed evidenze da mostrare

Un registro degli usi IA non è un inventario di software. È una riga per ogni caso d'uso, collegata a una responsabilità, a una valutazione e a un documento che si può aprire. Se un campo contiene una dichiarazione e non un rimando a un file verificabile, quel campo non serve. Per scegliere cosa allegare, un riferimento utile è questo elenco di quali evidenze includere in un assessment privacy, da applicare campo per campo.

I campi minimi del registro

1. ID del caso d'uso, stabile nel tempo e citato in ogni evidenza collegata.
2. Sistema e versione del modello attiva, con la data da cui quella versione è in uso.
3. Owner, una persona, non una funzione.
4. Processo o asset coinvolto, così il caso si aggancia al registro dei trattamenti.
5. Finalità, scritta in modo che un revisore possa leggerla senza chiedere chiarimenti.
6. Categorie di dati e di interessati.
7. Base giuridica, con riferimento all'articolo applicabile.
8. Riferimento alla DPIA con data.
9. Fornitore e subfornitori, inclusi i trasferimenti extra UE.
10. Rischio inerente e rischio residuo.
11. Controlli compensativi, con la misura che li rende verificabili.
12. Scadenza della revisione.
13. Periodo di conservazione ed eventuale blocco legale.
14. Tipo di evento, distinguendo eccezione autorizzata con scadenza, non conformità e incidente di sicurezza o privacy.
15. Data e riferimento della chiusura o del rinnovo dell'eccezione, con l'approvazione che lo sostiene.

La funzione vera del registro emerge quando cambia qualcosa. Un revisore deve poter ricostruire quale versione era attiva in una data precisa e quale DPIA la copriva. Se il registro non conserva le versioni precedenti, la ricostruzione si fa a memoria, e la memoria non è un'evidenza.

Sul fronte delle segnalazioni di uso improprio, il collegamento utile è con il canale di whistleblowing previsto dal D.Lgs. 24/2023. Quando il caso incide sul Modello 231, l'evento rilevante deve arrivare all'Organismo di Vigilanza senza trascinarsi dietro il testo della segnalazione: il canale riservato e la gestione degli eventi di governance sono due percorsi distinti, e la separazione va documentata.

Su questo punto conviene essere espliciti: AuditReady non promette governance automatica, compliance magica o responsabilità delegate al software. La piattaforma organizza registri, evidenze versionate con integrità SHA-256 e audit trail immutabile. La decisione resta di chi firma.

Errori comuni e verifica prima dell'audit

Gli errori che aprono un finding

Approvazioni retroattive. La delibera porta una data successiva all'avvio dell'uso. L'auditor lo vede subito, e da quel momento ogni altra data del fascicolo diventa sospetta.

DPIA mai riaperta. Il modello è cambiato tre volte, la valutazione è ferma alla prima versione. Il documento esiste, ma copre un sistema che non gira più.

Eccezioni rinnovate senza fine. Un'eccezione prorogata per la sesta volta ha smesso di essere temporanea: è un controllo assente con una firma sopra.

Evidenze sparse tra email, chat e cartelle condivise. Il controllo è stato eseguito, ma nessuno lo trova nel tempo utile. Ai fini della revisione equivale a un controllo mai fatto.

Screenshot senza data. L'immagine mostra una schermata, non dimostra quando è stata catturata né da quale ambiente.

Chiusure non verificate. Il finding è segnato come chiuso perché qualcuno ha dichiarato di aver agito. Senza evidenza di chiusura e verifica indipendente, resta aperto.

Sei domande da porre a un caso d'uso reale

Prese singolarmente sembrano ovvie. Applicate a un caso d'uso concreto, mostrano subito dove si interrompe la catena.

1. Ogni caso d'uso ha owner, base giuridica e DPIA datata?
2. L'ultima modifica del modello ha riattivato la valutazione?
3. Un auditor può ricostruire chi ha usato lo strumento e con quale categoria di dato?
4. Le approvazioni precedono l'uso, o lo seguono?
5. Ogni eccezione ha scadenza e approvazione tracciate?
6. Ogni finding ha un intervento e un'evidenza di chiusura verificata?

Il modo più utile di usarle è applicarle a un caso d'uso reale prima del prossimo audit, invece di distribuirle come questionario generale. Nella fase di validazione, AuditReady separa ciò che è pronto, ciò che manca e ciò che richiede intervento umano: la stessa distinzione che serve quando il tempo è poco e la priorità va scelta.

Le lacune che emergono vanno registrate come finding, con severità, responsabile, scadenza e intervento, non annotate in una chat. Un finding registrato produce un piano d'azione; un appunto in una chat produce una discussione che si chiude senza evidenza.

Un audit sull'IA misura la continuità della catena di prove più della qualità delle policy: owner, basi giuridiche, approvazioni, evidenze e chiusure devono reggere come un percorso unico. AuditReady collega casi d'uso IA, registri privacy, controlli, finding e remediation ed esporta Audit Day Pack strutturati per il revisore. Potete vedere come si costruisce il pacchetto su AuditReady.