Hendelser og klager i HR-AI: slik logger du og følger opp

Når KI brukes i HR-prosesser, vil det oppstå situasjoner der noe går galt – en kandidat som mener seg feilaktig avvist, et system som gir uventede resultater, eller en ansatt som reagerer på en KI-basert vurdering. Spørsmålet er ikke om det skjer, men om virksomheten har en prosess for å håndtere det. Denne artikkelen gir deg en praktisk fremgangsmåte for logging, klassifisering og oppfølging av hendelser og klager.

Merk: Denne artikkelen er veiledende og beskriver en prosess som kan tilpasses virksomhetens størrelse og behov.

Hva er en hendelse i HR-AI-sammenheng?

En hendelse er en situasjon der et KI-system i HR ikke fungerer som forventet, eller der bruken av systemet fører til et uønsket resultat. Hendelser kan variere i alvorlighet:

Kategorier

Kategori	Eksempler	Alvorlighet
Teknisk feil	Systemet krasjer, gir tomme resultater, responderer ikke	Varierer
Feilaktig output	Kandidater rangeres feil, vurderinger er åpenbart gale	Middels til høy
Mulig diskriminering	Systematisk skjevhet i resultater for bestemte grupper	Høy
Uautorisert bruk	Systemet brukes til formål det ikke er godkjent for	Høy
Personvernbrudd	Data behandles i strid med GDPR eller samtykke	Høy
Brukerklage	En berørt person klager på en KI-basert beslutning	Varierer

Hva er en klage?

En klage er en formell eller uformell henvendelse fra en person som er berørt av en KI-basert beslutning. I HR-sammenheng kan klageren være:

Jobbsøker som mener seg urettmessig avvist eller rangert.
Ansatt som mener en KI-basert vurdering er feil eller urimelig.
Tillitsvalgt som tar opp en sak på vegne av ansatte.
Ekstern part som mener seg berørt av virksomhetens bruk av KI.

Klager bør behandles som hendelser – de logges, vurderes og følges opp etter samme prosess.

Hvorfor logging er nødvendig

Forordningens krav

KI-forordningen krever at deployere av høyrisiko-systemer logger hendelser og rapporterer alvorlige hendelser til tilsynsmyndigheten. Også for systemer som ikke er høyrisiko, er det god praksis å dokumentere hendelser.

Bevissikring

Uten logging har du ingenting å vise til ved tilsyn, revisjon eller rettslig tvist. En udokumentert hendelse er som om den ikke har skjedd – eller verre, den kan tolkes i virksomhetens disfavør.

Læring og forbedring

Hendelsesloggen er grunnlaget for å identifisere mønstre, forbedre rutiner og vurdere om systemet fungerer som det skal.

Prosess for hendelseshåndtering

Steg 1: Oppdage og melde

Hendelser kan oppdages av:

Brukeren (rekrutterer, HR-medarbeider, leder) som merker at noe er galt.
Den berørte (kandidat, ansatt) som klager.
Tilsynsansvarlig som oppdager avvik under gjennomgang.
Systemet selv via feilmeldinger eller automatisk overvåking.

Alle ansatte som bruker KI-systemer i HR bør vite:

Hva som regnes som en hendelse.
Hvem de skal melde til.
At det er bedre å melde for mye enn for lite.

Steg 2: Registrere

Hver hendelse registreres i en hendelseslogg. Minimumet av informasjon:

HENDELSESRAPPORT
================

Hendelse-ID: [Løpenummer]
Dato oppdaget: [Dato]
Meldt av: [Navn, rolle]
System: [Systemnavn]

BESKRIVELSE
-----------
Hva skjedde: [Kort beskrivelse]
Hvem er berørt: [Kandidater/ansatte/andre]
Omfang: [Antall berørte, tidsperiode]

KLASSIFISERING
--------------
Kategori: [Teknisk feil / Feilaktig output / Mulig diskriminering /
           Uautorisert bruk / Personvernbrudd / Klage]
Alvorlighet: [Lav / Middels / Høy / Kritisk]

UMIDDELBARE TILTAK
------------------
Tiltak iverksatt: [Beskrivelse]
Iverksatt av: [Navn]
Dato: [Dato]

Steg 3: Klassifisere alvorlighet

Alvorligheten bestemmer hvor raskt og grundig hendelsen håndteres:

