Il concetto di “ciclo di vita” sta assumendo un ruolo centrale nella regolazione europea delle tecnologie digitali.

Pur senza fornirne una definizione generale, il Cyber Resilience Act (CRA) e l’AI Act lo impiegano per superare una visione statica della conformità: sicurezza, gestione del rischio, aggiornamenti, monitoraggio e documentazione non si esauriscono prima dell’immissione sul mercato, ma devono accompagnare il prodotto o il sistema durante tutta la sua vita operativa.

La compliance diventa una capacità organizzativa continua, documentata e verificabile, fino alla dismissione della tecnologia.

Ecco le convergenze e le differenze tra i due regolamenti, il contributo degli standard tecnici e delle linee guida ENISA e le ricadute concrete per produttori, provider, deployer e altri attori della filiera.

Dal lessico alla regolazione: il significato del ciclo di vita

Poche stagioni normative hanno mostrato quanto quella europea sul digitale che le scelte linguistiche possano orientare l’evoluzione di una disciplina. Concetti inizialmente percepiti come formule tecniche entrano nel lessico giuridico, si consolidano nella prassi e finiscono per modellare obblighi, ruoli e responsabilità.

Il GDPR lo ha dimostrato con l’accountability: un termine divenuto familiare, ma tuttora denso di conseguenze organizzative e probatorie.

Una parola emblematica da questo punto di vista e attualissima è “lifecycle” (o “lifetime”), resa in italiano con “ciclo di vita”, riferita ai sistemi di intelligenza artificiale e ai prodotti e beni digitali.

Il termine, non nuovo per la verità, è usato massicciamente dal legislatore europeo nell’AI Act e nel Cyber Resilience Act (CRA), rispettivamente disciplinanti, appunto, i sistemi sopra detti.

I due regolamenti non contengono una definizione generale e autonoma di ‘ciclo di vita’, né ne fissano una sequenza tassativa di fasi. Il concetto opera però come criterio trasversale di interpretazione degli obblighi.

CRA e AI Act: un concetto comune, obblighi differenti

Prima di approfondire il concetto richiamando standard tecnici e atti di soft-law, è bene comprendere un messaggio molto chiaro che l’espressione ciclo di vita vuole trasmettere: la compliance dei sistemi di IA e dei prodotti digitali non è più un adempimento burocratico fine a sé stesso, passivo e statico, da fare una tantum.

Infatti il rispetto degli obblighi e delle prescrizioni ,in capo agli attori coinvolti, deve essere assicurato lungo tutto l’arco di vita dei prodotti e dei sistemi e, quindi, la compliance diventa un processo di governo continuo che accompagna la tecnologia in ogni fase rilevante, fino alla dismissione.

È un nuovo approccio alla tecnologia che porta il principio della security by design e by default a un livello successivo, che non si accontenta di singole verifiche precedenti all’immissione sul mercato, ma richiede il governo del sistema che crea il prodotto e lo accompagna.

Attraverso il meccanismo del feedback loop, addirittura, valutazioni inizialmente svolte all’inizio possono essere rimesse in discussione.

Convergenza dell’approccio senza sovrapposizione tra i due regolamenti

È bene sin da ora sottolineare che la convergenza dell’approccio e delle logiche sottese all’AI Act e al CRA non devono far dimenticare il diverso oggetto di tutela dei due testi normativi: il confronto proposto, quindi, non implica una sovrapposizione tra i due regolamenti.

Il CRA stabilisce requisiti orizzontali di cibersicurezza per i prodotti con elementi digitali, con attenzione a vulnerabilità, aggiornamenti e periodo di assistenza.

L’AI Act adotta invece un approccio basato sul rischio per i sistemi di IA e tutela, in particolare nel regime dei sistemi ad alto rischio, salute, sicurezza e diritti fondamentali.

Senza voler assimilare diversi oggetti di tutela, qui si mette in luce una convergenza di metodo: in entrambi i casi la conformità deve essere governata lungo l’intero ciclo di vita della tecnologia.

L’AI Act e il CRA, pur non definendo puntualmente il concetto di ciclo di vita, richiamano l’espressione – o formule strettamente collegate – in diversi considerando e articoli. I principali sono riportati nelle tabelle seguenti.

La tabella del CRA

La tabella dell’AI Act

Dalle norme agli standard: come si articola il ciclo di vita

I regolamenti, come accennato, non definiscono il ciclo di vita né enucleano le fasi che lo compongono.

