AI Act e valutazione continua dei rischi: perché un assessment iniziale non basta

In questo articolo

Un sistema AI può cambiare anche dopo la valutazione e l’approvazione iniziale quando il fornitore aggiorna il modello, aumentano gli utenti, vengono aggiunti nuovi dati o integrazioni e l’impiego si estende ad altri processi. Per questo la gestione del rischio deve proseguire oltre l’assessment iniziale. Per i sistemi ad alto rischio, l’AI Act richiede un processo continuo e iterativo, capace di utilizzare monitoraggio, anomalie e incidenti per aggiornare controlli, responsabilità e decisioni durante l’intero ciclo di vita.

L’AI Act classifica i sistemi ad alto rischio soprattutto in base alla finalità e all’impatto potenziale sulle persone. Rientrano in questa categoria i sistemi che costituiscono componenti di sicurezza di prodotti regolamentati, come alcuni dispositivi medici, robot o droni, e determinati utilizzi indicati nell’Allegato III, tra cui biometria, infrastrutture critiche, istruzione, occupazione e accesso ai servizi essenziali.

Per i sistemi così classificati, l’articolo 9, paragrafo 2, del Regolamento (UE) 2024/1689, noto come AI Act, definisce la gestione dei rischi come «un processo iterativo continuo […] nel corso dell’intero ciclo di vita», che richiede riesami e aggiornamenti costanti e sistematici.

Un caso concreto è un software HR che filtra i CV, classifica i candidati o valuta le prestazioni dei dipendenti. Poiché può influenzare l’accesso al lavoro o le decisioni sulla carriera, è considerato ad alto rischio. Un assistente che si limita a redigere l’annuncio o programmare i colloqui non rientra automaticamente nella stessa categoria.

Per i sistemi così classificati, il provider deve applicare il processo continuo e iterativo previsto dall’articolo 9 del Regolamento (UE) 2024/1689, cioè l’AI Act lungo l’intero ciclo di vita. Il deployer deve invece seguire le istruzioni, monitorare il funzionamento, garantire la supervisione umana e intervenire quando emergono rischi o incidenti.

Un sistema AI approvato oggi potrebbe essere diverso tra sei mesi.
Il provider aggiorna il modello, l’IT lo collega al CRM, nuovi reparti iniziano a utilizzarlo oppure cambiano i dati inseriti dagli utenti. Ognuna di queste modifiche può ampliare gli accessi, introdurre risultati inattesi o rendere insufficienti i controlli iniziali.

La valutazione continua del rischio serve a intercettare questi cambiamenti, con la necessità di stabilire quali eventi devono far scattare una nuova verifica come una versione del modello, una nuova integrazione, l’estensione a un altro processo, un’anomalia o un incidente.

A quel punto l’azienda può analizzare ciò che è cambiato, testare nuovamente le misure adottate e decidere se aggiornare i controlli, limitare alcune funzioni o proseguire alle condizioni definite. La valutazione diventa così un ciclo collegato alla vita reale del sistema e non una formalità da soddisfare con un documento.

Una nuova valutazione del rischio AI può scattare quando il fornitore aggiorna il modello, un reparto collega l’applicazione a una nuova fonte di dati oppure gli utenti iniziano a impiegarla per attività diverse da quelle approvate.

Questi esempi sono tutti eventi che devono attivare una nuova valutazione del rischio ma lo stesso vale quando cambiano i permessi, viene aggiunta un’integrazione, peggiora la qualità dei risultati, emerge una vulnerabilità o si verifica un incidente.

L’IT Manager può definire questi eventi in anticipo e inserirli nei processi di change management e gestione dei fornitori. Di seguito elenchiamo alcune domande che possono essere una linea guida per la valutazione ricorsiva:

• il sistema accede a più informazioni?
• produce decisioni con un impatto maggiore?
• coinvolge nuovi utenti?
• richiede controlli o supervisione differenti?

In base alle risposte, l’azienda può confermare l’utilizzo, introdurre ulteriori misure di sicurezza, limitare alcune funzionalità oppure sospenderle. La valutazione ricorsiva diventa quindi un meccanismo attivato dai cambiamenti reali, non una verifica ripetuta a intervalli arbitrari.

Il monitoraggio parte da una domanda semplice che può essere sintetizzata con: l’azienda riuscirebbe ad accorgersi se il sistema AI iniziasse a comportarsi in modo diverso?

Per rispondere, l’IT Manager deve sapere quali strumenti sono in uso, chi li utilizza, a quali dati accedono e chi ne è responsabile.

A queste informazioni vanno affiancati indicatori concreti come:

• variazioni nel numero degli utenti
• nuovi collegamenti con applicazioni aziendali
• errori ricorrenti, risultati anomali
• interventi manuali e incidenti segnalati

Un assistente AI interno, per esempio, può funzionare correttamente finché consulta documenti autorizzati mentre il rischio cambia se viene collegato a cartelle riservate o reso disponibile a nuovi reparti. Il monitoraggio deve comprendere anche gli aggiornamenti comunicati dal provider, perché modello, funzionalità e condizioni di utilizzo possono cambiare anche senza un intervento diretto dell’azienda. Ogni segnale rilevante deve avere un responsabile, una soglia di attenzione e un’azione prevista: approfondire, correggere i controlli, limitare l’accesso o avviare una nuova valutazione.

La valutazione va aggiornata quando cambia il sistema, il suo utilizzo o il contesto in cui opera. Per rendere il processo gestibile, l’azienda può definire in anticipo gli eventi che richiedono una verifica e le azioni da considerare.

Questa tabella può diventare una checklist per il change management e la gestione dei fornitori. La valutazione continua smette così di essere un controllo generico e si attiva in presenza di cambiamenti osservabili.

Un sistema AI che fornisce un risultato errato deve necessariamente essere disattivato al primo problema?

La risposta dipende dalla gravità, dalla frequenza e dall’impatto dell’anomalia. Se l’errore è circoscritto e facilmente correggibile, può essere sufficiente modificare configurazioni, dati, istruzioni o controlli. Se la causa non è ancora chiara, l’azienda può limitare temporaneamente gli utenti, rimuovere alcune integrazioni o richiedere l’approvazione umana prima di utilizzare il risultato.

La sospensione diventa necessaria quando il sistema espone dati riservati, produce decisioni potenzialmente discriminatorie, mostra segni di compromissione oppure influenza processi critici senza garanzie sufficienti di affidabilità. Questi criteri devono essere definiti prima dell’incidente, insieme alle responsabilità, per agire rapidamente. Chi può bloccare il sistema, chi valuta il rischio e chi autorizza la riattivazione.

Lo “Stanford AI Index Report 2026” riporta che l’AI Incident Database ha registrato 362 incidenti documentati nel 2025, rispetto ai 233 del 2024.

Il database raccoglie segnalazioni di danni o quasi-danni nei quali è coinvolto un sistema AI e il dato mostra l’aumento dei casi conosciuti, ma non rappresenta un censimento completo né dimostra che ogni incidente derivi da controlli insufficienti. Un esempio concreto riguarda il chatbot “My AI” di Snap. Nel 2023 l’autorità britannica per la protezione dei dati avviò un’indagine perché la valutazione dei rischi per la privacy, in particolare per gli utenti più giovani, risultava inadeguata.

Dopo un preavviso di enforcement, Snap approfondì l’analisi e introdusse ulteriori misure di mitigazione. L’indagine venne chiusa nel maggio 2024 e anche se questo caso riguarda il UK GDPR e non l’AI Act, rende evidente il punto: una valutazione iniziale incompleta deve poter essere aggiornata prima che il rischio diventi un incidente.

Gestire il rischio AI significa mantenere il controllo anche dopo l’approvazione iniziale.
Il punto di partenza è un inventario aggiornato dei sistemi utilizzati, seguito dall’assegnazione di responsabilità, dalla definizione degli eventi che attivano una nuova verifica e da procedure chiare per intervenire.

Per i sistemi ad alto rischio, questo approccio risponde al processo continuo e iterativo previsto dall’AI Act mentre per le altre applicazioni rappresenta comunque una misura utile di governance, cyber security e protezione dei dati.
L’obiettivo è evitare che uno strumento approvato oggi diventi, dopo aggiornamenti e nuovi utilizzi, un elemento che l’azienda non conosce più davvero.

L’assessment fotografa il rischio in un determinato momento ma sono il monitoraggio e la responsabilità a permettere di governarlo nel tempo.

BeeCyber offre un modello evoluto di cyber security “as-a-service”, pensato per le aziende che vogliono rafforzare la propria sicurezza senza appesantire il reparto IT interno. Attraverso un approccio integrato che combina tecnologie avanzate, competenze specialistiche e monitoraggio continuo, supportiamo le imprese nella difesa dei dati, nella conformità normativa e nella continuità operativa.