# Data Sovereignty for Norwegian Public Sector

**Last updated:** 2026-02
**Status:** GA
**Category:** Hybrid Cloud & Edge AI
**Type:** reference

---

## Innhold

- [Introduksjon](#introduksjon)
- [Regulatorisk landskap](#regulatorisk-landskap)
- [Norske krav til data residency](#norske-krav-til-data-residency)
- [Azure Data Residency for Norge](#azure-data-residency-for-norge)
- [EU Data Boundary (EUDB)](#eu-data-boundary-eudb)
- [Microsoft Sovereign Cloud](#microsoft-sovereign-cloud)
- [Azure Data Classification for AI](#azure-data-classification-for-ai)
- [Praktiske arkitekturmoenstre](#praktiske-arkitekturmoenstre)
- [Beslutningstre for datasuverenitet](#beslutningstre-for-datasuverenitet)
- [Compliance-sjekkliste for AI-prosjekter](#compliance-sjekkliste-for-ai-prosjekter)
- [Sammenligning: Sovereign Cloud-alternativer](#sammenligning-sovereign-cloud-alternativer)
- [For Cosmo](#for-cosmo)

## Introduksjon

Datasuverenitet er et av de viktigste temaene nar norsk offentlig sektor vurderer skybaserte AI-losninger. Etter Schrems II-dommen (2020), EUs AI Act (2024), og okt fokus pa digital autonomi i Europa, ma organisasjoner navigere et komplekst landskap av juridiske krav, tekniske kontroller og politiske forventninger.

For AI-arbeidsbelastninger er utfordringene spesielt store: AI-modeller kan inneholde implisitt persondata i sine vekter, treningsdata kan vare sensitivt, og inferensresultater kan avslore informasjon om underlaget. Samtidig er mange av de kraftigste AI-tjenestene kun tilgjengelige fra bestemte Azure-regioner, og noen krever global databehandling.

Denne referansen gir en strukturert oversikt over regulatoriske krav, Microsofts tilbud for datasuverenitet, og praktiske arkitekturmoenstre for norsk offentlig sektor som vil ta i bruk AI pa en trygg og lovlig mate.

---

## Regulatorisk landskap

### Schrems II og konsekvenser

Schrems II-dommen (juli 2020) ugyldiggjorde EU-US Privacy Shield og stilte strengere krav til overforing av persondata til tredjeland:

| Aspekt | Konsekvens for AI i skyen |
|--------|--------------------------|
| Ugyldiggjoring av Privacy Shield | Kan ikke basere dataoverforing til USA pa Privacy Shield |
| Strengere SCC-krav | Standard Contractual Clauses krever tilleggstiltak |
| Risikovurdering pakreves | Ma vurdere om mottakerlandets lovgivning gir tilstrekkelig vern |
| Supplementary measures | Tekniske, organisatoriske og kontraktuelle tiltak ma iverksettes |

**Post-Schrems II tiltak fra Microsoft:**
- EU Data Boundary (EUDB) implementert for a holde data i EU/EFTA
- Standard Contractual Clauses (SCCs) oppdatert
- Data Protection Addendum (DPA) styrket
- Transparensrapporter publisert

### EU-US Data Privacy Framework (2023)

I juli 2023 vedtok EU-kommisjonen EU-US Data Privacy Framework som ny mekanisme for lovlig overforing av persondata til USA:

| Aspekt | Status |
|--------|--------|
| Adequacy decision | Vedtatt juli 2023 |
| Microsoft-sertifisering | Ja, sertifisert under DPF |
| Norsk aksept | Norge (via EOS-avtalen) folger EU-beslutninger |
| Stabilitet | Utfordret av NOYB, men gyldig per 2026 |
| Anbefalinger | Bruk DPF + tekniske tiltak (defense in depth) |

### GDPR/Personvernforordningen

| Krav | Relevans for AI |
|------|-----------------|
| Art. 5 (formaalsbegrensning) | AI-modeller ma brukes til angitt formal |
| Art. 6 (behandlingsgrunnlag) | Samtykke, avtale eller berettiget interesse |
| Art. 22 (automatiserte beslutninger) | Rett til menneskelig inngripen |
| Art. 25 (privacy by design) | Innebygd personvern i AI-systemer |
| Art. 35 (DPIA) | Pakrevd for AI med hoy risiko |
| Art. 44-49 (tredjelands overforing) | Relevant for sky-AI-tjenester |

### EUs AI Act

| Risikokategori | Krav | Eksempler |
|----------------|------|-----------|
| Uakseptabel risiko | Forbudt | Sosial scoring, manipulering |
| Hoy risiko | Strenge krav | Biometrisk ID, kredittscoring |
| Begrenset risiko | Transparenskrav | Chatbots (merking) |
| Minimal risiko | Ingen sarlige krav | Spamfiltre, anbefalinger |

**Norsk implementering:** AI Act folges opp gjennom EOS-avtalen. Datatilsynet er ansvarlig for haandheving.

---

## Norske krav til data residency

### Utredningsinstruksen

Statlige tiltak (inkludert AI-prosjekter) ma folge utredningsinstruksen:

| Krav | Konsekvens for AI-prosjekter |
|------|------------------------------|
| Problemdefinisjon | Klar definisjon av hva AI skal lose |
| Behovsanalyse | Dokumenter hvorfor AI er nodvendig |
| Alternativvurdering | Sammenlign sky/hybrid/lokalt |
| Konsekvensutredning | Personvern, sikkerhet, okonomi |
| Forholdsmessighet | Balanse mellom nytte og risiko |
| Horing | Involver berorte parter |

### Sikkerhetsloven og NSMs krav

For virksomheter underlagt sikkerhetsloven:

| Krav | Implikasjon |
|------|------------|
| Informasjonssikkerhet | AI-systemer som behandler sikkerhetsgradert info |
| Forebyggende sikkerhet | Risikovurdering av AI-leverandorer |
| Personellsikkerhet | Klarering for tilgang til AI-systemer |
| Objektsikkerhet | Fysisk sikring av AI-infrastruktur |
| IKT-sikkerhet | NSMs grunnprinsipper for AI-systemer |

### Digitaliseringsrundskrivet

Regjeringens retningslinjer for offentlig sektors digitalisering:

| Prinsipp | AI-relevans |
|----------|-------------|
| Skyforst-strategi | Sky er forstevalg, men med unntak for sensitiv data |
| Apne data | AI-modeller bor benytte apne datakilder der mulig |
| Deling av data | Samarbeid mellom etater om AI-treningsdata |
| Personvern | DPIA for alle AI-systemer med persondata |
| Tilgjengelighet | AI-tjenester ma vaere universelt utformet |

---

## Azure Data Residency for Norge

### Azure-regioner i Norge

| Region | Tjenester | Formaal |
|--------|-----------|---------|
| Norway East (Oslo) | Fullt tjenesteomfang | Primaerregion |
| Norway West (Stavanger) | Begrenset | DR/backup |

### Azure-tjenester tilgjengelig i Norway East

| Tjenestekategori | Tilgjengelighet | Merknader |
|-----------------|-----------------|-----------|
| Compute (VMs) | GA | Inkl. GPU (NC, ND-serier) |
| Azure Kubernetes Service | GA | Primaer container-plattform |
| Azure Storage | GA | Alle lagringstyper |
| Azure SQL/Cosmos DB | GA | Regional data residency |
| Microsoft Foundry | Begrenset | Ikke alle modeller |
| Azure OpenAI | GA | GPT-4o, GPT-4o-mini |
| Azure AI Services | GA | Vision, Speech, Language |
| Azure Machine Learning | GA | Trening og inferens |
| Azure Key Vault | GA | Hemmelighetshaandtering |
| Azure Monitor | GA | Overvaking |

### Tjenester som IKKE er tilgjengelige i Norway East

| Tjeneste | Naermeste region | Alternativ |
|----------|-----------------|------------|
| Azure OpenAI (GPT-5) | Sweden Central | Bruk EUDB-region |
| Copilot Studio | EU-regioner | Sett tenant til EU |
| Noen AI Foundry-modeller | Sweden/West Europe | Vurder EUDB-scope |
| Azure AI Search (semantic) | West Europe | Kan kreve EU-plassering |

---

## EU Data Boundary (EUDB)

### Hva er EUDB?

EU Data Boundary er Microsofts forpliktelse til a lagre og behandle kundedata og persondata innenfor EU/EFTA for sine enterprise online services:

| Tjeneste | EUDB-stottet | Betingelse |
|----------|-------------|------------|
| Azure (regionale) | Ja | Deploy i EU/EFTA-region |
| Azure (ikke-regionale) | Delvis | Krever konfigurasjon |
| Dynamics 365 | Ja | Tenant i EU geo |
| Power Platform | Ja | Miljo i EU geo |
| Microsoft 365 | Ja | Tenant i EU geo |

### EUDB-land

EU Data Boundary dekker:
- **EU:** Osterrike, Belgia, Bulgaria, Kroatia, Kypros, Tsjekkia, Danmark, Estland, Finland, Frankrike, Tyskland, Hellas, Ungarn, Irland, Italia, Latvia, Litauen, Luxembourg, Malta, Nederland, Polen, Portugal, Romania, Slovakia, Slovenia, Spania, Sverige
- **EFTA:** Liechtenstein, Island, **Norge**, Sveits

### Konfigurering av EUDB for Azure

```bash
# Konfigurer Azure Data Boundary for tenant
az data-boundary create --data-boundary EU --default default
```

```json
// Azure Policy: Tving ressurser til Norway East
{
  "if": {
    "not": {
      "field": "location",
      "in": ["norwayeast", "norwaywest", "swedencentral",
             "westeurope", "northeurope"]
    }
  },
  "then": {
    "effect": "deny"
  }
}
```

---

## Microsoft Sovereign Cloud

### Sovereign deployment-modeller

Microsoft tilbyr tre nivaer av suverenitet:

| Modell | Beskrivelse | Kontrollniva | Tilgjengelighet |
|--------|-------------|-------------|-----------------|
| Sovereign Public Cloud | Azure med EUDB + sovereign controls | Hoy | GA (EU/EFTA) |
| Sovereign Private Cloud | Azure Local/M365 Local i eget datasenter | Hoyest | GA |
| National Partner Clouds | Partnerdrevet lokal sky | Variabel | Utvalgte land |

### Sovereign Landing Zone (SLZ)

SLZ er en variant av Azure Landing Zone med innebygde suverenitetskontroller:

| Kontrollniva | Policyer | Bruksomrade |
|-------------|----------|-------------|
| L1 (Basis) | Data residency, godkjente regioner | Standard offentlig sektor |
| L2 (Styrket) | L1 + kryptering med CMK | Sensitiv data |
| L3 (Konfidensielt) | L2 + confidential computing | Sikkerhetsgradert |

**SLZ Policy-kontroller:**

| Policy-ID | Kontroll | Effekt |
|-----------|---------|--------|
| SO.1 | Data residency — godkjente regioner | Deny |
| SO.2 | Kryptering med kundestyrt nokkel (CMK) | Audit/Deny |
| SO.3 | Confidential computing for utvalgte tjenester | Audit |
| SO.4 | Private endpoints for datatilgang | Deny |

### Implementering av SLZ

```bash
# Deploy Sovereign Landing Zone med Bicep
az deployment sub create \
  --location norwayeast \
  --template-file sovereign-landing-zone.bicep \
  --parameters \
    allowedLocations='["norwayeast","norwaywest"]' \
    requireCMK=true \
    enforcePrivateEndpoints=true \
    dataClassification="sensitive"
```

---

## Azure Data Classification for AI

### Dataklassifiseringsmatrise

| Klassifisering | Beskrivelse | Sky-tillatelse | Azure-krav |
|---------------|-------------|----------------|------------|
| Apen | Offentlig tilgjengelig | Alle regioner | Standard |
| Intern | Ikke-sensitiv intern data | EU/EFTA | EUDB |
| Fortrolig | Sensitiv, persondata | Norway East/West | CMK + RBAC |
| Strengt fortrolig | Hoy sensitivitet | Norway + spesialtiltak | SLZ L2+ |
| Sikkerhetsgradert | Underlagt sikkerhetsloven | Lokalt / godkjent sky | Azure Local |

### AI-spesifikke datakategorier

| Datakategori | Eksempel | Klassifisering | Behandlingssted |
|-------------|----------|---------------|-----------------|
| Treningsdata | Dokumenter, bilder | Fortrolig+ | Norway East |
| Modellvekter | Fine-tuned modeller | Intern/Fortrolig | Norway East |
| Inferens-input | Brukerforesporsler | Fortrolig | Norway East |
| Inferens-output | AI-svar | Fortrolig | Norway East |
| Systemlogger | Telemetri, metrikker | Intern | EU/EFTA |
| Prompt-logger | Bruker-prompts | Fortrolig | Norway East |

---

## Praktiske arkitekturmoenstre

### Moenster 1: Full sky i Norway East

```
┌─────────────────────────────────────┐
│        Norway East Region            │
│  ┌───────────┐  ┌───────────────┐  │
│  │ Azure     │  │ Azure AI      │  │
│  │ OpenAI    │  │ Services      │  │
│  │ (GPT-4o)  │  │ (Vision,Speech│  │
│  └─────┬─────┘  └──────┬────────┘  │
│        │               │           │
│  ┌─────▼───────────────▼────────┐  │
│  │    Azure ML Workspace        │  │
│  │    + Private Endpoints       │  │
│  └──────────────────────────────┘  │
│  ┌──────────────────────────────┐  │
│  │    Azure Key Vault (CMK)     │  │
│  └──────────────────────────────┘  │
└─────────────────────────────────────┘
```

**Best for:** Standard AI-prosjekter uten krav utover GDPR/EUDB.

### Moenster 2: Hybrid med Azure Local

```
┌──────────────────────┐  ┌────────────────────┐
│    Norway East        │  │   Eget datasenter  │
│  ┌────────────────┐  │  │  ┌──────────────┐  │
│  │ Azure ML       │  │  │  │ Azure Local   │  │
│  │ (Orchestration)│◄─┼──┼─►│ (AI Inference)│  │
│  └────────────────┘  │  │  │ GPU + Data    │  │
│  ┌────────────────┐  │  │  └──────────────┘  │
│  │ Azure Monitor  │  │  │  ┌──────────────┐  │
│  │ (Overvaking)   │◄─┼──┼──│ Arc Agent    │  │
│  └────────────────┘  │  │  └──────────────┘  │
└──────────────────────┘  └────────────────────┘
```

**Best for:** Sensitiv data som ikke kan forlate egne lokaler, men trenger sky-administrasjon.

### Moenster 3: Fullstendig lokal (sovereign private)

```
┌─────────────────────────────────────┐
│         Eget datasenter              │
│  ┌──────────────────────────────┐   │
│  │     Azure Local Cluster      │   │
│  │  ┌────────┐  ┌───────────┐  │   │
│  │  │ AKS    │  │ ONNX      │  │   │
│  │  │ (KAITO)│  │ Runtime   │  │   │
│  │  └────────┘  └───────────┘  │   │
│  │  ┌────────────────────────┐  │   │
│  │  │ Disconnected          │  │   │
│  │  │ AI Containers         │  │   │
│  │  └────────────────────────┘  │   │
│  └──────────────────────────────┘   │
│  Ingen ekstern tilkobling           │
└─────────────────────────────────────┘
```

**Best for:** Sikkerhetsgradert data, forsvarssektor, kritisk infrastruktur.

---

## Beslutningstre for datasuverenitet

```
Er dataene sikkerhetsgraderte (Sikkerhetsloven)?
├── Ja → Moenster 3: Azure Local, helt lokalt
│        Ingen sky-tilkobling
│        ONNX Runtime + Disconnected containers
│
└── Nei → Inneholder dataene personopplysninger?
    ├── Ja → Er det saerlige kategorier (helse, biometri)?
    │   ├── Ja → Moenster 2: Hybrid
    │   │        Data lokalt, styring fra Norway East
    │   │        DPIA pakrevd, CMK-kryptering
    │   │
    │   └── Nei → Moenster 1 eller 2
    │            Norway East med EUDB
    │            Standard GDPR-tiltak
    │
    └── Nei → Moenster 1: Full sky
             Norway East / EU region
             Standard sikkerhetstiltak
```

---

## Compliance-sjekkliste for AI-prosjekter

| # | Kontroll | Ansvarlig | Status |
|---|---------|-----------|--------|
| 1 | DPIA gjennomfort | Personvernombud | |
| 2 | Behandlingsgrunnlag dokumentert | Juridisk | |
| 3 | Dataklassifisering gjennomfort | Informasjonseier | |
| 4 | Azure-region valgt (Norway East) | IT-arkitekt | |
| 5 | EUDB konfigurert | Sky-administrator | |
| 6 | CMK aktivert for sensitiv data | Sikkerhetsansvarlig | |
| 7 | Private endpoints konfigurert | Nettverksansvarlig | |
| 8 | RBAC implementert | IAM-ansvarlig | |
| 9 | Logging og overvaking aktivert | Driftsansvarlig | |
| 10 | AI Act risikoklassifisering | AI-ansvarlig | |
| 11 | Utredningsinstruksen fulgt | Prosjektleder | |
| 12 | ROS-analyse gjennomfort | Sikkerhetsansvarlig | |
| 13 | Leverandorvurdering gjennomfort | Innkjopsansvarlig | |
| 14 | Databehandleravtale inngatt | Juridisk | |
| 15 | Exitstrategi dokumentert | IT-arkitekt | |

---

## Sammenligning: Sovereign Cloud-alternativer

| Egenskap | Azure Sovereign Public | Azure Local (Private) | National Partner Cloud |
|----------|----------------------|----------------------|----------------------|
| Data residency | EU/EFTA (konfiguerbar) | Fullt lokalt | Varierer |
| Kontroll over data | Microsoft-driftet | Kunde-driftet | Partnerdriftet |
| AI-tjenester | Fullt omfang | Begrensede (ONNX, containers) | Varierer |
| Skalerbarhet | Hoy | Begrenset av hardware | Varierer |
| Kostnad | Pay-as-you-go | CAPEX + OPEX | Varierer |
| Compliance (GDPR) | Ja | Ja | Varierer |
| Compliance (NSM) | Delvis | Ja (med tiltak) | Varierer |
| Sikkerhetsgradert | Nei | Mulig | Varierer |
| AI Act compliance | Verktoy tilgjengelig | Kunde-ansvar | Varierer |

---

## For Cosmo

- **Schrems II er ikke lenger den eneste utfordringen** — EU-US Data Privacy Framework (2023), EU Data Boundary, og Sovereign Landing Zone gir et nyansert verktoyskrin for lovlig bruk av Azure AI fra Norge.
- **Norway East-regionen er forstevalg for norsk offentlig sektor** — de fleste AI-tjenester (Azure OpenAI GPT-4o, AI Services, ML) er tilgjengelig der, men noen nyere modeller krever Sweden Central eller West Europe.
- **Tre arkitekturmoenstre dekker hele spekteret** — full sky for standard data, hybrid for sensitiv data, og helt lokalt (Azure Local) for sikkerhetsgradert — alltid med DPIA og risikovurdering.
- **Sovereign Landing Zone med L1-L3 policyer** gir mekanisk haandheving av data residency, kryptering og tilgangskontroll — ikke bare dokumentbaserte lovnader.
- **AI Act-klassifisering ma gjores for hvert AI-prosjekt** — norsk offentlig sektor ma identifisere risikokategori (minimal/begrenset/hoy/uakseptabel) og implementere tilsvarende tiltak for AI-systemer.