Hvad er en AI-gateway? En guide til routing, omkostningskontrol og styring af LLM- og agenttrafik

En AI-gateway er et centraliseret proxylag mellem dine applikationer eller AI-agenter og de store sprogmodeller (LLM'er) og værktøjer, de kalder. Den dirigerer forespørgsler, styrer AI-omkostninger, håndhæver sikkerhed og overvåger forbruget, så du ikke behøver at bygge disse kontroller separat ind i hver enkelt applikation. Det ville hurtigt blive upraktisk, efterhånden som dine teams forbinder flere modeller og implementerer flere agenter.

Her kan du læse, hvad en AI-gateway gør, hvordan den adskiller sig fra en traditionel API-gateway (og fra LLM- og MCP-gateways), hvilke funktioner og begrænsninger den har, og hvordan du afgør, om du har brug for en.

Hvad er en AI-gateway?

En AI-gateway er et mellemlag, der dirigerer hvert kald fra din applikation eller AI-agent til en stor sprogmodel (LLM).

Takket være den kan du få adgang til mange forskellige modeller, som om de var én.

Hver udbyder (OpenAI, Anthropic, Google, en open source-model eller dit eget selvhostede endpoint) har sit eget SDK, sine egne API-nøgler og sit eget forespørgselsformat. Gatewayen modtager én standardforespørgsel, oversætter den til den udbyder, du kalder, og returnerer svaret.

Du tilføjer, udskifter eller udfaser modeller ved at ændre gatewayens konfiguration, ikke applikationskoden.

Og fordi alle forespørgsler går gennem AI-gatewayen, kan du anvende kontroller for omkostninger, sikkerhed og logning for alle modeller ét sted.

Sådan fungerer en AI-gateway

Når du peger din applikation eller AI-agent på AI-gatewayens basis-URL, gennemgår hver forespørgsel de samme trin:

• Autentificering og autorisation: Gatewayen kontrollerer kalderens nøgle og rolle.
• Anvendelse af politikker: Den håndhæver tokengrænser og budgetter og kører guardrails som f.eks. maskering af PII.
• Routing: Den vælger model eller udbyder ud fra omkostninger, latenstid eller tilgængelighed og skifter til en backup, hvis den første er nede. Den oversætter også forespørgslen til måludbyderens format.
• Logning: Den registrerer model, antal tokens, latenstid og resultat til sporing af AI-udgifter og fejlfinding.

En forespørgsel, der ellers ville være gået direkte til en AI-udbyder, går altså nu gennem gatewayen, som kan begrænse dens tokens, skifte til en billigere model eller returnere et cachelagret svar, før den når en LLM.

Funktioner i en AI-gateway

En AI-gateway dirigerer modeltrafik, styrer omkostninger, beskytter og logger trafikken og bestemmer, hvem der må bruge hvad.

Udvid

Routing og failover

AI-gatewayen vælger, hvilken AI-model der håndterer hver forespørgsel, ud fra omkostninger, latenstid eller egenskaber.

Hvis den valgte udbyder er nede eller har ramt en hastighedsbegrænsning, sender gatewayen automatisk forespørgslen til en anden model.

Din applikation fortsætter dermed med at fungere under et nedbrud, og du kan fordele belastningen på flere udbydere på én gang.

Tokenbaserede hastighedsbegrænsninger og budgetter

Med AI-gatewayen kan du fastsætte lofter for teams, projekter eller brugere, og gatewayen afviser forespørgsler, når de når den tildelte tokengrænse.

Udgifterne holder sig dermed inden for budgettet, og intet enkelt team eller projekt kan bruge det hele op alene.

Semantisk caching

Den semantiske cache i AI-gateways gemmer tidligere svar og matcher nye prompts ud fra deres betydning. Når en ny prompt ligner en, som gatewayen allerede har besvaret, tilstrækkeligt meget, returnerer den det gemte svar uden at kalde modellen.

Ved AI-arbejdsbelastninger med mange lignende forespørgsler sænker det både omkostningerne og svartiden.

Guardrails og databeskyttelse

AI-gatewayen inspicerer hver prompt og hvert svar, der passerer igennem.

Den fjerner personlige eller følsomme data, før forespørgslen når modeludbyderen, mindsker risikoen for promptinjektioner og filtrerer indhold, du ikke ønsker at sende eller modtage.

Kontrollerne gælder for alle forespørgsler, så beskyttelsen ikke afhænger af, at hver enkelt AI-applikation gør det rigtigt.

Observerbarhed

AI-gatewayen registrerer hver forespørgsel: hvilken model der kørte, hvor mange tokens den brugte, hvor lang tid det tog, og om den mislykkedes.

Denne registrering af alle AI-interaktioner gør det muligt at henføre omkostninger til et team, fejlfinde en langsom eller fejlende model og se forbruget på tværs af alle udbydere.

AI-styring og adgangskontrol

AI-gatewayen styrer adgangen til AI på tværs af din organisation. Den giver adgang til modeller i henhold til dine rolleindstillinger, autentificerer alle kaldere og registrerer hvert kald i en revisionslog, så du kan gennemgå brugen af AI.

AI-gatewayens begrænsninger: latenstid og det, den ikke gør

En AI-gateway tilføjer en smule latenstid. Og den vurderer ikke kvaliteten af outputtet, som fortsat er dit ansvar.

Hvor meget latenstid en gateway tilføjer

En AI-gateway tilføjer latenstid, altså forsinkelsen mellem at sende en forespørgsel og få et svar tilbage, men den er forholdsvis lille ved LLM-trafik.

I et uafhængigt benchmark fra Broadcoms VMware Cloud Foundation-team fra juni 2026 tilføjede en finjusteret Envoy AI Gateway ca. 2 ms pr. forespørgsel ved op til 224 samtidige brugere med routing og hastighedsbegrænsning, men uden indholdsinspektion (guardrails og semantisk caching kan tilføje fra snesevis til hundredvis af millisekunder).

En AI-gateway styrer ikke kvaliteten af prompten eller outputtet

En AI-gateway styrer trafikken, ikke modellens output eller applikationslogikken omkring den.

AI-gateways bestemmer ikke, hvad en model skal spørges om, husker ikke din samtale eller hvor en opgave slap, og kører ikke en agents trin-for-trin-logik.

Og de vurderer ikke kvaliteten af svarene. De kan derfor ikke garantere, at et svar er korrekt eller sikkert.

Faktisk kan brugen af AI-gateways under visse omstændigheder forringe kvaliteten. Hvis gatewayen f.eks. dirigerer en forespørgsel til en billigere model for at spare penge, kan den model returnere et dårligere svar.

Det er derfor stadig din opgave at kontrollere kvaliteten af outputtet.

AI-gateway vs. API-gateway

En AI-gateway og en API-gateway fungerer på lignende måde, men styrer forskellige typer trafik. En API-gateway håndterer generelle API-kald (REST eller GraphQL mellem dine klienter og backendtjenester), hvor hver forespørgsel er forudsigelig. En AI-gateway håndterer kald til en sprogmodel, som måles i tokens og indeholder prompts i fri form.

Her er de vigtigste forskelle mellem AI-gateways og API-gateways:

• En API-gateway dirigerer forespørgsler til en backendtjeneste, mens en AI-gateway dirigerer dem til LLM'er.
• En API-gateway begrænser, hvor mange forespørgsler du sender, og måler båndbredde, hvorimod en AI-gateway måler tokens. Antallet af værktøjsforespørgsler er irrelevant for sporing af forbruget af AI-modeller, fordi ét kald kan bruge nogle få tokens eller flere hundrede tusinde.
• En API-gateway leverer kun et cachelagret svar ved et nøjagtigt match, mens en AI-gateway også kan cache ud fra betydning og returnere et gemt svar, når en ny prompt ligner en tidligere tilstrækkeligt meget. Prompts er sjældent identiske, så uden denne funktion ville du betale for modelkald for at besvare de samme spørgsmål igen og igen.
• En API-gateway autentificerer kun kaldere og kontrollerer nøgler, mens en AI-gateway også inspicerer prompts for følsomme data og skjulte instruktioner. Den forhindrer følsomme data i at forlade dit netværk og blokerer promptinjektioner.

»LLM-gateway« og »MCP-gateway« bruges sideløbende med »AI-gateway«, men betegner smallere lag:

• En LLM-gateway håndterer selve modelkaldet (tokenmåling, routing og promptfiltrering).
• En MCP-gateway styrer via Model Context Protocol (MCP), hvilke værktøjer og datakilder en agent kan tilgå, når modellen beslutter at handle.

I praksis overlapper de hinanden. Flere AI-gateways, herunder LiteLLM, Portkey, Azure API Management og Envoy AI Gateway, tilføjer nu MCP-styring, så begreberne beskriver forskellige kontrollag.

Sådan håndterer AI-gateways AI-agenter og MCP-trafik

AI-gatewayen styrer de handlinger, en AI-agent kan udføre med de værktøjer og data, den tilgår via Model Context Protocol (MCP).

AI-agenter arbejder i løkker: De kalder en model, bruger et værktøj, sender resultatet tilbage og kalder igen, indtil opgaven er fuldført. For at få adgang til eksterne værktøjer og ressourcer bruger de MCP, en standardprotokol, der lader AI-tjenester oprette forbindelse til tredjepartsværktøjer.

AI-gatewayen overvåger hvert trin i processen. Den styrer og overvåger al trafik, som agenten sætter i gang, godkender, hvilke værktøjer og datakilder agenten kan tilgå, og registrerer alle model- og værktøjskald i en revisionslog.

Når AI-agenter kalder flere værktøjer og modeller for at fuldføre opgaver, har gatewayen flere tokens at budgettere med, mere latenstid at holde øje med og en større angrebsflade at overvåge.

Derfor er AI-gateways vigtige nu

I en undersøgelse blandt 8.039 topledere i organisationer med over 500 medarbejdere svarede 83 %, at de planlægger at udvikle eller implementere AI-agenter (Cisco AI Readiness Index 2025), og Gartner forventer opgavespecifikke agenter i 40 % af virksomhedsapplikationerne ved udgangen af 2026, op fra under 5 % i 2025.

Den voksende udbredelse af agentisk AI forværrer gamle problemer og skaber nye, og AI-gateways kan hjælpe med at holde nogle af dem i skak:

• AI-omkostningerne løber løbsk. 79 % af de økonomiledere, der deltog i DoiT/Sapio-undersøgelsen fra 2026, overskred deres AI-budget i løbet af det seneste år. Værre endnu går det ofte ubemærket hen, fordi mange virksomheder ikke har pålidelige måder at spore deres AI-udgifter på.
• Virksomheder bruger mere end én AI-model. 93 % af de CIO'er i store virksomheder, som Dataiku og Harris Poll (2026) har spurgt, siger, at forskellige modeller klarer sig bedre til forskellige formål. 81 % af virksomhederne forventer at bruge to eller flere modeludbydere, og 55 % har allerede skiftet LLM-udbyder mindst én gang.
• Nedbrud hos udbydere er dyre. Uafhængig overvågning viser, at de førende LLM-udbydere er pålidelige: En oppetid på omkring 99,85–99,9 % (maj 2026) svarer til ca. 9–13 timers nedetid om året. Men når der sker nedbrud, er de dyre: To tredjedele af 1.125 ledende infrastrukturansvarlige anslog, at en times AI-nedetid ville koste deres organisation over 100.000 dollar (Cockroach Labs 2026).
• Prompts lækker data og gør organisationer sårbare over for angreb. Promptinjektion er den største sikkerhedsrisiko for LLM'er (OWASP, 2025), og strømmen af følsomme data til AI-værktøjer vokser hurtigt: Mængden af virksomhedsdata sendt til AI-apps steg med 93 % på et år, og ChatGPT alene udløste 410 millioner overtrædelser af regler for forebyggelse af datatab (Zscaler ThreatLabz).

Har du brug for en AI-gateway, og hvordan vælger du en?

En AI-gateway bliver afgørende, når din organisation skalerer AI-produktapplikationer, implementerer AI-agenter eller giver forskellige teams mulighed for at bruge flere AI-modeller på tværs af afdelinger.

Flere tegn viser, at tiden er inde:

• Udbydernøgler, endpoints og logik til genforsøg er kopieret eller hardcodet på tværs af flere applikationskodebaser.
• De månedlige regninger for modeller stiger uforudsigeligt, eller økonomiafdelingen kan ikke henføre udgifterne til et team eller projekt.
• Kundevendte funktioner rammer fejl på grund af hastighedsbegrænsninger eller nedetid, hver gang en udbyder har problemer.
• Applikationer sender uinspicerede prompts, der kan indeholde personoplysninger, kildekode eller andre følsomme oplysninger, til eksterne modeller.
• Forskellige teams tager konkurrerende udbydere i brug (OpenAI, Anthropic, Google eller selvhostede modeller), hver med sin egen integrationskode.
• Du udruller autonome agenter eller MCP-værktøjsintegrationer, der foretager kald i flere trin mod interne systemer.
• Sikkerheds-, IT- eller compliance-teams har intet overblik over, hvilke modeller der kører, hvem der kalder dem, eller om outputtet lever op til de regulatoriske krav.

Omvendt er en AI-gateway ikke nødvendig, når du bygger en enkelt prototype, kører et sideprojekt med lav volumen eller kun kalder ét modelendpoint med minimale sikkerhedskrav.

Host selv, eller køb en administreret AI-gateway

Når du udruller en AI-gateway, kan du vælge mellem en selvhostet og en administreret løsning.

Med en selvhostet løsning kører du en open source-gateway som LiteLLM, Portkey eller Apache APISIX på din egen infrastruktur, uanset om det er en privat cloud, en Kubernetes-klynge eller on-premises.

Selvhostede AI-gateways er et godt valg, når:

• Kravene til dataplacering eller compliance er strenge. Gatewayen, dens logfiler og dens nøgler forbliver i infrastruktur, som du selv ejer.
• Du har brug for omfattende tilpasning. Dit team ønsker brugerdefinerede plugins, routinglogik eller konfiguration af nøgler og budgetter ud over, hvad en administreret tjeneste tilbyder.
• Du har DevOps-kapacitet. Dit team kan opdatere, skalere og drive gatewayen og dens tilstandslagre, såsom PostgreSQL, Redis eller etcd.

Med administrerede løsninger som Cloudflare AI Gateway, Azure API Management eller Amazon Bedrock AgentCore Gateway driver udbyderen gatewayen som en tjeneste.

Fuldt administrerede AI-gateways passer bedre, når:

• Du vil hurtigt i gang med minimal vedligeholdelse. Udbyderen håndterer skalering, opdateringer og oppetid.
• Din stak ligger i én cloud. Du får indbygget identitets- og adgangsstyring, logning og sikkerhed fra AWS eller Azure lige fra start.
• Du vil have dine udviklere til at fokusere på produktet. Deres tid går til at udvikle AI-funktioner, ikke til at drive proxyinfrastruktur.

Ofte stillede spørgsmål

Hvad er en generativ AI-gateway?

En generativ AI-gateway er det samme som en AI-gateway; navnet fremhæver blot trafik til generative AI-modeller. Nogle leverandører, f.eks. AWS, bruger ”generativ AI-gateway” om et kontrollag, der styrer, hvordan applikationer bruger store sprogmodeller.

Du kan betragte de to begreber som synonyme.

Hvad er AI-modelrouting?

AI-modelrouting er den måde, hvorpå en AI-gateway sender hver anmodning til den mest egnede model ud fra omkostninger, latenstid eller egenskaber. Det gør det muligt for én applikation at nå mange udbydere via ét enkelt endpoint, uden at der skal bygges routinglogik ind i selve applikationen.

Hvad er forskellen på en AI-gateway og en MCP-gateway?

En AI-gateway styrer trafikken mellem dine applikationer og AI-modeller: prompts, tokens, routing og omkostninger. En MCP-gateway styrer, hvilke værktøjer og datakilder agenten eller klienten kan nå via Model Context Protocol.

Mange AI-gateways omfatter MCP-styring, så de to findes i ét og samme produkt.

Hvad er den bedste open source-AI-gateway?

Der findes ikke én bedste open source-AI-gateway. For at vælge den rette bør du sammenligne dem ud fra de udbydere, plugins og kontrolfunktioner, du har brug for.

LiteLLM er en udbredt proxy med bred dækning af udbydere; Kong AI Gateway passer til teams, der allerede kører Kong, mens Apache APISIX passer til teams, der ønsker én open source-gateway til både API- og AI-trafik.