ms-ai-architect/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-report-templates.md
Kjell Tore Guttormsen 3a73eeafdc refactor(ms-ai-architect): R13 del 1 — nøytraliser Cosmo-personaen i ref-korpusets headinger, etter å ha rettet en gate som var målt usann to ganger
Ordre 20260912T193441Z-7358817909. Steg 1 var ikke transformen, men å rette
roadmapens R13-gate og få den ratifisert. Gaten `grep -rl "Cosmo"
skills/*/references -> 0` var usann på to uavhengige måter:

1. Ordren fanget den første: 451 av forekomstene er Azure Cosmos DB, ekte
   produktinnhold. Diskriminatoren er ikke bokstaven «s» — `Cosmos <norsk
   substantiv>` er genitiv av personaen (`### Cosmos tonalitet`), mens
   `Cosmos DB`/`CosmosClient`/`cosmos_ru` er produkt.
2. Denne økten fant den andre: 132 persona-forekomster ligger i prosa,
   tabeller, dialog-replikker og proveniens-linjer. Heading-nøytralisering
   kan ikke nå dem, så «0 persona» er uoppnåelig også under den ratifiserte
   formen. Operatøren ratifiserte alternativ A: gaten speiler formen, og de
   132 bokføres til R13b/R14.

Tre korreksjoner av premisser som sto i ordren og STATE:
  «ca 320 produkt»   -> 451 (case-sensitivt nett manglet 327 lowercase
                        TOC-ankre + 99 identifikatorer; sann nevner 1 638)
  «169 headinger»    -> 401. 169 var `^## For Cosmo`-prefikset (168) og var
                        internt inkonsistent med sin egen topp-variant (204)
  «417 matcher ingen
   populasjon»       -> 417 er cosmo-headinger utenfor kodefences; briefens
                        nevner var reell hele tiden

Fence-bevissthet er målt skadelig, ikke nødvendig: begge toggle-regler er
gale på dette korpuset (naiv toggle skjuler en ekte heading i
chain-of-thought-prompting.md, CommonMark-regelen ubalanserer
service-level-documentation-dr.md). Fence-agnostisk deteksjon finner 401
heading-linjer i nøyaktig de samme 40 variantene som fence-bevisst finner
400 i — ingen kodeblokk-linje er byte-identisk til en persona-heading. Derfor
nøkles transformen på 40 enumererte heading-tekster og ignorerer fences. En
ukjent variant kaster; en slug-kollisjon kaster. Ingenting auto-fikses.

TOC-en regenereres ikke, den rettes kirurgisk: alle 327 persona-lenker hadde
lenketekst lik én av de 40 heading-tekstene og anker lik slugify av den
(327/327, 0 avvik), så heading og TOC-entry skrives i samme operasjon og
ingen mellomtilstand etterlater en død lenke.

Ratifisert målform: `For Cosmo`, `For Cosmo Skyberg` og `For arkitekten
(Cosmo)` konvergerer på `For arkitekten`. To filer kolliderte og er adjudisert
ved å lese dem, ikke ved regel.

Verifisering (alle 7 kriterier fra ordren):
  G1 persona på heading-linjer   401 -> 0
  G2 døde fragmentlenker         1 -> 1 (pre-eksisterende, unntatt)
  G3 produkt-forekomster         451 -> 451; `Cosmos DB|Azure Cosmos` 308 = 308
  de 3 kun-produkt-filene        byte-identiske
  nettet validert begge veier    injisert persona feller G1; genitiv feller G1;
                                 produkt-heading og de 3 filene passerer
  hele diffen                    802 heading-linjer + 654 TOC-linjer, ANNET = 0
  linjeantall                    728 lagt til = 728 slettet
  suite                          1120/1120 (1097 + 23 nye)
  validate-plugin                250 PASS / 0 FAIL
  stikkprøve                     10 filer, alle 5 skills, inkl. de 3 mest
                                 produkt-tunge (26/20/19) — kun heading+TOC

