AI lovar snabbare processer, smartare beslut och högre produktivitet. Samtidigt fattar många organisationer just nu beslut som kan bli betydligt svårare att ta sig ur än de inser.

Frågan är inte bara vilken AI-modell vi ska använda, utan hur vi bygger våra AI-lösningar så att vi fortfarande kan välja fritt om tre, fem eller tio år. När AI blir en del av kärnprocesserna handlar teknikval inte längre bara om effektivitet, utan om kontroll, säkerhet och långsiktig handlingsfrihet.

AI används i den här texten som exempel på teknik för att illustrera utmaningen. Samma mekanik gäller i princip alla teknikval som blir djupt inbäddade i kärnverksamheten, från molnplattformar till specialiserade affärssystem. Det som gör AI till ett särskilt tydligt exempel är hastigheten: organisationer binder upp sig snabbare och djupare än vid tidigare teknikskiften, vilket gör riskerna mer akuta och lättare att se.

AI är också en infrastrukturfråga

Det är lätt att se AI som en tjänst: man kopplar upp sig mot en språkmodell och börjar använda den. Under ytan består varje AI-lösning av flera lager av teknik och beroenden.

Två grundläggande frågor behöver besvaras:

1. Var kommer modellen ifrån? Köps den som en färdig tjänst, bygger den på öppna modellvikter eller utvecklas och anpassas den internt?
2. Var körs modellen? Hos en extern leverantör, i ett eget moln, på egna servrar eller lokalt i verksamheten?

De valen avgör inte bara kostnad och prestanda, utan också vem som kontrollerar data, infrastruktur och möjligheten att byta lösning senare.

Alla beroenden är inte synliga

Många tänker på leverantörsberoende som ett avtal eller en licens. AI introducerar flera typer av beroenden som inte syns i avtalstexten.

Databeroenden: om lösningen bygger på en specifik dataplattform eller ett proprietärt format blir informationen svår att flytta den dag ni vill byta.

Kompetensberoenden: När bara ett fåtal personer förstår hur AI-lösningen fungerar blir organisationen sårbar om de försvinner.

Regulatoriska beroenden: AI-lösningar måste fungera inom GDPR, AI Act och andra regelverk. Om en leverantör inte längre uppfyller kraven kan ni behöva byta snabbare än ni planerat.

Gemensamt för alla tre är att de ofta upptäcks först när något förändras.

Tankeexperiment som avslöjar hur exponerade ni är

Föreställ er att en central AI- eller molnleverantör inte finns tillgänglig i morgon.

För vissa organisationer handlar det om en chatbot som slutar svara. För andra stannar hela automatiserade arbetsflöden, utvecklingsteam tappar produktivitet och interna AI-agenter blir obrukbara. Skillnaden beror nästan helt på hur lösningen är byggd.

Ta en kundtjänstlösning som två organisationer bygger samma vecka. Den ena lägger ett tunt eget lager mellan applikationen och modellen, sparar all ärendehistorik i eget format och loggar anropen. Den andra bygger direkt mot leverantörens SDK, låter promptlogik, ärendedata och affärsregler bo i leverantörens plattform.

Båda fungerar lika bra i produktion. När modellen prishöjs, avvecklas eller inte längre uppfyller ett nytt regulatoriskt krav tar det första bytet några veckor, det andra blir ett långt projekt.

Skillnaden i insats mellan de två arkitekturerna är liten i byggfasen, men avgörande i bytesfasen.

Risken sitter i protokoll och lagringsformat

Det är inte beroendet i sig som är problemet. Alla organisationer är beroende av teknikleverantörer. Den strategiska risken uppstår när leverantören kontrollerar något ni inte enkelt kan återskapa eller flytta. Framför allt gäller det hur systemen kommunicerar med varandra och hur informationen sparas. Bygger de delarna på öppna, dokumenterade standarder blir resten av tekniken betydligt enklare att byta ut.

Lägg sedan till tidsperspektivet. Ett affärssystem kan leva i tio eller tjugo år. AI-leverantörer, molntjänster och modeller kommer att förändras flera gånger under samma period. Verksamhetens viktigaste information behöver överleva enskilda leverantörer.

Teknisk handlingsfrihet är ett bättre begrepp

”Hur blir vi systemoberoende?” är en vanlig men fel fråga. Fullständigt oberoende uppnår bara den som utvecklar och driftar allt själv, och för de flesta är det varken ekonomiskt eller praktiskt rimligt.

Teknisk handlingsfrihet är något annat: förmågan att byta ut delar utan att bygga om allt. Det gör det möjligt att använda marknadens bästa kommersiella AI-tjänster där de skapar värde, utan att låsa fast verksamheten i ett enda ekosystem.

Ett kort projekt med begränsad livslängd kan mycket väl motivera en proprietär tjänst. Ett verksamhetskritiskt system med känslig information ställer helt andra krav. Det viktiga är att beroendena är ett aktivt beslut och inte en bieffekt.

Handlingsfrihet är också en säkerhetsfråga

Teknisk handlingsfrihet är inte bara en IT-fråga. Den påverkar informationssäkerhetens tre grundprinciper direkt:

• Konfidentialitet: vem får tillgång till informationen?
• Riktighet: kan informationen förändras eller manipuleras?
• Tillgänglighet: fungerar systemen när verksamheten behöver dem?

Med kontroll över hur data lagras, överförs och driftas blir det enklare att skydda informationen mot exponering, förvanskning och avbrott. Samtidigt blir frågan affärsstrategisk: om verksamhetskritiska data, kompetens och AI-funktioner koncentreras hos ett fåtal globala leverantörer ökar beroendet av deras teknik, villkor och utvecklingsriktning.

Tre beslut ni kan ångra om fem år

Många AI-investeringar görs just nu under hög tidspress. Risken är att dagens genvägar blir morgondagens begränsningar. Tre beslut sticker ut:

1. Att bygga djupa integrationer mot en enda proprietär AI-leverantör.
2. Att lagra verksamhetskritisk information i odokumenterade eller proprietära format.
3. Att låta AI-kompetens koncentreras till ett fåtal personer eller externa leverantörer.

Alla tre minskar förmågan att ställa om när tekniken eller regelverken förändras.

Tre steg som stärker handlingsfriheten

Ni behöver inte bygga allt själva för att minska risken för inlåsning.

1. Kartlägg hur information lagras: säkerställ att verksamhetskritiska data kan exporteras och läsas i öppna, dokumenterade format som JSON, CSV, Parquet, XML eller databaser som går att läsa via standard SQL.
2. Standardisera integrationerna: dokumentera API:er och integrationspunkter och bygg kommunikationen på etablerade protokoll i stället för leverantörsspecifika lösningar.
3. Bygg för utbytbarhet: separera AI-modellen från resten av applikationen så att modellen kan ersättas utan att hela lösningen skrivs om.

AI förändras snabbt – arkitekturen måste hålla längre

AI-modeller blir bättre. Leverantörerna förändras. Nya regelverk införs. Det är ungefär det enda vi kan vara säkra på.

Den viktigaste frågan är därför inte vilken modell som är bäst idag, utan om ni fortfarande har friheten att välja nästa modell i morgon. Teknisk handlingsfrihet handlar i slutändan inte om att undvika beroenden, utan om att inget enskilt beroende ska kunna avgöra verksamhetens framtid åt er.

Börja med att svara på en enda fråga: om er viktigaste AI-leverantör försvann i morgon, hur lång tid och hur lätt skulle det vara att byta?

Publicerad 29 sep 2026.