Perché l'AI ha bisogno delle criptoattività, ora più che mai

a16z Crypto ha pubblicato di recente un carosello sintetico ma denso di contenuti, intitolato "AI needs crypto — now more than ever". Sei slide, sei tesi.

La convergenza tra intelligenza artificiale e blockchain non è più uno scenario speculativo. È una realtà che si sta strutturando a strati — infrastrutturale, identitario, finanziario — e che richiede un framework giuridico all'altezza. Proviamo a costruirlo, partendo dalle sei tesi di a16z.

1. Il problema della fiducia nell'era degli agenti

Il punto di partenza del carosello è semplice e chiaro: gli agenti AI operano alla velocità delle macchine. Ma chi garantisce che l'output sia affidabile? Chi risponde se un agente autonomo commette un errore, esegue un'istruzione distorta o viene manipolato da un attore malintenzionato?

Nell'AI Act europeo, i sistemi ad alto rischio — inclusi quelli che operano in ambito finanziario, creditizio o che influenzano decisioni rilevanti per le persone — sono soggetti a obblighi stringenti di trasparenza, supervisione umana e documentazione tecnica. Ma l'AI Act non si occupa ancora in modo esaustivo degli "agenti" autonomi nel senso più pieno del termine: sistemi che prendono decisioni su più step, gestiscono risorse e interagiscono con altri agenti.

Le criptoattività, nella visione di a16z, non sono solo una tecnologia finanziaria: sono un'infrastruttura di fiducia verificabile per sistemi che operano senza intermediari umani in tempo reale.

Dal punto di vista regolatorio, questo apre una questione cruciale: chi è il "deployer" di un agente AI che opera in autonomia? Chi è il "provider"? La risposta conta perché determina chi porta la responsabilità.

2. Il costo dell'impersonificazione AI: identità onchain come deterrente

La seconda tesi di a16z è chiara nella sua linearità: l'AI può impersonare esseri umani a costo zero. L'identità verificabile onchain rende questa operazione più difficile — e soprattutto più costosa.

Nel contesto del GDPR, il problema dell'impersonificazione AI ha già trovato una prima risposta parziale nella normativa eIDAS 2.0, che introduce il Digital Identity Wallet europeo. Ma eIDAS 2.0 non risolve il problema dell'autenticità in ambienti decentralizzati, né quello dell'anonimato selettivo.

3. Privacy by design onchain: la promessa degli zero-knowledge proof

Il terzo slide tocca un tema da sempre centrale nel dibattito tra blockchain e GDPR: la privacy. La risposta di a16z è elegante — zero-knowledge proof (ZKP). I sistemi basati su ZKP permettono di verificare che qualcosa sia vero senza rivelare il dato sottostante.

Questo è esattamente il principio di minimizzazione dei dati sancito dall'art. 5 del GDPR, applicato a un'architettura crittografica. In pratica:

• •posso dimostrare di avere più di 18 anni senza rivelare la mia data di nascita
• •posso dimostrare di essere residente nell'UE senza rivelare il mio indirizzo
• •posso dimostrare di non essere in una lista di sanzioni senza esporre la mia identità

Dal punto di vista del DPO, le architetture ZKP non eliminano il problema del dato personale — lo spostano. Il dato esiste comunque, viene solo gestito fuori dalla blockchain. La valutazione DPIA rimane necessaria.

Per i CASP e le piattaforme fintech che operano sotto MiCAR, l'integrazione di ZKP nei flussi di onboarding e di verifica KYC rappresenta una frontiera tecnica e regolatoria da presidiare. I protocolli di privacy onchain non sono ancora standardizzati a livello regolatorio europeo, ma le linee guida del Comitato Europeo per la Protezione dei Dati stanno evolvendo in questa direzione.

4. Identità decentralizzata: l'utente torna al centro

"Decentralized identity lets people — not platforms — own and control their data."

Questa slide condensa in una riga il principio di autodeterminazione informativa che la scuola tedesca del diritto ha elaborato per decenni.

Nel contesto europeo, il concetto di identità decentralizzata si lega a quello di Verifiable Credentials (VC) — standard W3C che il Digital Identity Wallet europeo adotterà. La differenza rispetto al modello attuale è strutturale: oggi le piattaforme custodiscono i dati identitari degli utenti (e spesso li monetizzano); con un'architettura DID + VC, l'utente porta con sé le proprie credenziali verificate e le condivide selettivamente.

