← terug

10 juni 2026

Model gateways en LLM-routers, de verkeerstoren van je AI-landschap

Een organisatie waar ik onlangs meekeek had vier AI-toepassingen draaien. Een chatbot op de website, een samenvatter voor klantmails, een intern zoekhulpje en een tool die offertes voorschreef. Vier teams, vier codebases, en in elke codebase een eigen API-key naar een modelprovider. Eentje praatte met OpenAI, eentje met Anthropic, twee met allebei, afhankelijk van wie de feature had gebouwd.

Toen iemand van finance vroeg wat AI de organisatie per maand kostte, kon niemand het zeggen. Toen iemand van privacy vroeg welke data er precies naar welke partij ging, werd het stil. En toen een van die providers een middag eruit lag, lag de chatbot er ook uit, zonder dat iemand wist waarom.

Dit is geen uitzondering. Dit is hoe AI in de meeste organisaties groeit: per team, per project, per enthousiaste ontwikkelaar. En op een gegeven moment heb je geen AI-toepassingen meer, maar een wirwar van directe lijntjes naar Amerikaanse API's waar niemand overzicht over heeft.

De oplossing daarvoor heet een model gateway. En het is een van die stukken infrastructuur die saai klinken tot je begrijpt wat ze doen.

Wat een model gateway is

Een model gateway is een tussenlaag tussen je applicaties en de modelproviders. In plaats van dat elke applicatie rechtstreeks naar OpenAI, Anthropic, Mistral of je eigen gehoste model praat, praten ze allemaal naar één centraal punt. Dat punt stuurt het verzoek door naar het juiste model, vangt het antwoord op en geeft het terug.

Vergelijk het met een verkeerstoren. Vliegtuigen vliegen niet op eigen houtje een luchthaven binnen. Alles loopt via één punt dat overzicht heeft, prioriteiten stelt en kan ingrijpen. Een gateway doet dat voor je AI-verkeer.

Technisch is het meestal een proxy met een OpenAI-compatible API. Dat is handig, want bijna elke AI-bibliotheek en tool kan met dat API-formaat overweg. Je applicatie denkt dat hij met "een model" praat. Welk model dat werkelijk is, en bij welke provider dat draait, bepaal je centraal in de gateway.

Dat levert een paar dingen op die je zonder gateway simpelweg niet hebt.

Eén plek voor keys. De echte API-keys van providers liggen alleen in de gateway. Applicaties en teams krijgen virtuele keys die je per stuk kunt intrekken, begrenzen of vervangen. Geen provider-keys meer in tien verschillende codebases, en als er eentje lekt, vervang je hem op één plek.

Kostenbewaking. Elke aanvraag loopt door hetzelfde punt, dus je kunt per team, per applicatie en per model zien wat er wordt uitgegeven. Je kunt budgetten instellen: dit team mag deze maand zoveel, daarna gaat de kraan dicht of krijgt iemand een melding. Zonder gateway ontdek je kosten achteraf op de factuur.

Logging en audit. Wie vroeg wat, wanneer, aan welk model, en wat kwam er terug? Voor incidentonderzoek, voor kwaliteitsbewaking en steeds vaker ook voor verantwoording richting toezicht wil je dit kunnen reconstrueren. De AI Act vraagt voor bepaalde toepassingen om logging en traceerbaarheid, en een gateway is technisch gezien de logische plek om dat te regelen.

Fallbacks. Provider plat, rate limit geraakt, time-out? De gateway kan automatisch een tweede model of tweede provider proberen. De gebruiker merkt er weinig van. Zonder gateway moet elk team dit zelf bouwen, en in de praktijk bouwt dus niemand het.

Model switching. Komt er een beter of goedkoper model uit, dan wijzig je de configuratie van de gateway en draait elke applicatie er meteen op. Niemand hoeft code aan te passen. Wie de afgelopen twee jaar heeft gezien hoe snel modellen elkaar opvolgen, snapt hoeveel dat scheelt.

Beleid. En dit is misschien wel de belangrijkste: de gateway is de plek waar je regels afdwingt over welke data naar welk model mag. Daarover zo meer.

En dan de LLM-router

Een gateway stuurt verkeer door. Een LLM-router gaat een stap verder: die kiest per verzoek welk model de taak krijgt.

Want niet elke vraag heeft hetzelfde model nodig. "Vat deze mail samen in twee zinnen" kan prima door een klein, snel, goedkoop model worden gedaan. "Analyseer dit contract van veertig pagina's en benoem de risico's" wil je naar een zwaarder model sturen. Het prijsverschil tussen die twee kan zomaar een factor twintig of meer zijn, en het snelheidsverschil is ook fors.

Een router beslist dat op basis van regels of een classificatie van het verzoek. Soms heel simpel: deze applicatie gaat altijd naar dat model. Soms slimmer: korte feitelijke vragen naar het kleine model, lange analyses naar het grote, en alles wat persoonsgegevens bevat naar het model dat op eigen infrastructuur draait.

