ms-ai-architect/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-analyse-ai-systems.md

ROS-analyse for AI-systemer

Last updated: 2026-02 Status: Gjeldende Category: Norwegian Public Sector AI Governance

---

Introduksjon

ROS-analyse (Risiko- og Sårbarhetsanalyse) er en systematisk tilnærming til å identifisere, vurdere og håndtere risikoer knyttet til IKT-systemer. For AI-systemer i norsk offentlig sektor innebærer dette en utvidet metodikk som tar høyde for AI-spesifikke risikoer som modellsikkerhet, dataintegritet, bias, og konsekvenser av automatiserte beslutninger.

Hva er ROS-analyse? ROS-analyse dekker tre hovedsteg:

1. Risikoidentifisering – identifisere hva som kan gå galt
2. Risikoanalyse – vurdere sannsynlighet og konsekvens
3. Risikoevaluering – prioritere og beslutte tiltak

For AI-systemer må denne prosessen inkludere både tekniske sårbarheter (prompt injection, datalekkasje, modellmanipulasjon) og samfunnsmessige risikoer (diskriminering, feilbeslutninger, manglende forklarbarhet).

Hvorfor er dette kritisk for offentlig sektor?

• Offentlige tjenester påvirker borgeres rettigheter og velferd direkte
• AI-beslutninger kan ha alvorlige konsekvenser (ytelser, tillatelser, helsetjenester)
• Lovkrav om forsvarlig risikostyring og internkontroll
• Tillitskrav til offentlige digitale tjenester

---

Lovgrunnlag og krav

Sikkerhetsloven

Sikkerhetsloven regulerer sikkerhet i virksomheter av betydning for nasjonale sikkerhetsinteresser, herunder IKT-sikkerhet i kritiske samfunnsfunksjoner.

Relevans for AI-systemer:

• AI-systemer i kritisk infrastruktur (helse, samferdsel, energi) må tilfredsstille sikkerhetskrav
• Krav om risikovurdering av IKT-systemer som behandler gradert informasjon
• Leverandørvurdering for skytjenester med AI-kapabiliteter

Sektorregelverk

Helseregisterloven og Pasientjournalloven

• Særlige krav til behandling av helseopplysninger med AI
• Dokumentasjonskrav for automatiserte beslutninger i helsesektoren

Forvaltningsloven

• § 11: Begrunnelsesplikt for enkeltvedtak – gjelder også AI-assisterte beslutninger
• Krav om forsvarlighet og sporbarhet i saksbehandling

Personopplysningsloven (GDPR)

• Art. 22: Rett til ikke å bli undergitt automatiserte individuelle avgjørelser
• Art. 35: DPIA (Data Protection Impact Assessment) for høyrisiko AI-behandling
• Art. 32: Sikkerhetstiltak tilpasset risiko

Offentleglova (Offentlighetsloven)

• Innsyn i offentlige AI-systemer (med visse unntak)
• Dokumentasjonsplikt for beslutningsgrunnlag

Internkontrollforskriften

Pålegger virksomheter å:

• Kartlegge farer og problemer
• Analysere risiko
• Iverksette tiltak for å redusere risiko
• Systematisk oppfølging og revisjon

For AI-systemer betyr dette:

• Dokumentert risikovurdering før iverksetting
• Kontinuerlig overvåking av AI-ytelse og sikkerhet
• Beredskapsplaner for AI-feil eller misbruk

---

ROS-metodikk for AI

Verdivurdering (Asset Identification)

Identifiser verdier som skal beskyttes:

1. Data

   • Treningsdata (ofte personopplysninger)
   • Spørringer/prompts fra brukere
   • Loggdata fra AI-interaksjoner

2. AI-modeller

   • Proprietære modeller eller fine-tuned versjoner
   • Konfigurasjoner og prompt engineering
   • Vektinger og hyperparametre

3. Tjenester

   • Tilgjengelighet av AI-tjenesten
   • Integritet i beslutningsgrunnlag
   • Konfidensiell behandling av brukerdata

4. Omdømme og tillit

   • Tilliten til offentlig sektor
   • Virksomhetens ansvarlighetsmål

