UCP contro ACP: i protocolli di agentic commerce per l'e-commerce italiano nel 2026

UCP contro ACP: i protocolli di agentic commerce per l'e-commerce italiano nel 2026

Sta succedendo una cosa che cambia le regole dell'e-commerce: gli assistant AI iniziano a comprare per conto degli utenti. Non "consigliano un prodotto", completano l'acquisto, dentro la conversazione, senza che l'utente apra il tuo sito. E se il tuo e-commerce non parla la lingua che quegli agenti capiscono, semplicemente non sei tra le opzioni che l'assistente considera. Nel 2026 questa lingua non è una sola: ci sono due protocolli principali in campo, lo Universal Commerce Protocol promosso da Google con Shopify, e l'Agentic Commerce Protocol promosso da OpenAI con Stripe, e per un titolare di e-commerce italiano la domanda urgente è capire cosa propongono, chi li sostiene, e soprattutto cosa serve fare adesso per restare "acquistabili" da un agente senza buttarsi a rincorrere ogni standard emergente. Vediamo i due protocolli a confronto, perché non sono i rivali che sembrano, e cosa preparare concretamente.

Cosa propone UCP, lo Universal Commerce Protocol

UCP è uno standard aperto per il commercio agentico annunciato da Google al National Retail Federation del 2026, con un intervento di Sundar Pichai, e co-sviluppato con Shopify e Walmart, con il sostegno di oltre venti partner tra cui nomi del calibro di Stripe, Visa, Mastercard, Adyen e American Express. La sua ambizione è coprire l'intero percorso d'acquisto, dalla scoperta del prodotto fino al post-vendita, non solo il momento del pagamento. Architetturalmente è a livelli: un servizio di shopping con le primitive della transazione (sessione di checkout, articoli, totali, stato), una serie di capability versionate indipendentemente (Checkout, Orders, Catalog), e delle estensioni per i casi specifici. La scoperta avviene tramite un file .well-known/ucp che il merchant pubblica, e il protocollo è progettato per integrarsi con altri standard agentici come MCP e A2A. A maggio 2026, al Google Marketing Live, è stata presentata anche una funzione di carrello unico cross-retailer. Il punto di forza dichiarato è la rapidità di integrazione per i merchant già su piattaforme partner, dell'ordine di poche ore. La documentazione di riferimento è quella ufficiale di Google per UCP.

Cosa propone ACP, l'Agentic Commerce Protocol

ACP è lo standard sviluppato da OpenAI insieme a Stripe come founding maintainer, e ha un fuoco diverso: l'acquisto dentro l'assistente AI, la cosiddetta interazione chat-to-buy. La sua prima implementazione concreta è l'Instant Checkout di ChatGPT, dove l'utente completa l'acquisto senza lasciare la conversazione. Sul piano dei pagamenti, ACP usa delegated payment token a uso singolo, limitati nell'importo e nel tempo, un design che dà controllo all'utente e fiducia al merchant. La specifica segue un versionamento basato sulla data, e le release recenti hanno aggiunto carrello, feed, ordini, autenticazione e l'integrazione con MCP. Il repository e la specifica sono pubblici, sul progetto GitHub di ACP. Rispetto a UCP, ACP non prova a coprire tutto il viaggio del cliente: si concentra sul momento conversazionale in cui l'agente, dentro la chat, conclude l'acquisto.

Se gestisci un e-commerce e vuoi capire come integrarti in questo nuovo scenario senza farti dettare le scelte dall'hype del momento, nel mio hub dedicato all'AI per l'integrazione raccolgo gli articoli con la metodologia che applico sul campo.

La differenza concettuale: tutto il viaggio contro la chat-to-buy

La tentazione è leggere UCP e ACP come due litiganti per lo stesso trono, ma è una lettura sbagliata che porta a decisioni sbagliate. La differenza è di prospettiva e di perimetro. UCP guarda dal punto di vista del merchant e dell'intero percorso: come rendere acquistabile un catalogo lungo tutto il viaggio del cliente, dalla scoperta al post-vendita. ACP guarda dal punto di vista dell'agente e di un momento preciso: come concludere un acquisto dentro la conversazione con l'assistente. Sono due risposte a due domande diverse, non due risposte alla stessa domanda.

Chiedersi "UCP o ACP?" è come chiedersi "vetrina o cassa?": non scegli l'una contro l'altra, perché servono a momenti diversi della stessa vendita. La domanda giusta non è quale protocollo vince, è in quali canali i tuoi clienti compreranno tramite un agente, e prepararsi per quelli.

