Che cos'è un AI gateway?
Un AI gateway è un unico punto d'ingresso condiviso tra le vostre applicazioni e i modelli di IA che usano — OpenAI, Anthropic, Mistral, oppure modelli che gestite voi. Invece di far custodire a ogni applicazione le proprie chiavi e prendere le proprie decisioni, ogni richiesta passa da un solo punto, dove accessi, costi, regole sui dati e registro di ciò che è accaduto vengono gestiti una volta sola, per tutti.
Le stesse tre applicazioni, in due scenari
Senza gateway
- Ogni applicazione custodisce le proprie chiavi dei provider — e ognuna è un punto in cui una chiave può trapelare.
- Ogni team costruisce i propri tentativi di ripetizione, limiti e log, ciascuno in modo un po' diverso.
- La spesa arriva come una fattura per provider, senza una riga per il team o la funzione che l'ha causata.
- Aggiungere o cambiare provider significa modificare il codice di ogni applicazione.
Con un gateway
- Le chiavi dei provider stanno in un solo posto. Le applicazioni ricevono chiavi gateway proprie, revocabili senza toccare il provider.
- Tentativi di ripetizione, failover e cache avvengono una volta sola, allo stesso modo, per ogni applicazione.
- Ogni richiesta viene attribuita a un team, a un'applicazione e a un utente nel momento in cui avviene.
- I modelli si aggiungono o si sostituiscono dalla configurazione. Il codice delle applicazioni non cambia.
Cinque cose accadono a ogni richiesta
I dettagli cambiano da prodotto a prodotto, ma lo schema è lo stesso: prima i controlli, al centro la chiamata al modello, alla fine il registro. Una richiesta che non supera un controllo si ferma prima che qualcuno paghi per essa.
- Verifica chi sta chiedendo. L'applicazione presenta la propria chiave gateway, oppure l'accesso aziendale di un utente. I chiamanti sconosciuti vengono rifiutati. ✗ rifiutata
- Verifica i limiti. Questo team è entro il proprio budget e il proprio limite di frequenza? In caso contrario la richiesta si ferma qui — prima di contattare il provider. ✗ budget superato
- Applica le regole. Le regole valide per tutta l'organizzazione agiscono sul prompt — ad esempio mascherare i dati personali, oppure impedire che escano verso un provider esterno. ✗ bloccata · ◑ mascherata
- Sceglie un modello e lo chiama. Il gateway decide quale provider e quale modello servono la richiesta, e passa al successivo se un provider è lento o non risponde.
- Registra cosa è successo. Chi ha chiesto, quale modello ha risposto, quanto è costato e quali regole sono state applicate — annotato per ogni richiesta, non ricostruito a posteriori.
Questa è la versione semplificata. Il percorso completo della richiesta in Wäg ha nove fasi, tra cui la cache e la policy sulle chiamate a strumenti degli agenti: il percorso della richiesta, fase per fase.
Di solito si parte da uno di questi motivi
Nessuno compra un gateway perché la categoria esiste. Lo compra perché è successa una delle cose di questo elenco.
| Cosa notate | Cosa fa un gateway | Approfondisci |
|---|---|---|
| La fattura dell'IA è raddoppiata e nessuno sa dire quale team l'abbia causato. | Attribuisce il costo di ogni richiesta a un team, a un'applicazione e a un utente, e blocca la spesa a un limite che stabilite voi. | Costi e budget |
| Le chiavi dei provider sono incollate in una dozzina di file di configurazione e segreti della CI. | Custodisce le chiavi dei provider in un solo posto. Le applicazioni ricevono chiavi gateway che potete limitare, ruotare e revocare. | Postura di sicurezza |
| Un'interruzione di un provider ha messo fuori uso una funzione rivolta ai clienti. | Ripete la richiesta e passa automaticamente a un altro provider o modello. | Routing e failover |
| Qualcuno ha chiesto se i dati dei clienti vengano inviati a un modello esterno, e nessuno lo sapeva. | Applica regole sui dati a ogni prompt — maschera, oscura o blocca — prima che esca. | Policy e guardrail |
| Ogni team ha scelto il proprio modello, e quasi tutti usano per abitudine il più costoso. | Instrada ogni richiesta al modello più economico in grado di gestirla, in base a una policy e non all'abitudine. | Routing intelligente |
| Un revisore, un cliente o il Regolamento europeo sull'IA chiede cosa abbiano fatto davvero i vostri sistemi di IA. | Conserva il registro di ogni richiesta: chi ha chiesto, quale modello ha risposto, quanto è costato, quali regole sono state applicate. | Regolamento europeo sull'IA e registrazione |
| Gli agenti ora chiamano strumenti e sistemi interni con credenziali reali. | Fa passare le chiamate agli strumenti degli agenti per la stessa identità, policy e registro delle chiamate ai modelli. Non tutti i gateway lo fanno — chiedete. | Governance degli agenti |
Di solito una riga
La maggior parte dei gateway parla l'API OpenAI, che quasi ogni SDK e framework di IA già supporta. Adottarne uno significa cambiare l'indirizzo a cui l'applicazione invia le richieste e la chiave con cui le invia.
client = OpenAI(
- base_url="https://api.openai.com/v1",
- api_key=os.environ["OPENAI_API_KEY"],
+ base_url="https://ai-gateway.internal/v1",
+ api_key=os.environ["GATEWAY_KEY"],
)Prompt, SDK e gestione delle risposte restano invariati. Un buon gateway traduce anche per i provider con un'API diversa, come Anthropic o Gemini, così l'applicazione non deve mai sapere quale provider ha risposto.
La decisione che molti non sanno di prendere
Un gateway vede ogni prompt e ogni risposta che lo attraversa. Perciò la prima domanda non è quali funzioni abbia, ma sull'infrastruttura di chi giri.
| Domanda | Gestito da terzi — lo fa girare un fornitore | Autogestito — lo fate girare voi |
|---|---|---|
| Dove vanno prompt e risposte | Attraverso la rete e i sistemi del fornitore, sulla strada verso il provider | In nessun posto nuovo — restano nella vostra infrastruttura finché non raggiungono il provider che avete scelto |
| Chi custodisce le chiavi dei provider | Il fornitore | Voi |
| Tempo alla prima richiesta | Minuti — ci si registra e si cambia l'URL di base | Più lungo — prima va installato |
| Chi lo mantiene in funzione | Il fornitore | Il vostro team, di solito il team di piattaforma |
| È la scelta giusta quando | La rapidità conta più di tutto e i dati non sono sensibili | Protezione dei dati, normativa o regole di acquisto escludono una terza parte nel percorso della richiesta |
Non sempre
Avete una sola applicazione, un solo provider e un solo team, e nessuno fuori dall'ingegneria chiede conto della spesa o dei dati dell'IA. Chiamare direttamente il provider è più semplice, e la semplicità è un pregio. Tornate quando le cose cambiano.
Iniziate a valutarlo quando accade una di queste cose:
- Arriva un secondo team, o un secondo provider.
- Qualcuno chiede quanto costa l'IA per team o per prodotto, e rispondere richiede una settimana.
- La protezione dei dati o la sicurezza chiedono dove vanno i prompt.
- Un'interruzione di un provider diventa un'interruzione vostra.
- Gli agenti iniziano ad agire sui vostri sistemi con credenziali reali.
Quando un gateway non basta
Un gateway governa le applicazioni che scelgono di puntarvi. Quando l'IA diventa un'infrastruttura condivisa — molti team, agenti con autorità reale, revisori che fanno domande — la questione passa da come si inoltrano le richieste a chi decide cosa una richiesta può essere, per l'intera organizzazione. È questo il confine tra un AI gateway e una AI control plane.
Un AI gateway che gestite voi
Wäg è un AI gateway open source che gira interamente nella vostra infrastruttura: nessuna versione ospitata, nessun fornitore nel percorso della richiesta, nessuna chiamata verso l'esterno. Parla l'API OpenAI, si collega a più di 25 provider compatibili con OpenAI più Anthropic e Gemini in modo nativo, e aggiunge il livello di control plane — identità, budget gerarchici, policy, governance degli agenti e audit — nello stesso percorso della richiesta. Apache-2.0, scritto in Rust.
Usate già LiteLLM o un altro gateway? Wäg importa la configurazione di LiteLLM, e la guida alla migrazione spiega come far girare entrambi in parallelo prima di passare.
Cosa si chiede per prima cosa
Un AI gateway è lo stesso che un proxy LLM?
In gran parte sì. Proxy LLM, proxy IA, gateway LLM e AI gateway descrivono tutti un unico endpoint davanti a più provider di modelli. Gateway di solito suggerisce qualcosa in più dell'inoltro — chiavi, limiti, regole e un registro — ma i termini non sono usati in modo coerente, quindi verificate cosa un prodotto applica davvero, non come si chiama.
In cosa si distingue da un API gateway?
Un API gateway gestisce le richieste: instradamento, autenticazione e limiti di frequenza per ogni chiamata. Un AI gateway capisce anche cosa c'è dentro una richiesta a un modello — token, prezzo per modello, risposte in streaming, prompt che possono contenere dati personali, provider che possono sostituirsi a vicenda. Alcuni API gateway ora aggiungono funzioni di IA; la domanda utile è se contano token e costi, o soltanto richieste.
Devo modificare il codice della mia applicazione?
Di solito solo l'URL di base e la chiave, a condizione che il gateway parli l'API OpenAI e che la vostra applicazione usi un SDK o un framework compatibile con OpenAI — come fanno quasi tutte.
Rallenta le richieste?
Aggiunge un passaggio di rete, quindi un po' di tempo lo aggiunge. Un gateway ben fatto aggiunge millisecondi, a fronte di risposte dei modelli che richiedono da centinaia di millisecondi a diversi secondi, e un riscontro nella cache può rendere una richiesta molto più rapida che chiamare il provider. Chiedete a qualsiasi fornitore l'overhead misurato con log e budget attivi, non disattivati.
Non è un singolo punto di guasto?
Solo se gira come istanza singola. I gateway in produzione girano come più istanze senza stato dietro un bilanciatore di carico, e il failover tra provider di norma elimina più interruzioni di quante ne aggiunga il gateway.
Il fornitore del gateway vede i miei prompt?
Con un gateway gestito da terzi, sì: prompt e risposte passano dai sistemi del fornitore. Con un gateway autogestito, il fornitore non è affatto nel percorso della richiesta — il software gira nella vostra infrastruttura e parla solo con i provider che configurate.
Può instradare verso modelli che ospitiamo noi?
Sì, se quei modelli espongono un'API compatibile con OpenAI, come fanno vLLM, Ollama e la maggior parte dei server di inferenza. Il gateway li tratta come qualsiasi altro provider, così modelli on-premise e cloud stanno dietro lo stesso endpoint e le stesse regole. Per i modelli sui computer dei dipendenti o dentro le app mobili, Wäg Edge registra le chiamate locali e le riporta al gateway.
Un endpoint. Tutti i modelli. Controllo completo.
Gestitelo nella vostra infrastruttura
Tutto ciò che serve per gestire una control plane in produzione è sotto Apache-2.0 e lo resterà — routing, alta disponibilità, cache, failover, budget, policy, MCP, job e osservabilità. Self-hosted, senza account, senza chiamate verso l'esterno.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>Non è un pull funzionante: le immagini non sono ancora pubbliche. I partner di progettazione ricevono i dettagli del registry in forma privata.
Avvia in 5 minutiContribuite come design partner
Wäg non è ancora disponibile pubblicamente. Lavoriamo con un piccolo gruppo di team che gestiscono IA multi-provider in produzione e prendono sul serio governance e sovranità, per irrobustire la control plane su carichi reali.
- Tutte le funzioni Enterprise incluse, senza costi di licenza
- Migrazione assistita — la facciamo insieme a voi, anche da LiteLLM
- Una linea diretta con gli ingegneri e un'influenza reale su ciò che arriva dopo