refactor(examples): replace sector-specific example material with generic, fictitious examples

Reference files, test fixtures, the playground demo project and one design document now use generic, fictitious examples (buildings, energy, water, grants, municipal services). The playground demo (17 fixtures plus the embedded demo state) tells one consistent story: a municipal customer chatbot that pre-screens housing-benefit applications, classified under Annex III point 5(a). The embedded demo copies were edited in place rather than regenerated, because they already carry newer AI Act dates than the fixture files. Legal text is unchanged. Test semantics are unchanged. Four dark-theme onboarding screenshots with outdated placeholder text are removed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-23 14:03:53 +02:00 · 2026-09-23 14:03:53 +02:00 · 544934dc57
commit 544934dc57
parent ced0c5f46d
77 changed files with 363 additions and 368 deletions
--- a/agents/ros-analysis-agent.md
+++ b/agents/ros-analysis-agent.md
@ -252,7 +252,7 @@ Bruk rapportmalene fra ros-report-templates.md:

 Scan system description for keywords:
 - Helse/pasient/journal -> Load health checklist
- Veg/trafikk/transport -> Load transport checklist
+- Trafikk/transport -> Load transport checklist
 - Bank/finans/kreditt -> Load finance checklist
 - Politi/justis -> Load justice checklist
 - Skole/utdanning -> Load education checklist
--- a/docs/eu-ai-act-integration-handover.md
+++ b/docs/eu-ai-act-integration-handover.md
@ -37,8 +37,8 @@ Systematisk metodikk for klassifisering i fire steg:
 3. Høyrisiko-sjekk via Annex III (8 kategorier) og Annex I (produktsikkerhet)
 4. Begrenset/minimal risiko (default)

-For hvert steg: beslutningspunkter, terskelverdier, DDT-eksempler.  
-Inkluder: Annex III full liste på norsk med presiseringer for transport/infrastruktur-sektoren.
+For hvert steg: beslutningspunkter, terskelverdier, eksempler fra offentlig sektor.  
+Inkluder: Annex III full liste på norsk med presiseringer for offentlig forvaltning.

 #### 1b. `ai-act-provider-obligations.md`
 Forpliktelser for **tilbydere** (organisasjoner som utvikler/tilpasser AI-systemer):
