zk-ML: perché l’AI verificabile ha bisogno del determinismo

Provate a rivolgere la stessa identica domanda allo stesso modello di intelligenza artificiale mille volte di fila, con la temperatura impostata a zero, il parametro che in teoria azzera ogni casualità. In un mondo ordinato otterreste mille risposte identiche. Un gruppo di ricercatori lo ha fatto davvero, su un modello da 235 miliardi di parametri, e ne ha ottenute ottanta diverse.

Questa piccola stranezza tecnica è il cuore di un problema molto più grande per tutto il settore dell’AI verificabile, e in particolare per lo zk-ML, la tecnica che usa le prove a conoscenza zero (zero-knowledge) per dimostrare che un modello ha davvero eseguito un certo calcolo. Se un’AI non riesce nemmeno a ripetere se stessa, come può una blockchain dimostrare, prova crittografica alla mano, che quel calcolo è stato fatto correttamente? La risposta, nel 2026, ruota attorno a una parola poco appariscente: determinismo.

Le puntate precedenti su HOGE Wire hanno spiegato che cos’è lo zk-ML, come funziona la sua pipeline e a cosa serve. Questa guida parte da un’angolazione diversa e meno battuta: il determinismo come precondizione nascosta di ogni prova sull’AI, il motivo per cui lo zk-ML ha la forma che ha, e la corsa, tutta del 2026, a rendere l’inferenza ripetibile bit per bit.

Che cos’è lo zk-ML, in due minuti

Lo zk-ML mette insieme due mondi: il machine learning e le prove a conoscenza zero. L’idea è produrre, accanto al risultato di un modello, una prova crittografica compatta che attesta una cosa precisa: dato questo modello e questo input, l’output è esattamente quello dichiarato. Chi verifica non deve rieseguire il calcolo, gli basta controllare la prova, un’operazione molto più economica. La fiducia si sposta: non più «fidati del server che ha fatto girare il modello», ma «verifica la matematica».

Il problema è che questa matematica costa. Nel suo saggio ormai canonico sull’incrocio tra crittografia e AI, Vitalik Buterin ricordava che moltiplicare matrici dentro un circuito ZK aggiunge un sovraccarico «inferiore a 4 volte», ma i layer non lineari (le funzioni di attivazione, il softmax) fanno esplodere il conto fino a «circa 200 volte», al punto che provare un singolo blocco Ethereum «può richiedere ore» (vitalik.eth.limo). Per anni questo ha relegato lo zk-ML a modelli giocattolo. Ma prima ancora del costo c’è un problema più sottile, quasi filosofico, che raramente finisce nei titoli: il modello deve produrre sempre lo stesso risultato, altrimenti non c’è nulla da provare.

È una distinzione che sfugge a molti. Rendere verificabile un’AI non vuol dire soltanto pubblicare il codice o i pesi del modello; vuol dire poter dimostrare, a chi non si fida, che un output specifico è il frutto legittimo di un modello specifico. E una dimostrazione ha senso solo se l’oggetto dimostrato è stabile. È da qui che nasce il legame, troppo spesso ignorato, tra la crittografia delle prove e l’ingegneria a basso livello delle schede grafiche.

La stessa domanda, ottanta risposte diverse

Il caso dei mille tentativi arriva da un lavoro pubblicato a settembre 2025 dai Thinking Machines Lab, il laboratorio guidato da ex ingegneri di primo piano dell’ecosistema PyTorch. Nel post «Defeating Nondeterminism in LLM Inference», l’autore Horace He e colleghi hanno preso il modello Qwen3-235B, impostato la temperatura a zero (la configurazione che dovrebbe rendere l’output completamente prevedibile) e gli hanno chiesto mille volte di raccontare chi fosse Richard Feynman.

Il risultato: mille completamenti, ottanta versioni distinte. Le risposte erano identiche per i primi 102 token, poi divergevano al token numero 103. In un caso, 992 completamenti scrivevano che Feynman era nato a «Queens, New York», mentre 8 dicevano «New York City» (thinkingmachines.ai). Attivando dei kernel appositi, tutti e mille i completamenti tornavano identici. Per uno sviluppatore di applicazioni questo è un fastidio. Per chi costruisce AI verificabile è una minaccia esistenziale: se lo stesso modello, sullo stesso input, con la casualità disattivata, non produce lo stesso output, la parola «prova» perde significato.

Il dettaglio interessante è che il fenomeno non dipende dal modello scelto. Il lavoro documenta lo stesso comportamento su reti di dimensioni molto diverse, dai grandi modelli conversazionali a quelli multimodali più compatti. Non è quindi il difetto di un singolo prodotto, ma una proprietà di come l’inferenza gira oggi sull’hardware di serie. Chiunque offra un servizio di AI, dai grandi provider ai piccoli nodi di una rete decentralizzata, eredita lo stesso problema.

Perché lo stesso modello non si ripete

La causa non è magia né vera casualità, ma banale ingegneria dei sistemi. Entrano in gioco due ingredienti. Il primo è la non associatività della virgola mobile: sommando numeri in floating point, (a + b) + c non dà necessariamente lo stesso bit di a + (b + c), perché ogni passaggio arrotonda. Il secondo, quello che il lavoro dei Thinking Machines Lab indica come vero colpevole, è la mancanza di invarianza rispetto al batch.

• Una GPU processa più richieste insieme, in un «batch», e il numero di richieste nel batch cambia in continuazione a seconda del carico del server.
• A seconda della dimensione del batch, il kernel (il pezzo di codice che gira sulla GPU) sceglie una strategia diversa per sommare i numeri, cambiando l’ordine delle operazioni.
• Ordine diverso, per la non associatività, significa bit diversi, e quindi, a valle, token diversi.

Horace He lo riassume così: «la ragione principale per cui quasi tutti gli endpoint di inferenza LLM sono non deterministici è che il carico (e quindi la dimensione del batch) varia in modo non deterministico». E ancora, in forma più generale: «se componi una proprietà rispetto alla quale il kernel non è invariante (la dimensione del batch) con la non determinatezza di quella proprietà (il carico sul server), ottieni un sistema non deterministico». La conseguenza è netta: la stessa richiesta, inviata quando il server è scarico o quando è affollato, può prendere due strade numeriche diverse.

Non puoi provare ciò che non puoi riprodurre

Qui sta il nodo che unisce tutto. Una prova, qualunque prova, è un’affermazione su un calcolo ben definito. Se il calcolo non è riproducibile, non esiste «il» calcolo su cui fare un’affermazione, ne esistono decine di varianti tutte plausibili. Ogni famiglia di AI verificabile inciampa nello stesso ostacolo, in modo diverso.

Lo zk-ML costruisce una prova che dice: «facendo girare questo circuito su questo input si ottiene questo output». Ma se il modello reale, su una GPU diversa, avesse dato un output leggermente diverso, la prova parlerebbe del circuito, non di ciò che l’utente ha davvero ricevuto. L’opML, di cui parliamo più avanti, si basa sulla ri-esecuzione: un verificatore rifà il calcolo e confronta. Se l’esecuzione onesta produce bit diversi, ogni nodo onesto sembra un truffatore. Il modello crypto-economico punisce (con lo slashing) il nodo che diverge dal consenso, ma se tutti i nodi onesti divergono per natura, lo slashing finisce per colpire l’onestà.

Il paradosso è che più si decentralizza, più il problema morde. In un sistema con un solo operatore fidato la non riproducibilità è un fastidio invisibile: nessuno confronta due esecuzioni. Nel momento in cui si chiede a più nodi indipendenti di concordare, o a un verificatore di rifare i conti, ogni minima divergenza numerica diventa indistinguibile da un tentativo di imbroglio. La decentralizzazione, che è il punto dell’intera crypto, trasforma un dettaglio numerico in una questione di fiducia.

Non è un caso che i progetti seri abbiano affrontato il problema alla radice. Gensyn, che verifica l’addestramento AI su hardware non fidato, ha costruito un intero strato chiamato RepOps proprio per rendere le operazioni riproducibili tra macchine diverse, come raccontato nella nostra analisi di Gensyn e del suo sistema Verde. Il determinismo non è un dettaglio a valle: è la precondizione su cui poggia qualsiasi discorso di verifica.

La virgola mobile, il vero nemico dello zk-ML

