ms-ai-architect/skills/ms-ai-advisor/references/architecture/public-sector-checklist.md

Public Sector Checklist - Norsk offentlig sektor og Microsoft AI

Last updated: 2026-06-24 (research via microsoft-learn MCP + WebSearch) Målgruppe: Arkitekter som rådgiver norske offentlige virksomheter Category: Solution Architecture & Advisory Status: Established Practice

---

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 2026, men forsinket pga. EØS-tilpasning (trolig noe etter EUs 2. aug 2026)
• 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: - Data residency i Norge/EU - Customer Lockbox aktivert - Auditing og DLP konfigurert - Private endpoints (ingen offentlig internett-eksponering)
Fortrolig	Uautorisert tilgang kan være til alvorlig skade	⚠️ Krever grundig risikovurdering: - Vurder Azure Stack Hub (on-premises) - Eller Azure med dedikerte ressurser og kryptering med kundestyrt nøkkel - 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 ✅ 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 ✅ 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 - Aktivér sensitivity labels - Implementer retention policies
Sensitive personopplysninger (GDPR Art. 9)	Helse, etnisitet, politisk mening, religion, fagforeningsmedlemskap, biometri, genetikk, seksuell orientering	- DPIA obligatorisk - Ekstra sikkerhetstiltak (kryptering, tilgangskontroll) - Vurder om AI-behandling er strengt nødvendig - Dokumenter rettslig grunnlag
Opplysninger om straffedommer (GDPR Art. 10)	Straffehistorikk, lovanvendelse	- Kun lovhjemlet behandling - Ekstra tilgangskontroll - 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: 2026 (forsinket pga. EØS-tilpasning; trolig noe etter EUs 2. aug 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 - Sanntids biometrisk identifikasjon i offentlig rom (med unntak for alvorlig kriminalitet) - Manipulerende AI	❌ Forbudt
Høy risiko	Kan påvirke helse, sikkerhet eller grunnleggende rettigheter betydelig	- AI i offentlig saksbehandling (vedtak) - Rekruttering i offentlig sektor - Kritisk infrastruktur (vann, energi, transport) - Lovhåndhevelse (prediktiv policing)	✅ Strengt regulert: - Risikovurdering og testing - Omfattende dokumentasjon - Human oversight obligatorisk - Registrering i EU-database - Conformity assessment
Begrenset risiko	Noen åpenbaringsplikter	- Chatbots for publikumskontakt - AI-generert innhold (tekst, bilder, video)	⚠️ Transparenskrav: - Informere brukere om AI-bruk - Merking av generert innhold
Minimal risiko	Lite eller ingen regulering	- Spamfilter - 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-06-24 Versjon: 1.0 Neste revidering: 2026-08 (etter AI Act ikrafttredelse)