Utenfor scope, urørt: de 4 SKILL.md, de 23 commands, CLAUDE.md, README.md,
NOTICE.md, docs/ (alt R14).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-12 22:12:28 +02:00

19 KiB
Raw Blame History

ROS-rapportmaler for AI-systemer

Last updated: 2026-02 Category: Norwegian Public Sector AI Governance Status: Established Practice Formål: Standardiserte rapportmaler for ros-analysis-agent — Quick ROS og Full ROS Type: template


Innhold

Oversikt

To maler for ulike behov og målgrupper. Agenten velger mal basert på brukerens intensjon og tilgjengelig informasjon.

Mal Omfang Typisk lengde Målgruppe Trigger
Quick ROS Top-10 risikoer, trafikklys-dashboard ~50–80 linjer Ledelse, prosjektleder, produkteier --quick flagg eller åpenbart behov
Full ROS Komplett 8-fase NS 5814 prosess ~200–300 linjer Arkitekturrevisjonsråd, DPO, CISO, anskaffelsesansvarlig Standard (default)

Begge maler bruker identiske risiko-ID-serier (R-001, T-001) slik at Quick ROS enkelt kan utvides til Full ROS ved behov.


Mal A: Quick ROS

Bruk denne malen for raske orienteringsanalyser, statusoppdateringer til ledelsen, eller som inngang til en mer fullstendig analyse. Fyll inn alle placeholders markert med [...].

## ROS-analyse (Quick): [Systemnavn]

**Dato:** [YYYY-MM-DD]
**Versjon:** [1.0]
**Vurdert av:** ROS Analysis Agent (ms-ai-architect)
**Rekvirent:** [Navn / rolle]
**Metodikk:** NS 5814:2021 (forenklet), ISO 31000:2018
**Scope:** [Kort én-setnings beskrivelse av systemet og primær bruksflate]
**Klassifisering:** [Åpen / Begrenset / Fortrolig]

---

### Trafikklys per risikodimensjon

Scorene er vektede gjennomsnitt der 1 = svært lav risiko og 5 = svært høy risiko.
Trafikklys: 🟢 ≤ 2.0 (lav) | 🟡 2.1–3.5 (moderat) | 🔴 > 3.5 (høy/kritisk)

| Dimensjon | Vekt | Score | Status | Nøkkelfunn |
|-----------|------|-------|--------|------------|
| Modellsikkerhet og robusthet | 20 % | X.X / 5 | 🟢/🟡/🔴 | [Kritisk observasjon på én linje] |
| Dataintegritet og personvern | 20 % | X.X / 5 | 🟢/🟡/🔴 | [Kritisk observasjon på én linje] |
| Bias og diskriminering | 15 % | X.X / 5 | 🟢/🟡/🔴 | [Kritisk observasjon på én linje] |
| Tilgjengelighet og robusthet | 10 % | X.X / 5 | 🟢/🟡/🔴 | [Kritisk observasjon på én linje] |
| Forklarbarhet og sporbarhet | 10 % | X.X / 5 | 🟢/🟡/🔴 | [Kritisk observasjon på én linje] |
| Juridisk og regulatorisk | 15 % | X.X / 5 | 🟢/🟡/🔴 | [Kritisk observasjon på én linje] |
| Organisatorisk og menneskelig | 10 % | X.X / 5 | 🟢/🟡/🔴 | [Kritisk observasjon på én linje] |

**Vektet totalscore:** X.XX / 5
**Risikokategori:** [Lav / Moderat / Høy / Kritisk]
**Overordnet trafikklys:** 🟢 / 🟡 / 🔴

---

### Top-10 risikoer

Rangert etter risikoscore (Sannsynlighet × Konsekvens, skala 1–5).