Dat laatste is het punt waar routing en beleid samenkomen. Je kunt technisch afdwingen: klantdata en personeelsdata gaan alleen naar het model dat wij zelf in Europa hosten, en de generieke taken mogen naar een commerciële provider. Dat is geen beleidsdocument dat in een la ligt, dat is een regel die elke aanvraag daadwerkelijk raakt. In HostYourAI hebben we precies om die reden een LLM-router op Europese infrastructuur gebouwd: zodat de routeringsbeslissing zelf, en de logs die erbij horen, niet alsnog buiten Europa belanden. Maar het principe staat los van welk product je gebruikt.

Een voorbeeld: de gemeente met drie AI-toepassingen

Stel, een gemeente draait drie dingen. Een publieke chatbot die vragen over afvalinzameling en openingstijden beantwoordt. Een interne assistent die ambtenaren helpt met het samenvatten van beleidsstukken. En een tool die binnenkomende brieven van inwoners categoriseert, inclusief brieven over schuldhulp en zorg.

Zonder gateway praten die drie systemen elk rechtstreeks met een provider. De brief over schuldhulp gaat dan langs dezelfde route als de vraag over de grijze container, naar dezelfde Amerikaanse API, onder dezelfde voorwaarden.

Met een gateway en router kun je het anders inrichten. De chatbot mag naar een commercieel model, want die verwerkt publieke informatie. De beleidsassistent ook, eventueel. Maar de brievenstroom, met daarin bijzondere persoonsgegevens, routeer je naar een open-source model dat op eigen of Europese infrastructuur draait. Eén configuratie, drie verschillende routes, en je kunt aan je functionaris gegevensbescherming laten zien hoe het loopt. Niet als belofte, maar als logregel.

Dit is het verschil tussen "wij hebben beleid over AI" en "ons beleid wordt technisch afgedwongen". Dat eerste is een intentie. Dat tweede is infrastructuur.

De ongemakkelijke keerzijde: de gateway ziet alles

Nu het deel dat in veel verkooppraatjes wordt overgeslagen.

Een gateway werkt omdat al je AI-verkeer erdoorheen loopt. Elke prompt, elk antwoord, elk document dat in een context wordt meegestuurd. Dat is precies waarom hij zo nuttig is, en precies waarom hij het gevoeligste systeem in je hele AI-landschap wordt. Je hebt het probleem "onze data gaat naar tien verschillende plekken" ingeruild voor "al onze data gaat door één plek". Dat is een verbetering, maar alleen als je die ene plek serieus neemt.

Drie vragen bepalen of je het goed doet.

Waar draait de gateway? Er zijn gateways als SaaS-dienst, vaak op Amerikaanse infrastructuur. Handig, snel opgezet, maar dan stuur je dus al je prompts eerst naar die partij, ook de verzoeken die daarna naar je eigen Europese model gaan. Daarmee ondergraaf je het hele idee. Wie het serieus aanpakt, draait de gateway zelf of bij een Europese partij. Er zijn volwassen open-source opties waarmee dat kan, LiteLLM is daarvan een bekend voorbeeld.

Wat wordt er gelogd, en hoe lang? Volledige prompts loggen is goud voor debugging en kwaliteitsbewaking, maar het betekent ook dat je een database opbouwt met alles wat je medewerkers en klanten ooit aan AI hebben gevraagd. Denk na over wat je bewaart: alleen metadata zoals tijdstip, model en tokenaantallen, of ook de inhoud. En als je inhoud bewaart: hoe lang, versleuteld waarmee, en wie kan erbij.

Wie beheert hem? De beheerder van de gateway kan in potentie al het AI-verkeer van de organisatie inzien. Dat vraagt om dezelfde zorgvuldigheid als beheer van je mailserver of identiteitsplatform: beperkte toegang, vier-ogen op configuratiewijzigingen, en monitoring op de monitor zelf.

En dan is er nog de operationele kant. De gateway is een single point of failure: ligt hij eruit, dan ligt alles eruit. Dat is oplosbaar met redundantie, maar je moet het wél oplossen. Hij voegt ook een klein beetje latency toe, meestal verwaarloosbaar naast de seconden die het model zelf nodig heeft, maar het is niet nul. En een routeringsfout in de configuratie kan betekenen dat gevoelige data ineens naar het verkeerde model gaat. De gateway dwingt je beleid af, inclusief de fouten in dat beleid.

Een denkmodel om dit te beoordelen

Als je hiermee aan de slag wilt, loop dan deze vragen langs:

De volgorde is bewust. De eerste vier vragen laten zien of je een gateway nodig hebt. De laatste laat zien of je hem veilig inzet.

Tot slot

Een model gateway is geen spannende technologie. Het is een proxy met een configuratiebestand. Maar het is wel het verschil tussen AI als losse experimenten en AI als beheerde infrastructuur. Keys op één plek, kosten zichtbaar, fallbacks geregeld, modellen verwisselbaar, en beleid dat echt iets doet in plaats van ergens te staan.

De prijs is dat je één component creëert die alles ziet. Dat is geen reden om het niet te doen. Het is een reden om de vraag "waar draait dit ding en wie beheert hem" net zo serieus te nemen als de vraag welk model je gebruikt. De gebruiker ziet alleen het antwoord. De organisatie moet de hele dataflow begrijpen, en de gateway is voortaan het hart van die dataflow. 

↘︎ ALLE ARTIKELEN