feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command
Add /ultraresearch-local for structured research combining local codebase analysis with external knowledge via parallel agent swarms. Produces research briefs with triangulation, confidence ratings, and source quality assessment. New command: /ultraresearch-local with modes --quick, --local, --external, --fg. New agents: research-orchestrator (opus), docs-researcher, community-researcher, security-researcher, contrarian-researcher, gemini-bridge (all sonnet). New template: research-brief-template.md. Integration: --research flag in /ultraplan-local accepts pre-built research briefs (up to 3), enriches the interview and exploration phases. Planning orchestrator cross-references brief findings during synthesis. Design principle: Context Engineering — right information to right agent at right time. Research briefs are structured artifacts in the pipeline: ultraresearch → brief → ultraplan --research → plan → ultraexecute. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen
commit
baa2d0220b
488 changed files with 213221 additions and 0 deletions
|
|
@ -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
|
||||
Loading…
Add table
Add a link
Reference in a new issue