AI Gateway: perché le piattaforme AI hanno bisogno di un nuovo livello di controllo

Le trattative tra Stripe e OpenRouter, riportate dal Wall Street Journal e arrivate a una possibile valutazione di circa 10 miliardi di dollari, danno agli AI Gateway una rilevanza che supera il perimetro degli architetti software. OpenRouter non sviluppa modelli propri: offre un punto di accesso unificato a centinaia di modelli di provider diversi, permettendo di confrontarli, instradare le richieste e gestire costi e disponibilità.

La possibile valutazione di OpenRouter mostra dove si concentra una parte del valore: nella capacità di scegliere, instradare, controllare e misurare l’uso di molti modelli diversi. L’AI Gateway assume così un ruolo da componente dell’architettura enterprise.

La complessità si sposta dal modello all’ecosistema che lo circonda: provider differenti, modelli specializzati, servizi distribuiti e politiche di sicurezza sempre più articolate.

Il precedente storico sono gli API Gateway. Quando il numero di API e microservizi aumentò oltre una certa soglia, l’integrazione diretta tra applicazioni e backend smise di essere sostenibile. Servì un livello incaricato di centralizzare autenticazione, instradamento, monitoraggio e applicazione delle policy.

L’AI Gateway applica questa logica al traffico AI: centralizzare funzioni che diventano ingestibili se restano replicate in ogni applicazione.

Quando l’integrazione diretta non basta più

Nelle prime sperimentazioni con l’intelligenza artificiale generativa, l’integrazione diretta con il provider era spesso sufficiente. Un’applicazione chiamava l’API di un modello, inviava un prompt, riceveva una risposta e la incorporava nel proprio flusso. Uno schema adatto alla prototipazione e alle prime applicazioni interne.

In produzione il quadro cambia. Una stessa applicazione può utilizzare un large language model per la generazione dei testi, un modello dedicato agli embedding per la ricerca semantica, servizi di riconoscimento vocale, modelli di computer vision, sistemi di reasoning e modelli eseguiti localmente per motivi di costo, latenza o riservatezza dei dati. A questi componenti si aggiungono strumenti esterni, basi di conoscenza, servizi aziendali e, sempre più spesso, altri agenti AI. L’introduzione di protocolli come Model Context Protocol (MCP) e le prime implementazioni di comunicazione agent-to-agent (A2A) amplia ulteriormente il numero di elementi coinvolti nell’esecuzione di una singola richiesta.

Questo schema mostra rapidamente i propri limiti. Ogni nuova applicazione tende a replicare gli stessi problemi: dove conservare le chiavi API, come ruotarle, come misurare i costi, come gestire gli errori, come instradare le richieste verso un modello alternativo, come impedire l’invio di dati sensibili, come applicare policy coerenti tra team diversi.

Ne deriva una frammentazione architetturale. Ogni gruppo di sviluppo implementa il proprio wrapper, il proprio sistema di retry, il proprio logging, il proprio modo di gestire i provider. Utile all’inizio; su scala enterprise diventa un problema di controllo.

L’AI Gateway interviene su questo livello. Il suo ruolo è governare molte chiamate a molti modelli, provenienti da molte applicazioni, con requisiti diversi di sicurezza, costo, latenza, qualità e conformità.

Negli ultimi mesi numerosi fornitori hanno introdotto componenti dedicati alla gestione dell’accesso ai modelli AI. Kong ha esteso la propria piattaforma con AI Gateway, Cloudflare propone un servizio omonimo per controllare traffico, osservabilità, caching e rate limiting, IBM integra un Model Gateway nell’ecosistema watsonx, mentre progetti come LiteLLM, Portkey e OpenRouter offrono livelli di astrazione per unificare l’accesso a provider e modelli differenti.

La terminologia resta instabile. Oltre ad AI Gateway compaiono definizioni come LLM Gateway, Model Gateway, AI Proxy, Inference Gateway e, più recentemente, Agent Gateway. Nomi diversi, stessa funzione architetturale: separare le applicazioni dalla crescente complessità dell’ecosistema AI.

Le funzioni che stanno convergendo

Le implementazioni oggi disponibili convergono su alcune funzioni ricorrenti.

