# Utredningsinstruksen - AI Project Scoping and Methodology

**Last updated:** 2026-05
**Status:** Gjeldende regelverk (Effective regulation)
**Category:** Norwegian Public Sector Governance
**Confidence:** High (offisielle kilder fra regjeringen.no og DFØ)

---

## Introduksjon

Utredningsinstruksen er et sentralt styringsinstrument i norsk statsforvaltning som stiller minimumskrav til utredning av alle statlige tiltak. Instruksen ble fastsatt ved kongelig resolusjon 19. februar 2016 og trådte i kraft 1. mars 2016.

**Formål:** Legge et godt grunnlag for beslutninger om statlige tiltak gjennom systematisk analyse av problemer, alternativer, effekter og kostnader.

**Virkeområde:** Gjelder utarbeidelse av beslutningsgrunnlag for statlige tiltak som gjennomføres i eller på vegne av statlige forvaltningsorganer (departementer og underliggende virksomheter).

**Relevans for AI-prosjekter:** AI-systemer som skal implementeres i offentlig sektor faller inn under instruksen dersom de har eksterne effekter (påvirker innbyggere, næringsliv eller andre offentlige aktører). Små interne IT-endringer som kun påvirker egen organisasjon er unntatt.

### Historikk og kontekst

Utredningsinstruksen har røtter tilbake til 1990-tallet, men dagens versjon er en modernisering som legger vekt på:
- Proporsjonalitet (utredning tilpasset tiltakets betydning)
- Involvering av berørte parter tidlig i prosessen
- Samfunnsøkonomisk analyse ved betydelige økonomiske konsekvenser
- Kvalitetssikring av store investeringsprosjekter

**DFØs rolle:** Direktoratet for forvaltning og økonomistyring (DFØ) forvalter instruksen og tilbyr kompetansetjenester til departementer og underliggende etater. DFØ har utviklet en omfattende veileder som utdyper kravene.

---

## De seks spørsmålene anvendt på AI

Minimumskravet er at alle utredninger skal besvare følgende **seks spørsmål**:

### 1. Hva er problemet, og hva vil vi oppnå?

**Standard krav:**
Beskriv problemet tiltaket skal løse, og hvilke mål som skal nås.

**AI-kontekst:**
- Hvilket beslutnings- eller prosessområde skal AI støtte?
- Er problemet egnet for AI-løsning (tilstrekkelig data, klart definert)?
- Hva er dagens situasjon (baseline) uten AI?
- Hvilke målbare forbedringer forventes (effektivitet, kvalitet, tilgjengelighet)?
- Er AI nødvendig, eller finnes enklere løsninger?

**Eksempel:**
"Saksbehandlingstid i NAV for førstegangssøknader er 45 dager. Mål: Redusere til 20 dager ved AI-assistert dokumentklassifisering og informasjonsutvinning."

**Cosmo-spørsmål:**
- Er problemformuleringen spesifikk nok til å evaluere AI-løsninger?
- Finnes baseline-data som kan måle effekt?

---

### 2. Hvilke tiltak er aktuelle, og hva er konsekvensene av disse?

**Standard krav:**
Beskriv alternative tiltak (inkludert nullalternativet) og deres konsekvenser.

**AI-kontekst:**
- **Nullalternativet:** Fortsette uten AI (ofte obligatorisk referansepunkt)
- **Alternativ 1:** Eksisterende IT-løsning med forbedringer (ikke AI)
- **Alternativ 2:** Regel-basert automatisering
- **Alternativ 3:** Maskinlæring (klassisk ML)
- **Alternativ 4:** Generativ AI (LLM-basert)
- **Alternativ 5:** Hybrid (menneske + AI)

For hvert alternativ må du vurdere:
- **Teknisk gjennomførbarhet** (modenhetsgrad, kompetansekrav)
- **Kostnader** (lisensiering, infrastruktur, kompetanse, drift)
- **Risikoer** (nøyaktighet, bias, personvern, sikkerhet)
- **Compliance** (GDPR, AI Act, sektorregler)
- **Implementeringstid**
- **Reversibilitet** (kan vi gå tilbake hvis det ikke fungerer?)