Di grande aiuto sono gli standard tecnici e gli atti di soft-law, che hanno il pregio di colmare le lacune legislative e di fornire buone pratiche e linee guida agli attori economici: nel segmentare il ciclo di vita del prodotto o del sistema, entrambe, con le dovute differenze, forniscono il linguaggio operativo e i checkpoint pratici per tradurre gli obblighi astratti dei regolamenti (risk management continuo, monitoraggio post-market) in azioni concrete, assegnabili e verificabili fase per fase: è esattamente il “come fare” che la norma giuridica non affronta in modo approfondito e dettagliato.

La presenza di un ciclo di vita condiviso evita che l’accountability si frammenti e fallisca.

Inoltre, permette di approfondire e trattare in modo mirato vulnerabilità specifiche di singole fasi, anziché applicare un metodo generico e uniforme, che rischia di non essere oggettivo e aderente alla realtà.

Ogni fase è rilevante e degna di attenzione: se, da un lato, la necessità di garantire la sicurezza inizia ben prima dell’immissione sul mercato, dall’altro, è importante non sottovalutare la fase finale su cui concordano le norme tecniche, cioè la dismissione del prodotto o del sistema, che può essere abbandonato del tutto o reintegrato in una nuova entità.

CRA: sicurezza, aggiornamenti e periodo di assistenza

Partiamo dai prodotti digitali al centro della disciplina del CRA.

L’Agenzia europea per la cibersicurezza (ENISA) nel recentissimo Secure by Design and Default Playbook affronta la questione nella sezione due, quando afferma che la sicurezza del prodotto deve essere considerata durante l’intero ciclo di vita del prodotto, articolato nei seguenti processi:

• requisiti (requirements),
• progettazione (design),
• sviluppo/implementazione,
• (development/implementation),
• test e accettazione (testing and acceptance),
• distribuzione e integrazione (deployment and integration),
• manutenzione e dismissione (maintenance and disposal).

A partire dalla scansione delle fasi del ciclo di vita si individuano gli asset e le minacce e si decidono quindi le azioni da mettere in atto per concretizzare il principio della sicurezza by design e by default.

La stessa Agenzia sottolinea come il ciclo di vita e queste azioni, benché si presentino in forma sequenziale, siano da considerarsi un processo iterativo.

La gestione del rischio è quindi un’attività che va rivista e svolta a ogni passaggio tra fasi e ogniqualvolta c’è un evento scatenante (cosiddetto trigger) che impone una riflessione o azioni specifiche, come la scoperta di nuove vulnerabilità.

L’esperienza continua dell’approccio life-cycle

L’approccio life-cycle è poi considerato nello stesso documento componente essenziale dell’integrità operativa, garantendo che la sicurezza sia vista più come un’esperienza continua e viva, sia per gli sviluppatori che per gli utenti, piuttosto che una lista di controllo da completare una sola volta durante la fase di progettazione.

AI Act: il rischio come processo continuo

Per i sistemi di IA, invece, i due punti di riferimento principali sono l’Artificial Intelligence Risk Management Framework (AI RMF) del National Institute of Standards and Technology (NIST) e la ISO/IEC 5338 Information technology – Artificial intelligence – AI system life cycle processes.

Il primo è un framework volontario che riprende la tassonomia da OECD Framework for the Classification of AI Systems (2022) e indica che la gestione del rischio dovrebbe iniziare dalla fase di pianificazione e progettazione e proseguire per tutto il ciclo di vita, articolato nelle fasi Plan and Design, Data Collection and Processing, Model Building and Use, Verification and Validation, Deployment and Use, Operation and Monitoring.

ISO/IEC 5338:2023

L’ISO/IEC 5338:2023 adotta un’impostazione diversa e più analitica. Non prescrive un’unica sequenza obbligatoria di fasi, ma definisce i processi che possono comporre il ciclo di vita di un sistema di IA, dalla concezione al ritiro.

Accanto ai processi tradizionali di requisiti, progettazione, implementazione, integrazione, verifica, transizione, validazione, esercizio e manutenzione, introduce processi propri dell’IA, quali l’acquisizione della conoscenza, l’AI data engineering e la validazione continua.

Include inoltre espressamente il disposal process, cioè la dismissione del sistema. Proprio questo ultimo passaggio merita attenzione: la dismissione non coincide con il semplice spegnimento di un modello o con la cessazione di una licenza.

Può richiedere la gestione ordinata di dati, modelli, log, accessi, dipendenze tecniche, contratti e obblighi di conservazione, oltre alla valutazione dell’eventuale migrazione verso un nuovo sistema.

