Dismissione dei sistemi di IA: gli orologi di conservazione non si fermano quando si spegne il sistema

Spegnere un sistema di IA non chiude il trattamento dei dati. L’AI Act ancora i termini di conservazione all’immissione sul mercato o alla messa in servizio, non alla dismissione: dieci anni per la documentazione tecnica del fornitore, almeno sei mesi per i log del deployer. Il GDPR li ancora alla finalità, che con lo spegnimento cessa.

In sintesi

• L’art. 18 del regolamento (UE) 2024/1689 (AI Act) impone al fornitore di tenere a disposizione delle autorità nazionali competenti la documentazione tecnica per dieci anni dall’immissione sul mercato o dalla messa in servizio del sistema.
• Gli artt. 19 e 26, par. 6, fissano per i log generati automaticamente un periodo adeguato alla finalità prevista del sistema e comunque non inferiore a sei mesi, rispettivamente in capo al fornitore e al deployer.
• Nessuno di questi termini decorre dalla dismissione: decorrono dall’ingresso del sistema nel mercato o nel servizio.
• Il principio di limitazione della conservazione (art. 5, par. 1, lett. e, GDPR) lavora nella direzione opposta: lega la durata alla finalità, che con la dismissione si esaurisce.
• Il regolamento (UE) 2026/1744 ha spostato le date di applicazione degli obblighi sui sistemi ad alto rischio, ma non ha modificato gli artt. 18, 19 e 26. L’architettura della conservazione è rimasta quella.
• Il punto in cui i due orologi vanno conciliati è l’atto di dismissione. Nella prassi quell’atto non esiste: esiste un ticket.

Cosa resta attivo quando un sistema di IA viene spento?

Restano tre cose che nessuno ha deciso di spegnere: i set di dati usati per addestrare, convalidare e provare il modello; i log prodotti durante l’esercizio; le credenziali tecniche che collegavano il sistema al resto dell’infrastruttura. Lo spegnimento agisce sull’interfaccia. Il trattamento, in senso giuridico, prosegue: conservare è trattare, per definizione dell’art. 4, punto 2, del regolamento (UE) 2016/679 (GDPR).

Da qui nasce l’errore più costoso. L’organizzazione considera chiusa la partita perché il sistema non produce più output, mentre il registro delle attività di trattamento resta fermo alla configurazione originaria, il responsabile della protezione dei dati non è stato informato della cessazione, e i dati residui non hanno più una finalità che li giustifichi.

Per quanto tempo vanno conservati log e documentazione dopo la dismissione?

Qui sta lo snodo, e conviene esplicitarlo con gli estremi esatti.

Il regolamento (UE) 2024/1689 (AI Act) fissa due termini per i sistemi di IA ad alto rischio:

• art. 18 – il fornitore tiene a disposizione delle autorità nazionali competenti la documentazione tecnica di cui all’art. 11, la documentazione relativa al sistema di gestione della qualità di cui all’art. 17, le decisioni e i documenti degli organismi notificati e la dichiarazione di conformità UE di cui all’art. 47, per un periodo di dieci anni successivo alla data di immissione sul mercato o di messa in servizio del sistema;
• artt. 19 e 26, par. 6 – fornitore e deployer conservano i log generati automaticamente dal sistema, nella misura in cui sono sotto il loro controllo, per un periodo adeguato alla finalità prevista del sistema e comunque non inferiore a sei mesi.

Il punto non è la durata. È il dies a quo. Nessuno dei due termini è agganciato allo spegnimento: decorrono dall’ingresso del sistema nel mercato o nel servizio. Un sistema messo in servizio nel 2028 e dismesso nel 2030 lascia in capo al fornitore un obbligo documentale che arriva al 2038, otto anni dopo che l’ultimo utente ha smesso di usarlo.

Il GDPR ragiona all’inverso. Il principio di limitazione della conservazione (art. 5, par. 1, lett. e) lega la durata alla finalità: esaurita la finalità, la conservazione perde giustificazione. E la dismissione è precisamente il momento in cui la finalità originaria si esaurisce.

Due orologi che girano in direzioni opposte sullo stesso perimetro tecnico. Nessuna norma dice a chi tocchi conciliarli. Nei fatti tocca al titolare del trattamento, e il momento in cui deve farlo è uno solo: la dismissione.

Il rinvio del Digital Omnibus sposta anche questo problema?

No. Il regolamento (UE) 2026/1744, pubblicato nella Gazzetta ufficiale dell’Unione europea del 24 luglio 2026, ha spostato l’entrata in applicazione del capo III, sezioni 1, 2 e 3 dell’AI Act: 2 dicembre 2027 per i sistemi classificati ad alto rischio ai sensi dell’art. 6, par. 2, e dell’allegato III; 2 agosto 2028 per quelli classificati ai sensi dell’art. 6, par. 1, e dell’allegato I. Ha inoltre modificato un numero consistente di disposizioni, fra cui l’art. 25 sui ruoli lungo la catena del valore e l’art. 27 sulla valutazione d’impatto sui diritti fondamentali.

