Det, der stopper, er de opgaver, hvor en bestemt model hos en bestemt udbyder er bygget ind uden en anden vej, og dem kan I finde med en opgørelse på en til tre dage. Opgørelsen viser, hvilke opgaver der står stille, hvor længe forretningen kan tåle det, og hvad I kører videre på, så en lukning kan håndteres som et driftsproblem.
Anledningen er, at en model kan blive utilgængelig af grunde, der ligger uden for både jeres og udbyderens kontrol. I juni 2026 lukkede en amerikansk udvikler to modeller efter et direktiv fra myndighederne om udenlandske brugeres adgang, og de blev åbnet igen i to tempi. Forløbet står på digital-suveraenitet.dk og gengives ikke her. Artiklen handler om, hvad I gør, før det sker for den model, I bruger.
Fire grunde til, at en model kan forsvinde
En model kan blive utilgængelig af flere grunde, og opgørelsen er den samme for dem alle.
- Regler og myndigheder · eksportregler eller direktiver, der lukker for bestemte brugere eller lande.
- Udfasning · udbyderen udfaser modellen efter sin plan, med et varsel, der i de læste kilder spænder fra uger til måneder.
- Udbyderens beslutning · ændrede vilkår, en lukket konto eller en tjeneste, der ophører.
- Drift · nedbrud, kapacitetsmangel eller en fejl hos udbyderen.
De første tre giver normalt et varsel, men varslet kan være kort, og ved regler og myndigheder kan det mangle helt. Planen skal derfor kunne bruges uden varsel.
Trin 1: find opgaverne
Begynd med at skrive alle de opgaver op, hvor en sprogmodel indgår. Det er mere end chatassistenten. Det kan være en dokumentsøgning, en kundeservicefunktion, et værktøj til at skrive kode, en automatisk sortering af mails, en oversættelse eller en funktion i et forretningssystem, som leverandøren har bygget ind.
Spørg i afdelingerne, og se i de systemer, der kalder en model. Opgaver, som medarbejdere har sat op selv, kan først komme frem, når nogen spørger direkte.
Trin 2: find modellen bag hver opgave
Skriv for hver opgave, hvilken model den bruger, hvilken version, hvilken udbyder og hvilken kanal. Samme model kan købes direkte hos udvikleren, gennem en stor platform eller gennem en partner, og den kan lukke i den ene kanal og ikke i den anden.
Notér også, hvor modellen er bygget ind. Kaldes den ét sted, er et skifte overskueligt. Kaldes den mange steder, eller er instruktioner og test skrevet til netop den model, er skiftet tungere. Hvad der binder, er beskrevet i hvad binder, når I vælger AI?.
Trin 3: hvad stopper, og hvor længe kan I tåle det?
For hver opgave skal I vurdere, hvad der sker, hvis modellen er væk i morgen. Står opgaven helt stille, kan den løses manuelt i en periode, eller er den en bekvemmelighed, der kan undværes?
Sæt derefter tal på i jeres eget ark: hvad mister forretningen pr. dag, og hvor mange dage kan I tåle? Det er jeres egne tal, og sitet regner dem ikke for jer. Metoden til at omsætte et stop til egne tal er beskrevet på exit-plan.dk.
Trin 4: hvad kører I videre på?
Opgaver, der ikke kan tåle et langt stop, skal have en anden vej. Den kan gå til en anden model fra samme udbyder, til samme model gennem en anden kanal, til en model hos en anden udbyder, til en åben model, I selv kan køre, eller til en manuel procedure.
Vej svarene efter, hvad der er realistisk. En anden model fra samme udvikler hjælper, når én model udfases, men den hjælper næppe, når det er udvikleren selv, der rammes af en regel. En åben model, I har hentet og kører selv, er uafhængig af udbyderens adgang, men kræver drift. Hvad en reserve skal kunne, er emnet i reservemodel.
Trin 5: prøv det af
En plan, der aldrig er prøvet, er en antagelse. Vælg den vigtigste opgave, og kør den på reserven i en dag eller en uge. Mål, om svarene er gode nok, om instruktionerne skal skrives om, og hvor lang tid skiftet tog. Det giver jer et tal for, hvor hurtigt I reelt kan skifte. Fremgangsmåden står i øvelsen med at skifte model.
Udbyderen kan selv skifte model bag tjenesten
En detalje fra forløbet i juni 2026 er værd at kende. Da den ene model blev åbnet igen, sendte udvikleren de forespørgsler, som en ny kontrol blokerede, videre til en anden af sine modeller og gav brugeren besked. Det er et eksempel på, at en udbyder selv kan skifte model bag en tjeneste. Spørg jeres udbyder, om og hvordan det kan ske, og om I får besked.
Hvad det kræver, og hvad det koster at lade være
Opgørelsen kræver en IT-ansvarlig og en kontaktperson i hver afdeling, der bruger AI. Trin 1 til 4 tager en til tre dage afhængigt af antallet af opgaver. Prøven i trin 5 tager fra en dag til en uge for den vigtigste opgave. Posterne er intern tid, eventuelt en konto hos en anden udbyder og tid til at holde opgørelsen opdateret.
Lader I være, er opgørelsen det første, I skal lave den dag, modellen lukker. Så findes opgaverne under pres, reserven vælges uden test, og instruktioner skrives om, mens forretningen venter. Tabet er det, I selv har regnet ud i trin 3, ganget med den tid, det tager at improvisere.
Det skal I lade være med
- At regne kun chatassistenten med · modeller er bygget ind mange andre steder.
- At vælge en reserve hos samme udvikler og kalde risikoen dækket · det hjælper ved udfasning og næppe ved en regel, der rammer udvikleren.
- At skrive planen uden at prøve den · først prøven viser, hvor lang tid et skifte tager.
Det skal valget kunne vise
- ☐ En liste over opgaver med model, version, udbyder og kanal.
- ☐ For hver opgave: hvad et stop betyder, og hvor mange dage det kan vare, i egne tal.
- ☐ Hvad I kører videre på for de kritiske opgaver.
- ☐ Resultatet af en prøve på den vigtigste opgave, med dato.
Kilder
- Udviklerens egen meddelelse af 30. juni 2026 om genåbningen, læst 8. november 2026. Forløbet med kilder står på https://digital-suveraenitet.dk/sag-ai-eksportkontrol-juni-2026/.
- Udbydernes egne sider om udfasning af modeller hos fem udbydere og platforme, læst 8. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Lav listen i trin 1 og 2 for jeres vigtigste afdeling, og tag de øvrige bagefter.
Læs også: Eksportkontrol på AI: det, en ledelse skal vide · Stop i modellen: sådan regner I risikoen med
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT