Perplexity forklarer hvordan KI-gatewayer fungerer, og hvilke begrensninger de har

Perplexity publiserte 20. oktober 2026 en veiledning som forklarer hvordan KI-gatewayer ruter, måler og styrer trafikk mellom applikasjoner og store språkmodeller, og når en organisasjon trenger en slik gateway. Innlegget, med tittelen «Hva er en KI-gateway? En veiledning i ruting, kostnadskontroll og styring av trafikk fra LLM-er og agenter», var det nyeste innlegget på selskapets blogg.

Definisjon og håndtering av forespørsler

Veiledningen definerer en KI-gateway som et sentralt proxy-lag mellom organisasjonens applikasjoner eller KI-agenter på den ene siden og de store språkmodellene og verktøyene de bruker på den andre. Ruting, kostnadskontroll, sikkerhetstiltak og bruksovervåking håndteres på ett sted. Siden hver leverandør (veiledningen nevner OpenAI, Anthropic, Google, modeller med åpen kildekode og selvdriftede endepunkter) leverer sitt eget SDK, sine egne API-nøkler og sitt eget forespørselsformat, tar gatewayen imot én standardisert forespørsel og oversetter den til formatet til leverandøren som brukes. Modeller legges til, byttes ut eller tas ut av bruk ved å endre gateway-konfigurasjonen, ikke applikasjonskoden.

Ifølge veiledningen går hver forespørsel som sendes til gatewayens basis-URL, gjennom de samme fire trinnene: Gatewayen autentiserer og autoriserer den som sender forespørselen, basert på nøkkel og rolle; håndhever retningslinjer som tokenbegrensninger, budsjetter og sikkerhetsregler, inkludert sladding av personopplysninger; ruter forespørselen til en modell eller leverandør basert på kostnad, responstid eller tilgjengelighet, går over til en reserveleverandør ved behov og oversetter forespørselen til mål­leverandørens format; og logger modell, antall token, responstid og resultat for kostnadssporing og feilsøking.

Funksjoner og oppgitte begrensninger

Veiledningen beskriver seks funksjonsområder. Ruting og reservevalg velger en modell ut fra kostnad, responstid eller kapasitet og videresender automatisk forespørsler når en leverandør er nede eller har nådd en hastighetsbegrensning. Tokenbaserte hastighetsgrenser og budsjetter setter tak på bruken per team, prosjekt eller bruker og avviser forespørsler når en tildelt kvote er brukt opp. Semantisk hurtigbufring sammenligner nye spørsmål med lagrede svar ut fra betydningen og returnerer det lagrede svaret uten å kalle på en modell når spørsmålene er tilstrekkelig like. Sikkerhetsregler kontrollerer hver forespørsel og hvert svar, fjerner personopplysninger eller sensitive data før de når en leverandør, reduserer risikoen for prompt-injeksjon og filtrerer bort uønsket innhold. Overvåking registrerer hvilken modell som ble brukt, tokenforbruk, responstid og feil, mens styringsfunksjoner gir modelltilgang basert på roller og fører en revisjonslogg over hvert kall.

Når det gjelder begrensninger, oppgir veiledningen at en gateway øker responstiden, men beskriver forsinkelsen som relativt liten for LLM-trafikk. Den viser til en uavhengig referansemåling fra juni 2026 utført av Broadcoms VMware Cloud Foundation-team. I denne målingen førte en optimalisert Envoy AI Gateway til en økning på rundt 2 millisekunder per forespørsel ved opptil 224 samtidige brukere, med ruting og hastighetsbegrensning, men uten innholdskontroll. Ifølge veiledningen viser den samme målingen at sikkerhetsregler og semantisk hurtigbufring kan legge til fra titalls til hundrevis av millisekunder. Veiledningen slår også fast at gatewayer ikke avgjør hva man skal spørre en modell om, husker samtaler, utfører en agents trinnvise logikk eller vurderer kvaliteten på svarene. Den advarer dessuten om at kostnadsstyrt ruting kan redusere kvaliteten hvis en billigere modell gir et dårligere svar.

Typer gatewayer og agenttrafikk

