ms-ai-architect/skills/ms-ai-advisor/references/architecture/ai-utredning-template.md

AI-arkitekturutredning — Mal for norsk offentlig sektor

Sist oppdatert: 2026-02 (v1.0) Målgruppe: Løsningsarkitekter, prosjektledere og beslutningstagere i norsk offentlig sektor Format: Strukturert utredningsmal basert på utredningsinstruksen, Digdirs arkitekturprinsipper, rammeverk for digital samhandling og EU AI Act

---

Om denne malen

Denne malen kombinerer obligatoriske krav for norsk offentlig sektor med AI-spesifikke vurderinger til ett sammenhengende utredningsdokument. Den er designet for bruk med architect-pluginens kommandoer og agenter.

Regulatorisk grunnlag

Krav	Kilde	Obligatorisk
Utredningsinstruksen (6 spørsmål)	Regjeringen, 2016	✅ Ja, for alle statlige tiltak
7 arkitekturprinsipper	Digdir	✅ Ja, for statlige IT-løsninger
Rammeverk for digital samhandling	Digdir (basert på EIF)	✅ Ja, for digitale tjenester
EU AI Act	EU-forordning, norsk lov fra aug 2026	✅ Ja, for AI-systemer
GDPR / Personopplysningsloven	EU-forordning + norsk lov	✅ Ja, ved personopplysninger
NSM grunnprinsipper	NSM	✅ Ja, for IKT-sikkerhet

Bruk med architect-pluginen

Malen er designet for å fylles ut progressivt med støtte fra eksisterende kommandoer og agenter:

