← Tutti gli articoli

10 min di lettura

Come dimostrare i dati di addestramento senza rivelarli

Vincola lo snapshot di un dataset privato a un hash o a una Merkle root e pubblica una sola prova con timestamp. I dati restano privati; più avanti potrai dimostrare in modo selettivo che un file, una riga o una versione faceva parte dell'insieme vincolato.

Sì, puoi dimostrare che un dataset privato è esistito senza pubblicarlo.

Lo schema è breve: costruisci un manifest del dataset, calcola l'hash delle sue voci, riunisci quegli hash in un'unica Merkle root e pubblica un solo record di Proof-of-Existence Label 309 su Cardano. Il dataset in sé non esce mai dal tuo controllo. Più avanti puoi rivelare esattamente un file, una riga, una voce del manifest o una inclusion proof per mostrare che faceva parte dello snapshot vincolato — e nient'altro.

Questo dimostra il possesso anteriore in un dato momento. Di per sé non dimostra la proprietà, lo stato del copyright, il consenso o l'uso lecito. Sono domande distinte, che richiedono record distinti.

Perché un team di AI dovrebbe averne bisogno?

I dati di addestramento sono diventati una questione da consiglio di amministrazione. Un model provider può aver bisogno di mostrare quali dati possedeva, quando li possedeva, da dove venivano, come sono stati trattati e quali dataset hanno alimentato una determinata versione del modello — per investitori, partner, clienti, autorità di regolamentazione, revisori, licenzianti o contenziosi.

Allo stesso tempo, spesso l'azienda non può pubblicare il dataset. Può contenere contenuti su licenza, dati dei clienti, dati personali, fonti proprietarie, annotazioni interne, segreti commerciali, valutazioni di sicurezza, corpora di retrieval, dati sintetici o regole di filtraggio sensibili.

La Proof of Existence scioglie questa tensione. Ti permette di vincolarti allo stato e alla cronologia del dataset senza divulgarlo pubblicamente. Pubblichi un'impronta; i byte restano a casa.

A cosa dovresti vincolarti: ai dati grezzi o a un manifest?

Vincolati a un manifest, non ai soli byte grezzi.

Un manifest del dataset descrive lo snapshot in modo strutturato e leggibile da una macchina. Può registrare:

  • nome del dataset e id dello snapshot;
  • finestra di raccolta;
  • categorie delle fonti e metadati sui diritti;
  • hash per ogni file e per ogni riga;
  • versioni di deduplicazione e filtraggio;
  • versioni delle pipeline di annotazione e preprocessing;
  • il modello o l'esecuzione di addestramento che l'ha usato;
  • politica di conservazione e proprietà interna.

Il manifest non deve esporre pubblicamente alcun dettaglio sensibile. Può restare interamente all'interno dell'azienda. La prova pubblica si vincola solo al suo hash, oppure a una Merkle root su molte voci del manifest. L'obiettivo è preciso e durevole: congelare la prova dello stato del dataset in un momento noto.

Perché usare una Merkle root invece di un record per file?

I dataset sono grandi, e pubblicare un record per ogni file o riga non è scalabile. Una Merkle root risolve il problema: si vincola a una lista ordinata di molti hash sotto un unico valore da 32 byte, ancorato in una sola transazione.

Più avanti, per dimostrare che un singolo item era incluso, riveli solo:

  • l'item o il suo hash;
  • la voce del manifest pertinente;
  • una Merkle inclusion proof;
  • il riferimento della transazione Label 309.

Un verificatore ricalcola il percorso da quella foglia fino alla root e conferma che la root è stata pubblicata a uno specifico block time di Cardano. La prova cresce con il logaritmo della dimensione del batch, quindi resta piccola anche per milioni di foglie. E soprattutto, costruire l'albero e controllare le prove è puro calcolo offline — al momento della verifica non servono server, account né alcuna collaborazione da parte tua.

È questo che rende possibile la divulgazione selettiva. Non devi mai rivelare l'intero dataset per dimostrare che un singolo item apparteneva allo snapshot vincolato.

Cosa vede effettivamente il pubblico?

Solo il record di prova on-chain. A seconda di come pubblichi, può includere un hash del manifest, una Merkle root, un conteggio delle foglie, l'orario della transazione, una firma opzionale della tua azienda o del tuo sistema, e URI opzionali indirizzati per contenuto (ar://, ipfs://) per materiale di supporto pubblico o cifrato.

