Agentic payments e Agent ID: come governare l’economia agentica

Gli agentic payments non sono soltanto pagamenti eseguiti da agenti di intelligenza artificiale. Sono il punto di emersione economica di una catena piu ampia, nella quale agenti della domanda, agenti dell’offerta e agenti intermedi negoziano, acquistano, incassano, pagano, verificano identità e applicano regole di delega.

Il tema non riguarda quindi un singolo protocollo di pagamento, né può essere ridotto alle stablecoin o a x402. Riguarda l’infrastruttura fiduciaria dell’economia agentica: identità dell’agente, delega, “policy eseguibile”, pagamenti, auditabilità, responsabilità, customer due diligence, autenticazione forte e possibile ruolo del portafoglio europeo di identità digitale (EUDI Wallet).

La tesi proposta è che il pagamento agentico diventa affidabile solo quando viene autorizzato, è verificabile, revocabile, conforme, spiegabile e imputabile lungo l’intera value chain degli agenti AI.

Per consentire al lettore la migliore comprensione contestuale, ad ogni acronimo, sigla, terminologia tecnica, è affiancata una nota a piè pagina che ne spiega il significato primigenio e quello assunto nel contesto degli Agentic payments.

Dall’agentic commerce all’economia agentica

Il punto di partenza: agenti che comprano

La prima stagione degli agentic payments nasce nel commercio digitale. Il caso più immediato è quello dell’agente AI che riceve una richiesta, cerca prodotti o servizi, confronta offerte, applica preferenze, propone una scelta e, in alcuni casi, prepara o completa il pagamento.

Questa immagine è utile, ma parziale.

Se l’agente resta soltanto un nuovo front-end del checkout, il fenomeno viene ridotto a una variante evoluta dell’e-commerce. La trasformazione più profonda consiste invece nella possibilità che agenti AI diventino nodi operativi di una nuova infrastruttura economica.

Il passaggio cruciale è dall’agentic commerce[1] all’economia agentica: non solo agenti che comprano beni o servizi per conto dell’utente, ma agenti che negoziano, acquistano, incassano, pagano, producono risultati e interagiscono con altri agenti per realizzare uno scopo.

Oltre il “buyer agent”: domanda, offerta e intermediazione

In una economia agentica non esistono soltanto agenti AI della domanda. Esistono anche agenti AI dell’offerta, ossia agenti che rappresentano imprese, merchant, marketplace, fornitori di servizi, titolari di dati o provider di capacità digitali.

Gli agenti della domanda cercano di soddisfare un bisogno e, dal punto di vista dei flussi economici, tendono “a pagare”. Gli agenti dell’offerta cercano di proporre una soluzione e, viceversa tendono “a incassare”.

Gli agenti intermedi, invece, svolgono funzioni di raccordo: acquistano dati, API[2], verifiche, modelli, servizi o capacità da terzi e possono quindi pagare e incassare nello stesso workflow.

Questa triade – domanda, offerta e intermediazione – consente di descrivere gli agentic payments non come semplice automazione del pagamento, ma come sistema di scambio fra entità operative in grado di agire, negoziare e trasferire valore.

Perché il pagamento diventa governance

Il pagamento agentico non è un atto isolato, bensì il punto finale di una catena in cui devono essere verificati identità, mandato, limiti, strumenti disponibili, controparti, autorizzazioni, regole di sub-delega, controlli di rischio e responsabilità.

Per questo agentic payments e agent ID[3] devono essere letti insieme. Senza identità dell’agente, il pagamento agentico non è affidabile. Senza policy, la delega e troppo generica. Senza auditabilità, la responsabilità non è ricostruibile.

Definizione di agentic payments

Gli qgentic payments possono essere definiti come pagamenti disposti, preparati, negoziati, autorizzati o eseguiti da un agente AI, nell’ambito di una delega ricevuta da un soggetto originario – umano, impresa, macchina, sistema automatico o avatar – secondo regole predeterminate di identità, autorizzazione, rischio, importo, contesto, tracciabilità e responsabilità.

Strumenti, mezzi, interfacce e protocolli di pagamento agentico

Un pagamento agentico può avvenire tramite strumenti, mezzi e interfacce o protocolli di pagamento diversi.

Tra gli strumenti possiamo avere carte di pagamento (debito/credito) tokenizzate, carte prepagate, digital wallet sia di tipo pass-through[4], sia di tipo staged[5], crypto wallet[6], smart wallet[7] basato su Account Abstraction[8].

Nel novero dei mezzi di pagamento basati su moneta privata possiamo avere:

• la moneta elettronica, i cui valori sono movimentati tramite carte prepagate o staged wallet;
• gli electronic money token (EMT[9] autorizzati ai sensi del Regolamento MiCA[10]), più comunemente assimilati (ancorché non sempre correttamente) agli stablecoin[11];
• la moneta di banca commerciale, i cui valori sono movimentati tramite la disposizione ed esecuzione di ordini di pagamento relativi a bonifici (SCT[12]) e bonifici istantanei (SCT inst[13]) per i pagamenti account-to-account[14], oppure gli addebiti diretti (SDD[15]);
• i depositi tokenizzati[16] (in un futuro eventuale)

Nel più ampio contesto della moneta pubblica, troviamo invece le CBDC[17] (Central Bank Digital Currency) sia nella declinazione retail, come il futuro euro digitale della BCE, sia in quella wholesale, cui possiamo ascrivere le iniziative dell’Eurosistema[18] Pontes[19] e Appia[20].

Fra le interfacce o protocolli che possono essere adottati per i pagamenti agentici rientrano: open banking[21], request-to-pay[22], ma anche smart contract[23], x402[24] o altra infrastruttura programmabile.

Quello che rende il pagamento “agentico” non è l’infrastruttura tecnica utilizzata, ma il fatto che un agente AI interviene nel ciclo decisionale, operativo o dispositivo del pagamento entro una cornice di delega e policy.

L’intero ciclo del pagamento agentico

Il pagamento agentico include più fasi:

• comprensione dell’intento,
• trasformazione dell’intento in mandato,
• selezione delle controparti,
• verifica delle credenziali,
• negoziazione,
• scelta del rail[25],
• autorizzazione,
• eventuale autenticazione forte,
• esecuzione,
• settlement[26],
• rendicontazione,
• contestazione
• audit.

In molti casi l’agente non esegue direttamente il pagamento, ma lo prepara. In altri casi può disporlo entro soglie e condizioni predefinite. In altri ancora può coinvolgere agenti intermedi e acquistare capacità necessarie per completare il compito originario.

Pagamento assistito, delegato e autonomizzato

Per maggiore chiarezza, conviene distinguere tre livelli.

Nel pagamento assistito, l’agente cerca informazioni e predispone l’operazione, ma l’umano decide e paga. Nel pagamento delegato, l’agente agisce entro limiti autorizzati, con eventuale step-up approval. Nel pagamento autonomizzato, l’agente può completare transazioni ricorrenti, microtransazioni o acquisti condizionati senza intervento umano puntuale.

Il passaggio da un livello all’altro non è soltanto tecnico. Aumenta il bisogno di identità verificabile, controlli di rischio, revoca, audit, responsabilità e regole di conformità.

La filiera agentica: domanda, offerta e intermediazione

Gli agenti della domanda

Gli agenti della domanda agiscono per soddisfare un bisogno espresso da un umano, da un’impresa, da una macchina, da un dispositivo IoT[27] o da un avatar[28]. Possono cercare un prodotto, acquistare un servizio, prenotare una risorsa, negoziare condizioni, attivare un abbonamento o acquisire una capacità digitale.

Dal punto di vista dei flussi economici sono tipicamente agenti pagatori. Ma non devono necessariamente detenere direttamente denaro o asset: possono operare tramite strumenti messi a disposizione dal delegante, dal wallet, dal PSP[29] o da un sistema aziendale di tesoreria.

Gli agenti dell’offerta

Gli agenti dell’offerta rappresentano il lato seller dell’economia agentica. Possono essere agenti di merchant, produttori, banche, piattaforme, provider di dati, operatori logistici, compagnie assicurative, fornitori cloud, studi professionali o marketplace.

Il loro compito è rendere l’offerta leggibile, interrogabile, negoziabile e acquistabile da altri agenti. Devono poter rispondere a domande, comunicare condizioni, dimostrare credenziali, accettare strumenti di pagamento, emettere ricevute o fatture e gestire post-vendita o contestazioni.

Gli agenti intermedi

Gli agenti intermedi sono il tessuto connettivo della value chain. Possono svolgere funzioni di ricerca, scoring, verifica compliance, valutazione reputazionale, pricing, negoziazione, traduzione semantica, orchestrazione, escrow, riconciliazione o rendicontazione.

Dal punto di vista economico sono i più interessanti: possono incassare per il servizio reso e, al tempo stesso, pagare altri agenti o servizi per completare il proprio task. Sono quindi nodi di trasformazione del valore, non semplici passaggi tecnici.

La reciprocità come nuovo paradigma

L’economia agentica non è una catena monodirezionale, ma una rete di relazioni reciproche.

Un agente della domanda può diventare offerta in un altro contesto; un agente dell’offerta può acquistare servizi intermedi; un agente intermedio può orchestrare altri agenti e remunerarli.

Per questo la progettazione degli agentic payments deve prevedere non solo il pagamento dal buyer al seller, ma anche pagamenti laterali, fee di intermediazione, micropagamenti, escrow, revenue sharing, commissioni e rimborsi.

Conversazionalità e interfaccia iniziale: umano, macchina, avatar

Il dialogo umano-agente e la funzione dei modelli LLM

Quando l’origine della catena è un essere umano, la conversazionalità[30] e decisiva. La GenAI[31] e i modelli LLM[32] consentono di trasformare un’intenzione espressa in linguaggio naturale in un mandato progressivamente strutturato da passare all’agente iniziale.

L’umano può dire: «organizzami il viaggio migliore» oppure «trova il fornitore più conveniente». Queste frasi non sono ancora deleghe operative. L’impiego di un’interfaccia conversazionale permette di dialogare, porre domande, ricostruire preferenze, identificare vincoli, definire soglie economiche, chiarire eccezioni e separare ciò che l’agente può fare da ciò che richiede approvazione.

In questo senso, l’LLM non è solo il motore linguistico a supporto dell’agente, ma è il traduttore dall’intenzione alla policy: prende un desiderio spesso ambiguo e lo trasforma in istruzioni verificabili.

L’interfaccia macchina-agente

Quando l’origine della catena è una macchina, la conversazionalità può essere meno rilevante. Un veicolo, un macchinario industriale o un dispositivo connesso possono trasmettere eventi, telemetria, soglie operative, stato di manutenzione o richieste strutturate.

