# Public Sector Checklist - Norsk offentlig sektor og Microsoft AI

**Last updated:** 2026-01 (research via microsoft-learn MCP + WebSearch)
**Målgruppe:** Arkitekter som rådgiver norske offentlige virksomheter

---

Dette dokumentet gir en omfattende sjekkliste for norske offentlige virksomheter som vurderer eller implementerer Microsoft AI-løsninger. Sjekklisten dekker norsk regelverk, EU-direktiver, dataresidenskrav, sikkerhetsvurderinger og Responsible AI-prinsipper.

## 1. Regulatorisk landskap (Norge + EU)

### 1.1 Norske lover og forskrifter

**Forvaltningsloven**
- Krav til forsvarlig saksbehandling (§ 17)
- Veiledningsplikt overfor publikum (§ 11)
- Begrunnelsesplikt for vedtak (§§ 24-25)
- **AI-implikasjon:** Automatiserte beslutninger må kunne forklares og begrunnes

**Offentleglova (Offentlighetsloven)**
- Hovedregel om offentlighet for saksdokumenter (§ 3)
- Unntak for taushetsbelagt informasjon (§ 13)
- **AI-implikasjon:** AI-generert innhold kan være offentlig; loggføring av AI-beslutninger må journalføres

**Arkivlova**
- Plikt til å arkivere offentlige dokumenter (§ 6)
- Krav til bevaringsverdig dokumentasjon (§ 9)
- **AI-implikasjon:** AI-genererte dokumenter og beslutningsgrunnlag må arkiveres i henhold til Noark 5-standarden

**Personopplysningsloven (GDPR-implementering)**
- Norsk implementering av EU GDPR
- Datatilsynet er norsk tilsynsmyndighet
- **AI-implikasjon:** Se eget GDPR-avsnitt nedenfor

**Informasjonssikkerhetsloven** (vedtatt 2024, trer i kraft 2025)
- Omfatter offentlige virksomheter og kritisk infrastruktur
- Krav til sikkerhetsstyring og risikovurderinger
- **AI-implikasjon:** AI-systemer må inngå i virksomhetens helhetlige risikovurdering

### 1.2 EU-regelverk som gjelder Norge (EØS)

**GDPR (General Data Protection Regulation)**
- Gjeldende fra mai 2018
- Datatilsynet håndhever i Norge
- **Viktige artikler for AI:**
  - Art. 22: Rett til ikke å bli underlagt automatiserte beslutninger
  - Art. 35: Data Protection Impact Assessment (DPIA) ved høy risiko
  - Art. 28: Databehandleravtaler (viktig for Microsoft-tjenester)

**AI Act** (EU Artificial Intelligence Act)
- **Norsk implementering:** Regjeringen sendte lovforslag på høring januar 2025
- **Ikrafttredelse i Norge:** Planlagt august 2026 (samtidig med EU)
- **Tilsynsmyndighet:** Nasjonal kommunikasjonsmyndighet (Nkom) blir koordinerende tilsynsmyndighet
- **Viktige implikasjoner:**
  - Risikobasert tilnærming (uakseptabel, høy, begrenset, minimal risiko)
  - Høyrisikoklassifiserte AI-systemer krever omfattende dokumentasjon
  - Bøter også for offentlige virksomheter (viktig endring fra tidligere praksis)
  - Transparenskrav for AI-generert innhold

**NIS2-direktivet** (Network and Information Security)
- Implementeres i Norge gjennom informasjonssikkerhetsloven
- Gjelder kritisk infrastruktur og viktige sektorer
- **AI-implikasjon:** Cybersikkerhetskrav for AI-systemer i scope-virksomheter

**Schrems II-konsekvenser**
- EU-domstolens avgjørelse fra 2020 om dataoverføringer til USA
- **Status i Norge (2025):**
  - Norske offentlige virksomheter har jobbet tett med dette siden 2020
  - Microsoft har svart med informasjonspakke og bekreftet ingen utleveringer av data fra norsk offentlig sektor til etterretning
  - EU-US Data Privacy Framework vedtatt, men juridisk usikkerhet gjenstår
  - **Anbefaling:** Bruk Microsofts EU Data Boundary-garanti (se seksjon 5)

## 2. Pre-implementering sjekkliste

Følg denne fasen-for-fase sjekklisten før implementering av Microsoft AI-løsninger.

### Fase 1: Innledende vurdering

- [ ] **Behovsanalyse**
  - Dokumenter forretningsbehov og forventet gevinst
  - Identifiser hvilke oppgaver AI skal utføre
  - Vurder om AI er riktig løsning (AI er ikke alltid svaret)

- [ ] **Risikoklassifisering iht. AI Act**
  - Er løsningen høyrisiko? (f.eks. saksbehandling, HR-systemer, kritisk infrastruktur)
  - Innebærer løsningen forbudte bruksområder? (f.eks. sosial scoring, sanntidsbiometri i offentlig rom)
  - Dokumenter klassifiseringen

- [ ] **Personvernvurdering (DPIA)**
  - Er DPIA påkrevd? (AI-systemer med persondata er ofte høyrisiko)
  - Involver virksomhetens personvernombud
  - Dokumenter personvernrisiko og mottiltak
  - Vurder behov for konsultasjon med Datatilsynet

- [ ] **Sikkerhetsvurdering (ROS-analyse)**
  - Gjennomfør ROS-analyse iht. NSMs grunnprinsipper for IKT-sikkerhet
  - Vurder trusler mot konfidensialitet, integritet og tilgjengelighet
  - Dokumenter akseptkriterier for risiko
  - Involver virksomhetens sikkerhetsansvarlig