**Cosmo-anbefaling:**
Start alltid med minst tre alternativer (null + to AI-løsninger). Vurder hybridløsninger der AI assisterer, men mennesker tar endelige beslutninger.

---

### 3. Hvilket tiltak anbefales, og hvorfor?

**Standard krav:**
Angi hvilket tiltak som anbefales og begrunn valget.

**AI-kontekst:**
Begrunnelsen må dekke:
- **Teknisk egnethet** for oppgaven
- **Kostnad-nytte-vurdering** (samfunnsøkonomisk lønnsomhet)
- **Risikohåndtering** (hvordan håndteres bias, feil, sikkerhet?)
- **Compliance** (oppfyller AI Act, GDPR, sektorspesifikke krav?)
- **Kompetanse** (har vi nødvendig spisskompetanse internt/eksternt?)
- **Leverandørlandskap** (modne produkter tilgjengelig?)
- **Exit-strategi** (hva hvis løsningen ikke fungerer?)

**Kriterier for valg:**
1. **Nødvendighet:** Er AI nødvendig for å nå målet?
2. **Proporsjonalitet:** Står kostnader/risikoer i forhold til gevinst?
3. **Subsidiaritet:** Er dette riktig nivå å løse på (nasjonalt vs. lokalt)?

**Eksempel på begrunnelse:**
"Vi anbefaler Azure AI Document Intelligence (alternativ 4) fordi:
- Reduserer saksbehandlingstid med 55% (målt i POC)
- Norsk språkstøtte er tilstrekkelig (92% nøyaktighet)
- GDPR-compliant (data i EU)
- TCO lavere enn egenutviklet ML-løsning
- Reversibelt (kan falle tilbake til manuell prosess)"

---

### 4. Hva er de viktigste virkningene av tiltaket?

**Standard krav:**
Beskriv positive og negative virkninger, varighet og hvem som påvirkes.

**AI-kontekst - Virkninger å vurdere:**

**A. Brukere/innbyggere:**
- Bedre service (raskere, mer tilgjengelig)?
- Forståelighet (kan beslutninger forklares?)
- Tillit (aksepterer brukerne AI-beslutninger?)
- Diskriminering (risiko for bias mot grupper?)

**B. Ansatte:**
- Endret arbeidshverdag (frigjøring fra rutineoppgaver vs. tap av kompetanse)
- Kompetansebehov (opplæring, ny type roller)
- Jobbtrygghet (erstatning vs. augmentering)

**C. Organisasjon:**
- Effektivitet (tid, kostnad)
- Kvalitet (færre feil, bedre konsistens)
- Kompetanseavhengighet (ny kritisk kompetanse)
- Vendor lock-in (avhengighet av leverandør)

**D. Samfunn:**
- Økonomisk nytte (verdiskaping, ressursbruk)
- Demokratiske verdier (rettssikkerhet, innsyn, kontroll)
- Miljø (energiforbruk til trening/inferens)

**E. Sikkerhet og personvern:**
- Databehandling (hvilke data, hvor lagres de, hvor lenge?)
- Sårbarheter (prompt injection, data poisoning, adversarial attacks)
- Avhengighet (hva skjer ved systemsvikt?)

**Varighet:** Er effektene midlertidige (pilotfase) eller permanente? Når inntrer gevinster?

**Cosmo-spørsmål:**
- Har dere vurdert ikke-intenderte konsekvenser (f.eks. brukere som tilpasser atferd for å "lure" AI)?
- Hvordan måles faktisk virkning post-implementering?

---

### 5. Hvem har blitt involvert, og hvordan?

**Standard krav:**
Beskriv involvering av berørte parter.

**AI-kontekst - Involvering må inkludere:**

**A. Interne stakeholders:**
- **Sluttbrukere** (de som skal bruke AI-systemet daglig)
- **IT/sikkerhet** (infrastruktur, drift, sikkerhet)
- **Juridisk** (compliance, personvern, kontrakter)
- **Tillitsvalgte** (fagforeninger ved endring i arbeidsprosesser)
- **Ledelse** (strategisk forankring, ressurser)

**B. Eksterne stakeholders:**
- **Brukere/innbyggere** (hvis AI påvirker tjenester de mottar)
- **Datatilsynet** (ved behandling av personopplysninger)
- **Leverandører** (teknisk feasibility, SLA, support)
- **Fagmiljøer** (forskning, bransjenettverk)

