EU AI Act e governance dei dati: cosa devono documentare le aziende di IA nel 2026

L'EU AI Act — Regulation (EU) 2024/1689 — è entrato in vigore il 1° agosto 2024. Per i team che sviluppano prodotti di IA in Europa, quella data ha segnato l'inizio di un orologio della conformità, non solo un titolo di politica. Gli obblighi per i modelli di IA per uso generale si applicano dall'agosto 2025. I requisiti per i sistemi di IA ad alto rischio si applicano pienamente dall'agosto 2026. La finestra per costruire la propria infrastruttura documentale è aperta ora.

Questo articolo si concentra sulle disposizioni che con maggiore probabilità creeranno esposizione legale per le aziende di IA nel breve termine: i requisiti di governance dei dati dell'Articolo 10, gli obblighi di conservazione dei registri dell'Articolo 12 e la sfida pratica di dimostrare la provenienza dei dati di addestramento — un problema che la maggior parte dei team non ha ancora operativizzato.

Cosa richiede effettivamente l'Articolo 10

L'Articolo 10 dell'EU AI Act stabilisce pratiche obbligatorie di governance dei dati per i fornitori di sistemi di IA ad alto rischio. La disposizione è intitolata «Dati e governance dei dati» e non è un linguaggio aspirazionale — impone obblighi specifici e verificabili.

Ai sensi dell'Articolo 10(2), i set di dati di addestramento, validazione e test devono essere soggetti a pratiche appropriate di governance e gestione dei dati. In particolare, i fornitori devono documentare:

- Le scelte progettuali rilevanti — perché sono stati selezionati particolari set di dati, quali criteri ne hanno disciplinato l'inclusione o l'esclusione

- I processi di raccolta dei dati e l'origine dei dati — da dove provengono i dati, in quali circostanze sono stati acquisiti e chi deteneva i diritti al momento dell'acquisizione

- Le operazioni di preparazione dei dati — pulizia, etichettatura, arricchimento, aggregazione, annotazione; ogni trasformazione che ha modificato il set di dati prima dell'addestramento

- Una valutazione statistica dei set di dati — per identificare e attenuare i potenziali pregiudizi che potrebbero compromettere i diritti fondamentali, in particolare nei domini applicativi ad alto rischio

- Le limitazioni note — lacune nella copertura, pregiudizi temporali, distorsioni geografiche o qualsiasi caratteristica del set di dati che potrebbe influire sulle prestazioni del sistema nelle condizioni di distribuzione

L'Articolo 10(3) aggiunge che i dati di addestramento devono essere pertinenti, sufficientemente rappresentativi e privi di errori nella misura del possibile, tenuto conto della finalità prevista. L'Articolo 10(5) consente il trattamento di categorie particolari di dati personali per il rilevamento e la correzione dei pregiudizi — ma solo nelle condizioni rigorose e con le garanzie definite dal diritto dell'Unione in materia di protezione dei dati, e con controlli di accesso che limitino l'esposizione al minimo necessario.

Per le aziende che finora hanno trattato i set di dati di addestramento come artefatti ingegneristici interni piuttosto che come documenti legali, l'Articolo 10 rappresenta un cambiamento fondamentale nel modo in cui la gestione dei set di dati deve essere strutturata.

Le quattro categorie documentali richieste dall'Articolo 10

Quando i regolatori o un'autorità di vigilanza nazionale controlleranno la vostra conformità all'Articolo 10, cercheranno prove in quattro categorie documentali. Ciascuna richiede un approccio operativo diverso.

1. Registri di provenienza e origine dei dati

Dovete essere in grado di dimostrare, per ogni set di dati o componente di set di dati, l'origine dei dati. Ciò include: la fonte (repository pubblico, corpus concesso in licenza, fornitore di dati contrattualizzato, web scraping, generazione sintetica), la data di acquisizione, la base giuridica in virtù della quale si detengono e si utilizzano i dati e qualsiasi condizione contrattuale che ne limiti il trattamento. Un registro di provenienza creato settimane o mesi dopo l'acquisizione — ricostruito dalla memoria degli ingegneri o da messaggi Slack informali — non soddisferà un revisore.

2. Valutazioni dei pregiudizi e registri delle limitazioni