- [ ] **Leverandørvurdering**
  - Er Microsoft godkjent leverandør i virksomheten?
  - Finnes gjeldende rammeavtale?
  - Er anskaffelsen i tråd med anskaffelsesregelverket?
  - Har virksomheten kompetanse til å forvalte løsningen?

### Fase 2: Juridisk og kontraktsmessig

- [ ] **Databehandleravtale (DPA)**
  - Signer Microsofts Data Protection Addendum (DPA)
  - Verifiser at DPA dekker alle planlagte tjenester
  - Sjekk at DPA er oppdatert med nyeste versjon

- [ ] **Product Terms og Service Level Agreement**
  - Les Microsofts Product Terms for aktuelle tjenester
  - Forstå SLA-garantier (typisk 99,9% for Microsoft 365, Azure AI)
  - Dokumenter hva som IKKE dekkes av SLA

- [ ] **Ansvar og rollefordeling**
  - Klargjør Microsofts ansvar som databehandler
  - Klargjør virksomhetens ansvar som behandlingsansvarlig
  - Dokumenter shared responsibility model for valgte tjenester

- [ ] **Dataresidenskrav (se seksjon 5)**
  - Bestem krav til datalokalisering
  - Vurder behov for Advanced Data Residency
  - Dokumenter valg og begrunnelse

### Fase 3: Teknisk planlegging

- [ ] **Informasjonsklassifisering**
  - Klassifiser data som skal brukes av AI-systemet (se seksjon 3)
  - Vurder om gradering er nødvendig (begrenset/fortrolig/hemmelig)
  - Avklar om ugradert/åpen informasjon kan benyttes

- [ ] **Tilgangskontroll**
  - Design rolle- og tilgangsmodell (RBAC)
  - Implementer Microsoft Entra ID med conditional access
  - Planlegg Multi-Factor Authentication (MFA) for alle brukere

- [ ] **Dataminimering**
  - Identifiser minimumssett av data som trengs
  - Planlegg anonymisering/pseudonymisering der mulig
  - Dokumenter begrunnelse for dataomfang

- [ ] **Logging og revisjonsspor**
  - Planlegg logging av alle AI-interaksjoner
  - Sikre at logger oppfyller krav i arkivlova
  - Bestem lagringsperiode for logger

- [ ] **Integrasjoner**
  - Kartlegg integrasjoner med eksisterende fagsystemer
  - Vurder sikkerheten i dataflyt mellom systemer
  - Planlegg API-sikkerhet (API Management, OAuth 2.0)

### Fase 4: Responsible AI-vurdering

- [ ] **Formålsbegrensning**
  - Definer AI-systemets formål presist
  - Dokumenter tillatte og ikke-tillatte bruksområder
  - Kommuniser formål til sluttbrukere

- [ ] **Rettferdighet og ikke-diskriminering**
  - Vurder risiko for bias i treningsdata
  - Planlegg testing for urimelige utfall på sårbare grupper
  - Etabler prosess for å håndtere klager på urettferdig behandling

- [ ] **Transparens**
  - Planlegg hvordan brukere skal informeres om AI-bruk
  - Utform menneske-vennlige forklaringer av AI-beslutninger
  - Vurder behov for AI-watermarking (spesielt for generativ AI)

- [ ] **Menneske-i-løkken (Human-in-the-loop)**
  - Identifiser beslutninger som krever manuell godkjenning
  - Design override-mekanismer for AI-forslag
  - Tren ansatte i når de skal overstyre AI

- [ ] **Accountability**
  - Utnevn ansvarlig for AI-systemet
  - Etabler eskaleringsveier ved problemer
  - Planlegg regelmessig gjennomgang av AI-ytelse

## 3. Dataklassifisering og håndteringskrav

Norske offentlige virksomheter bruker sikkerhetsgraderings-systemet fra NSM for informasjon som krever beskyttelse.

### 3.1 Sikkerhetsgraderte opplysninger (NSMs klassifiseringssystem)

| Gradering | Definisjon | Microsoft AI-anbefalinger |
|-----------|------------|---------------------------|
| **Ugradert** | Informasjon som ikke trenger beskyttelse ut over normal personvern- og informasjonssikkerhet | ✅ Kan bruke: Azure OpenAI, M365 Copilot, Power Platform AI (med riktig konfigurasjon) |
| **Begrenset** | Uautorisert tilgang kan være til skade for enkeltpersoner, virksomhet eller nasjon | ⚠️ Kan bruke Azure/M365 med forsterkede sikkerhetstiltak: <br>- Data residency i Norge/EU<br>- Customer Lockbox aktivert<br>- Auditing og DLP konfigurert<br>- Private endpoints (ingen offentlig internett-eksponering) |
| **Fortrolig** | Uautorisert tilgang kan være til alvorlig skade | ⚠️ Krever grundig risikovurdering:<br>- Vurder Azure Stack Hub (on-premises)<br>- Eller Azure med dedikerte ressurser og kryptering med kundestyrt nøkkel<br>- Ikke bruk multi-tenant AI-tjenester uten godkjenning fra sikkerhetsansvarlig |
| **Hemmelig** | Uautorisert tilgang kan være til meget alvorlig skade for nasjonal sikkerhet | ❌ Skal IKKE bruke public cloud AI-tjenester<br>✅ Bruk Azure Stack Hub (air-gapped) eller on-premises løsninger |
| **Strengt hemmelig** | Uautorisert tilgang kan være til eksepsjonelt alvorlig skade | ❌ Skal IKKE bruke public cloud AI-tjenester<br>✅ Kun on-premises, fysisk isolerte systemer |