Trusselvurdering (Threat Assessment)

Kartlegg relevante trusler:

Trusselelement	Beskrivelse	Eksempel (AI-kontekst)
Sabotasje	Forsettlig skade på system	Data poisoning, adversarial attacks
Spionasje	Uautorisert tilgang til informasjon	Model extraction, training data inference
Svikt	Tekniske eller menneskelige feil	Modell-drift, hallusinasjoner, bias
Ulykke	Utilsiktede hendelser	Feilklassifisering med alvorlige konsekvenser

AI-spesifikke trusler:

• Prompt injection – manipulering av AI-respons via ondsinnet input
• Jailbreaking – omgåelse av sikkerhetsbegrensninger
• Model inversion – rekonstruksjon av treningsdata fra modell
• Bias amplification – systematisk forskjellsbehandling

Sårbarhetsanalyse (Vulnerability Analysis)

Vurder sårbarhet langs ulike dimensjoner:

1. Teknisk sårbarhet

   • Eksponering av API-endepunkter
   • Manglende input-validering
   • Svak autentisering/autorisasjon
   • Manglende kryptering av data i transit/rest

2. Organisatorisk sårbarhet

   • Manglende kompetanse på AI-sikkerhet
   • Uklar ansvarsfordeling for AI-drift
   • Manglende prosedyrer for hendelseshåndtering

3. Juridisk sårbarhet

   • Uklare retningslinjer for AI-bruk
   • Manglende dokumentasjon av beslutningslogikk
   • Ikke-compliance med GDPR eller AI-forordningen

Konsekvensanalyse (Impact Assessment)

Vurder konsekvens på skala 1-5:

Nivå	Beskrivelse	Eksempel (AI)
1 - Ubetydelig	Ingen merkbar påvirkning	Trivielle feil i ikke-kritiske tjenester
2 - Liten	Begrenset påvirkning	Forsinkelser i saksbehandling
3 - Moderat	Merkbar påvirkning	Feilaktig avslag på søknad (reversibel)
4 - Alvorlig	Betydelig skade	Diskriminering i tjenesteyting
5 - Svært alvorlig	Katastrofal skade	Feil i helsebeslutninger med livsfare

Konsekvensdimensjoner:

• Personvern og individuelle rettigheter
• Tjenestekvalitet og tilgjengelighet
• Juridiske konsekvenser (erstatning, sanksjoner)
• Omdømme og tillit
• Økonomisk tap

Sannsynlighetsvurdering (Likelihood Assessment)

Vurder sannsynlighet på skala 1-5:

Nivå	Beskrivelse	Estimat
1 - Svært lite sannsynlig	Ekstremt sjelden hendelse	< 1 gang per 10 år
2 - Lite sannsynlig	Kan skje, men sjelden	1 gang per 5-10 år
3 - Mulig	Kan skje med jevne mellomrom	1 gang per 1-5 år
4 - Sannsynlig	Vil sannsynligvis skje	1-5 ganger per år
5 - Svært sannsynlig	Forventes å skje ofte	Ukentlig/månedlig

Faktorer som påvirker sannsynlighet:

• Eksponering (intern vs. eksternt tilgjengelig AI)
• Kompleksitet av systemet
• Modenhetsgrad på sikkerhetstiltak
• Trussel-landskap (målrettet vs. opportunistisk)

Risikoberegning

Risiko = Sannsynlighet × Konsekvens

Risiko	Farge	Tiltak
1-4	🟢 Grønn	Akseptabel – dokumenter og overvåk
5-9	🟡 Gul	Moderat – vurder tiltak
10-14	🟠 Oransje	Betydelig – implementer tiltak
15-25	🔴 Rød	Uakseptabel – umiddelbare tiltak eller avslutt aktivitet

Eksempel:

• Trussel: Prompt injection som gir tilgang til sensitiv data
• Sannsynlighet: 4 (sannsynlig – offentlig eksponert chatbot)
• Konsekvens: 4 (alvorlig – brudd på personvern)
• Risiko: 16 (rød – krever umiddelbare tiltak)