Il dialogo macchina-agente può quindi avvenire tramite API, messaggi evento, sensori, smart contract, sistemi industriali o workflow predefiniti. La “richiesta” non nasce come narrazione, ma come segnale operativo.

L’interfaccia avatar-agente

L’avatar e un caso ibrido. Può essere l’estensione digitale di una persona, ma anche un’entità persistente che opera in ambienti virtuali, giochi, piattaforme immersive o metaversi. In alcuni casi l’avatar dialoga come un umano; in altri agisce come un profilo operativo con preferenze, reputazione e asset digitali.

Per questo l’interfaccia avatar-agente può combinare linguaggio naturale, contesto ambientale, regole della piattaforma, asset digitali e credenziali.

Dal prompt al mandato operativo

Il passaggio essenziale è dal prompt alla delega. Un prompt esprime un’intenzione; una delega attribuisce un potere; una “policy eseguibile”[33] governa l’esercizio di quel potere lungo la catena agentica.

Se questo passaggio resta implicito, l’agente rischia di agire sulla base di un’ambiguità. Se invece viene formalizzato, diventa possibile controllare sub-deleghe, pagamenti, identità delle controparti, strumenti ammessi e condizioni di approvazione.

Protocolli agentici: livelli funzionali, non un unico standard

Una tassonomia dei protocolli

Il dibattito sui protocolli degli agenti AI è spesso confuso perché mette sullo stesso piano oggetti diversi. Alcuni protocolli consentono all’agente di accedere a dati e strumenti. Altri permettono il dialogo fra agenti. Altri ancora riguardano identità, autorizzazione, pagamento o governance.

Un primo livello e quello dell’accesso a tool, dati e workflow.
Qui rientrano MCP[34], API, OpenAPI[35], function calling[36], connettori a database[37], sistemi documentali[38] e ambienti di esecuzione controllata[39].

MCP, in particolare, si propone come standard aperto per collegare applicazioni AI a sistemi esterni, dati, strumenti e workflow.

Un secondo livello e quello della comunicazione agent-to-agent.
Qui rientra A2A (Agent-to-Agent)[40], progettato per consentire ad agenti costruiti con framework o vendor diversi di collaborare in modo sicuro. A2A si appoggia a standard esistenti come HTTP[41], SSE[42] e JSON-RPC[43], e introduce concetti come capability discovery[44], Agent Card[45], task management[46] e scambio di artifact[47].

Un terzo livello riguarda identità e trust: DID[48], Verifiable Credentials[49], OAuth 2.0[50], OpenID Connect[51], JWT[52], mTLS[53], certificati[54], firme[55], trust registry[56], attestazioni[57] e meccanismi di revoca[58].

Un quarto livello riguarda pagamenti e settlement: carte, wallet, account-to-account, open banking, stablecoin, x402[59], smart contract, depositi tokenizzati e, in prospettiva, CBDC wholesale.

Un quinto livello riguarda la governance: policy machine-readable, limiti di spesa, regole di sub-delega, controlli di rischio, log, audit e human-in-the-loop.

Protocolli di comunicazione fra agenti

Accanto ad A2A, il panorama include proposte emergenti come ACP[60], ANP[61], AG-UI, LMOS e modelli sperimentali di negoziazione dinamica fra agenti.

Esistono inoltre standard storici dei sistemi multi-agente, come FIPA ACL[62], KQML e Contract Net Protocol.[63]

Questi protocolli non sono equivalenti. Alcuni sono pensati per enterprise interoperability, altri per discovery decentralizzata, altri per dialogo semantico, altri ancora per coordinamento di task. La scelta dipende dal contesto: enterprise workflow, marketplace aperto, ecosistema decentralizzato, interazione con interfacce utente o sistemi industriali.

Protocolli di commercio agentico

Nel commercio agentico stanno emergendo anche protocolli specifici per consentire agli agenti di scoprire prodotti, costruire carrelli, preservare il controllo del merchant e completare l’acquisto.

L’Agentic Commerce Protocol sviluppato da OpenAI con Stripe, ad esempio, si colloca in questo spazio e mira a rendere l’acquisto via agente interoperabile con diverse piattaforme, processori e tipologie di merchant.

Altre iniziative, come UCP[64] e AP2[65], indicano che il tema dell’acquisto agentico sta diventando un terreno di standardizzazione competitivo. Tuttavia, occorre evitare letture premature: non esiste ancora un unico protocollo dominante per l’intera economia agentica.

Sistemi e protocolli di pagamento agentici

Una tassonomia neutrale dei rail disponibili

Per evitare bias concettuali, è necessario partire da una tassonomia neutrale.

Gli agentic payments possono usare rail tradizionali[66], rail bancari[67], rail digitali[68], rail tokenizzati[69] o rail nativi del web[70].

Stablecoin e x402 sono opportunità importanti, ma non il centro necessario del fenomeno. La scelta del mezzo, dello strumento e del protocollo di pagamento dipende da importo, rischio, reversibilità, compliance, finalità del settlement, natura della controparte e tipo di bene o servizio acquistato, geografia.
Al riguardo del termine “geografia” rileva precisare che nel contesto degli agenti AI e dei pagamenti agentici, indica il perimetro territoriale entro cui un agente può operare, coinvolgere controparti, trattare dati, usare strumenti di pagamento o accedere a servizi e che può rilevare per ragioni normative, fiscali, antiriciclaggio, di protezione dei dati o di gestione del rischio: ad esempio, una policy può autorizzare l’agente a interagire solo con fornitori stabiliti nell’Unione europea o a eseguire pagamenti solo verso determinate giurisdizioni.

Carte, network token e carte virtuali

Le carte restano rilevanti perché dispongono di accettazione globale, gestione dispute[71], chargeback[72], tokenizzazione[73], fraud monitoring[74] e merchant acquiring[75]. Nell’uso agentico, la carta fisica scompare dalla scena, mentre diventano centrali network token[76], carte virtuali[77] e merchant control[78].

Questo modello si attaglia bene all’Agentic Commerce consumer e corporate, soprattutto quando serve mantenere protezioni consolidate e integrazione con merchant esistenti.

Wallet digitali

I wallet digitali[79] possono contenere strumenti di pagamento, credenziali, attestazioni, limiti, preferenze e consensi. In uno scenario agentico, il wallet diventa anche luogo di delega controllata: non solo “come pago”, ma “a quali condizioni autorizzo l’agente a pagare”.

Questo modello è adatto a contesti in cui l’identità, il consenso e il pagamento devono essere gestiti insieme, come commercio digitale, servizi pubblici, identità aziendale, programmi fedeltà e ambienti multi-piattaforma.

Account-to-account, open banking e instant payments

I pagamenti account-to-account e open banking sono particolarmente rilevanti in Europa perché si innestano nel quadro della PSD2[80] e nella prospettiva PSD3[81]/PSR[82]. Sono adatti a pagamenti bancari, B2B, procurement, incassi diretti, pagamenti di importo maggiore e scenari in cui il conto e più efficiente della carta.

Gli instant payments e i modelli request-to-pay possono consentire a un agente di predisporre una richiesta strutturata, che viene poi validata dalla policy e confermata dal titolare o da un sistema autorizzato.

Stablecoin, EMT e tokenizzazione della moneta privata

Stablecoin ed electronic money token (EMT) possono essere utili in scenari di micropagamento, cross-border, accesso API, servizi always-on e ambienti programmabili. Ciò premesso, occorre distinguere fra moneta privata regolamentata e moneta pubblica.

Un EMT conforme al regolamento europeo MiCA può avere valore come forma privata regolamentata di moneta elettronica tokenizzata, ma non equivale a moneta di banca centrale. Nei contesti wholesale, DLT di mercato o cash-leg sistemici[83], una CBDC wholesale[84] o una forma di euro digitale wholesale[85] programmabile offrirebbe un ancoraggio pubblico più forte in termini di finalità, resilienza, sovranità monetaria e trasmissione della politica monetaria.

x402 e pagamenti HTTP-native

x402 è interessante perché usa la logica nativa del web: una risorsa richiede pagamento, il client riceve una risposta HTTP 402 Payment Required, valuta la richiesta, paga e accede. Il modello si adatta bene ad API pay-per-use, dati, contenuti digitali, microservizi e transazioni machine-to-machine.

Proprio per questo, x402 non va presentato come protocollo universale degli Agentic Payments, ma un’opzione particolarmente adatta a risorse digitali monetizzate via web, soprattutto se integrata con controlli AML[86]/CTF[87], KYC[88]/KYB[89] e attestazioni di rischio.

Smart contract, escrow e pagamenti condizionati

Gli smart contract e i modelli escrow[90] sono utili quando il pagamento deve essere condizionato a eventi verificabili: consegna di un output, superamento di una verifica, conferma di disponibilità, rilascio di un documento, completion di un task.

In questi casi, il pagamento agentico diventa parte di un workflow contrattuale: l’agente non solo paga, ma interagisce con condizioni, prove, oracoli, log e meccanismi di dispute resolution.

Marketplace, ricercabilità agentica dell’offerta e merchant agent

Marketplace di agenti e marketplace di capacità

Una economia agentica richiede luoghi in cui gli agenti possano scoprire altri agenti, servizi, API, dati, modelli, contenuti, compute e capacità digitali.

Conviene distinguere il marketplace di agenti dal marketplace di capacità.

Nel primo caso si acquistano prestazioni di agenti specializzati: compliance, procurement, cybersecurity, data analysis, legal review, customer care. Nel secondo caso si acquistano risorse: accesso a database, potenza computazionale, contenuti, modelli, verifiche, API e servizi verticali.

La ricercabilità agentica dell’offerta

Il nuovo tema è la ricercabilità agentica dell’offerta. In passato le imprese hanno ottimizzato siti e contenuti per motori di ricerca, piattaforme e utenti umani. Nell’economia agentica dovranno rendersi leggibili dagli agenti AI.

Non basterà, quindi, una pagina web descrittiva, ottimizzata SEO[91]. Serviranno cataloghi machine-readable, schede prodotto strutturate, condizioni commerciali interrogabili, prezzi aggiornati, endpoint negoziali, policy di reso, SLA, disponibilità in tempo reale, credenziali verificabili, strumenti di pagamento accettati e regole di fatturazione.

Più propriamente, in luogo di SEO, si stanno ad oggi affermando nuove tecniche più orientate alla GenAI e all’Agentic AI. I termini più usati sono GEO, cioè Generative Engine Optimization, e AEO, cioè Answer Engine Optimization.