### 3.2 Personopplysninger (GDPR-kategorier)

| Kategori | Eksempler | Microsoft AI-tiltak |
|----------|-----------|---------------------|
| **Vanlige personopplysninger** | Navn, e-post, telefonnummer | - Bruk Microsoft Purview DLP<br>- Aktivér sensitivity labels<br>- Implementer retention policies |
| **Sensitive personopplysninger** (GDPR Art. 9) | Helse, etnisitet, politisk mening, religion, fagforeningsmedlemskap, biometri, genetikk, seksuell orientering | - DPIA obligatorisk<br>- Ekstra sikkerhetstiltak (kryptering, tilgangskontroll)<br>- Vurder om AI-behandling er strengt nødvendig<br>- Dokumenter rettslig grunnlag |
| **Opplysninger om straffedommer** (GDPR Art. 10) | Straffehistorikk, lovanvendelse | - Kun lovhjemlet behandling<br>- Ekstra tilgangskontroll<br>- Separat logging og auditspor |

### 3.3 Beste praksis for datahåndtering

**Dataminimering:**
- Fjern unødvendige personopplysninger før AI-behandling
- Bruk aggregerte data der mulig
- Implementer automatisk sletting etter definert periode

**Pseudonymisering:**
- Erstatt direkte identifikatorer med pseudonymer
- Lagre koblingsnøkkel separat med strengere tilgangskontroll
- Vurder differential privacy for statistiske analyser

**Kryptering:**
- Data i transit: TLS 1.2 minimum (TLS 1.3 anbefalt)
- Data at rest: Azure Storage Service Encryption (256-bit AES)
- Vurder Customer Managed Keys (CMK) for sensitiv data

## 4. Microsoft compliance-sertifiseringer relevante for Norge

Microsoft har omfattende compliance-portefølje. Følgende er spesielt relevante for norsk offentlig sektor.

### 4.1 Internasjonale standarder

| Sertifisering | Hva dekkes | Relevans for Norge |
|---------------|------------|---------------------|
| **ISO/IEC 27001** | Informasjonssikkerhetsledelse | ✅ Grunnleggende krav for offentlig sektor |
| **ISO/IEC 27017** | Cloud-spesifikk informasjonssikkerhet | ✅ Viktig for skytjenester |
| **ISO/IEC 27018** | Personvern i public cloud | ✅ Understøtter GDPR-compliance |
| **ISO/IEC 27701** | Privacy Information Management System (PIMS) | ✅ Demonstrerer personvernprosesser |
| **SOC 1/2/3** | Service Organization Controls | ✅ Transparens om interne kontroller |

### 4.2 EU/EØS-spesifikke

| Sertifisering | Hva dekkes | Status |
|---------------|------------|--------|
| **EU Cloud Code of Conduct** | GDPR Art. 28-krav for databehandlere | ✅ Azure har level 2 compliance (2021) |
| **EU Data Boundary** | Forpliktelse om datalokalisering i EU | ✅ Gjeldende fra 2023; dekker Azure, M365, Dynamics 365 |
| **EUDB (EU Data Boundary)** | Garanterer at kunde- og diagnostikkdata ikke forlater EU | ✅ Norge inkludert via EØS (datasentre i Norge: Oslo, Stavanger) |

### 4.3 Verifisering av sertifiseringer

**Service Trust Portal:**
- URL: https://servicetrust.microsoft.com
- Krever Microsoft-konto
- Tilgang til:
  - Audit reports (ISO, SOC, etc.)
  - Compliance guides
  - Risk assessment tools
  - Data protection impact assessment templates

**Azure Compliance Documentation:**
- URL: https://learn.microsoft.com/en-us/azure/compliance/
- Publisert tilgjengelig oversikt
- Oppdateres regelmessig

## 5. Dataresidenskrav og beslutningstrær

### 5.1 Microsoft-garanti for datalokalisering (Norge)

**Product Terms commitment (M365, Azure):**
- Norge er "Local Region Geography"
- Datasentre: Oslo, Stavanger
- **Garantert lokalisering for:**
  - Exchange Online (mailbox-innhold)
  - SharePoint Online / OneDrive (filer)
  - Microsoft Teams (chat, filer, møteopptak)
  - Microsoft 365 Copilot og Copilot Chat (interaksjonsdata)

**Viktig nyanse:**
- Product Terms dekker *Core Services* for Norge
- **Utvidede tjenester** (f.eks. Viva, Purview, Defender for Office) krever **Advanced Data Residency (ADR)** for garantert Norge-lokalisering
- Diagnostic data og telemetri kan sendes til EU/USA for plattformforvalting (ikke kundeinnhold)

### 5.2 Beslutningstre for dataresidenskrav

```
START: Hvilken type data skal behandles?

├─ Inneholder IKKE personopplysninger?
│  └─ Ugradert offentlig informasjon?
│     ├─ Ja → Standard Azure/M365 OK (følg normal sikkerhetspraksis)
│     └─ Nei (f.eks. forretningshemmeligheter) → Vurder dataresidenskrav basert på risiko
│
├─ Inneholder personopplysninger (GDPR)?
│  └─ Er dataene sensitive iht. GDPR Art. 9?
│     ├─ Ja (helse, etnisitet, etc.)
│     │  └─ KREVER:
│     │     - DPIA
│     │     - Data residency i Norge/EU (Product Terms eller ADR)
│     │     - Microsoft DPA signert
│     │     - Vurder Customer Managed Keys
│     │
│     └─ Nei (vanlige personopplysninger)
│        └─ KREVER:
│           - Data residency i Norge/EU anbefalt
│           - Microsoft DPA signert
│           - Purview DLP konfigurert
│
└─ Gradert informasjon (NSM)?
   ├─ Begrenset
   │  └─ Kan bruke Azure/M365 med:
   │     - Data residency Norge
   │     - Customer Lockbox
   │     - Private endpoints
   │     - Avansert logging
   │
   ├─ Fortrolig
   │  └─ Krever risikovurdering:
   │     - Vurder Azure Stack Hub (on-prem)
   │     - ELLER Azure med dedikert tenant og CMK
   │     - Unngå multi-tenant AI-tjenester
   │
   └─ Hemmelig / Strengt hemmelig
      └─ IKKE bruk public cloud
         - Kun on-premises løsninger
         - Azure Stack Hub (air-gapped)
```

### 5.3 Tilgjengelige Microsoft-alternativer

| Løsning | Datalokalisering | Egnet for | Kostnad |
|---------|------------------|-----------|---------|
| **Standard Azure/M365** | Norge (Oslo/Stavanger) via Product Terms | Ugradert, vanlige personopplysninger | Standard lisens |
| **Advanced Data Residency (ADR)** | Norge (garantert for utvidede tjenester) | Sensitive personopplysninger, høye residenskrav | +ekstra lisenskostnad |
| **Multi-Geo** | Velg geo per bruker/ressurs | Multinasjonale organisasjoner | +ekstra lisenskostnad |
| **Azure Government (EU)** | EU-dedikerte datasentre | Offentlig sektor med strenge krav | Egne SKUer |
| **Azure Stack Hub** | On-premises (kundens datasentre) | Begrenset/fortrolig, hybridskyløsninger | Investeringskostnad + lisens |
| **Azure Stack Edge** | Edge/feltlokasjon | Begrenset konnektivitet, lav latens | Hardware + lisens |

### 5.4 Schrems II-mitigering

**Microsoft EU Data Boundary (EUDB):**
- Gjeldende fra 1. januar 2023
- Dekker Azure, M365, Dynamics 365, Power Platform
- **Garanti:**
  - Kundedata lagres og prosesseres i EU
  - Støttepersonell kun fra EU (unntatt ekstraordinære situasjoner med kundesamtykke)
  - Ingen dataoverføring til USA for kjernefunksjonalitet

**Juridisk grunnlag for dataoverføring (hvis nødvendig):**
1. **EU Standard Contractual Clauses (SCC)** - Microsoft DPA inkluderer SCC
2. **EU-US Data Privacy Framework** - Microsoft er sertifisert, men juridisk usikkerhet gjenstår
3. **Supplerende tiltak:**
   - Kryptering med Customer Managed Keys (CMK)
   - Customer Lockbox (krever godkjenning før Microsoft-tilgang)
   - Transparent logging av all Microsoft-tilgang

**Anbefaling for norsk offentlig sektor:**
- Benytt EU Data Boundary
- Aktiver Customer Lockbox
- Krev data residency i Norge/EU
- Dokumenter i DPIA

## 6. Sikkerhetsvurderingskrav (DPIA, ROS-analyse)

### 6.1 Data Protection Impact Assessment (DPIA)

**Når er DPIA obligatorisk?**
- Behandling av sensitive personopplysninger (GDPR Art. 9)
- Systematisk overvåking av offentlig tilgjengelige områder
- Automatiserte beslutninger med rettslige konsekvenser (GDPR Art. 22)
- Storskala behandling av personopplysninger
- **AI-systemer:** De fleste AI-systemer i offentlig sektor vil utløse DPIA-krav

**DPIA-prosess:**
1. **Beskriv behandlingen**
   - Formål med AI-systemet
   - Typer personopplysninger
   - Datakilde og dataflyt
   - Lagringsperiode

2. **Vurder nødvendighet og proporsjonalitet**
   - Er AI-behandling nødvendig for formålet?
   - Finnes mindre inngripende alternativer?
   - Er dataomfang proporsjonalt?

3. **Identifiser risikoer**
   - Risiko for urettmessig tilgang
   - Risiko for bias/diskriminering
   - Risiko for feilaktige beslutninger
   - Risiko ved databrudd

4. **Identifiser mottiltak**
   - Tekniske tiltak (kryptering, tilgangskontroll, logging)
   - Organisatoriske tiltak (opplæring, retningslinjer, kvalitetssikring)
   - Prosedyrer for rettighetsutøvelse (innsyn, sletting, retting)

5. **Konsulter personvernombud**
   - Alltid involvert ved DPIA
   - Råd og kvalitetssikring

6. **Vurder konsultasjon med Datatilsynet**
   - Obligatorisk hvis restrisiko er høy etter mottiltak
   - Datatilsynet har 8 ukers svarfrist

**Microsoft-verktøy for DPIA:**
- Microsoft har publisert DPIA-templates for Azure og M365
- URL: https://learn.microsoft.com/en-us/compliance/regulatory/gdpr-data-protection-impact-assessments
- Inkluderer pre-populated informasjon om Microsoft-kontroller

### 6.2 ROS-analyse (Risiko- og sårbarhetsanalyse)

**NSMs krav:**
- Følg "Grunnprinsipper for IKT-sikkerhet 2.0" fra NSM
- ROS-analyse skal dekke konfidensialitet, integritet og tilgjengelighet

**ROS-prosess for AI-systemer:**

1. **Identifiser verdier**
   - Informasjonsverdier (data, modeller, treningsdata)
   - Funksjoner og tjenester (tilgjengelighet av AI-system)
   - Tillit og omdømme

2. **Identifiser trusler**
   - Eksterne trusler: Cyberangrep, datainnbrudd, DDoS
   - Interne trusler: Misbruk av privilegier, utilsiktet datalekkasje
   - AI-spesifikke trusler: Model poisoning, adversarial attacks, prompt injection

3. **Vurder sårbarheter**
   - Tekniske sårbarheter (ukonfigurert sikkerhet, svake passord)
   - Organisatoriske sårbarheter (mangel på opplæring, uklare roller)
   - AI-spesifikke: Bias i treningsdata, mangel på explainability

4. **Vurder risiko**
   - Sannsynlighet (lav/middels/høy)
   - Konsekvens (lav/middels/høy/kritisk)
   - Risikonivå = sannsynlighet × konsekvens

5. **Foreslå tiltak**
   - Redusere sannsynlighet (forebyggende tiltak)
   - Redusere konsekvens (beskyttelse, beredskap)
   - Prioriter tiltak basert på kost/nytte

6. **Akseptkriterier**
   - Definer akseptabel restrisiko
   - Ledelsens godkjenning av restrisiko
   - Dokumenter i risikomatrise

**NSM sine grunnprinsipper (eksempler relevant for AI):**
- **Identifisere og kartlegge:** Dokumenter alle AI-systemer og dataflyt
- **Beskytte:** Implementer tilgangskontroll, kryptering, segmentering
- **Oppdage:** Logging, SIEM, anomalideteksjon
- **Håndtere og gjenopprette:** Beredskapsplan, backup, incident response

### 6.3 Tilsynskrav og dokumentasjon

**Dokumentasjon som må være tilgjengelig:**
- DPIA-rapport (signert av personvernombud)
- ROS-analyse (godkjent av ledelsen)
- Databehandleravtale med Microsoft (DPA)
- Oversikt over behandlingsaktiviteter (protokoll iht. GDPR Art. 30)
- Rutiner for rettighetsutøvelse (innsyn, sletting, retting, dataportabilitet)
- Beredskapsplan ved personvernbrudd (melding innen 72 timer til Datatilsynet)

**Revisjonsfrekvens:**
- Årlig gjennomgang av DPIA (eller ved vesentlige endringer)
- Årlig ROS-analyse (eller ved nye trusler)
- Løpende overvåking av compliance-status via Microsoft Purview Compliance Manager

## 7. AI Act-implikasjoner for norsk offentlig sektor

### 7.1 Tidsplan og tilsynsmyndighet

**Norsk implementering:**
- Lovforslag sendt på høring: Januar 2025
- Planlagt ikrafttredelse: August 2026
- Tilsynsmyndighet: Nasjonal kommunikasjonsmyndighet (Nkom) som koordinerende myndighet
- Sektoransvarlige myndigheter har også ansvar (f.eks. Helsedirektoratet for helsesektoren)

**Viktig:** EU AI Act får direkte virkning i Norge via EØS-avtalen.

### 7.2 Risikoklassifisering (AI Act)

| Risikokategori | Definisjon | Eksempler offentlig sektor | Krav |
|----------------|------------|----------------------------|------|
| **Uakseptabel risiko** | Forbudt bruk | - Sosial scoring av borgere<br>- Sanntids biometrisk identifikasjon i offentlig rom (med unntak for alvorlig kriminalitet)<br>- Manipulerende AI | ❌ Forbudt |
| **Høy risiko** | Kan påvirke helse, sikkerhet eller grunnleggende rettigheter betydelig | - AI i offentlig saksbehandling (vedtak)<br>- Rekruttering i offentlig sektor<br>- Kritisk infrastruktur (vann, energi, transport)<br>- Lovhåndhevelse (prediktiv policing) | ✅ Strengt regulert:<br>- Risikovurdering og testing<br>- Omfattende dokumentasjon<br>- Human oversight obligatorisk<br>- Registrering i EU-database<br>- Conformity assessment |
| **Begrenset risiko** | Noen åpenbaringsplikter | - Chatbots for publikumskontakt<br>- AI-generert innhold (tekst, bilder, video) | ⚠️ Transparenskrav:<br>- Informere brukere om AI-bruk<br>- Merking av generert innhold |
| **Minimal risiko** | Lite eller ingen regulering | - Spamfilter<br>- AI-basert søk i dokumenter | ✅ Frivillige etiske retningslinjer |

### 7.3 Krav til høyrisikoklassifiserte AI-systemer

**Før ibruktagelse:**
1. **Risk management system**
   - Identifiser kjente og forutsigbare risikoer
   - Estimer og evaluer risiko
   - Implementer tiltak
   - Dokumenter prosessen

2. **Data governance**
   - Relevante, representative og feilfrie treningsdata
   - Unngå bias
   - Dokumenter datakilder og datakvalitet

3. **Teknisk dokumentasjon**
   - Systembeskrivelse
   - Design og arkitektur
   - Testing og validering
   - Ytelsesmetrikker

4. **Logging**
   - Automatisk logging av AI-beslutninger
   - Sporbarhet (hvem, hva, når)
   - Mulighet for etterfølgende granskning

5. **Transparens og informasjon**
   - Brukere må informeres om AI-bruk
   - Forståelige forklaringer av AI-beslutninger
   - Veiledning for sikker bruk

