Initial oppdragsstruktur for Standard Online

Etablerer 9-mappe-arbeidsstruktur basert på Forte sitt
startklar-malverk (Salg/_mal/startklar-malverk/), kalibrert
for Nivå 1 (avgrenset strategisk, 6-8 uker).

Inkluderer skeletter for:
- 1. Oppdrag og kontekst (oppdragsbeskrivelse, leveranser, rammer,
  interessenter, møtelogg, møtenotat-mal)
- 2. Organisasjonsforståelse (struktur, roller, nøkkelpersoner)
- 3. System- og datalandskap (SuperOffice, Business Central,
  nopCommerce — fylles ut i Fase A-B)
- 4. Informasjonsarkitektur (begrepskatalog, masterdata-og-eierskap,
  Data Governance prinsipper) — kjernen for leveranse 03 og 07
- 5. Personvern og sikkerhet (GDPR, Privacy by Design)
- 6. AI-rammeverk (operasjonelle prinsipper — ny for Standard,
  bygger på Forte AI Accelerator)
- 7. Standardisering og handlingsplan (avvik, prioritering, tiltak)
- 8. Kontinuerlig læring (intervjuguider, åpne spørsmål, funn)
- 9. Leveranser (Executive Summary, sluttrapport, leveranseplan)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

6.ai-rammeverk/ai-prinsipper.md

@@ -0,0 +1,59 @@
+---
+title: "AI-prinsipper — Standard Online"
+date: "YYYY-MM-DD"
+tags: ["ai", "prinsipper", "rammeverk"]
+refs:
+  - "../4.informasjonsarkitektur/masterdata-og-eierskap.md"
+  - "../5.personvern-og-sikkerhet/gdpr-oversikt.md"
+  - "identifiserbarhet-og-tilgang.md"
+  - "logging-og-sporbarhet.md"
+  - "human-in-the-loop.md"
+qa:
+  status: "draft"
+version: 1
+---
+
+# AI-prinsipper
+
+Operasjonelle prinsipper for AI-agenter hos Standard Online. **Dette er ikke en arkitektur-spec** — det er et sett premisser som arkitekturen må respektere. Konkret implementering avklares i en senere fase.
+
+## Grunnpremiss
+
+AI-agenter blir bare så pålitelige som dataene under dem. Kontroll og eierskap til data er fundamentet for å kunne sette agenter i produksjon. AI-fundamentet er bygget på [[../4.informasjonsarkitektur/masterdata-og-eierskap]] og [[../4.informasjonsarkitektur/data-governance-prinsipper]].
+
+## Fem prinsipper
+
+### 1. Identifiserbarhet — hver agent har egen identitet
+
+Ingen AI-agent skal opptre under en generisk eller delt identitet. Hver agent autentiseres og autoriseres som en egen entitet. Se [[identifiserbarhet-og-tilgang]].
+
+### 2. Minste privilegium — agenter får kun det de trenger
+
+Tilganger gis per agent, per oppgave, og kun til nødvendig data og funksjonalitet. Tilganger gjennomgås periodisk. Se [[identifiserbarhet-og-tilgang]].
+
+### 3. Sporbarhet — hver handling logges
+
+Hver handling utført av en agent logges med agent-ID, tidspunkt, input, output og berørt data. Logger er tilgjengelige for dataeier. Se [[logging-og-sporbarhet]].
+
+### 4. Human-in-the-loop for kritiske beslutninger
+
+Beslutninger kategoriseres i tre nivåer: autonom, varslende, godkjennende. Kategoriseringen reflekterer risiko og reversibilitet. Se [[human-in-the-loop]].
+
+### 5. Datakvalitet som premiss
+
+En agent settes ikke i produksjon mot et domene før domenet har tydelig System-of-Record, definert Dataforvalter og minimum akseptabel datakvalitet. Se [[datakvalitet-som-ai-premiss]].
+
+## Åpne spørsmål for kundedialog
+
+Disse spørsmålene bør avklares før konkret AI-arkitektur designes:
+
+- Hva er kundens akseptable risikonivå for autonome handlinger?
+- Hvilke domener er "high-stakes" hvor menneskelig godkjenning alltid kreves?
+- Hvilke ansatte/roller skal kunne sette opp og endre agenter?
+- Hvordan håndteres feil og avvik fra agenter — incident response?
+- Hvilke åpne kilder/LLM-leverandører er akseptable? Hva er GDPR-grunnlaget for treningsdata?
+- Hva er kundens posisjon på AI-baserte beslutninger overfor sluttbrukere (transparens, klagerett)?
+
+---
+
+*Klassifisering: Begrenset*

