EU AI Act Articolo 12
Il gap delle evidenze nell'EU AI Act: cosa chiederanno davvero gli auditor
Gli organismi notificati stanno già segnalando aspettative più rigorose
L'ecosistema della valutazione di conformità si è mobilitato attorno alla scadenza di agosto 2025 per la designazione degli organismi notificati. TUV SUD ha iniziato a offrire certificati volontari di conformità all'AI Act a novembre 2025. Team-NB ha avvertito di una potenziale carenza di organismi designati con competenze in materia di AI. Quelli che otterranno la designazione applicheranno standard rigorosi.
Il sandbox regolatorio AESIA della Spagna ha prodotto 16 guide tecniche di esecuzione che coprono metodi documentali specifici. I partecipanti ricevono "report di uscita" che i valutatori di conformità devono "tenere positivamente in considerazione", stabilendo un precedente su come debba presentarsi una documentazione accettabile.
Ai sensi dell<annex>Allegato VII</annex>, gli organismi notificati avranno ampi poteri di accesso: accesso completo ai dataset di addestramento tramite API, diritti di test diretti e, in casi eccezionali, accesso ai modelli addestrati stessi. I vostri log di accesso ai dataset diventeranno obiettivi di audit.
Lo schema è chiaro: il testo vago diventa prassi rigorosa
Ogni normativa importante segue la stessa traiettoria. I requisiti basati su principi evolvono in aspettative di audit altamente specifiche entro 2-4 anni.
In cosa si è evoluto
- Divergenza UTC di 100 microsecondi (HFT)
- 1 millisecondo (trading algoritmico)
- Archiviazione WORM per 5-7 anni
- Ricostruzione dei trade in 72 ore su richiesta
Lezione chiave
La precisione temporale è diventata 1.000.000x più rigorosa
La 'registrazione automatica degli eventi' dell'Articolo 12 diventerà logging tamper‑evident e ancorato crittograficamente entro 2‑4 anni dall'inizio dell'applicazione.
Come altre normative sono evolute da vaghe a prescrittive
Requisito originale
"Fonte temporale accurata" per le registrazioni di trading
Cosa è diventato
Divergenza di 100 microsecondi UTC (HFT), storage WORM, conservazione 5-7 anni, ricostruzione in 72 ore
I requisiti di precisione temporale sono diventati 1.000.000 di volte più rigorosi di quanto il testo originale lasciasse intendere
Requisito originale
"Controllo interno adeguato" (nessuna definizione)
Cosa è diventato
Framework COSO: 17 principi, 87 punti focali, tasso di carenze del 40% negli audit Big 4
Un testo basato su principi è diventato altamente prescrittivo attraverso la pratica di audit
Requisito originale
"Misure tecniche adeguate"
Cosa è diventato
2FA ora atteso (sanzione Haga Hospital), procedure di accesso documentate obbligatorie
Il principio di accountability ha reso la documentazione stessa un requisito di compliance
Requisito originale
Requisiti di "documentazione tecnica"
Cosa è diventato
Tracce di audit IEC 62304, controllo di versione completo, tracciabilità dai requisiti ai test
I pattern dei dispositivi medici vengono importati direttamente nelle aspettative dell'AI Act
Cosa si preparano a valutare gli auditor
Sulla base di prEN ISO/IEC 24970, prEN 18286 e delle aree di pratica emergenti dei Big 4, ecco cosa coprirà probabilmente la valutazione di conformità.
- Eventi operativi (input, output, decisioni)
- Eventi di monitoraggio automatizzato (drift, anomalie)
- Interventi di supervisione umana (approvazioni, sovrascritture)
Segnali tecnici convergenti nelle linee guida di audit
Pur non essendo esplicitamente prescritti, questi pattern tecnici rispondono alla domanda pratica che porranno gli auditor: come dimostrate che questi log non sono stati modificati?
Concatenamento crittografico
Ogni voce di log include un hash della voce precedente, creando sequenze a integrità verificabile
Catene hash SHA-256 con rollup Merkle tree
Storage WORM
Lo storage Write-Once-Read-Many impedisce la modifica dei record storici
immudb, Amazon S3 Object Lock, blob immutabili Azure
Ancoraggio temporale
Timestamp di terze parti indipendenti dimostrano che le registrazioni esistevano in un momento specifico
OpenTimestamps, RFC 3161 TSA, ancoraggio blockchain
Architettura append-only
Le correzioni diventano nuove versioni collegate anziché sovrascritture
Event sourcing, registri append-only, database nativi per tracce di audit
Catena delle evidenze: dalle operazioni alla prova pronta per l'audit
Ogni passaggio produce evidenze che un revisore può verificare in modo indipendente e offline.
Gli auditor vogliono prova che il vostro QMS funziona (registrazioni) e che le registrazioni siano affidabili (prove di integrità).
Dove i team sbagliano
- Aspettare gli standard armonizzati prima di implementare i controlli di integrità
- Considerare la conservazione di 6 mesi sufficiente quando le regole di settore richiedono periodi più lunghi
- Il logging esiste ma l'integrità non è verificabile (nessun hashing, nessun concatenamento)
- I log di accesso ai dataset mancano o sono facilmente modificabili
- Nessuna prova temporale indipendente che le registrazioni esistessero quando dichiarato
Integrate evidenze a integrità verificabile nelle vostre operazioni AI
KLA fornisce tracce di audit con ancoraggio crittografico fin dal primo giorno.
- immudb-backed ledger: storage delle evidenze append-only; ogni esportazione viene ancorata al registro e il record di ancoraggio viaggia all'interno del bundle
- Ancoraggio OpenTimestamps: ancoraggio batch su Bitcoin ogni ora; il bundle contiene la ricevuta OTS, così che il timestamp possa essere confermato rispetto alla blockchain Bitcoin quando lo si desidera
- S3 Object Lock: storage WORM in modalità compliance per la conservazione dei payload grezzi
- Esportazioni Evidence Room: bundle firmati con hash per artefatto e istruzioni di verifica
Non aspettate gli standard armonizzati. Costruite l'architettura delle evidenze che gli auditor esigeranno.
Verificate l'integrità delle evidenze con la CLI:
# Verify evidence bundle integrity kla evidence verify --bundle ./evidence-export.zip # Export with full hash chain kla export evidence \ --tenant $KLA_TENANT_ID \ --days 30 \ --include-timestamps \ --format pdf
Cosa dimostra il verificatore
L'export dell'Evidence Room include un verificatore autonomo che controlla un bundle senza accesso di rete e senza infrastruttura KLA. Offline dimostra che il bundle è internamente coerente: ogni input — dati, prove e chiavi pubbliche — proviene dal bundle stesso.
Firma del manifest
Il manifest si canonicalizza (RFC 8785 / JCS) e il suo digest si ricalcola. Il JWS separato porta firme ES256 SEK e TEK valide su quel digest, verificate contro le chiavi pubbliche che il bundle incorpora in keys/jwks.json.
Inclusione Merkle
Ogni artefatto viene re-hashato (SHA-256) sul digest dichiarato dal manifest, la prova di inclusione di ogni artefatto raggiunge la radice sigillata, e la radice Merkle ricalcolata è uguale al valore del manifest.
Firme delle ricevute
Ogni catena di ricevute di governance viene verificata: la firma ed25519 di ogni ricevuta è valida contro una chiave incorporata nel bundle, e il prevReceiptHash di ogni passo collega al passo precedente, dalla genesi all'ultimo.
Catena di hash del ledger
Ogni record di ledger esportato viene re-hashato sul suo hash dichiarato, e i record consecutivi si collegano tramite previousHash da un capo all'altro.
Ancoraggio OpenTimestamps
timestamp.ots viene analizzato secondo le regole rigorose di OpenTimestamps e si vincola al digest del manifest ricalcolato. Quando la ricevuta è attestata su Bitcoin, il verificatore riporta la sua altezza di blocco; una ricevuta di calendario in sospeso viene accettata come conferma Bitcoin in sospeso.
Cosa la verifica offline non dimostra
- L'autenticità richiede un controllo delle chiavi fuori banda. Le firme SEK, TEK e delle ricevute sono tutte verificate contro le chiavi che il bundle incorpora in keys/jwks.json, quindi offline il bundle dimostra solo di essere internamente coerente. Per dimostrare che proviene da KLA, ancorate quelle chiavi a un JWKS pubblicato da KLA o a un'impronta di chiave.
- L'ancoraggio Bitcoin di OpenTimestamps è considerato attendibile offline. Confermare la sua altezza di blocco confronta la prova con la catena Bitcoin dal vivo, e una ricevuta di calendario in sospeso resta in sospeso fino a un aggiornamento del calendario.
- La prova dell'ancoraggio del ledger immudb è presente e viene analizzata offline. Confermare la sua inclusione contro lo stato firmato del ledger richiede un controllo in rete.
Domande frequenti
L'Articolo 12 richiede esplicitamente l'integrità crittografica?
No, ma lo schema emerso da MiFID II, SOX, GDPR e MDR è inequivocabile: il testo basato su principi diventa prassi prescrittiva entro 2-4 anni. Auditor e organismi notificati interpreteranno "registrazione automatica" come logging a integrità verificabile.
Quali periodi di conservazione si applicano ai log AI?
L'Articolo 12 specifica un minimo di 6 mesi per i log automatizzati, ma i requisiti settoriali spesso prevalgono. Gli istituti finanziari dovrebbero aspettarsi 5-7 anni. La documentazione tecnica deve essere conservata per 10 anni dopo l'immissione del sistema sul mercato.
Quando verranno pubblicati gli standard armonizzati?
prEN ISO/IEC 24970 (standard di logging) è in fase di voto come Draft International Standard. prEN 18286 (standard QMS) è entrato in inchiesta pubblica a ottobre 2025. Standard definitivi attesi per il Q4 2026, ma le aspettative degli auditor si stanno formando ora.
Quale accesso avranno gli organismi notificati?
Ai sensi dell'Allegato VII, gli organismi notificati possono richiedere accesso completo via API ai dataset di addestramento, validazione e test. Possono condurre test diretti se non soddisfatti dalle evidenze del provider. I log di accesso ai dataset diventeranno essi stessi obiettivi di audit.
Come dovremmo gestire l'auditabilità dei modelli ML?
Le soglie per un logging estensivo restano poco chiare, ma gli auditor si aspetteranno probabilmente: tracciamento delle versioni del modello, modifiche degli iperparametri, metadati delle sessioni di addestramento e tracciabilità delle decisioni per gli output ad alto rischio.
Risorse correlate
Proseguite il vostro percorso di conformità EU AI Act.
Template QMS Article 17
Template del sistema di gestione della qualità per AI ad alto rischio con mappatura prEN 18286.
Panoramica sulla sicurezza
Architettura tecnica per l'integrità delle evidenze e la protezione dei dati.
Demo esportazione evidenze
Scoprite come vengono generati i bundle di evidenze verificabili offline.
Non aspettate che gli standard vi raggiungano
Il divario tra il testo dell'Articolo 12 e le aspettative pratiche di audit si colmerà rapidamente. Le organizzazioni che anticipano requisiti più rigorosi avranno vantaggi competitivi significativi quando inizieranno le valutazioni di conformità.