Alvorlighet	Beskrivelse	Responstid	Eskalering
Lav	Mindre feil uten konsekvens for berørte	Innen 5 virkedager	Systemeier
Middels	Feil som kan ha påvirket en beslutning	Innen 2 virkedager	KI-ansvarlig
Høy	Systematisk feil eller mulig diskriminering	Innen 1 virkedag	Daglig leder
Kritisk	Alvorlig hendelse, mange berørte, pågående skade	Umiddelbart	Daglig leder + vurder ekstern varsling

Steg 4: Undersøke

For hendelser med middels eller høyere alvorlighet, gjennomfør en undersøkelse:

Samle fakta. Hva skjedde konkret? Hva viser loggene? Hva sier brukeren og den berørte?
Identifiser årsaken. Er det en teknisk feil, en konfigurasjonsfeil, en svakhet i modellen, eller feil bruk?
Vurder omfanget. Er dette en enkelthendelse eller et mønster? Hvor mange er berørt?
Kontakt leverandøren hvis årsaken kan ligge i systemet selv.

Steg 5: Iverksette tiltak

Basert på undersøkelsen, beslutt og iverksett tiltak:

Tiltakstype	Eksempler
Umiddelbart	Stans bruk av systemet, manuell gjennomgang av berørte beslutninger
Korrigerende	Rekjør berørte kandidater manuelt, omgjør beslutning, informer berørte
Forebyggende	Oppdater rutiner, gi tilleggsopplæring, endre systemkonfigurasjon
Systemisk	Be leverandør om utbedring, vurder alternativt system, endre tilsynsrutine

Steg 6: Dokumentere og lukke

Når hendelsen er håndtert, oppdater hendelsesrapporten med fullstendig informasjon:

OPPFØLGING OG AVSLUTNING
=========================

Undersøkelse gjennomført av: [Navn]
Dato for undersøkelse: [Dato]

Årsak: [Beskrivelse av identifisert årsak]

Tiltak iverksatt:
1. [Tiltak] – [Ansvarlig] – [Dato]
2. [Tiltak] – [Ansvarlig] – [Dato]

Berørte informert: [Ja/Nei – hvis ja, dato og hvordan]

Ekstern varsling: [Ikke nødvendig / Varslet til [mottaker] den [dato]]

Status: [Åpen / Under behandling / Lukket]
Lukket av: [Navn]
Dato lukket: [Dato]

Lærdom: [Hva kan gjøres for å forhindre lignende hendelser?]

Prosess for klagebehandling

Klager følger samme grunnprosess som hendelser, men med noen tillegg:

Mottak av klage

Når en klage mottas:

Bekreft mottaket overfor klageren innen rimelig tid (1–3 virkedager).
Registrer klagen i hendelsesloggen med kategori «Klage».
Vurder om klagen gjelder en KI-basert beslutning. Ikke alle klager er KI-relaterte, selv om de gjelder en prosess der KI brukes.

Klagebehandlingsmal

KLAGEBEHANDLING
===============

Klage-ID: [Løpenummer / kobling til hendelseslogg]
Dato mottatt: [Dato]
Klager: [Navn / anonymisert referanse]
Klagerens tilknytning: [Jobbsøker / Ansatt / Tillitsvalgt / Annet]

KLAGEN
------
Hva gjelder klagen: [Kort beskrivelse]
System involvert: [Systemnavn]
Beslutning som klages på: [Beskrivelse]
Dato for beslutningen: [Dato]

VURDERING
---------
Er KI-systemet involvert i beslutningen: [Ja / Nei / Delvis]
Hva viser systemets logg: [Oppsummering]
Er det grunnlag for å omgjøre beslutningen: [Ja / Nei – med begrunnelse]

BESLUTNING
----------
Utfall: [Klage avvist / Beslutning opprettholdt / Beslutning omgjort / Annet]
Begrunnelse: [Kort beskrivelse]
Besluttet av: [Navn, rolle]
Dato: [Dato]

OPPFØLGING
----------
Klager informert om utfall: [Dato og hvordan]
Tiltak iverksatt: [Beskrivelse, eller «ingen tiltak nødvendig»]

Klagerens rettigheter

Vær oppmerksom på klagerens rettigheter:

Informasjonsrett: Klageren har rett til å vite at KI er brukt i beslutningsprosessen (artikkel 86 i KI-forordningen, samt informasjonsplikten i GDPR).
Innsyn: Klageren kan ha rett til innsyn i hvilke data som er behandlet (GDPR artikkel 15).
Ikke automatiserte beslutninger: GDPR artikkel 22 gir rett til å ikke bli underlagt rent automatiserte beslutninger med rettslig eller tilsvarende virkning.
Menneskelig vurdering: Klageren kan kreve at et menneske vurderer saken.