L'Articolo 10(2)(f) richiede esplicitamente ai fornitori di identificare e documentare eventuali pregiudizi noti o lacune potenziali nei set di dati che potrebbero dare origine a rischi per la salute, la sicurezza o i diritti fondamentali. Non si tratta di un esercizio una tantum. Man mano che i set di dati evolvono nel corso dei cicli di addestramento, le valutazioni dei pregiudizi devono essere aggiornate e la storia di tali valutazioni deve essere conservata. La documentazione deve registrare cosa è stato rilevato, quali misure di mitigazione sono state applicate e quali limitazioni restano riconosciute nella configurazione finale di addestramento.

3. Registri di elaborazione e trasformazione dei dati

Ogni operazione di pre-elaborazione — deduplicazione, normalizzazione, filtraggio, arricchimento sintetico, revisione delle annotazioni — deve essere registrata con dettagli sufficienti a ricostruire lo stato del set di dati in qualsiasi punto della pipeline. L'obiettivo è la verificabilità: se un'autorità di regolamentazione identifica un guasto del sistema o un output discriminatorio, deve poter risalire la catena causale attraverso i dati di addestramento. Una descrizione vaga di «pulizia standard dei dati» non soddisferà tale requisito.

4. Documentazione dei consensi e dei diritti

Laddove i dati di addestramento includano dati personali, i registri del consenso e le basi giuridiche del trattamento devono essere documentati in una forma recuperabile e con marcatura temporale. Laddove i dati siano concessi in licenza da terzi, i termini della licenza, le eventuali restrizioni d'uso e la versione del set di dati coperta da tali termini devono essere conservati per tutta la durata operativa del sistema — e oltre, poiché gli obblighi di sorveglianza post-commercializzazione ai sensi dell'Articolo 72 estendono la finestra documentale pertinente.

Articolo 12: Documentazione tecnica e obblighi di conservazione dei registri

L'Articolo 12 dell'EU AI Act stabilisce obblighi di conservazione dei registri che si affiancano ai requisiti di governance dei dati dell'Articolo 10. Ai sensi dell'Articolo 12, i fornitori di sistemi di IA ad alto rischio devono garantire che i loro sistemi abbiano la capacità di registrare automaticamente gli eventi rilevanti per l'identificazione dei rischi per la salute, la sicurezza o i diritti fondamentali lungo tutto il ciclo di vita del sistema.

Più in generale, l'Allegato IV del Regolamento (richiamato all'Articolo 11) specifica la documentazione tecnica che deve essere predisposta prima che un sistema di IA ad alto rischio sia immesso sul mercato o messo in servizio. La Sezione 2 dell'Allegato IV si riferisce direttamente ai requisiti dell'Articolo 10: richiede una descrizione generale delle metodologie e tecniche di addestramento utilizzate, dei set di dati di addestramento, validazione e test utilizzati, compresa la loro provenienza, portata e caratteristiche principali.

La documentazione prodotta ai sensi degli Articoli 10 e 12 non è destinata principalmente all'uso interno. Deve essere messa a disposizione delle autorità nazionali competenti su richiesta. Deve essere conservata per almeno dieci anni dopo l'immissione sul mercato o la messa in servizio del sistema. E deve essere aggiornata ogni volta che il sistema subisce una modifica sostanziale.

Articolo 53: Obblighi per i fornitori di modelli di IA per uso generale

Per le aziende che sviluppano modelli di IA per uso generale — grandi modelli linguistici, modelli fondazionali multimodali e sistemi analoghi — l'Articolo 53 dell'EU AI Act introduce un insieme parallelo di obblighi applicabili dall'agosto 2025. I fornitori di modelli GPAI devono mantenere documentazione tecnica che copra i dati di addestramento e le metodologie utilizzate per l'addestramento, i test e la valutazione. Laddove un modello GPAI sia classificato come modello con rischio sistemico ai sensi dell'Articolo 51, si applicano obblighi aggiuntivi relativi ai test avversariali e alla segnalazione degli incidenti.

