Risikovurdering av maskinlæringsprosjekter: slik gjør du det i praksis

Hva denne guiden dekker – og hva den ikke dekker

Denne artikkelen handler om én ting:

Hvordan du gjør en konkret risikovurdering av ett maskinlæringsprosjekt i en norsk bedrift, før (og rett etter) produksjonssetting.

Vi går ikke inn i grunnbegreper som hva er maskinlæring eller typer algoritmer – det er dekket i pilarinnlegget. Her forutsetter vi at du allerede har et avgrenset prosjekt, for eksempel:

modell for å foreslå kontering på inngående faktura
modell for å predikere kundefrafall
modell for å prioritere saker i kundeservice

Målet er at du etterpå kan svare på:

Hvor trygt er det å bruke denne modellen?
Hvor mye kan vi automatisere, og hvor må mennesker inn?
Hvilke kontroller, målinger og grenser må på plass før lansering?

1. Start med én konkret beslutning – ikke med modellen

En risikovurdering er meningsløs hvis du ikke vet hvilken beslutning modellen påvirker.

Gjør dette skriftlig før du ser på teknikken:

Beskriv beslutningen i én setning
Eksempler:
- «Modellen skal foreslå kontering på inngående fakturaer i prosessen for leverandørreskontro.»
- «Modellen skal rangere abonnementskunder etter sannsynlighet for å si opp innen 90 dager.»
- «Modellen skal foreslå prioritet (høy/middels/lav) på nye kundeservice-saker.»
Angi hvordan forslaget brukes i praksis
Kryss av for riktig nivå:
- Kun som beslutningsstøtte (menneske må aktivt godkjenne hver gang)
- Styrer rekkefølge (prioritering), men ikke ja/nei-beslutning
- Tar automatisert beslutning innenfor definerte rammer
Vurder konsekvens ved feil
Vurder både én feil og mange feil på rad:
- Lav: irritasjon, små beløp, lett å rette
- Middels: merkbare kostnader/SLA-brudd, men håndterbart
- Høy: store beløp, regulatorisk risiko, eller alvorlig skade på kunder/omdømme

Denne enkle matrisen styrer hvor streng du må være i resten av risikovurderingen.

2. Kartlegg datagrunnlaget – før du diskuterer algoritmer

Modellen arver all skjevhet og feil fra dataene. Start med en strukturert gjennomgang av treningsdata.

2.1 Lag en enkel dataoversikt

For datasettet modellen er trent på, lag en tabell med:

Kilder: ERP, CRM, fagsystem, logger osv.
Eier(e):
- forretning (hvem eier prosessen/dataene)
- teknisk (hvem drifter systemet)
Personopplysninger: ja/nei, og grovtype (kunde, ansatt, sluttbruker)

Samtidig: noter nøyaktig tidsperiode treningsdata dekker (f.eks. jan 2022–sep 2024).

2.2 Vurder datakvalitet på nøkkelfelter

Identifiser 10–20 viktigste variabler (features) modellen bruker. For hver:

andel manglende verdier
typiske feil (feil format, åpenbart urimelige verdier)
om feltet har endret betydning over tid (ny koding, nye verdier)

Spør deg selv:

«Ville jeg akseptert disse tallene som grunnlag for manuell analyse?»
Hvis svaret er nei, har du et dataproblem, ikke et modellproblem.

2.3 Sjekk om historikken er representativ

Spør:

Er dagens produktmiks, kundetyper og prosesser lignende det som finnes i treningsdata?
Har dere:
- nye segmenter
- nye prisstrukturer
- nye kanaler

Hvis ja: avgrens bruken i starten (f.eks. «kun eksisterende kunder», «kun segment X/Y») til dere har ny data på plass.

3. Analyser feilprofilen – ikke bare gjennomsnittstall

En modell med «90 % nøyaktighet» kan være ubrukelig hvis den feiler på feil type saker.

3.1 Avklar hvilke feil som er verst

For den konkrete modellen:

Hva er verst: falsk positiv eller falsk negativ?
- F.eks. svindeldeteksjon: verre å slippe gjennom reell svindel enn å stoppe noe uskyldig
- Frafallsmodell: verre å overse en verdifull kunde enn å følge opp noen ekstra

Dette bestemmer om du bør stramme eller løsne terskelen for «høy risiko».

3.2 Se på resultater per segment – ikke bare totalt

Del opp evalueringsresultatene på relevante dimensjoner, for eksempel:

kundestørrelse (SMB/enterprise)
bransje eller region
produktkategori
kanal (innkommende vs. oppsøkende)

Se etter segmenter der modellen:

har markant lavere presisjon/recall
konsekvent overvurderer eller undervurderer

Tiltak kan være:

egne terskler per segment
krav om manuell godkjenning i gitte segmenter
å midlertidig ikke bruke modellen for segmenter der den er for svak

3.3 Test stabilitet over tid