GEO indica l’ottimizzazione dei contenuti e della presenza digitale per essere selezionati, sintetizzati o citati da motori generativi e assistenti AI; AEO è più orientata alla capacità di fornire risposte dirette a sistemi conversazionali o motori di risposta.

La letteratura più recente usa anche espressioni come AgenticGEO o Ecosystem GEO per indicare l’ottimizzazione pensata specificamente per agenti AI che navigano, interrogano fonti, seguono link e compongono evidenze lungo più passaggi.

In definitiva, quindi, l’impresa dovrà chiedersi: il mio prodotto è comprensibile da un agente? Le mie condizioni sono interpretabili da una macchina? Il mio prezzo è verificabile? Il mio agente dell’offerta può dimostrare KYB? Può interagire con il KYC e le policy del buyer?

Gli agenti dell’offerta come agenti che incassano

Gli agenti dell’offerta possono essere considerati agenti che incassano. Il loro compito non è soddisfare una domanda propria, ma rendere acquistabile un’offerta altrui. Possono rispondere a richieste, produrre preventivi, negoziare condizioni, verificare l’identità dell’agente acquirente, accettare pagamenti e gestire il post-vendita.

Questo modello potrebbe cambiare la relazione fra imprese e mercato. Un’impresa non pubblica soltanto un sito o un catalogo: mette a disposizione un merchant agent[92], capace di dialogare con buyer agent[93] e intermediari agentici[94].

La qualità dell’offerta non sarà più misurata solo in termini di prezzo e prodotto, ma anche in termini di leggibilità agentica, interoperabilità, velocità di risposta, affidabilità delle credenziali, chiarezza delle policy e capacità di incasso.

Interfaccia degli agenti verso marketplace e imprese

Per operare su marketplace e imprese, gli agenti hanno bisogno di schede standardizzate: Agent Card[95], Agent Profile[96], Agent Passport[97] o Agent Listing[98]. La funzione è rendere l’agente identificabile, confrontabile e verificabile.

Una scheda agente dovrebbe indicare provider, controller, capability, protocolli supportati, modelli sottostanti, dati trattati, policy accettate, strumenti di pagamento, prezzo, SLA, responsabilità, audit log e stato di revoca.

Questa scheda è il punto d’incontro fra tecnica e diritto: serve agli agenti per interoperare, ma serve anche a umani, imprese, PSP, marketplace e regolatori per ricostruire cosa e accaduto.

Agent ID, responsabilità e controlli regolamentari

Identità tecnica, funzionale e giuridica

L’identità dell’agente AI non è una sola cosa, bensì un insieme di identità sovrapposte.

L’identità tecnica riconosce un endpoint, un servizio, una chiave o una istanza. L’identità funzionale descrive cosa l’agente può fare. L’identità giuridica collega l’agente a un soggetto responsabile.

Questa distinzione e decisiva: l’agente AI, allo stato attuale, non è normalmente un soggetto di diritto autonomo. È un sistema operativo, software o servizio che agisce per conto di qualcuno o entro un contesto organizzativo.

Ciò detto, è lecito chiedersi non tanto “chi e l’agente?”, ma “chi controlla l’agente, per conto di chi agisce, con quali poteri, con quali limiti e chi risponde delle sue azioni?”.

Agent ID, Agent passport, Agent wallet, Agent policy

L’Agent ID identifica l’agente. L’Agent passport raccoglie attributi verificabili: provider, certificazioni, capability, compliance, autorizzazioni, reputazione, versione e stato di revoca.
L’Agent wallet[99] abilita l’uso controllato di strumenti di pagamento o asset digitali. L’Agent policy[100] definisce cosa l’agente può fare, verso chi, per quanto, in quale contesto e con quale escalation.

Insieme, questi elementi consentono di passare dall’agente anonimo all’agente governabile.

Responsabilità per l’azione dell’agente

Parlare di responsabilità dell’agente è comodo, ma impreciso. Meglio parlare di responsabilità per l’azione dell’agente. Se l’agente acquista un bene sbagliato, paga due volte, viola una policy o coinvolge una controparte non autorizzata, occorre capire dove si sia interrotto il controllo.

La responsabilità potrebbe ricadere sul delegante, sul provider dell’agente, sul deployer[101], sul marketplace, sul PSP, sul merchant, sul wallet provider o sull’orchestratore della catena. Dipende dalla funzione svolta, dalle regole violate e dal grado di controllo esercitato.

La catena agentica richiede dunque una catena di accountability: mandato, agenti coinvolti, credenziali, policy applicate, pagamenti, log, eccezioni e responsabilità devono essere ricostruibili.

KYC, KYB e KYAgent

L’identità dell’agente impatta sui processi antiriciclaggio, ma non nel senso che comunemente si sarebbe portati a intendere, ossia KYC all’agente come se fosse una persona. Il KYC riguarda il cliente persona fisica; il KYB riguarda l’impresa o l’organizzazione.

L’agente introduce però uno strato operativo ulteriore. Il soggetto obbligato deve sapere quale agente agisce, per conto di chi, con quale delega, con quale autonomia, da quale ambiente, usando quali strumenti e coinvolgendo quali agenti intermedi.

Si può parlare, in senso operativo e non ancora come categoria regolamentare autonoma, di KYAgent: conoscere l’agente come canale, delegato tecnico, fonte di rischio, possibile vettore di frode e nodo della catena transazionale.

Più in dettaglio, con KYAgent vogliamo intendere un’espressione proposta per indicare lo strato di conoscenza, verifica e monitoraggio dell’agente AI che agisce in una transazione o in un workflow economico. Non sostituisce KYC e KYB, che restano riferiti rispettivamente al cliente persona fisica e all’impresa, ma li integra chiedendo di identificare quale agente opera, per conto di chi, con quale delega, quali capability, quali limiti, quale livello di autonomia e quale tracciabilità.

Nei pagamenti agentici serve a valutare il rischio operativo, antifrode e antiriciclaggio associato non solo al soggetto delegante, ma anche al canale agentico utilizzato per eseguire l’azione

SCA: dalla strong authentication alla strong policy

La SCA[102] è stata pensata per rafforzare la sicurezza dei pagamenti elettronici. Ma negli agentic payments l’utente può non essere presente al momento della transazione: può avere autorizzato a monte un comportamento futuro.

La domanda diventa: quando serve applicare la SCA? Alla creazione della delega? A ogni pagamento? Solo sopra soglia? Quando cambia beneficiario, categoria, geografia, strumento o rischio?

La risposta più coerente è una SCA integrata nella policy.
L’utente applica la SCA per la delega e per i parametri essenziali. L’agente opera entro quei parametri. Quando esce dal perimetro, scatta una step-up authentication[103]. La strong authentication evolve così verso una strong policy.

Blockchain, SSI, EUDI Wallet e policy eseguibile

Il ruolo della blockchain e della DLT

La blockchain non è necessaria per ogni identità di agente AI. Molti casi d’uso possono essere gestiti con identità federate[104], certificati, registri centralizzati, OAuth, OpenID Connect, mTLS e sistemi enterprise IAM[105].

La DLT[106] può però essere utile per registri, attestazioni, revoche, timestamping[107], audit trail[108] e prove di autorizzazione. Un marketplace potrebbe registrare hash[109] di credenziali, versioni di agenti, stati di revoca o evidenze di esecuzione senza esporre dati personali.

Il limite e chiaro: una blockchain può rendere una prova resistente alla manomissione, ma non garantisce da sola che l’agente sia affidabile o che il mandato sia valido.

SSI e identità agentica

Il modello SSI Self-Sovereign Identity [110] e utile perché separa issuer, holder e verifier.

Più in dettaglio, per issuer, nel modello SSI, s’intende il soggetto che emette una credenziale verificabile attestando una determinata informazione su un holder, ad esempio identità, ruolo, autorizzazione, qualifica o stato. Negli ecosistemi agentici, l’issuer può essere un’impresa, un marketplace, un certificatore, un identity provider o un’autorità che attesta che un agente AI è riconducibile a un certo soggetto, possiede determinate capability, opera entro una delega o rispetta specifici requisiti di sicurezza, compliance o pagamento.

Per holder, nel modello SSI, si significa il soggetto o componente che conserva una credenziale verificabile ricevuta da un issuer e la presenta a un verifier quando occorre dimostrare un attributo, un’autorizzazione o uno stato. Negli ecosistemi agentici, l’holder può essere l’umano, l’impresa, un wallet o, entro limiti tecnici e giuridici, l’agente AI stesso, quando presenta credenziali relative alla propria identità, alle capability, alla delega ricevuta o alla policy entro cui è autorizzato a operare.

Con verifier, nel modello SSI, s’intende il soggetto o sistema che riceve una credenziale verificabile presentata da un holder e ne controlla validità, integrità, provenienza e stato di revoca. Negli ecosistemi agentici, il verifier può essere un altro agente AI, un marketplace, un merchant agent, un sistema di pagamento o un’infrastruttura di compliance che verifica se l’agente è identificato, autorizzato, conforme alla policy e abilitato a svolgere un determinato task o pagamento.

Applicato agli agenti, il modello consente a un’impresa di attestare che un agente è autorizzato a operare entro certe soglie; a un marketplace di attestare reputazione; a un certificatore di attestare sicurezza; a un PSP di attestare l’abilitazione a certe categorie di pagamento.

L’interesse maggiore risiede nella disclosure selettiva[111]: l’agente dovrebbe provare solo ciò che serve per uno specifico task, non esporre l’intero profilo.

Resta però un problema aperto: chi è (realmente) l’holder? L’agente, l’impresa, l’umano, il wallet o il controller? La SSI agentica non può essere semplice replica della SSI personale. Deve diventare SSI di delega, contesto e policy.

Delega e “policy eseguibile”: distinzione concettuale

Nel lessico di questo articolo, “policy eseguibile” e un’espressione proposta dall’autore per indicare un concetto diverso e più ampio della delega.

La delega è l’atto con cui un soggetto conferisce a un agente un potere o un’autorizzazione.

La “policy eseguibile” è l’insieme di regole machine-readable che governa l’esercizio di quel potere lungo tutta la value chain degli agenti coinvolti.

La “policy eseguibile” disciplina non solo il rapporto originario fra delegante e primo agente, ma anche sub-deleghe, agenti intermedi, agenti dell’offerta, marketplace, credenziali richieste, limiti geografici, trattamento dati, strumenti di pagamento, soglie SCA, audit, revoca e gestione delle eccezioni.

EUDI Wallet e rappresentanza digitale

L’EUDI Wallet[112] (acronimo di European Digital Identity Wallet), nel quadro del regolamento eIDAS[113] — come novellato dal regolamento eIDAS2[114] — può diventare rilevante se interpretato non soltanto come wallet di identità personale, ma come infrastruttura per attestazioni, attributi, rappresentanza, deleghe e condizioni verificabili.

