# ROS-scoringsrubrikker (7×5)

**Sist oppdatert:** 2026-02 (v1.0)
**Kategori:** Norwegian Public Sector AI Governance
**Status:** Established Practice
**Formål:** Deterministiske rubrikker for ros-analysis-agent — erstatter vage 1-5 beskrivelser med eksakte, verifiserbare sjekkpunkter

---

## Oversikt

Denne filen definerer **35 rubrikk-celler** (7 dimensjoner × 5 nivåer) med ja/nei-sjekkpunkter for å sikre konsistent, reproduserbar ROS-vurdering av AI-systemer i norsk offentlig sektor. Rammeverket er forankret i NS 5814:2021 (Krav til risikovurdering), ISO 31000:2018 (Risikostyring), ISO/IEC 23894:2023 (AI risk management guidance), og EU AI Act Art. 9 (Risk Management System).

I motsetning til `security-scoring-rubrics-6x5.md` (som vurderer teknisk sikkerhetsnivå) dekker dette rammeverket den helhetlige risikoprofilen til et AI-system — inkludert bias, forklarbarhet, juridisk compliance, og organisatorisk modenhet.

### Scoringsregel (gjelder alle celler)

Hver celle inneholder 5 sjekkpunkter. Regelen er:

| Antall "Ja" | Score |
|-------------|-------|
| 5/5 | 5 — Excellent |
| 4/5 | 4 — Good |
| 3/5 | 3 — Adequate |
| 2/5 | 2 — Poor |
| 0-1/5 | 1 — Critical |

**Merk:** Sjekkpunktene er kumulative — høyere score forutsetter at grunnleggende kontroller er på plass. Agenten dokumenterer evidens for hvert sjekkpunkt som grunnlag for score-begrunnelse. Tvilstilfeller rundes ned (ikke opp).

---

## Vektingsmodell

| # | Dimensjon | Vekt | Begrunnelse |
|---|-----------|------|-------------|
| 1 | Modellsikkerhet | 20 % | AI-spesifikke angrep (prompt injection, jailbreak, data poisoning) er unike for AI-systemer og krever særskilte kontroller |
| 2 | Dataintegritet og konfidensialitet | 20 % | Personopplysninger og sensitiv forvaltningsdata krever sterk beskyttelse i henhold til Personopplysningsloven og GDPR |
| 3 | Bias og diskriminering | 15 % | Diskriminering i offentlige tjenester er lovbrudd (Likestillings- og diskrimineringsloven) og kjernerisiko ved AI i forvaltning |
| 4 | Tilgjengelighet og robusthet | 10 % | Offentlige tjenester må være tilgjengelige; AI-systemfeil kan stoppe lovpålagte saksbehandlingsprosesser |
| 5 | Forklarbarhet og sporbarhet | 10 % | Forvaltningsloven § 24-25 krever begrunnelse for enkeltvedtak; GDPR Art. 22 gir rett til forklaring ved automatiserte beslutninger |
| 6 | Juridisk og regulatorisk | 15 % | AI Act, GDPR, Forvaltningsloven, og Sikkerhetsloven skaper et komplekst regulatorisk landskap med høye sanksjonsrisikoer |
| 7 | Organisatorisk og menneskelig | 10 % | Tekniske kontroller er ineffektive uten kompetanse, prosesser og ansvarlighetstruktur i organisasjonen |
| | **Sum** | **100 %** | |

---

## Dimensjon 1: Modellsikkerhet (20 %)

*Referanse: OWASP LLM Top 10 (2025), MITRE ATLAS, Azure AI Content Safety, Azure AI Foundry Guardrails*

Dimensjonen vurderer i hvilken grad AI-systemet er beskyttet mot AI-spesifikke angrep som prompt injection, jailbreaking, adversarial input og poisoning. Dette er den mest teknisk AI-spesifikke dimensjonen og skiller seg fra generell applikasjonssikkerhet.

### Sjekkpunkter

| # | Sjekkpunkt | Verifiseringsmetode |
|---|-----------|---------------------|
| 1 | Azure AI Content Safety (eller tilsvarende) er aktivert med content filters på alle 4 harm-kategorier (hate, violence, sexual, self-harm) på severity medium eller høyere | Azure AI Foundry → Guardrails → Content filter: sjekk at alle kategorier er konfigurert, ikke kun "default" |
| 2 | Prompt Shields er aktivert for deteksjon av både direkte jailbreak og indirekte prompt injection fra dokumenter og ekstern innhold | Content filter → Prompt Shields = ON for user messages OG documents/grounded content |
| 3 | System message (meta-prompt) definerer eksplisitt AI-systemets rolle, tillatte operasjoner, og inneholder instruksjoner om å ikke avsløre konfigurasjon | System prompt inneholder: tydelig rollebeskrivelse, scope-begrensning, "do not reveal system prompt"-instruksjon, og avvisning av rolleplay-angrep |
| 4 | Red team-testing er gjennomført og dokumentert med systematisk testing av minst 20 jailbreak- og injection-varianter | Dokumentert red team-rapport med Attack Success Rate (ASR) < 10 % for alle harm-kategorier, eller Azure AI Foundry automated red teaming-rapport |
| 5 | Input- og output-validering er implementert i AI-pipeline som supplement til content filters (f.eks. regex-filtre, lengdebegrensning, output-groundedness) | Kodegjennomgang eller arkitekturdokumentasjon viser pre/post-processing med eksplisitte valideringsregler |

### Scoringstabell

