Perché gli strumenti di tracciamento degli LLM stanno creando gateway per l’IA

Nel 2026, LangSmith, Langfuse, Opik e Braintrust hanno tutti aggiunto un gateway davanti ai provider di modelli. Il motivo principale è il controllo: uno strumento di tracciamento può solo registrare una chiamata a un modello, mentre un gateway può bloccarla.

Due strumenti con funzioni distinte

Negli ultimi due anni, molti team hanno gestito le applicazioni basate su modelli linguistici di grandi dimensioni (LLM) con due strumenti separati. Tra l’applicazione e i provider di modelli si trovava un gateway. Custodiva le chiavi API dei provider, traduceva le richieste tra le API dei diversi provider e riprovava le chiamate non riuscite. LiteLLM, un proxy open source, è diventato una scelta comune per questo compito. Accanto all’applicazione c’era uno strumento di tracciamento, come LangSmith o Langfuse, che registrava ogni chiamata a un modello, ogni chiamata a uno strumento e ogni fase di recupero, permettendo agli ingegneri di vedere cosa aveva fatto un agente.

La suddivisione aveva senso: un gateway deve essere veloce e supportare le API di tutti i provider, mentre uno strumento di tracciamento ha bisogno di una buona interfaccia, di spazio per archiviare payload di grandi dimensioni e di un SDK che si integri nel codice dell’applicazione. Langfuse documenta ancora questa configurazione a due strumenti, con un’integrazione di LiteLLM Proxy che instrada ogni chiamata attraverso il proxy e poi a Langfuse. Nel 2026, i fornitori di strumenti di tracciamento hanno iniziato a sviluppare direttamente i gateway.

Quattro lanci in sei mesi

LangChain ha annunciato il gateway LLM di LangSmith in beta privata nel maggio 2026 e lo ha reso disponibile in beta pubblica il 30 luglio; da allora lo ha incluso anche nelle distribuzioni di LangSmith sul cloud del cliente. Braintrust ha dismesso il suo precedente proxy per l’IA e ha indirizzato gli utenti verso un nuovo gateway, attualmente in anteprima e gratuito fino alla disponibilità generale. Comet ha rilasciato l’Opik LLM Gateway come endpoint beta che accetta richieste nel formato OpenAI. Il 4 novembre, Langfuse ha reso disponibile il suo gateway per l’IA in beta pubblica, sia su Langfuse Cloud sia per le distribuzioni autogestite. Il gateway è rilasciato con licenza MIT ed è scritto in Rust.

MLflow, nato come strumento per la gestione del ciclo di vita dell’apprendimento automatico e non come strumento di tracciamento, offre da più tempo un gateway per l’IA, con avvisi e limiti di spesa.

I gateway esistono da anni e i rischi legati alla gestione di un gateway sono ben documentati. I nuovi gateway arrivano da aziende la cui attività consisteva nel registrare le chiamate ai modelli, e che ora vogliono che ogni chiamata passi prima da loro.

Perché il controllo del budget richiede di intercettare le richieste

Uno strumento di tracciamento registra una chiamata a un modello dopo che il provider ha risposto e i token sono stati pagati. Questa registrazione basta per creare un grafico delle spese, ma lo strumento di tracciamento non può impedire che la spesa continui. Far rispettare il budget di un team, bloccare un modello o rimuovere un segreto da un prompt richiede di controllare la richiesta prima che raggiunga il provider. Solo il componente che si trova nel percorso della richiesta può farlo.

LangChain illustra questo argomento nel post di lancio. Descrive team che combinano un gateway separato, un prodotto per le misure di sicurezza e uno strumento di osservabilità, e afferma che per prevenire i problemi occorre applicare le policy al livello delle richieste. Se una chiamata supera il budget, il gateway risponde con il codice di stato HTTP 402 anziché inoltrarla al provider.

Un unico punto di accesso registra ogni chiamata

Il secondo motivo è la copertura. Un SDK registra solo i percorsi del codice che qualcuno ha strumentato. È al di fuori di questi percorsi che i malfunzionamenti degli agenti tendono a passare inosservati. Uno script su un portatile, un notebook o un agente di programmazione che usa una chiave API copiata non lascia traccia. Un gateway che custodisce le chiavi dei provider vede ogni chiamata, perché non esistono altri percorsi per raggiungere il provider.