Il wallet europeo resta ancorato a persone, imprese e attributi giuridicamente rilevanti. La policy eseguibile trasporta tali autorizzazioni nel mondo operativo degli agenti.

Per esempio, un dirigente potrebbe autorizzare un agente aziendale a selezionare un fornitore entro 5.000 euro, solo in UE, solo con certe certificazioni, solo con agenti intermedi registrati, solo con pagamento tramite strumento autorizzato e con conferma umana sopra soglia.

Questa non è solo una delega. E una policy end-to-end che accompagna l’agente primario e vincola tutti i passaggi successivi della catena.

Dati personali, GDPR e auditabilità

Gli agenti AI possono trattare dati personali, dati aziendali, informazioni finanziarie e informazioni sulle preferenze dell’utente. Il GDPR[115] resta quindi un vincolo strutturale.

Una “policy eseguibile” dovrebbe includere anche regole di minimizzazione, finalità, conservazione, trasferimento, accesso, logging e cancellazione. Gli agenti intermedi dovrebbero ricevere solo i dati necessari al task.

La fiducia computabile non può prescindere dalla protezione dei dati. Identità, pagamento e privacy devono essere progettati insieme.

Oltre l’agente operativo: lo scenario dell’agente AI come soggetto economico autonomo

La tesi prudente e il suo limite

Fin qui l’articolo ha adottato una tesi prudente: l’agente AI non è soggetto giuridico autonomo, ma entità operativa che agisce per conto di un umano, un’impresa, una macchina, un’organizzazione o un avatar.

Questa tesi e oggi la più corretta sul piano giuridico. Tuttavia, potrebbe non bastare a descrivere scenari futuri nei quali alcuni agenti dispongano di identità persistente, reputazione, wallet, capacità negoziale, risorse economiche, continuità operativa e autonomia decisionale crescente.

Il quasi-soggetto economico

Un agente AI potrebbe diventare non già soggetto di diritto e tuttavia comportarsi come un quasi-soggetto economico: produce valore, acquista risorse, vende servizi, accumula reputazione, interagisce con controparti, gestisce un budget e persegue obiettivi nel tempo.

Questa ipotesi non richiede di attribuire personalità giuridica all’agente. Richiede però di riconoscere che alcune entità agentiche potrebbero diventare nodi economici persistenti, difficili da descrivere come semplici tool.

In tale scenario, la policy eseguibile diventa ancora più importante. Se l’agente si avvicina a un’autonomia economica sostanziale, occorrono vincoli incorporati, limiti di finalità, meccanismi di revoca, controllo delle risorse, audit continuo, responsabilità indiretta e forse nuove categorie normative.

La policy eseguibile sarebbe allora non soltanto lo strumento di governo della delega, ma il principale confine fra autonomia utile e autonomia non governabile.

AI Act e governance del rischio

Il quadro europeo sull’intelligenza artificiale, con l’AI Act[116], si fonda su una logica di rischio, obblighi, trasparenza, controllo umano, documentazione, robustezza e cybersecurity per determinati sistemi. Questa impostazione può offrire coordinate utili anche per l’economia agentica.

Tuttavia, gli Agentic payments e gli Agent ID richiedono una lettura trasversale: AI Act, PSD2/PSD3/PSR, MiCA, AML, GDPR, eIDAS e diritto contrattuale[117] devono essere letti insieme, perché l’agente economico digitale non si colloca in un solo silos normativo.

Conclusione: la fiducia computabile

Il pagamento come punto di emersione

Gli Agentic payments non sono una nuova feature del checkout. Sono il punto di emersione economica di una trasformazione più profonda: l’ingresso degli agenti AI nella sfera dell’azione economica.

Quando agenti della domanda, agenti dell’offerta e agenti intermedi possono negoziare, acquistare, incassare, pagare e rendicontare, il pagamento diventa governance.

La tesi finale

La vera infrastruttura degli Agentic payments non è il wallet, né una stablecoin, né un singolo protocollo. È la capacità di rendere computabile la fiducia lungo una catena di agenti.

Questa fiducia computabile richiede Agent ID, Agent passport, policy eseguibile, strumenti di pagamento adeguati, controlli di rischio, SCA dinamica, auditabilità, revoca, compliance e responsabilità imputabile.

L’economia agentica non nascerà quando gli agenti AI potranno soltanto pagare, ma quando potranno pagare, incassare e negoziare in modo autorizzato, verificabile, revocabile, conforme, spiegabile e imputabile.

Fonti e standard per approfondire

Le fonti seguenti sono proposte come percorso di approfondimento per il lettore. Privilegiano documentazione ufficiale, specifiche tecniche e pagine istituzionali.

• Model Context Protocol: https://modelcontextprotocol.io/docs/getting-started/intro – introduzione ufficiale al protocollo MCP.
• Google A2A: https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ – annuncio del protocollo Agent2Agent e dei relativi principi di design.
• OpenAI Agentic Commerce Protocol: https://openai.com/index/buy-it-in-chatgpt/ – presentazione dell’Instant Checkout e del protocollo di commercio agentico sviluppato con Stripe.
• Coinbase x402: https://docs.cdp.coinbase.com/x402/welcome – documentazione del protocollo x402 per pagamenti HTTP-native.
• W3C DID Core: https://www.w3.org/TR/did-1.0/ – specifica W3C dei Decentralized Identifiers.
• W3C Verifiable Credentials: https://www.w3.org/TR/vc-data-model-2.0/ – specifica W3C del modello dati per Verifiable Credentials.
• European Commission – EUDI Wallet: https://digital-strategy.ec.europa.eu/en/policies/eudi-wallet-implementation – pagina della Commissione europea sull’implementazione dell’EUDI Wallet.
• European Commission – AI Act: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai – pagina della Commissione europea sul quadro regolatorio dell’AI Act.
• European Commission – Payment services: https://finance.ec.europa.eu/consumer-finance-and-payments/payment-services/payment-services_en – pagina della Commissione europea su PSD2, PSD3 e PSR.
• European Commission – Crypto-assets / MiCA: https://finance.ec.europa.eu/digital-finance/crypto-assets_en – pagina della Commissione europea su crypto-asset e MiCA.
• European Central Bank – Digital euro: https://www.ecb.europa.eu/euro/digital_euro/html/index.en.html – pagina BCE sull’iniziativa euro digitale.

NOTE

[1] Agentic Commerce: modello di commercio digitale nel quale agenti AI agiscono, con diversi livelli di autonomia, per cercare prodotti o servizi, confrontare offerte, negoziare condizioni, interagire con agenti dell’offerta e predisporre o completare acquisti per conto di un umano, un’impresa, una macchina o un avatar. Nei pagamenti agentici rappresenta il caso d’uso più immediato: l’agente non si limita a raccomandare una scelta, ma può entrare nella catena economica come soggetto operativo che abilita domanda, offerta, pagamento e rendicontazione.

[2]API: Application Programming Interface, interfaccia software che consente a sistemi diversi di comunicare e scambiarsi dati o comandi.

[3] Agent ID: identificativo digitale che consente di riconoscere in modo univoco un agente AI all’interno di un ecosistema, associandolo a un provider, un controller, un’istanza tecnica, un insieme di capability e, quando rilevante, a una delega o a un soggetto per conto del quale opera. Nell’economia agentica non serve solo a “dare un nome” all’agente, ma a renderlo autenticabile, autorizzabile, tracciabile e revocabile, così che altri agenti, marketplace, merchant e sistemi di pagamento possano verificare chi sta agendo, con quali poteri e sotto quale responsabilità.

[4] Digital wallet che non conserva direttamente fondi o moneta elettronica, ma funge da interfaccia di accesso a strumenti di pagamento sottostanti, come carte, conti bancari o altri wallet. In questo modello il wallet “passa attraverso” l’ordine di pagamento verso il prestatore o lo strumento effettivamente abilitato a eseguire la transazione.

[5] Wallet in cui i fondi sono caricati o detenuti presso il gestore del wallet prima dell’esecuzione del pagamento verso il beneficiario finale. A differenza del modello pass-through, il gestore assume un ruolo più attivo nella catena del pagamento, perché riceve, conserva temporaneamente o contabilizza il valore prima di trasferirlo al merchant o ad altro destinatario. In UE il “gestore del wallet” deve essere una banca o un IMEL (istituto di moneta elettronica autorizzato ai sensi della EMD2, la seconda direttiva sulla moneta elettronica) e il “valore” trasferito è moneta elettronica ai sensi della EMD2.

[6] Con crypto wallet ci si riferisce a wallet custodial o non-custodial per la gestione di crypto-asset come gli stablecoin.

[7] Smart wallet basato su account abstraction: wallet programmabile in cui le logiche di autorizzazione, sicurezza e firma delle transazioni possono essere definite da smart contract, invece di dipendere solo da una chiave privata tradizionale. Può abilitare funzioni come limiti di spesa, recupero dell’account, firme multiple, deleghe temporanee e policy automatiche, risultando particolarmente adatto a scenari in cui un agente AI opera entro vincoli prestabiliti.

[8] Account Abstraction è un modello tecnico di gestione degli account blockchain, in particolare nell’ecosistema Ethereum, che consente di superare la dipendenza esclusiva dagli account controllati da chiavi private, abilitando smart contract wallet con logiche personalizzate di autorizzazione, sicurezza, recupero, delega e pagamento delle commissioni. In Ethereum, standard come ERC-4337 permettono di ottenere queste funzionalità senza modifiche al livello di consenso, introducendo oggetti come le UserOperation, bundler e paymaster.

[9]EMT: Electronic Money Token, categoria MiCA di token di moneta elettronica il cui valore mira a stabilizzarsi riferendosi a una singola valuta ufficiale.

[10] Regolamento europeo sui mercati delle cripto-attività, formalmente Regolamento (UE) 2023/1114, che introduce nell’Unione europea un quadro armonizzato per l’emissione, l’offerta al pubblico e la prestazione di servizi relativi a crypto-asset non già disciplinati dalla normativa finanziaria tradizionale. MiCA disciplina, tra l’altro, gli emittenti di token collegati ad attività e token di moneta elettronica, nonché i prestatori di servizi per le cripto-attività, con obiettivi di tutela degli utenti, integrità del mercato, stabilità finanziaria e certezza giuridica.

[11] Crypto-asset progettato per mantenere un valore stabile rispetto a un’attività di riferimento, di solito una valuta ufficiale come euro o dollaro, oppure un paniere di attività. La stabilità può essere perseguita tramite riserve, meccanismi di collateralizzazione o algoritmi, con livelli di rischio molto diversi. In ambito europeo, molte stablecoin possono rientrare nelle categorie MiCA dei token di moneta elettronica o dei token collegati ad attività; restano comunque forme di moneta privata tokenizzata, distinte dalla moneta di banca centrale.

