VAR BEHANDLAS ERA AI-ANROP? LAGRINGSORT ÄR INTE SAMMA SAK SOM DRIFTSORT
”Data lagras i EU” är ett svar på en fråga ni kanske inte ställde. Var uppgifterna ligger när de vilar och var modellen körs i det ögonblick anropet behandlas är två skilda saker – och avtalsbilagan svarar oftast bara på den första. Den här texten ger frågelistan som skiljer dem åt, visar varför ett driftsortskrav är en prissatt konfiguration och inte en självklarhet, och hur kravet skrivs in och följs upp.
Vem står bakom innehållet?
Den här texten är redaktionellt framtagen av AI på svenska för inköpare, avtalsägare, IT-ansvariga och dataskyddsfunktioner på svenska arbetsplatser. Den bygger på fyra leverantörers egen produktdokumentation, på dataskyddsförordningens kapitel V (artiklarna 44–46), på Integritetsskyddsmyndighetens vägledning om överföring till tredjeland, på EDPB:s riktlinjer 05/2021 (öppnas i ny flik) och på AI-förordningen (EU) 2024/1689. Samtliga källor öppnades och kontrollerades 2026-08-22. Texten ger frågor och kontrollpunkter för en upphandling – inte besked om huruvida en viss konfiguration hos en viss leverantör är tillåten i ert fall.
Två frågor som ser ut som en
Lagringsorten är var uppgifterna ligger när de vilar: uppladdade filer, promptar, svarshistorik, loggar, supportkopior och säkerhetskopior. Driftsorten är var modellen körs i den sekund anropet behandlas – där texten faktiskt läses in, beräknas och besvaras. De två kan ligga i olika världsdelar samtidigt, hos samma leverantör, i samma tjänst, under samma avtal.
Det här är inte en teoretisk uppdelning. Microsoft skriver rakt ut i sin dokumentation för driftsformer i Foundry att data som lagras i vila stannar i den valda Azure-geografin för samtliga driftsformer, men att inferensdata behandlas olika beroende på vilken form ni valt: en global form kan behandlas i vilken Azure-region som helst, en datazonsform endast inom angiven datazon (USA, EU eller Asien–Stillahavsområdet), och en enregionsform i den region ni pekat ut. Samma resurs, samma lagringslöfte, tre helt olika svar på var anropet körs.
Konsekvensen för er: ett skriftligt besked om att ”kunddata lagras inom EU” är sant och samtidigt otillräckligt. Det utesluter inte att anropet dirigerades någon annanstans. Om ni ställde frågan ”var lagras data?” och fick svaret ”i EU”, har ni ännu inte ställt den andra frågan.
Att göra uppgifter tillgängliga är också en överföring
IMY beskriver överföring till tredjeland som att personuppgifter ”skickas eller på annat sätt görs tillgängliga för en mottagare i ett land utanför EU/EES-området”. Formuleringen på annat sätt görs tillgängliga är den som gör driftsorten intressant: det krävs ingen permanent flytt av en fil för att kapitel V ska aktualiseras.
EDPB anger i riktlinjerna 05/2021 tre kumulativa kriterier för att en behandling ska räknas som en överföring: exportören omfattas av dataskyddsförordningen för behandlingen, exportören lämnar ut eller på annat sätt gör uppgifterna tillgängliga för en importör, och importören finns i tredjeland eller är en internationell organisation. Är alla tre uppfyllda gäller kapitel V, med adekvansbeslut eller lämpliga skyddsåtgärder som möjliga grunder.
Notera vad artikeln inte påstår: att global routning automatiskt är en otillåten överföring. Bedömningen är fallspecifik och beror på mottagare, mekanism och kompletterande åtgärder. Poängen är att bedömningen behöver ett svar på var behandlingen sker – och att det svaret inte går att läsa ur en lagringsklausul. Den juridiska genomgången av själva avtalsbilagan har vi gjort separat i Personuppgiftsbiträdesavtal för AI; den här texten äger den operativa frågan om var anropet körs.
Global routning är grundläget, EU-drift är valet
Mönstret återkommer hos leverantör efter leverantör, med olika produktnamn men samma logik: den breda, globalt dirigerade formen är utgångspunkten, och geografiskt avgränsad drift är något ni aktivt beställer.
- Microsoft Foundry / Azure OpenAI. Tre driftsformer: global, datazon och enskild region. Dokumentationen rekommenderar uttryckligen att börja med den globala formen och byta ”bara när ni har ett särskilt skäl, till exempel datahemvist”. EU-datazonen följer Azures EU Data Boundary, som kan omfatta Efta-länder som Norge och Schweiz utöver EU:s medlemsstater – och Microsoft anger att regioner kan läggas till i en datazon utan föregående avisering.
- OpenAI:s API. Regionen för lagring väljs när ett nytt projekt skapas. Regional behandling kan dessutom väljas per anrop från ett globalt projekt genom den regionala domänen, om slutpunkten och modellen stöder det. OpenAI redovisar regional lagring och regional behandling som två separata egenskaper – exakt den uppdelning den här artikeln handlar om.
- Google Cloud. Den aktuella dokumentationen visar regionala och globala slutpunkter samt särskilda flerregionsslutpunkter för USA och EU. Google varnar samtidigt för att en slutpunkt i sig inte är ett löfte om datahemvist eller behandling i regionen; för EU-flerregionen anges däremot uttryckligen att ML-behandlingen stannar inom EU. Adressen är alltså ett tekniskt spår, men måste kopplas till det dokumenterade löftet för just den driftsformen.
- Anthropic. Deras sida om regionala krav ställer saken kort: globala slutpunkter dirigerar dynamiskt till regioner med ledig kapacitet, medan regionala slutpunkter garanterar att både lagring och modellbehandling stannar inom den geografi ni angett. Regional hemvist i Europa anges vara tillgänglig via molnplattformarna.
Den icke-självklara fallgropen ligger i den sista raden i varje punkt. Byter ni till en molnplattform för att få EU-drift, byter ni samtidigt motpart i behandlingskedjan: den som driftar modellen är då någon annan än den som byggde den. Underbiträdeslistan och avtalskedjan måste följa med i bytet, annars har ni löst driftsortsfrågan och öppnat en ny.
Driftsortskravet är prissatt – räkna på det före kravställningen
Det är lätt att skriva in ”behandling ska ske inom EU/EES” i en kravspecifikation och svårt att veta vad raden kostar. Hos Microsoft är den globala driftsformen enligt deras egen dokumentation den som lanseras först vid en ny modell, har det lägsta priset och den bredaste regiontäckningen. Enregionsformerna beskrivs som de som ”kommer sist, har inget garanterat lanseringsdatum och beror på kapacitet som frigörs när äldre modeller pensioneras”. Prislistan är följaktligen noterad per modell och driftsform, med separata rader.
Kravet har alltså tre prislappar, inte en: en högre tokenkostnad, en fördröjning innan nya modeller blir tillgängliga i den snävare formen, och en kapacitetsrisk om formen inte kan levereras alls för den modell ni valt. Den tredje är den som brukar överraska, eftersom den inte syns i någon prislista.
Praktiskt råd: hämta beloppen för er modell, er region och er valuta ur leverantörens prisverktyg innan kravet formuleras – siffror ur en blogg eller en jämförelseartikel är sällan aktuella och gäller sällan er kombination. Räkna sedan om kravet till en årskostnad vid förväntad volym. Först då vet ni om ”EU-drift” är en formalitet eller en budgetpost. Den bredare behovs- och leverantörskontrollen inför inköp finns i Köpa in AI utan att köpa problem.
Frågelistan som skiljer lagringsort från driftsort
Skriv kravet så att det går att bryta mot
En klausul som lyder ”leverantören tillämpar datahemvist inom EU” är i praktiken oprövbar. Den anger varken vilken behandling som avses, vilken konfiguration som ger effekten eller vad som gäller när kapaciteten tryter. Bygg i stället kravet av fem beståndsdelar, var och en möjlig att kontrollera i efterhand.
- Behandlingen namnges. Skilj på lagring i vila och behandling vid inferens, och ange geografin för båda var för sig. Låt inte ett ord som ”behandling” täcka båda utan att definieras.
- Konfigurationen pekas ut. Skriv in produktens faktiska namn på driftsformen eller slutpunkten, inte bara det önskade resultatet. Namnet är det som går att jämföra mot verkligheten i en konsoll.
- Undantagen regleras. Vad gäller vid kapacitetsbrist, incident eller avbrott? Ett tyst omdirigeringsbeteende är vanligt och behöver antingen förbjudas eller aviseras – välj vilket, och skriv det.
- Ändringar aviseras. Om leverantören kan utvidga en zon eller ändra routning ensidigt behöver ni framförhållning, en arkiverad version av villkoret och en rätt att invända. Detsamma gäller tillägg i underbiträdeslistan.
- Bevisbördan placeras. Ange vilket underlag leverantören ska kunna lämna på begäran och hur ofta. Utan den punkten är kravet en avsiktsförklaring.
Lämna samtidigt det ni inte kan avgöra till rätt funktion. Om kedjan går utanför EU/EES är frågan om överföringsmekanism och kompletterande skyddsåtgärder en juridisk bedömning, inte en inköpsdetalj – och den ska stå som öppen punkt tills dataskyddsombud eller jurist har svarat.
Fyra spår som gör driftsorten kontrollerbar
Det som gör driftsort till en tacksam kravpunkt är att valet nästan alltid lämnar tekniska avtryck. Till skillnad från löften om vad leverantören inte gör med er data går det här faktiskt att titta efter.
- Adressen i anropet. Flera leverantörer använder en egen domän eller slutpunkt för geografiskt avgränsad drift – OpenAI använder
eu.api.openai.comför EU-behandling, och Google exponerar regionala, globala och flerregionala slutpunkter som skilda adresser. Bas-URL:en i er kod eller integration är därför ett kontrollerbart spår, men inte hela beviset: kontrollera också att den valda slutpunkten omfattas av leverantörens uttryckliga behandlingslöfte. - Namnet på resursen. Där driftsformen är ett namngivet objekt går den att läsa av direkt. Microsoft namnger sina former i kod –
GlobalStandard,DataZoneStandard,Standard– vilket gör en avvikelse synlig utan att någon behöver svara på en fråga. - Den tekniska spärren. Där plattformen stöder det, spärra den bredare formen i stället för att förlita er på rutin. Microsoft publicerar en färdig policyregel för att neka en viss driftsform. En spärr är starkare än en instruktion eftersom den överlever personalomsättning.
- Fältet i svaret. Be om att svaret eller loggen innehåller vilken geografi som betjänade anropet. Routningen är redan känd på leverantörens sida, så begäran är rimlig – och ett sådant fält förvandlar uppföljningen från en årlig fråga till en löpande mätpunkt.
Gör ett prov: skicka ett anrop från ert eget konto och följ det genom loggarna. Kan ni för det enskilda anropet visa adressen, driftsformens namn och den region som behandlade det? Om inte är kravet inte uppföljningsbart ännu, oavsett vad avtalet säger. Samma resonemang om att pröva löften i praktiken använder vi i Så kan AI-leverantörer hantera indata.
Att vara tillämpare flyttar inte valet till leverantören
AI-förordningen (EU) 2024/1689 skiljer på leverantör – den som utvecklar eller låter utveckla ett AI-system och släpper ut det på marknaden i eget namn – och tillämpare, den som använder systemet under egen auktoritet i yrkesmässig verksamhet. En arbetsgivare som använder ett AI-verktyg i verksamheten är normalt tillämpare, inte leverantör. En tillämpare som väsentligt modifierar systemet eller sätter eget varumärke på det kan dock enligt artikel 25 räknas om till leverantör och ärver då leverantörens skyldigheter.
Rollfördelningen säger ingenting om driftsort i sig, men den avgör vem som äger valet. Konfigurationen väljs i ert konto, i er prenumeration, av er beställare. Att systemet kommer från någon annan gör inte valet till leverantörens. Det är därför frågelistan ovan hör hemma i inköpsprocessen och inte i en teknisk bilaga som ingen läser.
Exempel: en utvecklare behöver en nyare modell som ännu inte finns i den EU-avgränsade driftsformen, byter driftsform i konsollen för att komma vidare och löser sin uppgift på en eftermiddag. Avtalet är oförändrat, lagringen ligger kvar i EU, och beskrivningen i bilagan stämmer fortfarande – men driftsorten är en annan. Ingen har brutit mot något som stod skrivet, eftersom kravet aldrig knöts till namnet på en konfiguration.
Namngiven fallgrop: driftsortskravet ägs av avtalsägaren men verkställs av den som klickar i konsollen, och de två pratar sällan med varandra. Utse därför en namngiven ägare för konfigurationen, inte bara för avtalet, och koppla ägarskapet till en kontrollpunkt med datum. Om svaret på frågan ”vem märker att någon bytte driftsform?” är ”ingen bestämd”, är kravet i praktiken frivilligt. Vilket verktyg som över huvud taget bör användas för känsligt innehåll är en tidigare fråga i kedjan – den behandlas i Vilket AI-verktyg för känslig information?
Sju steg innan nästa avtal skrivs under
- Läs om er befintliga bilaga och markera varje mening som handlar om plats. Svarar den på lagring, på drift, eller på båda?
- Skicka frågelistan skriftligt och begär svar per datatyp, inte per produkt.
- Ta reda på vad standardvärdet är om ingen gör något – det är det värde ni kör på i dag.
- Prissätt kravet för er modell, region och volym, och lägg till fördröjningen för nya modeller som en egen post.
- Skriv kravet i fem delar: behandling, konfigurationsnamn, undantag, avisering, bevis.
- Sätt en teknisk spärr där det går, och en namngiven ägare där det inte går.
- Lägg in en återkommande kontroll av adress, driftsform, underleverantörslista och aviseringar – med datum, inte ”löpande”.
Kan ni inte i dag svara på var ert vanligaste AI-anrop behandlades i går, är det den luckan som ska stängas först – före nästa kravspecifikation och före nästa förhandling.
Vanliga frågor om lagringsort och driftsort
Vad är skillnaden mellan lagringsort och driftsort?
Lagringsorten är var uppgifterna ligger när de vilar: filer, promptar, svarshistorik, loggar och säkerhetskopior. Driftsorten är var modellen faktiskt körs i det ögonblick anropet behandlas. Samma leverantör kan hålla lagringen inom en geografi och ändå dirigera själva anropet till en annan region.
Räcker det att leverantören lovar datahemvist i EU?
Nej, inte om löftet bara gäller lagring i vila. Fråga separat var inferensen sker, om det är styrbart, vad det heter i produkten och hur det syns i avtalet. Ett svar om lagring besvarar inte frågan om behandlingsplats.
Kostar det extra att kräva att anropen körs inom EU?
Ofta ja. Hos flera leverantörer är global routning grundläget med det lägsta priset och den bredaste modelltillgången, medan snävare geografisk routning prissätts separat och kan komma senare till nya modeller. Hämta priset för er egen modell och region i stället för att anta att kravet är gratis.
Hur kontrollerar vi driftsorten efter att avtalet är påskrivet?
Valet lämnar tekniska spår: en egen slutpunkt eller bas-URL i anropet, ett namngivet driftformsnamn på resursen och i vissa miljöer en policyregel som nekar den bredare formen. Lägg in en återkommande kontroll av dessa punkter samt av underleverantörslistan och aviseringar om ändringar.
Källor och vidare läsning
- Microsoft Learn: Understanding deployment types in Microsoft Foundry Models (öppnas i ny flik) — lagring i vila per geografi, inferens per driftsform, EU Data Boundary och lanseringsordning.
- OpenAI: Data controls in the OpenAI platform (öppnas i ny flik) — regional lagring och regional behandling som separata egenskaper, projektbunden lagringsregion och regional behandling per anrop.
- Google Cloud: Deployments and endpoints (öppnas i ny flik) — regionala, globala och flerregionala slutpunkter samt skillnaden mellan en adress och ett behandlingslöfte.
- Anthropic: Regional compliance (öppnas i ny flik) — global dynamisk routning mot regional slutpunkt för lagring och modellbehandling.
- IMY: Vad menas med överföring till tredjeland? (öppnas i ny flik) — att göra uppgifter tillgängliga för en mottagare utanför EU/EES.
- EDPB: Guidelines 05/2021 om artikel 3 och kapitel V (öppnas i ny flik) — de tre kumulativa kriterierna för en överföring.
- EUR-Lex: dataskyddsförordningen, kapitel V (öppnas i ny flik) — artiklarna 44–46 om överföringar till tredjeland.
- EUR-Lex: AI-förordningen (EU) 2024/1689 (öppnas i ny flik) — definitionerna av leverantör och tillämpare samt artikel 25.