KB-currency refresh (high priority, 2026-06-19) via /architect:kb-update. 49 high-prioritets governance/security/monitoring-filer re-verifisert mot Microsoft Learn (MCP) — delegert til 8 parallelle Opus-subagenter gruppert etter delt kilde, verifisert i hovedkontekst (diff-review + tester). Hovedendringer (faktuelle korreksjoner + currency): - MITRE ATLAS-IDer korrigert (supply-chain): AML.T0050 -> AML.T0018.000 (Poison AI Model); AML.T0020 = Poison Training Data; T1195 Supply Chain Compromise. Gamle IDer var utdaterte (verifisert mot MCSB v2 AI-1). - OTel-sampling presisert (distributed-tracing): adaptive sampling = klassisk App Insights SDK; OTel-distroen sampler IKKE by default (fixed-rate/ rate-limited maa konfigureres); Functions parent-based sampling er default. - MCSB v2 AI-kontroller AI-1 -> AI-7 (risk-taxonomy three-pillar, scoring- framework, rubrics, red-team, adversarial); Defender for Cloud AI threat protection + AI-SPM (GA). - AI gateway (APIM) multi-provider: Anthropic Messages API v2-tiers, Google Vertex, unified model API (preview), MCP/A2A, Foundry-integrasjon; eksakte policy-navn (llm-emit-token-metric maks 5 dims, llm-semantic-cache-*, score-threshold = avstand, MS-eks. 0.15). - Purview Enterprise AI apps inkl. Anthropic Claude (Enterprise) + ChatGPT Enterprise; Security Dashboard for AI (Agent 365-inventar, MCP-servere, tredjepartsmodeller; Security Reader minimumsrolle). - Entra Agent ID: CA-lisenskrav (Entra ID P1/P2 + Agent 365), CA-scoping per tilgangsmoenster (on-behalf-of/app-only/agent-as-user), CA-grenser, connector-permissions som API-permissions. - Copilot DLP: Block SITs in web search (GA, Performing Web Searches) + Block external email (preview) som prompt injection-vern. - Azure AI Language PII: tre feature-typer, GA-API 2026-05-01; NOIdentityNumber bekreftet dedikert kategori for norske foedselsnummer. - Foundry Tools-rename forsterket paa tvers; alle 49 Last updated -> 2026-06-19. Discovery: 500 kandidater (alle Databricks-stoey) -> kun registry-kandidater, ingen nye skills/-filer -> 389-telling uendret. validate 239 PASS, kb-integrity 115/115 (262 orphan-warnings uendret), gitleaks clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01REiKFhP4w6xGXXqWKpPCJJ
682 lines
28 KiB
Markdown
682 lines
28 KiB
Markdown
# Utredningsinstruksen - AI Project Scoping and Methodology
|
|
|
|
**Last updated:** 2026-06-19
|
|
**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-06-19
|
|
**Neste review:** Når AI Act-implementering er vedtatt i Norge (forventet sommer 2026)
|