Questa distinzione ha una conseguenza pratica enorme: non devi necessariamente "scegliere il vincitore", perché coprono momenti diversi del processo d'acquisto. Un e-commerce può aver bisogno di essere presente sia nel viaggio orchestrato da Google sia nella chat di ChatGPT, e questi sono canali distinti serviti da protocolli distinti. Ho già esplorato questo confronto allargandolo anche al protocollo di pagamento AP2 parlando di AP2, ACP e UCP per l'e-commerce italiano B2B e B2C: la mappa è più ricca di un semplice duello.

I protocolli non convergono, e questo è un progetto, non un fallimento

C'è un istinto, in chi guarda da fuori, a vedere la pluralità di standard come immaturità: "ma perché non si mettono d'accordo su uno solo?". È l'istinto sbagliato. La coesistenza di più protocolli è intenzionale, ed è la stessa logica per cui sul web non c'è un solo protocollo ma una pila di protocolli, ciascuno per uno strato diverso. Nel commercio agentico, MCP fa da standard trasversale per collegare gli agenti ai sistemi, mentre UCP e ACP coprono superfici di vendita diverse. Lo dimostrano i comportamenti dei grandi attori, che non scelgono un campo: Walmart è integrato sia con ChatGPT tramite ACP sia con Google tramite UCP; Shopify co-sviluppa UCP e insieme supporta i suoi merchant su ChatGPT; Stripe sostiene UCP pur avendo co-creato ACP, perché i protocolli di pagamento e quelli di commercio hanno funzioni diverse. La lezione, per un e-commerce, è che il futuro è multi-protocollo, e che il vero asset difendibile è un'architettura capace di parlarne più di uno, non la scommessa su quello "giusto". È lo stesso ragionamento che faccio sul ruolo di MCP come standard di fondo, descritto parlando di MCP, Linux Foundation e i bandi enterprise in Italia.

Cosa cambia concretamente per un e-commerce italiano

Tradotto per chi vende online in Italia, il messaggio è duplice. Da un lato, il rischio di restare invisibili agli agenti è reale e va preso sul serio: se i tuoi clienti iniziano a chiedere a un assistente "comprami questo" e il tuo negozio non è acquistabile in quel canale, perdi vendite che nemmeno vedi passare. Dall'altro, la risposta non è correre a implementare tutto subito, perché gli standard sono ancora in evoluzione e le release si susseguono. La via di mezzo sensata dipende molto da come è costruito il tuo e-commerce. Se sei su una piattaforma che partecipa a questi standard, come Shopify, una parte significativa dell'integrazione arriva dalla piattaforma stessa, e il tuo compito è soprattutto abilitarla e curare i dati. Se hai un e-commerce custom, l'integrazione è un progetto vero, che richiede di esporre catalogo e checkout in modi che gli agenti possano consumare, ed è il tipo di lavoro di integrazione che progetto attorno a server e API dedicati, come ho descritto parlando di MCP server personalizzati per il workflow aziendale.

Il nodo dei pagamenti e della fiducia, che in Italia pesa di più

C'è un aspetto in cui un e-commerce italiano deve stare particolarmente attento, ed è il pagamento. Quando un agente compra per conto dell'utente, il pagamento non lo autorizza più una persona che clicca, lo esegue un software, e questo apre una domanda di fiducia e di conformità. I protocolli rispondono con meccanismi pensati per non dare carta bianca all'agente: ACP usa delegated payment token a uso singolo, limitati nell'importo e nel tempo, in modo che l'agente possa concludere quel preciso acquisto e nient'altro; sul versante UCP esiste un protocollo di pagamento dedicato, AP2, che si occupa proprio dei pagamenti agentici sicuri. Il principio comune è ridurre il rischio dando all'agente un permesso minimo e circoscritto, non l'accesso al portafoglio dell'utente.

Per l'Italia, e per l'Europa, c'è una dimensione in più: la normativa sui pagamenti. La direttiva PSD2 e i suoi requisiti di Strong Customer Authentication sono nati pensando a un essere umano che autentica una transazione, e l'acquisto eseguito da un agente solleva domande non banali su come si concili l'autenticazione forte con un'operazione delegata a un software. Non è un dettaglio tecnico secondario: è il genere di nodo regolatorio che, in Europa, può determinare quali implementazioni sono ammissibili e quali no, e che un e-commerce serio deve presidiare con il proprio fornitore di pagamenti invece di darlo per risolto. La fiducia, in questo scenario, non è solo una questione di esperienza utente, è una questione di conformità: un acquisto agentico che non rispetta i requisiti di autenticazione europei è un problema legale, non solo tecnico. È un'area in cui consiglio sempre di muoversi con il partner di pagamento e con un occhio alla normativa, non con l'entusiasmo del "facciamolo subito".

