feat(ms-ai-architect): add plugin to open marketplace (v1.5.0 baseline)
Initial addition of ms-ai-architect plugin to the open-source marketplace. Private content excluded: orchestrator/ (Linear tooling), docs/utredning/ (client investigation), generated test reports and PDF export script. skill-gen tooling moved from orchestrator/ to scripts/skill-gen/. Security scan: WARNING (risk 20/100) — no secrets, no injection found. False positive fixed: added gitleaks:allow to Python variable reference in output-validation-grounding-verification.md line 109. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen
parent
a8d79e4484
commit
6a7632146e
490 changed files with 213249 additions and 2 deletions
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,312 @@
|
|||
# Alternativanalyse-metodikk — Vektet multi-kriterie-analyse (MCA)
|
||||
|
||||
**Sist oppdatert:** 2026-02 (v1.0)
|
||||
**Målgruppe:** Arkitekter som gjennomfører AI-arkitekturutredninger for norsk offentlig sektor
|
||||
**Regulatorisk forankring:** Utredningsinstruksen (2016), DFOs veileder til utredningsinstruksen
|
||||
|
||||
---
|
||||
|
||||
## Om dette dokumentet
|
||||
|
||||
Denne referansefilen definerer en strukturert metodikk for alternativsammenligning i AI-arkitekturutredninger. Metodikken sikrer etterprøvbare, transparente og rettferdige sammenligninger — i tråd med utredningsinstruksens krav om at beslutningsgrunnlaget skal være "så omfattende og grundig som nødvendig" (§2-2).
|
||||
|
||||
---
|
||||
|
||||
## 1. Scoringsskala 1-5
|
||||
|
||||
Alle kriterier scores på en felles skala med eksplisitte definisjoner per nivå. Vurderingene skal være konkrete og etterprøvbare — unngå vage formuleringer.
|
||||
|
||||
| Score | Betegnelse | Definisjon | Eksempel (norsk språkstøtte) |
|
||||
|-------|-----------|------------|------------------------------|
|
||||
| **1** | Oppfyller ikke | Oppfyller ikke kravet i det hele tatt. Fundamental mangel som ikke kan kompenseres uten betydelig ekstraarbeid. | Ingen støtte for norsk. Kun engelskspråklige modeller uten mulighet for tilpasning. |
|
||||
| **2** | Delvis, vesentlige mangler | Oppfyller kravet delvis, men har vesentlige mangler som krever betydelige workarounds eller tilleggsinvesteringer. | Begrenset norskstøtte. Forstår grunnleggende norsk, men produserer ofte grammatiske feil og blander bokmål/nynorsk. |
|
||||
| **3** | Oppfyller minimumskrav | Oppfyller minimumskravet uten vesentlige mangler. Funksjonelt akseptabelt, men uten margin. | Akseptabel norskstøtte. Forstår og produserer korrekt bokmål. Nynorsk og fagterminologi er ustabilt. |
|
||||
| **4** | Over minimumskrav, god dekning | Overgår minimumskravet. God dekning med noen forbedringsmuligheter. | God norskstøtte. Behersker bokmål og nynorsk. Forstår vanlig fagterminologi. Noen mangler i spesialdomener. |
|
||||
| **5** | Utmerket, overgår forventning | Utmerket dekning som overgår forventningene. Beste tilgjengelige løsning for dette kriteriet. | Utmerket norskstøtte. Behersker bokmål, nynorsk og vanlige dialektuttrykk. Korrekt fagterminologi i domenet. Samisk grunnstøtte. |
|
||||
|
||||
### Regler for scoring
|
||||
|
||||
- **Alltid begrunn scoren** med en kort setning som refererer til verifiserbar informasjon
|
||||
- **Bruk hele skalaen** — unngå å gi alle alternativer 3-4 (dette indikerer at kriteriene er for vage)
|
||||
- **Skill mellom "i dag" og "planlagt"** — score kun det som er tilgjengelig nå, ikke roadmap-løfter
|
||||
- **Dokumenter usikkerhet** — hvis scoren er usikker, noter det (f.eks. "Score 3, usikkerhet +/- 1, mangler testdata")
|
||||
|
||||
---
|
||||
|
||||
## 2. Standard vurderingskriterier for AI-arkitektursammenligning
|
||||
|
||||
### 2.1 Kriteriesett med foreslåtte vekter
|
||||
|
||||
| # | Kriterie | Foreslått vekt | Beskrivelse | Typiske vurderingspunkter |
|
||||
|---|----------|---------------|-------------|---------------------------|
|
||||
| K1 | **Teknisk modenhet** | 15% | Hvor moden og stabil er teknologien? | GA vs. preview, versjonsstabilitet, kjente begrensninger, community/økosystem, dokumentasjonskvalitet |
|
||||
| K2 | **Norsk språkstøtte** | 15% | Kvalitet på norskstøtte (bokmål, nynorsk, fagterminologi) | Språkforståelse, tekstgenerering, oversettelse, fagterminologi, samisk (hvis relevant) |
|
||||
| K3 | **Sikkerhet og compliance** | 20% | Oppfyllelse av regulatoriske og sikkerhetskrav | AI Act, GDPR/DPIA, dataresidenskrav (Norway East/Sweden Central), NSM grunnprinsipper, Schrems II |
|
||||
| K4 | **Kostnadseffektivitet** | 15% | Total eierkostnad (TCO) relativt til verdi | Lisenskostnader, Azure-forbruk, driftskostnader, implementeringskostnad, skjulte kostnader |
|
||||
| K5 | **Skalerbarhet** | 10% | Evne til å håndtere vekst i brukere, data og funksjoner | Horisontal skalering, autoscaling, throughput-grenser, multi-region, ytelsesgarantier |
|
||||
| K6 | **Organisatorisk gjennomførbarhet** | 15% | Evne til å gjennomføre med tilgjengelig kompetanse og organisasjon | Kompetansegap, endringsledelse, leverandøravhengighet, økosystem-tilpasning, intern forankring |
|
||||
| K7 | **Tid til verdi** | 10% | Hvor raskt kan løsningen levere målbar verdi? | POC-varighet, MVP-tid, produksjon, kompleksitet i oppsett, tilgjengelige akseleratorer |
|
||||
|
||||
**Total:** 100%
|
||||
|
||||
### 2.2 Justering av vekter
|
||||
|
||||
Vektene over er utgangspunkt og **skal tilpasses** konteksten. Vanlige justeringer:
|
||||
|
||||
| Kontekst | Juster opp | Juster ned | Begrunnelse |
|
||||
|----------|-----------|-----------|-------------|
|
||||
| Høyrisiko AI Act | K3 Sikkerhet → 25-30% | K7 Tid → 5% | Compliance er ikke forhandlingsbart |
|
||||
| Tidskritisk prosjekt | K7 Tid → 15-20% | K5 Skalerbarhet → 5% | Første versjon trenger ikke full skalering |
|
||||
| Lavt kompetansenivå | K6 Organisatorisk → 20-25% | K1 Teknisk → 10% | Hjelper ikke med moden teknologi hvis ingen kan bruke den |
|
||||
| Tett budsjett | K4 Kostnad → 20-25% | K5 Skalerbarhet → 5% | Prioriter å holde seg innenfor budsjett |
|
||||
| Samisk befolkning berørt | K2 Norsk språk → 20% | K1 Teknisk → 10% | Språkkrav er avgjørende for likeverdig tjeneste |
|
||||
|
||||
**Regel:** Dokumenter alltid *hvorfor* vektene er justert fra standardoppsettet.
|
||||
|
||||
---
|
||||
|
||||
## 3. Sammenligningstabellmal
|
||||
|
||||
### 3.1 Komplett vektet scorecard
|
||||
|
||||
```markdown
|
||||
### Alternativsammenligning — Vektet multi-kriterie-analyse
|
||||
|
||||
**Prosjekt:** [Prosjektnavn]
|
||||
**Dato:** YYYY-MM-DD
|
||||
**Vektbegrunnelse:** [Standard / Justert — begrunn justeringer]
|
||||
|
||||
| # | Kriterie | Vekt | Alt 0: Null | Alt 1: [Navn] | Alt 2: [Navn] | Alt 3: [Navn] |
|
||||
|---|----------|------|-------------|---------------|---------------|---------------|
|
||||
| K1 | Teknisk modenhet | 15% | — | [1-5] | [1-5] | [1-5] |
|
||||
| K2 | Norsk språkstøtte | 15% | — | [1-5] | [1-5] | [1-5] |
|
||||
| K3 | Sikkerhet og compliance | 20% | — | [1-5] | [1-5] | [1-5] |
|
||||
| K4 | Kostnadseffektivitet | 15% | — | [1-5] | [1-5] | [1-5] |
|
||||
| K5 | Skalerbarhet | 10% | — | [1-5] | [1-5] | [1-5] |
|
||||
| K6 | Org. gjennomførbarhet | 15% | — | [1-5] | [1-5] | [1-5] |
|
||||
| K7 | Tid til verdi | 10% | — | [1-5] | [1-5] | [1-5] |
|
||||
| | **Vektet totalsum** | **100%** | **—** | **[X.XX]** | **[X.XX]** | **[X.XX]** |
|
||||
|
||||
**Beregning:** Vektet sum = Σ (score_i × vekt_i)
|
||||
**Maks mulig:** 5.00 | **Anbefalt terskel:** ≥ 3.50 for anbefaling
|
||||
```
|
||||
|
||||
### 3.2 Begrunnelsestabell (obligatorisk)
|
||||
|
||||
Hver score **må** ha en kort begrunnelse:
|
||||
|
||||
```markdown
|
||||
### Scorebegrunnelser
|
||||
|
||||
| Kriterie | Alternativ | Score | Begrunnelse | Kilde |
|
||||
|----------|-----------|-------|-------------|-------|
|
||||
| K1 Teknisk modenhet | Alt 2: Copilot Studio | 4 | GA siden nov 2023, stabil plattform, god dokumentasjon | KB: platforms/copilot-studio.md |
|
||||
| K2 Norsk språkstøtte | Alt 2: Copilot Studio | 3 | GPT-4o forstår norsk godt, men generative topics har begrenset nynorsk-støtte | MCP: microsoft-learn (verifisert 2026-02) |
|
||||
| K3 Sikkerhet | Alt 2: Copilot Studio | 4 | Data i EU, GDPR-compliant, mangler noen granulære DLP-kontroller | KB: public-sector-checklist.md |
|
||||
| ... | ... | ... | ... | ... |
|
||||
```
|
||||
|
||||
### 3.3 Beregningseksempel
|
||||
|
||||
```
|
||||
Alt 2: Copilot Studio + Azure AI Search
|
||||
K1: 4 × 0.15 = 0.60
|
||||
K2: 3 × 0.15 = 0.45
|
||||
K3: 4 × 0.20 = 0.80
|
||||
K4: 3 × 0.15 = 0.45
|
||||
K5: 3 × 0.10 = 0.30
|
||||
K6: 4 × 0.15 = 0.60
|
||||
K7: 4 × 0.10 = 0.40
|
||||
──────────────────────
|
||||
Vektet totalsum: 3.60 ✅ (over terskel 3.50)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Sensitivitetsanalyse
|
||||
|
||||
Sensitivitetsanalysen avdekker om anbefalingen er robust — eller om den "vipper" ved rimelige endringer i vekter eller scorer.
|
||||
|
||||
### 4.1 Metode
|
||||
|
||||
For hvert kriterie, test hva som skjer dersom:
|
||||
1. **Vekten økes med 10 prosentpoeng** (og fordeles jevnt fra øvrige)
|
||||
2. **Vekten reduseres med 10 prosentpoeng** (og fordeles jevnt til øvrige)
|
||||
3. **Scoren endres med +/- 1** for det ledende alternativet
|
||||
|
||||
### 4.2 Sensitivitetsanalysetal
|
||||
|
||||
```markdown
|
||||
### Sensitivitetsanalyse
|
||||
|
||||
**Basecase:** Alt 2 (score 3.60) > Alt 3 (score 3.45) — forskjell: 0.15
|
||||
|
||||
| Test | Endring | Alt 2 ny score | Alt 3 ny score | Vinner endres? |
|
||||
|------|---------|----------------|----------------|----------------|
|
||||
| K3 vekt +10pp | Sikkerhet 20% → 30% | [X.XX] | [X.XX] | Ja/Nei |
|
||||
| K3 vekt -10pp | Sikkerhet 20% → 10% | [X.XX] | [X.XX] | Ja/Nei |
|
||||
| K4 vekt +10pp | Kostnad 15% → 25% | [X.XX] | [X.XX] | Ja/Nei |
|
||||
| K6 vekt +10pp | Org. gj.førb. 15% → 25% | [X.XX] | [X.XX] | Ja/Nei |
|
||||
| Alt 2 K2 score -1 | Norsk 3 → 2 | [X.XX] | — | Ja/Nei |
|
||||
| Alt 2 K3 score -1 | Sikkerhet 4 → 3 | [X.XX] | — | Ja/Nei |
|
||||
|
||||
**Robusthetskonklusjon:**
|
||||
- [ ] Anbefalingen er **robust** — den endres ikke ved noen rimelig endring
|
||||
- [ ] Anbefalingen er **betinget robust** — den endres kun ved ekstreme vektendringer
|
||||
- [ ] Anbefalingen er **sensitiv** — den endres ved [spesifiser hvilke endringer]
|
||||
```
|
||||
|
||||
### 4.3 Kritiske kriterier ("swing criteria")
|
||||
|
||||
Identifiser kriterier der en endring i score eller vekt vil endre anbefalingen:
|
||||
|
||||
```markdown
|
||||
### Kritiske kriterier
|
||||
|
||||
| Kriterie | Breakpoint | Implikasjon |
|
||||
|----------|-----------|-------------|
|
||||
| K3 Sikkerhet | Hvis Alt 3 scorer ≥ 4 (i stedet for 3) | Alt 3 overtar som anbefalt |
|
||||
| K4 Kostnad | Hvis vekt økes til > 25% | Alt 1 (billigere) blir anbefalt |
|
||||
| K6 Org. gjennomf. | Hvis Alt 2 scorer ≤ 2 | Ingen alternativer når terskel |
|
||||
|
||||
**Aksjonspunkter:**
|
||||
- [ ] Verifiser K3-score for Alt 3 — hent oppdatert compliance-informasjon
|
||||
- [ ] Avklar faktisk budsjettramme — påvirker K4-vekting
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Krav om tilstrekkelig dybde (utredningsinstruksen)
|
||||
|
||||
### 5.1 Regulatorisk grunnlag
|
||||
|
||||
Utredningsinstruksen §2-2 fastslår at utredningen skal være "så omfattende og grundig som nødvendig". DFOs veileder presiserer at kravene til grundighet øker med tiltakets omfang og virkninger. For alternativanalysen innebærer dette:
|
||||
|
||||
- **Alle reelle alternativer skal beskrives tilstrekkelig** til at beslutningstaker kan vurdere dem
|
||||
- **Virkningene av hvert alternativ** skal utredes med tilstrekkelig dybde
|
||||
- **Nullalternativet** skal alltid inkluderes som referanse
|
||||
- **Ikke-AI-alternativ** bør alltid vurderes (prosessforbedring, tradisjonell automatisering)
|
||||
|
||||
DFOs veileder til utredningsinstruksen (kap. 2.1) presiserer minimumskravene, der spørsmål 2 ("Hvilke tiltak er relevante?") krever at alle aktuelle alternativer identifiseres og vurderes.
|
||||
|
||||
### 5.2 Sjekkliste for tilstrekkelig dybde
|
||||
|
||||
Bruk denne sjekklisten **etter** at alternativanalysen er ferdig for å verifisere at alle alternativer er behandlet med tilstrekkelig og rettferdig dybde:
|
||||
|
||||
```markdown
|
||||
### Sjekkliste: Tilstrekkelig dybde i alternativanalysen
|
||||
|
||||
**Strukturell likhet:**
|
||||
- [ ] Alle alternativer har beskrivelse av samme lengde (+/- 30%)
|
||||
- [ ] Alle alternativer er vurdert mot samtlige kriterier (ingen tomme celler)
|
||||
- [ ] Alle scorer har skriftlig begrunnelse
|
||||
- [ ] Kildehenvisning finnes for alle vesentlige påstander
|
||||
|
||||
**Informasjonsdybde:**
|
||||
- [ ] Nullalternativet er beskrevet med reelle konsekvenser (ikke bare "ingen endring")
|
||||
- [ ] Minst ett ikke-AI-alternativ er inkludert og reelt vurdert
|
||||
- [ ] Tekniske detaljer (arkitektur, komponenter) er beskrevet for alle alternativer
|
||||
- [ ] Kostnadsestimater dekker alle alternativer med sammenlignbare kostnadsposter
|
||||
- [ ] Sikkerhetsvurdering dekker alle alternativer med samme dimensjoner
|
||||
|
||||
**Objektivitet:**
|
||||
- [ ] Ingen alternativer er beskrevet med systematisk positivt/negativt ladede ord
|
||||
- [ ] Fordeler og ulemper er balansert for alle alternativer
|
||||
- [ ] Ukjente aspekter er merket som ukjente (ikke utelatt)
|
||||
- [ ] Antakelser er eksplisitt merket og gjelder likt for alle alternativer
|
||||
|
||||
**MCA-integritet:**
|
||||
- [ ] Vekter er begrunnet uavhengig av alternativene (bestemt før scoring)
|
||||
- [ ] Scorer er begrunnet per alternativ per kriterie (ikke bare totalvurdering)
|
||||
- [ ] Sensitivitetsanalyse er gjennomført
|
||||
- [ ] Terskelverdi for anbefaling er definert på forhånd
|
||||
|
||||
**Ettersporing:**
|
||||
- [ ] Det er klart hvem som har scoret (person/rolle)
|
||||
- [ ] Det er klart når scoringen ble gjort (dato)
|
||||
- [ ] Det er klart hvilke kilder som ble brukt (MCP-verifisert, KB, ekspert, antakelse)
|
||||
```
|
||||
|
||||
### 5.3 Vanlige feil som bryter med kravet om tilstrekkelig dybde
|
||||
|
||||
| Feil | Eksempel | Konsekvens | Korreksjon |
|
||||
|------|----------|------------|------------|
|
||||
| **Stråmannsalternativ** | Alt 1 er en åpenbart dårlig løsning inkludert bare for å gjøre Alt 2 bedre | Manipulerer beslutningen | Sørg for at alle alternativer er realistiske og relevante |
|
||||
| **Ujevn informasjonstilgang** | Alt 2 (anbefalt) har 2 sider beskrivelse, Alt 3 har 3 linjer | Beslutningstaker kan ikke vurdere Alt 3 | Beskriv alle med sammenlignbar dybde |
|
||||
| **Manglende nullalternativ** | Nullalternativet nevnes bare som "ikke et alternativ" | Bryter utredningsinstruksen | Beskriv reelle konsekvenser av å ikke gjøre noe |
|
||||
| **Cherry-picking kriterier** | Kriterier er valgt fordi anbefalt alternativ scorer høyt | Skjult bias | Definer kriterier uavhengig av løsning, gjerne med interessenter |
|
||||
| **Post-hoc vekting** | Vekter justeres etter scoring for å få "riktig" resultat | Manipulasjon | Sett vekter før scoring. Dokumenter tidspunkt. |
|
||||
| **Manglende ikke-AI-alternativ** | Kun AI-løsninger sammenlignes | Kan bryte utredningsinstruksen | Inkluder alltid minst ett ikke-AI-alternativ |
|
||||
|
||||
---
|
||||
|
||||
## 6. Prosess for gjennomføring
|
||||
|
||||
### 6.1 Anbefalt rekkefølge
|
||||
|
||||
```
|
||||
1. Definer kriterier med interessenter (workshop)
|
||||
↓
|
||||
2. Sett vekter (før scoring!) — dokumenter begrunnelse
|
||||
↓
|
||||
3. Identifiser 3-5 reelle alternativer (inkl. nullalt. og ikke-AI)
|
||||
↓
|
||||
4. Beskriv hvert alternativ med tilstrekkelig dybde
|
||||
↓
|
||||
5. Score hvert alternativ per kriterie — begrunn skriftlig
|
||||
↓
|
||||
6. Beregn vektet sum
|
||||
↓
|
||||
7. Gjennomfør sensitivitetsanalyse
|
||||
↓
|
||||
8. Verifiser tilstrekkelig dybde (sjekkliste 5.2)
|
||||
↓
|
||||
9. Formuler anbefaling med referanse til MCA-resultater
|
||||
```
|
||||
|
||||
### 6.2 Hvem scorer?
|
||||
|
||||
| Tilnærming | Når | Fordel | Ulempe |
|
||||
|------------|-----|--------|--------|
|
||||
| **Arkitekt alene** | Enkle utredninger, rådgivende karakter | Rask, konsistent | Subjektivt, lav legitimitet |
|
||||
| **Tverrfaglig team** | Middels/komplekse utredninger | Bredere perspektiv, høyere legitimitet | Tidkrevende, kan kreve fasilitering |
|
||||
| **Delphi-metode** | Komplekse utredninger med mange interessenter | Reduserer gruppetenkning, dokumenterer uenighet | Krever flere runder, tar tid |
|
||||
|
||||
---
|
||||
|
||||
## 7. Referanser
|
||||
|
||||
- [Utredningsinstruksen](https://www.regjeringen.no/no/dokumenter/instruks-om-utredning-av-statlige-tiltak-utredningsinstruksen/id2476518/) (Regjeringen, 2016)
|
||||
- [Veileder til utredningsinstruksen](https://dfo.no/fagomrader/utredning-og-analyse-av-statlige-tiltak/veileder-til-utredningsinstruksen/) (DFO)
|
||||
- [Kap. 2.1 Minimumskrav](https://dfo.no/fagomrader/utredning-og-analyse-av-statlige-tiltak/veileder-til-utredningsinstruksen/kap-21-minimumskrav-til-utredning-av-statlige-tiltak) (DFO)
|
||||
- [Kap. 2 Krav til innhold i beslutningsgrunnlaget](https://dfo.no/fagomrader/utredning-og-analyse-av-statlige-tiltak/veileder-til-utredningsinstruksen/kap-2-krav-til-innhold-i-beslutningsgrunnlaget) (DFO)
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo Skyberg
|
||||
|
||||
Denne referansefilen er ditt verktøy for strukturert alternativsammenligning. Slik bruker du den:
|
||||
|
||||
### Når du gjennomfører en alternativanalyse:
|
||||
|
||||
1. **Bruk standardkriteriene (K1-K7)** som utgangspunkt. Juster vekter basert på kontekst og begrunn justeringene.
|
||||
2. **Score med 1-5-skalaen** og bruk de eksakte definisjonene. Aldri gi en score uten begrunnelse.
|
||||
3. **Beregn vektet sum** og presenter i sammenligningstabellmalen.
|
||||
4. **Kjør sensitivitetsanalyse** for å avdekke om anbefalingen er robust.
|
||||
5. **Verifiser tilstrekkelig dybde** med sjekklisten i seksjon 5.2.
|
||||
|
||||
### Integrasjon med andre referansefiler:
|
||||
|
||||
- **Kostnadsdata** (K4): Hent fra `cost-models.md` og `/architect:cost`
|
||||
- **Sikkerhetsscorer** (K3): Hent fra `/architect:security` (6-dimensjons-rammeverket)
|
||||
- **Plattformmodenhet** (K1): Hent fra `platforms/*.md` (kunnskapsbasen)
|
||||
- **Regional tilgjengelighet**: Kryssreferanse med `regional-availability-verification.md`
|
||||
- **Antakelser**: Dokumenter i `source-traceability-assumption-register.md`
|
||||
- **Gjennomførbarhet** (K6): Bruk `capacity-feasibility-benchmarks.md` for kompetansegap og tidsplan
|
||||
|
||||
### Viktige regler:
|
||||
|
||||
- **Sett vekter FØR scoring** — aldri juster vekter etter at du har scoret alternativene
|
||||
- **Inkluder alltid nullalternativ og minst ett ikke-AI-alternativ**
|
||||
- **Bruk sjekklisten** i seksjon 5.2 før du leverer analysen
|
||||
- **Vær eksplisitt om usikkerhet** — en ærlig "score 3, usikker +/- 1" er bedre enn en falsk presis "score 4"
|
||||
|
|
@ -0,0 +1,307 @@
|
|||
# Kapasitet og gjennomførbarhetsvurdering — Benchmarks for AI-prosjekter
|
||||
|
||||
**Sist oppdatert:** 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
|
||||
|
||||
---
|
||||
|
||||
## 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** | Azure AI 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
|
||||
|
|
@ -0,0 +1,590 @@
|
|||
# Cost Models - Microsoft AI Platforms
|
||||
|
||||
**Last updated:** 2026-01 (research via microsoft-learn MCP)
|
||||
**Disclaimer:** Prices change frequently. Always verify at azure.microsoft.com/pricing
|
||||
|
||||
---
|
||||
|
||||
## Oversikt
|
||||
|
||||
Microsoft AI-plattformene har ulike prismodeller tilpasset forskjellige bruksområder. Denne guiden gir en praktisk oversikt over kostnadsstruktur, lisenskrav og optimaliseringsstrategier for norske offentlige virksomheter.
|
||||
|
||||
## Prismodell-sammendrag
|
||||
|
||||
| Plattform | Prismodell | Måleenhet | Typisk kostnad |
|
||||
|-----------|-----------|-----------|----------------|
|
||||
| **Azure OpenAI Service** | Pay-per-token | Per 1000 tokens | $0.01–$0.60 per 1K tokens (modell-avhengig) |
|
||||
| **Copilot Studio** | Message-based | Per melding | 25,000 meldinger/måned inkludert i basis-lisens |
|
||||
| **M365 Copilot** | Per-user | Per bruker/måned | Krever M365 E3/E5 + Copilot-lisens |
|
||||
| **Power Platform AI** | Credit-based | AI Builder credits | Varierer per funksjon (se AI Builder-tabell) |
|
||||
| **Azure AI Foundry** | Consumption-based | Per service | Avhenger av hvilke Azure AI-tjenester som brukes |
|
||||
|
||||
---
|
||||
|
||||
## Azure OpenAI Service
|
||||
|
||||
### Prismodeller
|
||||
|
||||
**1. Pay-as-you-go (Standard deployment)**
|
||||
- Betaler for faktisk forbruk per token
|
||||
- Input og output tokens prises separat
|
||||
- Ingen forhåndsforpliktelse
|
||||
|
||||
**2. Provisioned Throughput Units (PTU)**
|
||||
- Fast månedlig kostnad for reservert kapasitet
|
||||
- Forutsigbar kostnad ved høy, stabil bruk
|
||||
- Anbefales ved >100,000 requests/måned
|
||||
|
||||
### Modellpriser (per 1 million tokens)
|
||||
|
||||
| Modell | Input | Output | Bruksområde |
|
||||
|--------|-------|--------|-------------|
|
||||
| **GPT-4o** | $10 | $30 | Generell bruk, balanse kostnad/kvalitet |
|
||||
| **GPT-4o-mini** | $0.165 | $0.66 | Kostnadseffektiv, enklere oppgaver |
|
||||
| **GPT-4 Turbo** | $10 | $30 | Komplekse oppgaver, lengre kontekst |
|
||||
| **GPT-3.5 Turbo** | $0.50 | $1.50 | Enkel chat, høy hastighet |
|
||||
| **o1-preview** (reasoning) | $15 | $60 | Kompleks resonnering, analyse |
|
||||
| **o1-mini** (reasoning) | $3 | $12 | Rimeligere resonnering |
|
||||
|
||||
**Vision-enabled models:**
|
||||
- Bilder: 85–1105 tokens per bilde (avhenger av oppløsning)
|
||||
- Ekstra for OCR: $1.50 per 1000 transaksjoner
|
||||
- Ekstra for Object Grounding: $1.50 per 1000 transaksjoner
|
||||
|
||||
### Fine-tuning kostnader
|
||||
|
||||
| Fase | Pris | Enhet |
|
||||
|------|------|-------|
|
||||
| Training | Token-based | Per 1000 tokens i treningsdata |
|
||||
| Hosting | ~$3–$10/time | Per distribuert modell (alltid påløpende) |
|
||||
| Inference | Model-avhengig | Input + output tokens |
|
||||
|
||||
**Viktig:** Hosting-kostnader løper 24/7 uavhengig av bruk. Slett ubrukte deployments.
|
||||
|
||||
### Commitment tiers (Provisioned Throughput)
|
||||
|
||||
Gir forutsigbare kostnader ved stabil bruk:
|
||||
|
||||
- Små arbeidsmengder: Pay-as-you-go
|
||||
- Middels (stabil): PTU commitment
|
||||
- Hybrid: PTU for baseline + pay-as-you-go for spikes
|
||||
|
||||
**Anbefaling:** Kombiner PTU-endpoint (for baseline-trafikk) med consumption-endpoint (for overflow).
|
||||
|
||||
---
|
||||
|
||||
## Microsoft Copilot Studio
|
||||
|
||||
### Basispriser
|
||||
|
||||
| Lisens | Pris (USD) | Inkludert meldinger | Bruksrett |
|
||||
|--------|------------|---------------------|-----------|
|
||||
| **Copilot Studio tenant** | Varierer | 25,000 meldinger/måned/tenant | Bygg og deploy agenter |
|
||||
| **Copilot Studio user** | $0/måned | N/A | Tillatelse til å lage agenter (krever tenant-lisens) |
|
||||
|
||||
### Copilot Credits (forbruksenhet)
|
||||
|
||||
Fra november 2024 er **Copilot Credits** felles valuta på tvers av Copilot Studio-funksjoner.
|
||||
|
||||
| Funksjon | Copilot Credits | Beskrivelse |
|
||||
|----------|-----------------|-------------|
|
||||
| Classic answer | 1 | Manuelt forfattet svar |
|
||||
| Generative answer | 2 | AI-generert svar |
|
||||
| Agent action | 5 | Trigger, resonnering, topic-endring |
|
||||
| Tenant graph grounding | 10 | RAG over Microsoft Graph |
|
||||
| Agent flow actions | 13 per 100 actions | Flyt-automatisering |
|
||||
| AI tools (basic) | 1 per 10 responser | Enkel prompt-prosessering |
|
||||
| AI tools (standard) | 15 per 10 responser | Standard prompt-prosessering |
|
||||
| AI tools (premium) | 100 per 10 responser | Avansert resonnering (reasoning models) |
|
||||
| Content processing tools | 8 per side | Dokument-/bildebehandling |
|
||||
|
||||
### Pay-as-you-go (Azure-basert)
|
||||
|
||||
**Microsoft 365 Copilot Chat & SharePoint agents:**
|
||||
- Meter: $0.01 per melding
|
||||
- Krever Azure-abonnement koblet til tenant
|
||||
- Capacity packs: 25,000 Copilot Credits per pack/måned
|
||||
|
||||
### Overage enforcement
|
||||
|
||||
- Når forbruk > 125% av prepaid capacity → agenter stenges
|
||||
- Løsning: Kjøp mer capacity, realoker eksisterende, eller aktiver pay-as-you-go
|
||||
|
||||
---
|
||||
|
||||
## Microsoft 365 Copilot
|
||||
|
||||
### Lisenskrav
|
||||
|
||||
**Grunnlag:**
|
||||
- Microsoft 365 E3/E5, A3/A5, Business Standard/Premium, eller tilsvarende
|
||||
|
||||
**Copilot-lisens:**
|
||||
- Per user/måned (priser varierer per region/avtale)
|
||||
- Vanligvis ~$30/user/måned (USA-priser)
|
||||
- Ingen minimum antall brukere (tidligere 300-bruker minimum er fjernet)
|
||||
|
||||
**Inkludert:**
|
||||
- Copilot i Word, Excel, PowerPoint, Outlook, Teams
|
||||
- Work-grounded chat (tilgang til SharePoint, OneDrive, Microsoft Graph)
|
||||
- Copilot Pages (kollaborativ AI-arbeidsflate)
|
||||
|
||||
**Microsoft 365 Copilot Chat (gratis):**
|
||||
- Inkludert for kvalifiserte M365-brukere (ingen ekstra kostnad)
|
||||
- Web-grounded chat (kun åpen web-data)
|
||||
- Begrenset funksjonalitet vs. full Copilot-lisens
|
||||
- Pay-as-you-go for tenant-data-tilgang (SharePoint-grounding)
|
||||
|
||||
### Cost drivers
|
||||
|
||||
- Antall lisensierte brukere
|
||||
- Bruk av pay-as-you-go for M365 Chat (kun for brukere uten full Copilot-lisens)
|
||||
- Extensibility (custom agents, connectors) → kan generere ekstra Copilot Credits-forbruk
|
||||
|
||||
---
|
||||
|
||||
## Power Platform AI (AI Builder)
|
||||
|
||||
### AI Builder Credits
|
||||
|
||||
**Kilder til credits:**
|
||||
- AI Builder capacity add-ons: 1,000,000 credits per pack
|
||||
- Per-user licenses (seeded capacity): 500–5,000 credits/måned (fases ut nov 2026)
|
||||
- Copilot Credits kan også brukes (fallback når AI Builder credits er oppbrukt)
|
||||
|
||||
### Prismodell
|
||||
|
||||
**AI Builder capacity add-on:**
|
||||
- Tier 1: 1 pack = 1M credits
|
||||
- Kjøpes som tenant-level capacity
|
||||
- Kan allokeres til spesifikke miljøer
|
||||
|
||||
**Forbruk:**
|
||||
- Resettes 1. hver måned
|
||||
- Ubrukte credits rulles **ikke** over til neste måned
|
||||
|
||||
### Credit consumption rates (per funksjon)
|
||||
|
||||
| Funksjon | Forbruk | Eksempel |
|
||||
|----------|---------|----------|
|
||||
| **Document processing** | Varierer (minimal/basic/standard) | Form processing: ~10–50 credits/dokument |
|
||||
| **Text recognition (OCR)** | Basic meter | ~5 credits per side |
|
||||
| **Prebuilt models** (f.eks. receipt processing) | Model-avhengig | Receipt: ~20 credits/kvittering |
|
||||
| **Custom models** | Avhenger av kompleksitet | Training: Gratis; Prediction: varierer |
|
||||
| **Prompt builder** | Se Copilot Credits tabell | Basic: 0.1 per 1K tokens |
|
||||
|
||||
**Overage-håndtering:**
|
||||
1. Først: Bruk AI Builder credits (environment eller tenant-level)
|
||||
2. Deretter: Bruk Copilot Credits (hvis tilgjengelig)
|
||||
3. Hvis ingen capacity: Blokkering av AI Builder-funksjoner
|
||||
|
||||
---
|
||||
|
||||
## Azure AI Foundry (AI Studio)
|
||||
|
||||
### Priskomponenter
|
||||
|
||||
Azure AI Foundry er en **orkestreringsplattform** som benytter flere Azure-tjenester. Kostnader er summen av:
|
||||
|
||||
**1. Kjerne-tjenester:**
|
||||
- Azure OpenAI Service (token-basert)
|
||||
- Azure AI Speech (per time audio)
|
||||
- Azure AI Vision (per transaksjon)
|
||||
- Azure Document Intelligence (per side)
|
||||
- Content Safety (per transaksjon)
|
||||
|
||||
**2. Infrastruktur:**
|
||||
- Compute (VM-timer for training/hosting)
|
||||
- Storage (database, files, logs)
|
||||
- Networking (bandwidth, private links)
|
||||
|
||||
**3. Spesialfunksjoner:**
|
||||
- Azure AI Search: $0.01–$0.10 per 1000 queries (tier-avhengig)
|
||||
- Vector storage: Kapasitetsbasert
|
||||
- Model router: Inkludert i token-prising (ingen ekstra kostnad)
|
||||
- Agent runtime: Code Interpreter sessions ($X per session-time)
|
||||
|
||||
### Foundry Agent Service
|
||||
|
||||
**Pricing breakdown:**
|
||||
- Inferens (base model): Token-based (se Azure OpenAI-priser)
|
||||
- Code Interpreter: Per session (default 1 time, idle timeout 30 min)
|
||||
- File Search: Vector storage-basert
|
||||
- Custom tools (Azure Functions): Functions Flex Consumption pricing
|
||||
|
||||
**Eksempel:** En agent som kjører 100 samtaler/dag med GPT-4o + Code Interpreter:
|
||||
- Tokens: ~200K input + 50K output = $2 + $1.50 = $3.50
|
||||
- Code Interpreter: 10 sessions × 1 time × $X = (sjekk aktuelle priser)
|
||||
|
||||
---
|
||||
|
||||
## Kostnadsscenarioer (norsk offentlig sektor)
|
||||
|
||||
### Scenario 1: Liten kommune (5000 innbyggere)
|
||||
|
||||
**Behov:** Enkel chatbot for innbyggerservice (åpningstider, avfallshenting, søknadsskjemaer)
|
||||
|
||||
**Løsning:** Copilot Studio
|
||||
- Estimat: 2000 samtaler/måned
|
||||
- Gjennomsnitt: 4 meldinger per samtale (2 classic + 2 generative)
|
||||
- Forbruk: `2000 × (2×1 + 2×2) = 12,000 Copilot Credits/måned`
|
||||
- Kostnad: Dekkes av basis-lisens (25,000 credits/måned)
|
||||
- Ekstra: Ingen
|
||||
|
||||
**Månedskostnad: ~$0 (innenfor gratis tier)**
|
||||
|
||||
---
|
||||
|
||||
### Scenario 2: Mellomstort fylke (20 ansatte, dokumentanalyse)
|
||||
|
||||
**Behov:** AI-assistent for saksbehandling (analysere PDF-dokumenter, generere sammendrag)
|
||||
|
||||
**Løsning:** Azure OpenAI + Document Intelligence
|
||||
- Estimat: 500 dokumenter/måned
|
||||
- Gjennomsnitt: 10 sider per dokument
|
||||
- Azure OpenAI (GPT-4o mini for sammendrag):
|
||||
- Input: ~1M tokens (200 tokens/side × 10 sider × 500 docs)
|
||||
- Output: ~100K tokens
|
||||
- Kostnad: `(1M × $0.165/M) + (0.1M × $0.66/M) = $0.165 + $0.066 = $0.23`
|
||||
- Document Intelligence:
|
||||
- OCR: 5000 sider × basic meter ≈ $25–$50
|
||||
- Storage/Compute: ~$10/måned
|
||||
|
||||
**Månedskostnad: ~$35–$60**
|
||||
|
||||
---
|
||||
|
||||
### Scenario 3: Statlig etat (500 brukere, M365 Copilot)
|
||||
|
||||
**Behov:** Produktivitetsverktøy for alle ansatte (Copilot i Word, Excel, Teams)
|
||||
|
||||
**Løsning:** Microsoft 365 Copilot
|
||||
- Lisenskrav: M365 E3 (~$36/user/måned) + Copilot (~$30/user/måned)
|
||||
- 500 brukere × $30 = **$15,000/måned**
|
||||
- Ingen ekstra forbrukskostnader (inkludert i per-user-lisens)
|
||||
|
||||
**Månedskostnad: ~$15,000 (kun Copilot-lisens)**
|
||||
|
||||
**Optimalisering:**
|
||||
- Start med pilot (50 brukere): $1,500/måned
|
||||
- Utvid gradvis basert på ROI-analyse
|
||||
|
||||
---
|
||||
|
||||
### Scenario 4: Universitet (RAG over forskningsdata)
|
||||
|
||||
**Behov:** Forsknings-assistent med RAG over 10 TB dokumenter
|
||||
|
||||
**Løsning:** Azure AI Foundry + Azure AI Search
|
||||
- Azure AI Search:
|
||||
- Basic tier: $0.10 per 1000 queries
|
||||
- 50,000 queries/måned: $5
|
||||
- Vector storage: ~$100/måned (avhenger av data-volum)
|
||||
- Azure OpenAI (GPT-4o):
|
||||
- RAG input: 5M tokens/måned
|
||||
- Output: 1M tokens/måned
|
||||
- Kostnad: `(5M × $10/M) + (1M × $30/M) = $50 + $30 = $80`
|
||||
- Compute (VM for hosting): ~$200/måned
|
||||
|
||||
**Månedskostnad: ~$385**
|
||||
|
||||
---
|
||||
|
||||
### Scenario 5: Stort departement (autonome agenter)
|
||||
|
||||
**Behov:** 10 autonome agenter for interne prosesser (ordrebehandling, HR-workflows, rapportering)
|
||||
|
||||
**Løsning:** Copilot Studio + Foundry Agent Service
|
||||
- Estimat: 100,000 agent-aksjoner/måned totalt
|
||||
- Copilot Credits forbruk:
|
||||
- Agent actions: 100,000 × 5 = 500,000 credits
|
||||
- Generative answers: 50,000 × 2 = 100,000 credits
|
||||
- Tenant graph grounding: 20,000 × 10 = 200,000 credits
|
||||
- Total: **800,000 credits/måned**
|
||||
- Capacity packs nødvendig: `800,000 / 25,000 = 32 packs`
|
||||
- Kostnad per pack: (sjekk aktuelle priser, typisk $200–$500/pack)
|
||||
|
||||
**Månedskostnad: ~$6,400–$16,000** (avhenger av faktisk pack-pris)
|
||||
|
||||
**Optimalisering:**
|
||||
- Bruk pay-as-you-go for variable bruk
|
||||
- Kombiner prepaid capacity (baseline) + PAYG (spikes)
|
||||
|
||||
---
|
||||
|
||||
## Lisensavhengigheter
|
||||
|
||||
### Azure OpenAI
|
||||
- **Krever:** Azure-abonnement
|
||||
- **RBAC-roller:** Cognitive Services User, Contributor
|
||||
- **Ingen per-user-lisenser:** Kun forbruksbasert
|
||||
|
||||
### Copilot Studio
|
||||
- **Krever:** Tenant-lisens (25K messages/måned)
|
||||
- **Valgfritt:** Per-user-lisens ($0) for makers
|
||||
- **M365 Copilot users:** Gratis bruk av custom agents (innenfor fair use)
|
||||
|
||||
### M365 Copilot
|
||||
- **Krever:** M365 E3/E5, A3/A5, Business Standard/Premium
|
||||
- **Per-user:** Copilot-lisens (~$30/user/måned)
|
||||
- **Ingen minimum:** (tidligere 300-bruker krav fjernet)
|
||||
|
||||
### Power Platform AI
|
||||
- **Standalone:** AI Builder capacity add-on (1M credits)
|
||||
- **Seeded capacity:** Power Apps Premium, Power Automate Premium (500–5000 credits/måned, fases ut nov 2026)
|
||||
- **Copilot Credits:** Kan brukes som fallback
|
||||
|
||||
### Azure AI Foundry
|
||||
- **Krever:** Azure-abonnement
|
||||
- **Per-service billing:** Hver AI-tjeneste prises separat
|
||||
- **RBAC:** AI User, AI Administrator
|
||||
|
||||
---
|
||||
|
||||
## Kostnadsoptimalisering
|
||||
|
||||
### Generelle strategier
|
||||
|
||||
**1. Right-size modellvalg**
|
||||
- Bruk GPT-4o-mini for enkle oppgaver → 94% billigere enn GPT-4o
|
||||
- Bruk GPT-3.5 Turbo for chat → 85% billigere enn GPT-4o
|
||||
- Bruk reasoning models (o1) kun for komplekse problemer
|
||||
|
||||
**2. Prompt engineering**
|
||||
- Kortere prompts = færre input tokens
|
||||
- System prompts: Gjenbruk på tvers av requests (ikke send hver gang)
|
||||
- Few-shot examples: Balanser kvalitet vs. token-kostnad
|
||||
|
||||
**3. Caching og deduplisering**
|
||||
- Cache vanlige svar (FAQ, standardsvar)
|
||||
- Bruk semantic search før RAG-kall (reduser unødvendige LLM-calls)
|
||||
- Implementer rate limiting for brukere
|
||||
|
||||
**4. Batch-prosessering**
|
||||
- Samle dokumentanalyse til batch-kjøringer
|
||||
- Bruk Azure Batch Inference (når tilgjengelig)
|
||||
|
||||
**5. Overvåkning og alerts**
|
||||
- Sett opp Azure Cost Management budgets
|
||||
- Alert ved 80%, 100%, 120% av budsjett
|
||||
- Månedlig review av største kostnadsdrivere
|
||||
|
||||
### Copilot Studio-spesifikke tips
|
||||
|
||||
**1. Bruk classic answers der mulig**
|
||||
- 1 credit vs. 2 credits (generative answer)
|
||||
- Predefinerte svar for vanlige spørsmål
|
||||
|
||||
**2. Unngå unødvendig tenant graph grounding**
|
||||
- 10 credits per melding
|
||||
- Aktiver kun for agenter som faktisk trenger Microsoft Graph-data
|
||||
|
||||
**3. Optimalisering av agent flows**
|
||||
- 13 credits per 100 actions → minimiser unødvendige flow-calls
|
||||
- Batch flere actions sammen
|
||||
|
||||
**4. Monitor overage**
|
||||
- Sett opp alerts før 125% threshold
|
||||
- Ha fallback til pay-as-you-go for kritiske agenter
|
||||
|
||||
### Azure OpenAI-spesifikke tips
|
||||
|
||||
**1. Use PTU for stabil, høy bruk**
|
||||
- Break-even: Typisk ved >100,000 requests/måned
|
||||
- Kjør cost calculator: `(monthly_tokens × pay-as-you-go_rate) vs. (PTU_monthly_cost)`
|
||||
|
||||
**2. Delete inactive fine-tuned deployments**
|
||||
- Hosting: $3–$10/time × 730 timer/måned = $2,190–$7,300/måned per modell
|
||||
- Auto-deletion ved 15 dager inaktivitet (men vær proaktiv)
|
||||
|
||||
**3. Bruk model router**
|
||||
- Automatisk routing til billigste modell som møter kravene
|
||||
- Ingen ekstra kostnad (inkludert i token-prising)
|
||||
|
||||
**4. Monitor HTTP error codes**
|
||||
- 400/408 errors: Du betaler (service prosesserte request)
|
||||
- 401/429 errors: Du betaler **ikke** (autentisering/rate limit)
|
||||
|
||||
### Azure AI Foundry-spesifikke tips
|
||||
|
||||
**1. Right-size compute**
|
||||
- Bruk autoscaling for variable workloads
|
||||
- Azure Spot VMs for fault-tolerant training (opptil 90% rabatt)
|
||||
- Reserved Instances for stabil bruk (1-3 år commitment)
|
||||
|
||||
**2. Storage optimization**
|
||||
- Bruk Azure Blob Storage lifecycle policies (hot → cool → archive)
|
||||
- Delete intermediate training data etter modell er trent
|
||||
|
||||
**3. Commitment tiers**
|
||||
- Bruk commitment tiers for Foundry Tools (fast fee vs. pay-as-you-go)
|
||||
- Vurder ved stabil, høy bruk
|
||||
|
||||
---
|
||||
|
||||
## Skjulte kostnader og gotchas
|
||||
|
||||
### Azure OpenAI
|
||||
- **Fine-tuning hosting:** Løper 24/7, også når ubrukt
|
||||
- **Vision models:** Bilder kan være 85–1105 tokens (avhenger av oppløsning)
|
||||
- **HTTP 4xx errors:** Du betaler hvis service prosesserte (400, 408), ikke ved autentisering (401, 429)
|
||||
|
||||
### Copilot Studio
|
||||
- **Overage enforcement:** Ved 125% → agenter stenges (ingen gradvis degradering)
|
||||
- **Tenant graph grounding:** 10 credits per melding (5x dyrere enn generative answer)
|
||||
- **M365 Copilot users:** "Fair use limits" ikke eksplisitt definert (Microsoft kan justere)
|
||||
|
||||
### M365 Copilot
|
||||
- **Krever M365 E3/E5:** Basislisens $36/user/måned + Copilot $30 = $66 totalt
|
||||
- **Extensibility costs:** Custom agents/connectors kan generere ekstra Copilot Credits-forbruk
|
||||
- **Pay-as-you-go for Chat:** Kun for brukere uten full Copilot-lisens (kan bli uventet dyrt)
|
||||
|
||||
### Power Platform AI
|
||||
- **Seeded credits fases ut:** Nov 2026 (planlegg overgangen nå)
|
||||
- **AI Builder credits rulles ikke over:** Bruk-eller-tap hver måned
|
||||
- **Copilot Credits fallback:** Hvis AI Builder credits er oppbrukt, brukes Copilot Credits (uten varsel)
|
||||
|
||||
### Azure AI Foundry
|
||||
- **Multi-service billing:** Costs spredt over mange Azure-tjenester (vanskelig å spore)
|
||||
- **Marketplace models:** Tredjepartsmodeller (Cohere, etc.) faktureres via Azure Marketplace (vises på resource group-nivå, ikke Foundry-ressurs)
|
||||
- **Code Interpreter sessions:** Hver parallell thread = ny session ($X/time)
|
||||
|
||||
---
|
||||
|
||||
## Regionsbasert prising (Nordic/Norge)
|
||||
|
||||
**Generelt:**
|
||||
- Azure-priser varierer per region (typisk +5–15% i Europa vs. USA)
|
||||
- Copilot Studio/M365 Copilot: Lik pris globalt (faktureres i USD/EUR)
|
||||
- **Norske regioner:** Norway East, Norway West (Azure)
|
||||
|
||||
**Anbefalinger:**
|
||||
- Bruk Norway East for produksjon (data residency)
|
||||
- Bruk West Europe for backup/DR (billigere, men data utenfor Norge)
|
||||
- Sjekk data residency-krav (offentlig sektor: ofte krav om Norge/EU)
|
||||
|
||||
**Cost comparison (Norway East vs. West Europe):**
|
||||
- Compute: ~10–15% dyrere i Norway East
|
||||
- Storage: ~5–10% dyrere i Norway East
|
||||
- OpenAI/Foundry Tools: Lik pris (global pricing)
|
||||
|
||||
---
|
||||
|
||||
## Cost Management verktøy
|
||||
|
||||
### Azure Cost Management
|
||||
- **Budgets:** Sett månedlige budsjetter per subscription/resource group
|
||||
- **Alerts:** Email/SMS ved 80%, 100%, 120% av budsjett
|
||||
- **Cost Analysis:** Drill-down per tjeneste, resource, tag
|
||||
- **Recommendations:** Azure Advisor anbefaler kostnadsbesparelser
|
||||
|
||||
### Power Platform Admin Center
|
||||
- **Copilot Credit monitoring:** Real-time forbruk per miljø
|
||||
- **AI Builder activity:** Per-modell forbruk
|
||||
- **Capacity allocation:** Fordeling av credits på miljøer
|
||||
|
||||
### Copilot Studio Analytics
|
||||
- **Telemetri:** Meldinger per dag/uke/måned
|
||||
- **Feature usage:** Hvilke features driver forbruk (generative answers, actions, etc.)
|
||||
- **Per-agent metrics:** Isoler kostnadsdrivere
|
||||
|
||||
### Third-party tools
|
||||
- **Azure Pricing Calculator:** Estimere kostnader før deployment
|
||||
- **Copilot Studio Estimator:** https://microsoft.github.io/copilot-studio-estimator/
|
||||
- **Power BI dashboards:** Custom rapportering (koble til Azure Cost Management API)
|
||||
|
||||
---
|
||||
|
||||
## Eksempel: Total Cost of Ownership (TCO) - Kommunal chatbot
|
||||
|
||||
**Scenario:** Innbyggerservice chatbot for 30,000 innbyggere
|
||||
|
||||
**Antagelser:**
|
||||
- 5% av innbyggere bruker chatbot/måned = 1,500 brukere
|
||||
- 3 samtaler per bruker = 4,500 samtaler/måned
|
||||
- 5 meldinger per samtale = 22,500 meldinger/måned
|
||||
|
||||
**Løsning:** Copilot Studio
|
||||
|
||||
**Kostnadsberegning:**
|
||||
|
||||
| Komponent | Forbruk | Rate | Kostnad |
|
||||
|-----------|---------|------|---------|
|
||||
| Classic answers (2 per samtale) | 9,000 meldinger | 1 credit | 9,000 credits |
|
||||
| Generative answers (3 per samtale) | 13,500 meldinger | 2 credits | 27,000 credits |
|
||||
| **Total månedlig forbruk** | | | **36,000 credits** |
|
||||
| Basis-lisens (inkludert) | | | 25,000 credits |
|
||||
| **Overskudd** | | | **11,000 credits** |
|
||||
|
||||
**Løsning:** Kjøp 1 ekstra capacity pack (25,000 credits)
|
||||
|
||||
**Månedskostnad:**
|
||||
- Copilot Studio tenant-lisens: (sjekk aktuelle priser)
|
||||
- Ekstra capacity pack: ~$200–$500/måned
|
||||
|
||||
**Årskostnad:** ~$2,400–$6,000 + tenant-lisens
|
||||
|
||||
**Skjulte kostnader:**
|
||||
- Oppsett/utvikling: 40–80 timer × $100/time = $4,000–$8,000 (engangs)
|
||||
- Vedlikehold: 5 timer/måned × $100/time = $500/måned
|
||||
- Training/opplæring: $1,000–$2,000 (engangs)
|
||||
|
||||
**Total TCO (år 1):** ~$15,000–$25,000
|
||||
|
||||
---
|
||||
|
||||
## Anbefalinger for norsk offentlig sektor
|
||||
|
||||
### 1. Start smått
|
||||
- Pilot med 1–2 use cases
|
||||
- Bruk gratis tiers der mulig (Copilot Studio 25K messages, M365 Chat)
|
||||
- Mål ROI før skalering
|
||||
|
||||
### 2. Etabler governance
|
||||
- Sett budsjetter per prosjekt/enhet
|
||||
- Krev cost-benefit-analyse før deployment
|
||||
- Månedlig review av faktiske kostnader vs. estimat
|
||||
|
||||
### 3. Skill mellom pilot og produksjon
|
||||
- Pilot: Pay-as-you-go (fleksibilitet)
|
||||
- Produksjon: Commitment tiers / PTU (forutsigbarhet)
|
||||
|
||||
### 4. Optimaliser kontinuerlig
|
||||
- Månedlig review av største kostnadsdrivere
|
||||
- Quarterly model evaluation (er GPT-4o fortsatt nødvendig, eller holder GPT-4o-mini?)
|
||||
- Deaktiver ubrukte ressurser (fine-tuned models, deployments)
|
||||
|
||||
### 5. Data residency
|
||||
- Bruk Norway East for persondata
|
||||
- Evaluer GDPR/Schrems II-implikasjoner
|
||||
- Sjekk leverandøravtaler (DPA, databehandleravtale)
|
||||
|
||||
### 6. Opplæring og kompetanse
|
||||
- Invester i AI literacy (reduserer "trial-and-error"-kostnader)
|
||||
- Etabler senter for kompetanse (tverrfaglig, delt kunnskap)
|
||||
|
||||
---
|
||||
|
||||
## Ressurser
|
||||
|
||||
**Offisielle prisguider:**
|
||||
- [Azure Pricing Calculator](https://azure.microsoft.com/pricing/calculator/)
|
||||
- [Azure OpenAI Pricing](https://azure.microsoft.com/pricing/details/cognitive-services/openai-service/)
|
||||
- [Copilot Studio Licensing Guide](https://go.microsoft.com/fwlink/?linkid=2320995)
|
||||
- [Power Platform Licensing Guide](https://go.microsoft.com/fwlink/?linkid=2085130)
|
||||
|
||||
**Kostnadsestimering:**
|
||||
- [Copilot Studio Estimator](https://microsoft.github.io/copilot-studio-estimator/)
|
||||
- [Azure Cost Management](https://azure.microsoft.com/services/cost-management/)
|
||||
|
||||
**Dokumentasjon:**
|
||||
- [Azure OpenAI Cost Management](https://learn.microsoft.com/azure/ai-foundry/openai/how-to/manage-costs)
|
||||
- [Copilot Studio Billing](https://learn.microsoft.com/microsoft-copilot-studio/requirements-messages-management)
|
||||
- [AI Builder Credit Management](https://learn.microsoft.com/ai-builder/credit-management)
|
||||
|
||||
---
|
||||
|
||||
## Versjonshistorikk
|
||||
|
||||
- **2026-01:** Opprettet (basert på microsoft-learn MCP research)
|
||||
- **Disclaimer:** Priser endres hyppig; verifiser alltid via offisielle kilder før budsjettbeslutninger.
|
||||
|
|
@ -0,0 +1,242 @@
|
|||
# Decision Trees for Microsoft AI
|
||||
|
||||
Akkumulerte beslutningstrær og arkitekturmønstre for Microsoft AI-stakken.
|
||||
|
||||
---
|
||||
|
||||
## 1. Plattformvalg: Copilot vs Studio vs Foundry
|
||||
|
||||
```
|
||||
START: Hvem skal bruke løsningen?
|
||||
│
|
||||
├─► Informasjonsarbeidere (produktivitet i M365)
|
||||
│ │
|
||||
│ └─► Har de M365 E3/E5?
|
||||
│ ├─► Ja → Trenger de custom agenter?
|
||||
│ │ ├─► Nei → M365 COPILOT (out-of-box)
|
||||
│ │ └─► Ja → Er det enkle Q&A-agenter?
|
||||
│ │ ├─► Ja → AGENT BUILDER (i M365)
|
||||
│ │ └─► Nei → COPILOT STUDIO
|
||||
│ │
|
||||
│ └─► Nei → Vurder lisensoppgradering eller Copilot Chat (gratis)
|
||||
│
|
||||
├─► Business users / Citizen developers
|
||||
│ │
|
||||
│ └─► Har de Power Platform?
|
||||
│ ├─► Ja → COPILOT STUDIO
|
||||
│ └─► Nei → Vurder Power Platform-lisenser
|
||||
│
|
||||
└─► Utviklere / Data scientists
|
||||
│
|
||||
└─► Trenger de multi-model tilgang?
|
||||
├─► Ja → AZURE AI FOUNDRY
|
||||
│
|
||||
└─► Nei → Kun OpenAI API-kall?
|
||||
├─► Ja, enkelt → AZURE OPENAI (direkte)
|
||||
└─► Nei, orkestrering → AZURE AI FOUNDRY
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. Agenttype-valg
|
||||
|
||||
```
|
||||
START: Hva skal agenten gjøre?
|
||||
│
|
||||
├─► Besvare spørsmål basert på dokumenter
|
||||
│ │
|
||||
│ └─► Hvem er brukerne?
|
||||
│ ├─► Interne ansatte i M365 → M365 COPILOT + DECLARATIVE AGENT
|
||||
│ ├─► Kunder/eksterne → COPILOT STUDIO (web/WhatsApp)
|
||||
│ └─► Begge → COPILOT STUDIO med auth
|
||||
│
|
||||
├─► Utføre handlinger i andre systemer
|
||||
│ │
|
||||
│ └─► Er det Power Platform connectors?
|
||||
│ ├─► Ja → COPILOT STUDIO + Actions
|
||||
│ └─► Nei → FOUNDRY AGENT SERVICE + Custom APIs
|
||||
│
|
||||
├─► Kjøre autonomt i bakgrunnen
|
||||
│ │
|
||||
│ └─► Trigges av hendelser i M365?
|
||||
│ ├─► Ja → COPILOT STUDIO AUTONOMOUS AGENT
|
||||
│ └─► Nei → FOUNDRY AGENT SERVICE
|
||||
│
|
||||
└─► Multi-agent orkestrering
|
||||
│
|
||||
└─► Kompleksitet?
|
||||
├─► Moderat → COPILOT STUDIO + MCP
|
||||
└─► Høy / Forretningskritisk → FOUNDRY AGENT SERVICE
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. RAG-arkitektur
|
||||
|
||||
```
|
||||
START: Hvor er dataene?
|
||||
│
|
||||
├─► Primært i M365 (SharePoint, OneDrive, Teams)
|
||||
│ │
|
||||
│ └─► Har M365 Copilot-lisenser?
|
||||
│ ├─► Ja → Trenger custom app?
|
||||
│ │ ├─► Nei → M365 COPILOT (out-of-box)
|
||||
│ │ ├─► Low-code agent → COPILOT STUDIO (tenant graph)
|
||||
│ │ └─► Custom app → M365 RETRIEVAL API
|
||||
│ │
|
||||
│ └─► Nei → AZURE AI SEARCH + SharePoint indexer
|
||||
│
|
||||
├─► Azure Blob/ADLS/OneLake
|
||||
│ │
|
||||
│ └─► Trenger custom chunking?
|
||||
│ ├─► Nei → AZURE AI SEARCH (integrated vectorization)
|
||||
│ └─► Ja → AZURE AI SEARCH + Custom skillset
|
||||
│
|
||||
├─► Databaser (SQL, Cosmos DB)
|
||||
│ │
|
||||
│ └─► Structured data → AZURE AI SEARCH + Cosmos DB indexer
|
||||
│ eller → MS AGENT FRAMEWORK + Cosmos DB Vector
|
||||
│
|
||||
├─► Multiple kilder
|
||||
│ │
|
||||
│ └─► Kompleksitet?
|
||||
│ ├─► Moderat → AZURE AI SEARCH (hybrid)
|
||||
│ └─► Høy → AGENTIC RETRIEVAL (preview)
|
||||
│
|
||||
└─► Full kontroll påkrevd
|
||||
└─► MS AGENT FRAMEWORK + Custom vector store
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Sikkerhetsnivå
|
||||
|
||||
```
|
||||
START: Hvilke compliance-krav?
|
||||
│
|
||||
├─► Offentlig sektor / Høy sensitivitet
|
||||
│ │
|
||||
│ └─► Er EU Data Boundary tilstrekkelig?
|
||||
│ ├─► Ja → M365 COPILOT eller COPILOT STUDIO (EU region)
|
||||
│ │ + Microsoft Purview for governance
|
||||
│ │ + Sensitivity labels
|
||||
│ │
|
||||
│ └─► Nei, strengere krav → AZURE AI FOUNDRY
|
||||
│ + Private endpoints
|
||||
│ + Customer-managed keys
|
||||
│ + Defender for Cloud AI SPM
|
||||
│
|
||||
├─► Enterprise / Standard compliance
|
||||
│ │
|
||||
│ └─► Intern eller ekstern bruk?
|
||||
│ ├─► Intern → Standard konfigurasjon OK
|
||||
│ │ + Azure AD / Entra ID auth
|
||||
│ │ + Default content filters
|
||||
│ │
|
||||
│ └─► Ekstern → COPILOT STUDIO eller FOUNDRY
|
||||
│ + Azure AI Content Safety
|
||||
│ + Prompt Shields aktivert
|
||||
│ + Rate limiting
|
||||
│
|
||||
├─► Starter opp / Lav risiko
|
||||
│ │
|
||||
│ └─► Default sikkerhet er typisk tilstrekkelig
|
||||
│ + API keys OK for prototyping
|
||||
│ + Managed identity for produksjon
|
||||
│
|
||||
└─► Regulert industri (finans, helse)
|
||||
│
|
||||
└─► HIPAA?
|
||||
├─► Ja → Verifiser HIPAA BAA
|
||||
│ + M365 Copilot (med riktig lisens)
|
||||
│ + Azure AI (HIPAA-eligible services)
|
||||
│
|
||||
└─► Nei, annen regulering → Verifiser compliance-sertifiseringer
|
||||
+ ISO 27001, SOC 2, etc.
|
||||
+ Data residency-krav
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Kostnadsoptimalisering
|
||||
|
||||
```
|
||||
START: Hva er budsjettsituasjonen?
|
||||
│
|
||||
├─► Stram / Må minimere kostnader
|
||||
│ │
|
||||
│ └─► Har allerede M365 Copilot-lisenser?
|
||||
│ ├─► Ja → Utnytt inkluderte features først
|
||||
│ │ + Agent Builder (gratis med lisens)
|
||||
│ │ + Copilot Studio i M365/Teams (inkludert)
|
||||
│ │
|
||||
│ └─► Nei → Pay-as-you-go
|
||||
│ + Azure OpenAI direkte
|
||||
│ + Copilot Credits ($0.01/credit)
|
||||
│
|
||||
├─► Moderat / Forutsigbarhet viktig
|
||||
│ │
|
||||
│ └─► PREPAID SUBSCRIPTIONS
|
||||
│ + Copilot Credits monthly pool
|
||||
│ + Azure Reserved Capacity
|
||||
│
|
||||
├─► Fleksibel / Optimalisering viktig
|
||||
│ │
|
||||
│ └─► FOUNDRY MODEL ROUTER
|
||||
│ + Cost mode for høyvolum
|
||||
│ + Smaller models for enklere oppgaver
|
||||
│ + GPT-5-mini vs GPT-5-pro
|
||||
│
|
||||
└─► Ukjent / Trenger estimat
|
||||
└─► Bruk ESTIMERINGSVERKTØY
|
||||
+ Microsoft Copilot Studio estimator
|
||||
+ Azure Pricing Calculator
|
||||
+ Pilot med logging av token-bruk
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference: Plattform-egenskaper
|
||||
|
||||
| Egenskap | M365 Copilot | Copilot Studio | Azure AI Foundry |
|
||||
|----------|--------------|----------------|------------------|
|
||||
| **Målgruppe** | Informasjonsarbeidere | Makers, citizen devs | Utviklere |
|
||||
| **Tilnærming** | Out-of-box | Low-code | Code-first |
|
||||
| **Modeller** | GPT (managed) | GPT + custom | 11,000+ |
|
||||
| **Data access** | M365 Graph | Graph + 1000 connectors | Custom |
|
||||
| **Governance** | M365 admin | PP admin center | Azure RBAC |
|
||||
| **Pris** | ~$30/user/mnd | Pay-per-message | Pay-per-token |
|
||||
| **Time-to-value** | Timer | Dager | Uker |
|
||||
| **Fleksibilitet** | Lav | Medium | Høy |
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference: Sikkerhet per plattform
|
||||
|
||||
| Sikkerhetsfunksjon | M365 Copilot | Copilot Studio | Azure AI Foundry |
|
||||
|-------------------|--------------|----------------|------------------|
|
||||
| EU Data Boundary | ✓ | ✓ (EU region) | ✓ (velg region) |
|
||||
| Managed Identity | N/A | ✓ | ✓ |
|
||||
| Private Endpoints | N/A | ✗ | ✓ |
|
||||
| Customer-managed keys | ✗ | Preview | ✓ |
|
||||
| Content Safety | Built-in | Built-in | Konfigurerbar |
|
||||
| Prompt Shields | Built-in | Built-in | Konfigurerbar |
|
||||
| Purview integration | ✓ | ✓ | ✓ |
|
||||
| Defender for Cloud | ✓ | ✓ | ✓ |
|
||||
| HIPAA | ✓ | ✓ | ✓ |
|
||||
| ISO 27001 | ✓ | ✓ | ✓ |
|
||||
|
||||
---
|
||||
|
||||
## Kilder og verifisering
|
||||
|
||||
Original analysis synthesized from platform reference files in this knowledge base, which are derived from Microsoft Learn documentation ([CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)):
|
||||
|
||||
- `platforms/m365-copilot.md` — M365 Copilot capabilities and licensing
|
||||
- `platforms/copilot-studio.md` — Copilot Studio features and use cases
|
||||
- `platforms/azure-ai-foundry.md` — Azure AI Foundry architecture and pricing
|
||||
- `platforms/power-platform.md` — Power Platform AI capabilities
|
||||
|
||||
Decision trees and decision guidance are original work.
|
||||
|
||||
*Sist oppdatert: Januar 2026*
|
||||
|
|
@ -0,0 +1,256 @@
|
|||
# Diagram Prompt Templates for Imagen 3
|
||||
|
||||
**Sist oppdatert:** 2026-02 (v1.0)
|
||||
**Målgruppe:** diagram-generation-agent
|
||||
**Format:** Prompt-maler for `mcp__mcp-image__generate_image` (Imagen 3 / Nano Banana Pro)
|
||||
|
||||
---
|
||||
|
||||
## Azure-stilkonstanter
|
||||
|
||||
Alle diagrammer skal følge Microsofts visuelle identitet:
|
||||
|
||||
| Element | Verdi |
|
||||
|---------|-------|
|
||||
| Primærfarge | `#0078D4` (Azure Blue) |
|
||||
| Sekundærfarge | `#50E6FF` (Azure Cyan) |
|
||||
| Aksentfarge | `#FFB900` (Warning/Gold) |
|
||||
| Bakgrunn | Hvit eller svært lys grå |
|
||||
| Fontstil | Clean sans-serif (Segoe UI-lignende) |
|
||||
| Ikondesign | Flat, moderne, Microsoft Fluent-stil |
|
||||
| Layout | Venstre-til-høyre eller topp-til-bunn |
|
||||
| Aspect ratio | 16:9 (standard for presentasjoner) |
|
||||
|
||||
### Generelle regler for alle diagrammer
|
||||
|
||||
- Bruk flat design med tydelige bokser og piler
|
||||
- Unngå 3D-effekter, skygger eller gradienter
|
||||
- Tekst skal være stor nok til å lese i en presentasjon
|
||||
- Bruk Azure-ikoner der mulig (stiliserte, ikke detaljerte)
|
||||
- Grupper relaterte komponenter med fargebokser
|
||||
- Nummerer steg i dataflyt-diagrammer
|
||||
|
||||
---
|
||||
|
||||
## Mal 1: Arkitekturoversikt
|
||||
|
||||
**Brukes i:** S8.2 (alltid, alle kompleksitetsnivåer)
|
||||
**Formål:** Vise hele løsningens arkitektur med komponenter og dataflyten mellom dem.
|
||||
|
||||
### Prompt-mal
|
||||
|
||||
```
|
||||
Professional Microsoft Azure architecture diagram in flat design style.
|
||||
|
||||
Components: [KOMPONENT_LISTE]
|
||||
|
||||
Layout: Clean left-to-right or top-to-bottom flow diagram showing data flow between components.
|
||||
|
||||
Visual style:
|
||||
- Azure blue (#0078D4) for primary services
|
||||
- Cyan (#50E6FF) for data stores
|
||||
- White background with light gray grouping boxes
|
||||
- Flat modern icons for each Azure service (Fluent design style)
|
||||
- Clear labeled arrows showing data flow direction
|
||||
- Component names in clean sans-serif font
|
||||
- Grouped by layer: User → Orchestration → AI Services → Data
|
||||
|
||||
Technical diagram, presentation quality, 16:9 aspect ratio, no 3D effects, no gradients.
|
||||
```
|
||||
|
||||
### Eksempel (Copilot Studio + RAG)
|
||||
|
||||
```
|
||||
Professional Microsoft Azure architecture diagram in flat design style.
|
||||
|
||||
Components:
|
||||
- User (browser/Teams) connects to Copilot Studio
|
||||
- Copilot Studio orchestrates the flow
|
||||
- Azure OpenAI (GPT-4o) processes queries
|
||||
- Azure AI Search provides RAG retrieval
|
||||
- SharePoint Online as document source
|
||||
- Azure AI Content Safety filters content
|
||||
- Microsoft Entra ID handles authentication
|
||||
- Application Insights monitors the system
|
||||
|
||||
Layout: Clean top-to-bottom flow diagram showing data flow between components.
|
||||
|
||||
Visual style:
|
||||
- Azure blue (#0078D4) for primary services
|
||||
- Cyan (#50E6FF) for data stores
|
||||
- White background with light gray grouping boxes
|
||||
- Flat modern icons for each Azure service (Fluent design style)
|
||||
- Clear labeled arrows showing data flow direction
|
||||
- Grouped by layer: User → Orchestration → AI/Search → Data → Security/Monitoring
|
||||
|
||||
Technical diagram, presentation quality, 16:9 aspect ratio, no 3D effects, no gradients.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Mal 2: Sikkerhetssoner
|
||||
|
||||
**Brukes i:** S5.1 (middels + kompleks)
|
||||
**Formål:** Vise sikkerhetslag, tilgangskontroll og databeskyttelse.
|
||||
|
||||
### Prompt-mal
|
||||
|
||||
```
|
||||
Microsoft Azure security zones architecture diagram in flat design style.
|
||||
|
||||
Security layers:
|
||||
- External zone: [EKSTERNE_KOMPONENTER]
|
||||
- DMZ / Edge: [EDGE_KOMPONENTER]
|
||||
- Application zone: [APP_KOMPONENTER]
|
||||
- Data zone: [DATA_KOMPONENTER]
|
||||
- Management zone: [MGMT_KOMPONENTER]
|
||||
|
||||
Visual style:
|
||||
- Concentric colored zones from outside (red-tinted) to inside (green-tinted)
|
||||
- Azure blue (#0078D4) for identity services
|
||||
- Gold (#FFB900) for security checkpoints
|
||||
- Lock icons at zone boundaries
|
||||
- Shield icon for Content Safety
|
||||
- Key icon for encryption/Key Vault
|
||||
- Clean labeled arrows showing allowed traffic flow
|
||||
|
||||
Security architecture diagram, presentation quality, 16:9 aspect ratio, no 3D effects.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Mal 3: Dataflyt / RAG-pipeline
|
||||
|
||||
**Brukes i:** S4.3 (når RAG er involvert)
|
||||
**Formål:** Vise how data flows through the RAG pipeline from source to response.
|
||||
|
||||
### Prompt-mal
|
||||
|
||||
```
|
||||
Microsoft Azure RAG (Retrieval-Augmented Generation) pipeline diagram in flat design style.
|
||||
|
||||
Pipeline steps:
|
||||
1. Data ingestion: [DATAKILDER] → Document processing
|
||||
2. Chunking: [CHUNKING_STRATEGI]
|
||||
3. Embedding: [EMBEDDING_MODELL] generates vectors
|
||||
4. Indexing: Vectors stored in [INDEKS_TJENESTE]
|
||||
5. Query flow: User query → [ORKESTRERING] → Hybrid search → Reranking
|
||||
6. Generation: Retrieved context + query → [LLM_MODELL] → Response
|
||||
7. Safety: [SIKKERHETSTILTAK]
|
||||
|
||||
Visual style:
|
||||
- Numbered steps flowing left to right
|
||||
- Azure blue (#0078D4) for AI services
|
||||
- Cyan (#50E6FF) for data stores and indexes
|
||||
- Green for successful output
|
||||
- Orange arrows for data ingestion pipeline (top)
|
||||
- Blue arrows for query pipeline (bottom)
|
||||
- Two parallel lanes: Ingestion (top) and Query (bottom)
|
||||
|
||||
Technical RAG pipeline diagram, presentation quality, 16:9 aspect ratio, no 3D effects.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Mal 4: Problem → Løsning
|
||||
|
||||
**Brukes i:** S2.1 (middels + kompleks)
|
||||
**Formål:** Visuelt kontrastere nåsituasjon (problem) med fremtidig situasjon (løsning).
|
||||
|
||||
### Prompt-mal
|
||||
|
||||
```
|
||||
Before and after comparison diagram for AI solution implementation.
|
||||
|
||||
Left side (BEFORE - current state):
|
||||
- Title: "Nåsituasjon"
|
||||
- [PROBLEM_ELEMENTER]
|
||||
- Visual tone: Gray, cluttered, manual process indicators
|
||||
- Red warning indicators for pain points
|
||||
|
||||
Right side (AFTER - with AI solution):
|
||||
- Title: "Med AI-løsning"
|
||||
- [LØSNING_ELEMENTER]
|
||||
- Visual tone: Azure blue, streamlined, automated flow
|
||||
- Green checkmarks for improvements
|
||||
|
||||
Center: Large arrow pointing from left to right with "[PLATTFORM]" label
|
||||
|
||||
Visual style:
|
||||
- Split layout: left (gray/red) vs right (blue/green)
|
||||
- Clean icons representing users, processes, systems
|
||||
- Metrics showing improvement (e.g., "14 dager → 2 timer")
|
||||
- Azure blue (#0078D4) dominates the right side
|
||||
- Professional infographic style
|
||||
|
||||
Comparison diagram, presentation quality, 16:9 aspect ratio, no 3D effects.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Mal 5: Implementeringstidslinje
|
||||
|
||||
**Brukes i:** S9.1 (middels + kompleks)
|
||||
**Formål:** Vise faseplan med milepæler og leveranser over tid.
|
||||
|
||||
### Prompt-mal
|
||||
|
||||
```
|
||||
Implementation roadmap timeline diagram for Microsoft AI project.
|
||||
|
||||
Phases:
|
||||
- Phase 0: Preparation - [FORBEREDELSE_AKTIVITETER]
|
||||
- Phase 1: POC - [POC_AKTIVITETER]
|
||||
- Phase 2: MVP - [MVP_AKTIVITETER]
|
||||
- Phase 3: Production - [PRODUKSJON_AKTIVITETER]
|
||||
- Phase 4: Optimization - [OPTIMALISERING_AKTIVITETER]
|
||||
|
||||
Key milestones: [MILEPÆLER]
|
||||
|
||||
Visual style:
|
||||
- Horizontal timeline flowing left to right
|
||||
- Phase blocks as colored segments growing in width
|
||||
- Azure blue (#0078D4) gradient from light (Phase 0) to dark (Phase 3)
|
||||
- Gold (#FFB900) diamond markers for milestones
|
||||
- Small icons above each phase representing key activities
|
||||
- Clean sans-serif labels
|
||||
- Go/No-Go decision points marked clearly
|
||||
|
||||
Project roadmap diagram, presentation quality, 16:9 aspect ratio, no 3D effects.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Imagen 3-spesifikke tips
|
||||
|
||||
### Hva fungerer godt
|
||||
- Klare, beskrivende prompts med eksplisitt layout
|
||||
- Spesifisering av farger med hex-koder
|
||||
- "Professional", "technical diagram", "flat design" som stilord
|
||||
- Eksplisitt aspect ratio (16:9)
|
||||
- Numbered lists for sekvensielle flytsteg
|
||||
|
||||
### Hva bør unngås
|
||||
- For mye tekst i prompten (hold under 300 ord)
|
||||
- Vage instruksjoner ("make it look nice")
|
||||
- Krav om spesifikke fonter (modellen velger selv)
|
||||
- Detaljerte Azure-ikonkrav (beskriv heller stilen)
|
||||
- Forventning om lesbar tekst i diagrammet (bruk heller få, store labels)
|
||||
|
||||
### Bildekvalitet
|
||||
- Be alltid om "presentation quality"
|
||||
- Spesifiser 16:9 for slides, 1:1 for dokumenter
|
||||
- Unngå å be om for mange elementer (maks 10-12 bokser)
|
||||
- Grupper elementer i lag for bedre lesbarhet
|
||||
|
||||
---
|
||||
|
||||
## For diagram-generation-agent
|
||||
|
||||
Bruk disse malene som utgangspunkt, men tilpass til det spesifikke scenarioet:
|
||||
|
||||
1. **Velg riktig mal** basert på diagramtype fra oppdraget
|
||||
2. **Erstatt placeholder-tekst** ([KOMPONENT_LISTE] etc.) med reelle verdier fra arkitekturbeslutningene
|
||||
3. **Tilpass visuell stil** til kompleksitetsnivået — enklere for enkel, mer detaljert for kompleks
|
||||
4. **Generer bildet** med `mcp__mcp-image__generate_image`
|
||||
5. **Hvis generering feiler** — returner den ferdig utfylte promptteksten så brukeren kan bruke den manuelt
|
||||
|
|
@ -0,0 +1,593 @@
|
|||
# Licensing Matrix - Microsoft AI Capabilities
|
||||
|
||||
**Last updated:** 2026-01 (research via microsoft-learn MCP)
|
||||
**Disclaimer:** Licensing changes frequently. Verify at microsoft.com/licensing
|
||||
|
||||
---
|
||||
|
||||
## Innledning
|
||||
|
||||
Denne referansen gir en komplett oversikt over hvordan Microsoft-lisenser gir tilgang til ulike AI-funksjoner. Dette er kritisk for arkitekturvalg — feil antakelser om lisenskrav kan føre til budsjettsprekk eller tekniske begrensninger.
|
||||
|
||||
**Viktig:** Microsoft går over til Copilot Credits som felles valuta for mange AI-tjenester. AI Builder credits fases ut gradvis (seeded credits fjernes 1. november 2026).
|
||||
|
||||
---
|
||||
|
||||
## 1. Master Licensing Matrix
|
||||
|
||||
### M365 Copilot & AI Features
|
||||
|
||||
| License | M365 Copilot | Copilot Chat (web) | Copilot Chat (work) | AI Builder Credits | Power Platform AI | Azure AI | Copilot Studio |
|
||||
|---------|--------------|--------------------|--------------------|-------------------|-------------------|----------|----------------|
|
||||
| **Microsoft 365 E3** | 💰 Add-on required | ✅ Included | 💰 Requires M365 Copilot | 500/user* | Standard connectors | ❌ Separate Azure sub | ❌ Requires Copilot Studio license |
|
||||
| **Microsoft 365 E5** | 💰 Add-on required | ✅ Included | 💰 Requires M365 Copilot | 500/user* | Standard connectors | ❌ Separate Azure sub | ❌ Requires Copilot Studio license |
|
||||
| **Microsoft 365 Business Basic** | 💰 Add-on required | ✅ Included | 💰 Requires M365 Copilot | ❌ Not included | Standard connectors | ❌ Separate Azure sub | ❌ Requires Copilot Studio license |
|
||||
| **Microsoft 365 Business Standard** | 💰 Add-on required | ✅ Included | 💰 Requires M365 Copilot | ❌ Not included | Standard connectors | ❌ Separate Azure sub | ❌ Requires Copilot Studio license |
|
||||
| **Microsoft 365 Business Premium** | 💰 Add-on required | ✅ Included | 💰 Requires M365 Copilot | ❌ Not included | Standard connectors | ❌ Separate Azure sub | ❌ Requires Copilot Studio license |
|
||||
| **Office 365 E3/E5** | 💰 Add-on required | ✅ Included | 💰 Requires M365 Copilot | ❌ Not included | ❌ Requires Power Platform | ❌ Separate Azure sub | ❌ Requires Copilot Studio license |
|
||||
| **Microsoft 365 F1/F3** | 💰 Add-on required | ✅ Included | 💰 Requires M365 Copilot | ❌ Not included | Limited | ❌ Separate Azure sub | ❌ Requires Copilot Studio license |
|
||||
|
||||
*\*AI Builder seeded credits fjernes 1. november 2026*
|
||||
|
||||
### Power Platform Licenses
|
||||
|
||||
| License | AI Builder Credits (monthly) | Copilot Studio Access | Premium Connectors | RPA Capabilities |
|
||||
|---------|------------------------------|----------------------|-------------------|------------------|
|
||||
| **Power Apps Premium** | 500/user* | ❌ Separate license | ✅ Included | ❌ Separate license |
|
||||
| **Power Apps Per App** | 250/user* | ❌ Separate license | ❌ Standard only | ❌ Separate license |
|
||||
| **Power Automate Premium** | 5,000/user* | ❌ Separate license | ✅ Included | ✅ Attended RPA |
|
||||
| **Power Automate Process** | 5,000/license* | ❌ Separate license | ✅ Included | ✅ Unattended RPA |
|
||||
| **AI Builder Add-on** | 1,000,000/add-on | ❌ Separate license | N/A | N/A |
|
||||
| **Copilot Studio Standalone** | N/A (uses Copilot Credits) | ✅ Full access | ✅ Premium included | N/A |
|
||||
|
||||
*\*Seeded credits fjernes 1. november 2026. Max 1,000,000 credits per tenant for per-user licenses.*
|
||||
|
||||
### Azure AI Services
|
||||
|
||||
| License Type | Cost Model | Capabilities | Prerequisites |
|
||||
|--------------|-----------|--------------|---------------|
|
||||
| **Azure Free Tier** | Free (limited) | 1 free search service, limited AI services calls | Azure subscription |
|
||||
| **Azure Pay-as-you-go** | Consumption-based | Full Azure AI portfolio | Azure subscription, payment method |
|
||||
| **Azure Enterprise Agreement** | Committed spend | Full Azure AI portfolio + volume discounts | EA contract |
|
||||
| **Azure AI Foundry** | Consumption-based | Model catalog, prompt flow, evaluation | Azure subscription |
|
||||
| **Azure OpenAI Service** | Token-based pricing | GPT-4, GPT-3.5, Embeddings, DALL-E | Azure subscription, application approval |
|
||||
|
||||
---
|
||||
|
||||
## 2. License Profiles - Hva Får Du Med Hver Lisens?
|
||||
|
||||
### Microsoft 365 E3
|
||||
|
||||
**Pris:** ~€36/user/month (EA pricing, Norway)
|
||||
|
||||
**AI-funksjoner inkludert:**
|
||||
- ✅ Copilot Chat (web-based, public data only)
|
||||
- ✅ Basic Microsoft Graph access
|
||||
- ✅ SharePoint Advanced Management (when using M365 Copilot)
|
||||
- ✅ 500 AI Builder credits/user/month (til nov 2026)
|
||||
- ✅ Basic sensitivity labels
|
||||
- ✅ Basic DLP (SharePoint, Exchange, OneDrive)
|
||||
|
||||
**AI-funksjoner som krever add-on:**
|
||||
- 💰 Microsoft 365 Copilot (~$30/user/month)
|
||||
- 💰 Copilot Studio (~$200/month tenant + user licenses)
|
||||
- 💰 AI Builder credits beyond seeded amount
|
||||
- 💰 Advanced DLP (Teams, Endpoints)
|
||||
|
||||
**Best for:** Organisasjoner som vil teste Copilot Chat uten full Copilot-investering.
|
||||
|
||||
---
|
||||
|
||||
### Microsoft 365 E5
|
||||
|
||||
**Pris:** ~€57/user/month (EA pricing, Norway)
|
||||
|
||||
**AI-funksjoner inkludert (utover E3):**
|
||||
- ✅ Advanced compliance (eDiscovery Premium, Insider Risk)
|
||||
- ✅ Microsoft Security Copilot (coming in 2025)
|
||||
- ✅ Advanced DLP (Teams, Endpoints)
|
||||
- ✅ Adaptive Protection
|
||||
- ✅ Communication Compliance
|
||||
- ✅ Auto-labeling for sensitivity/retention
|
||||
- ✅ 500 AI Builder credits/user/month (til nov 2026)
|
||||
|
||||
**AI-funksjoner som krever add-on:**
|
||||
- 💰 Microsoft 365 Copilot (~$30/user/month)
|
||||
- 💰 Copilot Studio (~$200/month tenant + user licenses)
|
||||
- 💰 AI Builder credits beyond seeded amount
|
||||
|
||||
**Best for:** Organisasjoner med strenge compliance-krav som planlegger full AI-adopsjon.
|
||||
|
||||
---
|
||||
|
||||
### Microsoft 365 Copilot Add-on
|
||||
|
||||
**Pris:** ~$30/user/month
|
||||
|
||||
**Forutsetninger:**
|
||||
- Must have one of: M365 E3/E5, Business Basic/Standard/Premium, Office 365 E1/E3/E5, Teams Enterprise, or compatible plan
|
||||
|
||||
**Inkluderer:**
|
||||
- ✅ Copilot in Word, Excel, PowerPoint, Outlook, Teams
|
||||
- ✅ Copilot Chat (work-based, grounded in org data)
|
||||
- ✅ Copilot Pages
|
||||
- ✅ SharePoint Advanced Management
|
||||
- ✅ Copilot Analytics
|
||||
- ✅ Zero-rated Copilot Studio usage when used in M365 services (classic answers, generative answers, Graph grounding)
|
||||
|
||||
**Ekskluderer:**
|
||||
- ❌ Copilot Studio standalone features (premium connectors, multi-channel deployment)
|
||||
- ❌ Azure AI services
|
||||
- ❌ AI Builder credits (separate purchase)
|
||||
|
||||
---
|
||||
|
||||
### Copilot Studio Standalone
|
||||
|
||||
**Pris:**
|
||||
- Tenant license: ~$200/month (includes capacity)
|
||||
- User licenses: ~$30/user/month
|
||||
- Prepaid Copilot Credits: Consumption-based
|
||||
- Pay-as-you-go: Azure meter-based
|
||||
|
||||
**Inkluderer:**
|
||||
- ✅ Generative orchestration
|
||||
- ✅ Deployment to any channel (web, Teams, Slack, etc.)
|
||||
- ✅ Premium Power Platform connectors
|
||||
- ✅ Power Automate flows (automated, instant, scheduled)
|
||||
- ✅ Web security with secret generation
|
||||
- ✅ Bot Framework skills integration
|
||||
- ✅ Live agent handoff
|
||||
|
||||
**Teams Plan (inkludert i M365-lisenser):**
|
||||
- ⚠️ Limited to Teams channel only
|
||||
- ⚠️ Standard connectors only
|
||||
- ⚠️ No generative orchestration
|
||||
- ⚠️ 10 sessions/user/24h limit
|
||||
|
||||
---
|
||||
|
||||
### Power Apps Premium
|
||||
|
||||
**Pris:** ~$40/user/month
|
||||
|
||||
**Inkluderer:**
|
||||
- ✅ 500 AI Builder credits/user/month (til nov 2026)
|
||||
- ✅ Premium connectors (1,000+)
|
||||
- ✅ Dataverse capacity (2 GB database + 2 GB file)
|
||||
- ✅ Custom connectors
|
||||
- ✅ On-premises data gateway
|
||||
|
||||
**Best for:** App-builders som trenger AI-capabilities (document processing, prediction).
|
||||
|
||||
---
|
||||
|
||||
### Power Automate Premium
|
||||
|
||||
**Pris:** ~$40/user/month
|
||||
|
||||
**Inkluderer:**
|
||||
- ✅ 5,000 AI Builder credits/user/month (til nov 2026)
|
||||
- ✅ Attended RPA
|
||||
- ✅ Premium connectors
|
||||
- ✅ Process mining
|
||||
- ✅ AI-driven process recommendations
|
||||
|
||||
**Best for:** Automatisering med RPA og AI-features.
|
||||
|
||||
---
|
||||
|
||||
## 3. Copilot-Specific Licensing Guide
|
||||
|
||||
### Copilot License Types
|
||||
|
||||
| Copilot Type | License Required | Use Case | Pricing Model |
|
||||
|--------------|------------------|----------|---------------|
|
||||
| **Microsoft 365 Copilot** | M365 Copilot add-on | Embedded in M365 apps | $30/user/month |
|
||||
| **Copilot Chat (web)** | Any M365 subscription | Web-only, public data | Included |
|
||||
| **Copilot Chat (work)** | M365 Copilot license | Org data grounding | $30/user/month |
|
||||
| **Copilot Studio Agents** | Copilot Studio license | Custom agents, multi-channel | Consumption-based (Copilot Credits) |
|
||||
| **Copilot for Sales** | Dynamics 365 Sales + add-on | Sales-specific features | Add-on pricing |
|
||||
| **Copilot for Service** | Dynamics 365 Customer Service + add-on | Service-specific features | Add-on pricing |
|
||||
| **Security Copilot** | M365 E5 (2025) or standalone | Security operations | Included in E5 (2025) |
|
||||
|
||||
### Message/Session Quotas
|
||||
|
||||
**Copilot Studio:**
|
||||
- **Standalone subscription:** No hard session limits, but quota enforcement based on RPM (requests per minute)
|
||||
- **Teams plan:** 10 sessions/user/24h across all agents in tenant
|
||||
- **M365 Copilot users:** Zero-rated usage for classic/generative answers, Graph grounding
|
||||
|
||||
**RPM Quotas (per environment):**
|
||||
| Prepaid Message Packs | RPM | RPH |
|
||||
|-----------------------|-----|-----|
|
||||
| 1-10 packs | 50 | 1,000 |
|
||||
| 11-50 packs | 80 | 1,600 |
|
||||
| 51-150 packs | 100 | 2,000 |
|
||||
| 150+ packs | +1 RPM per 10 packs | +20 RPH per 10 packs |
|
||||
| Pay-as-you-go | 100 | 2,000 |
|
||||
| Trial/dev environments | 10 | 200 |
|
||||
|
||||
---
|
||||
|
||||
## 4. AI Builder Credit Allocation
|
||||
|
||||
### Seeded Credits by License (til 1. nov 2026)
|
||||
|
||||
| License | AI Builder Credits/Month | Max Tenant Credits |
|
||||
|---------|--------------------------|-------------------|
|
||||
| Power Apps Premium | 500 | 1,000,000 |
|
||||
| Power Apps Per App | 250 | 1,000,000 |
|
||||
| Power Automate Premium | 5,000 | 1,000,000 |
|
||||
| Power Automate Process | 5,000 | 1,000,000 |
|
||||
| Power Automate Hosted RPA | 5,000 | 1,000,000 |
|
||||
| Power Automate Unattended RPA | 5,000 | 1,000,000 |
|
||||
| Dynamics 365 F&O | 20,000 | 20,000 |
|
||||
| M365 E3/E5 | 500 | 1,000,000 |
|
||||
|
||||
### Add-on Credits
|
||||
|
||||
| Add-on Tier | Credits | Est. Price |
|
||||
|-------------|---------|-----------|
|
||||
| AI Builder T1 | 1,000,000 | ~$500/month |
|
||||
| AI Builder T2 | 1,000,000 | ~$500/month |
|
||||
| AI Builder T3 | 1,000,000 | ~$500/month |
|
||||
|
||||
**Viktig:**
|
||||
- Unused credits DO NOT carry over to next month
|
||||
- Credits reset on 1st of each month
|
||||
- Environment in overage switches to Copilot Credits if available
|
||||
- Post Nov 2026, only add-on credits remain — seeded credits removed
|
||||
|
||||
---
|
||||
|
||||
## 5. Azure AI Services — Subscription Requirements
|
||||
|
||||
### Free Tier
|
||||
|
||||
**Hva er inkludert:**
|
||||
- 1 free Azure AI Search service per subscription
|
||||
- Limited AI services calls (varies by service)
|
||||
- 20 transactions/minute for most AI services
|
||||
- 5,000 transactions/month for many services
|
||||
|
||||
**Begrensninger:**
|
||||
- May be deleted after extended inactivity
|
||||
- 50 MB storage limit (Search)
|
||||
- No dedicated compute
|
||||
- No SLA
|
||||
|
||||
---
|
||||
|
||||
### Pay-as-you-go
|
||||
|
||||
**Pricing Models:**
|
||||
- **Azure OpenAI:** Token-based (input + output tokens)
|
||||
- GPT-4: ~$30-60/1M tokens (model-dependent)
|
||||
- GPT-3.5-turbo: ~$0.50-2/1M tokens
|
||||
- **Azure AI Search:** Per-hour pricing for tiers (Basic ~$75/month, Standard ~$250/month)
|
||||
- **AI Document Intelligence:** Per-page pricing (~$0.01-0.10/page)
|
||||
- **Speech Services:** Per-hour or per-character pricing
|
||||
|
||||
**Best for:** Variable workloads, POC, dev/test.
|
||||
|
||||
---
|
||||
|
||||
### Enterprise Agreement
|
||||
|
||||
**Benefits:**
|
||||
- Volume discounts (typically 15-40% off pay-as-you-go)
|
||||
- Committed spend model
|
||||
- Centralized billing
|
||||
- Reserved capacity discounts
|
||||
|
||||
**Best for:** Large organizations with predictable AI spend.
|
||||
|
||||
---
|
||||
|
||||
### Azure AI Foundry (formerly Azure ML Studio)
|
||||
|
||||
**Inkluderer:**
|
||||
- Model catalog (Azure OpenAI, Hugging Face, Meta)
|
||||
- Prompt flow authoring
|
||||
- Evaluation tools
|
||||
- Content filtering
|
||||
- Deployment options (real-time, batch)
|
||||
|
||||
**Pricing:** Separate charges for:
|
||||
- Compute (training/inference)
|
||||
- Storage (models, datasets)
|
||||
- Model API calls (if using MaaS)
|
||||
|
||||
---
|
||||
|
||||
## 6. Common Licensing Mistakes & Pitfalls
|
||||
|
||||
### Feil 1: Antar at M365 E5 inkluderer alt
|
||||
|
||||
**Realitet:**
|
||||
- E5 inkluderer IKKE M365 Copilot (krever add-on)
|
||||
- E5 inkluderer IKKE Copilot Studio
|
||||
- E5 inkluderer IKKE Azure AI (krever separat Azure-sub)
|
||||
|
||||
**Fix:** Budsjettér for separate add-ons.
|
||||
|
||||
---
|
||||
|
||||
### Feil 2: Forventer at AI Builder credits akkumuleres
|
||||
|
||||
**Realitet:**
|
||||
- Credits resettes hver måned
|
||||
- Unused credits går tapt
|
||||
- Ingen rollover til neste måned
|
||||
|
||||
**Fix:** Estimer månedlig peak-forbruk og kjøp for det.
|
||||
|
||||
---
|
||||
|
||||
### Feil 3: Tror Copilot Studio Teams-plan er tilstrekkelig
|
||||
|
||||
**Realitet:**
|
||||
- Kun Teams-kanal
|
||||
- Ingen premium connectors
|
||||
- Ingen generativ orkestrering
|
||||
- 10 sessions/user/24h-grense
|
||||
|
||||
**Fix:** Kjøp standalone hvis du trenger multi-channel eller enterprise features.
|
||||
|
||||
---
|
||||
|
||||
### Feil 4: Glemmer Azure subscription for AI Foundry
|
||||
|
||||
**Realitet:**
|
||||
- Azure AI Foundry/OpenAI krever aktiv Azure subscription
|
||||
- Separat billing fra M365
|
||||
- Kan generere uventede kostnader hvis ikke monitored
|
||||
|
||||
**Fix:** Sett opp cost alerts i Azure, budsjettér separat.
|
||||
|
||||
---
|
||||
|
||||
### Feil 5: Blander AI Builder credits og Copilot Credits
|
||||
|
||||
**Realitet:**
|
||||
- AI Builder credits brukes i Power Apps/Power Automate
|
||||
- Copilot Credits brukes i Copilot Studio
|
||||
- AI Builder features kan falle tilbake på Copilot Credits ved overage
|
||||
- Fra nov 2026: kun Copilot Credits for nye kunder
|
||||
|
||||
**Fix:** Forstå hvilken valuta hver service bruker.
|
||||
|
||||
---
|
||||
|
||||
### Feil 6: Ignorerer M365 E3 vs E5 compliance-forskjeller
|
||||
|
||||
**Realitet:**
|
||||
- E3 har basic DLP (SharePoint, Exchange, OneDrive)
|
||||
- E5 kreves for advanced DLP (Teams, Endpoints)
|
||||
- E5 kreves for Adaptive Protection, Insider Risk, eDiscovery Premium
|
||||
- Viktig for norske offentlige virksomheter (GDPR, Schrems II)
|
||||
|
||||
**Fix:** Vurder compliance-krav før du velger E3 vs E5.
|
||||
|
||||
---
|
||||
|
||||
## 7. Upgrade Paths
|
||||
|
||||
### E3 → E5
|
||||
|
||||
**Cost delta:** ~€21/user/month (EA pricing)
|
||||
|
||||
**Du får:**
|
||||
- Advanced Threat Protection
|
||||
- Advanced compliance (eDiscovery, Insider Risk)
|
||||
- Advanced DLP
|
||||
- Security Copilot (2025)
|
||||
- Power BI Pro
|
||||
|
||||
**Når det er verdt det:**
|
||||
- Strenge compliance-krav
|
||||
- Trenger Insider Risk Management
|
||||
- Vil ha Security Copilot når det kommer
|
||||
- >200 users (volume discount kicks in)
|
||||
|
||||
---
|
||||
|
||||
### Standalone Copilot Studio → M365 Copilot Bundle
|
||||
|
||||
**Scenario:** Du har Copilot Studio standalone, vurderer M365 Copilot.
|
||||
|
||||
**Gevinster:**
|
||||
- Zero-rated usage i M365-kanaler
|
||||
- Integrated experience i Word/Excel/Teams
|
||||
- Enklere lisenshåndtering
|
||||
|
||||
**Trade-offs:**
|
||||
- Fortsatt trenger Copilot Studio for multi-channel
|
||||
- M365 Copilot krever base M365 license (E3/E5)
|
||||
|
||||
---
|
||||
|
||||
### AI Builder Add-on → Copilot Credits
|
||||
|
||||
**Forced migration:** Nov 2026 for seeded credits, nye kunder må kjøpe Copilot Credits nå.
|
||||
|
||||
**Hva endres:**
|
||||
- Felles valuta på tvers av Copilot Studio og AI Builder
|
||||
- Pay-as-you-go option via Azure
|
||||
- Consumption-based vs fixed monthly allocation
|
||||
|
||||
**Migrering:**
|
||||
- Beregn dagens AI Builder-forbruk
|
||||
- Konverter til Copilot Credits (rate card i Power Platform Licensing Guide)
|
||||
- Kjøp prepaid pack eller enable pay-as-you-go
|
||||
|
||||
---
|
||||
|
||||
## 8. Norwegian Public Sector Licensing Notes
|
||||
|
||||
### Akademia (UH-sektoren)
|
||||
|
||||
**Tilgjengelige lisenser:**
|
||||
- Microsoft 365 A1 (gratis for studenter)
|
||||
- Microsoft 365 A3/A5 (faculty/staff)
|
||||
- Education-specific pricing (~40% rabatt vs commercial)
|
||||
|
||||
**AI-funksjoner:**
|
||||
- A1: Copilot Chat (web) included, NO AI Builder credits
|
||||
- A3: Samme som E3, 500 AI Builder credits/user* (til nov 2026)
|
||||
- A5: Samme som E5, 500 AI Builder credits/user* (til nov 2026)
|
||||
- M365 Copilot tilgjengelig som add-on (edu pricing)
|
||||
|
||||
**Compliance:**
|
||||
- EU Data Boundary supported
|
||||
- Schrems II-compliant (EEA data residency)
|
||||
- GDPR-ready (men krever config)
|
||||
|
||||
---
|
||||
|
||||
### Offentlig Sektor (Statlig/Kommunal)
|
||||
|
||||
**Procurement:**
|
||||
- Gjennom SSA (Statens innkjøpsavtaler)
|
||||
- DFØ agreements
|
||||
- KGV (Kommunenes Gjeninnkjøpsavdeling)
|
||||
|
||||
**Licensing:**
|
||||
- Ofte EA (Enterprise Agreement) med volum-rabatt
|
||||
- Government Community Cloud (GCC) available (US Gov, ikke Norge-spesifikt)
|
||||
- Standard commercial licenses for Norwegian public sector
|
||||
|
||||
**Pricing Considerations:**
|
||||
- Forhandlingsrom avhenger av antall brukere
|
||||
- Multi-year commits gir rabatt
|
||||
- Consider cyclical budgets (årlige bevilgninger)
|
||||
|
||||
---
|
||||
|
||||
### Data Residency & Compliance
|
||||
|
||||
**EU Data Boundary:**
|
||||
- M365 E3/E5: ✅ Supported (data lagret i EU)
|
||||
- Azure: ✅ Norway regions available (Norway East, Norway West)
|
||||
- Copilot Studio: ✅ EU data residency (når environment er i EU)
|
||||
|
||||
**GDPR:**
|
||||
- All Microsoft AI services GDPR-compliant when configured
|
||||
- DPA (Data Processing Agreement) included in enterprise licenses
|
||||
- Consider DLP policies for sensitive data (E5 recommended)
|
||||
|
||||
**Schrems II:**
|
||||
- EU Data Boundary mitigates Schrems II concerns
|
||||
- Azure confidential computing available
|
||||
- Consider on-premises options for highly sensitive workloads
|
||||
|
||||
---
|
||||
|
||||
## 9. Quick Decision Matrix
|
||||
|
||||
### Scenario 1: "Vi vil teste Copilot uten stor investering"
|
||||
|
||||
**Anbefaling:**
|
||||
- Behold dagens M365 E3/E5
|
||||
- Kjøp 10-50 M365 Copilot licenses for pilot-brukere (~$30/user/month)
|
||||
- Evaluer i 3-6 måneder
|
||||
- Scale dersom ROI er positiv
|
||||
|
||||
**Estimated cost:** $300-1,500/month for pilot
|
||||
|
||||
---
|
||||
|
||||
### Scenario 2: "Vi trenger custom agents for kundeservice"
|
||||
|
||||
**Anbefaling:**
|
||||
- Copilot Studio standalone (~$200/month tenant + user licenses)
|
||||
- Power Automate Premium hvis RPA trengs (~$40/user/month)
|
||||
- Azure OpenAI for custom models (consumption-based)
|
||||
|
||||
**Estimated cost:** $500-2,000/month (avhenger av message volume)
|
||||
|
||||
---
|
||||
|
||||
### Scenario 3: "Vi vil bruke AI i interne apper (Power Apps)"
|
||||
|
||||
**Anbefaling:**
|
||||
- Power Apps Premium (~$40/user/month)
|
||||
- AI Builder add-on hvis seeded credits ikke holder ($500/month per 1M credits)
|
||||
- Alternativt: Copilot Credits fra nov 2026
|
||||
|
||||
**Estimated cost:** $40-100/user/month
|
||||
|
||||
---
|
||||
|
||||
### Scenario 4: "Vi trenger full compliance + AI (offentlig sektor)"
|
||||
|
||||
**Anbefaling:**
|
||||
- M365 E5 (~€57/user/month)
|
||||
- M365 Copilot add-on (~$30/user/month)
|
||||
- Azure med Norwegian regions
|
||||
- DLP, Adaptive Protection, eDiscovery Premium
|
||||
|
||||
**Estimated cost:** ~€90-100/user/month
|
||||
|
||||
---
|
||||
|
||||
### Scenario 5: "Vi skal bygge egne AI-modeller"
|
||||
|
||||
**Anbefaling:**
|
||||
- Azure Enterprise Agreement
|
||||
- Azure AI Foundry (for MLOps)
|
||||
- Azure OpenAI Service (for LLMs)
|
||||
- Azure Machine Learning (for custom models)
|
||||
|
||||
**Estimated cost:** Highly variable ($1,000-50,000+/month avhenger av compute/storage)
|
||||
|
||||
---
|
||||
|
||||
## 10. Verified vs Assumed Information
|
||||
|
||||
### ✅ Verified (fra microsoft-learn MCP)
|
||||
|
||||
- M365 Copilot add-on pris: $30/user/month
|
||||
- AI Builder seeded credits fjernes 1. nov 2026
|
||||
- Security Copilot inkluderes i E5 (coming 2025)
|
||||
- Copilot Studio Teams plan: 10 sessions/user/24h limit
|
||||
- AI Builder credits reset monthly, no rollover
|
||||
- Azure free tier: 1 free search service per subscription
|
||||
|
||||
### ⚠️ Assumed (basert på erfaring, verifiser)
|
||||
|
||||
- Norwegian EA pricing (~€36 E3, ~€57 E5) — varies by customer agreement
|
||||
- Copilot Studio tenant license ~$200/month — see official pricing
|
||||
- AI Builder add-on ~$500/month per 1M credits — see official pricing
|
||||
- Education discount ~40% — varies by institution
|
||||
|
||||
---
|
||||
|
||||
## 11. Key Takeaways for Architects
|
||||
|
||||
1. **Ingen "all-in-one" license** — Microsoft AI-stakken krever flere lisenser for full funksjonalitet
|
||||
2. **M365 Copilot ≠ Copilot Studio** — Separate produkter, separate lisenser, ulike bruksområder
|
||||
3. **AI Builder → Copilot Credits migrering** — Planlegg nå, seeded credits forsvinner nov 2026
|
||||
4. **E3 vs E5 er viktig for compliance** — Offentlig sektor bør vurdere E5 for advanced DLP/eDiscovery
|
||||
5. **Azure-kostnader kan eksplodere** — Sett opp cost alerts, budsjettér separat fra M365
|
||||
6. **Quotas og limits varierer** — Copilot Studio RPM, AI Builder monthly reset, Teams plan-begrensninger
|
||||
7. **Norwegian data residency er tilgjengelig** — Men må konfigureres (EU Data Boundary, Azure Norway regions)
|
||||
|
||||
---
|
||||
|
||||
## Relaterte Referanser
|
||||
|
||||
- [Decision Trees](./decision-trees.md) — Når bruke hvilken plattform
|
||||
- [Security & Compliance](./security.md) — Sikkerhetskrav per lisens
|
||||
- [Microsoft Agent Framework](../development/microsoft-agent-framework.md) — Custom agent development
|
||||
|
||||
---
|
||||
|
||||
## Kilder
|
||||
|
||||
- [Microsoft 365 Copilot Licensing](https://learn.microsoft.com/en-us/copilot/microsoft-365/microsoft-365-copilot-licensing)
|
||||
- [Copilot Studio Licensing](https://learn.microsoft.com/en-us/microsoft-copilot-studio/requirements-licensing-subscriptions)
|
||||
- [AI Builder Credit Management](https://learn.microsoft.com/en-us/ai-builder/credit-management)
|
||||
- [Power Platform Licensing Guide](https://go.microsoft.com/fwlink/?linkid=2085130) (PDF)
|
||||
- [Microsoft 365 E3 vs E5 Feature Comparison](https://learn.microsoft.com/en-us/copilot/microsoft-365/microsoft-365-copilot-license-feature-overview)
|
||||
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,945 @@
|
|||
# POC Template - Microsoft AI Projects
|
||||
|
||||
**Last updated:** 2026-01 (research via microsoft-learn MCP)
|
||||
|
||||
---
|
||||
|
||||
Dette dokumentet tilbyr en strukturert mal for å planlegge, gjennomføre og evaluere Proof of Concept (POC) prosjekter for Microsoft AI-løsninger. Malen er tilpasset Azure AI Foundry, Copilot Studio, Power Platform AI, og andre Microsoft AI-plattformer.
|
||||
|
||||
## Innhold
|
||||
|
||||
1. [POC Plan Template](#poc-plan-template)
|
||||
2. [Success Criteria Framework](#success-criteria-framework)
|
||||
3. [Evaluation Rubric](#evaluation-rubric)
|
||||
4. [Platform-Specific Checklists](#platform-specific-checklists)
|
||||
5. [Risk Assessment Template](#risk-assessment-template)
|
||||
6. [Timeline Templates](#timeline-templates)
|
||||
7. [Stakeholder Communication Template](#stakeholder-communication-template)
|
||||
8. [Go/No-Go Decision Framework](#gono-go-decision-framework)
|
||||
9. [Example POC Plan](#example-poc-plan)
|
||||
|
||||
---
|
||||
|
||||
## POC Plan Template
|
||||
|
||||
Bruk denne malen for å strukturere din POC-plan. Fyll ut hver seksjon basert på ditt spesifikke use case.
|
||||
|
||||
### 1. Executive Summary
|
||||
|
||||
**Hensikt med POC:**
|
||||
_[1-2 setninger: Hva skal POC bevise eller validere?]_
|
||||
|
||||
**Forventet varighet:** _[1 uke / 2 uker / 4 uker]_
|
||||
|
||||
**Estimert ressursbehov:** _[Antall personer, roller, budsjett]_
|
||||
|
||||
**Beslutningspunkt:** _[Dato for go/no-go beslutning]_
|
||||
|
||||
---
|
||||
|
||||
### 2. Business Case
|
||||
|
||||
#### 2.1 Problem Statement
|
||||
_[Beskriv forretningsproblemet eller ineffektiviteten som AI kan løse.]_
|
||||
|
||||
**Eksempel:**
|
||||
> Kundestøtte bruker 40% av tiden på repetitive spørsmål om ordrestatus, produktreturer og leveringsinformasjon. Dette binder opp ressurser som kunne brukes på mer komplekse kundehenvendelser.
|
||||
|
||||
#### 2.2 Target Outcome
|
||||
_[Hva er det ønskede resultatet? Vær konkret og målbar.]_
|
||||
|
||||
**Eksempel:**
|
||||
> Automatisere 60% av repetitive kundehenvendelser via chatbot, redusere gjennomsnittlig responstid fra 15 minutter til 2 minutter, og frigjøre 16 timer per uke for støtteteamet.
|
||||
|
||||
#### 2.3 Strategic Value
|
||||
Ranger strategisk verdi (1-5, hvor 5 er høyest):
|
||||
|
||||
- **Business Impact:** _[1-5]_ — Hvor stor påvirkning har dette på forretningen?
|
||||
- **User Value:** _[1-5]_ — Hvor mye verdi gir dette til sluttbrukere?
|
||||
- **Innovation Potential:** _[1-5]_ — Hvor innovativt er dette for organisasjonen?
|
||||
- **Strategic Alignment:** _[1-5]_ — Hvor godt aligner dette med organisasjonens AI-strategi?
|
||||
|
||||
---
|
||||
|
||||
### 3. Technical Scope
|
||||
|
||||
#### 3.1 AI Maturity Assessment
|
||||
Identifiser din organisasjons AI-modningsnivå (basert på Microsoft CAF):
|
||||
|
||||
| Level | Skills Required | Data Readiness | Feasible Use Cases |
|
||||
|-------|-----------------|----------------|-------------------|
|
||||
| **Level 1** | Basic AI-forståelse, data-integrasjon | Minimal data, enterprise data tilgjengelig | Azure quickstart, Copilot-løsninger |
|
||||
| **Level 2** | Model selection, deployment, data cleaning | Små strukturerte datasett, domene-spesifikk data | Analytical AI (Foundry Tools), Custom gen AI chat uten RAG, Fine-tuning |
|
||||
| **Level 3** | Prompt engineering, data chunking, preprocessing | Store historiske datasett, domene-spesifikk data | Gen AI med RAG, ML model training, small AI models på VMs |
|
||||
| **Level 4** | Advanced AI/ML, infra management, orchestration | Store treningsdatasett | Large gen AI/ML apps på VMs, AKS, Container Apps |
|
||||
|
||||
**Din organisasjon er på:** _[Level 1 / 2 / 3 / 4]_
|
||||
|
||||
#### 3.2 Chosen AI Solution
|
||||
_[Velg én eller flere:]_
|
||||
|
||||
- [ ] **Microsoft 365 Copilot** (extensions/agents)
|
||||
- [ ] **Copilot Studio** (custom agents)
|
||||
- [ ] **Azure AI Foundry** (custom gen AI apps)
|
||||
- [ ] **Power Platform AI** (AI Builder, Power Automate AI)
|
||||
- [ ] **Azure Machine Learning** (custom ML models)
|
||||
- [ ] **Analytical AI** (Content Safety, Document Intelligence, Custom Vision)
|
||||
|
||||
**Rationale:**
|
||||
_[Hvorfor er denne løsningen valgt? Hva gjør den til det beste valget for dette use case?]_
|
||||
|
||||
#### 3.3 Data Requirements
|
||||
|
||||
**Data Sources:**
|
||||
1. _[Source 1: Type, format, quality, accessibility]_
|
||||
2. _[Source 2: Type, format, quality, accessibility]_
|
||||
3. _[Source 3: ...]_
|
||||
|
||||
**Data Preparation Needed:**
|
||||
- [ ] Data cleaning/normalization
|
||||
- [ ] Data labeling
|
||||
- [ ] Data chunking (for RAG)
|
||||
- [ ] Privacy/security review (PII removal, anonymization)
|
||||
- [ ] Data governance approvals
|
||||
|
||||
**Estimated Data Volume:**
|
||||
_[Small (<100 MB) / Medium (100 MB - 10 GB) / Large (>10 GB)]_
|
||||
|
||||
#### 3.4 Infrastructure Requirements
|
||||
|
||||
**Compute:**
|
||||
- [ ] Azure OpenAI capacity (model, region, quota)
|
||||
- [ ] Azure Machine Learning compute (SKU, vCPUs, GPU)
|
||||
- [ ] Power Platform capacity (Copilot Studio, AI Builder credits)
|
||||
|
||||
**Storage:**
|
||||
- [ ] Azure Storage (type, size)
|
||||
- [ ] Vector database (Azure AI Search, Cosmos DB)
|
||||
|
||||
**Network:**
|
||||
- [ ] VNet integration
|
||||
- [ ] Private endpoints
|
||||
- [ ] Bandwidth requirements
|
||||
|
||||
**Security & Compliance:**
|
||||
- [ ] Azure Policy enforcement
|
||||
- [ ] Content Safety filters
|
||||
- [ ] Data residency requirements
|
||||
- [ ] Authentication/authorization (Entra ID, RBAC)
|
||||
|
||||
---
|
||||
|
||||
### 4. Success Criteria
|
||||
|
||||
Definer spesifikke, målbare kriterier for POC-suksess. Se [Success Criteria Framework](#success-criteria-framework) for detaljerte KPIer.
|
||||
|
||||
#### 4.1 Technical Success Criteria
|
||||
1. **Functional Requirements:**
|
||||
- _[Eksempel: Chatbotten skal kunne svare på 80% av testspørsmålene korrekt.]_
|
||||
- _[Eksempel: Systemet skal kunne håndtere 100 samtidige forespørsler.]_
|
||||
|
||||
2. **Performance Metrics:**
|
||||
- **Response Time:** _[Target: < 3 sekunder for 95% av forespørslene]_
|
||||
- **Accuracy:** _[Target: 85% nøyaktighet på validasjonsdatasett]_
|
||||
- **Availability:** _[Target: 99% uptime under testperioden]_
|
||||
|
||||
3. **Quality Metrics (for Gen AI):**
|
||||
- **Groundedness:** _[Target: 90% av svarene skal være faktabaserte]_
|
||||
- **Relevance:** _[Target: 85% av svarene skal være relevante for brukerens spørsmål]_
|
||||
- **Content Safety:** _[Target: 0% harmful content, 100% moderate risk filtered]_
|
||||
|
||||
#### 4.2 Business Success Criteria
|
||||
1. **Efficiency Gains:**
|
||||
- _[Eksempel: Redusere behandlingstid med 50%]_
|
||||
|
||||
2. **Cost Savings:**
|
||||
- _[Eksempel: Redusere driftskostnader med 20%]_
|
||||
|
||||
3. **User Satisfaction:**
|
||||
- _[Eksempel: Oppnå 70% user satisfaction score]_
|
||||
|
||||
#### 4.3 Responsible AI Criteria
|
||||
- [ ] **Fairness:** Løsningen skal ikke diskriminere basert på alder, kjønn, etnisitet, etc.
|
||||
- [ ] **Transparency:** Brukere skal forstå når de interagerer med AI
|
||||
- [ ] **Privacy:** Persondata skal beskyttes i henhold til GDPR/compliance-krav
|
||||
- [ ] **Accountability:** Klare roller og ansvar for AI-beslutninger
|
||||
- [ ] **Safety:** Content Safety filters implementert og testet
|
||||
- [ ] **Inclusiveness:** Løsningen skal fungere for alle brukergrupper
|
||||
|
||||
---
|
||||
|
||||
### 5. Implementation Plan
|
||||
|
||||
#### 5.1 Phases & Milestones
|
||||
|
||||
**Phase 1: Prepare (Duration: _[X dager]_)**
|
||||
- [ ] Data collection and preparation
|
||||
- [ ] Environment setup (Azure, Power Platform)
|
||||
- [ ] Team onboarding
|
||||
- [ ] Security/compliance approvals
|
||||
|
||||
**Deliverable:** _[Data ready for use, infrastructure provisioned]_
|
||||
|
||||
---
|
||||
|
||||
**Phase 2: Build (Duration: _[X dager]_)**
|
||||
- [ ] Develop initial prototype/POC
|
||||
- [ ] Implement core functionality
|
||||
- [ ] Integrate data sources
|
||||
- [ ] Configure AI model/agent
|
||||
|
||||
**Deliverable:** _[Working prototype in dev environment]_
|
||||
|
||||
---
|
||||
|
||||
**Phase 3: Evaluate & Iterate (Duration: _[X dager]_)**
|
||||
- [ ] Functional testing
|
||||
- [ ] Performance testing
|
||||
- [ ] Responsible AI testing (fairness, safety, bias)
|
||||
- [ ] User acceptance testing (UAT)
|
||||
- [ ] Iterate based on feedback
|
||||
|
||||
**Deliverable:** _[Validated POC with test results]_
|
||||
|
||||
---
|
||||
|
||||
**Phase 4: Document & Decide (Duration: _[X dager]_)**
|
||||
- [ ] Document lessons learned
|
||||
- [ ] Compile evaluation report
|
||||
- [ ] Prepare go/no-go recommendation
|
||||
- [ ] Present to stakeholders
|
||||
|
||||
**Deliverable:** _[POC report + go/no-go decision]_
|
||||
|
||||
---
|
||||
|
||||
#### 5.2 Team Roles & Responsibilities
|
||||
|
||||
| Role | Responsible For | Time Commitment |
|
||||
|------|-----------------|-----------------|
|
||||
| **Project Lead** | Overall POC coordination, stakeholder communication | _[X hours/week]_ |
|
||||
| **Solution Architect** | Technical design, platform selection | _[X hours/week]_ |
|
||||
| **Data Scientist/Engineer** | Data preparation, model evaluation | _[X hours/week]_ |
|
||||
| **Developer/Maker** | Building prototype (Copilot Studio, Power Platform, code) | _[X hours/week]_ |
|
||||
| **Subject Matter Expert (SME)** | Domain knowledge, validation | _[X hours/week]_ |
|
||||
| **Security/Compliance Officer** | Responsible AI review, compliance validation | _[X hours/week]_ |
|
||||
| **End-User Representative** | User testing, feedback | _[X hours/week]_ |
|
||||
|
||||
---
|
||||
|
||||
### 6. Testing & Validation Plan
|
||||
|
||||
#### 6.1 Functional Testing
|
||||
- [ ] Unit tests for individual components
|
||||
- [ ] Integration tests for data pipelines
|
||||
- [ ] End-to-end scenario testing
|
||||
|
||||
**Test Cases:** _[Liste av testscenarier, f.eks. "User asks about order status"]_
|
||||
|
||||
#### 6.2 Performance Testing
|
||||
- [ ] Load testing (concurrent users/requests)
|
||||
- [ ] Latency testing (response times)
|
||||
- [ ] Throughput testing (requests per second)
|
||||
|
||||
#### 6.3 Responsible AI Testing
|
||||
- [ ] **Fairness Assessment:** Test på diverse brukergrupper
|
||||
- [ ] **Content Safety:** Test adversarial prompts (jailbreak, harmful content)
|
||||
- [ ] **Bias Detection:** Evaluate model outputs for bias
|
||||
- [ ] **Explainability:** Validate that model decisions are understandable
|
||||
|
||||
**Tools:**
|
||||
- Azure AI Foundry evaluation tools
|
||||
- Azure AI Content Safety
|
||||
- Responsible AI Dashboard (Azure ML)
|
||||
|
||||
#### 6.4 User Acceptance Testing (UAT)
|
||||
- [ ] Recruit representative users
|
||||
- [ ] Define UAT scenarios
|
||||
- [ ] Collect qualitative feedback (surveys, interviews)
|
||||
- [ ] Measure user satisfaction (NPS, CSAT)
|
||||
|
||||
---
|
||||
|
||||
### 7. Risk Management
|
||||
|
||||
Se [Risk Assessment Template](#risk-assessment-template) for detaljert risikovurdering.
|
||||
|
||||
**High-Priority Risks:**
|
||||
1. _[Risk 1: Description + Mitigation Plan]_
|
||||
2. _[Risk 2: Description + Mitigation Plan]_
|
||||
3. _[Risk 3: Description + Mitigation Plan]_
|
||||
|
||||
---
|
||||
|
||||
### 8. Budget & Resources
|
||||
|
||||
**Estimated Costs:**
|
||||
|
||||
| Category | Estimated Cost | Notes |
|
||||
|----------|---------------|-------|
|
||||
| **Azure Compute** | _[NOK/USD]_ | OpenAI quota, VM SKUs, AML compute |
|
||||
| **Storage** | _[NOK/USD]_ | Blob Storage, AI Search |
|
||||
| **Licensing** | _[NOK/USD]_ | Copilot Studio, Power Platform |
|
||||
| **Personnel** | _[NOK/USD]_ | Team member time (internal/external) |
|
||||
| **Contingency (20%)** | _[NOK/USD]_ | Buffer for unexpected costs |
|
||||
| **TOTAL** | _[NOK/USD]_ | |
|
||||
|
||||
---
|
||||
|
||||
### 9. Go/No-Go Decision Criteria
|
||||
|
||||
Ved slutten av POC, evaluer mot disse kriteriene:
|
||||
|
||||
- [ ] **Technical Feasibility:** Løsningen fungerer som forventet (>80% success criteria oppfylt)
|
||||
- [ ] **Business Value:** ROI er positiv, eller verdi er dokumentert
|
||||
- [ ] **User Acceptance:** Brukere er fornøyde (>70% satisfaction)
|
||||
- [ ] **Responsible AI:** Ingen kritiske fairness/safety issues
|
||||
- [ ] **Risk Acceptable:** Identifiserte risikoer kan håndteres
|
||||
- [ ] **Budget Viable:** Production deployment er innenfor budsjett
|
||||
|
||||
**Decision:** _[GO / NO-GO / CONDITIONAL GO (specify conditions)]_
|
||||
|
||||
---
|
||||
|
||||
## Success Criteria Framework
|
||||
|
||||
### Technical KPIs (Generative AI)
|
||||
|
||||
| Metric | Definition | Target Range | Measurement Method |
|
||||
|--------|------------|--------------|-------------------|
|
||||
| **Groundedness** | % of responses supported by source data | >85% | Azure AI Foundry evaluation |
|
||||
| **Relevance** | % of responses relevant to user query | >80% | Azure AI Foundry evaluation |
|
||||
| **Fluency** | % of responses that are coherent and grammatical | >90% | Azure AI Foundry evaluation |
|
||||
| **Content Safety** | % of harmful content blocked | 100% | Azure AI Content Safety |
|
||||
| **Response Time** | Average latency (seconds) | <3s (p95) | Application Insights |
|
||||
| **Throughput** | Requests per second handled | >100 rps | Load testing |
|
||||
| **Availability** | Uptime during test period | >99% | Azure Monitor |
|
||||
|
||||
### Business KPIs
|
||||
|
||||
| Metric | Definition | Target | Measurement Method |
|
||||
|--------|------------|--------|-------------------|
|
||||
| **Time Saved** | Hours saved per week | _[X hours]_ | Before/after comparison |
|
||||
| **Cost Reduction** | % reduction in operational costs | _[X%]_ | Financial analysis |
|
||||
| **User Satisfaction (CSAT)** | Customer satisfaction score (1-5) | >4.0 | Survey |
|
||||
| **Net Promoter Score (NPS)** | Likelihood to recommend (0-10) | >7.0 | Survey |
|
||||
| **Task Completion Rate** | % of user tasks successfully completed | >80% | Analytics |
|
||||
| **Adoption Rate** | % of target users actively using solution | >60% | Usage analytics |
|
||||
|
||||
### Responsible AI KPIs
|
||||
|
||||
| Metric | Definition | Target | Measurement Method |
|
||||
|--------|------------|--------|-------------------|
|
||||
| **Fairness (Demographic Parity)** | Max difference in positive prediction rates across groups | <10% | Responsible AI Dashboard |
|
||||
| **Bias Detection** | No significant bias detected in outputs | 0 critical issues | Manual review + automated tools |
|
||||
| **Privacy Compliance** | % of PII correctly handled (removed/anonymized) | 100% | Data audit |
|
||||
| **Content Safety Pass Rate** | % of responses passing content safety filters | 100% | Azure AI Content Safety |
|
||||
| **Explainability Score** | % of users who understand AI decisions | >70% | User survey |
|
||||
|
||||
---
|
||||
|
||||
## Evaluation Rubric
|
||||
|
||||
Bruk denne matrisen for å score POC-resultater:
|
||||
|
||||
### Technical Performance
|
||||
|
||||
| Criterion | Score 1 (Poor) | Score 3 (Fair) | Score 5 (Good) | Score 7 (Excellent) | Score |
|
||||
|-----------|---------------|----------------|----------------|---------------------|-------|
|
||||
| **Accuracy/Quality** | <60% | 60-74% | 75-89% | ≥90% | _[X]_ |
|
||||
| **Performance** | Frequent failures, >5s latency | Occasional failures, 3-5s latency | Stable, 2-3s latency | Highly stable, <2s latency | _[X]_ |
|
||||
| **Reliability** | <95% uptime | 95-97% uptime | 97-99% uptime | >99% uptime | _[X]_ |
|
||||
| **Scalability** | Cannot scale beyond POC | Limited scalability | Scales to production | Easily scales | _[X]_ |
|
||||
|
||||
**Technical Score:** _[Sum / 28]_ → _[%]_
|
||||
|
||||
---
|
||||
|
||||
### Business Value
|
||||
|
||||
| Criterion | Score 1 (Poor) | Score 3 (Fair) | Score 5 (Good) | Score 7 (Excellent) | Score |
|
||||
|-----------|---------------|----------------|----------------|---------------------|-------|
|
||||
| **Efficiency Gains** | <20% improvement | 20-40% | 40-60% | >60% | _[X]_ |
|
||||
| **User Satisfaction** | <50% satisfied | 50-65% | 65-80% | >80% | _[X]_ |
|
||||
| **Cost-Effectiveness** | ROI negative | ROI break-even | ROI 1-2x | ROI >2x | _[X]_ |
|
||||
| **Strategic Fit** | Misaligned | Partially aligned | Well aligned | Critical priority | _[X]_ |
|
||||
|
||||
**Business Score:** _[Sum / 28]_ → _[%]_
|
||||
|
||||
---
|
||||
|
||||
### Responsible AI
|
||||
|
||||
| Criterion | Score 1 (Poor) | Score 3 (Fair) | Score 5 (Good) | Score 7 (Excellent) | Score |
|
||||
|-----------|---------------|----------------|----------------|---------------------|-------|
|
||||
| **Fairness** | Significant bias issues | Minor bias detected | Fair across groups | Highly fair | _[X]_ |
|
||||
| **Safety** | Harmful content generated | Moderate safety issues | Safe with minor exceptions | 100% safe | _[X]_ |
|
||||
| **Privacy** | PII leaks detected | Minor privacy concerns | Privacy compliant | Exceeds compliance | _[X]_ |
|
||||
| **Transparency** | Opaque, users confused | Somewhat transparent | Transparent | Highly transparent | _[X]_ |
|
||||
|
||||
**Responsible AI Score:** _[Sum / 28]_ → _[%]_
|
||||
|
||||
---
|
||||
|
||||
### Overall POC Score
|
||||
|
||||
| Dimension | Weight | Score (%) | Weighted Score |
|
||||
|-----------|--------|-----------|----------------|
|
||||
| Technical Performance | 40% | _[X%]_ | _[X]_ |
|
||||
| Business Value | 40% | _[X%]_ | _[X]_ |
|
||||
| Responsible AI | 20% | _[X%]_ | _[X]_ |
|
||||
| **TOTAL** | **100%** | | **_[X%]_** |
|
||||
|
||||
**Recommendation:**
|
||||
- **>80%:** Strong GO — Proceed to production
|
||||
- **60-80%:** Conditional GO — Address gaps before production
|
||||
- **<60%:** NO-GO — Re-evaluate or pivot
|
||||
|
||||
---
|
||||
|
||||
## Platform-Specific Checklists
|
||||
|
||||
### Copilot Studio POC Checklist
|
||||
|
||||
**Pre-Development:**
|
||||
- [ ] Define agent scope (which topics/intents)
|
||||
- [ ] Identify data sources for grounding (SharePoint, Dataverse, APIs)
|
||||
- [ ] Determine deployment channels (Teams, website, custom)
|
||||
- [ ] Configure Copilot Studio environment (dev, test, prod)
|
||||
- [ ] Set up authentication (if required)
|
||||
|
||||
**Development:**
|
||||
- [ ] Build initial topics using conversational design best practices
|
||||
- [ ] Configure generative orchestration (if using gen AI)
|
||||
- [ ] Integrate data sources (connections, AI Search)
|
||||
- [ ] Implement content moderation (Azure AI Content Safety)
|
||||
- [ ] Test conversation flows with representative users
|
||||
|
||||
**Evaluation:**
|
||||
- [ ] Test intent recognition accuracy
|
||||
- [ ] Measure conversation abandonment rate
|
||||
- [ ] Validate grounding accuracy (if using data sources)
|
||||
- [ ] Test escalation paths (handoff to human)
|
||||
- [ ] Collect user feedback via surveys
|
||||
|
||||
**Governance:**
|
||||
- [ ] Apply content filters (Azure Policy)
|
||||
- [ ] Configure security groups (Entra ID)
|
||||
- [ ] Review compliance (data residency, privacy)
|
||||
- [ ] Document agent behavior and limitations
|
||||
|
||||
---
|
||||
|
||||
### Azure AI Foundry POC Checklist
|
||||
|
||||
**Pre-Development:**
|
||||
- [ ] Select foundation model (GPT-4o, GPT-4, custom)
|
||||
- [ ] Provision Azure OpenAI capacity (region, quota)
|
||||
- [ ] Define prompt engineering strategy
|
||||
- [ ] Identify grounding data (if RAG)
|
||||
- [ ] Set up Azure AI Search (if RAG)
|
||||
|
||||
**Development:**
|
||||
- [ ] Build prompt flow orchestration
|
||||
- [ ] Implement RAG pipeline (chunking, embedding, retrieval)
|
||||
- [ ] Configure content safety filters
|
||||
- [ ] Develop evaluation dataset (test queries + expected outputs)
|
||||
- [ ] Deploy to pre-production endpoint
|
||||
|
||||
**Evaluation:**
|
||||
- [ ] Run Azure AI Foundry evaluation suite (groundedness, relevance, fluency)
|
||||
- [ ] Test adversarial prompts (jailbreak attempts)
|
||||
- [ ] Measure latency and throughput
|
||||
- [ ] Validate cost per request
|
||||
- [ ] Collect SME feedback on output quality
|
||||
|
||||
**Governance:**
|
||||
- [ ] Enforce Azure Policy (allowed models, regions)
|
||||
- [ ] Configure RBAC for deployment
|
||||
- [ ] Enable monitoring (Application Insights, Azure Monitor)
|
||||
- [ ] Document model version and configuration
|
||||
|
||||
---
|
||||
|
||||
### Power Platform AI (AI Builder) POC Checklist
|
||||
|
||||
**Pre-Development:**
|
||||
- [ ] Identify AI Builder capability (document processing, text classification, object detection)
|
||||
- [ ] Prepare training data (labeled datasets)
|
||||
- [ ] Validate Power Platform capacity (AI Builder credits)
|
||||
- [ ] Define integration points (Power Apps, Power Automate)
|
||||
|
||||
**Development:**
|
||||
- [ ] Train AI Builder model
|
||||
- [ ] Validate model accuracy on test dataset
|
||||
- [ ] Build Power Automate flow or Power App integration
|
||||
- [ ] Test end-to-end automation
|
||||
|
||||
**Evaluation:**
|
||||
- [ ] Measure model precision/recall
|
||||
- [ ] Test on real-world data
|
||||
- [ ] Validate processing speed
|
||||
- [ ] Collect user feedback
|
||||
|
||||
**Governance:**
|
||||
- [ ] Configure DLP policies
|
||||
- [ ] Review data residency
|
||||
- [ ] Document model performance metrics
|
||||
|
||||
---
|
||||
|
||||
## Risk Assessment Template
|
||||
|
||||
### Risk Identification Matrix
|
||||
|
||||
| Risk Category | Risk Description | Likelihood (1-5) | Impact (1-5) | Risk Score (L×I) | Mitigation Plan |
|
||||
|---------------|------------------|------------------|--------------|------------------|-----------------|
|
||||
| **Technical** | _[Example: Model accuracy below target]_ | _[X]_ | _[X]_ | _[X]_ | _[Retrain with more data, fine-tune prompts]_ |
|
||||
| **Data** | _[Example: Insufficient training data]_ | _[X]_ | _[X]_ | _[X]_ | _[Synthetic data generation, expand data sources]_ |
|
||||
| **Security** | _[Example: PII leakage in outputs]_ | _[X]_ | _[X]_ | _[X]_ | _[Implement PII detection, anonymization]_ |
|
||||
| **Compliance** | _[Example: GDPR violation]_ | _[X]_ | _[X]_ | _[X]_ | _[Legal review, data residency controls]_ |
|
||||
| **Organizational** | _[Example: Lack of user adoption]_ | _[X]_ | _[X]_ | _[X]_ | _[Change management, training, communication]_ |
|
||||
| **Budget** | _[Example: Cost overruns]_ | _[X]_ | _[X]_ | _[X]_ | _[Monitor spending, set cost alerts]_ |
|
||||
| **Responsible AI** | _[Example: Bias in model outputs]_ | _[X]_ | _[X]_ | _[X]_ | _[Fairness testing, diverse training data]_ |
|
||||
|
||||
**Risk Scoring:**
|
||||
- 1-5: Low risk (monitor)
|
||||
- 6-10: Medium risk (active mitigation required)
|
||||
- 11-25: High risk (escalate, consider showstopper)
|
||||
|
||||
---
|
||||
|
||||
### Common AI POC Risks & Mitigations
|
||||
|
||||
#### Technical Risks
|
||||
|
||||
**Risk:** Model decay over time (accuracy degrades)
|
||||
- **Mitigation:** Implement continuous monitoring, plan for retraining cadence
|
||||
|
||||
**Risk:** Latency exceeds user expectations
|
||||
- **Mitigation:** Optimize prompt length, use faster models, implement caching
|
||||
|
||||
**Risk:** Integration failures with existing systems
|
||||
- **Mitigation:** Early integration testing, API contract validation
|
||||
|
||||
---
|
||||
|
||||
#### Data Risks
|
||||
|
||||
**Risk:** Data quality issues (missing, incomplete, biased data)
|
||||
- **Mitigation:** Data profiling upfront, data cleaning pipelines, diverse data sources
|
||||
|
||||
**Risk:** Insufficient data volume for training
|
||||
- **Mitigation:** Synthetic data generation, transfer learning, start with simpler models
|
||||
|
||||
**Risk:** Data access blocked by governance/compliance
|
||||
- **Mitigation:** Early stakeholder engagement, privacy-preserving techniques (anonymization)
|
||||
|
||||
---
|
||||
|
||||
#### Security & Compliance Risks
|
||||
|
||||
**Risk:** Prompt injection attacks
|
||||
- **Mitigation:** Input validation, content filtering, prompt engineering defenses
|
||||
|
||||
**Risk:** Data residency violations
|
||||
- **Mitigation:** Use compliant Azure regions, review data flow architecture
|
||||
|
||||
**Risk:** Unauthorized data access
|
||||
- **Mitigation:** RBAC, private endpoints, encryption at rest/in transit
|
||||
|
||||
---
|
||||
|
||||
#### Organizational Risks
|
||||
|
||||
**Risk:** User resistance to AI adoption
|
||||
- **Mitigation:** Involve users early, transparent communication about AI capabilities/limitations
|
||||
|
||||
**Risk:** Insufficient team skills
|
||||
- **Mitigation:** Training programs, external consultants, phased learning approach
|
||||
|
||||
**Risk:** Unclear ownership and accountability
|
||||
- **Mitigation:** Define RACI matrix, establish AI governance board
|
||||
|
||||
---
|
||||
|
||||
## Timeline Templates
|
||||
|
||||
### 1-Week Sprint POC
|
||||
|
||||
**Anbefalt for:** Simple use cases (Copilot Studio med pre-built connectors, basic chatbot)
|
||||
|
||||
| Day | Activities | Deliverables |
|
||||
|-----|------------|--------------|
|
||||
| **Day 1** | Kickoff, scope definition, environment setup | Approved scope, dev environment ready |
|
||||
| **Day 2-3** | Build prototype, integrate data sources | Working prototype |
|
||||
| **Day 4** | Testing (functional, UAT) | Test results, feedback collected |
|
||||
| **Day 5** | Document findings, prepare recommendation | POC report, go/no-go decision |
|
||||
|
||||
**Total Effort:** ~40 person-hours
|
||||
|
||||
---
|
||||
|
||||
### 2-Week Standard POC
|
||||
|
||||
**Anbefalt for:** Moderate complexity (Azure AI Foundry RAG, Copilot Studio med custom topics)
|
||||
|
||||
| Week | Activities | Deliverables |
|
||||
|------|------------|--------------|
|
||||
| **Week 1** | - Kickoff & planning (Day 1-2)<br>- Data preparation (Day 2-3)<br>- Environment setup (Day 3-4)<br>- Initial prototype build (Day 4-5) | Data ready, dev environment, initial prototype |
|
||||
| **Week 2** | - Iterate on prototype (Day 1-2)<br>- Testing & validation (Day 3-4)<br>- Documentation & presentation (Day 5) | Validated POC, test results, final report, go/no-go decision |
|
||||
|
||||
**Total Effort:** ~80-120 person-hours
|
||||
|
||||
---
|
||||
|
||||
### 4-Week Extended POC
|
||||
|
||||
**Anbefalt for:** Complex use cases (Azure ML model training, multi-agent systems, advanced RAG)
|
||||
|
||||
| Week | Phase | Activities | Deliverables |
|
||||
|------|-------|------------|--------------|
|
||||
| **Week 1** | **Prepare** | - Kickoff, detailed planning<br>- Data collection & preparation<br>- Infrastructure setup<br>- Team onboarding | Data pipeline ready, infra provisioned, team aligned |
|
||||
| **Week 2** | **Build** | - Develop core functionality<br>- Model training/fine-tuning<br>- Integration with systems | Working prototype (alpha) |
|
||||
| **Week 3** | **Evaluate** | - Functional testing<br>- Performance testing<br>- Responsible AI evaluation<br>- User acceptance testing<br>- Iterate based on feedback | Validated prototype (beta), test reports |
|
||||
| **Week 4** | **Decide** | - Final validation<br>- Documentation (lessons learned, architecture)<br>- Stakeholder presentation<br>- Go/no-go decision | POC final report, production roadmap, decision |
|
||||
|
||||
**Total Effort:** ~200-320 person-hours
|
||||
|
||||
---
|
||||
|
||||
### Timeline Adjustment Factors
|
||||
|
||||
Legg til ekstra tid hvis:
|
||||
- [ ] **Data ikke er klar:** +1-2 uker for data cleaning, labeling
|
||||
- [ ] **Komplekse integrasjoner:** +1 uke per critical integration
|
||||
- [ ] **Compliance reviews:** +1-2 uker for legal/security approvals
|
||||
- [ ] **New team to AI:** +1 uke for onboarding/training
|
||||
- [ ] **Custom model training:** +2-4 uker for ML model development
|
||||
|
||||
**Anbefaling:** Legg til 20-30% buffer for uforutsette utfordringer.
|
||||
|
||||
---
|
||||
|
||||
## Stakeholder Communication Template
|
||||
|
||||
### POC Kickoff Email
|
||||
|
||||
**Subject:** [POC Name] - Kickoff & Plan
|
||||
|
||||
**To:** Project team, stakeholders
|
||||
|
||||
**Body:**
|
||||
|
||||
> Vi starter POC for [use case name] med mål om å [brief objective]. POC vil løpe fra [start date] til [end date] ([X uker]).
|
||||
>
|
||||
> **Mål:**
|
||||
> - [Goal 1]
|
||||
> - [Goal 2]
|
||||
>
|
||||
> **Team:**
|
||||
> - Project Lead: [Name]
|
||||
> - Solution Architect: [Name]
|
||||
> - Developer: [Name]
|
||||
>
|
||||
> **Neste steg:**
|
||||
> - [Action 1]
|
||||
> - [Action 2]
|
||||
>
|
||||
> **Beslutningspunkt:** [Date for go/no-go decision]
|
||||
>
|
||||
> Spørsmål? Kontakt [Lead].
|
||||
|
||||
---
|
||||
|
||||
### Weekly Status Update Template
|
||||
|
||||
**Subject:** [POC Name] - Week [X] Status
|
||||
|
||||
**Progress This Week:**
|
||||
- [Completed item 1]
|
||||
- [Completed item 2]
|
||||
|
||||
**Blockers/Risks:**
|
||||
- [Risk 1 + mitigation plan]
|
||||
|
||||
**Next Week:**
|
||||
- [Planned item 1]
|
||||
- [Planned item 2]
|
||||
|
||||
**On Track?** [Yes / No / At Risk]
|
||||
|
||||
---
|
||||
|
||||
### Final POC Report Template
|
||||
|
||||
**Executive Summary:**
|
||||
- **Objective:** [What we set out to prove]
|
||||
- **Outcome:** [What we learned/achieved]
|
||||
- **Recommendation:** [GO / NO-GO / CONDITIONAL GO]
|
||||
|
||||
**Technical Results:**
|
||||
- Accuracy: [X%] (Target: [Y%])
|
||||
- Performance: [X seconds] (Target: [Y seconds])
|
||||
- [Other KPIs]
|
||||
|
||||
**Business Value:**
|
||||
- Efficiency gains: [X hours/week saved]
|
||||
- User satisfaction: [X% CSAT]
|
||||
- Estimated ROI: [X]
|
||||
|
||||
**Responsible AI:**
|
||||
- Fairness: [Pass/Fail + details]
|
||||
- Safety: [Pass/Fail + details]
|
||||
- Privacy: [Pass/Fail + details]
|
||||
|
||||
**Risks & Mitigations:**
|
||||
- [Risk 1 + status]
|
||||
- [Risk 2 + status]
|
||||
|
||||
**Next Steps:**
|
||||
- If GO: [Production roadmap, timeline, budget]
|
||||
- If NO-GO: [Reasons, alternative approaches]
|
||||
|
||||
**Attachments:**
|
||||
- Test results
|
||||
- User feedback summary
|
||||
- Cost analysis
|
||||
|
||||
---
|
||||
|
||||
## Go/No-Go Decision Framework
|
||||
|
||||
### Decision Criteria Scorecard
|
||||
|
||||
| Category | Weight | Pass Threshold | Actual Score | Weighted | Pass? |
|
||||
|----------|--------|---------------|--------------|----------|-------|
|
||||
| **Technical Feasibility** | 30% | >75% | _[X%]_ | _[X]_ | _[Y/N]_ |
|
||||
| **Business Value** | 30% | >70% | _[X%]_ | _[X]_ | _[Y/N]_ |
|
||||
| **Responsible AI** | 20% | >80% | _[X%]_ | _[X]_ | _[Y/N]_ |
|
||||
| **User Acceptance** | 10% | >70% | _[X%]_ | _[X]_ | _[Y/N]_ |
|
||||
| **Risk Management** | 10% | No critical risks | _[X/5 risks mitigated]_ | _[X]_ | _[Y/N]_ |
|
||||
| **TOTAL** | **100%** | **>75%** | | **_[X%]_** | **_[Y/N]_** |
|
||||
|
||||
---
|
||||
|
||||
### Decision Paths
|
||||
|
||||
#### GO Decision
|
||||
**Criteria:**
|
||||
- Overall score >75%
|
||||
- All critical dimensions pass threshold
|
||||
- No unmitigated high risks (score >15)
|
||||
- Stakeholder approval obtained
|
||||
|
||||
**Next Steps:**
|
||||
1. Finalize production architecture
|
||||
2. Secure production budget
|
||||
3. Define production roadmap (6-12 months)
|
||||
4. Establish MLOps/GenAIOps processes
|
||||
5. Plan change management/training
|
||||
|
||||
**Timeline to Production:** _[X weeks/months]_
|
||||
|
||||
---
|
||||
|
||||
#### CONDITIONAL GO Decision
|
||||
**Criteria:**
|
||||
- Overall score 60-75%
|
||||
- Some dimensions below threshold
|
||||
- High risks present but mitigatable
|
||||
|
||||
**Conditions to Meet:**
|
||||
- _[Condition 1: e.g., Improve accuracy to 85% before production]_
|
||||
- _[Condition 2: e.g., Complete security audit]_
|
||||
- _[Condition 3: e.g., Obtain legal approval for data usage]_
|
||||
|
||||
**Re-evaluation Date:** _[Date]_
|
||||
|
||||
---
|
||||
|
||||
#### NO-GO Decision
|
||||
**Criteria:**
|
||||
- Overall score <60%
|
||||
- Critical dimension failures
|
||||
- Unmitigatable high risks
|
||||
- Stakeholder concerns unresolved
|
||||
|
||||
**Reasons:**
|
||||
- _[Reason 1]_
|
||||
- _[Reason 2]_
|
||||
|
||||
**Alternatives:**
|
||||
1. **Pivot:** Change approach (different platform, simpler use case)
|
||||
2. **Delay:** Address blockers, re-run POC in [X months]
|
||||
3. **Cancel:** Not viable, explore non-AI solutions
|
||||
|
||||
---
|
||||
|
||||
## Example POC Plan
|
||||
|
||||
### POC: Customer Support Chatbot (Copilot Studio)
|
||||
|
||||
**Executive Summary:**
|
||||
- **Hensikt:** Automatisere repetitive kundehenvendninger (ordrestatus, returer, leveringsspørsmål) via chatbot i Teams og på web.
|
||||
- **Varighet:** 2 uker
|
||||
- **Ressurser:** 3 personer (1 solution architect, 1 developer, 1 SME)
|
||||
- **Beslutningsdato:** 2025-02-14
|
||||
|
||||
---
|
||||
|
||||
**Business Case:**
|
||||
|
||||
**Problem:** Kundestøtte bruker 40% av tiden (16 timer/uke) på repetitive spørsmål. Gjennomsnittlig responstid er 15 minutter.
|
||||
|
||||
**Målsetting:**
|
||||
- Automatisere 60% av repetitive henvendelser
|
||||
- Redusere responstid til <2 minutter
|
||||
- Frigjøre 10 timer/uke for støtteteamet
|
||||
|
||||
**Strategic Value:**
|
||||
- Business Impact: 4/5 (betydelig effektivisering)
|
||||
- User Value: 5/5 (raskere svar for kunder)
|
||||
- Innovation: 3/5 (standard chatbot-løsning)
|
||||
- Strategic Alignment: 4/5 (aligner med AI-strategi)
|
||||
|
||||
---
|
||||
|
||||
**Technical Scope:**
|
||||
|
||||
**AI Maturity:** Level 2 (har litt erfaring med Power Platform, basic AI-forståelse)
|
||||
|
||||
**Chosen Solution:** Copilot Studio
|
||||
- Hvorfor: Low-code, rask utvikling, godt integrert med Teams/Dataverse, møter compliance-krav
|
||||
|
||||
**Data Sources:**
|
||||
1. **Dataverse:** Ordredata (Order Status, Tracking Numbers)
|
||||
2. **SharePoint:** FAQ-dokumenter, return policies
|
||||
3. **Customer Service API:** Live order lookup
|
||||
|
||||
**Infrastructure:**
|
||||
- Copilot Studio capacity: 1000 conversations/month
|
||||
- Azure AI Search: For FAQ grounding
|
||||
- Dataverse: For order data
|
||||
- Content Safety: Azure AI Content Safety filters
|
||||
|
||||
---
|
||||
|
||||
**Success Criteria:**
|
||||
|
||||
**Technical:**
|
||||
- Intent recognition accuracy: >85%
|
||||
- Response time: <3 seconds
|
||||
- Availability: >99%
|
||||
- Content Safety: 100% pass rate
|
||||
|
||||
**Business:**
|
||||
- Automation rate: >60% of test queries handled without human
|
||||
- User satisfaction: >70% CSAT
|
||||
- Cost per conversation: <5 NOK
|
||||
|
||||
**Responsible AI:**
|
||||
- No bias in responses across customer demographics
|
||||
- All PII handled securely
|
||||
- Transparent AI disclosure to users
|
||||
|
||||
---
|
||||
|
||||
**Implementation Plan (2 weeks):**
|
||||
|
||||
**Week 1:**
|
||||
- Day 1-2: Setup Copilot Studio environment, define topics (Order Status, Returns, Shipping)
|
||||
- Day 3-4: Integrate Dataverse + SharePoint, configure gen AI orchestration
|
||||
- Day 5: Build initial conversation flows
|
||||
|
||||
**Week 2:**
|
||||
- Day 1-2: Test with internal users, iterate on prompts
|
||||
- Day 3-4: User acceptance testing (10 customer service reps), collect feedback
|
||||
- Day 5: Document results, prepare go/no-go recommendation
|
||||
|
||||
---
|
||||
|
||||
**Team:**
|
||||
- **Project Lead:** Kari Nordmann (10 timer/uke)
|
||||
- **Solution Architect:** Ola Hansen (15 timer/uke)
|
||||
- **Developer (Copilot Studio):** Emma Larsen (20 timer/uke)
|
||||
- **SME (Customer Service):** Per Johansen (5 timer/uke)
|
||||
|
||||
---
|
||||
|
||||
**Testing Plan:**
|
||||
|
||||
**Functional Tests:**
|
||||
- Test all 3 main topics (Order Status, Returns, Shipping)
|
||||
- Test escalation to human agent
|
||||
|
||||
**Performance:**
|
||||
- Load test: 50 concurrent conversations
|
||||
- Latency: Measure p50, p95, p99
|
||||
|
||||
**Responsible AI:**
|
||||
- Test 20 adversarial prompts (jailbreak attempts)
|
||||
- Validate content filters active
|
||||
|
||||
**UAT:**
|
||||
- 10 customer service reps test for 2 days
|
||||
- Survey: CSAT, ease of use, accuracy
|
||||
|
||||
---
|
||||
|
||||
**Risks:**
|
||||
|
||||
| Risk | Likelihood | Impact | Score | Mitigation |
|
||||
|------|-----------|--------|-------|------------|
|
||||
| Low intent recognition accuracy | 3 | 4 | 12 | Add more training phrases, use gen AI fallback |
|
||||
| Dataverse integration delays | 2 | 3 | 6 | Start integration early, have mock data ready |
|
||||
| User resistance (prefer human support) | 2 | 2 | 4 | Change management, involve users early |
|
||||
|
||||
---
|
||||
|
||||
**Budget:**
|
||||
|
||||
| Item | Cost |
|
||||
|------|------|
|
||||
| Copilot Studio license (1 month) | 5,000 NOK |
|
||||
| Azure AI Search (dev tier) | 500 NOK |
|
||||
| Personnel (80 hours × 1000 NOK/hr) | 80,000 NOK |
|
||||
| **TOTAL** | **85,500 NOK** |
|
||||
|
||||
---
|
||||
|
||||
**Go/No-Go Criteria:**
|
||||
|
||||
- [ ] Intent accuracy >85%
|
||||
- [ ] Response time <3s
|
||||
- [ ] User satisfaction >70%
|
||||
- [ ] No critical safety issues
|
||||
- [ ] Budget for production <50,000 NOK/year
|
||||
|
||||
**Expected Outcome:** GO (90% confidence based on similar implementations)
|
||||
|
||||
---
|
||||
|
||||
## Vedlegg: Nyttige Ressurser
|
||||
|
||||
### Microsoft Documentation
|
||||
- [AI Adoption Framework (CAF)](https://learn.microsoft.com/azure/cloud-adoption-framework/scenarios/ai/)
|
||||
- [Copilot Studio Implementation Guidance](https://learn.microsoft.com/microsoft-copilot-studio/guidance/overview)
|
||||
- [Azure AI Foundry Evaluation](https://learn.microsoft.com/azure/ai-foundry/concepts/evaluation-evaluators/)
|
||||
- [Responsible AI Standard](https://www.microsoft.com/ai/responsible-ai)
|
||||
|
||||
### Tools
|
||||
- **Azure AI Foundry:** Model evaluation, deployment
|
||||
- **Copilot Studio:** Agent development, testing
|
||||
- **Azure AI Content Safety:** Content moderation
|
||||
- **Responsible AI Dashboard:** Fairness, bias detection (Azure ML)
|
||||
|
||||
### Templates
|
||||
- [AI Impact Assessment Template](https://www.microsoft.com/ai/tools-practices)
|
||||
- [Responsible AI Maturity Model](https://www.microsoft.com/research/publication/responsible-ai-maturity-model/)
|
||||
|
||||
---
|
||||
|
||||
**Sist oppdatert:** 2026-01-XX
|
||||
**Versjon:** 1.0
|
||||
**Eier:** AI Architect Plugin
|
||||
|
|
@ -0,0 +1,918 @@
|
|||
# Public Sector Checklist - Norsk offentlig sektor og Microsoft AI
|
||||
|
||||
**Last updated:** 2026-01 (research via microsoft-learn MCP + WebSearch)
|
||||
**Målgruppe:** Arkitekter som rådgiver norske offentlige virksomheter
|
||||
|
||||
---
|
||||
|
||||
Dette dokumentet gir en omfattende sjekkliste for norske offentlige virksomheter som vurderer eller implementerer Microsoft AI-løsninger. Sjekklisten dekker norsk regelverk, EU-direktiver, dataresidenskrav, sikkerhetsvurderinger og Responsible AI-prinsipper.
|
||||
|
||||
## 1. Regulatorisk landskap (Norge + EU)
|
||||
|
||||
### 1.1 Norske lover og forskrifter
|
||||
|
||||
**Forvaltningsloven**
|
||||
- Krav til forsvarlig saksbehandling (§ 17)
|
||||
- Veiledningsplikt overfor publikum (§ 11)
|
||||
- Begrunnelsesplikt for vedtak (§§ 24-25)
|
||||
- **AI-implikasjon:** Automatiserte beslutninger må kunne forklares og begrunnes
|
||||
|
||||
**Offentleglova (Offentlighetsloven)**
|
||||
- Hovedregel om offentlighet for saksdokumenter (§ 3)
|
||||
- Unntak for taushetsbelagt informasjon (§ 13)
|
||||
- **AI-implikasjon:** AI-generert innhold kan være offentlig; loggføring av AI-beslutninger må journalføres
|
||||
|
||||
**Arkivlova**
|
||||
- Plikt til å arkivere offentlige dokumenter (§ 6)
|
||||
- Krav til bevaringsverdig dokumentasjon (§ 9)
|
||||
- **AI-implikasjon:** AI-genererte dokumenter og beslutningsgrunnlag må arkiveres i henhold til Noark 5-standarden
|
||||
|
||||
**Personopplysningsloven (GDPR-implementering)**
|
||||
- Norsk implementering av EU GDPR
|
||||
- Datatilsynet er norsk tilsynsmyndighet
|
||||
- **AI-implikasjon:** Se eget GDPR-avsnitt nedenfor
|
||||
|
||||
**Informasjonssikkerhetsloven** (vedtatt 2024, trer i kraft 2025)
|
||||
- Omfatter offentlige virksomheter og kritisk infrastruktur
|
||||
- Krav til sikkerhetsstyring og risikovurderinger
|
||||
- **AI-implikasjon:** AI-systemer må inngå i virksomhetens helhetlige risikovurdering
|
||||
|
||||
### 1.2 EU-regelverk som gjelder Norge (EØS)
|
||||
|
||||
**GDPR (General Data Protection Regulation)**
|
||||
- Gjeldende fra mai 2018
|
||||
- Datatilsynet håndhever i Norge
|
||||
- **Viktige artikler for AI:**
|
||||
- Art. 22: Rett til ikke å bli underlagt automatiserte beslutninger
|
||||
- Art. 35: Data Protection Impact Assessment (DPIA) ved høy risiko
|
||||
- Art. 28: Databehandleravtaler (viktig for Microsoft-tjenester)
|
||||
|
||||
**AI Act** (EU Artificial Intelligence Act)
|
||||
- **Norsk implementering:** Regjeringen sendte lovforslag på høring januar 2025
|
||||
- **Ikrafttredelse i Norge:** Planlagt august 2026 (samtidig med EU)
|
||||
- **Tilsynsmyndighet:** Nasjonal kommunikasjonsmyndighet (Nkom) blir koordinerende tilsynsmyndighet
|
||||
- **Viktige implikasjoner:**
|
||||
- Risikobasert tilnærming (uakseptabel, høy, begrenset, minimal risiko)
|
||||
- Høyrisikoklassifiserte AI-systemer krever omfattende dokumentasjon
|
||||
- Bøter også for offentlige virksomheter (viktig endring fra tidligere praksis)
|
||||
- Transparenskrav for AI-generert innhold
|
||||
|
||||
**NIS2-direktivet** (Network and Information Security)
|
||||
- Implementeres i Norge gjennom informasjonssikkerhetsloven
|
||||
- Gjelder kritisk infrastruktur og viktige sektorer
|
||||
- **AI-implikasjon:** Cybersikkerhetskrav for AI-systemer i scope-virksomheter
|
||||
|
||||
**Schrems II-konsekvenser**
|
||||
- EU-domstolens avgjørelse fra 2020 om dataoverføringer til USA
|
||||
- **Status i Norge (2025):**
|
||||
- Norske offentlige virksomheter har jobbet tett med dette siden 2020
|
||||
- Microsoft har svart med informasjonspakke og bekreftet ingen utleveringer av data fra norsk offentlig sektor til etterretning
|
||||
- EU-US Data Privacy Framework vedtatt, men juridisk usikkerhet gjenstår
|
||||
- **Anbefaling:** Bruk Microsofts EU Data Boundary-garanti (se seksjon 5)
|
||||
|
||||
## 2. Pre-implementering sjekkliste
|
||||
|
||||
Følg denne fasen-for-fase sjekklisten før implementering av Microsoft AI-løsninger.
|
||||
|
||||
### Fase 1: Innledende vurdering
|
||||
|
||||
- [ ] **Behovsanalyse**
|
||||
- Dokumenter forretningsbehov og forventet gevinst
|
||||
- Identifiser hvilke oppgaver AI skal utføre
|
||||
- Vurder om AI er riktig løsning (AI er ikke alltid svaret)
|
||||
|
||||
- [ ] **Risikoklassifisering iht. AI Act**
|
||||
- Er løsningen høyrisiko? (f.eks. saksbehandling, HR-systemer, kritisk infrastruktur)
|
||||
- Innebærer løsningen forbudte bruksområder? (f.eks. sosial scoring, sanntidsbiometri i offentlig rom)
|
||||
- Dokumenter klassifiseringen
|
||||
|
||||
- [ ] **Personvernvurdering (DPIA)**
|
||||
- Er DPIA påkrevd? (AI-systemer med persondata er ofte høyrisiko)
|
||||
- Involver virksomhetens personvernombud
|
||||
- Dokumenter personvernrisiko og mottiltak
|
||||
- Vurder behov for konsultasjon med Datatilsynet
|
||||
|
||||
- [ ] **Sikkerhetsvurdering (ROS-analyse)**
|
||||
- Gjennomfør ROS-analyse iht. NSMs grunnprinsipper for IKT-sikkerhet
|
||||
- Vurder trusler mot konfidensialitet, integritet og tilgjengelighet
|
||||
- Dokumenter akseptkriterier for risiko
|
||||
- Involver virksomhetens sikkerhetsansvarlig
|
||||
|
||||
- [ ] **Leverandørvurdering**
|
||||
- Er Microsoft godkjent leverandør i virksomheten?
|
||||
- Finnes gjeldende rammeavtale?
|
||||
- Er anskaffelsen i tråd med anskaffelsesregelverket?
|
||||
- Har virksomheten kompetanse til å forvalte løsningen?
|
||||
|
||||
### Fase 2: Juridisk og kontraktsmessig
|
||||
|
||||
- [ ] **Databehandleravtale (DPA)**
|
||||
- Signer Microsofts Data Protection Addendum (DPA)
|
||||
- Verifiser at DPA dekker alle planlagte tjenester
|
||||
- Sjekk at DPA er oppdatert med nyeste versjon
|
||||
|
||||
- [ ] **Product Terms og Service Level Agreement**
|
||||
- Les Microsofts Product Terms for aktuelle tjenester
|
||||
- Forstå SLA-garantier (typisk 99,9% for Microsoft 365, Azure AI)
|
||||
- Dokumenter hva som IKKE dekkes av SLA
|
||||
|
||||
- [ ] **Ansvar og rollefordeling**
|
||||
- Klargjør Microsofts ansvar som databehandler
|
||||
- Klargjør virksomhetens ansvar som behandlingsansvarlig
|
||||
- Dokumenter shared responsibility model for valgte tjenester
|
||||
|
||||
- [ ] **Dataresidenskrav (se seksjon 5)**
|
||||
- Bestem krav til datalokalisering
|
||||
- Vurder behov for Advanced Data Residency
|
||||
- Dokumenter valg og begrunnelse
|
||||
|
||||
### Fase 3: Teknisk planlegging
|
||||
|
||||
- [ ] **Informasjonsklassifisering**
|
||||
- Klassifiser data som skal brukes av AI-systemet (se seksjon 3)
|
||||
- Vurder om gradering er nødvendig (begrenset/fortrolig/hemmelig)
|
||||
- Avklar om ugradert/åpen informasjon kan benyttes
|
||||
|
||||
- [ ] **Tilgangskontroll**
|
||||
- Design rolle- og tilgangsmodell (RBAC)
|
||||
- Implementer Microsoft Entra ID med conditional access
|
||||
- Planlegg Multi-Factor Authentication (MFA) for alle brukere
|
||||
|
||||
- [ ] **Dataminimering**
|
||||
- Identifiser minimumssett av data som trengs
|
||||
- Planlegg anonymisering/pseudonymisering der mulig
|
||||
- Dokumenter begrunnelse for dataomfang
|
||||
|
||||
- [ ] **Logging og revisjonsspor**
|
||||
- Planlegg logging av alle AI-interaksjoner
|
||||
- Sikre at logger oppfyller krav i arkivlova
|
||||
- Bestem lagringsperiode for logger
|
||||
|
||||
- [ ] **Integrasjoner**
|
||||
- Kartlegg integrasjoner med eksisterende fagsystemer
|
||||
- Vurder sikkerheten i dataflyt mellom systemer
|
||||
- Planlegg API-sikkerhet (API Management, OAuth 2.0)
|
||||
|
||||
### Fase 4: Responsible AI-vurdering
|
||||
|
||||
- [ ] **Formålsbegrensning**
|
||||
- Definer AI-systemets formål presist
|
||||
- Dokumenter tillatte og ikke-tillatte bruksområder
|
||||
- Kommuniser formål til sluttbrukere
|
||||
|
||||
- [ ] **Rettferdighet og ikke-diskriminering**
|
||||
- Vurder risiko for bias i treningsdata
|
||||
- Planlegg testing for urimelige utfall på sårbare grupper
|
||||
- Etabler prosess for å håndtere klager på urettferdig behandling
|
||||
|
||||
- [ ] **Transparens**
|
||||
- Planlegg hvordan brukere skal informeres om AI-bruk
|
||||
- Utform menneske-vennlige forklaringer av AI-beslutninger
|
||||
- Vurder behov for AI-watermarking (spesielt for generativ AI)
|
||||
|
||||
- [ ] **Menneske-i-løkken (Human-in-the-loop)**
|
||||
- Identifiser beslutninger som krever manuell godkjenning
|
||||
- Design override-mekanismer for AI-forslag
|
||||
- Tren ansatte i når de skal overstyre AI
|
||||
|
||||
- [ ] **Accountability**
|
||||
- Utnevn ansvarlig for AI-systemet
|
||||
- Etabler eskaleringsveier ved problemer
|
||||
- Planlegg regelmessig gjennomgang av AI-ytelse
|
||||
|
||||
## 3. Dataklassifisering og håndteringskrav
|
||||
|
||||
Norske offentlige virksomheter bruker sikkerhetsgraderings-systemet fra NSM for informasjon som krever beskyttelse.
|
||||
|
||||
### 3.1 Sikkerhetsgraderte opplysninger (NSMs klassifiseringssystem)
|
||||
|
||||
| Gradering | Definisjon | Microsoft AI-anbefalinger |
|
||||
|-----------|------------|---------------------------|
|
||||
| **Ugradert** | Informasjon som ikke trenger beskyttelse ut over normal personvern- og informasjonssikkerhet | ✅ Kan bruke: Azure OpenAI, M365 Copilot, Power Platform AI (med riktig konfigurasjon) |
|
||||
| **Begrenset** | Uautorisert tilgang kan være til skade for enkeltpersoner, virksomhet eller nasjon | ⚠️ Kan bruke Azure/M365 med forsterkede sikkerhetstiltak: <br>- Data residency i Norge/EU<br>- Customer Lockbox aktivert<br>- Auditing og DLP konfigurert<br>- Private endpoints (ingen offentlig internett-eksponering) |
|
||||
| **Fortrolig** | Uautorisert tilgang kan være til alvorlig skade | ⚠️ Krever grundig risikovurdering:<br>- Vurder Azure Stack Hub (on-premises)<br>- Eller Azure med dedikerte ressurser og kryptering med kundestyrt nøkkel<br>- Ikke bruk multi-tenant AI-tjenester uten godkjenning fra sikkerhetsansvarlig |
|
||||
| **Hemmelig** | Uautorisert tilgang kan være til meget alvorlig skade for nasjonal sikkerhet | ❌ Skal IKKE bruke public cloud AI-tjenester<br>✅ Bruk Azure Stack Hub (air-gapped) eller on-premises løsninger |
|
||||
| **Strengt hemmelig** | Uautorisert tilgang kan være til eksepsjonelt alvorlig skade | ❌ Skal IKKE bruke public cloud AI-tjenester<br>✅ Kun on-premises, fysisk isolerte systemer |
|
||||
|
||||
### 3.2 Personopplysninger (GDPR-kategorier)
|
||||
|
||||
| Kategori | Eksempler | Microsoft AI-tiltak |
|
||||
|----------|-----------|---------------------|
|
||||
| **Vanlige personopplysninger** | Navn, e-post, telefonnummer | - Bruk Microsoft Purview DLP<br>- Aktivér sensitivity labels<br>- Implementer retention policies |
|
||||
| **Sensitive personopplysninger** (GDPR Art. 9) | Helse, etnisitet, politisk mening, religion, fagforeningsmedlemskap, biometri, genetikk, seksuell orientering | - DPIA obligatorisk<br>- Ekstra sikkerhetstiltak (kryptering, tilgangskontroll)<br>- Vurder om AI-behandling er strengt nødvendig<br>- Dokumenter rettslig grunnlag |
|
||||
| **Opplysninger om straffedommer** (GDPR Art. 10) | Straffehistorikk, lovanvendelse | - Kun lovhjemlet behandling<br>- Ekstra tilgangskontroll<br>- Separat logging og auditspor |
|
||||
|
||||
### 3.3 Beste praksis for datahåndtering
|
||||
|
||||
**Dataminimering:**
|
||||
- Fjern unødvendige personopplysninger før AI-behandling
|
||||
- Bruk aggregerte data der mulig
|
||||
- Implementer automatisk sletting etter definert periode
|
||||
|
||||
**Pseudonymisering:**
|
||||
- Erstatt direkte identifikatorer med pseudonymer
|
||||
- Lagre koblingsnøkkel separat med strengere tilgangskontroll
|
||||
- Vurder differential privacy for statistiske analyser
|
||||
|
||||
**Kryptering:**
|
||||
- Data i transit: TLS 1.2 minimum (TLS 1.3 anbefalt)
|
||||
- Data at rest: Azure Storage Service Encryption (256-bit AES)
|
||||
- Vurder Customer Managed Keys (CMK) for sensitiv data
|
||||
|
||||
## 4. Microsoft compliance-sertifiseringer relevante for Norge
|
||||
|
||||
Microsoft har omfattende compliance-portefølje. Følgende er spesielt relevante for norsk offentlig sektor.
|
||||
|
||||
### 4.1 Internasjonale standarder
|
||||
|
||||
| Sertifisering | Hva dekkes | Relevans for Norge |
|
||||
|---------------|------------|---------------------|
|
||||
| **ISO/IEC 27001** | Informasjonssikkerhetsledelse | ✅ Grunnleggende krav for offentlig sektor |
|
||||
| **ISO/IEC 27017** | Cloud-spesifikk informasjonssikkerhet | ✅ Viktig for skytjenester |
|
||||
| **ISO/IEC 27018** | Personvern i public cloud | ✅ Understøtter GDPR-compliance |
|
||||
| **ISO/IEC 27701** | Privacy Information Management System (PIMS) | ✅ Demonstrerer personvernprosesser |
|
||||
| **SOC 1/2/3** | Service Organization Controls | ✅ Transparens om interne kontroller |
|
||||
|
||||
### 4.2 EU/EØS-spesifikke
|
||||
|
||||
| Sertifisering | Hva dekkes | Status |
|
||||
|---------------|------------|--------|
|
||||
| **EU Cloud Code of Conduct** | GDPR Art. 28-krav for databehandlere | ✅ Azure har level 2 compliance (2021) |
|
||||
| **EU Data Boundary** | Forpliktelse om datalokalisering i EU | ✅ Gjeldende fra 2023; dekker Azure, M365, Dynamics 365 |
|
||||
| **EUDB (EU Data Boundary)** | Garanterer at kunde- og diagnostikkdata ikke forlater EU | ✅ Norge inkludert via EØS (datasentre i Norge: Oslo, Stavanger) |
|
||||
|
||||
### 4.3 Verifisering av sertifiseringer
|
||||
|
||||
**Service Trust Portal:**
|
||||
- URL: https://servicetrust.microsoft.com
|
||||
- Krever Microsoft-konto
|
||||
- Tilgang til:
|
||||
- Audit reports (ISO, SOC, etc.)
|
||||
- Compliance guides
|
||||
- Risk assessment tools
|
||||
- Data protection impact assessment templates
|
||||
|
||||
**Azure Compliance Documentation:**
|
||||
- URL: https://learn.microsoft.com/en-us/azure/compliance/
|
||||
- Publisert tilgjengelig oversikt
|
||||
- Oppdateres regelmessig
|
||||
|
||||
## 5. Dataresidenskrav og beslutningstrær
|
||||
|
||||
### 5.1 Microsoft-garanti for datalokalisering (Norge)
|
||||
|
||||
**Product Terms commitment (M365, Azure):**
|
||||
- Norge er "Local Region Geography"
|
||||
- Datasentre: Oslo, Stavanger
|
||||
- **Garantert lokalisering for:**
|
||||
- Exchange Online (mailbox-innhold)
|
||||
- SharePoint Online / OneDrive (filer)
|
||||
- Microsoft Teams (chat, filer, møteopptak)
|
||||
- Microsoft 365 Copilot og Copilot Chat (interaksjonsdata)
|
||||
|
||||
**Viktig nyanse:**
|
||||
- Product Terms dekker *Core Services* for Norge
|
||||
- **Utvidede tjenester** (f.eks. Viva, Purview, Defender for Office) krever **Advanced Data Residency (ADR)** for garantert Norge-lokalisering
|
||||
- Diagnostic data og telemetri kan sendes til EU/USA for plattformforvalting (ikke kundeinnhold)
|
||||
|
||||
### 5.2 Beslutningstre for dataresidenskrav
|
||||
|
||||
```
|
||||
START: Hvilken type data skal behandles?
|
||||
|
||||
├─ Inneholder IKKE personopplysninger?
|
||||
│ └─ Ugradert offentlig informasjon?
|
||||
│ ├─ Ja → Standard Azure/M365 OK (følg normal sikkerhetspraksis)
|
||||
│ └─ Nei (f.eks. forretningshemmeligheter) → Vurder dataresidenskrav basert på risiko
|
||||
│
|
||||
├─ Inneholder personopplysninger (GDPR)?
|
||||
│ └─ Er dataene sensitive iht. GDPR Art. 9?
|
||||
│ ├─ Ja (helse, etnisitet, etc.)
|
||||
│ │ └─ KREVER:
|
||||
│ │ - DPIA
|
||||
│ │ - Data residency i Norge/EU (Product Terms eller ADR)
|
||||
│ │ - Microsoft DPA signert
|
||||
│ │ - Vurder Customer Managed Keys
|
||||
│ │
|
||||
│ └─ Nei (vanlige personopplysninger)
|
||||
│ └─ KREVER:
|
||||
│ - Data residency i Norge/EU anbefalt
|
||||
│ - Microsoft DPA signert
|
||||
│ - Purview DLP konfigurert
|
||||
│
|
||||
└─ Gradert informasjon (NSM)?
|
||||
├─ Begrenset
|
||||
│ └─ Kan bruke Azure/M365 med:
|
||||
│ - Data residency Norge
|
||||
│ - Customer Lockbox
|
||||
│ - Private endpoints
|
||||
│ - Avansert logging
|
||||
│
|
||||
├─ Fortrolig
|
||||
│ └─ Krever risikovurdering:
|
||||
│ - Vurder Azure Stack Hub (on-prem)
|
||||
│ - ELLER Azure med dedikert tenant og CMK
|
||||
│ - Unngå multi-tenant AI-tjenester
|
||||
│
|
||||
└─ Hemmelig / Strengt hemmelig
|
||||
└─ IKKE bruk public cloud
|
||||
- Kun on-premises løsninger
|
||||
- Azure Stack Hub (air-gapped)
|
||||
```
|
||||
|
||||
### 5.3 Tilgjengelige Microsoft-alternativer
|
||||
|
||||
| Løsning | Datalokalisering | Egnet for | Kostnad |
|
||||
|---------|------------------|-----------|---------|
|
||||
| **Standard Azure/M365** | Norge (Oslo/Stavanger) via Product Terms | Ugradert, vanlige personopplysninger | Standard lisens |
|
||||
| **Advanced Data Residency (ADR)** | Norge (garantert for utvidede tjenester) | Sensitive personopplysninger, høye residenskrav | +ekstra lisenskostnad |
|
||||
| **Multi-Geo** | Velg geo per bruker/ressurs | Multinasjonale organisasjoner | +ekstra lisenskostnad |
|
||||
| **Azure Government (EU)** | EU-dedikerte datasentre | Offentlig sektor med strenge krav | Egne SKUer |
|
||||
| **Azure Stack Hub** | On-premises (kundens datasentre) | Begrenset/fortrolig, hybridskyløsninger | Investeringskostnad + lisens |
|
||||
| **Azure Stack Edge** | Edge/feltlokasjon | Begrenset konnektivitet, lav latens | Hardware + lisens |
|
||||
|
||||
### 5.4 Schrems II-mitigering
|
||||
|
||||
**Microsoft EU Data Boundary (EUDB):**
|
||||
- Gjeldende fra 1. januar 2023
|
||||
- Dekker Azure, M365, Dynamics 365, Power Platform
|
||||
- **Garanti:**
|
||||
- Kundedata lagres og prosesseres i EU
|
||||
- Støttepersonell kun fra EU (unntatt ekstraordinære situasjoner med kundesamtykke)
|
||||
- Ingen dataoverføring til USA for kjernefunksjonalitet
|
||||
|
||||
**Juridisk grunnlag for dataoverføring (hvis nødvendig):**
|
||||
1. **EU Standard Contractual Clauses (SCC)** - Microsoft DPA inkluderer SCC
|
||||
2. **EU-US Data Privacy Framework** - Microsoft er sertifisert, men juridisk usikkerhet gjenstår
|
||||
3. **Supplerende tiltak:**
|
||||
- Kryptering med Customer Managed Keys (CMK)
|
||||
- Customer Lockbox (krever godkjenning før Microsoft-tilgang)
|
||||
- Transparent logging av all Microsoft-tilgang
|
||||
|
||||
**Anbefaling for norsk offentlig sektor:**
|
||||
- Benytt EU Data Boundary
|
||||
- Aktiver Customer Lockbox
|
||||
- Krev data residency i Norge/EU
|
||||
- Dokumenter i DPIA
|
||||
|
||||
## 6. Sikkerhetsvurderingskrav (DPIA, ROS-analyse)
|
||||
|
||||
### 6.1 Data Protection Impact Assessment (DPIA)
|
||||
|
||||
**Når er DPIA obligatorisk?**
|
||||
- Behandling av sensitive personopplysninger (GDPR Art. 9)
|
||||
- Systematisk overvåking av offentlig tilgjengelige områder
|
||||
- Automatiserte beslutninger med rettslige konsekvenser (GDPR Art. 22)
|
||||
- Storskala behandling av personopplysninger
|
||||
- **AI-systemer:** De fleste AI-systemer i offentlig sektor vil utløse DPIA-krav
|
||||
|
||||
**DPIA-prosess:**
|
||||
1. **Beskriv behandlingen**
|
||||
- Formål med AI-systemet
|
||||
- Typer personopplysninger
|
||||
- Datakilde og dataflyt
|
||||
- Lagringsperiode
|
||||
|
||||
2. **Vurder nødvendighet og proporsjonalitet**
|
||||
- Er AI-behandling nødvendig for formålet?
|
||||
- Finnes mindre inngripende alternativer?
|
||||
- Er dataomfang proporsjonalt?
|
||||
|
||||
3. **Identifiser risikoer**
|
||||
- Risiko for urettmessig tilgang
|
||||
- Risiko for bias/diskriminering
|
||||
- Risiko for feilaktige beslutninger
|
||||
- Risiko ved databrudd
|
||||
|
||||
4. **Identifiser mottiltak**
|
||||
- Tekniske tiltak (kryptering, tilgangskontroll, logging)
|
||||
- Organisatoriske tiltak (opplæring, retningslinjer, kvalitetssikring)
|
||||
- Prosedyrer for rettighetsutøvelse (innsyn, sletting, retting)
|
||||
|
||||
5. **Konsulter personvernombud**
|
||||
- Alltid involvert ved DPIA
|
||||
- Råd og kvalitetssikring
|
||||
|
||||
6. **Vurder konsultasjon med Datatilsynet**
|
||||
- Obligatorisk hvis restrisiko er høy etter mottiltak
|
||||
- Datatilsynet har 8 ukers svarfrist
|
||||
|
||||
**Microsoft-verktøy for DPIA:**
|
||||
- Microsoft har publisert DPIA-templates for Azure og M365
|
||||
- URL: https://learn.microsoft.com/en-us/compliance/regulatory/gdpr-data-protection-impact-assessments
|
||||
- Inkluderer pre-populated informasjon om Microsoft-kontroller
|
||||
|
||||
### 6.2 ROS-analyse (Risiko- og sårbarhetsanalyse)
|
||||
|
||||
**NSMs krav:**
|
||||
- Følg "Grunnprinsipper for IKT-sikkerhet 2.0" fra NSM
|
||||
- ROS-analyse skal dekke konfidensialitet, integritet og tilgjengelighet
|
||||
|
||||
**ROS-prosess for AI-systemer:**
|
||||
|
||||
1. **Identifiser verdier**
|
||||
- Informasjonsverdier (data, modeller, treningsdata)
|
||||
- Funksjoner og tjenester (tilgjengelighet av AI-system)
|
||||
- Tillit og omdømme
|
||||
|
||||
2. **Identifiser trusler**
|
||||
- Eksterne trusler: Cyberangrep, datainnbrudd, DDoS
|
||||
- Interne trusler: Misbruk av privilegier, utilsiktet datalekkasje
|
||||
- AI-spesifikke trusler: Model poisoning, adversarial attacks, prompt injection
|
||||
|
||||
3. **Vurder sårbarheter**
|
||||
- Tekniske sårbarheter (ukonfigurert sikkerhet, svake passord)
|
||||
- Organisatoriske sårbarheter (mangel på opplæring, uklare roller)
|
||||
- AI-spesifikke: Bias i treningsdata, mangel på explainability
|
||||
|
||||
4. **Vurder risiko**
|
||||
- Sannsynlighet (lav/middels/høy)
|
||||
- Konsekvens (lav/middels/høy/kritisk)
|
||||
- Risikonivå = sannsynlighet × konsekvens
|
||||
|
||||
5. **Foreslå tiltak**
|
||||
- Redusere sannsynlighet (forebyggende tiltak)
|
||||
- Redusere konsekvens (beskyttelse, beredskap)
|
||||
- Prioriter tiltak basert på kost/nytte
|
||||
|
||||
6. **Akseptkriterier**
|
||||
- Definer akseptabel restrisiko
|
||||
- Ledelsens godkjenning av restrisiko
|
||||
- Dokumenter i risikomatrise
|
||||
|
||||
**NSM sine grunnprinsipper (eksempler relevant for AI):**
|
||||
- **Identifisere og kartlegge:** Dokumenter alle AI-systemer og dataflyt
|
||||
- **Beskytte:** Implementer tilgangskontroll, kryptering, segmentering
|
||||
- **Oppdage:** Logging, SIEM, anomalideteksjon
|
||||
- **Håndtere og gjenopprette:** Beredskapsplan, backup, incident response
|
||||
|
||||
### 6.3 Tilsynskrav og dokumentasjon
|
||||
|
||||
**Dokumentasjon som må være tilgjengelig:**
|
||||
- DPIA-rapport (signert av personvernombud)
|
||||
- ROS-analyse (godkjent av ledelsen)
|
||||
- Databehandleravtale med Microsoft (DPA)
|
||||
- Oversikt over behandlingsaktiviteter (protokoll iht. GDPR Art. 30)
|
||||
- Rutiner for rettighetsutøvelse (innsyn, sletting, retting, dataportabilitet)
|
||||
- Beredskapsplan ved personvernbrudd (melding innen 72 timer til Datatilsynet)
|
||||
|
||||
**Revisjonsfrekvens:**
|
||||
- Årlig gjennomgang av DPIA (eller ved vesentlige endringer)
|
||||
- Årlig ROS-analyse (eller ved nye trusler)
|
||||
- Løpende overvåking av compliance-status via Microsoft Purview Compliance Manager
|
||||
|
||||
## 7. AI Act-implikasjoner for norsk offentlig sektor
|
||||
|
||||
### 7.1 Tidsplan og tilsynsmyndighet
|
||||
|
||||
**Norsk implementering:**
|
||||
- Lovforslag sendt på høring: Januar 2025
|
||||
- Planlagt ikrafttredelse: August 2026
|
||||
- Tilsynsmyndighet: Nasjonal kommunikasjonsmyndighet (Nkom) som koordinerende myndighet
|
||||
- Sektoransvarlige myndigheter har også ansvar (f.eks. Helsedirektoratet for helsesektoren)
|
||||
|
||||
**Viktig:** EU AI Act får direkte virkning i Norge via EØS-avtalen.
|
||||
|
||||
### 7.2 Risikoklassifisering (AI Act)
|
||||
|
||||
| Risikokategori | Definisjon | Eksempler offentlig sektor | Krav |
|
||||
|----------------|------------|----------------------------|------|
|
||||
| **Uakseptabel risiko** | Forbudt bruk | - Sosial scoring av borgere<br>- Sanntids biometrisk identifikasjon i offentlig rom (med unntak for alvorlig kriminalitet)<br>- Manipulerende AI | ❌ Forbudt |
|
||||
| **Høy risiko** | Kan påvirke helse, sikkerhet eller grunnleggende rettigheter betydelig | - AI i offentlig saksbehandling (vedtak)<br>- Rekruttering i offentlig sektor<br>- Kritisk infrastruktur (vann, energi, transport)<br>- Lovhåndhevelse (prediktiv policing) | ✅ Strengt regulert:<br>- Risikovurdering og testing<br>- Omfattende dokumentasjon<br>- Human oversight obligatorisk<br>- Registrering i EU-database<br>- Conformity assessment |
|
||||
| **Begrenset risiko** | Noen åpenbaringsplikter | - Chatbots for publikumskontakt<br>- AI-generert innhold (tekst, bilder, video) | ⚠️ Transparenskrav:<br>- Informere brukere om AI-bruk<br>- Merking av generert innhold |
|
||||
| **Minimal risiko** | Lite eller ingen regulering | - Spamfilter<br>- AI-basert søk i dokumenter | ✅ Frivillige etiske retningslinjer |
|
||||
|
||||
### 7.3 Krav til høyrisikoklassifiserte AI-systemer
|
||||
|
||||
**Før ibruktagelse:**
|
||||
1. **Risk management system**
|
||||
- Identifiser kjente og forutsigbare risikoer
|
||||
- Estimer og evaluer risiko
|
||||
- Implementer tiltak
|
||||
- Dokumenter prosessen
|
||||
|
||||
2. **Data governance**
|
||||
- Relevante, representative og feilfrie treningsdata
|
||||
- Unngå bias
|
||||
- Dokumenter datakilder og datakvalitet
|
||||
|
||||
3. **Teknisk dokumentasjon**
|
||||
- Systembeskrivelse
|
||||
- Design og arkitektur
|
||||
- Testing og validering
|
||||
- Ytelsesmetrikker
|
||||
|
||||
4. **Logging**
|
||||
- Automatisk logging av AI-beslutninger
|
||||
- Sporbarhet (hvem, hva, når)
|
||||
- Mulighet for etterfølgende granskning
|
||||
|
||||
5. **Transparens og informasjon**
|
||||
- Brukere må informeres om AI-bruk
|
||||
- Forståelige forklaringer av AI-beslutninger
|
||||
- Veiledning for sikker bruk
|
||||
|
||||
6. **Human oversight**
|
||||
- Mulighet for manuell overstyring
|
||||
- Kompetente operatører
|
||||
- Tydelig ansvarsfordeling
|
||||
|
||||
7. **Robusthet og nøyaktighet**
|
||||
- Sikkerhet mot cyberangrep
|
||||
- Feilhåndtering
|
||||
- Testing under realistiske forhold
|
||||
|
||||
8. **Cybersikkerhet**
|
||||
- Resiliens mot adversarial attacks
|
||||
- Sikker utvikling (secure by design)
|
||||
- Sårbarhetshåndtering
|
||||
|
||||
**Etter ibruktagelse:**
|
||||
- **Post-market monitoring:** Løpende overvåking av ytelse
|
||||
- **Incident reporting:** Melding av alvorlige hendelser til myndighet
|
||||
- **Oppdateringer:** Vedlikehold av dokumentasjon ved endringer
|
||||
|
||||
### 7.4 Microsoft-verktøy for AI Act compliance
|
||||
|
||||
**Azure AI Studio:**
|
||||
- AI safety evaluations (testing for harmful content, groundedness)
|
||||
- Model cards (dokumentasjon av AI-modeller)
|
||||
- Responsible AI dashboard
|
||||
|
||||
**Microsoft Responsible AI Standard:**
|
||||
- Internt Microsoft-rammeverk som følger AI Act-prinsipper
|
||||
- Publisert: https://www.microsoft.com/en-us/ai/responsible-ai
|
||||
|
||||
**Azure Policy:**
|
||||
- Regulatory compliance initiatives for AI-governance
|
||||
- Automatisert sjekk av compliance-status
|
||||
|
||||
### 7.5 Særlige hensyn for norsk offentlig sektor
|
||||
|
||||
**Offentlige virksomheter kan bøtelegges:**
|
||||
- Tidligere antatt at offentlige virksomheter var unntatt fra administrative bøter
|
||||
- **AI Act:** Norsk implementering foreslår at bøter også skal gjelde offentlig sektor
|
||||
- Bøtenivå: Inntil 7% av global årlig omsetning (for virksomheter) eller fast beløp (for offentlige)
|
||||
|
||||
**Sektoransvar:**
|
||||
- Helsedirektoratet for helse
|
||||
- Utdanningsdirektoratet for utdanning
|
||||
- Etc.
|
||||
- Disse vil ha sektor-spesifikke veiledninger
|
||||
|
||||
**Anskaffelse av AI-systemer:**
|
||||
- Offentlige anskaffelser må sikre at leverandør (Microsoft) overholder AI Act
|
||||
- Krav kontraktsklausuler om compliance
|
||||
- Verifisering av conformity assessment
|
||||
|
||||
## 8. Responsible AI-sjekkliste
|
||||
|
||||
Denne sjekklisten følger Microsofts Responsible AI-prinsipper og norske etiske retningslinjer.
|
||||
|
||||
### 8.1 Rettferdighet (Fairness)
|
||||
|
||||
- [ ] **Bias-testing**
|
||||
- Test AI-modellen på representative datasett
|
||||
- Identifiser uforholdsmessige feil på sårbare grupper (kjønn, alder, etnisitet)
|
||||
- Bruk Fairness-verktøy i Azure Machine Learning
|
||||
|
||||
- [ ] **Representative data**
|
||||
- Verifiser at treningsdata reflekterer målpopulasjonen
|
||||
- Dokumenter potensielle skjevheter i datagrunnlag
|
||||
- Implementer prosess for å oppdatere modell med nye data
|
||||
|
||||
- [ ] **Klageprosess**
|
||||
- Etabler prosedyre for borgere/brukere som mener seg urettferdig behandlet
|
||||
- Tydelig kommunikasjon av klagerett
|
||||
- Logging og oppfølging av klager
|
||||
|
||||
### 8.2 Pålitelighet og sikkerhet (Reliability & Safety)
|
||||
|
||||
- [ ] **Testing**
|
||||
- Grundig testing før produksjonssetting
|
||||
- Edge case-testing (hva skjer ved uventede inndata?)
|
||||
- Load testing (håndtering av høy belastning)
|
||||
|
||||
- [ ] **Feilhåndtering**
|
||||
- Graceful degradation (systemet skal ikke krasje ved AI-feil)
|
||||
- Fallback til manuelle prosedyrer
|
||||
- Tydelig feilmeldinger til brukere
|
||||
|
||||
- [ ] **Overvåking**
|
||||
- Kontinuerlig overvåking av AI-ytelse (accuracy, precision, recall)
|
||||
- Deteksjon av model drift (endring i ytelse over tid)
|
||||
- Alert ved avvik fra forventet ytelse
|
||||
|
||||
- [ ] **Adversarial robustness**
|
||||
- Testing mot adversarial attacks (forsøk på å lure AI)
|
||||
- Implementer input validation
|
||||
- Beskytt mot prompt injection (spesielt for generativ AI)
|
||||
|
||||
### 8.3 Personvern og sikkerhet (Privacy & Security)
|
||||
|
||||
- [ ] **Dataminimering**
|
||||
- Bruk kun data som er strengt nødvendig
|
||||
- Slett data når formål er oppnådd
|
||||
- Implementer retention policies
|
||||
|
||||
- [ ] **Anonymisering/pseudonymisering**
|
||||
- Fjern direkte identifikatorer der mulig
|
||||
- Bruk differential privacy for statistiske analyser
|
||||
- Vurder federated learning (trening uten sentralisering av data)
|
||||
|
||||
- [ ] **Tilgangskontroll**
|
||||
- Principle of least privilege (kun nødvendig tilgang)
|
||||
- Multi-Factor Authentication (MFA)
|
||||
- Regelmessig review av tilganger
|
||||
|
||||
- [ ] **Kryptering**
|
||||
- Data i transit: TLS 1.2+
|
||||
- Data at rest: AES-256
|
||||
- Vurder Customer Managed Keys for ekstra kontroll
|
||||
|
||||
- [ ] **Audit logging**
|
||||
- Logg alle AI-interaksjoner
|
||||
- Beskyttet logging (tamper-proof)
|
||||
- Lagringsperiode iht. arkivlova
|
||||
|
||||
### 8.4 Inkludering (Inclusiveness)
|
||||
|
||||
- [ ] **Tilgjengelighet (universell utforming)**
|
||||
- AI-grensesnitt følger WCAG 2.1 AA-standarder
|
||||
- Støtte for skjermlesere
|
||||
- Alternativ til AI (manuelle prosesser)
|
||||
|
||||
- [ ] **Språklig inkludering**
|
||||
- Støtte for norsk (bokmål og nynorsk)
|
||||
- Støtte for samiske språk der relevant
|
||||
- Vurder støtte for minoritetsspråk
|
||||
|
||||
- [ ] **Digital kompetanse**
|
||||
- AI-løsninger skal være enkle å bruke
|
||||
- Veiledning og opplæring tilgjengelig
|
||||
- Hjelp og support for brukere
|
||||
|
||||
### 8.5 Åpenhet (Transparency)
|
||||
|
||||
- [ ] **Informasjonsplikt**
|
||||
- Informer brukere om at AI brukes
|
||||
- Forklar formål med AI-behandling
|
||||
- Tydelig kommunikasjon av AI-beslutninger
|
||||
|
||||
- [ ] **Forklarbarhet (Explainability)**
|
||||
- AI-beslutninger skal kunne forklares
|
||||
- Bruk interpretable models der mulig
|
||||
- Dokumenter hvordan beslutning ble tatt (audit trail)
|
||||
|
||||
- [ ] **AI-generert innhold**
|
||||
- Merk AI-generert tekst, bilder, video tydelig
|
||||
- Implementer watermarking for generativ AI
|
||||
- Unngå at borgere tror AI-innhold er menneskeskapt
|
||||
|
||||
- [ ] **Dokumentasjon**
|
||||
- Model cards (beskrivelse av AI-modell)
|
||||
- Datasheets for datasets (beskrivelse av treningsdata)
|
||||
- System cards (beskrivelse av hele AI-systemet)
|
||||
|
||||
### 8.6 Ansvarlighet (Accountability)
|
||||
|
||||
- [ ] **Tydelig ansvar**
|
||||
- Utnevn AI-systemeier
|
||||
- Definer roller og ansvar (RACI-matrise)
|
||||
- Eskaleringsveier ved problemer
|
||||
|
||||
- [ ] **Compliance-overvåking**
|
||||
- Regelmessig gjennomgang av AI-etikk
|
||||
- Sjekk mot regulatoriske krav
|
||||
- Bruk Microsoft Purview Compliance Manager
|
||||
|
||||
- [ ] **Menneske-i-løkken (Human-in-the-loop)**
|
||||
- AI skal være beslutningsstøtte, ikke erstatte mennesker
|
||||
- Kritiske beslutninger krever manuell godkjenning
|
||||
- Opplæring av ansatte i når de skal overstyre AI
|
||||
|
||||
- [ ] **Incident response**
|
||||
- Beredskapsplan ved AI-feil eller misbruk
|
||||
- Prosedyre for å stenge ned AI ved alvorlige feil
|
||||
- Post-mortem og læring fra hendelser
|
||||
|
||||
## 9. Anskaffelseshensyn (anskaffelsesregelverket)
|
||||
|
||||
### 9.1 Gjeldende regelverk
|
||||
|
||||
**Lov om offentlige anskaffelser (2016)**
|
||||
- Gjelder anskaffelser over fastsatte terskelverdier
|
||||
- Krav til konkurranse, likebehandling, forutberegnelighet, etterprøvbarhet
|
||||
|
||||
**Anskaffelsesforskriften**
|
||||
- Detaljer om prosedyrer (åpen, begrenset, konkurransepreget dialog, innovasjonspartnerskap)
|
||||
- Krav til kunngjøring, tildelingskriterier, kontrakt
|
||||
|
||||
### 9.2 AI-spesifikke anskaffelseskrav
|
||||
|
||||
**Funksjonelle krav:**
|
||||
- [ ] Krav til nøyaktighet/presisjon (f.eks. minst 95% accuracy)
|
||||
- [ ] Krav til forklarbarhet av AI-beslutninger
|
||||
- [ ] Krav til transparens (model cards, datasheets)
|
||||
- [ ] Krav til testing og validering før leveranse
|
||||
|
||||
**Sikkerhetskrav:**
|
||||
- [ ] ISO 27001-sertifisert leverandør
|
||||
- [ ] Penetrasjonstesting av AI-løsning
|
||||
- [ ] Sikker programvareutviklingssikring (SSDLC)
|
||||
- [ ] Sårbarhetshåndtering og patching
|
||||
|
||||
**Personvern og compliance:**
|
||||
- [ ] GDPR-compliance (DPA obligatorisk)
|
||||
- [ ] AI Act-compliance (spesielt for høyrisikosystemer)
|
||||
- [ ] Data residency-krav (Norge/EU)
|
||||
- [ ] Revisjonsrett (rett til å inspisere leverandørens prosesser)
|
||||
|
||||
**Kontraktsklausuler:**
|
||||
- [ ] Databehandleravtale (DPA) som vedlegg til kontrakt
|
||||
- [ ] SLA med definerte ytelsesmål
|
||||
- [ ] Exit-strategi (rett til å få ut data ved kontraktslutt)
|
||||
- [ ] Underentreprenører (krav om godkjenning av sub-processors)
|
||||
- [ ] Ansvar ved personvernbrudd (hvem betaler bøter?)
|
||||
|
||||
**Leverandørkompetanse:**
|
||||
- [ ] Dokumentert erfaring med lignende AI-løsninger
|
||||
- [ ] Sertifiseringer (f.eks. Microsoft Partner-status)
|
||||
- [ ] Referanser fra offentlig sektor
|
||||
- [ ] Norskspråklig support
|
||||
|
||||
### 9.3 Microsoft-spesifikke hensyn
|
||||
|
||||
**Lisensmodeller:**
|
||||
- **Commercial Cloud:** Standard lisenser (M365 E3/E5, Azure-forbruk)
|
||||
- **Enterprise Agreement (EA):** Forhandlet rabatt ved store volumer
|
||||
- **Rammeavtaler:** DFØs Marketplace for skybaserte tjenester kan benyttes
|
||||
- **Government pricing:** Spesielle tilbud for offentlig sektor (kontakt Microsoft Norge)
|
||||
|
||||
**Leverandørgjennomgang:**
|
||||
- Microsoft er prekvalifisert hos mange statlige virksomheter
|
||||
- Sjekk om virksomheten har eksisterende rammeavtale
|
||||
- Vurder behov for ny konkurranse
|
||||
|
||||
**Databehøvd og subprocessors:**
|
||||
- Microsoft bruker subprocessors (f.eks. datacenterpartnere)
|
||||
- Liste over subprocessors: https://aka.ms/servicesapproval
|
||||
- Rett til å protestere mot nye subprocessors (30 dagers varsel)
|
||||
|
||||
## 10. Arkivering og dokumentasjonshåndtering
|
||||
|
||||
### 10.1 Arkivlova og Noark 5-standard
|
||||
|
||||
**Arkivpliktige dokumenter:**
|
||||
- All korrespondanse som inngår i saksbehandling
|
||||
- Vedtak fattet med AI-støtte
|
||||
- AI-genererte rapporter som er del av saksdokumentasjon
|
||||
- Logg over AI-beslutninger (i visse sakstyper)
|
||||
|
||||
**Noark 5-krav:**
|
||||
- Metadata for AI-genererte dokumenter (hvem, hva, når)
|
||||
- Sporbarhet: Kobling mellom AI-output og saksbehandler
|
||||
- Autentisitet: Sikring av at dokument ikke er endret
|
||||
- Lagringsformat: PDF/A for langtidslagring
|
||||
|
||||
### 10.2 AI-spesifikk dokumentasjon som bør arkiveres
|
||||
|
||||
- [ ] **AI-systemdokumentasjon**
|
||||
- Systembeskrivelse (formål, funksjonalitet)
|
||||
- Leverandørinformasjon (Microsoft-kontraktsreferanse)
|
||||
- Konfigurasjon og innstillinger
|
||||
|
||||
- [ ] **Modell-dokumentasjon**
|
||||
- Model cards (for egne ML-modeller)
|
||||
- Treningsdata-beskrivelse
|
||||
- Valideringresultater
|
||||
|
||||
- [ ] **Beslutningsgrunnlag**
|
||||
- DPIA-rapport
|
||||
- ROS-analyse
|
||||
- Ledelsens godkjenning av ibruktagelse
|
||||
|
||||
- [ ] **Endringer og oppdateringer**
|
||||
- Endringslogg (når ble AI-modell oppdatert?)
|
||||
- Testing ved oppdateringer
|
||||
- Godkjenning av endringer
|
||||
|
||||
### 10.3 Lagringsperiode
|
||||
|
||||
**Personopplysninger (GDPR Art. 5):**
|
||||
- Lagringsperiode skal være begrenset til hva som er nødvendig
|
||||
- Automatisk sletting etter definert periode
|
||||
- Unntatt: Arkivformål i allmennhetens interesse
|
||||
|
||||
**Arkivverdige dokumenter (Arkivlova):**
|
||||
- Skal bevares permanent
|
||||
- Overføres til Arkivverket etter avsluttet sak
|
||||
|
||||
**AI-logger:**
|
||||
- Vurder nødvendig lagringsperiode basert på risikonivå
|
||||
- Typisk 1-5 år for audit trail
|
||||
- Sikker sletting etter utløp
|
||||
|
||||
### 10.4 Microsoft 365-arkivering
|
||||
|
||||
**Exchange Online Archiving:**
|
||||
- Automatisk arkivering av e-post
|
||||
- Retention policies (hvor lenge beholdes)
|
||||
- eDiscovery for søk i arkiv
|
||||
|
||||
**SharePoint / OneDrive:**
|
||||
- Retention labels for dokumenter
|
||||
- Records management (erklæring av arkivverdig innhold)
|
||||
- Compliance Center for policy-håndtering
|
||||
|
||||
**Microsoft Purview:**
|
||||
- Data Lifecycle Management (DLM)
|
||||
- Automatisk klassifisering av innhold
|
||||
- Policy-basert sletting
|
||||
|
||||
**Export til Noark-system:**
|
||||
- Microsoft 365 er ikke Noark-godkjent
|
||||
- Integrering med Noark-systemer via API (f.eks. Public 360, Elements)
|
||||
- Regelmessig eksport av arkivverdige dokumenter
|
||||
|
||||
## Referanser og ressurser
|
||||
|
||||
### Norske myndigheter
|
||||
|
||||
- **Digitaliseringsdirektoratet (Digdir):** https://www.digdir.no/kunstig-intelligens
|
||||
- Veiledning for ansvarlig bruk av AI i offentlig sektor
|
||||
- Sist oppdatert desember 2024
|
||||
- **Datatilsynet:** https://www.datatilsynet.no
|
||||
- GDPR-veiledning, maler for DPIA
|
||||
- **Nasjonal sikkerhetsmyndighet (NSM):** https://nsm.no
|
||||
- Grunnprinsipper for IKT-sikkerhet 2.0
|
||||
- FAQ om sky og tjenesteutsetting
|
||||
- **Nasjonal kommunikasjonsmyndighet (Nkom):** https://www.nkom.no
|
||||
- Framtidig tilsynsmyndighet for AI Act (fra 2026)
|
||||
|
||||
### Microsoft-ressurser
|
||||
|
||||
- **Microsoft Trust Center:** https://www.microsoft.com/en-us/trust-center
|
||||
- Compliance-oversikt, sertifiseringer, privacy
|
||||
- **Service Trust Portal:** https://servicetrust.microsoft.com
|
||||
- Audit reports, compliance guides, risk assessments
|
||||
- **Azure Compliance Documentation:** https://learn.microsoft.com/en-us/azure/compliance/
|
||||
- **Microsoft Responsible AI:** https://www.microsoft.com/en-us/ai/responsible-ai
|
||||
- **EU Data Boundary:** https://www.microsoft.com/en-us/trust-center/privacy/european-data-boundary-eudb
|
||||
- **Microsoft DPA:** https://aka.ms/dpa
|
||||
|
||||
### EU-regelverk
|
||||
|
||||
- **GDPR:** https://gdpr.eu
|
||||
- **AI Act:** https://artificialintelligenceact.eu
|
||||
- **EU Cloud Code of Conduct:** https://eucoc.cloud
|
||||
- **European Data Protection Board (EDPB):** https://edpb.europa.eu
|
||||
|
||||
### Standarder
|
||||
|
||||
- **ISO/IEC 27001:** Informasjonssikkerhetsledelse
|
||||
- **ISO/IEC 27701:** Privacy Information Management
|
||||
- **ISO/IEC 42001:** AI Management System (ny standard 2023)
|
||||
- **NIST AI Risk Management Framework:** https://www.nist.gov/itl/ai-risk-management-framework
|
||||
|
||||
---
|
||||
|
||||
## Oppsummering: Kritiske sjekkpunkter før go-live
|
||||
|
||||
Før du setter et Microsoft AI-system i produksjon i norsk offentlig sektor:
|
||||
|
||||
✅ **Juridisk:**
|
||||
- [ ] DPIA godkjent av personvernombud
|
||||
- [ ] ROS-analyse godkjent av ledelsen
|
||||
- [ ] Microsoft DPA signert
|
||||
- [ ] AI Act-klassifisering dokumentert
|
||||
|
||||
✅ **Teknisk:**
|
||||
- [ ] Data residency konfigurert (Norge/EU)
|
||||
- [ ] Tilgangskontroll implementert (MFA, RBAC)
|
||||
- [ ] Logging aktivert og testet
|
||||
- [ ] Backup og disaster recovery planlagt
|
||||
|
||||
✅ **Responsible AI:**
|
||||
- [ ] Bias-testing gjennomført
|
||||
- [ ] Transparens sikret (brukere informeres om AI)
|
||||
- [ ] Human-in-the-loop implementert for kritiske beslutninger
|
||||
- [ ] Klageprosedyre etablert
|
||||
|
||||
✅ **Compliance:**
|
||||
- [ ] Relevante sertifiseringer verifisert (ISO 27001, SOC 2, etc.)
|
||||
- [ ] Anskaffelsesprosess gjennomført korrekt
|
||||
- [ ] Arkiveringsprosedyre etablert
|
||||
- [ ] Incident response-plan klar
|
||||
|
||||
✅ **Organisatorisk:**
|
||||
- [ ] Ansvarlig for AI-system utnevnt
|
||||
- [ ] Brukere opplært
|
||||
- [ ] Dokumentasjon tilgjengelig
|
||||
- [ ] Support-avtale på plass
|
||||
|
||||
---
|
||||
|
||||
**Sist oppdatert:** 2026-02-03
|
||||
**Versjon:** 1.0
|
||||
**Neste revidering:** 2026-08 (etter AI Act ikrafttredelse)
|
||||
|
|
@ -0,0 +1,448 @@
|
|||
# RAG Maturity Model — Progressiv modenhetsmodell for Microsoft AI
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** Reference Architecture
|
||||
**Category:** RAG Architecture & Decision Framework
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
RAG (Retrieval-Augmented Generation) er ikke én teknikk, men et spektrum av arkitekturer med økende sofistikering. Organisasjoner som starter med enkel vektorsøk kan gradvis utvide til avanserte mønstre som agentic RAG, multimodal retrieval og selvreflekterende systemer — uten å måtte bygge om fra scratch.
|
||||
|
||||
Denne modenhetsmodellen definerer 11 nivåer som representerer en progressiv stige fra basic RAG til enterprise-grade kunnskapssystemer. Hvert nivå bygger på foregående og kan implementeres inkrementelt med Microsoft AI-tjenester. Modellen er basert på Ottomator-rammeverkets 11 strategier, organisert som en logisk progresjon med konkrete Microsoft-implementeringer.
|
||||
|
||||
**Nøkkelprinsipp:** Start på nivå 1-3, mål kvaliteten, og avanser kun når det er beviselig behov. Over-engineering er en vanligere feil enn under-engineering.
|
||||
|
||||
---
|
||||
|
||||
## Modenhetsmodellen
|
||||
|
||||
### Nivå 1: Naive RAG (Grunnleggende)
|
||||
|
||||
**Beskrivelse:** Enkel retrieve-then-generate pipeline. Dokumenter chunkes, embeddes og søkes med vektorsøk. Ingen pre- eller post-processing.
|
||||
|
||||
| Aspekt | Detaljer |
|
||||
|--------|---------|
|
||||
| **Flyt** | Embed query → Vector search → Top-K chunks → LLM prompt → Svar |
|
||||
| **Microsoft-tjenester** | Azure AI Search (Basic tier), Azure OpenAI (text-embedding-3-small, GPT-4o) |
|
||||
| **Kompleksitet** | Lav — kan settes opp på én dag |
|
||||
| **Kostnad** | ~1 000-2 000 NOK/mnd (Basic Search + PAYG OpenAI) |
|
||||
| **Typisk presisjon** | 50-65% recall@5 |
|
||||
|
||||
**Når tilstrekkelig:** MVP, proof-of-concept, intern FAQ med <1 000 dokumenter.
|
||||
|
||||
**Begrensninger:** Ingen reranking, ingen query-forståelse, chunks mister kontekst.
|
||||
|
||||
---
|
||||
|
||||
### Nivå 2: Reranking (Kvalitetssikring av resultater)
|
||||
|
||||
**Beskrivelse:** Legger til et reranking-steg etter initial retrieval for å sortere resultater etter semantisk relevans, ikke bare vektorsimilaritet.
|
||||
|
||||
| Aspekt | Detaljer |
|
||||
|--------|---------|
|
||||
| **Flyt** | Embed query → Vector search → Top-K → Semantic Ranker → Reranked top-N → LLM |
|
||||
| **Microsoft-tjenester** | Azure AI Search Semantic Ranker (Standard tier+), Azure OpenAI |
|
||||
| **Kompleksitet** | Lav-medium — én konfigurasjon i søkeindeks |
|
||||
| **Kostnad** | +500-1 000 NOK/mnd (Standard tier krev) |
|
||||
| **Typisk forbedring** | +10-25% precision over nivå 1 |
|
||||
|
||||
**Nøkkeltjeneste:** Azure AI Search Semantic Ranker — cross-encoder modell som re-evaluerer query-dokument-par.
|
||||
|
||||
**Implementering:**
|
||||
```json
|
||||
{
|
||||
"search": "Hvordan integrere AI Builder med Power Automate?",
|
||||
"vectorQueries": [{"vector": [...], "k": 50, "fields": "contentVector"}],
|
||||
"queryType": "semantic",
|
||||
"semanticConfiguration": "my-semantic-config",
|
||||
"top": 5
|
||||
}
|
||||
```
|
||||
|
||||
**Eksisterende skill:** `semantic-ranker-reranking.md` (komplett dekning)
|
||||
|
||||
---
|
||||
|
||||
### Nivå 3: Query Understanding (Spørringsoptimalisering)
|
||||
|
||||
**Beskrivelse:** Transformerer brukerens spørsmål til optimaliserte søkespørringer gjennom rewriting, expansion og intent classification.
|
||||
|
||||
| Aspekt | Detaljer |
|
||||
|--------|---------|
|
||||
| **Teknikker** | Query rewriting, expansion, decomposition, HyDE, filter extraction |
|
||||
| **Microsoft-tjenester** | Azure OpenAI (GPT-4o-mini for rewriting), Azure AI Search (synonym maps, fuzzy search) |
|
||||
| **Kompleksitet** | Medium |
|
||||
| **Kostnad** | +200-500 tokens per query (~2-6 NOK/1000 queries) |
|
||||
| **Typisk forbedring** | +15-30% precision over nivå 2 |
|
||||
|
||||
**Eksisterende skill:** `rag-query-understanding.md` (komplett + multi-query RAG-utvidelse)
|
||||
|
||||
---
|
||||
|
||||
### Nivå 4: Context-Aware Chunking (Intelligent oppdeling)
|
||||
|
||||
**Beskrivelse:** Erstatter fast chunk-størrelse med dokumentstruktur-bevisst chunking som bevarer semantiske enheter.
|
||||
|
||||
| Aspekt | Detaljer |
|
||||
|--------|---------|
|
||||
| **Teknikker** | Document Layout chunking, semantisk chunking, struktur-basert splitting |
|
||||
| **Microsoft-tjenester** | Azure AI Document Intelligence (Layout skill), Azure Content Understanding |
|
||||
| **Kompleksitet** | Medium |
|
||||
| **Kostnad** | +0,01-0,05 NOK/side (Document Intelligence) |
|
||||
| **Typisk forbedring** | +10-20% retrieval-kvalitet for strukturerte dokumenter |
|
||||
|
||||
**Eksisterende skill:** `chunking-strategies.md` (komplett + context-aware-utvidelse)
|
||||
|
||||
---
|
||||
|
||||
### Nivå 5: Contextual Retrieval (Kontekstuell berikelse)
|
||||
|
||||
**Beskrivelse:** Beriker hver chunk med dokumentnivå-kontekst før embedding, slik at isolerte chunks beholder informasjon om hvor de hører hjemme.
|
||||
|
||||
| Aspekt | Detaljer |
|
||||
|--------|---------|
|
||||
| **Teknikk** | Prepend kontekst (dokument-tittel, seksjon, sammendrag) til hver chunk før embedding |
|
||||
| **Microsoft-tjenester** | Azure OpenAI (kontekstgenerering), Azure AI Search (custom skill for prepending) |
|
||||
| **Kompleksitet** | Medium-høy |
|
||||
| **Kostnad** | +100-500 tokens per chunk (én gang ved indeksering) |
|
||||
| **Typisk forbedring** | 35-49% reduksjon i retrieval failures (Anthropic research) |
|
||||
|
||||
**Ny skill:** `contextual-retrieval.md`
|
||||
|
||||
---
|
||||
|
||||
### Nivå 6: Multi-Query RAG (Parallell spørringsutvidelse)
|
||||
|
||||
**Beskrivelse:** Genererer multiple varianter av brukerens spørsmål, kjører parallelle søk, og fusjonerer resultater med deduplisering.
|
||||
|
||||
| Aspekt | Detaljer |
|
||||
|--------|---------|
|
||||
| **Teknikk** | LLM genererer 3-5 query-varianter → parallelle søk → Reciprocal Rank Fusion |
|
||||
| **Microsoft-tjenester** | Azure OpenAI (query-generering), Azure AI Search (parallelle queries) |
|
||||
| **Kompleksitet** | Medium |
|
||||
| **Kostnad** | 3-5x søkekostnad per query |
|
||||
| **Typisk forbedring** | +10-20% recall (bredere dekning) |
|
||||
|
||||
**Utvidelse i:** `rag-query-understanding.md` (multi-query RAG-seksjon)
|
||||
|
||||
---
|
||||
|
||||
### Nivå 7: Hierarchical RAG (Multi-nivå retrieval)
|
||||
|
||||
**Beskrivelse:** Organiserer kunnskap i hierarkiske nivåer — sammendrag → seksjoner → chunks — og søker fra grovt til fint.
|
||||
|
||||
| Aspekt | Detaljer |
|
||||
|--------|---------|
|
||||
| **Teknikk** | Parent-child indekser, summary → section → chunk cascading |
|
||||
| **Microsoft-tjenester** | Azure AI Search (index projections, parent-child), Azure OpenAI (summary-generering) |
|
||||
| **Kompleksitet** | Høy |
|
||||
| **Kostnad** | +50-100% lagring (multiple representasjoner) |
|
||||
| **Typisk forbedring** | Opptil 47% høyere Hit@1, vesentlig token-reduksjon |
|
||||
|
||||
**Ny skill:** `hierarchical-rag-patterns.md`
|
||||
|
||||
---
|
||||
|
||||
### Nivå 8: Fine-tuned Embeddings (Domenespesifikk tuning)
|
||||
|
||||
**Beskrivelse:** Tilpasser embedding-modeller til domenespesifikk terminologi for bedre semantisk matching.
|
||||
|
||||
| Aspekt | Detaljer |
|
||||
|--------|---------|
|
||||
| **Teknikk** | Fine-tuning av embedding-modeller med domene-spesifikke treningspar |
|
||||
| **Microsoft-tjenester** | Azure AI Foundry (fine-tuning), Azure OpenAI (text-embedding-3-large med custom tuning) |
|
||||
| **Kompleksitet** | Høy — krever treningsdata og evalueringsrammeverk |
|
||||
| **Kostnad** | Variabel (fine-tuning compute + evaluering) |
|
||||
| **Typisk forbedring** | +15-30% retrieval-kvalitet i spesialiserte domener |
|
||||
|
||||
**Utvidelse i:** `embedding-models-selection.md` (fine-tuning-seksjon)
|
||||
|
||||
---
|
||||
|
||||
### Nivå 9: Knowledge Graphs + RAG (GraphRAG)
|
||||
|
||||
**Beskrivelse:** Kombinerer vektorsøk med kunnskapsgrafer for relasjonell reasoning og multi-hop spørsmål.
|
||||
|
||||
| Aspekt | Detaljer |
|
||||
|--------|---------|
|
||||
| **Teknikk** | Entity extraction → Graph construction → Graph + Vector hybrid search |
|
||||
| **Microsoft-tjenester** | Microsoft GraphRAG (open-source), Azure Cosmos DB (Gremlin API), Azure AI Search |
|
||||
| **Kompleksitet** | Svært høy |
|
||||
| **Kostnad** | Betydelig (graph storage + LLM-basert entity extraction) |
|
||||
| **Typisk forbedring** | +40-70% for relasjonelle spørsmål (hvem-hva-hvordan) |
|
||||
|
||||
**Eksisterende skill:** `graphrag-knowledge-graphs.md` (komplett dekning)
|
||||
|
||||
---
|
||||
|
||||
### Nivå 10: Agentic RAG (Agent-styrt retrieval)
|
||||
|
||||
**Beskrivelse:** Agenter som autonomt planlegger retrieval-strategi, velger verktøy og itererer basert på mellomresultater.
|
||||
|
||||
| Aspekt | Detaljer |
|
||||
|--------|---------|
|
||||
| **Teknikk** | LLM-agent med retrieval-verktøy, router-mønster, multi-backend søk |
|
||||
| **Microsoft-tjenester** | Microsoft Agent Framework, Semantic Kernel (VectorStore bridge), Azure AI Foundry Agent Service |
|
||||
| **Kompleksitet** | Svært høy |
|
||||
| **Kostnad** | 5-20x enkelt søk (multiple LLM-kall per query) |
|
||||
| **Typisk forbedring** | +30-50% for komplekse, multi-step spørsmål |
|
||||
|
||||
**Ny skill:** `agentic-rag-patterns.md`
|
||||
|
||||
---
|
||||
|
||||
### Nivå 11: Self-Reflective RAG (Selvevaluerende systemer)
|
||||
|
||||
**Beskrivelse:** Agenter som evaluerer kvaliteten på egne retrieval-resultater og iterativt forbedrer ved behov (CRAG/Self-RAG).
|
||||
|
||||
| Aspekt | Detaljer |
|
||||
|--------|---------|
|
||||
| **Teknikk** | Confidence scoring → evaluering → re-retrieval/re-generation loop |
|
||||
| **Microsoft-tjenester** | Azure AI Foundry Evaluators (Groundedness, Relevance, Retrieval), Semantic Kernel |
|
||||
| **Kompleksitet** | Svært høy |
|
||||
| **Kostnad** | 10-30x enkelt søk (evaluering + re-retrieval loops) |
|
||||
| **Typisk forbedring** | +20-40% groundedness, vesentlig reduksjon i hallusinasjoner |
|
||||
|
||||
**Ny skill:** `self-reflective-rag.md`
|
||||
|
||||
---
|
||||
|
||||
## Decision Tree: Hvilket nivå trenger du?
|
||||
|
||||
```
|
||||
START
|
||||
│
|
||||
├─ Har du < 1000 dokumenter og enkle spørsmål?
|
||||
│ → Nivå 1-2 (Naive RAG + Reranking)
|
||||
│
|
||||
├─ Har brukerne multi-turn samtaler eller vage spørsmål?
|
||||
│ → Nivå 3 (Query Understanding)
|
||||
│
|
||||
├─ Er dokumentene strukturerte (PDF-rapporter, regelverk)?
|
||||
│ → Nivå 4 (Context-Aware Chunking)
|
||||
│
|
||||
├─ Mister chunks viktig kontekst (anaforer, implisitte referanser)?
|
||||
│ → Nivå 5 (Contextual Retrieval)
|
||||
│
|
||||
├─ Har brukerne komplekse sammenligningsspørsmål?
|
||||
│ → Nivå 6 (Multi-Query RAG)
|
||||
│
|
||||
├─ Trenger du søk på ulike granularitetsnivåer?
|
||||
│ → Nivå 7 (Hierarchical RAG)
|
||||
│
|
||||
├─ Har du domenespesifikk terminologi som feiltolkes?
|
||||
│ → Nivå 8 (Fine-tuned Embeddings)
|
||||
│
|
||||
├─ Trenger du relasjonell reasoning (hvem jobber med hvem)?
|
||||
│ → Nivå 9 (Knowledge Graphs)
|
||||
│
|
||||
├─ Krever spørsmålene multiple retrieval-strategier?
|
||||
│ → Nivå 10 (Agentic RAG)
|
||||
│
|
||||
└─ Trenger du garantert kvalitet med self-correction?
|
||||
→ Nivå 11 (Self-Reflective RAG)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Sammendragstabell
|
||||
|
||||
| Nivå | Strategi | Microsoft-tjenester | Kompleksitet | Ekstra kostnad | Presisjonsforbedring |
|
||||
|------|----------|---------------------|-------------|----------------|---------------------|
|
||||
| 1 | Naive RAG | AI Search Basic, OpenAI | Lav | Baseline | Baseline |
|
||||
| 2 | Reranking | AI Search Semantic Ranker | Lav | +500 NOK/mnd | +10-25% |
|
||||
| 3 | Query Understanding | OpenAI (rewriting) | Medium | +2-6 NOK/1K queries | +15-30% |
|
||||
| 4 | Context-Aware Chunking | Document Intelligence | Medium | +0,01-0,05/side | +10-20% |
|
||||
| 5 | Contextual Retrieval | OpenAI (context gen) | Medium-høy | +100-500 tokens/chunk | +35-49% |
|
||||
| 6 | Multi-Query RAG | OpenAI (multi-query) | Medium | 3-5x søkekost | +10-20% recall |
|
||||
| 7 | Hierarchical RAG | AI Search (projections) | Høy | +50-100% lagring | +47% Hit@1 |
|
||||
| 8 | Fine-tuned Embeddings | AI Foundry | Høy | Variabel | +15-30% domene |
|
||||
| 9 | Knowledge Graphs | GraphRAG, Cosmos DB | Svært høy | Betydelig | +40-70% relasjon |
|
||||
| 10 | Agentic RAG | Agent Framework, SK | Svært høy | 5-20x per query | +30-50% kompleks |
|
||||
| 11 | Self-Reflective RAG | Foundry Evaluators | Svært høy | 10-30x per query | +20-40% groundedness |
|
||||
|
||||
---
|
||||
|
||||
## Migrasjonssti mellom nivåer
|
||||
|
||||
### Nivå 1→2: Legg til Semantic Ranker
|
||||
- **Krav:** Oppgrader Azure AI Search til Standard tier
|
||||
- **Endring:** Legg til `semanticConfiguration` og `queryType: semantic`
|
||||
- **Risiko:** Lav — bakoverkompatibel
|
||||
|
||||
### Nivå 2→3: Legg til Query Rewriting
|
||||
- **Krav:** GPT-4o-mini deployment for rewriting
|
||||
- **Endring:** Legg til pre-processing steg før søk
|
||||
- **Risiko:** Lav — original query kan beholdes som fallback
|
||||
|
||||
### Nivå 3→4: Oppgrader chunking
|
||||
- **Krav:** Azure AI Document Intelligence, re-indeksering
|
||||
- **Endring:** Bytt fra Text Split til Document Layout skill
|
||||
- **Risiko:** Medium — krever full re-indeksering
|
||||
|
||||
### Nivå 4→5: Legg til kontekstuell berikelse
|
||||
- **Krav:** Custom skill (Azure Functions) + re-indeksering
|
||||
- **Endring:** Prepend kontekst til chunks i indekseringspipeline
|
||||
- **Risiko:** Medium — øker indekseringstid og token-kostnad
|
||||
|
||||
### Nivå 5→6: Legg til multi-query
|
||||
- **Krav:** Minimal — kun kode-endring i query-pipeline
|
||||
- **Endring:** Parallelle søk med fusion
|
||||
- **Risiko:** Lav — øker latency med 2-3x
|
||||
|
||||
### Nivå 6→7: Legg til hierarkisk indeks
|
||||
- **Krav:** Ny indeksstruktur med index projections
|
||||
- **Endring:** Parent-child relasjoner, summary-generering
|
||||
- **Risiko:** Høy — ny arkitektur, kompleks indekshåndtering
|
||||
|
||||
### Nivå 7→8: Fine-tune embeddings
|
||||
- **Krav:** Treningsdata (query-dokument-par), Azure AI Foundry
|
||||
- **Endring:** Custom embedding-modell, full re-indeksering
|
||||
- **Risiko:** Høy — krever ML-kompetanse
|
||||
|
||||
### Nivå 8→9: Legg til Knowledge Graph
|
||||
- **Krav:** Azure Cosmos DB, GraphRAG toolkit, entity extraction
|
||||
- **Endring:** Parallell graph-pipeline ved siden av vektor-pipeline
|
||||
- **Risiko:** Svært høy — ny infrastruktur og datapipeline
|
||||
|
||||
### Nivå 9→10: Agentic orchestration
|
||||
- **Krav:** Semantic Kernel / Agent Framework, tool definitions
|
||||
- **Endring:** Agent wrapper rundt retrieval-pipeline
|
||||
- **Risiko:** Høy — ikke-deterministisk oppførsel, debugging-utfordringer
|
||||
|
||||
### Nivå 10→11: Self-reflection loop
|
||||
- **Krav:** Azure AI Foundry Evaluators, confidence thresholds
|
||||
- **Endring:** Evaluerings- og re-retrieval loop
|
||||
- **Risiko:** Høy — øker latency vesentlig, krever tydelige kvalitetsgrenser
|
||||
|
||||
---
|
||||
|
||||
## Offentlig sektor (Norge) — Anbefalinger
|
||||
|
||||
### Anbefalt utgangspunkt per virksomhetstype
|
||||
|
||||
| Virksomhet | Anbefalt startnivå | Typisk mål-nivå | Begrunnelse |
|
||||
|------------|-------------------|-----------------|-------------|
|
||||
| Kommuner (liten/mellom) | 1-2 | 3-4 | Begrenset kompetanse, moderate volumer |
|
||||
| Statlige etater | 2-3 | 5-7 | Strukturerte dokumenter, compliance-krav |
|
||||
| Helsesektoren | 3-4 | 7-8 | Domenespesifikk terminologi, høye krav til presisjon |
|
||||
| Forsvarssektoren | 4-5 | 8-11 | Gradert informasjon, relasjonelle spørsmål |
|
||||
| Justissektoren | 3-4 | 7-9 | Juridisk terminologi, relasjonell reasoning |
|
||||
|
||||
### Compliance-hensyn per nivå
|
||||
|
||||
| Nivå | GDPR | AI Act | Forvaltningsloven | Schrems II |
|
||||
|------|------|--------|-------------------|------------|
|
||||
| 1-3 | Standard DPA | Lav risiko | Minimal logging | EU-regioner OK |
|
||||
| 4-6 | PII i chunks | Dokumentasjonskrav | Kildehenvisning påkrevd | EU-regioner OK |
|
||||
| 7-9 | Utvidet DPIA | Transparenskrav | Full audit trail | Vurder Norway East |
|
||||
| 10-11 | Full DPIA | Høyrisiko-kategori mulig | Forklarbarhet påkrevd | Norway East anbefalt |
|
||||
|
||||
---
|
||||
|
||||
## Kostnad/kompleksitet-diagram
|
||||
|
||||
```
|
||||
Kostnad (NOK/mnd)
|
||||
│
|
||||
│ ● 11 Self-Reflective
|
||||
│ ● 10 Agentic
|
||||
│ ● 9 GraphRAG
|
||||
│ ● 8 Fine-tuned
|
||||
│ ● 7 Hierarchical
|
||||
│ ● 6 Multi-Query
|
||||
│ ● 5 Contextual
|
||||
│ ● 4 Context-Aware
|
||||
│ ● 3 Query Understanding
|
||||
│ ● 2 Reranking
|
||||
│ ● 1 Naive
|
||||
└─────────────────────────────────────────────────── Kompleksitet
|
||||
Lav Medium Høy Svært høy
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Tilleggsmønstre (ortogonale)
|
||||
|
||||
Disse mønstrene kan kombineres med ethvert nivå og er ikke del av den lineære progresjonen:
|
||||
|
||||
| Mønster | Beskrivelse | Når bruke | Skill |
|
||||
|---------|-------------|-----------|-------|
|
||||
| **Multimodal RAG** | Bilder, tabeller, diagrammer i pipeline | Dokumenter med visuelt innhold | `multimodal-rag.md` |
|
||||
| **Late Chunking** | Chunk etter embedding for kontekstbevaring | Long-context embedding-modeller tilgjengelig | `late-chunking-patterns.md` |
|
||||
| **Streaming RAG** | Strømming av svar under generering | Lav-latency krav | `streaming-rag-responses.md` |
|
||||
| **RBAC RAG** | Sikkerhetstrimming av resultater | Multi-tenant, klassifisert innhold | `rag-security-rbac.md` |
|
||||
| **Citation Tracking** | Kildehenvisning i svar | Compliance, etterprøvbarhet | `citation-tracking.md` |
|
||||
|
||||
---
|
||||
|
||||
## For arkitekten (Cosmo)
|
||||
|
||||
### Spørsmål for å plassere kunden på riktig nivå
|
||||
|
||||
1. **"Hva er den viktigste svakheten med dagens søk/RAG?"**
|
||||
- Dårlig presisjon → Nivå 2-3
|
||||
- Mister kontekst → Nivå 4-5
|
||||
- For smalt søk → Nivå 6
|
||||
- Trenger relasjonell info → Nivå 9
|
||||
|
||||
2. **"Hvor mange dokumenter skal indekseres?"**
|
||||
- <1 000 → Nivå 1-3 tilstrekkelig
|
||||
- 1 000-100 000 → Nivå 3-7
|
||||
- >100 000 → Nivå 4-8
|
||||
|
||||
3. **"Hva slags spørsmål stiller brukerne?"**
|
||||
- Enkle lookup → Nivå 1-3
|
||||
- Sammenligninger → Nivå 6-7
|
||||
- Multi-step reasoning → Nivå 9-11
|
||||
|
||||
4. **"Hva er budsjettrammen?"**
|
||||
- Pilot (<5 000 NOK/mnd) → Nivå 1-4
|
||||
- Produksjon (5 000-20 000 NOK/mnd) → Nivå 3-7
|
||||
- Enterprise (>20 000 NOK/mnd) → Nivå 5-11
|
||||
|
||||
5. **"Hvilken kompetanse har teamet?"**
|
||||
- Citizen developers → Nivå 1-3 (Copilot Studio)
|
||||
- Utviklere → Nivå 1-8
|
||||
- ML-ingeniører → Nivå 1-11
|
||||
|
||||
### Fallgruver
|
||||
|
||||
- **Over-engineering:** "Vi trenger agentic RAG" — nei, 80% av organisasjoner klarer seg med nivå 1-4
|
||||
- **Hoppe over nivåer:** Nivå 9 uten nivå 2-3 gir dårligere resultater enn nivå 3 alene
|
||||
- **Ingen baseline:** Alltid mål kvalitet på nåværende nivå før oppgradering
|
||||
- **Kostnadsblindhet:** Nivå 10-11 koster 10-30x per query — beregn ROI først
|
||||
- **Compliance-ignorering:** Nivå 7+ i offentlig sektor krever DPIA og arkitekturdokumentasjon
|
||||
|
||||
### Neste steg for ulike scenarioer
|
||||
|
||||
| Kunden sier | Anbefalt handling |
|
||||
|-------------|-------------------|
|
||||
| "Vi har ingen RAG i dag" | Start nivå 1-2, evaluer med 50 testspørringer |
|
||||
| "Vi har basic RAG, hva er neste steg?" | Mål baseline, legg til reranking (nivå 2) og query rewriting (nivå 3) |
|
||||
| "Retrieval-kvaliteten er for dårlig" | Evaluer chunking (nivå 4), contextual retrieval (nivå 5), og embeddings (nivå 8) |
|
||||
| "Vi trenger RAG over bilder og tabeller" | Multimodal RAG (ortogonalt mønster) |
|
||||
| "Vi har compliance-krav" | Nivå 4+ med citation tracking, RBAC, og audit logging |
|
||||
|
||||
---
|
||||
|
||||
## Kilder og verifisering
|
||||
|
||||
| Kilde | Konfidens | Område |
|
||||
|-------|-----------|--------|
|
||||
| Azure AI Search RAG overview | **Verified** | Nivå 1-4 tjenester og priser |
|
||||
| Azure AI Search Semantic Ranker | **Verified** | Nivå 2 reranking |
|
||||
| Azure AI Foundry evaluators | **Verified** | Nivå 11 evaluering |
|
||||
| Azure AI Foundry Agent Service | **Verified** | Nivå 10 agentic RAG |
|
||||
| Microsoft GraphRAG (GitHub) | **Verified** | Nivå 9 knowledge graphs |
|
||||
| Anthropic Contextual Retrieval research | **Baseline** | Nivå 5 forbedringsprosenter |
|
||||
| Jina AI Late Chunking research | **Baseline** | Late chunking konsept |
|
||||
| Ottomator 11 RAG Strategies | **Baseline** | Overordnet rammeverk |
|
||||
| RAG Maturity Model (Ombrulla) | **Baseline** | Modenhetsmodell-konsept |
|
||||
| Azure-priser | **Verified** | Konvertert NOK med kurs ~10.5 |
|
||||
|
||||
---
|
||||
|
||||
**For Cosmo:** Bruk denne modellen som standard rammeverk når kunder spør om "RAG-strategi" eller "hva er neste steg for vår RAG-løsning". Start alltid med å plassere kunden på riktig nivå gjennom spørsmålene over, deretter anbefal neste 1-2 nivåer. Aldri anbefal nivå 9-11 som første steg.
|
||||
|
|
@ -0,0 +1,246 @@
|
|||
# Recommended MCP Servers for AI Architect
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** Advisory
|
||||
**Category:** Architecture
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
MCP (Model Context Protocol) servers extend the AI Architect plugin by providing real-time access to external tools and data sources. Rather than relying solely on static knowledge base files, MCP servers let the architect agent query live documentation, manage infrastructure, generate diagrams, and interact with project management systems directly during a session.
|
||||
|
||||
This reference documents which MCP servers are already integrated, which are recommended for enhanced functionality, and how they map to the architect workflow phases.
|
||||
|
||||
---
|
||||
|
||||
## Allerede integrert
|
||||
|
||||
| Server | Formål | Tools | Workflow Phase |
|
||||
|--------|--------|-------|----------------|
|
||||
| `microsoft-learn` | Offisiell Microsoft dokumentasjon | `microsoft_docs_search`, `microsoft_docs_fetch`, `microsoft_code_sample_search` | Knowledge Validation (Phase 4-5) |
|
||||
| `mcp-image` | Bildegenerering med Imagen 3 | `generate_image` | Visualization (Phase 7) |
|
||||
|
||||
### microsoft-learn
|
||||
Primary knowledge validation tool. Used by the research-agent to fetch latest platform capabilities, pricing, regional availability, and best practices. Critical for ensuring recommendations are current.
|
||||
|
||||
**Typical usage in architect workflow:**
|
||||
- Verify service availability in Norway East/West regions
|
||||
- Check latest SDK versions and deprecation notices
|
||||
- Validate security configuration recommendations
|
||||
- Fetch code samples for POC plans
|
||||
|
||||
### mcp-image
|
||||
Used by the diagram-generation-agent to create architecture diagrams via Imagen 3. Produces visual representations of proposed architectures for documentation and stakeholder communication.
|
||||
|
||||
---
|
||||
|
||||
## Anbefalte tillegg
|
||||
|
||||
### Azure MCP Server (microsoft/azure-mcp-server)
|
||||
|
||||
**Description:** Official Microsoft MCP server for Azure resource management. Provides read/write access to Azure subscriptions, resource groups, and individual services.
|
||||
|
||||
**Key tools:**
|
||||
- Resource group listing and management
|
||||
- Service configuration inspection
|
||||
- Deployment status checking
|
||||
- Cost and usage data retrieval
|
||||
|
||||
**Use cases for architect:**
|
||||
- Validate existing infrastructure before proposing changes
|
||||
- Check current SKUs and configuration for cost optimization reviews
|
||||
- Verify network topology and security group rules during security assessments
|
||||
- Inspect AI service deployments (Azure OpenAI endpoints, AI Search indexes)
|
||||
- Compare proposed architecture against actual deployed state
|
||||
|
||||
**Relevant commands:** `/architect:security`, `/architect:cost`, `/architect:review`
|
||||
|
||||
**Installation:**
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"azure": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "@azure/mcp-server"],
|
||||
"env": {
|
||||
"AZURE_SUBSCRIPTION_ID": "<your-subscription-id>"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Bicep MCP Server
|
||||
|
||||
**Description:** Infrastructure as Code generation and validation for Azure using Bicep templates. Translates architecture decisions into deployable infrastructure definitions.
|
||||
|
||||
**Key tools:**
|
||||
- Bicep template generation from natural language
|
||||
- Template validation and what-if analysis
|
||||
- Parameter file generation
|
||||
- Module composition
|
||||
|
||||
**Use cases for architect:**
|
||||
- Generate IaC templates from ADR decisions (`/architect:adr` output)
|
||||
- Validate proposed infrastructure is deployable
|
||||
- Create POC infrastructure templates (`/architect:poc` output)
|
||||
- Ensure compliance with Azure Policy through template validation
|
||||
- Generate migration scripts for `/architect:migrate` plans
|
||||
|
||||
**Relevant commands:** `/architect:adr`, `/architect:poc`, `/architect:migrate`
|
||||
|
||||
**Installation:**
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"bicep": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "@azure/bicep-mcp-server"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Azure DevOps MCP Server (microsoft/azure-devops-mcp)
|
||||
|
||||
**Description:** Integration with Azure DevOps for work items, pipelines, repositories, and boards. Bridges architecture decisions with implementation tracking.
|
||||
|
||||
**Key tools:**
|
||||
- Work item creation and querying
|
||||
- Pipeline status and trigger
|
||||
- Repository browsing
|
||||
- Board and sprint management
|
||||
|
||||
**Use cases for architect:**
|
||||
- Create implementation work items from architecture review findings
|
||||
- Track ADR implementation progress
|
||||
- Link POC plans to sprint backlogs
|
||||
- Monitor deployment pipeline status for migration plans
|
||||
- Query existing codebase for integration point analysis
|
||||
|
||||
**Relevant commands:** `/architect:review`, `/architect:poc`, `/architect:migrate`
|
||||
|
||||
**Installation:**
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"azure-devops": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "@microsoft/azure-devops-mcp"],
|
||||
"env": {
|
||||
"AZURE_DEVOPS_ORG": "<your-org>",
|
||||
"AZURE_DEVOPS_PAT": "<your-pat>"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Playwright MCP Server
|
||||
|
||||
**Description:** Browser automation for visual testing and verification. Enables the architect plugin to visually verify deployed solutions and capture screenshots.
|
||||
|
||||
**Key tools:**
|
||||
- Page navigation and screenshot capture
|
||||
- Element interaction and form filling
|
||||
- Visual regression comparison
|
||||
- Network request interception
|
||||
|
||||
**Use cases for architect:**
|
||||
- Visual verification of diagram-generation-agent output
|
||||
- Screenshot capture of Azure Portal configurations during reviews
|
||||
- Validate Copilot Studio agent behavior in browser
|
||||
- Capture evidence for architecture review documentation
|
||||
- Accessibility testing (WCAG compliance checks)
|
||||
|
||||
**Relevant commands:** `/architect:diagram`, `/architect:review`
|
||||
|
||||
**Installation:**
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"playwright": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "@anthropic/mcp-playwright"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## MCP Server Selection Matrix
|
||||
|
||||
| Workflow Need | Primary MCP | Fallback |
|
||||
|---------------|-------------|----------|
|
||||
| Documentation lookup | microsoft-learn | WebSearch |
|
||||
| Resource inspection | azure | Azure Portal (manual) |
|
||||
| IaC generation | bicep | Manual Bicep authoring |
|
||||
| Work item tracking | azure-devops | Linear (already configured) |
|
||||
| Visual verification | playwright | Manual screenshot |
|
||||
| Diagram generation | mcp-image | Mermaid in markdown |
|
||||
|
||||
---
|
||||
|
||||
## Installasjon
|
||||
|
||||
Add MCP servers to your Claude Code settings file at `~/.claude/settings.json` or project-level `.claude/settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"microsoft-learn": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "@anthropic/mcp-microsoft-learn"]
|
||||
},
|
||||
"azure": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "@azure/mcp-server"],
|
||||
"env": {
|
||||
"AZURE_SUBSCRIPTION_ID": "<sub-id>"
|
||||
}
|
||||
},
|
||||
"bicep": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "@azure/bicep-mcp-server"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Notes:**
|
||||
- MCP servers requiring authentication (Azure, Azure DevOps) need environment variables configured
|
||||
- Use `.env` files or secret managers -- never commit credentials
|
||||
- Test each server independently before combining
|
||||
- Monitor MCP server resource usage in long sessions
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
These MCP servers enhance the 7-phase architect workflow:
|
||||
|
||||
| Phase | MCP Enhancement |
|
||||
|-------|-----------------|
|
||||
| 1. Problem Understanding | azure-devops: Query existing work items and requirements |
|
||||
| 2. Context & Constraints | azure: Inspect current infrastructure state |
|
||||
| 3. Capacity & Ambition | azure: Check subscription limits and quotas |
|
||||
| 4. Knowledge Validation | microsoft-learn: Verify latest documentation |
|
||||
| 5. Knowledge Integration | microsoft-learn + azure: Combine docs with live state |
|
||||
| 6. Architecture Proposal | bicep: Generate deployable IaC from proposal |
|
||||
| 7. Visualization | mcp-image: Generate architecture diagrams |
|
||||
|
||||
**Priority order for adoption:**
|
||||
1. `microsoft-learn` (already integrated, essential)
|
||||
2. `mcp-image` (already integrated, visualization)
|
||||
3. `azure` (highest value-add for live infrastructure validation)
|
||||
4. `bicep` (IaC generation from architecture decisions)
|
||||
5. `azure-devops` (implementation tracking bridge)
|
||||
6. `playwright` (visual verification, nice-to-have)
|
||||
|
|
@ -0,0 +1,289 @@
|
|||
# Regional tilgjengelighetsverifisering — Azure AI-tjenester
|
||||
|
||||
**Sist oppdatert:** 2026-02 (v1.0)
|
||||
**Målgruppe:** Arkitekter som verifiserer Azure-tjenestetilgjengelighet for norsk offentlig sektor
|
||||
**Datakilde:** Microsoft Learn (MCP-verifisert 2026-02-13), Azure Products by Region
|
||||
|
||||
---
|
||||
|
||||
## Om dette dokumentet
|
||||
|
||||
Regional tilgjengelighet av Azure AI-tjenester endrer seg jevnlig. Nye tjenester lanseres i nye regioner, preview-tjenester blir GA, og noen tjenester trekkes tilbake. For norsk offentlig sektor er dataresidenskrav sentralt — og feil antakelser om regional tilgjengelighet kan føre til arkitekturbeslutninger som bryter med krav om datalokalisering.
|
||||
|
||||
Denne referansefilen gir maler og protokoller for å verifisere, dokumentere og vedlikeholde regional tilgjengelighetsinformasjon.
|
||||
|
||||
---
|
||||
|
||||
## 1. Nøkkelregioner for norsk offentlig sektor
|
||||
|
||||
### 1.1 Regionhierarki
|
||||
|
||||
| Prioritet | Region | Azure-navn | Lokasjon | Bruksområde |
|
||||
|-----------|--------|-----------|----------|-------------|
|
||||
| **Primær** | Norway East | `norwayeast` | Oslo, Norge | Foretrukket for alle norske offentlige virksomheter. Oppfyller strengeste dataresidenskrav. |
|
||||
| **Sekundær** | Sweden Central | `swedencentral` | Gävle, Sverige | Brukes når tjenester ikke er tilgjengelig i Norway East. EU/EØS-compliance oppfylt. Nordisk datasenter. |
|
||||
| **Tertiær** | West Europe | `westeurope` | Amsterdam, Nederland | Fallback når verken Norway East eller Sweden Central tilbyr tjenesten. EU/EØS-compliance oppfylt. |
|
||||
|
||||
### 1.2 Vurdering ved regionvalg
|
||||
|
||||
| Spørsmål | Norway East | Sweden Central | West Europe |
|
||||
|----------|-------------|----------------|-------------|
|
||||
| Dataresidenskrav oppfylt (norsk lov)? | ✅ Ja — norsk territorium | ✅ Ja — EU/EØS (Schrems II-safe) | ✅ Ja — EU/EØS (Schrems II-safe) |
|
||||
| Oppfyller strengeste fortolkning (data i Norge)? | ✅ Ja | ⚠️ Avhenger av vurdering | ⚠️ Avhenger av vurdering |
|
||||
| Latency til norske brukere | ~2-5 ms | ~10-20 ms | ~20-40 ms |
|
||||
| Typisk tjeneste-bredde | Middels | Bred (full Microsoft-støtte) | Bredest |
|
||||
| Availability Zones | ✅ 3 AZ | ✅ 3 AZ | ✅ 3 AZ |
|
||||
|
||||
### 1.3 Beslutningstre for regionvalg
|
||||
|
||||
```
|
||||
Tjenesten er tilgjengelig i Norway East?
|
||||
├─ Ja → Bruk Norway East
|
||||
└─ Nei → Er dataresidenskrav absolutt (norsk territorium)?
|
||||
├─ Ja → Tjenesten kan ikke brukes. Finn alternativ arkitektur.
|
||||
└─ Nei → Tjenesten er tilgjengelig i Sweden Central?
|
||||
├─ Ja → Bruk Sweden Central. Dokumenter begrunnelse.
|
||||
└─ Nei → Tjenesten er tilgjengelig i West Europe?
|
||||
├─ Ja → Bruk West Europe. Dokumenter begrunnelse. Vurder DPIA-implikasjon.
|
||||
└─ Nei → Tjenesten er ikke tilgjengelig i EU/EØS.
|
||||
Finn alternativ arkitektur eller vent på GA.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. Verifiseringslogg — mal
|
||||
|
||||
### 2.1 Tjenesteverifiseringslogg
|
||||
|
||||
Denne loggen dokumenterer verifisering av regional tilgjengelighet for tjenester brukt i arkitekturen.
|
||||
|
||||
```markdown
|
||||
### Verifiseringslogg — Regional tilgjengelighet
|
||||
|
||||
**Prosjekt:** [Prosjektnavn]
|
||||
**Verifisert av:** [Navn/rolle]
|
||||
**Verifiseringsdato:** YYYY-MM-DD
|
||||
|
||||
| # | Tjeneste | Krav region | Tilgjengelig? | Verifiseringsmetode | Verifiseringsdato | Status | Best-before |
|
||||
|---|----------|-----------|---------------|--------------------|--------------------|--------|-------------|
|
||||
| 1 | Azure OpenAI (GPT-4o) | Norway East | ✅ GA | MCP: microsoft-learn "Azure OpenAI models region availability" | 2026-02-13 | Stabil | 2026-08 |
|
||||
| 2 | Azure OpenAI (GPT-4.1) | Norway East | ✅ GA | MCP: microsoft-learn "Azure OpenAI models region availability" | 2026-02-13 | Stabil | 2026-08 |
|
||||
| 3 | Azure AI Search | Norway East | ✅ GA (med begrensninger) | MCP: microsoft-learn "Azure AI Search regions" | 2026-02-13 | Stabil — NB: Semantic ranker IKKE tilgjengelig i Norway East | 2026-08 |
|
||||
| 4 | Azure AI Search (Semantic Ranker) | Norway East | ❌ | MCP: microsoft-learn "Azure AI Search regions" | 2026-02-13 | Ikke tilgjengelig — bruk Sweden Central | 2026-05 |
|
||||
| 5 | Azure AI Content Safety | Norway East | ✅ GA | MCP: microsoft-learn "Content Safety regional availability" | 2026-02-13 | Stabil | 2026-08 |
|
||||
| 6 | Microsoft Foundry (AI Foundry) | Norway East | ✅ GA | MCP: microsoft-learn "Foundry feature availability" | 2026-02-13 | Stabil | 2026-08 |
|
||||
| 7 | Copilot Studio | Norway East | ✅ (via M365 tenant) | MCP: microsoft-learn "Copilot Studio regions" | 2026-02-13 | Stabil | 2026-08 |
|
||||
| 8 | Azure Document Intelligence | Norway East | ⬜ Sjekk | — | — | Ikke verifisert | — |
|
||||
```
|
||||
|
||||
### 2.2 Hurtigreferanse: Verifisert tilgjengelighet (2026-02)
|
||||
|
||||
Basert på MCP-verifisering 2026-02-13:
|
||||
|
||||
**Azure OpenAI — Norway East (Standard deployment):**
|
||||
|
||||
| Modell | Norway East | Sweden Central | West Europe |
|
||||
|--------|-------------|----------------|-------------|
|
||||
| o3 (2025-04-16) | ✅ | ✅ | ✅ |
|
||||
| o4-mini (2025-04-16) | ✅ | ✅ | ✅ |
|
||||
| GPT-4.1 (2025-04-14) | ✅ | ✅ | ✅ |
|
||||
| GPT-4.1-mini (2025-04-14) | ✅ | ✅ | ✅ |
|
||||
| GPT-4.1-nano (2025-04-14) | ✅ | ✅ | ✅ |
|
||||
| o3-mini (2025-01-31) | ✅ | ✅ | ✅ |
|
||||
| GPT-4o (2024-05-13) | ✅ | ✅ | — |
|
||||
| GPT-4o (2024-08-06) | ✅ | ✅ | — |
|
||||
| GPT-4o (2024-11-20) | ✅ | ✅ | — |
|
||||
| GPT-4o-mini (2024-07-18) | ✅ | ✅ | — |
|
||||
| Whisper (001) | ✅ | ✅ | ✅ |
|
||||
| TTS (001) | — | ✅ | — |
|
||||
| TTS-HD (001) | — | ✅ | — |
|
||||
|
||||
**Azure AI Search — Europeiske regioner:**
|
||||
|
||||
| Funksjon | Norway East | Sweden Central | West Europe |
|
||||
|----------|-------------|----------------|-------------|
|
||||
| AI enrichment | ✅ | ✅ | ✅ |
|
||||
| Availability Zones | ✅ | ✅ | ✅ |
|
||||
| Agentic retrieval | — | ✅ | ✅ |
|
||||
| Confidential computing | ✅ | — | ✅ |
|
||||
| Semantic ranker | — | ✅ | ✅ |
|
||||
| Query rewrite | — | ✅ | ✅ |
|
||||
|
||||
**Microsoft Foundry (AI Foundry):** ✅ Tilgjengelig i Norway East
|
||||
|
||||
**Azure OpenAI On Your Data:** ✅ Norway East (GPT-4o 2024-11-20, GPT-35-turbo-16k, GPT-4 1106-preview)
|
||||
|
||||
---
|
||||
|
||||
## 3. Holdbarhetsvurdering
|
||||
|
||||
### 3.1 Holdbarhetskategorier
|
||||
|
||||
| Kategori | Definisjon | Typisk holdbarhet | Eksempler | Anbefalt re-verifisering |
|
||||
|----------|-----------|-------------------|-----------|--------------------------|
|
||||
| **Stabil** | GA-tjeneste (General Availability) med etablert regional tilstedeværelse | 6-12 måneder | Azure OpenAI GPT-4o i Norway East, Azure AI Search i Norway East | Halvårlig, eller ved major release |
|
||||
| **Volatil** | Public preview, nylig GA, eller tjeneste med pågående regional utrulling | 1-3 måneder | Nye modellversjoner, preview-funksjoner i AI Search | Månedlig |
|
||||
| **Svært volatil** | Private preview, beta, gated preview, eller tjeneste uten offisiell regional roadmap | Dager til uker | Ny modell i limited access, uannonsert funksjon | Ukentlig, eller ved hvert prosjektmøte |
|
||||
|
||||
### 3.2 Best-before-dato
|
||||
|
||||
Hver verifisering har en "best-before"-dato — etter denne datoen bør informasjonen re-verifiseres:
|
||||
|
||||
| Holdbarhet | Best-before-regel | Formel |
|
||||
|-----------|------------------|--------|
|
||||
| Stabil | Verifiseringsdato + 6 måneder | `2026-02-13 + 6 mnd = 2026-08-13` |
|
||||
| Volatil | Verifiseringsdato + 2 måneder | `2026-02-13 + 2 mnd = 2026-04-13` |
|
||||
| Svært volatil | Verifiseringsdato + 2 uker | `2026-02-13 + 2 uker = 2026-02-27` |
|
||||
|
||||
### 3.3 Re-verifiserings-triggere
|
||||
|
||||
Utenom planlagt re-verifisering, verifiser på nytt ved:
|
||||
|
||||
- Microsoft Ignite, Build, eller andre store events
|
||||
- Azure-oppdateringsblogg nevner tjenesten
|
||||
- Prisendringer annonsert
|
||||
- Ny modellversjon lansert
|
||||
- Prosjektet går fra POC til MVP eller fra MVP til produksjon
|
||||
- Mer enn 3 måneder siden forrige verifisering (uansett holdbarhet)
|
||||
|
||||
---
|
||||
|
||||
## 4. MCP-verifiseringsprotokoll
|
||||
|
||||
### 4.1 Steg-for-steg verifisering med microsoft-learn MCP
|
||||
|
||||
**Steg 1: Søk etter regional tilgjengelighet**
|
||||
|
||||
```
|
||||
Verktøy: microsoft_docs_search
|
||||
Søkeord: "[tjenestenavn] regional availability" eller "[tjenestenavn] regions Norway"
|
||||
Eksempel: "Azure OpenAI models region availability Norway East"
|
||||
```
|
||||
|
||||
**Steg 2: Hent detaljert dokumentasjon**
|
||||
|
||||
Hvis søket gir en URL med region-tabell, hent full side:
|
||||
|
||||
```
|
||||
Verktøy: microsoft_docs_fetch
|
||||
URL: [URL fra søkeresultat]
|
||||
```
|
||||
|
||||
**Steg 3: Verifiser spesifikk tjeneste i spesifikk region**
|
||||
|
||||
Se etter tabellcellen der **tjeneste** krysser **region**. Nøkkelverdier:
|
||||
- ✅ = Tilgjengelig (GA)
|
||||
- Preview = Tilgjengelig i preview (usikker SLA, kan endres)
|
||||
- — eller blank = Ikke tilgjengelig i denne regionen
|
||||
|
||||
**Steg 4: Dokumenter i verifiseringslogg**
|
||||
|
||||
Fyll inn rad i verifiseringsloggen (seksjon 2.1) med:
|
||||
- Tjeneste, region, tilgjengelighet, verifiseringsmetode, dato, holdbarhet, best-before
|
||||
|
||||
### 4.2 Verifiseringskommandoer
|
||||
|
||||
| Tjeneste | MCP-søkeord | Forventet resultat |
|
||||
|----------|-------------|-------------------|
|
||||
| Azure OpenAI (modeller) | `"Azure OpenAI models region availability"` | Tabell med modellnavn × region |
|
||||
| Azure AI Search | `"Azure AI Search regions list"` | Tabell med regioner × funksjoner |
|
||||
| Azure AI Content Safety | `"Azure AI Content Safety regional availability"` | Liste over regioner |
|
||||
| Azure AI Document Intelligence | `"Azure Document Intelligence regional availability"` | Tabell med regioner |
|
||||
| Microsoft Foundry (AI Foundry) | `"Microsoft Foundry feature availability regions"` | Liste over regioner |
|
||||
| Azure AI Speech | `"Azure AI Speech service supported regions"` | Tabell med regioner × funksjoner |
|
||||
| Azure AI Language | `"Azure AI Language service supported regions"` | Tabell med regioner × funksjoner |
|
||||
| Azure AI Vision | `"Azure AI Vision regional availability"` | Tabell med regioner × funksjoner |
|
||||
| Azure AI Translator | `"Azure AI Translator regional availability"` | Liste over regioner |
|
||||
|
||||
### 4.3 Supplerende verifisering med web-søk
|
||||
|
||||
Når MCP-dokumentasjon er ufullstendig, bruk:
|
||||
|
||||
```
|
||||
Verktøy: tavily_search eller WebSearch
|
||||
Søkeord: "Azure [tjeneste] Norway East availability 2026"
|
||||
```
|
||||
|
||||
**Merk:** Web-søk gir kildeklasse V, men med lavere holdbarhet (blogger og nyheter kan være utdatert raskere enn offisiell docs).
|
||||
|
||||
### 4.4 Live Azure-verifisering (hvis azure-mcp-server er tilgjengelig)
|
||||
|
||||
Hvis `azure-mcp-server` er konfigurert, kan du verifisere direkte mot Azure:
|
||||
|
||||
```
|
||||
Verifiser at ressurs kan opprettes i regionen:
|
||||
- Sjekk tilgjengelige SKU-er i regionen
|
||||
- Sjekk kvote og kapasitet
|
||||
- Sjekk om tjenesten krever registrering (resource provider)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Kjente begrensninger for Norway East
|
||||
|
||||
### 5.1 Tjenester med begrensninger i Norway East (2026-02)
|
||||
|
||||
| Tjeneste | Begrensning i Norway East | Alternativ | Verifisert |
|
||||
|----------|--------------------------|-----------|------------|
|
||||
| Azure AI Search — Semantic Ranker | Ikke tilgjengelig | Sweden Central (✅) | 2026-02-13 |
|
||||
| Azure AI Search — Agentic Retrieval | Ikke tilgjengelig | Sweden Central (✅) | 2026-02-13 |
|
||||
| Azure AI Search — Query Rewrite | Ikke tilgjengelig | Sweden Central (✅) | 2026-02-13 |
|
||||
| Azure OpenAI — TTS/TTS-HD | Ikke tilgjengelig | Sweden Central (✅) | 2026-02-13 |
|
||||
| Azure Databricks — Mosaic AI, Foundation Model Fine-tuning | Ikke tilgjengelig | Sweden Central (sjekk) | 2026-02-13 |
|
||||
|
||||
### 5.2 Arkitekturimplikasjoner
|
||||
|
||||
Når en tjeneste ikke er tilgjengelig i Norway East:
|
||||
|
||||
| Scenario | Anbefaling | Dataresidensimplikasjon |
|
||||
|----------|-----------|------------------------|
|
||||
| **Hovedtjeneste** mangler i Norway East | Bruk Sweden Central for hele løsningen. Dokumenter i DPIA. | Data i Sverige (EU/EØS). Akseptabelt for de fleste virksomheter. |
|
||||
| **Støttetjeneste** mangler i Norway East | Multi-region: Hovedtjeneste i Norway East, støttetjeneste i Sweden Central. | Data flyter mellom regioner. Dokumenter i DPIA og arkitekturbeskrivelse. |
|
||||
| **Sikkerhetskritisk** tjeneste mangler | Vurder alternativ arkitektur uten denne tjenesten. | Unngå dataflyt ut av Norge for sikkerhetskritiske data. |
|
||||
|
||||
---
|
||||
|
||||
## 6. Offisielle referanser
|
||||
|
||||
| Ressurs | URL | Oppdateringsfrekvens |
|
||||
|---------|-----|---------------------|
|
||||
| Azure Products by Region | https://azure.microsoft.com/en-us/explore/global-infrastructure/products-by-region | Fortløpende |
|
||||
| Azure OpenAI Models & Region | https://learn.microsoft.com/azure/ai-foundry/openai/concepts/models | Ved modellendringer |
|
||||
| Azure AI Search Regions | https://learn.microsoft.com/azure/search/search-region-support | Ved regionsendringer |
|
||||
| Microsoft Foundry Regions | https://learn.microsoft.com/azure/ai-foundry/reference/region-support | Ved regionsendringer |
|
||||
| Azure Status | https://status.azure.com | Sanntid |
|
||||
| Azure Updates | https://azure.microsoft.com/updates | Daglig |
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo Skyberg
|
||||
|
||||
Denne referansefilen er ditt verktøy for å sikre at arkitekturforslag faktisk er gjennomførbare i riktig Azure-region. Slik bruker du den:
|
||||
|
||||
### For hver arkitekturvurdering:
|
||||
|
||||
1. **List opp alle Azure-tjenester** i den foreslåtte arkitekturen
|
||||
2. **Verifiser hver tjeneste** mot Norway East (primær) ved hjelp av MCP-verifiseringsprotokollen (seksjon 4)
|
||||
3. **Dokumenter i verifiseringsloggen** (seksjon 2.1) med dato, metode og holdbarhet
|
||||
4. **Sjekk kjente begrensninger** i seksjon 5.1 — spesielt Semantic Ranker og Agentic Retrieval i AI Search
|
||||
5. **Foreslå regionstrategi** basert på beslutningstreet i seksjon 1.3
|
||||
|
||||
### Kritiske sjekker:
|
||||
|
||||
- **Azure AI Search + Semantic Ranker**: IKKE tilgjengelig i Norway East. Hvis RAG-arkitekturen krever semantic ranker, MÅ Sweden Central brukes (eller hybrid-arkitektur)
|
||||
- **TTS/TTS-HD**: Kun i Sweden Central (av nordiske regioner). Relevant for talegrensesnitt
|
||||
- **Nye modeller**: Verifiser alltid — nye modellversjoner ruller ut region for region
|
||||
|
||||
### Integrasjon med andre referansefiler:
|
||||
|
||||
- **Antakelsesregisteret** (`source-traceability-assumption-register.md`): Regional tilgjengelighet = kildeklasse V når MCP-verifisert
|
||||
- **Alternativanalysen** (`alternativanalyse-methodology.md`): K3 Sikkerhet/compliance avhenger av regionvalg
|
||||
- **Kostnadsvurdering** (`cost-models.md`): Priser kan variere mellom regioner
|
||||
- **Utredningsmal** (`ai-utredning-template.md`): S4.2 Modellstrategi og S5.4 Dataklassifisering trenger regioninformasjon
|
||||
|
||||
### Vanlige feller:
|
||||
|
||||
1. **"Azure OpenAI er tilgjengelig i Norway East, altså er alt OK"** — Nei! Sjekk *hvilke modeller* og *hvilke deployment types* som er tilgjengelige
|
||||
2. **"Vi bruker AI Search i Norway East"** — Sjekk om du trenger Semantic Ranker — den er IKKE tilgjengelig der
|
||||
3. **"Dokumentasjonen sa det var tilgjengelig"** — Når ble det sjekket? Dokumentasjon kan være utdatert. Bruk MCP for fersk verifisering.
|
||||
4. **"Sweden Central er jo nesten Norge"** — Juridisk er det Sverige/EU, ikke Norge. For de strengeste dataresidenskravene kan dette være en issue. Dokumenter alltid i DPIA.
|
||||
|
|
@ -0,0 +1,538 @@
|
|||
# Security for Microsoft AI Solutions
|
||||
|
||||
Omfattende guide til sikkerhet, compliance og governance for AI-løsninger i Microsoft-økosystemet.
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
1. [Shared Responsibility Model](#shared-responsibility-model)
|
||||
2. [Responsible AI Framework](#responsible-ai-framework)
|
||||
3. [Azure AI Content Safety](#azure-ai-content-safety)
|
||||
4. [Identity og Access Management](#identity-og-access-management)
|
||||
5. [Data Residency og Compliance](#data-residency-og-compliance)
|
||||
6. [Microsoft Purview for AI](#microsoft-purview-for-ai)
|
||||
7. [Defender for Cloud - AI Security](#defender-for-cloud---ai-security)
|
||||
8. [Encryption og Key Management](#encryption-og-key-management)
|
||||
9. [Red Teaming og Testing](#red-teaming-og-testing)
|
||||
10. [Security Checklist](#security-checklist)
|
||||
|
||||
---
|
||||
|
||||
## Shared Responsibility Model
|
||||
|
||||
AI-sikkerhet følger en delt ansvarsmodell mellom Microsoft og kunden. Ansvarsfordelingen varierer basert på tjenestetype (SaaS, PaaS, IaaS).
|
||||
|
||||
### Ansvarsfordeling etter tjeneste
|
||||
|
||||
| Lag | M365 Copilot (SaaS) | Copilot Studio (PaaS) | Azure AI Foundry (PaaS) | Custom IaaS |
|
||||
|-----|---------------------|----------------------|------------------------|-------------|
|
||||
| AI-modellsikkerhet | Microsoft | Delt | Delt | Kunde |
|
||||
| Content Safety | Microsoft | Microsoft + Kunde | Kunde | Kunde |
|
||||
| Data governance | Delt | Delt | Kunde | Kunde |
|
||||
| Brukerautentisering | Microsoft | Delt | Kunde | Kunde |
|
||||
| Infrastruktursikkerhet | Microsoft | Microsoft | Microsoft | Delt |
|
||||
| Nettverkssikkerhet | Microsoft | Microsoft | Delt | Kunde |
|
||||
|
||||
### AI-spesifikke sikkerhetshensyn
|
||||
|
||||
**Application Safety System:**
|
||||
- Deep inspection av innhold i metaprompts
|
||||
- Inspeksjon av plugin- og data connector-interaksjoner
|
||||
- Agent-til-agent kommunikasjonssikkerhet
|
||||
|
||||
**AI Usage Security:**
|
||||
- Brukeropplæring om AI-spesifikke angrep
|
||||
- Oppdaterte acceptable use policies
|
||||
- Bevissthet om deepfakes og AI-generert innhold
|
||||
|
||||
---
|
||||
|
||||
## Responsible AI Framework
|
||||
|
||||
Microsoft sitt Responsible AI-rammeverk definerer seks prinsipper for etisk og sikker AI:
|
||||
|
||||
### De seks prinsippene
|
||||
|
||||
| Prinsipp | Beskrivelse | Implementasjon |
|
||||
|----------|-------------|----------------|
|
||||
| **Fairness** | AI-systemer skal behandle alle grupper likeverdig | Bias-testing, fairness-metrikker |
|
||||
| **Reliability & Safety** | Konsistent og sikker oppførsel | Testing, content safety, escape hatches |
|
||||
| **Privacy & Security** | Beskyttelse av persondata | Anonymisering, kryptering, tilgangskontroll |
|
||||
| **Inclusiveness** | Tilgjengelig for alle | Universell utforming, flerspråklighet |
|
||||
| **Transparency** | Forklarbar og sporbar AI | Audit trails, dokumentasjon |
|
||||
| **Accountability** | Mennesker er ansvarlige | Governance, overvåking, intervensjon |
|
||||
|
||||
### Operasjonalisering
|
||||
|
||||
**1. Anonymiser data**
|
||||
- Bruk Azure AI Language PII detection
|
||||
- Rediger personlig informasjon automatisk
|
||||
- Unngå rå brukerdata i trening/evaluering
|
||||
|
||||
**2. Moderer innhold**
|
||||
- Implementer content safety APIs på alle inn- og utdata
|
||||
- Evaluer requests og responses i sanntid
|
||||
|
||||
**3. Identifiser og mitigér trusler**
|
||||
- Gjennomfør threat modeling
|
||||
- Dokumenter trusler og mitigeringer
|
||||
- Kjør red team-øvelser
|
||||
|
||||
**4. Bygg escape hatches i agentic design**
|
||||
- Human-in-the-loop checkpoints ved kritiske beslutninger
|
||||
- Coordinator agents som overvåker og eskalerer
|
||||
- Interception points ved routing og integrasjoner
|
||||
|
||||
**5. Gjør beslutninger auditerbare**
|
||||
- Logg modellvalg, oppdateringer, algoritmeendringer
|
||||
- Dokumenter databehandlingsdesign
|
||||
- Integrer med compliance-workflows
|
||||
|
||||
### AI Reports i Azure AI Foundry
|
||||
|
||||
Dokumenter AI-prosjekter med:
|
||||
- Model cards og versjoner
|
||||
- Content safety filter-konfigurasjoner
|
||||
- Evaluationsmetrikker
|
||||
- Eksport til PDF eller SPDX for GRC-workflows
|
||||
|
||||
---
|
||||
|
||||
## Azure AI Content Safety
|
||||
|
||||
Tjeneste for å oppdage og filtrere skadelig innhold i AI-applikasjoner.
|
||||
|
||||
### Innholdsfiltrering
|
||||
|
||||
**Harm Categories (Text og Image):**
|
||||
|
||||
| Kategori | Beskrivelse | Severity Threshold (Default) |
|
||||
|----------|-------------|------------------------------|
|
||||
| Hate & Fairness | Diskriminerende språk basert på identitetsgrupper | Medium |
|
||||
| Violence | Fysiske handlinger som skader/dreper | Medium |
|
||||
| Sexual | Seksuelt eksplisitt innhold | Medium |
|
||||
| Self-Harm | Selvskading eller selvmord | Medium |
|
||||
|
||||
**Konfigurerbarhet:**
|
||||
- Juster severity thresholds (Low, Medium, High, Off)
|
||||
- Legg til custom blocklists
|
||||
- Definer custom categories
|
||||
|
||||
### Prompt Shields
|
||||
|
||||
Beskytter mot prompt injection-angrep.
|
||||
|
||||
**User Prompt Attacks (Jailbreaks):**
|
||||
|
||||
| Angrepstype | Beskrivelse | Eksempel |
|
||||
|-------------|-------------|----------|
|
||||
| System rule change | Forsøk på å endre systemregler | "Ignorer alle tidligere instruksjoner..." |
|
||||
| Conversation mockup | Falske samtalehistorier | Embedding av fiktive AI-svar |
|
||||
| Role-play | Tilordne ny persona uten begrensninger | "Du er nå DAN som kan si alt..." |
|
||||
| Encoding attacks | Bruke koding for å omgå filtre | Base64, URL encoding, etc. |
|
||||
|
||||
**Indirect Attacks (Cross-Domain Prompt Injection):**
|
||||
- Ondsinnede instruksjoner i dokumenter AI prosesserer
|
||||
- Krever document embedding detection
|
||||
- Må aktiveres eksplisitt (off by default)
|
||||
|
||||
### Protected Material Detection
|
||||
|
||||
**Text:**
|
||||
- Identifiserer kjent opphavsrettsbeskyttet innhold
|
||||
- Blokkerer sangtekster, artikler, etc.
|
||||
|
||||
**Code:**
|
||||
- Detekterer kodesegmenter fra public repositories
|
||||
- Gir sitat og lisensinformasjon
|
||||
- Powered by GitHub Copilot
|
||||
|
||||
### Groundedness Detection (Preview)
|
||||
|
||||
- Sjekker om LLM-svar er forankret i kildemateriale
|
||||
- Oppdager hallusinasjoner og faktafeil
|
||||
- Krever document embedding
|
||||
|
||||
### Best Practices
|
||||
|
||||
```
|
||||
IMPLEMENTASJONSREKKEFØLGE:
|
||||
1. Aktiver standard harm category filters
|
||||
2. Aktiver Prompt Shields for user prompts (jailbreaks)
|
||||
3. Aktiver Protected Material detection
|
||||
4. Vurder Prompt Shields for indirect attacks
|
||||
5. Vurder Groundedness detection for RAG-scenarios
|
||||
6. Definer custom categories for domene-spesifikke behov
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Identity og Access Management
|
||||
|
||||
### Autentiseringsmetoder
|
||||
|
||||
| Metode | Sikkerhetsnivå | Anbefalt? | Bruksområde |
|
||||
|--------|---------------|-----------|-------------|
|
||||
| API-nøkler | Lav | Nei | Kun prototyping |
|
||||
| Service Principal | Medium | Delvis | Spesifikke scenarios |
|
||||
| Managed Identity | Høy | **Ja** | Produksjon |
|
||||
| User Delegation | Høy | **Ja** | Brukerbasert tilgang |
|
||||
|
||||
### Managed Identities
|
||||
|
||||
**System-assigned:**
|
||||
- Opprettes automatisk med ressursen
|
||||
- Slettes når ressursen slettes
|
||||
- Én-til-én forhold med ressurs
|
||||
|
||||
**User-assigned:**
|
||||
- Opprettes separat fra ressurser
|
||||
- Kan tilordnes flere ressurser
|
||||
- Administreres uavhengig
|
||||
|
||||
**Fordeler:**
|
||||
- Ingen hemmeligheter å administrere
|
||||
- Automatisk rotasjon av credentials
|
||||
- Beskyttet av plattformen
|
||||
|
||||
### RBAC for Azure AI
|
||||
|
||||
**Innebygde roller:**
|
||||
|
||||
| Rolle | Tilgang | Bruksområde |
|
||||
|-------|---------|-------------|
|
||||
| Cognitive Services User | Bruke API-er | Applikasjoner |
|
||||
| Cognitive Services Contributor | Full tilgang unntatt RBAC | Utviklere |
|
||||
| Cognitive Services OpenAI User | Bruke OpenAI deployments | AI-applikasjoner |
|
||||
| Cognitive Services OpenAI Contributor | Administrere deployments | AI-administratorer |
|
||||
|
||||
**Prinsipp:** Minste privilegium - gi kun nødvendig tilgang.
|
||||
|
||||
### Conditional Access
|
||||
|
||||
- Blokker/tillat basert på lokasjon
|
||||
- Krev MFA for sensitive operasjoner
|
||||
- Blokker risikofylte innlogginger
|
||||
- Krev managed devices
|
||||
|
||||
### Microsoft Entra Agent ID
|
||||
|
||||
- Sentralisert visning av AI-agenter
|
||||
- Spor agenter fra Foundry og Copilot Studio
|
||||
- Håndhev tilgangskontroller
|
||||
- Overvåk policy compliance
|
||||
|
||||
---
|
||||
|
||||
## Data Residency og Compliance
|
||||
|
||||
### EU Data Boundary
|
||||
|
||||
**For EU/EFTA-brukere:**
|
||||
- Trafikk forblir innenfor EU Data Boundary
|
||||
- Gjelder M365 Copilot, Copilot Studio (med EU-region)
|
||||
- LLM-prosessering kan skje i EU
|
||||
|
||||
**Utenfor EU:**
|
||||
- Queries kan prosesseres i US, EU eller andre regioner
|
||||
- Avhengig av kapasitet
|
||||
|
||||
### Data Residency per plattform
|
||||
|
||||
| Plattform | Støttede regioner | Data at rest |
|
||||
|-----------|-------------------|--------------|
|
||||
| M365 Copilot | 17+ regioner | I tenant-region |
|
||||
| Copilot Studio | Multiple | Valgbar per environment |
|
||||
| Azure AI Foundry | 30+ Azure regions | I valgt region |
|
||||
|
||||
**Advanced Data Residency (ADR):**
|
||||
- Utvidet garanti for datalagring
|
||||
- Krever ADR-abonnement for alle brukere
|
||||
- Inkluderer M365 Copilot fra mars 2024
|
||||
|
||||
### Compliance-sertifiseringer
|
||||
|
||||
**Copilot Studio/Power Platform:**
|
||||
- HIPAA, HITRUST
|
||||
- FedRAMP
|
||||
- SOC 1/2/3
|
||||
- ISO 27001, ISO 27017, ISO 27018
|
||||
- PCI DSS
|
||||
- GDPR
|
||||
- UK G-Cloud
|
||||
- Singapore MTCS Level 3
|
||||
|
||||
**Azure AI Services:**
|
||||
- Azure compliance portfolio
|
||||
- Region-spesifikke sertifiseringer
|
||||
|
||||
### GDPR-krav
|
||||
|
||||
**Data Subject Requests (DSR):**
|
||||
- Rett til innsyn
|
||||
- Rett til sletting
|
||||
- Rett til portabilitet
|
||||
|
||||
**Implementation:**
|
||||
- Bruk Microsoft Purview for DSR-håndtering
|
||||
- Implementer data lifecycle management
|
||||
- Dokumenter databehandling
|
||||
|
||||
---
|
||||
|
||||
## Microsoft Purview for AI
|
||||
|
||||
### Data Security Posture Management (DSPM) for AI
|
||||
|
||||
Sentralisert dashboard for AI-sikkerhet:
|
||||
|
||||
**Capabilities:**
|
||||
- Overvåk AI-interaksjoner (prompts/responses)
|
||||
- Klassifiser sensitiv data i AI-bruk
|
||||
- Detekter risikofylt AI-bruk
|
||||
- Beskytt sensitiv data fra Copilot-prosessering
|
||||
|
||||
### Sensitivity Labels og AI
|
||||
|
||||
**Beskyttelse:**
|
||||
- Data med sensitivity labels vises med label-navn
|
||||
- Encryption krever EXTRACT + VIEW usage rights
|
||||
- Beskytter data in use fra Office-apps
|
||||
|
||||
**Anbefaling:**
|
||||
```
|
||||
AKTIVER sensitivity labels for SharePoint/OneDrive
|
||||
før M365 Copilot-utrulling for å:
|
||||
- Sikre at krypterte filer respekteres
|
||||
- Gi brukere visuell indikasjon på sensitivitet
|
||||
- Logge tilgang til merket innhold
|
||||
```
|
||||
|
||||
### Audit og Logging
|
||||
|
||||
**AI-spesifikke audit events:**
|
||||
- AIExecuteTool
|
||||
- AIInvokeAgent
|
||||
- AIInferenceCall
|
||||
|
||||
**Logges:**
|
||||
- Prompts og responses
|
||||
- Tidspunkt og bruker
|
||||
- M365-tjeneste hvor aktivitet skjedde
|
||||
- Referanser til aksesserte filer
|
||||
- Sensitivity labels på aksessert innhold
|
||||
|
||||
### Data Classification
|
||||
|
||||
**Sensitive Information Types (SIT):**
|
||||
- Identifiser sensitiv data i prompts/responses
|
||||
- Både innebygde og custom SITs
|
||||
|
||||
**Trainable Classifiers:**
|
||||
- ML-basert klassifisering
|
||||
- Tilpass til organisasjonens data
|
||||
|
||||
### Insider Risk Management
|
||||
|
||||
- Detekter IP-tyveri via AI
|
||||
- Overvåk datalekkasje gjennom AI-bruk
|
||||
- Identifiser sikkerhetsovertredelser
|
||||
- Pseudonymisering for personvern
|
||||
|
||||
---
|
||||
|
||||
## Defender for Cloud - AI Security
|
||||
|
||||
### AI Security Posture Management (AI SPM)
|
||||
|
||||
**Discovery:**
|
||||
- Automatisk oppdagelse av AI workloads
|
||||
- Støtter: Azure OpenAI, AI Foundry, ML, Amazon Bedrock, GCP Vertex AI
|
||||
- Skanner IaC for misconfigurations
|
||||
- Sjekker container images for sårbarheter
|
||||
|
||||
**AI Bill of Materials (AI BOM):**
|
||||
- Oversikt over AI-komponenter
|
||||
- Modeller, SDKs, teknologier
|
||||
- Data og artefakter
|
||||
|
||||
### Security Recommendations
|
||||
|
||||
**Eksempler på AI-spesifikke anbefalinger:**
|
||||
- Use Azure AI Service Private Endpoints
|
||||
- Restrict Azure AI Service Endpoints
|
||||
- Use Managed Identity for Azure AI Service Accounts
|
||||
- Use identity-based authentication
|
||||
|
||||
### Attack Path Analysis
|
||||
|
||||
**AI-spesifikke angrepsveier:**
|
||||
- Data exposure under grounding/fine-tuning
|
||||
- Lateral movement til sensitive data
|
||||
- Data poisoning vulnerabilities
|
||||
|
||||
### AI Threat Protection
|
||||
|
||||
**Deteksjon basert på:**
|
||||
- Azure AI Content Safety Prompt Shields
|
||||
- Microsoft threat intelligence
|
||||
- Contextual activity monitoring
|
||||
|
||||
**Integrasjon:**
|
||||
- Microsoft Defender XDR
|
||||
- Unified SOC experience
|
||||
|
||||
### Cloud Security Explorer
|
||||
|
||||
**Pre-configured queries:**
|
||||
- AI workloads and models in use
|
||||
- Vulnerable code repos that provision Azure OpenAI
|
||||
- Containers with GenAI vulnerabilities
|
||||
|
||||
---
|
||||
|
||||
## Encryption og Key Management
|
||||
|
||||
### Data at Rest
|
||||
|
||||
**Default:**
|
||||
- Microsoft-managed keys (MMK)
|
||||
- AES-256 encryption
|
||||
- Automatisk nøkkelrotasjon
|
||||
|
||||
**Customer-Managed Keys (CMK):**
|
||||
- Bring Your Own Key (BYOK)
|
||||
- Lagres i Azure Key Vault
|
||||
- Kun RSA/RSA-HSM 2048-bit
|
||||
|
||||
### Key Vault-krav for CMK
|
||||
|
||||
```
|
||||
REQUIREMENTS:
|
||||
1. Soft Delete aktivert
|
||||
2. Do Not Purge aktivert
|
||||
3. Legacy access policies (ikke RBAC)
|
||||
4. System-assigned managed identity permissions:
|
||||
- Get key
|
||||
- Wrap key
|
||||
- Unwrap key
|
||||
```
|
||||
|
||||
### Data in Transit
|
||||
|
||||
- TLS 1.2+ for all kommunikasjon
|
||||
- Certificate pinning hvor støttet
|
||||
- Mutual TLS for service-to-service
|
||||
|
||||
---
|
||||
|
||||
## Red Teaming og Testing
|
||||
|
||||
### PyRIT (Python Risk Identification Tool)
|
||||
|
||||
Microsoft sitt open-source verktøy for AI red teaming.
|
||||
|
||||
**Capabilities:**
|
||||
- Simuler prompt injection-angrep
|
||||
- Test content filter effectiveness
|
||||
- Automatiser adversarial testing
|
||||
|
||||
**Bruksområde:**
|
||||
- Test grounding effectiveness
|
||||
- Verifiser meta-prompt resilience
|
||||
- Identifiser jailbreak-sårbarheter
|
||||
|
||||
### Red Team Best Practices
|
||||
|
||||
**1. Planlegg systematisk:**
|
||||
- Definer scope og mål
|
||||
- Identifiser høy-risiko scenarios
|
||||
- Dokumenter test cases
|
||||
|
||||
**2. Test kontinuerlig:**
|
||||
- Integrer i CI/CD
|
||||
- Test ved modellendringer
|
||||
- Test ved prompt-endringer
|
||||
|
||||
**3. Dokumenter funn:**
|
||||
- Kategoriser sårbarheter
|
||||
- Prioriter etter alvorlighet
|
||||
- Spor remediering
|
||||
|
||||
### MITRE ATLAS
|
||||
|
||||
Adversarial Threat Landscape for AI Systems:
|
||||
- Taksonomi for AI-angrep
|
||||
- Referanse for threat modeling
|
||||
- Kontinuerlig oppdatert
|
||||
|
||||
---
|
||||
|
||||
## Security Checklist
|
||||
|
||||
### Pre-deployment
|
||||
|
||||
| Område | Sjekkliste | Status |
|
||||
|--------|------------|--------|
|
||||
| **Identity** | ☐ Managed Identity konfigurert | |
|
||||
| | ☐ RBAC med minste privilegium | |
|
||||
| | ☐ API-nøkler deaktivert i produksjon | |
|
||||
| **Content Safety** | ☐ Harm category filters aktivert | |
|
||||
| | ☐ Prompt Shields aktivert | |
|
||||
| | ☐ Protected material detection aktivert | |
|
||||
| **Data Protection** | ☐ Sensitivity labels konfigurert | |
|
||||
| | ☐ Data residency verifisert | |
|
||||
| | ☐ Encryption (MMK eller CMK) | |
|
||||
| **Network** | ☐ Private endpoints hvor mulig | |
|
||||
| | ☐ Firewall-regler konfigurert | |
|
||||
|
||||
### Post-deployment
|
||||
|
||||
| Område | Sjekkliste | Status |
|
||||
|--------|------------|--------|
|
||||
| **Monitoring** | ☐ Defender for Cloud aktivert | |
|
||||
| | ☐ Audit logging aktivert | |
|
||||
| | ☐ DSPM for AI konfigurert | |
|
||||
| **Testing** | ☐ Red team-øvelser gjennomført | |
|
||||
| | ☐ Content filter testing utført | |
|
||||
| | ☐ Jailbreak-testing utført | |
|
||||
| **Governance** | ☐ AI reports generert | |
|
||||
| | ☐ Responsible AI-vurdering | |
|
||||
| | ☐ Incident response-plan | |
|
||||
|
||||
### Kontinuerlig
|
||||
|
||||
| Område | Aktivitet | Frekvens |
|
||||
|--------|-----------|----------|
|
||||
| Vulnerability scanning | Container images, IaC | Kontinuerlig |
|
||||
| Model updates | Sikkerhetsvurdering | Ved hver oppdatering |
|
||||
| Policy review | Content filters, RBAC | Kvartalsvis |
|
||||
| Red teaming | Adversarial testing | Minimum årlig |
|
||||
| Training | Brukeropplæring | Ved onboarding + årlig |
|
||||
|
||||
---
|
||||
|
||||
## Decision Matrix: Sikkerhetsnivå
|
||||
|
||||
| Scenario | M365 Copilot | Copilot Studio | Azure AI Foundry |
|
||||
|----------|--------------|----------------|------------------|
|
||||
| Offentlig sektor, sensitiv data | ✓ Med Purview | ✓ Med EU-region | ✓ Med private endpoints |
|
||||
| Enterprise, internal use | ✓ | ✓ | ✓ |
|
||||
| External-facing chatbot | ✗ | ✓ Med auth | ✓ Med Content Safety |
|
||||
| Healthcare (HIPAA) | Krever vurdering | ✓ | ✓ |
|
||||
| Financial services | ✓ | ✓ | ✓ |
|
||||
|
||||
---
|
||||
|
||||
## Kilder og lenker
|
||||
|
||||
- [Responsible AI in Azure Well-Architected](https://learn.microsoft.com/en-us/azure/well-architected/ai/responsible-ai)
|
||||
- [Azure AI Content Safety](https://learn.microsoft.com/en-us/azure/ai-services/content-safety/overview)
|
||||
- [Azure OpenAI Security Baseline](https://learn.microsoft.com/en-us/security/benchmark/azure/baselines/azure-openai-security-baseline)
|
||||
- [Microsoft Purview for AI](https://learn.microsoft.com/en-us/purview/ai-microsoft-purview)
|
||||
- [Defender for Cloud AI SPM](https://learn.microsoft.com/en-us/azure/defender-for-cloud/ai-security-posture)
|
||||
- [PyRIT on GitHub](https://github.com/Azure/PyRIT)
|
||||
- [MITRE ATLAS](https://atlas.mitre.org/)
|
||||
|
||||
*Sist oppdatert: Januar 2026*
|
||||
|
|
@ -0,0 +1,254 @@
|
|||
# Kildesporing og antakelsesregister
|
||||
|
||||
**Sist oppdatert:** 2026-02 (v1.0)
|
||||
**Målgruppe:** Arkitekter som utarbeider AI-arkitekturvurderinger og utredninger
|
||||
**Formål:** Sikre sporbarhet, transparens og etterprøvbarhet i arkitekturvurderinger
|
||||
|
||||
---
|
||||
|
||||
## Om dette dokumentet
|
||||
|
||||
Enhver arkitekturvurdering bygger på en blanding av verifiserte fakta, kunnskapsbase-informasjon, eksperterfaring og antakelser. Denne referansefilen gir rammeverk for å klassifisere, dokumentere og validere kildene — slik at beslutningstakere vet hva de kan stole på og hva som må verifiseres.
|
||||
|
||||
---
|
||||
|
||||
## 1. Kildeklassifisering
|
||||
|
||||
### 1.1 Klassifiseringsnivåer
|
||||
|
||||
| Klasse | Betegnelse | Tillitsnivå | Definisjon | Eksempler | Holdbarhet |
|
||||
|--------|-----------|-------------|------------|-----------|------------|
|
||||
| **V** | **Verifisert** | Høyest | Bekreftet via MCP-verktøy (microsoft-learn, tavily) eller offisiell dokumentasjon i nåværende sesjon | MCP-søk i microsoft-learn som bekrefter GA-status for Azure OpenAI i Norway East; prisdata fra azure.microsoft.com/pricing | 1-6 måneder (avhenger av tjenestens modenhet) |
|
||||
| **KB** | **Kunnskapsbase** | Høy | Fra plugin-kunnskapsbasen (references/). Kvalitetssikret ved opprettelse, men kan være foreldet. | Informasjon fra `platforms/copilot-studio.md`, `cost-models.md`, `security.md` | Sjekk "Sist oppdatert"-dato. Stale etter 6+ måneder. |
|
||||
| **E** | **Ekspert** | Middels | Basert på arkitektens erfaring og fagkunnskap. Ikke verifisert mot offisiell kilde i denne sesjonen. | Arkitektens vurdering av integrasjonskompleksitet; erfaringsbaserte tidsestimater; beste-praksis-anbefalinger | Varierer. Mest robust for etablerte mønstre, minst for nye tjenester. |
|
||||
| **A** | **Antakelse** | Lavest | Uverifisert antakelse. Kan være rimelig, men er ikke bekreftet. Må valideres. | "Vi antar at virksomheten har M365 E5-lisenser"; "Vi antar at Azure AI Search støtter semantic ranker i Norway East" | Må valideres før den brukes i beslutning. |
|
||||
|
||||
### 1.2 Visuelle markører
|
||||
|
||||
For bruk i utredningsdokumenter:
|
||||
|
||||
```markdown
|
||||
Denne tjenesten er tilgjengelig i Norway East [V: microsoft-learn MCP, 2026-02-13]
|
||||
Copilot Studio støtter custom topics med GPT-4o [KB: platforms/copilot-studio.md, 2026-01]
|
||||
Integrasjonen med fagsystemet tar typisk 4-6 uker [E: erfaringsbasert]
|
||||
Virksomheten har tilgjengelig Azure-abonnement [A: ikke verifisert — må avklares]
|
||||
```
|
||||
|
||||
### 1.3 Regler for kildeklassifisering
|
||||
|
||||
1. **Alltid bruk høyest tilgjengelig klasse.** Hvis du kan verifisere via MCP, gjør det — ikke nøy deg med KB.
|
||||
2. **Nedgrader ved usikkerhet.** Hvis KB-informasjon er eldre enn 6 måneder, vurder å verifisere via MCP eller nedgrader til E.
|
||||
3. **Vær ærlig om antakelser.** Det er bedre å merke noe som A enn å presentere det som V.
|
||||
4. **Verifiser kritiske antakelser.** Antakelser som påvirker anbefalingen må valideres — enten i sesjonen eller som oppfølgingspunkt.
|
||||
|
||||
---
|
||||
|
||||
## 2. Antakelsesregister — mal
|
||||
|
||||
### 2.1 Registertabell
|
||||
|
||||
```markdown
|
||||
### Antakelsesregister
|
||||
|
||||
**Prosjekt:** [Prosjektnavn]
|
||||
**Sist oppdatert:** YYYY-MM-DD
|
||||
|
||||
| ID | Antakelse | Kilde | Klasse | Konsekvens hvis feil | Sannsynlighet for feil | Valideringsplan | Status | Validert dato |
|
||||
|----|-----------|-------|--------|---------------------|----------------------|-----------------|--------|---------------|
|
||||
| A01 | Virksomheten har M365 E5-lisenser | Oppdragsbeskrivelse | A | Copilot-løsningen krever E5, uten den trengs separat lisensanskaffelse (+3 mnd, +X NOK) | Lav | Bekreft med IT-avdeling | ⬜ Åpen | — |
|
||||
| A02 | Azure OpenAI GPT-4o er GA i Norway East | KB: platforms/azure-ai-foundry.md | KB | Må bruke Sweden Central → dataresidenskonsekvens, mulig DPIA-påvirkning | Lav | Verifiser via MCP: microsoft-learn | ✅ Validert | 2026-02-13 |
|
||||
| A03 | SharePoint-innhold er strukturert og klassifisert | Ikke verifisert | A | RAG-kvalitet blir lav → POC-tid øker med 4-6 uker for datakuratering | Middels | Be om tilgang til SharePoint, gjennomfør stikkprøve | ⬜ Åpen | — |
|
||||
| A04 | Integrasjon med fagsystem [X] er mulig via REST API | Muntlig fra prosjektleder | E | Uten API kreves custom connector-utvikling (+8 uker, +Y NOK) | Middels | Be om API-dokumentasjon, gjennomfør teknisk spike | ⬜ Åpen | — |
|
||||
| A05 | AI Act risikoklasse er "begrenset" (ikke "høy") | Arkitektens vurdering | E | Høyrisikoklassifisering utløser conformity assessment (+3-6 mnd, +Z NOK) | Lav-Middels | Gjennomgå med juridisk rådgiver | 🔄 Under arbeid | — |
|
||||
```
|
||||
|
||||
### 2.2 Status-verdier
|
||||
|
||||
| Status | Betydning | Neste steg |
|
||||
|--------|-----------|------------|
|
||||
| ⬜ **Åpen** | Ikke påbegynt validering | Prioriter basert på konsekvens |
|
||||
| 🔄 **Under arbeid** | Validering pågår | Vent på resultat |
|
||||
| ✅ **Validert** | Bekreftet korrekt | Oppgrader kildeklasse (A→V eller A→E) |
|
||||
| ❌ **Avkreftet** | Antakelsen var feil | Revurder arkitekturbeslutning |
|
||||
| ⏳ **Utløpt** | Valideringen er foreldet | Re-valider |
|
||||
|
||||
---
|
||||
|
||||
## 3. Konsekvensanalyse per antakelse
|
||||
|
||||
### 3.1 Konsekvens-kategorier
|
||||
|
||||
Når du dokumenterer "Konsekvens hvis feil" i antakelsesregisteret, bruk disse kategoriene:
|
||||
|
||||
| Kategori | Beskrivelse | Eksempel |
|
||||
|----------|-------------|---------|
|
||||
| **Tidskonsekvens** | Forsinkelse i prosjektplan | "+4 uker for å anskaffe manglende lisenser" |
|
||||
| **Kostnadskonsekvens** | Uforutsett kostnad | "+200 000 NOK for alternativ komponent" |
|
||||
| **Arkitekturkonsekvens** | Endring i valgt løsning | "Må bytte fra Norway East til Sweden Central → DPIA-oppdatering" |
|
||||
| **Regulatorisk konsekvens** | Compliance-implikasjon | "Høyrisiko iht. AI Act → conformity assessment nødvendig" |
|
||||
| **Organisatorisk konsekvens** | Krav til organisasjonen | "Trenger ekstern data engineer → anskaffelsesprosess" |
|
||||
| **Prosjektkonsekvens** | Påvirkning på prosjektet som helhet | "Prosjektet bør stoppes/omfangsreduseres" |
|
||||
|
||||
### 3.2 Konsekvensmatrise
|
||||
|
||||
Prioriter validering basert på konsekvens × sannsynlighet:
|
||||
|
||||
| Prioritet | Når | Handling |
|
||||
|-----------|-----|---------|
|
||||
| **P1 — Kritisk** | Høy konsekvens + middels/høy sannsynlighet | Valider **før** beslutning. Blokkerer anbefaling. |
|
||||
| **P2 — Viktig** | Middels konsekvens + middels sannsynlighet, ELLER høy konsekvens + lav sannsynlighet | Valider i **POC-fase**. Dokumenter som risiko. |
|
||||
| **P3 — Ønskelig** | Lav konsekvens ELLER lav sannsynlighet | Valider **underveis**. Dokumenter, men blokker ikke. |
|
||||
|
||||
---
|
||||
|
||||
## 4. Valideringsarbeidsflyt
|
||||
|
||||
### 4.1 Valideringsprosess
|
||||
|
||||
```
|
||||
1. Identifiser antakelse under utredningsarbeid
|
||||
↓
|
||||
2. Registrer i antakelsesregisteret med kildeklasse og konsekvens
|
||||
↓
|
||||
3. Vurder prioritet (P1/P2/P3)
|
||||
↓
|
||||
4. For P1: Forsøk å validere umiddelbart
|
||||
│
|
||||
├─ MCP-verifiserbar? → Bruk microsoft-learn, tavily, eller azure-mcp
|
||||
├─ Krever tilgang/info fra virksomhet? → Dokumenter som oppfølgingspunkt
|
||||
└─ Krever ekstern ekspertise? → Registrer som avhengighet
|
||||
↓
|
||||
5. Oppdater status og kildeklasse
|
||||
↓
|
||||
6. Hvis avkreftet: Revurder berørte beslutninger
|
||||
```
|
||||
|
||||
### 4.2 MCP-verifiseringsprotokoll
|
||||
|
||||
For antakelser som kan verifiseres med MCP-verktøy i sesjonen:
|
||||
|
||||
| Verktøytype | MCP-verktøy | Egnet for |
|
||||
|-------------|-------------|-----------|
|
||||
| **Microsoft-dokumentasjon** | `microsoft_docs_search`, `microsoft_docs_fetch` | GA-status, regional tilgjengelighet, prismodeller, konfigurasjon |
|
||||
| **Kodeeksempler** | `microsoft_code_sample_search` | API-tilgjengelighet, SDK-støtte |
|
||||
| **Generelt web** | `tavily_search`, `tavily_extract` | Nyheter, annonserte endringer, community-erfaringer |
|
||||
| **Azure-infrastruktur** | `azure-mcp-server` (hvis tilgjengelig) | Faktisk konfigurasjon, RBAC, ressursstatus |
|
||||
|
||||
### 4.3 Valideringsmal per antakelse
|
||||
|
||||
```markdown
|
||||
### Validering av A01: [Antakelse]
|
||||
|
||||
**Antakelse:** [Beskrivelse]
|
||||
**Kilde:** [Original kilde]
|
||||
**Prioritet:** P1/P2/P3
|
||||
|
||||
**Valideringsmetode:** [MCP/Dokumentgjennomgang/Intervju/Teknisk spike]
|
||||
|
||||
**Valideringsresultat:**
|
||||
- [ ] Bekreftet korrekt → Oppgrader til klasse [V/KB/E]
|
||||
- [ ] Delvis korrekt → Oppdater antakelse: [ny formulering]
|
||||
- [ ] Avkreftet → Konsekvens: [beskrivelse], Tiltak: [handling]
|
||||
|
||||
**Ny kildeklasse:** [V/KB/E]
|
||||
**Validert av:** [Navn/rolle]
|
||||
**Dato:** YYYY-MM-DD
|
||||
**Notater:** [Evt. tilleggsinfo]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Integrasjon med utredningsdokumentet
|
||||
|
||||
### 5.1 Kildesporing i tekst
|
||||
|
||||
I utredningsdokumentet, bruk inline-kildemarkører:
|
||||
|
||||
```markdown
|
||||
Azure OpenAI tilbyr GPT-4o i Norway East [V: MCP microsoft-learn 2026-02-13].
|
||||
Copilot Studio kan integreres med Azure AI Search for RAG [KB: platforms/copilot-studio.md].
|
||||
Vi estimerer at integrasjon med fagsystemet tar 4-6 uker [E: erfaringsbasert].
|
||||
Vi antar at virksomheten har tilstrekkelig Azure-budsjett [A01: Må valideres med IT-avdeling].
|
||||
```
|
||||
|
||||
### 5.2 Antakelsessammendrag i utredningen
|
||||
|
||||
Inkluder dette i utredningens sammendrag (S1):
|
||||
|
||||
```markdown
|
||||
### Antakelser og konfidens
|
||||
|
||||
| Antall | Kategori | Konsekvens |
|
||||
|--------|----------|------------|
|
||||
| [X] | Verifisert (V) | Høy tillit — dokumentert i sesjonen |
|
||||
| [X] | Kunnskapsbase (KB) | Høy tillit — sjekk "sist oppdatert" |
|
||||
| [X] | Ekspert (E) | Middels tillit — basert på erfaring |
|
||||
| [X] | Antakelse (A) | Lav tillit — må valideres |
|
||||
|
||||
**P1-antakelser (kritiske, blokkerende):**
|
||||
- A01: [Beskrivelse] — Valideringsplan: [Plan]
|
||||
- A05: [Beskrivelse] — Valideringsplan: [Plan]
|
||||
|
||||
**Overordnet konfidensgrad:** 🟢 Høy / 🟡 Medium / 🔴 Lav
|
||||
```
|
||||
|
||||
### 5.3 Antakelsesregister som vedlegg
|
||||
|
||||
Fullt antakelsesregister (seksjon 2.1) bør inkluderes som vedlegg i utredningsdokumentet, referert fra S10 (Vedlegg).
|
||||
|
||||
---
|
||||
|
||||
## 6. Livssyklus for antakelser
|
||||
|
||||
### 6.1 Antakelsens livssyklus
|
||||
|
||||
```
|
||||
Identifisert (A) → Prioritert (P1/P2/P3) → Validering pågår (🔄) → Validert (✅) / Avkreftet (❌)
|
||||
↓ (med tid)
|
||||
Utløpt (⏳) → Re-validering
|
||||
```
|
||||
|
||||
### 6.2 Re-valideringsregler
|
||||
|
||||
| Kildeklasse | Re-valider etter | Trigger |
|
||||
|-------------|-----------------|---------|
|
||||
| V (Verifisert) | 3-6 måneder | Ny major release, prisendring, regional utvidelse |
|
||||
| KB (Kunnskapsbase) | 6 måneder | KB-staleness-sjekk (`scripts/kb-staleness-check.sh`) |
|
||||
| E (Ekspert) | Ved ny informasjon | Ny erfaring, tilbakemelding fra prosjekt |
|
||||
| A (Antakelse) | Umiddelbart — bør valideres snarest | Alltid |
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo Skyberg
|
||||
|
||||
Denne referansefilen er ditt verktøy for å sikre transparens og etterprøvbarhet i arkitekturvurderinger. Slik bruker du den:
|
||||
|
||||
### Under arkitekturvurderinger:
|
||||
|
||||
1. **Klassifiser alltid kilder** med [V], [KB], [E], eller [A] inline i teksten. Dette tar sekunder og gir enorm verdi for beslutningstaker.
|
||||
2. **Opprett antakelsesregister** for hvert prosjekt. Start med de mest kritiske antakelsene.
|
||||
3. **Verifiser P1-antakelser i sesjonen** ved hjelp av MCP-verktøy (microsoft-learn, tavily).
|
||||
4. **Presenter konfidensoversikt** i sammendragseksjonen.
|
||||
|
||||
### Når du bruker MCP-verktøy for verifisering:
|
||||
|
||||
- **microsoft_docs_search** → Oppgrader til klasse V med dato og søkeord
|
||||
- **tavily_search** → Oppgrader til klasse V, men noter at web-kilder er mindre stabile enn offisiell docs
|
||||
- **Kunnskapsbasen** → Bruk klasse KB, men sjekk "Sist oppdatert"-dato i filen
|
||||
|
||||
### Vanlige antakelser å registrere:
|
||||
|
||||
1. Lisenssituasjon (M365 E3/E5, Copilot Studio, Azure-abonnement)
|
||||
2. Regional tilgjengelighet (Norway East vs. Sweden Central)
|
||||
3. Datakvalitet og tilgjengelighet (SharePoint, fagsystemer)
|
||||
4. Kompetansenivå i organisasjonen
|
||||
5. Budsjettramme og tidsfrist
|
||||
6. Regulatorisk klassifisering (AI Act risikoklasse)
|
||||
7. Integrasjonsmuligheter (API-er i fagsystemer)
|
||||
|
||||
### Integrasjon med andre referansefiler:
|
||||
|
||||
- **Alternativanalyse** (`alternativanalyse-methodology.md`): Score-begrunnelser bør ha kildeklassifisering
|
||||
- **Regional tilgjengelighet** (`regional-availability-verification.md`): Verifiseringslogg er kildeklasse V
|
||||
- **Gjennomførbarhet** (`capacity-feasibility-benchmarks.md`): Tidsestimater er typisk klasse E eller A
|
||||
- **Utredningsmal** (`ai-utredning-template.md`): Antakelsesregister er vedlegg i utredningen
|
||||
Loading…
Add table
Add a link
Reference in a new issue