Gli obblighi dell’EU AI Act — Regolamento (UE) 2024/1689 — descrivono proprietà che un sistema deve mostrare mentre gira, non documenti da produrre dopo. Gestione del rischio (art. 9), trasparenza (art. 13), supervisione umana (art. 14) e registrazione automatica degli eventi (art. 12) sono scritti come requisiti di processo, eppure ognuno ha una controparte tecnica che si misura: una soglia, un endpoint, un log immutabile, un tempo di risposta. Chi tratta la conformità come adempimento cartaceo si ritrova cartelle di evidenze; chi la tratta come architettura ottiene un sistema che le evidenze le emette da solo.

Problema

Il Regolamento è entrato in vigore il 1 agosto 2024 e si applica per fasi: i divieti dell’art. 5 dal 2 febbraio 2025, gli obblighi sui modelli per finalità generali (GPAI — General Purpose AI) dal 2 agosto 2025, gli obblighi sui sistemi ad alto rischio fissati in origine al 2 agosto 2026 (art. 113). Su quest’ultima scadenza pesa una proposta della Commissione del 19 novembre 2025, il Digital Omnibus on AI, che rinvia l’applicazione degli obblighi high-risk: 2 dicembre 2027 per i sistemi stand-alone dell’allegato III, 2 agosto 2028 per quelli incorporati in prodotti regolati dell’allegato I. Su quel testo Parlamento e Consiglio hanno trovato un accordo politico provvisorio il 7 maggio 2026, e il voto di conferma è atteso nella plenaria di giugno 2026. Resta una proposta in iter: finché non esce nella Gazzetta Ufficiale dell’Unione, le nuove date non vincolano e quelle del Regolamento originario restano il riferimento giuridico.

Il nodo, però, non dipende dalle date. Gli articoli 9-15 dell’AI Act dicono cosa deve fare un sistema ad alto rischio, non come dimostrarlo in modo ripetibile. L’art. 9 chiede un sistema di gestione del rischio «continuo e iterativo» per tutto il ciclo di vita; l’art. 12 chiede la registrazione automatica degli eventi («logs») per la tracciabilità; l’art. 14 chiede misure di supervisione umana «commisurate» ai rischi. Tre verbi normativi, zero metriche. Tradurre il requisito in un controllo verificabile tocca all’operatore, che oggi se la cava caso per caso, spesso con documenti che descrivono un’intenzione invece di misurare un comportamento.

Architettura

Ogni obbligo dell’AI Act si può riscrivere come proprietà osservabile del sistema. Non si reinterpreta il diritto: si sceglie l’evidenza che rende l’obbligo controllabile.

  • Gestione del rischio (art. 9) — proprietà: il sistema espone una soglia di rischio per ogni decisione e rifiuta o segnala quando la supera. Evidenza misurabile: la quota di decisioni corredate da uno score e da una motivazione, e il tasso di abstention quando la confidenza scende sotto soglia.
  • Accuratezza, robustezza, cybersicurezza (art. 15) — proprietà: il sistema tiene le metriche di accuratezza dichiarate e regge gli input avversari. Evidenza: i valori misurati su un set di validazione versionato, e il tempo medio per accorgersi di una manipolazione a runtime.
  • Trasparenza (art. 13) — proprietà: per ogni risposta il sistema sa restituire fonti dei dati, versione del modello e livello di confidenza. Evidenza: la latenza entro cui questa spiegazione arriva via API, non la sua presenza in un manuale.
  • Supervisione umana (art. 14) — proprietà: c’è un punto di intervento umano reale, con uno stato e l’autorità per bloccare. Evidenza: il tempo che passa tra la segnalazione e la capacità di interrompere, e il record di chi ha esercitato l’override.
  • Registrazione degli eventi (art. 12) — proprietà: ogni decisione lascia un record append-only, riconducibile a input, versione del modello e operatore. Evidenza: l’integrità verificabile del log (hashing concatenato, firma) e le ore che servono per estrarre la traccia di un singolo caso quando un’autorità la chiede.

Così la conformità si riscrive come un insieme di controlli, ognuno con un valore atteso, un metodo di misura e una soglia di accettazione. Non è un’invenzione: è il modello che i framework di gestione del rischio usano già. Il NIST AI RMF organizza il governo dei rischi nelle funzioni Govern, Map, Measure, Manage, e la funzione Measure esiste proprio per quantificare ciò che le altre tre presidiano. La ISO/IEC 42001 definisce un sistema di gestione dell’AI (AIMS) certificabile, con controlli e un ciclo di miglioramento auditabile. Entrambi danno la struttura entro cui i controlli elencati sopra diventano ripetibili e verificabili da terzi.

Punto critico