Astrazione dei provider. Un gateway espone alle applicazioni un’interfaccia uniforme, spesso compatibile con le API OpenAI, e traduce poi le richieste verso provider differenti. È l’approccio adottato, con modalità diverse, da progetti come LiteLLM, Portkey, MLflow AI Gateway e IBM watsonx Model Gateway. Per gli sviluppatori significa poter cambiare modello o provider senza modificare continuamente il codice applicativo.

Credenziali. Il gateway custodisce e richiama chiavi e token, riducendone la dispersione tra applicazioni, ambienti e team. IBM collega il Model Gateway alla gestione sicura dei secret della piattaforma watsonx; Kong presenta l’AI Gateway anche come un modo per evitare che le credenziali siano incorporate nelle singole applicazioni.

Routing e fallback. In uno scenario multi-modello, il gateway decide il percorso delle richieste. Alcune possono essere inviate a un modello più economico, altre richiedono un modello più potente, altre ancora devono restare su un’infrastruttura locale per ragioni di riservatezza. Il routing può essere statico, basato su regole, oppure più dinamico, legato a costo, disponibilità, latenza o qualità attesa.

Osservabilità e accounting. Un’azienda deve sapere quali applicazioni usano quali modelli, quanti token consumano, quali errori generano, quali latenze introducono e quanto costano. Cloudflare, Kong, Portkey e MLflow AI Gateway insistono molto su questo punto: senza un livello comune di logging e accounting, l’uso dell’AI resta difficile da misurare.

Policy e guardrail. Sul gateway possono concentrarsi rate limiting basato sui token, filtri sui prompt, regole di sicurezza, guardrail, controlli sui dati sensibili e meccanismi di audit. Kong parla di prompt guard, prompt template, semantic prompt guard e metriche specifiche per il traffico AI; Gravitee estende il discorso a LLM, MCP e A2A, proponendo un unico runtime di controllo per interazioni tra modelli, strumenti e agenti.

Con queste funzioni l’AI Gateway assume il ruolo di componente infrastrutturale: un punto in cui l’organizzazione può decidere come l’intelligenza artificiale viene consumata dalle applicazioni.

Le sfide ancora aperte

La nascita di un nuovo livello architetturale non elimina automaticamente la complessità. In alcuni casi la sposta.

Smart routing. Scegliere automaticamente il modello migliore per ogni richiesta è un obiettivo attraente, ma difficile. Per decidere se una richiesta richiede un modello economico, un modello di reasoning o un modello specializzato, il gateway deve interpretare il contenuto, stimarne la difficoltà, prevedere costi e latenza e valutare il rischio di errore. Più il routing diventa intelligente, più il gateway stesso assomiglia a un componente decisionale.

Prompt cache. Molti provider ottimizzano i costi attraverso meccanismi di prompt caching o caching del contesto. Un routing troppo aggressivo tra modelli diversi può ridurre questi benefici: risparmiare scegliendo un provider più economico può non convenire se si perde la cache già costruita altrove. Per questo la scelta del modello non può essere valutata solo sul prezzo nominale per token.

Semantic caching. Riutilizzare risposte già generate per richieste semanticamente simili può ridurre costi e latenze, ma solleva domande delicate: quanto devono essere simili due richieste per condividere una risposta? Come evitare risposte non aggiornate? Come impedire che informazioni sensibili vengano riutilizzate nel contesto sbagliato?

Affidabilità. Un gateway aumenta controllo e visibilità, ma può diventare un nuovo single point of failure. Se tutte le applicazioni AI passano da quel livello, la sua disponibilità diventa critica. Servono architetture ridondate, policy di fallback, osservabilità interna e una gestione molto attenta della resilienza.

Sicurezza. Centralizzare credenziali e policy riduce la dispersione, ma aumenta il valore del componente da proteggere. Un AI Gateway diventa un punto sensibile dell’architettura: contiene chiavi, policy, log, informazioni sui consumi e potenzialmente dati contenuti nei prompt. L’estensione di CrowdStrike Falcon AIDR agli AI gateway conferma che il gateway entra nella superficie di sicurezza dell’AI enterprise. Per questo non può essere trattato come un semplice middleware applicativo.