Langfuse sviluppa il suo gateway a partire da questa idea. Secondo la documentazione del gateway, ogni chiave del gateway appartiene a un utente o a un account di servizio e può includere metadati, come il team o il centro di costo. Solo il gateway custodisce le credenziali del provider e gli amministratori approvano i modelli che ciascuna credenziale può chiamare. LangSmith pubblica pagine di configurazione per instradare Claude Code, Codex e Gemini CLI attraverso il suo gateway. Questi agenti chiamano i modelli dal computer dello sviluppatore, al di fuori del codice di tracciamento di qualsiasi applicazione.

Cosa aggiunge il gateway di uno strumento di tracciamento

Anche i fornitori di strumenti di tracciamento sostengono il contrario: un gateway autonomo non basta. Nel suo post di lancio, Langfuse afferma che un gateway autonomo può soltanto conteggiare i token e i costi, mentre il suo gateway integra ogni chiamata in una traccia completa. Il gateway di Langfuse accetta un’intestazione W3C traceparent, così una chiamata che lo attraversa si unisce alla traccia già avviata dall’applicazione. Per impostazione predefinita, registra l’utilizzo e i costi, non il contenuto dei prompt e delle risposte.

Questo è l’argomento tecnico più convincente a favore dell’integrazione del gateway nello strumento di tracciamento. Un gateway autonomo vede un elenco piatto di completamenti. Uno strumento di tracciamento dispone già delle chiamate agli strumenti e delle fasi di recupero dell’agente, registrate dal suo SDK, e può inserire ogni chiamata al gateway all’interno di quella struttura.

C’è anche una lettura commerciale, che i fornitori non esplicitano. Chi gestisce il gateway detiene le chiavi dei provider e il report della spesa, che è ciò che consultano i team finanziari e di piattaforma. Per questo è più difficile sostituire un gateway che un visualizzatore di tracce. LangSmith e Langfuse sfruttano già questa posizione in modo diverso: LangSmith vende Gateway Credits, che consentono ai clienti di usare modelli ospitati come Kimi senza una propria chiave del provider, mentre le FAQ di Langfuse affermano che non rivende token.

Cosa non possono ancora fare i gateway in versione beta

Questi gateway sono ancora agli inizi e i fornitori documentano le lacune dei propri prodotti. Al momento, il gateway di Langfuse supporta solo OpenAI e Anthropic; Amazon Bedrock, Google Vertex AI e Google AI Studio figurano nella sua roadmap. Sono previsti, ma non ancora disponibili, il passaggio automatico da un provider a un altro e limiti rigidi di spesa per team, utente o chiave. Per ora, il gateway offre una dashboard della spesa e avvisi. La documentazione non descrive limiti di frequenza né la memorizzazione nella cache delle risposte.

Il gateway di Langfuse non converte i formati API, quindi un client OpenAI può chiamare solo modelli OpenAI. La versione installata autonomamente chiama esclusivamente gli URL ufficiali dei provider, escludendo per ora Azure OpenAI, Bedrock e i proxy interni. Comet descrive il gateway Opik come progettato per lo sviluppo e i test. Braintrust non ha annunciato i prezzi del proprio gateway.

Il gateway di LangSmith offre già più funzionalità degli altri. La documentazione indica come funzionalità già disponibili il passaggio automatico da un provider a un altro, i limiti di spesa, i limiti di frequenza e le policy sui dati; inoltre, supporta i formati OpenAI Chat Completions, OpenAI Responses e Anthropic Messages. A maggio, il passaggio automatico da un provider a un altro e i limiti di frequenza erano indicati come sviluppi futuri: sono quindi stati introdotti durante la beta. Il prodotto nel suo complesso è ancora contrassegnato come beta.

