Essere trovati, compresi e interrogati dalle macchine diventa una nuova condizione di accesso al mercato
Nel libro Bot 2 Bot: The New Future of B2B Commerce, pubblicato nel maggio 2026, Andy Hoar descrive una trasformazione del commercio tra aziende che va molto oltre l’introduzione di chatbot più evoluti.
La tesi di fondo è che una parte crescente delle attività che oggi vengono svolte direttamente dalle persone potrà essere delegata ad agenti di intelligenza artificiale: applicazioni capaci non solo di fornire risposte, ma anche di cercare informazioni, interrogare sistemi, confrontare alternative e, quando autorizzate, eseguire determinate attività.
Nel commercio B2B questo cambiamento può essere particolarmente rilevante perché una parte importante del lavoro necessario per acquistare un prodotto riguarda attività ripetitive e basate sui dati: identificare un articolo, verificare caratteristiche, trovare un ricambio, confrontare alternative, recuperare documentazione, controllare disponibilità e condizioni di fornitura.
Hoar sintetizza il passaggio come evoluzione da “search and click” a “intent and authorize”: dalla ricerca e navigazione effettuate personalmente dal compratore alla dichiarazione di un’esigenza che può essere elaborata, almeno in parte, da un agente.
Lo scenario più avanzato è quello del cosiddetto commercio agentico, o Agentic Commerce: un agente AI del compratore, che agisce nell’ambito del mandato e quindi della delega ricevuti dall’essere umano, individua autonomamente un bisogno, cerca prodotti appropriati, raccoglie informazioni presso possibili fornitori e presenta alla persona una proposta da valutare o autorizzare.
Per produttori e distributori tecnico-industriali, però, il punto più interessante non è immaginare fin da subito un agente che effettua autonomamente un ordine.
Il cambiamento più vicino e concreto è un altro: che cosa deve fare un’impresa affinché i propri prodotti e la propria competenza possano essere trovati, compresi e interrogati da motori di risposta e agenti AI?
Da questa domanda derivano cinque trasformazioni fondamentali.
1. Dal commercio digitale al commercio mediato dagli agenti
L’e-commerce che conosciamo è stato progettato essenzialmente per le persone.
Una persona:
- effettua una ricerca
- arriva sul sito
- naviga nelle categorie o usa il motore interno di site search
- utilizza i filtri
- apre una scheda prodotto
- confronta le caratteristiche
- eventualmente richiede informazioni o completa l’acquisto.
Un agente AI può seguire una logica differente.
Il compratore potrebbe chiedergli, per esempio:
“Trova una chiave dinamometrica con campo di lavoro adatto a questa applicazione, attacco da 1/2”, conforme alla norma richiesta, acquistabile da un fornitore italiano.”
L’agente potrebbe cercare più fonti, identificare i prodotti, confrontare caratteristiche e documentazione e presentare una selezione.
Il passaggio fondamentale è quindi da:
persona → sito → prodotto
a una possibile relazione:
persona → delega → agente AI → fonti e sistemi di diversi fornitori → prodotti
Questo non significa che il sito scomparirà.
Significa che il sito non sarà necessariamente l’unica porta attraverso cui il mercato accede all’offerta dell’impresa.
Hoar osserva che nel B2B le attività più standardizzabili, ripetitive e fondate su regole saranno probabilmente automatizzate prima di quelle che richiedono negoziazione, fiducia, assunzione di responsabilità e giudizio in presenza di informazioni incomplete o soggette a interpretazione.
Per un’impresa industriale conviene quindi distinguere almeno tre livelli.
Il primo è la scoperta assistita dei prodotti: l’agente trova prodotti compatibili con un’esigenza.
Il secondo è l’assistenza al processo commerciale: l’agente verifica, per esempio, documenti, disponibilità o condizioni.
Il terzo è la vera esecuzione agentica: l’agente può compiere autonomamente operazioni autorizzate.
Per molte PMI italiane il primo livello è già sufficientemente importante da giustificare una strategia specifica.
Non occorre aspettare che i robot “comprino da soli”.
Occorre iniziare a chiedersi: come rendere il catalogo comprensibile e interrogabile dalle macchine?
2. Product data e conoscenza tecnica diventano infrastruttura commerciale
Uno dei messaggi più forti di Bot 2 Bot è che la qualità dei dati diventerà una condizione essenziale per la competitività.
Non vinceranno necessariamente le aziende che possiedono più informazioni, ma quelle che dispongono di dati puliti, pertinenti, strutturati, coerenti, aggiornati e leggibili dalle macchine.
È un cambiamento particolarmente importante nel B2B tecnico-industriale.
Una persona esperta riesce spesso a compensare dati insufficienti.
Un addetto commerciale può sapere che due denominazioni indicano la stessa famiglia di prodotti. Un tecnico può riconoscere che un certo componente è compatibile con un altro. Un cliente abituale può sapere quale codice interno corrisponde al codice del produttore.
Una macchina può farlo soltanto se dispone delle informazioni o delle relazioni esplicite necessarie per dedurlo con sufficiente affidabilità.
Per questo il tradizionale elenco di articoli deve progressivamente trasformarsi in un vero modello della conoscenza di prodotto.
Non bastano codice, titolo e descrizione
Per un prodotto tecnico diventano importanti almeno:
Identità
- codice articolo del distributore
- codice del produttore
- marca
- modello
- GTIN, quando disponibile
- eventuali codici alternativi.
Classificazione
- famiglia
- categoria
- sottocategoria
- tassonomia tecnica
- tassonomia standardizzata, quando applicabile. Esempi: eCl@ss, ETIM (Electro-Technical Information Model), Nato Stock Number (NSN) / Codifica NATO
Caratteristiche
- materiali
- dimensioni
- prestazioni
- campi di lavoro
- precisioni
- interfacce
- norme
- certificazioni
- unità di misura normalizzate.
Applicazioni
- lavorazioni
- macchine
- materiali lavorabili
- condizioni operative
- settori di utilizzo.
Relazioni
- accessorio di
- compatibile con
- ricambio di
- alternativa a
- utilizzabile insieme a
- componente di un kit
- modello precedente o successivo (versione).
Documentazione
- schede tecniche
- manuali
- certificati
- disegni
- video
- istruzioni.
Provenienza
- fonte dell’informazione
- revisione del contenuto
- data di aggiornamento
- eventuale validazione.
Non è indispensabile costruire tecnicamente un knowledge graph, cioè una banca dati organizzata esplicitamente come rete di entità e relazioni.
È però necessario arrivare a un modello della conoscenza leggibile dalle macchine, nel quale caratteristiche e relazioni importanti non restino solamente implicite nella mente degli esperti o frammentate in PDF, fogli elettronici e descrizioni non strutturate.
Questo patrimonio diventa la base comune di tutto ciò che viene dopo: AEO/GEO (Answer Engine Optimization / Generative Engine Optimization), motore interno di site search, chatbot tecnico, alimentazione dei cataloghi di parti terze (distributori, rivenditori, partner), API e server MCP (ed eventuali altri protocolli di Agentic Commerce).
3. La visibilità si divide in due: essere citati e poter essere interrogati
Finora la visibilità digitale è stata interpretata soprattutto attraverso la SEO, la Search Engine Optimization, cioè l’ottimizzazione per i motori di ricerca.
Con l’affermarsi delle risposte generate dall’intelligenza artificiale si stanno aggiungendo due sigle:
AEO – Answer Engine Optimization, cioè ottimizzazione dei contenuti per i motori che forniscono direttamente risposte;
GEO – Generative Engine Optimization, cioè ottimizzazione dei contenuti affinché possano essere compresi, recuperati e utilizzati dai sistemi di intelligenza artificiale generativa.
Le definizioni e i confini fra AEO e GEO non sono ancora completamente standardizzati. Dal punto di vista aziendale interessa soprattutto il risultato: aumentare la probabilità che la conoscenza e i prodotti dell’impresa vengano presi in considerazione e scelti quando un sistema AI deve costruire una risposta.
Ma nel nuovo scenario si aggiunge una seconda forma di visibilità, differente.
Non basta essere citabili. Sarà sempre più importante essere anche direttamente interrogabili.
Primo livello: essere una fonte per motori AI e chatbot
Questo è il terreno di AEO e GEO.
Google precisa che non esiste uno speciale codice sorgente “GEO” da inserire nel sito e che, anche per le proprie esperienze basate sull’intelligenza artificiale, rimangono fondamentali indicizzazione, accessibilità e contenuti utili e affidabili. I dati strutturati aiutano a rendere esplicito il significato delle informazioni, ma non costituiscono da soli una scorciatoia per essere citati.
Per un’impresa industriale significa pubblicare contenuti che rispondano realmente alle domande degli utenti:
- criteri di scelta
- FAQ tecniche
- confronti
- compatibilità
- problemi, cause e rimedi
- guide operative
- casi applicativi
- tabelle tecniche
- glossari
- documentazione
- video dimostrativi
- informazioni sui servizi.
La scheda prodotto rimane importante, ma non dovrebbe essere l’unica unità informativa.
Un utente non chiede necessariamente:
“Mostrami il prodotto 12345.”
Può chiedere:
“Quale utensile utilizzare per questa lavorazione?”
oppure:
“Qual è la differenza fra questi due sistemi?”
oppure:
“Quale ricambio è compatibile con questo modello?”
I contenuti aziendali devono riuscire a rispondere anche a queste domande.
Il caso particolare del distributore
Per i distributori industriali nasce un problema interessante.
Essi vendono prodotti di marche che spesso dispongono già di siti, cataloghi e documentazione autorevole.
Per non essere penalizzati da AEO/GEO sarà sempre più importante mantenere coerente l’identità del prodotto attraverso i diversi canali.
Il distributore dovrebbe quindi riportare con precisione:
- marca
- codice del produttore
- modello
- GTIN se disponibile
- caratteristiche ufficiali
- documentazione primaria.
Coerenza non significa però copiare la descrizione del produttore.
Significa permettere ai sistemi di riconoscere senza ambiguità che il prodotto presentato dal distributore è la stessa entità descritta dal produttore e dagli altri soggetti della catena commerciale.
Per differenziarsi, il distributore deve aggiungere un secondo livello di informazione.
Potremmo definirlo: conoscenza del distributore
Il “knowledge del distributore” comprende ciò che il distributore conosce grazie alla propria esperienza di mercato, alle peculiarità dei distretti o delle filiere industriali in cui opera prevalentemente oppure al tipo di clientela che serve in prevalenza:
- applicazioni
- compatibilità
- alternative
- prodotti complementari
- combinazioni e kit
- disponibilità sul territorio, cioè disponibilità di prossimità
- servizi associati
- supporto tecnico
- formazione
- casi d’uso
- esempi applicativi
- video realizzati sul campo
- domande frequenti dei clienti
- problemi riscontrati e relative soluzioni.
La regola potrebbe essere sintetizzata così: coerenza sull’identità del prodotto, differenziazione sulla conoscenza e sul servizio.
Se la domanda è:
“Quali sono le caratteristiche del prodotto X?”
la documentazione ufficiale del produttore è la fonte naturale.
Se invece la domanda è:
“Quale soluzione disponibile in Italia posso utilizzare per questa applicazione, con quali accessori e quale assistenza?”
il distributore dispone di elementi che il produttore potrebbe non conoscere o non pubblicare.
È qui che si costruisce una possibile difendibilità GEO del distributore.
Secondo livello: essere scoperti come fornitore interrogabile
Con gli agenti compare una domanda nuova: come fa una macchina a sapere che la mia azienda possiede un catalogo capace di rispondere a una determinata richiesta tecnica?
AEO/GEO lavorano principalmente sul contenuto pubblicato.
L’accesso diretto degli agenti introduce invece API e protocolli macchina-macchina.
Ed è qui che entra il concetto di architettura API-first.
4. API-first e MCP: il catalogo diventa un servizio interrogabile
API significa Application Programming Interface, interfaccia di programmazione applicativa.
In termini non tecnici, un’API è una porta strutturata attraverso cui un’applicazione può chiedere dati o servizi a un’altra applicazione senza dover utilizzare manualmente il suo sito.
Per esempio, invece di aprire un e-commerce, impostare cinque filtri e leggere dieci pagine, un software potrebbe chiedere direttamente:
“Restituisci le chiavi dinamometriche con queste caratteristiche.”
Il sistema risponde con dati strutturati.
Essere API-first significa progettare i sistemi aziendali in modo che dati e funzioni importanti possano essere messi a disposizione attraverso interfacce stabili, indipendenti dalla singola pagina web.
Il sito diventa quindi uno dei possibili utilizzatori dei dati, non necessariamente l’unico.
Che cos’è il protocollo MCP e a che cosa serve
MCP significa Model Context Protocol.
È uno standard aperto che permette alle applicazioni di intelligenza artificiale di collegarsi a sistemi esterni e utilizzarne dati e funzioni. Il progetto MCP lo paragona, semplificando, a una sorta di porta USB-C per le applicazioni AI: un’interfaccia standard attraverso cui sistemi differenti possono comunicare.
Un produttore o distributore potrebbe quindi predisporre un server MCP, cioè un servizio che dichiara agli agenti quali operazioni è in grado di eseguire.
Per esempio:
- trovare un prodotto per codice
- cercare prodotti per caratteristiche
- individuare prodotti adatti a un’applicazione
- cercare compatibilità
- confrontare articoli
- recuperare documentazione tecnica.
L’aspetto importante è che il server non si limita a dichiarare:
“dispongo di un catalogo”.
Descrive anche come può essere interrogato.
Un servizio di ricerca di prodotti potrebbe dichiarare, per esempio, di poter ricevere:
- categoria
- applicazione
- materiale
- diametro
- norma
- produttore
- codice produttore.
Questa descrizione costituisce una sorta di mappa semantica delle capacità del catalogo.
Non è un vero grafo della conoscenza, ma permette all’agente di capire quali domande ha senso rivolgere a quel sistema.
Il sistema può inoltre definire in forma strutturata quali informazioni restituirà: codice, produttore, caratteristiche, applicazioni, collegamenti alla documentazione, fonte del dato e così via.
MCP non sostituisce l’API aziendale: dati e capacità devono essere governati a monte
Per una PMI sarebbe poco opportuno costruire l’intera architettura informativa attorno a MCP o a un altro protocollo destinato agli agenti AI. Gli standard possono evolvere e nuovi protocolli possono affermarsi; i product data e la logica con cui l’azienda li utilizza costituiscono invece un patrimonio aziendale che deve rimanere indipendente dai singoli canali di pubblicazione.
È utile, a questo proposito, distinguere due asset differenti.
Asset 1 – Product knowledge: che cosa sappiamo?
È l’insieme della conoscenza relativa ai prodotti:
- identità e codici
- classificazioni e tassonomie
- caratteristiche tecniche
- applicazioni
- relazioni fra prodotti
- compatibilità
- accessori e ricambi
- alternative
- documentazione tecnica
- provenienza e validazione delle informazioni.
Questa conoscenza può essere governata attraverso PIM, CCMS, ERP, database e altri sistemi aziendali e resa disponibile tramite API.
Asset 2 – Product capabilities: che cosa sappiamo fare con quella conoscenza?
È l’insieme delle funzioni attraverso cui i product data vengono trasformati in risposte operative. Per esempio:
- trovare un prodotto partendo da un codice
- cercare prodotti in base a caratteristiche tecniche
- individuare i prodotti adatti a una determinata applicazione
- trovare accessori e ricambi compatibili
- individuare alternative
- confrontare prodotti
- recuperare la documentazione pertinente.
Questa seconda componente è particolarmente importante nell’era degli agenti AI. La logica di product discovery diventa infatti patrimonio aziendale governato, esattamente come i product data.
Se ogni sito, chatbot o applicazione riceve soltanto i dati grezzi e implementa in modo autonomo le proprie regole di ricerca e selezione, la stessa conoscenza viene interpretata più volte e può produrre risultati differenti. Il sito aziendale potrebbe individuare dieci prodotti per una certa applicazione, il sito di un distributore otto e il chatbot dodici, pur partendo dagli stessi dati.
Quando invece la funzione find_products_for_application, per esempio, viene gestita centralmente come servizio aziendale, tutti i canali possono utilizzare la stessa logica validata.
L’architettura può quindi evolvere da un semplice servizio di distribuzione dei dati a un vero livello di servizi di prodotto:
ERP / PIM / CCMS / documentazione tecnica
↓
modello della conoscenza di prodotto
↓
API aziendali
che possono mettere a disposizione due famiglie di servizi:
servizi dati
- restituzione dei product data
- attributi
- classificazioni
- relazioni
- documentazione
e servizi di dominio o di product discovery
- ricerca per codice
- ricerca per caratteristiche
- selezione per applicazione
- compatibilità
- alternative
- confronto
- recupero della documentazione pertinente.
↓
Questi servizi possono essere utilizzati da canali differenti:
- sito aziendale
- siti di distributori, rivenditori e partner autorizzati
- applicazioni mobili
- chatbot
- server MCP
- flussi verso piattaforme esterne
- eventuali altri protocolli presenti o futuri.
In questo modello, quindi, il sito non è più il luogo in cui necessariamente risiede la logica di ricerca del catalogo. Il sito è uno dei possibili utilizzatori delle capacità messe a disposizione dal livello API.
Questo è il significato più ampio di un’architettura API-first: non soltanto rendere i product data indipendenti dal sito, ma rendere indipendenti dal singolo canale anche le principali capacità con cui quei dati vengono interrogati e trasformati in risposte.
Come si inserisce MCP a questa architettura
MCP, Model Context Protocol, è un protocollo aperto che permette alle applicazioni basate sull’intelligenza artificiale (come per esempio gli agenti dell’Agentic Commerce) di conoscere e utilizzare dati e funzioni messi a disposizione da sistemi esterni.
Il server MCP può quindi essere realizzato soprattutto come connettore di agenti AI verso servizi aziendali già esistenti, anziché duplicare dati e logiche applicative.
MCP distingue, in particolare, due concetti utili nel nostro scenario.
Le resources, cioè le risorse, consentono di rendere disponibili dati e contenuti che possono fornire contesto all’agente: per esempio una scheda prodotto, una classificazione, un manuale o una scheda tecnica.
I tools, cioè gli strumenti, rappresentano invece operazioni che l’agente può richiamare. Per esempio:
- get_product_by_code
- find_products_by_attributes
- find_products_for_application
- find_compatible_products
- find_alternatives
- get_product_documentation.
Il server MCP descrive all’agente quali strumenti sono disponibili, a che cosa servono, quali parametri accettano e quale tipo di risultato restituiscono.
Ma questo non implica che la logica debba essere implementata nel server MCP stesso.
Un tool MCP come:
find_products_for_application
può semplicemente tradurre la richiesta dell’agente in una chiamata a una funzione già disponibile nelle API aziendali:
agente AI
↓
tool MCP find_products_for_application
↓
API aziendale di product discovery
↓
motore di ricerca / regole / PIM / database (potrebbe essere una ricerca SQL, full-text/lessicale oppure vettoriale semantica, ecc.)
↓
prodotti pertinenti
↓
risposta strutturata all’agente
MCP diventa quindi lo strato attraverso cui una capacità aziendale viene descritta e resa utilizzabile dagli agenti, mentre la logica che effettua realmente la ricerca rimane nel livello comune delle API.
Questo approccio presenta un vantaggio strategico importante: la stessa capacità può essere utilizzata anche dal sito, da un’applicazione, da un chatbot o da un partner senza dover essere sviluppata nuovamente per ogni canale.
Non è necessario esporre l’intero catalogo come risorsa MCP
Questa distinzione è importante soprattutto per i cataloghi industriali di grandi dimensioni.
Se un’impresa gestisce centinaia di migliaia di articoli, non avrebbe senso consentire a un agente di acquisire indiscriminatamente tutti i product data e lasciare poi al modello il compito di individuare i prodotti pertinenti.
È molto più efficiente mettere a disposizione funzioni mirate.
Alla richiesta:
“Cerco un utensile per questa lavorazione, con queste caratteristiche”
l’agente può utilizzare un tool di ricerca, che interroga i servizi aziendali e restituisce soltanto un insieme ristretto di prodotti pertinenti.
Successivamente potrà richiamare una seconda funzione per ottenere i dettagli o la documentazione dei soli articoli selezionati.
Il catalogo diventa così interrogabile, anziché semplicemente trasferibile.
Una base comune, più adattatori
La struttura complessiva può essere rappresentata così:
PIM / CCMS / ERP
↓
Product Knowledge Layer
Che cosa sappiamo?
identità + classificazioni + attributi + applicazioni + relazioni + documentazione + provenienza
↓
API aziendali
Data Services
Quali dati possiamo fornire?
Product / Domain Services
Che cosa sappiamo fare con quei dati?
ricerca + selezione + compatibilità + alternative + confronto + recupero documenti
↓
adattatori e canali
- sito
- siti partner
- chatbot
- MCP
- flussi strutturati di prodotto
- ACP, UCP o altri protocolli eventualmente adottati in futuro.
In questo modo la fonte della verità rimane una e la logica di product discovery rimane governata centralmente.
Se in futuro cambia un protocollo o ne emerge uno nuovo, non è necessario ricostruire il patrimonio informativo o la logica di selezione dei prodotti. Occorre principalmente realizzare un nuovo adattatore che traduca le capacità aziendali nel linguaggio richiesto dal nuovo ecosistema.
La distinzione fondamentale può quindi essere sintetizzata così:
Product knowledge: che cosa sappiamo sui prodotti.
Product capabilities: che cosa sappiamo fare con quella conoscenza.
Entrambi sono asset da governare.
E proprio qui emerge il significato strategico dell’API-first nell’era degli agenti: API-first non significa soltanto pubblicare i product data attraverso un’interfaccia indipendente dal sito. Significa rendere indipendenti dal sito anche le capacità con cui quei dati vengono interrogati, correlati e trasformati in risposte.
MCP diventa allora uno dei possibili strati di accesso a questo patrimonio: utilizza resources per mettere a disposizione dati e contenuti e tools per permettere agli agenti di utilizzare le capacità aziendali.
MCP (così come ACP, UCP o altri protocolli futuri dell’ecommerce agentico) non sostituisce quindi l’architettura API-first: la valorizza e la rende accessibile a una nuova categoria di interlocutori, gli agenti AI.
Come viene trovato un server MCP?
Questo è attualmente uno dei punti meno maturi dell’ecosistema.
Una volta che un agente conosce un server MCP, il protocollo gli permette di capire quali strumenti mette a disposizione.
Ma rimane la domanda: come scopre l’agente che quel server esiste?
Esiste un Official MCP Registry, cioè un registro pubblico ufficiale dei server MCP, progettato anche per alimentare altri registri e servizi di catalogazione.
Esistono inoltre registri e cataloghi secondari che possono indicizzare server e singole capacità.
Il progetto MCP sta lavorando anche alle cosiddette Server Cards, documenti standardizzati pubblicabili sul dominio dell’impresa in modo che crawler, registri e altri sistemi possano individuare un server e conoscerne le capacità senza collegarsi preventivamente. Ad agosto 2026 questo meccanismo è ancora in sviluppo. È quindi importante non promettere oggi a un’azienda:
“Pubblicate un server MCP e tutti gli agenti AI troveranno automaticamente il vostro catalogo.”
Non è ancora così.
È invece corretto affermare:
MCP consente già di rendere il catalogo direttamente interrogabile; l’infrastruttura universale attraverso cui agenti generici potranno scoprire automaticamente tutti i server pertinenti è ancora in costruzione.
Questo è probabilmente uno dei punti da monitorare con maggiore attenzione nei prossimi anni.
5. Flussi di dati di prodotto, ACP e UCP: un’altra strada verso la scoperta agentica
Un server MCP non è l’unico modo con cui una piattaforma AI può conoscere un catalogo.
Esiste un’altra soluzione, già molto utilizzata nel commercio elettronico: il flusso strutturato di dati di prodotto, spesso chiamato product feed.
In questo caso il venditore invia periodicamente a una piattaforma una rappresentazione strutturata del catalogo.
È la piattaforma a indicizzarla e utilizzarla per le proprie funzioni di ricerca e raccomandazione.
ACP di OpenAI
ACP significa Agentic Commerce Protocol, protocollo per il commercio agentico.
OpenAI lo utilizza come strato di collegamento fra commercianti e le proprie esperienze commerciali. La documentazione attuale prevede innanzitutto la fornitura di un catalogo strutturato in modo che ChatGPT possa indicizzare correttamente prodotti, caratteristiche, disponibilità e prezzi.
OpenAI stessa suggerisce alla maggior parte degli operatori commerciali di partire proprio dai flussi di dati di prodotto.
Per le imprese italiane esiste però un limite importante: ad agosto 2026 le esperienze Shopping di ChatGPT basate su questa infrastruttura risultano ancora disponibili negli Stati Uniti, con estensione ad altre aree geografiche prevista successivamente.
Per una PMI italiana è quindi sensato preparare dati compatibili, ma non considerare ancora questo canale come operativo sul mercato nazionale.
UCP di Google
UCP significa Universal Commerce Protocol, protocollo universale per il commercio.
Google lo sta sviluppando per permettere agli agenti di accompagnare una parte crescente del percorso commerciale, dalla scoperta fino ad attività più vicine alla transazione.
Per la scoperta dei prodotti sulle superfici Google, UCP continua però a fare ampio affidamento sui dati presenti in Google Merchant Center, il sistema con cui le aziende inviano a Google i propri cataloghi commerciali.
Per le aziende B2B italiane ed europee questo modello presenta difficoltà pratiche.
Merchant Center è fortemente influenzato dalla logica del commercio al dettaglio e, nei paesi europei, richiede normalmente di rappresentare il prezzo lordo comprensivo di IVA. Google stessa dedica indicazioni specifiche agli operatori B2B e conferma questo requisito per la maggior parte dei mercati.
Nel B2B industriale sono invece frequenti:
- prezzi IVA esclusa
- listini diversi
- sconti cliente
- condizioni contrattuali
- quantità minime
- prezzi diversi in base a scaglioni di quantità
- offerte su richiesta.
Per molte PMI italiane, quindi, Merchant Center/UCP non rappresenta ancora il percorso più naturale verso la scoperta dei prodotti da parte degli agenti.
API, MCP, ACP e UCP: un’unica architettura, protocolli con ruoli diversi
Una volta definito che l’impresa dovrebbe governare centralmente sia i product data sia le capacità con cui quei dati vengono interrogati e trasformati in risposte, emerge una domanda naturale:
MCP, ACP e UCP svolgono tutti lo stesso ruolo nei confronti delle API aziendali?
La risposta è: condividono la stessa logica architetturale di fondo, ma non funzionano allo stesso modo e non hanno lo stesso scopo.
Il principio comune rimane quello dell’architettura API-first:
ERP / PIM / CCMS / sistemi aziendali
↓
Product Knowledge
↓
API aziendali
↓
adattatori verso siti, partner, chatbot, agenti AI e piattaforme esterne
In questo modello, MCP, ACP e UCP non dovrebbero diventare il luogo in cui risiedono i product data o la logica fondamentale dell’impresa. Dovrebbero piuttosto costituire strati di adattamento, attraverso cui dati e capacità già governati a monte vengono resi utilizzabili da ecosistemi differenti.
La distinzione diventa più chiara se riprendiamo i due asset fondamentali.
Asset 1 – Product knowledge: che cosa sappiamo dei prodotti?
È il patrimonio informativo dell’impresa.
Asset 2 – Product capabilities: che cosa sappiamo fare con questa conoscenza?
È il patrimonio operativo dell’impresa. Comprende le funzioni con cui il patrimonio informativo viene trasformato in risposte operative.
La differenza fra MCP, ACP e UCP sta soprattutto nel modo in cui ciascun protocollo utilizza questi due asset.
MCP: protocollo generale per esporre dati e capacità agli agenti AI
MCP, Model Context Protocol, è il protocollo più generale dei tre.
Non nasce specificamente per il commercio. Nasce per permettere a un’applicazione di intelligenza artificiale di collegarsi a sistemi esterni e utilizzarne dati e funzioni.
Per questo è particolarmente adatto a rappresentare direttamente il modello che abbiamo definito.
Un server MCP può infatti esporre:
- resources, cioè dati e contenuti
- tools, cioè funzioni che l’agente può invocare.
La corrispondenza con le API aziendali può quindi essere molto diretta:
API aziendale
find_products_for_application()
↓
tool MCP
find_products_for_application
↓
agente AI
Il protocollo MCP non stabilisce quali capacità debba possedere l’impresa. Un distributore di utensili può esporre un tool molto specifico come:
find_cutting_tools_for_material
un produttore di pompe:
find_pump_for_operating_conditions
un distributore di componenti:
find_replacement_component
MCP permette quindi di rappresentare anche conoscenza e logiche fortemente specifiche del dominio tecnico dell’impresa. Con MCP, l’impresa non mette a disposizione soltanto ciò che sa, ma anche ciò che sa fare con quella conoscenza.
È proprio questa caratteristica a renderlo particolarmente interessante nel B2B industriale.
ACP: il protocollo commerciale di OpenAI segue una logica differente
ACP significa Agentic Commerce Protocol.
È un protocollo pensato specificamente per il commercio e per le esperienze commerciali dell’ecosistema OpenAI.
A differenza di MCP, non nasce come meccanismo generale attraverso cui un’impresa può pubblicare qualsiasi capacità.
Nella product discovery, la logica è soprattutto questa:
Product Knowledge
↓
Product API
↓
adattatore ACP
↓
flusso strutturato di dati di prodotto
↓
OpenAI
↓
ChatGPT effettua discovery e selezione
Il merchant fornisce quindi alla piattaforma informazioni strutturate sui prodotti.
La piattaforma le acquisisce, le indicizza e utilizza i propri sistemi per capire quali prodotti presentare in risposta alla richiesta dell’utente.
È un modello molto diverso da:
“ChatGPT chiama la funzione find_products_for_application sviluppata dall’impresa.”
Nel modello ACP di product discovery, l’impresa mette soprattutto a disposizione il catalogo e le informazioni commerciali, mentre la logica di selezione viene svolta prevalentemente dalla piattaforma.
Con ACP possiamo avere questo flusso:
utente
“Mi serve un prodotto adatto a questa applicazione.”
↓
ChatGPT
↓
cataloghi già acquisiti dalla piattaforma
↓
motore di product discovery OpenAI
↓
risultato
Per un’impresa tecnico-industriale la differenza fra MCP e ACP può essere rilevante.
Se il valore competitivo consiste nel possedere determinati prodotti a catalogo, il modello ACP può essere adeguato.
Se invece il valore consiste anche nel sapere, per esempio, quale prodotto utilizzare, in quali condizioni, con quali accessori, con quali vincoli, quali alternative considerare, allora MCP permette di esporre qualcosa di più vicino alla competenza aziendale.
ACP può comunque appoggiarsi alle API aziendali
Il fatto che ACP funzioni in modo diverso da MCP non significa che debba avere una propria base dati separata.
Al contrario, il modello API-first rimane valido.
Se l’impresa dispone già di API come:
- /products
- /prices
- /availability
- /promotions
un adattatore ACP può utilizzare questi servizi per generare e aggiornare il flusso richiesto dalla piattaforma di OpenAI.
L’architettura diventa:
PIM / ERP
↓
Product Knowledge
↓
API aziendali
↓
adattatore ACP
↓
OpenAI
In questo modo il catalogo destinato alla piattaforma non viene gestito separatamente.
Deriva dalla stessa fonte governata utilizzata dal sito, dai partner e dagli altri canali.
Quando ACP entra poi in fasi più vicine alla transazione, può interagire anche con capacità operative come ordini, pagamenti e altri servizi commerciali.
Ma anche in questo caso la logica centrale dovrebbe rimanere nei sistemi aziendali.
ACP diventa il protocollo attraverso cui l’ecosistema OpenAI accede alle capacità necessarie.
UCP: un modello basato su capacità commerciali standardizzate
UCP significa Universal Commerce Protocol.
È il protocollo promosso da Google per standardizzare una parte crescente delle interazioni commerciali svolte da agenti.
Dal punto di vista concettuale presenta una caratteristica particolarmente interessante.
Un’impresa può pubblicare un profilo UCP, cioè una descrizione strutturata delle capacità commerciali che supporta e degli endpoint attraverso cui possono essere utilizzate.
Questo significa che UCP adotta esplicitamente una logica di capabilities, cioè di capacità.
L’impresa può dichiarare, per esempio, di supportare funzioni relative a:
- checkout
- gestione dell’ordine
- evasione
- identità
- pagamento
- altre fasi del processo commerciale.
Ma, diversamente da MCP, queste capacità non sono arbitrarie. Sono principalmente primitive commerciali standardizzate dal protocollo.
MCP dice:
“Descrivi quali strumenti possiedi.”
UCP dice più propriamente:
“Dichiara quali capacità commerciali previste dallo standard supporti e come possono essere richiamate.”
UCP può utilizzare REST API, MCP o altri meccanismi
Questo punto è importante perché mostra che i protocolli non sono necessariamente alternativi fra loro.
UCP può descrivere una capacità commerciale e indicare poi il modo attraverso cui essa viene effettivamente eseguita.
L’esecuzione può avvenire, per esempio, tramite:
- REST API
- MCP
- altri meccanismi di comunicazione fra agenti.
REST è l’approccio comunemente utilizzato per realizzare API Web: un’applicazione chiama un determinato indirizzo e scambia dati strutturati, normalmente in formato JSON.
Possiamo quindi avere:
UCP Business Profile
↓
dichiara:
“Supporto questa capacità commerciale.”
↓
indica:
REST endpoint
↓
API aziendale
oppure:
UCP Business Profile
↓
MCP binding
↓
MCP tool
↓
API aziendale
Questo mostra molto bene perché non conviene considerare MCP e UCP come tecnologie necessariamente concorrenti.
Possono operare a livelli differenti.
UCP può descrivere la capacità commerciale.
MCP può costituire uno dei modi attraverso cui quella capacità viene resa invocabile.
La product discovery di Google rimane però oggi un caso particolare
Bisogna distinguere fra la logica generale di UCP e il modo in cui Google gestisce oggi la scoperta dei prodotti all’interno delle proprie piattaforme.
Per la product discovery, Google continua a utilizzare soprattutto i dati presenti in Google Merchant Center, il sistema attraverso cui i merchant forniscono cataloghi strutturati a Google.
Il modello è quindi:
Product Knowledge
↓
feed Merchant Center
↓
infrastruttura prodotto Google
↓
discovery
Parallelamente:
Commerce Services
↓
API aziendali
↓
UCP
↓
capacità commerciali agentiche
Quindi, almeno nello scenario attuale, non bisogna immaginare necessariamente che un agente Google chiami direttamente una funzione aziendale come:
find_products_for_application
per scoprire i prodotti.
La discovery tende ancora a essere effettuata sulla base dei dati precedentemente acquisiti dalla piattaforma.
MCP, ACP e UCP non sono quindi tre adattatori equivalenti
È utile evitare una rappresentazione troppo semplice come:
API → MCP
API → ACP
API → UCP
perché suggerirebbe che i tre protocolli fanno sostanzialmente la stessa cosa.
La rappresentazione più corretta è:
API AZIENDALI
↓
MCP
protocollo generale per agenti
Può esporre:
- dati
- documentazione
- capacità arbitrarie
- logiche tecniche specifiche dell’impresa.
↓
agenti AI
***
ACP
protocollo ed ecosistema commerciale OpenAI
Utilizza soprattutto:
- flussi di prodotto
- informazioni commerciali
- capacità necessarie alle esperienze di commercio OpenAI.
↓
ChatGPT / ecosistema OpenAI
***
UCP
protocollo per capacità commerciali standardizzate, supportato da Google
Dichiara:
- quali capacità commerciali supporta l’impresa
- attraverso quali endpoint possono essere eseguite.
Può utilizzare:
- REST
- MCP
- altri meccanismi compatibili.
↓
ecosistemi di commercio agentico
Il principio API-first acquista un significato ancora più ampio: non significa soltanto separare i product data dal sito, ma rendere indipendenti dai singoli canali anche le capacità con cui quei dati vengono interrogati, correlati e trasformati in risposte o azioni.
MCP, ACP e UCP si collocano sopra questo livello comune, ciascuno con un ruolo diverso.
E proprio questa separazione permette a una PMI di prepararsi al commercio agentico senza dover scommettere oggi su quale protocollo diventerà dominante domani.
SEO, AEO/GEO, Agentic Commerce, approccio API-first, protocolli MCP, ACP e UCP: il punto di convergenza è la conoscenza di prodotto
SEO, AEO/GEO, Agentic Commerce, approccio API-first, protocolli MCP, ACP e UCP, siti di e-commerce, chatbot tecnici, distribuzione verso parti terze autorizzate di patrimonio informativo e operativo dell’azienda: potrebbero sembrare tutti progetti differenti.
In realtà dipendono quasi tutti dalla stessa materia prima.
Prendiamo un distributore che conosce: quali prodotti sono adatti a una lavorazione, quali accessori servono, quali alternative esistono e quale documentazione supporta l’affermazione.
Questa stessa conoscenza può alimentare:
una pagina GEO
“Come scegliere un utensile per…”
una FAQ / un answer asset per l’AI generativa
“Quale accessorio è compatibile con…?”
un chatbot
“Per questa applicazione puoi valutare…”
un server MCP
ricerca prodotti per applicazione e compatibilità;
un flusso di dati di prodotto
caratteristiche, classificazione e relazioni strutturate.
Il problema non è quindi produrre separatamente contenuti per cinque canali.
È costruire una fonte aziendale governata dalla quale possano derivare cinque rappresentazioni differenti.
Questo è uno dei motivi per cui la gestione della conoscenza tecnica acquista un’importanza strategica completamente nuova.
Argo CCMS e PIM come possibile base di questa architettura
In questo scenario un sistema come Argo di Kea, che integra funzioni di CCMS e PIM, può costituire una base particolarmente interessante.
CCMS significa Component Content Management System, sistema di gestione dei contenuti a componenti. Invece di gestire ogni manuale, pagina o documento come un blocco isolato, un CCMS permette di organizzare contenuti tecnici in unità strutturate e riutilizzabili.
PIM significa Product Information Management, gestione delle informazioni di prodotto.
Il PIM organizza invece dati come:
- codici
- classificazioni
- attributi
- caratteristiche
- varianti
- relazioni
- documentazione associata.
L’unione dei due mondi è particolarmente adatta allo scenario descritto in questo articolo.
Da una parte abbiamo i dati di fatto relativi al prodotto, cioè il patrimonio informativo.
Dall’altra abbiamo la conoscenza tecnica che permette di interpretarli e utilizzarli, cioè il patrimonio operativo.
Un sistema come Argo CCMS e PIM può quindi diventare la base dalla quale produrre e governare:
- manualistica
- cataloghi
- schede prodotto
- FAQ
- guide alla scelta
- troubleshooting
- contenuti per AEO/GEO / answer asset
- dati strutturati per il Web
- basi di conoscenza per chatbot
- informazioni da esporre attraverso API
- contenuti e product data destinati in futuro ad agenti AI e protocolli di commercio agentico.
Il valore consiste soprattutto nell’avere una fonte governata, strutturata e riutilizzabile della conoscenza tecnica e dei dati di prodotto. L’intelligenza artificiale può poi diventare uno dei molti utilizzatori di quella fonte.
Che cosa dovrebbe fare oggi una PMI tecnico-industriale
Per un produttore o distributore italiano non avrebbe senso partire acquistando indiscriminatamente nuove tecnologie.
La sequenza dovrebbe essere quasi opposta.
Primo: verificare la qualità della base informativa
Occorre chiedersi:
- i prodotti sono identificati senza ambiguità?
- utilizziamo anche i codici dei produttori?
- gli attributi sono normalizzati?
- le unità di misura sono coerenti?
- sappiamo rappresentare compatibilità e relazioni?
- conosciamo la provenienza delle informazioni?
- la documentazione è collegata correttamente ai prodotti?
Secondo: trasformare il sapere aziendale in conoscenza esplicita
Molto valore rimane ancora nelle persone:
“questo prodotto va bene anche per…”
“quando succede questo, il problema normalmente è…”
“questi due articoli vengono utilizzati insieme…”
“questo è il ricambio corretto…”
“per questa applicazione consigliamo invece…”
Questa conoscenza deve progressivamente diventare patrimonio aziendale strutturato.
Terzo: produrre contenuti pensati per le domande
Non solo schede prodotto, ma anche:
- FAQ
- guide
- comparazioni
- criteri di selezione
- problemi e soluzioni
- casi applicativi
- video
- tabelle di compatibilità.
È la base dell’AEO/GEO.
Quarto: separare i dati dalla loro presentazione
Il sito non dovrebbe essere l’unico luogo in cui esistono le informazioni.
Occorre disporre di una base dati e di API che permettano agli stessi contenuti, ed eventualmente alle loro logiche di utilizzo, di essere pubblicati attraverso canali differenti.
Questa è la vera logica API-first.
Quinto: iniziare a sperimentare l’accesso agentico
Quando il catalogo è sufficientemente strutturato, può avere senso sperimentare un server MCP inizialmente limitato alla sola lettura.
Non occorre esporre prezzi riservati, contratti o funzioni di ordine.
Il primo obiettivo può essere molto più semplice: permettere a un agente di trovare prodotti in base a requisiti tecnici.
Per un distributore industriale potrebbe essere già un notevole passo avanti.
Conclusione: essere un’impresa comprensibile dalle macchine
La trasformazione descritta da Bot 2 Bot non impone alle PMI industriali di costruire immediatamente complessi sistemi di commercio autonomo.
Pone però una domanda molto concreta: quanto è comprensibile la nostra azienda da una macchina?
Un’intelligenza artificiale riesce a capire:
- quali prodotti vendiamo?
- come sono identificati?
- per quali applicazioni sono adatti?
- quali caratteristiche possiedono?
- quali prodotti sono compatibili?
- quali alternative esistono?
- quale documentazione supporta le informazioni?
- quali servizi associamo ai prodotti?
- in quali mercati operiamo?
- perché dovrebbe considerare noi, anziché un altro fornitore?
Per molto tempo la digitalizzazione commerciale si è concentrata soprattutto sull’esperienza della persona davanti allo schermo.
La prossima fase aggiunge un nuovo interlocutore: la macchina che lavora per la persona da cui ha ricevuto la delega e il mandato per farlo.
Per questo il vantaggio competitivo non consisterà semplicemente nell’“avere l’intelligenza artificiale”.
Consisterà sempre più nell’essere: un’impresa che l’intelligenza artificiale riesce a trovare, capire, interrogare e considerare affidabile.
Ed è proprio qui che contenuti tecnici, product data, AEO/GEO, API e protocolli come MCP smettono di essere iniziative separate e diventano parti di una stessa strategia.