6. **Human oversight**
   - Mulighet for manuell overstyring
   - Kompetente operatører
   - Tydelig ansvarsfordeling

7. **Robusthet og nøyaktighet**
   - Sikkerhet mot cyberangrep
   - Feilhåndtering
   - Testing under realistiske forhold

8. **Cybersikkerhet**
   - Resiliens mot adversarial attacks
   - Sikker utvikling (secure by design)
   - Sårbarhetshåndtering

**Etter ibruktagelse:**
- **Post-market monitoring:** Løpende overvåking av ytelse
- **Incident reporting:** Melding av alvorlige hendelser til myndighet
- **Oppdateringer:** Vedlikehold av dokumentasjon ved endringer

### 7.4 Microsoft-verktøy for AI Act compliance

**Azure AI Studio:**
- AI safety evaluations (testing for harmful content, groundedness)
- Model cards (dokumentasjon av AI-modeller)
- Responsible AI dashboard

**Microsoft Responsible AI Standard:**
- Internt Microsoft-rammeverk som følger AI Act-prinsipper
- Publisert: https://www.microsoft.com/en-us/ai/responsible-ai

**Azure Policy:**
- Regulatory compliance initiatives for AI-governance
- Automatisert sjekk av compliance-status

### 7.5 Særlige hensyn for norsk offentlig sektor

**Offentlige virksomheter kan bøtelegges:**
- Tidligere antatt at offentlige virksomheter var unntatt fra administrative bøter
- **AI Act:** Norsk implementering foreslår at bøter også skal gjelde offentlig sektor
- Bøtenivå: Inntil 7% av global årlig omsetning (for virksomheter) eller fast beløp (for offentlige)

**Sektoransvar:**
- Helsedirektoratet for helse
- Utdanningsdirektoratet for utdanning
- Etc.
- Disse vil ha sektor-spesifikke veiledninger

**Anskaffelse av AI-systemer:**
- Offentlige anskaffelser må sikre at leverandør (Microsoft) overholder AI Act
- Krav kontraktsklausuler om compliance
- Verifisering av conformity assessment

## 8. Responsible AI-sjekkliste

Denne sjekklisten følger Microsofts Responsible AI-prinsipper og norske etiske retningslinjer.

### 8.1 Rettferdighet (Fairness)

- [ ] **Bias-testing**
  - Test AI-modellen på representative datasett
  - Identifiser uforholdsmessige feil på sårbare grupper (kjønn, alder, etnisitet)
  - Bruk Fairness-verktøy i Azure Machine Learning

- [ ] **Representative data**
  - Verifiser at treningsdata reflekterer målpopulasjonen
  - Dokumenter potensielle skjevheter i datagrunnlag
  - Implementer prosess for å oppdatere modell med nye data

- [ ] **Klageprosess**
  - Etabler prosedyre for borgere/brukere som mener seg urettferdig behandlet
  - Tydelig kommunikasjon av klagerett
  - Logging og oppfølging av klager

### 8.2 Pålitelighet og sikkerhet (Reliability & Safety)

- [ ] **Testing**
  - Grundig testing før produksjonssetting
  - Edge case-testing (hva skjer ved uventede inndata?)
  - Load testing (håndtering av høy belastning)

- [ ] **Feilhåndtering**
  - Graceful degradation (systemet skal ikke krasje ved AI-feil)
  - Fallback til manuelle prosedyrer
  - Tydelig feilmeldinger til brukere

- [ ] **Overvåking**
  - Kontinuerlig overvåking av AI-ytelse (accuracy, precision, recall)
  - Deteksjon av model drift (endring i ytelse over tid)
  - Alert ved avvik fra forventet ytelse

- [ ] **Adversarial robustness**
  - Testing mot adversarial attacks (forsøk på å lure AI)
  - Implementer input validation
  - Beskytt mot prompt injection (spesielt for generativ AI)

### 8.3 Personvern og sikkerhet (Privacy & Security)

- [ ] **Dataminimering**
  - Bruk kun data som er strengt nødvendig
  - Slett data når formål er oppnådd
  - Implementer retention policies

- [ ] **Anonymisering/pseudonymisering**
  - Fjern direkte identifikatorer der mulig
  - Bruk differential privacy for statistiske analyser
  - Vurder federated learning (trening uten sentralisering av data)

- [ ] **Tilgangskontroll**
  - Principle of least privilege (kun nødvendig tilgang)
  - Multi-Factor Authentication (MFA)
  - Regelmessig review av tilganger

- [ ] **Kryptering**
  - Data i transit: TLS 1.2+
  - Data at rest: AES-256
  - Vurder Customer Managed Keys for ekstra kontroll

- [ ] **Audit logging**
  - Logg alle AI-interaksjoner
  - Beskyttet logging (tamper-proof)
  - Lagringsperiode iht. arkivlova

### 8.4 Inkludering (Inclusiveness)

- [ ] **Tilgjengelighet (universell utforming)**
  - AI-grensesnitt følger WCAG 2.1 AA-standarder
  - Støtte for skjermlesere
  - Alternativ til AI (manuelle prosesser)

- [ ] **Språklig inkludering**
  - Støtte for norsk (bokmål og nynorsk)
  - Støtte for samiske språk der relevant
  - Vurder støtte for minoritetsspråk

- [ ] **Digital kompetanse**
  - AI-løsninger skal være enkle å bruke
  - Veiledning og opplæring tilgjengelig
  - Hjelp og support for brukere

### 8.5 Åpenhet (Transparency)

