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>
This commit is contained in:
Kjell Tore Guttormsen 2026-09-23 14:03:53 +02:00
commit 544934dc57
Signed by: ktg
SSH key fingerprint: SHA256:JakMjO6FTBBzN0Bhfj9saOoEjaFxlSdYuZQQpM/lF9Q
77 changed files with 363 additions and 368 deletions

View file

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

View file

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

View file

@ -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** |

View file

@ -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:**

View file

@ -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.
---

View file

@ -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] |

View file

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

View file

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

View file

@ -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)

View file

@ -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 │
└─────────────────┘ └──────────────────┘

View file

@ -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:**