**C. Metodikk:**
- **Workshops** (behovsavklaring, konsepttesting)
- **Pilotbrukere** (testing i kontrollert miljø)
- **Høring** (offentlig konsultasjon ved omfattende tiltak)
- **Referansegrupper** (kontinuerlig input under utvikling)

**Timing:** Involvering skal skje **tidlig** (før løsningsvalg) og **kontinuerlig** (under utvikling og testing).

**Dokumentasjon:** Loggfør hvem som er involvert, når, og hvordan tilbakemeldinger påvirket beslutninger.

**Cosmo-anbefaling:**
Involver alltid sluttbrukere i POC-fase. "AI-optimisme" hos ledelse må balanseres med realisme fra de som skal bruke systemet daglig.

---

### 6. Hva er forutsetningene for å gjennomføre tiltaket?

**Standard krav:**
Beskriv ressurser, kompetanse, organisering og andre forutsetninger.

**AI-kontekst - Kritiske forutsetninger:**

**A. Kompetanse:**
- **Teknisk:** AI/ML-ingeniører, prompt engineers, data scientists
- **Domene:** Fageksperter som kan evaluere AI-output
- **Jus/compliance:** Personvern, AI-regulering
- **Prosess:** Change management, opplæring

**B. Data:**
- **Tilgjengelighet:** Finnes nødvendige data?
- **Kvalitet:** Er data strukturert, merket, oppdatert?
- **Juridisk grunnlag:** Har vi rett til å bruke data til AI-trening?
- **Representativitet:** Dekker data alle relevante grupper (unngå bias)?

**C. Infrastruktur:**
- **Compute:** On-premises GPU vs. Azure cloud
- **Lagring:** Sikker lagring av treningsdata og modeller
- **Nettverk:** Latens, båndbredde (spesielt for sanntidsinferens)

**D. Organisasjon:**
- **Styringsmodell:** Hvem eier AI-systemet? Hvem tar beslutninger om modellendringer?
- **Ansvarsfordeling:** Klare roller (RACI)
- **Budsjett:** Kapital (initial investering) og drift (løpende kostnader)

**E. Juridisk/regulatorisk:**
- **AI Act compliance** (fra 2026 via EØS)
- **GDPR** (databehandleravtaler, DPIA)
- **Sektorspesifikke krav** (f.eks. Helsepersonelloven)
- **Kontrakter** (SLA med leverandør, exit-klausuler)

**F. Risikohåndtering:**
- **Contingency plan:** Hva gjør vi hvis AI ikke fungerer som forventet?
- **Fallback:** Kan vi fortsette manuelt hvis AI feiler?
- **Monitorering:** Hvordan overvåkes modellens ytelse over tid?

**Cosmo-checkpoint:**
- Sjekk om alle forutsetninger er **realistiske** (ikke optimistiske antakelser)
- Identifiser **kritiske avhengigheter** (hva kan stoppe prosjektet?)

---

## Krav til utredning av AI-tiltak

### Når kreves utredning?

**Alltid når:**
- AI-systemet påvirker innbyggere, næringsliv eller andre offentlige aktører
- Tiltaket har betydelige økonomiske konsekvenser (over terskelverdier)
- Tiltaket reiser prinspielle spørsmål (f.eks. automatiserte beslutninger i sårbare områder)

**Unntatt:**
- Små interne IT-endringer uten eksterne effekter
- Piloter/POC hvis de ikke tas i bruk permanent (men POC-resultater må utredes før produksjonssetting)

### Spesifikke krav for AI-systemer

**1. Risikoklassifisering (AI Act):**

Fra 2026 vil EU AI Act gjelde i Norge via EØS-avtalen. AI-systemer klassifiseres i:
- **Uakseptabel risiko:** Forbudt (f.eks. sosial scoring)
- **Høy risiko:** Strenge krav (f.eks. rekruttering, helsetjenester, offentlige tjenester)
- **Begrenset risiko:** Transparenskrav (informer brukere om AI-bruk)
- **Minimal risiko:** Ingen spesielle krav

Utredning må identifisere risikoklasse og dokumentere overholdelse av krav.

**2. Personvernkonsekvensvurdering (DPIA):**

Hvis AI behandler personopplysninger og har "høy risiko" for personvern, kreves DPIA (GDPR Art. 35). Dette gjelder ofte:
- Automatisert beslutningstaking
- Profilering
- Storskalabehandling av sensitive data

DPIA må gjennomføres **før** implementering.

**3. Samfunnsøkonomisk analyse:**

Ved betydelige økonomiske konsekvenser kreves samfunnsøkonomisk analyse (jf. DFØs veileder i samfunnsøkonomiske analyser). Dette inkluderer:
- **Nytteverdi:** Kvantifisering av gevinster (tidssparing, kvalitetsforbedring)
- **Kostnader:** Totaløkonomisk eierskap (TCO) over systemets levetid
- **Kalkulasjonsrente:** Nåverdiberegning av fremtidige kostnader/gevinster
- **Sensitivitetsanalyse:** Hvordan påvirkes lønnsomheten av endrede forutsetninger?

**4. Kvalitetssikring (KS-ordningen):**

Store statlige investeringsprosjekter (over 750 mill. NOK) må kvalitetssikres eksternt i to faser:
- **KS1:** Før valg av konsept
- **KS2:** Før budsjettfastsettelse

For AI-prosjekter vil dette typisk gjelde store infrastrukturprosjekter eller omfattende tjenesteplattformer.

---

## Metodikk og gjennomføring

### Trinn-for-trinn veiledning for AI-utredning

**Fase 1: Forberedelse (1-2 uker)**

1. **Etabler prosjektorganisasjon:**
   - Prosjektleder (ansvar for utredning)
   - Arbeidsgruppe (tverrfaglig: IT, domene, jus, økonomi)
   - Styringsgruppe (beslutningsmandat)

2. **Avklar mandat:**
   - Hva skal utredes? (scope)
   - Tidsfrist for beslutning
   - Budsjett for utredningsarbeid

3. **Identifiser stakeholders:**
   - Hvem påvirkes?
   - Hvem har kunnskap vi trenger?

**Fase 2: Problemanalyse (2-4 uker)**

4. **Beskriv nåsituasjon:**
   - Dagens prosess/tjeneste
   - Målinger (baseline-data)
   - Utfordringer og ineffektivitet

5. **Definer mål:**
   - SMART-mål (Specific, Measurable, Achievable, Relevant, Time-bound)
   - Suksesskriterier (hva er "god nok" løsning?)

6. **Valider at AI er relevant:**
   - Finnes tilstrekkelig data?
   - Er problemet egnet for ML-løsning?
   - Hva er alternativene?

**Fase 3: Alternativanalyse (4-8 uker)**

7. **Identifiser alternativer:**
   - Minimum: Nullalternativ + 2 AI-løsninger
   - Vurder både teknologi og leverandør

8. **Gjennomfør POC/pilot (hvis mulig):**
   - Test nøkkelteknologi i kontrollert miljø
   - Mål nøyaktighet, ytelse, brukervennlighet
   - Identifiser risiko og utfordringer

9. **Vurder hvert alternativ:**
   - Gjennomførbarhet (teknisk, organisatorisk)
   - Kostnader (initial + drift)
   - Risiko (teknisk, juridisk, reputasjon)
   - Gevinster (kvantifiserbare + kvalitative)

**Fase 4: Konsekvensanalyse (3-6 uker)**

10. **Vurder virkninger:**
    - Brukere (positiv/negativ påvirkning)
    - Ansatte (kompetanse, arbeidshverdag)
    - Organisasjon (effektivitet, risiko)
    - Samfunn (økonomi, demokrati, miljø)

11. **Gjennomfør DPIA (hvis aktuelt):**
    - Identifiser personvernrisiko
    - Vurder avbøtende tiltak
    - Konsulter Datatilsynet ved høy risiko

12. **Samfunnsøkonomisk analyse (hvis aktuelt):**
    - Kvantifiser kostnader og gevinster
    - Beregn netto nåverdi (NPV)
    - Sensitivitetsanalyse

**Fase 5: Involvering og høring (4-12 uker)**

13. **Intern involvering:**
    - Workshops med sluttbrukere
    - Review med IT/sikkerhet/jus
    - Presentasjon for ledelse/tillitsvalgte

14. **Ekstern høring (hvis aktuelt):**
    - Offentlig konsultasjon (typisk 3 måneder)
    - Innhenting av faglige innspill
    - Eventuell konsultasjon med Datatilsynet

**Fase 6: Anbefaling og beslutning (2-4 uker)**

15. **Skriv beslutningsgrunnlag:**
    - Besvar de seks spørsmålene
    - Inkluder analyser (DPIA, samfunnsøkonomi)
    - Dokumenter involvering og høring

16. **Ledelsesvedtak:**
    - Presentasjon for beslutningstaker
    - Avklaring av forutsetninger
    - Formelt vedtak (inkl. budsjett og mandat)

17. **Oppfølging:**
    - Gevinstrealisering (måling post-implementering)
    - Evaluering (fungerte løsningen som forventet?)

---

### Proporsjonalitet - Hvor omfattende skal utredning være?

Utredningsinstruksen krever at utredning skal være **"så omfattende og grundig som nødvendig"** basert på:
- Tiltakets **betydning** (store økonomiske/samfunnsmessige konsekvenser)
- **Prinspielle spørsmål** (påvirker grunnleggende rettigheter?)
- **Tilgjengelig tid** (haster det?)

**For AI-prosjekter:**

| Scenario | Utredningsomfang |
|----------|------------------|
| Pilot/POC (ikke produksjon) | Lett: Risikovurdering, juridisk screening, ressursplan |
| Intern AI-assistent (kontorproduksjon) | Middels: De 6 spørsmålene, DPIA, kompetanseplan |
| Offentlig tjeneste (høy-risiko AI Act) | Omfattende: Full utredning, DPIA, samfunnsøkonomi, ekstern kvalitetssikring |
| Kritisk infrastruktur (f.eks. helsediagnostikk) | Meget omfattende: Alle analyser + uavhengig validering, kliniske studier |

**Cosmo-anbefaling:**
Selv ved "lett" utredning, **gjør alltid:**
1. Risikoklassifisering (AI Act)
2. Personvernssjekk (trenger vi DPIA?)
3. Sikkerhetsvurdering (prompt injection, data poisoning)
4. Kompetansekartlegging (har vi nødvendig kompetanse?)

---

## Beslutningsgrunnlag og kvalitetssikring

### Hva skal beslutningsgrunnlaget inneholde?

**Minimum (alle AI-tiltak):**
1. **Executive summary:** Problemstilling, anbefaling, begrunnelse (1-2 sider)
2. **Besvarelse av de 6 spørsmålene** (strukturert)
3. **Risikovurdering:** Teknisk, juridisk, organisatorisk
4. **Ressursplan:** Kompetanse, budsjett, tid
5. **Implementeringsplan:** Milepæler, ansvarsfordeling

**Tillegg for høy-risiko AI:**
- DPIA (personvernkonsekvensvurdering)
- Samfunnsøkonomisk analyse
- Compliance-sjekk (AI Act, sektorregelverk)
- Leverandørevaluering (hvis eksternt produkt)

**Tillegg for store investeringer:**
- Ekstern kvalitetssikring (KS1/KS2)
- Gevinstanalyse (business case)
- Kontraktsstrategi
- Exit-strategi

### Kvalitetssikring av utredningen

**Intern kvalitetssikring:**
- **Faglig review:** Kvalitetssjekk av IT, jus, økonomi
- **Brukerinvolvering:** Er brukerbehov ivaretatt?
- **Ledelsesreview:** Er anbefaling i tråd med strategi?

**Ekstern kvalitetssikring (KS-ordningen):**

For prosjekter over 750 mill. NOK kreves ekstern kvalitetssikring i to faser:

**KS1 (før konseptvalg):**
- Er problemstillingen riktig forstått?
- Er alternativer grundig utredet?
- Er samfunnsøkonomisk analyse solid?

**KS2 (før budsjettfastsettelse):**
- Er valgt løsning gjennomførbar?
- Er kostnader realistisk estimert?
- Er organisasjonen klar til gjennomføring?

**For AI-prosjekter:**
Selv under terskelverdi kan frivillig ekstern review være lurt (f.eks. fagmiljø, leverandør, konsulent) for å utfordre antakelser om teknisk gjennomførbarhet og risiko.

