Verifiable compute: l’inferenza si prova, l’addestramento no
Provare che un modello AI ha risposto in modo onesto è quasi un problema risolto nel 2026. Dimostrare come è stato addestrato resta la frontiera più dura del verifiable compute.
Un modello di intelligenza artificiale restituisce una risposta. Come fate a sapere che ha davvero eseguito il modello che dichiara, per intero, e non una versione più piccola e più economica che gli assomiglia? Questa è la domanda a cui risponde il verifiable compute, il calcolo verificabile, ed è la stessa domanda che un oracolo, un agente autonomo o un ente di vigilanza si pongono ogni volta che un calcolo avviene fuori dalla catena. Nel 2026 il settore è diventato sorprendentemente bravo a rispondere quando la domanda riguarda una singola risposta. Resta quasi impotente quando la domanda riguarda la cosa che quella risposta l’ha prodotta: l’addestramento del modello.
È questa la frattura che oggi organizza l’intero campo. Provare un’inferenza, cioè un passaggio in avanti del modello, è passato da fantascienza a ingegneria praticabile nel giro di diciotto mesi. Provare un addestramento, cioè i milioni di passaggi che hanno costruito i pesi del modello a partire da un dataset, resta un problema di ricerca. E il 2026 ha offerto la dimostrazione più eloquente proprio sul secondo fronte, quando i progetti nati per addestrare l’AI in modo decentralizzato e verificabile hanno fatto marcia indietro.
Due metà della stessa promessa
Il verifiable compute promette una cosa sola: insieme a un risultato, una prova a basso costo che quel risultato è stato calcolato correttamente, così che chi verifica non debba rieseguire il calcolo. La fiducia si sposta dal «fidati del server» al «verifica la prova». Finché il calcolo è deterministico e piccolo, la promessa è facile. L’AI rompe entrambe le ipotesi, e lo fa in due modi profondamente diversi a seconda che si parli di inferenza o di addestramento.
Un’inferenza è un singolo calcolo: prompt in ingresso, una sequenza di moltiplicazioni fra matrici, una risposta in uscita. Un addestramento è un processo: un intero dataset, milioni o miliardi di aggiornamenti dei pesi, settimane di tempo macchina, scelte di iperparametri che nessuno riscriverà mai passo per passo. Provare il primo significa certificare un’operazione; provare il secondo significa certificare una storia. Le due metà condividono lo stesso vocabolario (zero-knowledge, enclave, prove di frode, stake) ma hanno costi, maturità e domanda di mercato che nel 2026 divergono in modo netto.
Verifiable compute, in breve: un risultato più una prova
Conviene fissare la definizione, perché il termine viene spesso confuso con il suo vicino. Noleggiare potenza di calcolo in modo distribuito (quello che fanno marketplace di GPU come Akash, Render o le subnet di Bittensor) non è verifiable compute: quei sistemi affittano hardware, ma non dimostrano che l’hardware abbia calcolato in modo onesto. Il verifiable compute aggiunge il pezzo mancante, la prova. Chi riceve il risultato controlla un oggetto crittografico o economico leggero, invece di ripetere il lavoro.
La mappa concettuale più citata resta quella tracciata da Vitalik Buterin nel saggio «The promise and challenges of crypto + AI applications», dove distingue l’AI come giocatore, come interfaccia, come regola del gioco e come obiettivo, e avverte che usare l’AI per scrivere le regole di un sistema con valore economico è la categoria da trattare «con estrema cautela». Buterin nota anche il dato tecnico che spiega perché l’inferenza sia diventata trattabile: la parte più pesante di un calcolo AI sono le moltiplicazioni fra matrici, per cui è possibile costruire prove a conoscenza zero molto efficienti (meno di 4 volte l’overhead), mentre gli strati non lineari costano «circa 200 volte» e una prova ZK di un intero blocco Ethereum «può richiedere ore». La differenza fra 4x e 200x, e fra un passaggio e un milione, è tutta la storia che segue.
Perché nel 2026 provare l’inferenza è quasi un problema risolto
Due anni fa provare l’inferenza di un modello linguistico era considerato impraticabile: gli strati non lineari (le funzioni di attivazione come ReLU e softmax) facevano esplodere il costo dei circuiti aritmetici. Il muro si è incrinato. La svolta tecnica sono state le tabelle di consultazione (lookups) e il protocollo sumcheck, che eliminano la necessità di rappresentare quelle operazioni come circuiti, e il risultato più citato arriva da Lagrange: il suo sistema DeepProve è stato il primo a provare end-to-end l’inferenza di un modello linguistico completo (GPT-2, poi Gemma-3), con oltre 12 milioni di prove generate e più di 3 milioni di inferenze verificate, dichiarando una generazione delle prove fino a 60 volte più rapida e una verifica fino a 671 volte più rapida rispetto allo stato dell’arte precedente.
Il fondatore e CEO di Lagrange, Ismael Hishon-Rezaizadeh, ha riassunto così la posta in gioco al momento del rilascio open source: «Non abbiamo costruito DeepProve per possedere l’AI verificabile. L’abbiamo costruita perché nessuno dovesse farlo. La scatola nera è aperta». Lagrange, citando una ricerca McKinsey, sostiene che il 71% dei dirigenti d’azienda non scalerà i sistemi AI senza una prova di correttezza, il che riporta il discorso dalla crittografia alla domanda commerciale. Vale la nota di cautela: i modelli di frontiera (classe Llama e oltre) restano in sviluppo, non ancora provati end-to-end, quindi la parola «risolto» vale per i modelli piccoli e medi, non per i più grandi.
Nello stesso periodo si è sbloccato anche il problema gemello del determinismo. L’inferenza di un LLM su GPU non è riproducibile per via della non associatività dei calcoli in virgola mobile e della variabilità dei lotti (batch), e senza riproducibilità non c’è nulla da verificare. La risposta crittografica è arrivata con EigenAI, che dichiara un’esecuzione bit-exact: «su 10.000 esecuzioni, tutti gli hash hanno coinciso esattamente», così che la verifica «si riduce a un confronto di uguaglianza fra byte». Sommando prove a conoscenza zero mature, determinismo risolto ed enclave hardware veloci, nel 2026 per una singola inferenza esiste quasi sempre un metodo adatto. È l’altra metà a non avere ancora questa fortuna.
I quattro modi per provare un calcolo
Prima di capire perché l’addestramento resista, conviene avere sottomano i quattro strumenti con cui il settore prova un calcolo AI. Nessuno domina: ognuno sacrifica qualcosa fra integrità, latenza e costo, quello che il paper sui cosiddetti Optimistic TEE-Rollups chiama il trilemma della verificabilità.
| Approccio | Come prova | Garanzia | Limite principale | Progetti tipici |
|---|---|---|---|---|
| zkML (prove a conoscenza zero) | Una prova crittografica che il calcolo è avvenuto secondo il modello dichiarato | Matematica, senza fiducia in terzi | Costo di prova ancora alto sui modelli grandi; richiede quantizzazione | EZKL, DeepProve (Lagrange), Jolt Atlas, SP1 (Succinct) |
| TEE (calcolo riservato) | Attestazione firmata da un chip che isola l’esecuzione in un’enclave | Hardware: ci si fida del produttore del chip | Superficie di attacco fisica (vedi TEE.Fail); non è «fiducia zero» | Phala, EigenCompute, NVIDIA H100, Intel TDX |
| opML (ottimistico) | Si pubblica il risultato, si apre una finestra di sfida con prova di frode | Economica, con almeno un osservatore onesto | Latenza della finestra di disputa; niente interattività in tempo reale | Ora Protocol (OAO) |
| Crypto-economico | Stake vincolato e slashing di chi calcola in modo disonesto | Economica: costo di corruzione maggiore del profitto | Garanzia probabilistica, non una dimostrazione | EigenCloud (EigenLayer) |
Il nodo che accomuna i primi due e che tornerà sull’addestramento riguarda i numeri in virgola mobile. Come ha spiegato Elena Burger, Deal Partner di a16z crypto, le prove a conoscenza zero oggi «non possono rappresentare le operazioni in virgola mobile a 32 bit nel formato di circuito aritmetico richiesto senza overhead enormi», e questo costringe a quantizzare il modello a 8 bit, ottenendo una «approssimazione grezza» di quello originale. Si prova una versione semplificata, non sempre il modello esatto: una tensione che sull’addestramento diventa un abisso.
Addestrare non è inferire: la prova si fa mille volte più difficile
Perché provare l’addestramento è un problema di un altro ordine di grandezza? Quattro ragioni, e insieme spiegano perché ogni approccio del riquadro precedente si inceppi quando lo si punta sul training invece che sull’inferenza.
La prima è la scala. Un’inferenza è un passaggio in avanti; un addestramento ne contiene milioni o miliardi, ciascuno con una retropropagazione che tocca tutti i pesi. Se provare una singola inferenza costa secondi, provare crittograficamente un addestramento completo, passaggio per passaggio, è semplicemente fuori portata con la tecnologia del 2026. La seconda è la provenienza dei dati: certificare un’inferenza significa legare un output a un modello e a un input, ma certificare un addestramento significa anche dimostrare su quali dati è avvenuto, ed è un problema di catena di custodia, non solo di integrità del calcolo. La terza è il determinismo che si accumula: le minime divergenze in virgola mobile che su una inferenza si domano con kernel dedicati, ripetute per milioni di passaggi e su hardware diverso, rendono irriproducibile l’intera traiettoria. La quarta è la natura stessa di ciò che si prova: non un singolo risultato, ma un’intera storia di ottimizzazione che nessuno riesegue.
| Dimensione | Provare l’inferenza | Provare l’addestramento |
|---|---|---|
| Che cosa si certifica | Questo output viene da questo modello e da questo input | Questo modello è il risultato onesto di questi dati e di questa procedura |
| Numero di passaggi | Uno (un passaggio in avanti) | Milioni o miliardi di aggiornamenti dei pesi |
| Dati in gioco | Un prompt | L’intero dataset, più la sua provenienza |
| Costo della prova | Da secondi a minuti sui modelli piccoli e medi | Proibitivo end-to-end; si ripiega su replica o campionamento |
| Non determinismo | Domato con kernel bit-exact su hardware identico | Si accumula su milioni di passaggi; riproduzione cross-hardware irrisolta |
| Stato nel 2026 | Maturo sui modelli piccoli e medi, parziale sui grandi | Aspirazionale; in produzione solo surrogati |
Verde, TOPLOC e proof-of-training: come si prova (in teoria) un addestramento
La ricerca non è rimasta ferma, e vale la pena capire come aggira la scala, perché nessuna delle risposte è una prova crittografica completa dell’addestramento. La prima famiglia è la delega arbitrata (refereed delegation): invece di provare tutto, due o più calcolatori rieseguono il lavoro e, in caso di disaccordo, un arbitro ispeziona solo il singolo passaggio contestato. È l’idea del paper Verde, che la presenta come una via di mezzo fra l’onere di verificare interamente un addestramento e l’insicurezza degli approcci euristici, con test su modelli come DistilBERT (66 milioni di parametri), Llama-3.1-1B e Llama-3.1-8B. La replica sostituisce la crittografia: più economica, ma richiede che qualcuno rifaccia davvero il calcolo.
La seconda famiglia attacca il determinismo come precondizione. Il paper Optimistic Verifiable Training by Controlling Hardware Nondeterminism mostra che, se si controlla la non determinazione dell’hardware, un addestramento diventa abbastanza riproducibile da poterne contestare i passaggi con prove di frode: lo stesso schema ottimistico dell’opML, ma applicato al training. La terza famiglia è accademica: le costruzioni di tipo proof-of-training trasformano l’addestramento stesso nel lavoro utile di un consenso, come nel lavoro «Proof of Training», dove la rete viene ingaggiata per addestrare in modo provabile un modello sui dati forniti dal cliente. Sono eleganti, ma restano lontane dalla produzione.
C’è poi un dettaglio rivelatore. Il meccanismo di verifica più concreto in circolazione, il TOPLOC di Prime Intellect, non prova affatto il passaggio di addestramento: è uno schema di hashing sensibile alla località che verifica la fase di inferenza (la generazione dei rollout) all’interno del ciclo di reinforcement learning, restando robusto fra tipi di GPU diversi nonostante la non determinazione. In altre parole, anche il sistema di punta per l’addestramento decentralizzato risolve il suo problema di fiducia verificando delle inferenze. L’addestramento, nel punto in cui conta davvero (il gradiente, l’aggiornamento dei pesi), resta non provato.
Gensyn: il campione che ha messo in pausa l’addestramento
Se c’è un progetto che incarnava la promessa dell’addestramento decentralizzato e verificabile, era Gensyn. Sostenuto da a16z crypto, costruito come rollup Layer 2 su Ethereum, aveva lanciato RL Swarm, presentato come il primo test dal vivo di addestramento decentralizzato di AI su hardware di sconosciuti, con il meccanismo di verifica a delega arbitrata che eredita dalla linea di Verde. L’idea era seducente: chiunque presti una GPU, le prove garantiscono che il lavoro sia onesto, il token $AI paga i contributi.
Nel 2026 è arrivato il controcanto. Il primo prodotto in produzione di Gensyn non è un mercato dell’addestramento: è Delphi, una piattaforma di mercati informativi regolati dall’AI, in cui chi crea un mercato ne fa decidere l’esito a modelli AI fissati e verificabili anziché a esseri umani. Delphi è passato dalla testnet di dicembre 2025 alla mainnet nell’aprile 2026, e i nodi di RL Swarm sono stati sospesi per concentrare le energie sul primo prodotto con valore economico reale. In pratica, il poster child dell’addestramento verificabile ha spedito per prima cosa un oracolo AI per mercati predittivi, non il marketplace di training che aveva ispirato la sua esistenza. Chi vuole il dettaglio del dietrofront lo trova nella nostra analisi dedicata, Gensyn nel 2026: addestramento AI in pausa, Delphi al lavoro.
Lo ha confermato il cofondatore e CEO Ben Fielding, spiegando la mossa: «Delphi non compete direttamente con Polymarket e Kalshi sugli stessi mercati; la strategia è aprire una categoria interamente nuova di mercati di nicchia, di proprietà dei creatori, che quelle piattaforme non costruirebbero mai». Il token $AI, al momento del lancio di Delphi, non era ancora quotato: il modello prevede una commissione dello 0,5% sul volume per riacquistare e bruciare il token, e un 1,5% in USDC ai creatori sui mercati risolti. La lezione, per il tema di questo articolo, è semplice: provare l’addestramento era la missione; il prodotto che paga, almeno per ora, prova delle inferenze.
Prime Intellect e la gravità del cluster centralizzato
L’altro protagonista è Prime Intellect, che nel 2025 aveva fatto scalpore con INTELLECT-2, un modello da 32 miliardi di parametri addestrato interamente tramite reinforcement learning distribuito a livello globale, su GPU messe a disposizione da chiunque. L’impalcatura ha tre moduli: PRIME-RL per il reinforcement learning asincrono, SHARDCAST per distribuire i file dei pesi, e il già citato TOPLOC per la verifica. Secondo l’annuncio, TOPLOC abilita «una partecipazione davvero aperta, permettendo a chiunque nel mondo di contribuire risorse GPU in modo pienamente permissionless». Sulla carta, l’addestramento senza fiducia funziona.
Poi è arrivato INTELLECT-3, un Mixture-of-Experts da 106 miliardi di parametri rilasciato a fine novembre 2025, e qui la realtà ha presentato il conto. Il modello di punta non è stato addestrato in modo decentralizzato: è stato addestrato su un cluster centralizzato di 512 GPU NVIDIA H200 distribuite su 64 nodi con interconnessione InfiniBand a 400 Gbps, per circa due mesi. La ragione è la fisica dell’addestramento di frontiera: la larghezza di banda fra i nodi conta più della decentralizzazione, e il reinforcement learning su scala richiede una sincronia che una rete di sconosciuti non garantisce. Il token PRIME esiste su più catene ma resta scarsamente liquido. Quando è contato un modello competitivo, la gravità del data center co-locato ha avuto la meglio sull’ideale permissionless: un secondo indizio, dopo Gensyn, che nel 2026 l’addestramento verificabile e decentralizzato è più facile da raccontare che da spedire.
Il buco di provenienza: l’AI Act chiede le origini, i laboratori chiudono i rubinetti
Qui la storia tecnica incontra quella politica, e la tempistica è impietosa. Mentre provare l’addestramento resta aspirazionale, la trasparenza volontaria dei laboratori sta crollando proprio quando la legge inizia a pretenderla. L’AI Index 2026 di Stanford fotografa il paradosso: 80 dei 95 modelli di rilievo usciti nel 2025 sono stati pubblicati senza il codice di addestramento (solo quattro con codice aperto), l’indice di trasparenza dei foundation model è sceso da 58 a 40, e laboratori come Google, Anthropic e OpenAI hanno smesso di divulgare la dimensione dei dataset e la durata dell’addestramento dei loro modelli più recenti. I modelli più capaci sono, oggi, fra i meno trasparenti. Nello stesso rapporto, gli incidenti legati all’AI salgono a 362 nel 2025 (più 55% sull’anno prima), con l’adozione aziendale all’88%.
Dall’altro lato arriva l’obbligo. Dal 2 agosto 2026 diventano operativi i poteri di enforcement e le sanzioni dell’AI Act europeo per i fornitori di modelli di uso generale (GPAI), fino a 15 milioni di euro o il 3% del fatturato globale annuo. Tra gli obblighi: pubblicare un riassunto «sufficientemente dettagliato» dei contenuti usati per l’addestramento, seguendo un modello fornito dalla Commissione (fonti dei dati, copertura linguistica e geografica, tipi di contenuto, intervalli temporali), e conservare una documentazione tecnica versione per versione, con ritenzione decennale. L’AI Office può chiedere informazioni a qualsiasi fornitore che offra modelli nell’Unione, ovunque abbia sede.
Il punto che lega tutto è questo: la legge impone di dichiarare la provenienza dell’addestramento, ma nulla prova che la dichiarazione sia vera. Un riassunto compilato è un pezzo di carta; l’addestramento verificabile sarebbe esattamente la tecnologia capace di trasformarlo in una prova. È la domanda che non trova ancora l’offerta: il regime di conformità del 2026 gira sulla fiducia e sull’audit documentale, non su una dimostrazione crittografica, perché quest’ultima, sull’addestramento, non esiste ancora a un costo sostenibile.
Cosa cambia in Italia: Consob, Banca d’Italia e la provenienza dei modelli
Per il lettore italiano la cornice ha due livelli. L’infrastruttura in sé (le reti di prover, le enclave, le GPU) non è regolata in modo diretto: non è un servizio finanziario. Lo diventano però i token che la pagano e, soprattutto, i servizi costruiti sopra, quando un agente AI gestisce asset della clientela o alimenta una decisione di investimento. Qui entrano il MiCA e il decreto che lo attua in Italia, il D.lgs. 129/2024, che designa Consob per la condotta di mercato e la tutela degli investitori e la Banca d’Italia per i profili prudenziali e sulle stablecoin (ART ed EMT); il periodo transitorio del MiCA per gli operatori italiani si è chiuso il 1 luglio 2026.
Consob ha recepito gli orientamenti ESMA sulla classificazione delle cripto-attività, con un principio di sostanza sulla forma che decide se un token sia cripto-attività sotto MiCA o strumento finanziario sotto MiFID II, e ha ricordato, insieme all’ESMA, che l’uso dell’AI nei servizi di investimento non sospende gli obblighi di governance e accountability. Tradotto: una fintech o una banca italiana che usi un modello per selezionare titoli dovrà poterne documentare origine e comportamento. Non è un caso che l’ingresso delle banche italiane nella custodia e negli ETP cripto stia procedendo con prudenza: la provenienza provabile è esattamente il tipo di primitiva che un revisore vorrebbe, e che oggi manca.
L’applicazione più vicina alla realtà istituzionale, non a caso, non riguarda l’addestramento ma una prova molto più semplice: la prova di riserve. Un emittente può far girare i dati sensibili dentro un’enclave e pubblicare solo un verdetto firmato («coperto almeno 1:1») senza esporre le cifre, uno schema già sperimentato con il calcolo riservato di Flare per la stablecoin USDX di Hex Trust. Per un emittente di EMT europeo, la stessa meccanica potrebbe un giorno attestare le riserve richieste dal MiCA. Dove invece l’importo passa dal bilancio alla dichiarazione dei redditi, restano aperti i nodi fiscali che abbiamo trattato parlando dello scostamento e dell’aliquota al 26% nella Manovra 2027: provare un calcolo non esime dal dichiararne il risultato al Fisco.
Tecnologia su, token giù
C’è un modo rapido per misurare quanto il mercato creda alla narrazione dell’AI verificabile: guardare i token dei progetti che la costruiscono. Il divario è imbarazzante. Le prove scalano, i prezzi no. Tutti i principali token del settore delle prove restano fra l’80 e il 98% sotto il massimo storico, nonostante abbiano spedito tecnologia funzionante. La tabella sotto riporta i valori rilevati il 13 ottobre 2026 su CoinGecko (prezzi in euro, arrotondati).
| Token | Progetto | Approccio | Prezzo (EUR) | Cap. di mercato | Da massimo storico |
|---|---|---|---|---|---|
| EIGEN | EigenCloud | Crypto-economico | 0,217 | circa 211 mln | circa -96% |
| PROVE | Succinct | zkML (zkVM) | 0,169 | circa 33 mln | circa -88% |
| PHA | Phala Network | TEE | 0,049 | circa 42 mln | circa -96% |
| LA | Lagrange | zkML (DeepProve) | 0,057 | circa 11 mln | circa -96% |
| ZKC | Boundless | zkML (marketplace) | 0,034 | circa 9,9 mln | circa -98% |
| TAO | Bittensor | DePIN AI (proxy) | 248,59 | circa 2,8 mld | intero ecosistema |
E questo è il mercato dell’inferenza provabile, quello maturo. Il mercato dei token legati all’addestramento è ancora più rarefatto: il $AI di Gensyn non è quotato, il PRIME di Prime Intellect è poco liquido, e l’unico riferimento capitalizzato davvero è il TAO di Bittensor, che però è l’intero ecosistema di subnet, non un token puro dell’addestramento verificabile. Se la verifica dell’inferenza fatica a sostenere una valutazione, quella dell’addestramento non ha nemmeno un mercato su cui provarci.
Chi pagherà per provare l’addestramento?
La domanda commerciale per il verifiable compute esiste, ma si concentra dove il calcolo tocca denaro o conformità, e quasi sempre sull’inferenza. Un agente autonomo che firma una transazione ha interesse a provare di aver eseguito il modello giusto prima di muovere fondi; un oracolo che alimenta un protocollo DeFi deve dimostrare che il prezzo o il rischio non sono stati manomessi; un ente che adotta l’AI nei servizi regolati vuole un audit crittografico anziché una promessa. Sono i casi d’uso che raccontiamo analizzando a cosa serve davvero l’AI verificabile on-chain, e il filo comune è che il valore sta nel momento della decisione, non in quello della costruzione del modello.
Per l’addestramento la lista di chi paga è più corta. Ha senso provare un training solo quando la provenienza è giuridicamente o economicamente portante: modelli regolati sotto l’AI Act, contenziosi sulla proprietà intellettuale dei dati, licenze di modello dove il compratore vuole garanzie su che cosa ha davvero appreso la rete. Fuori da questi casi, il premio da pagare per una prova resta superiore al dolore che evita, e il mercato lo sa. Vale qui la lezione che aleggia su tutto il comparto, cristallizzata dal pivot di aziende nate zkML e poi convertite ad altro: la verifica pura è un business difficile, e non tutto ciò che si può provare conviene provarlo. Resta persino la domanda di fondo, se il verifiable compute abbia bisogno di un token proprio o sia piuttosto un servizio che qualcun altro venderà.
Il 2026 che verrà: ibridi, hardware canonico e il limite del determinismo
Sul fronte dell’inferenza la direzione è ormai tracciata: gli ibridi aggirano il trilemma invece di risolverlo. Le architetture di tipo Optimistic TEE-Rollup combinano la finalità rapida di un’enclave, le prove di frode ottimistiche e controlli a campione a conoscenza zero, dichiarando circa il 99% del throughput centralizzato a un costo intorno ai sette centesimi di dollaro per query. EigenCloud fa stake e slashing oggi con la promessa dello zero-knowledge domani, Ritual impacchetta il tutto in modo modulare. Per una singola risposta, insomma, nel 2026 si sceglie l’ibrido più adatto al proprio punto del trilemma.
Ma proprio qui si annida il limite che riporta la decentralizzazione con i piedi per terra. Il determinismo bit-exact che rende la verifica un semplice confronto fra byte funziona solo su GPU identiche: come ammette lo stesso paper di EigenAI, una A100 e una H100 non producono gli stessi bit, e processori di generazioni o produttori diversi divergono. Serve quindi un «bersaglio hardware canonico», che però ricentralizza il mercato delle GPU che si voleva aprire. È la stessa gravità che ha spinto Prime Intellect verso un cluster co-locato: l’ideale permissionless e il requisito di riproducibilità tirano in direzioni opposte, e sull’addestramento, dove i passaggi sono milioni, lo strappo è massimo.
Per l’addestramento, allora, la risposta realistica del 2026 non è una prova crittografica unica ed elegante, ma una pila di garanzie parziali: replica e delega arbitrata per dirimere le dispute, controlli alla TOPLOC sulle inferenze interne al ciclo, attestazione TEE dell’ambiente di addestramento, registri di provenienza e watermarking per i dati. «Provare» un training, oggi, significa impilare questi strati, non emettere un singolo SNARK. È meno soddisfacente di una dimostrazione pulita, ma è ciò che regge il peso quando la scala rende la crittografia pura impraticabile.
La parabola, in fondo, è questa. In diciotto mesi provare l’inferenza è passato dalla ricerca all’ingegneria; provare l’addestramento è il punto dove si concentra oggi il lavoro difficile ed economicamente più rilevante. L’AI Act ha trasformato la provenienza in un obbligo di legge proprio mentre la trasparenza volontaria dei laboratori crollava, e chi riuscirà a rendere l’addestramento provabile a basso costo si prenderà lo strato di audit dell’economia dell’AI. Per ora lo stato delle cose, alla fine del 2026, si riassume in una frase: la risposta si può provare, l’origine no, non ancora.
Domande frequenti
Che cos’è il verifiable compute?
Il verifiable compute, o calcolo verificabile, è la capacità di produrre insieme a un risultato una prova a basso costo che quel risultato è stato calcolato correttamente, così che chi verifica non debba rieseguire il calcolo. La fiducia passa dal fidarsi del server al verificare la prova. È diverso dal semplice noleggio di potenza di calcolo, che affitta hardware senza dimostrarne l’onestà.
Qual è la differenza fra provare l’inferenza e provare l’addestramento di un’AI?
Provare l’inferenza significa certificare un singolo calcolo, cioè che un output deriva da un dato modello e da un dato input. Provare l’addestramento significa certificare un intero processo fatto di milioni di passaggi su un intero dataset. Nel 2026 il primo problema è quasi risolto per i modelli piccoli e medi, mentre il secondo resta aspirazionale perché scala e provenienza dei dati lo rendono enormemente più costoso.
Si può davvero provare come è stato addestrato un modello AI?
Non ancora in modo completo e a costo sostenibile. Esistono metodi parziali come la delega arbitrata (per esempio Verde), i controlli di tipo TOPLOC che in realtà verificano la fase di inferenza dentro il ciclo di addestramento, e costruzioni accademiche di proof-of-training. Nessuno prova crittograficamente un addestramento di frontiera passaggio per passaggio: resta una frontiera di ricerca.
Cosa sono zkML, TEE e opML?
Sono tre dei quattro approcci al calcolo verificabile. Lo zkML usa prove a conoscenza zero, una garanzia matematica senza fiducia in terzi ma costosa sui modelli grandi. Il TEE usa enclave hardware attestate da un chip, veloci ma basate sulla fiducia nel produttore. L’opML pubblica il risultato e apre una finestra di sfida con prova di frode. Il quarto approccio è quello crypto-economico, basato su stake e slashing.
L’AI Act europeo obbliga a provare l’addestramento dei modelli?
No. L’AI Act obbliga i fornitori di modelli di uso generale a dichiarare e documentare la provenienza dell’addestramento, con un riassunto dei dati usati e una documentazione tecnica conservata per dieci anni, e dal 2 agosto 2026 prevede sanzioni fino a 15 milioni di euro o il 3% del fatturato. Ma chiede di dichiarare, non di dimostrare crittograficamente: è proprio il divario che l’addestramento verificabile punterebbe a colmare.
Marcus Okafor è redattore senior di HOGE Wire e segue AI, crypto e infrastrutture di calcolo verificabile.