6.ai-rammeverk/datakvalitet-som-ai-premiss.md

@@ -0,0 +1,63 @@
+---
+title: "Datakvalitet som AI-premiss — Standard Online"
+date: "YYYY-MM-DD"
+tags: ["ai", "datakvalitet", "premiss"]
+refs:
+  - "ai-prinsipper.md"
+  - "../4.informasjonsarkitektur/masterdata-og-eierskap.md"
+  - "../4.informasjonsarkitektur/datakvalitet-og-avvik.md"
+qa:
+  status: "draft"
+version: 1
+---
+
+# Datakvalitet som AI-premiss
+
+## Prinsipp
+
+**AI-agenter blir bare så pålitelige som dataene under dem.** En agent settes ikke i produksjon mot et domene før domenet har:
+
+1. Tydelig **System-of-Record**
+2. Definert **Dataforvalter**
+3. Minimum akseptabel **datakvalitet** for use casen
+4. Sporbar **datakilde** for treningsdata (hvis aktuelt)
+
+## Modenhets-gate per domene
+
+Per masterdata-domene må følgende være på plass før AI-agenter slippes inn:
+
+| Krav | Lenke |
+|---|---|
+| SoR tildelt | [[../4.informasjonsarkitektur/masterdata-og-eierskap]] |
+| Dataforvalter utnevnt | [[../4.informasjonsarkitektur/masterdata-og-eierskap]] |
+| Begrepskatalog dekker entitetene | [[../4.informasjonsarkitektur/begrepskatalog]] |
+| Datakvalitet kjent (måling utført) | [[../4.informasjonsarkitektur/datakvalitet-og-avvik]] |
+| Personverntiltak på plass | [[../5.personvern-og-sikkerhet/tiltak-for-innebygd-personvern]] |
+| Tilgangsstyring etablert | [[identifiserbarhet-og-tilgang]] |
+
+## Per use case
+
+| AI-use case | Domene(r) | Modenhet | Klar for produksjon? |
+|---|---|---|---|
+
+## Garbage in, garbage out
+
+Konkrete risikoer hvis datakvalitet ikke er på plass:
+
+- **Hallusinasjon-amplifisering:** LLM-er bygger på data — dårlig data gir feilaktige svar med høy konfidens
+- **Skjevhet (bias):** Manglende eller skjev data gir diskriminerende output
+- **Reproduserbarhet:** Uten kjent kilde kan man ikke reprodusere eller fikse feil
+- **Ansvar:** Hvem svarer for feil hvis dataeier ikke er utpekt?
+
+## AI-treningsdata
+
+Hvis modeller trenes på Standard Onlines data:
+
+- **Behandlingsgrunnlag:** Hva er GDPR-grunnlaget for å bruke persondata til trening?
+- **Anonymisering:** Kan data anonymiseres før trening?
+- **Sletting:** Hvordan håndteres sletteforespørsler — må modellen retrenes?
+- **Versjonering:** Hvilken datasnapshot trente vi på?
+
+---
+
+*Klassifisering: Begrenset*

6.ai-rammeverk/human-in-the-loop.md