Lo scarto che conta è quello tra il requisito normativo e il controllo tecnico che lo rende verificabile; non è quello tra azienda conforme e azienda non conforme. Un’organizzazione può avere una policy di supervisione umana scritta a regola d’arte e nessun modo di dimostrare, a cose fatte, chi ha potuto interrompere il sistema e quando. La policy è documentazione; l’audit log firmato è architettura.

Tre proprietà distinguono un’evidenza che regge da una che descrive e basta:

  1. Immutabilità. Un log di conformità che si può modificare dopo i fatti non è un’evidenza. Serve append-only con integrità verificabile — log concatenati via hash, o firma con cosign o equivalenti — così che l’autorità possa accertare che la traccia non è stata riscritta.
  2. Riconducibilità a uno standard. Un controllo isolato vale poco; un controllo mappato a un requisito dell’AI Act e a un controllo NIST AI RMF o ISO/IEC 42001 si riusa per più audit e taglia la duplicazione. La mappatura è l’indice che lega l’evidenza all’obbligo.
  3. Estrazione automatica. Se produrre le evidenze per un’autorità richiede settimane di lavoro manuale, il sistema non è governato: è documentato. La metrica che conta sono le ore che servono per generare il pacchetto di evidenze su richiesta.

È lo stesso scarto che il vocabolario OISG (Open, Intelligent, Secure, Governed) mette in chiaro: gli standard regolatori fissano obblighi ad alto livello senza dire quali proprietà misurabili un sistema deve mostrare per soddisfarli. OISG propone, per ogni pilastro, criteri di adeguatezza misurabili — per il pilastro Governed, ad esempio, le ore che servono per produrre evidenze di conformità per un’autorità di vigilanza — e una mappatura esplicita verso EU AI Act, NIST AI RMF e ISO/IEC 42001. È il livello che lega l’articolo del Regolamento al controllo che lo dimostra.

Implicazioni

Per chi progetta sistemi ad alto rischio l’approccio architetturale ha conseguenze operative concrete. La gestione del rischio dell’art. 9 diventa un requisito di runtime — scoring e abstention — non un capitolo della documentazione tecnica dell’allegato IV. Il logging dell’art. 12 diventa una scelta di design dello storage (append-only, firmato) presa all’inizio, non un export ricostruito alla vigilia di un audit. La supervisione umana dell’art. 14 diventa un componente con uno stato osservabile e un’autorità di blocco che si può testare.

Il guadagno sta nel costo dell’audit: le evidenze raccolte una volta, mappate a NIST AI RMF e ISO/IEC 42001, si riusano per più framework e più cicli di vigilanza. La stessa traccia firmata che dimostra la tracciabilità dell’art. 12 serve anche per la rendicontazione ISO/IEC 42001 e per gli obblighi di sicurezza che si intrecciano con la NIS2 (Network and Information Security Directive 2) nei settori regolati.

Il contesto italiano aggiunge un livello. La legge 23 settembre 2025, n. 132 — pubblicata nella Gazzetta Ufficiale n. 223 del 25 settembre 2025, in vigore dal 10 ottobre 2025 — fissa il quadro nazionale e indica AgID (Agenzia per l’Italia Digitale) e ACN (Agenzia per la Cybersicurezza Nazionale) come autorità competenti: AgID per notifica, valutazione e accreditamento, ACN per la vigilanza e i poteri ispettivi e sanzionatori. La legge contiene deleghe al Governo da esercitare entro 12 e 24 mesi: i decreti attuativi sono in corso di adozione e definiranno parte degli obblighi puntuali. Un sistema che emette evidenze automatiche non bada a quale autorità le chiede né in quale forma: cambia il destinatario, non l’architettura.

Limiti

L’approccio non scioglie le scelte normative aperte. Stabilire se un sistema è ad alto rischio ai sensi dell’art. 6 e dell’allegato III resta una valutazione giuridica che nessuna metrica sostituisce; l’architettura verificabile dà per fatta la classificazione. Allo stesso modo, soglie e set di validazione vanno definiti con criteri difendibili: un controllo misurabile ma tarato male dà falsa sicurezza, non conformità.

Le date dell’applicazione high-risk restano incerte finché il Digital Omnibus non esce in Gazzetta Ufficiale dell’Unione, e i decreti attuativi della legge 132/2025 potranno aggiungere obblighi puntuali oggi ignoti. Nessuna di queste incognite cambia la conclusione operativa: i controlli tecnici — scoring, abstention, log append-only firmati, override tracciato, estrazione automatica delle evidenze — servono a prescindere dalla data esatta in cui diventano obbligatori, perché sono la forma misurabile di obblighi che il Regolamento ha già scritto nel testo.

Immagine di copertina: L’emiciclo del Parlamento europeo a Strasburgo: ampia sala semicircolare con file curve di banchi e scranni che digradano verso il… — foto di David Iliff, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:European_Parliament_Strasbourg_Hemicycle_-_Diliff.jpg