Il pubblico non vede i file del dataset, la lista completa delle foglie, i metadati sulle fonti, i dati dei clienti, i dettagli di licenza, le annotazioni o le note interne. Restano dentro il tuo sistema di prove finché una domanda specifica non ne imponga la divulgazione.

Cosa riveleresti più avanti, e quando?

Rivela solo ciò che la domanda richiede.

  • Un determinato file era nel dataset? Rivela il file o il suo hash, la voce del manifest e una inclusion proof.
  • Una categoria di fonti era inclusa? Rivela la sezione pertinente del manifest e la prova che appartiene allo snapshot vincolato.
  • Una versione del modello ha usato un determinato snapshot? Rivela il manifest dell'esecuzione di addestramento che collega la versione del modello alla root del dataset.
  • Si tratta di un audit completo? Rivela l'intero manifest e la lista delle foglie nell'ambito dell'opportuno processo di riservatezza.

La root on-chain dimostra la cronologia. Il tuo archivio interno determina quanto dettaglio puoi mostrare, e a chi. Per i casi in cui il materiale di supporto stesso debba passare a un terzo restando però privato, puoi condividerlo in modo riservato invece di renderlo pubblico.

Come si lega tutto questo alla regolamentazione sull'AI?

La regolamentazione sull'AI si muove verso doveri più stringenti di documentazione e trasparenza. L'AI Act dell'UE, per esempio, stabilisce regole di trasparenza e relative al copyright per i modelli di AI di uso generale, e la Commissione europea ha pubblicato un modello per il riepilogo pubblico dei contenuti di addestramento — descritto, nelle parole stesse della Commissione, come una soglia minima per le informazioni da rendere pubblicamente disponibili.

La prova di un dataset privato non è la stessa cosa di quel riepilogo pubblico. Non sostituisce la rendicontazione regolamentare, la revisione legale, la gestione del consenso o i registri delle licenze, e se tutto questo sia di aiuto in un caso specifico dipende dalla tua giurisdizione e dai tuoi legali.

Quello che può sostenere è il livello probatorio dietro a quei processi. Se più avanti un'azienda deve mostrare cosa aveva, cosa sapeva o su quale snapshot si basava un riepilogo pubblicato, un vincolo del manifest con timestamp è una prova concreta, ancorata da un terzo, riguardo a tempistiche e integrità.

Cosa dimostra davvero la prova di un dataset?

Dimostra che un determinato vincolo a un dataset esisteva entro un block time pubblico. A seconda delle prove che conservi, può aiutare a mostrare:

  • che un file era in uno snapshot del dataset;
  • che un manifest esisteva prima di una controversia;
  • che una versione del dataset esisteva prima del rilascio di un modello;
  • che un'esecuzione di addestramento faceva riferimento a un determinato snapshot;
  • che una categoria di fonti era documentata all'epoca;
  • che una pipeline di preprocessing o filtraggio era registrata.

Se il record è firmato — Label 309 supporta firme opzionali a livello di record — può anche mostrare che una chiave aziendale o una chiave di sistema ha avallato il vincolo. La firma non è mai obbligatoria, quindi un vincolo non firmato è altrettanto valido; la firma aggiunge soltanto una paternità attribuibile.

Cosa non dimostra?

Questa è la parte su cui essere onesti, perché le lacune contano.

La prova di un dataset non dimostra che i dati fossero leciti da usare. Non dimostra che fossi proprietario dei dati, che siano stati raccolti con consenso, né quale sia il loro stato di copyright. Non dimostra che i dati siano stati effettivamente usati per l'addestramento — a meno che la tua pipeline di addestramento e i record del modello non siano essi stessi legati allo snapshot del dataset. E non dimostra che il manifest sia completo; solo i tuoi processi e controlli possono rendere credibile la completezza.

La Proof of Existence è una prova di cronologia e integrità. Stabilisce che byte esatti esistevano entro un orario pubblico. Non dice nulla su verità, proprietà, diritti o compliance — quelli richiedono record aggiuntivi e analisi legale. Se vuoi il quadro completo di dove passa il confine, vedi cosa dimostra e cosa non dimostra una prova.

Come dovresti progettare il flusso di lavoro?

Progetta per la domanda a cui ti aspetti di rispondere più avanti, non solo per calcolare hash oggi.

