Perplexity udgiver en forklaring på AI-gatewayers funktion og begrænsninger

Perplexity udgav den 20. oktober 2026 en vejledning, der forklarer, hvordan AI-gateways dirigerer, måler og styrer trafikken mellem applikationer og store sprogmodeller, og hvornår en organisation har brug for en. Indlægget med titlen “Hvad er en AI-gateway? En vejledning i routing, omkostningsstyring og governance for LLM- og agenttrafik” var det nyeste indlæg på virksomhedens blog.

Definition og håndtering af forespørgsler

Vejledningen definerer en AI-gateway som et centralt proxy-lag mellem på den ene side en organisations applikationer eller AI-agenter og på den anden side de store sprogmodeller og værktøjer, de bruger. Routing, omkostningsstyring, sikkerhedshåndhævelse og overvågning af brugen håndteres ét sted. Da hver udbyder (vejledningen nævner OpenAI, Anthropic, Google, open source-modeller og selvhostede endepunkter) leverer sit eget SDK, sine egne API-nøgler og sit eget forespørgselsformat, modtager gatewayen én standardiseret forespørgsel og oversætter den til formatet hos den udbyder, der anmodes om. Modeller tilføjes, udskiftes eller udfases via gatewayens konfiguration i stedet for applikationens kode.

Ifølge vejledningen gennemgår hver forespørgsel, der sendes til gatewayens basis-URL, de samme fire trin: Gatewayen autentificerer og godkender den, der foretager forespørgslen, ud fra nøgle og rolle; anvender politikker såsom tokenbegrænsninger, budgetter og sikkerhedsforanstaltninger, herunder fjernelse af personhenførbare oplysninger; dirigerer forespørgslen til en model eller udbyder ud fra omkostninger, svartid eller tilgængelighed, skifter til en backup ved behov og oversætter forespørgslen til måludbyderens format; og logger modellen, tokenforbruget, svartiden og resultatet til brug for udgiftsopfølgning og fejlfinding.

Funktioner og angivne begrænsninger

Vejledningen beskriver seks funktionsområder. Routing og failover vælger en model ud fra omkostninger, svartid eller funktioner og omdirigerer automatisk forespørgsler, hvis en udbyder er nede eller har indført en hastighedsbegrænsning. Tokenbaserede hastighedsbegrænsninger og budgetter sætter et loft over forbruget pr. team, projekt eller bruger og afviser forespørgsler, når den tildelte mængde er nået. Semantisk caching sammenligner nye prompts med gemte svar ud fra betydningen og returnerer det gemte svar uden at kalde en model, når prompts er tilstrækkeligt ens. Sikkerhedsforanstaltninger kontrollerer hver prompt og hvert svar, fjerner personlige eller følsomme oplysninger, før de når en udbyder, mindsker risikoen for prompt injection og filtrerer uønsket indhold. Observerbarhed registrerer, hvilken model der blev kørt, tokenforbrug, svartid og fejl, mens governance-funktioner giver rollebaseret adgang til modeller og fører en revisionslog over hvert kald.

Om begrænsningerne oplyser vejledningen, at en gateway øger svartiden, men beskriver forsinkelsen som relativt lille for LLM-trafik. Den henviser til et uafhængigt benchmark fra juni 2026 udført af Broadcoms VMware Cloud Foundation-team, hvor en finjusteret Envoy AI Gateway tilføjede omkring 2 millisekunder pr. forespørgsel ved op til 224 samtidige brugere med routing og hastighedsbegrænsning, men uden indholdskontrol. Ifølge vejledningens gengivelse bemærker samme benchmark, at sikkerhedsforanstaltninger og semantisk caching kan tilføje fra ti til flere hundrede millisekunder. Vejledningen fastslår også, at gateways ikke afgør, hvad man skal spørge en model om, husker samtaler, udfører en agents trin for trin-logik eller vurderer kvaliteten af svar. Den advarer desuden om, at omkostningsbaseret routing kan forringe kvaliteten, hvis en billigere model giver et dårligere svar.

Gatewaytyper og agenttrafik

