AI skulle ge företag fördelar. Det kan också skapa ett nytt beroende
För bara några år sedan handlade samtal om vendor lock-in främst om moln, ERP‑system, databaser eller centrala tekniska plattformar.
Företag ställde frågor: Kan vi flytta applikationen till en annan molnleverantör? Kan vi byta databas? Kan vi lämna ett visst system?
Idag läggs ett nytt element till den listan – artificiell intelligens.
Organisationer bygger allt oftare system som använder språkliga modeller, generativ AI, RAG‑lösningar, processautomation och AI‑agenter. Modeller blir del av applikationer, säljprocesser, kundservice, dokumentanalys, beslutsstöd och teamens dagliga arbete.
I praktiken betyder det att ett företag kan börja bli beroende inte bara av en viss programvara utan också av en viss leverantör av intelligens som används i dess system.
Och här uppstår problemet. För att använda en AI‑tjänst är en sak. Att vara beroende av den är en annan.
Det är just skillnaden mellan ett medvetet teknologiskt beroende och vendor lock‑in.
Vad är egentligen AI Vendor Lock‑in?
Vendor lock‑in innebär en situation där en organisation är så starkt bunden till en leverantör av teknologi att övergång till en konkurrent blir svår, kostsam, tidskrävande eller riskfylld.
I AI‑världen kan det ta fler former än det klassiska beroendet av ett enda API.
Företaget kan vara beroende av:
- en specifik AI‑modell,
- en viss API‑leverantör,
- ett bestämt kommunikationsformat,
- funktioner som endast finns hos en leverantör,
- ett agent‑system,
- molninfrastruktur,
- sättet data lagras på,
- en specifik embeddings‑mekanism,
- ett specifikt RAG‑system,
- sättet agenter kallar verktyg,
- prompts optimerade för en viss modell,
- teamets kompetenser knutna till ett ekosystem.
Därför är frågan: "Använder vi OpenAI?"
alltför enkel.
En bättre fråga är: "Hur svårt skulle det vara för oss att byta AI‑leverantör om vi behövde göra det om sex månader?"
Om svaret är: "Vi vet inte." – kan det vara en första varningssignal.
OpenAI, Anthropic, Google – spelar valet av leverantör roll?
På marknaden finns idag flera mycket starka ekosystem av modeller och AI‑tjänster, bland annat lösningar från OpenAI, Anthropic och Google.
Var och en av dessa leverantörer utvecklar egna modeller, API:er, verktyg och tilläggstjänster.
Problemet är inte att någon av dem är "ond". Tvärtom.
Att använda färdiga, högkvalitativa modeller är ofta det bästa affärsmässiga valet. Inte alla företag bör träna en egen modell. Inte alla behöver egen GPU‑infrastruktur. Inte alla bör bygga hela AI‑stacken från grunden.
Att använda en extern leverantör möjliggör snabbare time‑to‑market, lägre initiala kostnader och tillgång till teknologi som vore utom räckhåll att utveckla på egen hand.
Problemet börjar när ett företag slutar se leverantören som en utbytbar komponent och istället bygger hela produkten som om den valda leverantören skulle finnas oförändrad i tio år.
Och det kan man inte garantera…
Modeller uppdateras, äldre versioner fasas ut, priser förändras, begränsningar ändras, API:er ändras, nya modeller dyker upp, licensvillkor ändras, konkurrensmöjligheter förändras.
Det är en normal del av teknologimarknaden.
Därför bör AI‑arkitektur beakta inte bara: "Vilken modell är bäst idag?"
utan också: "Vilken kostnad får vi om vi om ett år vill använda en annan?"
Den största fallgropen – "vi byter bara API"
Vid första anblick kan migration verka trivial.
Vi har en applikation. Applikationen skickar en förfrågan till modellen. Modellen svarar. Vi byter leverantör. Klart.
I verkligheten kan situationen se helt annorlunda ut.
Föreställ dig en applikation som utvecklats runt en modell under två år.
Under den tiden har teamet:
- skapade hundratals prompts,
- optimerat deras innehåll,
- anpassat svarens format,
- byggt ett RAG‑system,
- konfigurerat tool‑calling,
- skapade agenter,
- designat arbetsflöden,
- förberett tester,
- lärt användarna hur systemet fungerar.
Efter två år visar det sig att modellen inte längre är tillgänglig i samma version.
Eller priset stiger, eller en konkurrerande modell är klart bättre, eller företaget vill flytta delar av data till en annan miljö.
Teoretiskt räcker det att byta API. I praktiken kan det krävas att hela systemlogiken testas om.
Varför?
För att modeller inte är identiska:
- De tolkar instruktioner olika.
- De ger svar av varierande kvalitet.
- De beter sig olika i långt kontextläge.
- De använder verktyg olika.
- De hanterar structured output olika.
- De är olika multimodala.
- De har olika svarstider.
- De har olika prissättning.
- De beter sig även olika i gränsfall.
Därför kan migrering mellan modeller likna migrering av en hel affärskomponent snarare än en enkel URL‑ändring.
Fem nivåer av AI Vendor Lock‑in
Det är värt att se vendor lock‑in i ett bredare perspektiv.
1. Modell‑lock‑in
Den enklaste nivån.
Applikationen är optimerad för en specifik modell.
En prompt fungerar utmärkt mot en modell men sämre mot en annan.
Systemet bygger på egenskaper hos just den modellen.
Byte innebär behov av omskruvning.
2. API‑lock‑in
Systemet använder direkt funktioner från en viss leverantör.
Ju fler specifika funktioner vi använder, desto svårare blir migrationen.
Det handlar inte bara om textgenerering.
Betydelsefulla element är också:
- structured outputs,
- function calling,
- tool calling,
- multimodalitet,
- kontexthantering,
- säkerhetsmekanismer,
- agent‑system.
3. Data‑lock‑in
Data kan vara lagrade på ett sätt starkt kopplat till ett ekosystem.
Det gäller även:
- embeddings,
- vektorindex,
- metadata,
- interaktionshistorik,
- RAG‑konfigurationer.
Migration kan kräva inte bara överföring utan även omskapat data‑arbete.
4. Arkitektur‑lock‑in
En mer allvarlig nivå.
Hela applikationen är designad runt en leverantör.
Dess mekanismer finns på många ställen i systemet.
I ett sådant fall byter man inte en komponent.
Man bygger om delar av arkitekturen.
5. Organisations‑lock‑in
Detta är ofta det mest förbisett problemet.
Teamet kan ett ekosystem.
All kompetens är centrerad kring en lösning.
Dokumentation, processer, tester och know‑how är bundna till en leverantör.
Även om det tekniskt går att byta modell, saknar organisationen människor som kan genomföra bytet.
Då blir vendor lock‑in inte bara ett tekniskt problem utan ett affärsproblem.
Löser Multi‑Model problemet?
Naturligt svar: "Om en leverantör är en risk, använd flera."
Det är dock inte alltid den bästa strategin.
En multi‑model arkitektur medför kostnader.
Man måste hantera:
- flera API:er,
- olika begränsningar,
- olika prisstruktur,
- olika kvalitetsnivåer,
- olika svarformat,
- tester,
- övervakning,
- säkerhet.
Systemet blir mer komplext.
Målet bör inte vara: "Vi måste använda fem leverantörer."
Målet bör vara: "Vi måste kunna byta leverantör om affären kräver det."
Den skillnaden är avgörande.
Inte alla företag behöver Multi‑Model.
Men varje företag bör veta hur en migrering till en annan modell skulle se ut.
AI Gateway och Model Gateway – ett lager som separerar applikationen från leverantören
Ett sätt att minska beroendet är att införa ett mellanlager.
Det kan fungera som en AI Gateway eller Model Gateway.
Förenklat kan arkitekturen se ut så här:
Affärsapplikation
↓
Abstraktionslager för AI
↓
Model Routing
↓
Adapter för leverantör
↓
OpenAI / Anthropic / Google / open‑weight modell / lokal modell
Då behöver inte affärslogiken känna varje leverantörs detaljer.
Vi kan ha ett lager ansvarigt för:
- modellval,
- routing,
- fallback,
- kostnadskontroll,
- övervakning,
- loggning,
- säkerhetspolicyer,
- gränsöverskridande hantering.
Vid fel hos en leverantör kan systemet försöka en annan modell.
Vid prisökning kan vi ändra routing.
När en bättre modell dyker upp kan vi testa och besluta om migrering.
Det betyder inte att bytet alltid blir smärtfritt.
Men det gör det till en realistisk möjlighet.
Model Router – AI behöver inte alltid välja samma modell
Ett ännu intressantare koncept är model routing.
Föreställ dig ett system som tar emot olika typer av uppgifter.
En enkel uppgift: "Sammanfatta denna text."
Kan skickas till en snabb och billig modell.
En mer komplex uppgift: "Analysera dokumentet och förbered en detaljerad rekommendation."
Kan skickas till en kraftfullare modell.
En uppgift som kräver bildanalys kan gå till en multimodal modell.
Systemet kan alltså dynamiskt välja modell per uppgift.
Det optimerar:
- kostnader,
- kvalitet,
- svarstid,
- tillgänglighet.
I det här tillvägagångssättet blir leverantören en komponent i infrastrukturen, inte en integrerad del av affärslogiken.
Det är en viktig arkitektonisk förändring.
Abstraktion betyder inte att alla modeller är lika
Här måste man vara försiktig med en fallgrop.
Man kan implementera en funktion som generateText() och tro att problemet är löst.
Det är det inte.
Modeller är inte utbytbara LEGO‑bitar.
Om applikationen använder specifika möjligheter hos en modell kan enkel abstraktion bara dölja problemet.
Bra arkitektur bör därför abstrahera från leverantören men samtidigt medvetet hantera skillnader mellan modellerna.
I praktiken innebär det att AI‑lagret bör känna till att modeller kan ha olika:
- möjligheter,
- begränsningar,
- kostnader,
- kvalitetsnivåer,
- funktioner,
- kontexter,
- parametrar.
Att vara provider‑agnostic bör inte betyda att låtsas som att alla modeller är lika. Det bör betyda att systemet kan utnyttja skillnaderna medvetet.
Evals – utan dem är AI‑migration gissningslek
En av de viktigaste delarna i en arkitektur som är motståndskraftig mot byten är evals, alltså systematiska tester av modellernas kvalitet.
Anta att vi har 1000 verkliga användningsfall. Vi kör dem mot den nuvarande modellen. Sedan kör vi dem mot en ny. Vi jämför resultat.
Vi kontrollerar:
- kvalitet,
- korrekthet,
- kompletthet,
- hallucinationer,
- överensstämmelse med krav,
- svarstid,
- kostnad.
Först då kan vi säga: "Den nya modellen är tillräckligt bra."
Utan evals blir migration ett experiment. Med evals blir det en ingenjörsprocess.
Därför bör företag som använder AI bygga egna testsviter. Inte bara testa API:et. Testa ert eget affärsfall. Det är en stor skillnad.
Prompts kan också vara en källa till vendor lock‑in
Prompts behandlas ofta som text. I praktiken kan de bli en del av affärslogiken.
Om ett team under månader optimerar instruktioner för en viss modell kan prompten börja fungera som kod.
Därför bör de vara:
- versionerade,
- testade,
- dokumenterade,
- övervakade.
Det är också viktigt att veta vilka prompts som är kritiska för systemets funktion. Om ett modellbyte försämrar deras effektivitet måste vi veta var vi ska leta efter problemet.
Därför bör prompt engineering i mogna AI‑system behandlas mer och mer som en del av mjukvaruutveckling.
Open‑weight och egna modeller – är det flykt från vendor lock‑in?
Open‑weight‑modeller och möjligheten att köra modeller i egen infrastruktur ökar kontrollen över teknologin.
Men det betyder inte automatiskt fullständig oberoende.
Om vi flyttar en modell till vår egen infrastruktur behöver vi fortfarande:
- GPU:er,
- infrastruktur,
- MLOps,
- övervakning,
- säkerhet,
- uppdateringar,
- kompetens.
Vi kan alltså minska beroendet av modellleverantören men samtidigt öka beroendet av infrastrukturleverantörer. Vi kan även köra open‑weight i molnet – då flyttas problemet delvis till en annan nivå. Därför bör man betrakta teknologiskt oberoende i ett bredare perspektiv.
Inget system är helt fritt från beroenden.
Det finns däremot system där beroendena är:
- kända,
- kontrollerade,
- mätbara,
- möjliga att ersätta.
Det farligaste vendor lock‑inet kan sitta i teamets huvuden
Föreställ dig ett företag som använder en leverantörs AI.
Tekniskt kan det byta modell. Men ingen i företaget vet hur.
Teamet känner inga alternativ.
Det finns inga benchmark.
Inga evals.
Inga tester.
Ingen erfarenhet av andra modeller.
Alla lösningar byggdes runt ett ekosystem.
Det är organisations‑lock‑in.
Därför kräver motståndskraft mot vendor lock‑in också investering i kompetens.
Teamet bör förstå:
- hur modeller fungerar,
- vilka skillnader som finns mellan leverantörer,
- hur man bygger abstraktionslager,
- hur man testar modeller,
- hur man mäter kvalitet,
- hur man hanterar kostnader,
- hur man genomför en migrering.
Det handlar inte om att varje utvecklare ska kunna varje API.
Det handlar om att organisationen inte ska vara tekniskt blind utanför ett ekosystem.
När kan vendor lock‑in vara acceptabelt?
Vendor lock‑in är inte alltid dåligt.
Ibland är ett medvetet beroende en rimlig affärsbeslut.
Om:
- leverantören erbjuder en unik funktion,
- lösningen kraftigt reducerar time‑to‑market,
- kostnaden för migration är känd,
- risken är acceptabel,
- alternativen är svagare,
- affären kräver snabbhet,
kan ett starkare band till en leverantör vara motiverat.
Problemet är inte själva lock‑inet. Problemet är omedvetet lock‑in.
Företaget bör veta:
- vad det är beroende av,
- varför det är beroende,
- hur mycket ett byte skulle kosta,
- hur lång tid en migrering skulle ta,
- vilka alternativ som finns.
Först då kan beslutet anses vara en medveten arkitektur‑beslut.
Hur bedöma AI Vendor Lock‑in i ditt företag?
Det är bra att göra en enkel revision.
Ställ frågorna:
Kan vi byta modell utan att bygga om hela applikationen?
Är affärslogiken oberoende av AI‑leverantören?
Är prompts versionerade?
Har vi egna evals?
Har vi regressionstester för de viktigaste användningsfallen?
Kan vi exportera och flytta våra data?
Kan vi byta embeddings‑leverantör utan dataförlust?
Använder agenter ett orkestreringslager eller är de direkt bundna till ett ekosystem?
Har vi möjlighet att använda ett alternativt modell?
Har vi fallback?
Vet vi hur mycket migration skulle kosta?
Vet vi hur lång tid en migration tar?
Har vi människor som kan genomföra den?
Ju fler svar "nej", desto större beroende.
Man kan också skapa ett eget AI Portability Score. Till exempel bedöma organisationen i fem områden:
Arkitektur – är leverantören utbytbar?
Data – kan vi flytta dem?
Modeller – finns alternativ?
Evals – kan vi jämföra modeller?
Kompetens – kan teamet genomföra migration?
Ett sådant resultat behöver inte vara en formell standard. Det kan dock vara ett mycket bra ledningsverktyg.
Ibland är det största problemet inte vendor lock‑in. Det största problemet är att företaget inte vet att det har det.
Hur designa AI‑arkitektur som tål förändring?
Det finns ingen universell arkitektur. Men några praktiska principer kan följas.
Princip 1 - separera affärslogik från AI‑leverantör
Bygg inte hela systemet direkt runt ett API.
Princip 2 - använd abstraktionslager där det är meningsfullt
AI Gateway eller Model Gateway kan minska applikationens beroende av en specifik leverantör.
Princip 3 - versionera prompts
Behandla dem som systemkomponenter, inte lösa texter.
Princip 4 - bygg evals
Anta inte att "ny modell fungerar".
Testa det.
Princip 5 - testa alternativ
Du behöver inte använda dem i produktion.
Men det är bra att veta hur de hanterar dina användningsfall.
Princip 6 - kontrollera data
Låt inte dina affärsdata bli gisslan hos en plattform.
Princip 7 - dokumentera beroenden
Kunskap om var systemet är bundet till en leverantör är en del av arkitekturens dokumentation.
Princip 8 - abstrahera inte i onödan
Dölj inte skillnader mellan modeller bara för att få skenbar portabilitet.
Princip 9 - mät migrationskostnad
Det räcker inte att säga:
"Vi kan byta leverantör någon gång."
Du måste veta:
"Det kräver tre månader och fem personer."
Eller:
"Vi kan inte göra det utan ombyggnad."
Princip 10 - fatta medvetna beslut
Ibland är det bästa att vara starkt knuten till en leverantör.
Men det ska vara ett medvetet risktagande.
Inte en slump.
Frågan varje CTO bör ställa
Föreställ dig att leverantören imorgon:
- fördubblar priserna,
- drar tillbaka den modell vi använder,
- ändrar begränsningar,
- begränsar en funktion som vår produkt är beroende av,
- slutar uppfylla våra compliance‑krav.
Vad gör vi?
Om svaret är: "Vi byter leverantör."
bör nästa fråga vara: "Hur lång tid tar det?"
En dag?
En vecka?
En månad?
Ett halvår?
Eller vet vi inte?
Detta är måttet på vår tekniska motståndskraft.
Sammanfattning - det handlar inte om att inte ha leverantörer
Att bygga ett system helt oberoende av externa AI‑leverantörer kan vara olönsamt, onödigt eller rentav omöjligt.
Det är inte poängen.
Målet är inte att eliminera beroenden. Målet är medveten hantering av beroenden.
Vi kan använda OpenAI. Vi kan använda Anthropic. Vi kan använda Google. Vi kan använda open‑weight‑modeller. Vi kan kombinera olika lösningar.
Det viktigaste är att veta var gränsen går mellan: "vi använder teknologin" och "vi är beroende av den".
I AI‑världen kan den gränsen vara särskilt svår att se. Vendor lock‑in uppstår inte på en dag. Det uppstår gradvis. Först integrerar vi ett API. Sedan bygger vi en funktion. Sedan lägger vi till RAG. Sedan agenter. Sedan automatiserar vi en process. Sedan börjar hela teamet arbeta enligt detta system. Och plötsligt visar det sig att ett modellbyte inte längre bara är ett modellbyte – det är en förändring av delar av organisationen.
Därför bör AI‑arkitektur designas med tanke på inte bara vad som fungerar idag utan också vad händer när teknologivärlden förändras imorgon.
Du behöver inte bygga ett system som fungerar utan OpenAI, Anthropic eller Google. Du bör dock bygga ett system som också kan fungera den dag någon av dem saknas.
Det är skillnaden mellan att använda AI och att medvetet designa AI‑teknologi.