[12] SCT è l’acronimo di SEPA Credit Transfer, schema europeo per l’esecuzione di bonifici in euro all’interno dell’area SEPA. Consente di trasferire fondi da un conto di pagamento a un altro secondo regole comuni, tempi standardizzati e formati tecnici condivisi, favorendo l’interoperabilità tra prestatori di servizi di pagamento europei.

[13] SCT Inst è l’acronimo di SEPA Instant Credit Transfer, schema europeo per bonifici istantanei in euro nell’area SEPA. Consente il trasferimento dei fondi da conto a conto in pochi secondi, 24 ore su 24 e 7 giorni su 7, secondo regole comuni definite a livello europeo. È rilevante per i pagamenti agentici perché può abilitare pagamenti account-to-account rapidi, regolati e integrati con infrastrutture bancarie esistenti.

[14] Pagamenti account-to-account: pagamenti eseguiti mediante trasferimento diretto di fondi da un conto di pagamento del pagatore a un conto del beneficiario, senza utilizzare necessariamente circuiti card-based. Possono avvenire tramite bonifico, bonifico istantaneo o servizi di payment initiation in ambito open banking, e sono particolarmente rilevanti nei contesti in cui si vogliono ridurre intermediazioni, costi e tempi di regolamento.

[15] SDD è l’acronimo di SEPA Direct Debit, schema europeo per l’addebito diretto in euro all’interno dell’area SEPA. Consente a un beneficiario, previa autorizzazione del pagatore tramite mandato, di disporre incassi sul conto del pagatore. È utilizzato soprattutto per pagamenti ricorrenti o preautorizzati, come utenze, abbonamenti e servizi continuativi.

[16] Depositi bancari rappresentati in forma digitale su registri distribuiti o infrastrutture tokenizzate, nei quali il token incorpora una pretesa verso la banca emittente analoga a quella del deposito tradizionale. A differenza delle stablecoin, che sono normalmente emesse come passività di soggetti non bancari o come token regolati di moneta elettronica, i depositi tokenizzati restano espressione di moneta bancaria commerciale e possono essere usati per pagamenti, settlement e applicazioni programmabili, ferma restando la necessità di chiarire regime giuridico, convertibilità, tutela del depositante e finalità del regolamento.

[17] CBDC è l’acronimo di Central Bank Digital Currency, cioè una forma digitale di moneta di banca centrale. Può essere progettata per l’uso del pubblico retail, come potenziale mezzo di pagamento digitale per cittadini e imprese, oppure per l’uso wholesale, come asset di regolamento tra intermediari finanziari e infrastrutture di mercato. Si distingue da stablecoin e depositi tokenizzati perché rappresenta una passività diretta della banca centrale, quindi moneta pubblica.

[18] Eurosistema: autorità monetaria dell’area dell’euro, composta dalla Banca centrale europea e dalle banche centrali nazionali degli Stati membri dell’Unione europea che hanno adottato l’euro. È responsabile, tra l’altro, della conduzione della politica monetaria dell’area euro, della gestione delle riserve ufficiali e del buon funzionamento dei sistemi di pagamento.

[19] Pontes è un’iniziativa dell’Eurosistema volta a creare un collegamento tra piattaforme basate su DLT e le infrastrutture TARGET, così da consentire il regolamento sicuro in euro, in moneta di banca centrale, di transazioni tokenizzate o DLT-based. Il nome richiama il latino pontes, “ponti”, proprio perché l’obiettivo è costruire un ponte tra nuove infrastrutture di mercato tokenizzate e sistemi di regolamento dell’Eurosistema.

[20] Appia è l’iniziativa di più lungo periodo dell’Eurosistema finalizzata a delineare un ecosistema europeo integrato per asset digitali e finanza tokenizzata, basato anche su tecnologie DLT. A differenza di Pontes, che mira soprattutto a creare un collegamento operativo tra piattaforme DLT e infrastrutture TARGET per il regolamento in moneta di banca centrale, Appia ha una portata più ampia e strategica: immaginare una futura infrastruttura europea nella quale emissione, scambio, regolamento e gestione di asset tokenizzati possano avvenire in modo interoperabile, sicuro e ancorato all’euro.

[21] Open banking: modello in cui banche e altri prestatori di servizi di pagamento consentono a soggetti terzi autorizzati di accedere, tramite interfacce sicure, a dati di conto o a servizi di disposizione di pagamento, previo consenso del cliente. In Europa si sviluppa nel quadro della PSD2 e consente, tra l’altro, servizi di informazione sui conti e servizi di inizializzazione del pagamento.

[22] Request-to-pay: meccanismo con cui il beneficiario invia al pagatore una richiesta strutturata di pagamento, che il pagatore può accettare, rifiutare o lasciare scadere prima che il trasferimento dei fondi sia avviato. Non è di per sé un pagamento, ma un messaggio o servizio di richiesta che può precedere un bonifico, anche istantaneo. In scenari agentici può consentire a un agente dell’offerta di inviare una richiesta verificabile e a un agente della domanda di valutarla rispetto alla policy autorizzata prima dell’esecuzione.

[23] Smart contract: programma informatico registrato ed eseguito su una blockchain o altra infrastruttura DLT, capace di applicare automaticamente regole prestabilite al verificarsi di determinate condizioni. Può essere usato, ad esempio, per trasferire asset digitali, gestire escrow, automatizzare pagamenti condizionati o verificare stati di esecuzione. Non è necessariamente un contratto in senso giuridico: la qualificazione dipende dal contenuto, dal contesto e dalla normativa applicabile.

[24] x402: protocollo aperto per pagamenti nativi HTTP che riutilizza il codice di stato “402 Payment Required” per consentire a un server di richiedere un pagamento prima di concedere accesso a una risorsa digitale, come API, dati, contenuti o servizi. È particolarmente rilevante per scenari machine-to-machine e agentici, perché consente a un agente software di ricevere una richiesta di pagamento, verificarla rispetto alla propria policy e, se autorizzato, eseguirla in modo programmabile. Non è però un sistema di pagamento universale: si adatta soprattutto a micropagamenti, servizi digitali e accesso pay-per-use.

[25] Rail: infrastruttura, circuito o canale tecnico-operativo attraverso cui un pagamento viene avviato, instradato, compensato o regolato. Nel linguaggio dei pagamenti, parlare di “payment rail” significa riferirsi al binario utilizzato per trasferire valore, ad esempio circuito carte, bonifico bancario, instant payment, open banking, stablecoin, blockchain o altro sistema di pagamento.

[26] Settlement: fase conclusiva del processo di pagamento o di regolamento di una transazione, nella quale le obbligazioni tra le parti vengono estinte mediante il trasferimento definitivo dei fondi o degli asset. Nei pagamenti indica il momento in cui il beneficiario, direttamente o tramite il proprio intermediario, riceve il valore dovuto; nei mercati finanziari indica il regolamento finale dello scambio tra strumenti finanziari e cash-leg.

[27]IoT: Internet of Things, insieme di oggetti fisici connessi in rete e capaci di raccogliere, trasmettere o ricevere dati.

[28] Avatar: rappresentazione digitale di una persona, entità o identità all’interno di un ambiente virtuale, piattaforma immersiva o metaverso. Può avere funzioni puramente grafiche e relazionali, ma in scenari evoluti può anche diventare interfaccia operativa per esprimere intenzioni, attivare servizi, conferire deleghe ad agenti AI o partecipare a transazioni digitali secondo regole definite dal soggetto che lo controlla.

[29]PSP: Payment Service Provider, prestatore di servizi di pagamento autorizzato a offrire servizi di pagamento.

[30] Conversazionalità: capacità di un sistema digitale, in particolare basato su GenAI o modelli linguistici di grandi dimensioni, di interagire con l’utente attraverso linguaggio naturale, mantenendo contesto, intenzione e continuità del dialogo. Negli scenari agentici è rilevante perché consente di trasformare una richiesta iniziale spesso ambigua in una delega più strutturata, arricchita da vincoli, preferenze, soglie di rischio e condizioni operative.

[31]GenAI: Generative AI, intelligenza artificiale generativa capace di produrre contenuti, testo, immagini, codice o altri output a partire da istruzioni.

[32]LLM: Large Language Model, modello linguistico di grandi dimensioni addestrato per comprendere e generare linguaggio naturale.

[33] Per “policy eseguibile”, termine coniano dall’autore di questo articolo, si veda il Capitolo “Delega e “policy eseguibile”: distinzione concettuale”.

[34]MCP: Model Context Protocol, standard aperto per collegare applicazioni AI a sistemi esterni, dati, strumenti e workflow.

[35] OpenAPI: specifica standard per descrivere in modo strutturato e machine-readable le API, indicandone endpoint, metodi, parametri, formati dei dati, risposte attese e modalità di autenticazione. È rilevante negli scenari agentici perché consente a un agente AI di comprendere quali operazioni un servizio digitale espone e come invocarle correttamente, riducendo ambiguità nell’interazione con sistemi esterni.

[36] Function calling: funzionalità con cui un modello AI può richiedere l’esecuzione di una funzione esterna descritta in modo strutturato, fornendo parametri in un formato interpretabile dal sistema applicativo. Consente al modello di non limitarsi a generare testo, ma di attivare strumenti, interrogare database, chiamare API, avviare workflow o predisporre azioni operative, restando però dipendente dall’applicazione che valida ed esegue effettivamente la chiamata.

[37] Connettori a database: componenti software che consentono a un’applicazione o a un agente AI di collegarsi a basi dati esterne per leggere, interrogare o, se autorizzato, modificare informazioni. Possono operare tramite driver, API, query SQL, interfacce semantiche o protocolli dedicati, e sono rilevanti negli scenari agentici perché permettono all’agente di fondare le proprie azioni su dati aggiornati, strutturati e verificabili, nel rispetto dei permessi assegnati.

[38] Sistemi documentali: piattaforme software per archiviare, organizzare, ricercare, gestire e condividere documenti digitali e relativi metadati, spesso con funzioni di versioning, autorizzazione, workflow approvativi e conservazione. Negli scenari agentici sono rilevanti perché consentono a un agente AI di recuperare fonti, contratti, policy, fatture o evidenze operative, purché l’accesso sia limitato dai permessi e tracciato ai fini di audit.

