Kjell Tore Guttormsen
ddce43d8b2
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.
293 lines
17 KiB
Markdown
293 lines
17 KiB
Markdown
# 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
|
||
|
||
---
|
||
|
||
## Innhold
|
||
|
||
- [Introduksjon](#introduksjon)
|
||
- [Prinsippets kjerneinnhold](#prinsippets-kjerneinnhold)
|
||
- [Anvendelse på AI-løsninger](#anvendelse-på-ai-løsninger)
|
||
- [Beslutningsveiledning](#beslutningsveiledning)
|
||
- [Eksempler fra norsk offentlig sektor](#eksempler-fra-norsk-offentlig-sektor)
|
||
- [For arkitekten (Cosmo)](#for-arkitekten-cosmo)
|
||
- [Kilder og verifisering](#kilder-og-verifisering)
|
||
|
||
## 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:
|
||
|
||
1. **Basert på brukernes behov og perspektiver** — Tjenesteutvikling skal starte med innsikt i hva brukerne faktisk trenger, ikke med hva teknologien kan tilby
|
||
2. **Brukbar for alle** — Universell utforming skal sikre at tjenester fungerer uavhengig av brukerens alder eller funksjonsevne
|
||
3. **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
|
||
|
||
1. **"Hvem er brukerne, og hva er deres faktiske behov?"**
|
||
(Ikke aksepter "alle ansatte" eller "publikum" som svar — be om personas og bruksmønstre)
|
||
|
||
2. **"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)
|
||
|
||
3. **"Hvordan har dere testet tilgjengelighet (UU) så langt?"**
|
||
(Hvis svaret er "vi skal gjøre det senere", gi en tydelig advarsel)
|
||
|
||
4. **"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)
|
||
|
||
5. **"Hvordan vil dere måle om AI-løsningen faktisk møter brukernes behov?"**
|
||
(Forvent konkrete KPIer som brukertilfredshet, oppgavegjennomføring, ikke kun accuracy)
|
||
|
||
6. **"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")
|
||
|
||
7. **"Hvordan vil dere samle inn og agere på brukerfeedback etter lansering?"**
|
||
(AI-systemer krever kontinuerlig iterasjon basert på faktisk bruk)
|
||
|
||
8. **"Hvordan sikrer dere at AI-løsningen fungerer på tvers av etater (hvis relevant)?"**
|
||
(Sammenhengende tjenester krever planlegging for interoperabilitet, ikke silotekning)
|
||
|
||
### Fallgruver å unngå
|
||
|
||
1. **Teknologi-først-tilnærmingen**
|
||
Ikke start med "vi skal bruke Azure OpenAI" — start med "hva prøver brukerne å oppnå?"
|
||
|
||
2. **"One size fits all"-grensesnitt**
|
||
AI-chatbots som ser identiske ut for alle brukergrupper bryter med brukerorienteringsprinsippet
|
||
|
||
3. **Manglende tilgjengelighetstesting**
|
||
Testing med hjelpemiddelteknologi må skje hver sprint, ikke kun ved avslutning
|
||
|
||
4. **Overveldende transparens**
|
||
Ikke dump alle tekniske detaljer på brukeren — bruk gradvis disclosure
|
||
|
||
5. **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)
|
||
|
||
- [Arkitekturprinsippene bidrar til bedre digitale løsninger | Digdir](https://www.digdir.no/krav-og-anbefalinger/arkitekturprinsippene-bidrar-til-bedre-digitale-losninger/3172)
|
||
- [Overordnede arkitekturprinsipper | Digdir](https://www.digdir.no/digital-samhandling/overordnede-arkitekturprinsipper/1065)
|
||
- [Rammeverk for digital samhandling | Digdir](https://www.digdir.no/digital-samhandling/rammeverk-digital-samhandling/2148)
|
||
- [Sammenhengende tjenester med brukeren i sentrum | Digdir](https://www.digdir.no/handlingsplanen/sammenhengende-tjenester-med-brukeren-i-sentrum/1255)
|
||
|
||
### Tjenestedesign og brukerinvolvering (Verified via WebSearch 2026-02)
|
||
|
||
- [Design | Digdir](https://www.digdir.no/innovasjon/design/3075)
|
||
- [StimuLab: Brukerorientert offentlig innovasjon | Digdir](https://www.digdir.no/stimulab/stimulab-brukerorientert-offentlig-innovasjon-rad-og-erfaringer-fra-frontlinjen/1986)
|
||
- [StimuLab – Digdir og DOGA | DOGA](https://doga.no/aktiviteter/design-og-innovasjon/stimulab/dette-er-stimulab/)
|
||
|
||
### Nasjonal digitaliseringsstrategi (Verified via WebSearch 2026-02)
|
||
|
||
- [Digitalisering i offentlig sektor | Regjeringen.no](https://www.regjeringen.no/no/dokumenter/digitalisering-i-offentlig-sektor/id2830849/)
|
||
- [Én digital offentlig sektor | Regjeringen.no](https://www.regjeringen.no/no/dokumenter/en-digital-offentlig-sektor/id2653874/)
|
||
- [Bli kjent med digitaliseringsstrategien | Digdir](https://www.digdir.no/digitalisering-og-samordning/bli-kjent-med-digitaliseringsstrategien/2847)
|
||
|
||
### Microsoft-kilder for AI og tilgjengelighet (Verified via microsoft_docs_search 2026-02)
|
||
|
||
- [Design methodology for AI workloads on Azure | Microsoft Learn](https://learn.microsoft.com/en-us/azure/well-architected/ai/design-methodology)
|
||
- [Application design for AI workloads on Azure | Microsoft Learn](https://learn.microsoft.com/en-us/azure/well-architected/ai/application-design)
|
||
- [Responsible AI in Azure workloads | Microsoft Learn](https://learn.microsoft.com/en-us/azure/well-architected/ai/responsible-ai)
|
||
- [Accessibility information for IT professionals | Microsoft Learn](https://learn.microsoft.com/en-us/windows/configuration/accessibility/)
|
||
- [Recommendations for a user-centered design strategy | Microsoft Learn](https://learn.microsoft.com/en-us/power-platform/well-architected/experience-optimization/user-centered-design)
|
||
- [Microsoft Human-AI Experiences Design Library](https://www.microsoft.com/en-us/haxtoolkit/library/)
|
||
|
||
### 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
|