Sorveglianza post-commercializzazione dell’IA: come trasformare i segnali d’uso in controlli verificabili

Che cosa richiede la sorveglianza post-commercializzazione

La sorveglianza post-commercializzazione è il sistema con cui il fornitore raccoglie e analizza informazioni pertinenti sulle prestazioni di un sistema di IA ad alto rischio dopo la sua immissione sul mercato o la sua messa in servizio. Il suo scopo non è accumulare registrazioni fini a sé stesse: deve consentire al fornitore di verificare se il sistema continua a rispettare i requisiti applicabili e se sono emersi problemi da esaminare o affrontare.

L’articolo 72 del regolamento sull’IA attribuisce al fornitore la responsabilità di istituire e documentare tale sistema. Il sistema deve essere proporzionato alla natura della tecnologia e ai rischi del sistema. Il fornitore deve inoltre predisporre un piano di sorveglianza post-commercializzazione come parte della documentazione tecnica. In pratica, il piano spiega come saranno ottenuti e analizzati i dati, quali segnali potrebbero indicare una deviazione e come si deciderà se intervenire.

L’obbligo riguarda i sistemi di IA ad alto rischio. Non significa che tutti i fornitori debbano sorvegliare qualsiasi prodotto con la stessa intensità, né che debbano raccogliere tutti i dati disponibili. La proporzionalità conta: le fonti, gli indicatori e la frequenza delle verifiche dovrebbero essere ragionevolmente commisurati all’uso previsto, al contesto di impiego e ai rischi che il sistema può generare.

È utile distinguere due piani. Il requisito giuridico consiste nel disporre di un sistema e di un piano adeguati e documentati. Gli indicatori, le soglie e le procedure proposti in questa guida sono possibili scelte progettuali per rendere operativo l’obbligo; non costituiscono un elenco universale imposto dal regolamento.

Che cosa osservare e da dove possono provenire i dati

Il regolamento contempla dati pertinenti forniti dai deployer e dati ottenuti da altre fonti. Questo lascia ai fornitori margine per progettare un sistema adeguato al proprio prodotto, ma non elimina la necessità di motivare la pertinenza delle fonti né di spiegare come saranno interpretate. I dati dovrebbero servire a valutare le prestazioni del sistema durante il suo ciclo di vita e a individuare cambiamenti che potrebbero incidere sulla conformità o sui rischi.

Un inventario iniziale può comprendere metriche di funzionamento, risultati anomali, problemi tecnici, reclami, commenti strutturati degli utenti, richieste di assistenza e modifiche delle condizioni d’uso. A seconda del sistema, può essere importante osservare anche cambiamenti nella popolazione degli utenti, nei dati di input o nei processi con cui il sistema è integrato. Non tutti questi segnali sono obbligatori in ogni caso: la loro utilità dipende dal contesto e dal rischio che si intende sorvegliare.

L’interazione con altri sistemi di IA merita attenzione quando è pertinente per comprendere le prestazioni o i rischi. Per esempio, uno strumento può ricevere risultati da un altro sistema o alimentare con i propri output un processo automatizzato. In questi casi, un cambiamento nel sistema collegato, nel formato dei dati o nel flusso di lavoro può modificare il comportamento osservato senza che sia cambiato il modello sottoposto a sorveglianza. Il piano dovrebbe indicare quali dipendenze sono pertinenti e come saranno rilevati i cambiamenti che le riguardano.

La collaborazione con il deployer è importante perché il fornitore potrebbe non osservare direttamente tutte le condizioni d’uso effettive. Un accordo operativo può specificare quali categorie di dati saranno condivise, chi le prepara, con quale frequenza, attraverso quale canale e a chi comunicare i segnali urgenti. Si tratta di una raccomandazione pratica: il regolamento non trasforma questo elenco specifico in un modulo obbligatorio. Lo scambio dovrebbe limitarsi a quanto necessario per la finalità di sorveglianza e rispettare gli altri obblighi applicabili.

Progettare un piano concretamente applicabile

Un piano operativo parte dall’uso previsto e dai rischi che il sistema può comportare in quel contesto. Individua quindi quali dati potrebbero mostrare un cambiamento rilevante e quali decisioni potrebbero derivarne. Una tabella di metriche priva di responsabili, criteri di verifica e modalità d’intervento è difficile da usare e chiarisce poco il modo in cui è stato gestito un segnale.

