ms-ai-architect/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-methodology-ns5814-iso31000.md

# ROS-metodikk: NS 5814, ISO 31000 og AI-spesifikke rammeverk

**Sist oppdatert:** 2026-02
**Kategori:** Norwegian Public Sector AI Governance
**Status:** Established Practice
**Formål:** Detaljert metodikkguide for ros-analysis-agent — kobler AI-ROS til etablerte standarder og sikrer revisjonssporbarhet

---

## Oversikt

Denne guiden definerer den metodiske grunnmuren for ROS-analyser av AI-systemer i norsk offentlig sektor. Metodikken er konstruert som en syntese av etablerte risikostyringsrammeverk tilpasset AI-spesifikke utfordringer: ikke-deterministisk output, bias-risiko, forklarbarhetskrav og raskt skiftende trussellandskap.

Alle agentgenererte ROS-rapporter i ms-ai-architect skal være sporbare til minst én standard i tabellen under.

### Standarder som dekkes

| Standard | Versjon | Relevans for AI-systemer |
|----------|---------|--------------------------|
| NS 5814 | 2021 | Norsk standard for ROS-analyser — prosessmessig ryggrad |
| ISO 31000 | 2018 | Internasjonal risikostyringsstandard — prinsipper og rammeverk |
| ISO/IEC 23894 | 2023 | AI-spesifikk risikostyring — tekniske og organisatoriske tilpasninger |
| ISO/IEC 27005 | 2022 | Informasjonssikkerhetsrisiko — særlig relevant for dataintegritet |
| ISO/IEC 42001 | 2023 | AI management system — styring og kontinuerlig forbedring |
| EU AI Act Art. 9 | 2024 | Obligatorisk risikostyringssystem for høyrisiko AI |
| NIST AI RMF | 1.0 (2023) | GOVERN–MAP–MEASURE–MANAGE funksjonsrammeverk |
| DSB Veileder ROS | 2024 | Helhetlig ROS for kommuner og offentlige virksomheter |
| Datatilsynet AI-veileder | 2023 | Personvernkonsekvenser av AI — DPIA-kobling |
| NSM Grunnprinsipper | 2.0 (2022) | IKT-sikkerhetsgrunnlag — tilgjengelighet, integritet, konfidensialitet |

---

## Del 1: NS 5814:2021 — Prosessmapping

NS 5814 er den primære prosessstandarden. Standarden definerer fire hovedelementer i en ROS: planlegging, risikoidentifisering, risikoanalyse og risikoevaluering. Vår 8-fase metodikk operasjonaliserer disse elementene med AI-spesifikke tilpasninger.

### NS 5814:2021 prosessmapping

| NS 5814 hovedelement | NS 5814 aktivitet | Vår fase | AI-spesifikk tilpasning |
|----------------------|-------------------|----------|-------------------------|
| Planlegging | Definere formål og omfang | Fase 1: Scope og kontekst | Inkluderer AI-risikoklasse (AI Act), grad av autonomi og modelltype |
| Planlegging | Identifisere interessenter | Fase 2: Systembeskrivelse (brukere) | Spesifiserer sårbare grupper som kan påvirkes av AI-output |
| Risikoidentifisering | Identifisere verdier | Fase 3: Verdivurdering | Utvides med AI-spesifikke assets: modellvekter, prompts, treningsdata |
| Risikoidentifisering | Identifisere trusler og farer | Fase 4: Trusselidentifisering | STRIDE + AI-spesifikke angrep: prompt injection, data poisoning, model inversion |
| Risikoanalyse | Analysere årsaker og sannsynlighet | Fase 5: Sårbarhetsanalyse | Inkluderer AI-spesifikke sårbarheter: overfit, distribusjonsskift, hallusinasjon |
| Risikoanalyse | Analysere konsekvenser | Fase 6: Risikoanalyse | 7-dimensjons rammeverk i stedet for enkelt konsekvenstema |
| Risikoevaluering | Evaluere og prioritere risikoer | Fase 6: Risikoregister + matrise | Vektet totalscore på tvers av dimensjoner |
| Risikoevaluering | Beslutte tiltak | Fase 7: Tiltaksplan | 4-strategier (unngå/redusere/overføre/akseptere) med tidslinje |
| Risikoevaluering | Beslutte akseptanse | Fase 8: Restrisiko og akseptanse | Formell akseptanseerklæring med signaturer |

### NS 5814 kvalitetskrav vi etterlever

NS 5814:2021 stiller eksplisitte krav til dokumentasjon, sporbarhet og gjennomgang. Følgende krav er innbygd i rapportmalene:

**Krav 4.3 — Dokumentasjon:** Alle analyser skal dokumenteres slik at de kan reproduseres og etterprøves. Oppfylt ved: strukturert rapportmal med fasevis dokumentasjon, risiko-ID-serie (R-001), trussel-ID-serie (T-001), tiltak-ID-serie (M-001).

**Krav 5.2 — Kompetanse:** Analysen skal utføres av kompetente personer. Oppfylt ved: agenten er trent på NS 5814, ISO 31000 og AI-spesifikke rammeverk, og angir eksplisitt at rapporten ikke erstatter ekstern revisjon.

**Krav 6.1 — Kontekstforståelse:** Organisasjonens interne og eksterne kontekst skal kartlegges. Oppfylt ved: Fase 1 inkluderer juridisk kontekst, organisasjonsstrategi og systemeiers mandat.

**Krav 7.1 — Behandling av usikkerhet:** Usikkerhet i sannsynlighets- og konsekvensestimater skal kommuniseres. Oppfylt ved: konfidensangivelse i Quick ROS, og eksplisitte forutsetninger i Full ROS.

---

## Del 2: ISO 31000:2018 — Prinsipper og rammeverk

ISO 31000 er den overordnede styringsstandarden. Standarden definerer prinsipper, rammeverk og prosess for risikostyring som gjelder alle typer organisasjoner og risiko.

### ISO 31000 prinsippmapping

ISO 31000:2018 Klausul 4 definerer åtte prinsipper. Slik etterlever metodikken dem:

| ISO 31000 prinsipp | Operasjonalisering i AI-ROS |
|--------------------|------------------------------|
| Integrert | ROS kobles til DPIA, ADR og AI Act conformity — ikke isolert dokument |
| Strukturert og helhetlig | 8-fase prosess med standardiserte skalaer og ID-serier |
| Tilpasset | Scope og kontekst (Fase 1–2) tilpasser analysen til virksomheten |
| Inkluderende | Berørte parter identifiseres (Fase 2.4) — inkludert sårbare grupper |
| Dynamisk | Anbefalt revisjonsintervall (6–12 måneder) eller ved vesentlig endring |
| Basert på beste tilgjengelig informasjon | Agenten bruker Microsoft Learn MCP + offentlig tilgjengelig regulatorisk dokumentasjon |
| Menneskelig og kulturell | Organisatorisk og menneskelig dimensjon (10 % vekt) er eksplisitt i dimensjonsvurderingen |
| Kontinuerlig forbedring | Restrisiko og tiltaksplan gir grunnlag for neste revisjonssyklus |

### ISO 31000 prosesskobling

ISO 31000:2018 Klausul 6 definerer risikostyringsprosessen i tre hovedelementer:

**6.4 Risikovurdering (risk assessment)** — dekkes av Fase 3–6:
- 6.4.2 Risikoidentifisering → Fase 3 (verdivurdering) + Fase 4 (trusler)
- 6.4.3 Risikoanalyse → Fase 5 (sårbarhet) + Fase 6 (risikoanalyse)
- 6.4.4 Risikoevaluering → Fase 6 (risikoregister, matrise, prioritering)

**6.5 Risikobehandling (risk treatment)** — dekkes av Fase 7:
- Valg av behandlingsalternativ (unngå/redusere/overføre/akseptere)
- Utforming av tiltaksplan med ansvar, frist og estimert kostnad
- Evaluering av restrisiko etter tiltak

**6.6 Overvåking og gjennomgang** — dekkes av Fase 8 + rapportens gyldighetsdato:
- Restrisiko dokumenteres eksplisitt
- Akseptanseerklæring med navngitte signaturparter
- Anbefalt neste revisjonstidspunkt angis

---

## Del 3: ISO/IEC 23894:2023 — AI-spesifikk risikostyring

ISO/IEC 23894 er den internasjonale standarden spesifikt for AI-risikostyring. Den bygger på ISO 31000 og tilføyer AI-spesifikke retningslinjer som er sentrale for metodikken.

### AI-spesifikke risikokilder (ISO/IEC 23894 Klausul 6)

Standarden identifiserer risikokilder som er umodne eller fraværende i tradisjonell IT-risikostyring. Slik adresseres de i vår metodikk:

| ISO/IEC 23894 risikokilde | Vår operasjonalisering | Dimensjon |
|---------------------------|------------------------|-----------|
| Datakvalitet og representativitet | Dataintegritet-dimensjon; spørsmål om treningsdatakilder og skjevheter | Dataintegritet og personvern |
| Modellytelse under distribusjonsskift | Sårbarhet V-xxx knyttet til out-of-distribution input; krav om driftsmonitering | Modellsikkerhet og robusthet |
| Forklarbarhet og transparens | Dedikert dimensjon (10 % vekt); sjekk av XAI-mekanismer og logging | Forklarbarhet og sporbarhet |
| Uintendert bruk og misbruk | Trusselidentifisering T-xxx inkluderer misuse-scenarier; scope inkluderer "reasonably foreseeable misuse" | Modellsikkerhet og robusthet |
| Menneskelig avhengighet og kompetanse | Organisatorisk og menneskelig dimensjon (10 % vekt); HITL-vurdering | Organisatorisk og menneskelig |
| Systemiske og kumulative risikoer | Integrasjonsoversikt (Fase 2.3); identifisering av kritiske avhengigheter | Tilgjengelighet og robusthet |

### ISO/IEC 23894 livssyklusperspektiv

Standarden understreker at risikostyring er en kontinuerlig prosess gjennom hele AI-systemets livssyklus — ikke kun ved lansering. Metodikken reflekterer dette gjennom:

- **Design-fase:** ROS kan gjennomføres som "forward-looking" analyse basert på systemspesifikasjon
- **Pre-produksjon:** Full ROS med eksisterende kontroller vurdert mot faktisk implementasjon
- **Produksjon:** Revisjon utløses av (a) vesentlige endringer, (b) hendelser, (c) periodisk intervall (maks 12 måneder)
- **Avvikling:** ROS-oppdatering for å adressere dataretur, modellsletting og logging-oppbevaring

---

## Del 4: EU AI Act Art. 9 — Obligatorisk risikostyringssystem

For AI-systemer klassifisert som høy risiko under EU AI Act (Vedlegg III) er risikostyringssystem (Art. 9) et juridisk krav — ikke en anbefaling. Metodikken er konstruert slik at en fullstendig Full ROS utgjør grunnlaget for Art. 9-etterlevelse.

### Art. 9 kravmapping

| EU AI Act Art. 9 krav | Vår fase | Dokumentasjon |
|-----------------------|----------|---------------|
| Art. 9(1): Etabler og vedlikehold et risikostyringssystem gjennom hele livssyklusen | Fase 1 + Fase 8 (gyldighetsdato, revisjonsplan) | Rapportens metadata og akseptanseerklæring |
| Art. 9(2)(a): Identifiser og analyser kjente og rimelig forutsigbare risikoer | Fase 4 (trusler) + Fase 5 (sårbarheter) | Trussel-ID-tabell, sårbarhetstabell |
| Art. 9(2)(b): Estimer og evaluer risikoer fra tilsiktet bruk og rimelig forutsigbart misbruk | Fase 4 + Fase 6 (risikoregister) | Misuse-scenarier i T-xxx, bruttoscore i R-xxx |
| Art. 9(2)(c): Evaluer andre risikoer basert på analyse av data fra post-market monitoring | Fase 8 (restrisiko) + revisjonsplan | Restrisikovurdering og revisjonsintervall |
| Art. 9(3): Risikoreduksjonstiltak | Fase 7 (tiltaksplan) | M-xxx med strategi, ansvar, frist |
| Art. 9(4): Eliminer/reduser risiko so far as possible | Fase 7 (strategi: unngå > redusere > overføre > akseptere) | Tiltaksstrategi dokumentert per M-xxx |
| Art. 9(5): Test-protokoller | Ikke direkte dekket — cross-reference til teknisk dokumentasjon | Kryssreferansetabell i Fase 8 |
| Art. 9(6): Sporingsevne gjennom leverandørkjeden | Fase 2.3 (integrasjoner), Fase 3 (assets) | Integrasjonstabell, T-004 (forsyningskjedeangrep) |
| Art. 9(7): Skriftlig risikostyringssystem | Hele rapportstrukturen | Versjonert dokument med signaturer |

### Høyrisikoklassifisering under AI Act Vedlegg III

Følgende AI-brukstilfeller er automatisk høy risiko og krever Full ROS + Art. 9-dokumentasjon:

- **Offentlig forvaltning:** Systemer som evaluerer enkeltpersoner for offentlige ytelser, tjenester eller sanksjoner
- **Biometri:** Fjernidentifikasjon i sanntid (med unntak) eller kategorisering
- **Kritisk infrastruktur:** AI i styring av vann, energi, transport
- **Utdanning:** Systemer for opptak, vurdering eller karaktersetting
- **Arbeidsmarked:** Rekruttering, forfremmelse, oppsigelse basert på AI
- **Rettshåndhevelse:** Risikovurdering, kriminalitetsforutsigelse, bevisanalyse
- **Migrasjon:** Saksbehandling av asyl, visum, grensekontroll

---

## Del 5: NIST AI RMF 1.0 — Funksjonsrammeverk

NIST AI Risk Management Framework (2023) tilbyr et komplementært perspektiv med fire kjernefunksjoner: GOVERN, MAP, MEASURE og MANAGE. Rammeverket er særlig nyttig for å strukturere organisasjonens løpende AI-governance, ikke bare punktanalyser.

### NIST AI RMF mapping til vår metodikk

| NIST funksjon | Underkategori | Vår fase | Aktiviteter |
|---------------|---------------|----------|-------------|
| GOVERN | Retningslinjer, prosesser, roller | Fase 1 | Scope definerer hvem som eier risikostyringen; juridisk kontekst etablerer policy-ramme |
| GOVERN | Ansvarlighet og åpenhet | Fase 8 | Akseptanseerklæring med navngitte parter; klassifisering av rapport |
| MAP | Kategoriser AI-risikokontekst | Fase 1–2 | Systemtype, autonomigrad, modellarkitektur, brukerpopulasjon |
| MAP | Identifiser berørte parter | Fase 2.4 | Brukertabell med sårbarhetsvurdering |
| MAP | Identifiser AI-risikoer | Fase 3–4 | Verdivurdering, trusselidentifisering |
| MEASURE | Analyser og prioriter risikoer | Fase 5–6 | Sårbarhetsanalyse, risikoregister, 5×5-matrise |
| MEASURE | Dimensjonsvurdering | Fase 6 + sammendrag | 7-dimensjons vektet score |
| MANAGE | Prioriter og implementer tiltak | Fase 7 | Tiltaksplan med strategi, eier og frist |
| MANAGE | Overvåk og gjennomgå | Fase 8 + revisjonskrav | Restrisiko, akseptanse, gyldighetsdato |

### NIST AI RMF profiler

NIST definerer "current profile" (nå-situasjon) og "target profile" (ønsket situasjon). Vår ROS-rapport leverer begge:

- **Current profile:** Brutto score per dimensjon (før tiltak) + eksisterende kontroller (Fase 5–6)
- **Target profile:** Netto score per dimensjon (etter tiltak) + implementerte M-xxx (Fase 7–8)

Gap mellom current og target profile synliggjøres i dimensjonsvurderingstabellen (brutto vs. netto score).

---

## Del 6: Sannsynlighetsskala (5 nivåer)

Skalaen er kalibrert for norsk offentlig sektor-kontekst. Frekvensestimater er veiledende — bruk faglig skjønn basert på systemets eksponeringsflate.

| Nivå | Betegnelse | Definisjon | Frekvens (veiledende) | Eksempel (AI-kontekst) |
|------|-----------|-----------|----------------------|------------------------|
| 1 | Svært lav | Hendelsen er teoretisk mulig, men det finnes ingen kjente tilfeller og angrepsvektoren er svært vanskelig å utnytte | Sjeldnere enn hvert 10. år | Avansert model inversion-angrep mot intern klassifikasjonsmodell uten nettverkseksponering |
| 2 | Lav | Hendelsen har skjedd i bransjen, men er ikke vanlig. Krever spesialkompetanse eller ressurser å utnytte | 1 gang per 1–10 år | Prompt injection i RAG-system utført av sofistikert angriper; alvorlig hallusinasjon med konsekvenser |
| 3 | Moderat | Hendelsen skjer regelmessig i virksomheter med lignende systemer. Utnyttelse krever moderat kompetanse | Ca. 1 gang per år | Utilsiktet eksponering av persondata i AI-generert rapport; bias-problem oppdaget i produksjon |
| 4 | Høy | Hendelsen forekommer hyppig i lignende systemer. Lav terskel for utnyttelse eller systemisk årsak | Månedlig | Feil output ved edge-case input; saksbehandler følger AI-anbefaling ukritisk; API-timeout |
| 5 | Svært høy | Hendelsen er nær-sikkert å inntreffe uten tiltak. Kjent sårbarhet, ingen kontroller, eller systemisk designfeil | Ukentlig eller oftere | Modell uten content safety på åpent grensesnitt; ingen logging av AI-beslutninger |

### Kalibreringsprinsipper

**Bruk bruttosannsynlighet** (uten eksisterende kontroller) i risikoregisteret. Eksisterende kontroller fanges i "Kontrolleffekt"-kolonnen og reflekteres i netto score.

**Vurder eksponeringsflate:** Et internt system med 5 saksbehandlere har lavere eksponeringsflate enn en publikumstjeneste med 50 000 månedlige brukere. Juster sannsynlighet deretter.

**Dokumenter usikkerhet:** Dersom sannsynlighetsestimatet er usikkert, angi dette i kommentarfeltet og vurder å bruke konservativt (høyere) estimat.

---

## Del 7: Konsekvensskala (5 nivåer)

Konsekvenser vurderes langs fire dimensjoner. Samlet konsekvens-score er det høyeste nivået på tvers av dimensjonene (worst-case-prinsippet), ikke et gjennomsnitt.

| Nivå | Betegnelse | Menneske og samfunn | Økonomi | Omdømme | Juridisk og regulatorisk |
|------|-----------|---------------------|---------|---------|--------------------------|
| 1 | Ubetydelig | Ingen personskade. Ubetydelig ulempe for enkeltpersoner | Under 100 000 NOK | Intern hendelse. Ingen medieomtale | Ingen regelbrudd. Mulig intern avvik |
| 2 | Liten | Begrenset ulempe for et lite antall personer. Ingen varig skade | 100 000 – 1 000 000 NOK | Lokal medieomtale. Kortvarig negativ omtale | Mindre avvik fra regelverk. Pålegg om retting |
| 3 | Moderat | Alvorlig ulempe for et begrenset antall personer, eller mindre ulempe for mange. Mulig midlertidig skade | 1 – 10 millioner NOK | Nasjonal medieomtale. Tillitssvekking | Regelbrudd med administrativt gebyr. Datatilsynet involvert |
| 4 | Alvorlig | Alvorlig skade for et betydelig antall personer. Mulig varig skade for enkeltpersoner | 10 – 100 millioner NOK | Internasjonal medieomtale. Varig tillitssvikt | Alvorlig regelbrudd. GDPR-bot (opp til 4 % av global omsetning). Straffeansvar mulig |
| 5 | Katastrofal | Livstruende eller varig alvorlig skade for mange. Kan ramme sårbare grupper systematisk | Over 100 millioner NOK | Varig skade på virksomhetens eksistensgrunnlag | Systemsvikt i regelverksetterlevelse. Stans av virksomhet. Politisk konsekvens |

### Dimensjonsspesifikke presiseringer

**Menneske og samfunn:** Vurder særlig om AI-systemet kan påvirke tilgang til grunnleggende rettigheter (helse, bolig, utdanning, trygd) eller diskriminere systematisk mot beskyttede grupper. Konsekvens-nivå skaleres med antall berørte og varigheten av skaden.

**Økonomi:** Inkluder direkte kostnader (hendelseshåndtering, bøter, erstatning), indirekte kostnader (tapte kontrakter, økt forsikringspremie) og opportunitetskostnader (stans i tjenesteutvikling).

**Omdømme:** For offentlige virksomheter er tillit til det offentlige en selvstendig verdi. Vurder om hendelsen kan svekke innbyggernes tillit til offentlig forvaltning generelt, ikke bare den aktuelle virksomheten.

**Juridisk:** GDPR-brudd som involverer sensitive personopplysninger kan automatisk eskalere til nivå 4–5. AI Act-brudd kan medføre bøter på inntil €35 mill / 7 % (forbudte praksiser, Art. 5) eller €15 mill / 3 % (øvrige brudd, inkl. høyrisiko-krav) av global omsetning, jf. Art. 99.

---

## Del 8: Risikomatrise (5×5) og klassifisering

### Risikomatrise

Risikoscore = Sannsynlighet (S) × Konsekvens (K). Maksimal score = 25.

```
                    KONSEKVENS
                1        2        3        4        5
              Ubetyd   Liten   Moderat  Alvorlig  Katastrofal
          ┌─────────┬────────┬─────────┬─────────┬──────────┐
       5  │    5    │   10   │   15    │   20    │    25    │
S  Svært  │  Grønn  │ Grønn  │  Gul    │  Rød    │   Rød    │
A  høy    ├─────────┼────────┼─────────┼─────────┼──────────┤
N       4 │    4    │    8   │   12    │   16    │    20    │
N  Høy   │  Grønn  │ Grønn  │  Gul    │  Rød    │   Rød    │
L         ├─────────┼────────┼─────────┼─────────┼──────────┤
I       3 │    3    │    6   │    9    │   12    │    15    │
G  Moderat│  Grønn  │ Grønn  │  Gul    │  Gul    │   Rød    │
H         ├─────────┼────────┼─────────┼─────────┼──────────┤
E       2 │    2    │    4   │    6    │    8    │    10    │
T  Lav    │  Grønn  │ Grønn  │  Grønn  │  Grønn  │   Gul    │
          ├─────────┼────────┼─────────┼─────────┼──────────┤
       1  │    1    │    2   │    3    │    4    │     5    │
  Svært   │  Grønn  │ Grønn  │  Grønn  │  Grønn  │  Grønn   │
  lav     └─────────┴────────┴─────────┴─────────┴──────────┘
```

### Risikoklassifisering

| Score | Farge | Risikokategori | Akseptansenivå | Handlingskrav |
|-------|-------|----------------|----------------|---------------|
| 1–7 | Grønn | Lav | Akseptabel | Overvåk. Dokumenter akseptanse. |
| 8–14 | Gul | Moderat | Betinget akseptabel | Tiltak skal planlegges. Akseptanse krever begrunnelse. |
| 15–19 | Rød (lys) | Høy | Ikke akseptabel uten tiltak | Tiltak må implementeres innen 90 dager. |
| 20–25 | Rød (mørk) | Kritisk | Ikke akseptabel | Umiddelbare tiltak eller systempause. Eskaleres til ledelse. |

---

## Del 9: Tiltaksstrategier

### De fire strategiene

| Strategi | Definisjon | Når brukes | AI-kontekst eksempel | Dokumentasjonskrav |
|----------|------------|-----------|---------------------|-------------------|
| **Unngå** | Eliminer risikoen ved å ikke gjennomføre aktiviteten som skaper den | Score ≥ 20, eller der risikoen er fundamental for systemet og ikke kan reduseres tilstrekkelig | Ikke bruke AI til automatiserte vedtak om sosiale ytelser der forklarbarhet ikke kan garanteres | Eksplisitt beslutning fra systemeier. Alternativ løsning dokumentert. |
| **Redusere** | Implementer kontroller som senker sannsynlighet og/eller konsekvens | Score 8–19 (moderat–høy). Risikoen kan kontrolleres teknisk eller organisatorisk | HITL-krav for alle output med score > 3, content safety-filters, PII-scrubbing, strukturert logging | Konkrete kontroller med eier og frist. Forventet score etter tiltak. |
| **Overføre** | Del risikoen med tredjepart (kontrakt, forsikring, SLA) | Score 8–14 (moderat). Risikoen er ekstern og kan håndteres kontraktuelt | SLA med AI-leverandør for oppetid og feilhåndtering; databehandleravtale med DPA-klausuler; ansvarsforsikring | Kontraktsreferanse. Hvem bærer restkostnaden ved hendelse. |
| **Akseptere** | Godta risikoen bevisst etter vurdering | Score 1–7 (lav), eller der kostnad ved tiltak overstiger forventet tap | Akseptere at modellen av og til gir uriktige faktapåstander i intern kunnskapsdeling-kontekst | Eksplisitt akseptanse av navngitt systemeier. Revisjonsdato. Dokumentert begrunnelse. |

### Tiltaksprinsippet: ALARP

ALARP (As Low As Reasonably Practicable) er det grunnleggende prinsippet fra NS 5814 og britisk HMS-rett: risiko skal reduseres til et nivå som er så lavt som det er rimelig praktisk mulig, veid mot kostnad og nytte av ytterligere tiltak.

For AI-systemer i offentlig sektor gjelder et skjerpet ALARP-krav der:
- Tiltak som koster under 1 % av prosjektets totalbudsjett er presumptivt rimelige
- Tiltak som forebygger brudd på grunnleggende rettigheter er presumptivt rimelige uavhengig av kostnad
- Tiltaksvurderingen skal dokumenteres eksplisitt i tiltaksplanen

---

## Del 10: De 7 risikodimensjonene — detaljert veiledning

Dimensjonsrammeverket erstatter det tradisjonelle KIT-rammeverket (Konfidensialitet, Integritet, Tilgjengelighet) med et AI-tilpasset rammeverk som dekker bias, forklarbarhet og juridisk risiko som selvstendige dimensjoner.

### Dimensjon 1: Modellsikkerhet og robusthet (vekt 20 %)

Dekker: Motstandsdyktighet mot angrep, ikke-deterministisk oppførsel, distribusjonsskift, adversarial examples.

**Nøkkelspørsmål:**
- Er modellen beskyttet mot prompt injection og jailbreaking?
- Er det implementert content safety-filtrering på input og output?
- Er modellen testet på out-of-distribution input?
- Finnes det rate limiting og misbruksdeteksjon?
- Er det etablert prosess for håndtering av sikkerhetssårbarheter i modellen?

**Vanlige svakheter:** Manglende input-validering, ukritisk videresending av eksternt innhold til modellen (indirect prompt injection), ingen content safety på felter som tillater fri tekst.

### Dimensjon 2: Dataintegritet og personvern (vekt 20 %)

Dekker: Kvalitet og representativitet av treningsdata og retrieval-data, personvern by design, datasuverenitet.

**Nøkkelspørsmål:**
- Er treningsdataene representativefor alle brukergrupper?
- Er persondata behandlet i samsvar med GDPR og datatilsynets AI-veileder?
- Er det implementert PII-deteksjon og -scrubbing i modellens input og output?
- Er lagring, tilgang og sletting av data dokumentert i en ROPA?
- Er databehandleravtale inngått med alle leverandører som behandler persondata?

**Vanlige svakheter:** Ingen PII-scrubbing av fritekstfelt, manglende databehandleravtale med AI-leverandør, uklar hjemmel for bruk av persondata i RAG-kontekst.

### Dimensjon 3: Bias og diskriminering (vekt 15 %)

Dekker: Skjevheter i treningsdata og output, diskriminering av beskyttede grupper, algoritmisk rettferdighet.

**Nøkkelspørsmål:**
- Er det gjennomført bias-testing på tvers av kjønn, etnisitet, alder og funksjonsnivå?
- Er det etablert mekanismer for å oppdage og korrigere bias i produksjon?
- Er systemet i samsvar med likestillings- og diskrimineringslovens krav?
- Har sårbare grupper samme tilgang og like gode resultater som majoritetsbrukere?

**Vanlige svakheter:** Ingen formell bias-testing, homogen testpopulasjon, manglende representasjon av minoritetsgrupper i evalueringsdata.

### Dimensjon 4: Tilgjengelighet og robusthet (vekt 10 %)

Dekker: Oppetid, degradert drift, katastrofegjenoppretting, avhengighetsrisiko mot skyleverandør.

**Nøkkelspørsmål:**
- Er SLA fra AI-leverandør tilstrekkelig for kritikalitetsnivået?
- Finnes det fallback-mekanismer dersom AI-komponenten er utilgjengelig?
- Er katastrofegjenopprettingsplan (BCDR) dokumentert og testet?
- Hva er konsekvensen av 1 time / 1 dag / 1 uke nedetid?

**Vanlige svakheter:** Ingen fallback til manuell saksbehandling, enkel avhengighet mot én leverandør, manglende BCDR-test.

### Dimensjon 5: Forklarbarhet og sporbarhet (vekt 10 %)

Dekker: Krav til begrunnelse av AI-beslutninger, auditlogging, innsyn og klagerett.

**Nøkkelspørsmål:**
- Kan systemet gi forståelig forklaring på sine beslutninger eller anbefalinger?
- Er alle AI-beslutninger logget med tilstrekkelig kontekst for etterforskning?
- Er det etablert prosess for innsyn og klage (jf. forvaltningsloven § 17 og GDPR Art. 22)?
- Oppbevares logger tilstrekkelig lenge for revisjon?

**Vanlige svakheter:** Svart-boks-modeller uten XAI, utilstrekkelig logging av prompts og output, manglende klagehåndteringsprosess.

### Dimensjon 6: Juridisk og regulatorisk (vekt 15 %)

Dekker: AI Act-klassifisering, GDPR, forvaltningsloven, sektorspesifikke krav, innkjøpsregelverk.

**Nøkkelspørsmål:**
- Er AI Act-risikoklasse vurdert og dokumentert?
- Er det juridisk grunnlag for alle personopplysningsbehandlinger?
- Overholder anskaffelsen regelverket for offentlige innkjøp (anskaffelsesforskriften)?
- Er kontrakt med leverandør gjennomgått av juridisk kompetanse?

**Vanlige svakheter:** Uklar AI Act-klassifisering, manglende hjemmel for profilering, SaaS-kontrakter uten GDPR-klausuler.

### Dimensjon 7: Organisatorisk og menneskelig (vekt 10 %)

Dekker: Kompetanse, HITL-design, endringsledelse, ansvarskultur.

**Nøkkelspørsmål:**
- Er brukerne trent til å bruke AI-systemet kritisk — ikke blindt?
- Er det tydelig hvem som har ansvar for AI-systemets output?
- Er det etablert eskaleringsrutiner for tvilstilfeller?
- Er organisasjonens kapasitet for å overvåke og korrigere systemet tilstrekkelig?

**Vanlige svakheter:** Automation bias (ukritisk tillit til AI), uklart ansvarsforhold mellom IT og fag, manglende opplæringsplan.

---

## Del 11: Terminologimapping

| Norsk begrep | Engelsk ekvivalent | Primær standard |
|--------------|-------------------|-----------------|
| Risiko- og sårbarhetsanalyse (ROS) | Risk and Vulnerability Assessment | NS 5814 |
| Sannsynlighet | Likelihood | ISO 31000 |
| Konsekvens | Impact / Consequence | ISO 31000 |
| Restrisiko | Residual risk | ISO 31000 |
| Trusselaktør | Threat actor | ISO/IEC 27005 |
| Sårbarhet | Vulnerability | ISO/IEC 27005 |
| Kontroll | Control / Safeguard | ISO/IEC 27001 |
| Verdivurdering | Asset valuation | ISO/IEC 27005 |
| Tiltaksplan | Risk treatment plan | ISO 31000 |
| Akseptansenivå | Risk appetite / tolerance | ISO 31000 |
| Forklarbarhet | Explainability / Interpretability | ISO/IEC 23894 |
| Menneskelig tilsyn | Human oversight / HITL | EU AI Act Art. 14 |
| Databehandler | Data processor | GDPR Art. 4(8) |
| Behandlingsansvarlig | Data controller | GDPR Art. 4(7) |
| Personvernkonsekvensvurdering | Data Protection Impact Assessment (DPIA) | GDPR Art. 35 |
| Risikostyringssystem | Risk management system | EU AI Act Art. 9 |
| Høyrisikoklassifisering | High-risk classification | EU AI Act Vedlegg III |
| Distribusjonsskift | Distribution shift / covariate shift | ML-terminologi |
| Prompt injection | Prompt injection | AI-sikkerhet |
| Innebygd personvern | Privacy by design | GDPR Art. 25 |
| ALARP-prinsippet | As Low As Reasonably Practicable | NS 5814 / HMS |

---

## For Cosmo

Bruk denne guiden aktivt under gjennomføring av ROS-analyser:

1. **Standardreferanse:** Sitér alltid relevant standard når du beskriver metodiske valg. Eksempel: "Sannsynlighetsskalaen følger NS 5814:2021 Klausul 5.3 og er tilpasset AI-kontekst per ISO/IEC 23894:2023."

2. **AI Act-klassifisering:** Vurder alltid AI Act-risikoklasse i Fase 1. Bruk Vedlegg III-listen i Del 4 som sjekkliste. Dersom bruksfeltet er uklart, be rekvirenten avklare — feilklassifisering kan ha juridiske konsekvenser etter 2026.

3. **ALARP-dokumentasjon:** For alle risikoer med score ≥ 8 (gul), dokumentér eksplisitt hvorfor valgt tiltaksstrategi er tilstrekkelig i lys av ALARP-prinsippet.

4. **Dimensjonsvekter:** Vektene er normalverdier. For systemer med særlig høy personvernsensitivitet kan Dataintegritet og personvern vektes opp til 30 % og Tilgjengelighet ned til 5 %. Dokumenter avvik fra standardvektene.

5. **Kryssreferanser:** En ROS-rapport er ikke et isolert dokument. Alltid sjekk om DPIA, ADR og leverandørens egne sikkerhetsrapporter eksisterer og trekk inn relevante funn.