En leverandør, der kalder sin tjeneste suveræn, kan mene placering, drift eller ejerens retsforhold. Spørgsmålene her tvinger svaret ned på det konkrete, så exit-planen kan bygge på skriftlige oplysninger frem for på markedsføring.
De seks spørgsmål følger de tre lag fra → de tre lag i digital suverænitet og tilføjer to praktiske spørgsmål om exit og om AI-behandling. For hvert spørgsmål står det, hvad et brugbart svar indeholder.
Hvorfor svarene skal være skriftlige
Et mundtligt svar på et møde kan ikke efterprøves ved næste gennemgang. Et skriftligt svar med henvisning til kontrakt, vilkår eller udbyderens egen dokumentation kan.
Udbyderne ændrer løbende deres dokumentation. Microsofts side om flex routing for Copilot, som omtales nedenfor, blev senest opdateret 29. september 2026. Et svar uden dato mister derfor hurtigt værdi.
Skriftlige svar kan desuden genbruges, når jeres egne kunder, revisorer eller tilsyn spørger til leverandørkæden. Hvad en leverandør bør kunne dokumentere i den situation, står i → når kunden spørger.
Spørgsmål 1: I hvilke lande gemmes og behandles data?
Spørg om både lagring og behandling, og spørg om undtagelserne. Mange udbydere har en liste over de tilfælde, hvor data alligevel forlader det lovede område.
Bed om lande frem for regionsnavne, da en region kan dække flere lande. Spørg også, hvor sikkerhedskopier, logfiler og supportsager opbevares, fordi de ofte følger andre regler end selve kundedata.
Et brugbart svar angiver lande eller regioner, henviser til udbyderens liste over undtagelser og oplyser, om undtagelserne kan slås fra. Gennemgangen af de lister findes i → EU-lagring med undtagelser.
Spørgsmål 2: Hvilket selskab har vi kontrakt med?
Få navnet på den juridiske enhed, der står som part i kontrakten, med registreringsnummer og land. Spørg også, hvilket selskab der driver tjenesten, hvis det er et andet.
Køber I gennem en forhandler eller en partner, skal både forhandleren og producentens kontraherende selskab med. Et brugbart svar kan slås op i et handelsregister. Fremgangsmåden står i → trin 2 om juridisk enhed og moderselskab.
Spørgsmål 3: Hvilke staters love kan pålægge selskabet at udlevere data?
Spørg om kontraktpartens og moderselskabets retsforhold, og om udbyderen har modtaget eller offentliggjort myndighedsanmodninger. Spørg også, hvad udbyderen har forpligtet sig til at gøre ved et krav, der strider mod EU-retten.
Dataforordningen pålægger allerede udbydere af databehandlingstjenester at oplyse på deres websted, hvilken jurisdiktion den infrastruktur, der bruges til tjenesten, er underlagt. Det følger af artikel 28 i forordning (EU) 2023/2854, og reglerne om skifte er gennemgået i → Data Act og skifteret. De amerikanske hjemler forklares i → Cloud Act og → FISA 702.
Spørgsmål 4: Hvem kan få adgang til data, og hvordan kan vi se det?
Spørg, fra hvilke lande support og drift kan få adgang, om underleverandører har privilegeret adgang, og om adgangen kræver jeres godkendelse. Spørg også, om adgangen logges, og om I kan læse loggen.
Et brugbart svar beskriver godkendelsesproceduren og den log, I selv har adgang til. Det oplyser også, hvor længe loggen gemmes, og om den kan eksporteres til jeres egne systemer. En log, der kun findes hos udbyderen, kan forsvinde sammen med tjenesten ved en exit. Spørgsmålet hører sammen med → trin 4 om at lukke, se og ændre og med → vilkår, der tillader udlevering uden retskendelse.
Spørgsmål 5: Hvordan kommer vi ud, og hvor hurtigt?
Spørg, hvilke data og konfigurationer der kan eksporteres, i hvilke formater, med hvilket varsel og til hvilken pris. Spørg også, hvilken bistand udbyderen yder i en overgangsperiode.
Dataforordningens artikel 25 kræver, at aftalen blandt andet indeholder en udtømmende liste over de data og digitale aktiver, der kan flyttes. Efter samme artikel må opsigelsesfristen højst være to måneder, og overgangsperioden er som udgangspunkt højst 30 kalenderdage. Et brugbart svar henviser til listen og formaterne og oplyser, hvordan udbyderen opfylder fristerne for netop jeres tjeneste. Vilkårene skrives ind i kontrakten efter → trin 8.
Spørgsmål 6: Kan vi se, hvor en bestemt AI-forespørgsel blev behandlet?
Det sidste spørgsmål gælder AI-funktioner. En forespørgsel til en sprogmodel kan indeholde jeres egne dokumenter som grundlag for svaret. Hvor den behandles, kan afhænge af belastningen og af indstillinger, udbyderen har valgt som standard.
Spørg derfor, om AI-behandlingen kan flyttes ud af regionen, og om det sker som standard. Spørg også, hvem der kan slå det fra, og om I kan se i en log, hvor den enkelte forespørgsel blev behandlet. Emnet uddybes i → når AI-behandlingen forlader EU.
Tre store udbydere, tre måder at route AI-forespørgsler på
De tre største udbyderes egen dokumentation viser, hvor forskellige svarene på spørgsmål 6 kan være.
- Microsoft beskriver flex routing for Copilot i EU og EFTA. Når funktionen er slået til, kan inferens ved spidsbelastning ske i USA, Canada eller Australien. Funktionen er slået til som standard for berettigede tenants oprettet efter 25. marts 2026, og ældre tenants opfordres til at kontrollere deres indstilling. Microsofts liste over løbende overførsler nævner, at prompter, svar og grundlagsdata kan behandles uden for EU Data Boundary. Siden om flex routing beskriver ikke, hvordan kunden kan se, hvor en enkelt forespørgsel blev behandlet.
- AWS lader kunden vælge mellem en geografisk og en global inferensprofil i Bedrock. Den geografiske holder behandlingen inden for fx EU, den globale kan sende forespørgsler til alle understøttede regioner. Ifølge AWS logger CloudTrail alle forespørgsler i kilderegionen med et felt, der viser, hvor de blev behandlet.
- Google beskriver for Vertex AI et globalt endpoint, som kunden selv vælger. Ifølge Google kan kunden da hverken styre eller vide, hvilken region forespørgslen sendes til. Et endpoint for EU som multiregion holder ifølge samme side maskinlæringsbehandlingen inden for EU.
Forskellen ligger i, om omlægningen er et tilvalg eller en standard, og om kunden kan se den bagefter. Begge forhold hører med i svaret.
Om en AI-forespørgsel, der behandles i et tredjeland, udgør en overførsel af personoplysninger, må jurister vurdere i det konkrete tilfælde. Udgangspunktet står i databeskyttelsesforordningens artikel 44, der gælder personoplysninger, som behandles eller er bestemt til behandling efter overførsel til et tredjeland. Lagringsstedet alene afgør altså ikke spørgsmålet, og uden dokumentation for behandlingsstedet bliver det svært at vise, at reglerne er overholdt.
Sådan gemmes svarene i exit-planen
Hvert svar får en række i samme regneark som kortlægningen. Felterne kan være disse.
- Spørgsmål og system · hvilket af de seks spørgsmål, og hvilken tjeneste svaret gælder.
- Svar med henvisning · leverandørens svar og den kontraktbestemmelse eller side, det bygger på.
- Dato · hvornår svaret er modtaget, og hvornår kilden sidst var opdateret.
- Standardindstilling · om en funktion er slået til eller fra som standard, og hvem der kan ændre den.
- Hvad I kan se · om I selv kan efterprøve svaret i en log eller en rapport.
- Uafklaret · spørgsmål, leverandøren ikke har besvaret, og hvornår de rykkes for svar.
Feltet om uafklarede spørgsmål er lige så vigtigt som svarene. Et manglende svar på spørgsmål 3 eller 6 er en oplysning i sig selv. Spørgsmålene kan suppleres med de otte områder i → EU’s suverænitetsramme.
Hvad spørgsmålene kan og ikke kan vise
Spørgsmålene giver et dokumenteret udgangspunkt pr. tjeneste. De afslører også, hvor en leverandørs dokumentation er tavs, og hvor en standardindstilling afviger fra det, kontrakten lover.
Vær opmærksom på tre typer svar, der kræver opfølgning. Det ene henviser til en generel side uden at nævne jeres tjeneste. Det andet beskriver, hvad udbyderen tilbyder, men ikke hvad der er slået til hos jer. Det tredje lover at vende tilbage uden en dato.
De kan ikke vise, hvad en myndighed vil kræve, eller om leverandøren i praksis gør det, den skriver. Svarene er leverandørens egne, og de skal holdes op mod registre, vilkår og udbyderens offentlige dokumentation.
Betydningen for exit-planen
Send de seks spørgsmål skriftligt til leverandørerne bag jeres mest kritiske systemer. Bed om henvisning til kontrakt eller dokumentation for hvert svar, og notér datoen.
Når svarene viser, at flere kritiske systemer afhænger af samme ejer eller samme retsforhold, kan en uvildig gennemgang give et bedre grundlag. Nielco IT’s jurisdiktions- og afhængighedsvurdering omfatter blandt andet lovgivning pr. system, juridisk enhed og moderselskab samt afhængighedsgrad.
Kilder
- Microsoft Learn: Flex routing (EU and EFTA), opdateret 29. september 2026. https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-flex-routing
- Microsoft Learn: Services that transfer a subset of Customer Data, pseudonymized personal data, or Professional Services Data out of the EU Data Boundary on an ongoing basis, opdateret 9. oktober 2026. https://learn.microsoft.com/en-us/privacy/eudb/eu-data-boundary-ongoing-partial-transfers
- Amazon Web Services: Amazon Bedrock User Guide, Route model inference requests across AWS Regions with cross-Region inference, set 30. oktober 2026. https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference.html
- Google Cloud: Generative AI on Vertex AI, Deployments and endpoints (locations), opdateret 29. oktober 2026. https://docs.cloud.google.com/vertex-ai/generative-ai/docs/learn/locations
- Den Europæiske Unions Tidende (EUR-Lex): Forordning (EU) 2023/2854 af 13. december 2023 (dataforordningen), artikel 25 og 28. https://eur-lex.europa.eu/eli/reg/2023/2854/oj/dan
- Den Europæiske Unions Tidende (EUR-Lex): Forordning (EU) 2016/679 af 27. april 2016 (databeskyttelsesforordningen), artikel 44. https://eur-lex.europa.eu/eli/reg/2016/679/oj/dan
