Sovereign cloud, vad det är och varför EU pratar om det

Sovereign cloud är en molntjänst byggd så att europeisk rätt, europeisk drift och en europeisk leverantörskedja behåller kontrollen över data och system, oberoende av icke-europeiska lagar och bolag. Det skiljer sig från en vanlig molntjänst på en enda avgörande punkt: vem som kan tvingas lämna ut er data, och under vilken lag.

En vanlig molntjänst är en hyperscaler som AWS, Microsoft Azure eller Google Cloud. Den kan lagra er data i ett datacenter i Sverige och ändå lyda under amerikansk lag, eftersom moderbolaget gör det. En sovereign cloud är konstruerad så att den kopplingen bryts. Skillnaden är alltså inte var datan ligger geografiskt, utan vilken jurisdiktion som ytterst styr den.

Många känner molnet genom SaaS, programvara som tjänst, där ni hyr en applikation över internet i stället för att installera den lokalt. SaaS gav snabb start, automatiska uppdateringar och en kostnad som följer användningen. Suveränitetsfrågan ligger ett lager under den bekvämligheten. Den handlar inte om hur ni når tjänsten, utan om vem som ytterst kontrollerar datan och driften bakom den. En SaaS-tjänst kan vara suverän eller inte, det avgörs av leverantörens ägande, jurisdiktion och leverantörskedja, inte av leveransmodellen i sig.

Fram till 2026 var “sovereign cloud” till stor del ett marknadsföringsord. Vem som helst kunde kalla sin tjänst suverän. Det har ändrats. EU har gett ordet en mätsticka, och Sverige har gett offentlig sektor ett uppdrag. Den här artikeln översätter den nya mätstickan till en checklista en svensk CISO faktiskt kan använda.

Varför det spelar roll

I april 2026 tilldelade EU-kommissionen sitt första suveräna molnkontrakt under det nya Cloud Sovereignty Framework (CSF). Kontraktet är värt upp till 180 miljoner euro över sex år och fördelas på fyra europeiska konsortier. Det var första gången EU upphandlade moln med suveränitet som en mätbar, viktad parameter snarare än en självdeklaration. [Källa: Commission advances cloud sovereignty through strategic procurement, EU-kommissionen, 2026-04-17.]

Bakgrunden är ett beroende som vuxit sig stort. De tre amerikanska aktörerna Amazon, Microsoft och Google står för omkring 70 procent av den europeiska marknaden för molninfrastruktur, medan europeiska leverantörer tillsammans ligger kvar på cirka 15 procent (källa: Synergy Research Group, hämtad 2026-06). Beroendet syns tydligt på kommunnivå: en kartläggning av svenska kommuners e-postlösningar visar att 182 av 290 kommuner, knappt sex av tio, använder en amerikanskregistrerad leverantör och därmed omfattas av US CLOUD Act. Bilden bekräftas av en separat genomgång från Techtidningen, där en stor majoritet av de svarande kommunerna kör någon Microsoft-lösning i molnet. [Källa: kartläggningen “6 av 10 kommuner använder amerikanska e-postleverantörer” (swedish-mail-dependency-datasetet); Techtidningen, “Så stor är Microsoft-dominansen ute bland kommunerna”.]

För en CISO är det här ingen abstrakt fråga om geopolitik. Den blir konkret i tre lägen. Vid en upphandling, när kraven på datalokalisering och jurisdiktion ska besvaras. Vid en incident, när ni måste kunna visa var datan finns och vem som driftar den. Och vid ett myndighetsärende, om en amerikansk begäran krockar med svensk eller europeisk rätt.

US CLOUD Act från 2018 tvingar amerikanska bolag att lämna ut data på en giltig amerikansk begäran, oavsett var datan lagras. GDPR artikel 48 förbjuder samtidigt att personuppgifter lämnas till en myndighet utanför EU utan ett internationellt avtal. De två reglerna kan ställa motstridiga krav på samma organisation. Det är den juridiska kärnan i hela suveränitetsdebatten. [Källa: EU weighs restricting use of U.S. cloud platforms to process sensitive government data, CNBC, 2026-05-07.]

Riktningen i EU pekar åt ett håll. Den 3 juni 2026 presenterade EU-kommissionen sitt European technological sovereignty package, en uppsättning åtgärder som ska stärka EU:s kapacitet inom halvledare, AI, moln och öppen källkod och minska beroendet av icke-europeisk teknik. Paketet vilar på fyra delar: en Chips Act 2.0, en Cloud and AI Development Act (som bland annat inför ett enhetligt EU-ramverk för att bedöma moln- och AI-suveränitet), en open source-strategi och en strategisk färdplan för digitalisering och AI i energisektorn. [Källa: “Strengthening Europe’s tech sovereignty”, EU-kommissionen, 2026-06-03.] Ett uttalat motiv bakom paketet är att kritiska arbetslaster inte ska ha någon “kill switch”, som kommissionens exekutiva vice ordförande Henna Virkkunen uttryckte det vill man vara säker på att ingen ska kunna stänga av en samhällsviktig tjänst. [Källa: “Europe unveils tech sovereignty package”, CNBC, 2026-06-03.]

Hur det fungerar

EU:s Cloud Sovereignty Framework mäter suveränitet på en femstegsskala: SEAL-0 till SEAL-4, där SEAL står för Sovereignty Effectiveness Assurance Levels. Skalan ersätter självdeklarerade påståenden med en granskningsbar bedömning. [Källa: Sovereign Cloud Framework explained, EU-kommissionen, 2026-06-01.]

De fem nivåerna betyder i korthet detta:

SEAL-nivå	Innebörd
SEAL-0	Ingen suveränitet. Tjänst, teknik eller drift under icke-EU-parters exklusiva kontroll, helt styrd i icke-EU-jurisdiktioner.
SEAL-1	Jurisdiktionssuveränitet. EU-rätt gäller formellt men med begränsad praktisk genomdrivbarhet; tjänsten är fortfarande under icke-EU-parters exklusiva kontroll.
SEAL-2	Datasuveränitet. EU-rätt gäller och kan genomdrivas, men väsentliga icke-EU-beroenden kvarstår (indirekt kontroll av icke-EU-parter).
SEAL-3	Digital resiliens. EU-rätt kan genomdrivas och EU-aktörer utövar ett meningsfullt men inte fullt inflytande; icke-EU-parter har endast marginell kontroll.
SEAL-4	Full digital suveränitet. Teknik och drift under fullständig EU-kontroll, enbart underställd EU-rätt, utan kritiska icke-EU-beroenden.

(SEAL-definitionerna ordagrant ur EU-kommissionens Cloud Sovereignty Framework, källa: commission.europa.eu, “Cloud Sovereignty Framework”, hämtad 2026-06.)

Under skalan ligger åtta viktade mål, kallade SOV-mål, som tillsammans summerar till 100 procent. Leverantörskedjan väger tyngst.

SOV-mål	Vad det mäter	Vikt
SOV-1 Strategisk	Strategiskt oberoende	15 %
SOV-2 Juridisk	Isolering från CLOUD Act och FISA 702	10 %
SOV-3 Data & AI	Kontroll över data och modeller	10 %
SOV-4 Operativ	Vem som driftar tjänsten	15 %
SOV-5 Leverantörskedja	Ursprung i hela kedjan	20 %
SOV-6 Teknik	Öppna standarder, ingen inlåsning	15 %
SOV-7 Säkerhet & efterlevnad	BSI C5, EUCS	10 %
SOV-8 Miljö	Klimatavtryck	5 %

(Viktningen är hämtad ur EU-kommissionens Cloud Sovereignty Framework, tabellen “Weight in Scoring”, källa: commission.europa.eu, hämtad 2026-06.)

Det viktiga för en CISO är logiken: suveränitet är inte ett ja eller nej, utan en sammanvägd profil. En leverantör kan vara stark på datalokalisering men svag på leverantörskedja. CSF tillåter att styrka på ett mål väger upp svaghet på ett annat. Den kompensationslogiken är också det som gör skalan omtvistad, vilket vi återkommer till.

Två av de åtta målen är värda att stanna vid, eftersom de avgör hur fritt ni kan röra er. SOV-6 mäter teknik och öppna standarder. Frågan målet ställer är enkel: kan ni ta med er data och era system till en annan leverantör, eller är ni inlåst? Öppen källkod väger tungt här: när koden är öppen och datan ligger i öppna format finns det ingen enskild ägare som kan låsa dörren. SOV-4 mäter den operativa suveräniteten, vem som faktiskt driftar tjänsten, och om EU-baserad personal kan hålla den i gång utan en utländsk leverantör. En managerad, EU-baserad drift med säkerhetsprövad personal är ett konkret sätt att reducera risk i den delen av kedjan.

När det passar

Sovereign cloud passar när någon av dessa tre saker väger tungt för er organisation.

Känslig eller reglerad data. Vård, socialtjänst, rättsväsende, finansiell information och säkerhetsklassade uppgifter. Här är jurisdiktionen inte en bonus utan ett krav, och en SEAL-2-nivå eller högre blir relevant.

Lång livslängd och regelefterlevnad. Bygger ni ett system som ska leva i fem till tio år, blir frågan “vem kontrollerar plattformen” en reell riskfråga. NIS2-baserade Cybersäkerhetslagen trädde i kraft i Sverige 15 januari 2026 (SFS 2025:1506) och höjer kraven på riskhantering, incidentrapportering och styrning för flera sektorer. Bevisbar kontroll över driften gör efterlevnaden enklare att visa.

Offentlig upphandling. Sveriges molnpolicy från maj 2026 uppmanar offentlig sektor att välja svenskt eller europeiskt först. Det gör suveränitet till en faktor i utvärderingen, inte bara en intern preferens.

När det inte passar

Sovereign cloud är inte rätt svar på allt. Det finns lägen där det blir dyrare och krångligare utan motsvarande nytta.

Öppna, icke-känsliga data. En publik webbplats, öppna geodata, marknadsföringsmaterial. Här finns sällan ett juridiskt eller säkerhetsmässigt skäl att betala för suveränitet. En vanlig molntjänst räcker.

När ekosystemberoendet är avgörande. Ibland behöver ni en specifik hyperscaler-tjänst som bara finns där, en viss managed AI-modell, en proprietär dataplattform. Då kan en sovereign cloud sakna funktionen, och valet blir en avvägning mellan funktion och kontroll.

När exit-planen saknas oavsett. Suveränitet löser inte inlåsning på egen hand. Flyttar ni bara känslig data till en europeisk leverantör utan öppna standarder och testad exit-plan, har ni bara bytt ett beroende mot ett annat. Öppen källkod och dokumenterade exit-rutiner gör mer för er rörlighet än enbart en europeisk flagga på datacentret.

Den ärliga regeln: välj suveränitetsnivå efter datans känslighet och systemets livslängd, inte efter rubrikerna.

Konkret exempel

Tänk er en svensk region som driver ett vårdinformationssystem. Patientdata är känsliga personuppgifter, systemet ska leva i åratal, och regionen lyder under både GDPR och Cybersäkerhetslagen.

Lägger regionen systemet hos en hyperscaler med EU-datacenter, uppfyller de datalokalisering. Men moderbolaget lyder under US CLOUD Act, vilket innebär att en amerikansk begäran i teorin kan krocka med GDPR artikel 48. På SEAL-skalan landar uppställningen omkring SEAL-1 eller SEAL-2.

Väljer regionen i stället en europeiskt ägd leverantör med EU-baserad drift, europeisk nyckelhantering och en leverantörskedja utan amerikanskt moderbolag, flyttar de uppåt mot SEAL-3. Då kan de visa, inte bara påstå, att ingen icke-europeisk myndighet har en laglig väg till datan. Tjänsten kan dessutom drivas vidare även om en utländsk leverantör faller bort.

Det är den skillnaden Sovereign-by-Design handlar om: suveränitet som en egenskap ni kan bevisa, granskad mot SEAL-kriterier, inte ett löfte i ett avtal.

Digitalists egen molnplattform och drift bygger på den principen, öppen källkod i botten, drift och nyckelhantering i Sverige eller EU. Som trovärdighetsankare står de verifierade talen: cirka 50 medarbetare, NPS 61 och drift från Götgatan 55 i Stockholm.

Vanliga missförstånd

“Om datan ligger i ett EU-datacenter är den suverän.” Geografi räcker inte. En hyperscaler kan lagra data i Stockholm och ändå lyda under amerikansk lag via sitt moderbolag. Suveränitet handlar om jurisdiktion, drift och leverantörskedja, inte bara om var hårddisken står. Det är därför SEAL-skalan väger in åtta mål, inte ett.

“Sovereign cloud betyder att amerikanska moln är förbjudna.” Inget sådant förbud finns. Sveriges molnpolicy från maj 2026 uppmanar offentlig sektor att välja europeiskt först, men förbjuder ingenting. För känsliga data kan kommande EU-regler begränsa användningen, men en generell utfasning är inte beslutad.

“En sovereign-stämpel betyder full suveränitet.” Inte nödvändigtvis. Joint venture-bolaget S3NS bygger på Google Clouds teknik och klarade ändå SEAL-2 i EU:s upphandling. Branschorganet CISPE kallade det ett självmål som riskerar att institutionalisera “sovereignty washing”. Eftersom CSF tillåter att styrka på ett mål väger upp svaghet på ett annat, kan gränsfall lyftas in i en SEAL-ruta. Läs alltså SEAL-nivån tillsammans med SOV-profilen, inte som en ensam stämpel. [Källa: Europe picks 4 sovereign cloud providers, but one has Google, The Register, 2026-04-20.]

För en svensk organisation är slutsatsen enkel att formulera och svår att fuska med: kräv bevis, inte påståenden. Fråga var datan ligger, vem som driftar den, vilken rätt som gäller och hur exit ser ut, och be om svar ni kan granska.