EU AI Act stiller præcise krav til, hvad den tekniske dokumentation for høj-risiko AI-systemer skal indeholde. Kravene er ikke skrevet som løse retningslinjer — de er specificeret punkt for punkt i Annex IV til forordningen. Hvis din virksomhed udvikler eller anvender et AI-system til rekruttering, kreditvurdering, adgangskontrol til uddannelse eller lignende høj-risiko formål, er Annex IV det dokument, du skal kende udenad.
Denne artikel gennemgår alle otte hovedelementer i Annex IV, oversætter dem til HR-tech konteksten og forklarer, hvad der konkret kræves for et rekrutteringsscreeningssystem.
Hvad er Annex IV, og hvem er den relevant for?
EU AI Act trådte i kraft 1. august 2024. Forbuddene mod uacceptabel risiko-AI (Art. 5) gjaldt fra 2. februar 2025 — samme dato som Art. 4 om AI-kompetencer. For høj-risiko AI-systemer — herunder dem, der er oplistet i Annex III til forordningen — er overgangsfristen 2. august 2026 (gældende frist — Digital Omnibus-ændringen, der vil udskyde den til 2. december 2027, afventer publicering i EU-Tidende og er endnu ikke i kraft). Det er den dato, hvor al teknisk dokumentation skal være på plads og verificerbar.
Annex III lister de systemkategorier, der klassificeres som høj-risiko. Rekrutteringssoftware, der bruges til at screene CV'er, rangordne ansøgere eller filtrere kandidater, er eksplicit nævnt (Annex III, pkt. 4). Det gælder uanset om du er den, der har bygget systemet (provider/udbyder), eller den, der bruger det i praksis (deployer/bruger).
Annex IV specificerer præcis, hvad den tekniske dokumentation for disse systemer skal indeholde. Det er ikke en checkliste, man kan tilpasse efter smag — det er bindende minimumskrav, som tilsynsmyndighederne vil forvente at se dokumenteret.
De otte hovedelementer i Annex IV
§1 — Generel beskrivelse af AI-systemet
Det første element er en overordnet beskrivelse, der skal give læseren — typisk en tilsynsmyndighed eller ekstern revisor — et klart billede af, hvad systemet er og gør.
Beskrivelsen skal ifølge Annex IV §1 indeholde:
- Formål og tilsigtede anvendelsesområder: Hvad er systemet designet til at gøre? Hvilke konkrete beslutninger understøtter det?
- Versionsinformation: Versionnummer, udgivelsesdato og en kort ændringsoversigt (changelog).
- Hardware- og softwarekrav: Hvilken infrastruktur kræves for at køre systemet? Hvilke afhængigheder (biblioteker, tredjepartskomponenter) er systemet bygget på?
- Deployment-kontekst: I hvilke lande og sammenhænge er systemet tænkt brugt? Hvem er slutbrugerne — HR-medarbejdere, rekrutteringschefer, automatiserede pipelines?
HR-tech oversættelse: For et rekrutteringsscreeningssystem betyder §1 i praksis: en kort produktbeskrivelse der specificerer, at systemet rangordner jobansøgere baseret på CV-data, at det kører på en bestemt cloud-platform, og at det er tænkt brugt af HR-teams i virksomheder med mere end X ansatte. Versionsstyring er ikke valgfrit — den tekniske dokumentation skal afspejle den aktuelle version til enhver tid.
§2 — Beskrivelse af elementer og udviklingsproces
Dette er det mest teknisk tunge afsnit. Annex IV §2 kræver dokumentation af, hvordan systemet er blevet bygget — ikke blot hvad det kan.
Kravene inkluderer:
- Træningsdata: Hvilke datasæt er brugt til at træne modellen? Hvad er datakilderne, og hvordan er data blevet indsamlet, preprocesseret og annoteret?
- Træningsmetodologi: Hvilken algoritme eller modeltype er brugt? Logistisk regression, gradient boosting, neural network? Hvilke hyperparametre er valgt og hvorfor?
- Valideringsresultater: Hvilke resultater opnåede systemet under intern validering? Præcision, recall, F1-score eller tilsvarende metrikker afhængigt af systemtypen.
- Kendte begrænsninger i udviklingsfasen: Hvad viste det sig, at systemet ikke kan? Hvilke edge cases eller datatyper klarede det sig dårligt på?
HR-tech oversættelse: Et rekrutteringssystem skal her dokumentere, at det er trænet på en historisk ansættelsesdatabase — og det er præcis her, at mange HR-tech-leverandører løber ind i problemer. Hvis træningsdataene afspejler tidligere ansættelsesbeslutninger, der var påvirket af skæve udvælgelseskriterier, vil modellen reproducere disse mønstre. §2-dokumentationen skal ikke blot beskrive træningsdataene — den skal vise, at datakvalitet og repræsentativitet er aktivt vurderet.
§3 — Detaljeret information om overvågning, funktion og kontrol
Annex IV §3 handler om, hvad der sker, når systemet er i drift. Det er ikke nok at dokumentere, hvordan det virker i teorien — der skal foreligge dokumentation for, hvordan det overvåges og kontrolleres i praksis.
Kravene inkluderer:
- Performance-metrikker i produktion: Hvilke nøgletal overvåges løbende? Hvad er tærskler for acceptable og uacceptable afvigelser?
- Fejlrater og incident-log: Hvordan registreres fejl? Hvad er de kendte fejltyper, og hvad er den historiske fejlrate?
- Kendte begrænsninger i drift: Hvilke situationer klarer systemet sig dårligt i? Hvad er systemets gyldige anvendelsesområde (scope), og hvad er det udtrykkeligt ikke egnet til?
- Foranstaltninger til kontinuerlig monitorering: Hvem er ansvarlig for overvågningen? Hvilke alarmsystemer er implementeret?
HR-tech oversættelse: Har du et dashboard, der viser, hvordan dit screeningssystem performer over tid? Er der nogen, der kigger på, om accept-raten varierer systematisk på tværs af demografiske grupper? §3 kræver, at dette ikke blot sker ad hoc — det skal være formaliseret og dokumenteret.
§4 — Beskrivelse af human oversight-foranstaltninger
Artikel 14 i EU AI Act stiller krav om, at høj-risiko AI-systemer er designet med mulighed for menneskelig tilsyn. Annex IV §4 kræver, at disse foranstaltninger er beskrevet i den tekniske dokumentation.
Det betyder konkret:
- Brugergrænsefladedesign: Hvordan præsenteres AI-systemets output til den menneskelige operatør? Er det klart, at der er tale om et AI-assisteret forslag og ikke en endelig beslutning?
- Mulighed for at tilsidesætte: Kan brugeren afvise eller ændre systemets anbefaling? Er denne mulighed synlig og tilgængelig?
- Kompetencekrav til operatørerne: Hvilken viden og hvilke færdigheder skal en bruger have for at anvende systemet forsvarligt?
- Stop-funktion: Kan systemet tages ud af drift øjeblikkeligt, hvis det er nødvendigt?
HR-tech oversættelse: Artikel 14 og §4 er særligt relevante for rekrutteringssystemer, fordi det er let at glide ind i en praksis, hvor "AI-systemet sagde nej, så vi afviste ansøgeren" — uden at en menneskelig vurdering reelt finder sted. Dokumentationen skal vise, at systemets arkitektur aktivt modvirker dette — at HR-medarbejderen ser et forslag, ikke en afgørelse.
§5 — Beskrivelse af validering og testning
Annex IV §5 kræver en separat og detaljeret dokumentation af test- og valideringsprocessen. Dette er ikke identisk med §2's beskrivelse af udviklingsprocessen — §5 fokuserer specifikt på verifikation af systemets ydeevne, herunder:
- Testdatasæt: Hvilke datasæt er brugt til at teste systemet? Er de adskilt fra træningsdata? Hvad er deres sammensætning?
- Metrikker og benchmarks: Hvilke mål er brugt til at evaluere systemet? Hvad er resultaterne — ikke kun samlet, men opdelt på relevante undergrupper (alder, køn, etnicitet)?
- Ydeevne på tværs af grupper: EU AI Act lægger særlig vægt på ikke-diskrimination. §5-dokumentationen skal vise, at systemet er testet for skæv ydeevne på tværs af beskyttede karakteristika.
- Robusthed under distribution shift: Hvad sker der, hvis de data, systemet ser i produktion, afviger fra træningsdataene? Er dette testet?
HR-tech oversættelse: Et rekrutteringsscreeningssystem skal dokumentere, at det er testet på et adskilt testdatasæt, og at ydeevnen er opgjort separat for relevante undergrupper — fx køn og aldersgrupper — så skæv ydeevne opdages, før systemet tages i brug.
§6 — Risikoledelsessystemet
Annex IV §6 kræver en detaljeret beskrivelse af risikoledelsessystemet efter Artikel 9 — dokumentation for, at risici er identificeret, analyseret og afbødet i en løbende, iterativ proces gennem hele systemets livscyklus.
HR-tech oversættelse: Risikovurderingen af et screeningssystem er ikke et engangsdokument. Den skal have en ejer, en opdateringskadence og et versionsspor — og den skal opdateres, når modellen, brugskonteksten eller vidensgrundlaget ændrer sig.
§7 — Ændringer gennem livscyklussen og anvendte standarder
Annex IV §7 kræver en beskrivelse af relevante ændringer, der er foretaget i systemet gennem dets livscyklus, samt en liste over de harmoniserede standarder, der er anvendt helt eller delvist.
HR-tech oversættelse: Hver modelopdatering, der ændrer scoring-adfærden, skal kunne genfindes i dokumentationen — hvad blev ændret, hvorfor, og hvad viste re-valideringen?
§8 — EU-overensstemmelseserklæring og post-market plan
Endelig kræver Annex IV en kopi af EU-overensstemmelseserklæringen samt en detaljeret beskrivelse af planen for overvågning af systemet, efter det er bragt i omsætning (post-market monitoring, jf. Art. 72).
HR-tech oversættelse: Dokumentationen slutter ikke ved go-live. Der skal foreligge en plan for, hvordan performance, klager og hændelser opsamles og føres tilbage til risikovurderingen.
Dermed er alle otte hovedelementer dækket. Den røde tråd er verificerbarhed: Dokumentationen skal afspejle systemet, som det faktisk er i drift — ikke som det så ud ved lancering.