Dimostrare la provenienza dei contenuti AI su larga scala con il Merkle batching

Se il tuo team genera contenuti AI su larga scala, puoi dimostrare cosa hai creato e quando l'hai creato senza mettere on-chain ogni asset. Calcola l'hash di ogni output o manifesto di provenienza, raggruppa quegli hash in Merkle root e pubblica impegni Label 309 con timestamp a cadenza regolare. In seguito potrai dimostrare che una specifica immagine, video, file di testo, manifesto prompt-e-output o manifesto Content Credentials faceva parte di un batch impegnato — usando soltanto il riferimento della transazione e un explorer Cardano pubblico.

Quello che ottieni è una Proof of Existence (prova dell'esistenza): la prova che byte esatti esistevano entro un momento pubblico. Non dimostra che il contenuto sia vero, lecito o creato da un essere umano. Dimostra un impegno con timestamp su byte specifici, ancorato al di fuori dei tuoi sistemi modificabili.

Perché i contenuti AI hanno bisogno di un livello di prova separato?

I contenuti AI sono facili da creare, modificare, rielaborare e rigenerare — ed è esattamente questo il problema.

Se un'azienda produce migliaia di asset generati dall'AI, come dimostra poi quali output ha realizzato, quando li ha realizzati, quale prompt o contesto del modello è stato registrato e quale versione è stata mostrata a un cliente o pubblicata online?

Un log interno di database spesso non basta da solo. I log si possono riscrivere. Lo storage viene migrato. Gli asset si possono rigenerare byte per byte. I metadati vengono rimossi lungo il percorso. Un cliente, un revisore, un'autorità di regolamentazione, un partner o un tribunale può chiedere prove esistenti al di fuori dei sistemi modificabili dell'azienda — e a un momento verificabile.

La Proof of Existence dà a quei record un timestamp esterno che non dipende dalla fiducia nell'azienda, nei suoi server o nel suo dominio.

Cosa dovrebbe sottoporre a hash un team AI?

Calcola l'hash delle prove che potresti dover produrre in futuro.

Per i contenuti generati dall'AI, spesso questo include:

il file di output generato;
il prompt e il system prompt o profilo di policy;
il nome e la versione del modello;
seed o parametri di generazione, dove rilevanti;
la cronologia delle modifiche;
l'esito della moderazione;
l'identificativo dell'utente o della richiesta;
il manifesto di output;
il manifesto Content Credentials (C2PA);
i riferimenti al dataset o al contesto di retrieval;
l'evento di approvazione o pubblicazione;
il pacchetto di consegna al cliente.

Non tutto questo deve essere pubblico. I dettagli sensibili possono restare in un manifesto privato di cui calcoli l'hash e che impegni attraverso una Merkle root. In seguito riveli solo il sottoinsieme necessario per una specifica controversia, un audit o una verifica del cliente — il resto rimane privato pur essendo comunque impegnato in modo dimostrabile.

Perché raggruppare con una Merkle root invece di un record per ogni output?

Una piattaforma può produrre migliaia o milioni di output. Pubblicare un record on-chain separato per ciascuno sarebbe lento e dispendioso. Una Merkle root ti permette di impegnare molti hash in un solo record.

Il flusso di lavoro è questo:

Genera o ricevi gli output.
Costruisci un manifesto canonico per ogni output.
Calcola l'hash dell'asset e del suo manifesto in una foglia.
Aggiungi la foglia a una lista ordinata.
Pubblica una Merkle root ogni ora, ogni giorno, ogni release o ogni batch.
Conserva la lista delle foglie e le inclusion proof.

In seguito puoi dimostrare che un output o un manifesto era incluso in un batch specifico senza pubblicare l'intero batch on-chain. Costruire l'albero e verificare una inclusion proof sono operazioni del tutto offline — solo la pubblicazione della root tocca un gateway. Con il tooling open source, una inclusion proof cresce con il logaritmo della dimensione del batch, quindi la prova di un elemento su un milione di foglie resta piccola. La meccanica nel dettaglio è descritta in un record per migliaia di file.

Come funziona questo insieme a C2PA e Content Credentials?

C2PA e Label 309 risolvono problemi diversi, e si combinano bene.

C2PA — la Coalition for Content Provenance and Authenticity, la cui forma rivolta agli utenti è Content Credentials — è un livello di provenienza strutturato. Un manifesto C2PA può trasportare assertion, claim, firme e binding che descrivono l'origine e la cronologia delle modifiche di un asset multimediale.

Label 309 ancora un hash — di quel manifesto, o dell'asset più il manifesto — a un timestamp Cardano indipendente. Quindi:

C2PA descrive la provenienza dentro o accanto all'asset multimediale.
Label 309 dimostra che un determinato impegno su un manifesto o un asset esisteva entro un momento pubblico, senza alcun server dell'emittente da considerare affidabile o a cui sopravvivere.

C2PA dà al contenuto un vocabolario di provenienza; Label 309 dà alle prove un'àncora temporale pubblica. Per un confronto più ravvicinato tra i due, vedi Proof of Existence e C2PA a confronto e perché C2PA trae vantaggio da un'àncora temporale.

Perché non affidarsi ai soli metadati incorporati?

I metadati incorporati possono essere rimossi, persi o trasformati lungo il percorso. La maggior parte delle ricodifiche dei social elimina del tutto un manifesto C2PA.

Questo non rende inutile la provenienza incorporata. Le Content Credentials sono preziose proprio perché viaggiano insieme al contenuto e permettono ai consumatori di ispezionarne l'origine. Ma un impegno esterno, con timestamp, aiuta quando i metadati vengono rimossi, contestati o separati dall'asset.

In pratica, un team conserva:

l'asset generato originale;
il manifesto C2PA;
il manifesto di output;
il riferimento della transazione Label 309;
la inclusion proof Merkle.

Se in seguito circola una copia priva dei suoi metadati, puoi comunque ricollegare l'asset o il manifesto originale all'impegno pubblico ricalcolando l'hash.

E le regole sulla trasparenza dell'AI?

La pressione normativa sulla provenienza dell'AI è in crescita. La panoramica dell'AI Act della Commissione europea afferma che i fornitori di AI generativa devono garantire che i contenuti generati dall'AI siano identificabili, e che le regole di trasparenza dell'AI Act entreranno in vigore ad agosto 2026.

Questa non è consulenza legale, e i requisiti variano a seconda della giurisdizione e del caso d'uso. Ma la direzione è chiara: le aziende che producono contenuti AI hanno bisogno di pratiche probatorie più solide.

La Proof of Existence non è di per sé un programma di compliance. È un livello probatorio che può supportare il lavoro di compliance rendendo i record più difficili da riscrivere silenziosamente a posteriori. Che sia d'aiuto in un determinato contesto normativo dipende dalla regola e dalla tua giurisdizione, e non sostituisce il parere di un legale.

Cosa può davvero dimostrare qui una prova Label 309?

Può dimostrare che dati esatti esistevano entro un momento pubblico. Per i contenuti AI, quei dati potrebbero essere un file di output, un manifesto prompt-e-output, un manifesto C2PA, una root di batch su molti asset generati, un report di moderazione, un record di approvazione o un manifesto di pubblicazione.

Tre funzionalità opzionali estendono ciò che un singolo record può trasportare:

Record firmati. Se il record porta una firma opzionale, mostra anche che una chiave specifica ha avallato il record. La paternità è sempre opzionale in Label 309 — non è mai richiesta per pubblicare.
Record sigillati. I file sensibili possono essere cifrati e conservati senza essere resi pubblici, con la chiave di cifratura del contenuto incapsulata verso una o più chiavi dei destinatari.
Merkle batching. Una sola root può coprire volumi di output molto ampi.

Cosa non dimostra?

Un impegno con timestamp è volutamente circoscritto. Non dimostra che il contenuto sia veritiero. Non dimostra che l'output provenga da un modello specifico, a meno che il contesto del modello non sia registrato e considerato affidabile come parte del tuo flusso di lavoro. Non dimostra che il contenuto sia stato generato, addestrato o pubblicato in modo lecito. Non dimostra che un manifesto C2PA sia affidabile, a meno che anche la validazione C2PA e il modello di fiducia del firmatario non risultino corretti. E non dimostra che la tua pipeline interna sia stata onesta, a meno che quella pipeline non sia essa stessa controllata, registrata e verificabile.

La prova è un impegno con timestamp su byte specifici. È il sistema di provenienza che la circonda a dare significato all'impegno. Per approfondire questo confine, vedi cosa non dimostra una prova.

Come dovrebbero strutturare il manifesto i team?

Mantienilo banale, canonico e stabile. Un manifesto di output AI potrebbe includere:

l'hash dell'asset e il tipo di asset;
il timestamp di creazione del sistema;
l'identificativo e la versione del modello;
i parametri di generazione;
un hash del prompt o un riferimento al prompt cifrato;
l'identificativo dell'utente o del workflow;
la decisione di moderazione;
l'hash del manifesto C2PA;
lo stato di pubblicazione;
l'identificativo del batch;
un riferimento di approvazione interno.

I valori sensibili non devono essere pubblici. Il manifesto può essere privato, sigillato o divulgato in modo selettivo più avanti; la prova pubblica si impegna sull'hash del manifesto, oppure su una Merkle root che copre molti hash di manifesti. La chiave è la coerenza: se ogni team inventa una nuova forma di manifesto ogni settimana, la verifica futura diventa un calvario.

I prompt dovrebbero essere pubblici?

Di solito no. I prompt possono contenere dati dei clienti, segreti commerciali, dati personali, materiale di safety testing o dettagli di policy interne. Puoi calcolare l'hash dei prompt o dei manifesti di prompt senza mai pubblicare il testo del prompt.

Per i flussi di lavoro sensibili, un record sigillato può conservare un pacchetto prompt-e-output cifrato. Un verificatore successivo in possesso della chiave giusta può decifrare il pacchetto, ricalcolare l'hash e confermare che corrisponde all'impegno pubblico. Questo ti dà prove senza renderle pubbliche dal primo giorno. Nota il limite: una volta che un destinatario decifra un pacchetto sigillato, ha in mano il testo in chiaro e può condividerlo — la sigillatura controlla chi può aprire il record, non cosa ne fa dopo. Lo schema è descritto in divulgazione confidenziale senza file pubblici.

Qual è una buona prima implementazione?

Parti dagli impegni a batch. Per ogni giorno o release:

Raccogli gli output generati che contano.
Costruisci un manifesto per ogni output.
Includi gli hash dei manifesti C2PA dove disponibili.
Calcola l'hash di ogni manifesto in una foglia.
Costruisci una Merkle root.
Pubblica un record Label 309 firmato.
Conserva la lista delle foglie, le inclusion proof e il riferimento della transazione.

Poi aggiungi la conservazione sigillata per i pacchetti sensibili e la verifica rivolta ai clienti per gli asset pubblici. L'obiettivo non è costruire l'universo di provenienza perfetto dal primo giorno — è smettere di perdere la cronologia. Lo stesso schema di batching ricompare nelle prove di build CI/CD e nei manifesti di dataset AI.

A chi serve tutto questo?

Questo schema si adatta a qualsiasi team che produce contenuti su larga scala e che in futuro potrebbe aver bisogno di dimostrare cosa ha generato e quando:

aziende di media AI e strumenti di design generativo;
piattaforme di video e immagini AI;
piattaforme di marketing automation;
team AI aziendali;
aziende di dati sintetici e team di valutazione dei modelli;
editori che usano flussi di lavoro assistiti dall'AI;
aziende che si preparano ad audit sulla provenienza dell'AI.

La versione breve

La provenienza dell'AI su larga scala richiede il batching. Calcola l'hash dei tuoi output e manifesti, raccogli gli hash in Merkle root e pubblica record Label 309 a cadenza. Conserva le liste delle foglie e le inclusion proof. Usa C2PA e Content Credentials per la provenienza dei media dove ha senso, e usa Label 309 come àncora temporale pubblica al di sotto.

La prova non stabilisce la verità né la legalità. Stabilisce la cronologia di byte esatti — ed è spesso il pezzo che non puoi più ricostruire a posteriori.

Approfondimenti

Ancora migliaia di file sotto un'unica root
Proof of Existence e C2PA a confronto e perché C2PA ha bisogno di un'àncora temporale
Manifesti di dataset AI e dimostra i dati di addestramento senza rivelarli
Cosa non dimostra una prova
C2PA / Content Credentials: c2pa.org, la specifica tecnica C2PA e contentcredentials.org
Commissione europea, Quadro normativo per l'AI
Lo standard aperto su label309.org e gli SDK e la CLI open source su github.com/cardanowall