Come si forma il mercato degli AI Gateway

Il mercato degli AI Gateway nasce da più direzioni. Aziende provenienti da mondi diversi affrontano lo stesso problema: controllare il traffico AI prima che diventi troppo frammentato.

API Management e application delivery. Vendor come Kong, Gravitee, Google Apigee, Azure API Management e F5 partono da un’esperienza consolidata nella gestione di API, traffico applicativo, sicurezza e delivery. L’AI Gateway estende questo modello al traffico AI: autenticazione, policy, osservabilità, rate limiting e protezione del traffico, adattati alle caratteristiche dell’intelligenza artificiale.

AI Platform e model access. In questo approccio il gateway è spesso una funzione integrata nella piattaforma. IBM watsonx Model Gateway, ad esempio, offre un’interfaccia compatibile con OpenAI per accedere a modelli di provider differenti, gestendo credenziali, policy e load balancing. In ambito AWS, la stessa esigenza è descritta come gateway pattern per l’accesso centralizzato a Bedrock, SageMaker e provider esterni. Il gateway rende controllabile l’uso dei modelli all’interno di un ambiente enterprise più ampio.

Open source, developer tooling e broker di modelli. Progetti come LiteLLM e Portkey puntano sull’unificazione dell’accesso ai provider: un’unica API, fallback, routing, caching, budget, rate limit e supporto a molti modelli. OpenRouter aggiunge una dimensione di mercato: astrazione tecnica, confronto tra modelli, costi, disponibilità e canali di accesso. Strumenti nati spesso per risolvere problemi pratici degli sviluppatori stanno incorporando funzioni tipiche della governance enterprise.

Agent gateway. Solo.io agentgateway e Gravitee spingono il concetto oltre il traffico verso gli LLM, includendo protocolli come MCP e A2A, tool, agenti, autorizzazioni e tracciamento delle chiamate. L’AI Gateway diventa il possibile piano di controllo delle interazioni tra modelli, strumenti e agenti.

La categoria resta instabile: non esiste un nome unico, non esiste un perimetro condiviso e non tutti i prodotti risolvono lo stesso insieme di problemi. L’accesso ai modelli AI viene progressivamente separato dalle applicazioni e concentrato in un livello specializzato.

Verso il control plane dell’intelligenza artificiale

Gli AI Gateway potrebbero diventare una categoria autonoma oppure essere assorbiti da piattaforme più ampie.

Le prime implementazioni rispondevano a un problema semplice: usare più provider senza riscrivere le applicazioni. Le versioni successive hanno aggiunto governance, costi, sicurezza e osservabilità. Ora il perimetro si allarga verso agenti, tool e protocolli di interoperabilità.

Il riferimento architetturale è il control plane. In un’infrastruttura cloud-native, il control plane governa configurazione, policy, stato e comportamento dei workload. Un AI Gateway evoluto potrebbe svolgere una funzione analoga per i servizi AI: definire quali modelli possono essere usati, da quali applicazioni, con quali dati, entro quali limiti di costo, con quali guardrail e con quale tracciabilità.

Con gli agenti il tema diventa più rilevante. Un sistema agentico non si limita a inviare una richiesta a un modello. Può chiamare strumenti, interrogare API, accedere a dati aziendali, delegare compiti ad altri agenti e mantenere uno stato nel tempo. Ogni passaggio richiede identità, autorizzazione, audit, controllo dei costi e sicurezza.

Alcuni vendor spostano già l’attenzione dal semplice LLM Gateway a un gateway capace di comprendere traffico LLM, MCP e A2A. Il gateway controlla l’intera catena di interazioni che compone un’operazione AI.

Non è detto che il nome “AI Gateway” resterà quello definitivo. Parte di queste funzioni potrebbe essere assorbita dagli API Gateway tradizionali, dalle piattaforme AI, dai service mesh o dagli strumenti di gestione degli agenti.

Quando le applicazioni usano molti modelli, molti provider e molti strumenti, serve un livello che renda questo accesso governabile, osservabile e sostituibile. Che continui a chiamarsi AI Gateway o venga incorporato in altre piattaforme, sarà una delle componenti da considerare nella progettazione delle architetture AI enterprise.