Tiltaksplan (Risk Treatment)

Fire hovedstrategier:

1. Redusere risiko – implementere tekniske/organisatoriske tiltak
2. Akseptere risiko – dokumentert beslutning om å leve med restrisiko
3. Overføre risiko – forsikring, leverandøransvar
4. Unngå risiko – ikke implementere AI-løsningen

Prioritering:

• Røde risikoer først
• Fokuser på tiltak med høyest effekt vs. kostnad
• Kombiner flere tiltak for forsvar i dybden (defense-in-depth)

---

AI-spesifikke risikoer

Modellsikkerhet

Trusler:

• Adversarial attacks – subtile endringer i input som får modellen til å feile
• Model poisoning – manipulering av treningsdata for å påvirke modell
• Backdoor attacks – skjulte triggere som aktiverer ondsinnet oppførsel

Tiltak:

• Robust training med adversarial examples
• Validering av treningsdata (data provenance)
• Red teaming og penetrasjonstesting av AI-modeller
• Versjonshåndtering og auditlogg for modellendringer

Dataintegritet og konfidensialitet

Trusler:

• Training data leakage – gjenoppbygging av treningsdata via model queries
• Membership inference – avdekke om spesifikke data var i treningssett
• Data poisoning – injisere korrupte data i treningspipeline

Tiltak:

• Differential privacy i treningsprosess
• Anonymisering og pseudonymisering
• Streng tilgangskontroll til treningsdata
• Kryptering av data i hvile og under overføring
• Secure multi-party computation (SMPC) for sensitive datasett

Bias og diskriminering

Trusler:

• Historisk bias – gjenspeiling av diskriminering i treningsdata
• Representasjonsbias – underrepresenterte grupper i treningsdata
• Aggregasjonsbias – feil aggregering av data fra heterogene populasjoner

Tiltak:

• Fairness-testing på beskyttede grupper
• Balanserte datasett (resampling, synthetic data)
• Fairness constraints i treningsalgoritmer
• Kontinuerlig overvåking av ytelse per demografisk gruppe
• Menneskelig oversyn ved beslutninger som påvirker rettigheter

Tilgjengelighet (Availability)

Trusler:

• DDoS mot AI-endepunkter – overbelaste modellen med forespørsler
• Resource exhaustion – langvarige eller komplekse queries som blokkerer tjenesten
• Dependency failures – feil i underliggende infrastruktur (Azure OpenAI throttling)

Tiltak:

• Rate limiting og throttling
• Caching av vanlige svar
• Redundans og failover-mekanismer
• Azure Front Door med DDoS-beskyttelse
• Kapasitetsplanlegging med PTU (Provisioned Throughput Units)

Forklarbarhet og sporbarhet

Trusser:

• Black-box problem – umulig å forklare hvorfor AI tok en beslutning
• Manglende audit trail – ingen sporbarhet i beslutningsprosess
• Repudiation – bruker eller system nekter for handling

Tiltak:

• Explainable AI (XAI) metoder – SHAP, LIME
• Omfattende logging av alle AI-interaksjoner
• Menneske-i-løkken (HITL) for kritiske beslutninger
• Versjonering av modeller og beslutningslogikk
• Digital signering av AI-genererte beslutninger

---

Microsoft-verktøy for risikostyring

Azure Security Benchmark og Secure Score

Funksjon: Azure Secure Score gir kontinuerlig vurdering av sikkerhetsstatus for Azure-ressurser.

For AI-systemer:

• Evaluer sikkerhet for Azure OpenAI, Azure AI Search, Azure ML
• Identifiser misconfigurations (f.eks. offentlig tilgjengelige endepunkter)
• Prioriterte anbefalinger for sikkerhetstiltak

Praktisk bruk:

# Azure CLI kommando for å hente Secure Score
az security secure-score list

Microsoft Defender for Cloud

Funksjon: CSPM (Cloud Security Posture Management) og trusseldeteksjon for Azure-ressurser.

For AI-systemer:

• Defender for AI Workloads (preview) – detekterer onormale AI-interaksjoner
• Just-in-Time (JIT) access – reduser eksponering av AI-administrasjonsportaler
• Threat intelligence – advarsler om kjente angrep mot AI-systemer

Sikkerhetspolicies for AI:

• Påkrev private endpoints for Azure OpenAI
• Krev managed identity istedenfor API keys
• Aktiver diagnostikklogging for alle AI-tjenester

Microsoft Purview Compliance Manager

Funksjon: Overvåk compliance med regelverk (GDPR, AI Act, ISO 27001).

For AI-systemer:

• Compliance Score – sporbare tiltak for AI-compliance
• Improvement Actions – spesifikke anbefalinger (f.eks. DPIA-mal)
• Assessments – forhåndsdefinerte maler for AI-relaterte regelverk

Praktisk eksempel:

1. Velg "Data Protection Baseline" assessment
2. Filtrer på AI-relevante kontroler (automated decision-making)
3. Dokumenter hvordan Azure OpenAI oppfyller GDPR Art. 22

Microsoft Threat Modeling Tool

Funksjon: Strukturert trusselmodellering basert på STRIDE-rammeverket.

For AI-systemer:

• Importer Azure-arkitektur (Azure AI Foundry, Copilot Studio)
• Identifiser trust boundaries (f.eks. bruker → AI → backend-database)
• Automatisk generering av trusler basert på dataflyt
• Eksport til Azure DevOps for sporing av tiltak

STRIDE for AI:

• Spoofing – forfalsket brukeridentitet i prompt
• Tampering – manipulering av treningsdata
• Repudiation – benekt AI-generert handling
• Information Disclosure – lekkasje av treningsdata
• Denial of Service – overbelasting av AI-endepunkt
• Elevation of Privilege – prompt injection som gir admin-tilgang

Azure Policy og Blueprints

Funksjon: Automatiser compliance-krav gjennom policy-as-code.

Eksempler på AI-policies:

{
  "policyRule": {
    "if": {
      "allOf": [
        {"field": "type", "equals": "Microsoft.CognitiveServices/accounts"},
        {"field": "Microsoft.CognitiveServices/accounts/publicNetworkAccess", "equals": "Enabled"}
      ]
    },
    "then": {
      "effect": "deny"
    }
  }
}

Denne policyen blokkerer opprettelse av Azure OpenAI-ressurser med offentlig nettverkstilgang.

Azure Blueprints for AI:

• Standard-oppsett med private endpoints, logging, og RBAC
• Compliance-preset for GDPR eller ISO 27001

Microsoft Sentinel (SIEM)

Funksjon: Security Information and Event Management for AI-tjenester.

Bruksområder:

• Anomalideteksjon – uvanlige mønstre i AI-bruk (f.eks. massiv datautvinning)
• Threat hunting – aktiv søking etter prompt injection-forsøk
• Incident response – automatiske playbooks ved AI-sikkerhetshendelser

Eksempel-query (KQL):

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.COGNITIVESERVICES"
| where Category == "RequestResponse"
| where ResultType == "Failure"
| where Properties contains "prompt injection"
| summarize count() by CallerIPAddress, bin(TimeGenerated, 1h)

---

ROS-mal for AI-prosjekter

Mal for ROS-analyse (Excel/tabellformat)

ID	Trussel	Sårbarhet	Sannsynlighet (1-5)	Konsekvens (1-5)	Risiko	Eksisterende tiltak	Restrisiko	Nye tiltak	Ansvarlig	Frist
AI-001	Prompt injection	Ingen input-sanitering	4	4	16 (🔴)	Ingen	16	Implementer Azure AI Content Safety	IT-sikkerhet	2026-03-01
AI-002	Training data leakage	Ingen differential privacy	2	5	10 (🟠)	Pseudonymisering	10	Differential privacy i ML pipeline	Data Science	2026-04-01
AI-003	Bias i modell	Ubalansert treningsdata	3	4	12 (🟠)	Ingen	12	Fairness-testing + diverse datasett	AI-lead	2026-03-15
AI-004	DDoS mot API	Ingen rate limiting	3	3	9 (🟡)	Azure Front Door	6	Rate limiting per bruker	DevOps	2026-02-20

