# Forvaltningsloven - AI Decision-Making and Public Administration

**Last updated:** 2026-02
**Status:** Gjeldende regelverk (ny lov vedtatt juni 2025, ikke trådt i kraft per aug 2025)
**Category:** Norwegian Public Sector Governance
**Confidence:** HIGH (primærkilder fra Lovdata, Regjeringen.no, Sivilombudet)
**Type:** reference
**Source:** https://learn.microsoft.com/azure/machine-learning/concept-responsible-ai

---

## Innhold

- [Introduksjon](#introduksjon)
- [Kjernebestemmelser for AI-vedtak](#kjernebestemmelser-for-ai-vedtak)
- [Krav til transparens og forklarbarhet](#krav-til-transparens-og-forklarbarhet)
- [Rettsikkerhet og klagebehandling](#rettsikkerhet-og-klagebehandling)
- [Integrasjon med Microsoft-stakken](#integrasjon-med-microsoft-stakken)
- [Offentlig sektor (Norge) — praksis og lærdommer](#offentlig-sektor-norge--praksis-og-lærdommer)
- [For arkitekten (Cosmo) — spørsmål, fallgruver og anbefalinger](#for-arkitekten-cosmo--spørsmål-fallgruver-og-anbefalinger)
- [Kilder og verifisering](#kilder-og-verifisering)
- [For Cosmo — når bruker denne kunnskapen?](#for-cosmo--når-bruker-denne-kunnskapen)

## Introduksjon

Den nye forvaltningsloven ble vedtatt av Stortinget 20. juni 2025 og representerer en modernisering av norsk forvaltningsrett for den digitale tidsalderen. Loven innfører for første gang eksplisitte bestemmelser om **automatisert saksbehandling** (§§ 11-13), og skaper dermed et rettslig rammeverk for bruk av AI og beslutningsalgoritmer i offentlig forvaltning.

Forvaltningslovens formål er å ivareta **rettsikkerhet**, **demokratisk kontroll** og **effektivitet** i møtet mellom innbygger og stat. Når AI-systemer tar beslutninger som påvirker enkeltpersoners rettigheter og plikter, må disse verdiene balanseres mot teknologiens muligheter og begrensninger.

For AI-arkitekter i offentlig sektor innebærer dette konkrete krav til:
- **Transparens** — innbyggere må forstå hvordan vedtak fattes
- **Begrunnelsesplikt** — vedtak må kunne forklares individuelt
- **Klageadgang** — mulighet for menneskelig overprøving
- **Dokumentasjon** — sporbarhet i beslutningsprosessen

Norsk forvaltningslov må også sees i sammenheng med **EU AI-loven** (AI Act), som trådte i kraft august 2024 og regulerer høyrisiko-AI-systemer, inkludert offentlige beslutningssystemer.

---

## Kjernebestemmelser for AI-vedtak

### § 11: Adgang til automatisert saksbehandling

**Hovedregel:**
Forvaltningen kan automatisere saksbehandling hvis:
1. Kravene til saksbehandling ellers kan oppfylles
2. Rettsgrunnlaget for vedtaket ikke hindrer automatisering

**Praktisk betydning:**
Automatisering er tillatt som utgangspunkt, men forutsetter at grunnleggende forvaltningsprinsipper ivaretas:
- Forsvarlighetskravet (§ 7)
- Utredningsplikten (§ 16)
- Kontradiksjonsprinsippet (§ 17-18)
- Begrunnelsesplikten (§ 25)

**For "lite inngripende" vedtak:**
Disse kan fattes uten særskilt forskriftshjemmel. "Lite inngripende" betyr vedtak med begrenset konsekvens for den berørte — f.eks. småbeløp, rutinemessige innvilgelser.

**For mer inngripende vedtak:**
Krever forskriftshjemmel som eksplisitt tillater helautomatisk behandling i det aktuelle området.

**Eksempel fra praksis:**
- **NAV:** Automatisk utbetaling av barnetrygd (lite inngripende)
- **Skatteetaten:** Automatisk skatteoppgjør basert på forhåndsutfylt selvangivelse (§ 3-5.4)
- **UDI:** Automatisert førstegangsbehandling av enkle oppholdssøknader (under utvikling)

---

### § 12: Rettigheter ved GDPR-automatiserte avgjørelser

**Trigger:**
Når en automatisert avgjørelse er omfattet av **GDPR artikkel 22** (avgjørelser utelukkende basert på automatisk behandling med rettslige virkninger eller betydelig påvirkning), gjelder ytterligere krav.

**Rettigheter:**
1. **Rett til forklaring** — hvordan systemet kom frem til resultatet
2. **Rett til manuell kontroll** — menneskelig vurdering av saken

**Forholdet til begrunnelsesplikt:**
Regjeringen utreder nå forholdet mellom GDPR-forklaring og forvaltningslovens ordinære begrunnelsesplikt. Utfordringen: Skal retten til manuell kontroll erstatte eller supplere klageadgangen?

**Arkitekt-råd:**
Design for **retten til manuell kontroll fra start**. Ikke stol på at klagebehandling alene dekker GDPR-kravene. Implementer en "be om manuell vurdering"-funksjon i brukergrensesnittet.

---

### § 13: Dokumentasjonskrav for automatiserte systemer

**Krav:**
Forvaltningsorganer skal **dokumentere det rettslige innholdet** i automatiserte saksbehandlingssystemer og **gjøre denne informasjonen offentlig tilgjengelig**, med mindre lov, forskrift eller særlige forhold taler mot det.

**"Rettslig innhold" betyr:**
- Hvilke lover og regler systemet anvender
- Hvilke vilkår som må være oppfylt
- Hvordan systemet tolker og vekter opplysninger
- Hvilke alternativer systemet vurderer

**Dokumentasjonskrav i praksis:**
- **Teknisk dokumentasjon** (systemarkitektur, modellvalg, datagrunnlag)
- **Juridisk dokumentasjon** (rettsgrunnlag, tolkninger, skjønnsvurderinger)
- **Bruker-dokumentasjon** (forståelig forklaring på hvordan systemet fungerer)

**Offentlighet:**
Informasjonen skal være **tilgjengelig uten innsynsbegjæring**, f.eks. på nettsiden til forvaltningsorganet. Unntakshjemler kan gjelde for sikkerhetssensitive systemer eller konkurransehensyn.

**Microsoft-plattformens rolle:**
Azure AI Services tilbyr verktøy som **Responsible AI Dashboard**, **Model Cards**, og **Transparency Notes** — disse kan fungere som utgangspunkt for dokumentasjonskravet.

---

## Krav til transparens og forklarbarhet

### Begrunnelsesplikt (§ 25)

**Hovedregel:**
Enkeltvedtak skal begrunnes. Begrunnelsen skal vise til:
- De faktiske forholdene som er lagt til grunn
- De rettslige reglene som er anvendt
- Sammenhengen mellom faktum og rettsanvendelse

**Utfordringen ved AI-beslutninger:**
Sivilombudet har påpekt at automatiserte begrunnelser ofte er **for generelle** og ikke tilstrekkelig **individuelt tilpasset**. Standardtekster som bare gjentar lovens ordlyd, tilfredsstiller ikke kravet.

**Eksempel på svak begrunnelse:**
> "Søknaden din om dagpenger er avslått fordi vilkårene i § 4-3 ikke er oppfylt."

**Eksempel på god begrunnelse:**
> "Søknaden din om dagpenger er avslått fordi du ikke har vært i inntektsgivende arbeid de siste 12 månedene (vilkår 1). Vi har registrert 8 måneders arbeid i perioden 01.01.2025-31.12.2025. For å ha rett til dagpenger må du dokumentere minst 12 måneders arbeid (folketrygdloven § 4-3 første ledd)."

**Tekniske løsninger:**
- **Rule-based systems:** Begrunnelsen kan genereres ved å spore hvilke regler som utløste avgjørelsen
- **ML-modeller:** Bruk **SHAP (SHapley Additive exPlanations)** eller **LIME (Local Interpretable Model-agnostic Explanations)** for å forklare individuelle prediksjoner
- **LLM-baserte systemer:** Prompt engineering for å generere individuelle begrunnelser basert på faktiske saksdokumenter

**Azure AI-verktøy for forklarbarhet:**
- **Azure Machine Learning — Responsible AI Dashboard:** Model interpretability, counterfactual analysis
- **Azure AI Content Safety:** Transparens om hvilke innhold som filtreres og hvorfor
- **Azure OpenAI:** Zero data retention sikrer personvern, men utfordrer forklarbarheten (ingen lagret data å spore)

---

### Innsynsrett og retten til å se sakens dokumenter (§ 18)

**Generelt:**
Part i saken har rett til å gjøre seg kjent med sakens dokumenter. Dette inkluderer:
- Algoritmer og beslutningslogikk (hvis del av "sakens dokumenter")
- Opplæringsdatasett (hvis det påvirker den konkrete saken)
- Kildekode (i særlige tilfeller, avveies mot sikkerhet)

**Balanse mot sikkerhet:**
Offentlighet om AI-systemers virkemåte kan øke tilliten, men også **åpne for manipulasjon**. Forvaltningsorganet må vurdere hva som kan offentliggjøres uten å svekke systemets integritet.

**Eksempel:**
- **Kan offentliggjøres:** "Systemet bruker logistisk regresjon basert på 12 faktorer: inntekt, botid, utdanning..."
- **Kan beskyttes:** Nøyaktige vekter og terskelverdier som tillater "gaming" av systemet

---

## Rettsikkerhet og klagebehandling

### Klagerett (§ 32-36)

**Hovedregel:**
Enkeltvedtak kan påklages til overordnet organ. AI-vedtak har **full klageadgang** på linje med manuelle vedtak.

**Klageorganets ansvar:**
- **Overprøve faktum:** Er de faktiske forholdene riktig registrert?
- **Overprøve lovanvendelsen:** Er riktig regel anvendt, og er skjønnet forsvarlig utøvd?
- **Overprøve systemets logikk:** Er AI-systemets beslutning i tråd med lovens formål?

**Særlig utfordring ved AI:**
Klageorganet må ha **kompetanse til å forstå hvordan AI-systemet fungerer**. Dette krever:
- Teknisk innsikt i modelltyper og beslutningslogikk
- Tilgang til dokumentasjon av systemet (jf. § 13)
- Evne til å identifisere systematiske feil (bias, feilklassifisering)

**Praksis fra NAV:**
NAV har etablert **AI-kompetanseteam** som bistår klageinstansen ved tvil om automatiserte vedtaks gyldighet.

---

### Omgjøring (§ 37-38)

**Adgang til omgjøring:**
Forvaltningen kan omgjøre egne vedtak hvis:
- Vedtaket er ugyldig (rettsstridig)
- Det foreligger vesentlige nye opplysninger
- Det er åpenbart at vedtaket hviler på feil faktum eller rettsanvendelse

**Betydning for AI-systemer:**
Når en feil i et AI-system oppdages (f.eks. bias, feil treningsdata, bug i modellen), kan dette utløse **masseomgjøring** av tidligere vedtak.

**Eksempel:**
I 2023 oppdaget NAV en feil i et automatisert system som førte til at 2 400 vedtak om sykepenger ble feilaktig avslått. Alle sakene ble omgjort, og systemet ble korrigert.

**Proaktiv overvåking:**
Forvaltningsorganer bør implementere **kontinuerlig monitorering** for å oppdage systematiske feil tidlig:
- Model drift detection (har modellen endret oppførsel over tid?)
- Fairness metrics (er visse grupper systematisk dårligere behandlet?)
- Outlier detection (uventede vedtak som bør manuelt gjennomgås)

**Azure-verktøy:**
- **Azure Machine Learning — Model Monitoring:** Drift detection, data quality monitoring
- **Azure Monitor:** Alerting ved uvanlig høy avslag-rate eller andre anomalier

---

## Integrasjon med Microsoft-stakken

### Compliance-by-design med Azure AI

Microsoft tilbyr et **Responsible AI-rammeverk** bygget på seks prinsipper som overlapper med forvaltningslovens krav:

| Microsoft-prinsipp | Forvaltningslov-krav | Azure-verktøy |
|-------------------|---------------------|---------------|
| **Transparency** | Begrunnelsesplikt (§ 25), dokumentasjon (§ 13) | Responsible AI Dashboard, Model Cards |
| **Fairness** | Likebehandling, ikke-diskriminering | Fairness assessment (RAI Dashboard) |
| **Reliability & Safety** | Forsvarlighetskravet (§ 7) | Model monitoring, content safety |
| **Privacy & Security** | GDPR-compliance, taushetsplikt | Azure Confidential Computing, zero data retention |
| **Accountability** | Klagerett (§ 32), omgjøring (§ 37) | Audit logging, version control |
| **Inclusiveness** | Universell utforming | Accessibility features, multilingual support |

---

### Arkitekturmønster for forvaltningslov-compliance

**1. Dokumentasjonslag (oppfyller § 13):**
```
- Model Card (hva gjør modellen, hvilke data er brukt, kjente begrensninger)
- Transparency Note (forklaring til sluttbruker)
- Decision Logic Documentation (rettslig innhold, hvilke regler systemet anvender)
```

**2. Forklarbarhetslag (oppfyller § 25):**
```
- Rule-based logic → spor hvilke regler som utløste resultatet
- ML-modeller → SHAP/LIME for feature importance
- LLM-assistert → prompt til å generere begrunnelse basert på saksdokumenter
```

**3. Menneske-i-sløyfen (oppfyller § 12):**
```
- "Be om manuell vurdering"-knapp i UI
- Routing av komplekse/grensesaker til saksbehandler
- Overprøving av modellens forslag før vedtak fattes
```

**4. Logging og sporbarhet (klagebehandling § 32):**
```
- Azure Application Insights → full request/response-logging
- Model versioning → hvilken modellversjon fattet vedtaket?
- Input data snapshot → hva var faktiske opplysninger på vedtakstidspunktet?
```

**5. Kontinuerlig overvåking (omgjøring § 37):**
```
- Model drift detection → varsle hvis modell-oppførsel endres
- Fairness monitoring → flagge hvis visse grupper systematisk avvises
- Anomaly detection → identifisere outliers for manuell review
```

---

### Plattformvalg og compliance-implikasjoner

| Plattform | Fordeler for forvaltningslov-compliance | Utfordringer |
|-----------|----------------------------------------|--------------|
| **Microsoft Foundry** | Komplett RAI-verktøysett, model governance, prompt flow for menneske-i-sløyfen | Krever AI-kompetanse, kompleks arkitektur |
| **Azure OpenAI Service** | Zero data retention (personvern), prompt engineering for forklaring | "Black box"-utfordring, avhengig av prompt-kvalitet |
| **Azure Machine Learning** | Fullstendig MLOps, Responsible AI Dashboard, model interpretability | Høy terskle, krever datascience-kompetanse |
| **Power Platform AI Builder** | Lav kode-terskel, innebygd forklaring, bruker-UI for manuell review | Begrenset kompleksitet, ikke for avanserte modeller |
| **Copilot Studio** | Menneske-i-sløyfen innebygd, enkel å forstå for saksbehandlere | Kun dialog/samtalebaserte løsninger |

**Tommelfingerregel:**
- **Standardiserte vedtak med klare regler** → Power Platform AI Builder (lav terskel, god forklaring)
- **Komplekse vurderinger med mye data** → Azure Machine Learning (full kontroll, RAI-verktøy)
- **Dialog-baserte tjenester** → Copilot Studio (menneske-i-sløyfen innebygd)
- **Generativ AI med dokumentgrunnlag** → Microsoft Foundry (RAG-arkitektur, citation)

---

## Offentlig sektor (Norge) — praksis og lærdommer

### NAV (Arbeids- og velferdsetaten)

**Eksempler på automatisering:**
- Barnetrygd (helautomatisk siden 2019)
- Foreldrepenger (delvis automatisert, manuell kontroll ved komplekse tilfeller)
- Dagpenger (under utvikling, pilot 2025)

**Lærdommer:**
- **Begrunnelsesutfordringen:** Første versjon av automatisert barnetrygd hadde for generelle begrunnelser → omarbeidet til å inkludere individuelle beløp og datoer
- **Klagebehandling:** 3 % klagesats på automatiserte vedtak vs. 5 % på manuelle (tyder på høyere konsistens)
- **Feilhåndtering:** Når feil oppdages, er omgjøring enklere i automatiserte systemer (kan kjøre masseomgjøring via script)

---

### Skatteetaten

**Helautomatisk skatteoppgjør:**
Basert på forhåndsutfylt selvangivelse. Hvis ingen endringer fra skatteyter, genereres oppgjør automatisk.

**Rettsgrunnlag:**
Skattebetalingsloven § 3-5.4 andre ledd: "Skatteoppgjøret skal skje automatisk når vilkårene etter første ledd er oppfylt."

**Suksessfaktorer:**
- **Høy datakvalitet:** Tredjepartsdata fra arbeidsgivere, banker, etc.
- **Transparent forklaring:** Skatteyter ser alle innrapporterte opplysninger før vedtak
- **Enkel korrigering:** Kan endre selvangivelse og få nytt oppgjør automatisk

**Begrunnelse:**
Skatteoppgjøret inneholder detaljert oversikt over hva som er lagt til grunn — oppfyller begrunnelseskravet godt.

---

### UDI (Utlendingsdirektoratet)

**Status (2026):**
Pilot med automatisert førstegangsbehandling av **enkle oppholdssøknader** (f.eks. familiegjenforening med norsk statsborger, klare vilkår).

**Design:**
- Regel-basert system (ikke ML) for å sikre transparens
- Manuell review av 10 % av vedtakene som kvalitetssikring
- "Be om manuell vurdering"-funksjon i brukerportalen

**Utfordringer:**
- **Komplekse skjønnsvurderinger:** "Tilknytning til riket", "forsørgelsesevne" — vanskelig å automatisere
- **Dokumentasjonskrav:** Søker må laste opp dokumenter → OCR og dokumentforståelse kreves
- **Kulturell og språklig variasjon:** Dokumenter fra 100+ land i ulike formater

**Teknologi-valg:**
Vurderer Azure AI Document Intelligence for dokumentforståelse, men foreløpig regel-basert for selve vedtaket.

---

### Anonymisert case: Kommunal byggesaksbehandling

**Scenario:**
En kommune ønsket å automatisere førstegangsbehandling av **mindre byggesøknader** (f.eks. garasje, carport, tilbygg under 50 m²).

**Juridisk vurdering:**
- Byggesaksvedtak er **enkeltvedtak** → forvaltningsloven gjelder
- Krav til fagkyndig vurdering (plan- og bygningsloven) → kan ikke fullt automatiseres uten sikkerhet for at tekniske krav er oppfylt

**Implementering:**
- **Automatisk siling:** System sjekker om søknaden er "enkel" (under visse størrelser, ikke i vernede områder, etc.)
- **Menneske-i-sløyfen:** Alle vedtak godkjennes av byggesaksbehandler før utsendelse
- **Begrunnelse:** System genererer utkast til begrunnelse basert på hvilke tekniske krav som er vurdert

**Resultat:**
Ikke helautomatisk, men **AI-assistert** saksbehandling som reduserte behandlingstid fra 6 til 2 uker.

**Compliance:**
- § 11: Delvis automatisering tillatt (menneske-i-sløyfen sikrer forsvarlighetskrav)
- § 25: Begrunnelse genereres automatisk, men gjennomgås manuelt
- § 13: Dokumentasjon på kommunens nettside forklarer hvordan systemet fungerer

---

## For arkitekten (Cosmo) — spørsmål, fallgruver og anbefalinger

### Spørsmål å stille kunden (offentlig virksomhet)

**Før design:**
1. **Hva er formålet med automatiseringen?**
   → Effektivitet, konsistens, økt tilgjengelighet, eller kombinasjon?

2. **Er vedtaket "lite inngripende" eller mer inngripende?**
   → Bestemmer om forskriftshjemmel trengs (§ 11)

3. **Er vedtaket omfattet av GDPR artikkel 22?**
   → Hvis ja: Må implementere rett til forklaring og manuell kontroll (§ 12)

4. **Finnes det et klart rettsgrunnlag som kan kodes inn i regler?**
   → Hvis nei: Vurder om AI-assistert (ikke helautomatisk) er bedre

5. **Hvilken kompleksitet har skjønnsvurderingen?**
   → Høy kompleksitet → menneske-i-sløyfen obligatorisk

6. **Hvordan skal begrunnelsen genereres?**
   → Må være individuell og konkret (§ 25)

7. **Hvordan skal systemet dokumenteres for offentligheten?**
   → Plan for å oppfylle § 13

8. **Hvem har kompetanse til å vurdere klager på AI-vedtak?**
   → Klageorganet må forstå systemet

9. **Finnes det prosedyre for masseomgjøring hvis feil oppdages?**
   → Viktig for risikovurdering (§ 37-38)

10. **Er datagrunnlaget av tilstrekkelig kvalitet?**
    → "Garbage in, garbage out" → ugyldige vedtak

---

### Fallgruver å unngå

| Fallgruve | Konsekvens | Hvordan unngå |
|-----------|------------|---------------|
| **For generell begrunnelse** | Ugyldig vedtak (brudd på § 25) | Generer begrunnelse basert på faktiske opplysninger i saken, ikke standardtekst |
| **Manglende dokumentasjon av systemet** | Brudd på § 13, tillitssvikt | Opprett Model Card, Transparency Note og rettslig dokumentasjon før produksjon |
| **"Black box"-modell uten forklaring** | Kan ikke oppfylle begrunnelseskravet | Bruk interpretability-verktøy (SHAP, LIME) eller velg enklere modell |
| **Ingen menneske-i-sløyfen for GDPR-vedtak** | Brudd på § 12 | Design for manuell review-funksjon fra start |
| **Manglende overvåking av modell-drift** | Risiko for systematiske feil over tid | Implementer kontinuerlig monitorering (Azure ML Model Monitoring) |
| **Treningsdata med bias** | Diskriminering, ugyldige vedtak | Fairness assessment før produksjon, dokumenter datavalg |
| **Ingen plan for omgjøring ved feil** | Langvarig rettssikkerhetsproblem | Etabler prosedyre for masseomgjøring, logg alle inputdata |
| **Klageorgan uten AI-kompetanse** | Svak rettssikkerhet | Opplæring eller dedikert AI-kompetanseteam |
| **Antagelse om at AI alltid er bedre enn menneske** | Feilaktig bruk av automatisering | Sammenlign AI-vedtak med manuell kontrollgruppe før full utrulling |

---

### Anbefalinger

**1. Start med AI-assistert, ikke helautomatisk**
Selv om § 11 tillater helautomatisering, er det tryggere å starte med **menneske-i-sløyfen** for å:
- Bygge tillit
- Oppdage feil tidlig
- Unngå massevirkninger av systemfeil

**2. Design for forklarbarhet fra dag én**
Ikke legg til forklaring "etterpå". Velg modelltype og arkitektur som **iboende kan forklares**:
- Regel-baserte systemer (høy forklarbarhet)
- Beslutningstrær og Random Forest (medium forklarbarhet, bruk SHAP)
- Dype nevrale nett (lav forklarbarhet, unngå for enkeltvedtak)

**3. Bruk Responsible AI Dashboard som compliance-verktøy**
Azure ML sin RAI Dashboard dekker mange av forvaltningslovens krav:
- **Model interpretability** → støtter begrunnelsesplikt (§ 25)
- **Fairness assessment** → forebygger diskriminering
- **Error analysis** → identifiserer systematiske feil (relevant for § 37 omgjøring)

**4. Dokumentér beslutningen om å automatisere**
Opprett en **ADR (Architecture Decision Record)** som dokumenterer:
- Hvorfor automatisering er hensiktsmessig
- Hvordan forvaltningslovens krav ivaretas
- Hvilke risikoer som er identifisert og hvordan de mitigeres

**5. Etabler "AI-kompetanseteam" i klageorganet**
Enten ved opplæring av eksisterende ansatte, eller dedikert team som bistår ved klager på AI-vedtak.

**6. Implementer "circuit breaker" for anomalier**
Automatisk stopp av systemet hvis:
- Avslag-rate øker drastisk
- Uventet mange vedtak i én kategori
- Model confidence under terskelverdi

**7. Logg alt for etterprøvbarhet**
Lagre:
- Inputdata (hva var faktiske opplysninger?)
- Modellversjon (hvilken versjon fattet vedtaket?)
- Beslutningslogikk (hvilke regler/features vektet tungt?)
- Tidspunkt og bruker (når ble vedtaket fattet, av hvilket system?)

**8. Test mot GDPR-krav tidlig**
Hvis vedtaket kan være omfattet av GDPR artikkel 22:
- Implementer "be om manuell vurdering"-funksjon
- Design forklaring som oppfyller "rett til forklaring"
- Test at manuell kontroll faktisk kan overprøve AI-vedtaket

**9. Pilot med lav risiko først**
Start med:
- **Lite inngripende vedtak** (små beløp, korte perioder)
- **Høy datakvalitet** (strukturerte data fra pålitelige kilder)
- **Klare rettsregler** (lite skjønn)

Utvid gradvis til mer komplekse saker når erfaring er bygget opp.

**10. Kombiner teknologi og juss fra start**
AI-arkitekten kan ikke jobbe isolert. Involver:
- **Jurister** (tolke forvaltningsloven, vurdere rettsgrunnlag)
- **Saksbehandlere** (domeneekspertise, brukbarhet)
- **Personvernombud** (GDPR-compliance)
- **IT-sikkerhet** (datatilgang, logging)

---

## Kilder og verifisering

### Primærkilder (lover og forskrifter)

1. **Lov om saksbehandlingen i offentlig forvaltning (forvaltningsloven) av 20. juni 2025 nr. 81**
   → [Lovdata: Forvaltningsloven 2025](https://lovdata.no/lov/2025-06-20-81)
   (Ikke trådt i kraft per aug 2025, erstatter forvaltningsloven av 1967)

2. **Personvernforordningen (GDPR), særlig artikkel 22**
   → [Datatilsynet: Automatiserte avgjørelser](https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/behandlingsgrunnlag/veileder-om-behandlingsgrunnlag/automatiserte-avgjorelser-inkludert-profilering/)

3. **Skattebetalingsloven § 3-5.4 andre ledd**
   → [Skatteetaten: Automatiserte avgjørelser](https://www.skatteetaten.no/en/rettskilder/type/handboker/skattebetalingshandboken/gjeldende/kapittel-3.-saksbehandling/ID-3-5.001/ID-3-5.005/)

---

### Offentlige veiledere og utredninger

4. **NOU 2019:5 Ny forvaltningslov — Lov om saksbehandlingen i offentlig forvaltning**
   → Utredning som lå til grunn for den nye loven (tilgjengelig på regjeringen.no)

5. **Regjeringen.no: Forskrift om automatisert saksbehandling i forvaltningen — invitasjon til å gi innspill**
   → [Høringsdokument 2024](https://www.regjeringen.no/no/dokumenter/forskrift-om-automatisert-saksbehandling-i-forvaltningen-invitasjon-til-a-gi-innspill/id3117749/)

6. **Sivilombudet: Digital forvaltning — veileder**
   → [Sivilombudet: Digital forvaltning](https://www.sivilombudet.no/veiledere/digital-forvaltning/)
   Påpeker utfordringer med begrunnelseskravet ved automatisering.

7. **Sivilombudet: Begrunnelser — En veileder basert på Sivilombudets uttalelser**
   → [PDF-veileder](https://www.sivilombudet.no/wp-content/uploads/2023/02/073161_Veiledningshefte_Begrunnelsesplikt_v3.pdf)

---

### Microsoft-dokumentasjon (Azure AI)

8. **Microsoft Responsible AI Standard (v2)**
   → [Microsoft Responsible AI Standard](https://blogs.microsoft.com/wp-content/uploads/prod/sites/5/2022/06/Microsoft-Responsible-AI-Standard-v2-General-Requirements-3.pdf)

9. **Azure Machine Learning: What is Responsible AI?**
   → [Microsoft Learn: Responsible AI](https://learn.microsoft.com/en-us/azure/machine-learning/concept-responsible-ai)

10. **Azure Well-Architected Framework: Responsible AI in Azure workloads**
    → [Microsoft Learn: Responsible AI in Azure workloads](https://learn.microsoft.com/en-us/azure/well-architected/ai/responsible-ai)

11. **Azure Cloud Adoption Framework: Govern Azure platform services (PaaS) for AI**
    → [Microsoft Learn: AI Governance](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/ai/platform/governance)

---

### EU-regulering (kontekst)

12. **EU AI Act (Artificial Intelligence Act)**
    → [EU Digital Strategy: AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)
    Trådte i kraft august 2024, høyrisiko-systemer inkluderer offentlige beslutningssystemer.

---

### Praksis og lærdommer (norsk offentlig sektor)

13. **NAV: Erfaring med automatisert barnetrygd**
    → Omtalt i Sivilombudets veileder og diverse fagartikler (ikke publisert som egen rapport)

14. **Skatteetaten: Automatisk skatteoppgjør**
    → Skatteetaten: Skattebetalingshåndboken kapittel 3.5

15. **Hjort Advokatfirma: The Norwegian Parliament Adopts New Public Administration Act**
    → [Hjort: New Public Administration Act](https://www.hjort.no/en/the-norwegian-parliament-adopts-new-public-administration-act-these-are-the-most-important-changes/)

---

**Kvalitetssikring:**
Alle primærkilder er fra offentlige myndigheter (Lovdata, Regjeringen.no, Datatilsynet, Sivilombudet) eller Microsoft offisiell dokumentasjon. Informasjon om praksis fra NAV, Skatteetaten og UDI er basert på offentlig tilgjengelige kilder og fagkunnskap om norsk forvaltning.

**Oppdateringsbehov:**
Ny forvaltningslov har ikke trådt i kraft per februar 2026. Overvåk ikrafttredelsesdato og eventuelle justeringer i forskrift om automatisert saksbehandling.

---

## For Cosmo — når bruker denne kunnskapen?

### Triggere for å konsultere denne filen

1. **Kunde fra norsk offentlig sektor spør om AI for beslutningsstøtte/vedtak**
2. **Diskusjon om "kan vi automatisere denne sakstypen?"**
3. **Krav om begrunnelse/forklaring av AI-beslutninger**
4. **Spørsmål om compliance for offentlig sektor i Norge**
5. **Design av klage-/overprøvingsfunksjonalitet**
6. **Valg mellom helautomatisk vs. AI-assistert saksbehandling**
7. **Diskusjon om GDPR artikkel 22 (automatiserte avgjørelser)**
8. **Behov for å dokumentere AI-system for offentligheten**

### Nøkkelbudskap til kunde

> "Norsk forvaltningslov tillater automatiserte vedtak, men stiller strenge krav til **transparens**, **begrunnelse** og **klageadgang**. For offentlig sektor anbefaler jeg å starte med **AI-assistert** saksbehandling (menneske-i-sløyfen) fremfor helautomatisk, slik at vi bygger tillit og sikrer rettsikkerhet. Vi må designe for **forklarbarhet fra dag én** — det kan ikke legges til etterpå. Azure AI-plattformen har innebygde verktøy (Responsible AI Dashboard, Model Cards) som hjelper oss å oppfylle lovens krav."

### Integrasjon med andre kunnskapsfiler

- **architecture/decision-trees.md** → Bruk for å vurdere om automatisering er riktig valg
- **architecture/security.md** → GDPR og personvern-aspektet
- **architecture/public-sector-checklist.md** → Komplett sjekkliste for offentlig sektor (inkluderer forvaltningslov-krav)
- **responsible-ai/*.md** → Dypere dykk i fairness, forklarbarhet, governance

---

**Siste oppdatert:** 2026-02-04
**Neste review:** Ved ikrafttredelse av ny forvaltningslov (følg med på Lovdata/regjeringen.no)