@@ -0,0 +1,81 @@
+---
+title: "Human-in-the-loop — AI-agenter hos Standard Online"
+date: "YYYY-MM-DD"
+tags: ["ai", "hitl", "godkjenning", "kontroll"]
+refs:
+  - "ai-prinsipper.md"
+qa:
+  status: "draft"
+version: 1
+---
+
+# Human-in-the-loop
+
+## Prinsipp
+
+Ikke alle AI-handlinger krever menneskelig godkjenning, men noen gjør det. Kategoriseringen reflekterer risiko, reversibilitet og regulatoriske krav (jf. GDPR art. 22 om automatiserte beslutninger).
+
+## Tre nivåer
+
+### Nivå 1 — Autonom
+
+Agenten handler uten å varsle menneske. Loggene er etterspørrbar, men ingen aktiv kontroll.
+
+**Brukes når:**
+- Handlingen er lett reversibel
+- Risiko ved feil er lav
+- Volumet gjør manuell kontroll umulig (f.eks. innholdsklassifisering)
+
+**Eksempler:** Kategorisering av e-post for ruting, generering av interne sammendrag, automatisk merking av produkter.
+
+### Nivå 2 — Varslende
+
+Agenten handler, men varsler menneske som kan korrigere innen rimelig tid. Handling utføres ikke automatisk hvis konfidens er under en terskel.
+
+**Brukes når:**
+- Handlingen kan reverseres, men korrigering har en kostnad
+- Risiko ved feil er moderat
+- Modell-konfidens kan brukes som filter
+
+**Eksempler:** Foreslå svar til kunde med menneskelig review før utsendelse, oppdatere kundedata med flagg for verifisering.
+
+### Nivå 3 — Godkjennende
+
+Agenten foreslår, menneske godkjenner aktivt før handling utføres.
+
+**Brukes når:**
+- Handlingen er vanskelig/umulig å reversere
+- Risiko ved feil er høy
+- Regulatoriske krav (f.eks. GDPR art. 22 for beslutninger med rettsvirkning)
+- Beslutningen har stor økonomisk konsekvens
+
+**Eksempler:** Prising over en terskel, kredittsjekk-baserte avslag, automatiserte kommunikasjon med juridisk konsekvens.
+
+## Kategorisering per use case
+
+Bygges ut for konkrete AI-initiativ hos Standard Online:
+
+| Use case | Nivå | Begrunnelse | Konfidens-terskel for Nivå 2 |
+|---|---|---|---|
+
+## GDPR art. 22
+
+Automatiserte beslutninger med rettslige eller tilsvarende virkninger krever **explicit consent** eller annet grunnlag. Slike beslutninger må:
+
+- Inneholde menneskelig vurdering på begjæring (rett til menneskelig inngripen)
+- Være forklarbare (meningsfull informasjon om logikken)
+- Kunne klages på
+
+Disse use casene er **alltid Nivå 3** og må DPIA-vurderes.
+
+## Åpne avklaringer
+
+| Spørsmål | Status |
+|---|---|
+| Hvem fastsetter HITL-nivå per use case? | |
+| Hvilke konfidens-terskler brukes? | |
+| Hvem reviewer Nivå 2-handlinger som ikke blir korrigert? | |
+
+---
+
+*Klassifisering: Begrenset*

6.ai-rammeverk/identifiserbarhet-og-tilgang.md