Non ha toccato gli artt. 18, 19 e 26. L’architettura della conservazione è rimasta identica: il rinvio sposta la data in cui gli obblighi diventano esigibili, non la logica con cui i termini decorrono.

Ha però un effetto laterale che conviene mettere a fuoco. Allontanando la classificazione formale dei sistemi ad alto rischio, il rinvio rende probabile che molti dei sistemi sperimentali oggi in esercizio vengano dismessi prima ancora di essere stati classificati. Al GDPR, quella data non interessa: i dati di addestramento che restano nei bucket sono dati personali adesso, e la loro conservazione va giustificata adesso.

Non basta l’obbligo di legge come base giuridica per conservare?

È l’obiezione più solida a quanto precede, e va presa sul serio: se l’AI Act impone di conservare, la conservazione trova base giuridica nell’art. 6, par. 1, lett. c), GDPR – adempimento di un obbligo legale – e il conflitto fra i due orologi si dissolve da sé.

Regge, ma solo per ciò che l’AI Act impone effettivamente di conservare. Gli artt. 18 e 19 elencano documentazione tecnica, documentazione del sistema di gestione della qualità, dichiarazione di conformità e log generati automaticamente. Non elencano i set di addestramento, convalida e prova, che sono la parte più voluminosa e spesso più sensibile di ciò che sopravvive allo spegnimento. Per quei dati non c’è un obbligo di conservazione da invocare, e la finalità originaria è cessata.

C’è un secondo limite, meno intuitivo. L’obbligo legale non fonda soltanto la conservazione: ne determina anche il tetto. Se la base è l’art. 6, par. 1, lett. c), la conservazione è legittima nella misura e per la durata previste dalla norma che la impone. I sei mesi degli artt. 19 e 26, par. 6, sono un minimo agganciato alla finalità prevista del sistema, non un’autorizzazione a tempo indeterminato. Un deployer che tiene i log per anni senza una decisione documentata non sta adempiendo: sta eccedendo, e su una base giuridica che non lo copre.

Chi firma la dismissione, e cosa deve contenere l’atto?

Nella prassi la dismissione è un ticket. Non è un atto. La differenza conta: un ticket registra un’esecuzione tecnica, un atto registra una decisione e il suo autore.

A decidere è il titolare del trattamento, per il tramite della funzione che ha autorizzato l’adozione del sistema – non la funzione tecnica che esegue lo spegnimento. Se l’adozione è passata da una determina o da una delibera, la dismissione passa dallo stesso livello. È questa simmetria che rende l’atto difendibile davanti a chi, due anni dopo, chiede chi abbia deciso cosa.

Contenuto minimo dell’atto di dismissione:

1. Data di cessazione dell’uso e data di immissione sul mercato o di messa in servizio del sistema. La seconda è quella da cui decorrono i termini dell’AI Act: senza quel dato non si calcola nulla, e nella maggior parte dei progetti non è registrato da nessuna parte.
2. Inventario di ciò che sopravvive: set di addestramento, convalida e prova; log; output conservati; documentazione tecnica; copie presenti negli ambienti del fornitore e di eventuali sub-responsabili.
3. Per ciascuna voce, tre campi: destino (cancellazione, anonimizzazione, conservazione), termine, base giuridica residua. Dove la scelta è la conservazione, la motivazione va scritta; dove è la cancellazione, vanno indicati chi la esegue e come se ne dà evidenza.
4. Revoca degli accessi tecnici – chiavi API, utenze di servizio, integrazioni con le pipeline di gestione dei modelli – con evidenza dell’avvenuta revoca. È il punto in cui la dismissione tocca il perimetro della direttiva (UE) 2022/2555 (NIS2), recepita in Italia con il decreto legislativo 4 settembre 2024, n. 138: un’integrazione dimenticata resta superficie di attacco che nessuno monitora, proprio perché il sistema a cui apparteneva risulta chiuso.
5. Chiusura sul fornitore: cosa resta nei suoi ambienti, entro quando lo cancella, come lo attesta. Se il contratto non lo prevedeva, questo è il momento in cui la lacuna diventa visibile – ed è un’informazione utile per il capitolato successivo.
6. Aggiornamento del registro delle attività di trattamento (art. 30 GDPR) e comunicazione al responsabile della protezione dei dati.

Fra i sei, il campo che pesa di più è la base giuridica residua dei dati di addestramento. Nella maggior parte delle dismissioni resta vuoto, perché nessuno ha una risposta. Quel vuoto è già una risposta: significa che quei dati vanno cancellati.

La conseguenza

La domanda che chiude una dismissione non è se il sistema sia stato spento. È: da quale data decorrono i termini, chi ha deciso il destino di ciò che resta, e dove è scritto. Un’organizzazione che non sa rispondere non ha dismesso un sistema. Ha smesso di guardarlo.

Dott.ssa Martina Tosolini / DPO-RPD