Monitoraggio Post-Commercializzazione del Regolamento UE sull'IA (Art. 72): Obblighi per i Fornitori di IA ad Alto Rischio

La conformità non termina all'immissione sul mercato. L'Art. 72 richiede ai fornitori di sistemi AI ad alto rischio di mantenere un sistema attivo di monitoraggio post-commercializzazione, raccogliere dati sulle prestazioni e segnalare gli incidenti gravi. Ecco cosa dovete fare — e quando.

Cos'è il Monitoraggio Post-Commercializzazione?

La valutazione della conformità e la marcatura CE sono il biglietto d'ingresso al mercato UE per un sistema AI ad alto rischio — non il traguardo. L'articolo 72 del Regolamento UE sull'IA impone un obbligo continuativo: i fornitori devono istituire e gestire un sistema di monitoraggio post-commercializzazione (PMM) che raccoglie, analizza e agisce attivamente sui dati di prestazione nel mondo reale durante tutta la vita operativa del sistema.

Il ragionamento è semplice. Un sistema AI validato su un set di dati fisso può subire un drift man mano che gli input del mondo reale cambiano, la popolazione degli utenti cambia o l'ambiente in cui opera evolve. Le istantanee di conformità statiche non possono catturare questo. Il PMM è il meccanismo che trasforma la conformità in un processo continuo piuttosto che in un evento una tantum.

Il sistema PMM deve essere proporzionato alla natura e ai rischi del sistema AI ad alto rischio in questione. Un modello di scoring creditizio dispiegato su scala attraverso milioni di consumatori richiederà un monitoraggio più intensivo rispetto a uno strumento di classificazione dei documenti ad ambito limitato utilizzato internamente da un'impresa regolamentata.

Chi Deve Istituire un Sistema PMM?

Obbligatorio per:

• Fornitori di sistemi AI ad alto rischio autonomi dell'Allegato III — sistemi elencati nell'Allegato III che non sono componenti di sicurezza di un prodotto (ad es. IA utilizzata nelle decisioni occupazionali, nell'accesso all'istruzione, nell'attività di contrasto, nella valutazione del merito creditizio, nella gestione delle infrastrutture critiche)
• Fornitori di sistemi AI integrati nell'Allegato I — componenti di sicurezza AI integrati in prodotti coperti dalla normativa UE di armonizzazione esistente (dispositivi medici, macchinari, veicoli)

Non richiesto per:

• Fornitori di sistemi AI a rischio minimo (nessun obbligo formale di PMM, anche se si applica la buona pratica)
• Fornitori di sistemi AI solo per la trasparenza (gli obblighi dell'Art. 50 non si estendono al PMM)
• Fornitori di modelli GPAI — questi sono soggetti a un regime separato ai sensi degli Art. 61–62, che include la segnalazione degli incidenti per i modelli a rischio sistemico ma è strutturato diversamente dal PMM dell'Art. 72

Il ruolo del deployer è di supporto ma non opzionale. I deployer devono utilizzare il sistema AI in conformità con le istruzioni del fornitore, attivare e conservare la funzionalità di registrazione integrata nel sistema e — in modo cruciale — segnalare al fornitore eventuali incidenti gravi di cui vengono a conoscenza senza ingiustificato ritardo. Un deployer che osserva un incidente grave e non lo notifica al fornitore non è conforme.

Il Piano di Monitoraggio Post-Commercializzazione (Allegato IV, Punto 12)

Il piano PMM è un componente obbligatorio della documentazione tecnica (Allegato IV). Non può essere un documento generico: deve essere specifico per il sistema, il suo contesto di dispiegamento e i rischi identificati. Come minimo, deve definire:

1. Raccolta dei dati — quali metriche di prestazione vengono acquisite (accuratezza, tassi di errore, esiti delle decisioni), come vengono raccolti i dati (telemetria automatizzata, segnalazioni dei deployer, feedback degli utenti) e con quale frequenza
2. Cicli di feedback — il meccanismo con cui i deployer possono segnalare al fornitore problemi di prestazione, anomalie o incidenti in modo strutturato e tempestivo
3. Monitoraggio dell'accuratezza — come le prestazioni del sistema vengono monitorate rispetto al benchmark validato utilizzato durante la valutazione della conformità, inclusa qualsiasi metodologia di rilevamento del drift
4. Monitoraggio del pregiudizio — per i sistemi in cui i risultati demografici sono rilevanti (assunzione, credito, attività di contrasto), monitoraggio continuo delle disparità statistiche tra i gruppi protetti, con metodologia e soglie definite
5. Trigger di aggiornamento — le soglie specifiche quantitative o qualitative che richiedono un'azione correttiva, incluso il riaddestramento del modello, la regolazione dei parametri o la sospensione del dispiegamento
6. Calendario di revisione — con quale frequenza il piano PMM stesso viene rivisto e aggiornato, assicurando che rimanga adeguato man mano che il contesto di dispiegamento evolve

Il piano PMM deve essere aggiornato. Un piano obsoleto che non riflette più la metodologia di monitoraggio effettiva non soddisfa l'Art. 72.

Segnalazione degli Incidenti Gravi (Art. 73)

Cosa costituisce un incidente grave?

L'articolo 73 definisce un incidente grave come qualsiasi incidente o malfunzionamento di un sistema AI ad alto rischio che porta direttamente o indirettamente a:

• Morte o danno grave alla salute (fisico o psicologico)
• Una perturbazione grave e irreversibile della gestione o del funzionamento di infrastrutture critiche
• Una grave violazione dei diritti fondamentali (privacy, non discriminazione, dovuto processo)
• Una situazione in cui una persona ha evitato per poco uno qualsiasi dei precedenti

Significativamente, il Regolamento sull'IA non richiede che prima della segnalazione venga stabilito un nesso causale con il sistema AI. Un ragionevole sospetto che il sistema AI abbia contribuito al danno o non lo abbia impedito è sufficiente per attivare l'obbligo. I fornitori che aspettano la certezza prima di segnalare rischiano la non conformità.

Cronologie di segnalazione

Il termine di 15 giorni inizia quando il fornitore viene a conoscenza dell'incidente — il che, in pratica, significa quando il deployer lo notifica. I fornitori dovrebbero progettare le proprie procedure di notifica dei deployer in modo che le informazioni li raggiungano abbastanza rapidamente da soddisfare la scadenza di segnalazione a valle.

Cosa deve contenere una segnalazione di incidente

Una segnalazione di incidente conforme all'autorità nazionale di vigilanza del mercato dovrebbe includere:

• Identificazione del sistema: nome, versione, numero di registrazione nella banca dati UE
• Descrizione dell'incidente: cosa è successo, quale danno si è verificato o è stato evitato per poco, data e luogo
• Persone interessate: numero e categorie di utenti o terzi interessati (anonimizzati ove richiesto dal GDPR)
• Analisi causale preliminare: la comprensione attuale del fornitore di come si è verificato l'incidente, chiaramente etichettata come preliminare
• Misure correttive o di sicurezza immediate adottate: eventuali passi già compiuti per limitare ulteriori danni o rischi (ad es. sospensione delle funzionalità interessate, notifiche ai deployer)
• Punto di contatto: la persona o il team responsabile della corrispondenza di follow-up con l'autorità

La segnalazione dovrebbe essere fattuale e proporzionata. Le segnalazioni preliminari possono essere integrate da segnalazioni successive man mano che l'indagine progredisce.

Registrazione Obbligatoria (Art. 12)

L'articolo 12 richiede che i sistemi AI ad alto rischio siano progettati e sviluppati con la capacità di generare automaticamente registri con un livello di granularità sufficiente a consentire:

• Il monitoraggio post-commercializzazione ai sensi dell'Art. 72
• La tracciabilità degli eventi che portano a un incidente grave
• L'indagine da parte delle autorità nazionali

Questo è un requisito di progettazione imposto al fornitore. Il fornitore deve integrare la capacità di registrazione nel sistema prima che venga immesso sul mercato.

L'obbligo di attivare e conservare tali registri spetta al deployer. I deployer non devono disabilitare la funzionalità di registrazione e devono conservare i registri per il periodo specificato nelle istruzioni del fornitore e nella documentazione tecnica. Dove non è definito alcun periodo di conservazione specifico, i registri dovrebbero essere conservati per un periodo commisurato al ciclo di vita operativo del sistema e a eventuali requisiti settoriali specifici (ad es. norme di conservazione dei registri dei servizi finanziari ai sensi di DORA o MiFID II).

Modifiche Sostanziali e Nuova Valutazione

Non ogni modifica a un sistema AI dispiegato attiva una nuova valutazione della conformità. Il Regolamento distingue tra aggiornamenti minori e modifiche sostanziali.

Una modifica è sostanziale — e richiede una nuova valutazione della conformità e documentazione tecnica aggiornata — quando:

• Modifica lo scopo previsto del sistema (anche parzialmente)
• Comporta una modifica significativa dell'architettura o della metodologia di addestramento
• Utilizza nuovi dati di addestramento che influenzano materialmente le prestazioni del sistema in modi che potrebbero influenzare il comportamento rilevante per la conformità
• Degrada le prestazioni al di là delle soglie definite nella documentazione della gestione del rischio in modi che incidono sulla sicurezza o sui diritti fondamentali

Gli aggiornamenti minori — patch di sicurezza, correzioni di bug che correggono difetti chiaramente identificati senza alterare il comportamento rilevante per la conformità, modifiche estetiche all'interfaccia — non richiedono una nuova valutazione completa. Tuttavia, devono essere documentati, e il fornitore deve conservare una valutazione scritta che confermi che la modifica non costituisce una modifica sostanziale. Tale registro è soggetto a ispezione da parte delle autorità di vigilanza del mercato.

Lista di Controllo Pratica di Implementazione

La seguente lista di controllo riflette i requisiti operativi minimi ai sensi degli Art. 72, Art. 73 e Art. 12. Non sostituisce la consulenza legale ma fornisce un punto di partenza per l'analisi dei gap.

• [ ] Piano PMM documentato nel fascicolo tecnico (Allegato IV, punto 12), specifico per il sistema e il suo contesto di dispiegamento
• [ ] Capacità di registrazione automatica progettata e integrata nel sistema prima dell'immissione sul mercato
• [ ] Le istruzioni per i deployer includono una chiara procedura di segnalazione degli incidenti scritta con contatto di escalation
• [ ] Punto di contatto per la segnalazione degli incidenti istituito internamente e notificato all'autorità nazionale di vigilanza del mercato competente
• [ ] Processi o dashboard di monitoraggio del pregiudizio e dell'accuratezza definiti, con metodologia e soglie documentate
• [ ] Soglie di escalation per le azioni correttive documentate e collegate al sistema di gestione del rischio
• [ ] Procedura di valutazione delle modifiche sostanziali in atto, con un modello di registro delle decisioni per ogni aggiornamento
• [ ] Politica di conservazione dei registri definita, comunicata ai deployer e allineata con le norme di conservazione settoriali

Riferimenti incrociati: Documentazione Tecnica — Sistemi AI ad Alto Rischio dell'Allegato III — Fornitori vs. Deployer