Monitoraggio post-commercializzazione AI Act: articolo 72

Il provider deve istituire e documentare un sistema proporzionato ai rischi, fondato su un piano incluso nella documentazione tecnica. Il deployer monitora il funzionamento secondo le istruzioni e, ove pertinente, informa il provider; ciò non comporta l’invio automatico di tutti i log.

Regolamento UE 2026/1744 e articolo 72

Il Regolamento (UE) 2026/1744 sostituisce il paragrafo 3 dell’articolo 72 del Regolamento (UE) 2024/1689. La formulazione modificata stabilisce che il sistema di monitoraggio post-commercializzazione si basi su un piano e che il piano faccia parte della documentazione tecnica prevista dall’allegato IV.

La stessa disposizione prevede che la Commissione, tenendo nella massima considerazione il parere del comitato per l’IA, adotti orientamenti, incluso un modello del piano, entro il 2 settembre 2027. Il modello non deve quindi essere trattato come già adottato sulla base del solo testo del regolamento modificativo. L’atto modificativo non rende superfluo il sistema di monitoraggio: modifica il contenuto del paragrafo 3 e conserva il piano come elemento centrale della documentazione.

Il regolamento modificativo è stato pubblicato il 24 luglio 2026 ed è entrato in vigore il 27 luglio 2026. Questa data non coincide automaticamente con il calendario applicativo di ogni obbligo relativo ai sistemi ad alto rischio. Il nuovo testo dell’articolo 113 rinvia l’applicazione del capo III, sezioni 1, 2 e 3, al 2 dicembre 2027 per i sistemi classificati ad alto rischio ai sensi dell’articolo 6, paragrafo 2, e dell’allegato III, e al 2 agosto 2028 per quelli dell’articolo 6, paragrafo 1, e dell’allegato I. Poiché l’articolo 72 disciplina il monitoraggio dei sistemi ad alto rischio, la sua operatività per un sistema concreto va coordinata con la classificazione applicabile, l’articolo 111 sui sistemi già immessi sul mercato e le altre disposizioni transitorie.

Il testo dell’articolo 72 nell’AI Act Service Desk contiene un avviso: la pagina visualizzata non è ancora aggiornata alle modifiche del Digital Omnibus. La pagina resta utile per la struttura e per il testo precedente dell’articolo, mentre il nuovo paragrafo 3 deve essere verificato nel regolamento modificativo. Il passaggio relativo al precedente modello e alla precedente scadenza non va confuso con la nuova disciplina.

Che cosa deve organizzare il provider

Il testo dell’articolo 72 richiede al provider di raccogliere, documentare e analizzare attivamente e sistematicamente dati pertinenti sulle prestazioni dei sistemi di IA ad alto rischio per tutta la durata del loro ciclo di vita. I dati possono essere forniti dai deployer o raccolti tramite altre fonti.

Il risultato atteso è consentire al provider di valutare la costante conformità del sistema ai requisiti del capo III, sezione 2. Ove pertinente, il monitoraggio comprende anche l’interazione con altri sistemi di IA. La disposizione esclude dall’obbligo i dati operativi sensibili dei deployer che sono autorità di contrasto. Questa esclusione riguarda quella categoria specifica e non costituisce una regola generale per ogni organizzazione utilizzatrice.

La proporzionalità è un criterio espresso dalla disposizione. La sua attuazione concreta dipende dal sistema, dalla destinazione d’uso e dai rischi da controllare. Un sistema che opera su documenti, per esempio, può richiedere osservazioni sulle prestazioni di classificazione; il dato pertinente deve però essere individuato in rapporto alla funzione del sistema e alla valutazione di conformità, non scelto per automatismo.

L’articolo 72 non impone una piattaforma, un repository o una specifica architettura MLOps. Dashboard, ticket, audit trail e strumenti di osservabilità possono essere utilizzati come scelte progettuali. Restano strumenti organizzativi e tecnici da rapportare al sistema concreto.

Piano e documentazione tecnica

Poiché il piano fa parte della documentazione tecnica dell’allegato IV, il provider dovrebbe mantenerlo coerente con la versione del sistema, la destinazione d’uso e le istruzioni per l’uso. Questa è una raccomandazione operativa collegata alla funzione documentale del piano. Diventa particolarmente rilevante quando cambiano il modello, i dati, l’integrazione applicativa o il contesto nel quale il sistema viene utilizzato.

Una possibile struttura può descrivere le fonti informative, le prestazioni osservate, il momento o la frequenza dell’analisi e il trattamento dei segnali rilevati. Metriche di accuratezza, soglie di allarme, indicatori di drift e frequenze di raccolta non sono presentati come contenuti imposti espressamente dall’articolo 72. Si tratta di elementi progettuali da validare rispetto alla finalità del sistema, ai dati disponibili e al rischio da valutare.

Lo stesso vale per una procedura che associ ogni segnale a una valutazione tecnica, a una verifica della conformità e, se necessario, a una decisione documentata. La procedura può rendere leggibile il collegamento tra dato osservato e azione successiva, ma non va trasformata in un elenco tassativo ricavato dalla disposizione.

Il testo ufficiale dell’articolo 26 attribuisce al deployer un compito complementare: monitorare il funzionamento del sistema sulla base delle istruzioni per l’uso e, ove pertinente, informare il provider conformemente all’articolo 72. Per la distinzione dei ruoli, consulta gli obblighi generali del deployer ai sensi dell’articolo 26 e la differenza tra provider e deployer nell’AI Act.

Flusso informativo del deployer

Il deployer osserva il sistema nel contesto in cui lo utilizza. Un’anomalia nella prestazione o un comportamento non coerente con le istruzioni può costituire un segnale pertinente per il monitoraggio del provider. La trasmissione effettiva dipende dalla pertinenza dell’informazione, dalle istruzioni per l’uso e dal flusso organizzativo definito per quel sistema.

Come interpretazione testuale, dal testo dell’articolo 72 non risulta un elenco tassativo di campi che ogni deployer debba trasferire al provider. Non si ricava quindi, da solo, un obbligo generalizzato di inviare tutti i log grezzi, tutti gli input degli utenti, gli output completi o i dati identificativi.

Un contratto o un’istruzione per l’uso può definire un flusso più dettagliato, purché la soluzione sia compatibile con le altre norme applicabili. La pertinenza va valutata rispetto alle prestazioni e alla conformità del sistema. Un classificatore di documenti e uno strumento che supporta una decisione interna possono richiedere segnali differenti: l’esempio mostra la necessità di collegare la selezione delle informazioni al caso concreto, senza introdurre un requisito ulteriore.

Una possibile architettura tecnica

L’articolo 72 non prescrive una specifica architettura. Come proposta progettuale, il provider può separare la raccolta degli eventi, il filtraggio delle informazioni pertinenti, l’analisi delle prestazioni e la registrazione delle decisioni.

Un primo livello può ricevere dati dal deployer o da altre fonti individuate dal provider. Un secondo livello può distinguere le informazioni utili alla valutazione da quelle prive di collegamento con il monitoraggio. Un terzo può sottoporre le anomalie a una valutazione tecnica e documentale. L’audit trail può registrare il segnale ricevuto, l’analisi svolta, il soggetto responsabile e l’eventuale escalation.

Questa impostazione può aiutare quando il sistema viene aggiornato o integrato in applicazioni diverse. Il piano può indicare quali componenti alimentano l’osservabilità e come viene mantenuta la corrispondenza tra versione osservata, istruzioni per l’uso e risultato dell’analisi. Si tratta però di una raccomandazione di governance tecnica, non di un obbligo testuale dell’articolo 72.

Dati pertinenti e conservazione dei log

L’articolo 26 disciplina anche la conservazione dei log generati automaticamente dal sistema, nella misura in cui siano sotto il controllo del deployer. Il periodo deve essere adeguato alla finalità del sistema e comunque di almeno sei mesi, salvo diversa previsione del diritto dell’Unione o nazionale, in particolare in materia di protezione dei dati personali.

Questa regola riguarda la conservazione dei log. Il loro eventuale trasferimento al provider è una questione distinta: il fatto che un log debba essere conservato dal deployer non dimostra, da solo, che debba essere inviato per il monitoraggio post-commercializzazione. Il flusso deve essere collegato ai dati pertinenti, alle istruzioni applicabili e al sistema concreto.

GDPR nello scambio tra provider e deployer

Quando il flusso comprende dati personali, il GDPR continua ad applicarsi. La verifica non può essere assorbita dall’articolo 72: occorre individuare le finalità effettive, la necessità dei dati trasferiti, la base giuridica, i ruoli privacy, i tempi di conservazione e le misure di sicurezza. Le qualifiche di provider e deployer nell’AI Act non determinano, da sole, chi sia titolare o responsabile del trattamento ai sensi del GDPR.

Il principio operativo è selezionare le informazioni necessarie al monitoraggio senza trasformare il flusso in una raccolta indiscriminata. Se bastano evento, versione del sistema, categoria dell’anomalia e risultato della verifica, l’invio di input e output completi richiede una giustificazione ulteriore. La soluzione dipende però dal sistema e dai trattamenti effettivi; non esiste una configurazione privacy universale ricavabile dal solo articolo 72.

Per gli aspetti collegati, consulta gli approfondimenti su data drift e rivalutazione del sistema, sul rapporto tra DPIA e FRIA e sulla governance GDPR per SaaS e software house.

Monitoraggio ordinario e incidenti gravi

Il monitoraggio post-commercializzazione dell’articolo 72 osserva prestazioni e conformità durante il ciclo di vita. La segnalazione degli incidenti gravi segue invece l’articolo 73 e si attiva quando ricorre un incidente grave secondo la disciplina applicabile. Un degrado delle prestazioni, un data drift o un model drift non sono automaticamente incidenti gravi: possono essere segnali da analizzare nel monitoraggio ordinario.

Se il deployer individua un incidente grave, l’articolo 26 prevede che informi immediatamente prima il provider e poi l’importatore o distributore e le autorità di vigilanza del mercato pertinenti. Se il provider non è raggiungibile, l’articolo 73 si applica mutatis mutandis. L’articolo 26 disciplina anche il caso in cui il deployer ritenga che l’uso conforme alle istruzioni possa comportare un rischio.

Il testo dell’articolo 73 attribuisce, come regola generale, ai provider di sistemi di IA ad alto rischio l’obbligo di segnalare gli incidenti gravi alle autorità di vigilanza del mercato degli Stati membri nei quali l’incidente si è verificato. Questa regola opera fatto salvo l’articolo 75, paragrafo 1 bis, introdotto dal Regolamento (UE) 2026/1744: per i sistemi soggetti alla competenza dell’Ufficio per l’IA, il provider segnala l’incidente all’Ufficio per l’IA, che trasmette le informazioni all’autorità di vigilanza del mercato competente.

La regola generale dell’articolo 73 prevede una segnalazione immediata dopo l’accertamento del nesso causale, o della sua ragionevole probabilità, e comunque non oltre 15 giorni da quando il provider o, se pertinente, il deployer viene a conoscenza dell’incidente grave. Per una violazione diffusa o per l’incidente grave di cui all’articolo 3, punto 49, lettera b), la segnalazione deve essere immediata e comunque entro due giorni dalla conoscenza dell’evento. In caso di decesso di una persona, deve essere effettuata immediatamente dopo l’accertamento o il sospetto del nesso causale e comunque entro dieci giorni dalla conoscenza dell’incidente.

La qualificazione dell’evento e l’autorità destinataria devono essere verificate sul testo applicabile e sul sistema interessato. Per separare il monitoraggio ordinario dalla gestione degli incidenti, consulta la notifica degli incidenti gravi secondo l’AI Act.

Verifiche operative finali

Il provider dovrebbe verificare che il piano sia collegato alla documentazione tecnica, alla versione del sistema e alle istruzioni per l’uso. Il deployer dovrebbe verificare di poter monitorare il funzionamento nel proprio contesto, conservare i log sotto il proprio controllo e comunicare le informazioni pertinenti attraverso un canale identificato.

È utile distinguere le anomalie ordinarie, le valutazioni di conformità e gli incidenti gravi. Un audit trail può rendere ricostruibili la segnalazione ricevuta, la valutazione svolta, il soggetto responsabile e l’eventuale escalation. Anche questa è una raccomandazione tecnica: l’articolo 72 impone il sistema e il piano, non una specifica implementazione.

Domande frequenti

Chi deve predisporre il piano di monitoraggio post-commercializzazione?

Il piano rientra nel sistema di monitoraggio che il provider deve istituire e documentare per il sistema di IA ad alto rischio. Fa parte della documentazione tecnica.

L’articolo 72 impone al deployer di inviare tutti i log al provider?

No. L’articolo 72 riguarda dati pertinenti sulle prestazioni, forniti dai deployer o raccolti da altre fonti. Dal testo esaminato non risulta un obbligo di trasferire tutti i log grezzi.

Qual è il rapporto tra monitoraggio del deployer e monitoraggio del provider?

Il deployer monitora il funzionamento sulla base delle istruzioni per l’uso e, ove pertinente, informa il provider conformemente all’articolo 72. Il flusso operativo deve essere definito in relazione al sistema concreto.

Ogni degrado delle prestazioni è un incidente grave da notificare?

No. Il monitoraggio ordinario dell’articolo 72 è distinto dalla segnalazione degli incidenti gravi prevista dall’articolo 73. La qualificazione dell’evento deve essere valutata secondo la disciplina applicabile.

Verifica la tua situazione rispetto al piano, al flusso provider-deployer e alla documentazione tecnica.