Il modo in cui le aziende cercano, confrontano e acquistano prodotti tecnici sta entrando in una nuova fase.
Fino a poco tempo fa, il responsabile acquisti di un’azienda industriale, il manutentore di un impianto o il buyer di una distribuzione tecnica cercavano componenti, ricambi, DPI o attrezzature professionali attraverso Google, cataloghi PDF, siti dei fornitori, portali riservati ed e-commerce B2B.
La ricerca era ancora guidata dall’utente umano: inserire una keyword, aprire più schede prodotto, confrontare varianti, verificare codici, scaricare schede tecniche, controllare disponibilità, eventualmente accedere con login e richiedere un preventivo.
Con l’arrivo degli assistenti AI e degli agenti digitali, questo scenario comincia a cambiare.
Un utente può formulare una richiesta molto più naturale e operativa:
“Trova una valvola a sfera flangiata DN50 in acciaio inox 316, con guarnizioni in PTFE, pressione nominale PN40, disponibile per consegna nel Nord Italia.”
Oppure:
“Mi serve un guanto da lavoro DPI di seconda categoria, resistente all’abrasione, adatto a movimentazione in ambiente leggermente oleoso, disponibile in più taglie e acquistabile da un fornitore B2B italiano.”
In questi casi l’utente non sta più digitando una semplice keyword. Sta descrivendo un bisogno tecnico, commerciale e operativo. E si aspetta che l’assistente AI sia in grado di interpretarlo, confrontare le alternative, interrogare dati aggiornati e orientarlo verso il prodotto più adatto.
È qui che entra in gioco l’Agentic Commerce.
Dalla ricerca online al commercio tra agenti
L’obiettivo dell’Agentic Commerce è rendere possibile un commercio sempre più machine-to-machine, in cui gli agenti AI non si limitano a suggerire link o risultati, ma partecipano attivamente al processo di acquisto.
L’idea di fondo è semplice da descrivere, ma molto profonda nelle implicazioni: una persona indica al proprio agente AI che cosa vuole acquistare; l’agente interpreta il bisogno, scopre i prodotti disponibili, confronta alternative, verifica dati aggiornati e, in prospettiva, può arrivare fino al checkout e al pagamento.
In questo scenario, l’utente non naviga più manualmente decine di pagine. Affida al proprio agente un obiettivo.
L’agente, a sua volta, deve poter dialogare con sistemi esterni: cataloghi, feed prodotto, API, e-commerce, strumenti di pagamento, portali riservati, sistemi di disponibilità e infrastrutture commerce.
Nel B2C questo scenario è più immediato: un prodotto standard, un prezzo pubblico, una disponibilità aggiornata, un carrello e un pagamento.
Nel B2B industriale il quadro è più complesso. Molti acquisti dipendono da listini personalizzati, scontistiche per cliente, configurazioni, compatibilità tecniche, disponibilità di magazzino, minimi d’ordine, approvazioni interne, condizioni di pagamento e preventivi.
Ma proprio per questo il tema è ancora più rilevante.
Perché prima ancora di arrivare al pagamento automatico, un agente AI deve poter fare una cosa fondamentale: capire il catalogo.
Il prerequisito: rendere accessibili i product data
Prima di chiedersi quale protocollo adottare, un’azienda B2B deve porsi una domanda più elementare:
I miei dati prodotto sono davvero pronti per essere letti, interpretati e utilizzati da un agente AI?
Questa è la questione centrale.
Un agente AI non può lavorare bene se il catalogo è incompleto, incoerente o poco strutturato. Non può distinguere correttamente due varianti se gli attributi tecnici sono scritti in modo ambiguo. Non può confrontare prodotti se le informazioni sono sparse tra scheda web, PDF, gestionale e tabelle non normalizzate. Non può proporre un prodotto corretto se codice articolo, codice produttore, compatibilità e disponibilità non sono esposti in modo affidabile.
Per un e-commerce B2B industriale, i product data non sono un semplice contenuto editoriale. Sono l’infrastruttura informativa che permette al catalogo di essere trovato, compreso e utilizzato.
I dati più importanti includono:
- codici articolo;
- codici produttore;
- varianti;
- attributi tecnici;
- materiali;
- dimensioni;
- certificazioni;
- compatibilità;
- categorie merceologiche;
- immagini;
- documentazione tecnica;
- disponibilità;
- prezzo pubblico;
- condizioni di vendita;
- relazioni tra prodotto padre e varianti;
- accessori, ricambi e prodotti compatibili;
- dati pubblici e dati riservati.
Prepararsi all’Agentic Commerce significa quindi trasformare il catalogo da archivio pensato solo per la navigazione umana a base dati interrogabile.
Questo non elimina la SEO. La amplia.
La SEO resta decisiva per Google e per la visibilità organica tradizionale. Ma accanto alla SEO crescono altre esigenze: GEO, AEO, dati strutturati, feed prodotto, API, tassonomie coerenti, contenuti tecnici leggibili dai modelli e protocolli di interazione tra agenti AI e sistemi aziendali.
Non esiste un solo protocollo: UCP, ACP e MCP
Oggi non esiste un unico protocollo universale che copra tutto l’Agentic Commerce.
Si stanno consolidando più approcci, con finalità e ambiti diversi. Per chi gestisce un e-commerce o un catalogo B2B, i tre riferimenti principali da conoscere sono:
- UCP, Universal Commerce Protocol;
- ACP, Agentic Commerce Protocol;
- MCP, Model Context Protocol.
È importante distinguerli, perché non sono equivalenti.
UCP è il protocollo commerce oggi legato soprattutto all’ecosistema Google: AI Mode in Google Search, Gemini e Merchant Center.
ACP è il protocollo commerce collegato all’ecosistema OpenAI e ChatGPT, sviluppato per connettere merchant, utenti e agenti AI nei flussi di acquisto.
MCP è diverso: non è un protocollo commerce, ma un protocollo trasversale per collegare applicazioni AI, agenti e modelli linguistici a dati, strumenti, API e sistemi esterni.
In altre parole:
- UCP riguarda il commerce agentico in ambito Google;
- ACP riguarda il commerce agentico in ambito OpenAI/ChatGPT;
- MCP riguarda la connessione tra AI e sistemi esterni, anche fuori dal commerce.
Questa distinzione è fondamentale. Evita di confondere il tema del checkout agentico con il tema, più ampio, dell’accesso controllato ai dati aziendali.
UCP: il protocollo commerce di Google per AI Mode e Gemini
UCP significa Universal Commerce Protocol.
Google lo presenta come uno standard aperto per abilitare azioni agentiche su AI Mode in Google Search e Gemini, a partire da esperienze di acquisto diretto. L’obiettivo dichiarato è trasformare le interazioni AI in vendite immediate, permettendo agli agenti di interagire con i sistemi commerce dei merchant.
La logica di UCP è ampia: un agente deve poter scoprire prodotti, recuperare informazioni, costruire carrelli, gestire checkout e contribuire al completamento dell’acquisto.
A livello di implementazione, il cuore di questa architettura si esprime nel file manifest /.well-known/ucp da pubblicare nella root del server: un vero e proprio passaporto digitale in formato JSON attraverso il quale l’azienda dichiara esplicitamente ai crawler e agli agenti AI quali specifiche Capability commerciali supporta tra tutte quelle previste dallo standard globale, permettendo così a un e-commerce B2B di esporre esclusivamente le funzionalità di consultazione e scoperta del catalogo (Catalog Capabilities come search e lookup) e di escludere o blindare i flussi nativi di checkout e pagamento automatico.
Per questo UCP non riguarda solo la visibilità del catalogo, ma l’intero percorso commerce.
Google collega l’adozione di UCP al Merchant Center: per iniziare, il merchant deve preparare l’account, configurare informazioni commerciali e product feed, e l’integrazione UCP deve essere approvata da Google prima della pubblicazione su AI Mode in Google Search e Gemini.
Per un e-commerce B2C questo scenario è relativamente lineare: prodotti standard, prezzi pubblici, disponibilità, carrello, checkout.
Per un catalogo B2B industriale è diverso.
Molti distributori tecnici non possono rendere immediatamente acquistabili tutti i prodotti dentro un’esperienza AI. I motivi sono evidenti: listini riservati, scontistiche per cliente, preventivi, configurazioni su misura, prodotti soggetti a verifica tecnica, quantità minime, condizioni di pagamento concordate, login obbligatorio.
Questo non rende UCP irrilevante.
Al contrario, lo rende interessante soprattutto come indicazione della direzione in cui si sta muovendo Google: i cataloghi dovranno diventare sempre più strutturati, accessibili e interrogabili.
Nel B2B, il primo valore di un’integrazione di questo tipo può essere la capacità di far comprendere all’agente quali prodotti esistono, quali caratteristiche hanno, quali varianti sono disponibili e quale percorso commerciale deve seguire l’utente.
ACP: il protocollo commerce di OpenAI per ChatGPT
ACP significa Agentic Commerce Protocol.
È il protocollo commerce collegato a OpenAI e ChatGPT. OpenAI lo descrive come l’infrastruttura tra merchant e utenti ChatGPT: uno standard aperto che consente a ChatGPT di acquisire dati di catalogo strutturati, comprendere l’inventario del merchant e mostrare prodotti pertinenti nel contesto della conversazione.
Il riferimento ufficiale per approfondire è la documentazione OpenAI sull’Agentic Commerce: https://developers.openai.com/commerce.
ACP è stato sviluppato da OpenAI e Stripe come standard aperto per abilitare flussi di commercio programmatico tra buyer, agenti AI e aziende. Il sito dedicato al protocollo lo presenta come uno standard per consentire transazioni tra agenti AI e business, mantenendo l’infrastruttura commerce esistente del merchant.
Per ChatGPT, il primo livello documentato è il product feed.
OpenAI indica il product feed strutturato come punto di partenza dell’integrazione ACP: il feed fornisce a ChatGPT i dati necessari per indicizzare i prodotti, comprenderne gli attributi principali e presentare informazioni accurate nelle esperienze shopping.
Questo punto è molto importante.
La presenza dei prodotti in ChatGPT non va pensata solo come scansione libera del sito web. OpenAI documenta un modello in cui il merchant condivide dati strutturati: titoli, descrizioni, immagini, prezzo, disponibilità, varianti, URL e informazioni sul seller.
La specifica del product feed spiega che, per rendere i prodotti scopribili dentro ChatGPT, i merchant forniscono un file strutturato che OpenAI acquisisce e indicizza. Il feed serve a supportare discovery, pricing, availability e seller context.
OpenAI documenta due modalità principali:
- File upload tramite SFTP, con un feed strutturato che rappresenta il catalogo.
- API, per creare feed e aggiornare prodotti associati.
La guida OpenAI suggerisce anche un approccio ibrido: snapshot completo del catalogo tramite file upload e aggiornamenti durante la giornata tramite API.
Non si tratta, almeno allo stato attuale della documentazione, di un semplice pannello pubblico e self-service paragonabile a Google Merchant Center. OpenAI parla di onboarding per partner approvati.
Per un catalogo B2B industriale, il punto decisivo è che il feed non può essere un’esportazione minimale. Deve rappresentare la logica del catalogo.
Deve distinguere prodotti e varianti. Deve gestire codici, attributi, URL, immagini, disponibilità, prezzi e relazioni tra elementi. Deve permettere a ChatGPT di capire non solo che un prodotto esiste, ma anche perché è diverso da un altro.
La specifica OpenAI distingue infatti tra Product e Variant. Il prodotto può rappresentare la famiglia commerciale o il modello; la variante può rappresentare la specifica configurazione acquistabile, con codice, prezzo, disponibilità, barcode o altri identificativi.
Questa distinzione è molto rilevante nel B2B: un raccordo pneumatico può avere varianti per diametro tubo, filettatura e materiale; un DPI può avere varianti per taglia, colore e codice SKU; un utensile può avere varianti per geometria, dimensione, rivestimento o compatibilità.
ACP comprende anche il tema del checkout. OpenAI documenta una specifica di Agentic Checkout pensata per consentire flussi di acquisto end-to-end dentro ChatGPT, mantenendo ordini, pagamenti e compliance sull’infrastruttura commerce esistente del merchant.
Ma, anche in questo caso, per un’azienda B2B il primo problema resta la qualità del dato.
Senza product data completi, aggiornati e coerenti, l’agente non può né scoprire correttamente il prodotto né presentarlo in modo affidabile.
MCP: il protocollo trasversale per collegare AI, dati e strumenti
MCP significa Model Context Protocol.
È nato in Anthropic come standard aperto per collegare sistemi AI a fonti dati esterne. Anthropic lo ha presentato come un modo per superare integrazioni frammentate e creare una connessione più uniforme tra assistenti AI e sistemi dove vivono i dati.
La documentazione MCP lo definisce uno standard open-source per collegare applicazioni AI a sistemi esterni: file, database, strumenti, motori di ricerca, workflow, API e altre fonti di contesto.
Qui la differenza rispetto a UCP e ACP è decisiva.
MCP non è un protocollo commerce.
Non nasce per gestire carrelli, checkout o pagamenti. Nasce per consentire a un’applicazione AI di collegarsi in modo standardizzato a strumenti e dati esterni.
Per questo è più trasversale.
Anthropic lo supporta in Claude e Claude Code; la documentazione Anthropic spiega che Claude Code può connettersi a strumenti, database e API attraverso server MCP.
OpenAI supporta MCP nei propri strumenti per API e integrazioni, compresi remote MCP server e connector. La documentazione OpenAI descrive MCP come un modo per dare ai modelli accesso a nuove capacità tramite server remoti.
Anche Google supporta MCP in diversi contesti developer e Google Cloud. Google ha annunciato server MCP gestiti per servizi Google e Google Cloud, utilizzabili da agenti AI e client MCP come Gemini CLI.
Per un progetto B2B, MCP può essere molto interessante perché permette di collegare un agente AI a sistemi aziendali come PIM, ERP, database documentali, knowledge base tecniche o API interne.
Per esempio, un agente potrebbe interrogare:
- un PIM per recuperare attributi prodotto;
- un ERP per verificare disponibilità;
- una knowledge base per leggere manuali e schede tecniche;
- un configuratore per validare compatibilità;
- un sistema documentale per recuperare certificati o dichiarazioni di conformità.
Tuttavia, MCP non sostituisce UCP o ACP.
È un’infrastruttura di connessione tra AI e sistemi esterni. Può essere usata dentro progetti commerce, ma non è di per sé un protocollo di commercio agentico.
Allo stato della documentazione pubblica, Anthropic non risulta promuovere ufficialmente né UCP né ACP come protocollo commerce di Claude. Per Claude, il riferimento tecnico principale resta MCP.
7. UCP, ACP e MCP a confronto
| Protocollo | Ecosistema principale | Funzione principale | È commerce-specific? | Rilevanza per cataloghi B2B |
| UCP | Google, AI Mode, Gemini, Merchant Center | Abilitare interazioni commerce agentiche, fino ad acquisto e checkout | Sì | Product discovery, integrazione con Merchant Center, dati prodotto e potenziali flussi di acquisto su superfici Google |
| ACP | OpenAI, ChatGPT, Stripe | Collegare merchant e utenti ChatGPT tramite feed, dati catalogo e flussi commerce | Sì | Product feed strutturato, prodotti e varianti, prezzo, disponibilità, discovery e potenziale checkout in ChatGPT |
| MCP | Nato in Anthropic, supportato anche da OpenAI e Google in vari contesti | Collegare AI a dati, strumenti, API e workflow | No | Accesso controllato a PIM, ERP, cataloghi, documentazione tecnica e sistemi aziendali |
Questa tabella chiarisce il punto essenziale: UCP e ACP parlano direttamente di commercio agentico; MCP parla di connessione tra AI e sistemi esterni.
Per un e-commerce B2B industriale possono essere rilevanti tutti e tre, ma con funzioni diverse.
Che cosa cambia per un catalogo B2B industriale
L’Agentic Commerce non parte dal checkout.
Parte dalla capacità del catalogo di essere compreso da una macchina.
Questo è il passaggio decisivo per il B2B industriale.
Un catalogo tecnico non è composto solo da titoli prodotto e prezzi. È fatto di codici, varianti, attributi, compatibilità, norme, materiali, misure, schede PDF, immagini tecniche, certificazioni, condizioni commerciali, disponibilità e relazioni tra prodotti.
Per un utente umano, queste informazioni possono essere distribuite tra più livelli: pagina web, allegati, PDF, tabelle, filtri, motore di ricerca interno, area riservata, gestionale.
Per un agente AI, questa frammentazione è un problema.
Se il dato tecnico è nascosto in un PDF non strutturato, se le varianti non sono collegate al prodotto padre, se i filtri non corrispondono agli attributi reali, se il codice articolo è ambiguo, se disponibilità e prezzo non sono aggiornati, l’agente faticherà a interpretare correttamente l’offerta.
Prepararsi all’Agentic Commerce significa quindi lavorare su alcuni elementi fondamentali:
- dati prodotto completi;
- schede tecniche strutturate;
- attributi normalizzati;
- categorie coerenti;
- prodotti e varianti ben collegati;
- URL canonici;
- disponibilità aggiornate;
- prezzi chiari;
- immagini e media;
- documentazione accessibile;
- relazioni tra prodotto, accessori, ricambi e compatibilità.
Il punto non è aggiungere contenuto generico.
Il punto è rendere il dato tecnico più esplicito, ordinato, interrogabile e affidabile.
Feed, API, dati strutturati e pagine prodotto: i quattro livelli operativi
Per preparare un catalogo B2B all’Agentic Commerce, è utile ragionare su quattro livelli operativi.
Feed prodotto
Il feed è il primo livello di esposizione strutturata del catalogo.
Google Merchant Center, OpenAI ACP e altre piattaforme AI richiedono o documentano modalità di condivisione dei dati prodotto tramite feed o formati strutturati.
Nel B2B industriale, il feed non dovrebbe limitarsi a titolo, prezzo e immagine.
Dovrebbe includere identificativi univoci, descrizioni tecniche, categorie, varianti, codici produttore, URL canonici, disponibilità, prezzo, immagini, attributi rilevanti e informazioni sul seller.
Per ChatGPT, OpenAI specifica che il product feed serve a rendere i prodotti scopribili dentro ChatGPT e a fornire dati necessari per discovery, pricing, availability e seller context.
API di catalogo
Il secondo livello è l’accesso dinamico al catalogo.
Un feed aggiornato una volta al giorno può essere sufficiente per alcuni dati. Ma in un catalogo B2B molti elementi cambiano rapidamente: disponibilità, prezzi, varianti, prodotti sostituiti, accessori compatibili, documentazione tecnica.
Per questo diventano importanti API e connettori.
Le API possono permettere a un sistema esterno di effettuare ricerche, recuperare dettagli prodotto, verificare disponibilità, leggere attributi tecnici o validare una configurazione.
UCP lavora proprio nella direzione di capability commerce esposte in modo standardizzato; MCP, invece, può essere usato per collegare un agente AI a sistemi aziendali e strumenti interni.
Dati strutturati
Il terzo livello è il markup delle pagine prodotto.
I dati strutturati Schema.org aiutano motori di ricerca, crawler e sistemi automatici a interpretare meglio il contenuto della pagina.
In un catalogo B2B industriale, i dati strutturati dovrebbero essere coerenti con ciò che l’utente vede nella pagina e con ciò che viene inviato nei feed.
Non devono creare un livello parallelo e contraddittorio.
Se il feed indica un prezzo, la pagina deve mostrare un prezzo coerente. Se la scheda prodotto espone una disponibilità, questa deve corrispondere al dato strutturato. Se il prodotto ha varianti, il markup deve essere progettato in modo da non confondere prodotto padre e SKU acquistabili.
Pagine prodotto e contenuti tecnici
Il quarto livello resta la pagina prodotto.
Anche nell’era degli agenti AI, la scheda prodotto non perde importanza. Al contrario, diventa una fonte di verità pubblica.
Una buona scheda prodotto B2B dovrebbe spiegare con chiarezza:
- che cos’è il prodotto;
- a cosa serve;
- quali caratteristiche tecniche lo distinguono;
- quali varianti esistono;
- quali compatibilità sono rilevanti;
- quali documenti sono disponibili;
- quali condizioni commerciali sono pubbliche;
- quando è necessario login, richiesta di disponibilità o preventivo.
La pagina prodotto deve parlare sia all’utente umano sia ai sistemi automatici.
Il nodo B2B: Merchant Center, IVA, listini riservati, login e preventivi
Il B2B ha logiche commerciali diverse dal B2C.
Molti e-commerce industriali lavorano con prezzi IVA esclusa, listini personalizzati, sconti per cliente, condizioni riservate, acquisti dopo login, prodotti configurabili, richieste di preventivo e disponibilità non sempre pubbliche.
Questi elementi non sono anomalie. Sono parte normale del commercio B2B.
Il tema del prezzo IVA inclusa / IVA esclusa è particolarmente importante quando entra in gioco Google Merchant Center.
Google, nelle indicazioni per il B2B advertising, chiede di mostrare sulla landing page il prezzo lordo comprensivo di IVA, quando richiesto dal paese target, in modo più evidente di ogni altro prezzo; inoltre il prezzo visibile deve corrispondere a quello inviato nel feed.
Questo crea una questione concreta per molte aziende B2B europee, abituate a comunicare prezzi netti IVA esclusa.
La soluzione non è inviare dati incoerenti o nascondere i prezzi.
La soluzione è progettare una rappresentazione chiara del prezzo, distinguendo correttamente i canali.
Per Google Merchant Center, il prezzo inviato nel feed e quello visibile nella landing page devono essere coerenti. Se il contesto richiede il prezzo IVA inclusa, questo deve essere presente e ben visibile.
Per il buyer B2B, la pagina può comunque mostrare anche il prezzo netto, purché la comunicazione sia chiara.
Per esempio:
€ 100,00 IVA esclusa
€ 122,00 IVA inclusa
In questo modo il buyer aziendale trova il riferimento commerciale che si aspetta, mentre Google può verificare la coerenza tra feed e landing page.
Il tema non va però generalizzato in modo improprio.
La questione IVA inclusa / IVA esclusa è soprattutto un nodo legato a Google Merchant Center, alle regole dei feed prodotto e alla coerenza con le landing page. Altri ecosistemi, come ACP per ChatGPT, hanno specifiche e logiche proprie per feed, prezzo, disponibilità e checkout.
Più in generale, il vero problema B2B non è fiscale. È commerciale.
Un catalogo industriale deve chiarire quali informazioni sono pubbliche e quali richiedono autenticazione:
- prezzo pubblico;
- prezzo riservato;
- disponibilità pubblica;
- disponibilità dopo login;
- prodotto acquistabile online;
- prodotto soggetto a preventivo;
- prodotto configurabile;
- prodotto che richiede verifica tecnica;
- condizioni di pagamento personalizzate.
L’obiettivo non è forzare il B2B dentro un modello B2C.
L’obiettivo è rendere comprensibili agli agenti AI i confini commerciali entro cui il catalogo può essere consultato, confrontato e utilizzato.
Il ruolo di llms.txt: utile, ma non sostitutivo
Accanto a feed, API, dati strutturati e protocolli, può essere utile considerare anche il file llms.txt.
llms.txt non è un protocollo commerce. Non sostituisce UCP, ACP o MCP. Non gestisce feed, checkout, carrelli o pagamenti.
È una proposta per pubblicare alla root del sito un file Markdown con informazioni sintetiche, leggibili e orientative per i modelli linguistici. La proposta ufficiale lo descrive come un modo per fornire contenuti LLM-friendly: background, indicazioni e link a risorse più dettagliate.
Per un distributore B2B, llms.txt può essere utile come mappa editoriale e semantica del sito.
Può spiegare:
- chi è l’azienda;
- quali mercati serve;
- quali categorie tratta;
- come è organizzato il catalogo;
- quali sezioni sono più importanti;
- quali contenuti tecnici sono disponibili;
- quali condizioni commerciali generali valgono;
- quali aree richiedono login o preventivo.
Un esempio semplificato:
# [Nome Azienda] – Informazioni per sistemi AI
Siamo un distributore B2B di componentistica oleodinamica, pneumatica e strumenti per la manutenzione industriale.
## Profilo commerciale
– Vendiamo esclusivamente ad aziende e professionisti.
– Alcuni listini sono riservati ai clienti registrati.
– Per prodotti configurabili o forniture complesse può essere richiesta una quotazione personalizzata.
– I prezzi pubblici sono indicati secondo quanto specificato nelle singole schede prodotto.
## Struttura del catalogo
Il catalogo è organizzato in categorie merceologiche a tre livelli.
Le macro-categorie principali includono:
1. Oleodinamica
– Valvole
– Pompe
– Cilindri
– Raccordi
2. Pneumatica industriale
– Attuatori
– Raccordi
– Tubazioni
– Gruppi trattamento aria
3. Strumentazione e misura
– Manometri
– Flussimetri
– Sensori
– Strumenti di controllo
## Integrazioni e dati
– Il sito espone dati prodotto strutturati nelle pagine prodotto.
– Alcune informazioni di prezzo e disponibilità possono richiedere login.
– Il catalogo può essere alimentato tramite feed prodotto e API dedicate.
– Documentazione OpenAI Agentic Commerce: https://developers.openai.com/commerce
Il valore di llms.txt non sta nel forzare le AI a usare il sito in un certo modo.
Sta nel ridurre l’ambiguità, offrendo una sintesi controllata e coerente della struttura aziendale e del catalogo.
12. Conclusione: il catalogo diventa una fonte interrogabile
Per anni le aziende B2B hanno pensato al sito come a una destinazione: il luogo in cui portare traffico, far navigare l’utente, mostrare prodotti e raccogliere richieste.
Con l’Agentic Commerce, il sito e il catalogo diventano anche una fonte: una base dati che assistenti AI, motori generativi e agenti digitali possono interrogare per costruire risposte, confrontare opzioni e guidare decisioni d’acquisto.
Il punto non è inseguire ogni nuovo standard.
Il punto è preparare il catalogo a un futuro in cui le macchine dialogheranno sempre più spesso con altre macchine.
UCP, ACP e MCP indicano tre direzioni complementari:
- UCP mostra come Google immagina il commerce agentico nelle superfici AI come AI Mode e Gemini;
- ACP mostra come OpenAI sta costruendo l’infrastruttura commerce per ChatGPT;
- MCP mostra come agenti e applicazioni AI possono collegarsi a dati, strumenti e sistemi esterni.
Per il B2B industriale, la competitività passerà sempre più dalla qualità dei dati prodotto: completezza, precisione, aggiornamento, accessibilità e coerenza tra sito, feed, API, ERP e PIM.
Il catalogo del futuro non sarà solo navigabile.
Sarà interrogabile.
Sarà leggibile dagli agenti AI.
Sarà collegabile a protocolli e piattaforme diverse.
E sarà tanto più competitivo quanto più saprà trasformare dati tecnici complessi in risposte affidabili per buyer, manutentori, progettisti e responsabili acquisti.