È utile assegnare responsabilità distinte. Un gruppo tecnico può convalidare la qualità dei dati e analizzare il comportamento; il team di prodotto può valutare le modifiche alle funzionalità o alle condizioni d’uso; il team di conformità può verificare gli obblighi applicabili e la documentazione; una persona o un gruppo dotato di autorità chiaramente definita può decidere se il caso debba essere portato a un livello superiore. Nelle organizzazioni più piccole una stessa persona può svolgere più funzioni, ma le decisioni e le relative motivazioni devono comunque essere identificabili.

Gli indicatori dovrebbero essere formulati in modo da consentire verifiche coerenti. Possono comprendere tassi di errore, indisponibilità, cambiamenti nella distribuzione degli input, differenze tra gruppi pertinenti per la valutazione del sistema oppure un aumento dei risultati che richiedono una revisione umana. Un indicatore è utile solo se sono definiti il metodo di calcolo, il periodo di osservazione e i suoi limiti. Non si dovrebbe presentare una metrica come prova conclusiva se costituisce soltanto un segnale da approfondire.

Il fornitore può stabilire livelli interni di allerta. Per esempio, una variazione oltre una soglia concordata può avviare una verifica tecnica; la ripetizione della variazione, o la sua presenza in più implementazioni, può giustificare una valutazione più ampia. Queste soglie sono strumenti di gestione raccomandati, non valori fissati in generale dall’articolo 72. Dovrebbero essere riesaminate se cambiano l’uso, le prove disponibili o il profilo di rischio.

Esaminare i segnali e documentare le decisioni

Un segnale non equivale automaticamente a una non conformità. Potrebbe dipendere da dati incompleti, da una modifica del processo del cliente, da un problema temporaneo o da un effettivo deterioramento delle prestazioni. L’analisi dovrebbe distinguere queste possibilità e registrare le informazioni esaminate. Se il segnale riguarda più implementazioni, è opportuno verificare l’esistenza di una causa comune, come una versione specifica, una dipendenza condivisa o un cambiamento nelle condizioni di input.

Un registro delle decisioni utile comprende la data di rilevazione, la fonte, il sistema e le versioni interessate, la descrizione del segnale, la persona responsabile della valutazione, le prove esaminate, la conclusione e le fasi successive. Se non viene adottata alcuna misura, il registro dovrebbe spiegare perché le informazioni disponibili non giustificavano un intervento e quali condizioni porterebbero a riaprire il caso. Questo livello di dettaglio è una buona pratica documentale, non un formato rigido prescritto dal regolamento.

Le misure possibili dipendono dai risultati dell’analisi. Possono consistere nella correzione di un difetto, nell’aggiornamento delle istruzioni, nella modifica di un’integrazione, nel rafforzamento dei controlli umani, nella limitazione temporanea di determinati usi o nell’avvio di una revisione tecnica più ampia. La misura scelta dovrebbe essere proporzionata al problema osservato e documentata. Se il segnale suggerisce che il sistema non soddisfa più i requisiti applicabili o che sono emersi rischi non considerati, il fornitore dovrebbe collegare il risultato ai processi di valutazione e gestione dei rischi, anziché trattarlo come un caso isolato di assistenza clienti.

Anche il deployer deve sapere quali informazioni sono importanti per utilizzare adeguatamente il sistema e comunicare i problemi pertinenti. Il piano dovrebbe quindi prevedere un canale di escalation e un meccanismo per trasmettere le informazioni al fornitore. Nei prodotti con più clienti, definire una modalità coerente riduce il rischio che segnali simili restino dispersi tra diversi gruppi di assistenza.

Sorveglianza, gestione dei rischi, valutazioni d’impatto e incidenti

La sorveglianza post-commercializzazione non sostituisce la gestione dei rischi. Quest’ultima è un processo più ampio di identificazione, analisi e trattamento dei rischi che dovrebbe accompagnare il sistema. La sorveglianza fornisce informazioni sul suo funzionamento reale e può rivelare che un’ipotesi precedente non è più valida, che è emerso un nuovo rischio o che una misura di controllo non funziona come previsto. Il piano dovrebbe assicurare che tali segnali raggiungano le persone in grado di riesaminare le valutazioni e le misure esistenti.

La sorveglianza non coincide neppure con una valutazione d’impatto precedente all’implementazione. Una valutazione preventiva esamina i possibili effetti in un determinato contesto e prima di uno specifico impiego, ove applicabile. La sorveglianza esamina informazioni raccolte durante il ciclo di vita del sistema e aiuta a individuare cambiamenti che diventano visibili soltanto nell’uso effettivo. Sono attività complementari: una valutazione preventiva, da sola, non dimostra che il sistema continuerà a comportarsi allo stesso modo dopo l’implementazione.