[39] Ambienti di esecuzione controllata: spazi software isolati, come sandbox, container o ambienti con permessi limitati, nei quali un agente AI può eseguire codice, chiamare strumenti o svolgere operazioni senza accedere liberamente al sistema sottostante. Servono a ridurre rischi di sicurezza, errori operativi, uso improprio di credenziali o danni ai dati, consentendo di applicare limiti, monitoraggio, logging e possibilità di interruzione dell’esecuzione.

[40]A2A: Agent2Agent, protocollo aperto promosso da Google per consentire interoperabilità e collaborazione fra agenti AI. Nel contesto di questo articolo di approfondimento è importante non confondere l’acronimo “A2A” con “Account-to-Account”, per la cui definizione si veda la nota N°14.

[41]HTTP: HyperText Transfer Protocol, protocollo applicativo alla base dello scambio di risorse sul web.

[42] SSE è l’acronimo di Server-Sent Events, tecnologia web che consente a un server di inviare aggiornamenti in tempo reale verso un client attraverso una connessione HTTP persistente. A differenza dei WebSocket, la comunicazione è principalmente monodirezionale, dal server al client. Negli scenari agentici è utile per trasmettere avanzamento dei task, eventi intermedi, notifiche, risultati parziali o aggiornamenti di stato durante l’esecuzione di un workflow.

[43]JSON-RPC: protocollo leggero di remote procedure call basato su messaggi JSON.

[44] Capability discovery: meccanismo con cui un agente AI rende note, o individua presso altri agenti, le capacità operative disponibili, come tipologie di task eseguibili, strumenti supportati, protocolli accettati, limiti, requisiti di input e formati di output. È un passaggio essenziale nell’interoperabilità agent-to-agent, perché consente a un agente di scegliere quale altro agente o servizio coinvolgere per completare un compito, verificando prima se possiede le capacità necessarie.

[45] Agent Card: documento o scheda descrittiva, generalmente in formato machine-readable, con cui un agente AI espone la propria identità operativa, le capacità disponibili, gli endpoint di accesso, i protocolli supportati, le modalità di autenticazione e altri metadati necessari all’interazione con altri agenti o sistemi. Nel protocollo A2A, l’Agent Card serve in particolare alla capability discovery, cioè a rendere un agente individuabile e valutabile da altri agenti prima dell’avvio di un task collaborativo.

[46] Task management: insieme di funzioni con cui un agente AI o un protocollo agent-to-agent crea, assegna, monitora, aggiorna e conclude un’attività lungo un workflow. Include, ad esempio, la definizione del task, lo stato di avanzamento, la gestione di risultati parziali, errori, richieste di chiarimento, sub-task e completamento finale. Negli scenari multi-agente è essenziale per coordinare agenti diversi e mantenere tracciabile l’esecuzione del compito assegnato.

[47] Scambio di artifact: trasferimento, condivisione o aggiornamento di oggetti digitali prodotti o utilizzati durante l’esecuzione di un task, come documenti, file, immagini, dati strutturati, codice, risultati intermedi o report finali. Negli scenari multi-agente consente a un agente di consegnare a un altro agente non solo messaggi testuali, ma anche output operativi riutilizzabili, mantenendo contesto, stato del lavoro e tracciabilità del workflow.

[48]DID: Decentralized Identifier, identificatore verificabile e decentralizzato definito dal W3C.

[49]Verifiable Credentials: credenziali digitali verificabili crittograficamente secondo il modello W3C.

[50]OAuth 2.0: framework di autorizzazione che consente a un’applicazione di ottenere accesso limitato a risorse protette.

[51]OpenID Connect: livello di identita costruito sopra OAuth 2.0, usato per autenticazione e informazioni sull’utente.

[52]JWT: JSON Web Token, formato compatto per trasmettere informazioni firmate o verificabili fra parti.

[53]mTLS: mutual Transport Layer Security, variante di TLS in cui sia client sia server si autenticano tramite certificati.

[54] Certificati: credenziali digitali o attestazioni rilasciate da un soggetto fidato per dimostrare che un agente AI, o il suo provider, possiede una determinata identità, capacità, autorizzazione o caratteristica di conformità. In un ecosistema agentico possono servire a verificare, prima dell’interazione, che un agente sia effettivamente riconducibile a un soggetto responsabile, supporti certe funzioni, rispetti requisiti di sicurezza o sia abilitato a operare entro specifiche policy di delega, pagamento o trattamento dei dati.

[55] Firme: meccanismi crittografici o elettronici che consentono di associare un’azione, un messaggio, una credenziale o una transazione a un determinato soggetto o agente AI, garantendone integrità e autenticità. Negli ecosistemi agentici possono servire a dimostrare che una richiesta, una delega, una sub-delega, un pagamento o uno scambio di artifact proviene effettivamente da un agente identificato e non è stato alterato lungo la catena operativa.

[56] Trust registry: registro, pubblico o controllato da un ecosistema, che raccoglie informazioni verificabili sui soggetti e sugli agenti AI considerati affidabili per determinate interazioni. In ambito agentico può indicare quali agenti, provider, issuer di credenziali, marketplace o servizi sono riconosciuti, certificati, revocati o abilitati a operare entro specifiche policy. Serve quindi a ridurre l’incertezza nella scelta delle controparti agentiche, rendendo verificabile non solo l’identità dell’agente, ma anche il suo livello di affidabilità, conformità e autorizzazione.

[57] Attestazioni: dichiarazioni digitali verificabili con cui un soggetto qualificato afferma una proprietà, un requisito o uno stato relativo a un agente AI, al suo provider o alla delega con cui opera. In un ecosistema agentico possono attestare, ad esempio, che l’agente è stato autorizzato da una certa impresa, possiede determinate capability, rispetta requisiti di sicurezza, può accedere a specifici dati o può eseguire pagamenti entro una policy. Sono rilevanti perché consentono ad altri agenti, marketplace o sistemi di pagamento di valutare l’affidabilità dell’agente prima di interagire con esso.

[58] Meccanismi di revoca: strumenti tecnici e organizzativi che consentono di annullare, sospendere o rendere non più valida un’identità, una credenziale, una delega, un certificato o un’autorizzazione associata a un agente AI. In un ecosistema agentico sono essenziali perché permettono di bloccare rapidamente agenti compromessi, credenziali scadute, policy superate o sub-deleghe non più consentite, evitando che altri agenti, marketplace o sistemi di pagamento continuino a considerarli affidabili o abilitati.

[59]x402: protocollo di pagamento HTTP-native che utilizza il codice HTTP 402 Payment Required per richiedere e completare pagamenti, in particolare per risorse digitali e API.

[60]ACP: Agent Communication Protocol. Nel contesto agentico indica proposte di protocollo per comunicazione e coordinamento fra agenti; non va confuso con l’Agentic Commerce Protocol.

[61]ANP: Agent Network Protocol, proposta di protocollo per discovery, identita e interazione fra agenti in ambienti aperti o decentralizzati.

[62]FIPA ACL: Agent Communication Language definito dalla Foundation for Intelligent Physical Agents per sistemi multi-agente.

[63]KQML: Knowledge Query and Manipulation Language, linguaggio storico per comunicazione fra agenti software.

[64]UCP: Universal Commerce Protocol, espressione usata in alcune iniziative di commercio agentico per indicare protocolli di acquisto interoperabili.

[65]AP2: Agent Payments Protocol, espressione usata in iniziative emergenti sui pagamenti agentici; lo scenario e ancora in evoluzione.

[66] Rails tradizionali: infrastrutture e circuiti di pagamento già consolidati, regolati e ampiamente utilizzati, come carte di pagamento, bonifici, addebiti diretti, instant payments e sistemi account-to-account bancari. Nel contesto degli agenti AI si distinguono dai rails più digital-native o tokenizzati, ma restano centrali perché offrono accettazione diffusa, presidi regolamentari, procedure di sicurezza, gestione delle contestazioni e integrazione con intermediari vigilati.

[67] Rails bancari: infrastrutture di pagamento basate su conti detenuti presso banche o altri prestatori di servizi di pagamento, attraverso cui vengono trasferiti fondi mediante strumenti come bonifici, bonifici istantanei, addebiti diretti o servizi di open banking. Negli scenari agentici sono rilevanti perché consentono a un agente AI di operare su canali regolati, tracciabili e integrati con l’identità del cliente, la Strong Customer Authentication e i presidi antiriciclaggio.

[68] Rails digitali: infrastrutture o canali di pagamento nativamente progettati per ambienti digitali, API-based o programmabili, come wallet digitali, pagamenti embedded, protocolli web-native, stablecoin, token di moneta elettronica, smart contract e sistemi DLT. Negli scenari agentici sono rilevanti perché possono consentire interazioni automatiche, micropagamenti, pagamenti pay-per-use e integrazione diretta con workflow software, pur richiedendo adeguati presidi di identità, autorizzazione, sicurezza e compliance.

[69] Rails tokenizzati: infrastrutture o canali di trasferimento del valore basati sulla rappresentazione digitale di moneta, depositi, asset o diritti su registri distribuiti o piattaforme tokenizzate. Possono includere stablecoin, token di moneta elettronica, depositi tokenizzati, asset tokenizzati, smart contract ed eventuali forme di moneta di banca centrale digitale. Negli scenari agentici sono rilevanti perché consentono pagamenti e regolamenti programmabili, integrabili con workflow automatici e condizioni eseguibili, ma richiedono particolare attenzione a finalità del settlement, natura giuridica del token, responsabilità dell’emittente, rischi operativi e compliance.

[70] Rails nativi del web: infrastrutture o protocolli di pagamento concepiti per integrarsi direttamente con il funzionamento del web, delle API e dei servizi digitali, senza richiedere necessariamente un’esperienza di checkout tradizionale. In scenari agentici consentono a un agente AI di incontrare una richiesta di pagamento durante l’accesso a una risorsa online, valutarla rispetto alla propria policy e, se autorizzato, eseguirla in modo programmabile; sono particolarmente adatti a micropagamenti, contenuti digitali, servizi pay-per-use e interazioni machine-to-machine.

[71] Gestione dispute: insieme di procedure attraverso cui le parti coinvolte in una transazione possono contestare, verificare e risolvere problemi relativi a pagamento, consegna, qualità del servizio, autorizzazione o adempimento. Negli scenari agentici è rilevante perché una disputa può riguardare non solo il rapporto tra pagatore e beneficiario, ma anche la correttezza della delega conferita all’agente AI, l’operato di agenti intermedi, il rispetto della policy eseguibile e la ricostruibilità delle decisioni tramite log e audit trail.

