Et mellemlag, ofte kaldet AI gateway eller LLM gateway, samler alle kald til sprogmodeller ét sted, så jeres systemer taler med laget, og laget taler med modellerne. Det gør et skifte af model eller udbyder til en ændring ét sted, men det gør ikke svarene ens, og laget bliver selv en komponent, I er afhængige af.
Artiklen er skrevet til CTO og IT-chef, der overvejer et sådant lag som en del af valget af model og tjeneste. Næsten alt, der er skrevet om emnet, kommer fra dem, der sælger lagene. Vi har ikke fundet en uafhængig kilde, så det følgende er sitets egen faglige vurdering.
Hvad et mellemlag gør
Uden et lag kalder hvert system modellen direkte, med udbyderens adresse, nøgle og format. Med et lag går alle kald gennem én komponent, der kan:
- oversætte jeres kald til de forskellige udbyderes formater,
- holde nøgler til udbyderne, så de ikke ligger i hvert system,
- logge, hvem der kalder hvilken model, og hvad det koster i forbrug,
- sætte grænser pr. afdeling eller system,
- sende kald videre til en anden model, hvis den første ikke svarer,
- skifte model for et system ved en ændring i konfigurationen.
Det sidste er grunden til, at laget dukker op i et valg om binding. Har I tyve steder, der kalder én udbyder direkte, er et skifte et projekt. Har I tyve steder, der kalder laget, er selve omlægningen en indstilling.
Hvad laget ikke løser
Svarene bliver ikke ens. To modeller svarer forskelligt på den samme prompt. Laget kan sende kaldet videre, men det kan ikke gøre den nye model god til jeres opgave. Prompter skal stadig rettes, og testsættet skal stadig køres. Et lag fjerner den tekniske del af skiftet og efterlader kvalitetsdelen.
De særlige funktioner følger ikke med. Udbyderne har funktioner, der ikke findes hos de andre, eller som virker forskelligt: strukturerede svar efter et skema, værktøjskald, lagring af lange prompter, filer og lyd. Et lag, der skal kunne tale med alle, må enten nøjes med det, alle har til fælles, eller sende de særlige felter videre uændret. I det første tilfælde mister I funktioner. I det andet er bindingen stadig der, bare ét lag længere nede. To udbydere skriver selv i deres dokumentation, at felter, de ikke understøtter i en kompatibel grænseflade, kan blive ignoreret uden fejl. Det er beskrevet i kompatibelt API.
Udfasning sker stadig. Laget gør det lettere at skifte, når en model lukker. Det ændrer ikke på, at den lukker.
Laget kan selv binde
Et mellemlag er software med sin egen konfiguration, sine egne regler og sit eget format for logs. Bygger I mange regler ind i det, er de skrevet til netop det lag. Skal laget skiftes, er det et nyt projekt.
Der er groft sagt tre former, og de binder forskelligt:
Et lag, I selv bygger. I ejer koden og bestemmer selv. Til gengæld skal I selv følge med, når udbyderne ændrer deres grænseflader, og det sker ofte.
Et lag med åben kildekode, I selv driver. Koden kan læses og ændres, og I bestemmer, hvor laget kører. Binding opstår gennem konfigurationen og gennem afhængigheden af, at projektet bliver vedligeholdt. Læs, hvem der står bag projektet, og hvordan licensen er skruet sammen, før I bygger på det.
Et lag, I køber som tjeneste. Det er hurtigst at komme i gang med. Til gengæld går alle prompter og svar gennem endnu en leverandør. Det er en ny part, der skal vurderes på samme måde som modeludbyderen: hvor kører laget, hvor gemmes logs, hvem ejer leverandøren, og hvilken lov gælder. Spørgsmålene er beskrevet i hvor behandles prompten?.
Hvornår laget giver mening
Et lag giver mest, når flere systemer kalder modeller, når I bruger mere end én udbyder eller vil kunne gøre det, og når I har brug for at kunne se forbrug og adgang samlet. Det giver mindst, når én assistent bruges fra én kontorpakke, for så kalder I ikke modellen selv.
Ser I et lag som vejen til en reserve, hvis den primære model forsvinder, så læs reservemodel. Laget kan sende kaldet videre, men reserven skal være prøvet på jeres opgaver for at være en reserve.
Hvad det kræver, og hvad det koster at lade være
Et lag kræver drift. Det skal opdateres, overvåges, sikres og have en ejer, og det bliver et sted, hvor en fejl stopper alle AI-kald på én gang. Overslaget gives i tid: dage at sætte op, og et fast antal timer om måneden til at holde det ved lige. Købes laget som tjeneste, er der en abonnementspost og en ekstra leverandør at følge.
Lader I være, og vokser brugen, ender kaldene spredt over mange systemer med hver sin nøgle og hver sin måde at håndtere fejl på. Et skifte af model kræver så, at hvert system ændres og testes. Forbruget kan heller ikke ses samlet, så I opdager en dyr arbejdsgang på fakturaen. Det er poster i timer og i manglende overblik.
Det skal I lade være med
- At købe laget som svaret på kvaliteten · laget flytter kaldet og lader modellens evne til opgaven være den samme.
- At glemme, at et købt lag ser alle prompter · vurdér leverandøren som en modeludbyder.
- At bygge mange forretningsregler ind i laget · jo flere, jo tungere er laget selv at skifte.
Det skal valget kunne vise
- ☐ Hvor mange systemer der kalder modeller direkte i dag.
- ☐ Hvilke særlige funktioner hos udbyderen jeres løsninger bruger.
- ☐ Hvem der ejer og driver laget, og hvor det kører.
- ☐ Hvad et skifte af model kræver ud over ændringen i laget.
Kilder
- Udbydernes dokumentation om kompatible grænseflader hos to store udbydere, læst 8. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Tæl, hvor mange steder i jeres systemer en sprogmodel kaldes direkte, og hvilke udbydere der står bag.
Læs også: Agenter og forbindelser · Hvad binder, når I vælger AI?
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
