Elena Colombo | DPO/RPD — Advisor in Governance, Privacy & Compliance | UNI CEI EN 17740:2024, CIPP/E, CDPSE (ISACA) | I&P Partners, Milano
Un errore algoritmico è una violazione di dati personali quando compromette una proprietà di sicurezza dei dati: dati alterati, distrutti o resi accessibili a chi non doveva vederli. Non lo è quando il sistema funziona come progettato e produce un risultato inesatto: quello è un problema di esattezza, non di sicurezza. La distinzione decide se decorrono settantadue ore.
IN SINTESI
— La definizione di violazione dei dati personali (art. 4, punto 12, del Regolamento (UE) 2016/679 — GDPR) copre anche la distruzione, la perdita e la modifica accidentali. Non serve un attacco, e non serve un’esfiltrazione.
— Il criterio che separa il bug notificabile dall’errore di merito è se il malfunzionamento ha compromesso integrità, riservatezza o disponibilità dei dati.
— Un modello che funziona ma prevede male è un problema di esattezza (art. 5, par. 1, lett. d). Un modello che scrive il valore sbagliato nell’anagrafica è una violazione di integrità.
— Le settantadue ore decorrono dalla consapevolezza. L’ampiezza della violazione, però, retrocede alla data in cui il difetto è entrato in produzione.
— Il punto di rottura organizzativo è il triage: un difetto software entra nel sistema di ticketing come bug, non come incidente, e non raggiunge il DPO.
Che cosa è, esattamente, una violazione di dati personali?
L’articolo 4, punto 12, del GDPR definisce la violazione dei dati personali come una violazione di sicurezza che comporta accidentalmente o in modo illecito la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l’accesso ai dati personali trattati. Due parole reggono l’intera portata della norma: modifica e accidentalmente.
Nella pratica professionale la violazione viene associata quasi sempre a un’uscita di dati — un’esfiltrazione, un invio errato, un archivio esposto. È solo una delle tre categorie. Le linee guida EDPB 9/2022 sulla notifica delle violazioni di dati personali (versione 2.0, adottata il 28 marzo 2023, aggiornamento delle precedenti WP250 rev.01) le distinguono in violazioni di riservatezza, di integrità e di disponibilità, e osservano che la seconda e la terza sono strutturalmente meno riconoscibili della prima.
Un algoritmo difettoso opera quasi sempre sulle due categorie meno riconosciute. Non fa uscire nulla. Modifica, oppure cancella.
Un algoritmo che sbaglia produce una violazione di dati personali?
Dipende da che cosa ha ceduto. La variabile che decide è se l’errore ha compromesso una proprietà di sicurezza del trattamento — integrità, riservatezza, disponibilità — oppure ha prodotto un contenuto sbagliato mentre il sistema funzionava come previsto.
Il confine ha un fondamento testuale preciso. L’articolo 4, punto 12, qualifica la violazione come violazione di sicurezza: rimanda quindi alle proprietà che l’articolo 5, paragrafo 1, lettera f) e l’articolo 32 impongono di garantire. L’esattezza del dato sta altrove, nella lettera d) del medesimo articolo 5, ed è un principio autonomo. Sono due obblighi distinti, con conseguenze procedurali distinte: la violazione dell’uno apre le settantadue ore, la violazione dell’altro apre un piano di rettifica.
La formulazione operativa è questa: il sistema ha fatto quello che doveva fare, male? Oppure ha fatto qualcosa che non doveva fare? Nel primo caso si discute di qualità del trattamento. Nel secondo si apre un incidente.
Quali malfunzionamenti algoritmici sono quasi sempre una violazione?
Cinque famiglie ricorrono nella pratica, e nessuna di esse assomiglia a un data breach nell’immaginario corrente.
— Riconciliazione e deduplica. Una routine di matching che fonde i record di due persone omonime produce, per entrambe, dati alterati e la disponibilità dei dati dell’una all’interno del profilo dell’altra. È simultaneamente violazione di integrità e di riservatezza.
— Automazione della conservazione. Una procedura di cancellazione che seleziona la coorte sbagliata distrugge dati che dovevano restare. La perdita definitiva è il caso da manuale di violazione di disponibilità, e nasce da uno strumento che l’organizzazione considera un presidio di conformità.
— Regole di autorizzazione. Quando il difetto sta nella logica che decide chi vede che cosa, l’algoritmo non è il trattamento: è la misura di sicurezza. Un errore in quella logica è una violazione di riservatezza per definizione.
— Pseudonimizzazione e mascheramento. Una routine che non produce l’effetto atteso lascia identificabili dati che l’organizzazione tratta come non identificabili, in ambienti — test, analytics, addestramento — dove il perimetro di accesso è stato dimensionato su quel presupposto.
— Automazioni di invio e generazione documentale. Un’associazione errata tra destinatario e contenuto recapita il documento della persona sbagliata alla persona sbagliata, in serie e senza che nessuno se ne accorga finché qualcuno non reclama.
L’elemento comune è la scala. Un errore umano riguarda un caso; un difetto algoritmico riguarda tutti i casi trattati da quando è entrato in produzione. La sistematicità che rende efficiente l’automazione rende sistematico anche il suo errore.
Quando invece si resta nel campo dell’esattezza?
Quando il sistema opera secondo la propria specifica e il difetto sta nella specifica. Un modello di scoring con performance predittiva scadente classifica male, ma classifica come è stato costruito per fare: i dati di input sono integri, quelli di output riflettono la logica adottata, nessuna proprietà di sicurezza è stata compromessa.
Il caso non è innocuo — apre questioni di esattezza, di correttezza, e se produce effetti significativi sulle persone anche di legittimità della decisione automatizzata — ma non apre le settantadue ore. Confondere i due piani ha due esiti opposti, entrambi costosi: si notificano difetti di qualità che l’autorità non si aspetta di ricevere, oppure si archiviano come bug violazioni che andavano notificate.
Resta una zona non risolta, e vale la pena dichiararla invece di aggirarla: il modello addestrato su un set di dati corrotto. Il sistema funziona secondo specifica, ma la specifica è stata contaminata a monte da un’alterazione dei dati. Ritengo che vada trattato come violazione, perché l’integrità è stata compromessa nel dataset prima ancora che nel comportamento del modello. È una posizione argomentata, non una lettura pacifica.
Da quando decorrono le settantadue ore se l’errore è algoritmico?
Dal momento in cui il titolare raggiunge un ragionevole grado di certezza che una violazione si sia verificata. È il criterio di consapevolezza che l’EDPB adotta nelle linee guida 9/2022, e non coincide con il momento in cui il difetto è entrato nel codice.
La conseguenza operativa è asimmetrica, e conviene averla chiara prima di trovarcisi dentro. Il termine decorre in avanti dalla scoperta; il perimetro della violazione retrocede indietro fino al rilascio del difetto. Significa che nelle stesse settantadue ore in cui si prepara la notifica bisogna anche ricostruire da quale versione il difetto è attivo, quanti interessati ha toccato e quali dati ha modificato.
Questa ricostruzione dipende interamente da presidi che stanno fuori dal perimetro privacy: versionamento del codice, tracciabilità dei rilasci, log applicativi conservati per un tempo sufficiente, storicizzazione dei valori modificati. Un’organizzazione che non versiona i propri modelli non è in grado di delimitare la violazione. E una violazione che non si sa delimitare va notificata per l’intera popolazione potenzialmente interessata.
Chi si accorge che un bug è una violazione di dati?
Nella maggior parte delle organizzazioni, nessuno. Non per negligenza: per instradamento. Un difetto software viene rilevato dall’esercizio o segnalato dagli utenti, entra nel sistema di ticketing con una classificazione tecnica, viene assegnato a uno sviluppatore, corretto e chiuso. Il flusso è corretto sotto il profilo della gestione dei servizi ed è cieco sotto il profilo della protezione dei dati.
Il registro delle violazioni si alimenta da un canale diverso — segnalazioni di sicurezza, reclami, incidenti dichiarati — che non intercetta il ticket. Il risultato è un difetto documentato, corretto, tracciato e mai valutato ai sensi dell’articolo 33.
La correzione è una regola di instradamento, non una procedura nuova: quali classificazioni di difetto attivano automaticamente una valutazione privacy. Una regola difendibile parte dai difetti che comportano modifica non voluta di dati, cancellazione non prevista, visibilità a soggetti non abilitati o malfunzionamento di una componente di sicurezza. Chi la scrive deve conoscere il modello di classificazione del ticketing aziendale, non il GDPR: è il motivo per cui questa regola viene scritta con l’esercizio IT e non nella funzione privacy.
Che cosa cambia se il sistema è di intelligenza artificiale?
Cambia che le catene di segnalazione possono diventare due, e non sono alternative. Il Regolamento (UE) 2024/1689 — AI Act — prevede all’articolo 26, paragrafo 5, che il deployer che individui un incidente grave ne informi immediatamente il fornitore e, a seguire, l’importatore o il distributore e le autorità di vigilanza del mercato; se il fornitore non è raggiungibile, si applica in quanto compatibile l’articolo 73, che disciplina la comunicazione degli incidenti gravi.
I due regimi non si sovrappongono. Presupposti diversi: il GDPR guarda alla compromissione dei dati personali, l’AI Act alla gravità delle conseguenze dell’incidente. Destinatari diversi: il Garante da un lato, il fornitore e le autorità di vigilanza del mercato dall’altro. Un malfunzionamento può essere incidente grave senza essere violazione di dati, e viceversa. Chi tiene un solo registro, e una sola procedura, ne mancherà uno dei due.
Obiezione: così qualunque bug diventa un data breach
È l’obiezione che sento più spesso, ed è fondata nella preoccupazione, non nella conseguenza. Qualificare un difetto come violazione non significa notificarlo. L’articolo 33 esclude la notifica quando è improbabile che la violazione presenti un rischio per i diritti e le libertà delle persone fisiche: un difetto che ha alterato un campo non significativo su pochi record, corretto prima di produrre effetti, resta al di sotto della soglia.
Quello che non si può fare è saltare la valutazione. Il paragrafo 5 dello stesso articolo impone di documentare tutte le violazioni, comprese quelle non notificate, con le circostanze e le motivazioni della scelta. La distinzione reale non è tra bug che si notificano e bug che si ignorano: è tra bug che vengono valutati e bug che nessuno ha mai guardato con quella domanda in mente.
Va aggiunto, per onestà, che questo aumenta il carico. Instradare i difetti verso una valutazione privacy produce lavoro che oggi non viene fatto, e produrrà registrazioni che quasi sempre si concluderanno con una non notifica motivata. È il costo della differenza tra un’organizzazione che può dimostrare di aver valutato e una che può solo dimostrare di non aver visto.
La verifica da fare
Tre domande, rispondibili in una riunione con l’esercizio IT.
— Nella classificazione dei difetti in uso oggi, esiste una categoria — una qualsiasi — la cui apertura genera una notifica al DPO? Se non esiste, il registro delle violazioni non può essere completo, qualunque sia il suo contenuto.
— Per quanto tempo si conservano i log applicativi e la storicizzazione dei valori modificati dai processi automatici? Quel numero è il limite entro cui l’organizzazione riesce a delimitare una violazione retroattiva. Oltre quel limite non c’è ricostruzione, c’è stima.
— Guardando gli ultimi dodici mesi di difetti chiusi, quanti riguardavano modifica non voluta, cancellazione non prevista o visibilità impropria di dati? Quanti di questi compaiono nel registro delle violazioni? Se la seconda cifra è zero e la prima no, la risposta è già arrivata.
La domanda che chiude non riguarda la conformità del sistema. Riguarda chi, nella propria organizzazione, ha il compito di guardare un ticket tecnico e chiedersi se descriva una violazione di dati personali — e se quella persona esiste davvero o è solo prevista.
I&P Partners affianca titolari pubblici e privati nella definizione delle regole di instradamento tra gestione degli incidenti tecnici e valutazione delle violazioni di dati personali, e nella tenuta del relativo registro.