Per capire perché lo zk-ML ha proprio quella forma, bisogna guardare il rapporto tra circuiti e virgola mobile. I circuiti a conoscenza zero lavorano su campi finiti, cioè su numeri interi in aritmetica modulare, non sui numeri decimali in floating point con cui le GPU macinano le reti neurali. Elena Burger, deal partner di a16z crypto, lo spiega senza giri di parole: le prove a conoscenza zero, oggi, «non possono rappresentare operazioni in virgola mobile a 32 bit nel formato di circuito aritmetico necessario senza sovraccarichi enormi» (a16zcrypto.com).

La soluzione pratica è la quantizzazione: si converte il modello dalla virgola mobile a numeri interi, tipicamente a 8 bit. Ed è qui che i due fili, determinismo e zk-ML, si annodano. La quantizzazione non serve solo a risparmiare vincoli nel circuito, è anche una strategia di determinismo: si elimina alla fonte la non associatività della virgola mobile per ottenere una traccia di esecuzione fatta di interi, fissa e riproducibile, che si può poi trasformare in un circuito. Il prezzo lo mette in chiaro sempre Burger: il modello quantizzato è «una approssimazione grezza» di quello originale a piena precisione. È il classico compromesso tra accuratezza e dimostrabilità, e nasce direttamente dal problema del determinismo.

Vale la pena sfatare un equivoco comune: quantizzare non significa peggiorare il modello a caso, ma scegliere una rappresentazione a precisione ridotta e controllata, in cui ogni operazione dà lo stesso risultato ovunque venga eseguita. È il prezzo che lo zk-ML paga per avere una traccia di calcolo prevedibile. Buona parte della ricerca del 2026 punta ad abbassare quel prezzo, con schemi di quantizzazione più raffinati e con tecniche che spostano parte del lavoro fuori dal circuito senza rinunciare alla verificabilità.

Quattro modi di verificare l’AI, quattro debiti col determinismo

Lo zk-ML è uno dei quattro grandi approcci alla verifica dell’AI. Ognuno risolve in modo diverso la domanda «come faccio a fidarmi di un calcolo che non ho fatto io», e ognuno ha un conto aperto con il determinismo. La tabella qui sotto li mette a confronto.

Il dettaglio da notare è il filo comune: tre approcci su quattro (zk-ML, opML e crypto-economico) hanno bisogno di una risposta canonica e riproducibile per funzionare. Il TEE attesta che un certo programma è girato in un ambiente sigillato, ma non impone di per sé che due esecuzioni diano lo stesso bit. È il motivo per cui, nel 2026, la parola determinismo è finita al centro del dibattito tecnico su tutti e quattro i fronti.

opML: la prova che ri-esegue e confronta

L’opML (optimistic machine learning) è il caso in cui la dipendenza dal determinismo è più visibile. Il meccanismo, reso popolare da Ora Protocol, è preso in prestito dagli optimistic rollup: un nodo pubblica il risultato dell’inferenza dando per buono che sia corretto, si apre una finestra di sfida e chiunque può contestarlo. In caso di disputa, una macchina virtuale ri-esegue passo passo il calcolo conteso e confronta l’esito con quello dichiarato. Chi ha torto perde il deposito.

Tutto questo regge su una sola assunzione: la ri-esecuzione deve dare esattamente lo stesso risultato, bit per bit. Ecco perché le macchine virtuali dell’opML lavorano su interi e girano lontano dal non determinismo delle GPU: se la replica onesta divergesse anche di un solo bit, il sistema non saprebbe distinguere una frode da un normale rumore numerico. Il costo è la latenza: la finestra di sfida introduce un’attesa che rende l’opML poco adatto all’interattività in tempo reale.

Proprio per questo un filone di ricerca del 2026, gli Optimistic TEE-Rollup, prova a combinare l’esecuzione veloce dentro un TEE con le prove di frode ottimistiche, dichiarando di raggiungere circa il 99% del throughput di un sistema centralizzato con un sovraccarico dell’ordine di pochi centesimi di dollaro per richiesta. Anche in questi ibridi, però, il confronto tra l’esecuzione dichiarata e quella di controllo resta possibile solo se entrambe sono deterministiche. Il determinismo, qui, non è un’ottimizzazione: è la travatura portante.

La svolta del 2026: inferenza deterministica bit per bit

La buona notizia è che il problema del determinismo si sta risolvendo, e la spinta non arriva dalla crittografia ma dal cuore stesso del machine learning. La ricetta dei Thinking Machines Lab, resa pubblica come codice aperto, sono i «kernel invarianti rispetto al batch»: implementazioni di moltiplicazione di matrici, attenzione e normalizzazione che scelgono sempre lo stesso ordine di calcolo, indipendentemente da quante richieste ci sono nel batch. Fissato l’ordine, i bit tornano identici.

Non è un esperimento isolato. A settembre 2025 il team di SGLang, sostenuto da LMSYS, ha costruito sopra quegli operatori invarianti un motore di inferenza deterministico completo, arrivando a dichiarare un addestramento per rinforzo «riproducibile al 100%», con due esecuzioni indipendenti che tracciano curve identiche (lmsys.org). Il rallentamento medio dichiarato è intorno al 34%, un prezzo tutt’altro che proibitivo. Persino un divulgatore come Simon Willison ne ha parlato per il grande pubblico degli sviluppatori (simonwillison.net).

Il messaggio per la crypto è strategico. Per anni la verifica dell’AI on-chain ha dovuto reinventare da sola strumenti che il resto del mondo non chiedeva. Ora la ricerca mainstream, spinta dalla necessità di esperimenti riproducibili e di sistemi di produzione affidabili, sta costruendo le stesse fondamenta. I progetti crypto possono ereditarle invece di pagarle per intero, e concentrarsi sullo strato che è davvero loro: legare quell’output deterministico a una garanzia economica o crittografica. Il determinismo non è più una curiosità inventata dai criptografi, è un obiettivo di ingegneria condiviso da tutta l’industria dell’AI.

Quando la verifica diventa un confronto di byte

Il ponte tra questo lavoro e la crypto lo costruisce EigenAI, la piattaforma di inferenza verificabile costruita sull’ecosistema di restaking di EigenLayer. Il suo paper tecnico (arXiv 2602.00182) parte proprio dalle cause del non determinismo, elencandole senza pietà: «non associatività della virgola mobile, scheduling dei kernel e batching variabile». La proposta è un motore LLM deterministico affiancato a una ri-esecuzione ottimistica garantita da stake e slashing.

Il punto chiave, e la frase che vale l’intero lavoro, è che quando l’inferenza diventa bit-esatta la verifica si semplifica in modo drastico: «poiché l’inferenza è bit-esatta, la verifica si riduce a un controllo di uguaglianza tra byte, e una sola replica onesta basta a rilevare la frode» (arxiv.org). In un’altra sezione: «il determinismo fa collassare la verifica in un semplice controllo di uguaglianza», rendendo il predicato di verifica «sia corretto sia completo». A supporto, il paper riporta che «su 10.000 esecuzioni, tutti gli hash coincidevano esattamente, senza alcuna divergenza a livello di bit».

Il contrasto con lo zk-ML puro è istruttivo. Una prova a conoscenza zero resta imbattibile quando serve anche nascondere qualcosa (il modello, i dati, o entrambi) e quando chi verifica non può o non vuole rieseguire nulla. Ma se l’obiettivo è solo la correttezza, e i verificatori sono disposti a rifare il calcolo, il determinismo offre una scorciatoia radicale: niente circuiti, niente ore di proving, solo due hash da confrontare. Molti sistemi del 2026 combinano le due cose, usando la ri-esecuzione deterministica per il grosso del lavoro e le prove ZK dove serve davvero la riservatezza.

Vale la pena fermarsi su cosa significa. La verifica passa dal territorio costoso (proteggere con prove ZK o votare in modo probabilistico su un risultato) a un confronto di stringhe: due esecuzioni producono lo stesso hash oppure no. È la forma di verifica più economica immaginabile, e spiega perché nel 2026 anche progetti nati su altre strade guardino al determinismo come al vero acceleratore. Non a caso il dibattito su quanta parte di questo stack meriti una blockchain dedicata è ancora aperto, come raccontato nel nostro approfondimento su Ritual e l’AI verificabile.

Il conto da pagare: overhead e hardware canonico

Rendere deterministica l’inferenza costa, ma meno di quanto si temesse. Il paper EigenAI dichiara che i suoi kernel deterministici raggiungono «il 97-99% del throughput di cuBLAS» per le moltiplicazioni di matrici quantizzate, con un aumento di latenza end-to-end «di circa l’1,8%». I kernel dei Thinking Machines Lab, nelle prime implementazioni, mostravano un rallentamento tra 1,6 e 2,1 volte, poi ridotto; SGLang si assesta intorno al 34%. In tutti i casi, cifre gestibili.

C’è però un vincolo più insidioso, che il paper ammette con onestà: il determinismo tiene solo entro la stessa famiglia di GPU. EigenAI impone una «politica a singola architettura» in cui «tutti gli operatori e i verificatori devono usare SKU di GPU identici», perché i test tra architetture diverse (una A100 contro una H100) «non coincidono a livello di bit a causa delle differenze nell’arrotondamento della virgola mobile». La riproducibilità tra hardware eterogeneo resta un problema aperto, relegato ai «lavori futuri».

La conseguenza è quasi ironica. La promessa dei mercati GPU decentralizzati (chiunque affitta la sua scheda, di qualunque marca e modello) è la diversità dell’hardware. Il determinismo bit-esatto, invece, chiede un «bersaglio hardware canonico», cioè spinge tutti verso lo stesso chip. Verificabilità e decentralizzazione dell’hardware, sul filo dei bit, tirano in direzioni opposte, una tensione che pesa proprio sui protocolli come Akash, il cui valore ruota attorno alla domanda per un parco GPU quanto più ampio possibile.

Ci sono due vie d’uscita, entrambe imperfette. La prima è la normalizzazione numerica portabile, cioè far sì che GPU diverse producano lo stesso bit al costo di un po’ di prestazioni; è la strada che i ricercatori indicano come lavoro futuro, ma non è ancora pronta. La seconda è accettare insiemi di verificatori separati per ciascuna architettura, il che frammenta la rete in isole omogenee. In entrambi i casi il determinismo bit-esatto non è gratis sul piano della decentralizzazione: è un compromesso, non un pasto gratis.

Intanto la crittografia pura corre: lookup e DeepProve

Mentre il determinismo veniva domato, il fronte puramente crittografico dello zk-ML ha vissuto il suo anno migliore. La chiave tecnica sono i lookup e il sumcheck, che aggirano il collo di bottiglia storico: rappresentare le funzioni non lineari come circuiti. Con Jolt Atlas, la zkVM Jolt di a16z adattata dai ricercatori di ICME Labs e NovaNet alle operazioni tensoriali del formato ONNX, i costosi calcoli non lineari diventano semplici consultazioni di tabelle. Wyatt Benno, di ICME Labs, lo dice così: «i lookup eliminano del tutto la necessità di rappresentare il calcolo come circuito», con benchmark che portano l’inferenza da 4-5 secondi con gli strumenti precedenti a circa 0,7 secondi (blog.icme.io).

Il principio è elegante. Invece di codificare una funzione non lineare (una ReLU, un softmax) come una catena di vincoli aritmetici, la si pre-calcola in una tabella e si dimostra semplicemente che una certa coppia ingresso-uscita compare in quella tabella. Il sumcheck e le sue evoluzioni rendono questa verifica quasi gratuita rispetto al passato. Ed è qui che i due fili si toccano di nuovo: una traccia di esecuzione deterministica e intera è esattamente ciò che i lookup sanno macinare in fretta.

Il salto simbolico più grande porta la firma di Lagrange, il cui sistema DeepProve è stato il primo a provare end-to-end l’inferenza di un LLM completo (prima GPT-2, poi Gemma-3), con i modelli di classe Llama ancora in sviluppo. Reso open source a giugno 2026, DeepProve dichiara oltre 12 milioni di prove generate e miglioramenti dell’ordine di 60 volte nella generazione delle prove e 671 volte nella verifica rispetto allo stato dell’arte precedente (lagrange.dev). Il fondatore e CEO Ismael Hishon-Rezaizadeh ha accompagnato l’annuncio con una frase diventata uno slogan del settore: «non abbiamo costruito DeepProve per possedere l’AI verificabile, l’abbiamo costruito perché nessuno dovesse farlo. La scatola nera è aperta». Serve un frame conservativo: provare un LLM di frontiera resta lontano, ma la barriera del «lo zk-ML non regge gli LLM» si è incrinata.

