Come monitorare i sistemi di IA ai sensi dell'EU AI Act
Quando un sistema di IA è in funzione, la legge non chiede più «è stato costruito correttamente?» ma «si sta ancora comportando correttamente?». Ai sensi dell'EU AI Act, monitorare un sistema di IA in esercizio è un obbligo giuridico continuativo, non un'aggiunta facoltativa. Questa guida illustra cosa monitorare, chi è responsabile, come dimensionare lo sforzo in base al livello di rischio del sistema e una distinzione che mette in difficoltà la maggior parte dei team: monitorare un sistema di IA non equivale a monitorare le persone che lo usano.
Il monitoraggio è un obbligo giuridico, non un optional
Diversi articoli dell'AI Act, letti insieme, rendono il monitoraggio continuo obbligatorio per i sistemi di IA ad alto rischio:
- Monitoraggio successivo all'immissione sul mercato (Articolo 72) — I fornitori devono raccogliere, documentare e analizzare in modo attivo e sistematico i dati sulle prestazioni del sistema durante tutto il suo ciclo di vita, per confermarne la conformità continua.
- Registrazione automatica (Articoli 12 e 19) — I sistemi ad alto rischio devono registrare automaticamente gli eventi durante il loro ciclo di vita e i registri vanno conservati per almeno sei mesi.
- Monitoraggio del deployer (Articolo 26) — Le organizzazioni che usano un sistema ad alto rischio devono sorvegliarne il funzionamento secondo le istruzioni per l'uso e segnalare rischi o incidenti gravi.
- Accuratezza e robustezza lungo il ciclo di vita (Articolo 15) — I livelli di prestazione dichiarati devono mantenersi costanti in produzione, non solo il giorno del lancio.
- Sorveglianza umana (Articolo 14) — La sorveglianza deve restare efficace durante l'uso del sistema, con la possibilità di interpretarne gli output, intervenire e arrestarlo.
- Segnalazione di incidenti gravi (Articolo 73) — Gli incidenti che causano danni gravi vanno segnalati alle autorità immediatamente e comunque entro 15 giorni dalla presa di conoscenza.
Le dieci dimensioni del monitoraggio di un sistema di IA
Professionalmente, monitorare un sistema di IA significa osservare dieci dimensioni lungo il suo ciclo di vita. Non serve un team di data science: la maggior parte si ricava da registri e revisioni che un responsabile della conformità già controlla.
| Dimensione | Cosa osservi | Un KPI che puoi davvero rendicontare |
|---|---|---|
| Prestazioni vs. base dichiarata | Accuratezza o qualità reale rispetto al valore dichiarato al momento del rilascio | Accuratezza osservata vs. dichiarata (es. 92% → 88,5%, −3,5 p.p.) |
| Deriva dei dati e del concetto | Se gli input — e la relazione tra input ed esito — si sono allontanati dall'addestramento | Indice di deriva per caratteristica chiave vs. soglia; % di input fuori distribuzione |
| Qualità dei dati | Integrità dei dati in ingresso prima che il modello li elabori | % di record che superano la convalida; tasso di valori nulli/obsoleti; record in quarantena |
| Affidabilità e latenza | Se il servizio è disponibile e abbastanza veloce come sistema operativo | % di uptime vs. SLA; latenza p95; tasso di errori tecnici |
| Distorsioni ed equità | Se gli esiti differiscono in modo ingiustificato tra gruppi protetti o sensibili | Disparità del tasso di selezione (regola dell'80%); divario nel tasso di errore tra gruppi |
| Sicurezza e abuso | Attacchi e usi impropri: prompt injection, input avversari, fuga di dati | Tentativi di jailbreak rilevati; tasso di attivazione delle barriere; fughe bloccate |
| Sorveglianza umana | Che una persona possa sorvegliare e correggere gli output in modo significativo | Tasso di override; % di decisioni ad alto impatto riviste da umani; escalation |
| Incidenti e quasi-incidenti | Esiti dannosi o errati e quelli intercettati in tempo | Incidenti per gravità; tempo di rilevamento/risoluzione; % segnalati entro la scadenza |
| Modifiche e versioni | Una cronologia verificabile di ogni modifica al sistema in esercizio | Versione attiva + data di rilascio; % di modifiche passate dal controllo di approvazione; rollback |
| Revisione periodica | Una ri-attestazione programmata che il sistema sia ancora idoneo all'uso previsto | % di revisioni puntuali; giorni di ritardo; sistemi con un'approvazione valida e aggiornata |
Chi monitora cosa: fornitore vs. deployer
La responsabilità è divisa tra l'organizzazione che costruisce il sistema (il fornitore) e quella che lo usa (il deployer). Molte aziende sono entrambe: acquistano un modello e lo integrano nel proprio prodotto.
Il fornitore integra nel sistema la capacità di monitoraggio, esegue il piano di monitoraggio successivo all'immissione sul mercato, conserva i registri sotto il proprio controllo, dichiara le metriche di accuratezza nelle istruzioni per l'uso e segnala gli incidenti gravi alle autorità.
Il deployer monitora il funzionamento quotidiano rispetto alle istruzioni per l'uso, conserva i propri registri per almeno sei mesi, informa fornitore e autorità di rischi o incidenti e — per gli enti pubblici e alcuni servizi — completa una valutazione d'impatto sui diritti fondamentali prima dell'avvio.
Monitorare in proporzione al rischio
L'AI Act si basa sul rischio, e così anche lo sforzo di monitoraggio. Non applicare l'intero apparato a ogni sistema: adatta la profondità al rischio e alle tue dimensioni:
- Sistemi ad alto rischio (Allegato III) — l'apparato completo: un piano di monitoraggio successivo all'immissione sul mercato documentato, registrazione automatica, sorveglianza umana, KPI su deriva e prestazioni e segnalazione degli incidenti gravi.
- Sistemi a rischio limitato / solo trasparenza — un approccio più leggero: monitoraggio d'uso di base, un referente per la sorveglianza e una revisione periodica, non l'intero apparato.
- PMI e piccole imprese a media capitalizzazione — l'Act consente espressamente una documentazione e una gestione della qualità semplificate e proporzionate. Dimensiona la profondità in base al rischio e alle dimensioni aziendali, anziché massimizzare ovunque.
Il Digital Omnibus (accordo provvisorio, maggio 2026) ha rinviato gli obblighi per l'alto rischio al 2 dicembre 2027 (Allegato III) e al 2 agosto 2028 (Allegato I) e ha sostituito il modello obbligatorio di piano di monitoraggio con un quadro flessibile. La lezione per qualsiasi impostazione di monitoraggio: costruisci una base configurabile, da riorientare man mano che arrivano le linee guida, non un sistema una tantum legato a un modulo fisso. (Queste modifiche sono concordate ma in attesa di pubblicazione definitiva: tratta le date come quasi definitive, non acquisite.)
Monitorare il sistema non è monitorare i dipendenti
Monitorare un sistema di IA non equivale a monitorare le persone che usano l'IA. Il primo osserva il modello e i suoi output ed è disciplinato dall'AI Act. Il secondo osserva il tuo personale — chi usa quale strumento di IA, quanto e per cosa — ed è sorveglianza sul lavoro, disciplinata dal GDPR, dalle norme ePrivacy e dal diritto del lavoro nazionale, non dall'AI Act.
Tracciare l'uso da parte dei dipendenti di uno strumento come un assistente di IA richiede di norma una base giuridica, una valutazione d'impatto sulla protezione dei dati, trasparenza preventiva e — in diversi Stati UE — un accordo sindacale prima di attivarlo (in Italia l'accordo previsto dall'articolo 4 dello Statuto dei lavoratori). Tieni i due programmi separati: titolari diversi, basi giuridiche diverse, evidenze diverse. Far rientrare la sorveglianza del personale nel «monitoraggio dell'IA» è un errore costoso.
Come si presenta una buona evidenza
Quando un auditor — o, sempre più, un soggetto che agisce ai sensi della Direttiva sulla responsabilità per danno da prodotti rivista — chiede come monitori, sono questi gli artefatti che rispondono:
- Un piano di monitoraggio successivo all'immissione sul mercato documentato, con KPI, soglie e cadenza di revisione definiti.
- Registri delle metriche nel tempo e gli allarmi generati al superamento di una soglia.
- Registri immodificabili dell'uso del sistema e di ogni intervento o override umano.
- Un registro degli incidenti con analisi delle cause profonde e prova della notifica tempestiva alle autorità.
- Un verbale di revisione periodica firmato che indichi il responsabile e la decisione di proseguire l'uso.
Come aiuta LandingRed: LandingRed trasforma tutto questo in un sistema funzionante — un piano di monitoraggio successivo all'immissione sul mercato per ogni sistema di IA, tracciamento dei KPI con allarmi di soglia che si trasformano automaticamente in incidenti, registri immodificabili ai sensi dell'Articolo 12 con conservazione applicata, verbali di sorveglianza umana e un pacchetto di evidenze pronto per l'audit — dimensionato al livello di rischio di ciascun sistema.
LandingRed automatizza tutto questo
Smetti di gestire la conformità in fogli di calcolo. Classifica, documenta, valuta e monitora i tuoi sistemi di IA da un'unica piattaforma.