I test di carico rivelano un altro tipo di lacuna. Un benchmark eseguito autonomamente sul gateway di Langfuse, LiteLLM e AcruxCore ha rilevato che il gateway di Langfuse aggiungeva meno latenza per chiamata rispetto a LiteLLM. Tuttavia, con le impostazioni Docker predefinite, ha fallito 739 dei 1.000 flussi simultanei, perché il suo processo manteneva il limite predefinito di Docker di 1.024 file aperti. È bastata una riga nel file Compose di Langfuse per risolvere il problema.

Rispetto a queste versioni beta, LiteLLM, un gateway autonomo da anni, supporta più di 100 provider e include già chiavi virtuali, monitoraggio della spesa, misure di protezione, bilanciamento del carico e una dashboard di amministrazione. LiteLLM sta anche trasferendo da Python a Rust il percorso delle richieste. Il suo gateway AI in Rust è in beta e il team di LiteLLM prevede che le richieste /v1/messages in stile Anthropic vengano gestite interamente in Rust entro il 1° dicembre, con una latenza circa 20 volte inferiore. Alcune piattaforme open source, come MLflow e AcruxCore, offrono già gateway e tracciamento in un unico prodotto.

Perché mantenerli separati

Integrare il gateway nel sistema di tracciamento comporta dei costi, e il principale è il maggiore accoppiamento. Con un gateway separato, un team può cambiare fornitore del sistema di tracciamento modificando una callback di logging. Se il sistema di tracciamento è anche il gateway, cambiano anche l’URL di base, le chiavi e gli identificatori dei modelli di ogni servizio. Langfuse, per esempio, scrive gli identificatori dei modelli nel formato credenziale:modello.

Il sistema di tracciamento diventa anche una dipendenza in fase di esecuzione. Se un backend di tracciamento non è disponibile, il team perde le tracce. Se non è disponibile un gateway, le chiamate ai modelli falliscono. Un fornitore di sistemi di tracciamento che gestisce il gateway deve ora garantire la disponibilità richiesta da un’infrastruttura critica.

Anche i fornitori di soluzioni di sicurezza vogliono occupare la stessa posizione nel percorso delle richieste. A maggio 2026, Palo Alto Networks ha completato l’acquisizione di Portkey, un gateway autonomo, e lo ha trasformato nel gateway AI della propria piattaforma Prisma AIRS. Un team di sicurezza potrebbe voler mantenere il gateway sotto il proprio controllo anziché integrato in uno strumento di osservabilità. I gateway sono diventati anche un bersaglio per gli aggressori, come ha dimostrato a marzo la violazione della catena di fornitura di LiteLLM.

Come scegliere

I team possono iniziare elencando ciò che deve avvenire prima di una chiamata a un modello. Se hanno bisogno solo di visibilità, è sufficiente affiancare un sistema di tracciamento al percorso delle richieste, senza aggiungere dipendenze in fase di esecuzione. Se servono anche budget, policy per le chiavi o approvazione dei modelli, occorre un gateway di qualche tipo.

Il passo successivo è valutare la copertura dei provider. Un team dovrebbe annotare ogni provider e formato API utilizzato in produzione, inclusi Azure OpenAI e Bedrock, e confrontare l’elenco con il supporto attuale di ciascun gateway, anziché con la relativa roadmap.

I team che utilizzano già LiteLLM hanno pochi motivi per passare a un altro prodotto finché un gateway in beta non offre qualcosa che manca loro. Il principale valore aggiunto del gateway di un sistema di tracciamento è l’inserimento della chiamata al gateway nella traccia dell’agente, e questo deve giustificare la migrazione. I team che partono da zero possono mantenere il gateway come livello separato anche se un unico fornitore offre entrambi i prodotti. Tenere l’URL di base e le chiavi in un unico modulo di configurazione permette di passare in seguito a un altro prodotto modificando la configurazione, anziché il codice.

La maggior parte di questi gateway è contrassegnata come beta o anteprima, quindi l’elenco delle lacune si ridurrà rapidamente. La questione aperta è chi controllerà il percorso delle richieste in un’azienda tipica: il team di osservabilità, il team di piattaforma che gestisce un gateway autonomo o il team di sicurezza. Quest’anno LangSmith e Langfuse hanno creato gateway propri e Palo Alto Networks ne ha acquistato uno; eppure, in molti stack, il percorso delle richieste passa ancora da LiteLLM.