### Typiske feil i AI-utredninger (og hvordan unngå dem)

| Feil | Konsekvens | Forebygging |
|------|-----------|------------|
| **AI-optimisme** (overdriver gevinstpotensial) | Skuffelse post-implementering | Bruk konservative estimater, POC før beslutning |
| **Underkommunikasjon av risiko** (spesielt bias) | Omdømmetap, juridiske konsekvenser | Rød teaming, bias-testing, transparens |
| **Undervurdering av kompetansebehov** | Prosjektet stopper opp | Tidlig kompetansekartlegging, rekrutteringsplan |
| **Mangelfull dataanalyse** (antar data er "good enough") | Dårlig modellytelse | Datakvalitetsanalyse før teknologivalg |
| **Glemme endringsledelse** (fokus på teknologi) | Lav brukertilfredshet | Brukerinvolvering fra dag 1, opplæring |
| **Ignorere exit-strategi** (vendor lock-in) | Avhengighet av én leverandør | Krav om standarder, portabilitet i kontrakt |

---

## Integrasjon med Microsoft-stakken

### Hvordan Microsoft-verktøy støtter utredningsprosessen

**Fase: Problemanalyse og datakartlegging**

| Oppgave | Microsoft-verktøy | Bruk |
|---------|-------------------|------|
| Datakartlegging | **Microsoft Purview** | Identifiser hvor personopplysninger finnes |
| Data quality assessment | **Azure Data Factory, Synapse** | Evaluer datakvalitet for ML |
| Baseline-måling | **Power BI** | Dashboard for dagens situasjon |

**Fase: POC og alternativanalyse**

| Oppgave | Microsoft-verktøy | Bruk |
|---------|-------------------|------|
| Quick POC (generativ AI) | **Azure OpenAI Service** | Teste GPT-4 for use case |
| Custom ML-modeller | **Azure Machine Learning** | Bygge egne modeller |
| Low-code AI | **AI Builder (Power Platform)** | Dokumentbehandling, sentiment-analyse |
| Chatbot/agent | **Copilot Studio** | Conversational AI (kundeservice, intern support) |
| Søk/RAG | **Azure AI Search** | Semantic search, retrieval-augmented generation |

**Fase: Compliance og risiko**

| Oppgave | Microsoft-verktøy | Bruk |
|---------|-------------------|------|
| DPIA | **Microsoft Purview Compliance Manager** | Template for privacy impact assessment |
| AI Act compliance | **Azure AI Foundry (model cards, transparency notes)** | Dokumentasjon av modeller |
| Content filtering | **Azure AI Content Safety** | Blokkere harmful content |
| Responsible AI dashboard | **Responsible AI Toolbox** | Bias detection, explainability |

**Fase: Implementering og drift**

| Oppgave | Microsoft-verktøy | Bruk |
|---------|-------------------|------|
| Monitoring | **Azure Monitor, Application Insights** | Overvåke modellytelse |
| Governance | **Azure Policy** | Håndheve sikkerhetskrav |
| Cost management | **Azure Cost Management** | Spore AI-kostnader (token usage) |

### Arkitekturmønstre for offentlig sektor AI

**1. Hybrid Human-AI (anbefalt for høy-risiko AI):**
```
Innbygger → AI forslag → Saksbehandler (final decision) → Vedtak
```
Fordel: Menneske i løkken, reduserer risiko for feil
Eksempel: AI anbefaler trygdevedtak, saksbehandler godkjenner

**2. AI-Assisted (for ekspertstøtte):**
```
Saksbehandler → Spør AI → AI svarer med kilder → Saksbehandler beslutter
```
Fordel: Frigjør tid, øker kvalitet
Eksempel: RAG-basert assistent for lovtolkning (Azure AI Search + OpenAI)

**3. Fully Automated (kun for lav-risiko AI):**
```
Innbygger → AI-system (regelbasert + ML) → Automatisk vedtak (med innsyn)
```
Krav: Høy nøyaktighet, transparens, klageadgang
Eksempel: Automatisk utbetaling av barnetrygd (regel-basert med ML-fraud detection)

**Cosmo-anbefaling:**
Start med **hybrid** (menneske i løkken), selv om teknologien kunne gjort det fullt automatisk. Bygg tillit gradvis.