L'intersezione tra l'Articolo 53 e l'Articolo 10 è importante per le aziende i cui modelli per uso generale vengono successivamente integrati da operatori a valle in applicazioni di IA ad alto rischio. L'operatore a valle è responsabile della conformità all'Articolo 10, ma dipende da informazioni accurate sulla provenienza da parte del fornitore del modello fondazionale. Le lacune nella documentazione del fornitore GPAI compromettono direttamente la capacità dell'operatore di conformarsi — e in pratica, ne seguirà la responsabilità contrattuale.

Il problema della provenienza: perché la documentazione dei dati di addestramento è difficile

In teoria, i requisiti documentali dell'Articolo 10 sono semplici. In pratica, i team di IA affrontano una sfida strutturale: il modo in cui i set di dati di addestramento vengono assemblati, iterati e riutilizzati nello sviluppo ML moderno non è mai stato progettato tenendo in mente la verificabilità legale.

I corpus di addestramento vengono tipicamente assemblati nel corso di mesi o anni, attingendo da decine di fonti — set di dati pubblici, corpus concessi in licenza, web crawl, fornitori di annotazioni contrattualizzati e pipeline interne di generazione sintetica. Il controllo delle versioni per il codice è maturo; per i set di dati su larga scala non lo è. Un set di dati «raccolto nel T3 2024» è spesso un composito di acquisizioni che coprono più trimestri, elaborato da più team, con tracciamento informale di cosa è cambiato tra le esecuzioni.

Quando l'Articolo 10 chiede di documentare l'«origine dei dati» e i «processi di raccolta dei dati», richiede un livello di precisione retrospettiva che molti team semplicemente non sono attualmente in grado di fornire. Il divario tra ciò che si sa sui propri dati di addestramento e ciò che si può dimostrare — a un regolatore, a un tribunale, a una controparte in una controversia di proprietà intellettuale — è dove si concentra l'esposizione all'Articolo 10.

Esiste una dimensione temporale aggiuntiva. La documentazione creata oggi, che descrive dati acquisiti oggi, è relativamente semplice da produrre. La documentazione che sarà ancora credibile e giuridicamente affidabile tra cinque o dieci anni — dopo che i sistemi saranno stati aggiornati, i membri del team se ne saranno andati e le licenze delle fonti saranno cambiate — richiede registri duraturi e a prova di manomissione piuttosto che wiki interni o fogli di calcolo.

Come i timestamp crittografici colmano il deficit di provenienza

La risposta tecnica al problema della documentazione della provenienza è la marcatura temporale crittografica applicata al momento dell'acquisizione dei dati e ad ogni successiva fase di elaborazione.

Ai sensi dell'Articolo 41 del eIDAS Regulation, una marca temporale elettronica qualificata comporta una presunzione legale di accuratezza della data e dell'ora indicate e dell'integrità dei dati a cui è associata. Non si tratta di un'affermazione commerciale di marketing — è uno standard probatorio legale che si applica in tutti gli Stati membri dell'UE. Quando si appone una marca temporale qualificata a un set di dati al momento dell'acquisizione, si crea un registro presunto legalmente autentico attestante che il set di dati esisteva in quello stato esatto in quel momento preciso, indipendentemente da qualsiasi successiva pretesa o controversia.

Ciò risponde simultaneamente a tre delle quattro categorie documentali dell'Articolo 10:

- Provenienza e origine — la marca temporale stabilisce quando il set di dati è stato acquisito e, se il sigillo include metadati, da quale fonte

- Registri di elaborazione — il sigillo del set di dati dopo ogni fase di trasformazione crea un registro con marcatura temporale dello stato del set di dati in ogni punto della pipeline

- Integrità delle versioni — qualsiasi successiva alterazione del set di dati invaliderà il hash crittografico, rendendo rilevabile qualsiasi manomissione

In modo cruciale, il set di dati stesso non deve essere divulgato per verificare il sigillo. La verifica viene eseguita rispetto al hash crittografico, non ai dati sottostanti — il che significa che i registri di provenienza possono essere condivisi con i regolatori senza esporre corpus di addestramento commercialmente sensibili o i dati personali che potrebbero contenere.

Per la validità a lungo termine — essenziale dato l'obbligo di conservazione della documentazione per dieci anni ai sensi dell'Articolo 12 — i sigilli emessi con codifica Long-Term Validation (LTV) rimangono verificabili in modo indipendente molto dopo la scadenza del certificato emittente, poiché l'intera catena di validazione è incorporata nel documento sigillato al momento della firma.

