Piano di monitoraggio post-commercializzazione per agenti AI: cosa richiede l'Articolo 72 dell'AI Act UE

Partite dalla classificazione, non dalle etichette

Gli agenti AI non costituiscono una categoria giuridica separata nell'AI Act. Il fattore che fa scattare l'Articolo 72 non è la parola agente. Il fattore rilevante è se il sistema sia classificato come ad alto rischio oppure faccia parte di un sistema ad alto rischio.

Un assistente interno che prepara verbali di riunione non è trattato allo stesso modo di un agente impiegato nel credit underwriting, nel triage dei sinistri, nelle assunzioni, nella verifica dell'identità, nel supporto alle decisioni della pubblica amministrazione o in altri casi d'uso dell'Allegato III. Se non avete ancora svolto il lavoro di classificazione, iniziate da Classificazione dei sistemi di AI ad alto rischio ai sensi dell'AI Act UE e Conformità degli agenti AI ai sensi dell'AI Act UE. Una volta che il sistema rientra nel perimetro, il monitoraggio post-commercializzazione diventa parte del modello operativo, non una best practice opzionale.

Che cosa richiede davvero l'Articolo 72

L'Articolo 72 richiede ai fornitori di sistemi di AI ad alto rischio di istituire e documentare un sistema di monitoraggio post-commercializzazione proporzionato alla natura della tecnologia AI e ai rischi del sistema. Il monitoraggio deve restare attivo per tutto il ciclo di vita del sistema.

In pratica, l'obbligo si articola in cinque elementi. Occorre raccogliere, documentare e analizzare in modo attivo e sistematico dati pertinenti successivi al rilascio; valutare la conformità continua ai requisiti del Capitolo III, Sezione 2; includere, ove rilevante, le interazioni con altri sistemi AI; basare il sistema di monitoraggio su un piano di monitoraggio post-commercializzazione; e mantenere quel piano all'interno del pacchetto documentale dell'Allegato IV. I processi settoriali già esistenti possono essere riutilizzati quando il diritto dell'Unione richiede già una governance equivalente, ma solo se il risultato integrato garantisce comunque lo stesso livello di protezione.

• Raccogliere dati pertinenti successivi al rilascio in modo sistematico, non episodico.
• Riesaminare i dati rispetto ai requisiti di conformità continui, non solo ai KPI di prodotto.
• Catturare le interazioni con altri sistemi AI e strumenti esterni quando sono rilevanti.
• Documentare il piano nell'Allegato IV in modo che un revisore possa capire come funziona davvero il monitoraggio.
• Integrare i processi settoriali esistenti solo quando il livello di protezione resta equivalente.

Una dashboard non è un piano

Il fallimento più comune consiste nel confondere l'osservabilità con la conformità. Una dashboard può indicare latenza, tasso di successo, costo o utilizzo dei token. Un piano di monitoraggio post-commercializzazione dovrebbe invece spiegare a un revisore quali rischi sono monitorati, quali segnali dimostrano che i controlli continuano a funzionare, quali soglie attivano l'escalation, chi riesamina cosa e come vengono documentate le azioni correttive.

Per questo il monitoraggio post-commercializzazione è strettamente collegato alla Checklist dell'Articolo 17 dell'AI Act UE, a Audit trail degli agenti AI: dai log alle evidenze e al vostro pacchetto probatorio sottostante. Se non riuscite a dimostrare come la telemetria diventi evidenza riesaminata, non disponete ancora di un modello operativo conforme all'Articolo 72.

• Quali rischi vengono monitorati: collegamento diretto al registro dei rischi di cui all'Articolo 9.
• Quali segnali contano: non solo output, ma chiamate agli strumenti, approvazioni, override ed effetti a valle.
• Quali soglie contano: che cosa è solo informativo, che cosa richiede revisione in giornata e che cosa congela la produzione.
• Quali registrazioni sopravvivono a un audit: incidenti, razionali dei revisori, azioni correttive ed esportazioni di evidenze collegate alla versione.

Perché l'Articolo 72 conta ancora di più per gli agenti AI

I sistemi di previsione statici possono fallire in silenzio. Gli agenti falliscono attraverso più sistemi. Recuperano dati, chiamano strumenti, attivano workflow, delegano attività ad altri modelli e operano con livelli diversi di autonomia. Questo significa che il monitoraggio degli agenti deve essere a livello di workflow, non soltanto a livello di modello.

