# AI-arkitekturutredning — Mal for norsk offentlig sektor

**Last updated:** 2026-06-24 (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
**Category:** Solution Architecture & Advisory
**Status:** Reference

---

## 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 ventet 2026 (forsinket pga. EØS-tilpasning) | ✅ 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

```markdown
# 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.

```markdown
## 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](https://www.regjeringen.no/no/dokumenter/instruks-om-utredning-av-statlige-tiltak/id2476518/) (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å?

```markdown
### 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?

```markdown
### 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. Microsoft 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?

```markdown
### 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?

```markdown
### 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?

```markdown
### 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?

```markdown
### 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](https://www.digdir.no/digitalisering-og-samordning/overordnede-arkitekturprinsipper/1065)
> **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

```markdown
### 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**

```markdown
### 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

```markdown
### 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`

```markdown
### 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

```markdown
### 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`

```markdown
### 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`

```markdown
### 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`

```markdown
### 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

```markdown
### 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)

```markdown
### 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)

```markdown
### 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

```markdown
### 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

```markdown
### 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`

```markdown
## 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](https://www.digdir.no/digitalisering-og-samordning/rammeverk-digital-samhandling/2148) (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.

```markdown
## 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`

```markdown
## 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 Microsoft 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`

```markdown
## 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

```markdown
## 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:**
- [Microsoft Foundry](https://learn.microsoft.com/azure/foundry/)
- [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:** Microsoft 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
```