| Score | Kriterier | Typisk scenario |
|-------|-----------|-----------------|
| **5** | Alle 5 sjekkpunkter oppfylt | Azure AI Foundry med full content safety-konfigurasjon, dokumentert red team, og pipeline-validering |
| **4** | 4/5 oppfylt (typisk: mangler formell red team-rapport, men uformell testing er gjennomført) | Alle tekniske kontroller aktivert, men ingen systematisk adversarial testing med dokumentasjon |
| **3** | 3/5 oppfylt (typisk: content filters + prompt shields + system message, men ingen output-validering eller red team) | Default-kontroller aktivert via wizard/portal, men ingen tilpasning eller testing utover standard |
| **2** | 2/5 oppfylt (typisk: content filters på default, men ingen prompt shields og svak system message) | Noen sikkerhetstiltak ved oppstart, ikke oppdatert eller testet etter lansering |
| **1** | 0-1/5 oppfylt | Ingen content safety-kontroller aktivert, system message mangler, ingen testing gjennomført |

---

## Dimensjon 2: Dataintegritet og konfidensialitet (20 %)

*Referanse: GDPR Art. 5 (dataminimering, formålsbegrensning), Art. 32 (sikkerhet), Personopplysningsloven, Azure Data Protection baseline, MCSB v2 DP*

Dimensjonen vurderer om data som brukes av, sendes til, og produseres av AI-systemet er beskyttet mot uautorisert tilgang, lekkasje, korrupsjon og misbruk. Inkluderer kryptering, tilgangskontroll, dataresidens og PII-håndtering.

### Sjekkpunkter

| # | Sjekkpunkt | Verifiseringsmetode |
|---|-----------|---------------------|
| 1 | All kommunikasjon til og fra AI-tjenester er kryptert med TLS 1.2 eller høyere, og kryptering i hvile benytter minst platform-managed keys (ideelt Customer-Managed Keys) | Azure Policy-rapport: minimum TLS version = 1.2 på alle ressurser; Key Vault CMK-referanse verifisert for sensitive ressurser |
| 2 | Data residency er sikret i godkjente Azure-regioner (Norway East/Norway West) og ingen ufrivillig dataoverføring til regioner utenfor EU/EØS | Alle AI-ressurser i norwayeast/norwaywest; Azure Policy for tillatte regioner; global deployment av Azure OpenAI er unntatt med dokumentert begrunnelse |
| 3 | Tilgangskontroll til data (treningsdata, RAG-indeks, samtalelogger) er implementert med prinsippet om minste privilegium og dokumentert rollestruktur | RBAC-gjennomgang: ingen "Owner"-tildeling uten PIM, rollestruktur dokumentert, Azure AI Search med document-level security trimming |
| 4 | PII-deteksjon og/eller redaksjon er implementert i AI-pipeline (minst én av: input-filtrering, output-filtrering, eller database-pseudonymisering) | Azure AI Content Safety PII-deteksjon aktivert, eller Microsoft Presidio/custom PII-filter verifisert i kodebasen |
| 5 | Dataminimering er implementert — AI-systemet behandler og lagrer ikke mer data enn nødvendig for formålet, og dataretensjonspolicyer er definert og teknisk håndhevet | Dataflytdiagram dokumenterer hvilke data som lagres hvor og hvor lenge; Azure Policy for storage lifecycle management; samtalelogger slettes etter X dager |

### Scoringstabell

| Score | Kriterier | Typisk scenario |
|-------|-----------|-----------------|
| **5** | Alle 5 sjekkpunkter oppfylt | CMK-kryptering + Norway region + dokumentert RBAC + PII-filter + dataminimering med teknisk håndhevede retensjonspolicyer |
| **4** | 4/5 oppfylt (typisk: dataminimering og retensjonspolicyer mangler teknisk håndhevelse, kun dokumentert) | Sterk datakryptering og tilgangskontroll, men dataretensjon håndteres manuelt |
| **3** | 3/5 oppfylt (typisk: TLS + platform-managed encryption + Norway region, men ingen PII-filter og svak RBAC) | Grunnleggende databeskyttelse på plass, mangler PII-filtrering og finkornet tilgangskontroll |
| **2** | 2/5 oppfylt (typisk: TLS + platform-managed encryption, men feil region og ingen PII-kontroller) | Minimumsimplementasjon: trafikk kryptert men ingen dataresidens-kontroll eller PII-håndtering |
| **1** | 0-1/5 oppfylt | Ukjent krypteringsstatus, data behandlet i feil region, ingen tilgangskontroll eller PII-håndtering |

---

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

*Referanse: Likestillings- og diskrimineringsloven (2017) §§ 6-13, EU AI Act Art. 10 (training data requirements for high-risk AI), ISO/IEC 23894:2023 §6.3 (bias), Azure ML Responsible AI Dashboard*

Dimensjonen vurderer om AI-systemet aktivt identifiserer, måler og håndterer bias og diskrimineringsrisiko. Dette er en kjernerisk for AI i norsk offentlig forvaltning der likeverdig behandling er et lovkrav og et demokratisk prinsipp.

### Sjekkpunkter

