Provenance dei dati di addestramento AI: come dimostrare l’autenticita’ dei dataset sotto l’AI Act

A partire dal 2 agosto 2026 l'AI Act richiedera' ai fornitori di modelli AI general-purpose una documentazione dettagliata sui dataset di addestramento. L'art. 53, paragrafo 1, lettera c, impone elenchi sintetici dei contenuti utilizzati e il rispetto del copyright; per i sistemi ad alto rischio, l'art. 10 estende l'obbligo a qualita', rilevanza e rappresentativita' dei dati. Per le imprese italiane ed europee che addestrano modelli proprietari, fine-tunano LLM open source o costruiscono pipeline RAG, il problema strategico e' tecnico prima che giuridico: come si dimostra, a un auditor o a un giudice, che un dato di training e' stato realmente acquisito da una fonte autorizzata, in una data certa, con quel preciso contenuto, e non e' stato modificato dopo l'ingestione?

La risposta non sta in un certificato emesso a fine percorso. Sta nel modo in cui ogni file, ogni payload, ogni record che entra nel dataset viene fissato al momento dell'ingestione. La provenance dei dati di addestramento e' la nuova superficie di rischio: chi non la presidia oggi, fra dodici mesi si trovera' nell'impossibilita' di rispondere a un audit, con sanzioni che possono arrivare al 3% del fatturato globale.

Questo approfondimento fa parte della guida: data integrity nell'era dell'AI e certificazione alla fonte

Cosa chiede l'AI Act sulla provenance dei dati di addestramento

L'AI Act distingue due regimi sulla documentazione dei dati di training. Per i modelli AI general-purpose (GPAI), l'art. 53, paragrafo 1, lettera c, richiede un riepilogo dettagliato dei contenuti usati per l'addestramento, secondo un template che la Commissione UE ha pubblicato a maggio 2026. Per i sistemi ad alto rischio (allegato III: HR, education, law enforcement, biometric ID, ecc.), l'art. 10 aggiunge obblighi piu' stringenti su qualita', rilevanza e assenza di bias dei dataset, con tracciabilita' dei criteri di selezione.

Riepilogo sintetico ex art. 53: cosa deve contenere

Il template ufficiale richiede l'elenco delle fonti per categoria (web pubblico, dataset commerciali, dati proprietari da clienti, dataset sintetici, fine-tuning su contenuti protetti da copyright), il volume per categoria, le date di acquisizione, le misure di rispetto del diritto d'autore. Il punto critico e' che l'audit dell'AI Office potra' chiedere, su un campione, la dimostrazione tecnica che quel record specifico e' stato acquisito quando dichiarato e non e' stato alterato successivamente. Senza una catena di custodia digitale, la risposta diventa fragile.

Sistemi ad alto rischio ex art. 10: il salto di livello

Per i sistemi ad alto rischio l'asticella si alza. Non basta dichiarare le fonti: bisogna dimostrare che ogni record passa attraverso un processo di valutazione documentato (qualita', rappresentativita', mitigazione del bias) e che la trasformazione dal dato grezzo al dato curato e' tracciabile. Il dataset di training diventa un artefatto regolatorio: ogni cambio, ogni eliminazione, ogni augmentation deve essere giustificabile a un'ispezione.

Implementazione tecnica della provenance: cosa serve davvero

L'esperienza dei progetti enterprise pilotati nel primo trimestre 2026 ha consolidato cinque elementi che una pipeline conforme deve garantire: hashing crittografico all'ingestione, marca temporale qualificata per ogni file e batch, catena di custodia digitale fra dato grezzo e dato curato, tracciabilita' end-to-end fra ingestione del dato e prediction del modello, registro di attestazione immutabile sui passaggi di trasformazione.

Hash crittografico all'ingestione

Ogni file che entra nel dataset deve essere identificato da un hash SHA-256 calcolato sul payload originale. Questo hash diventa il riferimento univoco di quel dato. Qualsiasi modifica posteriore al file produce un hash diverso, rendendo l'alterazione immediatamente verificabile. Il momento dell'ingestione e' quello critico: se l'hash viene calcolato dopo che il dato e' transitato in un sistema intermedio, la catena di custodia parte gia' compromessa.

Marca temporale qualificata e sigillo

Hash da solo non basta: serve anche un'ancoraggio temporale incontestabile. Una marca temporale qualificata eIDAS, erogata da un QTSP qualificato terzo, lega l'hash a un istante certo nel tempo. Il sigillo elettronico aggiunge il legame con l'identita' dell'organizzazione che ha acquisito il dato. La tripla hash + marca temporale + sigillo e' lo standard di facto per costruire prove digitali con valore legale in Europa.

Catena di custodia fra dato grezzo e dato curato

I dataset di training raramente vengono usati cosi' come acquisiti: subiscono pulizia, normalizzazione, augmentation, filtering. Ogni passaggio deve essere registrato come trasformazione, con un puntatore al dato di origine e un nuovo hash sul dato trasformato. Cosi' a fine pipeline e' possibile ricostruire ogni record curato fino al dato grezzo originario, dimostrando ogni step intermedio.

Come TrueScreen abilita la provenance dei dati di training

La sfida operativa per le imprese che addestrano AI non e' inventare un sistema di hashing e marca temporale: i mattoni crittografici esistono da anni. La sfida e' integrarli nei flussi di data ingestion senza ricostruire l'infrastruttura. TrueScreen certifica alla fonte file e payload di dati attraverso una API REST e SDK pronti per essere richiamati dentro le pipeline esistenti.

Integrazione nelle pipeline di ingestione

Una pipeline tipica di data ingestion (es. crawler che acquisisce contenuti web autorizzati, ETL che importa dati da clienti enterprise, processo che incorpora dataset commerciali) chiama l'API TrueScreen passando il payload e riceve in risposta hash SHA-256, marca temporale qualificata eIDAS, sigillo elettronico erogato da QTSP qualificato integrato, identificativo nel registro di attestazione. Il record che entra nel dataset di training porta con se' il proprio passaporto crittografico, verificabile in autonomia da chiunque.

Risposta a un audit AI Act in pochi minuti

Quando l'AI Office, un cliente enterprise o un giudice chiede dimostrazione che un record specifico e' stato acquisito quando dichiarato, il sistema interroga il registro di attestazione di TrueScreen e produce in pochi minuti la catena di custodia probatoria immutabile: il file e' stato acquisito alle 14:32:08 UTC del 12 marzo 2026, da quella fonte autorizzata, con quel preciso payload, e non e' stato alterato. Questo livello di prova soddisfa simultaneamente l'audit regolatorio e la difesa in giudizio in caso di contestazione su un singolo input.