Ordre 20260912T193441Z-7358817909. Steg 1 var ikke transformen, men å rette
roadmapens R13-gate og få den ratifisert. Gaten `grep -rl "Cosmo"
skills/*/references -> 0` var usann på to uavhengige måter:
1. Ordren fanget den første: 451 av forekomstene er Azure Cosmos DB, ekte
produktinnhold. Diskriminatoren er ikke bokstaven «s» — `Cosmos <norsk
substantiv>` er genitiv av personaen (`### Cosmos tonalitet`), mens
`Cosmos DB`/`CosmosClient`/`cosmos_ru` er produkt.
2. Denne økten fant den andre: 132 persona-forekomster ligger i prosa,
tabeller, dialog-replikker og proveniens-linjer. Heading-nøytralisering
kan ikke nå dem, så «0 persona» er uoppnåelig også under den ratifiserte
formen. Operatøren ratifiserte alternativ A: gaten speiler formen, og de
132 bokføres til R13b/R14.
Tre korreksjoner av premisser som sto i ordren og STATE:
«ca 320 produkt» -> 451 (case-sensitivt nett manglet 327 lowercase
TOC-ankre + 99 identifikatorer; sann nevner 1 638)
«169 headinger» -> 401. 169 var `^## For Cosmo`-prefikset (168) og var
internt inkonsistent med sin egen topp-variant (204)
«417 matcher ingen
populasjon» -> 417 er cosmo-headinger utenfor kodefences; briefens
nevner var reell hele tiden
Fence-bevissthet er målt skadelig, ikke nødvendig: begge toggle-regler er
gale på dette korpuset (naiv toggle skjuler en ekte heading i
chain-of-thought-prompting.md, CommonMark-regelen ubalanserer
service-level-documentation-dr.md). Fence-agnostisk deteksjon finner 401
heading-linjer i nøyaktig de samme 40 variantene som fence-bevisst finner
400 i — ingen kodeblokk-linje er byte-identisk til en persona-heading. Derfor
nøkles transformen på 40 enumererte heading-tekster og ignorerer fences. En
ukjent variant kaster; en slug-kollisjon kaster. Ingenting auto-fikses.
TOC-en regenereres ikke, den rettes kirurgisk: alle 327 persona-lenker hadde
lenketekst lik én av de 40 heading-tekstene og anker lik slugify av den
(327/327, 0 avvik), så heading og TOC-entry skrives i samme operasjon og
ingen mellomtilstand etterlater en død lenke.
Ratifisert målform: `For Cosmo`, `For Cosmo Skyberg` og `For arkitekten
(Cosmo)` konvergerer på `For arkitekten`. To filer kolliderte og er adjudisert
ved å lese dem, ikke ved regel.
Verifisering (alle 7 kriterier fra ordren):
G1 persona på heading-linjer 401 -> 0
G2 døde fragmentlenker 1 -> 1 (pre-eksisterende, unntatt)
G3 produkt-forekomster 451 -> 451; `Cosmos DB|Azure Cosmos` 308 = 308
de 3 kun-produkt-filene byte-identiske
nettet validert begge veier injisert persona feller G1; genitiv feller G1;
produkt-heading og de 3 filene passerer
hele diffen 802 heading-linjer + 654 TOC-linjer, ANNET = 0
linjeantall 728 lagt til = 728 slettet
suite 1120/1120 (1097 + 23 nye)
validate-plugin 250 PASS / 0 FAIL
stikkprøve 10 filer, alle 5 skills, inkl. de 3 mest
produkt-tunge (26/20/19) — kun heading+TOC
Utenfor scope, urørt: de 4 SKILL.md, de 23 commands, CLAUDE.md, README.md,
NOTICE.md, docs/ (alt R14).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
28 KiB
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Ø) Type: methodology
Innhold
- Introduksjon
- De seks spørsmålene anvendt på AI
- Krav til utredning av AI-tiltak
- Metodikk og gjennomføring
- Beslutningsgrunnlag og kvalitetssikring
- Integrasjon med Microsoft-stakken
- For arkitekten
- Kilder og verifisering
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:
- Nødvendighet: Er AI nødvendig for å nå målet?
- Proporsjonalitet: Står kostnader/risikoer i forhold til gevinst?
- 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)
-
Etabler prosjektorganisasjon:
- Prosjektleder (ansvar for utredning)
- Arbeidsgruppe (tverrfaglig: IT, domene, jus, økonomi)
- Styringsgruppe (beslutningsmandat)
-
Avklar mandat:
- Hva skal utredes? (scope)
- Tidsfrist for beslutning
- Budsjett for utredningsarbeid
-
Identifiser stakeholders:
- Hvem påvirkes?
- Hvem har kunnskap vi trenger?
Fase 2: Problemanalyse (2-4 uker)
-
Beskriv nåsituasjon:
- Dagens prosess/tjeneste
- Målinger (baseline-data)
- Utfordringer og ineffektivitet
-
Definer mål:
- SMART-mål (Specific, Measurable, Achievable, Relevant, Time-bound)
- Suksesskriterier (hva er "god nok" løsning?)
-
Valider at AI er relevant:
- Finnes tilstrekkelig data?
- Er problemet egnet for ML-løsning?
- Hva er alternativene?
Fase 3: Alternativanalyse (4-8 uker)
-
Identifiser alternativer:
- Minimum: Nullalternativ + 2 AI-løsninger
- Vurder både teknologi og leverandør
-
Gjennomfør POC/pilot (hvis mulig):
- Test nøkkelteknologi i kontrollert miljø
- Mål nøyaktighet, ytelse, brukervennlighet
- Identifiser risiko og utfordringer
-
Vurder hvert alternativ:
- Gjennomførbarhet (teknisk, organisatorisk)
- Kostnader (initial + drift)
- Risiko (teknisk, juridisk, reputasjon)
- Gevinster (kvantifiserbare + kvalitative)
Fase 4: Konsekvensanalyse (3-6 uker)
-
Vurder virkninger:
- Brukere (positiv/negativ påvirkning)
- Ansatte (kompetanse, arbeidshverdag)
- Organisasjon (effektivitet, risiko)
- Samfunn (økonomi, demokrati, miljø)
-
Gjennomfør DPIA (hvis aktuelt):
- Identifiser personvernrisiko
- Vurder avbøtende tiltak
- Konsulter Datatilsynet ved høy risiko
-
Samfunnsøkonomisk analyse (hvis aktuelt):
- Kvantifiser kostnader og gevinster
- Beregn netto nåverdi (NPV)
- Sensitivitetsanalyse
Fase 5: Involvering og høring (4-12 uker)
-
Intern involvering:
- Workshops med sluttbrukere
- Review med IT/sikkerhet/jus
- Presentasjon for ledelse/tillitsvalgte
-
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)
-
Skriv beslutningsgrunnlag:
- Besvar de seks spørsmålene
- Inkluder analyser (DPIA, samfunnsøkonomi)
- Dokumenter involvering og høring
-
Ledelsesvedtak:
- Presentasjon for beslutningstaker
- Avklaring av forutsetninger
- Formelt vedtak (inkl. budsjett og mandat)
-
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:
- Risikoklassifisering (AI Act)
- Personvernssjekk (trenger vi DPIA?)
- Sikkerhetsvurdering (prompt injection, data poisoning)
- Kompetansekartlegging (har vi nødvendig kompetanse?)
Beslutningsgrunnlag og kvalitetssikring
Hva skal beslutningsgrunnlaget inneholde?
Minimum (alle AI-tiltak):
- Executive summary: Problemstilling, anbefaling, begrunnelse (1-2 sider)
- Besvarelse av de 6 spørsmålene (strukturert)
- Risikovurdering: Teknisk, juridisk, organisatorisk
- Ressursplan: Kompetanse, budsjett, tid
- 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 | Microsoft 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
Spørsmål å stille når organisasjon starter AI-utredning
Tidlig fase (problemforståelse):
- "Hva er dagens måte å løse dette på, og hva er dokumentert ineffektivitet?"
- "Finnes det data nok til å trene/evaluere en AI-modell?"
- "Hvem er faktiske brukere av systemet, og er de involvert?"
- "Hva er risikoklassifisering (AI Act), og er dere klar over konsekvensene?"
- "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)
-
Regjeringen.no - Utredningsinstruksen (2016): https://www.regjeringen.no/no/dokumenter/instruks-om-utredning-av-statlige-tiltak-utredningsinstruksen/id2476518/ Offisiell tekst av instruksen
-
DFØ - 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
-
DFØ - Veileder i samfunnsøkonomiske 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)
-
Regjeringen.no - Nasjonal strategi for kunstig intelligens: https://www.regjeringen.no/en/documents/nasjonal-strategi-for-kunstig-intelligens/id2685594/ Norsk AI-strategi
-
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/ Beskriver at AI Act implementeres via EØS fra 2026
-
European Commission - AI Act: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai Offisiell EU-kilde for AI Act
Microsoft Azure AI governance (høy konfidens)
-
Microsoft Learn - Govern AI apps and data for regulatory compliance: https://learn.microsoft.com/en-us/security/security-for-ai/govern
-
Microsoft Learn - Enhance public sector services with generative AI (training): https://learn.microsoft.com/en-us/training/modules/enhance-public-sector-services-generative-ai/
-
Microsoft Learn - Governance and security for AI agents: 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)