Documentazione dinamica e accountability lungo il ciclo di vita

La mappatura del ciclo di vita non deve restare un esercizio descrittivo. Deve tradursi in documentazione, ruoli, procedure e decisioni tracciabili.

Per ciascuna fase occorre individuare almeno: il soggetto responsabile, i rischi da valutare, le misure tecniche e organizzative adottate, le evidenze da conservare, le condizioni che richiedono un riesame e i flussi informativi verso fornitori, deployer, utilizzatori e, quando necessario, autorità competenti.

In questa prospettiva, la documentazione tecnica richiesta dal CRA e dall’AI Act non è un fascicolo da produrre alla vigilia della commercializzazione.

Ma diventa l’archivio dinamico delle decisioni assunte durante il ciclo di vita del prodotto o del sistema: dalla valutazione iniziale dei rischi ai test, dagli aggiornamenti alle vulnerabilità segnalate, dal monitoraggio post-market fino alla dismissione.

Laddove l’approccio lifecycle si salda con l’accountability

Non basta poter affermare che una misura è stata adottata; bisogna poter dimostrare chi l’ha decisa, su quali elementi, con quali effetti e perché sia stata mantenuta, modificata o dismessa nel tempo.

Per gli operatori economici, la conformità diventa quindi una capacità organizzativa permanente, non un adempimento documentale isolato.

Dal principio al presidio: cosa devono fare gli operatori

Come tradurre i principi in gioco nell’operatività quotidiana? Con una governance che, tenendo conta delle differenze fra i prodotti e i sistemi disciplinati, copra almeno i seguenti aspetti:

• Mappare il perimetro. Individuare prodotti, componenti digitali, sistemi di IA, modelli, dati, fornitori e soggetti che intervengono nelle diverse fasi.
• Attribuire responsabilità. Stabilire chi approva requisiti e rilascio, chi presidia test e documentazione, chi gestisce aggiornamenti e vulnerabilità, chi monitora prestazioni e incidenti e chi autorizza o esegue la dismissione.
• Definire trigger di riesame. Nuove vulnerabilità, incidente grave, cambiamento di destinazione d’uso, aggiornamento significativo, retraining, data drift, degrado delle prestazioni, modifica sostanziale o fine del supporto.
• Allineare contratti e supply chain. Prevedere clausole su aggiornamenti, vulnerability disclosure, informazioni sui componenti, periodi di assistenza, cooperazione nel monitoraggio e restituzione/cancellazione di dati e asset alla fine del rapporto.
• Preparare il fine vita. Stabilire in anticipo come disattivare il prodotto o sistema, migrare gli utenti, revocare credenziali e chiavi, governare log e dati residui, cancellare ciò che non deve essere conservato e comunicare la cessazione del supporto.

La compliance come capacità organizzativa permanente

Il ciclo di vita non è un’etichetta lessicale, ma il criterio che trasforma la compliance in presidio continuativo.

Il concetto esprime un mutamento di prospettiva nel diritto europeo delle tecnologie: la conformità non coincide più con un’attestazione iniziale, con un fascicolo tecnico prodotto prima dell’immissione sul mercato o con una verifica da ripetere soltanto in occasione di un controllo.

Diventa, invece, una capacità organizzativa permanente, fatta di valutazione, monitoraggio, aggiornamento, documentazione e assunzione di responsabilità nel tempo.

CRA e AI Act traducono questa logica in obblighi diversi, ma coerenti. Nel primo caso, la continuità riguarda in particolare la gestione delle vulnerabilità, gli aggiornamenti di sicurezza e il periodo di assistenza, che deve essere proporzionato al tempo in cui il prodotto è ragionevolmente destinato a rimanere in uso.

Nel secondo, soprattutto per i sistemi di IA ad alto rischio, il sistema di gestione dei rischi deve essere istituito, attuato, documentato e mantenuto come processo iterativo continuo.

La domanda che imprese e pubbliche amministrazioni devono allora porsi non è più soltanto se un prodotto o un sistema sia conforme nel giorno in cui viene rilasciato, ma se l’organizzazione sia in grado di continuare a governarlo quando emergono una vulnerabilità, un incidente, un degrado delle prestazioni, un uso inatteso, un aggiornamento significativo o la necessità di ritirarlo.

Non basta, quindi, assicurarsi che il sistema o il prodotto inizino bene il loro percorso: occorre preoccuparsi – e occuparsi – del percorso stesso fino alla fine.