La segnalazione degli incidenti gravi prevista dall’articolo 73 ha un presupposto e una finalità diversi: riguarda gli incidenti che devono essere comunicati secondo le regole applicabili. La sorveglianza, invece, dovrebbe funzionare sistematicamente e non aspettare che si verifichi un incidente grave. Un segnale può giustificare verifiche e misure preventive anche se non ha ancora raggiunto la soglia di un incidente da segnalare. E, se viene individuato un incidente soggetto a segnalazione, il processo di sorveglianza non sostituisce la comunicazione prescritta.

Per evitare confusione, le organizzazioni possono collegare i processi senza fonderli: lo stesso evento può avviare un’analisi di sorveglianza e, separatamente, attivare una valutazione relativa alla segnalazione degli incidenti. Il registro dovrebbe mostrare quale percorso è stato considerato, chi ha preso la decisione e quali azioni sono state avviate. Questa distinzione aiuta a non sottovalutare un segnale precoce e a non trattare ogni deviazione minore come se fosse automaticamente un incidente grave.

Casi specifici e calendario normativo

L’articolo 72 prevede una cautela specifica per determinati sistemi di IA ad alto rischio nell’ambito delle attività di contrasto: il sistema di sorveglianza non comprende i dati operativi sensibili detenuti dalle autorità di contrasto. Si tratta di un’esclusione circoscritta. Non va interpretata come un’esenzione generale dalla sorveglianza per qualsiasi sistema utilizzato da un’autorità, né come un’autorizzazione a ignorare altri segnali pertinenti che possano essere trattati nel rispetto delle norme applicabili.

La riforma normativa del 2026 ha modificato la disposizione relativa agli orientamenti della Commissione. Il regolamento prevede che la Commissione pubblichi orientamenti e un modello volontario per il piano di sorveglianza post-commercializzazione entro il 2 settembre 2027. Il modello, pertanto, non dovrebbe essere descritto come uno strumento già disponibile né come un requisito obbligatorio in sé. In attesa della sua pubblicazione, i fornitori possono strutturare la documentazione sulla base degli obblighi giuridici vigenti e delle proprie esigenze operative.

Anche il calendario di applicazione per i sistemi ad alto rischio è stato modificato. Il testo consolidato stabilisce date diverse a seconda della categoria: per i sistemi ad alto rischio inclusi nell’allegato III, l’applicazione degli obblighi pertinenti decorre dal 2 dicembre 2027; per i sistemi ad alto rischio disciplinati dalla normativa di armonizzazione elencata nell’allegato I, decorre dal 2 agosto 2028. La classificazione e la data applicabile devono essere verificate per ogni sistema; è opportuno non estendere una data a tutti i prodotti di IA.

Queste date non tolgono valore alla preparazione anticipata del ciclo di sorveglianza. Progettare le fonti di dati, gli accordi di condivisione e l’assegnazione delle responsabilità spesso richiede coordinamento tra fornitore e cliente. Tuttavia, la preparazione operativa non va confusa con l’affermazione che un obbligo sia già applicabile a un determinato sistema prima della data pertinente.

Lista di controllo per riesaminare il piano

La prova pratica di un piano non è la sua lunghezza, ma la possibilità di ricostruire come viene sorvegliato il sistema e che cosa accade quando emerge un segnale. Le domande seguenti possono essere usate per una revisione interna. Non sostituiscono l’analisi giuridica del sistema, della sua classificazione o dei suoi obblighi specifici.

Un piano solido identifica il sistema e gli usi pertinenti, spiega quali fonti di informazione utilizza e perché, assegna le responsabilità e definisce una procedura di analisi. Considera inoltre come vengono comunicati i segnali tra il fornitore e il deployer, come sono conservate le decisioni e come i risultati vengono collegati a un riesame dei rischi o a una misura correttiva.

La revisione dovrebbe anche verificare se le metriche sono interpretabili, se gli avvisi portano ad azioni concrete e se il gruppo di lavoro è in grado di distinguere un’anomalia nei dati da un deterioramento del sistema. Se una modifica di versione, una nuova integrazione o un cambiamento del contesto possono alterare le prestazioni, il piano dovrebbe indicare come rilevarli e come riesaminare la sorveglianza.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.