Flusso di lavoro pratico: documentare l'acquisizione di set di dati con Swiss Trust Layer

Swiss Trust Layer supporta le aziende di IA nell'adempimento dei requisiti documentali degli Articoli 10 e 12 attraverso sigilli crittografici qualificati emessi tramite Swisscom Trust Services, un Qualified Trust Service Provider (QTSP) sia nell'ambito di ZertES (Svizzera) che di eIDAS (UE). I sigilli recano le presunzioni legali dell'Articolo 41 di eIDAS e sono ammissibili in tribunale in tutte le giurisdizioni europee.

Un pratico flusso di lavoro di documentazione ai sensi dell'Articolo 10 con Swiss Trust Layer funziona come segue:

- All'acquisizione — quando un set di dati o un componente di set di dati viene acquisito, generare un hash crittografico del set di dati e del file di metadati allegato (che registra fonte, data di acquisizione, base giuridica e limitazioni note). Sigillare entrambi tramite il flusso di lavoro di sigillatura dei set di dati IA di Swiss Trust Layer. Il certificato risultante è il registro di provenienza per quel componente del set di dati.

- Dopo ogni fase di elaborazione — dopo deduplicazione, pulizia, annotazione o arricchimento sintetico, sigillare il set di dati trasformato. La catena di versioni sigillate documenta la cronologia completa dell'elaborazione richiesta ai sensi dell'Articolo 10(2)(c).

- Prima dei cicli di addestramento — sigillare la configurazione finale di addestramento (manifesto del set di dati, hash delle versioni, output della valutazione dei pregiudizi). Ciò crea un registro istantaneo dello stato esatto dei dati utilizzato per ogni ciclo di addestramento, abilitando la tracciabilità a livello di sistema richiesta ai sensi dell'Articolo 12.

- Per la divulgazione regolamentare — condividere i certificati di sigillo con le autorità nazionali competenti su richiesta. La verifica non richiede accesso ai dati sottostanti — solo il certificato e il punto di verifica pubblico del servizio di verifica di Swiss Trust Layer.

Per le aziende che hanno già pubblicato contenuti generati da IA o distribuito sistemi di IA e devono stabilire retroattivamente la provenienza per i set di dati esistenti, si applica lo stesso flusso di lavoro — con la consapevolezza che i sigilli creati oggi stabiliscono la provenienza a partire da oggi, non retroattivamente. Un'implementazione precoce è quindi la scelta operativamente corretta.

Questo flusso di lavoro si interseca anche con i più ampi requisiti documentali di proprietà intellettuale discussi nel nostro articolo su i contenuti generati da IA e la protezione della proprietà intellettuale ai sensi del diritto dell'UE — in particolare per le aziende i cui corpus di addestramento includono dati sintetici che hanno generato e desiderano proteggere come asset proprietari.

Calendario di implementazione: quando si applicano i requisiti

Il calendario di implementazione graduale dell'EU AI Act è spesso letto in modo errato. Le date chiave per le aziende di IA sono:

- 1° agosto 2024 — Il Regolamento è entrato in vigore. Le disposizioni sulle pratiche vietate hanno iniziato ad applicarsi sei mesi dopo (febbraio 2025).

- 2 agosto 2025 — Gli obblighi relativi ai modelli GPAI ai sensi dell'Articolo 53 si applicano. Le aziende che sviluppano o distribuiscono modelli di IA per uso generale devono disporre di documentazione tecnica entro questa data.

- 2 agosto 2026 — Gli obblighi per i sistemi di IA ad alto rischio ai sensi degli Articoli 10, 11 e 12 si applicano integralmente. I fornitori e gli operatori di sistemi che rientrano nelle categorie dell'Allegato III devono essere conformi.

