Un sistema di IA non si governa soltanto mentre gira in produzione: si governa dalla prima idea fino al giorno in cui viene spento. È questo il senso della gestione del ciclo di vita dell’IA, e l’AI Act lo rende concreto, perché quasi ogni obbligo dei sistemi ad alto rischio si aggancia a una fase precisa. In questo articolo mettiamo in fila le fasi, gli obblighi che vi ricadono, i gate decisionali, il controllo delle modifiche e la dismissione, con le prove da conservare a ogni passaggio.
In sintesi
- La gestione del ciclo di vita dell’IA è una disciplina di governance: decide chi fa avanzare un sistema, su quali prove e che cosa si conserva. L’MLOps automatizza la pipeline, non decide.
- Nel testo inglese, l’AI Act usa «lifecycle» solo 11 volte, ma quasi ogni obbligo per l’alto rischio si lega a una fase.
- Una modifica sostanziale fa ripartire la valutazione della conformità e può trasformare il deployer in fornitore.
- Con l’Omnibus digitale, i sistemi ad alto rischio già sul mercato entrano nel perimetro solo dopo cambiamenti significativi di progettazione: il controllo delle modifiche fa da innesco.
- La dismissione è la fase che nessuno pianifica, eppure vi ricadono ritiro, banca dati dell’UE, conservazione decennale e cancellazione dei dati.
Gestione del ciclo di vita dell’IA: che cosa significa e che cosa lascia fuori l’MLOps
Per gestione del ciclo di vita dell’IA intendiamo il governo di un sistema di IA attraverso tutte le sue fasi: chi ne risponde, quali decisioni si prendono a ogni passaggio e su quali prove, come si trattano le modifiche, come si arriva alla dismissione. Le pagine meglio posizionate su questa ricerca, da IBM ad AWS fino alla guida della GSA statunitense, raccontano invece una pipeline ingegneristica: problema, dati, addestramento, valutazione, rilascio, monitoraggio. Persino la Panoramica AI di Google chiede infine al lettore se cerca strumenti MLOps o governance e conformità: manca proprio questa seconda metà. Abbiamo esaminato le dieci pagine leggibili in cima ai risultati: nessuna cita ISO/IEC 42001, ISO/IEC 5338, ISO/IEC 22989 o l’OCSE, nessuna parla di incidenti gravi, una sola cita un articolo dell’AI Act e due menzionano la dismissione.
L’MLOps automatizza: versiona i dati, riaddestra, distribuisce, misura. La gestione del ciclo di vita dell’IA decide: autorizza il passaggio di fase, documenta il perché, assegna un responsabile, stabilisce che cosa si conserva e per quanto. Una pipeline impeccabile può portare in produzione un modello che nessuno ha approvato per quella finalità. Il punto di partenza resta l’inventario dei sistemi di IA: ciò che non è censito non ha un ciclo di vita governato, ha soltanto una cronologia di rilasci.
L’articolo 9, paragrafo 2, dell’AI Act concepisce il sistema di gestione dei rischi come «un processo iterativo continuo pianificato ed eseguito nel corso dell’intero ciclo di vita di un sistema di IA ad alto rischio», soggetto a riesame e aggiornamento sistematici. L’articolo 15, paragrafo 1, vuole prestazioni costanti per tutto il ciclo di vita; l’allegato IV, punto 6, la descrizione delle modifiche pertinenti apportate dal fornitore; l’articolo 12, paragrafo 1, la registrazione automatica degli eventi per tutta la durata del sistema; l’articolo 72, paragrafo 2, dati sulle prestazioni lungo l’intera vita operativa. Eppure, nel testo inglese della Gazzetta ufficiale, «lifecycle» ricorre solo 11 volte: 7 nei considerando, 4 nell’articolato e negli allegati (articoli 9(2), 15(1), 40(2) e allegato IV, punto 6). Il termine è raro; gli obblighi che vi si appoggiano, no.
Le fasi: quattro modelli di riferimento a confronto
Per scandire il ciclo di vita dell’IA esistono più modelli, e non coincidono. Ecco il nostro modello di lavoro in otto fasi accanto a ISO/IEC 22989 (ripresa dal Garante europeo della protezione dei dati, GEPD), al NIST AI RMF (NIST AI 100-1), all’OCSE e all’allegato A.6.2 di ISO/IEC 42001.
| Fase (nostro modello) | ISO/IEC 22989 / GEPD | NIST AI RMF | OCSE | ISO/IEC 42001, allegato A.6.2 |
|---|---|---|---|---|
| Ideazione e finalità prevista | Ideazione e analisi | Plan and Design | Progettazione, dati e modelli | Requisiti e specifiche (A.6.2.2) |
| Acquisizione e preparazione dei dati | Acquisizione e preparazione dei dati | Collect and Process Data | Progettazione, dati e modelli | (i controlli sui dati sono in A.7) |
| Progettazione e sviluppo | Sviluppo | Build and Use Model | Progettazione, dati e modelli | Documentazione di progettazione e sviluppo (A.6.2.3) |
| Verifica e validazione | Verifica e validazione | Verify and Validate | Verifica e validazione | Verifica e validazione (A.6.2.4) |
| Rilascio | Rilascio | Deploy and Use | Rilascio | Rilascio (A.6.2.5) |
| Esercizio e monitoraggio | Esercizio e monitoraggio; validazione continua | Operate and Monitor | Esercizio e monitoraggio | Esercizio e monitoraggio (A.6.2.6); log degli eventi (A.6.2.8) |
| Rivalutazione e modifica | Rivalutazione | (TEVV lungo tutto il ciclo) | (iterativo, non sequenziale) | Documentazione tecnica mantenuta aggiornata (A.6.2.7) |
| Dismissione | Dismissione | (non è una fase a sé) | decisa durante esercizio e monitoraggio | (nessun controllo dedicato) |
ISO/IEC 5338:2023, pubblicata nel dicembre 2023 dal comitato JTC 1/SC 42, trasforma queste fasi in processi: parte dalle norme di ingegneria ISO/IEC/IEEE 15288 e 12207 e vi aggiunge processi specifici per l’IA tratti da ISO/IEC 22989 e ISO/IEC 23053, sia per chi sviluppa il sistema sia per chi lo acquisisce. Le somiglianze non sono casuali: la figura del NIST sulle fasi è adattata dal quadro di classificazione dell’OCSE. La nostra raccomandazione: scegliete un solo modello di lavoro e mappate gli altri su di esso. Un comitato che approva con lo schema NIST, un team che documenta con quello ISO e un revisore che verifica con quello dell’OCSE producono tre versioni dello stesso ciclo di vita dell’IA. Il raccordo tra norme tecniche e regolamento è nell’analisi su ISO 42001 e AI Act.
Il ciclo di vita dell’IA nell’AI Act: gli obblighi fase per fase
Per un sistema di IA ad alto rischio, il Regolamento (UE) 2024/1689 distribuisce gli obblighi lungo tutto il ciclo di vita dell’IA. Per ogni fase: che cosa chiede il testo, dove, e quali prove vorrà vedere un’autorità o un organismo notificato.
| Fase | Che cosa richiede l’AI Act | Articoli | Prove da conservare |
|---|---|---|---|
| Ideazione e finalità prevista | definire la finalità prevista, classificare, avviare la gestione dei rischi | Art. 3(12), 6, 9(1)-(2) | dichiarazione della finalità prevista, nota di classificazione, registro dei rischi aperto |
| Acquisizione e preparazione dei dati | governance dei dati di addestramento, convalida e prova | Art. 10; allegato IV, 2(d) | schede dei dataset, provenienza, verbale dell’esame dei bias |
| Progettazione e sviluppo | documentazione tecnica prima dell’immissione sul mercato; trasparenza e istruzioni per l’uso; sorveglianza umana fin dalla progettazione; accuratezza, solidità e cibersicurezza | Art. 11, 13, 14, 15; art. 17(1)(b)-(c) | fascicolo dell’allegato IV, istruzioni per l’uso, progetto della sorveglianza |
| Verifica e validazione | prove prima dell’immissione sul mercato rispetto a metriche definite; valutazione della conformità, dichiarazione, marcatura CE | Art. 9(6)-(8); art. 17(1)(d), 43, 47, 48 | rapporti di prova, fascicolo di conformità, dichiarazione di conformità UE |
| Rilascio | registrazione nella banca dati dell’UE prima dell’immissione sul mercato (sistemi dell’allegato III); obblighi del deployer; valutazione d’impatto sui diritti fondamentali per alcuni deployer | Art. 49, 26, 27 | prova della registrazione, checklist di rilascio, FRIA dove dovuta |
| Esercizio e monitoraggio | log per tutta la durata del sistema; monitoraggio successivo all’immissione sul mercato; monitoraggio e sospensione da parte del deployer; segnalazione degli incidenti gravi | Art. 12, 19, 26(5)-(6), 72, 73 | prova della conservazione dei log, piano e rapporti di monitoraggio, registro degli incidenti |
| Modifica | la modifica sostanziale impone una nuova valutazione della conformità; le modifiche predeterminate nell’allegato IV, 2(f), no; il deployer che modifica in modo sostanziale diventa fornitore | Art. 3(23), 43(4), 25(1); allegato IV, punto 6 | registro delle modifiche con decisione di triage, documentazione aggiornata |
| Dismissione | azioni correttive, ritiro, disattivazione o richiamo; documentazione conservata 10 anni; stato aggiornato nella banca dati | Art. 20, 18; allegato VIII, sezione A, punto 7 | verbale di dismissione, piano di conservazione, prova della cancellazione |
Sul calendario, il Regolamento (UE) 2026/1744, l’Omnibus digitale sull’IA, ha spostato gli obblighi per i sistemi ad alto rischio dell’allegato III al 2 dicembre 2027 e quelli per i prodotti dell’allegato I al 2 agosto 2028. Ha inoltre inserito il piano di monitoraggio nella documentazione tecnica dell’allegato IV, ha chiesto alla Commissione di adottare orientamenti, compreso un modello, entro il 2 settembre 2027 (nuovo articolo 72, paragrafo 3) e ha reso il sistema di gestione della qualità proporzionato alle dimensioni delle PMI e delle piccole imprese a media capitalizzazione (articolo 17, paragrafo 2). Il rinvio concede tempo, non cambia la mappa.
I gate del ciclo di vita dell’IA: chi decide e su quali prove
Un gate è il punto in cui il sistema si ferma finché qualcuno che ne ha l’autorità non decide, su prove documentate, che può proseguire. Per governare il ciclo di vita dell’IA ne bastano sei.
- <b>Ingresso.</b> Il sistema entra nell’inventario con un responsabile nominativo e una finalità prevista scritta. Senza questi due elementi non c’è nulla da approvare e il sistema resta nell’ombra.
- <b>Approvazione del progetto.</b> Classificazione, valutazione d’impatto e registro dei rischi aperto arrivano al comitato di governance dell’IA, che decide go o no-go. Un no-go motivato è una prova quanto un via libera.
- <b>Rilascio.</b> La validazione è superata rispetto a metriche fissate prima dei test, non dopo; la documentazione è completa e la sorveglianza umana è affidata a persone identificate. Per l’alto rischio, valutazione della conformità e registrazione nella banca dati dell’UE sono già concluse.
- <b>Triage delle modifiche.</b> Ogni modifica di modello, dati o finalità viene registrata e classificata come ordinaria, predeterminata o sostanziale. È il gate più frequente e quello che più spesso manca.
- <b>Rivalutazione periodica.</b> Almeno una volta l’anno, e dopo ogni incidente, si confrontano i risultati reali con i rischi identificati. Se divergono, il registro dei rischi si aggiorna e il sistema può tornare al gate 2.
- <b>Dismissione.</b> Decisione, notifica, archiviazione, cancellazione. Il sistema esce dall’inventario solo quando tutti e quattro i passaggi sono documentati.
Sui ruoli, la ripartizione che regge è semplice. Il responsabile di business porta il sistema e risponde della finalità; il comitato di governance dell’IA decide ai gate 2, 3 e 6; ufficio legale e DPO verificano base giuridica e protezione dei dati; la validazione dei modelli, o seconda linea, controlla le metriche secondo le logiche della gestione del rischio di modello; la sicurezza informatica valuta esposizione e accessi. AI Sigil modella i processi come fasi, con moduli e approvazioni per ciascuna fase, a partire dal registro dei sistemi di IA.
Controllo delle modifiche: quando un aggiornamento diventa una modifica sostanziale
È nelle modifiche che il ciclo di vita dell’IA diventa diritto. L’articolo 3, punto 23, definisce modifica sostanziale il cambiamento successivo all’immissione sul mercato o alla messa in servizio, non previsto né pianificato nella valutazione della conformità iniziale, che incide sulla conformità ai requisiti del capo III, sezione 2, o modifica la finalità prevista. In quel caso l’articolo 43, paragrafo 4, impone una nuova valutazione della conformità, sia che il sistema modificato venga ridistribuito, sia che resti in uso presso il deployer attuale. Per i sistemi che continuano ad apprendere vale un’eccezione: le modifiche predeterminate dal fornitore nella valutazione iniziale e descritte al punto 2, lettera f), dell’allegato IV non sono sostanziali.
La conseguenza più sottovalutata sta nell’articolo 25, paragrafo 1, lettere b) e c): chi modifica in modo sostanziale un sistema ad alto rischio, o cambia la finalità di un sistema che non lo era fino a renderlo tale, è considerato fornitore. Si aggiunge l’articolo 111, paragrafo 2, riscritto dall’Omnibus: un sistema ad alto rischio già sul mercato prima della data di applicazione del capo III rientra nel regolamento solo se, da quella data, subisce cambiamenti significativi nella progettazione. Un considerando precisa che il «cambiamento significativo» equivale nella sostanza alla modifica sostanziale. Il controllo delle modifiche diventa così il punto del ciclo di vita dell’IA che porta i sistemi esistenti dentro il perimetro; ogni decisione di triage va riportata nella documentazione del sistema e, se serve, nella model card.
La Commissione ha pubblicato il 19 maggio 2026 la bozza di linee guida sulla classificazione ad alto rischio (consultazione prorogata al 23 luglio 2026, testo definitivo entro la fine del 2026), mentre quelle sulla modifica sostanziale l’Ufficio per l’IA le sta ancora preparando. Il documento del CERRE di giugno 2026 sostiene che le modifiche ordinarie del ciclo di vita debbano di regola restare fuori da quel regime, in coerenza con l’articolo 43, paragrafo 4, e cita il fornitore che sostituisce il modello per finalità generali sottostante con una versione più recente. Fuori dall’UE, la guida definitiva della FDA del 4 dicembre 2024 sui piani di controllo delle modifiche predeterminati per le funzioni software dei dispositivi medici basate sull’IA divide il piano in tre parti, riutilizzabili per il piano dell’allegato IV, punto 2, lettera f): descrizione delle modifiche, protocollo di modifica, valutazione d’impatto (sintesi).
Le domande di triage
- La modifica altera la finalità prevista?
- Incide su un requisito del capo III, come accuratezza, solidità, sorveglianza umana o dati?
- Era predeterminata nella documentazione tecnica?
- Chi l’ha apportata: il fornitore, il deployer o un fornitore a monte?
- Riguarda un sistema preesistente, dopo la data di applicazione del capo III?
Esercizio e monitoraggio: log, deriva e incidenti
In esercizio, l’articolo 72 chiede al fornitore un sistema di monitoraggio successivo all’immissione sul mercato che raccolga, documenti e analizzi in modo attivo e sistematico i dati sulle prestazioni per tutta la vita del sistema, compresi quelli forniti dai deployer. Il deployer monitora il funzionamento in base alle istruzioni per l’uso, informa il fornitore e sospende l’uso quando ha motivo di ritenere che il sistema presenti un rischio (articolo 26, paragrafo 5).
I log generati automaticamente si conservano per almeno sei mesi, salvo diversa disposizione del diritto dell’Unione o nazionale: lo prevedono l’articolo 19, paragrafo 1, per i fornitori e l’articolo 26, paragrafo 6, per i deployer. Sei mesi sono un minimo, non un obiettivo: la durata va fissata in funzione della finalità prevista e dei tempi di un’indagine.
Per gli incidenti gravi, l’articolo 73 fissa scadenze precise. La segnalazione va fatta subito dopo aver stabilito un nesso causale, o la sua ragionevole probabilità, e comunque entro 15 giorni da quando se ne viene a conoscenza; entro 2 giorni in caso di infrazione diffusa o di incidente grave ai sensi dell’articolo 3, punto 49, lettera b) (infrastrutture critiche); entro 10 giorni in caso di decesso. È ammessa una segnalazione iniziale incompleta, seguita da quella completa (articolo 73, paragrafo 5), e la Commissione ha già pubblicato un modello di segnalazione.
Il monitoraggio non riguarda solo gli incidenti. La deriva del modello erode le prestazioni senza fare rumore: i dati in ingresso cambiano e le soglie fissate al rilascio perdono significato. Per i sistemi che continuano ad apprendere, il GEPD tratta la «validazione continua» come una fase a sé. In questo tratto del ciclo di vita dell’IA il gate 5 smette di essere un adempimento annuale e diventa una soglia di allarme: quando le metriche escono dall’intervallo accettato, il sistema torna in rivalutazione.
Dismissione: la fase che nessuno pianifica
La dismissione è l’anello più debole del ciclo di vita dell’IA, anche nei documenti di riferimento. Nelle linee guida del GEPD dell’11 novembre 2025, la checklist dei rischi per fase dell’allegato 3 non associa alcun rischio né al rilascio né alla dismissione; per quest’ultima si limita a dire che il sistema andrebbe dismesso in modo responsabile ed efficiente. Il ciclo dell’OCSE non prevede una fase di dismissione separata: la decisione di ritirare il sistema può maturare durante l’esercizio e il monitoraggio. E nella nostra analisi, solo due delle dieci pagine meglio posizionate ne parlano.
Eppure è qui che si concentrano obblighi precisi. L’articolo 20 impone al fornitore che ritiene il sistema non conforme di adottare subito le azioni correttive necessarie, oppure di ritirarlo, disattivarlo o richiamarlo, informando distributori e deployer. L’articolo 18 obbliga a conservare per 10 anni dall’immissione sul mercato la documentazione tecnica, quella del sistema di gestione della qualità e la dichiarazione di conformità UE. L’allegato VIII, sezione A, punto 7, prevede che la banca dati dell’UE indichi se il sistema non è più immesso sul mercato o in servizio, oppure se è stato richiamato. Restano i log e i dati: la limitazione della conservazione e il diritto alla cancellazione previsti dal GDPR valgono per i dati di addestramento e di inferenza anche quando il modello è spento.
Una checklist minima di dismissione:
- decisione e motivazione registrate, con data e autore;
- deployer e utenti informati nei tempi previsti dai contratti;
- accessi revocati e artefatti del modello (pesi, configurazioni, prompt di sistema) archiviati o cancellati;
- dati personali cancellati o anonimizzati secondo il piano di conservazione;
- documentazione archiviata per l’intero periodo di conservazione, con lo stato aggiornato nell’inventario e nella banca dati dell’UE;
- il sistema sostitutivo, se esiste, riparte dal gate di ingresso.
Acquistato, non sviluppato: il ciclo di vita dell’IA visto dal deployer
La maggior parte delle organizzazioni l’IA la compra. Le linee guida del GEPD, scritte per le istituzioni dell’UE soggette al regolamento 2024/2509, descrivono anche un ciclo di vita degli appalti in quattro tappe: pubblicazione e trasparenza, bando di gara, selezione e aggiudicazione, esecuzione. È nell’esecuzione che si ripetono le fasi tecniche: verifica e validazione, rilascio, esercizio e monitoraggio, validazione continua, rivalutazione e dismissione. Vale anche per un’impresa privata: il ciclo di vita dell’IA di un sistema acquistato si governa soprattutto attraverso il contratto.
Le clausole che lo rendono governabile vanno verificate già in sede di due diligence sui fornitori:
- preavviso sulle modifiche di modello o di versione;
- accesso ai log;
- cooperazione in caso di incidente;
- documentazione e istruzioni per l’uso aggiornate;
- fine vita, con restituzione o cancellazione dei dati.
Attenzione poi all’articolo 25: il deployer che appone il proprio nome o marchio su un sistema ad alto rischio, o lo modifica in modo sostanziale, diventa fornitore.
In Italia, la legge 132/2025 ha designato l’AgID e l’Agenzia per la cybersicurezza nazionale (ACN) come autorità nazionali per l’intelligenza artificiale: alla prima spettano le funzioni di notifica, alla seconda la vigilanza, compresa quella sul mercato. Per i dati personali resta competente, lungo tutto il ciclo di vita, il Garante per la protezione dei dati personali, dalla scelta dei dati di addestramento alla cancellazione finale. Per un deployer italiano significa due interlocutori per lo stesso sistema e un fascicolo che deve reggere davanti a entrambi. In Spagna la supervisione fa capo all’AESIA, affiancata dall’AEPD per i dati personali. In Germania la KI-MIG, in vigore dal 29 luglio 2026, affida la vigilanza del mercato alla Bundesnetzagentur.
Domande frequenti
<b>Che cos’è la gestione del ciclo di vita dell’IA?</b>
È il governo di un sistema di IA in tutte le sue fasi, dall’ideazione alla dismissione. Non si limita alla parte tecnica: stabilisce chi risponde del sistema, chi decide il passaggio da una fase all’altra, su quali prove e che cosa va conservato. In pratica significa un inventario con un responsabile per ogni sistema, gate decisionali documentati e un fascicolo di prove che regge a un audit, anche quando il modello cambia.
<b>Quali sono le fasi del ciclo di vita dell’IA?</b>
Non esiste un elenco unico. ISO/IEC 22989, ripresa dal GEPD, distingue ideazione e analisi, dati, sviluppo, verifica e validazione, rilascio, esercizio e monitoraggio, validazione continua, rivalutazione e dismissione. Il NIST AI RMF ne conta sei, l’OCSE le raggruppa in quattro blocchi spesso iterativi. Il nostro modello di lavoro ne usa otto, dalla finalità prevista alla dismissione, con una fase dedicata a rivalutazione e modifica. Conta meno il numero che la coerenza: un solo modello, con gli altri mappati su di esso.
<b>L’AI Act impone la gestione del ciclo di vita dell’IA?</b>
Non con questa espressione, ma nella sostanza sì, per i sistemi ad alto rischio. L’articolo 9 estende la gestione dei rischi all’intero ciclo di vita, l’articolo 12 chiede log per tutta la durata del sistema, l’articolo 72 un monitoraggio continuo dopo l’immissione sul mercato, l’articolo 18 dieci anni di conservazione della documentazione. Dopo l’Omnibus digitale, gli obblighi dell’allegato III si applicano dal 2 dicembre 2027. Senza un ciclo di vita dell’IA organizzato per fasi, queste prove arrivano tardi.
<b>Che differenza c’è tra la gestione del ciclo di vita dell’IA e l’MLOps?</b>
L’MLOps è l’insieme di pratiche e strumenti che automatizzano la pipeline di un modello: versionamento dei dati, addestramento, test, distribuzione, monitoraggio tecnico. La gestione del ciclo di vita dell’IA è una disciplina di governance: decide se il sistema può passare alla fase successiva, chi lo approva, su quali prove e con quali conseguenze giuridiche. Le due cose si completano: l’MLOps fornisce molte delle prove (metriche di validazione, log, versioni), ma non sostituisce la decisione.
<b>Quando una modifica diventa una modifica sostanziale?</b>
Secondo l’articolo 3, punto 23, quando un cambiamento successivo all’immissione sul mercato o alla messa in servizio non era previsto nella valutazione della conformità iniziale e incide sulla conformità ai requisiti del capo III, sezione 2, oppure modifica la finalità prevista. Per i sistemi che continuano ad apprendere, le modifiche predeterminate e descritte nell’allegato IV, punto 2, lettera f), non contano. La modifica sostanziale impone una nuova valutazione della conformità e può rendere fornitore chi la apporta.
<b>Che cosa succede quando un sistema di IA viene dismesso?</b>
Per un sistema ad alto rischio la dismissione non chiude gli obblighi. Il fornitore che lo ritira, lo disattiva o lo richiama informa distributori e deployer (articolo 20), conserva per 10 anni la documentazione tecnica e quella del sistema qualità, oltre alla dichiarazione di conformità (articolo 18), e aggiorna lo stato nella banca dati dell’UE. I dati personali di addestramento e di inferenza vanno cancellati o anonimizzati secondo il GDPR, e l’eventuale sistema sostitutivo riparte dal gate di ingresso.
Conclusione
Il ciclo di vita dell’IA non è un diagramma da mettere in apertura di una policy: è una sequenza di decisioni, ciascuna con un responsabile e una prova. L’AI Act lo dice con poche parole e molti obblighi, e l’Omnibus digitale ha spostato le date senza cambiare la logica: chi modifica in modo significativo un sistema esistente lo porta dentro il perimetro, chi lo dismette senza un piano perde prove che dovrà conservare per dieci anni. Partite da tre cose: un inventario completo con un responsabile per ogni sistema, un registro delle modifiche con una decisione di triage per ogni voce, una checklist di dismissione approvata prima del primo rilascio. Su questa base la gestione del ciclo di vita dell’IA diventa verificabile. Il passo successivo è la nostra guida operativa al regolamento UE sull’IA, con la scheda sul framework AI Act.