Devo implementare questi protocolli adesso?

La risposta onesta è: dipende, e la fretta è cattiva consigliera. Implementare oggi, alla cieca, tutti i protocolli emergenti è un modo eccellente per spendere su standard che cambieranno ancora. Ma ignorare del tutto il fenomeno, sperando che passi, è altrettanto rischioso, perché il commercio agentico non è una moda passeggera, è uno spostamento strutturale di dove avvengono gli acquisti. La posizione giusta è di preparazione, non di rincorsa: investire in ciò che serve a qualunque protocollo, e adottare i protocolli specifici quando il tuo canale e i tuoi clienti lo richiedono davvero. La differenza tra preparazione e rincorsa è la differenza tra un investimento che dura e una spesa che invecchia in fretta.

Cosa preparare adesso senza inseguire ogni standard

Qui sta il consiglio concreto e duraturo, quello che vale a prescindere da quale protocollo prevarrà. La base su cui qualunque protocollo di commercio agentico si appoggia è sempre la stessa: un catalogo strutturato, pulito e leggibile dalla macchina, e una API di checkout solida e ben progettata. Un agente, qualunque protocollo parli, ha bisogno di capire cosa vendi (prodotti, varianti, prezzi, disponibilità in forma strutturata e affidabile) e di poter completare un acquisto in modo sicuro. Se queste due fondamenta sono in ordine, adottare UCP, ACP o qualunque cosa venga dopo è un lavoro di adattamento gestibile; se non lo sono, nessun protocollo ti salva. Investire oggi nella qualità dei dati di prodotto e nella robustezza dell'infrastruttura di checkout è quindi la scelta a prova di futuro, perché è il terreno su cui ogni standard, presente e futuro, dovrà comunque poggiare. Scommettere invece tutto su un singolo protocollo emergente è il modo per ritrovarsi, tra un anno, ad aver costruito sulla sabbia.

La buona notizia è che questo investimento non è perso anche se i protocolli cambiassero del tutto, perché coincide in gran parte con un lavoro che andava fatto comunque. Un catalogo con dati di prodotto strutturati, accurati e aggiornati è esattamente ciò che serve anche per la SEO, per le schede prodotto ricche, per i feed verso i marketplace e per la visibilità nei risultati generati dall'AI. La leggibilità da parte di un agente è la stessa qualità del dato che un motore di ricerca premia: stai costruendo una volta sola un asset che paga su più fronti. È la continuità tra l'essere trovabili e l'essere acquistabili: per anni l'obiettivo è stato apparire nei risultati di ricerca, ora si aggiunge l'essere conclusi dentro una conversazione con un agente, ma la base, dati puliti e infrastruttura solida, è la stessa. Investire lì non è scommettere su una tecnologia, è migliorare la qualità di fondo del proprio e-commerce, e quella non invecchia con il protocollo di turno.

Tirando le somme, UCP e ACP non sono due rivali tra cui scegliere, sono due risposte a due domande diverse del commercio agentico: UCP all'intero viaggio del cliente orchestrato dal merchant, ACP all'acquisto dentro la conversazione con l'assistente. Convivranno, insieme a MCP come standard trasversale e ad AP2 sul lato pagamenti, perché la pluralità di protocolli è il progetto, non un difetto. Per un e-commerce italiano, la mossa intelligente non è scegliere il cavallo vincente né implementare tutto in fretta, è prepararsi: un catalogo strutturato e una API di checkout solida sono le fondamenta su cui qualunque protocollo si appoggia, e investire lì è l'unica scommessa che non si può perdere. Restare acquistabili dagli agenti diventerà, nei prossimi anni, importante quanto lo è stato finora essere trovabili dai motori di ricerca, e chi si prepara per tempo arriverà a quel momento con un vantaggio difficile da colmare. Se gestisci un e-commerce e vuoi capire da dove cominciare per restare rilevante in questo scenario senza sprecare budget su standard ancora in movimento, puoi usare il modulo di preventivo gratuito: sette domande, due minuti, e ti dico se il tuo caso rientra nel mio perimetro o se ti conviene un'altra figura.

Ultima modifica: