Due direzioni opposte, vendute sotto la stessa etichetta
All'incrocio fra AI e blockchain si vendono due cose diverse. Una usa la catena come fonte dati, l'altra come notaio. Confonderle costa caro in fase di scope.
Sotto l'etichetta "AI più blockchain" si vendono due cose opposte. Hanno gli stessi ingredienti, compaiono nelle stesse slide, e risolvono problemi che non si assomigliano per niente. Chi sta valutando un progetto su questo incrocio farebbe bene a capire quale delle due gli viene proposta, perché la differenza non è di sfumatura: è di architettura.
Prima direzione: l'agente legge la catena
Nella prima direzione la blockchain è una fonte dati e l'agente è il consumatore. L'agente sorveglia wallet e movimenti, segue gli eventi di protocollo, segnala pattern che meritano un secondo sguardo, prepara il report di conformità che nessuno vuole scrivere il venerdì pomeriggio, rilegge uno smart contract prima del deploy e dice cosa non lo convince.
È lavoro utile, e in molti contesti è esattamente ciò che serve. Ma va chiamato con il suo nome: è un'integrazione. La catena sta a monte, l'agente sta a valle, e quello che l'agente produce va comunque creduto sulla parola. Se il modello sbaglia, il report sbagliato arriva sulla scrivania con la stessa formattazione ordinata di quello giusto.
Seconda direzione: la catena dimostra l'agente
Nella seconda direzione i ruoli si rovesciano. L'agente scrive un decision ledger strutturato a ogni chiamata: hash dell'input, tool invocati, versione del modello, output. Le voci si raccolgono in batch, dal batch si costruisce una radice di Merkle, e sulla catena si ancora solo quella. Nessun dato sensibile esce dall'infrastruttura del cliente: on-chain viaggia un'impronta, non il contenuto.
Qui la catena non è una fonte dati. Fa il notaio. Serve a rendere dimostrabile, anche verso un terzo che non si fida, che il registro delle decisioni dell'agente non è stato riscritto dopo il fatto. Una tabella di log nello stesso database dell'applicativo non offre questa garanzia: chiunque abbia i permessi giusti può modificarla, e nessuno può dimostrare che non sia successo.
La differenza di scope, vista da una software house .NET
Per una software house .NET la distinzione si traduce in stime molto diverse. La prima direzione è un progetto di integrazione: un SDK, un servizio di indicizzazione, un componente in C#, e il risultato si vede in poche settimane. La seconda tocca il modo in cui l'applicativo registra ciò che fa — e questa è una decisione che va presa prima di scrivere il primo agente, non dopo, perché retrofittare un decision ledger su un sistema che non lo prevede costa molto più che progettarlo da subito.
C'è anche un vincolo normativo che spinge nella stessa direzione. L'AI Act, per i sistemi ad alto rischio, richiede la registrazione automatica degli eventi. Non è un extra da aggiungere al preventivo in un secondo momento: è un requisito che condiziona l'architettura del sistema fin dall'inizio.
Il punto debole delle due direzioni è diverso, ed è un altro modo per distinguerle. La prima fallisce in silenzio, quando il modello sbaglia e nessuno se ne accorge. La seconda fallisce quando la voce del ledger la scrive un componente che nessuno ha revisionato: ancorare un record sbagliato dimostra soltanto che quel record sbagliato è vecchio.
Quasi tutte le proposte che girano in questo momento sono la prima direzione vestita da seconda. Si vende la parola "auditabilità" con l'architettura di un'integrazione dati. Chi firma il contratto se ne accorge tardi, di solito alla prima richiesta di un revisore.
Se state definendo un progetto su questo incrocio: quale delle due direzioni risolve il vostro problema?