AI-leverandørrisiko: bliver du for afhængig af ChatGPT eller Claude?

Hvor risikoen opstår

AI-leverandørrisiko opstår, når en virksomhed bliver så afhængig af én platform, én model eller én leverandør, at ændringer uden for virksomhedens kontrol kan stoppe arbejdet. Det kan være prisændringer, nye rate limits, modeludskiftninger, ændrede vilkår, midlertidig utilgængelighed, datakrav, sikkerhedspolitikker eller fjernede funktioner.

Risikoen er ikke teoretisk. I 2026 har både modelpriser, adgangsniveauer og sikkerhedspolitikker ændret sig hurtigt. Anthropic suspenderede kort adgang til Fable 5 og Mythos 5 efter lanceringen og genåbnede senere. OpenAI har justeret GPT-5.6-priser efter lancering og opdelt modeller i Sol, Terra og Luna. Det er almindelige tegn på et marked, der stadig bevæger sig.

Det betyder ikke, at du skal undgå ChatGPT, Claude eller andre stærke platforme. Det betyder, at du skal vide, hvor afhængigheden ligger. Hvis AI kun bruges til ideer og udkast, er risikoen lav. Hvis AI driver kundeleverancer, kode, rapportering eller automatiserede beslutninger, er risikoen højere.

De fem typer lock-in

Den første type er prompt-lock-in. Jeres bedste arbejdsgange ligger i private chats, bruger platformsspecifikke features og kan ikke flyttes. Når en medarbejder stopper, eller platformen ændrer sig, forsvinder viden. Løsningen er at gemme vigtige prompts og instruktioner i fælles dokumenter eller et repo.

Den anden type er data-lock-in. Filer, vidensbaser, embeddings, tråde og agenter lever kun i én platform. Det gør det svært at skifte leverandør eller køre samme opgave et andet sted. Brug åbne filformater, eksportmuligheder og tydelig struktur, hvor det er muligt.

Den tredje type er workflow-lock-in. En proces virker kun, fordi en bestemt connector, agent eller modeladfærd findes. Den fjerde er prismæssig lock-in, hvor forbruget vokser uden klare enhedsomkostninger. Den femte er kompetence-lock-in, hvor teamet kun kan arbejde i én platform og ikke forstår de underliggende opgaver.

Hvad danske SMV'er bør kortlægge

Start med en enkel inventarliste. Hvilke AI-værktøjer bruger I? Hvem har adgang? Hvilke opgaver løser de? Hvilke data sendes ind? Hvilke output bruges eksternt? Hvilke workflows ville være svære at køre i morgen, hvis værktøjet var nede?

Del derefter opgaverne i tre risikoniveauer. Lav risiko er ideer, udkast og intern sparring. Mellem risiko er rapporter, analyse, content, support og salgsarbejde. Høj risiko er kodeændringer, juridiske vurderinger, persondata, økonomiske beslutninger og automatiseringer, der handler uden menneskelig godkendelse.

For højrisikoopgaver bør der være en ejer, en fallback og et reviewkrav. For mellemrisikoopgaver bør der i det mindste være dokumenterede prompts og klare datagrænser. For lavrisikoopgaver kan reglerne være lettere, så brugen ikke bliver kvalt.

Portabilitet uden at miste fart

Portabilitet betyder ikke, at alt skal bygges leverandørneutralt fra dag ét. Det betyder, at de vigtigste aktiver kan flyttes. Gem prompts i almindelig tekst. Gem kilder i mapper, CRM eller vidensbase, som virksomheden kontrollerer. Brug strukturerede outputformater, som kan læses af andre systemer. Dokumentér modelvalg og antagelser.

Hvis du bygger AI-automatisering, så adskil forretningslogik fra modelkald. Systemet bør vide, hvad opgaven er, hvilke data der må bruges, og hvordan output valideres, uden at alt er skjult i én lang prompt. Det gør det lettere at skifte fra ChatGPT til Claude eller omvendt.

Lav også små evalueringssæt. Et evalueringssæt er en håndfuld rigtige opgaver med forventet godt output. Når en model ændrer sig, kan I køre sættet igen og se, om kvaliteten stadig holder. Det er en praktisk forsikring mod stille modelændringer.

Fallback er en arbejdsproces

En fallback er ikke bare en ekstra konto. Den skal være testet. Hvis jeres primære model er ChatGPT, så prøv de vigtigste opgaver i Claude. Hvis jeres primære model er Claude, så test ChatGPT eller en anden relevant leverandør. Noter, hvilke instruktioner der skal ændres, og hvor kvaliteten falder.

Fallback kan også være manuel. Nogle opgaver bør have en reduceret nødprocedure, hvor teamet kan levere langsommere, men sikkert. Det er især vigtigt for kundevendt arbejde. Det er bedre at sige, at en rapport tager en dag længere, end at levere ukontrolleret output fra en uprøvet model.

Hvis I bruger API'er, bør fallback bygges teknisk. Hav modelkonfiguration uden hårdkodede antagelser. Log fejl. Sæt budgetlofter. Sørg for, at systemet kan give en pæn besked, hvis en model ikke svarer. Den slags er kedeligt under udvikling og værdifuldt den dag noget fejler.

Indkøb og governance

AI-indkøb bør ikke kun ligge hos den mest nysgerrige medarbejder. IT, ledelse, økonomi og fagteam bør som minimum kende de vigtigste valg. Hvilke værktøjer er godkendt? Hvilke data må bruges? Hvad koster det? Hvilke vilkår gælder? Hvem lukker adgang, når en medarbejder stopper?

Det behøver ikke være tungt. En SMV kan starte med én side: godkendte værktøjer, forbudte datatyper, reviewkrav, ejer og fallback. Opdater den månedligt i begyndelsen, fordi markedet ændrer sig hurtigt.

Se også Claude vs. ChatGPT og AI-modelpriser i 2026. De to beslutninger hænger sammen: pris, kvalitet og risiko kan ikke vurderes adskilt.

Den sunde balance

For lidt afhængighed kan også være et problem. Hvis virksomheden aldrig standardiserer, får den spredte værktøjer, uklare data og ingen læring. Målet er ikke at undgå leverandører. Målet er at være afhængig med åbne øjne.

Vælg gerne en primær platform. Giv teamet gode rammer. Byg stærke workflows. Men sørg for, at kritisk viden, prompts, kilder og processer ikke kun findes inde i platformen. Så kan I udnytte tempoet i AI-markedet uden at blive fanget af næste prisændring, adgangsændring eller modelskifte.

Den bedste test er enkel: hvis jeres primære AI-værktøj forsvandt i morgen, kunne I så levere videre i reduceret form? Hvis svaret er ja, har I en sund afhængighed. Hvis svaret er nej, bør næste AI-projekt handle mindre om nye features og mere om robusthed. Leverandørrisiko handler om jeres drift. Det bredere spørgsmål om, hvem der har kontrollen med AI-udviklingen, tog fart i september 2026. Få et overblik over mulighederne på Manids' AI-side, før I bygger videre.