@@ -0,0 +1,56 @@
+---
+title: "Identifiserbarhet og tilgang — AI-agenter hos Standard Online"
+date: "YYYY-MM-DD"
+tags: ["ai", "identitet", "tilgang", "iam"]
+refs:
+  - "ai-prinsipper.md"
+  - "../5.personvern-og-sikkerhet/tiltak-for-innebygd-personvern.md"
+qa:
+  status: "draft"
+version: 1
+---
+
+# Identifiserbarhet og tilgang for AI-agenter
+
+## Prinsipp
+
+Hver AI-agent skal være identifiserbar og autoriseres som egen entitet — på samme måte som mennesker eller systemer. Generisk eller delt agent-identitet er ikke akseptabelt.
+
+## Agent som identitet
+
+| Element | Krav |
+|---|---|
+| Unik identifikator | Hver agent-instans har egen ID |
+| Autentisering | Token-basert (f.eks. EntraID, OIDC client credentials) |
+| Eier | En menneskelig eller organisatorisk eier per agent |
+| Levetidssyklus | Opprettelse, endring, dekommisjonering dokumentert |
+| Synlighet | Agenter er listet i et register tilgjengelig for systemeiere |
+
+## Tilgangsstyring
+
+### Minste privilegium
+
+Agenten gis kun tilgang til:
+- De data den faktisk trenger for sin oppgave
+- De funksjoner (skriving, lesing, ekstern integrasjon) som er nødvendige
+- Den tidsperioden tilgangen behøves
+
+### Skille les vs. skriv
+
+Lese-tilganger gis lettere. Skrive-tilganger krever eksplisitt godkjenning fra Dataforvalter for berørt domene.
+
+### Tilgangsreview
+
+Tilganger gjennomgås minst hvert kvartal, eller når en agent endres betydelig.
+
+## Åpne avklaringer
+
+| Spørsmål | Status |
+|---|---|
+| Hvilket IAM-system administrerer agent-identiteter? | |
+| Hvem godkjenner ny agent-tilgang per domene? | |
+| Hvordan håndteres roterte tokens / hemmeligheter? | |
+
+---
+
+*Klassifisering: Begrenset*

6.ai-rammeverk/logging-og-sporbarhet.md

@@ -0,0 +1,55 @@
+---
+title: "Logging og sporbarhet — AI-agenter hos Standard Online"
+date: "YYYY-MM-DD"
+tags: ["ai", "logging", "sporbarhet", "audit"]
+refs:
+  - "ai-prinsipper.md"
+qa:
+  status: "draft"
+version: 1
+---
+
+# Logging og sporbarhet for AI-agenter
+
+## Prinsipp
+
+Hver handling utført av en AI-agent skal være sporbar — hvem (hvilken agent), hva (input/output), når, og hvilke data ble berørt.
+
+## Hva skal logges
+
+| Element | Hvorfor |
+|---|---|
+| Agent-ID + agent-versjon | Identifisere kilden |
+| Tidspunkt (UTC, millisekunder) | Rekonstruere hendelsesforløp |
+| Input/prompt | Forstå hva agenten ble bedt om |
+| Output/handling | Forstå hva agenten gjorde |
+| Berørte dataentiteter | Kobling til SoR for sletteforpliktelse |
+| Konfidens / modellscore | Forstå usikkerhet i beslutning |
+| Eskaleringspunkter | Når ble HITL utløst, av hva |
+
+## Hvor logges det
+
+Sentral loggplattform tilgjengelig for:
+
+- **Systemeier** for agent-instansen
+- **Dataforvalter** for berørt domene
+- **DPO** ved personverninnsyn eller sletteforespørsler
+- **Sikkerhetsleder** ved incident-respons
+
+Logger lagres med samme krav som andre systemlogger (typisk 12-24 måneder, kortere for personopplysninger der formålet er oppfylt).
+
+## Sporbarhet på tvers av agentkjeder
+
+Hvis en agent kaller en annen agent eller et eksternt API, skal sammenhengen være sporbar via correlation-ID. End-to-end-spor må kunne rekonstrueres.
+
+## Åpne avklaringer
+
+| Spørsmål | Status |
+|---|---|
+| Eksisterer en sentral loggplattform i dag, eller skal en velges? | |
+| Hva er retensjonstid for agent-logger? Forskjellig per datatype? | |
+| Hvem har innsynsrett i logger? | |
+
+---
+
+*Klassifisering: Begrenset*