Hendelseslogg: sentralt register

Hold en sentral hendelseslogg som gir oversikt over alle hendelser og klager:

HENDELSESLOGG KI I HR
=====================

ID  | Dato      | System    | Kategori         | Alvorlighet | Status       | Ansvarlig
----|-----------|-----------|------------------|-------------|--------------|----------
H01 | 2026-02-10| System X  | Feilaktig output | Middels     | Lukket       | [Navn]
H02 | 2026-02-15| System X  | Klage            | Middels     | Under beh.   | [Navn]
H03 | 2026-03-01| System Y  | Teknisk feil     | Lav         | Lukket       | [Navn]
H04 | 2026-03-10| System X  | Mulig diskrim.   | Høy         | Under beh.   | [Navn]

Loggen bør gjennomgås regelmessig – for eksempel kvartalsvis – for å identifisere mønstre.

Når skal du varsle eksternt?

Tilsynsmyndigheten

KI-forordningen krever varsling til tilsynsmyndigheten ved alvorlige hendelser med høyrisiko-systemer. En «alvorlig hendelse» er definert som en hendelse som kan ha ført til:

Død eller alvorlig skade på helse.
Alvorlig og irreversibel forstyrrelse av forvaltning eller drift av kritisk infrastruktur.
Brudd på grunnleggende rettigheter.

For HR-systemer er den mest relevante kategorien brudd på grunnleggende rettigheter – for eksempel systematisk diskriminering.

Datatilsynet

Ved personvernbrudd gjelder GDPR artikkel 33: varsling til Datatilsynet innen 72 timer.

Praktisk vurdering

Ikke alle hendelser krever ekstern varsling. Bruk denne vurderingen:

Spørsmål	Ja →
Er systemet klassifisert som høyrisiko?	Vurder varsling nøye
Er mange personer berørt?	Øker sannsynligheten for varsling
Er det systematisk skjevhet basert på beskyttede egenskaper?	Taler sterkt for varsling
Er personopplysninger kommet på avveie?	Varsle Datatilsynet innen 72 timer
Kan hendelsen ha påvirket ansettelse eller oppsigelse?	Vurder varsling

Ved tvil, konsulter juridisk rådgiver.

Eskaleringsmatrise

Definer hvem som varsles ved ulike alvorlighetsgrader:

Alvorlighet	Varsles umiddelbart	Varsles innen 24 timer	Informeres
Lav	Systemeier	-	KI-ansvarlig
Middels	Systemeier, KI-ansvarlig	HR-leder	-
Høy	KI-ansvarlig, HR-leder	Daglig leder	Tillitsvalgt
Kritisk	Daglig leder, KI-ansvarlig	Tilsynsmyndighet (vurderes)	Tillitsvalgt, styret

Læring fra hendelser

Hendelser er en kilde til forbedring. Etter at en hendelse er lukket:

Identifiser rotårsaken. Ikke bare symptomet, men den underliggende årsaken.
Vurder om rutinen bør endres. Er det noe i prosessen som tillot at hendelsen oppstod?
Del lærdommen. Relevante funn bør deles med brukere og tilsynsansvarlige.
Oppdater dokumentasjon. Systemfilen eller tilsynsrutinen bør oppdateres hvis hendelsen avdekker hull.
Følg opp tiltak. Sjekk at forebyggende tiltak faktisk er gjennomført.

Vanlige feil å unngå

Ikke logge «småting». Små hendelser kan være del av et mønster. Logg alt – du kan alltid sortere etterpå.
Behandle klager uformelt. En klage som håndteres muntlig uten dokumentasjon, kan ikke etterprøves. Selv om løsningen er enkel, bør den dokumenteres.
Ignorere tidsfrister. Særlig ved personvernbrudd er 72-timersfristen absolutt. Ha en prosess som sikrer at fristen overholdes.
Ikke informere berørte. Når en hendelse har påvirket en person, har de som regel rett til å vite om det. Unnlatelse kan forsterke skaden.
Lukke hendelser for tidlig. En hendelse bør ikke lukkes før tiltak er gjennomført og virkningen er verifisert.
Mangle eskaleringsrutine. Hvis ingen vet hvem de skal varsle, blir kritiske hendelser liggende. Definer eskalering på forhånd.