Menu

Issue 10021

Architettura enterprise per l'agentic commerce: fiducia, confini e controllo

Come progettare un agente che aiuta a vendere e comprare senza diventare una scorciatoia per autorizzazioni, dati e processi critici.

· 5 min

Dalla serie

Obiettivo

Disegnare una reference architecture enterprise con confini di fiducia, autorità delegate, policy enforcement, human-in-the-loop, audit, osservabilità, valutazione e adozione progressiva.

Cosa deve fare davvero una reference architecture

In un contesto enterprise, un agente per l'agentic commerceGlossarioAgentic CommerceUn modello di commercio digitale nel quale agenti software interpretano obiettivi e possono preparare o compiere azioni commerciali entro limiti espliciti.Apri la voce completa non va trattato come una semplice interfaccia conversazionale. Va invece progettato come un nuovo attore operativo con permessi limitati, responsabilità tracciabili e punti di controllo ben definiti. La prima scelta architetturale è separare decisione proposta e decisione autorevole. L'agente può interpretare l'intento, recuperare candidati, spiegare opzioni e preparare un'azione. Ma PIM e catalogo restano autorevoli per identità e attributi del prodotto, mentre pricing, inventory, OMS e payment restano autorevoli per i fatti dinamici e transazionali. La seconda scelta è rendere esplicita l'autorità delegata. Un agente può avere il mandatoGlossarioMandatoL'autorizzazione esplicita a occuparti di un risultato, con confini su cosa puoi decidere e cosa puoi solo rendere visibile.Apri la voce completa di preparare un carrello, ma non di completare un ordine oltre una soglia. Può operare per una sessione, un importo o un set di prodotti specifico. Se questi limiti non sono applicati dal sistema, la fiducia diventa solo una promessa narrativa. La terza scelta è inserire human-in-the-loopGlossarioHuman-in-the-loopUn controllo nel quale una persona verifica, approva o corregge una decisione prima o durante l'esecuzione.Apri la voce completa nei punti giusti. Non serve confermare ogni tool call. Serve conferma quando cambia un fatto difficile da invertire: importo, destinatario, metodo di pagamento, policy o rischio. In pratica, il team deve progettare l'esperienza di conferma come una decisione di business, non come un dettaglio UX. Infine, l'architettura deve prevedere osservabilitàGlossarioOsservabilitàLa capacità di comprendere il comportamento di un sistema a partire dai segnali che produce.Apri la voce completa end-to-end: intento ricevuto, vincoli estratti, dati autorevoli letti, policy valutate, azioni eseguite, esiti e eventuale revisione umana. Senza questa correlazione, non puoi spiegare perché un ordine è stato consentito, rifiutato o ritentato.

I trade-off che non puoi evitare

Più autonomia all'agente significa meno attrito per il cliente, ma anche più superficie di rischio. Se allarghi il mandato, migliori la fluidità del percorso, però aumentano anche i requisiti di audit, sicurezza, compensazione e ownership. Se sposti logica commerciale dentro il layer agentico, rendi il sistema apparentemente più veloce da costruire, ma perdi il controllo sulle fonti di verità. Il rischio tipico è duplice: dati duplicati nel layer AI e comportamenti diversi tra canaleGlossarioCanaleUn formato o una destinazione attraverso cui una issue raggiunge il lettore.Apri la voce completa conversazionale e sistemi transazionali. Se scegli una forte separazione tra reasoning probabilistico e controlli deterministici, ottieni più robustezza e una governance più chiara. Il costo è una maggiore complessità di integrazione e una user experience meno “magica”, perché alcune decisioni richiedono conferme o ricalcoli dal sistema autorevole. Anche la scelta del protocollo ha un trade-offGlossarioTrade-offUno scambio in cui migliorare un risultato ne indebolisce o ne rende più costoso un altro.Apri la voce completa. Standard come ACP o UCP possono aiutare l'interoperabilità, ma non sostituiscono l'architettura interna. Se li tratti come una soluzione completa, rischi di nascondere i veri problemi: identità, policy, idempotenzaGlossarioIdempotenzaLa proprietà per cui ripetere un’operazione non produce effetti aggiuntivi indesiderati.Apri la voce completa, riconciliazione e separazione delle responsabilità. In breve: l'obiettivo non è dare più potere all'agente, ma dare al sistema abbastanza controllo da potersi fidare del suo impiego in produzione.

Un caso realistico: retailer omnicanale con checkout assistito

Immagina un retailer omnicanale che vuole introdurre un buyer agent per supportare acquisti ricorrenti di materiale da ufficio e dispositivi elettronici. Il primo tentativo del team è collegare il modello direttamente al catalogo e al carrello. Funziona in demo, ma in staging emergono subito i problemi: prezzi non allineati, varianti confuse, ordini duplicati dopo timeoutGlossarioTimeoutUn limite definito a quanto un’operazione attende prima di considerare il tentativo non riuscito.Apri la voce completa e nessuna prova chiara di chi abbia autorizzato cosa. La versione corretta separa i layer. Il channel layer gestisce la conversazione. L'agent gateway autentica il canale e traduce il protocollo esterno in capability interne. L'orchestration layer mantiene stato e idempotency key. I domini di pricing, inventory e OMS restano autorevoli. Il policy decision point verifica soglia di spesa, prodotti consentiti e necessità di conferma umana. Nel primo rilascio l'agente fa solo discovery grounded: propone opzioni e spiega i compromessi. Nel secondo costruisce un carrello preparato, ma non completa nulla. Nel terzo può completare solo entro un mandato limitato e con conferma esplicita quando cambia il rischio. Ogni fase ha metriche diverse: qualità della selezione, tasso di astensione, duplicati, escalationGlossarioEscalationUna richiesta deliberata a un’autorità superiore o diversa per risolvere un rischio materiale o una decisione bloccata.Apri la voce completa, conversione e accuratezza delle spiegazioni. Il risultato non è un agente più “intelligente” in astratto. È un sistema più affidabile, perché ogni decisione importante resta verificabile, riconciliabile e attribuibile a un owner enterprise.

Per approfondire

Fonti esterne autorevoli per approfondire rischio, minacce agentiche e modelli di interoperabilità nel commerce. • NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence • OWASP Agentic Security Initiative — Agentic AI: Threats and Mitigations — https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/Universal Commerce ProtocolGlossarioUniversal Commerce ProtocolUno standard aperto che definisce linguaggio e primitive comuni per l'interoperabilità tra piattaforme, business e provider di pagamento.Apri la voce completa — Core Concepts — https://ucp.dev/documentation/core-concepts/

Tag