La logica alla base del monitoraggio post-commercializzazione è particolarmente rilevante per i sistemi agentici anche quando il modello non viene riaddestrato continuamente. Il rischio emergente può derivare da modifiche ai prompt, aggiornamenti delle policy, sostituzioni del modello, ampliamento dell'accesso agli strumenti, cambiamenti nel retrieval, deriva nelle integrazioni o modifiche del workflow effettuate dal deployer. Il sistema può diventare più rischioso senza che si verifichi alcun classico ciclo di addestramento.

• Esecuzione degli strumenti: azioni fallite, retry, effetti collaterali e tentativi non autorizzati.
• Segnali di controllo delle policy: dinieghi, quasi-dinieghi, code di approvazione e motivi degli override.
• Comportamento cross-system: che cosa accade quando l'agente dipende da altri servizi AI o automazioni esterne.
• Risultati rilevanti per i diritti: disparità, reclami, ricorsi ed effetti dannosi materiali a valle.

Che cosa deve contenere un piano difendibile ai sensi dell'Articolo 72

Un piano difendibile non deve essere lungo per sembrare serio. Deve essere abbastanza specifico da permettere a un revisore di capire come si rileva il degrado, chi indaga sulle anomalie e come le evidenze rientrano nella conformità e nel change control.

Per gli agenti AI, il piano dovrebbe normalmente includere almeno i seguenti elementi. È anche il punto in cui molti team affiancano il requisito legale al Template del piano di monitoraggio post-commercializzazione, al Playbook della procedura di supervisione umana e alla Checklist del pacchetto probatorio, così che il processo resti utilizzabile da team di engineering e operations, non solo dai legali.

• Identificazione del sistema e finalità prevista: nome esatto del sistema, versione, entità fornitrice, ambito del rilascio, contesto di deployment, utenti interessati, confini e logica di classificazione ad alto rischio.
• Obiettivi di monitoraggio collegati al registro dei rischi: ogni rischio materiale dovrebbe avere almeno un segnale monitorato, un owner e un percorso di escalation.
• Fonti dei dati e metodi di raccolta: log di esecuzione, trace degli strumenti, eventi di approvazione, registri degli override, reclami, output campionati, ticket di incidente e registri dei cambiamenti di integrazione.
• Metriche, soglie e livelli di gravità: tasso di fallimento dei task, tasso di errore degli strumenti, tasso di allucinazioni o azioni non supportate dove rilevante, frequenza degli override, indicatori di disparità, eventi di rollback e logica di conseguenza legata alle soglie.
• Policy di campionamento e cadenza di revisione: telemetria always-on, revisione al 100% delle azioni critiche, campionamento di base per output a minor rischio e revisione intensificata dopo release, model swap o incidenti.
• Dati di supervisione umana e intervento: cosa è stato escalato, chi lo ha riesaminato, quale contesto ha visto, che cosa ha modificato e se lo stesso pattern di errore si sta ripetendo.
• Gestione degli incidenti e collegamento con l'Articolo 73: chi indaga, cosa diventa incidente, quali scadenze verso le autorità si applicano e come viene identificato e provato l'avvio del termine di segnalazione.
• Azione correttiva e controllo delle modifiche: chi può sospendere, disabilitare, effettuare rollback o ritirare il sistema e come i risultati post-commercializzazione rientrano nella gestione dei rischi dell'Articolo 9 e nel sistema qualità dell'Articolo 17.
• Conservazione delle evidenze e prontezza per l'audit: come log, note dei revisori, incidenti e azioni correttive vengono conservati, protetti, collegati alle versioni ed esportati per la revisione regolatoria.

Quando il monitoraggio diventa segnalazione ai sensi dell'Articolo 73

Il vostro piano di monitoraggio dovrebbe indicare chiaramente quando un alert diventa un incidente, chi possiede il triage e quando si attiva la segnalazione ai sensi dell'Articolo 73. Quel termine non dovrebbe essere lasciato all'improvvisazione.

Nel quadro attuale dell'Articolo 73, il termine esterno ordinario è di 15 giorni da quando il fornitore o il deployer viene a conoscenza di un incidente grave. Il termine esterno è di 2 giorni per violazioni diffuse di obblighi destinati a proteggere diritti fondamentali o per interruzioni gravi e irreversibili di infrastrutture critiche, e di 10 giorni nel caso di decesso, una volta stabilita la causalità o il ragionevole sospetto di causalità. Il punto operativo è semplice: soglie e regole di escalation devono far emergere questi scenari con la rapidità necessaria per rendere ancora possibile la segnalazione.