---

## For arkitekten (Cosmo)

### Spørsmål å stille når organisasjon starter AI-utredning

**Tidlig fase (problemforståelse):**
1. "Hva er dagens måte å løse dette på, og hva er dokumentert ineffektivitet?"
2. "Finnes det data nok til å trene/evaluere en AI-modell?"
3. "Hvem er faktiske brukere av systemet, og er de involvert?"
4. "Hva er risikoklassifisering (AI Act), og er dere klar over konsekvensene?"
5. "Har dere vurdert ikke-AI-alternativer først?"

**Midt i utredning (teknisk dybde):**
6. "Hvordan måler dere suksess (ikke bare teknisk nøyaktighet, men brukertilfredshet)?"
7. "Hva er fallback-plan hvis AI-modellen feiler?"
8. "Hvordan håndteres bias (er treningsdata representativt)?"
9. "Hvilken kompetanse mangler dere, og hvordan skaffer dere den?"
10. "Hva er total eierkostnad (TCO) over 5 år?"

**Før beslutning:**
11. "Er alle forutsetninger (data, kompetanse, budsjett) realistiske?"
12. "Har dere DPIA hvis personopplysninger behandles?"
13. "Kan dere forklare AI-beslutninger til innbyggere (explainability)?"
14. "Hva er exit-strategi (vendor lock-in, reversibility)?"
15. "Hvordan overvåkes modellytelse i produksjon (concept drift)?"

### Fallgruver å unngå

**1. "AI vil løse alt"-syndromet**
- **Problem:** Overoptimisme uten kritisk vurdering av begrensninger
- **Motgift:** Krev POC med reelle data før beslutning

**2. Teknologi først, problem sist**
- **Problem:** "Vi må bruke GPT-4" uten klar use case
- **Motgift:** Start med problem, la teknologi følge

**3. Ignorere endringsledelse**
- **Problem:** Fokus på teknologi, glemmer at mennesker må endre arbeidsmåte
- **Motgift:** Involver brukere tidlig, plan for opplæring og support

**4. Mangelfull risikovurdering**
- **Problem:** Ser bare gevinster, undervurderer bias, sikkerhet, personvern
- **Motgift:** Rød teaming, bias-testing, DPIA

**5. Vendor lock-in uten bevissthet**
- **Problem:** Velger proprietær løsning uten exit-strategi
- **Motgift:** Krev standarder (OpenAI API-format, ONNX-modeller), portabilitet i kontrakt

**6. Data-kvalitet som ettertanke**
- **Problem:** Antar at eksisterende data er god nok for ML
- **Motgift:** Datakvalitetsanalyse før teknologivalg

**7. Glemme drift og vedlikehold**
- **Problem:** Budsjetterer initial utvikling, ignorerer drift (retraining, monitoring)
- **Motgift:** TCO-analyse inkludert drift over 5+ år

### Anbefalinger per modenhetsnivå

**Organisasjon er AI-novise (første prosjekt):**
- ✅ **Start smått:** Velg lavt-hengende frukt (dokumentklassifisering, FAQ-chatbot)
- ✅ **Kjøp, ikke bygg:** Bruk ferdige tjenester (Azure AI Services, Copilot Studio)
- ✅ **Lær underveis:** Invester i kompetanseheving parallelt med pilot
- ✅ **Menneske i løkken:** AI assisterer, mennesker bestemmer
- ⚠️ **Unngå:** Høy-risiko AI som første prosjekt (f.eks. automatiserte vedtak)

**Organisasjon har noen AI-prosjekter:**
- ✅ **Skalér:** Gjenbruk lærdommer fra første prosjekt
- ✅ **Etabler AI-governance:** Policy for databruk, modellvalidering, etikk
- ✅ **Bygg kompetanse internt:** Rekruttere/utvikle AI-team
- ✅ **Vurder custom models:** Hvis bruksmønster skiller seg fra standardløsninger
- ⚠️ **Unngå:** Silo-løsninger (sørg for deling av infrastruktur, kompetanse)