Rapportmal

1. Sammendrag

• Kort beskrivelse av AI-systemet
• Overordnet risikonivå (rød/oransje/gul/grønn)
• Kritiske funn (røde risikoer)

2. Systembeskrivelse

• Formål og bruksområde
• Arkitektur (dataflyt-diagram)
• Brukergrupper og tilgangsnivåer

3. Verdivurdering

• Hvilke verdier skal beskyttes?
• Klassifisering av data (åpen, sensitiv, gradert)

4. Trusselvurdering

• Identifiserte trusler (intern/ekstern, forsettlig/utilsiktet)
• Trusselbilde (referanse til NSM, ENISA, OWASP)

5. Risikoanalyse

• Tabell med alle identifiserte risikoer (se mal over)
• Risikomatrise (heat map)

6. Tiltaksplan

• Prioriterte tiltak for røde/oransje risikoer
• Tidsplan og ansvarlig
• Ressursbehov

7. Restrisiko og akseptanse

• Dokumentert aksept av restrisiko av ledelsen
• Forbehold og forutsetninger

8. Vedlegg

• Referanser (lover, regelverk, standarder)
• Deltakerliste (hvem var involvert i analysen)
• Revisjonsplan (neste gjennomgang)

Prosess-sjekkliste

Før ROS-analyse:

• Etabler tverrfaglig team (AI, jus, sikkerhet, domeneekspert)
• Skaff dokumentasjon (arkitektur, dataflyt, personvernkonsekvensvurdering)
• Definer scope (hvilke deler av AI-systemet dekkes?)

Under ROS-analyse:

• Identifiser verdier (hva skal beskyttes?)
• Kartlegg trusler (brainstorming, threat libraries)
• Vurder sårbarheter (gap-analyse mot beste praksis)
• Beregn risiko (sannsynlighet × konsekvens)
• Foreslå tiltak (teknisk, organisatorisk, juridisk)

Etter ROS-analyse:

• Dokumenter i rapport
• Få godkjenning fra ledelsen
• Implementer tiltak (følg opp i backlog)
• Planlegg neste revisjon (årlig eller ved vesentlige endringer)

---

For arkitekten (Cosmo)

Når du møter en virksomhet som skal utføre ROS-analyse for et AI-system, bruk disse spørsmålene:

1. Hva er formålet med AI-systemet?

   • Hvilke beslutninger tar systemet? (automatiske eller assisterte)
   • Hvem er brukerne? (interne saksbehandlere, eksterne borgere)
   • Hvilke data behandles? (personopplysninger, sensitive opplysninger, gradert info)

2. Hvilke juridiske krav gjelder?

   • Er dette et høyrisiko AI-system ihht. AI Act?
   • Kreves DPIA etter GDPR Art. 35?
   • Gjelder særlovgivning (helseregisterloven, sikkerhetsloven)?

3. Hvordan er AI-systemet arkitektonisk bygget?

   • On-premises, cloud (Azure), hybrid?
   • Proprietær modell eller LLM-as-a-service (Azure OpenAI)?
   • Hvilke integrasjoner finnes? (databaser, fagsystemer, tredjepartstjenester)

4. Hvilke trusler bekymrer virksomheten mest?

   • Datalekkasje, bias, tjenestefeil, manipulering, omdømmetap?
   • Har det vært sikkerhetshendelser tidligere (for AI eller andre systemer)?

5. Hvilke sikkerhetstiltak er allerede implementert?

   • Input-validering, autentisering, kryptering, logging?
   • Content filtering (Azure AI Content Safety)?
   • Overvåking og alerting (Azure Monitor, Sentinel)?

6. Hvem er ansvarlig for AI-sikkerheten?

   • Finnes dedikert AI-sikkerhetsrolle?
   • Hvordan er ansvaret fordelt mellom IT, jus, og fagavdeling?

7. Hvordan håndteres AI-hendelser?

   • Finnes beredskapsplan for AI-feil eller angrep?
   • Hvem kontaktes ved mistanke om prompt injection eller datalekkasje?
   • Hvordan kommuniseres hendelser til brukere/berørte?