Vejledningen sammenligner AI-gateways med traditionelle API-gateways på flere områder: tokenmåling kontra begrænsninger baseret på antal forespørgsler, semantisk caching kontra caching af nøjagtige match, kontrol af prompts for følsomme data og skjulte instruktioner kontra nøglebaseret autentificering samt routing til modeller ud fra omkostninger, svartid eller funktioner kontra routing til backend-tjenester. Den skelner også mellem to snævrere begreber: En LLM-gateway håndterer selve modelkaldet, mens en MCP-gateway styrer, hvilke værktøjer og datakilder en agent kan få adgang til via Model Context Protocol. LiteLLM, Portkey, Azure API Management og Envoy AI Gateway understøtter nu også MCP-governance, bemærker vejledningen, så begreberne beskriver lag af kontrol, der overlapper hinanden.

For agenter, som ifølge vejledningen arbejder i løkker af modelkald og værktøjsbrug, indtil en opgave er fuldført, styrer og overvåger gatewayen al trafik, som agenterne selv igangsætter, godkender, hvilke værktøjer og datakilder agenten kan få adgang til, og registrerer alle model- og værktøjskald i en revisionslog.

Data om udbredelse og vejledning i implementering

For at anslå efterspørgslen henviser vejledningen til tal fra tredjeparter. Cisco AI Readiness Index 2025 viste, at 83 % af de 8.039 adspurgte ledende erhvervsledere i organisationer med mere end 500 ansatte planlægger at udvikle eller implementere AI-agenter, og Gartner forventer, at opgavespecifikke agenter vil indgå i 40 % af virksomhedsapplikationerne inden udgangen af 2026, sammenlignet med under 5 % i 2025. Om omkostninger henviser vejledningen til DoiT/Sapio-undersøgelsen fra 2026, hvor 79 % af de deltagende økonomiansvarlige sagde, at de havde overskredet deres AI-budget i løbet af det seneste år, samt en undersøgelse fra 2026 foretaget af Dataiku og Harris Poll, hvor 93 % af CIO’erne i større virksomheder sagde, at forskellige modeller fungerer bedre til forskellige anvendelser, 81 % af virksomhederne forventer at bruge to eller flere modeludbydere, og 55 % har skiftet LLM-udbyder mindst én gang.

Uafhængig overvågning, som guiden henviser til, viste, at de førende LLM-udbyderes oppetid lå omkring 99,85–99,9 % i maj 2026. Ifølge guiden svarer det til cirka 9–13 timers nedetid om året. I en undersøgelse fra Cockroach Labs i 2026 blandt 1.125 ledende medarbejdere inden for infrastruktur anslog to tredjedele, at en times nedetid for AI ville koste deres organisation over 100.000 USD. Guiden henviser også til OWASP’s rangering fra 2025, hvor prompt injection blev udpeget som den største sikkerhedsrisiko ved LLM’er, og til en undersøgelse fra Zscaler ThreatLabz, der viste, at mængden af virksomhedsdata sendt til AI-applikationer steg med 93 % på et år, mens ChatGPT alene udløste 410 millioner overtrædelser af regler for forebyggelse af datatab.

Guiden opremser tegn på, at en organisation har brug for en gateway: Udbydernøgler, der er hardkodet i flere kodebaser; modelregninger, som økonomiafdelingen ikke kan henføre til bestemte formål; fejl på grund af hastighedsbegrænsninger eller nedetid, der skyldes afhængighed af en enkelt udbyder; prompts med følsomme data, som ikke bliver kontrolleret; konkurrerende integrationer med udbydere på tværs af teams; MCP-værktøjsintegrationer; og manglende overblik over sikkerhed eller compliance. Ifølge guiden er en gateway ikke nødvendig til en enkelt prototype, et sideprojekt med lav aktivitet eller kald til ét modelendepunkt med minimale sikkerhedskrav. Blandt de selvhostede muligheder nævnes LiteLLM, Portkey og Apache APISIX på privat cloud-infrastruktur, Kubernetes eller lokal infrastruktur. Blandt de administrerede muligheder nævnes Cloudflare AI Gateway, Azure API Management og Amazon Bedrock AgentCore Gateway. Guiden tager udgangspunkt i datakontrol og privatliv, den operationelle byrde, herunder tilstandslagre som PostgreSQL, Redis eller etcd, implementeringshastighed og integrationer. I FAQ’en står der, at »generativ AI-gateway« kan bruges i stedet for »AI-gateway«, og at der ikke findes én enkelt bedste open source-AI-gateway.