**Organisasjon er AI-moden:**
- ✅ **Industrialisering:** Felles AI-plattform, MLOps-pipeline
- ✅ **Kontinuerlig forbedring:** A/B-testing, retraining-strategier
- ✅ **Innovasjon:** Utforsk cutting-edge (multimodal AI, agent frameworks)
- ✅ **Deling:** Bidra til fellesløsninger (f.eks. gjennom Digdir, KS)
- ⚠️ **Unngå:** Kompleksitet for kompleksitetens skyld (KISS-prinsippet gjelder fortsatt)

---

## Kilder og verifisering

### Offisielle kilder (høy konfidens)

1. **Regjeringen.no - Utredningsinstruksen (2016):**
   [https://www.regjeringen.no/no/dokumenter/instruks-om-utredning-av-statlige-tiltak-utredningsinstruksen/id2476518/](https://www.regjeringen.no/no/dokumenter/instruks-om-utredning-av-statlige-tiltak-utredningsinstruksen/id2476518/)
   _Offisiell tekst av instruksen_

2. **DFØ - Veileder til utredningsinstruksen:**
   [https://www.dfo.no/fagomrader/utredning-og-analyse-av-statlige-tiltak/veileder-til-utredningsinstruksen](https://www.dfo.no/fagomrader/utredning-og-analyse-av-statlige-tiltak/veileder-til-utredningsinstruksen)
   _Omfattende veiledning i hvordan instruksen skal følges_

3. **DFØ - Veileder i samfunnsøkonomiske analyser:**
   [https://www.dfo.no/fagomrader/utredning-og-analyse-av-statlige-tiltak/samfunnsokonomiske-analyser](https://www.dfo.no/fagomrader/utredning-og-analyse-av-statlige-tiltak/samfunnsokonomiske-analyser)
   _Metodikk for cost-benefit analyse_

### EU AI Act og norsk implementering (middels konfidens)

4. **Regjeringen.no - Nasjonal strategi for kunstig intelligens:**
   [https://www.regjeringen.no/en/documents/nasjonal-strategi-for-kunstig-intelligens/id2685594/](https://www.regjeringen.no/en/documents/nasjonal-strategi-for-kunstig-intelligens/id2685594/)
   _Norsk AI-strategi_

5. **Regjeringen.no - Gjør Norge klar for trygg og innovativ KI-bruk (2025):**
   [https://www.regjeringen.no/en/whats-new/gjor-norge-klar-for-trygg-og-innovativ-ki-bruk/id3093081/](https://www.regjeringen.no/en/whats-new/gjor-norge-klar-for-trygg-og-innovativ-ki-bruk/id3093081/)
   _Beskriver at AI Act implementeres via EØS fra 2026_

6. **European Commission - AI Act:**
   [https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)
   _Offisiell EU-kilde for AI Act_

### Microsoft Azure AI governance (høy konfidens)

7. **Microsoft Learn - Govern AI apps and data for regulatory compliance:**
   [https://learn.microsoft.com/en-us/security/security-for-ai/govern](https://learn.microsoft.com/en-us/security/security-for-ai/govern)

8. **Microsoft Learn - Enhance public sector services with generative AI (training):**
   [https://learn.microsoft.com/en-us/training/modules/enhance-public-sector-services-generative-ai/](https://learn.microsoft.com/en-us/training/modules/enhance-public-sector-services-generative-ai/)

9. **Microsoft Learn - Governance and security for AI agents:**
   [https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization)

### Konfidensnivå for denne filen

**Høy konfidens (90%):**
- De seks spørsmålene fra utredningsinstruksen
- Krav til samfunnsøkonomisk analyse og kvalitetssikring
- Microsoft Azure AI-verktøy for compliance

**Middels konfidens (70%):**
- Detaljer om AI Act-implementering i Norge (fortsatt under utarbeidelse per 2026-02)
- Terskelverdier for KS-ordningen (kan endre seg)

**Lav konfidens (50%):**
- Eksakte timelines for AI Act-ikrafttredelse i Norge (avhenger av EØS-prosess)

**Cosmo-anbefaling:**
Verifiser alltid aktuelle lover og forskrifter på regjeringen.no og lovdata.no før beslutning. Denne filen er en veiledning, ikke juridisk rådgivning.

---

**Sist oppdatert:** 2026-02-04
**Neste review:** Når AI Act-implementering er vedtatt i Norge (forventet sommer 2026)