AI skulle give virksomheder en fordel. Det kan også skabe et nyt afhængighedsforhold
For få år siden handlede samtalen om vendor lock-in primært om cloud, ERP-systemer, databaser eller centrale teknologiplatforme.
Virksomheder stillede spørgsmål som: Kan vi flytte applikationen til en anden cloud-udbyder?, Kan vi skifte database?, Kan vi forlade et givent system?
I dag tilføjes et nyt element til denne liste - kunstig intelligens.
Organisationer bygger i stigende grad systemer, der bruger sprogmodeller, generativ AI, RAG-løsninger, procesautomatisering og AI-agenter. Modeller bliver en del af applikationer, salgsprocesser, kundeservice, dokumentanalyse, beslutningssystemer og teamenes daglige arbejde.
I praksis betyder det, at en virksomhed kan blive afhængig ikke kun af bestemt software, men også af den specifikke intelligens, der driver dens systemer.
Og her opstår problemet. For det er én ting at bruge en AI-tjeneste. Noget andet er at være afhængig af den.
Det er netop forskellen mellem bevidst teknologisk afhængighed og vendor lock-in.
Hvad er AI Vendor Lock-in egentlig?
Vendor lock-in betyder en situation, hvor en organisation er så bundet til én teknologileverandør, at det bliver vanskeligt, dyrt, tidskrævende eller risikabelt at skifte til en konkurrent.
I AI-verdenen kan det antage langt flere former end den klassiske afhængighed af ét API.
En virksomhed kan være afhængig af:
- en konkret AI-model,
- en specifik API-leverandør,
- et bestemt kommunikationsformat,
- funktioner der kun findes hos én leverandør,
- et agent-system,
- cloud-infrastruktur,
- måden data gemmes på,
- en bestemt embedding-mekanisme,
- et specifikt RAG-system,
- måden agenter kalder værktøjer på,
- prompts optimeret til en bestemt model,
- teamets kompetencer knyttet til ét økosystem.
Derfor er spørgsmålet: "Bruger vi OpenAI?"
alt for simpelt.
Et bedre spørgsmål er: "Hvor svært ville det være for os at skifte AI-leverandør, hvis vi skulle gøre det om seks måneder?"
Hvis svaret er: "Vi ved det ikke." - så kan det være det første advarselstegn.
OpenAI, Anthropic, Google - betyder valget noget?
Markedet har i dag flere stærke model- og tjenesteøkosystemer, blandt andre løsninger fra OpenAI, Anthropic og Google.
Hver af disse leverandører udvikler egne modeller, API’er, værktøjer og supplerende tjenester.
Problemet er ikke, at nogen af dem er "onde". Tværtimod.
At bruge færdige, højkvalitetsmodeller er ofte den bedste forretningsmæssige løsning. Ikke alle virksomheder bør træne deres egen model. Ikke alle har brug for egen GPU-infrastruktur. Ikke alle bør bygge hele AI-stakken fra bunden.
At benytte en ekstern leverandør gør det hurtigere at komme på markedet, reducerer startomkostninger og giver adgang til teknologi, som de fleste organisationer ikke selv kunne udvikle.
Problemet begynder, når en virksomhed holder op med at se leverandøren som en udskiftelig komponent og begynder at designe sit produkt, som om den valgte leverandør vil forblive uændret i de næste ti år.
Og det kan man ikke garantere...
Modeller opdateres, ældre versioner udfases, priser og grænser ændres, API’er ændres, nye modeller dukker op, licensbetingelser udvikler sig, konkurrenceforhold ændres.
Det er en normal del af teknologi-markedet.
Derfor bør AI-arkitektur ikke kun spørge: "Hvilken model er bedst i dag?"
men også: "Hvad koster det os, hvis vi om et år vil bruge en anden?"
Den største fælde - "vi skifter bare API"
På overfladen kan migration se triviel ud.
Vi har en applikation. Den sender en forespørgsel til en model. Modellen svarer. Vi skifter leverandør. Færdig...
I virkeligheden kan situationen være helt anderledes.
Forestil dig en applikation, der i to år er bygget omkring én model.
I denne tid har teamet:
- skrevet hundredvis af prompts,
- optimeret deres indhold,
- tilpasset svarformatet,
- bygget et RAG-system,
- konfigureret tool-calling,
- opbygget agenter,
- designet workflows,
- udarbejdet tests,
- lært brugerne at arbejde med systemet.
Efter to år viser det sig, at modellen ikke længere er tilgængelig i sin tidligere form.
Enten stiger prisen, en konkurrerende model er markant bedre, eller virksomheden ønsker at flytte data til et andet miljø.
Teoretisk er det nok at skifte API - i praksis kan det vise sig, at hele systemets logik skal testes og justeres igen.
Hvorfor?
Fordi modeller ikke er identiske:
- De fortolker instruktioner forskelligt.
- De leverer forskellig svar-kvalitet.
- De opfører sig forskelligt i langt kontekst.
- De bruger værktøjer forskelligt.
- De håndterer struktureret output forskelligt.
- De varierer i multimodal kapacitet.
- De har forskellige latenstider.
- De har forskellige priser.
- Og de adskiller sig i edge-cases.
Derfor kan migration mellem modeller ligne migration af et helt forretningskomponent snarere end blot at ændre en URL.
Fem niveauer af AI Vendor Lock-in
Det er nyttigt at betragte vendor lock-in bredere.
1. Model-lock-in
Det enkleste niveau.
Applikationen er optimeret til en bestemt model.
En prompt fungerer glimrende med én model, men dårligere med en anden.
Systemet bygger på specifikke muligheder i den givne model.
At skifte kræver genjustering.
2. API-lock-in
Systemet bruger direkte funktioner fra en bestemt leverandør.
Jo flere specifikke funktioner vi bruger, desto vanskeligere kan migration blive.
Det handler ikke kun om at generere tekst.
Også betydningsfuldt er:
- structured outputs,
- function calling,
- tool calling,
- multimodalitet,
- kontekststyring,
- sikkerhedsmekanismer,
- agent-systemer.
3. Data-lock-in
Data kan være gemt på måder, der er stærkt bundet til et bestemt økosystem.
Det gælder også:
- embeddings,
- vektorindekser,
- metadata,
- interaktionshistorik,
- RAG-konfigurationer.
Migration kan kræve ikke blot flytning af data, men også deres genbehandling.
4. Arkitektur-lock-in
Dette niveau er langt mere alvorligt.
Hele applikationen er designet omkring én leverandør.
Dens mekanismer findes mange steder i systemet.
I så fald udskifter man ikke blot en komponent.
Man genopbygger en del af arkitekturen.
5. Organisations-lock-in
Dette er ofte det mest undervurderede problem.
Teamet kender kun ét økosystem.
Alle kompetencer er centreret omkring én løsning.
Dokumentation, procedurer, tests og know-how er bundet til én leverandør.
Selv hvis det teknisk set er muligt at skifte model, har organisationen ikke folk, der kan gennemføre det.
Så bliver vendor lock-in ikke længere kun et teknisk problem.
Det bliver et forretningsproblem.
Løser Multi-Model problemet?
Den naturlige reaktion er: "Hvis én leverandør er en risiko, så brug flere."
Det er dog ikke altid den bedste strategi.
En multi-model arkitektur har sine omkostninger.
Man skal håndtere:
- flere API’er,
- forskellige grænser,
- forskellige prismodeller,
- forskellige kvalitetsniveauer,
- forskellige svarformater,
- tests,
- monitorering,
- sikkerhed.
Systemet bliver mere komplekst.
Derfor bør målet ikke være: "Vi skal bruge fem leverandører."
Målet bør være: "Vi skal have mulighed for at skifte leverandør, hvis forretningen kræver det."
Det er en væsentlig forskel.
Ikke alle virksomheder har brug for Multi-Model.
Men alle virksomheder bør kende hvordan en migration til en anden model ville se ud.
AI Gateway og Model Gateway - et lag der adskiller appen fra leverandøren
En måde at reducere afhængighed på er at indsætte et mellemlag.
Det kan fungere som en AI Gateway eller Model Gateway.
Forenklet kan arkitekturen se sådan ud:
Forretningsapplikation
↓
AI-abstraktionslag
↓
Model-routing
↓
Provider-adapter
↓
OpenAI / Anthropic / Google / open-weight model / lokal model
Dermed behøver forretningslogikken ikke kende detaljerne i hver leverandør.
Vi kan have et lag ansvarligt for:
- modelvalg,
- routing,
- fallback,
- omkostningskontrol,
- monitorering,
- logning,
- sikkerhedspolitikker,
- grænse- og quota-styring.
Hvis en leverandør går ned, kan systemet forsøge et alternativt modelkald.
Hvis prisen stiger, kan vi ændre routing.
Hvis en bedre model dukker op, kan vi teste og beslutte en migration.
Det betyder ikke, at skift altid bliver smertefrit.
Men det betyder, at skiftet er designet som en realistisk mulighed.
Model Router - AI behøver ikke altid vælge samme model
Endnu mere interessant er model-routing.
Forestil dig et system, der modtager forskellige opgaver.
En simpel opgave: "Sammenfat denne tekst."
Kan sendes til en hurtig og billig model.
En mere kompleks opgave: "Analyser dokumentet og udarbejd en detaljeret anbefaling."
Bør sendes til en stærkere model.
En opgave der kræver billedanalyse, bør sendes til en multimodal model.
Systemet kan dermed dynamisk vælge model til opgaven.
Det optimerer:
- omkostninger,
- kvalitet,
- svarstid,
- tilgængelighed.
I dette scenarie er AI-leverandøren ikke en integreret del af forretningslogikken.
Den bliver blot et element i infrastrukturen.
Det er en vigtig arkitektonisk ændring.
Abstraktion betyder ikke, at alle modeller er ens
Her skal man passe på en fælde.
Man kan lave en funktion som: generateText() og tro, at problemet er løst.
Det er det ikke.
Modeller er ikke udskiftelige LEGO-klodser.
Hvis applikationen benytter specifikke funktioner i en model, kan en simpel abstraktion blot skjule problemet.
God arkitektur bør derfor abstrahere fra leverandøren, men samtidig bevidst håndtere forskellene mellem modeller.
I praksis betyder det, at AI-laget bør kende til forskelle i:
- kapabiliteter,
- grænser,
- omkostninger,
- kvalitetsniveauer,
- funktioner,
- kontekster,
- parametre.
At være "provider-agnostic" bør ikke betyde, at man lader som om alle modeller er ens.
Det bør betyde, at systemet bevidst kan udnytte forskelle mellem modeller.
Evals - uden dem er AI-migration gætteri
Et af de vigtigste elementer i en migrationstolerant arkitektur er evals, altså systematiske tests af modellernes ydeevne.
Antag at vi har 1000 reelle use-cases. Vi kører dem på den nuværende model. Derefter kører vi dem på den nye. Vi sammenligner resultaterne.
Vi måler på:
- kvalitet,
- korrekthed,
- komplethed,
- hallucinationer,
- overholdelse af krav,
- svarstid,
- omkostning.
Først da kan vi sige: "Den nye model er god nok."
Uden evals bliver migration et eksperiment. Med evals bliver det en ingeniørproces.
Derfor bør en AI-brugende virksomhed bygge egne test-suiter. Ikke kun teste API’et. Teste den egne forretningscase. Det er en stor forskel.
Prompts kan også være kilde til vendor lock-in
Prompts behandler vi ofte som fritekst. I praksis kan de blive en del af forretningslogikken.
Hvis et team i månedsvis optimerer instruktioner til en model, kan prompten begynde at virke som kode.
Derfor bør prompts være:
- versionerede,
- testede,
- dokumenterede,
- monitorerede.
Det er også vigtigt at vide, hvilke prompts der er kritiske for systemets funktion. Hvis modelskift forringer deres effektivitet, skal vi vide, hvor vi skal lede efter fejlen.
I modne AI-systemer bør prompt engineering behandles mere og mere som software engineering.
Open-weight og egne modeller - er det en flugt fra vendor lock-in?
Open-weight modeller og muligheden for at køre modeller i egen infrastruktur øger kontrollen over teknologien.
Men det betyder ikke automatisk fuldstændig uafhængighed.
Hvis vi flytter en model til egen infrastruktur, har vi stadig brug for:
- GPU’er,
- infrastruktur,
- MLOps,
- monitorering,
- sikkerhed,
- opdateringer,
- kompetencer.
Vi kan dermed reducere afhængigheden af en model-leverandør, men øge afhængigheden af infrastruktur-leverandører. Vi kan også køre open-weight modeller i cloud; så flytter problemet sig til et andet niveau. Derfor bør man se teknologisk uafhængighed bredere.
Der findes ikke et system helt uden afhængigheder.
Der findes derimod systemer, hvor afhængigheder er:
- kendte,
- kontrollerede,
- målbare,
- udskiftelige.
Den farligste vendor lock-in kan sidde i teamets hoveder
Forestil dig en virksomhed, der bruger én AI-leverandør.
Teknisk kan den skifte model. Men ingen i virksomheden ved, hvordan.
Teamet kender ikke alternativer.
Der er ingen benchmarks.
Ingen evals.
Ingen tests.
Ingen erfaring med andre modeller.
Alle løsninger er bygget omkring ét økosystem.
Det er organisatorisk lock-in.
Derfor kræver modstandsdygtighed mod vendor lock-in også investering i kompetencer.
Teamet bør forstå:
- hvordan modeller fungerer,
- hvad forskellene mellem leverandører er,
- hvordan man bygger abstraktionslag,
- hvordan man tester modeller,
- hvordan man måler kvalitet,
- hvordan man styrer omkostninger,
- hvordan man gennemfører migration.
Det handler ikke om, at hver udvikler skal kende hvert API.
Det handler om, at organisationen ikke skal være teknologisk blind overfor ét økosystem.
Når vendor lock-in kan være acceptabelt
Vendor lock-in er ikke altid dårligt.
Nogle gange er en bevidst afhængighed en fornuftig forretningsbeslutning.
Hvis:
- leverandøren tilbyder en unik funktion,
- løsningen markant forkorter time-to-market,
- migreringsomkostningen er kendt,
- risikoen er acceptabel,
- alternativerne er svagere,
- forretningen har brug for hastighed,
så kan en tæt binding til en leverandør være begrundet.
Problemet er ikke selve lock-in. Problemet er ubevidst lock-in.
Virksomheden bør vide:
- hvad den er afhængig af,
- hvorfor den er afhængig,
- hvad skiftet ville koste,
- hvor lang tid en migration ville tage,
- hvad alternativerne er.
Først derefter kan man tale om en bevidst arkitektonisk beslutning.
Hvordan vurdere AI Vendor Lock-in i din virksomhed?
Det er værd at gennemføre en simpel revision.
Spørg dig selv:
Kan vi skifte model uden at genopbygge hele applikationen?
Er forretningslogikken uafhængig af AI-leverandøren?
Er prompts versioneret?
Har vi egne evals?
Har vi regressions-tests for de vigtigste use-cases?
Kan vi eksportere og flytte vores data?
Kan vi skifte embedding-leverandør uden datatab?
Bruger agenter et orkestrationslag, eller er de direkte bundet til et økosystem?
Har vi mulighed for at bruge en alternativ model?
Har vi fallback?
Ved vi, hvad migration ville koste?
Ved vi, hvor lang en migration ville tage?
Har vi folk, der kan gennemføre den?
Jo flere "nej"-svar, desto større afhængighed.
Man kan også skabe sin egen AI Portability Score. Fx vurdere organisationen på fem områder:
Arkitektur - er leverandøren udskiftelig?
Data - kan vi flytte dem?
Modeller - har vi alternativer?
Evaluering - kan vi sammenligne modeller?
Kompetencer - kan teamet gennemføre migration?
En sådan score behøver ikke være formel. Den kan dog være et stærkt ledelsesværktøj.
For nogle gange er det største problem ikke vendor lock-in, men at virksomheden ikke aner, at den har det.
Hvordan designe AI-arkitektur modstandsdygtig overfor ændringer?
Der findes ikke én universel arkitektur. Men man kan følge nogle praktiske principper.
Princip 1 - adskil forretningslogik fra AI-leverandøren
Byg ikke hele systemet direkte omkring ét API.
Princip 2 - brug abstraktionslag hvor det giver mening
En AI Gateway eller Model Gateway kan reducere applikationens afhængighed af en leverandør.
Princip 3 - versionér prompts
Behandle dem som systemkomponenter, ikke løse tekster.
Princip 4 - byg evals
Antag ikke, at "den nye model virker".
Test det.
Princip 5 - test alternativer
Du behøver ikke bruge dem i produktion.
Men det er godt at vide, hvordan de klarer dine use-cases.
Princip 6 - kontroller data
Lad ikke dine forretningsdata blive gidsel for én platform.
Princip 7 - dokumentér afhængigheder
Viden om, hvor systemet er bundet til en leverandør, bør være en del af arkitekturdokumentationen.
Princip 8 - abstrahér ikke for enhver pris
Skjul ikke forskelle mellem modeller kun for at opnå skinnet af portabilitet.
Princip 9 - mål migreringsomkostninger
Det er ikke nok at sige: "Vi kan skifte leverandør en dag."
Du skal vide:
"Det kræver tre måneder og fem personer."
Eller:
"Vi kan ikke gøre det uden arkitekturændring."
Princip 10 - tag informerede beslutninger
Nogle gange vil det bedste være at binde sig til én leverandør.
Men det bør være en bevidst risiko.
Ikke en tilfældighed.
Spørgsmålet enhver CTO bør stille
Forestil dig, at din AI-leverandør i morgen:
- doublerer priserne,
- udfaser den model vi bruger,
- ændrer grænser,
- begrænser en funktion, som dit produkt afhænger af,
- eller ikke længere opfylder vores compliance-krav.
Hvad gør vi?
Hvis svaret er: "Vi skifter leverandør."
Så bør det næste spørgsmål være: "Hvor lang tid tager det?"
En dag?
En uge?
En måned?
Et halvt år?
Eller ved vi det ikke?
Det er målet for vores teknologiske modstandsdygtighed.
Opsummering - det handler ikke om ikke at have en leverandør
At bygge et fuldstændigt uafhængigt AI-system fra eksterne leverandører kan være urentabelt, unødvendigt eller endda umuligt.
Det er ikke målet.
Målet er bevidst styring af afhængigheder.
Vi kan bruge OpenAI. Vi kan bruge Anthropic. Vi kan bruge Google. Vi kan bruge open-weight modeller. Vi kan kombinere løsninger.
Det vigtigste er at vide, hvor grænsen går mellem: "vi bruger teknologi" og "vi er afhængige af den".
I AI-verdenen kan den grænse være særlig svær at se. Vendor lock-in opstår ikke på én dag. Det sker gradvist. Først integrerer vi et API. Så bygger vi en funktion. Så tilføjer vi RAG. Så agenter. Så automatiserer vi processer. Så begynder hele teamet at arbejde efter systemet. Og pludselig er et modelskift ikke længere blot et modelskift - det er en ændring af en del af organisationen.
Derfor bør AI-arkitektur designes med tanke på ikke kun hvad der virker i dag, men også hvad der sker, hvis teknologiverdenen ændrer sig i morgen.
Du behøver ikke bygge et system, der kører uden OpenAI, Anthropic eller Google. Men du bør bygge et system, der også kan fungere, hvis en af dem forsvinder.
Det er netop forskellen mellem at bruge AI og at designe AI-teknologi bevidst.
