ms-ai-architect/skills/ms-ai-advisor/references/architecture/capacity-feasibility-benchmarks.md

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

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

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

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

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

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