Kjør «walk-forward»-tester:

tren på periode A, test på B
tren på A+B, test på C

Se om kvaliteten holder eller faller systematisk. Kraftig fall over tid tyder på at du må ha tett overvåking og hyppigere retrening i drift.

Kilde: NIST AI Risk Management Framework – om modellkvalitet, drift og risiko

4. Sjekk fairness og åpenbare skjevheter

Målet her er ikke full akademisk fairness-analyse, men å fange grove utslag før de havner i produksjon.

4.1 Identifiser «sensitive» og indirekte variabler

Del feature-listen i tre:

Må normalt ikke brukes: kjønn, helse, etnisitet, religion osv.
(Her bør du ha veldig gode grunner og juridisk vurdering.)
Potensielle proxyer: postnummer, utdanningsnivå, arbeidsgiver/bransje, inntektssurrogater
Relativt nøytrale: tekniske målinger, aggregerte bruksdata, produktdata

Hvis modellen påvirker enkeltpersoner (kreditt, ansettelser, forsikring osv.), skal første kategori normalt ut.

4.2 Kjør enkle gruppe-sammenligninger

Del datasettet inn i relevante grupper (for eksempel regioner, kundevolum, aldersgrupper hvis aktuelt) og sammenlign:

hvor ofte modellen anbefaler «risiko» per gruppe
feilrater per gruppe

Ser du at én gruppe systematisk:

blir oftere flagget som risiko
får dårligere treffrate

… uten god faglig forklaring, har du en fairness-risiko som må håndteres.

4.3 Dokumenter og håndter funn

Hvis du finner skjevheter:

fjern eller juster features som åpenbart driver uønskede forskjeller
legg på forretningsregler som begrenser effekten (f.eks. manuelt review for utvalgte grupper)
dokumenter vurderingene (nyttig ved revisjon/tilsyn)

Kilde: NIST AI Risk Management Framework – prinsipper for fairness og risikostyring

5. Avklar forklarbarhet og dokumentasjon før lansering

Forretningssiden må kunne forklare – i klare ord – hvorfor modellen typisk gir et resultat.

5.1 Lag et «modellkort» på én side

Minimumsinnhold:

Formål og beslutningstype modellen støtter
Datakilder og periode brukt til trening
De 5–10 viktigste variablene (med enkel forklaring)
Brukte kvalitetsmål (f.eks. presisjon, recall, AUC, MAE) og nivå
Kjente svakheter (segmenter, dataperioder, spesielle tilfeller)

Dette bør kunne forstås av en fagperson uten ML-bakgrunn.

5.2 Forbered eksempler som kan vises til brukere

Ta ut noen representative saker og vis:

sentrale input-verdier (forenklet)
modellens anbefaling
hvilke faktorer som påvirket mest opp/ned (for enkle modeller: koeffisienter; for komplekse: forenklet viktigste features)

Poenget er ikke perfekt teknisk nøyaktighet, men en ærlige, forståelige forklaring fagmiljøet kan stille seg bak.

5.3 Avtal offisiell forklaringstekst

Lag standardformuleringer som kan brukes mot kunder eller internt, f.eks.:

«Vurderingen er basert på betalingshistorikk, ordrevolum, kundetype og nylige endringer i kjøpsmønster.»

Unngå teknisk sjargong. Sørg for at juridisk/personvern er komfortable med formuleringene der det er relevant.

6. Drift, overvåking og fallback – før du trykker «produksjon»

En modell uten driftsplan er en operasjonell risiko.

6.1 Definer en tydelig fallback

Svar eksplisitt på:

Hva gjør vi hvis modellen ikke svarer?
Hva gjør vi hvis kvaliteten åpenbart faller?

Vanlige alternativer:

gå tilbake til tidligere regelbasert løsning
sette alle saker til «manuell behandling»
bruke trygg default (f.eks. «lav risiko + manuell kontroll»)

Fallback må være testet i forkant – ikke improvisert i produksjon.

6.2 Sett opp minimumsovervåking

Velg noen få nøkkelmål du kan følge ukentlig/månedlig:

modellkvalitet (for eksempel presisjon/recall, MAE) på et utvalg saker
volum og fordeling på viktige segmenter
tekniske metrikker (svartid, feilrate)

Lag terskler for når:

teamet får varsel
fallback skal vurderes aktivert

6.3 Kostgrenser

Hvis modellen kjører i skyen, må du ha kontroll på kost:

sett grenser per måned (eller per miljø) for:
- API-kall
- beregningsressurser
- evt. tokens/kontekst hvis generative komponenter brukes
lag varsler ved uvanlige toppperioder

Kilde: NIST AI Risk Management Framework – om overvåking, drift og koststyring

7. GDPR og personvern: koble risikovurdering og regelverk

Når modellen behandler personopplysninger, må risikovurdering og personvernvurdering henge sammen.