5. Denaro che si muove alla velocità dell'AI: micropagamenti e rails crypto

Gli agenti AI hanno bisogno di risorse per agire. Prenotare un servizio, acquistare dati, remunerare un altro agente per un'attività computazionale: tutte operazioni che richiedono la capacità di movimentare valore in tempo reale, in piccole frazioni, senza la frizione dei sistemi bancari tradizionali.

Qui il mondo crypto non è solo «utile»: è strutturalmente necessario. I sistemi di pagamento tradizionali non sono progettati per transazioni da frazioni di centesimo eseguite migliaia di volte al secondo da software autonomi.

Dal punto di vista regolatorio, questo è uno dei nodi più delicati dell'intero ecosistema AI+crypto. Chi è il soggetto obbligato ai fini AML quando è un agente a eseguire il pagamento? Come si applica il Travel Rule a transazioni generate autonomamente da software?

MiCAR, nella sua attuale formulazione, non contempla esplicitamente i pagamenti eseguiti da agenti AI autonomi. DORA impone requisiti di resilienza operativa che si applicano ai sistemi informatici degli intermediari finanziari, ma non ancora alle architetture multi-agente. Il perimetro normativo è in costruzione, e chi entra nel mercato adesso deve farlo con un approccio di compliance proattiva e documentata.

6. Reti più umane: proof of personhood contro lo spam AI

La sesta tesi affronta il problema dell'inquinamento digitale: l'automazione può inondare le reti di rumore e spam. Il proof of personhood — meccanismi che provano crittograficamente che un account è controllato da un essere umano — è la risposta infrastrutturale proposta.

Nel contesto normativo, questo si lega direttamente al Digital Services Act (DSA), che impone alle piattaforme molto grandi obblighi di trasparenza sugli account automatizzati e di prevenzione della disinformazione. Il proof of personhood onchain potrebbe diventare uno strumento di compliance DSA oltre che un'infrastruttura di fiducia.

Per i marketplace di crypto-asset e le piattaforme DeFi, il tema è particolarmente rilevante: wash trading, bot di arbitraggio non dichiarati, manipolazione del mercato via agenti autonomi sono già oggi sul radar di ESMA e delle autorità nazionali competenti. L'identità verificabile degli operatori di mercato — umani o agenti — è un requisito che MiCAR e le prossime linee guida di ESMA tenderanno a rafforzare.

7. Agenti al servizio degli esseri umani: identità portabile cross-app

L'ultima slide del carosello introduce un concetto che sposta il frame: non è solo un problema di sicurezza o di pagamenti, è un problema di architettura dell'identità degli agenti. Se un agente porta con sé un'identità portabile attraverso le app, mantiene contesto, storia delle interazioni, preferenze.

Dal punto di vista del diritto dei dati, questo solleva la questione della portabilità — art. 20 GDPR — applicata non all'utente umano, ma all'agente che agisce per suo conto. Chi possiede i dati di addestramento contestuale di un agente personale? Sono dati personali dell'utente? Sono dati del provider del modello?

Il tema è aperto e avrà implicazioni pratiche molto concrete nei prossimi 18-24 mesi, man mano che gli agenti AI passeranno dalla fase sperimentale alla fase di deployment su larga scala.

Cosa fare adesso

Il carosello di a16z è, nella sua brevità, una mappa del territorio che viene. Sei problemi, sei soluzioni infrastrutturali. Ma tra la soluzione tecnica e la sua implementazione conforme al quadro regolatorio europeo — AI Act, MiCAR, GDPR, DSA, DORA — c'è un gap che richiede presidio legale e tecnico specializzato.

Per le aziende che già operano nell'ecosistema crypto-asset (CASP, exchange, piattaforme DeFi), la convergenza con l'AI non è un'opzione futura: è già in corso. I primi agenti che gestiscono portafogli, ottimizzano strategie di trading o eseguono funzioni di compliance automatizzata sono già in produzione.

La compliance non può rincorrere la tecnologia. Deve anticiparla. E anticiparla significa costruire oggi i framework legali, le DPIA, le politiche di governance degli agenti e i presidi AML che saranno richiesti domani.