| # | Sjekkpunkt | Verifiseringsmetode |
|---|-----------|---------------------|
| 1 | Fairness-evaluering er gjennomført og dokumentert — ytelsen er målt og sammenlignet på tvers av relevante demografiske grupper (alder, kjønn, geografisk tilhørighet, språkbakgrunn) | Fairness-rapport med metriker (demographic parity, equalized odds, accuracy per gruppe) foreligger; Azure ML Responsible AI Dashboard brukt |
| 2 | Treningsdata er gjennomgått for representasjonsbalanse og historisk bias, og mangler er dokumentert med kompenserende tiltak | Datakvalitetsrapport med statistisk analyse av grupperepresentasjon; tiltak som resampling, synthetic augmentation eller ekskludering er dokumentert |
| 3 | Human-in-the-loop (HITL) er implementert for alle AI-anbefalinger som kan påvirke borgeres rettigheter (stønader, tillatelser, tjenester, prioritering) | Prosessbeskrivelse bekrefter at saksbehandler alltid vurderer og godkjenner AI-anbefalinger; ingen automatiske vedtak uten menneskelig oversyn |
| 4 | Kontinuerlig overvåking av modellens ytelse per demografisk gruppe er implementert i produksjon med alarmering ved statistisk signifikant avvik | Azure ML data drift monitoring eller custom fairness-metriker i Azure Monitor; alarmer konfigurert for F1-score-avvik > 5 % mellom grupper |
| 5 | Organisasjonen har gjennomgått en ekstern eller intern bias-audit av AI-systemet, og funnene er dokumentert og håndtert | Ekstern revisjonsrapport eller intern revisors gjennomgang med sporbar oppfølging av funn i issue-tracker |

### Scoringstabell

| Score | Kriterier | Typisk scenario |
|-------|-----------|-----------------|
| **5** | Alle 5 sjekkpunkter oppfylt | Dokumentert fairness-evaluering + dataanalyse + HITL + produksjonsovervåking + ekstern bias-audit |
| **4** | 4/5 oppfylt (typisk: ekstern bias-audit mangler, men intern gjennomgang er gjennomført) | Solide tekniske fairness-kontroller og HITL, men ingen uavhengig revisjon |
| **3** | 3/5 oppfylt (typisk: HITL er implementert og noe fairness-evaluering er gjort, men produksjonsovervåking og dataanalyse mangler) | Menneskelig oversyn reduserer risiko, men ingen systematisk fairness-testing eller kontinuerlig overvåking |
| **2** | 2/5 oppfylt (typisk: HITL finnes, men uten dokumentert fairness-evaluering eller dataanalyse) | Menneskelig oversyn som eneste skranke mot diskriminering; ingen proaktive bias-tiltak |
| **1** | 0-1/5 oppfylt | Ingen HITL, ingen fairness-evaluering, ingen bias-bevissthet i organisasjonen |

---

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

*Referanse: ISO 22301:2019 (Business Continuity), NS-EN 301 549 (tilgjengelighet), Azure SLA-er, Internkontrollforskriften*

Dimensjonen vurderer om AI-systemet er tilstrekkelig robust og tilgjengelig — inkludert failover-mekanismer, kapasitetsplanlegging, BCDR og fallback til manuelle prosesser. Offentlige tjenester har lovpålagte saksbehandlingstider som ikke kan suspenderes ved AI-nedetid.

### Sjekkpunkter

| # | Sjekkpunkt | Verifiseringsmetode |
|---|-----------|---------------------|
| 1 | SLA-krav er definert for AI-komponenten og er kontraktsmessig forankret i avtale med Microsoft (og eventuelle underleverandører), og samsvarer med virksomhetens krav til tjenestekontinuitet | SLA-dokumentasjon viser krav (f.eks. 99,9 % oppetid) og Microsoft Azure SLA bekrefter at tjenesten dekker dette; avvik er akseptert og dokumentert |
| 2 | Kapasitetsplanlegging er gjennomført med belastningstesting, og Azure OpenAI PTU (Provisioned Throughput Units) eller tilsvarende kapasitetsreservasjon er aktivert for produksjonskritiske systemer | Belastningstestrapport med dokumenterte peak-scenarier; PTU-avtale eller dokumentert begrunnelse for TPM-basert provisjonering |
| 3 | Fallback-prosedyre til manuell saksbehandling er dokumentert, testet og kjent av saksbehandlerne — AI-nedetid medfører ikke full stopp i lovpålagte saksbehandlingsprosesser | BCDR-plan med AI-specifik section; øvelsesprotokoll viser at fallback er gjennomgått; saksbehandlere kjenner prosedyren |
| 4 | Multi-region redundans eller aktiv failover er konfigurert for kritiske AI-komponenter | Azure AI Foundry eller Azure OpenAI deployert i minst 2 Azure-regioner med load balancing, ELLER dokumentert aksept av single-region risiko |
| 5 | AI-systemet er designet med graceful degradation — det fungerer i en redusert "uten AI"-modus som gir begrenset men funksjonell service ved AI-komponentfeil | Systemarkitekturen viser at kjernesystemet (saksbehandlingssystem, portal) fungerer uavhengig av AI-komponenten; AI er supplement, ikke enkeltfeilpunkt |

### Scoringstabell

| Score | Kriterier | Typisk scenario |
|-------|-----------|-----------------|
| **5** | Alle 5 sjekkpunkter oppfylt | PTU + dokumentert og testet fallback + multi-region + graceful degradation + SLA-avtale |
| **4** | 4/5 oppfylt (typisk: multi-region mangler, men fallback-prosedyre er solid) | Robust kapasitetsplanlegging og BCDR, men AI-systemet kjører kun i én region |
| **3** | 3/5 oppfylt (typisk: SLA-krav definert + fallback dokumentert + kapasitetstest gjennomført, men ingen multi-region og graceful degradation ikke testet) | Grunnleggende beredskapsplanlegging, men arkitektonisk robusthet er begrenset |
| **2** | 2/5 oppfylt (typisk: SLA-krav definert + noen ideer om fallback, men ikke dokumentert eller testet) | AI-nedetid vil sannsynligvis medføre tjenesteforstyrrelser; beredskapen er ikke reell |
| **1** | 0-1/5 oppfylt | AI-systemet er kritisk avhengighet uten alternativ; ingen beredskapsplan eksisterer |

---

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

*Referanse: Forvaltningsloven §§ 24-25 (begrunnelsesplikt), GDPR Art. 22 (automatiserte beslutninger), EU AI Act Art. 13 (transparency), AI Act Art. 14 (human oversight)*