- 2 agosto 2027 — Alcuni sistemi di IA integrati (sistemi ad alto rischio ai sensi dell'Articolo 6(1) già immessi sul mercato ai sensi di altra legislazione europea sulla sicurezza dei prodotti) ricevono un ulteriore periodo di transizione.

La scadenza di agosto 2026 è a circa quattordici mesi dal momento della stesura di questo articolo. Per le aziende che non hanno ancora iniziato a costruire la propria infrastruttura documentale ai sensi dell'Articolo 10, non si tratta di una finestra confortevole. I processi di governance dei dati non si implementano in uno sprint — richiedono modifiche alla pipeline, approvvigionamento di strumenti, revisione legale delle licenze esistenti dei set di dati e, in molti casi, un audit retrospettivo di cosa è stato raccolto e quando.

Le autorità nazionali competenti designate ai sensi dell'Articolo 70 non hanno ancora sviluppato una pratica di applicazione uniforme, ma il testo del Regolamento è chiaro: la non conformità ai requisiti documentali dell'Articolo 10 espone i fornitori a sanzioni amministrative fino a EUR 15 milioni o al 3% del fatturato annuo mondiale complessivo, a seconda dell'importo più elevato, ai sensi dell'Articolo 99(3).

Il caso strategico per costruire subito un'infrastruttura di provenienza

Al di là della conformità normativa, esiste una dimensione competitiva nella documentazione della provenienza dei set di dati che le aziende di IA lungimiranti stanno cominciando a riconoscere. Man mano che i contenuti generati da IA e i modelli addestrati da IA diventano oggetto di contenziosi di proprietà intellettuale — in particolare nelle giurisdizioni dove le controversie sul diritto d'autore sui dati di addestramento sono attivamente litigate — la capacità di dimostrare esattamente su quali dati si è addestrato, quando sono stati acquisiti e a quale base giuridica, sta diventando un asset strategico.

Le aziende in grado di produrre registri di provenienza qualificati e a prova di manomissione in risposta a una rivendicazione di proprietà dei dati o a una richiesta di informazioni di un regolatore si troveranno in una posizione fondamentalmente più solida rispetto a quelle che presentano registri ricostruiti e fogli di calcolo. Il costo della costruzione di tale infrastruttura prima che sorga una controversia è una frazione del costo della difesa di una pretesa senza di essa.

I requisiti di governance dei dati dell'EU AI Act e la necessità pratica aziendale di proteggere la proprietà intellettuale dei set di dati sono, sotto questo aspetto, perfettamente allineati. La conformità all'Articolo 10 non è un costo generale — è il fondamento di uno sviluppo di IA difendibile.

Prossimi passi per la vostra azienda di IA

Se la vostra organizzazione sviluppa, addestra o distribuisce sistemi di IA che rientrano nelle categorie ad alto rischio dell'EU AI Act — o se fornite modelli di IA per uso generale soggetti all'Articolo 53 — le seguenti azioni sono urgenti:

- Classificate i vostri sistemi di IA rispetto all'Allegato III per determinare quali prodotti rientrano nel perimetro dell'agosto 2026

- Verificate la documentazione esistente dei set di dati di addestramento rispetto ai requisiti dell'Articolo 10(2) — identificate le lacune in termini di provenienza, registri dei pregiudizi e registri di elaborazione

- Stabilite un protocollo di sigillatura dei set di dati per tutte le nuove acquisizioni e fasi di elaborazione future

- Incaricate consulenti legali qualificati di esaminare il vostro portafoglio di licenze dei set di dati rispetto ai requisiti documentali dei diritti dell'Articolo 10(2)(b)

- Esaminate i requisiti di documentazione tecnica dell'Allegato IV rispetto alle vostre pratiche documentali attuali

Il servizio di sigillatura della provenienza dei set di dati IA di Swiss Trust Layer supporta i passi tre e cinque — fornendo l'infrastruttura crittografica qualificata per la documentazione con marcatura temporale e a prova di manomissione richiesta dagli Articoli 10 e 12. I sigilli sono emessi tramite Swisscom Trust Services ai sensi di eIDAS e ZertES, con verifica indipendente disponibile su /compliance. Il prezzo parte da CHF 5 per documento.

L'EU AI Act è legge. L'orologio della documentazione è in funzione. La domanda non è se la vostra azienda di IA avrà bisogno di registri di provenienza conformi all'Articolo 10 — è se avrete costruito l'infrastruttura per produrli prima che arrivi la prima richiesta regolamentare.