Veiledningen sammenligner KI-gatewayer med tradisjonelle API-gatewayer på flere områder: måling av tokenforbruk kontra grenser for antall forespørsler, semantisk hurtigbufring kontra hurtigbufring basert på nøyaktig samsvar, kontroll av spørsmål for sensitive data og skjulte instruksjoner kontra autentisering med nøkler, og ruting til modeller basert på kostnad, responstid eller kapasitet kontra ruting til backend-tjenester. Den skiller også mellom to snevrere begreper: En LLM-gateway håndterer selve modellkallet, mens en MCP-gateway styrer hvilke verktøy og datakilder en agent kan nå gjennom Model Context Protocol. LiteLLM, Portkey, Azure API Management og Envoy AI Gateway har nå lagt til MCP-styring, påpeker veiledningen, så begrepene viser til overlappende kontrollag.

For agenter, som ifølge veiledningen arbeider i løkker med modellkall og bruk av verktøy fram til en oppgave er fullført, kontrollerer og overvåker gatewayen all trafikk som agenten setter i gang, godkjenner hvilke verktøy og datakilder agenten har tilgang til, og registrerer alle modell- og verktøykall i en revisjonslogg.

Tall om innføring og råd om implementering

For å anslå etterspørselen viser veiledningen til tall fra tredjeparter. Cisco AI Readiness Index 2025 viste at 83 % av 8 039 undersøkte ledere i organisasjoner med over 500 ansatte planlegger å utvikle eller ta i bruk KI-agenter. Gartner forventer at oppgavespesifikke agenter vil inngå i 40 % av bedriftsapplikasjonene innen utgangen av 2026, opp fra under 5 % i 2025. Når det gjelder kostnader, viser veiledningen til undersøkelsen DoiT/Sapio 2026, der 79 % av de deltakende økonomilederne sa at de hadde overskredet KI-budsjettet sitt det siste året. Den viser også til en undersøkelse fra Dataiku og Harris Poll i 2026, der 93 % av IT-direktørene i større virksomheter sa at ulike modeller gir bedre resultater for ulike bruksområder, 81 % av virksomhetene forventer å bruke to eller flere modelltilbydere, og 55 % har byttet LLM-leverandør minst én gang.

Uavhengig overvåking som omtales i veiledningen, viste at de ledende LLM-leverandørene hadde en oppetid på rundt 99,85–99,9 % i mai 2026. Ifølge veiledningen tilsvarer dette omtrent 9–13 timer med nedetid i året. I en undersøkelse fra Cockroach Labs i 2026 blant 1 125 ledende infrastruktursjefer anslo to tredjedeler at én time med nedetid for AI ville koste organisasjonen deres over 100 000 dollar. Veiledningen viser også til OWASPs rangering fra 2025, der prompt injection ble utpekt som den største sikkerhetsrisikoen for LLM-er, og til et funn fra Zscaler ThreatLabz om at mengden bedriftsdata som sendes til AI-applikasjoner, økte med 93 % på ett år. ChatGPT alene utløste 410 millioner brudd på retningslinjer for datatapssikring.

Veiledningen lister opp tegn på at en organisasjon trenger en gateway: leverandørnøkler som er hardkodet i flere kodebaser, modellkostnader som økonomiavdelingen ikke kan henføre, feil med hastighetsbegrensninger eller nedetid som skyldes avhengighet av én enkelt leverandør, uprøvde ledetekster som inneholder sensitive data, konkurrerende integrasjoner mot leverandører på tvers av team, integrasjoner med MCP-verktøy og manglende oversikt over sikkerhet og etterlevelse. Den sier at en gateway ikke er nødvendig for én enkelt prototype, et sideprosjekt med lavt volum eller kall til ett modellendepunkt med minimale sikkerhetskrav. Blant alternativene for egen drift nevnes LiteLLM, Portkey og Apache APISIX på privat sky, Kubernetes eller lokal infrastruktur. Blant de administrerte alternativene nevnes Cloudflare AI Gateway, Azure API Management og Amazon Bedrock AgentCore Gateway. Veiledningen setter valget i sammenheng med kontroll over data og personvern, driftsbelastning, inkludert tilstandslager som PostgreSQL, Redis eller etcd, utrullingshastighet og integrasjoner. I FAQ-en står det at «gateway for generativ AI» og «AI-gateway» kan brukes om hverandre, og at det ikke finnes én enkelt beste AI-gateway med åpen kildekode.