Dimensjonen vurderer om AI-systemets beslutningsprosess er sporbar og forklarbar for saksbehandlere, borgere og revisorer. Dette er en forutsetning for klagebehandling, internkontroll og lovlig bruk av AI i enkeltvedtak.

### Sjekkpunkter

| # | Sjekkpunkt | Verifiseringsmetode |
|---|-----------|---------------------|
| 1 | Alle AI-interaksjoner som inngår i beslutningsgrunnlag for enkeltvedtak er logget med tidsstempel, bruker-ID, input, output og eventuell modellversjon — og loggen oppbevares i minimum 5 år i henhold til arkivlovens krav | Log Analytics workspace med komplette AI-interaksjonslogger; retensjonspolicy satt til ≥ 5 år; immutable storage aktivert |
| 2 | Saksbehandlere kan på forespørsel fremvise hvilken AI-anbefaling som lå til grunn for et vedtak, og hvilke kilder/dokumenter som ble brukt (for RAG-systemer) | UI-funksjonalitet eller manuell logg-søkeprosess gir saksbehandler tilgang til AI-anbefalingen for en spesifikk sak; RAG-kildereferanser er inkludert i svar |
| 3 | Systemet presenterer eksplisitt kildehenvisning og/eller konfidensgrad for AI-genererte anbefalinger, og brukeren gjøres oppmerksom på at innholdet er AI-generert (AI Act Art. 50/52 transparenskrav) | UI viser "Generert av AI" med kildereferanser; ikke presentert som autorativt faktum; konfidensgrad eller forbehold inkludert |
| 4 | For klassifikasjons- og beslutningsmodeller (ikke generative) er feature importance implementert og tilgjengelig for faglig gjennomgang (SHAP, LIME eller tilsvarende) | Azure ML Responsible AI Dashboard med SHAP-visualisering for modellen; eller tilsvarende XAI-rapport verifisert i kodebasen |
| 5 | Virksomheten har en dokumentert prosedyre for håndtering av borgerkrav om innsyn i AI-beslutninger (GDPR Art. 15, Forvaltningsloven § 18), og prosedyren er testet | Prosedyre for "rett til forklaring" finnes i rutinehåndbok; ansvarlig rolle er definert; minst én testkjøring er gjennomført og dokumentert |

### Scoringstabell

| Score | Kriterier | Typisk scenario |
|-------|-----------|-----------------|
| **5** | Alle 5 sjekkpunkter oppfylt | Fullstendig revisjonslogg + saksbehandlertilgang + kildevisning med AI-merking + XAI-dashboard + testet innsynsprosedyre |
| **4** | 4/5 oppfylt (typisk: XAI for klassifikasjonsmodeller mangler fordi systemet bruker generativ AI der SHAP ikke er direkte anvendbart) | Solid logging og sporbarhet, men forklarbarhet er begrenset til kildevisning og konfidensgrad |
| **3** | 3/5 oppfylt (typisk: logging finnes + kildevisning + AI-merking, men ingen prosedyre for borgerkrav og begrenset saksbehandlertilgang til historiske logger) | Grunnleggende transparens overfor løpende brukere, men ikke egnet for etterfølgende revisjon eller klagebehandling |
| **2** | 2/5 oppfylt (typisk: logging finnes + noe kildevisning, men sporbarhet er ikke god nok for klagebehandling) | Minimumskrav for transparens delvis oppfylt; ikke egnet for forvaltningsrettslig revisjon |
| **1** | 0-1/5 oppfylt | Ingen logging av AI-interaksjoner i beslutningsgrunnlag; umulig å rekonstruere grunnlag for vedtak |

---

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

*Referanse: GDPR/Personopplysningsloven, EU AI Act (EØS-relevant), Forvaltningsloven, Sikkerhetsloven, Schrems II (Datatilsynets veileder), Digdir-arkitekturprinsipper*

Dimensjonen vurderer om AI-systemet er juridisk forankret og opererer i samsvar med gjeldende regelverk. Dette er den dimensjonen med høyest potensiell konsekvens — feilklassifisering eller manglende compliance kan medføre sanksjoner, krav om systemnedstengning, og straffeansvar for organisasjonen.

### Sjekkpunkter

| # | Sjekkpunkt | Verifiseringsmetode |
|---|-----------|---------------------|
| 1 | DPIA (Personvernkonsekvensutredning etter GDPR Art. 35) er gjennomført og godkjent av personvernombud for AI-systemet, med dokumentert risikomatrise og tiltakstabell | DPIA-dokument med signatur fra personvernombud og eventuelt Datatilsynet; inkluderer AI-spesifikke risikoer og tiltak |
| 2 | AI Act risikoklassifisering er utført og dokumentert (unacceptable/high/limited/minimal risk per AI Act Art. 6 og Annex III), med tilhørende tiltak implementert | Klassifiseringsdokument med begrunnelse per Annex III-kriterier; for high-risk: conformity assessment, teknisk dokumentasjon, og human oversight-prosedyre |
| 3 | Schrems II-vurdering er dokumentert og oppdatert — enten er EU Data Boundary aktivert, eller Transfer Impact Assessment (TIA) er gjennomført og godkjent | EU Data Boundary aktivert for Microsoft 365 og Azure (sjekk Microsoft 365 admin center); ELLER TIA-dokument datert < 12 måneder siden |
| 4 | Behandlingsgrunnlag etter GDPR Art. 6 (og Art. 9 for særlige kategorier) er identifisert og dokumentert for alle personopplysningsbehandlinger i AI-systemet | Behandlingsprotokoll (Art. 30-register) oppdatert med AI-systemet; hjemmel og formål dokumentert; informasjonsplikt etter Art. 13/14 oppfylt |
| 5 | Databehandleravtale (DPA) med Microsoft og alle relevante tredjeparter er signert og er dekkende for faktisk behandling — inkludert AI-tjenestene som brukes | Gjeldende Microsoft DPA (Azure, M365) er akseptert; sub-processor liste er gjennomgått; ingen behandling skjer uten DPA |

