Wat is een AI-gateway? Een gids voor routering, kostenbeheersing en governance van LLM- en agentverkeer

Een AI-gateway is een centrale proxylaag tussen je applicaties of AI-agents en de grote taalmodellen (LLM's) en tools die ze aanroepen. De gateway routeert verzoeken, houdt AI-kosten onder controle, dwingt beveiliging af en monitort het gebruik, zodat je die maatregelen niet in elke applicatie afzonderlijk hoeft in te bouwen. Dat zou al snel onwerkbaar worden naarmate je teams meer modellen koppelen en meer agents inzetten.

Hier lees je wat een AI-gateway doet, hoe die verschilt van een traditionele API-gateway (en van LLM- en MCP-gateways), wat de mogelijkheden en beperkingen zijn en hoe je bepaalt of je er een nodig hebt.

Wat is een AI-gateway?

Een AI-gateway is een tussenlaag die elke aanroep van je applicatie of AI-agent naar een groot taalmodel (LLM) routeert.

Dankzij deze laag kun je veel verschillende modellen benaderen alsof het één model is.

Elke provider (OpenAI, Anthropic, Google, een opensourcemodel of je eigen zelfgehoste endpoint) heeft een eigen SDK, eigen API-sleutels en een eigen verzoekformaat. De gateway accepteert één standaardverzoek, vertaalt het voor de provider die je aanroept en stuurt het antwoord terug.

Je voegt modellen toe, vervangt ze of faseert ze uit door de gatewayconfiguratie aan te passen in plaats van de applicatiecode.

En omdat elk verzoek via de AI-gateway loopt, kun je voor alle modellen op één plek regels voor kosten, beveiliging en logging toepassen.

Hoe een AI-gateway werkt

Wanneer je je applicatie of AI-agent naar de basis-URL van de AI-gateway laat verwijzen, doorloopt elk verzoek dezelfde reeks stappen:

• Authenticeren en autoriseren: De gateway controleert de sleutel en de rol van de aanroeper.
• Beleid toepassen: De gateway handhaaft tokenlimieten en budgetten en voert guardrails uit, zoals het maskeren van PII.
• Routeren: De gateway kiest het model of de provider op basis van kosten, latentie of beschikbaarheid en schakelt over naar een back-up als de eerste keuze niet beschikbaar is. Ook vertaalt de gateway het verzoek naar het formaat van de beoogde provider.
• Loggen: De gateway registreert het model, het aantal tokens, de latentie en het resultaat, zodat je AI-uitgaven kunt bijhouden en problemen kunt debuggen.

Een verzoek dat anders rechtstreeks naar een AI-provider zou zijn gegaan, loopt nu dus via de gateway. Die kan het aantal tokens begrenzen, een goedkoper model inzetten of een antwoord uit de cache teruggeven voordat het verzoek een LLM bereikt.

Mogelijkheden van een AI-gateway

Een AI-gateway routeert modelverkeer, beheerst de kosten, beveiligt en logt het verkeer en bepaalt wie wat mag gebruiken.

Vergroten

Routering en failover

De AI-gateway kiest welk AI-model elk verzoek afhandelt, op basis van kosten, latentie of mogelijkheden.

Als de gekozen provider niet beschikbaar is of een rate limit hanteert, stuurt de gateway het verzoek automatisch naar een ander model.

Zo blijft je applicatie werken tijdens een storing en kun je de belasting over meerdere providers tegelijk verdelen.

Op tokens gebaseerde rate limits en budgetten

Met de AI-gateway kun je limieten per team, project of gebruiker instellen. Zodra de toegewezen tokenlimiet is bereikt, weigert de gateway verdere verzoeken.

Zo blijven de uitgaven binnen het budget en kan geen enkel team of project het budget in zijn eentje opmaken.

Semantische caching

De semantische caches van AI-gateways slaan eerdere antwoorden op en vergelijken nieuwe prompts op basis van hun betekenis. Als een nieuwe prompt voldoende lijkt op een prompt die de gateway al heeft beantwoord, geeft de gateway het opgeslagen antwoord terug zonder het model aan te roepen.

Bij AI-workloads met veel vergelijkbare verzoeken verlaagt dit de kosten en de responstijd.

Guardrails en gegevensbescherming

De AI-gateway inspecteert elke prompt en elk antwoord dat erdoorheen gaat.

De gateway verwijdert persoonlijke of gevoelige gegevens voordat het verzoek de modelprovider bereikt, verkleint het risico op promptinjecties en filtert content die je niet wilt verzenden of ontvangen.

De controles gelden voor elk verzoek, zodat de bescherming niet afhangt van de vraag of elke AI-applicatie het zelf goed regelt.

Observability

De AI-gateway registreert elk verzoek: welk model werd gebruikt, hoeveel tokens het verbruikte, hoe lang het duurde en of het mislukte.

Met dat overzicht van elke AI-interactie kun je kosten aan een team toewijzen, een traag of falend model debuggen en het gebruik bij alle providers inzien.

AI-governance en toegangsbeheer

De AI-gateway beheert de toegang tot AI binnen je hele organisatie. De gateway verleent toegang tot modellen volgens je rolinstellingen, authenticeert alle aanroepers en legt elke aanroep vast in een auditlogboek, zodat je het AI-gebruik kunt controleren.

De beperkingen van een AI-gateway: latentie en wat de gateway niet doet

Een AI-gateway voegt een beetje latentie toe. En de gateway beoordeelt de kwaliteit van de output niet; dat blijft jouw verantwoordelijkheid.

Hoeveel latentie een gateway toevoegt

Een AI-gateway voegt latentie toe, oftewel de vertraging tussen het verzenden van een verzoek en het ontvangen van een antwoord, maar voor LLM-verkeer is die relatief klein.

In een onafhankelijke benchmark van het VMware Cloud Foundation-team van Broadcom uit juni 2026 voegde een geoptimaliseerde Envoy AI Gateway ongeveer 2 ms per verzoek toe bij maximaal 224 gelijktijdige gebruikers, met routering en rate limiting maar zonder inhoudsinspectie (guardrails en semantische caching kunnen tientallen tot honderden milliseconden toevoegen).

Een AI-gateway heeft geen invloed op de kwaliteit van de prompt of de output

Een AI-gateway regelt het verkeer, niet de output van het model of de applicatielogica eromheen.

AI-gateways bepalen niet wat er aan een model wordt gevraagd, onthouden je gesprek niet en weten niet waar een taak was gebleven, en ze voeren de stapsgewijze logica van een agent niet uit.

En ze beoordelen de kwaliteit van het antwoord niet. Ze kunnen dus niet garanderen dat een antwoord juist of veilig is.

Het implementeren van een AI-gateway kan onder bepaalde omstandigheden zelfs de kwaliteit verlagen. Als de gateway een verzoek bijvoorbeeld naar een goedkoper model routeert om kosten te besparen, kan dat model een slechter antwoord geven.

Het controleren van de outputkwaliteit blijft dus jouw taak.

AI-gateway vs. API-gateway

Een AI-gateway en een API-gateway werken op een vergelijkbare manier, maar regelen verschillende soorten verkeer. Een API-gateway verwerkt algemene API-aanroepen (REST of GraphQL tussen je clients en backendservices), waarbij elk verzoek voorspelbaar is. Een AI-gateway verwerkt aanroepen naar een taalmodel, die in tokens worden gemeten en vrij geformuleerde prompts bevatten.

Dit zijn de belangrijkste verschillen tussen AI-gateways en API-gateways:

• Een API-gateway routeert verzoeken naar een backendservice, terwijl een AI-gateway ze naar LLM's routeert.
• Een API-gateway beperkt hoeveel verzoeken je doet en meet de bandbreedte, terwijl een AI-gateway tokens meet. Het aantal toolverzoeken is irrelevant voor het bijhouden van het gebruik van AI-modellen, omdat één aanroep een paar tokens of honderdduizenden tokens kan verbruiken.
• Een API-gateway levert alleen bij een exacte overeenkomst een antwoord uit de cache, terwijl een AI-gateway ook op betekenis kan cachen en een opgeslagen antwoord kan teruggeven wanneer een nieuwe prompt voldoende lijkt op een eerdere. Prompts zijn zelden identiek, dus zonder deze functie zou je voor modelaanroepen betalen om steeds weer dezelfde vragen te beantwoorden.
• Een API-gateway authenticeert alleen aanroepers en controleert sleutels, terwijl een AI-gateway ook de prompts inspecteert op gevoelige gegevens en verborgen instructies. Zo voorkomt de gateway dat gevoelige gegevens je netwerk verlaten en blokkeert hij promptinjecties.

“LLM-gateway” en “MCP-gateway” worden naast “AI-gateway” gebruikt, maar die termen verwijzen naar smallere lagen:

• Een LLM-gateway handelt de modelaanroep zelf af (tokenmeting, routering en promptfiltering).
• Een MCP-gateway bepaalt via het Model Context Protocol (MCP) welke tools en gegevensbronnen een agent kan bereiken zodra het model besluit actie te ondernemen.

In de praktijk overlappen deze elkaar. Diverse AI-gateways, waaronder LiteLLM, Portkey, Azure API Management en Envoy AI Gateway, bieden nu ook MCP-governance, dus de termen beschrijven verschillende controlelagen.

Hoe AI-gateways AI-agents en MCP-verkeer beheren

De AI-gateway bepaalt welke acties een AI-agent kan uitvoeren met de tools en gegevens die de agent via het Model Context Protocol (MCP) bereikt.

AI-agents werken in lussen: ze roepen een model aan, gebruiken een tool, voeren het resultaat terug en roepen het model opnieuw aan tot de taak is voltooid. Voor toegang tot externe tools en bronnen gebruiken ze MCP, een standaardprotocol waarmee AI-services verbinding kunnen maken met tools van derden.

De AI-gateway bewaakt elke stap in het proces. De gateway beheert en monitort al het verkeer dat de agent initieert, bepaalt tot welke tools en gegevensbronnen de agent toegang heeft en legt alle model- en toolaanroepen vast in een auditlogboek.

Omdat AI-agents meerdere tools en modellen aanroepen om taken te voltooien, moet de gateway meer tokens budgetteren, meer latentie bijhouden en een groter beveiligingsoppervlak bewaken.

Waarom AI-gateways nu belangrijk zijn

In een enquête onder 8.039 senior bedrijfsleiders bij organisaties met meer dan 500 medewerkers gaf 83% aan AI-agents te willen ontwikkelen of inzetten (Cisco AI Readiness Index 2025), en Gartner verwacht taakspecifieke agents in 40% van de bedrijfsapplicaties eind 2026, tegenover minder dan 5% in 2025.

De groeiende adoptie van agentic AI verergert oude problemen en brengt nieuwe met zich mee, waarvan AI-gateways er een aantal helpen in te dammen:

• AI-kosten lopen uit de hand. 79% van de financiële leidinggevenden die deelnamen aan de enquête van DoiT/Sapio uit 2026, overschreed het afgelopen jaar hun AI-budget. Erger nog: dit blijft vaak onopgemerkt, omdat veel bedrijven geen betrouwbare manier hebben om hun AI-uitgaven bij te houden.
• Bedrijven gebruiken meer dan één AI-model. 93% van de enterprise-CIO's die door Dataiku en Harris Poll (2026) werden ondervraagd, zegt dat verschillende modellen beter presteren voor verschillende use cases. 81% van de grote bedrijven verwacht met twee of meer modelproviders te werken en 55% is al minstens één keer van LLM-provider gewisseld.
• Storingen bij providers zijn kostbaar. Onafhankelijke monitoring laat zien dat de toonaangevende LLM-providers betrouwbaar zijn: een uptime van ongeveer 99,85-99,9% (mei 2026) komt neer op zo'n 9-13 uur downtime per jaar. Maar als er storingen optreden, zijn ze duur: twee derde van 1.125 senior infrastructuurleiders schatte dat een uur AI-downtime hun organisatie meer dan $ 100.000 zou kosten (Cockroach Labs 2026).
• Prompts lekken gegevens en stellen organisaties bloot aan aanvallen. Promptinjectie is het grootste beveiligingsrisico voor LLM's (OWASP, 2025) en de hoeveelheid gevoelige gegevens die naar AI-tools stroomt, neemt snel toe: de hoeveelheid bedrijfsgegevens die naar AI-apps werd verzonden, steeg in een jaar met 93%, en ChatGPT alleen al veroorzaakte 410 miljoen schendingen van DLP-beleid (preventie van gegevensverlies) (Zscaler ThreatLabz).

Heb je een AI-gateway nodig, en hoe kies je er een?

Een AI-gateway wordt onmisbaar wanneer je organisatie AI-productapplicaties opschaalt, AI-agents inzet of verschillende teams in uiteenlopende afdelingen meerdere AI-modellen laat gebruiken.

Verschillende signalen laten zien dat het zover is:

• Providersleutels, endpoints en retrylogica zijn gekopieerd of hardgecodeerd in de codebases van meerdere applicaties.
• Maandelijkse rekeningen voor modellen pieken onvoorspelbaar, of de financiële afdeling kan de uitgaven niet toewijzen aan een team of project.
• Klantgerichte functies krijgen te maken met rate-limit- of downtimefouten zodra één provider problemen heeft.
• Applicaties sturen niet-geïnspecteerde prompts die persoonsgegevens, broncode of andere gevoelige informatie kunnen bevatten naar externe modellen.
• Verschillende teams kiezen voor concurrerende providers (OpenAI, Anthropic, Google of zelfgehoste modellen), elk met hun eigen integratiecode.
• Je zet autonome agents of MCP-toolintegraties in die in meerdere stappen interne systemen aanroepen.
• Beveiligings-, IT- of complianceteams hebben geen zicht op welke modellen er draaien, wie ze aanroept en of de output aan de wettelijke eisen voldoet.

Aan de andere kant heb je geen AI-gateway nodig als je één prototype bouwt, een zijproject met weinig verkeer draait of maar één modelendpoint aanroept met minimale beveiligingseisen.

Een AI-gateway zelf hosten of als beheerde dienst afnemen

Als je een AI-gateway inzet, kun je kiezen tussen een zelfgehoste en een beheerde oplossing.

Bij zelfhosting draai je een opensource-gateway zoals LiteLLM, Portkey of Apache APISIX op je eigen infrastructuur, of dat nu een private cloud, een Kubernetes-cluster of on-premises is.

Zelfgehoste AI-gateways zijn een goede keuze als:

• Er strenge eisen gelden voor dataresidentie of compliance. De gateway en de bijbehorende logs en sleutels blijven binnen infrastructuur die je zelf in handen hebt.
• Je veel maatwerk nodig hebt. Je team wil eigen plug-ins, routeringslogica of configuratie van sleutels en budgetten die verder gaat dan wat een beheerde dienst biedt.
• Je de DevOps-capaciteit hebt. Je team kan de gateway en de bijbehorende opslag voor statusgegevens, zoals PostgreSQL, Redis of etcd, patchen, schalen en beheren.

Bij beheerde oplossingen, zoals Cloudflare AI Gateway, Azure API Management of Amazon Bedrock AgentCore Gateway, draait de aanbieder de gateway als dienst.

Volledig beheerde AI-gateways passen beter als:

• Je de gateway snel en met weinig onderhoud draaiende wilt hebben. De aanbieder zorgt voor schaling, patches en uptime.
• Je stack in één cloud draait. Je krijgt standaard native identiteits- en toegangsbeheer, logging en beveiliging van AWS of Azure.
• Je je engineers op het product wilt laten focussen. Hun tijd gaat naar het ontwikkelen van AI-functies, niet naar het beheren van proxy-infrastructuur.

Veelgestelde vragen

Wat is een generatieve AI-gateway?

Een generatieve AI-gateway is hetzelfde als een AI-gateway; de naam legt alleen de nadruk op verkeer naar generatieve AI-modellen. Sommige leveranciers, zoals AWS, gebruiken “generatieve AI-gateway” voor een controlelaag die bepaalt hoe applicaties grote taalmodellen gebruiken.

Je kunt de twee termen als synoniemen beschouwen.

Wat is AI-modelroutering?

AI-modelroutering is de manier waarop een AI-gateway elk verzoek naar het meest geschikte model stuurt op basis van kosten, latentie of mogelijkheden. Zo kan één applicatie via één endpoint veel aanbieders bereiken, zonder dat er routeringslogica in de applicatie zelf hoeft te zitten.

Wat is het verschil tussen een AI-gateway en een MCP-gateway?

Een AI-gateway regelt het verkeer tussen je applicaties en AI-modellen: prompts, tokens, routering en kosten. Een MCP-gateway bepaalt welke tools en gegevensbronnen de agent of client via het Model Context Protocol kan bereiken.

Veel AI-gateways bevatten MCP-governance, zodat beide in één product samenkomen.

Wat is de beste opensource-AI-gateway?

Er is niet één beste opensource-AI-gateway. Om de juiste te kiezen, vergelijk je ze op de aanbieders, plug-ins en beheermogelijkheden die je nodig hebt.

LiteLLM is een veelgebruikte proxy die veel aanbieders ondersteunt; Kong AI Gateway past bij teams die Kong al gebruiken, terwijl Apache APISIX geschikt is voor teams die één opensource-gateway willen voor zowel API- als AI-verkeer.