Mal-seksjon	Støttes av	Referansefil
S2 Utredningsinstruksen	/architect:research	norwegian-public-sector-governance/utredningsinstruksen-*.md
S3 Digdirs 7 prinsipper	/architect:research	norwegian-public-sector-governance/digdir-principle-*.md
S4.1 AI Act	/architect:research	responsible-ai/ai-act-compliance-guide.md
S4.2 Modellstrategi	/architect:research	cost-optimization/model-selection-*.md
S4.3 Data og RAG	/architect:research	rag-architecture/*.md
S4.4 Prompt/sikkerhet	/architect:security	ai-security-engineering/prompt-injection-*.md, ai-security-engineering/jailbreak-*.md
S4.5 Bias	Manuelt	responsible-ai/bias-*.md
S4.6 Forklarbarhet	Manuelt	responsible-ai/model-explainability-*.md
S4.7 HITL	Manuelt	responsible-ai/human-in-the-loop-*.md
S4.8 MLOps	/architect:research	mlops-genaiops/*.md, monitoring-observability/*.md
S5.1 Sikkerhet	/architect:security	security.md, ai-security-engineering/ai-security-scoring-*.md
S5.2 DPIA	Manuelt	norwegian-public-sector-governance/dpia-*.md, public-sector-checklist.md
S5.3 ROS	Manuelt	norwegian-public-sector-governance/ros-analyse-*.md
S5.4 Dataklassifisering	Manuelt	ai-security-engineering/data-leakage-*.md, ai-security-engineering/pii-*.md
S6 Kostnad	/architect:cost	cost-models.md, cost-optimization/*.md
S7 Digital samhandling	Manuelt	norwegian-public-sector-governance/digital-samhandling-*.md
S8.1 Plattform	/architect:compare, /architect:license	decision-trees.md, licensing-matrix.md
S8.3 ADR	/architect:adr	adr-template.md
S9 Implementering	/architect:poc	poc-template.md, migration-patterns.md, norwegian-public-sector-governance/gevinstrealisering-*.md

---

SEKSJON 0: Dokumentmetadata

# AI-arkitekturutredning: [Tittel]

| Felt | Verdi |
|------|-------|
| **Virksomhet** | [Virksomhetsnavn] |
| **Utredningsansvarlig** | [Navn, rolle] |
| **Arkitekt** | [Navn, rolle] |
| **Opprettet** | YYYY-MM-DD |
| **Sist oppdatert** | YYYY-MM-DD |
| **Status** | Utkast / Under vurdering / Godkjent / Avvist |
| **Klassifisering** | Åpen / Intern / Begrenset |
| **Kompleksitet** | Enkel / Middels / Kompleks (se S11) |
| **AI Act risikoklasse** | Minimal / Begrenset / Høy / Uakseptabel |
| **Relaterte ADR-er** | [ADR-xxx, ADR-yyy] |
| **Relaterte utredninger** | [Evt. tidligere utredninger] |
| **Beslutningsfrist** | YYYY-MM-DD |

---

SEKSJON 1: Sammendrag

Formål: Gi beslutningstakere en komplett oversikt på én side.

## 1. Sammendrag

### Bakgrunn
[2-3 setninger om problemet og hvorfor utredningen er igangsatt]

### Anbefaling
[Klar anbefaling i 1-2 setninger — hva bør virksomheten gjøre?]

### Nøkkeltall

| Parameter | Verdi |
|-----------|-------|
| Estimert årskostnad (drift) | [X] NOK |
| Estimert etableringskostnad | [X] NOK |
| Forventet årlig gevinst | [X] NOK (kvantifiserbar) + kvalitativ |
| AI Act risikoklasse | [Minimal/Begrenset/Høy] |
| Overordnet risikonivå | [Lavt/Middels/Høyt] |
| Anbefalt plattform | [Microsoft-plattform] |
| Estimert tid til produksjon | [X måneder] |

### Konfidens

| Aspekt | Konfidens | Begrunnelse |
|--------|-----------|-------------|
| Teknisk gjennomførbarhet | 🟢 Høy / 🟡 Medium / 🔴 Lav | [Kort] |
| Kostnadsestimat | 🟢/🟡/🔴 | [Kort] |
| Regulatorisk compliance | 🟢/🟡/🔴 | [Kort] |
| Organisatorisk gjennomførbarhet | 🟢/🟡/🔴 | [Kort] |

---

SEKSJON 2: Utredningsinstruksen (6 obligatoriske spørsmål)

Kilde: Utredningsinstruksen (2016) Obligatorisk: Ja, for alle statlige tiltak som kan ha virkninger for andre.

Utredningsinstruksen krever at alle statlige tiltak besvarer minst disse seks spørsmålene. For AI-tiltak betyr dette:

2.1 Hva er problemet, og hva vil vi oppnå?

### 2.1 Problemanalyse

**Problemet:**
[Beskriv det faktiske problemet. Unngå å formulere problemet som fravær av en løsning.
FEIL: "Vi mangler en AI-chatbot"
RIKTIG: "Innbyggere venter i snitt 14 dager på svar på enkle henvendelser"]

**Årsaker:**
- [Rotårsak 1 — hvorfor oppstår problemet?]
- [Rotårsak 2]
- [Rotårsak 3]

**Mål (SMART):**
- [Spesifikt, Målbart, Oppnåelig, Relevant, Tidsbundet mål 1]
- [Mål 2]

**Berørte grupper:**
| Gruppe | Hvordan berørt | Antall |
|--------|----------------|--------|
| Innbyggere | [Beskrivelse] | [Ca. antall] |
| Saksbehandlere | [Beskrivelse] | [Ca. antall] |
| IT-avdeling | [Beskrivelse] | [Ca. antall] |
| Andre | [Beskrivelse] | [Ca. antall] |

2.2 Hvilke tiltak er relevante?

### 2.2 Relevante tiltak

Utredningsinstruksen krever at minst tre alternativer vurderes, inkludert nullalternativet.
For AI-løsninger betyr dette typisk:

**Alternativ 0: Nullalternativet (ingen endring)**
- Beskrivelse: Dagens løsning beholdes
- Estimert årskostnad: [X] NOK
- Fordeler: Ingen endringskostnad, ingen risiko
- Ulemper: Problemet vedvarer, [konsekvenser]

**Alternativ 1: [Ikke-AI-løsning]**
- Beskrivelse: [F.eks. prosessforbedring, BPM, tradisjonell automatisering]
- Estimert årskostnad: [X] NOK
- Fordeler: Lavere teknisk risiko, [andre]
- Ulemper: [Begrensninger]

**Alternativ 2: [AI-løsning A — enklere]**
- Beskrivelse: [F.eks. M365 Copilot + standard connectors]
- Plattform: [Microsoft-plattform]
- Estimert årskostnad: [X] NOK
- Fordeler: Raskere time-to-value, [andre]
- Ulemper: Begrenset tilpasning, [andre]

**Alternativ 3: [AI-løsning B — mer avansert]**
- Beskrivelse: [F.eks. Azure AI Foundry med custom RAG]
- Plattform: [Microsoft-plattform]
- Estimert årskostnad: [X] NOK
- Fordeler: Full kontroll, skalerbarhet, [andre]
- Ulemper: Høyere kompleksitet, krever utviklerkompetanse, [andre]

Tips: Bruk /architect:compare for å sammenligne AI-alternativene. Referanse: decision-trees.md inneholder beslutningstrær for plattformvalg. Referanse: architecture/alternativanalyse-methodology.md — Vektet multi-kriterie-analyse (MCA) med 1-5 scoringsskala, sensitivitetsanalyse og sjekkliste for lik dybde (utredningsinstruksen §2-2).

2.3 Hvilke prinsipielle spørsmål reiser tiltakene?

### 2.3 Prinsipielle spørsmål

Vurder om tiltakene reiser spørsmål knyttet til:

**Forvaltningsrettslige prinsipper:**
- [ ] Forklarbarhet — Kan AI-beslutninger begrunnes iht. forvaltningsloven?
- [ ] Likebehandling — Er det risiko for at AI behandler like saker ulikt?
- [ ] Kontradiksjon — Kan parter forstå og utfordre AI-baserte vurderinger?
- [ ] Dokumentasjon — Kan AI-prosessen journalføres iht. arkivlova?

**Etiske prinsipper:**
- [ ] Autonomi — Påvirker AI innbyggernes evne til å ta informerte valg?
- [ ] Transparens — Vet brukerne at de interagerer med AI?
- [ ] Rettferdighet — Er modellens treningsdata representative?
- [ ] Personvern — Behandles personopplysninger ut over formålet?

**Organisatoriske spørsmål:**
- [ ] Kompetanse — Har virksomheten nødvendig AI-kompetanse?
- [ ] Avhengighet — Skapes uønsket leverandøravhengighet?
- [ ] Demokratisk kontroll — Opprettholdes politisk styring av vesentlige avgjørelser?

**Teknologiske spørsmål:**
- [ ] Modenhet — Er teknologien tilstrekkelig moden for formålet?
- [ ] Reversibilitet — Kan man gå tilbake til manuell prosess ved behov?
- [ ] Interoperabilitet — Følger løsningen åpne standarder?

2.4 Hva er de positive og negative virkningene?

### 2.4 Virkningsanalyse

**Anbefalt alternativ:** [X]

#### Positive virkninger

| Virkning | Type | Berørte | Kvantifisering |
|----------|------|---------|----------------|
| Raskere saksbehandling | Effektivitet | Innbyggere, saksbehandlere | [X] dager spart |
| Redusert arbeidsmengde | Økonomi | Saksbehandlere | [X] årsverk frigjort |
| Bedre tilgjengelighet | Tjenestekvalitet | Innbyggere | 24/7 tilgang |
| [Virkning 4] | [Type] | [Hvem] | [Mål] |

#### Negative virkninger

| Virkning | Type | Berørte | Avbøtende tiltak |
|----------|------|---------|------------------|
| Feilrisiko ved AI | Kvalitet | Innbyggere | HITL, kvalitetskontroll |
| Personvernrisiko | Juss | Innbyggere | DPIA, dataminimering |
| Kompetansebehov | Organisasjon | IT-avdeling | Opplæring, kompetanseplan |
| Implementeringskostnad | Økonomi | Virksomheten | Fasevis utrulling |
| [Virkning 5] | [Type] | [Hvem] | [Tiltak] |

#### Ikke-prissatte virkninger

Noen virkninger kan ikke kvantifiseres i kroner, men er likevel vesentlige:
- [F.eks. økt tillit til offentlige tjenester]
- [F.eks. innovasjonseffekt i organisasjonen]
- [F.eks. forbedret medarbeidertilfredshet]

2.5 Hvilket tiltak anbefales, og hvorfor?

### 2.5 Anbefaling

**Anbefalt alternativ:** [Alternativ X: Navn]

**Begrunnelse:**
[Sammenhengende tekst som forklarer hvorfor dette alternativet er best.
Referer til virkningsanalysen, kostnadsvurderingen og prinsipielle spørsmål.]

**Sammenstilling:**

| Kriterie | Alt 0 | Alt 1 | Alt 2 | Alt 3 |
|----------|-------|-------|-------|-------|
| Løser problemet | ❌ | 🟡 | ✅ | ✅ |
| Kostnad (årlig) | [X] | [X] | [X] | [X] |
| Gjennomførbarhet | ✅ | ✅ | ✅ | 🟡 |
| Regulatorisk risiko | ✅ | ✅ | 🟡 | 🟡 |
| Skalerbarhet | ❌ | 🟡 | 🟡 | ✅ |
| Time-to-value | N/A | [X mnd] | [X mnd] | [X mnd] |
| **Totalvurdering** | ❌ | 🟡 | ✅ | 🟡 |

2.6 Hva er forutsetningene for vellykket gjennomføring?

### 2.6 Forutsetninger

**Kritiske forutsetninger (blokkerende):**
1. [F.eks. M365 E5-lisenser er tilgjengelig]
2. [F.eks. Data i SharePoint er strukturert og klassifisert]
3. [F.eks. DPIA er gjennomført og godkjent]
4. [F.eks. Tilstrekkelig Azure-budsjett er bevilget]

**Viktige forutsetninger (bør oppfylles):**
1. [F.eks. Prosjekteier med mandat er utpekt]
2. [F.eks. Kompetanseplan for driftsteam er på plass]
3. [F.eks. Superbrukere er identifisert og motivert]

**Forutsetninger for oppfølging:**
- Evaluering etter [X] måneder med definerte KPI-er
- Gevinstrealiseringsplan er forankret i ledelsen
- Endringsledelse er integrert i prosjektplanen

---

SEKSJON 3: Digdirs 7 arkitekturprinsipper

Kilde: Overordnede arkitekturprinsipper for digitalisering av offentlig sektor Obligatorisk: Ja, følg-eller-forklar for alle statlige IT-løsninger.

Alle statlige digitaliseringstiltak skal vurderes opp mot disse prinsippene. Ved avvik kreves eksplisitt begrunnelse (følg-eller-forklar).

Etterlevelsesmatrise

### 3. Arkitekturprinsipper — Etterlevelse

| # | Prinsipp | Status | Begrunnelse / Avvik |
|---|----------|--------|---------------------|
| 1 | Brukeren i satisfying | 🟢 Følger / 🟡 Delvis / 🔴 Avviker | [Begrunnelse] |
| 2 | Offentlige data skal deles | 🟢/🟡/🔴 | [Begrunnelse] |
| 3 | Løsninger skal samhandle | 🟢/🟡/🔴 | [Begrunnelse] |
| 4 | Sørge for tillit | 🟢/🟡/🔴 | [Begrunnelse] |
| 5 | Prosesser skal digitaliseres | 🟢/🟡/🔴 | [Begrunnelse] |
| 6 | Bruke fellesløsninger | 🟢/🟡/🔴 | [Begrunnelse] |
| 7 | Dele og gjenbruke løsninger | 🟢/🟡/🔴 | [Begrunnelse] |

Veiledning per prinsipp

Prinsipp 1: Brukeren i sentrum

• Er AI-løsningen designet ut fra brukerens behov?
• Er det gjennomført brukerinnsikt (intervjuer, tjenestereiser)?
• Har løsningen universell utforming (WCAG 2.1 AA)?
• AI-spesifikt: Er det tydelig for brukeren at de interagerer med AI?

Prinsipp 2: Offentlige data skal deles

• Genererer AI-løsningen data som kan være nyttig for andre virksomheter?
• Publiseres anonymiserte AI-ytelsesdata via data.norge.no?
• Deles erfaringer med andre virksomheter (f.eks. via Digdirs AI-nettverk)?
• AI-spesifikt: Er eventuelle fine-tunede modeller eller prompt-mønstre delbare?

Prinsipp 3: Løsninger skal samhandle

• Bruker løsningen åpne standarder og API-er?
• Kan den integreres med andre offentlige systemer (Altinn, Maskinporten, etc.)?
• Er dataformater basert på kjente standarder?
• AI-spesifikt: Er det mulig å bytte AI-modell eller -plattform uten å bygge om hele løsningen?

Prinsipp 4: Sørge for tillit

• Er personvern, informasjonssikkerhet og arkiv ivaretatt?
• Er det tydelig sporbarhet i AI-beslutninger?
• Er det gjennomført risikovurdering?
• AI-spesifikt: Er det etablert prosesser for å oppdage og korrigere AI-feil?

Prinsipp 5: Prosesser skal digitaliseres

• Automatiserer AI-løsningen en hel prosess, eller bare deler?
• Er det identifisert manuelle steg som bør digitaliseres?
• AI-spesifikt: Reduserer AI behovet for manuelle mellomsteg?

Prinsipp 6: Bruke fellesløsninger

• Brukes Digdirs fellesløsninger der det er relevant (ID-porten, Altinn, Maskinporten)?
• Er det vurdert om eksisterende fellesløsninger dekker behovet?
• AI-spesifikt: Er det offentlige AI-fellesløsninger (f.eks. Felles datakatalog, Altinn AI) som kan gjenbrukes?

Prinsipp 7: Dele og gjenbruke løsninger

• Kan løsningen gjenbrukes av andre virksomheter?
• Er arkitektur, kode og erfaringer dokumentert for deling?
• AI-spesifikt: Er prompt-templates, RAG-mønstre eller evalueringsdata delbare som open source?

---

SEKSJON 4: AI-spesifikk vurdering

Formål: Dekke AI-spesifikke aspekter som ikke fanges av tradisjonelle utredningsrammeverk.

4.1 AI Act — Risikoklassifisering og compliance

Referanse: responsible-ai/ai-act-compliance-guide.md Referanse: responsible-ai/ai-act-annex-iii-checklist.md — Systematisk Annex III-sjekkliste med 8 kategorier, 30 underpunkter, beslutningstre og grensevurdering beslutningsstøtte vs. automatisert vedtak

### 4.1 AI Act klassifisering

**Risikoklasse:** [Minimal / Begrenset / Høy / Uakseptabel]

**Klassifiseringsbegrunnelse:**

| Vurderingspunkt | Svar | Kommentar |
|-----------------|------|-----------|
| Er systemet listet i Annex III (høyrisiko)? | Ja/Nei | [Detaljer] |
| Brukes systemet til beslutninger som påvirker rettigheter? | Ja/Nei | [Detaljer] |
| Er systemet en safety component? | Ja/Nei | [Detaljer] |
| Genererer systemet innhold som kan oppfattes som menneskeskapt? | Ja/Nei | [Detaljer] |
| Brukes biometrisk identifikasjon? | Ja/Nei | [Detaljer] |

**Ved høyrisiko — krav som må oppfylles:**

| AI Act-krav | Status | Tiltak |
|-------------|--------|--------|
| Risikovurderingssystem (Art. 9) | ⬜ Planlagt / ✅ Oppfylt / ❌ Mangler | [Detaljer] |
| Datakvalitet og datastyring (Art. 10) | ⬜/✅/❌ | [Detaljer] |
| Teknisk dokumentasjon (Art. 11) | ⬜/✅/❌ | [Detaljer] |
| Logging og sporbarhet (Art. 12) | ⬜/✅/❌ | [Detaljer] |
| Transparens og informasjon (Art. 13) | ⬜/✅/❌ | [Detaljer] |
| Menneskelig tilsyn (Art. 14) | ⬜/✅/❌ | [Detaljer] |
| Nøyaktighet og robusthet (Art. 15) | ⬜/✅/❌ | [Detaljer] |

**Ved begrenset risiko — transparenskrav:**
- [ ] Brukere informeres om at de interagerer med AI
- [ ] AI-generert innhold er merket
- [ ] Deepfake-innhold er tydelig merket (hvis relevant)

4.2 Modellstrategi

Referanse: cost-optimization/model-selection-price-performance.md Referanse: norwegian-public-sector-governance/norwegian-nlp-benchmarks.md — Norske NLP-benchmarks (NorBench, NorEval, ScandEval, MTEB), embedding-sammenligning, chunking for norsk morfologi

### 4.2 Modellstrategi

**Valgt modellstrategi:** [Enkeltmodell / Multi-modell / Fine-tuned]

| Oppgave | Modell | Begrunnelse | Fallback |
|---------|--------|-------------|----------|
| [Hovedoppgave] | [F.eks. GPT-4o] | [Nødvendig resonneringsevne] | [GPT-4o-mini] |
| [Enklere oppgave] | [F.eks. GPT-4o-mini] | [Kostnadseffektiv for enkel klassifisering] | [—] |
| [Embedding] | [F.eks. text-embedding-3-large] | [Best for norsk tekst i denne konteksten] | [text-embedding-3-small] |

**Modellvurderinger:**

| Aspekt | Vurdering |
|--------|-----------|
| Norsk språkstøtte | [Evaluert? Hvordan?] |
| Datalokalitet | [Hvor prosesseres data? Hvilken region?] |
| SLA/oppetid | [Krav vs. tilgjengelig garantier] |
| Versjonshåndtering | [Strategi for modelloppdateringer] |
| Kostnad per request | [Estimert basert på bruksmønster] |

4.3 Data og RAG-strategi

Referanse: rag-architecture/*.md

### 4.3 Data og RAG

**Datastrategi:** [Ingen egne data / RAG / Fine-tuning / Hybrid]

**Datakilder:**

| Kilde | Type | Volum | Klassifisering | Oppdateringsfrekvens |
|-------|------|-------|----------------|----------------------|
| [Kilde 1] | [SharePoint/API/DB] | [Ca. størrelse] | [Åpen/Intern/Begrenset] | [Daglig/Ukentlig/Ad hoc] |
| [Kilde 2] | [Type] | [Ca. størrelse] | [Klassifisering] | [Frekvens] |

**RAG-arkitektur (hvis relevant):**

| Komponent | Valg | Begrunnelse |
|-----------|------|-------------|
| Indekseringstjeneste | [Azure AI Search / annet] | [Detaljer] |
| Chunking-strategi | [Fast størrelse / Semantisk / Hybrid] | [Detaljer] |
| Embedding-modell | [Modellnavn] | [Detaljer] |
| Retrieval-metode | [Vektor / Hybrid / Semantisk reranking] | [Detaljer] |
| Grounding | [Datakilde-tilkobling] | [Detaljer] |

**Datakvalitetsvurdering:**
- [ ] Data er representativ for målgruppen
- [ ] Personopplysninger er identifisert og håndtert
- [ ] Datakvalitet er målt (komplett, korrekt, aktuell)
- [ ] Data er tilgjengelig i maskinlesbart format
- [ ] Oppdateringsrutiner er definert

4.4 Prompt og sikkerhetsstrategi

### 4.4 Prompt og sikkerhet

**System prompt-strategi:**
- [ ] System-instruksjoner definerer rolle, begrensninger og tone
- [ ] Grounding-instruksjoner sikrer at svar er basert på data
- [ ] Output-formatering er spesifisert

**Sikkerhetsmekanismer:**

| Mekanisme | Status | Detaljer |
|-----------|--------|----------|
| Content Safety-filter | ⬜/✅ | [Azure AI Content Safety konfigurering] |
| Input-validering | ⬜/✅ | [Prompt injection-beskyttelse] |
| Output-validering | ⬜/✅ | [Hallusinasjonskontroll, faktagrounding] |
| PII-deteksjon | ⬜/✅ | [Azure AI Content Safety PII / Presidio] |
| Metaprompt-beskyttelse | ⬜/✅ | [Hindre utlevering av systeminstruksjoner] |
| Rate limiting | ⬜/✅ | [Misbrukshindring] |

4.5 Bias og rettferdighet

Referanse: responsible-ai/bias-*.md

### 4.5 Bias og rettferdighet

**Identifiserte biasrisikoer:**

| Risikotype | Risiko | Vurdering | Tiltak |
|------------|--------|-----------|--------|
| Datarepresentasjon | [F.eks. Treningsdata underrepresenterer samisk] | 🟢/🟡/🔴 | [Tiltak] |
| Algoritmisk bias | [F.eks. Modellen kan gi ulike svar basert på dialekt] | 🟢/🟡/🔴 | [Tiltak] |
| Interaksjonsbias | [F.eks. Brukergrensesnitt favoriserer digitalt kompetente] | 🟢/🟡/🔴 | [Tiltak] |
| Feedback-loop | [F.eks. Feilaktige AI-svar forsterkes over tid] | 🟢/🟡/🔴 | [Tiltak] |

**Evalueringsplan:**
- [ ] Definert metrikker for rettferdighet (demographic parity, equalized odds, etc.)
- [ ] Testscenarioer for underrepresenterte grupper
- [ ] Periodisk reevaluering planlagt
- [ ] Klageprosess for brukere som opplever urettferdig behandling

4.6 Forklarbarhet

Referanse: responsible-ai/model-explainability-*.md

### 4.6 Forklarbarhet

**Krav til forklarbarhet:**

| Kontekst | Krav | Løsning |
|----------|------|---------|
| Forvaltningsloven (begrunnelsesplikt) | Vedtak må begrunnes | [Detaljer] |
| AI Act (Art. 13, transparens) | Bruker skal forstå systemet | [Detaljer] |
| Intern kontroll | Driftsansvarlige må forstå feil | [Detaljer] |
| Klagesaksbehandling | Klageinstans trenger innsikt | [Detaljer] |

**Forklarbarhetsmekanismer:**

| Mekanisme | Implementert | Detaljer |
|-----------|-------------|----------|
| Kildehenvisninger (citations) | ⬜/✅ | [RAG-baserte referanser til kildedokumenter] |
| Konfidensscoring | ⬜/✅ | [Usikkerhetsnivå per svar] |
| Reasoning traces / Chain-of-thought | ⬜/✅ | [Synlig resonnering for saksbehandlere] |
| Beslutningslogg | ⬜/✅ | [Logging av input/output/begrunnelse] |
| Kontrafaktisk forklaring | ⬜/✅ | ["Hadde du oppgitt X, ville svaret vært Y"] |

4.7 Human-in-the-Loop (HITL)

Referanse: responsible-ai/human-in-the-loop-*.md

### 4.7 Human-in-the-Loop (HITL)

**HITL-mønster:** [Full autonomi / Forslag-og-godkjenn / Menneske-i-sløyfen / Kun menneskelig]

**HITL-design:**

| AI-handling | HITL-nivå | Begrunnelse |
|-------------|-----------|-------------|
| [F.eks. Klassifisere henvendelse] | Automatisk | [Lav konsekvens, høy nøyaktighet] |
| [F.eks. Foreslå svar til innbygger] | Forslag → saksbehandler godkjenner | [Moderat konsekvens] |
| [F.eks. Fatte vedtak] | Kun menneskelig | [Juridisk krav, forvaltningsloven] |

**Eskaleringspolicy:**

| Trigger | Handling |
|---------|----------|
| AI-konfidens < [X]% | Eskalér til saksbehandler |
| Bruker ber om menneske | Overfør umiddelbart |
| Sensitive emner detektert | Eskalér automatisk |
| Ukjent emne (out of scope) | Informér bruker, eskalér |

**Overstyringsmekanisme:**
- [ ] Saksbehandler kan alltid overstyre AI-forslag
- [ ] Overstyringer logges og brukes til forbedring
- [ ] Eskaleringsveier er dokumentert og testet

4.8 MLOps og livssyklus

### 4.8 MLOps og livssyklus

**Driftsmodell:** [Managed service / Custom pipeline / Hybrid]

| Aspekt | Plan |
|--------|------|
| Modelloppdateringer | [Automatisk / Manuelt / Styrt utrulling] |
| Ytelsesovervåking | [Metrikker, terskler, varsling] |
| Datadrift-deteksjon | [Hvordan oppdages det at data endrer seg?] |
| A/B-testing | [Strategi for å teste nye modellversjoner] |
| Rollback-plan | [Hvordan rulle tilbake ved feil] |
| Evalueringskadence | [Daglig/Ukentlig/Månedlig ytelsesrapport] |

**Ansvarsmatrise (MLOps):**

| Rolle | Ansvar |
|-------|--------|
| AI-ansvarlig | Overordnet ansvar for AI-systemet |
| Dataeier | Kvalitet og tilgjengelighet for trenings-/RAG-data |
| Modellansvarlig | Ytelse, oppdateringer, evaluering |
| Driftsansvarlig | Oppetid, overvåking, hendelseshåndtering |
| Personvernombud | DPIA, løpende vurdering |

---

SEKSJON 5: Sikkerhet og personvern

Formål: Samle alle sikkerhets- og personvernvurderinger. Referanse: security.md, public-sector-checklist.md Kommando: /architect:security

5.1 Sikkerhetsvurdering (6 dimensjoner)

### 5.1 Sikkerhet

Bruk `/architect:security` for å generere denne seksjonen.

| Dimensjon | Score (1-5) | Status | Viktigste funn |
|-----------|-------------|--------|----------------|
| Identity & Access | /5 | 🟢/🟡/🔴 | [Detaljer] |
| Network Security | /5 | 🟢/🟡/🔴 | [Detaljer] |
| Data Protection | /5 | 🟢/🟡/🔴 | [Detaljer] |
| Content Safety | /5 | 🟢/🟡/🔴 | [Detaljer] |
| Compliance & Governance | /5 | 🟢/🟡/🔴 | [Detaljer] |
| Monitoring & Response | /5 | 🟢/🟡/🔴 | [Detaljer] |

**Overordnet sikkerhetsvurdering:** [Akseptabel / Betinget akseptabel / Ikke akseptabel]

5.2 Personvernkonsekvensvurdering (DPIA)

### 5.2 DPIA-status

| Spørsmål | Svar |
|----------|------|
| Behandles personopplysninger? | Ja/Nei |
| Er DPIA påkrevd? | Ja/Nei/Under vurdering |
| Er DPIA gjennomført? | ✅ Godkjent / 🔄 Pågår / ⬜ Ikke startet |
| Personvernombud involvert? | Ja/Nei |
| Konsultasjon med Datatilsynet nødvendig? | Ja/Nei |

**Personvernrisikoer identifisert:**
| Risiko | Sannsynlighet | Konsekvens | Tiltak | Restrisiko |
|--------|---------------|------------|--------|------------|
| [Risiko 1] | [H/M/L] | [H/M/L] | [Tiltak] | [H/M/L] |

Referanse: Se public-sector-checklist.md for komplett DPIA-veiledning.

5.3 ROS-analyse

### 5.3 ROS-analyse

| # | Risiko | S | K | Risikonivå | Tiltak | Restrisiko |
|---|--------|---|---|------------|--------|------------|
| 1 | [Risikobeskrivelse] | [1-5] | [1-5] | [S×K] | [Tiltak] | [Nytt nivå] |
| 2 | [Risikobeskrivelse] | [1-5] | [1-5] | [S×K] | [Tiltak] | [Nytt nivå] |

S = Sannsynlighet, K = Konsekvens

**Risikoakseptkriterier:** [Definer hva virksomheten aksepterer]

**AI-spesifikke risikoer å vurdere:**
- Hallusinasjon/feilinformasjon fra modell
- Prompt injection / jailbreaking
- Datalekkasje via modellresponser
- Modell-degradering over tid (concept drift)
- Utilgjengelighet av underliggende AI-tjeneste
- Uforklarlige eller inkonsistente svar

5.4 Dataklassifisering

### 5.4 Dataklassifisering

| Datatype | Klassifisering | Behandlingsgrunnlag | Lagringssted |
|----------|----------------|---------------------|--------------|
| [Brukerhenvendelser] | [Intern] | [Berettiget interesse] | [Azure Sweden Central] |
| [Saksdata] | [Begrenset] | [Lovhjemmel] | [On-prem/Azure] |
| [AI-logger] | [Intern] | [Berettiget interesse] | [Azure Sweden Central] |
| [Anonymisert statistikk] | [Åpen] | [Åpne data] | [Data.norge.no] |

---

SEKSJON 6: Kostnadsvurdering

Formål: Gi fullstendig kostnadsgrunnlag for beslutning. Referanse: cost-models.md Referanse: cost-optimization/deterministic-cost-calculation-model.md — Enhetspriser med datostempel, eksplisitte beregningsformler, P10/P50/P90 konfidensintervaller Kommando: /architect:cost

## 6. Kostnadsvurdering

### 6.1 TCO per alternativ (3 år)

Bruk `/architect:cost` for å generere detaljerte estimater.

| Kostnadspost | Alt 0 (nullalt.) | Alt 1 | Alt 2 | Alt 3 |
|-------------|------------------|-------|-------|-------|
| **Etablering** | | | | |
| Prosjektkostnader | 0 | [X] | [X] | [X] |
| Utvikling/konfig. | 0 | [X] | [X] | [X] |
| Opplæring | 0 | [X] | [X] | [X] |
| **Årlig drift** | | | | |
| Lisenser | [X] | [X] | [X] | [X] |
| AI-tjenester (tokens, API) | 0 | [X] | [X] | [X] |
| Infrastruktur (Azure) | [X] | [X] | [X] | [X] |
| Drift/vedlikehold (FTE) | [X] | [X] | [X] | [X] |
| **3-års TCO** | **[X]** | **[X]** | **[X]** | **[X]** |

Alle beløp i NOK. Valutakurs: ~11 NOK/USD.

### 6.2 AI-spesifikke kostnadsdrivere

| Driver | Beskrivelse | Estimeringsmetode |
|--------|-------------|-------------------|
| Token-forbruk | Input + output tokens per request | [Volum × pris per 1M tokens] |
| Embedding-indeksering | Re-indeksering av RAG-data | [Volum × frekvens × pris] |
| Modellvalg | Forskjell mellom GPT-4o og GPT-4o-mini | [Se 4.2 modellstrategi] |
| Skalering | Vekst i brukere/volum over tid | [Vekstfaktor per år] |
| Content Safety | Azure AI Content Safety API-kall | [Per request-kostnad] |

### 6.3 Skjulte kostnader

| Kostnad | Estimat | Ofte oversett fordi |
|---------|---------|---------------------|
| Kompetanseoppbygging | [X] NOK | Undervurdert for AI-prosjekter |
| Prompt-engineering iterasjoner | [X] timer | Krever testing og finjustering |
| Datakuratering | [X] timer | RAG-kvalitet krever godt kuraterte data |
| Evaluering og testing | [X] NOK | Både teknisk og brukertest |
| Endringsledelse | [X] NOK | Organisatorisk adopsjon |
| Compliance-arbeid | [X] NOK | DPIA, AI Act, ROS |

### 6.4 Gevinstrealisering

| Gevinst | Type | Estimat (årlig) | Når realiseres | Eier |
|---------|------|-----------------|----------------|------|
| [Gevinst 1] | Effektivisering | [X] NOK | [Fra måned X] | [Rolle] |
| [Gevinst 2] | Kvalitetsøkning | Kvalitativ | [Fra måned X] | [Rolle] |
| [Gevinst 3] | Brukeropplevelse | Kvalitativ | [Fra måned X] | [Rolle] |

**Netto nåverdi (NNV) over 3 år:** [X] NOK (diskonteringsrente: 4%)
**Tilbakebetalingstid:** [X] måneder

Referanse: norwegian-public-sector-governance/gevinstrealisering-dfo-methodology.md — DFOs 5-stegs modell, gevinstregister-mal, KPI-er, RACI for gevinstansvarlig Referanse: norwegian-public-sector-governance/samfunnsokonomisk-analyse-nnv.md — NNV-beregning med 4% diskonteringsrente, sensitivitetsanalyse, fordelingsvirkninger (skaleres etter kompleksitet)

---

SEKSJON 7: Digital samhandling (5 lag)

Kilde: Rammeverk for digital samhandling (basert på European Interoperability Framework) Obligatorisk: Ja, for offentlige digitale tjenester.

Rammeverket har fem samhandlingslag. Alle skal vurderes for AI-løsninger som inngår i offentlige tjenester.

## 7. Digital samhandling

### 7.1 Juridisk samhandling

| Vurderingspunkt | Status | Detaljer |
|-----------------|--------|----------|
| Er det hjemmel for automatisert behandling? | ✅/⚠️/❌ | [Hjemmelsgrunnlag] |
| Er databehandleravtale på plass med Microsoft? | ✅/⚠️/❌ | [Avtaledetaljer] |
| Er det avklart hvem som er behandlingsansvarlig? | ✅/⚠️/❌ | [Detaljer] |
| Er AI-beslutninger juridisk bindende? | ✅/⚠️/❌ | [Avklaring] |
| Er klagerett ivaretatt? | ✅/⚠️/❌ | [Prosess] |

### 7.2 Organisatorisk samhandling

| Vurderingspunkt | Status | Detaljer |
|-----------------|--------|----------|
| Er roller og ansvar dokumentert? | ✅/⚠️/❌ | [Se RACI-matrise] |
| Er samarbeid med andre virksomheter kartlagt? | ✅/⚠️/❌ | [Detaljer] |
| Er endringsledelse planlagt? | ✅/⚠️/❌ | [Plan] |
| Er det etablert felles forståelse av prosessene? | ✅/⚠️/❌ | [Detaljer] |

### 7.3 Semantisk samhandling

| Vurderingspunkt | Status | Detaljer |
|-----------------|--------|----------|
| Brukes felles begrepsdefinisjoner? | ✅/⚠️/❌ | [Begrepskatalog] |
| Er datamodeller basert på åpne standarder? | ✅/⚠️/❌ | [Standarder brukt] |
| Er AI-output strukturert og maskinlesbart? | ✅/⚠️/❌ | [Format/standard] |
| Er det mappet mot DCAT/SKOS der relevant? | ✅/⚠️/❌ | [Detaljer] |

### 7.4 Teknisk samhandling

| Vurderingspunkt | Status | Detaljer |
|-----------------|--------|----------|
| Brukes åpne API-standarder? | ✅/⚠️/❌ | [REST/GraphQL/gRPC] |
| Er autentisering via Maskinporten/ID-porten? | ✅/⚠️/❌ | [Detaljer] |
| Støttes standard meldingsformater? | ✅/⚠️/❌ | [JSON/XML/etc.] |
| Er det SLA-krav til AI-tjenesten? | ✅/⚠️/❌ | [Oppetidskrav] |
| Er det failover/fallback-mekanismer? | ✅/⚠️/❌ | [Strategi] |

### 7.5 Styring av samhandling

| Vurderingspunkt | Status | Detaljer |
|-----------------|--------|----------|
| Er det styringsmodell for AI-systemet? | ✅/⚠️/❌ | [Modell] |
| Er KPI-er definert for samhandling? | ✅/⚠️/❌ | [Metrikker] |
| Er det etablert evalueringsrutiner? | ✅/⚠️/❌ | [Kadence] |
| Er det arena for erfaringsdeling? | ✅/⚠️/❌ | [Forum/nettverk] |

---

SEKSJON 8: Microsoft-plattformvalg

Formål: Dokumentere den teknologiske arkitekturbeslutningen. Referanse: decision-trees.md, licensing-matrix.md Kommandoer: /architect:compare, /architect:license, /architect:adr

## 8. Microsoft-plattformvalg

### 8.1 Plattformbeslutning

Bruk `/architect:compare` for strukturert sammenligning.

**Valgt plattform:** [F.eks. Copilot Studio + Azure AI Search]

**Begrunnelse:**
[Kort begrunnelse som refererer til decision tree og alternativvurdering i S2]

**Nøkkelkomponenter:**

| Komponent | Tjeneste | Rolle i arkitekturen |
|-----------|----------|----------------------|
| AI-modell | [F.eks. GPT-4o via Azure OpenAI] | Hovedresonneringsmodell |
| Orkestrering | [F.eks. Copilot Studio] | Brukergrensesnitt og agentlogikk |
| Søk/RAG | [F.eks. Azure AI Search] | Kunnskapsbase-søk |
| Sikkerhet | [F.eks. Entra ID + Content Safety] | Autentisering og innholdsfilter |
| Overvåking | [F.eks. Application Insights] | Ytelse og feilsporing |

### 8.2 Arkitekturoversikt

[Generer arkitekturdiagram med `/architect:diagram architecture for [scenario]`]

**Diagramgenerering:**
Bruk `diagram-generation-agent` til å generere et profesjonelt arkitekturdiagram basert på
komponentene i S8.1. Agenten bruker Imagen 3 via `mcp__mcp-image__generate_image`.

Ytterligere diagrammer basert på kompleksitet:
- **Middels+:** Sikkerhetssoner (S5.1), Problem/løsning (S2.1), Implementeringstidslinje (S9.1)
- **Med RAG:** Dataflyt/RAG-pipeline (S4.3)

Fallback: Mermaid-syntaks kan brukes som alternativ:

```mermaid
graph TB
    User[Bruker] --> CS[Copilot Studio]
    CS --> AOAI[Azure OpenAI]
    CS --> Search[Azure AI Search]
    Search --> Data[Datakilde]
    CS --> Safety[Content Safety]
    AOAI --> Safety
    CS --> EntraID[Entra ID]

8.3 Architecture Decision Records

Bruk /architect:adr for å generere disse.

ADR #	Tittel	Status	Dato
ADR-001	[F.eks. Valg av Copilot Studio over Azure AI Foundry]	Accepted	YYYY-MM-DD
ADR-002	[F.eks. Hybrid RAG-strategi med Azure AI Search]	Draft	YYYY-MM-DD

> Referanse: `adr-template.md` for komplett MADR v3.0-format.

### 8.4 Lisensbehov

```markdown
### 8.4 Lisensbehov

Bruk `/architect:license` for detaljert kartlegging.

| Lisens | Påkrevd | Allerede tilgjengelig | Kostnad (NOK/bruker/mnd) | Antall |
|--------|---------|------------------------|--------------------------|--------|
| [M365 E5] | ✅ | ✅/❌ | [X] | [X] |
| [Copilot Studio] | ✅ | ✅/❌ | [X] | [X] |
| [Azure-abonnement] | ✅ | ✅/❌ | [Forbruk] | 1 |

---

SEKSJON 9: Implementeringsplan

Formål: Vise en realistisk vei fra beslutning til produksjon. Referanse: poc-template.md, migration-patterns.md Referanse: architecture/capacity-feasibility-benchmarks.md — Kompetanse-gap-matrise, tidsplan-validering mot bransjereferanser, buffer-vurdering (min 20%), MVP-avgrensning Kommando: /architect:poc

## 9. Implementeringsplan

### 9.1 Faseplan

**Fase 0: Forberedelse** (før POC)
- [ ] Beslutning om å gå videre er fattet
- [ ] Prosjekteier og -team er utpekt
- [ ] Nødvendige lisenser og tilganger er bestilt
- [ ] DPIA er igangsatt
- [ ] Testdata er identifisert og klassifisert

**Fase 1: POC** (bruk `/architect:poc` for detaljert plan)
- [ ] POC-plan med suksesskriterier er godkjent
- [ ] Teknisk miljø er satt opp
- [ ] Kjernefunksjonalitet er demonstrert
- [ ] Go/No-Go-beslutning er tatt

**Fase 2: MVP**
- [ ] Scope for MVP er definert (subset av fullskala)
- [ ] Sikkerhetskrav er implementert
- [ ] Brukertesting med pilotgruppe
- [ ] Evaluering mot suksesskriterier
- [ ] Compliance-sjekkpunkter er gjennomført (AI Act, DPIA)

**Fase 3: Produksjon**
- [ ] Full utrulling til målgruppe
- [ ] Driftsdokumentasjon og runbook er på plass
- [ ] Overvåking og varsling er konfigurert
- [ ] Support- og eskaleringsprosesser er etablert
- [ ] Gevinstrealisering igangsatt

**Fase 4: Optimalisering** (løpende)
- [ ] Ytelsesmetrikker evalueres regelmessig
- [ ] Modell- og prompt-forbedringer basert på data
- [ ] Bruker-feedback integreres
- [ ] Skaleringsplan ved økt volum

### 9.2 Milepæler

| Milepæl | Leveranse | Ansvarlig | Avhengigheter |
|---------|-----------|-----------|---------------|
| M1: POC start | Prosjektplan, miljø klart | [Rolle] | Budsjett godkjent |
| M2: POC Go/No-Go | POC-rapport, anbefaling | [Rolle] | POC gjennomført |
| M3: MVP klar | Fungerende MVP med pilotbrukere | [Rolle] | Go fra M2 |
| M4: Produksjon | Full utrulling | [Rolle] | Alle compliance-krav oppfylt |
| M5: Evaluering | 3-måneders evalueringsrapport | [Rolle] | Produksjonsdata tilgjengelig |

### 9.3 Endringsledelse

| Aktivitet | Målgruppe | Tidspunkt |
|-----------|-----------|-----------|
| Informasjonsmøte | Alle berørte | Før POC |
| Opplæring (superbrukere) | Pilotgruppe | Under POC |
| Opplæring (alle) | Sluttbrukere | Før MVP-utrulling |
| Erfaringssamling | Pilotgruppe | Etter POC |
| Kommunikasjonsplan | Organisasjonen | Løpende |

---

SEKSJON 10: Vedlegg

## 10. Vedlegg

### Vedlegg A: DPIA (personvernkonsekvensvurdering)
[Referanse til fullstendig DPIA-dokument]

### Vedlegg B: ROS-analyse
[Referanse til fullstendig ROS-analyse]

### Vedlegg C: Architecture Decision Records
[Referanse til ADR-dokumenter, generert med /architect:adr]

### Vedlegg D: POC-rapport
[Referanse til POC-rapport fra fase 1, generert med /architect:poc]

### Vedlegg E: Kostnadsestimater (detaljert)
[Referanse til detaljert kostnadsanalyse, generert med /architect:cost]

### Vedlegg F: Leverandørvurdering
[Eventuell anskaffelsesvurdering]

### Vedlegg G: Antakelsesregister
[Formelt register over alle antakelser med kildeklassifisering, konsekvensanalyse og valideringsplan]
> Referanse: `architecture/source-traceability-assumption-register.md` — Mal for antakelsesregister med 4-nivå kildeklassifisering (Verifisert/KB/Ekspert/Antakelse)

### Vedlegg H: Verifiseringslogg — Regional tilgjengelighet
[Datostemplet logg over verifisert Azure-tjenestetilgjengelighet per region]
> Referanse: `architecture/regional-availability-verification.md` — Verifiseringslogg-mal, holdbarhetsvurdering (Stabil/Volatil/Svært volatil), MCP-verifiseringsprotokoll

### Vedlegg I: Referanser

**Regelverk:**
- [Utredningsinstruksen](https://www.regjeringen.no/no/dokumenter/instruks-om-utredning-av-statlige-tiltak/id2476518/)
- [Digdirs overordnede arkitekturprinsipper](https://www.digdir.no/digitalisering-og-samordning/overordnede-arkitekturprinsipper/1065)
- [Rammeverk for digital samhandling](https://www.digdir.no/digitalisering-og-samordning/rammeverk-digital-samhandling/2148)
- [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)
- [Personopplysningsloven / GDPR](https://lovdata.no/dokument/NL/lov/2018-06-15-38)
- [Forvaltningsloven](https://lovdata.no/dokument/NL/lov/1967-02-10)
- [Arkivlova](https://lovdata.no/dokument/NL/lov/1992-12-04-126)
- [Offentleglova](https://lovdata.no/dokument/NL/lov/2006-05-19-16)

**Microsoft-dokumentasjon:**
- [Azure AI Foundry](https://learn.microsoft.com/azure/ai-studio/)
- [Copilot Studio](https://learn.microsoft.com/microsoft-copilot-studio/)
- [Microsoft 365 Copilot](https://learn.microsoft.com/copilot/microsoft-365/)
- [Azure AI Content Safety](https://learn.microsoft.com/azure/ai-services/content-safety/)
- [Microsoft Purview](https://learn.microsoft.com/purview/)
- [EU Data Boundary](https://learn.microsoft.com/privacy/eudb/eu-data-boundary-learn)

---

SEKSJON 11: Skaleringsguide

Formål: Tilpasse utredningens omfang til tiltakets kompleksitet.

Ikke alle AI-tiltak krever en fullstendig utredning. Bruk denne guiden for å bestemme hvilke seksjoner som er nødvendige.

Kompleksitetsvurdering

Faktor	Enkel (1)	Middels (2)	Kompleks (3)
Datakritikalitet	Ingen persondata, åpne data	Intern data, noen persondata	Sensitive persondata, helseoppl.
Beslutningspåvirkning	Informasjonsstøtte	Beslutningsstøtte	Automatisert beslutning
Antall brukere	< 50	50-500	> 500 eller eksternt
Integrasjoner	Standalone	1-3 integrasjoner	> 3, eller med fagsystemer
Regulatorisk risiko	Minimal AI Act-risiko	Begrenset risiko	Høyrisiko iht. AI Act
Budsjett	< 500K NOK	500K-3M NOK	> 3M NOK

Sum 6-8: Enkel | Sum 9-13: Middels | Sum 14-18: Kompleks

Påkrevde seksjoner per kompleksitetsnivå

Seksjon	Enkel	Middels	Kompleks
S0 Dokumentmetadata	✅	✅	✅
S1 Sammendrag	✅ (kort)	✅	✅ (utvidet)
S2 Utredningsinstruksen	✅ (2.1, 2.2, 2.5)	✅ (alle)	✅ (alle, utvidet)
S3 Arkitekturprinsipper	🟡 (kort sjekk)	✅	✅ (full vurdering)
S4 AI-spesifikk	✅ (4.1, 4.7)	✅ (4.1-4.4, 4.7)	✅ (alle)
S5 Sikkerhet/personvern	🟡 (kort sjekk)	✅ (5.1-5.2)	✅ (alle, med DPIA)
S6 Kostnad	✅ (enkel tabell)	✅ (TCO)	✅ (full, med NNV)
S7 Digital samhandling	❌	🟡 (kort sjekk)	✅ (full vurdering)
S8 Plattformvalg	✅ (8.1-8.2)	✅ (8.1-8.3)	✅ (alle)
S9 Implementeringsplan	✅ (forenklet)	✅	✅ (utvidet)
S10 Vedlegg	🟡	✅	✅ (komplett)

✅ = Påkrevd | 🟡 = Anbefalt/forenklet | ❌ = Valgfri

Eksempler per nivå

Enkel: AI Builder-flyt i Power Automate som klassifiserer e-post internt

• Ingen persondata, intern bruk, < 50 brukere, standalone
• Fokus: S0-S2 (kort), S4.1 (AI Act minimal), S6 (enkel kostnad), S8 (kort plattformvalg)

Middels: Copilot Studio-agent som svarer på innbyggerhenvendelser med RAG

• Intern data, beslutningsstøtte, 50-500 brukere, integrert med SharePoint
• Fokus: Alle seksjoner, men S3/S7 i forenklet form

Kompleks: Azure AI Foundry-løsning for automatisert saksbehandling

• Sensitive persondata, automatiserte vedtak, > 500 brukere, fagsystem-integrasjon
• Alle seksjoner i full dybde, inkludert DPIA, ROS, ADR-er, og full samhandlingsvurdering

---

For Cosmo Skyberg

Denne malen er ditt hovedverktøy for strukturerte utredninger. Slik bruker du den:

1. Start med S11 — Bestem kompleksitetsnivå sammen med brukeren
2. Jobb sekvensielt — Fyll ut seksjonene i rekkefølge, men tilpass dybde etter nivå
3. Deleger — Bruk spesialistagenter for S5 (security), S6 (cost), S8 (ADR/license/compare)
4. Verifiser — Bruk MCP-verktøy for dynamisk informasjon (priser, tilgjengelighet)
5. Visualiser — Generer diagrammer med diagram-generation-agent (S8.2 alltid, flere for middels+)
6. Lever — Tilby å skrive til fil når utredningen er komplett

Dialogflow

Bruker: /architect:utredning [scenario]
Cosmo: → Bestem kompleksitet (S11)
       → Kartlegg problem og behov (S2.1)
       → Identifiser alternativer (S2.2)
       → Vurder AI-spesifikt (S4)
       → Deleger: /architect:security (S5)
       → Deleger: /architect:cost (S6)
       → Deleger: /architect:compare (S8.1)
       → Sammenstill anbefaling (S2.5)
       → Generer diagrammer (S8.2, S2.1, S4.3, S5.1, S9.1)
       → Presenter komplett utredning