Kjell Tore Guttormsen ddce43d8b2 feat(ms-ai-architect): Spor 1 — Port-1-substrat migrert på 4 ikke-advisor-skills (243 Source + 327 Type + 325 TOC + stale-verified poison fjernet) [skip-docs]

Steg 9 (R4): unified migrate-corpus.mjs --write over engineering/governance/
infrastructure/security. 327 filer mutert, verified=null, prosa byte-identisk
(fra første ## seksjon), advisor urørt (0 endringer).

To applier-fixes oppdaget under kjøring (TDD, RED→GREEN):
- insertHeaderFields: anker faller nå tilbake når en meta-linje selv passerer
  500B (2 filer pakket et avsnitt i **Status:** → Type/Source landet utenfor
  scan-vinduet, applierens post-write-assertion fanget + restaurerte).
- normalizeStaleVerified: fjerner nå ALLE stale non-date **Verified:** i
  500B-vinduet, inkl. stray body-dup rett under --- (9 mlops-genaiops-filer var
  ellers falskt "verified"/fresh, droppet fra worklist). Operatør-godkjent
  utvidelse av carve-out; kun stray metadata-linjer, aldri prosa.

test-transform-criterion: precondition oppdatert til post-migrasjons-sannhet
(fila bærer nå Source). Suite 728/728 grønn.

2026-07-04 10:19:11 +02:00

17 KiB

Raw Blame History

Digdirs arkitekturprinsipp 1: Brukerorientering

Last updated: 2026-02 Status: Gjeldende Category: Norwegian Public Sector AI Governance Type: reference Source: https://learn.microsoft.com/azure/well-architected/ai/responsible-ai

Introduksjon

Brukerorientering er det første og mest fundamentale arkitekturprinsippet etablert av Digitaliseringsdirektoratet (Digdir) for offentlig sektor i Norge. Prinsippet slår fast at offentlige tjenester skal være basert på brukernes behov og perspektiver, og være brukbare for alle, uavhengig av alder og funksjonsevne.

Dette prinsippet er gjort obligatorisk for statlig sektor gjennom digitaliseringssirkulæret og er anbefalt for kommunal sektor. Det skal anvendes ved etablering av nye IT-løsninger eller ved vesentlig ombygging av eksisterende IT-løsninger, og gjelder både for egenutviklede løsninger og ved anskaffelser.

For AI-løsninger er brukerorientering spesielt kritisk. AI-systemer opererer ofte med komplekse beslutningsprosesser som ikke er umiddelbart forståelige for brukerne. Samtidig plasserer brukerne sin tillit i systemets etiske funksjonalitet, selv når de ikke forstår den underliggende logikken. Dette gjør det essensielt å bygge AI-løsninger som aktivt involverer brukere, sikrer universell utforming (UU), og gir forståelige forklaringer på AI-beslutninger.

Prinsippets kjerneinnhold

Digdirs formulering

Prinsippet har tre hovedkomponenter:

Basert på brukernes behov og perspektiver — Tjenesteutvikling skal starte med innsikt i hva brukerne faktisk trenger, ikke med hva teknologien kan tilby
Brukbar for alle — Universell utforming skal sikre at tjenester fungerer uavhengig av brukerens alder eller funksjonsevne
Sammenhengende tjenester — Tjenester skal oppleves som helhetlige på tvers av etater, ikke som fragmenterte silo-løsninger

Underliggende krav

Brukerorientering stiller flere konkrete krav til utvikling:

Brukerinvolvering — Brukere skal involveres gjennom hele utviklingsløpet, fra problemdefinisjon til testing og iterasjon
Tilgjengelighet — Løsninger skal følge WCAG 2.1-standarder (minimum nivå AA) og være testbare med hjelpemiddelteknologi
Transparens — Brukere skal forstå hvordan systemet fungerer og hvordan beslutninger tas
Feedback-mekanismer — Brukere skal kunne gi tilbakemelding og oppleve at innspillene påvirker utviklingen
Kontinuerlig forbedring — Tjenester skal itereres basert på faktisk bruk og brukerinnsikt, ikke kun på interne antagelser

Koblinger til andre prinsipper

Brukerorientering er tett koblet til andre Digdir-arkitekturprinsipper:

Prinsipp 2: Ta arkitekturbeslutninger på rett nivå — Beslutninger skal tas så nært oppgaveløsningen og brukernes behov som mulig
Prinsipp 3: Samhandling — Digital samhandling på tvers av offentlig sektor skal skje ut fra brukernes behov, ikke organisasjonsstruktur
Rammeverk for digital samhandling — Brukerorientering er et gjennomgående tema i Digdirs nasjonale interoperabilitetsrammeverk

Anvendelse på AI-løsninger

Brukerinvolvering i AI-utvikling

AI-systemer har en tendens til å bli utviklet som "black boxes" der brukere først møter systemet når det er ferdig trent. Dette bryter med brukerorienteringsprinsippet. For AI-løsninger i offentlig sektor kreves:

Early-stage research:

Forstå brukernes faktiske problemer før du definerer AI som løsning
Identifiser hvilke brukerbehov AI faktisk kan adressere (og hvilke den ikke kan)
Kartlegg brukergrupper med ulike funksjonsevner og digitale ferdigheter

Co-creation og co-design:

Inviter brukere til workshops og design sprints der AI-systemets oppførsel diskuteres
Prototype med low-fidelity mock-ups av AI-interaksjoner før du trener modeller
Test tidlige versjoner (MVPs) med reelle brukere, ikke kun med tekniske testere

Kontinuerlig testing og iterasjon:

Launch beta-versjoner til et subsett av brukere for å samle inn feedback på AI-genererte svar
Analyser faktisk bruksmønster (ikke kun tekniske metrics som accuracy)
Iterer på prompts, grounding-data og UI basert på brukerinnsikt

Tilgjengelighet (UU) og AI

AI-løsninger må oppfylle kravene i forskrift om universell utforming av IKT-løsninger. Spesifikke hensyn for AI:

Skjermleser-kompatibilitet:

AI-genererte svar må være tilgjengelige for skjermlesere (Narrator, JAWS, NVDA)
Alt-tekst for AI-genererte bilder må genereres automatisk eller manuelt legges til
Tabelldata fra AI må struktureres med korrekt markup (headers, data cells)

Tastaturnavigasjon:

AI-chatbots må være fullt navigerbare med tastatur (tab, enter, esc)
Focus-indikatorer må være tydelige når bruker navigerer mellom AI-svar og input-felt
Shortcuts som "skip to main content" må fungere i AI-grensesnitt

Kognitiv tilgjengelighet:

AI-svar må være skrevet på et språknivå tilpasset målgruppen (typisk B1-nivå for offentlig sektor)
Lange AI-svar bør struktureres med headings og lister for lettere skanning
Brukere med kognitive utfordringer må få mulighet til å be om forenklede svar

Visuell tilgjengelighet:

Kontrast mellom AI-generert tekst og bakgrunn må være minimum 4.5:1 (WCAG AA)
Fonter bør være lesevennlige (anbefalt: Fluent Sitka Small, Fluent Calibri for dysleksi)
AI-grensesnitt må fungere med zooming opp til 200 % uten tap av funksjonalitet

Forståelige AI-beslutninger

Transparens i AI-svar:

Vis brukere hvilke kilder AI-modellen har konsultert (f.eks. top 3 dokumenter i en RAG-løsning)
Inkluder confidence scores eller usikkerhetsmarkører når modellen er usikker
Lag logging som sporer hver steg i en multi-agent workflow (men unngå å overvelde brukeren)

Gradvis disclosure:

Bruk minimalt disruptive UI-metoder (tooltips, expandable sections) for å vise teknisk informasjon
La brukere selv velge hvor mye detalj de ønsker (f.eks. "Vis kilder", "Forklar hvordan dette ble beregnet")
Ikke krev at brukere forstår tekniske termer som "embeddings" eller "retrieval" for å bruke systemet

Feedback-loops:

Implementer "thumbs up/down" eller lignende mekanismer for hvert AI-svar
La brukere rapportere problematiske svar (bias, feilinformasjon, upassende tone)
Sørg for at feedback faktisk påvirker modellen eller grounding-data i neste iterasjon

Beslutningsveiledning

Beslutningstabell for AI-prosjekter

Scenario	Brukerorientert tilnærming	Anti-pattern å unngå
Velge AI-modell	Velg basert på brukerbehov (responstid, språk, domene), ikke kun på teknisk performance	Velge den "beste" modellen på benchmarks uten å teste med reelle brukere
Designe chat-grensesnitt	Prototype med brukere før du bygger backend, test med hjelpemiddelteknologi	Bygge et generisk chat-vindu uten tilpasning til brukergruppen
Velge grounding-data for RAG	Basert på hvilke spørsmål brukere faktisk stiller, ikke på hvilken data organisasjonen har	Inkludere all tilgjengelig data "for sikkerhets skyld"
Håndtere AI-feil	Forklare hva som gikk galt i brukervennlig språk, gi forslag til omformulering	Vise tekniske feilmeldinger ("Error 500: model timeout")
Evaluere AI-suksess	Måle brukertilfredshet og oppgavegjennomføring, ikke kun accuracy	Kun rapportere tekniske metrics (F1-score, BLEU) til stakeholders

Vanlige feil (og hvordan unngå dem)

❌ "Vi bygger en AI-løsning først, så tester vi med brukere etterpå" ✅ Involver brukere i problemdefinisjonen før du bestemmer at AI er løsningen

❌ "WCAG-compliance er noe vi fikser i slutten av prosjektet" ✅ Design for tilgjengelighet fra dag 1, test med skjermleser hver sprint

❌ "Brukere trenger ikke å vite hvordan AI-modellen fungerer" ✅ Gi transparens om kilder og usikkerhet, men på en måte som ikke overvelder

❌ "Vi har gjort brukerundersøkelser, så vi vet hva de trenger" ✅ Brukerinvolvering er kontinuerlig, ikke en engangshendelse i discovery-fasen

❌ "Bare 44 % av offentlige virksomheter bruker brukerinnsikt til å styre digital strategi" ✅ Vær i den andre halvparten — gjør brukerinnsikt til en del av beslutningsprosessen

Røde flagg i AI-prosjekter

Ingen brukere involvert i de første 3 sprintene
AI-modellen velges før problemet er fullt forstått
Ingen testing med hjelpemiddelteknologi (skjermleser, tastaturnavigasjon)
Stakeholders ber om "en AI-løsning" uten å definere brukerbehov
Prosjektet måler kun tekniske KPIer (accuracy, latency), ikke brukertilfredshet
AI-svar gir ikke kilder eller forklaring på hvordan de ble generert

Eksempler fra norsk offentlig sektor

StimuLab — Digdirs innovasjonsprogram

StimuLab er Digdirs og DOGAs stimuleringsordning for brukerorientert innovasjon i offentlig sektor. Etablert i 2016, skal programmet bidra til å løse komplekse problemer i stat og kommune gjennom tjenestedesign med brukeren i sentrum.

Nøkkelprinsipper:

Holistisk perspektiv med brukeren i sentrum
Involvering av innbyggere fra frontlinjen av offentlig innovasjon
Tverrfaglig samarbeid mellom designere, tjenesteansvarlige og teknologer

Relevans for AI: StimuLab-metoden kan anvendes på AI-prosjekter for å sikre at teknologivalg (f.eks. hvilken type modell, hvilken grounding-strategi) er drevet av brukerbehov, ikke av teknologihype.

"Én digital offentlig sektor" (2019-2025)

Regjeringens og KS sin felles digitaliseringsstrategi legger vekt på:

Tydelig brukersentrisk tjenesteutvikling
Sammenhengende tjenester på tvers av forvaltningsnivåer
Kun 44 % av offentlige virksomheter bruker innsikt om brukerbehov til å styre digital strategi (måltall: øke denne andelen)

Implikasjon for AI: AI-løsninger i offentlig sektor må designes for samhandling på tvers av etater, ikke som isolerte chatbots eller interne verktøy.

Rammeverk for digital samhandling (NIF)

Norges nasjonale interoperabilitetsrammeverk definerer digital samhandling som mer enn et teknisk spørsmål. Brukerorientering er et gjennomgående tema, med krav om at:

Kommuner, fylkeskommuner og statlige etater skal kunne samarbeide for å utvikle brukerorienterte, sammenhengende og effektive digitale tjenester
Arbeidet skal skje ut fra brukernes behov, ikke ut fra organisasjonsstruktur

Relevans for AI: En RAG-løsning som bruker data fra flere etater må ha authorization-aware retrieval (brukeren får kun se data de har tilgang til), men samtidig oppleves som én helhetlig tjeneste.

For arkitekten (Cosmo)

Spørsmål å stille kunden

"Hvem er brukerne, og hva er deres faktiske behov?" (Ikke aksepter "alle ansatte" eller "publikum" som svar — be om personas og bruksmønstre)
"Har dere involvert brukere i problemdefinisjonen, eller er AI-løsningen allerede bestemt?" (Rødt flagg hvis AI er løsningen før problemet er forstått)
"Hvordan har dere testet tilgjengelighet (UU) så langt?" (Hvis svaret er "vi skal gjøre det senere", gi en tydelig advarsel)
"Hvilke brukergrupper har spesielle behov (eldre, synshemmede, kognitive utfordringer, ikke-digitale innbyggere)?" (AI-løsninger må fungere for de mest sårbare brukergruppene, ikke kun for tech-savvy brukere)
"Hvordan vil dere måle om AI-løsningen faktisk møter brukernes behov?" (Forvent konkrete KPIer som brukertilfredshet, oppgavegjennomføring, ikke kun accuracy)
"Har dere planlagt for hvordan brukere skal forstå og stole på AI-beslutninger?" (Transparens og forklarbarhet må være en del av design, ikke et "nice-to-have")
"Hvordan vil dere samle inn og agere på brukerfeedback etter lansering?" (AI-systemer krever kontinuerlig iterasjon basert på faktisk bruk)
"Hvordan sikrer dere at AI-løsningen fungerer på tvers av etater (hvis relevant)?" (Sammenhengende tjenester krever planlegging for interoperabilitet, ikke silotekning)

Fallgruver å unngå

Teknologi-først-tilnærmingen Ikke start med "vi skal bruke Azure OpenAI" — start med "hva prøver brukerne å oppnå?"
"One size fits all"-grensesnitt AI-chatbots som ser identiske ut for alle brukergrupper bryter med brukerorienteringsprinsippet
Manglende tilgjengelighetstesting Testing med hjelpemiddelteknologi må skje hver sprint, ikke kun ved avslutning
Overveldende transparens Ikke dump alle tekniske detaljer på brukeren — bruk gradvis disclosure
Antagelser om digital kompetanse Ikke design kun for brukere som forstår hva "AI" eller "språkmodell" betyr

Anbefalinger ved arkitekturbeslutninger

Ved valg av AI-modell:

Prioriter norsk språkstøtte hvis brukerne primært skal interagere på norsk
Velg modeller med lav latency hvis brukere forventer sanntidssvar
Test med reelle brukere, ikke kun på benchmarks (GPT-4 kan score høyt på MMLU, men gi dårlige svar for din brukerkontekst)

Ved design av grensesnitt:

Bruk Microsoft Human-AI Experiences Design Library som utgangspunkt
Implementer feedback-mekanismer (thumbs up/down, rapporter problem) fra dag 1
Sørg for at fokus-indikatorer og tastaturnavigasjon fungerer perfekt

Ved valg av grounding-strategi (RAG):

Basér chunking-strategi på hvordan brukere faktisk stiller spørsmål (f.eks. korte chunks hvis brukere ber om faktasvar, lengre hvis de ber om sammenhenger)
Implementer authorization-aware retrieval hvis data kommer fra flere etater
Vis brukerne hvilke kilder som ble brukt (øker tillit)

Ved evaluering:

Mål ikke kun teknisk accuracy — mål brukertilfredshet, oppgavegjennomføring, tillit
Samle inn kvalitativ feedback (ikke kun kvantitativ) for å forstå hvorfor brukere liker eller misliker svar
Test med brukergrupper som har spesielle behov (eldre, synshemmede, lavt utdannede)

Ved deployment:

Lanser som MVP til et subsett av brukere, ikke big-bang til alle
Implementer logging som lar deg spore hver interaksjon (men respekter personvern)
Ha en plan for hvordan du itererer basert på faktisk bruksdata

Kilder og verifisering

Offisielle Digdir-ressurser (Verified via WebSearch 2026-02)

Tjenestedesign og brukerinvolvering (Verified via WebSearch 2026-02)

Nasjonal digitaliseringsstrategi (Verified via WebSearch 2026-02)

Microsoft-kilder for AI og tilgjengelighet (Verified via microsoft_docs_search 2026-02)

Baseline (Modellkunnskap)

WCAG 2.1 Level AA-standarder for digital tilgjengelighet
Forskrift om universell utforming av IKT-løsninger (Norge)
Azure Well-Architected Framework AI-prinsipper

17 KiB Raw Blame History Unescape Escape