8. Når skal ROS-analysen oppdateres?

   • Årlig revisjon?
   • Ved vesentlige endringer (nye funksjoner, nye datasett, ny lovgivning)?
   • Etter sikkerhetshendelser?

Anbefalinger basert på scope:

Scenario	Primær risiko	Anbefalt Microsoft-verktøy
Intern chatbot for saksbehandling	Datalekkasje, bias	Azure OpenAI + Private Endpoint, Fairness-testing
Automatisk vedtak i forvaltning	Diskriminering, feilbeslutninger	Menneske-i-løkken, Explainable AI, omfattende logging
Prediktiv analyse på helsedata	Personvern, databrudd	Differential privacy, Defender for Cloud, Purview
Kunnskapsbase med RAG	Informasjonslekkasje	Azure AI Search med RBAC, Document-level security

---

Kilder og verifisering

Norske myndigheter og organisasjoner

1. Direktoratet for samfunnssikkerhet og beredskap (DSB)

   • Samfunnssikkerhet i arealplanlegging – Veileder til ROS-analyse som metode
   • Helhetlig ROS i kommunen – Metodikk for kommunal ROS

2. Nasjonal sikkerhetsmyndighet (NSM)

   • Risikovurdering av IKT-systemer (PDF) – Praktisk verktøy for risikovurdering
   • NSMs Grunnprinsipper for IKT-sikkerhet v2.1 (PDF) – 21 prinsipper og 118 sikkerhetstiltak
   • Gode risikovurderinger ved tjenesteutsetting

3. Universitetet i Oslo (UiO)

   • Kapittel 7: Risiko- og sårbarhetsanalyser – Krav og metodikk for ROS i universitetssektor

4. Finanstilsynet

   • Risiko- og sårbarhetsanalyse (ROS) 2024 – Sektorspesifikk ROS for finansnæringen (inkl. IKT-risiko)

5. KS (Kommunesektorens organisasjon)

   • Styrking av digital robusthet i kommunal sektor (PDF) – Veiledning for kommuner om cybersikkerhet

6. Datatilsynet

   • Risikovurdering – Personvernperspektivet på risikovurdering

Microsoft Azure dokumentasjon

7. Microsoft Learn – Threat Modeling

   • Security considerations for mission-critical workloads on Azure – STRIDE-rammeverk for Azure
   • Architecture strategies for threat analysis – Microsoft Threat Modeling Tool
   • Design secure applications on Azure – SDL og threat modeling i design-fasen

8. Microsoft Training – Threat Modeling

   • Secure your infrastructure with threat modeling – Praktisk trening i trusselmodellering
   • Choose a client application with threat modeling – Sikkerhetsvurdering av applikasjoner
   • Use a framework to identify threats – STRIDE-basert trusselidentifikasjon

9. Microsoft Security Benchmark

   • DevOps Security – DS-1: Conduct threat modeling – Integrere threat modeling i DevOps

10. Microsoft Security Development Lifecycle

    • SDL Threat Modeling Tool – Gratis verktøy for trusselmodellering

Internasjonale standarder og rammeverk

11. ISO/IEC 27005 – Information security risk management
12. NIST SP 800-30 – Guide for Conducting Risk Assessments
13. OWASP Threat Modeling – Threat Modeling Process
14. ENISA – AI Cybersecurity Challenges (EU-perspektiv på AI-risiko)

Verifikasjon og aktualitet

Denne kunnskapsreferansen er basert på:

• 10 unike kilder (DSB, NSM, Microsoft Learn, Datatilsynet, KS, Finanstilsynet, UiO)
• Dokumenter publisert i perioden 2021-2026
• NSMs Grunnprinsipper v2.1 (oppdatert 2024)
• Microsoft Well-Architected Framework (kontinuerlig oppdatert)
• Norsk regelverk gjeldende per februar 2026

Sist verifisert: 2026-02 Neste revisjon: 2027-02 (eller ved vesentlige endringer i AI-forordningen/NSM-veiledere)