7.1 Behandlingsgrunnlag og formål

Avklar – og dokumenter – hva som er rettslig grunnlag:

avtale (for eksempel kundeforhold)
berettiget interesse (med skriftlig interesseavveiing)
samtykke (spesielt ved mer sensitive eller nye formål)

Koble dette direkte til formålet med modellen (f.eks. kreditt, lojalitet, svindel).

7.2 Dataminimering i praksis

Gå gjennom feature-settet med dataminimering i bakhodet:

Hvilke felter er strengt nødvendige?
Kan noen felter aggregeres eller grovanonymiseres uten vesentlig kvalitetstap?

Fjern det du ikke trenger. Det gjør både teknisk og juridisk risiko lavere.

7.3 Vurder DPIA (personvernkonsekvensvurdering)

Gjennomfør DPIA hvis modellen:

brukes i nye eller vesentlig endrede prosesser med personopplysninger
kan gi betydelig utslag for enkeltpersoner (kredittbeslutninger, scoringer, profilering)

Her bør personvernansvarlig lede, men ML-/forretningsteam må bidra med beskrivelse av data, formål og risikoreduserende tiltak.

Kilde: Datatilsynet – Virksomhetenes plikter

8. 30–60–90-dagers plan for risikovurdering rundt én modell

Nedenfor er en praktisk plan for å komme fra «ferdig modell i test» til kontrollert pilot i drift.

Dag 0–30: Kartlegg og få første risikobilde

Fokus: forstå beslutning, data og feilprofil.

Skriv én setning om beslutningen modellen skal støtte (seksjon 1)
Lag dataoversikt: kilder, eiere, periode, personopplysninger (seksjon 2)
Analyser feilprofil og segmenterte resultater (seksjon 3)
Lag en enkel konsekvensmatrise (lav/middels/høy) for feil

Output: kort risikonotat (2–3 sider) som kan diskuteres i linja.

Dag 31–60: Avklar tiltak, forklarbarhet og styring

Fokus: redusere risiko og forberede drift.

Kjør enkle fairness-sjekker og juster features/regler ved behov (seksjon 4)
Lag modellkort + eksempelforklaringer (seksjon 5)
Definer overvåkingsmetrikker, terskler og fallback-løsning (seksjon 6)
Avklar behandlingsgrunnlag, dataminimering og DPIA-behov (seksjon 7)

Output:

oppdatert risikorapport
tydelig drifts- og overvåkingsplan

Dag 61–90: Kjør kontrollert pilot

Fokus: test risikobildet i virkeligheten.

Kjør modellen mot begrenset volum (utvalgt segment/avdeling)
Mål ukentlig: kvalitet, manuelle inngrep, avvik, teknisk stabilitet
Juster terskler, regler og overvåking basert på faktiske funn

Etter 90 dager tar du beslutning om én av tre:

Stoppe (for høy risiko eller for lav effekt)
Forbedre (flere tiltak før ny pilot)
Skalere (gradvis utrulling, med samme overvåkingsregime)

Kilder: NIST AI Risk Management Framework; Datatilsynet – Virksomhetenes plikter

FAQ: Vanlige spørsmål om risikovurdering av maskinlæring i bedrifter

Må vi ha avansert statistikk-kompetanse for å risikovurdere en modell?

Nei. Du trenger teknisk kompetanse for å bygge og evaluere modellen, men mye av risikovurderingen er prosess, eierskap og konsekvens:

Hva modellen brukes til
Hva som kan gå galt
Hvem som har ansvar når noe skjer

Når er det for risikabelt å automatisere?

Typiske tegn:

høy konsekvens ved feil + lav forklarbarhet
vesentlig dårligere resultater i enkelte segmenter
ingen robust fallback hvis modellen feiler

Da bør modellen brukes som beslutningsstøtte, ikke som autonom beslutning.

Hvor ofte bør vi revidere risikovurderingen?

Som minimum når:

datagrunnlaget endres vesentlig (nye systemer, nye segmenter)
modellen byttes ut eller justeres kraftig
dere ser kvalitetsfall eller flere alvorlige avvik i drift

I tillegg er årlig revisjon for kritiske modeller et fornuftig minimum.

Hvordan får vi fagpersoner til å stole på modellen?

vis konkrete eksempler der modellen er bedre enn dagens praksis
vis også eksempler der modellen tar feil – og hvordan feil fanges opp
gi fagfolk reell innflytelse på terskler, regler og fallback

Tillit bygges når modellen gjør jobben deres enklere, ikke mer uforutsigbar.

Hvordan henger dette sammen med MLOps?

Risikovurderingen bør oversettes til konkrete MLOps-krav:

hvilke metrikker som overvåkes
hvilke terskler som utløser tiltak
hvem som kan godkjenne nye modellversjoner

Da blir risikoarbeidet en del av løpende drift – ikke en engangsøvelse.