### Scoringstabell

| Score | Kriterier | Typisk scenario |
|-------|-----------|-----------------|
| **5** | Alle 5 sjekkpunkter oppfylt | Komplett compliance-dokumentasjon: DPIA + AI Act-klassifisering + Schrems II + behandlingsgrunnlag + DPA |
| **4** | 4/5 oppfylt (typisk: Schrems II TIA mangler, men EU Data Boundary er aktivert; eller AI Act-klassifisering er gjennomført men tiltak ikke fullt implementert) | Solid juridisk grunnlag, ett regulatorisk gap som er under utbedring |
| **3** | 3/5 oppfylt (typisk: DPIA + DPA + behandlingsgrunnlag på plass, men AI Act-klassifisering og Schrems II TIA ikke adressert) | Grunnleggende GDPR-compliance, men AI-spesifikt regelverk ikke håndtert |
| **2** | 2/5 oppfylt (typisk: DPA signert + behandlingsgrunnlag identifisert, men DPIA mangler og AI Act ikke vurdert) | Minimal juridisk forankring; stor eksponering mot GDPR- og AI Act-sanksjoner |
| **1** | 0-1/5 oppfylt | Ingen DPIA, ukjent rettslig grunnlag, AI Act ikke kjent; uakseptabel regulatorisk risiko |

---

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

*Referanse: ISO 31000:2018 §6.4 (organizational context), Internkontrollforskriften, Digdir-prinsipp 4 (tillit og sikkerhet), NSM Grunnprinsipper for IKT-sikkerhet (organisasjonsperspektivet)*

Dimensjonen vurderer om organisasjonen har nødvendig kompetanse, tydelig ansvarsfordeling, etablerte prosesser og en kultur som understøtter ansvarlig og sikker AI-bruk. Tekniske kontroller uten organisatorisk understøttelse er utilstrekkelige.

### Sjekkpunkter

| # | Sjekkpunkt | Verifiseringsmetode |
|---|-----------|---------------------|
| 1 | Ansvar for AI-systemets sikkerhet og risikostyring er tydelig fordelt og dokumentert — med navngitt systemeier, personvernombud-involvering, og fagansvarlig for AI-etikk | RACI-matrise eller tilsvarende ansvarsdokument finnes; rollene er besatt med navngitte personer; systemeierskapet er formelt delegert i organisasjonskartet |
| 2 | Saksbehandlere og andre brukere av AI-systemet har gjennomgått opplæring i systemets muligheter og begrensninger, og vet når de skal overstyre AI-anbefalinger | Opplæringsplan finnes; deltakerliste for gjennomført opplæring; opplæringen dekker eksplisitt "når stoler du ikke på AI?" |
| 3 | Virksomheten har en AI-policy eller retningslinje for ansvarlig AI-bruk som er vedtatt av ledelsen og kommunisert til alle ansatte | Vedtatt AI-policy finnes, datert < 2 år siden; kommunisert via intranett, all-hands, eller lignende kanal; ansatte kan referere til den |
| 4 | Det finnes en prosedyre for rapportering og håndtering av AI-hendelser og uønsket AI-atferd (hallusinasjoner, bias-observasjoner, sikkerhetshendelser), og ansatte vet hvem de skal kontakte | Hendelsesprosedyre for AI finnes i rutinehåndbok; ansatte er informert om rapporteringskanal; minst én reell rapportering er gjennomgått |
| 5 | ROS-analysen er sist revidert innenfor 12 måneder, og det er planlagt revisjon ved vesentlige endringer (ny funksjonalitet, ny lovgivning, ny modell, nye datakilder) | ROS-rapport har revisjonsdato < 12 måneder; neste revisjonstidspunkt er planlagt i kalender; endringslogg viser at ROS følger systemets utvikling |

### Scoringstabell

| Score | Kriterier | Typisk scenario |
|-------|-----------|-----------------|
| **5** | Alle 5 sjekkpunkter oppfylt | Tydelig ansvarsstruktur + dokumentert opplæring + vedtatt AI-policy + hendelsesprosedyre + løpende ROS-revisjon |
| **4** | 4/5 oppfylt (typisk: ROS-revisjon er planlagt men ikke gjennomført innenfor 12 måneder, eller hendelsesprosedyre eksisterer men er ikke kommunisert bredt) | God organisatorisk struktur, ett prosessgap som håndteres |
| **3** | 3/5 oppfylt (typisk: ansvarsfordeling + opplæring + AI-policy, men ingen formell hendelsesprosedyre og ROS ikke revidert på over et år) | Grunnleggende organisatorisk bevissthet, men ikke operasjonalisert i alle prosesser |
| **2** | 2/5 oppfylt (typisk: ansvarsfordeling finnes + noe opplæring, men ingen AI-policy, ingen hendelsesprosedyre, og ROS er ikke revidert) | Enkeltpersoners bevissthet bærer organisasjonens risikostyring; ikke institusjonalisert |
| **1** | 0-1/5 oppfylt | Uklar ansvarsfordeling, ingen opplæring, ingen AI-policy; organisasjonen har ikke tatt eierskap til AI-risiko |

---

## Totalscoreberegning

### Formel

```
Totalscore = Σ (Dimensjonscore × Vekt)
           = (D1 × 0.20) + (D2 × 0.20) + (D3 × 0.15) + (D4 × 0.10)
           + (D5 × 0.10) + (D6 × 0.15) + (D7 × 0.10)

Maks: 5.00, Min: 1.00
```

**Eksempel:**

```
D1=3, D2=3, D3=2, D4=3, D5=2, D6=3, D7=3

= (3 × 0.20) + (3 × 0.20) + (2 × 0.15) + (3 × 0.10)
+ (2 × 0.10) + (3 × 0.15) + (3 × 0.10)
= 0.60 + 0.60 + 0.30 + 0.30 + 0.20 + 0.45 + 0.30
= 2.75
```

### Risikokategori-mapping

| Totalscore | Risikokategori | Anbefalt handling |
|------------|----------------|-------------------|
| 4.50 – 5.00 | **Lav risiko** | Vedlikehold nåværende nivå, gjennomfør ROS-revisjon innen 12 måneder |
| 3.50 – 4.49 | **Moderat risiko** | Adresser identifiserte gap innen 1-3 måneder; ingen umiddelbar risiko for nedstenging |
| 2.50 – 3.49 | **Høy risiko** | Prioriter utbedring innen 2-4 uker; ledelsen informeres; vurder begrensning av scope |
| 1.50 – 2.49 | **Kritisk risiko** | Umiddelbar handling påkrevd; vurder å suspendere systemer som tar beslutninger med høy konsekvens |
| < 1.50 | **Uakseptabel risiko** | Stopp produksjonsdrift, full gjennomgang, ikke start igjen uten godkjenning fra ledelse og personvernombud |

### Absolutte triggere (overstyrer totalscore)

Uavhengig av beregnet totalscore skal risikokategorien oppgraderes til **Kritisk** dersom ett eller flere av disse er oppfylt:

- **Dimensjon 6 (Juridisk og regulatorisk) ≤ 1** — Ingen DPIA for et system som behandler personopplysninger er et aktivt lovbrudd
- **Dimensjon 3 (Bias) ≤ 1 og systemet er borgermøtende** — Ingen HITL og ingen fairness-evaluering for et system som påvirker borgeres rettigheter er uakseptabelt
- **Dimensjon 5 (Forklarbarhet) ≤ 1 og systemet brukes i enkeltvedtak** — Umulig å etterleve Forvaltningsloven § 24-25 uten logging
- **3 eller flere dimensjoner scorer ≤ 2** — Systemomfattende kontrollsvikt som ikke kan løses med enkeltpunkt-tiltak

---

## Referansecaser

### Case A: Intern kunnskapsassistent (chatbot med SharePoint RAG)

**Scenario:** Copilot Studio chatbot for interne saksbehandlere i en norsk statsforvaltning. Besvarer spørsmål om interne prosedyrer, regelverk og saksbehandlingsrutiner. Basert på SharePoint-dokumentbibliotek (ikke-sensitivt). Kun tilgjengelig for ansatte med M365 E5-lisens. AI-anbefalinger brukes som støtte, ikke som vedtaksgrunnlag.

| Dimensjon | Forventet score | Begrunnelse |
|-----------|----------------|-------------|
| Modellsikkerhet | **3** | Copilot Studio har innebygde guardrails og topic-avgrensning, men ingen custom red team-testing og begrenset output-validering |
| Dataintegritet og konfidensialitet | **4** | TLS 1.2 (Microsoft-managed), SharePoint kryptert, Norway-region, DLP via M365 E5 — men CMK sjelden og PII-filter ikke typisk konfigurert for intern SharePoint |
| Bias og diskriminering | **4** | HITL er implisitt (saksbehandler vurderer AI-svar), men ingen formell fairness-evaluering eller bias-audit; risikoen er lav fordi svar ikke tas direkte som vedtak |
| Tilgjengelighet og robusthet | **3** | Saksbehandlere vet å jobbe uten AI ved nedetid; ingen formell BCDR-plan for AI, ingen PTU |
| Forklarbarhet og sporbarhet | **3** | M365 audit logs finnes; Copilot Studio viser kildereferanser; men ingen formell prosedyre for borgerkrav om innsyn og logger ikke designet for juridisk bruk |
| Juridisk og regulatorisk | **3** | DPA med Microsoft eksisterer; AI Act-klassifisering er typisk "minimal risk" og ikke formelt dokumentert; ingen DPIA (siden ikke personopplysninger i RAG-basen) |
| Organisatorisk og menneskelig | **3** | Ansvarsfordeling finnes; noe opplæring; men ingen AI-policy vedtatt av ledelsen og ingen formell hendelsesprosedyre for AI |

**Totalscore:**
```
= (3 × 0.20) + (4 × 0.20) + (4 × 0.15) + (3 × 0.10)
+ (3 × 0.10) + (3 × 0.15) + (3 × 0.10)
= 0.60 + 0.80 + 0.60 + 0.30 + 0.30 + 0.45 + 0.30
= 3.35
```

**Risikokategori: Høy risiko** — Systemet er lavkritisk, men scorer under 3.50 pga. manglende AI-policy, BCDR og formell fairness-evaluering. Viktigste quick-win: vedta AI-policy (D7) og dokumenter AI Act-klassifisering som minimal risk (D6).

---

### Case B: Borgermøtende vedtaksstøttesystem med sensitive data

**Scenario:** Azure AI Foundry-basert system som assisterer saksbehandlere ved vurdering av søknader om offentlige tjenester (f.eks. tilskudd, støtteordninger). Systemet analyserer søknadstekst og støttedokumenter og gir en anbefaling med begrunnelse. Saksbehandler fatter det formelle vedtaket. Systemet behandler personopplysninger inkludert økonomidata og helseopplysninger.

| Dimensjon | Forventet score | Begrunnelse |
|-----------|----------------|-------------|
| Modellsikkerhet | **3** | Content filters aktivert (medium+), system message med rolleavgrensning, prompt shields ON — men ingen dokumentert red team-testing og output-validering for norsk kontekst er ufullstendig |
| Dataintegritet og konfidensialitet | **3** | TLS 1.2, Norway East region, noe tilgangskontroll — men CMK typisk ikke implementert for AI Search, PII-filter for norsk fødselsnummer/helseopplysninger sjelden komplett |
| Bias og diskriminering | **2** | HITL er implementert (saksbehandler vedtar) — men ingen fairness-evaluering, ingen overvåking av demografiske ytelsesforskjeller, ingen bias-audit gjennomført |
| Tilgjengelighet og robusthet | **3** | Manuell saksbehandling er mulig ved AI-nedetid; men ingen PTU, ingen multi-region, ingen formell BCDR-plan for AI-komponenten |
| Forklarbarhet og sporbarhet | **3** | Azure AI Foundry run history finnes; kildevisning i svar; men logger ikke lagret tilstrekkelig lenge (< 5 år), og prosedyre for borgerkrav om innsyn ikke etablert |
| Juridisk og regulatorisk | **2** | DPA eksisterer; behandlingsgrunnlag identifisert — men DPIA ikke gjennomført for AI-spesifikke risikoer (helseopplysninger krever DPIA), AI Act-klassifisering (sannsynligvis high-risk per Annex III punkt 5) ikke formalisert |
| Organisatorisk og menneskelig | **3** | Ansvarsfordeling finnes; saksbehandlere har fått noe opplæring; men ingen vedtatt AI-policy, ingen hendelsesprosedyre, ROS er ny og ikke revidert |

**Totalscore:**
```
= (3 × 0.20) + (3 × 0.20) + (2 × 0.15) + (3 × 0.10)
+ (3 × 0.10) + (2 × 0.15) + (3 × 0.10)
= 0.60 + 0.60 + 0.30 + 0.30 + 0.30 + 0.30 + 0.30
= 2.70
```

**Risikokategori: Høy risiko** — Merk: Absolutt trigger vurderes: D6 (Juridisk) = 2, men > 1, så ingen absolutt trigger. Imidlertid: systemet behandler helseopplysninger (særlige kategorier) uten DPIA, noe som er et aktivt lovbrudd. Dette bør eskaleres til ledelse og personvernombud umiddelbart. D3 (Bias) = 2 for et borgermøtende vedtakssystem er kritisk — HITL alene er utilstrekkelig uten fairness-evaluering.

**Prioriterte utbedringstiltak:**
1. Gjennomfør DPIA umiddelbart (D6 +1)
2. Gjennomfør fairness-evaluering og dokumenter (D3 +1)
3. Implementer formell red team-testing (D1 +1)
4. Forleng loggretensjon til 5 år og etabler innsynsprosedyre (D5 +1)

---

## Sammenligning av casene

| Aspekt | Case A (Intern assistent) | Case B (Vedtaksstøtte) |
|--------|--------------------------|------------------------|
| Totalscore | 3.35 | 2.70 |
| Risikokategori | Høy | Høy |
| Mest kritisk dimensjon | Juridisk (AI-policy mangler) | Juridisk (DPIA mangler for helsedata) + Bias |
| Absolutte triggere | Ingen | Vurdér: DPIA mangler for særlige kategorier |
| Lettest quick-win | Vedta AI-policy (D7: 3→4) | Gjennomfør DPIA (D6: 2→3) |
| Størst investering | Red team og output-validering (D1: 3→5) | Fairness-evaluering + produksjonsovervåking (D3: 2→4) |
| Tidshorisont | 1-2 måneder | 2-4 uker (pga. DPIA-hastegrad) |
| Neste ROS-revisjon | Om 12 måneder | Om 6 måneder (etter utbedring) |

---

## Evidensgrunnlag og konfidensgrad

For hver dimensjonsscore, angi evidensgrunnlag. Dette gjør scoren transparent og etterprøvbar, og gjør det tydelig for leseren hvor agenten har god dokumentasjon vs. hvor den antar.

### Konfidensgrader

| Konfidensgrad | Symbol | Kilde | Eksempel |
|---------------|--------|-------|----------|
| Høy | (H) | Verifisert dokumentasjon, live-test, penetrasjonstest, konfigurasjonsgjennomgang | Azure-konfigurasjon gjennomgått i portal, Content Safety testet med red team-rapport |
| Middels | (M) | Informasjon fra rekvirent, standardantakelser basert på plattformvalg | "Vi bruker RBAC" — ikke verifisert mot faktisk konfigurasjon |
| Lav | (L) | Antakelse uten støtte, informasjon mangler helt | Ingen info om logging — antar mangelfull |

### Bruk i dimensjonsvurdering

Marker scorer med (H), (M) eller (L) i dimensjonsvurderingstabellen:

| # | Dimensjon | Vekt | Score | Konfidens | Funn |
|---|-----------|------|-------|-----------|------|
| 1 | Modellsikkerhet | 20% | 3/5 | (M) | Content Safety aktivert per rekvirent, ikke verifisert |
| 2 | Dataintegritet | 20% | 4/5 | (H) | Azure-konfigurasjon gjennomgått, CMK verifisert |
| 3 | Bias | 15% | 2/5 | (L) | Ingen fairness-data tilgjengelig — antar mangelfull |

### Retningslinjer for agenten

1. **Scorer basert på (L)-konfidens bør helle mot lavere score** — tvilstilfeller rundes ned
2. **Anbefal verifisering for alle (L)-dimensjoner** i tiltaksplanen som første steg
3. **Dokumenter eksplisitt** hva som er rekvirentens opplysning vs. agentens antakelse
4. **Oppgrader konfidens** ved å bruke MCP-verktøy (microsoft_docs_search) for å verifisere plattformkontroller
5. **(H)-konfidens krever minimum én av:** konfigurasjonsgjennomgang, testrapport, eller dokumentert prosedyre

---

## Kalibreringsveiledning for agenten

### Slik bruker du rubrikkene

1. **Innhent kontekst:** Identifiser systemtype (borgermøtende/intern), dataklassifisering (personopplysninger/sensitive/gradert), plattform (Azure AI Foundry/Copilot Studio/Power Platform/M365), og tiltenkt bruk (vedtaksstøtte/informasjon/automatisering).
2. **Gå gjennom dimensjonene sekvensielt:** Vurder alle 5 sjekkpunkter for hver dimensjon med ja/nei. Dokumenter evidens for hvert svar.
3. **Beregn dimensjonscore:** Tell antall "ja" → score (5=5, 4=4, 3=3, 2=2, 0-1=1).
4. **Beregn totalscore:** Bruk vektingsformelen. Rund av til 2 desimaler.
5. **Sjekk absolutte triggere:** Før du presenterer risikokategori fra totalscoren.
6. **Presenter prioriterte tiltak:** For hvert gap, beskriv hva som mangler og hva tiltaket konkret er.

### Vanlige kalibreringsfeller

| Felle | Konsekvens | Slik unngår du |
|-------|------------|----------------|
| **Gi høy score for HITL alene på Bias-dimensjonen** | Bias er fortsatt i systemet; HITL reduserer kun konsekvens, ikke sannsynlighet for bias | HITL gir maksimalt 2 av 5 uten fairness-evaluering; 3 krever dokumentert evaluering |
| **Anta at DPA med Microsoft dekker DPIA** | DPIA er virksomhetens eget ansvar; Microsofts DPA erstatter ikke kravet | Sjekk eksplisitt om en DPIA-rapport finnes, uavhengig av Microsoft-avtaler |
| **Score AI Act-dimensjonen høyt fordi systemet er "bare" et støtteverktøy** | Vedtaksstøttesystemer i offentlig sektor er typisk high-risk per Annex III punkt 5 | Gjennomgå AI Act Annex III eksplisitt; "støtteverktøy" og "automatisk vedtak" er begge high-risk hvis de påvirker borgeres rettigheter |
| **Ignorere Organisatorisk-dimensjonen fordi det er "bløtt"** | Tekniske kontroller degraderes uten organisatorisk eierskap; D7 er tidenes beste predikator for om tekniske tiltak faktisk brukes | D7 vekter 10 % av en grunn; en score på 1 indikerer at alle andre tekniske kontroller er på sikt i fare |
| **Anta at revisjon ikke er nødvendig fordi systemet ikke er endret** | Lovgivning, trussellandskap og datafordelingen endres kontinuerlig; EU AI Act trer i kraft i faser | ROS skal revideres ved vesentlige endringer i kontekst, ikke bare systemet |

### Spørsmål å stille kunden for å bestemme score

For **Dimensjon 1 (Modellsikkerhet):**
- "Kan du vise meg content filter-konfigurasjonen i Azure AI Foundry eller Copilot Studio?"
- "Er det gjennomført noen form for adversarial testing av systemet?"

For **Dimensjon 3 (Bias):**
- "Hvordan vet dere at systemet behandler ulike brukergrupper likt?"
- "Hva skjer hvis en saksbehandler mistenker at AI-en er biased mot en søker?"

For **Dimensjon 6 (Juridisk):**
- "Finnes det en DPIA for dette AI-systemet? Kan jeg se den?"
- "Har dere vurdert om dette systemet faller inn under AI Act Annex III?"

For **Dimensjon 7 (Organisatorisk):**
- "Hvem er systemeier for dette AI-systemet?"
- "Hva gjør en saksbehandler hvis de mistenker at AI-en gir feil svar?"

---

## Kilder og forankring

### Standarder og rammeverk

| Kilde | Relevans for rubrikken |
|-------|----------------------|
| NS 5814:2021 — Krav til risikovurderinger | Norsk standard for ROS-metodikk; gir prosessrammeverket |
| ISO 31000:2018 — Risikostyring | Internasjonal standard for risikostyringssystemer |
| ISO/IEC 23894:2023 — AI Risk Management | AI-spesifikk veiledning til ISO 31000; dimensjon 1-5 |
| EU AI Act (2024/1689) — Art. 9, 10, 13, 14, 50 | High-risk AI-krav; transparens; human oversight |
| OWASP LLM Top 10 (2025 edition) | AI-spesifikke trusselkategorier for dimensjon 1 |
| MITRE ATLAS | AI adversarial ML-teknikker |
| Microsoft Cloud Security Benchmark v2 | Tekniske kontroller for dimensjon 1 og 2 |

### Norsk lovgivning

| Lov | Dimensjoner |
|-----|-------------|
| Personopplysningsloven (GDPR-implementering) | D2, D5, D6 |
| EU AI Act (EØS-relevant) | D1, D3, D5, D6 |
| Forvaltningsloven §§ 24-25 (begrunnelsesplikt) | D5 |
| Likestillings- og diskrimineringsloven §§ 6-13 | D3 |
| Sikkerhetsloven | D2, D6 |
| Internkontrollforskriften | D7 |
| Arkivloven (retensjonskrav) | D5 |

**Sist verifisert:** 2026-02
**Neste revisjon:** 2027-02, eller ved vesentlig endring i EU AI Act gjennomføringsbestemmelser