A cosa serve davvero: oracoli, agenti, giochi

Tutta questa impalcatura, determinismo compreso, ha senso solo se serve a qualcosa. I casi d’uso reali del 2026 poggiano tutti sulla stessa fondazione: un output riproducibile che si può provare.

• Oracoli e DeFi. OpenGradient, in collaborazione con EZKL, alimenta un meccanismo di commissioni dinamiche per Uniswap V3: un modello fissa le fee del pool in base alla volatilità e una prova garantisce che il modello non sia stato manomesso (blog.ezkl.xyz).
• Agenti autonomi. Un agente che muove capitali dovrebbe provare l’inferenza prima di firmare una transazione; è la lacuna di fiducia che gli standard emergenti per gli agenti cercano di colmare, come discusso nella nostra guida al framework Eliza per gli agenti AI.
• Giochi e provably-fair. Dai giochi con AI on-chain alle demo come Turing Roulette, la prova impedisce all’operatore di cambiare il modello a partita in corso.
• Inferenza privata. La conoscenza zero permette di provare che un modello ha prodotto un risultato senza rivelare né il modello né i dati sensibili in input.

Le prove scalano, i token no

C’è una frattura evidente tra i progressi tecnici e la reazione del mercato. La tecnologia ha fatto passi enormi, ma i token dei progetti che la costruiscono restano schiacciati, quasi tutti tra l’86% e il 99,9% sotto i loro massimi storici. La tabella riassume la situazione al 25 settembre 2026, con prezzi in euro presi da CoinGecko.

Alcune avvertenze per leggere i numeri con onestà. Non tutti questi token sono puro zk-ML: EIGEN è soprattutto restaking e sicurezza crypto-economica, mentre PHA è confidential computing (TEE) e ha vissuto una fiammata isolata, oltre il 280% in un mese, che riguarda la sua scommessa sull’hardware, non la crittografia. I token strettamente legati alle prove ZK (LA, ZKC, GIZA) restano micro-capitalizzazioni. Il caso più eloquente è Giza: partita come progetto zk-ML nel 2023, ha poi ripiegato sugli agenti finanziari (AgentFi), e oggi capitalizza circa 157 mila euro (CoinGecko). È la fotografia di quanto sia difficile trasformare in ricavi una tecnologia di prova.

La domanda vera, allora, non è se la tecnologia funzioni, ma chi sia disposto a pagarla. Finora i clienti naturali sono tre: chi deve rispettare regole che impongono di dimostrare il comportamento di un’AI, gli agenti autonomi che maneggiano denaro e devono provare le proprie decisioni, e la DeFi, dove c’è capitale reale in gioco a ogni inferenza. Sono mercati promettenti ma ancora giovani, e questo spiega, più della qualità del codice, perché le valutazioni dei token siano rimaste indietro rispetto agli annunci tecnici.

Regole: AI Act europeo, Consob e il vuoto di Washington

Se c’è una leva che può creare domanda per l’AI verificabile, è la regolamentazione. In Europa l’AI Act è entrato nella fase applicativa: dal 2 agosto 2026 scattano l’applicabilità generale, l’enforcement della Commissione e dell’AI Office sui modelli di uso generale (GPAI) e gli obblighi di trasparenza, con sanzioni che per i GPAI arrivano fino a 15 milioni di euro o il 3% del fatturato mondiale, e tetti più alti per le violazioni più gravi (digital-strategy.ec.europa.eu). Gli obblighi più pesanti sui sistemi ad alto rischio sono invece stati rinviati, in scaglioni, al dicembre 2027 e all’agosto 2028. La direzione è chiara: chi userà l’AI in contesti sensibili dovrà dimostrarne il comportamento, e una prova crittografica è un modo forte di farlo. Non a caso Lagrange, citando una ricerca McKinsey, sostiene che il 71% dei dirigenti d’azienda non intende scalare i sistemi di AI senza una prova di correttezza.

