En sprogmodel, der bruges i daglige arbejdsgange, er en leverandørafhængighed på linje med et ERP-system eller en mailplatform. Forskellen er, at modellen typisk har en fastsat udløbsdato, og at et skifte kan ændre de resultater, organisationen får.
Artiklen viser, hvad en AI-binding består af, hvad udbyderne selv lover om levetid og varsel, og hvordan AI kortlægges og testes som en del af exit-planen.
Hvad en AI-binding består af
En AI-løsning hviler sjældent på ét produkt. Den består typisk af en model, en platform, der leverer modellen, et datacenter, hvor beregningen sker, og en programmeringsgrænseflade, som egne systemer kalder.
Omkring dem ligger organisationens eget arbejde. Instruktioner og skabeloner til modellen, testsæt, tilpassede modeller, vektordatabaser med indlejrede dokumenter og integrationer i fagsystemer. Meget af det er skrevet til én bestemt model eller platform og skal efterprøves eller laves om ved et skifte.
Hertil kommer brugerne. Medarbejdere, der har vænnet sig til én assistent i kontorpakken eller browseren, mærker et skifte som en ændring i deres arbejdsgang. Bindingen kan derfor sidde flere steder på én gang. Kontrakten kan være kort, mens de tekniske tilpasninger gør et skifte langsomt og dyrt.
Hvad IBM’s undersøgelse viser
IBM Institute for Business Value offentliggjorde 17. juni 2026 undersøgelsen The Calculus of AI Sovereignty. Undersøgelsen hviler på besvarelser fra 1.000 topledere i 16 lande og 17 brancher, indsamlet med Oxford Economics fra februar til april 2026.
Ifølge IBM vurderer 71 procent af de adspurgte, at et skifte af deres primære AI-leverandør eller model ville blive vanskeligt. 91 procent siger, at de ikke fuldt ud forstår organisationens afhængigheder på tværs af AI-leverandører, modeller og infrastruktur.
De adspurgte melder om gennemsnitligt seks AI-relaterede afbrydelser på to år, især udløst af leverandørernes tjenester. 81 procent siger, at syv dages nedbrud hos leverandøren ville give alvorlige eller kritiske forstyrrelser. IBM vurderer, at kun 7 procent har den mest udviklede kontrol over data, modeller og infrastruktur i deres AI-løsninger.
Tallene er ledernes egne vurderinger, og IBM er selv leverandør af AI og cloud. Undersøgelsen viser altså et selvrapporteret billede og måler ikke, hvor lang tid et skifte faktisk tager.
Modeller har en udløbsdato
De store udbydere offentliggør, hvor længe en model er tilgængelig, og hvilket varsel kunden får. Varslerne er forskellige, og de gælder kun på udbyderens egen platform.
- OpenAI giver ifølge sin side om udfasninger mindst seks måneders varsel for generelt tilgængelige modeller og mindst tre måneder for specialiserede varianter. Forhåndsmodeller kan lukkes med meget kortere varsel, fx to uger.
- Anthropic varsler ifølge sin side om modeludfasning kunder med aktive installationer mindst 60 dage før, en offentligt udgivet model trækkes tilbage.
- Google lover på siden om modelversioner og livscyklus, at en række Gemini-modeller er tilgængelige i mindst 12 måneder efter udgivelsen. For modeller med kortere levetid gives mindst 45 dage til migrering, når en udløbsdato meldes ud.
- Microsoft fastsætter i sin livscykluspolitik for Foundry-modeller en standardlevetid på 18 måneder for generelt tilgængelige modeller og varsler mindst 60 dage før udløb. Ifølge politikken kan udløbsdatoer ikke forlænges.
Udfasning sker løbende
Udløbsdatoerne er ikke teoretiske. OpenAI meddelte 14. oktober 2026, at GPT-4o, GPT-4o mini, GPT-4.1 og GPT-4.1 mini fjernes 14. januar 2027.
Anthropic varslede 14. april 2026, at Claude Sonnet 4 og Claude Opus 4 ville blive trukket tilbage 15. juni 2026, og ifølge oversigten skete det på den dato. Google angiver for flere Gemini-modeller med kort levetid en fast udløbsdato, fx 28. januar 2027 for gemini-3.7-flash.
For en organisation betyder det, at en AI-løsning skal kunne skifte model flere gange i sin levetid, også selvom leverandøren er den samme. Hver gang skal resultaterne efterprøves. En løsning, der er bygget med et lag mellem egne systemer og modellen, kan typisk skifte model med færre ændringer end en løsning, hvor modellen kaldes direkte mange steder.
Automatisk opgradering ændrer resultaterne
Nogle platforme flytter selv kunden til en ny model. Microsoft opgraderer ifølge livscykluspolitikken automatisk visse installationstyper, når en modelversion udløber, region for region. Forhåndsmodeller kan blive tvangsopgraderet med mindst 30 dages varsel.
En automatisk opgradering holder tjenesten kørende, men den nye model kan svare anderledes. Instruktioner, testsæt og kvalitetskontrol, der virkede med den gamle model, skal derfor testes igen. Hvem der beslutter skiftet, og hvornår, hører med i beskrivelsen af afhængigheden (→ trin 4 om at kunne lukke, se og ændre).
Samme model, forskellige platforme
Den samme model kan ofte købes gennem flere platforme. Anthropic oplyser, at selskabets egne udløbsdatoer gælder dets egne platforme, mens Amazon Bedrock og den Google-drevne udgave på Google Cloud fastsætter deres egne tidsplaner.
Det giver en mulighed og en faldgrube. En model, der kan hentes gennem flere platforme, kan give et alternativ ved et skifte af platform. Til gengæld kan livscyklus, datacenterplacering og vilkår være forskellige, selvom modelnavnet er det samme (→ AI-behandling uden for EU).
Platformen kan også være bundet til det land, leverandøren hører hjemme i. Eksportregler og adgangsbegrænsninger er beskrevet i → AI-eksportpolitik og adgang.
Hvad dataforordningen dækker
AI-tjenester, der leveres som skalerbare tjenester over nettet, kan være omfattet af dataforordningens regler om skift af databehandlingstjeneste (→ Data Act og skifteret). For andre tjenester end ren infrastruktur skal udbyderen efter artikel 30, stk. 2, stille gratis åbne grænseflader til rådighed for at lette skiftet.
Efter artikel 30, stk. 6, er udbyderen ikke forpligtet til at udvikle nye teknologier eller overføre digitale aktiver, der er beskyttet af immaterielle rettigheder eller er forretningshemmeligheder. Selve modellen følger altså ikke med. Det, kunden kan forvente at få med, er sine egne data, og det er kunden, der skal få dem til at virke hos en ny leverandør. Derfor er det værd at afklare i kontrakten, hvordan instruktioner, testsæt, tilpasninger og indlejrede dokumenter kan eksporteres, og i hvilket format.
Kortlæg AI som andre systemer
AI-tjenester hører hjemme i den samme kortlægning som resten af systemlandskabet (→ trin 1 i exit-planen). For hver anvendelse noteres:
- hvilken forretningsproces modellen understøtter, og hvad der sker, hvis den står stille i en uge,
- modellens navn og version, platformen og den juridiske enhed bag aftalen,
- hvor beregning og lagring sker, og hvilken lov leverandøren hører under,
- modellens offentliggjorte udløbsdato og varslet ved udfasning,
- hvilke egne aktiver der er bygget til modellen, fx instruktioner, testsæt, tilpassede modeller og indlejrede dokumenter,
- om de egne aktiver kan eksporteres i et format, en anden platform kan bruge.
Kortlægningen viser ofte, at flere afdelinger bruger samme leverandør uden at vide det af hinanden (→ koncentrationsrisiko hos samme leverandør).
Afprøv et skifte i lille skala
Et papir kan dokumentere rettigheder, men kun en afprøvning viser, om en arbejdsgang kan flyttes. Afprøvningen behøver ikke være stor for at give værdi. Vælg én afgrænset anvendelse, og kør den på en anden model eller platform med de samme testdata.
Mål kvaliteten af svarene, de funktioner der mangler, tidsforbruget og den samlede omkostning ved skiftet. Notér, hvilken afhængighed afprøvningen skal mindske, så resultatet kan bruges i prioriteringen. Europæiske og offentlige alternativer er beskrevet i → europæiske AI-tjenester, efterprøvet.
Hvad kortlægningen kan og ikke kan
Kortlægningen kan vise, hvor bindingen sidder, hvilke udløbsdatoer der nærmer sig, og hvilke anvendelser der er kritiske. Den giver ledelsen et grundlag for at prioritere og for at stille krav ved næste kontrakt.
Den kan ikke garantere, at en alternativ model giver samme kvalitet. En vellykket afprøvning gælder den testede arbejdsgang og ikke alle anvendelser. Udbydernes varsler kan ændre sig, og nye modeller kommer hurtigere end de fleste kontraktperioder. Kortlægningen skal derfor opdateres oftere end for traditionelle systemer.
AI i exit-planen
- Registrér hver AI-anvendelse · Før model, platform, juridisk enhed og udløbsdato ind i systemoversigten.
- Vurder nedbrudstolerancen · Beskriv, hvordan processen fortsætter uden modellen i en uge.
- Gem de egne aktiver · Opbevar instruktioner, testsæt og tilpasninger, så de kan bruges uden for platformen.
- Afprøv ét skifte · Kør én arbejdsgang på et alternativ, og notér kvalitet, tid og omkostning (→ trin 9 om test og tilbagefald).
- Prissæt skiftet · Medregn ny test, tilpasning og oplæring i exit-omkostningen (→ trin 5).
Kortlægningen kan laves internt. En uvildig jurisdiktions- og afhængighedsvurdering omfatter afhængighedsgrad og exit-vurdering pr. system og kan også dække AI-tjenester.
Kilder
- IBM Newsroom: IBM Study: Limited Control and Rising Dependencies Leave Enterprises Exposed in the Age of AI (The Calculus of AI Sovereignty, IBM Institute for Business Value), 17.6.2026. https://newsroom.ibm.com/2026-06-17-ibm-study-limited-control-and-rising-dependencies-leave-enterprises-exposed-in-the-age-of-ai
- OpenAI: Deprecations, API-dokumentation, set 30.10.2026. https://developers.openai.com/api/docs/deprecations
- Anthropic: Model deprecations, Claude-dokumentation, set 30.10.2026. https://platform.claude.com/docs/en/about-claude/model-deprecations
- Google Cloud: Model versions and lifecycle, opdateret 28.10.2026. https://docs.cloud.google.com/vertex-ai/generative-ai/docs/learn/model-versions
- Microsoft Learn: Foundry Models lifecycle and support policy, 24.7.2026. https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-retirements
- Den Europæiske Unions Tidende (EUR-Lex): Europa-Parlamentets og Rådets forordning (EU) 2023/2854 af 13. december 2023 (dataforordningen), artikel 30. https://eur-lex.europa.eu/eli/reg/2023/2854/oj/dan