| # | Risiko-ID | Risikobeskrivelse | S | K | Score | Anbefalt tiltak |
|---|-----------|-------------------|---|---|-------|-----------------|
| 1 | R-001 | [Kort risikoformulering — hva kan gå galt, for hvem] | X | X | XX | [Konkret tiltaksforslag] |
| 2 | R-002 | [Kort risikoformulering] | X | X | XX | [Konkret tiltaksforslag] |
| 3 | R-003 | [Kort risikoformulering] | X | X | XX | [Konkret tiltaksforslag] |
| 4 | R-004 | [Kort risikoformulering] | X | X | XX | [Konkret tiltaksforslag] |
| 5 | R-005 | [Kort risikoformulering] | X | X | XX | [Konkret tiltaksforslag] |
| 6 | R-006 | [Kort risikoformulering] | X | X | XX | [Konkret tiltaksforslag] |
| 7 | R-007 | [Kort risikoformulering] | X | X | XX | [Konkret tiltaksforslag] |
| 8 | R-008 | [Kort risikoformulering] | X | X | XX | [Konkret tiltaksforslag] |
| 9 | R-009 | [Kort risikoformulering] | X | X | XX | [Konkret tiltaksforslag] |
| 10 | R-010 | [Kort risikoformulering] | X | X | XX | [Konkret tiltaksforslag] |

S = Sannsynlighet (1–5), K = Konsekvens (1–5), Score = S × K (maks 25)

---

### Anbefaling

**[GO / GO med forbehold / NO-GO]**

[2–3 setninger som oppsummerer anbefalingen. Forklar begrunnelsen — hva veier tyngst, og hva er absolutte krav dersom anbefalingen er betinget.]

**Forutsetninger for GO (dersom relevant):**
- [Forutsetning 1]
- [Forutsetning 2]

---

### Neste steg

- [ ] [Tiltak 1 — ansvarlig rolle, frist]
- [ ] [Tiltak 2 — ansvarlig rolle, frist]
- [ ] [Tiltak 3 — ansvarlig rolle, frist]
- [ ] Vurder full ROS dersom systemet skaleres eller scope endres
- [ ] Planlegg revisjon om [6/12] måneder

---

*Generert av ros-analysis-agent (ms-ai-architect). Basert på informasjon oppgitt av rekvirent — ikke ekstern revisjon.*

Mal B: Full ROS

Bruk denne malen for alle AI-systemer som skal i produksjon i offentlig sektor, ved høy risiko-score i Quick ROS, eller der lovkrav (AI Act, sikkerhetsloven, forvaltningsloven) krever dokumentert risikovurdering. Alle faser er obligatoriske.

## ROS-analyse (Full): [Systemnavn]

**Dato:** [YYYY-MM-DD]
**Versjon:** [1.0 / revisjon X.Y]
**Vurdert av:** ROS Analysis Agent (ms-ai-architect)
**Rekvirent:** [Navn, rolle, enhet]
**Godkjent av:** [Navn, rolle — fylles inn manuelt]
**Metodikk:** NS 5814:2021, ISO 31000:2018, ISO/IEC 23894:2023
**Klassifisering:** [Åpen / Begrenset / Fortrolig]
**Gyldig til:** [YYYY-MM-DD — anbefalt 12 måneder eller ved vesentlig endring]

---

### Versjonsoversikt

| Versjon | Dato | Endring | Forfatter |
|---------|------|---------|-----------|
| 1.0 | [YYYY-MM-DD] | Første versjon | ROS Analysis Agent |

---

### Ledelsessammendrag

[3-5 avsnitt for beslutningstakere. Inkluderer:]
- Hva ble vurdert og hvorfor
- Samlet risikonivå (med trafikklys)
- Kritiske funn (røde risikoer) — maks 3
- Overordnet anbefaling (GO / GO med forbehold / NO-GO)
- Neste steg (maks 3 punkter)

---

### Fase 1: Scope og kontekst

#### 1.1 Systemidentifikasjon

| Felt | Verdi |
|------|-------|
| Systemnavn | [Navn] |
| Versjon / iterasjon | [X.Y] |
| Primær bruksflate | [Intern saksbehandling / publikumstjeneste / beslutningsstøtte / etc.] |
| Eierenhet | [Avdeling / direktorat] |
| Systemeier (rolle) | [Tittel] |
| Driftsansvarlig | [Internt / ekstern leverandør: navn] |
| Planlagt produksjonsdato | [YYYY-MM-DD] |