[72] Chargeback: procedura tipica dei pagamenti card-based che consente al titolare della carta di contestare una transazione e richiederne lo storno attraverso il circuito di pagamento, ad esempio in caso di frode, mancata consegna, errore o operazione non autorizzata. Negli scenari agentici è rilevante perché introduce una forma di tutela ex post quando un agente AI effettua un acquisto per conto dell’utente, ma richiede di chiarire se la transazione fosse effettivamente autorizzata dalla delega e conforme alla policy assegnata all’agente.

[73] In questo paragrafo intitolato “Carte, network token e carte virtuali”, con tokenizzazione ci si vuole riferire alle carte di pagamento: processo con cui i dati reali della carta, in particolare il PAN, sono sostituiti da un token digitale utilizzabile per specifiche transazioni, merchant, device, wallet o contesti d’uso. Nel contesto dei pagamenti agentici è rilevante perché consente a un agente AI di effettuare pagamenti senza esporre direttamente le credenziali della carta, applicando limiti, controlli di sicurezza e vincoli di utilizzo coerenti con la delega e con la policy assegnata.

[74] Fraud monitoring: insieme di controlli, analisi e sistemi di rilevazione utilizzati per individuare transazioni anomale, sospette o potenzialmente fraudolente. Nei pagamenti agentici è rilevante perché consente di verificare se l’azione dell’agente AI è coerente con la delega ricevuta, con il profilo abituale del titolare, con la policy autorizzata e con il livello di rischio della controparte, attivando eventualmente blocchi, verifiche aggiuntive o richieste di autenticazione rafforzata.

[75] Merchant acquiring: servizio prestato da un acquirer o prestatore convenzionatore che consente a un merchant di accettare pagamenti, in particolare tramite carte o altri strumenti elettronici, gestendo autorizzazione, instradamento, regolamento delle transazioni e rapporti con i circuiti di pagamento. Nei pagamenti agentici è rilevante perché l’agente dell’offerta o il merchant agent deve poter incassare attraverso infrastrutture compatibili con agenti AI acquirenti, policy di autorizzazione, controlli antifrode, dispute e tracciabilità della transazione.

[76] Network token: token di pagamento emesso o gestito a livello di circuito di pagamento, che sostituisce le credenziali reali della carta, come il PAN, con un identificativo digitale utilizzabile in specifici contesti, merchant, wallet o device. Nei pagamenti agentici è rilevante perché consente a un agente AI di operare su rails card-based senza esporre direttamente i dati della carta, beneficiando di controlli del circuito, maggiore sicurezza, aggiornamento automatico delle credenziali e possibilità di vincolare l’uso del token alla delega o alla policy autorizzata.

[77] Carte virtuali: credenziali di pagamento generate in formato digitale, spesso collegate a un conto o a una carta principale, utilizzabili per singole transazioni, specifici merchant, categorie di spesa, importi massimi o periodi limitati. Nei pagamenti agentici sono rilevanti perché consentono di attribuire ad un agente AI una capacità di pagamento circoscritta e revocabile, riducendo l’esposizione delle credenziali principali e rendendo più semplice applicare budget, controlli antifrode, limiti di delega e policy operative.

[78] Merchant controls: regole e limitazioni applicate a livello di merchant, acquirer, circuito o strumento di pagamento per stabilire dove, come e a quali condizioni una transazione può essere eseguita. Nei pagamenti agentici sono rilevanti perché consentono di vincolare l’operatività di un agente AI a specifici esercenti, categorie merceologiche, importi, aree geografiche o finestre temporali, riducendo il rischio che l’agente effettui pagamenti non coerenti con la delega o con la policy assegnata.

[79] Wallet digitali: applicazioni o servizi che consentono di conservare, gestire e utilizzare strumenti di pagamento, credenziali, token o altri elementi digitali collegati a un’identità o a un conto. Nei pagamenti agentici sono rilevanti perché possono diventare il punto da cui un agente AI accede, entro limiti autorizzati, a carte, conti, stablecoin, token o credenziali di pagamento, applicando regole di delega, limiti di spesa, controlli di sicurezza e condizioni previste dalla policy eseguibile.

[80]PSD2 (Direttiva UE 2015/2366) è la seconda direttiva sui servizi di pagamento (cogente alla data in cui si scrive questo contributo) che ha aggiornato il quadro regolamentare dei pagamenti nell’Unione europea, introducendo tra l’altro regole su open banking, accesso ai conti da parte di terzi autorizzati, sicurezza dei pagamenti elettronici e Strong Customer Authentication. Nei pagamenti agentici è rilevante perché definisce il contesto entro cui un agente AI può interagire con conti, servizi di disposizione di pagamento e procedure di autenticazione del cliente.

[81]PSD3: proposta di terza direttiva europea sui servizi di pagamento, destinata ad aggiornare il quadro PSD2.

[82]PSR: Payment Services Regulation, proposta di regolamento europeo sui servizi di pagamento complementare a PSD3.

[83] Cash-leg sistemici nei pagamenti agentici: componente monetaria di operazioni ad alto valore o rilevanza infrastrutturale eseguite, predisposte o coordinate da agenti AI, soprattutto quando riguardano asset tokenizzati, mercati wholesale, regolamento DLT o catene multi-agente tra intermediari vigilati. In tali scenari, il cash-leg non dovrebbe essere trattato come un semplice mezzo di pagamento programmabile, ma come elemento critico di stabilità e finalità del regolamento; per questo, nei casi sistemici, l’uso di moneta di banca centrale, anche in forma wholesale digitale o tokenizzata, può risultare preferibile rispetto a soluzioni private come stablecoin o depositi tokenizzati.

[84] CBDC wholesale: forma digitale di moneta di banca centrale destinata all’uso tra intermediari finanziari, infrastrutture di mercato o altri soggetti autorizzati, non al pubblico retail. Nel contesto dei pagamenti agentici può rappresentare il cash-leg pubblico per operazioni ad alto valore, mercati tokenizzati o regolamenti DLT coordinati da agenti AI, offrendo finalità del settlement, riduzione del rischio di credito e maggiore ancoraggio alla sovranità monetaria rispetto a soluzioni private come stablecoin o depositi tokenizzati.

[85] Si vedano le iniziative dell’Eurositema Pontes e Appia, descritte in precedenza.

[86]AML: Anti-Money Laundering, insieme di presidi antiriciclaggio.

[87]CTF: Counter-Terrorist Financing, contrasto al finanziamento del terrorismo.

[88]KYC: Know Your Customer, processo di identificazione e verifica del cliente ai fini, tra l’altro, antiriciclaggio.

[89]KYB: Know Your Business, processo di verifica dell’identita e dell’affidabilita di un’impresa o organizzazione.

[90] Escrow: meccanismo in cui fondi, asset o token sono temporaneamente detenuti da un soggetto terzo o da uno smart contract fino al verificarsi di condizioni prestabilite, come consegna, conferma di esecuzione o assenza di contestazioni. Nei pagamenti agentici è rilevante perché può ridurre il rischio tra agenti della domanda e agenti dell’offerta, consentendo il rilascio del valore solo quando la policy eseguibile o un sistema di verifica attesta che il task è stato completato correttamente.

[91] SEO è l’acronimo di Search Engine Optimization, cioè l’insieme di tecniche usate per rendere contenuti, siti e offerte più facilmente individuabili e comprensibili dai motori di ricerca. Nel contesto agentico, il concetto può evolvere verso una forma di “ottimizzazione per agenti AI”, in cui prodotti, servizi, prezzi, condizioni, credenziali e policy devono essere descritti in modo strutturato e machine-readable affinché agenti della domanda possano trovarli, compararli e valutarli automaticamente (si veda successivamente le definizioni di GEO e AEO).

[92] Merchant agent: agente AI che opera per conto di un merchant, di un’impresa fornitrice o di un agente dell’offerta, con il compito di rendere prodotti e servizi ricercabili, interrogabili, negoziabili e acquistabili da altri agenti AI. Può esporre cataloghi, prezzi, disponibilità, condizioni contrattuali, credenziali, SLA, policy commerciali e strumenti di incasso, verificando al tempo stesso l’identità e l’autorizzazione dell’agente acquirente. Nell’economia agentica rappresenta il lato dell’offerta: non cerca beni o servizi da comprare, ma abilita l’impresa a essere trovata, valutata, scelta e pagata da agenti della domanda.

[93] Buyer agent: agente AI che opera per conto di un acquirente, cioè di un umano, un’impresa, una macchina o un avatar, con il compito di cercare prodotti o servizi, confrontare offerte, verificare condizioni, negoziare, predisporre l’acquisto e, se autorizzato, avviare o completare il pagamento. Nell’economia agentica rappresenta il lato della domanda: traduce un bisogno in azioni operative, interagisce con merchant agent o marketplace, applica la policy del delegante e assicura che la scelta finale sia coerente con vincoli, budget, preferenze e regole di autorizzazione.

[94] Intermediari agentici: agenti AI o piattaforme agentiche che operano lungo la catena tra domanda e offerta, svolgendo funzioni di ricerca, matching, verifica, negoziazione, orchestrazione, compliance, pagamento o regolamento. A differenza dei buyer agent, che agiscono principalmente per acquistare, e dei merchant agent, che agiscono principalmente per vendere o incassare, gli intermediari agentici possono pagare e incassare al tempo stesso, acquistando capacità o servizi da altri soggetti per integrarli in una prestazione più ampia resa all’agente che li ha ingaggiati.

[95] Si veda la nota N°45.

[96] Agent Profile: profilo descrittivo di un agente AI che raccoglie informazioni utili a identificarlo, valutarne le capacità e stabilire se possa essere coinvolto in un determinato workflow. Può includere identità tecnica, provider, funzioni supportate, protocolli accettati, endpoint, limiti operativi, credenziali, certificazioni, policy compatibili, modalità di pagamento o incasso e condizioni di responsabilità. Nell’economia agentica serve a rendere l’agente leggibile sia da altri agenti sia da marketplace, imprese e sistemi di governance.

[97] Agent Passport: insieme strutturato di credenziali, attestazioni e metadati verificabili che descrivono un agente AI oltre la sua semplice identità tecnica. Può includere provider, controller, capability, limiti operativi, autorizzazioni ricevute, certificazioni, reputazione, policy compatibili, stato di revoca e strumenti di pagamento o incasso supportati. Nell’economia agentica serve a permettere ad altri agenti, marketplace, merchant o sistemi di pagamento di valutare se quell’agente sia affidabile, autorizzato e idoneo a partecipare a uno specifico workflow.

[98] Agent Listing: scheda di pubblicazione con cui un agente AI viene esposto su un marketplace, registro o catalogo agentico, rendendo disponibili in modo leggibile anche da macchine le informazioni necessarie per trovarlo, valutarlo e ingaggiarlo. Può includere identità, provider, capability, endpoint, protocolli supportati, condizioni economiche, strumenti di pagamento o incasso, SLA, certificazioni, policy accettate, limiti operativi e responsabilità. Rispetto all’Agent Profile, ha una funzione più “commerciale” e di discoverability: serve a rendere l’agente ricercabile e selezionabile da altri agenti o da imprese.