@ -51,7 +51,7 @@ Forpliktelser for **tilbydere** (organisasjoner som utvikler/tilpasser AI-system
 - Art. 15: Nøyaktighet, robusthet, cybersikkerhet
 - Art. 16–27: Kvalitetsstyring, samsvarsvurdering, CE-merking (relevant ved anskaffelse)

-DDT-kontekst: Direktoratet for digital tjenesteutvikling er typisk **deployer**, ikke provider. Men ved intern utvikling på topp av Azure AI/Copilot Studio: provider-rolle.
+Offentlig kontekst: en typisk offentlig virksomhet er **deployer**, ikke provider. Men ved intern utvikling på topp av Azure AI/Copilot Studio: provider-rolle.

 #### 1c. `ai-act-deployer-obligations.md`
 Forpliktelser for **deployere** (organisasjoner som tar i bruk AI-systemer):
@ -63,7 +63,7 @@ Forpliktelser for **deployere** (organisasjoner som tar i bruk AI-systemer):
  - Informasjon til berørte parter
  - FRIA-plikt for offentlig sektor (Art. 27)

-DDT som deployer: Copilot Studio-agenter, Azure AI Foundry-løsninger, M365 Copilot.
+Offentlig virksomhet som deployer: Copilot Studio-agenter, Azure AI Foundry-løsninger, M365 Copilot.

 #### 1d. `ai-act-fria-template.md`
 Fundamental Rights Impact Assessment – **obligatorisk for offentlig sektor** (Art. 27).
@ -98,7 +98,7 @@ Mal for transparensnotiser per Art. 13 og 52:
 - Art. 52(3): Deepfake-merking
 - Art. 50: GPAI-modeller – krav til maskinlesbar metadata

-DDT-eksempler: Chatbot på ddt.no, AI i saksbehandling.
+Eksempler: Chatbot på virksomhetens nettsted, AI i saksbehandling.

 #### 1g. `ai-act-microsoft-tools-mapping.md`
 Kartlegging av Microsoft-verktøy mot AI Act-krav:
@ -148,7 +148,7 @@ tools:
 **Hjemmel:** Annex III, kategori X – [beskrivelse]

 ## Rolle
-**DDT som:** [Provider / Deployer / Begge]
+**Virksomheten som:** [Provider / Deployer / Begge]

 ## Forpliktelser
 ### Umiddelbart (innen 2026-08-02)
@ -269,7 +269,7 @@ Legg til i review-sjekklisten:
 ```
 EU AI Act Conformity Check (kjøres automatisk hvis systemet er AI-basert):
 □ Er systemet klassifisert mot Annex III?
-□ Er DDTs rolle (provider/deployer) avklart?
+□ Er virksomhetens rolle (provider/deployer) avklart?
 □ Er teknisk dokumentasjon (Annex IV) påbegynt?
 □ Er Art. 14 menneskelig tilsyn implementert i arkitekturen?
 □ Er logging (Art. 12/26) designet inn – ikke ettermontering?
@ -394,15 +394,15 @@ I eksport-formater (steg 5) – legg til AI Act-output alternativ:
 ### STEG 8: Opprett tester

 #### 8a. `tests/fixtures/ai-act/fixture.md`
-Test-case: Fiktivt AI-system hos DDT
+Test-case: Fiktivt AI-system hos Acme Kommune

 ```markdown
-# Test-system: FartsPrediksjonsagent
-Formål: Predikere trafikkfart på E6 ved hjelp av historisk og sanntids-data
+# Test-system: Energiprognoseagent
+Formål: Predikere energiforbruk i kommunale formålsbygg ved hjelp av historisk og sanntids-data
 Teknologi: Azure Machine Learning, python-modell, REST API
-Brukere: Intern trafikkovervåking, ingen direkte borgerinteraksjon
-Data: GPS-data fra biler, kameraer, sensorer (anonymisert)
-Sektor: Transport og infrastruktur
+Brukere: Interne energirådgivere, ingen direkte borgerinteraksjon
+Data: Måledata fra energimålere og bygningssensorer (ingen persondata)
+Sektor: Energi og eiendom
 ```

 Forventet output: Klassifisert som "Begrenset/Minimal" (ikke Annex III, ikke direkte borgerimpakt)
@ -412,10 +412,10 @@ Test-case: Høyrisiko-system

 ```markdown
 # Test-system: AutomatiskSaksbehandler
-Formål: Automatisk vurdering av dispensasjonssøknader (kjøretillatelser)
+Formål: Automatisk vurdering av søknader om tilskudd
 Teknologi: Azure OpenAI GPT-4, Copilot Studio
 Brukere: Borgere sender søknad, AI gir innstilling til saksbehandler
-Data: Persondata, helseopplysninger (ved dispensasjon)
+Data: Persondata, inntektsopplysninger
 Sektor: Offentlig forvaltning
 ```

@ -478,11 +478,11 @@ Verifiser at alle eksisterende tester fortsatt passerer.

 1. **Sekvens er uforanderlig**: AI Act → DPIA → ROS. Aldri omgå dette.

-2. **DDT er typisk deployer**, ikke provider. Men ved intern utvikling (Copilot Studio-agenter bygget internt): provider-rolle. Agenten skal avklare dette eksplisitt.
+2. **En offentlig virksomhet er typisk deployer**, ikke provider. Men ved intern utvikling (Copilot Studio-agenter bygget internt): provider-rolle. Agenten skal avklare dette eksplisitt.

 3. **FRIA er obligatorisk for offentlig sektor** ved høyrisiko-systemer. Ikke valgfritt.

-4. **Fristen 2026-08-02 er 162 dager unna** (per 2026-02-22). DDT må ha klassifisert alle høyrisiko-systemer og ha GPAI-compliance på plass innen da.
+4. **Fristen 2026-08-02 er 162 dager unna** (per 2026-02-22). Virksomheten må ha klassifisert alle høyrisiko-systemer og ha GPAI-compliance på plass innen da.

 5. **Ikke overskriv eksisterende KB-filer**: `ai-act-compliance-guide.md` og `ai-act-annex-iii-checklist.md` er komplette. Referer til dem, ikke erstatt dem.

--- a/playground/ms-ai-architect-playground.html
+++ b/playground/ms-ai-architect-playground.html
@ -248,27 +248,27 @@
      "reports": {
        "classify": {
          "input": {},
-          "raw_markdown": "# EU AI Act — Klassifisering: Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nBeskrivelse: AI-system som identifiserer objekter som krever oppfølging via sensordata + objektregister\n\n## Risikonivå\n\nRisk-level: høy\n\n## Rolle\n\nRolle: Provider og Deployer (utvikler internt + drifter selv)\n\n## Begrunnelse\n\nReasoning: Systemet brukes av offentlig myndighet for håndheving av lov, og påvirker individers rettigheter direkte gjennom automatisert beslutningsstøtte for håndtering. Dette plasserer systemet under Annex III, punkt 6 (rettshåndhevelse) og krever full høyrisiko-compliance per Art. 6(2).\n\n## Forpliktelser\n\n- Risk management system per Art. 9\n- Data governance og -kvalitet per Art. 10\n- Teknisk dokumentasjon per Art. 11\n- Logging og sporbarhet per Art. 12\n- Transparens overfor deployer per Art. 13\n- Menneskelig oversikt per Art. 14\n- Robusthet, sikkerhet og nøyaktighet per Art. 15\n- FRIA (Fundamental Rights Impact Assessment) per Art. 27 — obligatorisk for offentlig sektor\n- Registrering i EU-database per Art. 49\n- Conformity assessment per Art. 43\n\n## Frist\n\nFull compliance innen 2027-12-02 (Annex III høyrisiko full compliance, utsatt fra 2026-08-02).\n"
+          "raw_markdown": "# EU AI Act — Klassifisering: Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nBeskrivelse: Innbyggerchatbot som svarer på henvendelser og forhåndsvurderer søknader om kommunal bostøtte via vedleggstolkning + oppslag i fagsystemet\n\n## Risikonivå\n\nRisk-level: høy\n\n## Rolle\n\nRolle: Provider og Deployer (utvikler internt + drifter selv)\n\n## Begrunnelse\n\nReasoning: Systemet brukes av offentlig myndighet til å vurdere om innbyggere har rett til en offentlig ytelse, og påvirker individers rettigheter direkte gjennom automatisert beslutningsstøtte for saksbehandlingen. Dette plasserer systemet under Annex III, punkt 5(a) (tilgang til offentlige ytelser og tjenester) og krever full høyrisiko-compliance per Art. 6(2).\n\n## Forpliktelser\n\n- Risk management system per Art. 9\n- Data governance og -kvalitet per Art. 10\n- Teknisk dokumentasjon per Art. 11\n- Logging og sporbarhet per Art. 12\n- Transparens overfor deployer per Art. 13\n- Menneskelig oversikt per Art. 14\n- Robusthet, sikkerhet og nøyaktighet per Art. 15\n- FRIA (Fundamental Rights Impact Assessment) per Art. 27 — obligatorisk for offentlig sektor\n- Registrering i EU-database per Art. 49\n- Conformity assessment per Art. 43\n\n## Frist\n\nFull compliance innen 2027-12-02 (Annex III høyrisiko full compliance, utsatt fra 2026-08-02).\n"
        },
        "requirements": {
          "input": {},
-          "raw_markdown": "# EU AI Act — Krav for høyrisiko provider+deployer\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nKlassifisering: høy risiko, rolle Provider+Deployer\n\n## Krav\n\n| Krav | Status | Kilde |\n|------|--------|-------|\n| Risk Management System etablert og dokumentert | partial | Art. 9 |\n| Treningsdata-governance med kvalitetssjekker | met | Art. 10 |\n| Teknisk dokumentasjon (Annex IV) komplett | partial | Art. 11 |\n| Automatisk logging av hendelser implementert | met | Art. 12 |\n| Transparens-instruksjoner for deployer skrevet | missing | Art. 13 |\n| Human-in-the-loop på alle sanksjonsavgjørelser | met | Art. 14 |\n| Nøyaktighetsmål med stratifisert testing | partial | Art. 15 |\n| Cybersikkerhetstiltak verifisert (NSM Grunnprinsipper) | met | Art. 15 |\n| FRIA gjennomført før idriftsettelse | missing | Art. 27 |\n| Registrering i EU-database planlagt | missing | Art. 49 |\n| Conformity assessment per Annex VI gjennomført | missing | Art. 43 |\n| CE-merking utført før markedsføring | missing | Art. 48 |\n| Post-market monitoring system etablert | partial | Art. 72 |\n| Avviksrapportering til myndigheter rutinert | partial | Art. 73 |\n\n## Sammendrag\n\n- 4 krav er møtt (met)\n- 4 krav er delvis møtt (partial)\n- 6 krav mangler implementering (missing)\n\nPrioritering: FRIA og transparens-instruksjoner må adresseres før idriftsettelse 2027-12-02.\n"
+          "raw_markdown": "# EU AI Act — Krav for høyrisiko provider+deployer\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nKlassifisering: høy risiko, rolle Provider+Deployer\n\n## Krav\n\n| Krav | Status | Kilde |\n|------|--------|-------|\n| Risk Management System etablert og dokumentert | partial | Art. 9 |\n| Treningsdata-governance med kvalitetssjekker | met | Art. 10 |\n| Teknisk dokumentasjon (Annex IV) komplett | partial | Art. 11 |\n| Automatisk logging av hendelser implementert | met | Art. 12 |\n| Transparens-instruksjoner for deployer skrevet | missing | Art. 13 |\n| Human-in-the-loop på alle vedtak om avslag | met | Art. 14 |\n| Nøyaktighetsmål med stratifisert testing | partial | Art. 15 |\n| Cybersikkerhetstiltak verifisert (NSM Grunnprinsipper) | met | Art. 15 |\n| FRIA gjennomført før idriftsettelse | missing | Art. 27 |\n| Registrering i EU-database planlagt | missing | Art. 49 |\n| Conformity assessment per Annex VI gjennomført | missing | Art. 43 |\n| CE-merking utført før markedsføring | missing | Art. 48 |\n| Post-market monitoring system etablert | partial | Art. 72 |\n| Avviksrapportering til myndigheter rutinert | partial | Art. 73 |\n\n## Sammendrag\n\n- 4 krav er møtt (met)\n- 4 krav er delvis møtt (partial)\n- 6 krav mangler implementering (missing)\n\nPrioritering: FRIA og transparens-instruksjoner må adresseres før idriftsettelse 2027-12-02.\n"
        },
        "transparency": {
          "input": {},
-          "raw_markdown": "# Transparensnotis — Acme Kunde-chatbot\n\nTittel: Informasjon om automatisert operasjonell analyse (Art. 13 og Art. 50)\n\n## Hva systemet gjør\n\nAcme Kommune bruker et AI-system som leser av objekt-ID (Acme Kunde-chatbot — automatisert klassifisering) fra sensordata langs produksjonsmiljøet. Systemet identifiserer objekter som har overtrådt terskelverdi gjennom å beregne gjennomsnittlig respons mellom to datapunkt.\n\n## Hvilke data som behandles\n\nBehandlede data inkluderer objekt-ID, tidsstempel, datapunkt, objektklasse og oppslag i Acme Kommune objektregister. Personlig identifiserbar informasjon kobles ikke til oppføring uten saksbehandler eksplisitte godkjenning.\n\n## Hvordan beslutninger tas\n\nSystemet er beslutningsstøtte, ikke -taker. Hver flagged hendelse går til menneskelig saksbehandler som tar endelig avgjørelse om gebyr eller anmeldelse. AI-output inkluderer konfidensgrad og forklaring av hvorfor saken ble flagget.\n\n## Dine rettigheter\n\nSom registrert har du rett til innsyn (GDPR Art. 15), retting (Art. 16), sletting (Art. 17 — med begrensninger ved lovhjemmel), og å klage til Datatilsynet. Du kan også be om manuell vurdering uten AI-bistand per GDPR Art. 22.\n\n## Kontakt\n\nPersonvernombud: pvo@Acme.no\nTilsyn: Datatilsynet — postkasse@datatilsynet.no\nEU AI Act-tilsyn: under etablering (Digitaliseringsdirektoratet er forventet)\n"
+          "raw_markdown": "# Transparensnotis — Acme Kunde-chatbot\n\nTittel: Informasjon om automatisert forhåndsvurdering av søknader (Art. 13 og Art. 50)\n\n## Hva systemet gjør\n\nAcme Kommune bruker et AI-system (Acme Kunde-chatbot) som svarer på spørsmål om kommunale tjenester og leser vedlegg du laster opp med en søknad om bostøtte. Systemet vurderer om søknaden er komplett, og om inntekt og boutgifter ser ut til å ligge innenfor vilkårene.\n\n## Hvilke data som behandles\n\nBehandlede data inkluderer det du skriver i chatten, opplastede vedlegg, saksnummer, tidsstempel og oppslag i Acme Kommunes fagsystem for bostøtte. Samtalen kobles ikke til søknaden din uten at du samtykker til det i chatten.\n\n## Hvordan beslutninger tas\n\nSystemet er beslutningsstøtte, ikke -taker. Hver flaggede søknad går til en menneskelig saksbehandler som fatter vedtaket. AI-output inkluderer konfidensgrad og forklaring av hvorfor saken ble flagget.\n\n## Dine rettigheter\n\nSom registrert har du rett til innsyn (GDPR Art. 15), retting (Art. 16), sletting (Art. 17 — med begrensninger ved lovhjemmel), og å klage til Datatilsynet. Du kan også be om manuell vurdering uten AI-bistand per GDPR Art. 22.\n\n## Kontakt\n\nPersonvernombud: pvo@Acme.no\nTilsyn: Datatilsynet — postkasse@datatilsynet.no\nEU AI Act-tilsyn: under etablering (Digitaliseringsdirektoratet er forventet)\n"
        },
        "frimpact": {
          "input": {},
-          "raw_markdown": "# FRIA (Fundamental Rights Impact Assessment) — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nHjemmel: EU AI Act Art. 27 (obligatorisk for offentlig sektor)\n\n## Vurderte rettigheter\n\n| Rettighet | Impact | Tiltak |\n|-----------|--------|--------|\n| Menneskeverd | 1 | Ingen reduksjon — saksbehandler tar endelig avgjørelse, ikke AI |\n| Rett til frihet og sikkerhet | 1 | Ingen frihetsberøvelse direkte fra AI; politi/domstol er reell beslutter |\n| Respekt for privatliv | 4 | Massiv overvåking via veikameraer — kompenseres med strenge oppbevaringsregler (90 dager), formålsbegrensning, og minimering av kobling til objektregister |\n| Personvern | 4 | DPIA gjennomført; Datatilsynet konsultert; rettslig grunnlag i interne retningslinjer §13 — likevel høy impact pga skala |\n| Ikke-diskriminering | 3 | Algoritmisk bias-testing på objekt-ID fra utenlandske registre (lavere Acme Kunde-chatbot-nøyaktighet) — kvartalsvis review |\n| Ytringsfrihet og informasjonsfrihet | 0 | Ikke berørt |\n| Forsamlingsfrihet | 0 | Ikke berørt |\n| Religionsfrihet | 0 | Ikke berørt |\n| Eiendomsrett | 2 | Gebyr/sanksjoner berører eiendomsrett — kompenseres med klagemulighet og rettslig prøving |\n| Rett til effektivt rettsmiddel | 2 | Klageadgang sikret; menneskelig review garantert; AI-forklaring tilgjengelig for klager |\n| Barns rettigheter | 1 | Lav direkte påvirkning; barn er sjelden registrerte førere |\n| Eldres rettigheter | 2 | Eldre kan ha vanskeligere for å klage digitalt — papir-klage må fortsatt være tilgjengelig |\n\n## Konklusjon\n\nTre rettigheter har høy impact (3-4): privatliv, personvern og ikke-diskriminering. Tiltakene reduserer reell risiko, men FRIA må re-evalueres årlig per Art. 27(2).\n"
+          "raw_markdown": "# FRIA (Fundamental Rights Impact Assessment) — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nHjemmel: EU AI Act Art. 27 (obligatorisk for offentlig sektor)\n\n## Vurderte rettigheter\n\n| Rettighet | Impact | Tiltak |\n|-----------|--------|--------|\n| Menneskeverd | 1 | Ingen reduksjon — saksbehandler tar endelig avgjørelse, ikke AI |\n| Rett til frihet og sikkerhet | 0 | Ikke berørt — systemet vurderer bare søknader om en økonomisk ytelse |\n| Respekt for privatliv | 4 | Samtaler og vedlegg inneholder ofte helse-, familie- og økonomiopplysninger som innbyggere oppgir fritt — kompenseres med strenge oppbevaringsregler (90 dager for samtalelogger), formålsbegrensning, og minimering av kobling til fagsystemet |\n| Personvern | 4 | DPIA gjennomført; Datatilsynet konsultert; rettslig grunnlag i interne retningslinjer §13 — likevel høy impact pga skala |\n| Ikke-diskriminering | 3 | Algoritmisk bias-testing på henvendelser og vedlegg på andre språk enn norsk (lavere tolkningsnøyaktighet) — kvartalsvis review |\n| Ytringsfrihet og informasjonsfrihet | 0 | Ikke berørt |\n| Forsamlingsfrihet | 0 | Ikke berørt |\n| Religionsfrihet | 0 | Ikke berørt |\n| Rett til sosial sikring | 2 | Feilaktig forhåndsvurdering kan forsinke en ytelse — kompenseres med at saksbehandler vurderer hver søknad, og med klagemulighet |\n| Rett til effektivt rettsmiddel | 2 | Klageadgang sikret; menneskelig review garantert; AI-forklaring tilgjengelig for klager |\n| Barns rettigheter | 1 | Lav direkte påvirkning; barn søker ikke selv, men bor i husstander som søker |\n| Eldres rettigheter | 2 | Eldre kan ha vanskeligere for å klage digitalt — papir-klage må fortsatt være tilgjengelig |\n\n## Konklusjon\n\nTre rettigheter har høy impact (3-4): privatliv, personvern og ikke-diskriminering. Tiltakene reduserer reell risiko, men FRIA må re-evalueres årlig per Art. 27(2).\n"
        },
        "conformity": {
          "input": {},
-          "raw_markdown": "# Samsvarsvurdering (Art. 43) — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsprosedyre: Annex VI (intern kontroll)\n\n## Sjekkliste\n\n| Krav | Status | Bevis |\n|------|--------|-------|\n| Risk Management System dokumentert | bestått | RMS-rapport v2.1 (2026-04-15) |\n| Treningsdata-governance med kvalitetskriterier | bestått | Data-governance handbook §4.2 |\n| Teknisk dokumentasjon Annex IV komplett | betinget | Mangler ytelsesmål per stratum |\n| Logging av hendelser implementert | bestått | OpenTelemetry-spans i Azure Monitor |\n| Transparens-instruksjoner skrevet | avvist | Skal leveres innen 2026-09-01 |\n| Menneskelig oversikt på saksbehandler | bestått | Workflow-design godkjent av juridisk |\n| Nøyaktighetsmål dokumentert | betinget | 96.3% overall, men ikke per objekt-ID-region |\n| Robusthet under adversarielle forhold | betinget | Test-suite mangler skitne plater og natt-scenarier |\n| Cybersikkerhetstiltak per Art. 15 | bestått | NSM Grunnprinsipper-vurdering bestått |\n| Conformity assessment underskrevet | avvist | Avhengig av FRIA-resultat |\n| EU declaration of conformity utstedt | avvist | Avhenger av Art. 47 |\n| CE-merking påført | avvist | Markedsplassering ikke aktuell (intern bruk) — vurder om Art. 48 gjelder |\n\n## Frister\n\n| Dato | Milepæl | Status |\n|------|---------|--------|\n| 2026-08-02 | Transparens (Art. 50) | upcoming |\n| 2026-09-01 | Transparens-instruksjoner ferdigstilt | upcoming |\n| 2027-02-01 | FRIA og DPIA-revisjon | upcoming |\n| 2027-12-02 | Full Annex III høyrisiko-compliance (utsatt fra 2026-08-02) | upcoming |\n\n## Konklusjon\n\n5 av 12 krav er fullt møtt; 4 er delvis møtt; 3 mangler implementering. Critical path: transparens-instruksjoner (Art. 13) blokkerer conformity declaration.\n"
+          "raw_markdown": "# Samsvarsvurdering (Art. 43) — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsprosedyre: Annex VI (intern kontroll)\n\n## Sjekkliste\n\n| Krav | Status | Bevis |\n|------|--------|-------|\n| Risk Management System dokumentert | bestått | RMS-rapport v2.1 (2026-04-15) |\n| Treningsdata-governance med kvalitetskriterier | bestått | Data-governance handbook §4.2 |\n| Teknisk dokumentasjon Annex IV komplett | betinget | Mangler ytelsesmål per stratum |\n| Logging av hendelser implementert | bestått | OpenTelemetry-spans i Azure Monitor |\n| Transparens-instruksjoner skrevet | avvist | Skal leveres innen 2026-09-01 |\n| Menneskelig oversikt på saksbehandler | bestått | Workflow-design godkjent av juridisk |\n| Nøyaktighetsmål dokumentert | betinget | 96.3% overall, men ikke per språkgruppe |\n| Robusthet under adversarielle forhold | betinget | Test-suite mangler skannede, skjeve og håndskrevne vedlegg |\n| Cybersikkerhetstiltak per Art. 15 | bestått | NSM Grunnprinsipper-vurdering bestått |\n| Conformity assessment underskrevet | avvist | Avhengig av FRIA-resultat |\n| EU declaration of conformity utstedt | avvist | Avhenger av Art. 47 |\n| CE-merking påført | avvist | Markedsplassering ikke aktuell (intern bruk) — vurder om Art. 48 gjelder |\n\n## Frister\n\n| Dato | Milepæl | Status |\n|------|---------|--------|\n| 2026-08-02 | Transparens (Art. 50) | upcoming |\n| 2026-09-01 | Transparens-instruksjoner ferdigstilt | upcoming |\n| 2027-02-01 | FRIA og DPIA-revisjon | upcoming |\n| 2027-12-02 | Full Annex III høyrisiko-compliance (utsatt fra 2026-08-02) | upcoming |\n\n## Konklusjon\n\n5 av 12 krav er fullt møtt; 4 er delvis møtt; 3 mangler implementering. Critical path: transparens-instruksjoner (Art. 13) blokkerer conformity declaration.\n"
        },
        "dpia": {
          "input": {},
-          "raw_markdown": "# DPIA / PVK — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nMetodikk: Datatilsynets veileder + ISO/IEC 29134\n\n## Risikomatrise (5×5)\n\n| Trussel | Sannsynlighet | Konsekvens | Score | Nivå |\n|---------|---------------|------------|-------|------|\n| Feilaktig objekt-ID-tolkning fører til urettmessig sanksjon | 3 | 4 | 12 | medium |\n| Massiv lokasjonsdata-lekkasje fra objektregister | 2 | 5 | 10 | medium |\n| AI-forklaring viser sensitiv kontekst om eier | 3 | 3 | 9 | medium |\n| Stratifisert bias mot utenlandske objekt-ID | 4 | 3 | 12 | medium |\n| Fysisk angrep på sensordata skaper deteksjonshull | 2 | 2 | 4 | low |\n| Insider-misbruk for sporing av enkeltpersoner | 2 | 5 | 10 | medium |\n| Auto-flagging utløser kjedereaksjon ved system-feil | 1 | 5 | 5 | low |\n| Subject Access Request (GDPR Art. 15) ignoreres | 3 | 3 | 9 | medium |\n\n## Trusler\n\n| ID | Beskrivelse | Severity | Tiltak |\n|----|-------------|----------|--------|\n| T-001 | Feilaktig OCR av objekt-ID | high | Konfidensgrad-cutoff på 0.95; saksbehandler-review under cutoff |\n| T-002 | Lokasjonsdata-lekkasje | critical | Pseudonymisering ved lagring; HSM-backed nøkler i Azure Key Vault |\n| T-003 | Kontekst-eksponering i AI-forklaring | high | Filter på sensitive felt; kontekst kun til autorisert saksbehandler |\n| T-004 | Bias mot utenlandske registre | high | Kvartalsvis stratifisert testing; juster modell ved >5% avvik |\n| T-005 | Insider-misbruk | critical | Audit-logging på alle oppslag; SIEM-deteksjon av unormale mønstre |\n\n## Tiltak\n\n| ID | Tiltak | Status | Eier |\n|----|--------|--------|------|\n| M-001 | Cutoff-konfidensgrad implementert | done | Tech Lead |\n| M-002 | Pseudonymisering pilotert | in-progress | Sikkerhetsarkitekt |\n| M-003 | Bias-test-pipeline etablert | planned | Data Scientist |\n| M-004 | Audit-logging utrullet | done | Drift |\n| M-005 | SIEM-regler kalibrert | in-progress | SOC |\n\n## Konklusjon\n\nRestrisiko: 4×3 → 2×2\n\nRestrisiko etter tiltak: medium-lav. DPIA godkjent av Datatilsynet 2026-04-22.\n"
+          "raw_markdown": "# DPIA / PVK — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nMetodikk: Datatilsynets veileder + ISO/IEC 29134\n\n## Risikomatrise (5×5)\n\n| Trussel | Sannsynlighet | Konsekvens | Score | Nivå |\n|---------|---------------|------------|-------|------|\n| Feilaktig vedleggstolkning fører til urettmessig avslag | 3 | 4 | 12 | medium |\n| Massiv lekkasje av økonomiopplysninger fra fagsystemet | 2 | 5 | 10 | medium |\n| AI-forklaring viser sensitiv kontekst om søker | 3 | 3 | 9 | medium |\n| Stratifisert bias mot henvendelser på andre språk | 4 | 3 | 12 | medium |\n| Manipulerte vedlegg skaper vurderingshull | 2 | 2 | 4 | low |\n| Insider-misbruk for oppslag på enkeltpersoner | 2 | 5 | 10 | medium |\n| Auto-flagging utløser kjedereaksjon ved system-feil | 1 | 5 | 5 | low |\n| Subject Access Request (GDPR Art. 15) ignoreres | 3 | 3 | 9 | medium |\n\n## Trusler\n\n| ID | Beskrivelse | Severity | Tiltak |\n|----|-------------|----------|--------|\n| T-001 | Feilaktig OCR av vedlegg | high | Konfidensgrad-cutoff på 0.95; saksbehandler-review under cutoff |\n| T-002 | Lekkasje av økonomiopplysninger | critical | Pseudonymisering ved lagring; HSM-backed nøkler i Azure Key Vault |\n| T-003 | Kontekst-eksponering i AI-forklaring | high | Filter på sensitive felt; kontekst kun til autorisert saksbehandler |\n| T-004 | Bias mot henvendelser på andre språk | high | Kvartalsvis stratifisert testing; juster modell ved >5% avvik |\n| T-005 | Insider-misbruk | critical | Audit-logging på alle oppslag; SIEM-deteksjon av unormale mønstre |\n\n## Tiltak\n\n| ID | Tiltak | Status | Eier |\n|----|--------|--------|------|\n| M-001 | Cutoff-konfidensgrad implementert | done | Tech Lead |\n| M-002 | Pseudonymisering pilotert | in-progress | Sikkerhetsarkitekt |\n| M-003 | Bias-test-pipeline etablert | planned | Data Scientist |\n| M-004 | Audit-logging utrullet | done | Drift |\n| M-005 | SIEM-regler kalibrert | in-progress | SOC |\n\n## Konklusjon\n\nRestrisiko: 4×3 → 2×2\n\nRestrisiko etter tiltak: medium-lav. DPIA godkjent av Datatilsynet 2026-04-22.\n"
        },
        "security": {
          "input": {},
@ -276,23 +276,23 @@
        },
        "ros": {
          "input": {},
-          "raw_markdown": "# ROS-analyse — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nMetodikk: NS 5814 / ISO 31000 + AI-trusselbibliotek\n\n## Risikomatrise (5×5)\n\n| Trussel | Sannsynlighet | Konsekvens | Score | Nivå |\n|---------|---------------|------------|-------|------|\n| Modell-drift som degraderer nøyaktighet | 4 | 3 | 12 | medium |\n| Treningsdata-bias mot småbiler eller MC | 3 | 3 | 9 | medium |\n| Adversarielle plate-design unngår OCR | 2 | 4 | 8 | medium |\n| API-utilgjengelighet i kritisk periode | 2 | 4 | 8 | medium |\n| Klage-saksbehandling overbelastet ved skalering | 4 | 3 | 12 | medium |\n| Datatap pga manglende georedundans | 1 | 5 | 5 | low |\n| Misbruk av AI-forklaring som bevis | 3 | 4 | 12 | medium |\n| Kjedevirkning ved feil i objektregister | 2 | 5 | 10 | medium |\n\n## Radar-akser (7 dimensjoner)\n\n| Akse | Score (1-5) |\n|------|-------------|\n| Tilgjengelighet | 4 |\n| Konfidensialitet | 4 |\n| Integritet | 4 |\n| Sporbarhet | 5 |\n| Pålitelighet | 3 |\n| Robusthet | 3 |\n| Etterlevelse | 4 |\n\n## Trusler\n\n| ID | Beskrivelse | Severity | Tiltak |\n|----|-------------|----------|--------|\n| T-101 | Modell-drift over tid | high | Månedlig retraining-pipeline; alarm ved >2% nøyaktighetsfall |\n| T-102 | Bias mot småbiler/MC | high | Stratifisert evaluering ved hver release |\n| T-103 | Adversarielle plate-design | medium | Robusthetstest mot kjente angreps-mønstre |\n| T-104 | API-utilgjengelighet | medium | Multi-region failover med RTO 1t |\n| T-105 | Saksbehandlings-overbelastning | high | Automatisk batching + prioriteringsregler |\n\n## Tiltak\n\n| ID | Tiltak | Status | Eier |\n|----|--------|--------|------|\n| M-101 | Retraining-pipeline etablert | done | MLOps |\n| M-102 | Stratifisert evalueringssett bygget | in-progress | Data Scientist |\n| M-103 | Robusthetstest planlagt | planned | Sikkerhetsarkitekt |\n| M-104 | Multi-region failover testet | done | Drift |\n| M-105 | Batching-logikk implementert | in-progress | Tech Lead |\n\n## Top-risikoer\n\n| ID | Trussel | Score | Severity |\n|----|---------|-------|----------|\n| T-101 | Modell-drift over tid | 12 | high |\n| T-105 | Saksbehandlings-overbelastning | 12 | high |\n| T-107 | Misbruk av AI-forklaring som bevis | 12 | high |\n| T-108 | Kjedevirkning ved feil i objektregister | 10 | high |\n| T-103 | Bias mot småbiler/MC | 9 | medium |\n\nRestrisiko: 4×3 → 2×2\n\n## Anbefaling\n\nROS godkjent av seksjonsleder 2026-04-25 forutsatt at M-103 (robusthetstest) ferdigstilles innen 2026-06-15. Re-evaluering ved hver modell-release eller ved endring i sak-volum > 20%.\n\n## Konklusjon\n\nRestrisiko etter tiltak: medium. ROS godkjent av seksjonsleder 2026-04-25.\n"
+          "raw_markdown": "# ROS-analyse — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nMetodikk: NS 5814 / ISO 31000 + AI-trusselbibliotek\n\n## Risikomatrise (5×5)\n\n| Trussel | Sannsynlighet | Konsekvens | Score | Nivå |\n|---------|---------------|------------|-------|------|\n| Modell-drift som degraderer nøyaktighet | 4 | 3 | 12 | medium |\n| Treningsdata-bias mot nynorsk og andre språk | 3 | 3 | 9 | medium |\n| Manipulerte vedlegg unngår OCR-kontroll | 2 | 4 | 8 | medium |\n| API-utilgjengelighet i kritisk periode | 2 | 4 | 8 | medium |\n| Klage-saksbehandling overbelastet ved skalering | 4 | 3 | 12 | medium |\n| Datatap pga manglende georedundans | 1 | 5 | 5 | low |\n| Misbruk av AI-forklaring som vedtaksbegrunnelse | 3 | 4 | 12 | medium |\n| Kjedevirkning ved feil i fagsystemet | 2 | 5 | 10 | medium |\n\n## Radar-akser (7 dimensjoner)\n\n| Akse | Score (1-5) |\n|------|-------------|\n| Tilgjengelighet | 4 |\n| Konfidensialitet | 4 |\n| Integritet | 4 |\n| Sporbarhet | 5 |\n| Pålitelighet | 3 |\n| Robusthet | 3 |\n| Etterlevelse | 4 |\n\n## Trusler\n\n| ID | Beskrivelse | Severity | Tiltak |\n|----|-------------|----------|--------|\n| T-101 | Modell-drift over tid | high | Månedlig retraining-pipeline; alarm ved >2% nøyaktighetsfall |\n| T-102 | Bias mot nynorsk og andre språk | high | Stratifisert evaluering ved hver release |\n| T-103 | Manipulerte vedlegg | medium | Robusthetstest mot kjente angreps-mønstre |\n| T-104 | API-utilgjengelighet | medium | Multi-region failover med RTO 1t |\n| T-105 | Saksbehandlings-overbelastning | high | Automatisk batching + prioriteringsregler |\n\n## Tiltak\n\n| ID | Tiltak | Status | Eier |\n|----|--------|--------|------|\n| M-101 | Retraining-pipeline etablert | done | MLOps |\n| M-102 | Stratifisert evalueringssett bygget | in-progress | Data Scientist |\n| M-103 | Robusthetstest planlagt | planned | Sikkerhetsarkitekt |\n| M-104 | Multi-region failover testet | done | Drift |\n| M-105 | Batching-logikk implementert | in-progress | Tech Lead |\n\n## Top-risikoer\n\n| ID | Trussel | Score | Severity |\n|----|---------|-------|----------|\n| T-101 | Modell-drift over tid | 12 | high |\n| T-105 | Saksbehandlings-overbelastning | 12 | high |\n| T-107 | Misbruk av AI-forklaring som vedtaksbegrunnelse | 12 | high |\n| T-108 | Kjedevirkning ved feil i fagsystemet | 10 | high |\n| T-103 | Bias mot nynorsk og andre språk | 9 | medium |\n\nRestrisiko: 4×3 → 2×2\n\n## Anbefaling\n\nROS godkjent av seksjonsleder 2026-04-25 forutsatt at M-103 (robusthetstest) ferdigstilles innen 2026-06-15. Re-evaluering ved hver modell-release eller ved endring i sak-volum > 20%.\n\n## Konklusjon\n\nRestrisiko etter tiltak: medium. ROS godkjent av seksjonsleder 2026-04-25.\n"
        },
        "review": {
          "input": {},
-          "raw_markdown": "# Arkitekturgjennomgang — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsdato: 2026-04-30\nReviewers: AI-arkitekt, sikkerhetsarkitekt, Datatilsynet\n\n## Funn\n\n| ID | Severity | Status | Lokasjon | Anbefaling |\n|----|----------|--------|----------|------------|\n| F-01 | critical | remove | Authentication layer | Tilgang til AI-forklaringer mangler attribute-based access control — alle saksbehandler ser alle saker. Implementer ABAC basert på sak-tildeling. |\n| F-02 | high | review | Data pipeline | Treningsdata oppdateres månedlig, men ingen formell drift-deteksjon. Etabler statistisk drift-monitoring i Azure Monitor. |\n| F-03 | high | review | Model serving | Modellen serves fra en enkelt regional endpoint uten failover. Replikér til en sekundær region for RTO < 1t. |\n| F-04 | high | review | Logging | Audit-logg lagres 30 dager — under arkivlovens krav for sak-relevant info. Endre retensjon til 7 år for sak-knyttede oppslag. |\n| F-05 | medium | keep | Cost management | Ingen budsjettalarmer på Azure AI Services — prediction-kostnaden kan øke med 4× ved belastnings-topper uten varsel. |\n| F-06 | medium | review | Compliance | FRIA-rapport ikke vedlikeholdt etter modell-endring 2026-03-12. Re-evaluering trengs. |\n| F-07 | medium | keep | UX | saksbehandler-grensesnitt viser ikke konfidensgrad tydelig nok — risiko for over-trust på AI-output. |\n| F-08 | low | suppressed | Documentation | README mangler oppdatert arkitekturdiagram (siste fra 2025-11). |\n| F-09 | low | suppressed | Testing | Manglende E2E-test for utenlandske objekt-ID. |\n\n## Sammendrag\n\nCritical (1): ABAC mangler — må fikses før idriftsettelse.\nHigh (3): Drift-deteksjon, failover, logg-retensjon — må fikses innen 6 mnd.\nMedium (3): Budsjett, FRIA-revisjon, UX-konfidens — bør fikses innen 12 mnd.\nLow (2): Dokumentasjon, testing — opportunity-quality.\n\n## Anbefaling\n\nIdriftsettelse anbefales IKKE før F-01 er løst. F-02 til F-04 må adresseres innen 2026-09-01 for å holde 2027-12-02-fristen.\n"
+          "raw_markdown": "# Arkitekturgjennomgang — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsdato: 2026-04-30\nReviewers: AI-arkitekt, sikkerhetsarkitekt, Datatilsynet\n\n## Funn\n\n| ID | Severity | Status | Lokasjon | Anbefaling |\n|----|----------|--------|----------|------------|\n| F-01 | critical | remove | Authentication layer | Tilgang til AI-forklaringer mangler attribute-based access control — alle saksbehandler ser alle saker. Implementer ABAC basert på sak-tildeling. |\n| F-02 | high | review | Data pipeline | Treningsdata oppdateres månedlig, men ingen formell drift-deteksjon. Etabler statistisk drift-monitoring i Azure Monitor. |\n| F-03 | high | review | Model serving | Modellen serves fra en enkelt regional endpoint uten failover. Replikér til en sekundær region for RTO < 1t. |\n| F-04 | high | review | Logging | Audit-logg lagres 30 dager — under arkivlovens krav for sak-relevant info. Endre retensjon til 7 år for sak-knyttede oppslag. |\n| F-05 | medium | keep | Cost management | Ingen budsjettalarmer på Azure AI Services — prediction-kostnaden kan øke med 4× ved belastnings-topper uten varsel. |\n| F-06 | medium | review | Compliance | FRIA-rapport ikke vedlikeholdt etter modell-endring 2026-03-12. Re-evaluering trengs. |\n| F-07 | medium | keep | UX | saksbehandler-grensesnitt viser ikke konfidensgrad tydelig nok — risiko for over-trust på AI-output. |\n| F-08 | low | suppressed | Documentation | README mangler oppdatert arkitekturdiagram (siste fra 2025-11). |\n| F-09 | low | suppressed | Testing | Manglende E2E-test for henvendelser på andre språk. |\n\n## Sammendrag\n\nCritical (1): ABAC mangler — må fikses før idriftsettelse.\nHigh (3): Drift-deteksjon, failover, logg-retensjon — må fikses innen 6 mnd.\nMedium (3): Budsjett, FRIA-revisjon, UX-konfidens — bør fikses innen 12 mnd.\nLow (2): Dokumentasjon, testing — opportunity-quality.\n\n## Anbefaling\n\nIdriftsettelse anbefales IKKE før F-01 er løst. F-02 til F-04 må adresseres innen 2026-09-01 for å holde 2027-12-02-fristen.\n"
        },
        "cost": {
          "input": {},
-          "raw_markdown": "# Kostnadsestimat — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nPeriode: 12 måneder fra produksjonssetting\nValuta: NOK\n\n## Distribusjon (P10/P50/P90)\n\n| Persentil | Månedlig (NOK) | Årlig (NOK) |\n|-----------|----------------|-------------|\n| P10 | 78 000 | 936 000 |\n| P50 | 142 000 | 1 704 000 |\n| P90 | 285 000 | 3 420 000 |\n\n## Månedlig fordeling (P50)\n\n| Komponent | Kostnad (NOK/mnd) |\n|-----------|-------------------|\n| Azure AI Services (OCR + classification) | 64 000 |\n| Azure OpenAI (forklaringsmodell) | 28 000 |\n| Azure AI Search (indeks for objektregister) | 12 000 |\n| Storage (blob + cosmos for audit) | 8 500 |\n| Compute (Container Apps for orchestration) | 11 000 |\n| Networking (Private Endpoints + egress) | 5 200 |\n| Monitoring (Sentinel + Log Analytics) | 9 800 |\n| Backup og DR | 3 500 |\n\n## TCO-tabell (3 år)\n\n| År | Capex | Opex | Total | Akkumulert |\n|----|-------|------|-------|------------|\n| År 1 | 850 000 | 1 704 000 | 2 554 000 | 2 554 000 |\n| År 2 | 120 000 | 1 875 000 | 1 995 000 | 4 549 000 |\n| År 3 | 80 000 | 2 060 000 | 2 140 000 | 6 689 000 |\n\n## Kostnadsdrivere\n\n- Datavolum: ~12 millioner Acme Kunde-chatbot-deteksjoner/mnd\n- Forklaring-prompt-tokens: ~250 tokens per flagged hendelse\n- Reservert kapasitet for 99.9% SLA\n\n## Konfidensgradering\n\nP50 er beregnet med 95% konfidens basert på 6 måneder pilot-data. P90 inkluderer 2× volum-skalering ved fullnasjonal utrulling. P10 forutsetter optimaliserte prompt-cache (>40% hit-rate).\n\n## Anbefaling\n\nBruk P50 som budsjettlinje. Sett alarm på 1.4× P50 (≈ 200 000/mnd) for tidlig varsling.\n"
+          "raw_markdown": "# Kostnadsestimat — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nPeriode: 12 måneder fra produksjonssetting\nValuta: NOK\n\n## Distribusjon (P10/P50/P90)\n\n| Persentil | Månedlig (NOK) | Årlig (NOK) |\n|-----------|----------------|-------------|\n| P10 | 78 000 | 936 000 |\n| P50 | 142 000 | 1 704 000 |\n| P90 | 285 000 | 3 420 000 |\n\n## Månedlig fordeling (P50)\n\n| Komponent | Kostnad (NOK/mnd) |\n|-----------|-------------------|\n| Azure AI Services (OCR + classification) | 64 000 |\n| Azure OpenAI (forklaringsmodell) | 28 000 |\n| Azure AI Search (indeks for regelverk og tjenesteinformasjon) | 12 000 |\n| Storage (blob + cosmos for audit) | 8 500 |\n| Compute (Container Apps for orchestration) | 11 000 |\n| Networking (Private Endpoints + egress) | 5 200 |\n| Monitoring (Sentinel + Log Analytics) | 9 800 |\n| Backup og DR | 3 500 |\n\n## TCO-tabell (3 år)\n\n| År | Capex | Opex | Total | Akkumulert |\n|----|-------|------|-------|------------|\n| År 1 | 850 000 | 1 704 000 | 2 554 000 | 2 554 000 |\n| År 2 | 120 000 | 1 875 000 | 1 995 000 | 4 549 000 |\n| År 3 | 80 000 | 2 060 000 | 2 140 000 | 6 689 000 |\n\n## Kostnadsdrivere\n\n- Datavolum: ~1,2 millioner chatbot-meldinger og vedlegg/mnd\n- Forklaring-prompt-tokens: ~250 tokens per flaggede søknad\n- Reservert kapasitet for 99.9% SLA\n\n## Konfidensgradering\n\nP50 er beregnet med 95% konfidens basert på 6 måneder pilot-data. P90 inkluderer 2× volum-skalering ved utvidelse til flere tjenesteområder. P10 forutsetter optimaliserte prompt-cache (>40% hit-rate).\n\n## Anbefaling\n\nBruk P50 som budsjettlinje. Sett alarm på 1.4× P50 (≈ 200 000/mnd) for tidlig varsling.\n"
        },
        "license": {
          "input": {},
-          "raw_markdown": "# Lisens-kapabilitetsmatrise — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsdato: 2026-04-30\n\n## Matrise\n\n| Kapabilitet | M365 E3 | M365 E5 | Copilot for M365 | Copilot Studio | Azure AI Foundry |\n|-------------|---------|---------|------------------|----------------|------------------|\n| OCR av objekt-ID | missing | missing | missing | conditional | available |\n| Custom modell-trening | missing | missing | missing | missing | available |\n| Audit-logging på AI-input | missing | available | available | available | available |\n| Customer-managed keys | missing | available | conditional | conditional | available |\n| Private Endpoints | missing | available | missing | conditional | available |\n| saksbehandler-co-pilot UI | missing | missing | available | available | conditional |\n| Norsk språkstøtte i prompts | available | available | available | available | available |\n| Compliance-pakke for leverandøren | missing | available | conditional | conditional | available |\n| Real-time inference (<100ms) | missing | missing | missing | missing | available |\n| Batch-inference for nattlige jobber | missing | missing | missing | missing | available |\n\n## Status-betydning\n\n- available: Inkludert i lisensen, klar til bruk\n- cost: Tilgjengelig som tillegg, krever separat fakturering\n- conditional: Kan brukes med begrensninger eller add-on\n- missing: Ikke tilgjengelig på dette lisensnivået\n\n## Sammendrag\n\nAzure AI Foundry er eneste lisens som dekker alle kjernekapabiliteter. Copilot Studio passer for saksbehandler-UI men kan ikke håndtere OCR/custom modeller alene. Hybrid: Foundry (kjerne) + Copilot Studio (UI) gir best dekning.\n\n## Anbefaling\n\nBruk Azure AI Foundry for AI-tjenester (OCR, klassifisering, forklaring). Hold M365 E5 på saksbehandler-arbeidsstasjoner for audit-logging og compliance-pakke. Vurder Copilot Studio i fase 2 for saksbehandler-co-pilot.\n"
+          "raw_markdown": "# Lisens-kapabilitetsmatrise — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsdato: 2026-04-30\n\n## Matrise\n\n| Kapabilitet | M365 E3 | M365 E5 | Copilot for M365 | Copilot Studio | Azure AI Foundry |\n|-------------|---------|---------|------------------|----------------|------------------|\n| OCR av vedlegg | missing | missing | missing | conditional | available |\n| Custom modell-trening | missing | missing | missing | missing | available |\n| Audit-logging på AI-input | missing | available | available | available | available |\n| Customer-managed keys | missing | available | conditional | conditional | available |\n| Private Endpoints | missing | available | missing | conditional | available |\n| saksbehandler-co-pilot UI | missing | missing | available | available | conditional |\n| Norsk språkstøtte i prompts | available | available | available | available | available |\n| Compliance-pakke for leverandøren | missing | available | conditional | conditional | available |\n| Real-time inference (<100ms) | missing | missing | missing | missing | available |\n| Batch-inference for nattlige jobber | missing | missing | missing | missing | available |\n\n## Status-betydning\n\n- available: Inkludert i lisensen, klar til bruk\n- cost: Tilgjengelig som tillegg, krever separat fakturering\n- conditional: Kan brukes med begrensninger eller add-on\n- missing: Ikke tilgjengelig på dette lisensnivået\n\n## Sammendrag\n\nAzure AI Foundry er eneste lisens som dekker alle kjernekapabiliteter. Copilot Studio passer for saksbehandler-UI men kan ikke håndtere OCR/custom modeller alene. Hybrid: Foundry (kjerne) + Copilot Studio (UI) gir best dekning.\n\n## Anbefaling\n\nBruk Azure AI Foundry for AI-tjenester (OCR, klassifisering, forklaring). Hold M365 E5 på saksbehandler-arbeidsstasjoner for audit-logging og compliance-pakke. Vurder Copilot Studio i fase 2 for saksbehandler-co-pilot.\n"
        },
        "migrate": {
          "input": {},
-          "raw_markdown": "# Migrasjonsplan — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nFra: On-prem OCR + manuell klassifisering\nTil: Azure AI Foundry + saksbehandler-co-pilot\n\n## Faser\n\n### Fase 1 — Foundry-fundament (uker 1-6)\n\nVarighet: 6 uker\nStatus: done\n\nMilepæler:\n- Hub + projects opprettet i West Europe\n- Network isolation: Private Endpoints + Vnet integration\n- Identity: Entra ID-integrasjon med PIM\n- Logging: OpenTelemetry → Sentinel pipeline\n\nSuksesskriterier:\n- Pilot OCR-modell deployert med <100ms latency P95\n- Audit-logg fanger 100% av inferences\n- Sikkerhetsarkitekt godkjenner foundation-design\n\n### Fase 2 — Modell-trening og baseline (uker 7-14)\n\nVarighet: 8 uker\nStatus: done\n\nMilepæler:\n- Treningsdata kuratert (200k norske objekt-ID, stratifisert)\n- Custom modell trent på Azure ML\n- Baseline-nøyaktighet etablert (mål: ≥96% F1)\n- Bias-evaluering på utenlandske registre fullført\n\nSuksesskriterier:\n- F1 ≥ 96% overall, ≥ 92% per objekter-segment\n- Drift-deteksjon kalibrert med terskel\n- ROS-revisjon godkjent\n\n### Fase 3 — saksbehandler-co-pilot (uker 15-22)\n\nVarighet: 8 uker\nStatus: active\n\nMilepæler:\n- Forklaringsmodell (GPT-4 Turbo) integrert via Foundry\n- saksbehandler-UI bygget (Copilot Studio + Power Platform)\n- Workflow: AI flagger → saksbehandler reviewer → klar for sanksjon\n- Brukertest med 12 saksbehandler fra ulike regioner\n\nSuksesskriterier:\n- Saksbehandlingstid -40% vs baseline\n- saksbehandler-tillit >7/10 i post-pilot survey\n- Ingen kritiske UX-feil\n\n### Fase 4 — Compliance og produksjonssetting (uker 23-28)\n\nVarighet: 6 uker\nStatus: planned\n\nMilepæler:\n- FRIA gjennomført og godkjent\n- Conformity assessment ferdigstilt per Annex VI\n- DPIA oppdatert med nye operasjonelle data\n- Produksjonssetting til 3 piloter (Oslo, Bergen, Trondheim)\n\nSuksesskriterier:\n- Personvernombud signerer DPIA\n- Ingen open critical-funn fra arkitekturgjennomgang\n- Stabil 99.9% uptime i 30 dager pilot\n\n## Risiko\n\n| Risiko | Sannsynlighet | Konsekvens | Tiltak |\n|--------|---------------|------------|--------|\n| Custom modell underyter mot 96% mål | medium | high | Backup-strategi: bruk Azure AI Vision OCR som fallback |\n| saksbehandler-motstand mot AI | medium | medium | Tidlig involvering; transparent forklaring; opt-out på enkelt-saker |\n| FRIA blokkerer fase 4 | low | high | Pre-FRIA-kjøring i fase 2 for tidlig varsling |\n| Cost-overrun ved skalering | medium | medium | Reserved capacity-binding etter fase 3 |\n\n## Total varighet\n\n28 uker (~7 måneder). Avhengighet: Foundry-fundament må være ferdig før modell-trening starter.\n"
+          "raw_markdown": "# Migrasjonsplan — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nFra: On-prem OCR + manuell klassifisering\nTil: Azure AI Foundry + saksbehandler-co-pilot\n\n## Faser\n\n### Fase 1 — Foundry-fundament (uker 1-6)\n\nVarighet: 6 uker\nStatus: done\n\nMilepæler:\n- Hub + projects opprettet i West Europe\n- Network isolation: Private Endpoints + Vnet integration\n- Identity: Entra ID-integrasjon med PIM\n- Logging: OpenTelemetry → Sentinel pipeline\n\nSuksesskriterier:\n- Pilot OCR-modell deployert med <100ms latency P95\n- Audit-logg fanger 100% av inferences\n- Sikkerhetsarkitekt godkjenner foundation-design\n\n### Fase 2 — Modell-trening og baseline (uker 7-14)\n\nVarighet: 8 uker\nStatus: done\n\nMilepæler:\n- Treningsdata kuratert (200k anonymiserte vedlegg, stratifisert på dokumenttype og språk)\n- Custom modell trent på Azure ML\n- Baseline-nøyaktighet etablert (mål: ≥96% F1)\n- Bias-evaluering på henvendelser og vedlegg på andre språk fullført\n\nSuksesskriterier:\n- F1 ≥ 96% overall, ≥ 92% per dokumenttype\n- Drift-deteksjon kalibrert med terskel\n- ROS-revisjon godkjent\n\n### Fase 3 — saksbehandler-co-pilot (uker 15-22)\n\nVarighet: 8 uker\nStatus: active\n\nMilepæler:\n- Forklaringsmodell (GPT-4 Turbo) integrert via Foundry\n- saksbehandler-UI bygget (Copilot Studio + Power Platform)\n- Workflow: AI flagger → saksbehandler reviewer → klar for vedtak\n- Brukertest med 12 saksbehandlere fra ulike tjenesteområder\n\nSuksesskriterier:\n- Saksbehandlingstid -40% vs baseline\n- saksbehandler-tillit >7/10 i post-pilot survey\n- Ingen kritiske UX-feil\n\n### Fase 4 — Compliance og produksjonssetting (uker 23-28)\n\nVarighet: 6 uker\nStatus: planned\n\nMilepæler:\n- FRIA gjennomført og godkjent\n- Conformity assessment ferdigstilt per Annex VI\n- DPIA oppdatert med nye operasjonelle data\n- Produksjonssetting i 3 pilotbydeler\n\nSuksesskriterier:\n- Personvernombud signerer DPIA\n- Ingen open critical-funn fra arkitekturgjennomgang\n- Stabil 99.9% uptime i 30 dager pilot\n\n## Risiko\n\n| Risiko | Sannsynlighet | Konsekvens | Tiltak |\n|--------|---------------|------------|--------|\n| Custom modell underyter mot 96% mål | medium | high | Backup-strategi: bruk Azure AI Vision OCR som fallback |\n| saksbehandler-motstand mot AI | medium | medium | Tidlig involvering; transparent forklaring; opt-out på enkelt-saker |\n| FRIA blokkerer fase 4 | low | high | Pre-FRIA-kjøring i fase 2 for tidlig varsling |\n| Cost-overrun ved skalering | medium | medium | Reserved capacity-binding etter fase 3 |\n\n## Total varighet\n\n28 uker (~7 måneder). Avhengighet: Foundry-fundament må være ferdig før modell-trening starter.\n"
        },
        "adr": {
          "input": {},
@ -300,15 +300,15 @@
        },
        "summary": {
          "input": {},
-          "raw_markdown": "# Beslutningsnotat — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nDato: 2026-04-30\nTil: Direktør for Digital og IT\nFra: AI-teamet\n\n## Verdict\n\nVerdict: warning\nSub: Pilot anbefalt med betingelser\n\n## Rationale\n\nArkitekturen er teknisk solid og økonomisk forsvarlig (P50 NOK 1.7M/år), men compliance-arbeidet ligger 6 måneder bak ideell tidslinje. Pilot kan starte etter at FRIA og transparens-instruksjoner er ferdigstilt; full produksjonssetting krever lukking av alle critical funn fra arkitekturgjennomgang.\n\n## Key Metrics\n\n| Metric | Verdi | Mål |\n|--------|-------|-----|\n| Compliance-dekning | 33% (4/12 fullt møtt) | 100% innen 2027-12-02 |\n| Sikkerhetsscore | 22/30 (73%) | ≥27/30 (90%) |\n| TCO 3 år | NOK 6.7M | ≤ NOK 7M |\n| Saksbehandlingstid (pilot) | -32% (estimert) | -40% |\n| ROS-restrisiko | medium | low-medium |\n\n## Next Steps\n\n- Lukk F-01 (ABAC) innen 2026-06-15\n- Gjennomfør FRIA innen 2026-07-15 (Art. 27-frist)\n- Produksjonsdokumentere transparens-instruksjoner innen 2026-09-01\n- Pilot 3 regioner (Oslo, Bergen, Trondheim) Q4 2026\n- Full utrulling Q2 2027\n\n## Restrisiko\n\nEtter foreslåtte tiltak: medium. Hovedeksponering: bias mot utenlandske objekt-ID krever løpende monitoring.\n\n## Anbefaling\n\nGodkjenn pilot-fase med tydelig stage-gate til full produksjonssetting. Avstem med Datatilsynet før fase 4.\n"
+          "raw_markdown": "# Beslutningsnotat — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nDato: 2026-04-30\nTil: Direktør for Digital og IT\nFra: AI-teamet\n\n## Verdict\n\nVerdict: warning\nSub: Pilot anbefalt med betingelser\n\n## Rationale\n\nArkitekturen er teknisk solid og økonomisk forsvarlig (P50 NOK 1.7M/år), men compliance-arbeidet ligger 6 måneder bak ideell tidslinje. Pilot kan starte etter at FRIA og transparens-instruksjoner er ferdigstilt; full produksjonssetting krever lukking av alle critical funn fra arkitekturgjennomgang.\n\n## Key Metrics\n\n| Metric | Verdi | Mål |\n|--------|-------|-----|\n| Compliance-dekning | 33% (4/12 fullt møtt) | 100% innen 2027-12-02 |\n| Sikkerhetsscore | 22/30 (73%) | ≥27/30 (90%) |\n| TCO 3 år | NOK 6.7M | ≤ NOK 7M |\n| Saksbehandlingstid (pilot) | -32% (estimert) | -40% |\n| ROS-restrisiko | medium | low-medium |\n\n## Next Steps\n\n- Lukk F-01 (ABAC) innen 2026-06-15\n- Gjennomfør FRIA innen 2026-07-15 (Art. 27-frist)\n- Produksjonsdokumentere transparens-instruksjoner innen 2026-09-01\n- Pilot i 3 bydeler Q4 2026\n- Full utrulling Q2 2027\n\n## Restrisiko\n\nEtter foreslåtte tiltak: medium. Hovedeksponering: bias mot henvendelser på andre språk enn norsk krever løpende monitoring.\n\n## Anbefaling\n\nGodkjenn pilot-fase med tydelig stage-gate til full produksjonssetting. Avstem med Datatilsynet før fase 4.\n"
        },
        "poc": {
          "input": {},
-          "raw_markdown": "# POC-plan — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nPOC-mål: Validere at Azure AI Foundry kan dekke OCR + forklaring + audit innen tids- og kostbudsjett\n\n## Faser\n\n### Fase 1 — Foundation (uker 1-2)\n\nVarighet: 2 uker\nStatus: done\n\nMilepæler:\n- Foundry hub + project i West Europe\n- Identity og networking konfigurert\n- Sample-data uploadet (10k anonymiserte objekt-ID)\n\nSuksesskriterier:\n- Inferens-endpoint nåbart fra dev-Vnet via Private Endpoint\n- Audit-logg fanger første test-inferens\n- Cost-monitor viser daglig forbruk i Azure portal\n\n### Fase 2 — OCR-modell (uker 3-5)\n\nVarighet: 3 uker\nStatus: active\n\nMilepæler:\n- Pre-trent Azure AI Vision OCR pilotert\n- Custom fine-tune på 10k objekt-ID\n- Sammenligning av accuracy/latency mellom de to\n\nSuksesskriterier:\n- F1 ≥ 92% på pilot-sett (lavere mål enn produksjon, akseptabelt for POC)\n- Latency P95 < 200ms\n- Inference-cost ≤ NOK 0.04 per kall\n\n### Fase 3 — Forklarings-loop (uker 6-7)\n\nVarighet: 2 uker\nStatus: planned\n\nMilepæler:\n- GPT-4 Turbo via Foundry integrert\n- Prompt-template for forklaring av flagged sak\n- saksbehandler-mock UI (en enkel webside) prøvd ut med 3 brukere\n\nSuksesskriterier:\n- Forklaring referer til konfidens og kontekst korrekt i 95% av tilfellene\n- saksbehandler-feedback kvalitativt positiv (\"forståelig, men trenger justering\")\n- Prompt-tokens under 250 i snitt per sak\n\n### Fase 4 — Compliance-pre-check (uke 8)\n\nVarighet: 1 uke\nStatus: planned\n\nMilepæler:\n- Audit-logg mot EU AI Act Art. 12-krav\n- Customer-managed keys verifisert\n- Pre-DPIA-sjekk gjort med Datatilsynet\n\nSuksesskriterier:\n- Audit-logg dekker 100% av inferences med tidsstempel + bruker\n- Personvernombud signer pre-DPIA-utkast\n- Ingen åpenbare GDPR-blokkere\n\n## Risiko\n\n| Risiko | Sannsynlighet | Konsekvens | Tiltak |\n|--------|---------------|------------|--------|\n| Custom OCR-modell underyter pre-trent | medium | medium | Aksepter pre-trent for POC; planlegg custom for full prod |\n| Foundry-quota i West Europe utilstrekkelig | low | medium | Reserver kapasitet før POC starter |\n| saksbehandler-recruitment forsinker fase 3 | medium | low | Bruk interne ressurser i AI-teamet som mock |\n| Audit-logg-format ikke kompatibelt med Sentinel | low | medium | Test integrasjon i fase 1 |\n\n## POC-Verdict: BETINGET\n\nPilot-fase 1 fullført med F1=0.94 og inference-cost 0.038 NOK/kall (under budsjett). Fase 2 pågår — sammenligning av custom fine-tune mot pre-trent OCR i progress. Forklarings-loop og compliance-pre-check planlagt for siste halvdel.\n\n## Total varighet\n\n8 uker. Beslutningskriterium for full prosjektgodkjenning: alle 4 fasers suksesskriterier møtt.\n"
+          "raw_markdown": "# POC-plan — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nPOC-mål: Validere at Azure AI Foundry kan dekke OCR + forklaring + audit innen tids- og kostbudsjett\n\n## Faser\n\n### Fase 1 — Foundation (uker 1-2)\n\nVarighet: 2 uker\nStatus: done\n\nMilepæler:\n- Foundry hub + project i West Europe\n- Identity og networking konfigurert\n- Sample-data uploadet (10k anonymiserte vedlegg)\n\nSuksesskriterier:\n- Inferens-endpoint nåbart fra dev-Vnet via Private Endpoint\n- Audit-logg fanger første test-inferens\n- Cost-monitor viser daglig forbruk i Azure portal\n\n### Fase 2 — OCR-modell (uker 3-5)\n\nVarighet: 3 uker\nStatus: active\n\nMilepæler:\n- Pre-trent Azure AI Vision OCR pilotert\n- Custom fine-tune på 10k vedlegg\n- Sammenligning av accuracy/latency mellom de to\n\nSuksesskriterier:\n- F1 ≥ 92% på pilot-sett (lavere mål enn produksjon, akseptabelt for POC)\n- Latency P95 < 200ms\n- Inference-cost ≤ NOK 0.04 per kall\n\n### Fase 3 — Forklarings-loop (uker 6-7)\n\nVarighet: 2 uker\nStatus: planned\n\nMilepæler:\n- GPT-4 Turbo via Foundry integrert\n- Prompt-template for forklaring av flagged sak\n- saksbehandler-mock UI (en enkel webside) prøvd ut med 3 brukere\n\nSuksesskriterier:\n- Forklaring referer til konfidens og kontekst korrekt i 95% av tilfellene\n- saksbehandler-feedback kvalitativt positiv (\"forståelig, men trenger justering\")\n- Prompt-tokens under 250 i snitt per sak\n\n### Fase 4 — Compliance-pre-check (uke 8)\n\nVarighet: 1 uke\nStatus: planned\n\nMilepæler:\n- Audit-logg mot EU AI Act Art. 12-krav\n- Customer-managed keys verifisert\n- Pre-DPIA-sjekk gjort med Datatilsynet\n\nSuksesskriterier:\n- Audit-logg dekker 100% av inferences med tidsstempel + bruker\n- Personvernombud signer pre-DPIA-utkast\n- Ingen åpenbare GDPR-blokkere\n\n## Risiko\n\n| Risiko | Sannsynlighet | Konsekvens | Tiltak |\n|--------|---------------|------------|--------|\n| Custom OCR-modell underyter pre-trent | medium | medium | Aksepter pre-trent for POC; planlegg custom for full prod |\n| Foundry-quota i West Europe utilstrekkelig | low | medium | Reserver kapasitet før POC starter |\n| saksbehandler-recruitment forsinker fase 3 | medium | low | Bruk interne ressurser i AI-teamet som mock |\n| Audit-logg-format ikke kompatibelt med Sentinel | low | medium | Test integrasjon i fase 1 |\n\n## POC-Verdict: BETINGET\n\nPilot-fase 1 fullført med F1=0.94 og inference-cost 0.038 NOK/kall (under budsjett). Fase 2 pågår — sammenligning av custom fine-tune mot pre-trent OCR i progress. Forklarings-loop og compliance-pre-check planlagt for siste halvdel.\n\n## Total varighet\n\n8 uker. Beslutningskriterium for full prosjektgodkjenning: alle 4 fasers suksesskriterier møtt.\n"
        },
        "utredning": {
          "input": {},
-          "raw_markdown": "# AI-arkitekturutredning — Acme Kunde-chatbot for Acme Kommune\n\n## 1. Bakgrunn og formål\n\nAcme Kommune har siden 2018 driftet en on-prem Acme Kunde-chatbot-løsning for operasjonell analyse på tvers av leverandørens tjenesteportefølje. Løsningen er basert på et OCR-bibliotek fra 2017 og leveres som et lukket system uten mulighet for retrening eller forbedring av modell. Saksbehandlingen er manuell og tar i snitt 14 minutter per sak. Et internt AI-team utreder modernisering til en skybasert AI-plattform som støtter custom modell-trening, audit-logging på inferens-nivå, og saksbehandler-co-pilot.\n\n## 2. Mandat\n\nUtredningen skal:\n- Anbefale teknologivalg blant Azure AI Foundry, Azure ML+AKS, AWS SageMaker og on-prem GPU-cluster\n- Vurdere compliance-status mot EU AI Act, GDPR, sikkerhetsloven og arkivloven\n- Estimere TCO over 3 år\n- Identifisere risiko og foreslå mitigerende tiltak\n- Definere KPI-er for produksjonssetting\n\n## 3. Metode\n\nUtredningen kombinerer:\n- Kvalitativ analyse av compliance-krav per relevante lover og forskrifter\n- Kvantitativ TCO-analyse basert på 12 millioner Acme Kunde-chatbot-deteksjoner/mnd\n- Risikoanalyse per NS 5814 og DPIA per Datatilsynets veileder\n- Markedsundersøkelse av tilgjengelige plattformer fra Azure, AWS og GCP\n\n## 4. Funn\n\n### 4.1 Compliance\n\nEU AI Act klassifiserer systemet som høyrisiko (Annex III, punkt 6 — rettshåndhevelse). Acme Kommune er Provider og Deployer, hvilket trigger alle krav i Art. 9-15 + Art. 27 (FRIA) + Art. 49 (registrering).\n\n### 4.2 Teknologivalg\n\nAzure AI Foundry er anbefalt primær plattform fordi:\n- Full compliance-pakke for leverandøren\n- Customer-managed keys og Customer Lockbox tilgjengelig\n- Custom modell-trening via integrert Azure ML\n- Norsk dataresidens (West Europe + EU Data Boundary)\n\n### 4.3 TCO\n\n3-års TCO estimert til NOK 6.7M (P50). Hovedkostnad: Azure AI Services (38%) + Azure OpenAI (16%).\n\n### 4.4 Risiko\n\nHovedrisiko: bias mot utenlandske objekt-ID, modell-drift over tid, og manglende ABAC-implementering på saksbehandler-tilgang. Alle har konkrete tiltak.\n\n## 5. Konklusjon\n\nAnbefalt: gjennomfør 8-ukers POC før formell prosjektoppstart. Ved vellykket POC, full implementering over 28 uker mot produksjonssetting Q2 2027.\n\n## 6. Anbefaling\n\nGodkjenn POC-budsjett på NOK 1.2M og forenkle prosjekt-mandat for fase 1-4 ved positiv POC-evaluering.\n\n## 7. Referanser\n\n- EU AI Act 2024/1689\n- GDPR 2016/679\n- Sikkerhetsloven (LOV-2018-06-01-24)\n- Arkivloven (LOV-1992-12-04-126)\n- NS 5814:2008 — Krav til risikovurderinger\n- Datatilsynets veileder for AI og personvern (2024)\n"
+          "raw_markdown": "# AI-arkitekturutredning — Acme Kunde-chatbot for Acme Kommune\n\n## 1. Bakgrunn og formål\n\nAcme Kommune har siden 2018 driftet en on-prem Acme Kunde-chatbot-løsning for forhåndsvurdering av søknader på tvers av kommunens tjenesteportefølje. Løsningen er basert på et OCR-bibliotek fra 2017 og leveres som et lukket system uten mulighet for retrening eller forbedring av modell. Saksbehandlingen er manuell og tar i snitt 14 minutter per sak. Et internt AI-team utreder modernisering til en skybasert AI-plattform som støtter custom modell-trening, audit-logging på inferens-nivå, og saksbehandler-co-pilot.\n\n## 2. Mandat\n\nUtredningen skal:\n- Anbefale teknologivalg blant Azure AI Foundry, Azure ML+AKS, AWS SageMaker og on-prem GPU-cluster\n- Vurdere compliance-status mot EU AI Act, GDPR, sikkerhetsloven og arkivloven\n- Estimere TCO over 3 år\n- Identifisere risiko og foreslå mitigerende tiltak\n- Definere KPI-er for produksjonssetting\n\n## 3. Metode\n\nUtredningen kombinerer:\n- Kvalitativ analyse av compliance-krav per relevante lover og forskrifter\n- Kvantitativ TCO-analyse basert på 1,2 millioner chatbot-meldinger og vedlegg/mnd\n- Risikoanalyse per NS 5814 og DPIA per Datatilsynets veileder\n- Markedsundersøkelse av tilgjengelige plattformer fra Azure, AWS og GCP\n\n## 4. Funn\n\n### 4.1 Compliance\n\nEU AI Act klassifiserer systemet som høyrisiko (Annex III, punkt 5(a) — tilgang til offentlige ytelser). Acme Kommune er Provider og Deployer, hvilket trigger alle krav i Art. 9-15 + Art. 27 (FRIA) + Art. 49 (registrering).\n\n### 4.2 Teknologivalg\n\nAzure AI Foundry er anbefalt primær plattform fordi:\n- Full compliance-pakke for leverandøren\n- Customer-managed keys og Customer Lockbox tilgjengelig\n- Custom modell-trening via integrert Azure ML\n- Norsk dataresidens (West Europe + EU Data Boundary)\n\n### 4.3 TCO\n\n3-års TCO estimert til NOK 6.7M (P50). Hovedkostnad: Azure AI Services (38%) + Azure OpenAI (16%).\n\n### 4.4 Risiko\n\nHovedrisiko: bias mot henvendelser på andre språk enn norsk, modell-drift over tid, og manglende ABAC-implementering på saksbehandler-tilgang. Alle har konkrete tiltak.\n\n## 5. Konklusjon\n\nAnbefalt: gjennomfør 8-ukers POC før formell prosjektoppstart. Ved vellykket POC, full implementering over 28 uker mot produksjonssetting Q2 2027.\n\n## 6. Anbefaling\n\nGodkjenn POC-budsjett på NOK 1.2M og forenkle prosjekt-mandat for fase 1-4 ved positiv POC-evaluering.\n\n## 7. Referanser\n\n- EU AI Act 2024/1689\n- GDPR 2016/679\n- Sikkerhetsloven (LOV-2018-06-01-24)\n- Arkivloven (LOV-1992-12-04-126)\n- NS 5814:2008 — Krav til risikovurderinger\n- Datatilsynets veileder for AI og personvern (2024)\n"
        },
        "compare": {
          "input": {},
@ -5617,7 +5617,7 @@
        sub: 'Hvem er dere?',
        fields: [
          { id: 'name', label: 'Virksomhetsnavn', type: 'text', required: true,
-            placeholder: 'f.eks. Bærum kommune, Statens vegvesen, Helse Sør-Øst RHF' },
+            placeholder: 'f.eks. Bærum kommune, Eksempeldirektoratet, Helse Sør-Øst RHF' },
          { id: 'description', label: 'Kort beskrivelse', type: 'textarea',
            placeholder: 'Hva gjør virksomheten? F.eks. "Kommune med 8 000 ansatte, ansvar for skole, helse og byggesak."' },
          { id: 'sector', label: 'Sektor', type: 'select', required: true,
--- a/playground/screenshots/v1.10.0/01-onboarding-empty-dark.png
+++ b/playground/screenshots/v1.10.0/01-onboarding-empty-dark.png
--- a/playground/screenshots/v1.11.0/01-onboarding-empty-dark.png
+++ b/playground/screenshots/v1.11.0/01-onboarding-empty-dark.png
--- a/playground/screenshots/v1.14.0/01-onboarding-empty-dark.png
+++ b/playground/screenshots/v1.14.0/01-onboarding-empty-dark.png
--- a/playground/screenshots/v1.15.0/01-onboarding-empty-dark.png
+++ b/playground/screenshots/v1.15.0/01-onboarding-empty-dark.png
--- a/playground/test-fixtures/classify.md
+++ b/playground/test-fixtures/classify.md
@ -1,7 +1,7 @@
 # EU AI Act — Klassifisering: Acme Kunde-chatbot

 System: Acme Kunde-chatbot (Acme Kommune)
-Beskrivelse: AI-system som identifiserer objekter som krever oppfølging via sensordata + objektregister
+Beskrivelse: Innbyggerchatbot som svarer på henvendelser og forhåndsvurderer søknader om kommunal bostøtte via vedleggstolkning + oppslag i fagsystemet

 ## Risikonivå

@ -13,7 +13,7 @@ Rolle: Provider og Deployer (utvikler internt + drifter selv)

 ## Begrunnelse

-Reasoning: Systemet brukes av offentlig myndighet for håndheving av lov, og påvirker individers rettigheter direkte gjennom automatisert beslutningsstøtte for håndtering. Dette plasserer systemet under Annex III, punkt 6 (rettshåndhevelse) og krever full høyrisiko-compliance per Art. 6(2).
+Reasoning: Systemet brukes av offentlig myndighet til å vurdere om innbyggere har rett til en offentlig ytelse, og påvirker individers rettigheter direkte gjennom automatisert beslutningsstøtte for saksbehandlingen. Dette plasserer systemet under Annex III, punkt 5(a) (tilgang til offentlige ytelser og tjenester) og krever full høyrisiko-compliance per Art. 6(2).

 ## Forpliktelser

--- a/playground/test-fixtures/conformity.md
+++ b/playground/test-fixtures/conformity.md
@ -13,8 +13,8 @@ Vurderingsprosedyre: Annex VI (intern kontroll)
 | Logging av hendelser implementert | bestått | OpenTelemetry-spans i Azure Monitor |
 | Transparens-instruksjoner skrevet | avvist | Skal leveres innen 2026-09-01 |
 | Menneskelig oversikt på saksbehandler | bestått | Workflow-design godkjent av juridisk |
-| Nøyaktighetsmål dokumentert | betinget | 96.3% overall, men ikke per objekt-ID-region |
-| Robusthet under adversarielle forhold | betinget | Test-suite mangler skitne plater og natt-scenarier |
+| Nøyaktighetsmål dokumentert | betinget | 96.3% overall, men ikke per språkgruppe |
+| Robusthet under adversarielle forhold | betinget | Test-suite mangler skannede, skjeve og håndskrevne vedlegg |
 | Cybersikkerhetstiltak per Art. 15 | bestått | NSM Grunnprinsipper-vurdering bestått |
 | Conformity assessment underskrevet | avvist | Avhengig av FRIA-resultat |
 | EU declaration of conformity utstedt | avvist | Avhenger av Art. 47 |
--- a/playground/test-fixtures/cost.md
+++ b/playground/test-fixtures/cost.md
@ -18,7 +18,7 @@ Valuta: NOK
 |-----------|-------------------|
 | Azure AI Services (OCR + classification) | 64 000 |
 | Azure OpenAI (forklaringsmodell) | 28 000 |
-| Azure AI Search (indeks for objektregister) | 12 000 |
+| Azure AI Search (indeks for regelverk og tjenesteinformasjon) | 12 000 |
 | Storage (blob + cosmos for audit) | 8 500 |
 | Compute (Container Apps for orchestration) | 11 000 |
 | Networking (Private Endpoints + egress) | 5 200 |
@ -35,13 +35,13 @@ Valuta: NOK

 ## Kostnadsdrivere

- Datavolum: ~12 millioner Acme Kunde-chatbot-deteksjoner/mnd
- Forklaring-prompt-tokens: ~250 tokens per flagged hendelse
+- Datavolum: ~1,2 millioner chatbot-meldinger og vedlegg/mnd
+- Forklaring-prompt-tokens: ~250 tokens per flaggede søknad
 - Reservert kapasitet for 99.9% SLA

 ## Konfidensgradering

-P50 er beregnet med 95% konfidens basert på 6 måneder pilot-data. P90 inkluderer 2× volum-skalering ved fullnasjonal utrulling. P10 forutsetter optimaliserte prompt-cache (>40% hit-rate).
+P50 er beregnet med 95% konfidens basert på 6 måneder pilot-data. P90 inkluderer 2× volum-skalering ved utvidelse til flere tjenesteområder. P10 forutsetter optimaliserte prompt-cache (>40% hit-rate).

 ## Anbefaling

--- a/playground/test-fixtures/dpia.md
+++ b/playground/test-fixtures/dpia.md
@ -7,12 +7,12 @@ Metodikk: Datatilsynets veileder + ISO/IEC 29134

 | Trussel | Sannsynlighet | Konsekvens | Score | Nivå |
 |---------|---------------|------------|-------|------|
-| Feilaktig objekt-ID-tolkning fører til urettmessig sanksjon | 3 | 4 | 12 | medium |
-| Massiv lokasjonsdata-lekkasje fra objektregister | 2 | 5 | 10 | medium |
-| AI-forklaring viser sensitiv kontekst om eier | 3 | 3 | 9 | medium |
-| Stratifisert bias mot utenlandske objekt-ID | 4 | 3 | 12 | medium |
-| Fysisk angrep på sensordata skaper deteksjonshull | 2 | 2 | 4 | low |
-| Insider-misbruk for sporing av enkeltpersoner | 2 | 5 | 10 | medium |
+| Feilaktig vedleggstolkning fører til urettmessig avslag | 3 | 4 | 12 | medium |
+| Massiv lekkasje av økonomiopplysninger fra fagsystemet | 2 | 5 | 10 | medium |
+| AI-forklaring viser sensitiv kontekst om søker | 3 | 3 | 9 | medium |
+| Stratifisert bias mot henvendelser på andre språk | 4 | 3 | 12 | medium |
+| Manipulerte vedlegg skaper vurderingshull | 2 | 2 | 4 | low |
+| Insider-misbruk for oppslag på enkeltpersoner | 2 | 5 | 10 | medium |
 | Auto-flagging utløser kjedereaksjon ved system-feil | 1 | 5 | 5 | low |
 | Subject Access Request (GDPR Art. 15) ignoreres | 3 | 3 | 9 | medium |

@ -20,10 +20,10 @@ Metodikk: Datatilsynets veileder + ISO/IEC 29134

 | ID | Beskrivelse | Severity | Tiltak |
 |----|-------------|----------|--------|
-| T-001 | Feilaktig OCR av objekt-ID | high | Konfidensgrad-cutoff på 0.95; saksbehandler-review under cutoff |
-| T-002 | Lokasjonsdata-lekkasje | critical | Pseudonymisering ved lagring; HSM-backed nøkler i Azure Key Vault |
+| T-001 | Feilaktig OCR av vedlegg | high | Konfidensgrad-cutoff på 0.95; saksbehandler-review under cutoff |
+| T-002 | Lekkasje av økonomiopplysninger | critical | Pseudonymisering ved lagring; HSM-backed nøkler i Azure Key Vault |
 | T-003 | Kontekst-eksponering i AI-forklaring | high | Filter på sensitive felt; kontekst kun til autorisert saksbehandler |
-| T-004 | Bias mot utenlandske registre | high | Kvartalsvis stratifisert testing; juster modell ved >5% avvik |
+| T-004 | Bias mot henvendelser på andre språk | high | Kvartalsvis stratifisert testing; juster modell ved >5% avvik |
 | T-005 | Insider-misbruk | critical | Audit-logging på alle oppslag; SIEM-deteksjon av unormale mønstre |

 ## Tiltak
--- a/playground/test-fixtures/frimpact.md
+++ b/playground/test-fixtures/frimpact.md
@ -8,16 +8,16 @@ Hjemmel: EU AI Act Art. 27 (obligatorisk for offentlig sektor)
 | Rettighet | Impact | Tiltak |
 |-----------|--------|--------|
 | Menneskeverd | 1 | Ingen reduksjon — saksbehandler tar endelig avgjørelse, ikke AI |
-| Rett til frihet og sikkerhet | 1 | Ingen frihetsberøvelse direkte fra AI; politi/domstol er reell beslutter |
-| Respekt for privatliv | 4 | Massiv overvåking via veikameraer — kompenseres med strenge oppbevaringsregler (90 dager), formålsbegrensning, og minimering av kobling til objektregister |
+| Rett til frihet og sikkerhet | 0 | Ikke berørt — systemet vurderer bare søknader om en økonomisk ytelse |
+| Respekt for privatliv | 4 | Samtaler og vedlegg inneholder ofte helse-, familie- og økonomiopplysninger som innbyggere oppgir fritt — kompenseres med strenge oppbevaringsregler (90 dager for samtalelogger), formålsbegrensning, og minimering av kobling til fagsystemet |
 | Personvern | 4 | DPIA gjennomført; Datatilsynet konsultert; rettslig grunnlag i interne retningslinjer §13 — likevel høy impact pga skala |
-| Ikke-diskriminering | 3 | Algoritmisk bias-testing på objekt-ID fra utenlandske registre (lavere Acme Kunde-chatbot-nøyaktighet) — kvartalsvis review |
+| Ikke-diskriminering | 3 | Algoritmisk bias-testing på henvendelser og vedlegg på andre språk enn norsk (lavere tolkningsnøyaktighet) — kvartalsvis review |
 | Ytringsfrihet og informasjonsfrihet | 0 | Ikke berørt |
 | Forsamlingsfrihet | 0 | Ikke berørt |
 | Religionsfrihet | 0 | Ikke berørt |
-| Eiendomsrett | 2 | Gebyr/sanksjoner berører eiendomsrett — kompenseres med klagemulighet og rettslig prøving |
+| Rett til sosial sikring | 2 | Feilaktig forhåndsvurdering kan forsinke en ytelse — kompenseres med at saksbehandler vurderer hver søknad, og med klagemulighet |
 | Rett til effektivt rettsmiddel | 2 | Klageadgang sikret; menneskelig review garantert; AI-forklaring tilgjengelig for klager |
-| Barns rettigheter | 1 | Lav direkte påvirkning; barn er sjelden registrerte førere |
+| Barns rettigheter | 1 | Lav direkte påvirkning; barn søker ikke selv, men bor i husstander som søker |
 | Eldres rettigheter | 2 | Eldre kan ha vanskeligere for å klage digitalt — papir-klage må fortsatt være tilgjengelig |

 ## Konklusjon
--- a/playground/test-fixtures/license.md
+++ b/playground/test-fixtures/license.md
@ -7,7 +7,7 @@ Vurderingsdato: 2026-04-30

 | Kapabilitet | M365 E3 | M365 E5 | Copilot for M365 | Copilot Studio | Azure AI Foundry |
 |-------------|---------|---------|------------------|----------------|------------------|
-| OCR av objekt-ID | missing | missing | missing | conditional | available |
+| OCR av vedlegg | missing | missing | missing | conditional | available |
 | Custom modell-trening | missing | missing | missing | missing | available |
 | Audit-logging på AI-input | missing | available | available | available | available |
 | Customer-managed keys | missing | available | conditional | conditional | available |
--- a/playground/test-fixtures/migrate.md
+++ b/playground/test-fixtures/migrate.md
@ -28,13 +28,13 @@ Varighet: 8 uker
 Status: done

 Milepæler:
- Treningsdata kuratert (200k norske objekt-ID, stratifisert)
+- Treningsdata kuratert (200k anonymiserte vedlegg, stratifisert på dokumenttype og språk)
 - Custom modell trent på Azure ML
 - Baseline-nøyaktighet etablert (mål: ≥96% F1)
- Bias-evaluering på utenlandske registre fullført
+- Bias-evaluering på henvendelser og vedlegg på andre språk fullført

 Suksesskriterier:
- F1 ≥ 96% overall, ≥ 92% per objekter-segment
+- F1 ≥ 96% overall, ≥ 92% per dokumenttype
 - Drift-deteksjon kalibrert med terskel
 - ROS-revisjon godkjent

@ -46,8 +46,8 @@ Status: active
 Milepæler:
 - Forklaringsmodell (GPT-4 Turbo) integrert via Foundry
 - saksbehandler-UI bygget (Copilot Studio + Power Platform)
- Workflow: AI flagger → saksbehandler reviewer → klar for sanksjon
- Brukertest med 12 saksbehandler fra ulike regioner
+- Workflow: AI flagger → saksbehandler reviewer → klar for vedtak
+- Brukertest med 12 saksbehandlere fra ulike tjenesteområder

 Suksesskriterier:
 - Saksbehandlingstid -40% vs baseline
@ -63,7 +63,7 @@ Milepæler:
 - FRIA gjennomført og godkjent
 - Conformity assessment ferdigstilt per Annex VI
 - DPIA oppdatert med nye operasjonelle data
- Produksjonssetting til 3 piloter (Oslo, Bergen, Trondheim)
+- Produksjonssetting i 3 pilotbydeler

 Suksesskriterier:
 - Personvernombud signerer DPIA
--- a/playground/test-fixtures/poc.md
+++ b/playground/test-fixtures/poc.md
@ -13,7 +13,7 @@ Status: done
 Milepæler:
 - Foundry hub + project i West Europe
 - Identity og networking konfigurert
- Sample-data uploadet (10k anonymiserte objekt-ID)
+- Sample-data uploadet (10k anonymiserte vedlegg)

 Suksesskriterier:
 - Inferens-endpoint nåbart fra dev-Vnet via Private Endpoint
@ -27,7 +27,7 @@ Status: active

 Milepæler:
 - Pre-trent Azure AI Vision OCR pilotert
- Custom fine-tune på 10k objekt-ID
+- Custom fine-tune på 10k vedlegg
 - Sammenligning av accuracy/latency mellom de to

 Suksesskriterier:
--- a/playground/test-fixtures/requirements.md
+++ b/playground/test-fixtures/requirements.md
@ -12,7 +12,7 @@ Klassifisering: høy risiko, rolle Provider+Deployer
 | Teknisk dokumentasjon (Annex IV) komplett | partial | Art. 11 |
 | Automatisk logging av hendelser implementert | met | Art. 12 |
 | Transparens-instruksjoner for deployer skrevet | missing | Art. 13 |
-| Human-in-the-loop på alle sanksjonsavgjørelser | met | Art. 14 |
+| Human-in-the-loop på alle vedtak om avslag | met | Art. 14 |
 | Nøyaktighetsmål med stratifisert testing | partial | Art. 15 |
 | Cybersikkerhetstiltak verifisert (NSM Grunnprinsipper) | met | Art. 15 |
 | FRIA gjennomført før idriftsettelse | missing | Art. 27 |
--- a/playground/test-fixtures/review.md
+++ b/playground/test-fixtures/review.md
@ -16,7 +16,7 @@ Reviewers: AI-arkitekt, sikkerhetsarkitekt, Datatilsynet
 | F-06 | medium | review | Compliance | FRIA-rapport ikke vedlikeholdt etter modell-endring 2026-03-12. Re-evaluering trengs. |
 | F-07 | medium | keep | UX | saksbehandler-grensesnitt viser ikke konfidensgrad tydelig nok — risiko for over-trust på AI-output. |
 | F-08 | low | suppressed | Documentation | README mangler oppdatert arkitekturdiagram (siste fra 2025-11). |
-| F-09 | low | suppressed | Testing | Manglende E2E-test for utenlandske objekt-ID. |
+| F-09 | low | suppressed | Testing | Manglende E2E-test for henvendelser på andre språk. |

 ## Sammendrag

--- a/playground/test-fixtures/ros.md
+++ b/playground/test-fixtures/ros.md
@ -8,13 +8,13 @@ Metodikk: NS 5814 / ISO 31000 + AI-trusselbibliotek
 | Trussel | Sannsynlighet | Konsekvens | Score | Nivå |
 |---------|---------------|------------|-------|------|
 | Modell-drift som degraderer nøyaktighet | 4 | 3 | 12 | medium |
-| Treningsdata-bias mot småbiler eller MC | 3 | 3 | 9 | medium |
-| Adversarielle plate-design unngår OCR | 2 | 4 | 8 | medium |
+| Treningsdata-bias mot nynorsk og andre språk | 3 | 3 | 9 | medium |
+| Manipulerte vedlegg unngår OCR-kontroll | 2 | 4 | 8 | medium |
 | API-utilgjengelighet i kritisk periode | 2 | 4 | 8 | medium |
 | Klage-saksbehandling overbelastet ved skalering | 4 | 3 | 12 | medium |
 | Datatap pga manglende georedundans | 1 | 5 | 5 | low |
-| Misbruk av AI-forklaring som bevis | 3 | 4 | 12 | medium |
-| Kjedevirkning ved feil i objektregister | 2 | 5 | 10 | medium |
+| Misbruk av AI-forklaring som vedtaksbegrunnelse | 3 | 4 | 12 | medium |
+| Kjedevirkning ved feil i fagsystemet | 2 | 5 | 10 | medium |

 ## Radar-akser (7 dimensjoner)

@ -33,8 +33,8 @@ Metodikk: NS 5814 / ISO 31000 + AI-trusselbibliotek
 | ID | Beskrivelse | Severity | Tiltak |
 |----|-------------|----------|--------|
 | T-101 | Modell-drift over tid | high | Månedlig retraining-pipeline; alarm ved >2% nøyaktighetsfall |
-| T-102 | Bias mot småbiler/MC | high | Stratifisert evaluering ved hver release |
-| T-103 | Adversarielle plate-design | medium | Robusthetstest mot kjente angreps-mønstre |
+| T-102 | Bias mot nynorsk og andre språk | high | Stratifisert evaluering ved hver release |
+| T-103 | Manipulerte vedlegg | medium | Robusthetstest mot kjente angreps-mønstre |
 | T-104 | API-utilgjengelighet | medium | Multi-region failover med RTO 1t |
 | T-105 | Saksbehandlings-overbelastning | high | Automatisk batching + prioriteringsregler |

@ -54,9 +54,9 @@ Metodikk: NS 5814 / ISO 31000 + AI-trusselbibliotek
 |----|---------|-------|----------|
 | T-101 | Modell-drift over tid | 12 | high |
 | T-105 | Saksbehandlings-overbelastning | 12 | high |
-| T-107 | Misbruk av AI-forklaring som bevis | 12 | high |
-| T-108 | Kjedevirkning ved feil i objektregister | 10 | high |
-| T-103 | Bias mot småbiler/MC | 9 | medium |
+| T-107 | Misbruk av AI-forklaring som vedtaksbegrunnelse | 12 | high |
+| T-108 | Kjedevirkning ved feil i fagsystemet | 10 | high |
+| T-103 | Bias mot nynorsk og andre språk | 9 | medium |

 Restrisiko: 4×3 → 2×2

--- a/playground/test-fixtures/summary.md
+++ b/playground/test-fixtures/summary.md
@ -29,12 +29,12 @@ Arkitekturen er teknisk solid og økonomisk forsvarlig (P50 NOK 1.7M/år), men c
 - Lukk F-01 (ABAC) innen 2026-06-15
 - Gjennomfør FRIA innen 2026-07-15 (Art. 27-frist)
 - Produksjonsdokumentere transparens-instruksjoner innen 2026-09-01
- Pilot 3 regioner (Oslo, Bergen, Trondheim) Q4 2026
+- Pilot i 3 bydeler Q4 2026
 - Full utrulling Q2 2027

 ## Restrisiko

-Etter foreslåtte tiltak: medium. Hovedeksponering: bias mot utenlandske objekt-ID krever løpende monitoring.
+Etter foreslåtte tiltak: medium. Hovedeksponering: bias mot henvendelser på andre språk enn norsk krever løpende monitoring.

 ## Anbefaling

--- a/playground/test-fixtures/transparency.md
+++ b/playground/test-fixtures/transparency.md
@ -1,18 +1,18 @@
 # Transparensnotis — Acme Kunde-chatbot

-Tittel: Informasjon om automatisert operasjonell analyse (Art. 13 og Art. 50)
+Tittel: Informasjon om automatisert forhåndsvurdering av søknader (Art. 13 og Art. 50)

 ## Hva systemet gjør

-Acme Kommune bruker et AI-system som leser av objekt-ID (Acme Kunde-chatbot — automatisert klassifisering) fra sensordata langs produksjonsmiljøet. Systemet identifiserer objekter som har overtrådt terskelverdi gjennom å beregne gjennomsnittlig respons mellom to datapunkt.
+Acme Kommune bruker et AI-system (Acme Kunde-chatbot) som svarer på spørsmål om kommunale tjenester og leser vedlegg du laster opp med en søknad om bostøtte. Systemet vurderer om søknaden er komplett, og om inntekt og boutgifter ser ut til å ligge innenfor vilkårene.

 ## Hvilke data som behandles

-Behandlede data inkluderer objekt-ID, tidsstempel, datapunkt, objektklasse og oppslag i Acme Kommune objektregister. Personlig identifiserbar informasjon kobles ikke til oppføring uten saksbehandler eksplisitte godkjenning.
+Behandlede data inkluderer det du skriver i chatten, opplastede vedlegg, saksnummer, tidsstempel og oppslag i Acme Kommunes fagsystem for bostøtte. Samtalen kobles ikke til søknaden din uten at du samtykker til det i chatten.

 ## Hvordan beslutninger tas

-Systemet er beslutningsstøtte, ikke -taker. Hver flagged hendelse går til menneskelig saksbehandler som tar endelig avgjørelse om gebyr eller anmeldelse. AI-output inkluderer konfidensgrad og forklaring av hvorfor saken ble flagget.
+Systemet er beslutningsstøtte, ikke -taker. Hver flaggede søknad går til en menneskelig saksbehandler som fatter vedtaket. AI-output inkluderer konfidensgrad og forklaring av hvorfor saken ble flagget.

 ## Dine rettigheter

--- a/playground/test-fixtures/utredning.md
+++ b/playground/test-fixtures/utredning.md
@ -2,7 +2,7 @@

 ## 1. Bakgrunn og formål

-Acme Kommune har siden 2018 driftet en on-prem Acme Kunde-chatbot-løsning for operasjonell analyse på tvers av leverandørens tjenesteportefølje. Løsningen er basert på et OCR-bibliotek fra 2017 og leveres som et lukket system uten mulighet for retrening eller forbedring av modell. Saksbehandlingen er manuell og tar i snitt 14 minutter per sak. Et internt AI-team utreder modernisering til en skybasert AI-plattform som støtter custom modell-trening, audit-logging på inferens-nivå, og saksbehandler-co-pilot.
+Acme Kommune har siden 2018 driftet en on-prem Acme Kunde-chatbot-løsning for forhåndsvurdering av søknader på tvers av kommunens tjenesteportefølje. Løsningen er basert på et OCR-bibliotek fra 2017 og leveres som et lukket system uten mulighet for retrening eller forbedring av modell. Saksbehandlingen er manuell og tar i snitt 14 minutter per sak. Et internt AI-team utreder modernisering til en skybasert AI-plattform som støtter custom modell-trening, audit-logging på inferens-nivå, og saksbehandler-co-pilot.

 ## 2. Mandat

@ -17,7 +17,7 @@ Utredningen skal:

 Utredningen kombinerer:
 - Kvalitativ analyse av compliance-krav per relevante lover og forskrifter
- Kvantitativ TCO-analyse basert på 12 millioner Acme Kunde-chatbot-deteksjoner/mnd
+- Kvantitativ TCO-analyse basert på 1,2 millioner chatbot-meldinger og vedlegg/mnd
 - Risikoanalyse per NS 5814 og DPIA per Datatilsynets veileder
 - Markedsundersøkelse av tilgjengelige plattformer fra Azure, AWS og GCP

@ -25,7 +25,7 @@ Utredningen kombinerer:

 ### 4.1 Compliance

-EU AI Act klassifiserer systemet som høyrisiko (Annex III, punkt 6 — rettshåndhevelse). Acme Kommune er Provider og Deployer, hvilket trigger alle krav i Art. 9-15 + Art. 27 (FRIA) + Art. 49 (registrering).
+EU AI Act klassifiserer systemet som høyrisiko (Annex III, punkt 5(a) — tilgang til offentlige ytelser). Acme Kommune er Provider og Deployer, hvilket trigger alle krav i Art. 9-15 + Art. 27 (FRIA) + Art. 49 (registrering).

 ### 4.2 Teknologivalg

@ -41,7 +41,7 @@ Azure AI Foundry er anbefalt primær plattform fordi:

 ### 4.4 Risiko

-Hovedrisiko: bias mot utenlandske objekt-ID, modell-drift over tid, og manglende ABAC-implementering på saksbehandler-tilgang. Alle har konkrete tiltak.
+Hovedrisiko: bias mot henvendelser på andre språk enn norsk, modell-drift over tid, og manglende ABAC-implementering på saksbehandler-tilgang. Alle har konkrete tiltak.

 ## 5. Konklusjon

--- a/skills/ms-ai-advisor/references/architecture/adr-template.md
+++ b/skills/ms-ai-advisor/references/architecture/adr-template.md
@ -648,7 +648,7 @@ Selv om Microsoft Foundry gir mer fleksibilitet, oppveier ikke dette den 60% hø
 ### Kontekst og problemstilling

 **Bakgrunn:**
-Vi har en kunde-facing chatbot for Direktoratet for digital tjenesteutvikling sitt "Min Side"-portal (brukt av 500k+ innbyggere for å sjekke kjøretøyinfo, bøter, etc.). Chatbot skal svare på vanlige spørsmål og navigere brukere til riktig selvbetjeningsportal. Prototypen er bygget med Azure OpenAI GPT-4 på Standard (pay-as-you-go) deployment.
+Vi har en kunde-facing chatbot for Direktoratet for digital tjenesteutvikling sitt "Min Side"-portal (brukt av 500k+ innbyggere for å sjekke søknadsstatus, fakturaer, etc.). Chatbot skal svare på vanlige spørsmål og navigere brukere til riktig selvbetjeningsportal. Prototypen er bygget med Azure OpenAI GPT-4 på Standard (pay-as-you-go) deployment.

 **Problem statement:**
 Bestemme deployment-type for production: Standard (pay-per-token) vs Provisioned Throughput Units (PTU) for forutsigbar ytelse og kostnad.
--- a/skills/ms-ai-advisor/references/copilot-extensibility/copilot-extensibility-security-patterns.md
+++ b/skills/ms-ai-advisor/references/copilot-extensibility/copilot-extensibility-security-patterns.md
@ -532,12 +532,12 @@ Start-SPOAccessReview -SiteUrl "https://contoso.sharepoint.com/sites/Finance"

 **Copilot-tilgang basert på dataklassifisering:**
 ```yaml
-# Security Copilot plugin for vegdata
+# Security Copilot plugin for registerdata
 Descriptor:
-  Name: VegdataPlugin
+  Name: RegisterdataPlugin
  Authorization:
    Type: AADDelegated
-    EntraScopes: https://vegdata.no/.default
+    EntraScopes: https://register.example/.default
  DataClassification: Internal
  RequiredLabels:
    - Internal
@ -594,24 +594,24 @@ Descriptor:

 ### Når anbefale hvilken security pattern?

-**Scenario 1: Offentlig sektor (Direktoratet for digital tjenesteutvikling) trenger M365 Copilot med intern vegdata**
+**Scenario 1: Offentlig sektor (Direktoratet for digital tjenesteutvikling) trenger M365 Copilot med intern registerdata**

 **Anbefaling:**
 1. **Zero Trust foundation (E5 + SharePoint Advanced Management):**
   - Conditional Access: Require MFA + compliant devices
-   - Sensitivity labels på alle vegdata-dokumenter (Internal/Confidential)
-   - DLP policies for å blokkere deling av vegdata eksternt
-   - Oversharing review for alle SharePoint-siter med vegdata
+   - Sensitivity labels på alle registerdata-dokumenter (Internal/Confidential)
+   - DLP policies for å blokkere deling av registerdata eksternt
+   - Oversharing review for alle SharePoint-siter med registerdata

-2. **Connector for vegdata-API:**
+2. **Connector for registerdata-API:**
   - Microsoft Graph Connector med ACL basert på Entra groups
   - AADDelegated authentication (on-behalf-of)
-   - Vegdata forblir i tenant (ikke sendt til tredjeparter)
+   - Registerdata forblir i tenant (ikke sendt til tredjeparter)

 3. **Audit og compliance:**
   - Microsoft Purview Audit (1 år retention minimum for offentlig sektor)
   - Regular access reviews (kvartalsvis)
-   - DPIA for Copilot-bruk med vegdata
+   - DPIA for Copilot-bruk med registerdata

 **Kostnad (100 brukere):**
 - M365 Copilot: 30 000 NOK/måned
--- a/skills/ms-ai-advisor/references/prompt-engineering/multimodal-prompt-design.md
+++ b/skills/ms-ai-advisor/references/prompt-engineering/multimodal-prompt-design.md
@ -346,7 +346,7 @@ Can you tell me what the image depicts?

 | Sektor | Use case | Multimodal pattern |
 |--------|----------|-------------------|
-| **Direktoratet** | Skaderegistrering vei/bruer fra drone-bilder | Multi-image damage assessment |
+| **Kommunal eiendom** | Skaderegistrering av bygg fra drone-bilder | Multi-image damage assessment |
 | **NAV** | Automatisk dokumentklassifisering (skjema med vedlegg) | OCR + structured extraction |
 | **Helsedirektoratet** | Visuell analyse av offentlige helsedata (grafer) | ⚠️ IKKE medisinske bilder |
 | **Kulturminnevern** | Katalogisering av bygninger/artefakter | Product catalog pattern |
--- a/skills/ms-ai-engineering/references/agent-orchestration/agent-to-agent-a2a-protocol.md
+++ b/skills/ms-ai-engineering/references/agent-orchestration/agent-to-agent-a2a-protocol.md
@ -437,7 +437,7 @@ A2A er spesielt relevant for offentlig sektor fordi norske myndigheter opererer
 | Scenario | Aktører | A2A-kobling |
 |----------|---------|-------------|
 | Innbygger-henvendelse (NAV + Skatteetaten) | NAV-agent, Skatteetaten-agent | NAV-agent delegerer skatteoppslag via A2A |
-| Direktoratet for digital tjenesteutvikling + Politiet | Kjøretøy-agent, Trafikk-agent | Felles trafikkanalyse via A2A |
+| Direktoratet for digital tjenesteutvikling + kommune | Tilskudd-agent, Saksarkiv-agent | Felles saksoppslag via A2A |
 | Helseforetak på tvers | Sykehus A-agent, Fastlege-agent | Pasienthistorikk-utveksling (med samtykke) |
 | DigDir-tjenester | eID-agent, Altinn-agent | Autentisert datautveksling |

@ -455,7 +455,7 @@ A2A er spesielt relevant for offentlig sektor fordi norske myndigheter opererer

 ```json
 {
-  "name": "Direktoratet Kjøretøy-agent",
+  "name": "Direktoratet Tilskudd-agent",
  "version": "2.0.0",
  "capabilities": {
    "streaming": false,
@ -464,7 +464,7 @@ A2A er spesielt relevant for offentlig sektor fordi norske myndigheter opererer
  "extensions": {
    "gdpr": {
      "personalData": true,
-      "dataCategories": ["kjøretøydata", "eierskap"],
+      "dataCategories": ["søknadsdata", "inntekt"],
      "retentionDays": 90,
      "dataLocation": "Norway East",
      "legalBasis": "offentlig myndighetsutøvelse"
--- a/skills/ms-ai-engineering/references/agent-orchestration/declarative-vs-imperative-agent-design.md
+++ b/skills/ms-ai-engineering/references/agent-orchestration/declarative-vs-imperative-agent-design.md
@ -55,7 +55,7 @@ For mange organisasjoner er svaret ikke enten-eller, men en hybrid tilnærming d
    ],
    "knowledge": {
        "sharepoint_sites": [
-            "https://ddt.sharepoint.com/sites/IT-KB"
+            "https://contoso.sharepoint.com/sites/IT-KB"
        ],
        "graph_connectors": ["servicenow-connector"]
    },
--- a/skills/ms-ai-engineering/references/api-management/semantic-caching-apim.md
+++ b/skills/ms-ai-engineering/references/api-management/semantic-caching-apim.md
@ -286,7 +286,7 @@ Distance 1.0  = Helt ulike prompts
 | "Hva er hovedstaden i Norge?" | "Hvilken by er Norges hovedstad?" | ~0.05 | Ja |
 | "Forklar maskinlæring" | "Hva er machine learning?" | ~0.10 | Ja |
 | "Hvordan søker jeg om byggetillatelse?" | "Prosessen for å få byggetillatelse" | ~0.12 | Ja |
-| "Hva er veibygging?" | "Hvordan bygger man en bro?" | ~0.25 | Nei |
+| "Hva er fotosyntese?" | "Hvordan fungerer en solcelle?" | ~0.25 | Nei |
 | "Fortell om AI" | "Hva er kvantemekanikk?" | ~0.45 | Nei |

 ---
--- a/skills/ms-ai-engineering/references/data-engineering/data-cataloging-discovery.md
+++ b/skills/ms-ai-engineering/references/data-engineering/data-cataloging-discovery.md
@ -183,18 +183,18 @@ Unified Catalog tilbyr flere oppdagelsesmekanismer for å finne data:
 ```
 Eksempler på naturlig språk-søk (preview):

-Søk: "Jeg trenger tre år med trafikkdata fra Direktoratet for digital tjenesteutvikling
-       for å analysere rushtrafikk-mønstre"
-Resultat: Data products med trafikktelledata, reisehastighetsmålinger
+Søk: "Jeg trenger tre år med energidata fra Direktoratet for digital tjenesteutvikling
+       for å analysere forbruksmønstre i kontorbygg"
+Resultat: Data products med timeverdier fra energimålere, temperaturmålinger

 Søk: "Finn sertifiserte kundedata med kundeID, navn og adresse"
 Resultat: Data products med masterdata for kunder

-Søk: "Vis meg Power BI-rapporter om tilstandsdata for broer"
-Resultat: Rapporter og underliggende datasett for bro-tilstand
+Søk: "Vis meg Power BI-rapporter om tilstandsdata for skolebygg"
+Resultat: Rapporter og underliggende datasett for bygningstilstand

 Søk: "Jeg jobber med prediktiv vedlikehold.
-       Vis sensordata fra veisensorer"
+       Vis sensordata fra ventilasjonsanlegg"
 Resultat: IoT-sensordata, vedlikeholdshistorikk-datasett
 ```

@ -335,25 +335,25 @@ Governance Domain: "AI og Maskinlæring"
 │       ├── Synonymer: "Model drift", "Concept drift"
 │       └── Tilknyttede assets: monitoring.drift_metrics

-Governance Domain: "Veiforvaltning"
+Governance Domain: "Eiendomsforvaltning"
 ├── Glossary Terms
-│   ├── "AADT"
-│   │   ├── Definisjon: "Årsdøgntrafikk - gjennomsnittlig daglig trafikk"
-│   │   ├── Synonym: "Annual Average Daily Traffic"
-│   │   └── Tilknyttede assets: traffic.aadt_measurements
+│   ├── "EUI"
+│   │   ├── Definisjon: "Energiintensitet - årlig energiforbruk per m² oppvarmet areal"
+│   │   ├── Synonym: "Energy Use Intensity"
+│   │   └── Tilknyttede assets: energy.eui_measurements
 │   │
-│   ├── "ÅDT"
-│   │   ├── Definisjon: "Døgntrafikk for et enkelt år"
-│   │   └── Relatert: "AADT"
+│   ├── "Energiintensitet"
+│   │   ├── Definisjon: "Energiforbruk per m² for et enkelt år"
+│   │   └── Relatert: "EUI"
 │   │
 │   └── "Tilstandsgrad"
-│       ├── Definisjon: "Skala 0-5 for tilstandsvurdering av veiobjekter"
+│       ├── Definisjon: "Skala 0-5 for tilstandsvurdering av bygningsdeler"
 │       ├── Sub-termer:
 │       │   ├── "TG0 - Ingen avvik"
 │       │   ├── "TG1 - Mindre avvik"
 │       │   ├── "TG2 - Moderate avvik"
 │       │   └── "TG3 - Alvorlige avvik"
-│       └── Tilknyttede assets: nvdb.condition_assessments
+│       └── Tilknyttede assets: asset_register.condition_assessments
 ```

 ### Opprette glossary terms programmatisk
@ -394,7 +394,7 @@ ai_terms = [
                       "skal predikere på.",
        "abbreviation": "TD",
        "glossary_guid": ai_glossary_guid,
-        "owner": "ml-team@ddt.no",
+        "owner": "ml-team@ddt.example",
        "regulation": "GDPR Art. 6 - Lovlig behandlingsgrunnlag"
    },
    {
@ -402,7 +402,7 @@ ai_terms = [
        "definition": "Sentralisert repository for beregning, lagring og "
                       "servering av ML-features med punkt-i-tid korrekthet.",
        "glossary_guid": ai_glossary_guid,
-        "owner": "data-engineering@ddt.no"
+        "owner": "data-engineering@ddt.example"
    },
    {
        "name": "Dataminimering",
@ -531,9 +531,9 @@ def assign_data_owner(purview_endpoint, token, asset_guid, owner_info):

 # Eksempel: Tilordne eierskap for ML-datasett
 assign_data_owner(endpoint, token, gold_features_guid, {
-    "email": "ml-team@ddt.no",
+    "email": "ml-team@ddt.example",
    "aad_object_id": "abc-123-def",
-    "expert_email": "data-scientist@ddt.no",
+    "expert_email": "data-scientist@ddt.example",
    "expert_aad_id": "ghi-456-jkl"
 })
 ```
@ -560,12 +560,12 @@ Oppsett av Governance Domain for AI-prosjekter:

 4. Opprett data products:
   - "Customer 360 for Churn" -- Kundedatasett for churn-prediksjon
-   - "Traffic Sensor Features" -- Sensordata for trafikkanalyse
-   - "Bridge Condition ML Set" -- Bro-tilstandsdata for vedlikeholds-ML
+   - "Energy Sensor Features" -- Sensordata for energianalyse
+   - "Building Condition ML Set" -- Bygningstilstandsdata for vedlikeholds-ML

 5. Definer glossary terms:
   - AI-spesifikke termer (se seksjon over)
-   - Domenespesifikke termer (vei, trafikk, infrastruktur)
+   - Domenespesifikke termer (eiendom, energi, infrastruktur)

 6. Sett OKR-er:
   - "90% av AI-datasett har dokumentert eierskap innen Q2"
@ -790,9 +790,9 @@ def calculate_discovery_metrics(purview_endpoint, token, domain_id):
 ## For arkitekten

 - **Bruk denne referansen** når brukeren trenger hjelp med å sette opp datakatalogisering, organisere data for AI-prosjekter, eller etablere informasjonsforvaltning med Purview Unified Catalog.
- For norsk offentlig sektor: **Governance Domains** mapper naturlig til avdelinger/seksjoner i etaten. Anbefal å opprette domener som speiler organisasjonsstrukturen (f.eks. "AI og Maskinlæring", "Veiforvaltning", "Trafikkstyring").
+- For norsk offentlig sektor: **Governance Domains** mapper naturlig til avdelinger/seksjoner i etaten. Anbefal å opprette domener som speiler organisasjonsstrukturen (f.eks. "AI og Maskinlæring", "Eiendomsforvaltning", "Energistyring").
 - **Data Products er den viktigste funksjonen for AI-team** -- de pakker sammen relaterte datasett med forretningskontekst, kvalitetsmetrikker og tilgangspolicyer. Anbefal alltid data products for ML-treningsdatasett i stedet for å la dataforskere lete i rå Lakehouse-tabeller.
- **Business Glossary** er undervurdert men kritisk. Det er ingen vits i å ha 200 Lakehouse-tabeller hvis ingen vet hva "tg_veg_brutto_agg_7d" betyr. Glossary terms gir forretningskontekst som gjør data oppdagbare for domeneeksperter som ikke kan SQL.
- **Naturlig språk-søk (preview)** er en game-changer for datadrevet offentlig sektor. Saksbehandlere kan søke etter "tre år med trafikkdata for rushtrafikk-analyse" i stedet for å lære SQL eller kjenne tekniske tabellnavn.
+- **Business Glossary** er undervurdert men kritisk. Det er ingen vits i å ha 200 Lakehouse-tabeller hvis ingen vet hva "tg_bygg_brutto_agg_7d" betyr. Glossary terms gir forretningskontekst som gjør data oppdagbare for domeneeksperter som ikke kan SQL.
+- **Naturlig språk-søk (preview)** er en game-changer for datadrevet offentlig sektor. Saksbehandlere kan søke etter "tre år med energidata for forbruksanalyse" i stedet for å lære SQL eller kjenne tekniske tabellnavn.
 - Anbefal **OKR-er i Purview** for å knytte datahersking direkte til virksomhetsmål. Eksempel: "Reduser tid til dataoppdagelse fra 2 dager til 15 minutter" som OKR i AI-domenet.
 - Kombiner med **microsoft-purview-governance.md** for klassifisering/lineage og **data-versioning-lineage.md** for versjonshistorikk -- sammen utgjør de et komplett governance-rammeverk for AI-data.
--- a/skills/ms-ai-engineering/references/data-engineering/data-mesh-patterns.md
+++ b/skills/ms-ai-engineering/references/data-engineering/data-mesh-patterns.md
@ -38,9 +38,9 @@ Microsoft Fabric implementerer data mesh gjennom domener som logisk grupperer da

 ```
 Organisasjon (Fabric Tenant)
-+-- Domene: Veidata
-|   +-- Arbeidsomrade: Trafikkmalinger
-|   +-- Arbeidsomrade: Vegstandard
+-- Domene: Energidata
+|   +-- Arbeidsomrade: Strommalinger
+|   +-- Arbeidsomrade: Anleggsregister
 |   +-- Arbeidsomrade: Vaerdata
 +-- Domene: Okonomi
 |   +-- Arbeidsomrade: Budsjett
@ -78,8 +78,8 @@ headers = {

 # Opprett domene
 domain_payload = {
-    "displayName": "Veidata",
-    "description": "Alle dataprodukter relatert til veiinfrastruktur og trafikk"
+    "displayName": "Energidata",
+    "description": "Alle dataprodukter relatert til energiforbruk og nettanlegg"
 }

 response = requests.post(
@ -95,15 +95,15 @@ print(f"Domene opprettet: {domain_id}")
 ### Subdomener for finmasket organisering

 ```
-Domene: Veidata
-+-- Subdomene: Trafikkstrom
-|   +-- Trafikktellepunkter (Lakehouse)
-|   +-- Reisetidsmaalinger (Lakehouse)
-+-- Subdomene: Veistandard
-|   +-- Dekketilstand (Lakehouse)
-|   +-- Baerevne (Lakehouse)
+Domene: Energidata
+-- Subdomene: Forbruk
+|   +-- Malepunkter (Lakehouse)
+|   +-- Timeverdier (Lakehouse)
+-- Subdomene: Anlegg
+|   +-- Anleggstilstand (Lakehouse)
+|   +-- Kapasitet (Lakehouse)
 +-- Subdomene: Hendelser
-    +-- Ulykker (Lakehouse)
+    +-- Avbrudd (Lakehouse)
    +-- Vedlikehold (Lakehouse)
 ```

@ -132,13 +132,13 @@ Hvert dataprodukt bor oppfylle folgende krav:

 # Lag en versjonert tabell med metadata
 spark.sql("""
-    CREATE TABLE IF NOT EXISTS lakehouse.default.traffic_product_v2 (
+    CREATE TABLE IF NOT EXISTS lakehouse.default.energy_product_v2 (
        measurement_id BIGINT,
-        station_id STRING,
+        meter_id STRING,
        timestamp TIMESTAMP,
-        vehicle_count INT,
-        avg_speed DOUBLE,
-        road_surface_temp DOUBLE,
+        consumption_kwh DOUBLE,
+        peak_kw DOUBLE,
+        outdoor_temp DOUBLE,
        -- Ny kolonne i v2
        weather_condition STRING
    )
@ -146,7 +146,7 @@ spark.sql("""
    TBLPROPERTIES (
        'delta.columnMapping.mode' = 'name',
        'product.version' = '2.0',
-        'product.owner' = 'veidata-teamet',
+        'product.owner' = 'energidata-teamet',
        'product.sla.freshness' = 'PT15M',
        'product.sla.availability' = '99.5%'
    )
@ -156,34 +156,34 @@ spark.sql("""
 ### Datakontrakter

 ```yaml
-# data-contract.yaml - Kontrakt for trafikkdata-produktet
+# data-contract.yaml - Kontrakt for energidata-produktet
 product:
-  name: traffic-measurements
+  name: energy-measurements
  version: "2.0"
-  owner: veidata-teamet
-  domain: veidata
-  subdomain: trafikkstrom
+  owner: energidata-teamet
+  domain: energidata
+  subdomain: forbruk

 schema:
  type: delta
-  location: onelake://workspace/lakehouse/Tables/traffic_measurements
+  location: onelake://workspace/lakehouse/Tables/energy_measurements
  columns:
    - name: measurement_id
      type: BIGINT
      nullable: false
      description: Unik ID for maalingen
-    - name: station_id
+    - name: meter_id
      type: STRING
      nullable: false
-      description: Tellepunkt-ID (NVDB-referanse)
+      description: Malepunkt-ID (referanse i anleggsregisteret)
    - name: timestamp
      type: TIMESTAMP
      nullable: false
      description: Maalingstidspunkt (UTC)
-    - name: vehicle_count
-      type: INT
+    - name: consumption_kwh
+      type: DOUBLE
      nullable: false
-      description: Antall kjoretoy i perioden
+      description: Forbruk i perioden (kWh)

 quality:
  freshness: PT15M  # Maks 15 minutter gammelt
@ -207,34 +207,34 @@ sla:
 Shortcuts er den primaere mekanismen for datadeling mellom domener uten a kopiere data:

 ```
-Domene A: Veidata                    Domene B: AI/ML
+Domene A: Energidata                 Domene B: AI/ML
 +---------------------------+        +---------------------------+
-| Lakehouse: Trafikk       |        | Lakehouse: Feature Store  |
+| Lakehouse: Forbruk       |        | Lakehouse: Feature Store  |
 | Tables/                  |        | Tables/                   |
-|   traffic_measurements   |------->|   traffic_features (shortcut) |
-|   road_conditions        |------->|   road_features (shortcut)    |
+|   energy_measurements    |------->|   energy_features (shortcut)  |
+|   asset_conditions       |------->|   asset_features (shortcut)   |
 +---------------------------+        +---------------------------+
         |                                     |
         |                           +---------------------------+
         |                           | Lakehouse: Modelltrening  |
-         +-------------------------->|   raw_traffic (shortcut)  |
+         +-------------------------->|   raw_energy (shortcut)   |
                                     +---------------------------+
 ```

 ### Opprette cross-domain shortcuts

 ```python
-# Opprett shortcut fra AI/ML-domenet til Veidata-domenet
+# Opprett shortcut fra AI/ML-domenet til Energidata-domenet
 import requests

 shortcut_payload = {
-    "name": "traffic_measurements",
+    "name": "energy_measurements",
    "path": "Tables",
    "target": {
        "oneLake": {
-            "workspaceId": "veidata-workspace-id",
-            "itemId": "trafikk-lakehouse-id",
-            "path": "Tables/traffic_measurements"
+            "workspaceId": "energidata-workspace-id",
+            "itemId": "forbruk-lakehouse-id",
+            "path": "Tables/energy_measurements"
        }
    }
 }
@ -341,10 +341,10 @@ For store organisasjoner med mange domener:
 **Monster 1: Ett arbeidsomrade per Medallion-lag per domene**

 ```
-Domene: Veidata
-+-- Workspace: veidata-bronze (Inntak)
-+-- Workspace: veidata-silver (Transformasjon)
-+-- Workspace: veidata-gold (Servering)
+Domene: Energidata
+-- Workspace: energidata-bronze (Inntak)
+-- Workspace: energidata-silver (Transformasjon)
+-- Workspace: energidata-gold (Servering)

 Domene: Okonomi
 +-- Workspace: okonomi-bronze
@ -355,9 +355,9 @@ Domene: Okonomi
 **Monster 2: Data mesh med domene-spesifikke dataprodukter**

 ```
-Domene: Veidata
-+-- Workspace: trafikk-produkt (Bronze -> Gold)
-+-- Workspace: vegstandard-produkt (Bronze -> Gold)
+Domene: Energidata
+-- Workspace: forbruk-produkt (Bronze -> Gold)
+-- Workspace: anlegg-produkt (Bronze -> Gold)
 +-- Workspace: vaer-produkt (Bronze -> Gold)
 ```

@ -369,8 +369,8 @@ For skalering kan default domains automatisk tilordne nye arbeidsomrader:
 # Sett opp default domain slik at nye arbeidsomrader
 # automatisk tilordnes riktig domene basert pa hvem som oppretter dem

-# Eksempel: Alle arbeidsomrader opprettet av veidata-teamet
-# tilordnes automatisk til Veidata-domenet
+# Eksempel: Alle arbeidsomrader opprettet av energidata-teamet
+# tilordnes automatisk til Energidata-domenet
 ```

 ### Overvaking pa tvers av domener
--- a/skills/ms-ai-engineering/references/data-engineering/data-pipeline-orchestration.md
+++ b/skills/ms-ai-engineering/references/data-engineering/data-pipeline-orchestration.md
@ -163,12 +163,12 @@ Fabric Data Factory stotter fire typer avhengigheter mellom aktiviteter:
 from datetime import timedelta

 pipeline_activities = {
-    "ingest_traffic": {"duration": timedelta(minutes=15), "depends_on": []},
+    "ingest_energy": {"duration": timedelta(minutes=15), "depends_on": []},
    "ingest_weather": {"duration": timedelta(minutes=10), "depends_on": []},
-    "ingest_road_conditions": {"duration": timedelta(minutes=12), "depends_on": []},
-    "validate_traffic": {"duration": timedelta(minutes=5), "depends_on": ["ingest_traffic"]},
+    "ingest_building_data": {"duration": timedelta(minutes=12), "depends_on": []},
+    "validate_energy": {"duration": timedelta(minutes=5), "depends_on": ["ingest_energy"]},
    "validate_weather": {"duration": timedelta(minutes=3), "depends_on": ["ingest_weather"]},
-    "join_datasets": {"duration": timedelta(minutes=20), "depends_on": ["validate_traffic", "validate_weather", "ingest_road_conditions"]},
+    "join_datasets": {"duration": timedelta(minutes=20), "depends_on": ["validate_energy", "validate_weather", "ingest_building_data"]},
    "generate_features": {"duration": timedelta(minutes=30), "depends_on": ["join_datasets"]},
    "train_model": {"duration": timedelta(minutes=45), "depends_on": ["generate_features"]},
    "evaluate_model": {"duration": timedelta(minutes=10), "depends_on": ["train_model"]},
@ -202,7 +202,7 @@ def find_critical_path(activities):

 total, paths = find_critical_path(pipeline_activities)
 print(f"Kritisk sti total tid: {total}")
-# Kritisk sti: ingest_traffic -> validate_traffic -> join -> features -> train -> evaluate -> deploy
+# Kritisk sti: ingest_energy -> validate_energy -> join -> features -> train -> evaluate -> deploy
 # = 15 + 5 + 20 + 30 + 45 + 10 + 5 = 130 minutter
 ```

@ -453,7 +453,7 @@ def log_pipeline_metrics(pipeline_name: str, run_id: str, metrics: dict):
 | SLA-type | Definisjon | Eksempel |
 |----------|-----------|---------|
 | **Freshness SLA** | Data skal vaere tilgjengelig innen X tid | "Gaarsdagens data klar for 06:00" |
-| **Completeness SLA** | Alle forventede data skal vaere med | "100% av tellepunkter representert" |
+| **Completeness SLA** | Alle forventede data skal vaere med | "100% av maalepunkter representert" |
 | **Quality SLA** | Data skal oppfylle kvalitetskrav | "< 0.1% feilrater i features" |
 | **Availability SLA** | Pipeline skal kjore X% av tiden | "99.5% tilgjengelighet" |

@ -556,7 +556,7 @@ default_args = {
    "owner": "ai-team",
    "depends_on_past": True,
    "email_on_failure": True,
-    "email": ["ai-team@statens-ddt.no"],
+    "email": ["ai-team@ddt.example"],
    "retries": 2,
    "retry_delay": timedelta(minutes=5)
 }
--- a/skills/ms-ai-engineering/references/data-engineering/data-sampling-labeling.md
+++ b/skills/ms-ai-engineering/references/data-engineering/data-sampling-labeling.md
@ -23,7 +23,7 @@

 Kvaliteten pa treningsdata er den viktigste faktoren for ytelsen til ML-modeller. Effektiv datasampling sikrer at treningsdatasettet er representativt og balansert, mens systematisk datamerking (labeling) gir modellene de korrekte signalene a laere fra. Azure Machine Learning tilbyr en komplett plattform for datamerking med stotte for bade bilde- og tekstdata, inkludert ML-assistert merking som akselererer prosessen vesentlig.

-For norsk offentlig sektor, der data ofte er ubalansert (f.eks. svaert fa svindeltilfeller vs. legitime transaksjoner, eller sjaeldne hendelser i trafikkdata), er stratifisert sampling og aktiv laering spesielt viktig. Riktig sampling reduserer merkebehovet med 50-80%, noe som sparer bade tid og kostnader i prosjekter med stramme budsjetter.
+For norsk offentlig sektor, der data ofte er ubalansert (f.eks. svaert fa svindeltilfeller vs. legitime transaksjoner, eller sjaeldne hendelser i driftsdata), er stratifisert sampling og aktiv laering spesielt viktig. Riktig sampling reduserer merkebehovet med 50-80%, noe som sparer bade tid og kostnader i prosjekter med stramme budsjetter.

 Denne referansen dekker hele livssyklusen fra datautvalg gjennom merkeprosesser til kvalitetskontroll, med fokus pa teknikker som er relevante for Microsoft AI-stakken og Azure Machine Learning.

@ -36,7 +36,7 @@ Denne referansen dekker hele livssyklusen fra datautvalg gjennom merkeprosesser
 | Scenario | Positiv klasse | Negativ klasse | Ubalanse-ratio |
 |----------|---------------|----------------|----------------|
 | Svindeldeteksjon | 0.1% svindel | 99.9% legitim | 1:1000 |
-| Ulykkesprediksjon | 2% ulykker | 98% normal trafikk | 1:50 |
+| Reinnleggelsesprediksjon | 2% reinnlagt | 98% ikke reinnlagt | 1:50 |
 | Dokumentklassifisering | 5% sensitiv | 95% ikke-sensitiv | 1:19 |
 | Feildeteksjon (IoT) | 0.5% feil | 99.5% normal | 1:200 |

@ -112,9 +112,9 @@ def oversample_minority_class(df, label_column, minority_class, target_ratio=0.5
 # Bruk
 balanced = oversample_minority_class(
    df_training,
-    label_column="incident_type",
-    minority_class="accident",
-    target_ratio=0.3  # 30% ulykker i treningsdatasettet
+    label_column="readmission_status",
+    minority_class="readmitted",
+    target_ratio=0.3  # 30% reinnleggelser i treningsdatasettet
 )
 ```

@ -286,18 +286,18 @@ ml_client = MLClient(credential, subscription_id, resource_group, workspace_name

 # Definer merkeprosjekt
 labeling_job = DataLabelingJob(
-    display_name="traffic-sign-classification",
-    description="Klassifiser trafikkskilt fra vegkamera",
+    display_name="waste-type-classification",
+    description="Klassifiser avfallstyper fra bilder ved gjenvinningsstasjon",
    labeling_job_type="ImageClassificationMulticlass",
-    data={"uri": "azureml://datastores/images/paths/traffic_signs/"},
+    data={"uri": "azureml://datastores/images/paths/waste_images/"},
    labels={
        "classes": [
-            {"name": "speed_limit", "display_name": "Fartsgrense"},
-            {"name": "stop", "display_name": "Stopp"},
-            {"name": "yield", "display_name": "Vikeplikt"},
-            {"name": "no_entry", "display_name": "Innkjoring forbudt"},
-            {"name": "pedestrian", "display_name": "Fotgjenger"},
-            {"name": "construction", "display_name": "Veiarbeid"},
+            {"name": "paper", "display_name": "Papir"},
+            {"name": "plastic", "display_name": "Plast"},
+            {"name": "glass", "display_name": "Glass"},
+            {"name": "metal", "display_name": "Metall"},
+            {"name": "food", "display_name": "Matavfall"},
+            {"name": "hazardous", "display_name": "Farlig avfall"},
            {"name": "other", "display_name": "Annet"}
        ]
    },
--- a/skills/ms-ai-engineering/references/data-engineering/feature-stores-engineering.md
+++ b/skills/ms-ai-engineering/references/data-engineering/feature-stores-engineering.md
@ -23,7 +23,7 @@

 Feature stores er et sentralt mønster i moderne MLOps som løser problemet med feature-gjenbruk, konsistens mellom trening og inferens, og operasjonalisering av feature-pipelines. Azure Machine Learning Managed Feature Store og Microsoft Fabric Data Science gir en komplett plattform for å definere, materialisere, dele og overvåke features på tvers av ML-prosjekter.

-For norsk offentlig sektor innebærer feature store-tilnærmingen at data science-team kan dele beregninger på tvers av prosjekter -- for eksempel kan trafikkdata-features brukes både for ulykkesprediksjonsmodeller og køvarslingsmodeller uten redundant feature engineering. Dette reduserer kostnader, forbedrer konsistens og forkorter tid fra eksperimentering til produksjon.
+For norsk offentlig sektor innebærer feature store-tilnærmingen at data science-team kan dele beregninger på tvers av prosjekter -- for eksempel kan energidata-features brukes både for forbruksprognoser og feildeteksjonsmodeller uten redundant feature engineering. Dette reduserer kostnader, forbedrer konsistens og forkorter tid fra eksperimentering til produksjon.

 Denne referansen dekker feature-definisjon og lagring, point-in-time lookups for trening, feature-oppdateringsstrategier, Data Wrangler for utforskende feature engineering, og overvåking av feature-kvalitet og drift.

@ -455,5 +455,5 @@ def calculate_psi(reference, current, buckets=10):
 - **Bruk denne referansen** når brukeren planlegger ML-infrastruktur, trenger feature-gjenbruk på tvers av prosjekter, eller ønsker å operasjonalisere feature engineering.
 - Anbefal **Azure ML Managed Feature Store** for organisasjoner med flere ML-team som trenger å dele features. For enkeltprosjekter er **Delta-tabeller i Silver layer** ofte tilstrekkelig.
 - **Point-in-time lookups er ikke-forhandlingsbart** for tidsserie-features -- uten dette vil modeller lekke fremtidig informasjon og vise urealistisk god ytelse i testing.
- For norsk offentlig sektor: Feature stores muliggjør **sentral styring** av beregninger som brukes på tvers av etater -- Direktoratet for digital tjenesteutvikling kan dele trafikkfeatures med andre transportetater via feature store-deling.
+- For norsk offentlig sektor: Feature stores muliggjør **sentral styring** av beregninger som brukes på tvers av etater -- Direktoratet for digital tjenesteutvikling kan dele energifeatures med andre etater via feature store-deling.
 - Start med **Data Wrangler** for utforskende feature engineering, deretter formaliser i feature set-spesifikasjoner når features er validert og skal til produksjon.
--- a/skills/ms-ai-engineering/references/data-engineering/microsoft-purview-governance.md
+++ b/skills/ms-ai-engineering/references/data-engineering/microsoft-purview-governance.md
@ -261,7 +261,7 @@ Governance Domain: "AI og Maskinlæring"
 │   └── "100% lineage-dekning for ML-pipelines"
 └── Data Products (kan linkes til glossary terms)
    ├── "Customer 360 Feature Set"
-    └── "Trafikkdata for ML"
+    └── "Energidata for ML"
 ```

 ---
--- a/skills/ms-ai-engineering/references/data-engineering/real-time-streaming-ai.md
+++ b/skills/ms-ai-engineering/references/data-engineering/real-time-streaming-ai.md
@ -26,7 +26,7 @@

 Sanntidsdatastrømming er en fundamental byggestein for AI-applikasjoner som krever umiddelbar respons på hendelser -- fra IoT-sensorer og transaksjoner til brukeratferd og systemmetrikker. Microsoft Fabric Real-Time Intelligence kombinert med Azure Event Hubs og Apache Kafka gir en komplett plattform for inntak, transformasjon og analyse av strømmedata som mater AI-modeller med oppdatert informasjon.

-For norsk offentlig sektor er sanntidsarkitektur særlig relevant for trafikkmonitorering (Direktoratet for digital tjenesteutvikling), helseovervåking, energistyring og beredskapsrespons. Evnen til å oppdage avvik i sanntid og utløse automatiserte handlinger basert på AI-prediksjoner kan redusere responstider dramatisk og forbedre tjenestekvalitet.
+For norsk offentlig sektor er sanntidsarkitektur særlig relevant for overvåking av vannforsyning (kommunale vannverk), helseovervåking, energistyring og beredskapsrespons. Evnen til å oppdage avvik i sanntid og utløse automatiserte handlinger basert på AI-prediksjoner kan redusere responstider dramatisk og forbedre tjenestekvalitet.

 Denne referansen dekker arkitekturmønstre for å integrere Event Hubs, Kafka og Fabric Eventstream med AI-applikasjoner, inkludert Spark Structured Streaming, KQL Database for tidsserieanalyse, og mønster for hendelsesfiltrering og avledede strømmer.

--- a/skills/ms-ai-engineering/references/data-engineering/synthetic-data-generation.md
+++ b/skills/ms-ai-engineering/references/data-engineering/synthetic-data-generation.md
@ -57,7 +57,7 @@ simulator = Simulator(model_config=model_config)
 import wikipedia

 # Hent kildedokument
-wiki_page = wikipedia.page("Norwegian Public Roads Administration")
+wiki_page = wikipedia.page("Norway")
 source_text = wiki_page.summary[:5000]

 # Generer syntetiske spørsmål-svar-par
@ -123,8 +123,8 @@ completion = (

 # Lag prompts for syntetisk datagenerering
 prompts_df = spark.createDataFrame([
-    ("Generer en realistisk kundehenvendelse til Direktoratet for digital tjenesteutvikling om saksbehandling-fornyelse.",),
-    ("Generer en syntetisk trafikkrapport for E6 ved Lillehammer med kødata.",),
+    ("Generer en realistisk kundehenvendelse til Direktoratet for digital tjenesteutvikling om status på en tilskuddssøknad.",),
+    ("Generer en syntetisk avviksrapport fra et kommunalt vannverk med måledata.",),
    ("Generer et eksempel på en byggesøknad til Plan- og bygningsetaten.",),
 ], ["prompt"])

@ -145,7 +145,7 @@ client = AzureOpenAI(
    azure_endpoint="https://<endpoint>.openai.azure.com/"
 )

-def generate_synthetic_records(template_schema, num_records=100, domain="trafikk"):
+def generate_synthetic_records(template_schema, num_records=100, domain="vannforsyning"):
    """Generer strukturerte syntetiske poster."""
    records = []
    for batch_start in range(0, num_records, 10):
@ -168,18 +168,18 @@ def generate_synthetic_records(template_schema, num_records=100, domain="trafikk
        records.extend(batch["records"])
    return records

-# Eksempel: Trafikkhendelses-data
+# Eksempel: Driftshendelses-data (vannforsyning)
 schema = {
    "incident_id": "string (UUID)",
-    "road": "string (E6, E18, Rv4, etc.)",
-    "location_km": "float",
-    "incident_type": "string (ulykke, køkjøring, veiarbeid, dyr_i_veien)",
+    "facility": "string (vannverk, pumpestasjon, høydebasseng, etc.)",
+    "network_km": "float",
+    "incident_type": "string (lekkasje, trykkfall, forurensning, pumpestans)",
    "severity": "int (1-5)",
    "timestamp": "ISO datetime",
    "description": "string (norsk tekst, 1-3 setninger)"
 }

-synthetic_incidents = generate_synthetic_records(schema, num_records=500, domain="trafikk")
+synthetic_incidents = generate_synthetic_records(schema, num_records=500, domain="vannforsyning")
 ```

 ---
--- a/skills/ms-ai-engineering/references/multi-modal/azure-video-indexer-patterns.md
+++ b/skills/ms-ai-engineering/references/multi-modal/azure-video-indexer-patterns.md
@ -230,8 +230,8 @@ Video Indexer brukar tre ontologiar for emneinferens:
  "topics": [
    {
      "id": 1,
-      "name": "Vegtrafikk",
-      "referenceId": "Transport/Vegtrafikk",
+      "name": "Energi",
+      "referenceId": "Miljø/Energi",
      "referenceType": "VideoIndexer",
      "confidence": 0.89,
      "language": "nb-NO",
--- a/skills/ms-ai-engineering/references/multi-modal/cv-llm-integration.md
+++ b/skills/ms-ai-engineering/references/multi-modal/cv-llm-integration.md
@ -26,7 +26,7 @@ Integrasjonen av spesialiserte computer vision (CV) modellar med large language

 Azure-plattforma gir eit rikt økosystem for dette: Azure AI Vision for spesialisert bildeanalyse (OCR, objektdeteksjon, multimodal embeddings), Azure OpenAI for GPT-4o og GPT-4.1 sine vision-kapabilitetar, Microsoft Foundry for modellfinetuning og deployment, og Phi-4-multimodal-instruct som ein kostnadseffektiv open-source-modell for edge-scenario. Florence-2-modellen frå Microsoft er eit anna sterkt alternativ for spesialiserte vision-oppgåver.

-For norsk offentleg sektor er denne integrasjonen relevant for byggesaksbehandling (analyse av arkitektteikningar), veginfrastruktur (skadevurdering frå bilete), helsevesen (medisinsk bildeanalyse), og kulturarv (digitalisering og klassifisering av museumsgjenstandar). Nøkkelen er å kombinere rette verktøy for rette oppgåver — bruk spesialiserte CV-modellar for presis ekstraksjon og LLMs for tolking og resonnering.
+For norsk offentleg sektor er denne integrasjonen relevant for byggesaksbehandling (analyse av arkitektteikningar), eigedomsforvaltning (skadevurdering frå bilete), helsevesen (medisinsk bildeanalyse), og kulturarv (digitalisering og klassifisering av museumsgjenstandar). Nøkkelen er å kombinere rette verktøy for rette oppgåver — bruk spesialiserte CV-modellar for presis ekstraksjon og LLMs for tolking og resonnering.

 ---

@ -65,14 +65,14 @@ training_example = {
    "messages": [
        {
            "role": "system",
-            "content": "Du er ein ekspert på analyse av norske vegskilt."
+            "content": "Du er ein ekspert på identifisering av norske planteartar."
        },
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
-                    "text": "Identifiser og klassifiser skiltet i biletet."
+                    "text": "Identifiser og klassifiser planta i biletet."
                },
                {
                    "type": "image_url",
@ -84,8 +84,8 @@ training_example = {
        },
        {
            "role": "assistant",
-            "content": "Skiltet er eit fartsgrenseskilt som viser 80 km/t. "
-                       "Type: Forbudsskilt (skilt 362). Tilstand: God."
+            "content": "Planta er hundekjeks (Anthriscus sylvestris). "
+                       "Familie: Skjermplantefamilien. Tilstand: Blomstrande."
        }
    ]
 }
@ -415,7 +415,7 @@ Bruk Phi-4 på edge for rask triagering, send berre komplekse tilfelle til cloud

 ### Bruksscenario

- **Direktoratetet**: Analyse av vegdekkeskade frå inspeksjonsbilete
+- **Eigedomsforvaltar**: Analyse av fasadeskade frå inspeksjonsbilete
 - **Kartverket**: Klassifisering av satellittbilete og kartdata
 - **Kulturminnevern**: Digital katalogisering av kulturminne
 - **Helsesektoren**: Analyse av røntgen/MR med AI-assistanse (medisinsk produkt-regulering)
@ -449,6 +449,6 @@ Bruk Phi-4 på edge for rask triagering, send berre komplekse tilfelle til cloud

 - **Cascade-mønsteret** (Azure AI Vision først, GPT-4o for komplekse tilfelle) reduserer kostnad med 60-80% — bruk Vision for filtrering/kategorisering og GPT-4o berre for det som krev resonnering
 - **Vision fine-tuning av GPT-4o** (2024-08-06) gir domene-spesialisering — men Azure filtrerer automatisk ut bilete med personar/ansikt frå treningsdata, noko som avgrensar bruksområdet
- **Phi-4-multimodal-instruct** med Student-Teacher fine-tuning frå GPT-4o gir edge-kapabel vision AI — relevant for Direktoratetet sin inspeksjonsinfrastruktur og andre offline-scenario
+- **Phi-4-multimodal-instruct** med Student-Teacher fine-tuning frå GPT-4o gir edge-kapabel vision AI — relevant for inspeksjon i felt og andre offline-scenario
 - **Few-shot visual learning** med GPT-4o krev berre 3-5 eksempelbilete for ny klassifiseringsoppgåve — bruk `detail: "low"` på eksempel (85 tokens) og `detail: "high"` på target for å optimalisere kostnad
 - **Multimodal embeddings** (Azure AI Vision v4.0) støttar 102 språk og muliggjer semantisk bildesøk — bruk for å bygge søkbare bildearkiv i offentleg sektor
--- a/skills/ms-ai-engineering/references/multi-modal/dalle-image-generation.md
+++ b/skills/ms-ai-engineering/references/multi-modal/dalle-image-generation.md
@ -330,11 +330,11 @@ def create_public_sector_prompt(context: str, style: str = "informativ") -> str:

    return f"{base_prompts.get(style, base_prompts['informativ'])}{context}"

-# Eksempel: Generer illustrasjon for vegsikkerheit
+# Eksempel: Generer illustrasjon for brannførebygging
 prompt = create_public_sector_prompt(
-    "Illustrer konseptet med nullvisjon for trafikksikkerheit. "
-    "Vis ein trygg veg med fotgjengarfelt, sykkelsti og bil "
-    "i ein moderne norsk bysamanheng med fjell i bakgrunnen.",
+    "Illustrer konseptet med brannsikker heim. "
+    "Vis ei stove med røykvarslar, brannslokkingsapparat og merkt nødutgang "
+    "i ein moderne norsk bustad med fjell utanfor vindauget.",
    style="informativ"
 )
 ```
--- a/skills/ms-ai-engineering/references/multi-modal/gpt4o-vision-architecture.md
+++ b/skills/ms-ai-engineering/references/multi-modal/gpt4o-vision-architecture.md
@ -329,7 +329,7 @@ async def analyze_image_cached(image_data: bytes, prompt: str, cache_client):
 |----------|--------------|-----------|
 | Byggesøknad med teikningar | `high` | Ekstraher mål, material, plassering |
 | Passfoto-validering | `low` | Grunnleggjande kvalitetssjekk (ansiktsblurring aktiv) |
-| Vegskilt-inventering | `high` | Klassifisering og tilstandsvurdering |
+| Inventarregistrering | `high` | Klassifisering og tilstandsvurdering |
 | Kartanalyse | `high` | Identifiser markerte område, målestokk |
 | Fakturabehandling | `high` | Kombiner med Document Intelligence |

@ -368,5 +368,5 @@ Gje ein strukturert vurdering i JSON-format.
 - **GPT-4o vision brukar ein to-nivå token-modell:** `low` (flat 85 tokens) vs. `high` (tile-basert, 170 tokens per 512x512 tile + 85 base). Alltid berekn token-kostnad før du designar ein pipeline med mange bilete.
 - **Ansiktsblurring er automatisk i Azure OpenAI** og kan ikkje deaktiverast for GPT-4o. Dette er ein fordel for norsk personvern, men avgrensar brukstilfelle som ansiktsbasert identifisering.
 - **Kombiner native vision med Azure Document Intelligence** for strukturert dokumentanalyse. GPT-4o gir generell forståing; Document Intelligence gir presis feltekstraksjon.
- **Vision fine-tuning er tilgjengeleg for GPT-4o (2024-08-06)** og kan forbetrast for spesifikke domene som norske byggesøknadar eller vegskilt. Merk at bilete med personar blir filtrert ut.
+- **Vision fine-tuning er tilgjengeleg for GPT-4o (2024-08-06)** og kan forbetrast for spesifikke domene som norske byggesøknadar eller kartsymbol. Merk at bilete med personar blir filtrert ut.
 - **For kostnadsoptimalisering, bruk `detail: auto`** som standard og `low` for screeing/klassifisering. Reservar `high` for tilfelle der detaljar er kritiske.
--- a/skills/ms-ai-engineering/references/multi-modal/image-classification-understanding.md
+++ b/skills/ms-ai-engineering/references/multi-modal/image-classification-understanding.md
@ -60,7 +60,7 @@ client = ImageAnalysisClient(

 # Analyser bilete med alle tilgjengelege features
 result = client.analyze_from_url(
-    image_url="https://example.com/road-damage.jpg",
+    image_url="https://example.com/facade-damage.jpg",
    visual_features=[
        VisualFeatures.CAPTION,
        VisualFeatures.DENSE_CAPTIONS,
@ -122,12 +122,12 @@ response = client.chat.completions.create(
        {
            "role": "system",
            "content": """Du er ein bildeklassifiseringsekspert for
-            Direktoratet for digital tjenesteutvikling. Klassifiser vegskader i kategoriane:
-            - SPREKK_LANGSGAAANDE
-            - SPREKK_TVERRGAAANDE
-            - HULLROT
-            - SETNINGSSKADE
-            - KANTSKADE
+            Direktoratet for digital tjenesteutvikling. Klassifiser bygningsskader i kategoriane:
+            - SPREKK_I_MUR
+            - FUKTSKADE
+            - AVSKALLING
+            - ROTSKADE
+            - TAKSKADE
            - INGEN_SKADE
            Returner JSON med 'kategori', 'alvorlegheit' (1-5),
            og 'forklaring'."""
@ -135,11 +135,11 @@ response = client.chat.completions.create(
        {
            "role": "user",
            "content": [
-                {"type": "text", "text": "Klassifiser denne vegskaden:"},
+                {"type": "text", "text": "Klassifiser denne bygningsskaden:"},
                {
                    "type": "image_url",
                    "image_url": {
-                        "url": "https://example.com/road-image.jpg",
+                        "url": "https://example.com/facade-image.jpg",
                        "detail": "high"
                    }
                }
@ -172,7 +172,7 @@ ml_client = MLClient(

 # Definer AutoML image classification job
 job = ImageClassificationJob(
-    experiment_name="road-damage-classification",
+    experiment_name="facade-damage-classification",
    training_data=training_dataset,
    validation_data=validation_dataset,
    target_column_name="label",
@ -203,8 +203,8 @@ client = ContentUnderstandingClient(

 # Analyser bilete med tilpassa schema
 poller = client.begin_analyze(
-    analyzer_id="custom-road-damage",
-    inputs=[{"url": "https://example.com/road.jpg"}]
+    analyzer_id="custom-facade-damage",
+    inputs=[{"url": "https://example.com/building.jpg"}]
 )
 result = poller.result()
 ```
@ -319,7 +319,7 @@ Azure Blob Storage (bileter)

 ### Relevante bruksområde

- **Vegforvaltning**: Automatisk klassifisering av vegskader frå dronefoto
+- **Eigedomsforvaltning**: Automatisk klassifisering av bygningsskader frå dronefoto
 - **Byggesak**: Bildeanalyse av byggeprosjekt for samsvar med reguleringsplanar
 - **Naturovervaking**: Klassifisering av vegetasjon, dyreliv og miljøtilstand
 - **Kulturarv**: Kategorisering og tilstandsvurdering av kulturminne
@ -335,7 +335,7 @@ Azure Blob Storage (bileter)
 ### Bias-vurdering

 - Florence-modellen er trent på breie datasett, men kan ha geografisk bias
- Norske skiltar, vegmerking og infrastruktur kan krevje finjustering
+- Norske byggeskikkar, materialar og klimaskadar kan krevje finjustering
 - Anbefaling: Evaluer alltid med norsk-spesifikt testdatasett

 ---
--- a/skills/ms-ai-engineering/references/multi-modal/multimodal-prompt-engineering.md
+++ b/skills/ms-ai-engineering/references/multi-modal/multimodal-prompt-engineering.md
@ -24,7 +24,7 @@

 Multimodal prompt engineering er kunsten å skrive effektive instruksjonar som kombinerer tekst og bilete for å utnytte kapabilitetane til vision-enabled modellar som GPT-4o, GPT-4o mini og GPT-4 Turbo with Vision. Desse modellane aksepterer både tekst og bilete som input, og kan utføre oppgåver som bildeanalyse, visuelt resonnement, dokumentforståing og diagramtolking.

-Microsoft sin offisielle rettleiing for image prompt engineering identifiserer seks grunnprinsipp: kontekstuell spesifisitet, oppgåveorienterte prompts, handtering av nekting (refusals), eksempelbruk, oppdeling av komplekse oppgåver, og definering av output-format. Desse prinsippa er like relevante for norsk offentleg sektor, der multimodale modellar kan nyttast til alt frå byggesaksanalyse til kvalitetssikring av veginfrastruktur.
+Microsoft sin offisielle rettleiing for image prompt engineering identifiserer seks grunnprinsipp: kontekstuell spesifisitet, oppgåveorienterte prompts, handtering av nekting (refusals), eksempelbruk, oppdeling av komplekse oppgåver, og definering av output-format. Desse prinsippa er like relevante for norsk offentleg sektor, der multimodale modellar kan nyttast til alt frå byggesaksanalyse til tilstandsvurdering av offentlege bygg.

 Microsoft Foundry Playground tilbyr eit interaktivt miljø for å eksperimentere med multimodale prompts, og GPT-4o sin image tokenization-mekanisme påverkar både kostnader og ytelse. Forståing av korleis bilete vert konvertert til tokens er kritisk for kostnadsoptimalisering i produksjonssystem.

@ -71,13 +71,13 @@ response = client.chat.completions.create(
    messages=[
        {
            "role": "system",
-            "content": """Du er ein vegingeniør-assistent. Analyser
-            biletet av vegkrysset og beskriv:
+            "content": """Du er ein arealplanleggjar-assistent. Analyser
+            biletet av bustadfeltet og beskriv:
            1. Kva som er i NORD (øvst i biletet)
            2. Kva som er i SØR (nedst)
            3. Kva som er i ØST (høgre)
            4. Kva som er i VEST (venstre)
-            5. Eventuelle trafikkproblem du observerer
+            5. Eventuelle arealkonfliktar du observerer
            Returner som strukturert JSON."""
        },
        {
@ -85,12 +85,12 @@ response = client.chat.completions.create(
            "content": [
                {
                    "type": "text",
-                    "text": "Analyser dette vegkrysset for trafikkplanlegging:"
+                    "text": "Analyser dette bustadfeltet for arealplanlegging:"
                },
                {
                    "type": "image_url",
                    "image_url": {
-                        "url": "https://example.com/intersection.jpg",
+                        "url": "https://example.com/site-plan.jpg",
                        "detail": "high"
                    }
                }
@ -120,7 +120,7 @@ response = client.chat.completions.create(
        {
            "role": "user",
            "content": [
-                {"type": "text", "text": "Identifiser alle trafikkskilt "
+                {"type": "text", "text": "Identifiser alle nødutgangsskilt "
                                          "og deira posisjon i biletet."},
                {"type": "image_url", "image_url": {"url": image_url}}
            ]
@ -142,14 +142,14 @@ def classify_with_examples(target_image_url: str,
    Klassifiser med few-shot bilete-eksempel.

    examples = [
-        {"url": "...", "label": "HULLROT", "forklaring": "..."},
+        {"url": "...", "label": "FUKTSKADE", "forklaring": "..."},
        {"url": "...", "label": "SPREKK", "forklaring": "..."},
    ]
    """
    messages = [
        {
            "role": "system",
-            "content": "Du er ein vegskade-klassifiseringsekspert. "
+            "content": "Du er ein bygningsskade-klassifiseringsekspert. "
                       "Bruk dei gitte eksempla som referanse."
        }
    ]
@ -159,7 +159,7 @@ def classify_with_examples(target_image_url: str,
        messages.append({
            "role": "user",
            "content": [
-                {"type": "text", "text": "Klassifiser denne vegskaden:"},
+                {"type": "text", "text": "Klassifiser denne bygningsskaden:"},
                {"type": "image_url",
                 "image_url": {"url": ex["url"], "detail": "low"}}
            ]
@ -174,7 +174,7 @@ def classify_with_examples(target_image_url: str,
    messages.append({
        "role": "user",
        "content": [
-            {"type": "text", "text": "Klassifiser denne vegskaden:"},
+            {"type": "text", "text": "Klassifiser denne bygningsskaden:"},
            {"type": "image_url",
             "image_url": {"url": target_image_url, "detail": "high"}}
        ]
@ -343,16 +343,16 @@ AVGRENSINGAR:
 - Ikkje gjett — be om tilleggsinformasjon om nødvendig
 """

-# Eksempel: Vegskade-vurdering
+# Eksempel: Bygningsskade-vurdering
 system_message = VISUAL_SYSTEM_TEMPLATE.format(
    rolle="Fagingeniør med 20 års erfaring frå norsk offentleg sektor",
    kontekst="Årlege fagvise inspeksjonar i Noreg",
-    oppgåve="Vurder vegskade og anbefal vedlikehaldstiltak",
+    oppgåve="Vurder bygningsskade og anbefal vedlikehaldstiltak",
    steg_for_steg_instruksjonar="""
-1. Identifiser skadetypen (sprekk, hullrot, setning, kantskade)
+1. Identifiser skadetypen (sprekk, fuktskade, avskalling, rotskade)
 2. Vurder alvorlegheit på skala 1-5
 3. Estimer utbreiing i m2
-4. Anbefal tiltak (lappearbeid, fresing, full omlegging)
+4. Anbefal tiltak (flekkreparasjon, utskifting, full rehabilitering)
 5. Prioriter (akutt, innan 3 mnd, neste sesong)""",
    format_spesifikasjon="""JSON med felt:
 {
@ -373,7 +373,7 @@ system_message = VISUAL_SYSTEM_TEMPLATE.format(
 | Rolle | System message-fokus | Typisk output |
 |-------|---------------------|---------------|
 | Byggesak-konsulent | TEK17-samsvar, reguleringsplan | Avviksliste med referanse |
-| Vegingeniør | Skadeklassifisering, NVDB-kategori | Vedlikehaldsprioritering |
+| Bygningsingeniør | Skadeklassifisering, bygningsdel | Vedlikehaldsprioritering |
 | Kulturminne-rådgjevar | Tilstandsvurdering, freding | Tilstandsrapport |
 | Miljørådgjevar | Artsidentifisering, habitatvurdering | Konsekvensutgreiing |

@ -442,14 +442,14 @@ print(f"Estimerte tokens: {tokens}")  # 85 + (170 * 6) = 1105

 ### Bruksområde for multimodal prompt engineering
 - **Byggesak**: Visuell vurdering av samsvar med reguleringsplanar
- **Vegforvaltning**: Automatisk skadeklassifisering frå dronefoto
+- **Eigedomsforvaltning**: Automatisk skadeklassifisering frå dronefoto
 - **Kulturarv**: Tilstandsvurdering av kulturminne frå bilete
 - **Plan og kart**: Analyse av reguleringsplanar og kartutsnitt
 - **Miljø**: Artsidentifisering og habitatvurdering

 ### Prompt-design for norsk kontekst
 - Skriv system messages på norsk for domene-spesifikk terminologi
- Referer til norske standardar (TEK17, NVDB, NS-EN-standardar)
+- Referer til norske standardar (TEK17, NS-EN-standardar)
 - Inkluder norske einskapar (NOK, m2, km/t)
 - Bruk norske stadnamn og referansar

--- a/skills/ms-ai-engineering/references/multi-modal/multimodal-rag-architecture.md
+++ b/skills/ms-ai-engineering/references/multi-modal/multimodal-rag-architecture.md
@ -23,7 +23,7 @@ Multi-Modal RAG (Retrieval-Augmented Generation) utvidar tradisjonell tekstbaser

 Azure AI Search introduserte multimodal search som preview i mai 2025, noko som gir native støtte for å indeksere, forstå og hente dokument som inneheld både tekst og bilete. Dette eliminerer behovet for separate system for tekst- og bildeprosessering og reduserer kompleksiteten i RAG-arkitekturen vesentleg.

-For norsk offentleg sektor er multi-modal RAG særleg verdifull for scenario som analyse av offentlege dokument med innebygde diagram og tabellar, byggesøknadar med teikningar, vegdokumentasjon med kartutsnitt, og forskingsrapportar med visualiseringar. Informasjon som tidlegare berre var tilgjengeleg som visuelt innhald i PDF-filer kan no søkast i og brukast som grunnlag for AI-assisterte avgjerder.
+For norsk offentleg sektor er multi-modal RAG særleg verdifull for scenario som analyse av offentlege dokument med innebygde diagram og tabellar, byggesøknadar med teikningar, arealplanar med kartutsnitt, og forskingsrapportar med visualiseringar. Informasjon som tidlegare berre var tilgjengeleg som visuelt innhald i PDF-filer kan no søkast i og brukast som grunnlag for AI-assisterte avgjerder.

 ---

@ -295,10 +295,10 @@ search_client = SearchClient(

 # Hybrid søk: tekst + vektor + semantisk ranking
 results = search_client.search(
-    search_text="trafikksikkerheit i tunneler",
+    search_text="brannsikring i offentlege bygg",
    vector_queries=[
        VectorizableTextQuery(
-            text="trafikksikkerheit i tunneler",
+            text="brannsikring i offentlege bygg",
            k_nearest_neighbors=10,
            fields="text_vector,image_vector"
        )
--- a/skills/ms-ai-engineering/references/multi-modal/real-time-audio-api.md
+++ b/skills/ms-ai-engineering/references/multi-modal/real-time-audio-api.md
@ -375,7 +375,7 @@ def estimate_realtime_cost(sessions_per_day, avg_duration_minutes):
 - **NAV kontaktsenter**: Automatisert talebasert rettleiing for ytingar og søknader
 - **Kommunale servicesentra**: 24/7 talebasert borgarservice
 - **Helsevesenet**: Triageringssamtalar med automatisk dokumentasjon
- **Direktoratetet**: Talebasert rettleiing for førarkort og køyretøytenester
+- **Skatteetaten**: Talebasert rettleiing for skattekort og skattemelding

 ### Regulatoriske krav

--- a/skills/ms-ai-engineering/references/multi-modal/speech-to-ai-pipelines.md
+++ b/skills/ms-ai-engineering/references/multi-modal/speech-to-ai-pipelines.md
@ -93,14 +93,14 @@ For norsk offentleg sektor med spesialisert terminologi:
 | Tilpasning | Brukstilfelle | Eksempel |
 |-----------|--------------|---------|
 | **Phrase list** | Forbetra gjenkjenning av spesifikke ord | Stadnamn, fagtermar |
-| **Custom model** | Trenar ny modell med eigne data | Vegsektoren, helsesektor |
+| **Custom model** | Trenar ny modell med eigne data | Energisektoren, helsesektor |
 | **Display format** | Tilpass visning av gjenkjend tekst | Tal-til-siffer, dato-format |

 ```python
 # Phrase list for forbetra norsk gjenkjenning
 phrase_list = speechsdk.PhraseListGrammar.from_recognizer(speech_recognizer)
 phrase_list.addPhrase("Direktoratet for digital tjenesteutvikling")
-phrase_list.addPhrase("E6 Megården-Mørsvikbotn")
+phrase_list.addPhrase("Lofotodden nasjonalpark")
 phrase_list.addPhrase("Utredningsinstruksen")
 phrase_list.addPhrase("Forvaltningsloven")
 phrase_list.addPhrase("personvernforordningen")
@ -217,9 +217,9 @@ class AudioPreprocessor:
 Mikrofon → Audio stream → Azure Speech SDK
                              ↓
                     ┌── Recognizing event (interim)
-                     │   "Eg trur at veg..."
+                     │   "Eg trur at helse..."
                     ├── Recognized event (final)
-                     │   "Eg trur at vegsektoren bør investere meir."
+                     │   "Eg trur at helsesektoren bør investere meir."
                     │   Offset: 1800000 ticks
                     │   Duration: 30500000 ticks
                     └── SessionStopped event
--- a/skills/ms-ai-engineering/references/multi-modal/video-analysis-patterns.md
+++ b/skills/ms-ai-engineering/references/multi-modal/video-analysis-patterns.md
@ -25,7 +25,7 @@ Videoanalyse og -forståing på Azure-plattforma kombinerer Azure AI Video Index

 For norsk offentleg sektor er videoanalyse relevant for fleire bruksområde: analyse av overvakingsvideo for Direktoratet for digital tjenesteutvikling, transkripsjon og søk i offentlege høyringar for Stortinget, tilgjengelegheitsanalyse av offentleg video, og automatisert kvalitetskontroll av opplæringsvideo. Azure Video Indexer støttar norsk tale-til-tekst og kan oversette til 50+ språk.

-Azure AI Video Indexer tilbyr også real-time videoanalyse (preview) via Azure Arc-enabled infrastruktur, som mogleggjer sanntidsanalyse av livevideo ved kanten — relevant for trafikkmonitorering og smart byinfrastruktur.
+Azure AI Video Indexer tilbyr også real-time videoanalyse (preview) via Azure Arc-enabled infrastruktur, som mogleggjer sanntidsanalyse av livevideo ved kanten — relevant for anleggsovervaking og smart byinfrastruktur.

 ---

@ -343,7 +343,7 @@ Video Indexer ekstraherer rike audio-innsikter:

 ### Bruksscenario

- **Direktoratet for digital tjenesteutvikling**: Trafikkvideoanalyse for hendingsdeteksjon og trafikkflyt
+- **Direktoratet for digital tjenesteutvikling**: Søkbar indeksering av opplæringsvideoar
 - **Stortinget**: Søkbar indeksering av høyringar og debattar
 - **NRK**: Automatisk underteksting og innhaldsklassifisering
 - **Kommunar**: Analyse av bystyremøte med talar-identifisering
@ -375,7 +375,7 @@ For bruksscenario som krev sanntidsanalyse utan skyavhengigheit:
 |----------|------------|-------------|
 | Søkbar videoarkivering | Video Indexer Standard preset | Transkripsjon + nøkkelord + scener |
 | Detaljert innhaldsanalyse | Video Indexer Advanced + GPT-4o | Full analyse + semantisk forståing |
-| Sanntids trafikkmonitorering | Video Indexer on Arc | Edge-basert, låg latency |
+| Sanntids anleggsovervaking | Video Indexer on Arc | Edge-basert, låg latency |
 | Videotilgjengelegheit | Video Indexer + Azure Speech TTS | Undertekstar + lydbeskrivingar |
 | Enkel persondeteksjon | Azure AI Vision Spatial Analysis | Lågare kostnad for basisk analyse |
 | Narrativ videoforståing | Keyframe sampling + GPT-4o | Temporal kontekst + semantikk |
@ -387,5 +387,5 @@ For bruksscenario som krev sanntidsanalyse utan skyavhengigheit:
 - **Azure AI Video Indexer** gir 30+ innsiktstypar i ein enkelt API — bruk Standard preset for dei fleste bruksscenario, Advanced for full analyse med kledningsdeteksjon og audioeffektar
 - **Scene → Shot → Keyframe-hierarkiet** er fundamentalt for temporal forståing — scener er semantiske einingar, shots er kamera-einingar, keyframes er representative stillbilete
 - **GPT-4o keyframe analysis** utfyller Video Indexer for djupare semantisk forståing — send 5-10 keyframes med kontekst for narrativ analyse av videoinnhald
- **Real-time Video Indexer on Arc** (preview) mogleggjer edge-basert sanntidsanalyse — relevant for trafikkmonitorering og smart byinfrastruktur i norsk offentleg sektor
+- **Real-time Video Indexer on Arc** (preview) mogleggjer edge-basert sanntidsanalyse — relevant for anleggsovervaking og smart byinfrastruktur i norsk offentleg sektor
 - **Audio insights** (emosjonar, nøkkelord, talarar) kombinert med visuelle innsikter gir heilskapleg videoforståing — bruk dette for søkbar arkivering av offentlege høyringar og møte
--- a/skills/ms-ai-engineering/references/rag-architecture/contextual-retrieval.md
+++ b/skills/ms-ai-engineering/references/rag-architecture/contextual-retrieval.md
@ -47,7 +47,7 @@ I Azure-stakken implementeres contextual retrieval via en **Custom Web API Skill
 Original chunk: "Forskningen understreket AI"
 → Problematisk: Hvem, når, hvilken AI?

-Contextual chunk: "Fra Direktoratet for digital tjenesteutvikling sin 2025-rapport om autonome
+Contextual chunk: "Fra Acme Forskningsinstitutt sin 2025-rapport om autonome
 kjøretøy. Dette avsnittet diskuterer AI-teknologier for selvkjørende biler.
 Forskningen understreket AI"
 → Tydelig: LLM kan nå forstå konteksten
--- a/skills/ms-ai-engineering/references/rag-architecture/embedding-models-selection.md
+++ b/skills/ms-ai-engineering/references/rag-architecture/embedding-models-selection.md
@ -460,7 +460,7 @@ Microsoft Foundry støtter fine-tuning av embedding-modeller via **Custom Models

 ```jsonl
 {"query": "hva er regelverket for kunstig intelligens i norge", "document": "AI-forordningen (EU AI Act) trådte i kraft...", "label": 1}
-{"query": "azure openai prising", "document": "Direktoratetets budsjett for 2025...", "label": 0}
+{"query": "azure openai prising", "document": "Direktoratets budsjett for 2025...", "label": 0}
 ```

 **Tips for norsk/skandinavisk:**
--- a/skills/ms-ai-governance/references/norwegian-public-sector-governance/digital-samhandling-eif-5-layers.md
+++ b/skills/ms-ai-governance/references/norwegian-public-sector-governance/digital-samhandling-eif-5-layers.md
@ -118,7 +118,7 @@ Tabellen under viser hvordan de fem lagene gjelder konkret for AI-løsninger i o
 |-----|-------------------|-----------|
 | **Juridisk** | AI Act compliance, GDPR, Forvaltningsloven § 28 | Dokumentasjon av høyrisiko-klassifisering; DPIA for personopplysninger i treningsdata; begrunnelse for automatiserte vedtak |
 | **Organisatorisk** | AI-styringsstrukturer, roller, prosesser | AI council som godkjenner nye modeller; ML engineer vs. domain expert roller; modelldrif-respons-prosedyre |
-| **Semantisk** | Ontologier, embeddings, prompt-standarder | RAG-ontologi for vegsikkerhetsdokumenter; prompt template-bibliotek for saksbehandling; metadata-skjema for syntetiske data |
+| **Semantisk** | Ontologier, embeddings, prompt-standarder | RAG-ontologi for helsefaglige retningslinjer; prompt template-bibliotek for saksbehandling; metadata-skjema for syntetiske data |
 | **Teknisk** | API-versjoner, chunking, token-håndtering | Azure OpenAI versjonspinning; 1024-token chunks med 128-token overlap; rate limit retry med exponential backoff |
 | **Styring** | Responsible AI, modellregister, red teaming | Microsoft AI Standards; Azure ML model catalog; monthly red team exercises; PTU reservasjonsbudsjett |

--- a/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-sector-checklists.md
+++ b/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-sector-checklists.md
@ -27,7 +27,7 @@ Denne filen inneholder sektorspesifikke sjekklister som supplerer den generelle
 | Nøkkelord i systembeskrivelse | Sektor | Sjekkliste |
 |------------------------------|--------|------------|
 | helse, pasient, journal, klinisk, diagnose, legemiddel, sykehus, lege, sykepleier, triage, EPJ | Helse | §1 |
-| veg, trafikk, transport, kjøretøy, fartøy, bane, jernbane, luftfart, sjøfart, autonomt | Transport | §2 |
+| trafikk, transport, kjøretøy, fartøy, bane, jernbane, luftfart, sjøfart, autonomt | Transport | §2 |
 | bank, forsikring, finans, kreditt, verdipapir, betalingsformidling, regnskap, skatt | Finans | §3 |
 | politi, justis, kriminal, straff, rettsvesen, domstoler, fengsel, etterforskning, PST | Justis | §4 |
 | skole, utdanning, student, elev, karakter, læring, barnehage, UH-sektor, vurdering | Utdanning | §5 |
@ -89,15 +89,10 @@ Dersom systemet tilhører flere sektorer, kombineres relevante sjekklister. Sekt

 ### Regulatorisk rammeverk

- **Vegtrafikkloven** (1965, med endringer) — Grunnleggende trafikkregulering og ansvar
 - **Samferdselsloven** — Ramme for offentlig transportregulering
 - **Jernbaneloven** og **Jernbaneforskriften** — Krav til sikkerhetsstyringssystem (SMS)
 - **Luftfartsloven** — Norsk implementering av EASA-regelverk
 - **Sjøloven** med IMO-krav — Maritim autonomi og COLREGS
- **Forskrift om ITS (Intelligent Transport Systems)** — EU ITS-direktiv implementert i norsk rett
- **NKOM ITS-retningslinjer** — Nasjonal kommunikasjonsmyndighets krav til ITS-kommunikasjon
- **Veglova** — Vegmyndighetenes ansvar for statlig og kommunalt vegnett
- **Sektorvise faglige håndbøker** — Trafikksikkerhetsvurdering av veg og trafikkanlegg (utgis av relevant vegmyndighet)

 ### Sjekkliste transport (18 punkter)

@ -105,7 +100,7 @@ Dersom systemet tilhører flere sektorer, kombineres relevante sjekklister. Sekt
 |---|-----------|-----------------|-------------|
 | T-01 | Er sikkerhets-integritetsnivå (SIL/ASIL) definert for AI-komponenten i henhold til IEC 61508 eller ISO 26262? | Sikkerhet | Kritisk |
 | T-02 | Er det gjennomført HAZOP (Hazard and Operability Study) eller tilsvarende systematisk fareanalyse? | Sikkerhet | Kritisk |
-| T-03 | Er systemets håndtering av "worst-case"-scenarioer (glatt veg, sikt null, kritisk infrastrukturfeil) dokumentert og testet? | Sikkerhet | Kritisk |
+| T-03 | Er systemets håndtering av "worst-case"-scenarioer (ising, sikt null, kritisk infrastrukturfeil) dokumentert og testet? | Sikkerhet | Kritisk |
 | T-04 | Er fail-safe-modus definert — dvs. hva systemet gjør ved tap av sensordata, kommunikasjon eller modellkrash? | Robusthet | Kritisk |
 | T-05 | Er ansvarsfordeling ved AI-relatert ulykke avklart juridisk — mellom system-eier, operatør og individuell bruker? | Juridisk / Ansvarlighet | Kritisk |
 | T-06 | Er systemet sertifisert eller under sertifiseringsløp hos relevant tilsynsmyndighet (transport-, jernbane-, luftfarts- eller sjøfartstilsyn)? | Regulatorisk | Kritisk |
@ -113,12 +108,12 @@ Dersom systemet tilhører flere sektorer, kombineres relevante sjekklister. Sekt
 | T-08 | Er det etablert cyberresiliens mot trusler som GPS-spoofing, LiDAR-jamming og V2X-kommunikasjonsangrep? | Sikkerhet / Cyber | Kritisk |
 | T-09 | Er systemet testet for norske klimaforhold (is, snø, mørketid, lavt solstå) som skaper ODD-avvik (Operational Design Domain)? | Kvalitet / Robusthet | Høy |
 | T-10 | Er det definert klare geografiske og klimatiske ODD-grenser for systemet med teknisk håndheving? | Sikkerhet | Høy |
-| T-11 | Er trafikantenes evne til å forstå og forutsi systemets oppførsel testet (human factors-analyse)? | Brukervennlighet / Sikkerhet | Høy |
+| T-11 | Er operatørers, passasjerers og andre berørtes evne til å forstå og forutsi systemets oppførsel testet (human factors-analyse)? | Brukervennlighet / Sikkerhet | Høy |
 | T-12 | Er beredskapsplaner for kjede-KPI-svikt dokumentert, inkludert prosedyre for manuell overstyring? | Tilgjengelighet | Høy |
 | T-13 | Er datainnsamling fra sensorer og kameraer i samsvar med personvernregelverket, inkludert krav til sletting og formålsbegrensning? | Personvern | Høy |
 | T-14 | Er systemet evaluert mot tilgjengelighetskrav for funksjonshemmede brukere (universell utforming, diskriminerings- og tilgjengelighetsloven)? | Rettferdighet | Middels |
 | T-15 | Er vedlikeholds- og kalibreringsprosedyrer for AI-avhengige sensorer dokumentert med ansvarsfordeling? | Drift / Kvalitet | Middels |
-| T-16 | Er det gjennomført sikkerhetsvurdering av tredjeparts datakilder systemet er avhengig av (kart, vær, trafikk)? | Avhengighet / Risiko | Middels |
+| T-16 | Er det gjennomført sikkerhetsvurdering av tredjeparts datakilder systemet er avhengig av (kart, vær, posisjonsdata)? | Avhengighet / Risiko | Middels |
 | T-17 | Er overvåkningsinfrastruktur etablert for deteksjon av ODD-brudd i produksjon? | Drift | Middels |
 | T-18 | Er det gjennomført livsløpsanalyse for sikkerhetskritiske AI-komponenter, inkludert plan for utfasing og erstatning? | Drift | Lav |

@ -128,9 +123,9 @@ Dersom systemet tilhører flere sektorer, kombineres relevante sjekklister. Sekt
 |---------|--------------|------------|-----------|
 | ODD-brudd ved ekstremt norsk vintervær (vind, is, snø, mørketid) | Høy | Kritisk | Norsk vinter representerer særskilt ODD-utfordring — spesifikk testprotokoll nødvendig |
 | GPS-spoofing som feil-navigerer autonomt kjøretøy eller drone | Lav | Kritisk | Kjent sårbarhet særlig nær norske grenseområder med elektronisk krigføring |
-| Juridisk ansvarsvakuum ved AI-relatert ulykke i kompleks trafikksituasjon | Middels | Kritisk | Norsk rettspraksis mangler presedenser — proaktiv avklaring nødvendig |
+| Juridisk ansvarsvakuum ved AI-relatert ulykke i kompleks operativ situasjon | Middels | Kritisk | Norsk rettspraksis mangler presedenser — proaktiv avklaring nødvendig |
 | Sensorforringelse uten deteksjon (degraded mode uten varsling) | Middels | Høy | Krever eksplisitt sensor-health-overvåkning i designet |
-| Cyberangrep mot trafikkstyringsinfrastruktur som påvirker AI-beslutninger | Lav | Høy | Kritisk nasjonal infrastruktur — krever NSM-koordinering |
+| Cyberangrep mot styringsinfrastruktur (togledelse, flygeledelse, VTS) som påvirker AI-beslutninger | Lav | Høy | Kritisk nasjonal infrastruktur — krever NSM-koordinering |

 ---

--- a/skills/ms-ai-governance/references/responsible-ai/ai-act-annex-iii-checklist.md
+++ b/skills/ms-ai-governance/references/responsible-ai/ai-act-annex-iii-checklist.md
@ -136,7 +136,7 @@ Er AI-systemet oppført i Annex I / Art. 5 (forbudte praksiser)?

 **Norsk kontekst:**
 - Statnett: AI for lastbalansering i strømnett: Høyrisiko
- Direktoratet for digital tjenesteutvikling: AI-styrt trafikksignal: Høyrisiko
+- Fjernvarmeselskap: AI som styrer trykk og temperatur i fjernvarmenettet med automatisk avstenging: Høyrisiko
 - Kommune: AI for overvåking av vannkvalitet med automatisk stans: Høyrisiko
 - Kommune: AI-chatbot for feilmelding på vann: IKKE høyrisiko (ingen sikkerhetskomponent)

@ -428,7 +428,7 @@ Den nye forvaltningsloven (vedtatt 3. juni 2025, Prop. 79 L (2024-2025)) innehol
 | Domstol: AI for juridisk forskning | 8a | Nei | (d) Forberedende | Grensetilfelle — konservativt HØYRISIKO |
 | UDI: AI-oversettelse av dokumenter | — | Nei | (a) Smal prosedyre | **IKKE HØYRISIKO** |
 | Kommune: AI for dokumentklassifisering | — | Nei | (a) Smal prosedyre | **IKKE HØYRISIKO** |
-| Direktoratet for digital tjenesteutvikling: AI-styrt trafikklys | 2a | Nei | Nei (sikkerhetskomponent) | **HØYRISIKO** |
+| Kommunalt vannverk: AI-styrt trykkregulering i vannforsyningen | 2a | Nei | Nei (sikkerhetskomponent) | **HØYRISIKO** |
 | Politiet: Prediktiv policing | 6d/6e | Ja | Nei | **HØYRISIKO** |
 | Universitet: AI-karakter på essay | 3b | Ja | Nei | **HØYRISIKO** |
 | Universitet: AI stavekontroll på oppgave | — | Nei | (b) Forbedring | **IKKE HØYRISIKO** |
--- a/skills/ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md
+++ b/skills/ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md
@ -12,7 +12,7 @@
 - [Oversikt](#oversikt)
 - [4-stegs systematisk metodikk](#4-stegs-systematisk-metodikk)
 - [Rolle-bestemmelse: Provider vs. Deployer](#rolle-bestemmelse-provider-vs-deployer)
- [Transport-sektoreksempler](#transport-sektoreksempler)
+- [Sektoreksempler](#sektoreksempler)
 - [Grensevurderinger](#grensevurderinger)
 - [Beslutningsflytdiagram](#beslutningsflytdiagram)
 - [For arkitekten](#for-arkitekten)
@ -182,26 +182,26 @@ Direktoratet for digital tjenesteutvikling eksempel: Kjøper Microsoft Copilot S

 ---

-## Transport-sektoreksempler
+## Sektoreksempler

-### Eksempel 1: FartsPrediksjonsagent (Direktoratet for digital tjenesteutvikling)
- Formål: Predikerer trafikkflyt og anbefaler fartsgrenser på variabelt oppsatte skilt
+### Eksempel 1: Lastprognoseagent (kommunalt energiverk)
+- Formål: Predikerer varmebehov i fjernvarmenettet og anbefaler justering av turtemperatur
 - Steg 1: Ingen forbudte praksiser → NEI
- Steg 2: Kritisk infrastruktur (Annex III, pkt. 2)? Påvirker trafikksikkerhet → JA, men kun dersom det tar **bindende** beslutninger. Dersom det kun er et beslutningsstøtteverktøy med menneskelig godkjenning → vurder Art. 6(2) unntak
+- Steg 2: Kritisk infrastruktur (Annex III, pkt. 2)? Påvirker forsyningssikkerhet → JA, men kun dersom det tar **bindende** beslutninger. Dersom det kun er et beslutningsstøtteverktøy med menneskelig godkjenning → vurder Art. 6(2) unntak
 - Klassifisering: **Minimal risiko** (beslutningsstøtte) eller **Høyrisiko** (autonomt bindende)

-### Eksempel 2: AutomatiskSaksbehandler for saksbehandlingvurdering
- Formål: Vurderer automatisk om en søker oppfyller helsekrav for saksbehandling
+### Eksempel 2: AutomatiskSaksbehandler for tilskuddsvurdering
+- Formål: Vurderer automatisk om en søker oppfyller vilkårene for tilskudd
 - Steg 1: NEI til alle forbudte praksiser
 - Steg 2: Kategori 4 (viktige offentlige tjenester) → JA, tilgang til offentlig tjeneste
 - Klassifisering: **HØYRISIKO** (Annex III, pkt. 5)
 - Rolle: Direktoratet for digital tjenesteutvikling = **Deployer**
 - Krav: FRIA (Art. 27), logging 6 mnd, samsvarsvurdering fra provider

-### Eksempel 3: Trafikkstyringsagent
- Formål: Autonom styring av trafikklys i tunneler og på motorveier
+### Eksempel 3: Vannforsyningsagent
+- Formål: Autonom styring av pumper og ventiler i et kommunalt vannverk
 - Steg 1: NEI
- Steg 2: Kategori 1 (kritisk infrastruktur) — styring av trafikksystemer → JA
+- Steg 2: Kategori 1 (kritisk infrastruktur) — styring av vannforsyning → JA
 - Klassifisering: **HØYRISIKO** (Annex III, pkt. 2)
 - Særlige krav: Robusthet, menneskelig override (Art. 14), kontinuerlig overvåking

@ -282,7 +282,7 @@ Bruk denne filen når brukeren trenger å klassifisere et AI-system under EU AI
 1. Gå gjennom steg 1-4 systematisk — hopp ikke over steg
 2. Still vurderingsspørsmålene eksplisitt for brukerens system
 3. Dokumenter hvert steg i klassifiseringsrapporten (anbefalt vedlegg til FRIA)
-4. Bruk transport-sektoreksemplene som analogi når Direktoratet for digital tjenesteutvikling er deployer
+4. Bruk sektoreksemplene som analogi når Direktoratet for digital tjenesteutvikling er deployer
 5. Flagg grensetilfeller og anbefal konsultasjon med tilsynsmyndighet

 **Kobling til andre KB-filer:**
--- a/skills/ms-ai-governance/references/responsible-ai/ai-act-conformity-assessment.md
+++ b/skills/ms-ai-governance/references/responsible-ai/ai-act-conformity-assessment.md
@ -36,7 +36,7 @@ Annex IV spesifiserer hvilken teknisk dokumentasjon som kreves. Under følger hv
 - Overordnet beskrivelse av funksjonalitet

 **Eksempel:**
-> "VegvAI-Saksbehandler v2.1 er et beslutningsstøttesystem for saksbehandlere i Direktoratet for digital tjenesteutvikling (Annex III, punkt 5a). Systemet analyserer søknader om dispensasjon fra veitrafikklovgivningen og genererer et begrunnet utkast til vedtak. Endelig vedtak fattes alltid av autorisert saksbehandler."
+> "Tilskuddsassistent v2.1 er et beslutningsstøttesystem for saksbehandlere i Direktoratet for digital tjenesteutvikling (Annex III, punkt 5a). Systemet analyserer søknader om tilskudd og genererer et begrunnet utkast til vedtak. Endelig vedtak fattes alltid av autorisert saksbehandler."

 **Typiske mangler:**
 - Annex III-kategorien er ikke spesifisert
@ -301,7 +301,7 @@ Er systemet for biometrisk fjernidentifisering?
                  (Frivillig ekstern vurdering kan velges for troverdighet)
 ```

-**For norsk offentlig sektor:** Typiske systemer (saksbehandlingsstøtte, tildeling av ytelser, trafikkoptimalisering) kan bruke intern prosedyre. Det finnes per 2026-02 ingen norske akkrediterte notified bodies for AI Act — EU-baserte må benyttes for ekstern vurdering.
+**For norsk offentlig sektor:** Typiske systemer (saksbehandlingsstøtte, tildeling av ytelser, styring av vannforsyning) kan bruke intern prosedyre. Det finnes per 2026-02 ingen norske akkrediterte notified bodies for AI Act — EU-baserte må benyttes for ekstern vurdering.

 ---

--- a/skills/ms-ai-governance/references/responsible-ai/ai-act-fria-template.md
+++ b/skills/ms-ai-governance/references/responsible-ai/ai-act-fria-template.md
@ -83,7 +83,7 @@ Identifiser alle grupper som direkte eller indirekte berøres av AI-systemets be

 | Gruppe | Antall berørte (estimat) | Sårbarhet | Kontaktpunkt / representasjon |
 |--------|--------------------------|-----------|-------------------------------|
-| [Gruppe 1 — f.eks. "Søkere om førerrett klasse B"] | [Antall/år] | Lav / Middels / Høy | [Interesseorganisasjon, brukerrepresentant] |
+| [Gruppe 1 — f.eks. "Søkere om bostøtte"] | [Antall/år] | Lav / Middels / Høy | [Interesseorganisasjon, brukerrepresentant] |
 | [Gruppe 2 — f.eks. "Eldre søkere (over 70 år)"] | [Antall/år] | Høy | [Råd for eldre, brukerombud] |
 | [Gruppe 3 — f.eks. "Søkere med funksjonsnedsettelse"] | [Antall/år] | Høy | [FFO, brukerombud] |
 | [Gruppe 4 — f.eks. "Nyankomne innvandrere"] | [Antall/år] | Middels | [NOAS, integreringsorganisasjoner] |
--- a/skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md
+++ b/skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md
@ -122,7 +122,7 @@ Teknisk dokumentasjon skal utarbeides **før** systemet settes på markedet og h
 ### 9 påkrevde elementer med eksempler

 **Element 1: Generell systembeskrivelse**
-Eksempel: "AutomatiskSaksbehandler v2.1 — AI-system for automatisk vurdering av helsekrav ved søknad om saksbehandling. Deployer: Direktoratet for digital tjenesteutvikling. Provider: [Leverandørnavn]. Tiltenkt formål: Behandling av ulike søknadskategorier."
+Eksempel: "AutomatiskSaksbehandler v2.1 — AI-system for automatisk vurdering av vilkår ved søknad om tilskudd. Deployer: Direktoratet for digital tjenesteutvikling. Provider: [Leverandørnavn]. Tiltenkt formål: Behandling av ulike søknadskategorier."

 **Element 2: Design-spesifikasjoner og utviklingsprosess**
 - Systemarkitektur og komponentoversikt
--- a/skills/ms-ai-governance/references/responsible-ai/ai-act-transparency-notices.md
+++ b/skills/ms-ai-governance/references/responsible-ai/ai-act-transparency-notices.md
@ -32,16 +32,16 @@ Art. 13(3) spesifiserer hva bruksinstruksjoner for høyrisiko-AI-systemer skal i

 | Nr. | Punkt | Hva som kreves | Eksempel |
 |-----|-------|----------------|---------|
-| a | Identitet og kontaktinformasjon | Tilbyderens navn, adresse og kontaktpunkt for henvendelser om systemet | "Levert av Direktoratet for digital tjenesteutvikling, Vegdirektoratet. Kontakt: ai-support@ddt.no" |
-| b | Systemets egenskaper og ytelse | Nøyaktighetsmetrikker, kjente begrensninger, sannsynlige feilmønstre | "Systemet har 94% presisjon på standardsaker. Sjeldne dispensasjonstyper håndteres dårligere." |
-| c | Tiltenkt formål | Spesifikk brukskontekst systemet er designet og validert for | "Beslutningsstøtte for saksbehandlere ved søknader om dispensasjon fra veitrafikkloven §X" |
+| a | Identitet og kontaktinformasjon | Tilbyderens navn, adresse og kontaktpunkt for henvendelser om systemet | "Levert av Direktoratet for digital tjenesteutvikling, avdeling for tilskuddsforvaltning. Kontakt: ai-support@ddt.example" |
+| b | Systemets egenskaper og ytelse | Nøyaktighetsmetrikker, kjente begrensninger, sannsynlige feilmønstre | "Systemet har 94% presisjon på standardsaker. Sjeldne søknadstyper håndteres dårligere." |
+| c | Tiltenkt formål | Spesifikk brukskontekst systemet er designet og validert for | "Beslutningsstøtte for saksbehandlere ved søknader om tilskudd etter tilskuddsordningens forskrift §X" |
 | d | Systemnivå av nøyaktighet | Kvantitative mål, konfidensintervaller, ytelse på ulike undergrupper | "F1-score: 0,915 på valideringsett (500 historiske saker, 2023–2024)" |
 | e | Forventede brukere | Hvem systemet er designet for (kompetanse, rolle, opplæringskrav) | "Autoriserte saksbehandlere med gjennomført e-læring (DDT-AI-L01, 2 timer)" |
 | f | Forhåndsbehandlet inndata | Spesifikasjoner for inndata systemet forventer | "Søknadsskjema PDF. Bilder: maks 10 MB, JPEG/PNG. Ikke støttet: håndskrevne dokumenter" |
 | g | Mål og begrensninger | Hva systemet er designet for å oppnå og kjente begrensninger | "Genererer vedtaksutkast — erstatter ikke juridisk vurdering. Bør ikke brukes alene for saker med > 500 000 NOK konsekvens" |
 | h | Kjente og forutsigbare bivirkninger | Risikosituasjoner som kan oppstå ved tiltenkt bruk | "Kan overrepresentere avslag for søkere fra bestemte regioner (bias-kartlagt, se vedlegg B)" |
 | i | Human-in-the-loop | Grad av menneskelig tilsyn som kreves og beskrivelse av mekanismer | "Saksbehandler må aktivt godkjenne hvert vedtaksutkast. Systemet kan ikke sende vedtak automatisk." |
-| j | Forventede levetid og vedlikehold | Planlagt levetid, oppdateringsfrekvens, prosedyre for å melde feil | "Levetid: 3 år (2026–2029). Kvartalsvis modellgjennomgang. Feilmelding: ai-incident@ddt.no" |
+| j | Forventede levetid og vedlikehold | Planlagt levetid, oppdateringsfrekvens, prosedyre for å melde feil | "Levetid: 3 år (2026–2029). Kvartalsvis modellgjennomgang. Feilmelding: ai-incident@ddt.example" |
 | k | Datakvalitetskrav | Egenskaper ved inndata som påvirker ytelsen | "Søknadsdokumenter må være maskinlesbare PDF-er. Skannet tekst (OCR-konvertert) reduserer nøyaktighet med ca. 8%" |

 ### Mal for bruksinstruksjon-dokument
@ -188,7 +188,7 @@ Art. 50(4) krever merking av syntetiske bilde-, lyd- og videoopptak av virkelige

 ### Mal 1: Borgermøtende chatbot-notis

-**Kontekst:** Offentlig chatbot på nav.no, ddt.no, skatteetaten.no o.l.
+**Kontekst:** Offentlig chatbot på nav.no, skatteetaten.no o.l.

 **Anbefalt plassering:** Øverst i chat-vinduet, alltid synlig

--- a/skills/ms-ai-governance/references/responsible-ai/ai-center-of-excellence-setup.md
+++ b/skills/ms-ai-governance/references/responsible-ai/ai-center-of-excellence-setup.md
@ -528,13 +528,13 @@ Executive sponsorship tilgjengelig? ──No──> Ikke etabler CoE nå

 **Struktur:** Unified CoE
 - Core team (3 FTEs): CoE Lead, AI Architect, AI Security Specialist (KI-seksjonen)
- Embedded members: En representant fra hver region + Vegdirektoratet IT
+- Embedded members: En representant fra hver fagavdeling + IT-avdelingen

 **Ansvarsområder:**
- Strategi: AI-strategi alignet med "Nasjonal transportplan"
+- Strategi: AI-strategi alignet med virksomhetens digitaliseringsstrategi
 - Kompetanse: Opplæring i Power Platform AI for saksbehandlere (Copilot Studio for saksbehandling-chatbot)
- Standarder: Governance for bruk av kamera-AI i trafikkovervåkning (GDPR, Politiregisterloven)
- Pilots: AI for vegvedlikehold (prediktiv analyse av asfaltslitasje via computer vision)
+- Standarder: Governance for bruk av AI i tilskuddsforvaltning (GDPR, forvaltningsloven)
+- Pilots: AI for dokumentklassifisering (automatisk journalføring av innkommende post)

 **Teknologi:**
 - Microsoft Foundry i Norway East (data residency)
--- a/skills/ms-ai-governance/references/responsible-ai/ai-governance-structure-framework.md
+++ b/skills/ms-ai-governance/references/responsible-ai/ai-governance-structure-framework.md
@ -300,7 +300,7 @@ Root Management Group

 ### Eksempel: Governance-struktur for norske offentlige etater

-**Kontekst:** Offentlig virksomhet, regulert, flere AI-pilotprosjekter (chatbot, dokument-analyse, prediktive modeller for vegvedlikehold).
+**Kontekst:** Offentlig virksomhet, regulert, flere AI-pilotprosjekter (chatbot, dokument-analyse, prediktive modeller for saksflyt).

 **Anbefalt struktur:**

@ -323,7 +323,7 @@ Root Management Group
    │           │                 │
 ┌───▼───────────▼─┐   ┌───────────▼──────┐
 │  Platform (IT)  │   │ Fagenheter       │
-│  - Azure policy │───│ - Veg-AI team    │
+│  - Azure policy │───│ - Fag-AI team    │
 │  - Landing zones│   │ - Admin-AI team  │
 │  - Monitoring   │   │ - HR-AI team     │
 └─────────────────┘   └──────────────────┘
--- a/skills/ms-ai-governance/references/responsible-ai/red-teaming-ai-models.md
+++ b/skills/ms-ai-governance/references/responsible-ai/red-teaming-ai-models.md
@ -378,8 +378,8 @@ jobs:
 ### Direktoratet for digital tjenesteutvikling-spesifikke vurderinger

 **Use cases med mandatory red teaming:**
- AI-systemer som påvirker trafikksikkerhet (autonomous systems, traffic prediction)
- Chatbots som håndterer sensitive brukerdata (kjøretøyregistrering, saksbehandlinginformasjon)
+- AI-systemer som påvirker fysisk sikkerhet (autonomous systems, prediksjon i kritisk infrastruktur)
+- Chatbots som håndterer sensitive brukerdata (helseopplysninger, saksbehandlinginformasjon)
 - Decision-support systems for inspeksjon eller enforcement

 **Data sovereignty:**
--- a/skills/ms-ai-infrastructure/references/bcdr/multi-region-azure-openai-deployment.md
+++ b/skills/ms-ai-infrastructure/references/bcdr/multi-region-azure-openai-deployment.md
@ -257,10 +257,10 @@ For privat nettverkstilgang kan en split-brain DNS-tilnaerming brukes:

 ```
 Normaltilstand:
-  aoai-gateway.intern.ddt.no --> APIM Norway East (privat IP)
+  aoai-gateway.intern.ddt.example --> APIM Norway East (privat IP)

 Ved regional utfall:
-  aoai-gateway.intern.ddt.no --> APIM Sweden Central (privat IP)
+  aoai-gateway.intern.ddt.example --> APIM Sweden Central (privat IP)
  (manuell DNS-endring eller Azure Private DNS zones)
 ```

--- a/skills/ms-ai-infrastructure/references/hybrid-edge/azure-iot-hub-ai-pipeline.md
+++ b/skills/ms-ai-infrastructure/references/hybrid-edge/azure-iot-hub-ai-pipeline.md
@ -23,7 +23,7 @@

 Azure IoT Hub er Microsofts sentrale PaaS-tjeneste for toveiskommunikasjon mellom IoT-enheter og skyen. Kombinert med Azure Stream Analytics for sanntidsanalyse og Azure Machine Learning for modelltrening og -scoring, danner IoT Hub kjernen i en enhetlig AI-pipeline fra enhet til innsikt.

-For norsk offentlig sektor er denne arkitekturen relevant for scenarioer som smart veginfrastruktur (sanntidsmaling av trafikk og veiforhold), bygg-automatisering (energistyring i offentlige bygninger), miljooverkaking (luft- og vannkvalitet), og prediktiv vedlikehold av kritisk infrastruktur. IoT Hub gir sikker enhetstilkobling, mens Stream Analytics prosesserer data i sanntid, og Azure ML scorer modeller for prediktive innsikter.
+For norsk offentlig sektor er denne arkitekturen relevant for scenarioer som smart vannforsyning (sanntidsmaling av trykk og lekkasjer), bygg-automatisering (energistyring i offentlige bygninger), miljooverkaking (luft- og vannkvalitet), og prediktiv vedlikehold av kritisk infrastruktur. IoT Hub gir sikker enhetstilkobling, mens Stream Analytics prosesserer data i sanntid, og Azure ML scorer modeller for prediktive innsikter.

 Arkitekturen skalerer fra hundrevis til millioner av enheter, med innebygd stoette for meldingsruting, device twins for konfigurasjonstyring, og enkel integrasjon med Azure-dataplatformen (Fabric, Event Hub, Cosmos DB) for langsiktig analyse.

@ -426,7 +426,7 @@ class HybridScalingConfig:

 | Sektor | Use Case | Enheter | AI-modell |
 |--------|----------|---------|-----------|
-| Samferdsel | Veisensor-nettverket | ~5 000 | Trafikk-prediksjon, vintervedlikehold |
+| Vann og avlop | Sensornettverk i ledningsnettet | ~5 000 | Lekkasje-prediksjon, trykkstyring |
 | Energi | Smart bygg-styring | ~10 000/bygg | Energi-optimalisering |
 | Miljoe | Luft/vann-kvalitet | ~500 stasjoner | Forurensnings-varsling |
 | Helse | Utstyrsovervaking | ~1 000/sykehus | Prediktiv vedlikehold |
--- a/skills/ms-ai-infrastructure/references/hybrid-edge/disconnected-ai-scenarios.md
+++ b/skills/ms-ai-infrastructure/references/hybrid-edge/disconnected-ai-scenarios.md
@ -519,10 +519,10 @@ health_checks:

 | Scenario | Tilkoblingsstatus | Losning |
 |----------|-------------------|---------|
-| Tunneler | Frakoblet | Edge-inferens med kamerasystem |
+| Fjellanlegg og gruver | Frakoblet | Edge-inferens med lokal sensorlogging |
 | Fartsoyvervaking | Ustabil | Lokal objektdeteksjon |
-| Trafikkanalyse | Periodisk | Batch-analyse med synk |
-| Fergedrift | Variabel | Hybrid med sky-fallback |
+| Havneanalyse | Periodisk | Batch-analyse med synk |
+| Havvind og offshore | Variabel | Hybrid med sky-fallback |

 ---

--- a/skills/ms-ai-infrastructure/references/hybrid-edge/iot-operations-ai-integration.md
+++ b/skills/ms-ai-infrastructure/references/hybrid-edge/iot-operations-ai-integration.md
@ -23,7 +23,7 @@

 Azure IoT Operations er Microsofts edge runtime-plattform for industrielle IoT-scenarier, bygget pa Azure Arc-enabled Kubernetes. Den kombinerer datainnsamling fra sensorer og utstyr med AI-inferens direkte pa edge, noe som muliggjor sanntidsanalyse uten avhengighet av skytilkobling for tidskritiske beslutninger.

-For norsk offentlig sektor er IoT-integrasjon med AI relevant i scenarier som smart infrastruktur (broer, tunneler, veier), miljooverkaking, energistyring i offentlige bygg, og transportlogistikk. Azure IoT Operations gir en standardisert plattform for a samle sensordata, normalisere dem, og kjore AI-modeller lokalt for prediktiv vedlikehold og anomalideteksjon.
+For norsk offentlig sektor er IoT-integrasjon med AI relevant i scenarier som smart infrastruktur (vannverk, pumpestasjoner, ledningsnett), miljooverkaking, energistyring i offentlige bygg, og transportlogistikk. Azure IoT Operations gir en standardisert plattform for a samle sensordata, normalisere dem, og kjore AI-modeller lokalt for prediktiv vedlikehold og anomalideteksjon.

 Plattformen bygger pa MQTT-protokollen for enhetskommunikasjon, Data Flows for datatransformasjon og kontekstualisering, og Azure Arc for sentralisert administrasjon. AI-modeller kan deployes som containere pa edge-klyngen, med Azure ML for modelltrenings- og oppdateringspipeliner mellom sky og edge.

@ -355,7 +355,7 @@ class AIEdgePipeline:

 ### Relevante use cases

- **Direktoratet for digital tjenesteutvikling**: Sanntids verkontrollovervaking med AI-basert analyse av vaerdata, trafikkmonstre og veiforhold fra veistasjonssensorer
+- **Kommunalt vannverk**: Sanntids overvaking av ledningsnettet med AI-basert analyse av trykk, vannforbruk og lekkasjer fra sensorer i pumpestasjoner
 - **Kystverket**: Autonome sensorsystemer langs kysten for miljooverkaking og sikkerhet, med begrenset tilkobling
 - **Energisektoren**: Smart styring av offentlige bygg med prediktiv vedlikeholdsanalyse av HVAC-systemer
 - **Helsesektoren**: IoT-basert pasientovervaking pa sykehus med lokal AI for tidlig varsling
--- a/skills/ms-ai-infrastructure/references/hybrid-edge/kubernetes-edge-aks-edge.md
+++ b/skills/ms-ai-infrastructure/references/hybrid-edge/kubernetes-edge-aks-edge.md
@ -25,7 +25,7 @@ AKS Edge Essentials er Microsofts lettvekts Kubernetes-distribusjon for edge-sce

 For AI-arbeidsbelastninger pa edge muliggjor AKS Edge Essentials deployment av ML-modeller, inferensservere, og AI-pipelines som Kubernetes-pods med GPU-akselerasjon (via GPU-PV). Tilkoblet Azure Arc gir sentralisert administrasjon, GitOps-basert deployment, og integrasjon med Azure ML, Azure Monitor og Azure Policy.

-For norsk offentlig sektor er AKS Edge Essentials relevant for distribuert AI pa lokale stasjoner (veisensorer, helseutstyr, energimalere) der Kubernetes-basert orkestrering gir standardisert deployment og oppdatering av AI-modeller pa tvers av geografisk spredte enheter.
+For norsk offentlig sektor er AKS Edge Essentials relevant for distribuert AI pa lokale stasjoner (pumpestasjoner, helseutstyr, energimalere) der Kubernetes-basert orkestrering gir standardisert deployment og oppdatering av AI-modeller pa tvers av geografisk spredte enheter.

 ---

@ -383,9 +383,9 @@ spec:

 | Stasjon | Antall | Hardware | AKS Edge-konfig | AI-workload |
 |---------|--------|----------|-----------------|-------------|
-| Veisensorer | ~200 | Industrial PC | Single-node K3s | Trafikk-analyse |
-| Tunnelverkaking | ~50 | Rack-server | Multi-node K8s | Brann/ventilasjon |
-| Ferjekaier | ~30 | Rugged PC | Single-node K3s | Bildetelling |
+| Pumpestasjoner | ~200 | Industrial PC | Single-node K3s | Lekkasje-analyse |
+| Sykehusbygg | ~50 | Rack-server | Multi-node K8s | Brann/ventilasjon |
+| Gjenvinningsstasjoner | ~30 | Rugged PC | Single-node K3s | Bildetelling |
 | Ladestajoner | ~500 | IoT gateway | K3s minimal | Energi-prediksjon |

 ### Sikkerhets- og administrasjonskrav
--- a/skills/ms-ai-infrastructure/references/hybrid-edge/offline-first-ai-applications.md
+++ b/skills/ms-ai-infrastructure/references/hybrid-edge/offline-first-ai-applications.md
@ -23,7 +23,7 @@

 Offline-first AI-applikasjoner er designet for a fungere primaert lokalt og synkronisere med skyen nar tilkobling er tilgjengelig. Dette monsteret snur den tradisjonelle sky-forst-tilnaermingen pa hodet: i stedet for a feile nar nettverket er nede, er applikasjonen designet for a operere uavhengig med lokal AI-inferens og datalagring.

-For norsk offentlig sektor er offline-first sarlig relevant i felt-scenarioer: vegarbeidere som inspiserer infrastruktur i omrader uten dekning, ambulansepersonell som trenger AI-stoette i rurale omrader, beredskapspersonell under krisesituasjoner der kommunikasjonsinfrastruktur kan vaere nede, og maritime inspeksjoner langs kysten.
+For norsk offentlig sektor er offline-first sarlig relevant i felt-scenarioer: driftspersonell som inspiserer ledningsnett i omrader uten dekning, ambulansepersonell som trenger AI-stoette i rurale omrader, beredskapspersonell under krisesituasjoner der kommunikasjonsinfrastruktur kan vaere nede, og maritime inspeksjoner langs kysten.

 Microsoft tilbyr flere byggeklosser for offline-first AI: ONNX Runtime for lokal inferens, Azure IoT Edge for container-basert edge-prosessering med utvidet offline-stoette, Azure Container Storage for lokal persistens med automatisk sky-synkronisering, og Phi-modeller for lokale SLM-kapabiliteter.

@ -405,7 +405,7 @@ class TestOfflineAI:
    def test_event_persistence_offline(self, event_store):
        """Hendelser skal lagres lokalt ved offline"""
        event = event_store.append_event(
-            "inspection", "bridge-001",
+            "inspection", "pumpestasjon-001",
            {"status": "ok", "notes": "Ingen synlige skader"}
        )
        assert event.synced is False
@ -465,7 +465,7 @@ class TestOfflineAI:

 | Scenario | Etat | Offline-varighet | AI-funksjon |
 |----------|------|-----------------|-------------|
-| Vegfinspeksjon | DDT | Timer | Skadeklassifisering |
+| Ledningsinspeksjon | Kommunalt vannverk | Timer | Skadeklassifisering |
 | Ambulanse | Helseetaten | Minutter-timer | Triagering |
 | Beredskap | DSB | Dager | Situasjonsanalyse |
 | Maritime inspeksjoner | Sjoefartsdir. | Timer-dager | Rapport-generering |
--- a/skills/ms-ai-infrastructure/references/hybrid-edge/regulatory-compliance-edge-ai.md
+++ b/skills/ms-ai-infrastructure/references/hybrid-edge/regulatory-compliance-edge-ai.md
@ -52,7 +52,7 @@ Ifoolge GDPR Art. 35 er DPIA pakrevd nar databehandling sannsynligvis medforer h
 | Trigger | Edge AI-eksempel | DPIA-krav |
 |---------|-----------------|-----------|
 | Automatiserte beslutninger | AI-basert triage pa sykehus | Pakrevd |
-| Systematisk overvaking | Kamerabasert trafikkanalyse | Pakrevd |
+| Systematisk overvaking | Kamerabasert overvaking av offentlige rom | Pakrevd |
 | Sensitive data i stor skala | Helsedata-analyse pa lokale servere | Pakrevd |
 | Ny teknologi | AI-modeller pa edge-enheter | Vurderes |
 | Saerbare grupper | AI i barnevern/NAV | Pakrevd |
--- a/skills/ms-ai-security/references/ai-security-engineering/pii-detection-norwegian-context.md
+++ b/skills/ms-ai-security/references/ai-security-engineering/pii-detection-norwegian-context.md
@ -57,7 +57,7 @@ Azure AI Language grupperer PII i tre feature-typer (etter input-format og prose
 | Adresse | `Address` | Storgata 1, 0123 Oslo | ML-basert |
 | Organisasjon | `Organization` | NAV, Skatteetaten | ML-basert |
 | EU Passport | `EUPassportNumber` | Norsk pass | Format-validering |
-| EU Drivers License | `EUDriversLicenseNumber` | Norsk saksbehandling | Format-validering |
+| EU Drivers License | `EUDriversLicenseNumber` | Dokumentnummer i EU-format | Format-validering |
 | Bank Account | `InternationalBankingAccountNumber` | IBAN | Format-validering |

 **Viktig:** Azure detekterer norske fødselsnummer under kategorien `NOIdentityNumber`. Du må spesifisere `language: "no"` for optimal deteksjon.
--- a/skills/ms-ai-security/references/cost-optimization/azure-cost-management-ai.md
+++ b/skills/ms-ai-security/references/cost-optimization/azure-cost-management-ai.md
@ -286,7 +286,7 @@ Azure Cost Management aggregerer kostnader per dag, men fakturering skjer måned
 | Arkitekturmønstre | **Baseline + Domain Expertise** | FinOps Framework + Azure Well-Architected |
 | Beslutningsveiledning | **Verified** | Cost optimization best practices (Well-Architected) |
 | Integrasjon med Microsoft-stakken | **Verified** | Official docs (tags, Power BI, Azure Monitor) |
-| Offentlig sektor (Norge) | **Domain Expertise** | KTG/DDT-kontekst, ikke Microsoft-spesifikk |
+| Offentlig sektor (Norge) | **Domain Expertise** | Norsk offentlig sektor-kontekst, ikke Microsoft-spesifikk |
 | For arkitekten | **Baseline + Best Practices** | Syntetisert fra research + field experience |

 ---
--- a/skills/ms-ai-security/references/performance-scalability/batch-api-usage-optimization.md
+++ b/skills/ms-ai-security/references/performance-scalability/batch-api-usage-optimization.md
@ -62,9 +62,9 @@ Denne referansen dekker hele arbeidsflyten for Batch API, fra filsammensetning o
 Batch API bruker JSON Lines-format (`.jsonl`), der hver linje er en selvstendig JSON-objekt:

 ```jsonl
-{"custom_id": "req-001", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-4o-batch", "messages": [{"role": "system", "content": "Klassifiser henvendelsen som KLAGE, SPORSMAL, eller TILBAKEMELDING."}, {"role": "user", "content": "Jeg er svart misfornoyd med ventetiden pa fornyelse av forerkort."}], "max_tokens": 50}}
-{"custom_id": "req-002", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-4o-batch", "messages": [{"role": "system", "content": "Klassifiser henvendelsen som KLAGE, SPORSMAL, eller TILBAKEMELDING."}, {"role": "user", "content": "Hvordan soker jeg om nytt forerkort?"}], "max_tokens": 50}}
-{"custom_id": "req-003", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-4o-batch", "messages": [{"role": "system", "content": "Klassifiser henvendelsen som KLAGE, SPORSMAL, eller TILBAKEMELDING."}, {"role": "user", "content": "Fint arbeid med den nye tunnelen i Rogaland!"}], "max_tokens": 50}}
+{"custom_id": "req-001", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-4o-batch", "messages": [{"role": "system", "content": "Klassifiser henvendelsen som KLAGE, SPORSMAL, eller TILBAKEMELDING."}, {"role": "user", "content": "Jeg er svart misfornoyd med ventetiden pa behandling av byggesoknaden min."}], "max_tokens": 50}}
+{"custom_id": "req-002", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-4o-batch", "messages": [{"role": "system", "content": "Klassifiser henvendelsen som KLAGE, SPORSMAL, eller TILBAKEMELDING."}, {"role": "user", "content": "Hvordan soker jeg om skjenkebevilling?"}], "max_tokens": 50}}
+{"custom_id": "req-003", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "gpt-4o-batch", "messages": [{"role": "system", "content": "Klassifiser henvendelsen som KLAGE, SPORSMAL, eller TILBAKEMELDING."}, {"role": "user", "content": "Fint arbeid med det nye biblioteket i kommunen!"}], "max_tokens": 50}}
 ```

 **Viktige regler:**
@ -517,7 +517,7 @@ def retry_failed_requests(
 system_prompt = """Klassifiser henvendelsen. Svar med JSON:
 {"kategori": "KLAGE|SPORSMAL|TILBAKEMELDING|SOKNAD",
 "prioritet": "HOY|NORMAL|LAV",
- "etat": "FORERKORT|KJORETOYREG|VEIPROSJEKT|ANNET"}"""
+ "tjenesteomraade": "BYGGESAK|SKJENKEBEVILLING|TILSKUDD|ANNET"}"""

 batch_file = generate_batch_file(
    items=henvendelser,
--- a/skills/ms-ai-security/references/performance-scalability/latency-optimization-azure-openai.md
+++ b/skills/ms-ai-security/references/performance-scalability/latency-optimization-azure-openai.md
@ -316,7 +316,7 @@ Azure OpenAI prompt caching reduserer latens og kostnad for requests med identis
 # System prompt som gjenbrukes pa tvers av requests
 SYSTEM_PROMPT = """Du er en saksbehandlingsassistent for Direktoratet for digital tjenesteutvikling.
 Du hjelper med a analysere og klassifisere innkommende henvendelser
-relatert til forerkort, kjoretoysregistrering og veiprosjekter.
+relatert til byggesaker, skjenkebevillinger og tilskudd.

 Folg disse retningslinjene:
 1. Klassifiser henvendelsen i riktig kategori
--- a/skills/ms-ai-security/references/performance-scalability/prompt-caching-performance.md
+++ b/skills/ms-ai-security/references/performance-scalability/prompt-caching-performance.md
@ -172,11 +172,11 @@ def design_cacheable_prompt(
 messages, stats = design_cacheable_prompt(
    system_instructions="""Du er en AI-assistent for saksbehandlere i
    Direktoratet for digital tjenesteutvikling. Du hjelper med å analysere klager på vedtak om
-    saksbehandling, vurdere om klagen har grunnlag, og foreslå svar.
+    tilskudd, vurdere om klagen har grunnlag, og foreslå svar.

    Regelverk du skal referere til:
-    - Vegtrafikkloven § 24-34
-    - fagforskriften
+    - Tilskuddsordningens forskrift
+    - Reglement for økonomistyring i staten
    - Forvaltningsloven § 28-36 (klagebehandling)

    Format: Alltid bruk overskrifter, vurder hvert punkt separat,
@ -184,11 +184,11 @@ messages, stats = design_cacheable_prompt(

    few_shot_examples=[
        {
-            "input": "Klage: Jeg fikk avslag på fornyelse...",
+            "input": "Klage: Jeg fikk avslag på søknad om driftstilskudd...",
            "output": "## Vurdering\n### Regelverksvurdering..."
        },
        {
-            "input": "Klage: Mitt saksbehandling ble inndratt...",
+            "input": "Klage: Tilskuddet mitt ble krevd tilbakebetalt...",
            "output": "## Vurdering\n### Regelverksvurdering..."
        }
    ],
--- a/tests/fixtures/ai-act/fixture-high-risk.md
+++ b/tests/fixtures/ai-act/fixture-high-risk.md
@ -11,7 +11,7 @@
 | **Risikonivå** | Høyrisiko |
 | **Annex III-kategori** | Kategori 5: Tilgang til og bruk av essensielle offentlige tjenester og ytelser |
 | **GPAI-status** | Ja — basert på GPT-4o via Azure OpenAI |
-| **Klassifiseringsgrunnlag** | Systemet automatiserer vurdering av helsekrav ved søknad om saksbehandling (klasse B). Direkte påvirkning på borgeres rett til saksbehandling — en essensiell offentlig tjeneste. |
+| **Klassifiseringsgrunnlag** | Systemet automatiserer vurdering av vilkår ved søknad om tilskudd. Direkte påvirkning på borgeres rett til tilskudd — en essensiell offentlig tjeneste. |
 | **Konfidens** | Høy |

 #### Steg 1: Forbudt-sjekk (Art. 5)
@ -20,7 +20,7 @@ Ingen forbudte praksiser identifisert. Systemet scorer ikke individer sosialt, o
 #### Steg 2: Annex III høyrisiko-sjekk
 **Treffer kategori 5 (a):** AI-systemer som brukes av offentlige myndigheter for å vurdere berettigelse til offentlige ytelser og tjenester, inkludert tildelingsbeslutninger.

-Tjenesten er en essensiell offentlig tjeneste i norsk kontekst. Automatisert vurdering av helsekrav påvirker direkte borgeres tilgang til denne tjenesten.
+Tjenesten er en essensiell offentlig tjeneste i norsk kontekst. Automatisert vurdering av tilskuddsvilkår påvirker direkte borgeres tilgang til denne tjenesten.

 **Grensevurdering:** Det er ingen tvil om at dette er høyrisiko. Systemet tar beslutninger som direkte påvirker enkeltpersoners rettigheter og muligheter.

--- a/tests/fixtures/ai-act/fixture.md
+++ b/tests/fixtures/ai-act/fixture.md
@ -1,4 +1,4 @@
-## EU AI Act — Vurdering: FartsPrediksjonsagent
+## EU AI Act — Vurdering: Energiprognoseagent

 **Dato:** 2026-02-22
 **Vurdert av:** AI Act Assessor
@ -11,7 +11,7 @@
 | **Risikonivå** | Minimal risiko |
 | **Annex III-kategori** | Ikke Annex III |
 | **GPAI-status** | Ja — basert på GPT-4o, men ikke systemisk risiko |
-| **Klassifiseringsgrunnlag** | Systemet predikerer gjennomsnittsfart på vegstrekninger basert på historiske trafikkdata. Ingen direkte påvirkning på individer, ingen biometrisk identifikasjon, ikke kritisk infrastrukturstyring. |
+| **Klassifiseringsgrunnlag** | Systemet predikerer energiforbruk i kommunale formålsbygg basert på historiske måledata. Ingen direkte påvirkning på individer, ingen biometrisk identifikasjon, ikke kritisk infrastrukturstyring. |
 | **Konfidens** | Høy |

 #### Steg 1: Forbudt-sjekk (Art. 5)
@ -29,10 +29,10 @@ Systemet treffer ingen av de 8 Annex III-kategoriene:
 - Ikke rettsforvaltning

 #### Steg 3: GPAI-sjekk
-Systemet bruker Azure OpenAI GPT-4o som grunnmodell. GPT-4o er en GPAI-modell, men FartsPrediksjonsagent er en downstream-applikasjon — provider-forpliktelser for GPAI hviler på Microsoft som modell-provider.
+Systemet bruker Azure OpenAI GPT-4o som grunnmodell. GPT-4o er en GPAI-modell, men Energiprognoseagent er en downstream-applikasjon — provider-forpliktelser for GPAI hviler på Microsoft som modell-provider.

 #### Steg 4: Begrenset/Minimal
-Systemet har ingen direkte brukerinteraksjon med borgere. Resultater vises kun til trafikkplanleggere internt. Klassifiseres som **minimal risiko**.
+Systemet har ingen direkte brukerinteraksjon med borgere. Resultater vises kun til energirådgivere internt. Klassifiseres som **minimal risiko**.

 ### 2. Rolle

@ -54,7 +54,7 @@ Systemet har ingen direkte brukerinteraksjon med borgere. Resultater vises kun t

 | # | Tiltak | Prioritet | Frist | Ansvarlig |
 |---|--------|-----------|-------|-----------|
-| T1 | Formalisér AI-kompetanseplan for trafikkplanleggere | Lav | 2026-12-31 | Seksjonsleder |
+| T1 | Formalisér AI-kompetanseplan for energirådgivere | Lav | 2026-12-31 | Seksjonsleder |
 | T2 | Vurdér frivillig Code of Conduct-tilslutning | Lav | 2027-06-30 | AI-rådgiver |

 ### 5. Neste steg
--- a/tests/fixtures/cost-estimation/fixture.md
+++ b/tests/fixtures/cost-estimation/fixture.md
@ -18,7 +18,7 @@
 | Drift/vedlikehold | 0 | 0 | 50K | 150K | 350K |
 | Overvåking | 0 | 0 | 20K | 80K | 100K |
 | Embedding-refresh | 0 | 0 | 20K | 60K | 60K |
-| Regional støtte/opplæring | 0 | 0 | 0 | 150K | 150K |
+| Lokal brukerstøtte/opplæring | 0 | 0 | 0 | 150K | 150K |
 | Risk buffer (drift) | 0 | 0 | 0 | 150K | 230K |
 | **3-års TCO** | **0** | **0** | **2 000K** | **6 335K** | **9 100K** |

--- a/tests/fixtures/security-assessment/fixture.md
+++ b/tests/fixtures/security-assessment/fixture.md
@ -21,7 +21,7 @@
 3. **Incident Response-plan mangler** — Ingen prosedyre for AI-spesifikke hendelser (prompt injection breach, PII-lekkasje)

 **P1 (Høy prioritet):**
-4. **Red team-testing av security trimming** — Må verifisere at regionbasert tilgangskontroll fungerer korrekt
+4. **Red team-testing av security trimming** — Må verifisere at rollebasert tilgangskontroll fungerer korrekt
 5. **AI-spesifikk alerting mangler** — Ingen varsling for anomalier i prompt-mønstre eller uvanlig token-forbruk
 6. **PIM ikke konfigurert** — Admin-tilgang til AI-ressurser bør styres via Privileged Identity Management

@ -52,12 +52,12 @@

 | Datatype | Klassifisering | Behandlingsgrunnlag | Lagringssted |
 |----------|----------------|---------------------|--------------|
-| Håndbøker (N-serien) | Intern | Berettiget interesse | Azure AI Search (Norway East) |
+| Retningslinjer | Intern | Berettiget interesse | Azure AI Search (Norway East) |
 | Kontrakter | Fortrolig | Berettiget interesse | Azure AI Search (Norway East), security trimmed |
-| Inspeksjonsrapporter | Intern | Berettiget interesse | Azure AI Search (Norway East) |
+| Saksdokumenter | Intern | Berettiget interesse | Azure AI Search (Norway East) |
 | Avviksrapporter (PII) | Fortrolig | Samtykke/Lovhjemmel | Azure AI Search (Norway East), PII-maskert |
 | Chatlogger | Intern | Berettiget interesse | Application Insights (Sweden Central), 90d retention |
-| NVDB-data | Åpen | Åpne data | Ikke lagret — live API-oppslag |
+| Åpne statistikkdata | Åpen | Åpne data | Ikke lagret — live API-oppslag |

 ---

--- a/tests/fixtures/summary/fixture.md
+++ b/tests/fixtures/summary/fixture.md
@ -2,35 +2,35 @@

 ### 1.1 Teknisk sammendrag

-Denne utredningen vurderer innføring av en AI-assistert kunnskapssøk-løsning for drift- og vedlikeholdsavdelinger i en norsk statlig veietat med ~1500 ansatte fordelt på 5 regioner. Løsningen skal erstatte dagens fragmenterte, manuelle dokumentsøk på tvers av 65 000+ dokumenter i 5 separate systemer (SharePoint, Doculive, Landbruks-IT, lokale filservere, NVDB).
+Denne utredningen vurderer innføring av en AI-assistert kunnskapssøk-løsning for saksbehandlere i plan-, bygg- og eiendomsforvaltningen i en stor norsk kommune, med ~1500 ansatte fordelt på 3 tjenesteområder. Løsningen skal erstatte dagens fragmenterte, manuelle dokumentsøk på tvers av 65 000+ dokumenter i 5 separate systemer (SharePoint, ESDH-systemet, intranettet, lokale filservere, regelverksbasen).

 **Anbefalt plattform:** Alternativ 2B — Hybrid (Copilot Studio + Azure AI Foundry RAG) (S2.5, S8.1)

-Copilot Studio fungerer som Teams-native UI-lag («Veihjelper AI»), mens Azure AI Foundry gir full kontroll over RAG-pipeline med custom chunking, Presidio PII-filtrering og SharePoint ACL-basert security trimming. Multi-modell-strategi med GPT-4o for komplekse fagspørsmål og GPT-4o-mini for enkel gjenfinning (80/20 cost routing) sikrer kostnadseffektivitet (S4.2). Embedding med text-embedding-3-large (3072 dim) i Azure AI Search S1 med hybrid search og semantic reranking gir best ytelse for norsk fagterminologi (S4.3).
+Copilot Studio fungerer som Teams-native UI-lag («Fagassistent AI»), mens Azure AI Foundry gir full kontroll over RAG-pipeline med custom chunking, Presidio PII-filtrering og SharePoint ACL-basert security trimming. Multi-modell-strategi med GPT-4o for komplekse fagspørsmål og GPT-4o-mini for enkel gjenfinning (80/20 cost routing) sikrer kostnadseffektivitet (S4.2). Embedding med text-embedding-3-large (3072 dim) i Azure AI Search S1 med hybrid search og semantic reranking gir best ytelse for norsk fagterminologi (S4.3).

-**Arkitektur (S8.2):** Brukerinteraksjon via Teams (mobil/desktop) → Entra ID-autentisering → Copilot Studio Agent → Azure AI Foundry RAG-pipeline (Azure OpenAI GPT-4o/mini i Sweden Central, Azure AI Search S1 i Norway East) + NVDB REST API via function calling. Presidio PII-filter (pre-indexing) og Azure AI Content Safety (runtime) sikrer personvern og innholdssikkerhet.
+**Arkitektur (S8.2):** Brukerinteraksjon via Teams (mobil/desktop) → Entra ID-autentisering → Copilot Studio Agent → Azure AI Foundry RAG-pipeline (Azure OpenAI GPT-4o/mini i Sweden Central, Azure AI Search S1 i Norway East) + ESDH-systemets REST API via function calling. Presidio PII-filter (pre-indexing) og Azure AI Content Safety (runtime) sikrer personvern og innholdssikkerhet.

 **Sikkerhetsstatus (S5):** Totalscore 2.80/5.00 — BETINGET AKSEPTABEL. Tre P0-blokkere er identifisert: (1) DPIA ikke gjennomført (GDPR art. 35), (2) Schrems II TIA mangler for Azure OpenAI i Sweden Central, (3) Incident Response-plan mangler. Alle tre er innarbeidet som obligatoriske aktiviteter i Fase 0 av implementeringsplanen (S9.4). AI Act-klassifisering: Begrenset risiko — transparenskrav oppfylt med AI-merking og kildehenvisninger (S4.1).

-**Kostnad (S6):** Etableringskostnad 2.035M NOK (Fase 1, innenfor 2M-budsjettramme). Årlig driftskostnad 1.35M NOK inkludert Copilot Studio capacity pack (230K), Azure OpenAI tokens (210K), Azure AI Search (200K), infrastruktur (120K), drift/vedlikehold (150K), overvåking (80K), embedding-refresh (60K), regional støtte (150K) og risk buffer (150K). 3-års TCO: 6.335M NOK. Fase 2 (Doculive + Landbruks-IT) budsjetteres separat til 850K.
+**Kostnad (S6):** Etableringskostnad 2.035M NOK (Fase 1, innenfor 2M-budsjettramme). Årlig driftskostnad 1.35M NOK inkludert Copilot Studio capacity pack (230K), Azure OpenAI tokens (210K), Azure AI Search (200K), infrastruktur (120K), drift/vedlikehold (150K), overvåking (80K), embedding-refresh (60K), lokal brukerstøtte (150K) og risk buffer (150K). 3-års TCO: 6.335M NOK. Fase 2 (ESDH-systemet + intranettet) budsjetteres separat til 850K.

-**Implementeringsplan (S9):** Fasevis utrulling over 48 uker. Fase 0 (uke 1-4): Forberedelse, DPIA, Schrems II TIA, Azure OpenAI-søknad. Fase 1 (uke 5-32): MVP med SharePoint (39K dok) + NVDB, inkludert infrastruktur, RAG-pipeline, Copilot Studio agent, sikkerhetstesting, pilot med 50 brukere, opplæring (5 regioner) og region-for-region utrulling. Fase 2 (uke 33-48): Full dekning med Doculive (13K) og Landbruks-IT (10K). 8 milepæler definert (M0-M8), inkludert gevinstevaluering i uke 56 (S9.2).
+**Implementeringsplan (S9):** Fasevis utrulling over 48 uker. Fase 0 (uke 1-4): Forberedelse, DPIA, Schrems II TIA, Azure OpenAI-søknad. Fase 1 (uke 5-32): MVP med SharePoint (39K dok) + regelverksbasen, inkludert infrastruktur, RAG-pipeline, Copilot Studio agent, sikkerhetstesting, pilot med 50 brukere, opplæring (3 tjenesteområder) og utrulling område for område. Fase 2 (uke 33-48): Full dekning med ESDH-systemet (13K) og intranettet (10K). 8 milepæler definert (M0-M8), inkludert gevinstevaluering i uke 56 (S9.2).

 **Arkitekturprinsipper (S3):** 3 av 7 Digdir-prinsipper fullt oppfylt, 4 delvis oppfylt. Hovedavvik: Schrems II-risiko (P4 Tillit), begrenset ekstern datadeling (P2/P7). Trade-off vedtatt: Sweden Central aksepteres med formell risikoaksept da Norway East ikke tilbyr Azure OpenAI.

 **Digital samhandling (S7):** Juridisk samhandling er oppfylt (berettiget interesse, DPA med Microsoft, ingen vedtaksfatning). Organisatorisk samhandling er delvis under arbeid (RACI-matrise, AI-styringsgruppe). Semantisk samhandling er oppfylt (OData, Dublin Core, standardisert embedding). Teknisk samhandling er oppfylt (REST API, OAuth 2.0, SLA 99.8%). Styring planlagt med kvartalsvis AI-styringsgruppe og definerte KPI-er.

-5 ADR-er er utarbeidet (S8.3): Copilot Studio som UI (ADR-001), custom RAG i Azure AI Foundry (ADR-002), Sweden Central med risikoaksept (ADR-003), batch-import fra Landbruks-IT (ADR-004), og Security Trimming med SharePoint ACL-mapping (ADR-005).
+5 ADR-er er utarbeidet (S8.3): Copilot Studio som UI (ADR-001), custom RAG i Azure AI Foundry (ADR-002), Sweden Central med risikoaksept (ADR-003), batch-import fra intranettet (ADR-004), og Security Trimming med SharePoint ACL-mapping (ADR-005).

 ---

 ### 1.2 Beslutningsnotat (Executive Summary)

-**Anbefaling:** Iverksett Alternativ 2B — Hybrid Copilot Studio + Azure AI Foundry RAG for AI-assistert dokumentsøk i drift- og vedlikeholdsavdelingene.
+**Anbefaling:** Iverksett Alternativ 2B — Hybrid Copilot Studio + Azure AI Foundry RAG for AI-assistert dokumentsøk i plan-, bygg- og eiendomsforvaltningen.

-**Bakgrunn:** Driftspersonell bruker 3-5 timer per uke på manuelt dokumentsøk i 5 ulike systemer. Produktivitetstapet er estimert til ~77M NOK/år for hele organisasjonen. Kunnskapen er fragmentert, eksisterende søk forstår ikke norsk vei-fagterminologi, og det finnes ingen felles søkeflate.
+**Bakgrunn:** Saksbehandlere bruker 3-5 timer per uke på manuelt dokumentsøk i 5 ulike systemer. Produktivitetstapet er estimert til ~77M NOK/år for hele organisasjonen. Kunnskapen er fragmentert, eksisterende søk forstår ikke norsk fagterminologi, og det finnes ingen felles søkeflate.

-**Hva vi anbefaler:** En Teams-basert AI-assistent («Veihjelper AI») som gir umiddelbar tilgang til hele dokumentkorpuset (65 000+ dokumenter) med norskspråklig semantisk søk, kildehenvisninger og sanntids veidata fra NVDB. Løsningen bruker Microsofts AI-plattform med full kontroll over sikkerhet og personvern.
+**Hva vi anbefaler:** En Teams-basert AI-assistent («Fagassistent AI») som gir umiddelbar tilgang til hele dokumentkorpuset (65 000+ dokumenter) med norskspråklig semantisk søk, kildehenvisninger og oppdaterte saksdata fra ESDH-systemet. Løsningen bruker Microsofts AI-plattform med full kontroll over sikkerhet og personvern.

 **Hvorfor dette alternativet:** Alt 2B gir den beste balansen mellom brukeropplevelse (Teams-native), sikkerhet (PII-filtrering, security trimming) og kostnad (innenfor 2M budsjett for Fase 1). Alt 1 (SharePoint AI Search) dekker kun 60% av dokumentene. Alt 2 (innebygd RAG) mangler kontroll over PII og security trimming. Alt 3 (full custom) er overingeniørt og sprenger budsjettet.

@ -72,7 +72,7 @@ Copilot Studio fungerer som Teams-native UI-lag («Veihjelper AI»), mens Azure
 | **Brutto produktivitetsgevinst** | ~77M NOK/år |
 | **Gevinstraliseringsgrad** | 30-50% (konservativt) |
 | **Dokumentkorpus** | 65 000+ dokumenter |
-| **Datakilder** | 5 (SharePoint, Doculive, Landbruks-IT, filservere, NVDB) |
+| **Datakilder** | 5 (SharePoint, ESDH-systemet, intranettet, filservere, regelverksbasen) |
 | **Primærbrukere** | ~750 (potensielt 1500) |
 | **Time-to-value (MVP)** | 7-8 måneder (Fase 1) |
 | **Full dekning** | 12 måneder (Fase 1 + 2) |
--- a/tests/kb-update/test-user-data.test.mjs
+++ b/tests/kb-update/test-user-data.test.mjs
@ -85,7 +85,7 @@ const PROFILE = [
  'Statlig',
  '',
  '## Virksomhet',
-  'Statens vegvesen — nasjonal veiforvaltning',
+  'Eksempeldirektoratet — nasjonal forvaltning',
  '',
  '## Størrelse',
  '2000-10000',
@ -113,7 +113,7 @@ test('buildOrgSummary — strips frontmatter + H1, extracts H2 section => value
  assert.doesNotMatch(s, /Virksomhetsprofil/, 'H1 not included');
  assert.match(s, /Sektortype: Offentlig sektor/);
  assert.match(s, /Sektor: Statlig/);
-  assert.match(s, /Virksomhet: Statens vegvesen/);
+  assert.match(s, /Virksomhet: Eksempeldirektoratet/);
  assert.match(s, /Størrelse: 2000-10000/);
  assert.match(s, /Regulatoriske krav: .*Arkivloven/);
 });
--- a/tests/test-playground-projectview.sh
+++ b/tests/test-playground-projectview.sh
@ -92,7 +92,7 @@ function buildDemoState(opts) {
    projects: [{
      id: "p1",
      name: "Acme: Kunde-chatbot",
-      description: "AI-system for objekt-deteksjon i sensordata.",
+      description: "Innbyggerchatbot som forhåndsvurderer søknader om bostøtte.",
      createdAt: "2026-04-01T08:00:00.000Z",
      artifacts: {
        classify: {