In Italia il quadro sui crypto-asset è affidato a Consob per la condotta di mercato e la tutela degli investitori e alla Banca d’Italia per gli aspetti prudenziali e sulle stablecoin, secondo il decreto legislativo 129 del 2024 che ha recepito MiCA; il periodo transitorio si è chiuso il 1 luglio 2026. C’è anche una curiosità istituzionale: la stessa Consob usa tecniche di machine learning per la sorveglianza sugli abusi di mercato, con un principio esplicito di supervisione umana, il cosiddetto «human in the loop». È un promemoria che la verificabilità dell’AI interessa anche a chi vigila. Nel frattempo l’Unione sta rivedendo la stessa MiCA, con una consultazione che si chiude il 30 settembre 2026, tra chi vuole semplificare e chi vuole rafforzare le tutele, un bivio che abbiamo raccontato nel pezzo su MiCA tra semplificazione e tutele.

Sul versante opposto dell’Atlantico regna invece il vuoto. L’interpretazione congiunta di SEC e CFTC del marzo 2026 ha classificato come commodity digitali una manciata di grandi asset (Bitcoin, Ethereum, Solana, XRP), ma non ha detto nulla sui token dell’infrastruttura AI. LA, ZKC e PROVE restano così in una zona grigia normativa: né chiaramente dentro il perimetro europeo, né classificati oltreoceano. È lo stesso limbo che ha spinto alcuni progetti a chiedersi se un token serva davvero, o se la vera domanda per l’AI verificabile arriverà dalle regole prima che dai mercati. Va ricordato che MiCA disciplina i servizi sui crypto-asset a pronti e i loro emittenti, non l’infrastruttura di calcolo in quanto tale.

Domande frequenti

Che cos’è lo zk-ML in parole semplici?

Lo zk-ML unisce il machine learning e le prove a conoscenza zero. Serve a produrre, accanto al risultato di un modello AI, una prova crittografica che dimostra che quel risultato deriva davvero da quel modello e da quell’input, senza costringere chi verifica a rieseguire il calcolo. In pratica sposta la fiducia dal «fidati di chi ha fatto girare il modello» al «verifica la matematica».

Perché il determinismo è così importante per l’AI verificabile?

Perché una prova è sempre un’affermazione su un calcolo preciso. Se lo stesso modello, sullo stesso input, può dare risultati diversi, non esiste un unico calcolo da provare e la prova perde valore. Il determinismo, cioè la garanzia che il calcolo sia riproducibile bit per bit, è quindi la precondizione di zk-ML, opML e verifica crypto-economica.

Perché lo stesso modello AI dà risposte diverse alla stessa domanda?

Non per vera casualità, ma per due fattori tecnici: la non associatività della virgola mobile (l’ordine delle somme cambia i bit) e la mancanza di invarianza rispetto al batch, perché il numero di richieste elaborate insieme dalla GPU varia con il carico del server e cambia l’ordine dei calcoli. La soluzione sono i kernel invarianti rispetto al batch, che fissano l’ordine e rendono l’output riproducibile.

Lo zk-ML può già gestire i grandi modelli linguistici (LLM)?

In parte. Nel 2026 il sistema DeepProve di Lagrange è stato il primo a provare end-to-end l’inferenza di un LLM completo come GPT-2 e Gemma-3, e i lookup di Jolt Atlas hanno abbattuto il costo delle funzioni non lineari. Provare i modelli di frontiera più grandi resta però un obiettivo futuro: la barriera si è incrinata, non è ancora caduta.

Come sono regolati in Italia i token dei progetti zk-ML?

In Italia i crypto-asset ricadono sotto Consob (condotta di mercato) e Banca d’Italia (aspetti prudenziali), secondo il decreto legislativo 129 del 2024 che recepisce MiCA. I token legati all’infrastruttura di AI verificabile, però, non hanno una classificazione dedicata né in Europa né negli Stati Uniti, e restano in una zona grigia. L’infrastruttura in sé non è regolata direttamente, mentre lo sono i servizi e gli asset che vi si appoggiano.

Marcus Okafor scrive di AI, crittografia e infrastruttura on-chain per HOGE Wire.