L'articolo 12 del Regolamento UE sull'IA richiede che i sistemi di IA ad alto rischio supportino la registrazione automatica degli eventi per tutta la loro durata. I log devono rendere il sistema tracciabile a un livello adeguato alla finalità prevista e supportare il rilevamento dei rischi, il monitoraggio post-commercializzazione e il monitoraggio del deployer. L'articolo 19 assegna poi ai fornitori un obbligo di conservazione per i log generati automaticamente sotto il loro controllo. Per un agente IA, un'implementazione difendibile collega esecuzione, agente e Release, decisioni di policy, chiamate agli strumenti, decisioni umane, risultati ed evidenze di integrità. Questa guida separa il testo normativo dalla specifica ingegneristica usata per produrre record verificabili. Offre orientamento pratico e non costituisce consulenza legale.
Cosa richiedono gli articoli 12 e 19
L'articolo 12 si trova nel Capo III, sezione 2, dedicato ai requisiti per i sistemi di IA ad alto rischio. La sua portata dipende dalla classificazione del sistema e dalla finalità prevista. Un agente per il servizio clienti o un assistente interno non ricade nell'articolo 12 soltanto perché usa un modello IA o può chiamare strumenti. Inizia dalla base dei requisiti del Regolamento UE sull'IA e documenta la decisione di classificazione.
Il Regolamento (UE) 2026/1744 ha modificato le date di applicazione di queste disposizioni sui sistemi ad alto rischio. Le sezioni da 1 a 3 del Capo III si applicano dal 2 dicembre 2027 ai sistemi classificati ai sensi dell'articolo 6(2) e dell'Allegato III, e dal 2 agosto 2028 ai sistemi di prodotto classificati ai sensi dell'articolo 6(1) e dell'Allegato I. Le date successive lasciano tempo per l'implementazione. Lasciano invariata la progettazione dei controlli degli articoli 12 e 19.
| Fonte | Requisito del regolamento | Specifica operativa | Test dell’evidenza |
|---|---|---|---|
| Articolo 12(1) | Il sistema di IA ad alto rischio supporta tecnicamente la registrazione automatica degli eventi per tutta la sua durata. | Emetti record dal percorso di esecuzione per ogni esecuzione governata e ogni azione con conseguenze. Evita una progettazione che dipenda da una persona incaricata di assemblare il record dopo l'evento. | Esegui un Process rappresentativo e riconcilia la popolazione delle esecuzioni con i record creati automaticamente. |
| Articolo 12(2)(a) | I log catturano gli eventi rilevanti per identificare un rischio ai sensi dell'articolo 79(1) o una modifica sostanziale. | Registra guasti, blocchi e avvisi di policy, accessi anomali agli strumenti, override, modifiche alla Release, output inattesi ed effetti risultanti con identificatori stabili. | Attiva ogni segnale di rischio definito e conferma che il record identifichi l'esecuzione, la versione, l'evento, l'ora e il risultato interessati. |
| Articolo 12(2)(b) | I log facilitano il sistema di monitoraggio post-commercializzazione dell'articolo 72. | Usa campi evento che supportino query sulla popolazione, analisi delle tendenze, correlazione degli incidenti e collegamenti al piano di monitoraggio del fornitore. | Riproduci una metrica di monitoraggio dai record sorgente e segui un’eccezione nel piano di monitoraggio post-commercializzazione. |
| Articolo 12(2)(c) | I log supportano il monitoraggio del deployer ai sensi dell'articolo 26(5). | Rendi disponibile lo stato operativo, il contesto delle istruzioni per l'uso, il segnale di rischio, il riferimento della notifica al fornitore, l'evento di sospensione e il riferimento all'incidente grave, ove applicabile. | Segui un rischio simulato dal rilevamento alla sospensione o alla disposizione e verifica i riferimenti delle notifiche al fornitore e all’autorità. |
| Articolo 12(3) | Per i sistemi di identificazione biometrica remota coperti dall'Allegato III, punto 1(a), i log includono ogni periodo di utilizzo, il database di riferimento, i dati di input corrispondenti e le persone che hanno verificato i risultati ai sensi dell'articolo 14(5). | Crea campi dedicati per il record biometrico minimo. Applica ai dati sensibili i controlli di accesso e le regole di protezione dei dati. | Seleziona un utilizzo e verifica che ora di inizio e fine, riferimento del database, input corrispondente e identità dei verificatori siano presenti e autorizzati. |
| Articolo 19(1) | Un fornitore conserva i log dell'articolo 12 sotto il proprio controllo per un periodo adeguato alla finalità prevista e di almeno sei mesi, salvo diversa disposizione di altre norme applicabili. | Assegna a ogni record controllato dal fornitore una classe di conservazione, fonte, finalità, periodo minimo, comportamento in caso di blocco legale, regola di accesso e percorso di cancellazione verificato. | Esamina la policy di archiviazione, dimostra che i record coperti restano disponibili per i sei mesi richiesti, poi testa il blocco e la cancellazione autorizzata dopo la scadenza configurata. |
| Articolo 26(6) | Un deployer applica la stessa regola minima di sei mesi ai log generati automaticamente sotto il proprio controllo, fatte salve le altre norme applicabili. | Definisci il passaggio fornitore-deployer: quale parte controlla ogni record, come il deployer lo raccoglie e interpreta e come i contratti preservano l’accesso. | Traccia un record di produzione dalla generazione al repository controllato dal deployer e conferma recupero, conservazione e titolarità. |
Una specifica concreta di tracciabilità per un agente IA
L'articolo 12 stabilisce le finalità della registrazione e fornisce un elenco minimo specifico di campi per i sistemi di identificazione biometrica remota dell'articolo 12(3). Per gli altri sistemi ad alto rischio, il fornitore definisce un insieme di campi che renda il sistema tracciabile per la sua finalità prevista. La specifica seguente è un punto di partenza difendibile per un agente che può recuperare dati, prendere decisioni governate da policy, chiedere una revisione umana e chiamare strumenti. Lo schema di AI Agent Audit Log scaricabile trasforma queste famiglie di eventi in un contratto versionato e indipendente dal fornitore, con record completi, negati e di fallimento dell'integrità.
Cattura riferimenti o hash quando un payload completo entrerebbe in conflitto con i requisiti di minimizzazione dei dati, riservatezza o sicurezza. Un record utile conserva il significato dell’evento e un percorso controllato verso l’evidenza sottostante.
| Famiglia di eventi | Campi da catturare | Finalità del controllo | Test di accettazione |
|---|---|---|---|
| Identità dell’esecuzione | Tenant, ID di esecuzione e correlazione; ID agente; ID, versione e hash della Release; ID e versione del Process; ambiente; principal che avvia; soggetto per conto del quale si agisce; marche temporali di inizio e fine | Definire sistema, versione, autorità e periodo coinvolti in un’esecuzione. | Collega ogni evento di un’esecuzione campionata a un solo record di identità senza affidarti alle sole marche temporali. |
| Input e recupero | Riferimento dell’input o payload protetto; riferimenti a fonti e record; query o hash di recupero; versione del modello e del modello di prompt; stato della redazione; ora dell’evento | Mostrare quali informazioni sono entrate nell’esecuzione e quale versione le ha interpretate. | Ricostruisci l’insieme degli input approvati e dimostra che i campi protetti restano soggetti a controllo degli accessi. |
| Richiesta allo strumento | Nome dello strumento; ID di chiamata e gate; destinazione; argomenti o hash degli argomenti; autorità richiesta; chiave di idempotenza; ora della richiesta | Identificare l’azione consequenziale proposta dall’agente prima che si produca un effetto esterno. | Abbina la richiesta al risultato della policy e dimostra che una consegna duplicata non può creare un secondo effetto inspiegato. |
| Decisione di policy | ID decisione; tipo di gate; esito allow, warn, require_approval o block; ID, versione e hash del policy pack; ID delle regole corrispondenti; codici motivo; ora della decisione | Mostrare quale controllo ha governato l’azione e l’esatta versione valutata. | Rivaluta un campione fissato con i fatti registrati e spiega ogni differenza come cambiamento di versione. |
| Decisione umana | ID della Decision Request; ruolo richiesto; identità e autorità del revisore; esito approve, reject o escalate; motivazione; presa d’atto; ora della richiesta e della decisione | Collegare un giudizio sostanziale a una persona responsabile e all’azione trattenuta per la revisione. | Dimostra che il revisore aveva autorità al momento della decisione e che la richiesta allo strumento è rimasta in pausa fino alla risoluzione. |
| Esito dello strumento ed effetto aziendale | Stato; riferimento o hash del risultato; errore; decisione della policy sull’output; riferimenti allo stato prima e dopo; ID della transazione a valle; ora di completamento | Distinguere una proposta da un’azione arrivata al sistema di destinazione. | Riconcilia il record con il sistema a valle e contabilizza successo, errore, blocco, cancellazione e nuovi tentativi. |
| Segnale di monitoraggio e incidente | Tipo di segnale; gravità; esecuzione e Release interessate; versione della soglia o del rilevatore; disposizione; responsabile; riferimenti di notifica e incidente | Supportare il monitoraggio dell’articolo 72 e la risposta operativa dell’articolo 26(5). | Riproduci il segnale dai record sorgente e seguilo fino a una disposizione documentata. |
| Integrità e conservazione | Hash del record; hash del record precedente, se usato; firma e ID della chiave, se usati; riferimento a ledger o manifesto; classe di conservazione; scadenza; stato di blocco; evento di cancellazione | Rilevare modifiche successive e dimostrare che il record è rimasto disponibile per il periodo approvato. | Modifica un byte esportato e richiedi il fallimento della verifica; testa separatamente i controlli di conservazione, blocco e cancellazione. |
La conservazione è un controllo del fornitore e del deployer
L'articolo 19(1) assegna ai fornitori il dovere di conservare i log dell'articolo 12 generati automaticamente e sotto il loro controllo. L'articolo 26(6) attribuisce ai deployer il dovere equivalente per i log sotto il loro controllo. Entrambi seguono la stessa struttura: un periodo adeguato alla finalità prevista, un minimo di sei mesi e un’eccezione quando il diritto dell’Unione o nazionale applicabile prevede un’altra regola. Gli istituti finanziari conservano questi log nella documentazione mantenuta ai sensi della normativa dell’Unione pertinente sui servizi finanziari.
Il periodo di sei mesi è il limite minimo per i log coperti da queste disposizioni. L'articolo 18 richiede separatamente ai fornitori di conservare per dieci anni specifica documentazione tecnica e di conformità. Questi periodi riguardano record diversi. Le norme su privacy, lavoro, settore, blocco per controversie e diritto nazionale possono cambiare il periodo valido o i dati che possono essere conservati.
Costruisci un registro di conservazione prima di scegliere un TTL di archiviazione. Per ogni classe di evidenza, registra fonte legale o aziendale approvata, finalità, parte responsabile, sistema di riferimento, periodo minimo e massimo, data di attivazione, ruoli di accesso, regola di blocco legale, metodo di cancellazione ed evidenza dei test. Il modello di policy di conservazione degli audit log fornisce una struttura operativa.
- Assegna il controllo: nomina i record controllati dal fornitore e dal deployer, incluse le copie create da un fornitore di osservabilità o da un operatore dell’ambiente di esecuzione.
- Allinea i livelli: archivio delle tracce, registro delle evidenze, pacchetto esportato, indice, backup e ciclo di vita delle chiavi di cifratura devono avere periodi compatibili.
- Proteggi il contenuto: minimizza i dati personali, separa i payload sensibili dai metadati interrogabili più ampiamente e applica accessi vincolati alla finalità.
- Testa il recupero: un record conservato ha valore quando un revisore autorizzato può trovarlo, interpretarlo ed esportarlo entro il livello di servizio richiesto.
- Testa la scadenza: dimostra che il sistema rispetta un blocco legale, registra la cancellazione autorizzata e rimuove ogni copia governata quando termina il periodo approvato.
La prova di manomissione e la ricostruzione sono controlli di assurance
L'articolo 12 nomina la registrazione automatica e la tracciabilità. Non prescrive alcun meccanismo crittografico né alcun endpoint di ricostruzione. La prova di manomissione e la ricostruzione sono controlli di implementazione che aiutano il fornitore a dimostrare che il record è sufficientemente completo per essere usato e che è rimasto invariato.
Per ricostruzione si intende la ricomposizione del percorso di controllo registrato. Rieseguire un modello o uno strumento esterno può produrre un risultato diverso o ripetere un effetto collaterale. Una ricostruzione sicura legge sequenza, versioni, fatti di policy, decisioni umane e riferimenti al risultato memorizzati. Una simulazione separata della policy può rivalutare i fatti registrati rispetto a una versione fissata della policy senza inviare l'azione.
| Test | Risultato atteso | Segnale di errore |
|---|---|---|
| Riconciliazione della popolazione | Ogni esecuzione nel perimetro e ogni azione consequenziale ha un record, inclusi allow ordinari, blocchi, errori e cancellazioni. | Il numero di esecuzioni supera quello dei record oppure record non abbinati non hanno un’esecuzione sorgente. |
| Ordine causale | La decisione di policy precede l’azione governata; la decisione umana richiesta precede il rilascio; il risultato segue l’esecuzione. | Un effetto collaterale non ha un precedente record di controllo o i timestamp non stabiliscono la sequenza. |
| Contesto fissato | Il record risolve Release dell’Agent e del modello, versione del Process, versione della policy, identità e autorità attive al momento dell’evento. | Il revisore vede solo la configurazione attuale o deve dedurre quale versione è stata eseguita. |
| Riconciliazione del risultato | Esito dello strumento ed effetto aziendale corrispondono alla fonte a valle, incluso il comportamento di nuovi tentativi e idempotenza. | La traccia di audit indica il completamento mentre la destinazione non ha una transazione corrispondente, oppure effetti duplicati non hanno cause separate. |
| Verifica dell’integrità | Hash, firme, collegamenti di catena, prove del ledger e controlli del manifesto verificano quando configurati; una mutazione controllata rende rossa la verifica. | Un artefatto modificato continua a verificare oppure il verificatore non identifica il file o record interessato. |
| Ricostruzione sicura | Un revisore può leggere la sequenza completa senza rieseguire un effetto collaterale consequenziale. | L’unico percorso di ricostruzione invia la chiamata allo strumento originale o dipende da una risposta del modello non disponibile. |
Come le evidenze di esecuzione di KLA corrispondono alla specifica
KLA crea un Lineage Record per un’esecuzione governata e usa identificatori stabili di esecuzione e tenant per collegare gli eventi di esecuzione. Gli span di esecuzione possono contenere versione e hash del Process, identificatori della Release dell'Agent, ambiente, principal che avvia, soggetto per conto del quale si agisce e identità del client chiamante registrata per l’esecuzione. Gli span del workflow registrano esiti dei nodi, risultati di policy, ID e regole di policy, Decision Request, identità dei revisori, marche temporali ed errori.
Il gateway di governance KLA valuta i gate di input e output degli strumenti tramite il KLA Policy Engine quando gli operatori abilitano KLA_GOVERNANCE_GATEWAY per un ambiente. La configurazione di produzione di execution-worker presente nel repository non abilita attualmente questo percorso. Quando abilitato, un risultato di gate usa i quattro esiti allow, warn, require_approval e block. Le ricevute di decisione includono esecuzione, gate, strumento, versione della policy, hash del policy pack, codici motivo, Decision Request, traccia e hash dell’output ove applicabile. Il gateway sigilla la ricevuta del gate di input prima di eseguire lo strumento governato e sigilla la ricevuta del gate di output prima di restituire o trattenere il risultato. Un errore nella scrittura dell’evidenza impedisce al gate di avanzare.
| Necessità di controllo | Componente KLA | Evidenza prodotta | Confine da verificare |
|---|---|---|---|
| Identità stabile dell’esecuzione | Agent, Release, Process e Lineage Record | ID di esecuzione e tenant, versione e hash del Process, Release dell’Agent, ambiente, principal e identificatori di correlazione | Conferma che ogni integrazione propaghi gli identificatori e che i campi di identità opzionali siano presenti per il Process in esame. |
| Sequenza automatica degli eventi | KLA Runtime e span di esecuzione OpenTelemetry | Eventi di esecuzione, nodo, policy, approvazione, errore, tempo e risultato ordinati in un Lineage Record | Riconcilia la popolazione delle esecuzioni e conferma che gli strumenti selezionati emettano i riferimenti a input, risultato ed effetto downstream richiesti dalla finalità prevista. |
| Controllo di policy e strumento | Gateway di governance KLA abilitato per ambiente | Tipo di gate, versione della policy, decisione, motivi, Decision Request, hash degli argomenti, hash dell’output e stato di idempotenza; ID delle regole corrispondenti quando la decisione require_approval valutata fornisce le regole | Conferma che il gateway sia abilitato nell’ambiente esaminato. Testa tutti e quattro gli esiti, l’evidenza opzionale delle regole, il guasto del servizio di policy, argomenti cambiati dopo l’approvazione, nuovi tentativi e cancellazione. |
| Decisione umana | Decision Desk e record di approvazione durevoli | Ruolo richiesto, identità del revisore, decisione, motivazione, marche temporali, contesto di policy ed esecuzione correlata | Testa autorità del revisore, regole maker-checker quando configurate e sequenza completa da pausa a rilascio. |
| Record con prova di manomissione | Registro append-only delle evidenze e ricevute di governance | Scritture verificate nel registro; firme Ed25519 e collegamenti hash-chain quando la firma delle ricevute è abilitata | Tratta lo stato della firma come un fatto osservato del deployment. Allerta sul degrado della firma ed esegui un test di manomissione controllato. |
| Pacchetto di revisione portabile | Evidence Room e Sealed Evidence Bundles | Record selezionati di lineage, policy, approvazione e registro con manifesto, hash, dati di inclusione Merkle e firme per la verifica offline | Conferma popolazione esportata, profilo di redazione, risultato del verificatore, disponibilità delle chiavi e catena di custodia. |
| Conservazione | Conservazione dei job Evidence Factory e configurazione di archiviazione dei bundle | Metadati di conservazione e scadenza del job di esportazione e conservazione configurata dell’archiviazione dei bundle | Riconcilia questi controlli di esportazione con la conservazione dei Lineage Record sorgente e dei record nel registro. Imposta e testa il periodo richiesto per il sistema classificato e il settore. La sola capacità del prodotto non stabilisce il periodo legale approvato. |
Checklist di implementazione
Trasforma la specifica in un gate di rilascio per ogni sistema di IA ad alto rischio. Conserva insieme record di classificazione, finalità prevista, schema eventi, registro di conservazione, revisione privacy, test e piano di monitoraggio nel set documentale dell'Allegato IV.
- Nomina fornitore, deployer, finalità prevista, base dell’alto rischio, confine del sistema, Release dell’Agent e del modello e ogni parte che controlla una copia dei log.
- Definisci la popolazione di esecuzioni nel perimetro e le azioni consequenziali che richiedono record completi di strumento, policy, decisione umana e risultato.
- Pubblica uno schema eventi versionato con campi obbligatori, classificazioni dei dati, regole di redazione, identificatori, ordine degli eventi consentito e comportamento in caso di errore.
- Rendi automatica la creazione dei record nel percorso di esecuzione e chiudi il flusso quando una ricevuta di controllo mancante lascerebbe un’azione consequenziale senza governance.
- Riconcilia esecuzioni e record e testa allow ordinari, avvisi, approvazioni richieste, blocchi, errori, nuovi tentativi, cancellazioni e guasti del servizio di policy.
- Imposta la conservazione di fornitore e deployer dal registro approvato, con un test minimo di sei mesi quando si applica l’articolo 19 o l’articolo 26(6).
- Esegui test di ricostruzione sicura, riconciliazione dei risultati, controllo accessi, blocco legale, cancellazione, esportazione e manomissione di un byte.
- Alimenta il piano di monitoraggio dell’articolo 72 con gli eventi definiti e collega i segnali a responsabili, disposizioni, incidenti e azioni correttive.
Domande frequenti
L'articolo 12 del Regolamento UE sull'IA si applica a ogni agente IA?
L'articolo 12 si applica ai sistemi di IA ad alto rischio. Un agente richiede prima una classificazione documentata e una finalità prevista. Le organizzazioni possono usare gli stessi controlli di registrazione per agenti a rischio inferiore come scelta di governance.
Quali eventi deve registrare un agente IA ai sensi dell'articolo 12?
L'articolo 12 richiede eventi rilevanti per il rilevamento dei rischi, la modifica sostanziale, il monitoraggio post-commercializzazione e il monitoraggio del deployer. Fornisce un elenco minimo esplicito di campi per i sistemi di identificazione biometrica remota dell'articolo 12(3). Gli altri sistemi richiedono uno schema adeguato alla finalità. Per un agente che usa strumenti, identità dell'esecuzione, versioni, input o riferimenti, richieste agli strumenti, risultati di policy, decisioni umane, risultati, errori e timestamp costituiscono una base difendibile.
Per quanto tempo devono essere conservati i log dell’articolo 12?
L'articolo 19(1) richiede ai fornitori di conservare i log generati automaticamente sotto il proprio controllo per un periodo adeguato alla finalità prevista e di almeno sei mesi, salvo diversa disposizione del diritto dell'Unione o nazionale applicabile. L'articolo 26(6) applica la stessa regola ai deployer per i log sotto il loro controllo. Record separati e regole settoriali possono prevedere periodi diversi.
L'articolo 12 richiede log a prova di manomissione?
L'articolo richiede registrazione automatica e tracciabilità e non indica alcun meccanismo crittografico. Archiviazione append-only, hash, firme e verifica indipendente sono controlli di assurance che aiutano a rilevare modifiche e a sostenere un processo di evidenza difendibile.
L'articolo 12 richiede la ricostruzione?
L'articolo non contiene un requisito espresso di ricostruzione. La ricostruzione sicura è un utile test di accettazione: un revisore dovrebbe poter leggere sequenza registrata, versioni, decisioni e risultati senza rieseguire un modello o ripetere un effetto collaterale.
I normali log applicativi possono soddisfare il requisito?
Possono contribuire quando sono automatici, completi per la finalità prevista, correlati in tutto il sistema, interpretabili, soggetti a controllo accessi, conservati per il periodo approvato e disponibili per il monitoraggio. I messaggi di debug specifici di un servizio spesso non includono versioni di policy, autorità umana, risultati aziendali e riconciliazione della popolazione.
Come supporta KLA una progettazione della registrazione conforme all'articolo 12?
KLA collega span di esecuzione, risultati di policy, gate degli strumenti, Decision Request e risultati di esecuzione nei Lineage Record. Le esportazioni di Evidence Room selezionano record con metadati di integrità per la verifica offline. Fornitore e deployer restano responsabili di classificazione, sufficienza dei campi, conservazione, privacy, monitoraggio e valutazione finale di conformità.
Punti chiave
Un'implementazione utile dell'articolo 12 parte da classificazione e finalità prevista, poi registra automaticamente ogni esecuzione nel perimetro e ogni azione consequenziale. Gli articoli 19 e 26(6) trasformano la conservazione in un controllo assegnato. Uno schema eventi versionato, identità stabili, contesto di policy e decisioni umane, riferimenti ai risultati a valle, riconciliazione della popolazione, test di manomissione e ricostruzione sicura rendono questi log utilizzabili per monitoraggio e revisione. Usa la guida alle tracce di audit degli agenti IA per l'architettura più ampia delle evidenze, la guida alla documentazione dell'Allegato IV per il fascicolo tecnico e il piano di monitoraggio post-commercializzazione per il ciclo operativo.