• Decesso o grave danno alla salute richiedono il triage più rapido e un percorso decisionale sulla causalità chiaramente documentato.
• Interruzione grave e irreversibile di infrastrutture critiche dovrebbe bypassare le code lente di revisione interna.
• Violazioni dei diritti fondamentali non sono questioni legali astratte; richiedono trigger operativi collegati a reclami, override, ricorsi ed esiti dannosi a valle.
• Le azioni correttive ai sensi dell'Articolo 20 dovrebbero essere integrate nello stesso workflow, in modo che la mitigazione non debba attendere la chiusura della reportistica finale.

I fornitori hanno la responsabilità dell'Articolo 72, ma i deployer lo alimentano

L'Articolo 72 è un obbligo del fornitore, ma il fornitore spesso non controlla l'intero contesto operativo. I deployer possono detenere i registri dei reclami, le note di revisione umana, i ticket di incidente di prima linea o i dati sugli esiti a valle che rendono significativo il monitoraggio.

Per i sistemi agentici, i contratti tra fornitore e deployer dovrebbero specificare quali dati il deployer deve restituire, con quale rapidità devono essere escalati incidenti gravi e quasi-incidenti, come si conservano i registri degli override e come si comunicano le modifiche al workflow o alle integrazioni. Se questa interfaccia non viene progettata, il piano appare completo sulla carta ma fallisce in produzione.

• Obblighi di ritorno dei dati per reclami, override, ricorsi e metriche sugli esiti.
• Canali di segnalazione degli incidenti con contatti nominativi e mappatura delle giurisdizioni.
• Notifiche di modifica quando il deployer altera prompt, strumenti, workflow o controlli circostanti.
• Regole di conservazione ed esportazione per evitare che le evidenze post-commercializzazione si frammentino tra sistemi diversi.

La posizione su template e timeline a marzo 2026

La formulazione più prudente, secondo il diritto vigente, è questa: la questione del template è ancora aperta; l'obbligo del fornitore no. Il testo attuale dell'Articolo 72 continua a fare riferimento a un atto di esecuzione della Commissione per un template del piano. Tuttavia, il 19 novembre 2025 la Commissione ha proposto di sostituire tale prescrizione con orientamenti, anziché con un formato armonizzato di piano. La proposta è ancora in esame e quindi non modifica il diritto oggi in vigore.

La stessa cautela vale per la timeline. In base all'attuale AI Act, la maggior parte degli obblighi per i sistemi ad alto rischio si applica dal 2 agosto 2026, mentre alcuni sistemi di AI ad alto rischio integrati in prodotti regolamentati beneficiano di una transizione più lunga fino al 2 agosto 2027. La Commissione ha proposto modifiche alla timeline, ma tali modifiche non sono ancora legge. La mossa pratica consiste nel costruire ora un piano verificabile e adeguarne il formato in seguito, se la Commissione finalizzerà orientamenti o modifiche legislative relative al template.

• Testo attuale dell'Articolo 72: Sintesi dell'AI Act Service Desk sull'Articolo 72
• Tempistiche attuali sugli incidenti gravi: Sintesi dell'AI Act Service Desk sull'Articolo 73
• FAQ della Commissione sulla timeline di attuazione: Navigating the AI Act
• FAQ della Commissione sulla standardizzazione: Understanding the standardisation of the AI Act
• Proposta della Commissione ancora in esame: COM(2025) 811 final

Errori comuni che fanno fallire la revisione di un piano ai sensi dell'Articolo 72

I fallimenti sono di solito operativi, non teorici. I team scrivono il piano come se fosse un memo, ma regolatori e auditor lo tratteranno come evidenza di una capacità operativa viva.

Se desiderate un test pratico di revisione, chiedetevi se un terzo potrebbe leggere il vostro piano e capire come viene monitorato il sistema, chi indaga sulle anomalie, come le modifiche in produzione influenzano il campionamento e che cosa viene segnalato o riportato indietro quando le soglie vengono superate.

• Trattare il monitoraggio post-commercializzazione come una dashboard invece che come una procedura operativa.
• Monitorare solo la qualità del modello ignorando uso degli strumenti, approvazioni, override ed effetti a valle.
• Elencare metriche senza soglie, owner nominativi, logica di gravità o tempi di risposta.
• Dimenticare le interazioni con altri sistemi AI nei workflow agentici.
• Conservare i log grezzi ma non le decisioni sugli incidenti, il razionale dei revisori o le evidenze delle azioni correttive.
• Scollegare il monitoraggio dal controllo delle modifiche, così che ogni release azzeri il rischio senza un ciclo di revisione più stringente.
• Presumere che la documentazione del vendor del modello sostituisca il monitoraggio a livello di sistema svolto dal fornitore.