Una struttura praticabile:

  1. Definisci un formato canonico per il manifest del dataset.
  2. Calcola l'hash di ogni item del dataset o voce del manifest.
  3. Costruisci una Merkle root per lo snapshot.
  4. Pubblica un record Label 309, firmato se vuoi una paternità attribuibile.
  5. Conserva il manifest, la lista delle foglie e il materiale per le inclusion proof.
  6. Collega le esecuzioni di addestramento del modello alle root dei dataset.
  7. Sigilla i pacchetti di prove sensibili per i destinatari legali o di compliance.
  8. Registra gli snapshot che ne superano altri quando il dataset cambia.

La parte difficile raramente è la crittografia. La parte difficile è decidere quali prove saranno significative quando qualcuno le chiederà tra mesi o anni.

Con quale frequenza dovresti vincolare uno snapshot?

Vincolalo ogni volta che il dataset cambia in modo significativo — di norma dopo una nuova ingestione, prima di un'esecuzione di addestramento, dopo la deduplicazione o il filtraggio, dopo l'etichettatura, prima del rilascio di un modello, in un checkpoint di governance o prima di condividere il dataset con un partner.

La cadenza dovrebbe corrispondere alle domande a cui ti aspetti di rispondere. Vincola una volta all'anno e potresti non riuscire a dimostrare quale snapshot intermedio esisteva. Vincola a ogni modifica banale e generi rumore operativo. Poiché il Merkle batching consente a una sola root di rappresentare un intero snapshot — una transazione, per quanti file copra — il costo resta più o meno costante per ogni vincolo, quindi puoi scegliere una cadenza che si adatti alle prove che ti servono anziché una dettata dal prezzo.

Come si inserisce lo storage sigillato?

A volte calcolare l'hash non basta — vuoi conservare la prova stessa, non solo una sua impronta.

Una sealed PoE ti permette di farlo. Il record pubblico continua a vincolarsi all'hash del testo in chiaro, esattamente come farebbe una prova normale. Il payload sensibile è cifrato e conservato a un URI indirizzato per contenuto, con la chiave di cifratura del contenuto avvolta per una o più chiavi destinatarie. I destinatari autorizzati possono decifrarlo più avanti e confermare che il testo in chiaro recuperato corrisponde al vincolo on-chain ricalcolando l'hash.

La catena non porta mai il testo in chiaro e non rivela mai chi siano i destinatari; mostra soltanto che un vincolo sigillato è stato fatto al tempo T. Questo conta quando perdere il manifest originale indebolirebbe la tua prova. Un record solo-hash dimostra l'esistenza finché conservi ancora il file. Un record sigillato può conservare il file cifrato stesso, così la prova e il vincolo viaggiano insieme.

Un limite che vale la pena dire chiaramente: il sigillo mantiene il contenuto privato nei confronti di tutti tranne i possessori delle chiavi scelte, ma non rende nessuno anonimo, e un destinatario può sempre divulgare il testo in chiaro dopo averlo decifrato. Il sigillo controlla chi può leggere, non cosa fa dopo.

Chi dovrebbe essere responsabile del processo?

Un processo di prova dei dataset non dovrebbe essere uno script di ingegneria senza un responsabile. Tocca il legale, la sicurezza, la data governance, la compliance e lo sviluppo dei modelli, e un buon processo rende espliciti i confini: chi può creare snapshot, chi può firmare i vincoli, dove sono conservati i manifest, chi può decifrare i pacchetti sigillati, come si generano le inclusion proof, come le esecuzioni del modello si collegano alle root, come si gestiscono gli snapshot superati e come si producono le prove durante un audit o una controversia.

La prova è crittografica. La governance è organizzativa. Ti servono entrambe.

In breve

Per dimostrare i dati di addestramento senza rivelarli, vincolati allo snapshot, non al dataset. Costruisci un manifest, calcola l'hash delle sue voci, pubblica una Merkle root in un record Label 309 e conserva la lista delle foglie e le inclusion proof. Sigilla i file di supporto sensibili quando perderli indebolirebbe la prova. Poi rivela solo le prove che ogni singola domanda richiede davvero.

Questo ti dà una prova durevole e ancorata da un terzo del possesso anteriore e delle tempistiche. Di per sé non dimostra la proprietà, l'uso lecito o la compliance — ed è massimamente utile quando hai chiaro esattamente quali di questi sta facendo, e quali no.

Per approfondire

aidatasetsproof-of-existence