Un revisore interno apre il registro dei trattamenti e chiede tre cose. Chi ha autorizzato l'inserimento dei dati di clienti nei prompt dell'assistente generativo. Dove sono conservati i log di quelle sessioni. Quale decisione, con quale data, ha chiuso l'ultima revisione del sistema. La policy sull'uso dell'intelligenza artificiale esiste, è stata approvata due anni fa e nessuno l'ha mai contestata. Le tre risposte, invece, mancano.
È il punto in cui la conformità documentale si separa dalla prova di esecuzione. Il problema della maggior parte delle organizzazioni non è l'assenza di regole, ma l'impossibilità di dimostrare chi ha fatto cosa, quando e con quale esito. Il taglio di questo articolo è operativo e di governance, non giuridico. Non interpreta il GDPR né l'AI Act e non sostituisce il parere del legale, del DPO o dell'Organismo di Vigilanza. Si occupa di come si costruisce, si versiona e si esibisce l'evidenza che un controllo è stato eseguito.
Una policy senza data e senza autore è una dichiarazione di intenti. Un controllo senza prova è un ricordo.
Sulla privacy intelligenza artificiale circolano guide solide su basi giuridiche, anonimizzazione e divieto di incollare dati riservati nei chatbot. Restano più vaghe su una domanda che in audit arriva prima delle altre: come dimostrare che l'uso quotidiano degli strumenti è stato governato per tutto il periodo oggetto di verifica.
Indice
- Perché la privacy dell'IA si gioca sulle prove
- Inventario dei casi d'uso e soglie per la DPIA
- Ruoli, flusso e prove minime per ogni fase
- Fornitori IA, trasferimenti e prove dei subfornitori
- Registri, eccezioni e campi minimi di audit
- Output, richieste degli interessati e incidenti
- Errori comuni che indeboliscono l'audit
- Domande frequenti sui casi limite
- Verificare la prontezza prima del prossimo audit
- Perché la privacy dell'IA si gioca sulle prove
- Inventario dei casi d'uso e soglie per la DPIA
- Ruoli, flusso e prove minime per ogni fase
- Fornitori IA, trasferimenti e prove dei subfornitori
- Registri, eccezioni e campi minimi di audit
- Output, richieste degli interessati e incidenti
- Errori comuni che indeboliscono l'audit
- Domande frequenti sui casi limite
- Verificare la prontezza prima del prossimo audit
- Perché la privacy dell'IA si gioca sulle prove
- Inventario dei casi d'uso e soglie per la DPIA
- Ruoli, flusso e prove minime per ogni fase
- Fornitori IA, trasferimenti e prove dei subfornitori
- Registri, eccezioni e campi minimi di audit
- Output, richieste degli interessati e incidenti
- Errori comuni che indeboliscono l'audit
- Domande frequenti sui casi limite
- Verificare la prontezza prima del prossimo audit
Perché la privacy dell'IA si gioca sulle prove
La policy approvata due anni fa elencava finalità, divieti e responsabilità. Non diceva nulla su ciò che sarebbe accaduto dopo. Un team ha iniziato a usare un assistente generativo per riassumere i ticket dei clienti. Sei mesi più tardi lo stesso strumento riceveva estratti di contratti e valutazioni interne, senza che nessuno modificasse la decisione originaria. Nessuno ha deciso male: il caso d'uso si è spostato e il presidio è rimasto fermo alla versione approvata.
Il Garante per la protezione dei dati personali ha descritto il nodo in modo diretto: la privacy dell'IA non si esaurisce nella scelta del modello o del fornitore, e la domanda che resta aperta è come dimostrare che prompt, output, modifiche del modello, trasferimenti internazionali e richieste degli interessati siano stati governati nel tempo. Il punto più scomodo è che il rischio maggiore nasce dall'uso quotidiano e non autorizzato di strumenti apparentemente innocui, non solo da un progetto classificato formalmente ad alto rischio.
La scala del fenomeno non aiuta a trattarlo come un adempimento occasionale. Nella sintesi della Relazione sull'attività 2025 il Garante segnala 506 provvedimenti correttivi e sanzionatori e oltre 37 milioni di euro di sanzioni complessive. Sono numeri che non riguardano soltanto l'IA, ma collocano il tema dentro un apparato di enforcement con conseguenze economiche misurabili.
Quattro distinzioni reggono tutto il resto del ragionamento.
- Policy scritta contro controllo eseguito. Un documento approvato dimostra un'intenzione. Un log, un ticket, un export di configurazione con data e autore dimostrano un'esecuzione.
- Eccezione autorizzata e a tempo, non conformità, incidente di sicurezza o privacy. Sono tre stati diversi, con tre percorsi diversi: deroga motivata con scadenza, scostamento rilevato da un controllo, evento con impatto e notifica.
- Software e automazione contro responsabilità umana. Uno strumento raccoglie, versiona e collega evidenze. Non decide la conformità, non assume il rischio e non firma al posto di nessuno.
- Organizzazione operativa contro consulenza legale. Il presidio interno governa ruoli, prove e scadenze. L'interpretazione delle clausole e delle basi giuridiche resta a chi ha la competenza per farlo.
Su quest'ultimo punto vale una precisazione che riguarda gli strumenti, non le intenzioni: AuditReady non promette governance automatica, compliance magica o responsabilità delegate al software.
Catena di riferimento: requisito, controllo, owner, evidenza datata, audit trail, finding, rimedio.
Inventario dei casi d'uso e soglie per la DPIA
L'inventario è il punto di partenza perché è l'unico registro che risponde alla domanda "dove sta l'IA dentro i nostri trattamenti". I cinque casi ricorrenti nelle organizzazioni italiane si somigliano abbastanza da poter essere schemati.
| Caso d'uso | Dati coinvolti | Obblighi o verifiche principali |
|---|---|---|
| Assistente generativo con dati aziendali nei prompt | Dati di clienti e dipendenti inseriti dagli utenti | Politica di inserimento, log dei prompt, valutazione del fornitore |
| Addestramento su dati raccolti online | Dati personali pubblici di terzi | Base giuridica, finalità, minimizzazione, valutazione DPIA |
| Generazione di contenuti con voce o immagine di terzi | Dati biometrici o identificativi | Base giuridica, autorizzazioni, controlli contro l'uso non autorizzato |
| Monitoraggio di lavoratori con strumenti IA | Dati comportamentali e di prestazione | Necessità, proporzionalità, trasparenza verso i lavoratori |
| Servizio con infrastruttura fuori dall'UE | Dati di account, input e log | Mappatura dei trasferimenti e garanzie contrattuali |
Per ogni sistema la scheda dovrebbe riportare finalità, categorie di dati, base giuridica, ruoli privacy, fornitori, trasferimenti, tempi di conservazione e misure di minimizzazione, secondo l'impostazione che il Garante collega esplicitamente all'art. 25 GDPR. La valutazione non si ferma al modello. Dati eccedenti inseriti nei prompt finiscono nei log del fornitore e possono influenzare risposte successive, quindi vanno verificati anche dataset e interfacce.
Sul fronte dei dati raccolti online esiste un'indicazione dedicata: il Garante ha pubblicato precisazioni sul web scraping per l'addestramento dei sistemi generativi, ricordando che la disponibilità pubblica di un dato non equivale automaticamente alla libertà di riutilizzarlo per qualsiasi finalità. Chi usa dataset di terzi deve poter esibire origine dei dati, categorie di interessati, finalità e misure per l'esercizio dei diritti.
Il caso del monitoraggio dei lavoratori merita una riga a sé. Il Garante ha vietato ad Amazon Italia Logistica il trattamento dei dati personali di oltre 1.800 lavoratori, richiamando i criteri di necessità, proporzionalità e trasparenza. Un limite analogo vale per qualsiasi strumento di analisi delle performance che osservi persone e non processi.
Due piani distinti, due serie di prove
Il Regolamento (UE) 2024/1689 classifica i sistemi e assegna obblighi a fornitore e utilizzatore. Il GDPR governa liceità, informativa, minimizzazione, sicurezza e diritti degli interessati. Sono piani collegati ma non sovrapponibili, e la confusione tra i due produce una lacuna tipica: dichiarare un sistema "conforme all'AI Act" senza poter mostrare la base giuridica del trattamento o l'adeguatezza dell'informativa. Nel registro dei trattamenti e nella DPIA i due piani vanno riportati entrambi, con evidenze separate e con date.
La DPIA si attiva quando il trattamento presenta rischi elevati: profilazione sistematica, uso di dati sensibili, monitoraggio su larga scala. Rischi, controlli, decisioni e prove vanno collegati a responsabili, scadenze ed evidenze verificabili.
Chi deve allargare lo sguardo dal singolo caso d'uso al perimetro complessivo può partire dalla nostra analisi dei rischi dell'intelligenza artificiale.
Ruoli, flusso e prove minime per ogni fase
La separazione dei compiti non è un formalismo. Se chi propone l'uso dello strumento è anche chi ne verifica l'esito, l'auditor non ha bisogno di cercare altro: ha già il finding. Il flusso minimo, dalla proposta alla verifica, è questo.
| Fase o controllo | Decisione o responsabilità | Evidenza minima verificabile |
|---|---|---|
| Inventario del sistema IA | Proposta del responsabile di processo, verifica del DPO | Scheda con finalità, owner e stato datata |
| Valutazione preliminare e DPIA | Decisione del DPO, firma del titolare o del responsabile | Versione della DPIA con rischi, misure e data di approvazione |
| Approvazione del fornitore | Decisione del responsabile IT o sicurezza con parere privacy | Questionario compilato e clausole contrattuali archiviate |
| Configurazione e minimizzazione | Esecuzione IT, verifica del security manager | Export datato della configurazione e log delle modifiche |
| Uso operativo | Utenti autorizzati, supervisione umana per decisioni rilevanti | Registro degli accessi e campione di output classificati |
| Richieste degli interessati | Responsabile privacy con termini di risposta | Ticket con data di ricezione, esito e prova di esecuzione |
| Incidenti e non conformità | Owner dell'incidente, escalation al DPO | Registro con classificazione, timeline e chiusura verificata |
| Revisione periodica | Internal auditor o OdV, con sign-off del titolare del rischio | Verbale di revisione con evidenze campionate |
Sei passaggi, sei errori tipici
- Proposta motivata. Il responsabile di processo descrive finalità, dati coinvolti e fornitore, e la proposta viene protocollata. L'errore ricorrente è la proposta a voce in riunione: esiste nella memoria dei presenti, non nel fascicolo.
- Valutazione preliminare e decisione del DPO sulla necessità della DPIA. Serve una risposta scritta, anche quando è negativa. L'errore è avviare la DPIA dopo l'attivazione, trasformandola in una ratifica.
- Approvazione del titolare o del responsabile di processo, datata e precedente all'avvio. La data è la prova. L'errore è l'approvazione firmata quando il pilota gira già da tre settimane.
- Configurazione con minimizzazione, controllo degli accessi e registrazione delle modifiche. Pseudonimizzazione prima dell'invio, segregazione tra ambienti, divieto di dati particolari salvo necessità documentata. L'errore è accettare i default del fornitore senza esportarli e datarli.
- Uso monitorato con log e campionamento degli output. Il campione dice come lo strumento viene usato davvero. L'errore è non campionare mai e scoprire l'uso improprio solo dal reclamo di un interessato.
- Revisione periodica con verbale e finding. Serve un verbale con evidenze citate, non un riassunto. L'errore è far coincidere proponente e verificatore.
Per i sistemi che trattano voce o immagine di terzi la documentazione va costruita prima dell'adozione. Il Garante richiama i considerando 78 e l'art. 25 GDPR e avverte che il trattamento di voce o immagine di soggetti terzi può configurare una violazione degli articoli 5 e 6: servono caso d'uso, categorie di dati biometrici o identificativi coinvolte, base giuridica, necessità, limiti di conservazione, autorizzazioni e controlli contro l'uso non autorizzato di contenuti altrui. La prova non è la policy: sono valutazione del fornitore, configurazioni privacy-by-default, test, log degli accessi e gestione degli incidenti, con il DPO coinvolto quando il trattamento rientra nel suo perimetro.
Chi deve decidere quali documenti entrano nel fascicolo di queste fasi può usare la nostra guida su quali evidenze includere in un assessment privacy.
L'owner resta una persona nominata. Il sistema registra decisioni, versioni e scadenze, e questo è utile esattamente perché nessuno ricostruisce a memoria. La firma, però, resta umana.
Fornitori IA, trasferimenti e prove dei subfornitori
Nel febbraio 2025 il Garante ha adottato una misura urgente nei confronti di Hangzhou DeepSeek Artificial Intelligence e Beijing DeepSeek Artificial Intelligence, limitando con effetto immediato il trattamento dei dati degli utenti italiani da parte del chatbot DeepSeek. L'Autorità ha chiesto chiarimenti su quali dati personali fossero raccolti, sulle fonti utilizzate, sulle finalità, sulla base giuridica e sull'eventuale conservazione su server situati in Cina, in un contesto in cui il fornitore contestava l'applicabilità della normativa europea o sosteneva di non operare direttamente nel Paese.
Due elementi contano per chi acquista strumenti generativi. Il primo: l'intervento è arrivato prima di una sanzione definitiva, quindi il rischio non è solo economico, è di sospensione dell'operatività. Il secondo: la verifica riguardava dati di prompt, log, account, addestramento, subfornitori e localizzazione dell'infrastruttura, non la qualità delle risposte del modello.
Un fornitore va valutato per ciò che fa con i dati, non per ciò che dichiara in una brochure.
| Area | Evidenza da richiedere | Verifica nel tempo |
|---|---|---|
| Localizzazione e trasferimenti | Mappa dei server e clausole di trasferimento | All'onboarding, al rinnovo e a ogni cambio di infrastruttura |
| Conservazione di input e log | Tempi di retention e modalità di cancellazione | Revisione annuale e a ogni audit |
| Uso dei dati per addestramento | Dichiarazione contrattuale e configurazione disponibile | All'onboarding e a ogni aggiornamento dei termini |
| Subfornitori | Elenco aggiornato con ruolo e localizzazione | Trimestrale o al cambio di subfornitore |
| Gestione delle opposizioni | Procedura e tempi di propagazione | Test a campione |
| Notifica di incidenti | Termini contrattuali e contatti dedicati | Test annuale della catena di notifica |
La differenza che conta è tra dichiarazione contrattuale e configurazione verificata. Una clausola che esclude l'uso degli input per l'addestramento è necessaria e non sufficiente: accanto serve l'export datato dell'impostazione, con identificativo del tenant, versione del prodotto e autore della verifica. Vale per la retention, per l'accesso dei subfornitori e per la propagazione di un'opposizione.
La richiesta al fornitore, poi, va gestita come una pratica e non come uno scambio di email. Un canale tracciato, un termine di risposta dichiarato, un archivio con la versione del documento ricevuto e la data in cui è stato caricato. Se il fornitore risponde con una presentazione commerciale, la richiesta è ancora aperta.
Il parere legale resta necessario per negoziare clausole e valutare i trasferimenti. Il controllo operativo, cioè verificare che quanto promesso sia configurato e documentato, resta in carico al responsabile del fornitore, che ne risponde all'interno dell'organizzazione.
Per strutturare la richiesta in modo ripetibile c'è un modello pronto: questionario di qualifica fornitori.
Registri, eccezioni e campi minimi di audit
Un registro è verificabile solo se ogni record contiene gli stessi campi, compilati e datati. La variabilità è ciò che rende un registro inutile in sede di verifica, perché costringe l'auditor a interpretare invece di leggere.
I campi minimi, validi per un registro DPIA come per un registro finding o incidenti, sono questi.
- Identificativo univoco e stabile nel tempo.
- Owner, una persona nominata, non una funzione.
- Processo o asset coinvolto, collegato al sistema IA.
- Rischio inerente e rischio residuo, valutati prima e dopo i controlli.
- Controlli compensativi attivi, con la data in cui sono stati verificati.
- Data di apertura e scadenza, entrambe esplicite.
- Stato aggiornato, non dedotto dal contesto.
- Evidenza di chiusura allegata al record.
- Approvazione di chiusura firmata da un soggetto diverso dall'owner.
Eccezione, non conformità, incidente
Un'eccezione autorizzata è una deroga consapevole: ha motivazione scritta, controlli compensativi e una scadenza. Non si rinnova per inerzia. Ogni proroga richiede una nuova approvazione motivata e una nuova valutazione del rischio residuo, altrimenti diventa una non conformità travestita.
Una non conformità è uno scostamento rilevato da un controllo o da un audit, e vive dentro un piano di rimedio con responsabile e data. Un incidente ha una propria timeline e un proprio obbligo di notifica: non è la stessa cosa, e trattarlo come tale confonde sia il registro sia l'escalation.
Sul contenuto dei registri vale la separazione tra i due piani normativi. L'EU AI Act è il riferimento per classificare e governare i sistemi, ma non sostituisce il GDPR: il registro interno dovrebbe conservare finalità, modello o fornitore, dati utilizzati, ruolo dell'organizzazione, utenti autorizzati, supervisione umana, output rilevanti, incidenti e decisioni di remediation.
Nella fase di validazione AuditReady separa ciò che è pronto, ciò che manca e ciò che richiede intervento umano. È una distinzione pratica: un registro con soli titoli delle DPIA risulta "presente" in una scansione di cartelle e assente in un audit, perché mancano versione, data di approvazione, rischi valutati e firma. Lo stesso registro con quei campi compilati supera il campione senza discussioni.
Output, richieste degli interessati e incidenti
Un dipendente copia un output dell'assistente in un ticket di assistenza, in una valutazione delle performance o in una cartella condivisa. Il problema non è il testo: è l'assenza di un passaggio che colleghi quell'output all'uso reale che ne è stato fatto.
Classificare gli output in quattro categorie aiuta più di qualsiasi policy discorsiva: dati personali, dati particolari, informazioni lavorative, inferenze su persone. Quando un output alimenta una decisione su una persona servono un'approvazione umana prima dell'uso, una data di conservazione e un responsabile che ne risponde.
Il diritto di opposizione non è un'informativa: è una richiesta da ricevere, verificare, valutare e tracciare con esito e tempi. Il Garante ha riconosciuto questo diritto agli utenti di Facebook e Instagram e anche ai non utenti i cui dati compaiono sulle piattaforme perché pubblicati da altri, il che esclude che la gestione possa limitarsi ai soli account aziendali.
Quando un incidente coinvolge output o dati personali, il responsabile del processo apre la segnalazione, il DPO valuta la gravità e il titolare decide sulla notifica, che di norma va effettuata entro 72 ore dalla conoscenza della violazione secondo l'art. 33 GDPR, con motivazione documentata se il termine non viene rispettato. La timeline con data di rilevazione, contenimento e decisione di notifica è la prima cosa che l'auditor guarda.
Errori comuni che indeboliscono l'audit
L'errore più frequente non è documentale, è cronologico: la firma arriva dopo l'avvio. L'auditor lo vede subito, perché confronta la data di attivazione dello strumento con la data dell'approvazione.
- Approvazioni retroattive. Correzione: firma datata prima dell'avvio, con la proposta e la valutazione che la precedono.
- Eccezioni rinnovate senza fine. Correzione: scadenza obbligatoria e nuova analisi del rischio a ogni proroga.
- Evidenze sparse tra email, chat e cartelle personali. Correzione: un repository unico per caso, con i documenti collegati alla fase.
- Finding chiusi senza verifica indipendente. Correzione: firma del verificatore distinta da quella dell'owner.
- Screenshot senza timestamp, sistema e versione. Correzione: metadati su ogni evidenza, con autore e identificativo dell'ambiente.
- Policy aggiornate senza numero di versione e data di entrata in vigore. Correzione: versione e data su ogni documento, così da dimostrare quale testo era vigente al momento del fatto.
Nessuno di questi controlli si fa rileggendo la policy. Si fa campionando un caso reale e chiedendo al team di esibirlo senza ricostruzioni.
Domande frequenti sui casi limite
Un dipendente copia un output dell'assistente in una valutazione delle performance. Chi apre l'incidente? Il responsabile del processo, che classifica l'output, valuta l'impatto sulla persona e attiva l'escalation al DPO secondo i tempi interni. La prova è il ticket con data di apertura e valutazione.
Il fornitore dichiara di non addestrare i modelli sui dati del cliente. Basta come prova? No. Servono la clausola contrattuale e una configurazione verificata, esportata e datata, con l'indicazione del tenant e della versione del prodotto.
Quando un'eccezione diventa una non conformità? Alla scadenza senza rimedio, oppure al primo rinnovo non motivato. Da quel momento il record cambia natura e va trattato con un piano di rimedio.
Chi firma la valutazione di un sistema IA ad alto impatto? Un responsabile umano nominato, mai lo strumento. Il software organizza evidenze e scadenze, la valutazione resta un atto della persona.
Ogni risposta rimanda a un record campionabile: il ticket, la clausola, la scadenza, la firma.
Verificare la prontezza prima del prossimo audit
Scegliete un controllo, non l'intero sistema, e applicate queste sei domande. Se una risposta è "dipende da chi lo ha gestito", la risposta è no.
- Ogni sistema IA ha owner, finalità e stato nell'inventario, con data di ultimo aggiornamento?
- Ogni uso ad alto impatto ha una DPIA approvata prima dell'avvio, con numero di versione?
- Le evidenze del controllo campionato si trovano senza ricostruzione, con data e autore?
- Le eccezioni hanno scadenza, controlli compensativi e un'approvazione distinta da chi le ha proposte?
- Ogni finding chiuso ha un'evidenza verificata da un soggetto diverso dall'owner?
- Le richieste degli interessati e le opposizioni hanno esito e tempi tracciati?
Il flusso più utile su cui esercitarsi è la gestione delle richieste degli interessati, perché attraversa ufficio legale, IT, risorse umane e fornitori. Una simulazione con un auditor interno, su un campione di dieci richieste, mostra in mezza giornata dove la catena si interrompe.
La prontezza non è un adempimento da chiudere una volta. È una verifica continua, che invecchia come invecchiano i log e le configurazioni.
Il primo contatto con Devisia riguarda fatti, vincoli, responsabilità e criteri di accettazione, senza imporre uno stack tecnologico o un fornitore. Nessuno strumento, incluso il nostro, certifica la conformità o sostituisce una valutazione professionale.
AuditReady riunisce in un unico ambiente i sistemi di IA con finalità, owner, stato del ciclo di vita e classificazione del rischio, accanto ai registri privacy, ai controlli, ai finding e alle evidenze versionate con integrità SHA-256 e audit trail immutabile. I fornitori possono inviare la documentazione tramite collegamenti sicuri con scadenza, senza creare un account, e l'Audit Day Pack esporta il pacchetto ordinato per la revisione. Puoi vedere come funziona nella demo di AuditReady, con i tuoi casi d'uso e senza impegno.
Un revisore interno apre il registro dei trattamenti e chiede tre cose. Chi ha autorizzato l'inserimento dei dati di clienti nei prompt dell'assistente generativo. Dove sono conservati i log di quelle sessioni. Quale decisione, con quale data, ha chiuso l'ultima revisione del sistema. La policy sull'uso dell'intelligenza artificiale esiste, è stata approvata due anni fa e nessuno l'ha mai contestata. Le tre risposte, invece, mancano.
È il punto in cui la conformità documentale si separa dalla prova di esecuzione. Il problema della maggior parte delle organizzazioni non è l'assenza di regole, ma l'impossibilità di dimostrare chi ha fatto cosa, quando e con quale esito. Il taglio di questo articolo è operativo e di governance, non giuridico. Non interpreta il GDPR né l'AI Act e non sostituisce il parere del legale, del DPO o dell'Organismo di Vigilanza. Si occupa di come si costruisce, si versiona e si esibisce l'evidenza che un controllo è stato eseguito.
Una policy senza data e senza autore è una dichiarazione di intenti. Un controllo senza prova è un ricordo.
Sulla privacy intelligenza artificiale circolano guide solide su basi giuridiche, anonimizzazione e divieto di incollare dati riservati nei chatbot. Restano più vaghe su una domanda che in audit arriva prima delle altre: come dimostrare che l'uso quotidiano degli strumenti è stato governato per tutto il periodo oggetto di verifica.
Perché la privacy dell'IA si gioca sulle prove
La policy approvata due anni fa elencava finalità, divieti e responsabilità. Non diceva nulla su ciò che sarebbe accaduto dopo. Un team ha iniziato a usare un assistente generativo per riassumere i ticket dei clienti. Sei mesi più tardi lo stesso strumento riceveva estratti di contratti e valutazioni interne, senza che nessuno modificasse la decisione originaria. Nessuno ha deciso male: il caso d'uso si è spostato e il presidio è rimasto fermo alla versione approvata.
Il Garante per la protezione dei dati personali ha descritto il nodo in modo diretto: la privacy dell'IA non si esaurisce nella scelta del modello o del fornitore, e la domanda che resta aperta è come dimostrare che prompt, output, modifiche del modello, trasferimenti internazionali e richieste degli interessati siano stati governati nel tempo. Il punto più scomodo è che il rischio maggiore nasce dall'uso quotidiano e non autorizzato di strumenti apparentemente innocui, non solo da un progetto classificato formalmente ad alto rischio.
La scala del fenomeno non aiuta a trattarlo come un adempimento occasionale. Nella sintesi della Relazione sull'attività 2025 il Garante segnala 506 provvedimenti correttivi e sanzionatori e oltre 37 milioni di euro di sanzioni complessive. Sono numeri che non riguardano soltanto l'IA, ma collocano il tema dentro un apparato di enforcement con conseguenze economiche misurabili.
Quattro distinzioni reggono tutto il resto del ragionamento.
- Policy scritta contro controllo eseguito. Un documento approvato dimostra un'intenzione. Un log, un ticket, un export di configurazione con data e autore dimostrano un'esecuzione.
- Eccezione autorizzata e a tempo, non conformità, incidente di sicurezza o privacy. Sono tre stati diversi, con tre percorsi diversi: deroga motivata con scadenza, scostamento rilevato da un controllo, evento con impatto e notifica.
- Software e automazione contro responsabilità umana. Uno strumento raccoglie, versiona e collega evidenze. Non decide la conformità, non assume il rischio e non firma al posto di nessuno.
- Organizzazione operativa contro consulenza legale. Il presidio interno governa ruoli, prove e scadenze. L'interpretazione delle clausole e delle basi giuridiche resta a chi ha la competenza per farlo.
Su quest'ultimo punto vale una precisazione che riguarda gli strumenti, non le intenzioni: AuditReady non promette governance automatica, compliance magica o responsabilità delegate al software.
Catena di riferimento: requisito, controllo, owner, evidenza datata, audit trail, finding, rimedio.
Inventario dei casi d'uso e soglie per la DPIA
L'inventario è il punto di partenza perché è l'unico registro che risponde alla domanda "dove sta l'IA dentro i nostri trattamenti". I cinque casi ricorrenti nelle organizzazioni italiane si somigliano abbastanza da poter essere schemati.
| Caso d'uso | Dati coinvolti | Obblighi o verifiche principali |
|---|---|---|
| Assistente generativo con dati aziendali nei prompt | Dati di clienti e dipendenti inseriti dagli utenti | Politica di inserimento, log dei prompt, valutazione del fornitore |
| Addestramento su dati raccolti online | Dati personali pubblici di terzi | Base giuridica, finalità, minimizzazione, valutazione DPIA |
| Generazione di contenuti con voce o immagine di terzi | Dati biometrici o identificativi | Base giuridica, autorizzazioni, controlli contro l'uso non autorizzato |
| Monitoraggio di lavoratori con strumenti IA | Dati comportamentali e di prestazione | Necessità, proporzionalità, trasparenza verso i lavoratori |
| Servizio con infrastruttura fuori dall'UE | Dati di account, input e log | Mappatura dei trasferimenti e garanzie contrattuali |
Per ogni sistema la scheda dovrebbe riportare finalità, categorie di dati, base giuridica, ruoli privacy, fornitori, trasferimenti, tempi di conservazione e misure di minimizzazione, secondo l'impostazione che il Garante collega esplicitamente all'art. 25 GDPR. La valutazione non si ferma al modello. Dati eccedenti inseriti nei prompt finiscono nei log del fornitore e possono influenzare risposte successive, quindi vanno verificati anche dataset e interfacce.
Sul fronte dei dati raccolti online esiste un'indicazione dedicata: il Garante ha pubblicato precisazioni sul web scraping per l'addestramento dei sistemi generativi, ricordando che la disponibilità pubblica di un dato non equivale automaticamente alla libertà di riutilizzarlo per qualsiasi finalità. Chi usa dataset di terzi deve poter esibire origine dei dati, categorie di interessati, finalità e misure per l'esercizio dei diritti.
Il caso del monitoraggio dei lavoratori merita una riga a sé. Il Garante ha vietato ad Amazon Italia Logistica il trattamento dei dati personali di oltre 1.800 lavoratori, richiamando i criteri di necessità, proporzionalità e trasparenza. Un limite analogo vale per qualsiasi strumento di analisi delle performance che osservi persone e non processi.
Due piani distinti, due serie di prove
Il Regolamento (UE) 2024/1689 classifica i sistemi e assegna obblighi a fornitore e utilizzatore. Il GDPR governa liceità, informativa, minimizzazione, sicurezza e diritti degli interessati. Sono piani collegati ma non sovrapponibili, e la confusione tra i due produce una lacuna tipica: dichiarare un sistema "conforme all'AI Act" senza poter mostrare la base giuridica del trattamento o l'adeguatezza dell'informativa. Nel registro dei trattamenti e nella DPIA i due piani vanno riportati entrambi, con evidenze separate e con date.
La DPIA si attiva quando il trattamento presenta rischi elevati: profilazione sistematica, uso di dati sensibili, monitoraggio su larga scala. Rischi, controlli, decisioni e prove vanno collegati a responsabili, scadenze ed evidenze verificabili.
Chi deve allargare lo sguardo dal singolo caso d'uso al perimetro complessivo può partire dalla nostra analisi dei rischi dell'intelligenza artificiale.
Ruoli, flusso e prove minime per ogni fase
La separazione dei compiti non è un formalismo. Se chi propone l'uso dello strumento è anche chi ne verifica l'esito, l'auditor non ha bisogno di cercare altro: ha già il finding. Il flusso minimo, dalla proposta alla verifica, è questo.
| Fase o controllo | Decisione o responsabilità | Evidenza minima verificabile |
|---|---|---|
| Inventario del sistema IA | Proposta del responsabile di processo, verifica del DPO | Scheda con finalità, owner e stato datata |
| Valutazione preliminare e DPIA | Decisione del DPO, firma del titolare o del responsabile | Versione della DPIA con rischi, misure e data di approvazione |
| Approvazione del fornitore | Decisione del responsabile IT o sicurezza con parere privacy | Questionario compilato e clausole contrattuali archiviate |
| Configurazione e minimizzazione | Esecuzione IT, verifica del security manager | Export datato della configurazione e log delle modifiche |
| Uso operativo | Utenti autorizzati, supervisione umana per decisioni rilevanti | Registro degli accessi e campione di output classificati |
| Richieste degli interessati | Responsabile privacy con termini di risposta | Ticket con data di ricezione, esito e prova di esecuzione |
| Incidenti e non conformità | Owner dell'incidente, escalation al DPO | Registro con classificazione, timeline e chiusura verificata |
| Revisione periodica | Internal auditor o OdV, con sign-off del titolare del rischio | Verbale di revisione con evidenze campionate |
Sei passaggi, sei errori tipici
- Proposta motivata. Il responsabile di processo descrive finalità, dati coinvolti e fornitore, e la proposta viene protocollata. L'errore ricorrente è la proposta a voce in riunione: esiste nella memoria dei presenti, non nel fascicolo.
- Valutazione preliminare e decisione del DPO sulla necessità della DPIA. Serve una risposta scritta, anche quando è negativa. L'errore è avviare la DPIA dopo l'attivazione, trasformandola in una ratifica.
- Approvazione del titolare o del responsabile di processo, datata e precedente all'avvio. La data è la prova. L'errore è l'approvazione firmata quando il pilota gira già da tre settimane.
- Configurazione con minimizzazione, controllo degli accessi e registrazione delle modifiche. Pseudonimizzazione prima dell'invio, segregazione tra ambienti, divieto di dati particolari salvo necessità documentata. L'errore è accettare i default del fornitore senza esportarli e datarli.
- Uso monitorato con log e campionamento degli output. Il campione dice come lo strumento viene usato davvero. L'errore è non campionare mai e scoprire l'uso improprio solo dal reclamo di un interessato.
- Revisione periodica con verbale e finding. Serve un verbale con evidenze citate, non un riassunto. L'errore è far coincidere proponente e verificatore.
Per i sistemi che trattano voce o immagine di terzi la documentazione va costruita prima dell'adozione. Il Garante richiama i considerando 78 e l'art. 25 GDPR e avverte che il trattamento di voce o immagine di soggetti terzi può configurare una violazione degli articoli 5 e 6: servono caso d'uso, categorie di dati biometrici o identificativi coinvolte, base giuridica, necessità, limiti di conservazione, autorizzazioni e controlli contro l'uso non autorizzato di contenuti altrui. La prova non è la policy: sono valutazione del fornitore, configurazioni privacy-by-default, test, log degli accessi e gestione degli incidenti, con il DPO coinvolto quando il trattamento rientra nel suo perimetro.
Chi deve decidere quali documenti entrano nel fascicolo di queste fasi può usare la nostra guida su quali evidenze includere in un assessment privacy.
L'owner resta una persona nominata. Il sistema registra decisioni, versioni e scadenze, e questo è utile esattamente perché nessuno ricostruisce a memoria. La firma, però, resta umana.
Fornitori IA, trasferimenti e prove dei subfornitori
Nel febbraio 2025 il Garante ha adottato una misura urgente nei confronti di Hangzhou DeepSeek Artificial Intelligence e Beijing DeepSeek Artificial Intelligence, limitando con effetto immediato il trattamento dei dati degli utenti italiani da parte del chatbot DeepSeek. L'Autorità ha chiesto chiarimenti su quali dati personali fossero raccolti, sulle fonti utilizzate, sulle finalità, sulla base giuridica e sull'eventuale conservazione su server situati in Cina, in un contesto in cui il fornitore contestava l'applicabilità della normativa europea o sosteneva di non operare direttamente nel Paese.
Due elementi contano per chi acquista strumenti generativi. Il primo: l'intervento è arrivato prima di una sanzione definitiva, quindi il rischio non è solo economico, è di sospensione dell'operatività. Il secondo: la verifica riguardava dati di prompt, log, account, addestramento, subfornitori e localizzazione dell'infrastruttura, non la qualità delle risposte del modello.
Un fornitore va valutato per ciò che fa con i dati, non per ciò che dichiara in una brochure.
| Area | Evidenza da richiedere | Verifica nel tempo |
|---|---|---|
| Localizzazione e trasferimenti | Mappa dei server e clausole di trasferimento | All'onboarding, al rinnovo e a ogni cambio di infrastruttura |
| Conservazione di input e log | Tempi di retention e modalità di cancellazione | Revisione annuale e a ogni audit |
| Uso dei dati per addestramento | Dichiarazione contrattuale e configurazione disponibile | All'onboarding e a ogni aggiornamento dei termini |
| Subfornitori | Elenco aggiornato con ruolo e localizzazione | Trimestrale o al cambio di subfornitore |
| Gestione delle opposizioni | Procedura e tempi di propagazione | Test a campione |
| Notifica di incidenti | Termini contrattuali e contatti dedicati | Test annuale della catena di notifica |
La differenza che conta è tra dichiarazione contrattuale e configurazione verificata. Una clausola che esclude l'uso degli input per l'addestramento è necessaria e non sufficiente: accanto serve l'export datato dell'impostazione, con identificativo del tenant, versione del prodotto e autore della verifica. Vale per la retention, per l'accesso dei subfornitori e per la propagazione di un'opposizione.
La richiesta al fornitore, poi, va gestita come una pratica e non come uno scambio di email. Un canale tracciato, un termine di risposta dichiarato, un archivio con la versione del documento ricevuto e la data in cui è stato caricato. Se il fornitore risponde con una presentazione commerciale, la richiesta è ancora aperta.
Il parere legale resta necessario per negoziare clausole e valutare i trasferimenti. Il controllo operativo, cioè verificare che quanto promesso sia configurato e documentato, resta in carico al responsabile del fornitore, che ne risponde all'interno dell'organizzazione.
Per strutturare la richiesta in modo ripetibile c'è un modello pronto: questionario di qualifica fornitori.
Registri, eccezioni e campi minimi di audit
Un registro è verificabile solo se ogni record contiene gli stessi campi, compilati e datati. La variabilità è ciò che rende un registro inutile in sede di verifica, perché costringe l'auditor a interpretare invece di leggere.
I campi minimi, validi per un registro DPIA come per un registro finding o incidenti, sono questi.
- Identificativo univoco e stabile nel tempo.
- Owner, una persona nominata, non una funzione.
- Processo o asset coinvolto, collegato al sistema IA.
- Rischio inerente e rischio residuo, valutati prima e dopo i controlli.
- Controlli compensativi attivi, con la data in cui sono stati verificati.
- Data di apertura e scadenza, entrambe esplicite.
- Stato aggiornato, non dedotto dal contesto.
- Evidenza di chiusura allegata al record.
- Approvazione di chiusura firmata da un soggetto diverso dall'owner.
Eccezione, non conformità, incidente
Un'eccezione autorizzata è una deroga consapevole: ha motivazione scritta, controlli compensativi e una scadenza. Non si rinnova per inerzia. Ogni proroga richiede una nuova approvazione motivata e una nuova valutazione del rischio residuo, altrimenti diventa una non conformità travestita.
Una non conformità è uno scostamento rilevato da un controllo o da un audit, e vive dentro un piano di rimedio con responsabile e data. Un incidente ha una propria timeline e un proprio obbligo di notifica: non è la stessa cosa, e trattarlo come tale confonde sia il registro sia l'escalation.
Sul contenuto dei registri vale la separazione tra i due piani normativi. L'EU AI Act è il riferimento per classificare e governare i sistemi, ma non sostituisce il GDPR: il registro interno dovrebbe conservare finalità, modello o fornitore, dati utilizzati, ruolo dell'organizzazione, utenti autorizzati, supervisione umana, output rilevanti, incidenti e decisioni di remediation.
Nella fase di validazione AuditReady separa ciò che è pronto, ciò che manca e ciò che richiede intervento umano. È una distinzione pratica: un registro con soli titoli delle DPIA risulta "presente" in una scansione di cartelle e assente in un audit, perché mancano versione, data di approvazione, rischi valutati e firma. Lo stesso registro con quei campi compilati supera il campione senza discussioni.
Output, richieste degli interessati e incidenti
Un dipendente copia un output dell'assistente in un ticket di assistenza, in una valutazione delle performance o in una cartella condivisa. Il problema non è il testo: è l'assenza di un passaggio che colleghi quell'output all'uso reale che ne è stato fatto.
Classificare gli output in quattro categorie aiuta più di qualsiasi policy discorsiva: dati personali, dati particolari, informazioni lavorative, inferenze su persone. Quando un output alimenta una decisione su una persona servono un'approvazione umana prima dell'uso, una data di conservazione e un responsabile che ne risponde.
Il diritto di opposizione non è un'informativa: è una richiesta da ricevere, verificare, valutare e tracciare con esito e tempi. Il Garante ha riconosciuto questo diritto agli utenti di Facebook e Instagram e anche ai non utenti i cui dati compaiono sulle piattaforme perché pubblicati da altri, il che esclude che la gestione possa limitarsi ai soli account aziendali.
Quando un incidente coinvolge output o dati personali, il responsabile del processo apre la segnalazione, il DPO valuta la gravità e il titolare decide sulla notifica, che di norma va effettuata entro 72 ore dalla conoscenza della violazione secondo l'art. 33 GDPR, con motivazione documentata se il termine non viene rispettato. La timeline con data di rilevazione, contenimento e decisione di notifica è la prima cosa che l'auditor guarda.
Errori comuni che indeboliscono l'audit
L'errore più frequente non è documentale, è cronologico: la firma arriva dopo l'avvio. L'auditor lo vede subito, perché confronta la data di attivazione dello strumento con la data dell'approvazione.
- Approvazioni retroattive. Correzione: firma datata prima dell'avvio, con la proposta e la valutazione che la precedono.
- Eccezioni rinnovate senza fine. Correzione: scadenza obbligatoria e nuova analisi del rischio a ogni proroga.
- Evidenze sparse tra email, chat e cartelle personali. Correzione: un repository unico per caso, con i documenti collegati alla fase.
- Finding chiusi senza verifica indipendente. Correzione: firma del verificatore distinta da quella dell'owner.
- Screenshot senza timestamp, sistema e versione. Correzione: metadati su ogni evidenza, con autore e identificativo dell'ambiente.
- Policy aggiornate senza numero di versione e data di entrata in vigore. Correzione: versione e data su ogni documento, così da dimostrare quale testo era vigente al momento del fatto.
Nessuno di questi controlli si fa rileggendo la policy. Si fa campionando un caso reale e chiedendo al team di esibirlo senza ricostruzioni.
Domande frequenti sui casi limite
Un dipendente copia un output dell'assistente in una valutazione delle performance. Chi apre l'incidente? Il responsabile del processo, che classifica l'output, valuta l'impatto sulla persona e attiva l'escalation al DPO secondo i tempi interni. La prova è il ticket con data di apertura e valutazione.
Il fornitore dichiara di non addestrare i modelli sui dati del cliente. Basta come prova? No. Servono la clausola contrattuale e una configurazione verificata, esportata e datata, con l'indicazione del tenant e della versione del prodotto.
Quando un'eccezione diventa una non conformità? Alla scadenza senza rimedio, oppure al primo rinnovo non motivato. Da quel momento il record cambia natura e va trattato con un piano di rimedio.
Chi firma la valutazione di un sistema IA ad alto impatto? Un responsabile umano nominato, mai lo strumento. Il software organizza evidenze e scadenze, la valutazione resta un atto della persona.
Ogni risposta rimanda a un record campionabile: il ticket, la clausola, la scadenza, la firma.
Verificare la prontezza prima del prossimo audit
Scegliete un controllo, non l'intero sistema, e applicate queste sei domande. Se una risposta è "dipende da chi lo ha gestito", la risposta è no.
- Ogni sistema IA ha owner, finalità e stato nell'inventario, con data di ultimo aggiornamento?
- Ogni uso ad alto impatto ha una DPIA approvata prima dell'avvio, con numero di versione?
- Le evidenze del controllo campionato si trovano senza ricostruzione, con data e autore?
- Le eccezioni hanno scadenza, controlli compensativi e un'approvazione distinta da chi le ha proposte?
- Ogni finding chiuso ha un'evidenza verificata da un soggetto diverso dall'owner?
- Le richieste degli interessati e le opposizioni hanno esito e tempi tracciati?
Il flusso più utile su cui esercitarsi è la gestione delle richieste degli interessati, perché attraversa ufficio legale, IT, risorse umane e fornitori. Una simulazione con un auditor interno, su un campione di dieci richieste, mostra in mezza giornata dove la catena si interrompe.
La prontezza non è un adempimento da chiudere una volta. È una verifica continua, che invecchia come invecchiano i log e le configurazioni.
Il primo contatto con Devisia riguarda fatti, vincoli, responsabilità e criteri di accettazione, senza imporre uno stack tecnologico o un fornitore. Nessuno strumento, incluso il nostro, certifica la conformità o sostituisce una valutazione professionale.
AuditReady riunisce in un unico ambiente i sistemi di IA con finalità, owner, stato del ciclo di vita e classificazione del rischio, accanto ai registri privacy, ai controlli, ai finding e alle evidenze versionate con integrità SHA-256 e audit trail immutabile. I fornitori possono inviare la documentazione tramite collegamenti sicuri con scadenza, senza creare un account, e l'Audit Day Pack esporta il pacchetto ordinato per la revisione. Puoi vedere come funziona nella demo di AuditReady, con i tuoi casi d'uso e senza impegno.
Un revisore interno apre il registro dei trattamenti e chiede tre cose. Chi ha autorizzato l'inserimento dei dati di clienti nei prompt dell'assistente generativo. Dove sono conservati i log di quelle sessioni. Quale decisione, con quale data, ha chiuso l'ultima revisione del sistema. La policy sull'uso dell'intelligenza artificiale esiste, è stata approvata due anni fa e nessuno l'ha mai contestata. Le tre risposte, invece, mancano.
È il punto in cui la conformità documentale si separa dalla prova di esecuzione. Il problema della maggior parte delle organizzazioni non è l'assenza di regole, ma l'impossibilità di dimostrare chi ha fatto cosa, quando e con quale esito. Il taglio di questo articolo è operativo e di governance, non giuridico. Non interpreta il GDPR né l'AI Act e non sostituisce il parere del legale, del DPO o dell'Organismo di Vigilanza. Si occupa di come si costruisce, si versiona e si esibisce l'evidenza che un controllo è stato eseguito.
Una policy senza data e senza autore è una dichiarazione di intenti. Un controllo senza prova è un ricordo.
Sulla privacy intelligenza artificiale circolano guide solide su basi giuridiche, anonimizzazione e divieto di incollare dati riservati nei chatbot. Restano più vaghe su una domanda che in audit arriva prima delle altre: come dimostrare che l'uso quotidiano degli strumenti è stato governato per tutto il periodo oggetto di verifica.
Perché la privacy dell'IA si gioca sulle prove
La policy approvata due anni fa elencava finalità, divieti e responsabilità. Non diceva nulla su ciò che sarebbe accaduto dopo. Un team ha iniziato a usare un assistente generativo per riassumere i ticket dei clienti. Sei mesi più tardi lo stesso strumento riceveva estratti di contratti e valutazioni interne, senza che nessuno modificasse la decisione originaria. Nessuno ha deciso male: il caso d'uso si è spostato e il presidio è rimasto fermo alla versione approvata.
Il Garante per la protezione dei dati personali ha descritto il nodo in modo diretto: la privacy dell'IA non si esaurisce nella scelta del modello o del fornitore, e la domanda che resta aperta è come dimostrare che prompt, output, modifiche del modello, trasferimenti internazionali e richieste degli interessati siano stati governati nel tempo. Il punto più scomodo è che il rischio maggiore nasce dall'uso quotidiano e non autorizzato di strumenti apparentemente innocui, non solo da un progetto classificato formalmente ad alto rischio.
La scala del fenomeno non aiuta a trattarlo come un adempimento occasionale. Nella sintesi della Relazione sull'attività 2025 il Garante segnala 506 provvedimenti correttivi e sanzionatori e oltre 37 milioni di euro di sanzioni complessive. Sono numeri che non riguardano soltanto l'IA, ma collocano il tema dentro un apparato di enforcement con conseguenze economiche misurabili.
Quattro distinzioni reggono tutto il resto del ragionamento.
- Policy scritta contro controllo eseguito. Un documento approvato dimostra un'intenzione. Un log, un ticket, un export di configurazione con data e autore dimostrano un'esecuzione.
- Eccezione autorizzata e a tempo, non conformità, incidente di sicurezza o privacy. Sono tre stati diversi, con tre percorsi diversi: deroga motivata con scadenza, scostamento rilevato da un controllo, evento con impatto e notifica.
- Software e automazione contro responsabilità umana. Uno strumento raccoglie, versiona e collega evidenze. Non decide la conformità, non assume il rischio e non firma al posto di nessuno.
- Organizzazione operativa contro consulenza legale. Il presidio interno governa ruoli, prove e scadenze. L'interpretazione delle clausole e delle basi giuridiche resta a chi ha la competenza per farlo.
Su quest'ultimo punto vale una precisazione che riguarda gli strumenti, non le intenzioni: AuditReady non promette governance automatica, compliance magica o responsabilità delegate al software.
Catena di riferimento: requisito, controllo, owner, evidenza datata, audit trail, finding, rimedio.
Inventario dei casi d'uso e soglie per la DPIA
L'inventario è il punto di partenza perché è l'unico registro che risponde alla domanda "dove sta l'IA dentro i nostri trattamenti". I cinque casi ricorrenti nelle organizzazioni italiane si somigliano abbastanza da poter essere schemati.
| Caso d'uso | Dati coinvolti | Obblighi o verifiche principali |
|---|---|---|
| Assistente generativo con dati aziendali nei prompt | Dati di clienti e dipendenti inseriti dagli utenti | Politica di inserimento, log dei prompt, valutazione del fornitore |
| Addestramento su dati raccolti online | Dati personali pubblici di terzi | Base giuridica, finalità, minimizzazione, valutazione DPIA |
| Generazione di contenuti con voce o immagine di terzi | Dati biometrici o identificativi | Base giuridica, autorizzazioni, controlli contro l'uso non autorizzato |
| Monitoraggio di lavoratori con strumenti IA | Dati comportamentali e di prestazione | Necessità, proporzionalità, trasparenza verso i lavoratori |
| Servizio con infrastruttura fuori dall'UE | Dati di account, input e log | Mappatura dei trasferimenti e garanzie contrattuali |
Per ogni sistema la scheda dovrebbe riportare finalità, categorie di dati, base giuridica, ruoli privacy, fornitori, trasferimenti, tempi di conservazione e misure di minimizzazione, secondo l'impostazione che il Garante collega esplicitamente all'art. 25 GDPR. La valutazione non si ferma al modello. Dati eccedenti inseriti nei prompt finiscono nei log del fornitore e possono influenzare risposte successive, quindi vanno verificati anche dataset e interfacce.
Sul fronte dei dati raccolti online esiste un'indicazione dedicata: il Garante ha pubblicato precisazioni sul web scraping per l'addestramento dei sistemi generativi, ricordando che la disponibilità pubblica di un dato non equivale automaticamente alla libertà di riutilizzarlo per qualsiasi finalità. Chi usa dataset di terzi deve poter esibire origine dei dati, categorie di interessati, finalità e misure per l'esercizio dei diritti.
Il caso del monitoraggio dei lavoratori merita una riga a sé. Il Garante ha vietato ad Amazon Italia Logistica il trattamento dei dati personali di oltre 1.800 lavoratori, richiamando i criteri di necessità, proporzionalità e trasparenza. Un limite analogo vale per qualsiasi strumento di analisi delle performance che osservi persone e non processi.
Due piani distinti, due serie di prove
Il Regolamento (UE) 2024/1689 classifica i sistemi e assegna obblighi a fornitore e utilizzatore. Il GDPR governa liceità, informativa, minimizzazione, sicurezza e diritti degli interessati. Sono piani collegati ma non sovrapponibili, e la confusione tra i due produce una lacuna tipica: dichiarare un sistema "conforme all'AI Act" senza poter mostrare la base giuridica del trattamento o l'adeguatezza dell'informativa. Nel registro dei trattamenti e nella DPIA i due piani vanno riportati entrambi, con evidenze separate e con date.
La DPIA si attiva quando il trattamento presenta rischi elevati: profilazione sistematica, uso di dati sensibili, monitoraggio su larga scala. Rischi, controlli, decisioni e prove vanno collegati a responsabili, scadenze ed evidenze verificabili.
Chi deve allargare lo sguardo dal singolo caso d'uso al perimetro complessivo può partire dalla nostra analisi dei rischi dell'intelligenza artificiale.
Ruoli, flusso e prove minime per ogni fase
La separazione dei compiti non è un formalismo. Se chi propone l'uso dello strumento è anche chi ne verifica l'esito, l'auditor non ha bisogno di cercare altro: ha già il finding. Il flusso minimo, dalla proposta alla verifica, è questo.
| Fase o controllo | Decisione o responsabilità | Evidenza minima verificabile |
|---|---|---|
| Inventario del sistema IA | Proposta del responsabile di processo, verifica del DPO | Scheda con finalità, owner e stato datata |
| Valutazione preliminare e DPIA | Decisione del DPO, firma del titolare o del responsabile | Versione della DPIA con rischi, misure e data di approvazione |
| Approvazione del fornitore | Decisione del responsabile IT o sicurezza con parere privacy | Questionario compilato e clausole contrattuali archiviate |
| Configurazione e minimizzazione | Esecuzione IT, verifica del security manager | Export datato della configurazione e log delle modifiche |
| Uso operativo | Utenti autorizzati, supervisione umana per decisioni rilevanti | Registro degli accessi e campione di output classificati |
| Richieste degli interessati | Responsabile privacy con termini di risposta | Ticket con data di ricezione, esito e prova di esecuzione |
| Incidenti e non conformità | Owner dell'incidente, escalation al DPO | Registro con classificazione, timeline e chiusura verificata |
| Revisione periodica | Internal auditor o OdV, con sign-off del titolare del rischio | Verbale di revisione con evidenze campionate |
Sei passaggi, sei errori tipici
- Proposta motivata. Il responsabile di processo descrive finalità, dati coinvolti e fornitore, e la proposta viene protocollata. L'errore ricorrente è la proposta a voce in riunione: esiste nella memoria dei presenti, non nel fascicolo.
- Valutazione preliminare e decisione del DPO sulla necessità della DPIA. Serve una risposta scritta, anche quando è negativa. L'errore è avviare la DPIA dopo l'attivazione, trasformandola in una ratifica.
- Approvazione del titolare o del responsabile di processo, datata e precedente all'avvio. La data è la prova. L'errore è l'approvazione firmata quando il pilota gira già da tre settimane.
- Configurazione con minimizzazione, controllo degli accessi e registrazione delle modifiche. Pseudonimizzazione prima dell'invio, segregazione tra ambienti, divieto di dati particolari salvo necessità documentata. L'errore è accettare i default del fornitore senza esportarli e datarli.
- Uso monitorato con log e campionamento degli output. Il campione dice come lo strumento viene usato davvero. L'errore è non campionare mai e scoprire l'uso improprio solo dal reclamo di un interessato.
- Revisione periodica con verbale e finding. Serve un verbale con evidenze citate, non un riassunto. L'errore è far coincidere proponente e verificatore.
Per i sistemi che trattano voce o immagine di terzi la documentazione va costruita prima dell'adozione. Il Garante richiama i considerando 78 e l'art. 25 GDPR e avverte che il trattamento di voce o immagine di soggetti terzi può configurare una violazione degli articoli 5 e 6: servono caso d'uso, categorie di dati biometrici o identificativi coinvolte, base giuridica, necessità, limiti di conservazione, autorizzazioni e controlli contro l'uso non autorizzato di contenuti altrui. La prova non è la policy: sono valutazione del fornitore, configurazioni privacy-by-default, test, log degli accessi e gestione degli incidenti, con il DPO coinvolto quando il trattamento rientra nel suo perimetro.
Chi deve decidere quali documenti entrano nel fascicolo di queste fasi può usare la nostra guida su quali evidenze includere in un assessment privacy.
L'owner resta una persona nominata. Il sistema registra decisioni, versioni e scadenze, e questo è utile esattamente perché nessuno ricostruisce a memoria. La firma, però, resta umana.
Fornitori IA, trasferimenti e prove dei subfornitori
Nel febbraio 2025 il Garante ha adottato una misura urgente nei confronti di Hangzhou DeepSeek Artificial Intelligence e Beijing DeepSeek Artificial Intelligence, limitando con effetto immediato il trattamento dei dati degli utenti italiani da parte del chatbot DeepSeek. L'Autorità ha chiesto chiarimenti su quali dati personali fossero raccolti, sulle fonti utilizzate, sulle finalità, sulla base giuridica e sull'eventuale conservazione su server situati in Cina, in un contesto in cui il fornitore contestava l'applicabilità della normativa europea o sosteneva di non operare direttamente nel Paese.
Due elementi contano per chi acquista strumenti generativi. Il primo: l'intervento è arrivato prima di una sanzione definitiva, quindi il rischio non è solo economico, è di sospensione dell'operatività. Il secondo: la verifica riguardava dati di prompt, log, account, addestramento, subfornitori e localizzazione dell'infrastruttura, non la qualità delle risposte del modello.
Un fornitore va valutato per ciò che fa con i dati, non per ciò che dichiara in una brochure.
| Area | Evidenza da richiedere | Verifica nel tempo |
|---|---|---|
| Localizzazione e trasferimenti | Mappa dei server e clausole di trasferimento | All'onboarding, al rinnovo e a ogni cambio di infrastruttura |
| Conservazione di input e log | Tempi di retention e modalità di cancellazione | Revisione annuale e a ogni audit |
| Uso dei dati per addestramento | Dichiarazione contrattuale e configurazione disponibile | All'onboarding e a ogni aggiornamento dei termini |
| Subfornitori | Elenco aggiornato con ruolo e localizzazione | Trimestrale o al cambio di subfornitore |
| Gestione delle opposizioni | Procedura e tempi di propagazione | Test a campione |
| Notifica di incidenti | Termini contrattuali e contatti dedicati | Test annuale della catena di notifica |
La differenza che conta è tra dichiarazione contrattuale e configurazione verificata. Una clausola che esclude l'uso degli input per l'addestramento è necessaria e non sufficiente: accanto serve l'export datato dell'impostazione, con identificativo del tenant, versione del prodotto e autore della verifica. Vale per la retention, per l'accesso dei subfornitori e per la propagazione di un'opposizione.
La richiesta al fornitore, poi, va gestita come una pratica e non come uno scambio di email. Un canale tracciato, un termine di risposta dichiarato, un archivio con la versione del documento ricevuto e la data in cui è stato caricato. Se il fornitore risponde con una presentazione commerciale, la richiesta è ancora aperta.
Il parere legale resta necessario per negoziare clausole e valutare i trasferimenti. Il controllo operativo, cioè verificare che quanto promesso sia configurato e documentato, resta in carico al responsabile del fornitore, che ne risponde all'interno dell'organizzazione.
Per strutturare la richiesta in modo ripetibile c'è un modello pronto: questionario di qualifica fornitori.
Registri, eccezioni e campi minimi di audit
Un registro è verificabile solo se ogni record contiene gli stessi campi, compilati e datati. La variabilità è ciò che rende un registro inutile in sede di verifica, perché costringe l'auditor a interpretare invece di leggere.
I campi minimi, validi per un registro DPIA come per un registro finding o incidenti, sono questi.
- Identificativo univoco e stabile nel tempo.
- Owner, una persona nominata, non una funzione.
- Processo o asset coinvolto, collegato al sistema IA.
- Rischio inerente e rischio residuo, valutati prima e dopo i controlli.
- Controlli compensativi attivi, con la data in cui sono stati verificati.
- Data di apertura e scadenza, entrambe esplicite.
- Stato aggiornato, non dedotto dal contesto.
- Evidenza di chiusura allegata al record.
- Approvazione di chiusura firmata da un soggetto diverso dall'owner.
Eccezione, non conformità, incidente
Un'eccezione autorizzata è una deroga consapevole: ha motivazione scritta, controlli compensativi e una scadenza. Non si rinnova per inerzia. Ogni proroga richiede una nuova approvazione motivata e una nuova valutazione del rischio residuo, altrimenti diventa una non conformità travestita.
Una non conformità è uno scostamento rilevato da un controllo o da un audit, e vive dentro un piano di rimedio con responsabile e data. Un incidente ha una propria timeline e un proprio obbligo di notifica: non è la stessa cosa, e trattarlo come tale confonde sia il registro sia l'escalation.
Sul contenuto dei registri vale la separazione tra i due piani normativi. L'EU AI Act è il riferimento per classificare e governare i sistemi, ma non sostituisce il GDPR: il registro interno dovrebbe conservare finalità, modello o fornitore, dati utilizzati, ruolo dell'organizzazione, utenti autorizzati, supervisione umana, output rilevanti, incidenti e decisioni di remediation.
Nella fase di validazione AuditReady separa ciò che è pronto, ciò che manca e ciò che richiede intervento umano. È una distinzione pratica: un registro con soli titoli delle DPIA risulta "presente" in una scansione di cartelle e assente in un audit, perché mancano versione, data di approvazione, rischi valutati e firma. Lo stesso registro con quei campi compilati supera il campione senza discussioni.
Output, richieste degli interessati e incidenti
Un dipendente copia un output dell'assistente in un ticket di assistenza, in una valutazione delle performance o in una cartella condivisa. Il problema non è il testo: è l'assenza di un passaggio che colleghi quell'output all'uso reale che ne è stato fatto.
Classificare gli output in quattro categorie aiuta più di qualsiasi policy discorsiva: dati personali, dati particolari, informazioni lavorative, inferenze su persone. Quando un output alimenta una decisione su una persona servono un'approvazione umana prima dell'uso, una data di conservazione e un responsabile che ne risponde.
Il diritto di opposizione non è un'informativa: è una richiesta da ricevere, verificare, valutare e tracciare con esito e tempi. Il Garante ha riconosciuto questo diritto agli utenti di Facebook e Instagram e anche ai non utenti i cui dati compaiono sulle piattaforme perché pubblicati da altri, il che esclude che la gestione possa limitarsi ai soli account aziendali.
Quando un incidente coinvolge output o dati personali, il responsabile del processo apre la segnalazione, il DPO valuta la gravità e il titolare decide sulla notifica, che di norma va effettuata entro 72 ore dalla conoscenza della violazione secondo l'art. 33 GDPR, con motivazione documentata se il termine non viene rispettato. La timeline con data di rilevazione, contenimento e decisione di notifica è la prima cosa che l'auditor guarda.
Errori comuni che indeboliscono l'audit
L'errore più frequente non è documentale, è cronologico: la firma arriva dopo l'avvio. L'auditor lo vede subito, perché confronta la data di attivazione dello strumento con la data dell'approvazione.
- Approvazioni retroattive. Correzione: firma datata prima dell'avvio, con la proposta e la valutazione che la precedono.
- Eccezioni rinnovate senza fine. Correzione: scadenza obbligatoria e nuova analisi del rischio a ogni proroga.
- Evidenze sparse tra email, chat e cartelle personali. Correzione: un repository unico per caso, con i documenti collegati alla fase.
- Finding chiusi senza verifica indipendente. Correzione: firma del verificatore distinta da quella dell'owner.
- Screenshot senza timestamp, sistema e versione. Correzione: metadati su ogni evidenza, con autore e identificativo dell'ambiente.
- Policy aggiornate senza numero di versione e data di entrata in vigore. Correzione: versione e data su ogni documento, così da dimostrare quale testo era vigente al momento del fatto.
Nessuno di questi controlli si fa rileggendo la policy. Si fa campionando un caso reale e chiedendo al team di esibirlo senza ricostruzioni.
Domande frequenti sui casi limite
Un dipendente copia un output dell'assistente in una valutazione delle performance. Chi apre l'incidente? Il responsabile del processo, che classifica l'output, valuta l'impatto sulla persona e attiva l'escalation al DPO secondo i tempi interni. La prova è il ticket con data di apertura e valutazione.
Il fornitore dichiara di non addestrare i modelli sui dati del cliente. Basta come prova? No. Servono la clausola contrattuale e una configurazione verificata, esportata e datata, con l'indicazione del tenant e della versione del prodotto.
Quando un'eccezione diventa una non conformità? Alla scadenza senza rimedio, oppure al primo rinnovo non motivato. Da quel momento il record cambia natura e va trattato con un piano di rimedio.
Chi firma la valutazione di un sistema IA ad alto impatto? Un responsabile umano nominato, mai lo strumento. Il software organizza evidenze e scadenze, la valutazione resta un atto della persona.
Ogni risposta rimanda a un record campionabile: il ticket, la clausola, la scadenza, la firma.
Verificare la prontezza prima del prossimo audit
Scegliete un controllo, non l'intero sistema, e applicate queste sei domande. Se una risposta è "dipende da chi lo ha gestito", la risposta è no.
- Ogni sistema IA ha owner, finalità e stato nell'inventario, con data di ultimo aggiornamento?
- Ogni uso ad alto impatto ha una DPIA approvata prima dell'avvio, con numero di versione?
- Le evidenze del controllo campionato si trovano senza ricostruzione, con data e autore?
- Le eccezioni hanno scadenza, controlli compensativi e un'approvazione distinta da chi le ha proposte?
- Ogni finding chiuso ha un'evidenza verificata da un soggetto diverso dall'owner?
- Le richieste degli interessati e le opposizioni hanno esito e tempi tracciati?
Il flusso più utile su cui esercitarsi è la gestione delle richieste degli interessati, perché attraversa ufficio legale, IT, risorse umane e fornitori. Una simulazione con un auditor interno, su un campione di dieci richieste, mostra in mezza giornata dove la catena si interrompe.
La prontezza non è un adempimento da chiudere una volta. È una verifica continua, che invecchia come invecchiano i log e le configurazioni.
Il primo contatto con Devisia riguarda fatti, vincoli, responsabilità e criteri di accettazione, senza imporre uno stack tecnologico o un fornitore. Nessuno strumento, incluso il nostro, certifica la conformità o sostituisce una valutazione professionale.
AuditReady riunisce in un unico ambiente i sistemi di IA con finalità, owner, stato del ciclo di vita e classificazione del rischio, accanto ai registri privacy, ai controlli, ai finding e alle evidenze versionate con integrità SHA-256 e audit trail immutabile. I fornitori possono inviare la documentazione tramite collegamenti sicuri con scadenza, senza creare un account, e l'Audit Day Pack esporta il pacchetto ordinato per la revisione. Puoi vedere come funziona nella demo di AuditReady, con i tuoi casi d'uso e senza impegno.