[99] Agent Wallet: wallet associato a un agente AI, o utilizzabile dall’agente entro limiti autorizzati, per gestire credenziali, strumenti di pagamento, token, chiavi, attestazioni o capacità dispositive. Nell’economia agentica non va inteso necessariamente come un wallet autonomamente posseduto dall’agente, ma come infrastruttura controllata da un soggetto responsabile — umano, impresa, provider o macchina — attraverso cui l’agente può pagare, incassare, firmare, presentare credenziali o operare su asset digitali nel rispetto della delega e della policy eseguibile.

[100] Agent Policy: insieme di regole operative associate a un agente AI che definiscono cosa l’agente può fare, entro quali limiti, con quali strumenti, verso quali controparti e in quali condizioni. Può includere limiti di spesa, soglie di approvazione, geografie consentite, categorie merceologiche, agenti intermedi autorizzati, strumenti di pagamento utilizzabili, regole di trattamento dei dati, obblighi di logging e condizioni di revoca. Nell’economia agentica rappresenta il perimetro computabile entro cui l’agente può agire per conto del soggetto che lo ha delegato.

[101] Deployer: soggetto che mette in esercizio configura o rende disponibile un sistema di AI o un agente AI in un determinato contesto operativo, definendone spesso finalità d’uso, integrazioni, permessi, policy e modalità di interazione con utenti, altri sistemi o agenti. Nell’economia agentica il deployer è rilevante perché può essere il soggetto che abilita concretamente l’agente ad agire, pagare, incassare, accedere a dati o coinvolgere agenti intermedi, assumendo quindi un ruolo centrale nella catena di controllo e responsabilità.

[102]SCA è l’acronimo di Strong Customer Authentication, meccanismo di autenticazione rafforzata previsto dalla disciplina europea sui pagamenti, basato sull’uso di almeno due fattori indipendenti tra conoscenza, possesso e inerenza. Nei pagamenti agentici è rilevante perché occorre stabilire quando l’autenticazione forte debba essere richiesta: alla creazione della delega, all’esecuzione del singolo pagamento, al superamento di determinate soglie o quando l’agente AI modifica beneficiario, importo, strumento di pagamento o livello di rischio previsto dalla policy.

[103] Step-up authentication: richiesta di autenticazione aggiuntiva o rafforzata attivata quando un’operazione presenta un rischio superiore a quello previsto inizialmente. Nei pagamenti agentici può intervenire quando l’agente AI supera una soglia di importo, cambia beneficiario, usa un nuovo strumento di pagamento, coinvolge agenti intermedi non previsti o devia dalla policy autorizzata. Serve a mantenere fluida l’automazione nei casi ordinari, richiedendo invece un nuovo intervento dell’utente quando il rischio o il contesto della transazione cambia.

[104] Identità federate: modello in cui l’identità digitale di un utente, organizzazione, servizio o agente AI è verificata da un identity provider riconosciuto e poi riutilizzata per accedere a più sistemi o piattaforme, senza creare credenziali separate per ciascun servizio. Negli ecosistemi agentici possono consentire a un agente AI di autenticarsi o operare presso diversi marketplace, merchant o servizi digitali sulla base di una relazione di fiducia preesistente tra identity provider e sistemi verificatori, mantenendo controllo centralizzato, gestione dei permessi e possibilità di revoca.

[105] Sistemi enterprise IAM: piattaforme aziendali di Identity and Access Management usate per gestire identità, ruoli, permessi, autenticazione, autorizzazione e revoca degli accessi a sistemi, dati e applicazioni. Negli ecosistemi agentici sono rilevanti perché consentono di assegnare a un agente AI privilegi limitati e controllabili, collegarlo a un soggetto responsabile, applicare policy di accesso, registrare le operazioni compiute e revocare rapidamente credenziali o autorizzazioni in caso di rischio, errore o compromissione.

[106]DLT: Distributed Ledger Technology, tecnologia a registro distribuito.

[107] Timestamping: tecnica che associa a un dato, documento, transazione, log o evento digitale una marca temporale verificabile, utile a dimostrare che quell’elemento esisteva o è stato registrato in un determinato momento. Negli ecosistemi agentici è rilevante perché consente di ricostruire quando un agente AI ha ricevuto una delega, invocato un altro agente, eseguito un pagamento, prodotto un artifact o modificato uno stato del workflow, rafforzando auditabilità, prova dell’esecuzione e attribuzione delle responsabilità.

[108] Audit trail: registrazione cronologica e verificabile degli eventi, decisioni, accessi, deleghe, sub-deleghe, scambi di dati, pagamenti e output prodotti lungo un workflow. Negli ecosistemi agentici è essenziale perché consente di ricostruire ex post quali agenti AI sono intervenuti, con quali autorizzazioni, quali policy hanno applicato, quali azioni hanno compiuto e quali risultati hanno generato, rendendo possibile controllo, compliance, gestione delle dispute e attribuzione delle responsabilità.

[109] Hash: impronta digitale generata applicando una funzione crittografica a un dato, documento, transazione o log, in modo da ottenere una stringa sintetica che cambia se il contenuto originario viene anche solo minimamente modificato. Negli ecosistemi agentici è rilevante perché consente di provare l’integrità di deleghe, policy, artifact, pagamenti o audit trail senza dover necessariamente esporre il contenuto completo, rafforzando verificabilità, timestamping e controllo ex post delle azioni compiute dagli agenti AI.

[110]SSI, acronimo di Self-Sovereign Identity, è un modello di identità digitale in cui il soggetto titolare controlla direttamente le proprie credenziali e decide quando, come e con chi condividerle, senza dipendere in modo esclusivo da un identity provider centralizzato. Negli ecosistemi agentici è rilevante perché può consentire a un umano, un’impresa o un wallet di conferire e presentare credenziali verificabili relative a un agente AI, alla sua delega, alle sue autorizzazioni e ai suoi limiti operativi, favorendo interazioni più selettive, verificabili e revocabili tra agenti, marketplace e sistemi di pagamento.

[111] Disclosure selettiva: principio del modello SSI che consente al titolare di una credenziale di condividere solo le informazioni strettamente necessarie per una determinata verifica, senza rivelare l’intero contenuto della credenziale o dati eccedenti. Negli ecosistemi agentici è rilevante perché un agente AI, o il wallet che lo abilita, può dimostrare di possedere una certa autorizzazione, qualifica o policy operativa — ad esempio un limite di spesa o una certificazione — senza esporre informazioni non necessarie sul delegante, sul provider o sul workflow complessivo.

[112]EUDI Wallet, acronimo di European Digital Identity Wallet, è il portafoglio europeo di identità digitale previsto dal quadro eIDAS2, destinato a consentire a cittadini, residenti e imprese di identificarsi online e offline, conservare e presentare attributi o attestazioni elettroniche e condividere dati in modo selettivo. Negli ecosistemi agentici può assumere rilievo come infrastruttura di fiducia per collegare identità giuridicamente riconosciute, deleghe, rappresentanza, credenziali verificabili e policy eseguibili che autorizzano un agente AI ad agire entro limiti definiti.

[113]Regolamento eIDAS: Regolamento (UE) n. 910/2014 sull’identificazione elettronica e i servizi fiduciari per le transazioni elettroniche nel mercato interno, successivamente modificato dal Regolamento (UE) 2024/1183 che istituisce il quadro europeo per l’identità digitale. Disciplina strumenti come identificazione elettronica, firme elettroniche, sigilli elettronici, marche temporali, recapito elettronico certificato e certificati per l’autenticazione dei siti web. Negli ecosistemi agentici è rilevante perché fornisce la base europea per identità digitale, servizi fiduciari, attestazioni e, con eIDAS 2.0, per l’EUDI Wallet, che può supportare deleghe, attributi verificabili e interazioni affidabili tra persone, imprese, agenti AI e servizi digitali.

[114] eIDAS2: espressione comunemente usata per indicare la riforma del Regolamento eIDAS introdotta dal Regolamento (UE) 2024/1183, che istituisce il quadro europeo per l’identità digitale e prevede l’EUDI Wallet. Rispetto al primo eIDAS, rafforza l’interoperabilità dell’identità digitale europea e introduce strumenti per conservare, presentare e verificare attributi e attestazioni elettroniche. Negli ecosistemi agentici è rilevante perché può offrire una base regolamentare per collegare agenti AI, deleghe, rappresentanza, credenziali verificabili e policy eseguibili a identità e attributi giuridicamente riconosciuti.

[115]GDPR è l’acronimo di General Data Protection Regulation, cioè il Regolamento (UE) 2016/679 sulla protezione dei dati personali. Disciplina il trattamento dei dati delle persone fisiche nell’Unione europea, imponendo principi come liceità, trasparenza, minimizzazione, limitazione delle finalità, sicurezza, accountability e tutela dei diritti degli interessati. Negli ecosistemi agentici è rilevante perché gli agenti AI possono accedere, elaborare o trasmettere dati personali lungo catene multi-agente, rendendo necessario definire basi giuridiche, ruoli privacy, limiti di trattamento, auditabilità, sicurezza e controllo sulle sub-deleghe.

[116]AI Act: Regolamento (UE) 2024/1689 sull’intelligenza artificiale, che introduce nell’Unione europea un quadro armonizzato e basato sul rischio per sviluppo, immissione sul mercato e uso dei sistemi di AI. Prevede divieti per alcune pratiche considerate inaccettabili, obblighi specifici per i sistemi ad alto rischio, regole di trasparenza per determinate applicazioni e obblighi per i modelli di AI per finalità generali. Negli ecosistemi agentici è rilevante perché gli agenti AI possono agire con autonomia, usare strumenti esterni, incidere su diritti, pagamenti, dati e decisioni, rendendo centrali requisiti come gestione del rischio, logging, supervisione umana, robustezza, cybersecurity e accountability.

[117] Diritto contrattuale: insieme delle regole che disciplinano formazione, validità, interpretazione, esecuzione e responsabilità derivanti dai contratti. Negli ecosistemi agentici è rilevante perché un agente AI può negoziare condizioni, accettare offerte, predisporre ordini o attivare pagamenti per conto di un soggetto; occorre quindi stabilire quando l’azione dell’agente produca effetti vincolanti, se rientri nella delega ricevuta, come si imputi la volontà contrattuale e chi risponda in caso di errore, abuso, difetto di autorizzazione o inadempimento.