# Kapasitet og gjennomførbarhetsvurdering — Benchmarks for AI-prosjekter

**Last updated:** 2026-02 (v1.0)
**Målgruppe:** Arkitekter og prosjektledere som vurderer gjennomførbarhet av AI-prosjekter i norsk offentlig sektor
**Formål:** Gi konkrete benchmarks for kompetansevurdering, tidsplanvalidering, risikovurdering og MVP-avgrensning
**Category:** Solution Architecture & Advisory
**Status:** Reference

---

## Om dette dokumentet

Gjennomførbarhet er den vanligste blinde flekken i AI-utredninger. Teknologien kan være riktig, men prosjektet feiler fordi organisasjonen mangler kompetanse, tidsplanen er urealistisk, eller scopet er for ambisiøst. Denne referansefilen gir konkrete benchmarks for å avdekke slike risikoer tidlig.

---

## 1. Kompetanse-gap-matrise

### 1.1 AI/ML-kompetansenivåer

| Nivå | Betegnelse | Beskrivelse | Kan gjøre | Kan ikke gjøre |
|------|-----------|-------------|-----------|----------------|
| **1** | Bevisst | Forstår grunnleggende AI-konsepter. Har deltatt på kurs eller workshops. | Beskrive bruksområder, stille krav, evaluere demo | Konfigurere, utvikle eller drifte AI-løsninger |
| **2** | Praktiker | Har praktisk erfaring med konfigurasjon og bruk av AI-verktøy. | Konfigurere Copilot Studio, sette opp AI Builder, skrive prompter | Utvikle custom AI-løsninger, feilsøke komplekse modellproblemer |
| **3** | Spesialist | Har dyp kompetanse innen ett eller flere AI-domener. | Designe RAG-arkitektur, finjustere modeller, implementere sikkerhet, evaluere modellytelse | Lede store AI-transformasjoner, forske på nye metoder |
| **4** | Ekspert | Bred og dyp AI-kompetanse med strategisk perspektiv. | Alt over + definere AI-strategi, mentore andre, evaluere og velge mellom komplekse arkitekturer | — |

### 1.2 Nøkkelroller og kompetansekrav per prosjekttype

| Rolle | Enkel (konfig.) | Middels (low-code + RAG) | Kompleks (custom dev) |
|-------|----------------|--------------------------|----------------------|
| **Prosjektleder** | Nivå 1 | Nivå 2 | Nivå 2-3 |
| **Løsningsarkitekt** | Nivå 2 | Nivå 3 | Nivå 3-4 |
| **Prompt engineer** | Nivå 2 | Nivå 2-3 | Nivå 3 |
| **Data engineer** | — | Nivå 2 | Nivå 3 |
| **ML engineer** | — | — | Nivå 3 |
| **Cloud architect (Azure)** | Nivå 2 | Nivå 2-3 | Nivå 3 |
| **Sikkerhetsrådgiver** | Nivå 1 | Nivå 2 | Nivå 3 |
| **Domeneekspert (fagperson)** | Nødvendig | Nødvendig | Nødvendig |

### 1.3 Gap-matrise — mal

```markdown
### Kompetanse-gap-matrise

**Prosjekt:** [Prosjektnavn]
**Prosjekttype:** [Enkel / Middels / Kompleks]
**Dato:** YYYY-MM-DD

| Rolle | Krav (nivå) | Tilgjengelig (nivå) | Gap | Strategi |
|-------|------------|--------------------|----|----------|
| Løsningsarkitekt | 3 | 2 | -1 | Ekstern rådgiver i 3 mnd |
| Prompt engineer | 2 | 1 | -1 | Intern opplæring (2 uker) |
| Data engineer | 2 | 2 | 0 | OK — ingen gap |
| Sikkerhetsrådgiver | 2 | 1 | -1 | Bruk eksisterende sikkerhetsrådgiver + AI-opplæring |
| Domeneekspert | Nødvendig | Tilgjengelig | 0 | OK — [Navn] dedikert 40% |

**Gap-oppsummering:**
- Totalt gap: [X] roller med gap
- Kritisk gap (blokkerende): [Ja/Nei — hvilke roller]
- Estimert kostnad for å tette gap: [X] NOK
- Estimert tid for å tette gap: [X] uker
```

### 1.4 Strategier for å tette kompetansegap

| Strategi | Tidshorisont | Kostnad | Egnet for | Risiko |
|----------|-------------|---------|-----------|--------|
| **Intern opplæring** | 2-8 uker | Lav (tidskostnad) | Gap på 1 nivå, mange skal læres opp | Tar tid fra prosjektet |
| **Ekstern rådgiver/konsulent** | 1-2 uker å engasjere | Middels-høy | Gap på 1-2 nivåer, kritisk rolle, kort prosjekt | Kunnskapsoverføring må planlegges |
| **Nyansettelse** | 3-6 måneder | Høy | Varig behov, strategisk kompetanse | Lang ledetid, rekrutteringsrisiko |
| **Microsoft FastTrack** | 2-4 uker | Inkludert i visse lisenser | Konfigurasjon og oppsett av Microsoft-tjenester | Begrenset til Microsoft-plattform |
| **Partner/SI** | 2-4 uker å engasjere | Høy | Komplett leveranse, mangler bred intern kompetanse | Avhengighet, høy kostnad |

---

## 2. Tidsplan-validering mot bransjebenchmarks

### 2.1 Benchmarks per fase og kompleksitet

| Fase | Enkel | Middels | Kompleks | Inkluderer |
|------|-------|---------|----------|------------|
| **Forarbeid** | 1-2 uker | 2-4 uker | 4-8 uker | Behovsanalyse, interessentanalyse, regulatorisk avklaring, anskaffelse |
| **POC** | 4-8 uker | 8-12 uker | 12-16 uker | Teknisk oppsett, kjernefunksjonalitet, demo, evaluering |
| **MVP** | 2-4 måneder | 4-6 måneder | 6-9 måneder | Sikkerhet, DPIA, pilottesting, endringsledelse, integrasjon |
| **Produksjon** | 3-6 måneder | 6-12 måneder | 12-18 måneder | Full utrulling, opplæring, monitoring, optimalisering |

**Merk:** Tidene er *kumulativt* fra prosjektstart. POC starter etter forarbeid, MVP etter POC, osv.

### 2.2 Typiske eksempler per kompleksitet

| Kompleksitet | Eksempel | Total tid til produksjon |
|-------------|----------|-------------------------|
| **Enkel** | M365 Copilot for intern kunnskapssøk i SharePoint | 3-5 måneder |
| **Enkel** | AI Builder-flyt for dokumentklassifisering i Power Automate | 3-4 måneder |
| **Middels** | Copilot Studio-agent med RAG mot intern kunnskapsbase | 6-10 måneder |
| **Middels** | Azure OpenAI-integrasjon i eksisterende webportal | 6-9 måneder |
| **Kompleks** | Microsoft Foundry-løsning med custom RAG, fagsystem-integrasjon og HITL | 12-18 måneder |
| **Kompleks** | Multi-agent orkestrering med Semantic Kernel for saksbehandling | 14-20 måneder |

### 2.3 Tidsplanvalideringsmal

```markdown
### Tidsplanvalidering

**Planlagt total prosjekttid:** [X] måneder
**Prosjekttype:** [Enkel / Middels / Kompleks]
**Benchmark-range:** [Y-Z] måneder

| Sjekk | Status | Kommentar |
|-------|--------|-----------|
| Innenfor benchmark-range? | ✅/⚠️/❌ | [Kort forklaring] |
| Buffer inkludert? (≥ 20%) | ✅/⚠️/❌ | [X uker buffer av Y uker total = Z%] |
| Forarbeid-tid realistisk? | ✅/⚠️/❌ | [DPIA alene tar typisk 4-8 uker for høyrisiko] |
| POC-tid inkluderer evaluering? | ✅/⚠️/❌ | [Ikke bare utvikling, men også testing og demo] |
| MVP inkluderer endringsledelse? | ✅/⚠️/❌ | [Opplæring og organisatorisk forankring] |
| Anskaffelsestid inkludert? | ✅/⚠️/❌ | [Offentlig anskaffelse kan ta 3-6 mnd ekstra] |
| Ferietid og helligdager hensyntatt? | ✅/⚠️/❌ | [Norsk sommer = 3-4 uker redusert kapasitet] |

**Konklusjon:**
- [ ] Tidsplanen er **realistisk** — innenfor benchmarks med tilstrekkelig buffer
- [ ] Tidsplanen er **stram, men gjennomførbar** — krever [forutsetninger]
- [ ] Tidsplanen er **urealistisk** — bør justeres med [X] måneder
```

---

## 3. Buffer-vurdering

### 3.1 Bufferregler

| Prosjekttype | Minimumsbuffer | Anbefalt buffer | Begrunnelse |
|-------------|---------------|-----------------|-------------|
| **Enkel** | 15% | 20% | Lav usikkerhet, kjent teknologi |
| **Middels** | 20% | 25% | Moderat usikkerhet, integrasjoner |
| **Kompleks** | 25% | 30-35% | Høy usikkerhet, ukjent terreng, mange avhengigheter |

### 3.2 Buffermultiplikatorer

Legg til ekstra buffer for disse faktorene:

| Faktor | Ekstra buffer | Begrunnelse |
|--------|--------------|-------------|
| Offentlig anskaffelse nødvendig | +2-4 måneder | Konkurransegrunnlag, evaluering, karenstid |
| DPIA med Datatilsynet-konsultasjon | +2-3 måneder | Datatilsynet har 8 ukers svarfrist |
| Første AI-prosjekt i virksomheten | +20% | Organisatorisk læring, ukjente prosesser |
| Integrasjon med legacy fagsystem | +15-25% | Ofte dårlig dokumentert, uforutsigbare API-er |
| Krav om norsk/nynorsk-spesifikk evaluering | +2-4 uker | Krever manuell evaluering med morsmålsbrukere |
| Høyrisiko AI Act-klassifisering | +4-8 uker | Ekstra dokumentasjonskrav, conformity assessment |
| Preview/beta-tjenester i arkitekturen | +15-25% | Ustabile API-er, manglende dokumentasjon, breaking changes |

### 3.3 Beregningseksempel

```
Middels prosjekt: Copilot Studio-agent med RAG
  Base-estimat: 8 måneder
  Standard buffer (20%): +1.6 måneder
  Første AI-prosjekt (+20%): +1.6 måneder
  Offentlig anskaffelse: +3 måneder
  ─────────────────────
  Justert estimat: 14.2 måneder ≈ 14-15 måneder
```

---

## 4. Risikotabell for gjennomføring

### 4.1 Vanlige gjennomføringsrisikoer for AI-prosjekter

| # | Risiko | Sannsynlighet | Konsekvens | Risikonivå | Forebyggende tiltak | Utløsende hendelse |
|---|--------|---------------|------------|------------|--------------------|--------------------|
| R1 | **Kompetansemangel** — nøkkelpersoner mangler AI-kompetanse | Høy | Høy | **Kritisk** | Kompetansekartlegging tidlig, ekstern rådgiver i oppstart | Team klarer ikke å gjennomføre POC selvstendig |
| R2 | **Urealistisk tidsplan** — underestimering av kompleksitet | Høy | Høy | **Kritisk** | Bruk benchmarks fra seksjon 2, legg inn buffer | Første milepæl bommes med > 2 uker |
| R3 | **Datakvalitet** — RAG-data er ustrukturert, foreldet eller ufullstendig | Høy | Middels | **Høy** | Datakvalitetsvurdering i forarbeidsfasen | Retrieval-kvalitet < 70% i POC |
| R4 | **Scope creep** — utvidelse av krav underveis | Høy | Middels | **Høy** | Tydelig MVP-avgrensning, endringslogg, beslutningsstøtte | Nye krav tilkommer uten at noe fjernes |
| R5 | **Leverandøravhengighet** — Microsoft endrer priser, API-er eller tjenester | Middels | Middels | **Middels** | Abstraksjonssjikt, exit-strategi, unngå preview-tjenester i produksjon | Breaking change i API, prisøkning > 20% |
| R6 | **Regulatorisk endring** — AI Act-krav som ikke var forutsett | Middels | Høy | **Høy** | Følg med på regulatorisk utvikling, inkluder juridisk rådgiver | Ny veileder fra Nkom/Datatilsynet |
| R7 | **Organisatorisk motstand** — brukere ønsker ikke AI | Middels | Høy | **Høy** | Tidlig involvering, endringsledelse, synlige quick wins | Lavt pilotadopsjon (< 30% aktive brukere) |
| R8 | **Nøkkelpersonfrafall** — arkitekt eller prosjektleder slutter | Middels | Høy | **Høy** | Dokumentasjon, pairing, unngå enmannsavhengighet | Nøkkelperson sier opp |
| R9 | **Integrasjonskompleksitet** — fagsystem-integrasjon vanskeligere enn antatt | Middels | Middels | **Middels** | Kartlegg API-er i forarbeid, POC for integrasjon tidlig | API-testing avdekker manglende funksjonalitet |
| R10 | **Modellytelse på norsk** — modellen presterer dårlig på norsk fagspråk | Middels | Middels | **Middels** | Norsk evalueringssett i POC, finn fallback-modell | Accuracy < 80% på norsk evalueringssett |

### 4.2 Risikomatrise-mal

```markdown
### Risikomatrise

|   | Lav konsekvens (1) | Middels konsekvens (2) | Høy konsekvens (3) |
|---|-------------------|----------------------|-------------------|
| **Høy sannsynlighet (3)** | Akseptabel — overvåk | HØY — tiltak nødvendig | KRITISK — tiltak obligatorisk |
| **Middels sannsynlighet (2)** | Akseptabel — overvåk | MIDDELS — vurder tiltak | HØY — tiltak nødvendig |
| **Lav sannsynlighet (1)** | Akseptabel | Akseptabel — overvåk | MIDDELS — vurder tiltak |

Risikonivå = Sannsynlighet × Konsekvens
- **1-2:** Akseptabel — overvåk
- **3-4:** Middels — vurder tiltak
- **6:** Høy — tiltak nødvendig
- **9:** Kritisk — tiltak obligatorisk (blokkerer prosjektstart)
```

---

## 5. MVP-avgrensning

### 5.1 Framework for MVP-definisjon

MVP (Minimum Viable Product) for AI-prosjekter har to dimensjoner:
1. **Funksjonell avgrensning** — hvilke brukstilfeller inkluderes?
2. **Kvalitetsavgrensning** — hvilket presisjonsnivå kreves?

### 5.2 MVP-avgrensningsmal

```markdown
### MVP-avgrensning

**Prosjekt:** [Prosjektnavn]

#### Inkludert i MVP (must-have)

| # | Brukstilfelle | Beskrivelse | Suksesskriterium |
|---|---------------|-------------|------------------|
| 1 | [Hovedbrukstilfelle] | [Kort beskrivelse] | [Målbar metrikk] |
| 2 | [Støttebrukstilfelle] | [Kort beskrivelse] | [Målbar metrikk] |

#### Eksplisitt utelatt fra MVP (backlog)

| # | Brukstilfelle | Beskrivelse | Hvorfor utelatt | Planlagt i fase |
|---|---------------|-------------|-----------------|-----------------|
| 3 | [Tilleggsbrukstilfelle] | [Kort beskrivelse] | [Begrunnelse — f.eks. "for kompleks integrasjon"] | Fase 2 |
| 4 | [Tilleggsbrukstilfelle] | [Kort beskrivelse] | [Begrunnelse] | Fase 3 |

#### MVP-kvalitetskrav

| Aspekt | MVP-krav | Fullskala-krav | Gap-strategi |
|--------|---------|----------------|--------------|
| Accuracy/presisjon | ≥ 75% | ≥ 90% | Iterativ forbedring med produksjonsdata |
| Svartid | < 10 sekunder | < 3 sekunder | Optimaliser etter funksjonell validering |
| Samtidige brukere | 10-20 | [X] | Autoscaling i produksjon |
| Språkstøtte | Bokmål | Bokmål + nynorsk | Legg til nynorsk i fase 2 |
| Tilgjengelighet (WCAG) | Grunnleggende | WCAG 2.1 AA | Dedikert tilgjengelighetsvurdering i fase 2 |

#### MVP Go/No-Go-kriterier

- [ ] Hovedbrukstilfelle fungerer end-to-end
- [ ] Presisjon ≥ [X]% på evalueringssett
- [ ] Sikkerhet: Content Safety-filter aktivert
- [ ] DPIA gjennomført (i det minste foreløpig)
- [ ] Pilotbrukere (≥ 5) har testet og gitt feedback
- [ ] Ingen kritiske sikkerhetsfunn i sikkerhetsgjennomgang
```

### 5.3 Vanlige MVP-feller i AI-prosjekter

| Felle | Beskrivelse | Korreksjon |
|-------|-------------|------------|
| **"Alt i MVP"** | Alle brukstilfeller inkluderes — MVP = full løsning | Begrens til 1-2 kjernebrukstilfeller |
| **"Perfekt fra dag 1"** | Krever 95%+ presisjon i MVP | Sett MVP-terskel lavere (75-80%), iterer med data |
| **"Ignorer sikkerhet"** | Sikkerhet og DPIA utsettes til "senere" | Minimum Content Safety og foreløpig DPIA i MVP |
| **"MVP uten brukere"** | MVP testet bare av utviklere | Alltid pilotgruppe med reelle brukere |
| **"Ingen exit-kriterier"** | Ingen definisjon av når MVP er "ferdig" | Definer Go/No-Go-kriterier på forhånd |

---

## 6. Oppsummerende vurderingsmal

```markdown
### Gjennomførbarhetsvurdering — sammendrag

| Dimensjon | Vurdering | Status | Kommentar |
|-----------|-----------|--------|-----------|
| Kompetanse | [X] roller har gap | 🟢/🟡/🔴 | [Hovedfunn] |
| Tidsplan | [X] mnd planlagt vs. [Y-Z] benchmark | 🟢/🟡/🔴 | [Realistisk / stram / urealistisk] |
| Buffer | [X]% buffer inkludert | 🟢/🟡/🔴 | [Tilstrekkelig / marginal / utilstrekkelig] |
| Risiko | [X] kritiske, [Y] høye risikoer | 🟢/🟡/🔴 | [Hovedrisikoer] |
| MVP-klarhet | MVP definert med Go/No-Go | 🟢/🟡/🔴 | [Tydelig / uklar / mangler] |

**Overordnet gjennomførbarhetsvurdering:**
- [ ] **Gjennomførbar** — kompetanse, tid og risiko er under kontroll
- [ ] **Betinget gjennomførbar** — krever [tiltak] for å være gjennomførbar
- [ ] **Ikke gjennomførbar i nåværende form** — anbefaler [reduksjon/utsettelse/omfangsendring]
```

---

## For Cosmo Skyberg

Denne referansefilen hjelper deg å vurdere om et prosjekt faktisk er gjennomførbart — ikke bare om teknologien er riktig. Bruk den slik:

### Når du vurderer gjennomførbarhet:

1. **Kompetanse-gap** (seksjon 1): Kartlegg roller og kompetanse tidlig. Et gap på 2+ nivåer i en kritisk rolle er en blocker.
2. **Tidsplan** (seksjon 2): Sammenlign alltid den planlagte tidsplanen mot benchmarks. Flagg avvik tydelig.
3. **Buffer** (seksjon 3): Aldri aksepter en plan uten buffer. Minimum 20%, 30% for komplekse prosjekter.
4. **Risiko** (seksjon 4): Gå gjennom risikotabellen med brukeren. Spør: "Hvilke av disse kjenner dere igjen?"
5. **MVP** (seksjon 5): Hjelp brukeren med å definere et realistisk MVP. "Hva er det absolutt minste som gir verdi?"

### Integrasjon med utredningen:

- **Alternativanalysen** (K6 Organisatorisk gjennomførbarhet i `alternativanalyse-methodology.md`): Score basert på gap-matrisen
- **Implementeringsplanen** (S9 i `ai-utredning-template.md`): Bruk benchmarks for realistisk faseplan
- **Kostnadsvurderingen** (S6): Inkluder kostnad for å tette kompetansegap
- **Antakelsesregisteret** (`source-traceability-assumption-register.md`): Registrer tidsplan-antakelser

### Vanligste fallgruver du bør advare om:

1. **"Vi har jo M365-lisenser, det er bare å skru på Copilot"** — selv enkel konfigurasjon krever forarbeid, DPIA, datakvalitet
2. **"POC tar 2 uker"** — realistisk POC inkluderer evaluering, demo, beslutning — minimum 4 uker for enkel
3. **"Vi trenger ikke kompetanseplan, vi har IT-avdeling"** — AI-kompetanse ≠ generell IT-kompetanse
4. **"Vi tar sikkerhet i neste fase"** — DPIA og Content Safety er minimum fra dag 1