- [ ] **Informasjonsplikt**
  - Informer brukere om at AI brukes
  - Forklar formål med AI-behandling
  - Tydelig kommunikasjon av AI-beslutninger

- [ ] **Forklarbarhet (Explainability)**
  - AI-beslutninger skal kunne forklares
  - Bruk interpretable models der mulig
  - Dokumenter hvordan beslutning ble tatt (audit trail)

- [ ] **AI-generert innhold**
  - Merk AI-generert tekst, bilder, video tydelig
  - Implementer watermarking for generativ AI
  - Unngå at borgere tror AI-innhold er menneskeskapt

- [ ] **Dokumentasjon**
  - Model cards (beskrivelse av AI-modell)
  - Datasheets for datasets (beskrivelse av treningsdata)
  - System cards (beskrivelse av hele AI-systemet)

### 8.6 Ansvarlighet (Accountability)

- [ ] **Tydelig ansvar**
  - Utnevn AI-systemeier
  - Definer roller og ansvar (RACI-matrise)
  - Eskaleringsveier ved problemer

- [ ] **Compliance-overvåking**
  - Regelmessig gjennomgang av AI-etikk
  - Sjekk mot regulatoriske krav
  - Bruk Microsoft Purview Compliance Manager

- [ ] **Menneske-i-løkken (Human-in-the-loop)**
  - AI skal være beslutningsstøtte, ikke erstatte mennesker
  - Kritiske beslutninger krever manuell godkjenning
  - Opplæring av ansatte i når de skal overstyre AI

- [ ] **Incident response**
  - Beredskapsplan ved AI-feil eller misbruk
  - Prosedyre for å stenge ned AI ved alvorlige feil
  - Post-mortem og læring fra hendelser

## 9. Anskaffelseshensyn (anskaffelsesregelverket)

### 9.1 Gjeldende regelverk

**Lov om offentlige anskaffelser (2016)**
- Gjelder anskaffelser over fastsatte terskelverdier
- Krav til konkurranse, likebehandling, forutberegnelighet, etterprøvbarhet

**Anskaffelsesforskriften**
- Detaljer om prosedyrer (åpen, begrenset, konkurransepreget dialog, innovasjonspartnerskap)
- Krav til kunngjøring, tildelingskriterier, kontrakt

### 9.2 AI-spesifikke anskaffelseskrav

**Funksjonelle krav:**
- [ ] Krav til nøyaktighet/presisjon (f.eks. minst 95% accuracy)
- [ ] Krav til forklarbarhet av AI-beslutninger
- [ ] Krav til transparens (model cards, datasheets)
- [ ] Krav til testing og validering før leveranse

**Sikkerhetskrav:**
- [ ] ISO 27001-sertifisert leverandør
- [ ] Penetrasjonstesting av AI-løsning
- [ ] Sikker programvareutviklingssikring (SSDLC)
- [ ] Sårbarhetshåndtering og patching

**Personvern og compliance:**
- [ ] GDPR-compliance (DPA obligatorisk)
- [ ] AI Act-compliance (spesielt for høyrisikosystemer)
- [ ] Data residency-krav (Norge/EU)
- [ ] Revisjonsrett (rett til å inspisere leverandørens prosesser)

**Kontraktsklausuler:**
- [ ] Databehandleravtale (DPA) som vedlegg til kontrakt
- [ ] SLA med definerte ytelsesmål
- [ ] Exit-strategi (rett til å få ut data ved kontraktslutt)
- [ ] Underentreprenører (krav om godkjenning av sub-processors)
- [ ] Ansvar ved personvernbrudd (hvem betaler bøter?)

**Leverandørkompetanse:**
- [ ] Dokumentert erfaring med lignende AI-løsninger
- [ ] Sertifiseringer (f.eks. Microsoft Partner-status)
- [ ] Referanser fra offentlig sektor
- [ ] Norskspråklig support

### 9.3 Microsoft-spesifikke hensyn

**Lisensmodeller:**
- **Commercial Cloud:** Standard lisenser (M365 E3/E5, Azure-forbruk)
- **Enterprise Agreement (EA):** Forhandlet rabatt ved store volumer
- **Rammeavtaler:** DFØs Marketplace for skybaserte tjenester kan benyttes
- **Government pricing:** Spesielle tilbud for offentlig sektor (kontakt Microsoft Norge)

**Leverandørgjennomgang:**
- Microsoft er prekvalifisert hos mange statlige virksomheter
- Sjekk om virksomheten har eksisterende rammeavtale
- Vurder behov for ny konkurranse

**Databehøvd og subprocessors:**
- Microsoft bruker subprocessors (f.eks. datacenterpartnere)
- Liste over subprocessors: https://aka.ms/servicesapproval
- Rett til å protestere mot nye subprocessors (30 dagers varsel)

## 10. Arkivering og dokumentasjonshåndtering

### 10.1 Arkivlova og Noark 5-standard

**Arkivpliktige dokumenter:**
- All korrespondanse som inngår i saksbehandling
- Vedtak fattet med AI-støtte
- AI-genererte rapporter som er del av saksdokumentasjon
- Logg over AI-beslutninger (i visse sakstyper)

**Noark 5-krav:**
- Metadata for AI-genererte dokumenter (hvem, hva, når)
- Sporbarhet: Kobling mellom AI-output og saksbehandler
- Autentisitet: Sikring av at dokument ikke er endret
- Lagringsformat: PDF/A for langtidslagring

### 10.2 AI-spesifikk dokumentasjon som bør arkiveres