#### 1.2 Organisasjonskontekst

[Beskriv virksomhetens mandat, relevante strategier (digitaliseringsstrategi, AI-strategi), og hvordan dette systemet understøtter dem. 3–5 setninger.]

#### 1.3 Juridisk kontekst

[Liste opp alle relevante lover og regelverk som systemet er underlagt.]

- Forvaltningsloven (vedtaksstøtte, klagerett)
- Personopplysningsloven / GDPR (Art. [XX])
- EU AI Act — risikoklasse: [Uakseptabel / Høy risiko / Begrenset / Minimal]
- Sikkerhetsloven § [XX] (dersom relevant)
- Likestillings- og diskrimineringsloven § [XX]
- Sektorspesifikt: [Lov/forskrift]

#### 1.3.1 EU AI Act-klassifisering

| Kriterie | Vurdering | Kommentar |
|----------|-----------|-----------|
| Annex III-område | [Ja/Nei] | [Hvilket område] |
| Risikoklasse | [Uakseptabel/Høy/Begrenset/Minimal] | [Begrunnelse] |
| Krav utløst | [Art. 9, 13, 14, etc.] | [Spesifikke krav] |

#### 1.4 Avgrensninger

[Hva er eksplisitt utenfor scope for denne analysen. Eksempel: tredjeparts API-sikkerhet dekkes av leverandørs egne ROS.]

---

### Fase 2: Systembeskrivelse

#### 2.1 Funksjonell beskrivelse

[2–4 avsnitt som forklarer hva systemet gjør, hvordan brukere interagerer med det, og hvilke beslutninger eller handlinger det støtter eller automatiserer.]

**AI-komponenttype:** [Generativ AI / klassifisering / anbefaling / prediktiv / NLP / computer vision / hybrid]
**Grad av autonomi:** [Fullt manuelt (HITL alltid) / beslutningsstøtte / semi-autonomt / fullt autonomt]
**Modell(er):** [GPT-4o / Phi-4 / Azure AI Services / etc.]
**Plattform:** [Microsoft Foundry / Copilot Studio / Power Platform / Azure OpenAI / custom]

#### 2.2 Dataflyt

[Tegn enkel ASCII-dataflyt eller beskriv i punkter:]

Bruker → [Grensesnitt] → [Orkestrering / agent] → [AI-modell] → [Output] ↕ [Datakilder: intern DB, SharePoint, eksternt API] ↕ [Logging / auditlog / SIEM]


#### 2.3 Integrasjoner og avhengigheter

| System / tjeneste | Type | Eier | Kritikalitet |
|-------------------|------|------|--------------|
| [Navn] | [Datakilde / API / SSO / etc.] | [Intern/ekstern] | [Høy/Moderat/Lav] |
| [Navn] | [Datakilde / API / SSO / etc.] | [Intern/ekstern] | [Høy/Moderat/Lav] |
| [Navn] | [Datakilde / API / SSO / etc.] | [Intern/ekstern] | [Høy/Moderat/Lav] |

#### 2.4 Brukere og berørte parter

| Gruppe | Antall (estimat) | Rolle | Sårbarhet |
|--------|-----------------|-------|-----------|
| [Saksbehandlere] | [XX] | Primærbruker | [Lav] |
| [Publikum / innbyggere] | [XX] | Sluttmottaker av beslutning | [Varierer] |
| [IT-driftsansvarlig] | [X] | Vedlikehold | [Lav] |
| [Spesielt sårbare grupper] | [Ukjent/XX] | Berørt part | [Høy] |

---

### Fase 3: Verdivurdering

#### 3.1 Informasjonsverdier (assets)

| Asset | Type | Konfidensialitet | Integritet | Tilgjengelighet | Samlet kritikalitet |
|-------|------|-----------------|------------|-----------------|---------------------|
| [Persondata / saksdokumenter] | Data | [1–5] | [1–5] | [1–5] | [Lav/Moderat/Høy/Kritisk] |
| [AI-modell / prompts] | System | [1–5] | [1–5] | [1–5] | [Lav/Moderat/Høy/Kritisk] |
| [Integrasjonsnøkler / API-tokens] | Konfigurasjon | [1–5] | [1–5] | [1–5] | [Lav/Moderat/Høy/Kritisk] |
| [Auditlog / sporingsdata] | Data | [1–5] | [1–5] | [1–5] | [Lav/Moderat/Høy/Kritisk] |

#### 3.2 Kritikalitetsmatrise

| Asset | Konsekvens ved tap (K) | Sannsynlighet for tap (S) | Samlet (K×S) |
|-------|------------------------|---------------------------|---------------|
| [Asset 1] | [1–5] | [1–5] | [1–25] |
| [Asset 2] | [1–5] | [1–5] | [1–25] |

---

### Fase 4: Trusselidentifisering

Trusler er identifisert på tvers av STRIDE-kategorier og AI-spesifikke angrepsvektorer.

| Trussel-ID | Kategori | Trusselaktør | Beskrivelse | STRIDE | Angrepsvei |
|------------|----------|--------------|-------------|--------|------------|
| T-001 | Modellmisbruk | Ekstern aktør | Prompt injection via brukerinnput for å omgå sikkerhetspolicy | Tampering | Brukergrensesnitt |
| T-002 | Dataeksponering | Intern aktør | Utilsiktet eksponering av persondata i AI-generert svar | Information disclosure | Modelloutput |
| T-003 | Tilgjengelighetsangrep | Ekstern aktør | DDoS mot API-endepunkt | Denial of service | Nettverk |
| T-004 | Forsyningskjedeangrep | Trusselaktør | Kompromittering av tredjeparts AI-modell eller SDK | Tampering | Leverandørkjede |
| T-005 | Bias-utnyttelse | Systeminherent | Skjevheter i treningsdata gir diskriminerende output | [N/A — systemisk] | Modellarkitektur |
| T-006 | [Trussel] | [Aktør] | [Beskrivelse] | [STRIDE] | [Vei] |

*Legg til rader etter behov. STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.*

---

### Fase 5: Sårbarhetsanalyse

| Sårbarhet-ID | Knyttet til trussel | Beskrivelse | Eksisterende kontroll | Kontrolleffekt |
|--------------|---------------------|-------------|----------------------|----------------|
| V-001 | T-001 | Manglende input-validering og prompt-sanitering | Content Safety filters (Azure) | Moderat — omgås av avanserte angrep |
| V-002 | T-002 | Ingen systematisk PII-scrubbing av modellsvar | Manuell gjennomgang (delvis) | Lav |
| V-003 | T-003 | Rate limiting ikke implementert i dev-miljø | Azure APIM-kvote (prod) | Høy i prod, lav i test |
| V-004 | T-005 | Ingen formell bias-testing gjennomført | [Ingen] | Ingen |
| V-005 | [Trussel-ID] | [Beskrivelse] | [Kontroll] | [Effekt] |

#### 5.1 Vedlegg O-sjekk: Forsyningskjede og agentrisiko

| Sjekk | Relevant? | Status | Kommentar |
|-------|-----------|--------|-----------|
| MCP-servere / tredjeparts skills | Ja/Nei | [OK/Gap/N/A] | [Detalj] |
| RAG-pipeline med eksterne kilder | Ja/Nei | [OK/Gap/N/A] | [Detalj] |
| Autonome agenter med tool-tilgang | Ja/Nei | [OK/Gap/N/A] | [Detalj] |
| Multi-agent orkestrering | Ja/Nei | [OK/Gap/N/A] | [Detalj] |
| Personlige AI-agenter (Copilot) | Ja/Nei | [OK/Gap/N/A] | [Detalj] |

---

### Fase 6: Risikoanalyse

#### 6.1 Risikoregister

| Risiko-ID | Beskrivelse | Årsak (V-ID) | Konsekvens | S | K | Brutto score | Eksisterende kontroll | Netto score | Eier |
|-----------|-------------|--------------|------------|---|---|--------------|-----------------------|-------------|------|
| R-001 | [Risikoformulering] | V-001 | [Konsekvens] | X | X | XX | [Kontroll] | XX | [Rolle] |
| R-002 | [Risikoformulering] | V-002 | [Konsekvens] | X | X | XX | [Kontroll] | XX | [Rolle] |
| R-003 | [Risikoformulering] | V-003 | [Konsekvens] | X | X | XX | [Kontroll] | XX | [Rolle] |
| R-004 | [Risikoformulering] | V-004 | [Konsekvens] | X | X | XX | [Kontroll] | XX | [Rolle] |
| R-005 | [Risikoformulering] | V-005 | [Konsekvens] | X | X | XX | [Kontroll] | XX | [Rolle] |

S = Sannsynlighet (1–5), K = Konsekvens (1–5), Score = S × K (maks 25)

#### 6.2 Risikomatrise (5×5)

     Konsekvens →
          1       2       3       4       5
        Ubetyd  Liten   Moder   Alvor   Katas
     ┌───────┬───────┬───────┬───────┬───────┐

S 5 │ 5 │ 10 │ 15 │ 20 │ 25 │ ← Rød (> 15) a 4 │ 4 │ 8 │ 12 │ 16 │ 20 │ n 3 │ 3 │ 6 │ 9 │ 12 │ 15 │ ← Gul (8–15) n 2 │ 2 │ 4 │ 6 │ 8 │ 10 │ l 1 │ 1 │ 2 │ 3 │ 4 │ 5 │ ← Grønn (< 8) └───────┴───────┴───────┴───────┴───────┘

Plasser risikoer: R-001[S,K], R-002[S,K] ...


---

### Fase 7: Tiltaksplan

| Tiltak-ID | Adresserer | Tiltaksbeskrivelse | Strategi | Ansvarlig | Frist | Kostnad (est.) | Ny netto score |
|-----------|------------|--------------------|----------|-----------|-------|----------------|----------------|
| M-001 | R-001 | [Konkret tiltaksbeskrivelse] | Redusere | [Rolle] | [YYYY-MM-DD] | [NOK / person-dager] | [XX] |
| M-002 | R-002 | [Konkret tiltaksbeskrivelse] | Redusere | [Rolle] | [YYYY-MM-DD] | [NOK / person-dager] | [XX] |
| M-003 | R-003 | [Konkret tiltaksbeskrivelse] | Overføre | [Rolle] | [YYYY-MM-DD] | [NOK / person-dager] | [XX] |
| M-004 | R-004 | [Konkret tiltaksbeskrivelse] | Akseptere | [Rolle] | [YYYY-MM-DD] | — | [XX] |
| M-005 | R-005 | [Konkret tiltaksbeskrivelse] | Unngå | [Rolle] | [YYYY-MM-DD] | [NOK / person-dager] | [XX] |

Strategier: Unngå | Redusere | Overføre | Akseptere

#### 7.1 Implementeringstidslinje

[Nå]──────[30 dager]──────[60 dager]──────[90 dager]──────[6 mnd] │ │ │ │ │ M-001 M-002 M-003 M-004 Revisjon (kritisk) (høy prio) (moderat) (planlagt)


---

### Fase 8: Restrisiko og akseptanse

#### 8.1 Restrisikovurdering

| Risiko-ID | Beskrivelse | Restrisiko-score | Akseptabelt? | Begrunnelse |
|-----------|-------------|-----------------|--------------|-------------|
| R-001 | [Risiko] | [XX etter tiltak] | Ja / Nei | [Begrunnelse] |
| R-002 | [Risiko] | [XX etter tiltak] | Ja / Nei | [Begrunnelse] |
| R-003 | [Risiko] | [XX etter tiltak] | Ja / Nei | [Begrunnelse] |

**Total restrisiko:** [Lav / Moderat / Høy / Kritisk]

#### 8.2 Akseptanseerklæring

[Dersom restrisiko er akseptabel:]
Systemeier bekrefter at restrisikonivået er akseptabelt og at beskrevne tiltak vil implementeres ihht. tiltaksplan. Systemet kan tas i bruk under forutsetning av at M-[XX] er implementert før produksjonsstart.

**Systemeier (signatur):** _________________________ Dato: __________
**CISO / informasjonssikkerhetsansvarlig:** _________________________ Dato: __________
**DPO (der GDPR-relevant):** _________________________ Dato: __________

---

### Dimensjonsvurdering (sammendrag)

| Dimensjon | Vekt | Brutto score | Netto score (etter tiltak) | Status |
|-----------|------|-------------|---------------------------|--------|
| Modellsikkerhet og robusthet | 20 % | X.X / 5 | X.X / 5 | 🟢/🟡/🔴 |
| Dataintegritet og personvern | 20 % | X.X / 5 | X.X / 5 | 🟢/🟡/🔴 |
| Bias og diskriminering | 15 % | X.X / 5 | X.X / 5 | 🟢/🟡/🔴 |
| Tilgjengelighet og robusthet | 10 % | X.X / 5 | X.X / 5 | 🟢/🟡/🔴 |
| Forklarbarhet og sporbarhet | 10 % | X.X / 5 | X.X / 5 | 🟢/🟡/🔴 |
| Juridisk og regulatorisk | 15 % | X.X / 5 | X.X / 5 | 🟢/🟡/🔴 |
| Organisatorisk og menneskelig | 10 % | X.X / 5 | X.X / 5 | 🟢/🟡/🔴 |
| **Vektet total** | **100 %** | **X.XX / 5** | **X.XX / 5** | 🟢/🟡/🔴 |

**Risikokategori (brutto):** [Lav / Moderat / Høy / Kritisk]
**Risikokategori (netto):** [Lav / Moderat / Høy / Kritisk]

---

### Kryssreferanser

| Dokument | Status | Lenke / referanse |
|----------|--------|-------------------|
| DPIA / PVK | [Gjennomført / Pågår / Ikke påkrevd] | [Dokumentreferanse] |
| Sikkerhetsrevisjon | [Gjennomført / Planlagt / Ikke påkrevd] | [Dokumentreferanse] |
| ADR (Architecture Decision Record) | [Foreligger / Mangler] | [Dokumentreferanse] |
| AI Act conformity assessment | [Gjennomført / Pågår / Ikke påkrevd] | [Dokumentreferanse] |
| Leverandørs egne ROS / pen-test | [Foreligger / Mangler] | [Dokumentreferanse] |

---

### Referanser

- NS 5814:2021 — Krav til risikovurderinger
- ISO 31000:2018 — Risk management — Guidelines
- ISO/IEC 23894:2023 — Information technology — AI — Guidance on risk management
- EU AI Act (2024/1689) — særlig Art. 9 (risk management system) og Art. 13 (transparency)
- Datatilsynets veileder om kunstig intelligens og personvern (2023)
- Digdir Rammeverk for digital samhandling
- NSM Grunnprinsipper for IKT-sikkerhet 2.0
- NIST AI Risk Management Framework 1.0 (2023)

---

*Generert av ros-analysis-agent (ms-ai-architect plugin). Kilde: informasjon oppgitt av rekvirent og offentlig tilgjengelig dokumentasjon. Erstatter ikke ekstern revisjon eller juridisk rådgivning.*

For arkitekten

Bruk Mal A (Quick ROS) når bruker:

  • Eksplisitt ber om rask oversikt eller "quick ROS"
  • Er i tidlig utredningsfase og trenger orienteringsanalyse
  • Allerede har fullstendig ROS og vil ha statusoppdatering

Bruk Mal B (Full ROS) i alle andre tilfeller — spesielt når:

  • Systemet involverer persondata, sensitive kategorier eller automatiserte vedtak
  • AI Act høyrisikoklassifisering er sannsynlig
  • Rekvirent er i anskaffelses- eller godkjenningsfase
  • Systemet driftes i offentlig sektor og berører innbyggere

Begge maler kan leveres på norsk eller engelsk — standard er norsk.