- [ ] **AI-systemdokumentasjon**
  - Systembeskrivelse (formål, funksjonalitet)
  - Leverandørinformasjon (Microsoft-kontraktsreferanse)
  - Konfigurasjon og innstillinger

- [ ] **Modell-dokumentasjon**
  - Model cards (for egne ML-modeller)
  - Treningsdata-beskrivelse
  - Valideringresultater

- [ ] **Beslutningsgrunnlag**
  - DPIA-rapport
  - ROS-analyse
  - Ledelsens godkjenning av ibruktagelse

- [ ] **Endringer og oppdateringer**
  - Endringslogg (når ble AI-modell oppdatert?)
  - Testing ved oppdateringer
  - Godkjenning av endringer

### 10.3 Lagringsperiode

**Personopplysninger (GDPR Art. 5):**
- Lagringsperiode skal være begrenset til hva som er nødvendig
- Automatisk sletting etter definert periode
- Unntatt: Arkivformål i allmennhetens interesse

**Arkivverdige dokumenter (Arkivlova):**
- Skal bevares permanent
- Overføres til Arkivverket etter avsluttet sak

**AI-logger:**
- Vurder nødvendig lagringsperiode basert på risikonivå
- Typisk 1-5 år for audit trail
- Sikker sletting etter utløp

### 10.4 Microsoft 365-arkivering

**Exchange Online Archiving:**
- Automatisk arkivering av e-post
- Retention policies (hvor lenge beholdes)
- eDiscovery for søk i arkiv

**SharePoint / OneDrive:**
- Retention labels for dokumenter
- Records management (erklæring av arkivverdig innhold)
- Compliance Center for policy-håndtering

**Microsoft Purview:**
- Data Lifecycle Management (DLM)
- Automatisk klassifisering av innhold
- Policy-basert sletting

**Export til Noark-system:**
- Microsoft 365 er ikke Noark-godkjent
- Integrering med Noark-systemer via API (f.eks. Public 360, Elements)
- Regelmessig eksport av arkivverdige dokumenter

## Referanser og ressurser

### Norske myndigheter

- **Digitaliseringsdirektoratet (Digdir):** https://www.digdir.no/kunstig-intelligens
  - Veiledning for ansvarlig bruk av AI i offentlig sektor
  - Sist oppdatert desember 2024
- **Datatilsynet:** https://www.datatilsynet.no
  - GDPR-veiledning, maler for DPIA
- **Nasjonal sikkerhetsmyndighet (NSM):** https://nsm.no
  - Grunnprinsipper for IKT-sikkerhet 2.0
  - FAQ om sky og tjenesteutsetting
- **Nasjonal kommunikasjonsmyndighet (Nkom):** https://www.nkom.no
  - Framtidig tilsynsmyndighet for AI Act (fra 2026)

### Microsoft-ressurser

- **Microsoft Trust Center:** https://www.microsoft.com/en-us/trust-center
  - Compliance-oversikt, sertifiseringer, privacy
- **Service Trust Portal:** https://servicetrust.microsoft.com
  - Audit reports, compliance guides, risk assessments
- **Azure Compliance Documentation:** https://learn.microsoft.com/en-us/azure/compliance/
- **Microsoft Responsible AI:** https://www.microsoft.com/en-us/ai/responsible-ai
- **EU Data Boundary:** https://www.microsoft.com/en-us/trust-center/privacy/european-data-boundary-eudb
- **Microsoft DPA:** https://aka.ms/dpa

### EU-regelverk

- **GDPR:** https://gdpr.eu
- **AI Act:** https://artificialintelligenceact.eu
- **EU Cloud Code of Conduct:** https://eucoc.cloud
- **European Data Protection Board (EDPB):** https://edpb.europa.eu

### Standarder

- **ISO/IEC 27001:** Informasjonssikkerhetsledelse
- **ISO/IEC 27701:** Privacy Information Management
- **ISO/IEC 42001:** AI Management System (ny standard 2023)
- **NIST AI Risk Management Framework:** https://www.nist.gov/itl/ai-risk-management-framework

---

## Oppsummering: Kritiske sjekkpunkter før go-live

Før du setter et Microsoft AI-system i produksjon i norsk offentlig sektor:

✅ **Juridisk:**
- [ ] DPIA godkjent av personvernombud
- [ ] ROS-analyse godkjent av ledelsen
- [ ] Microsoft DPA signert
- [ ] AI Act-klassifisering dokumentert

✅ **Teknisk:**
- [ ] Data residency konfigurert (Norge/EU)
- [ ] Tilgangskontroll implementert (MFA, RBAC)
- [ ] Logging aktivert og testet
- [ ] Backup og disaster recovery planlagt

✅ **Responsible AI:**
- [ ] Bias-testing gjennomført
- [ ] Transparens sikret (brukere informeres om AI)
- [ ] Human-in-the-loop implementert for kritiske beslutninger
- [ ] Klageprosedyre etablert

✅ **Compliance:**
- [ ] Relevante sertifiseringer verifisert (ISO 27001, SOC 2, etc.)
- [ ] Anskaffelsesprosess gjennomført korrekt
- [ ] Arkiveringsprosedyre etablert
- [ ] Incident response-plan klar

✅ **Organisatorisk:**
- [ ] Ansvarlig for AI-system utnevnt
- [ ] Brukere opplært
- [ ] Dokumentasjon tilgjengelig
- [ ] Support-avtale på plass

---

**Sist oppdatert:** 2026-02-03
**Versjon:** 1.0
**Neste revidering:** 2026-08 (etter AI Act ikrafttredelse)