Annex IV teknisk dokumentation: Komplet guide til hvad der skal med

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. Forbudene mod uacceptabel risiko-AI gjaldt fra 2. februar 2025 (Art. 4-datoen). For høj-risiko AI-systemer — herunder dem, der er oplistet i Annex III til forordningen — er overgangsfristen 2. december 2027. 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 udtrykkelig 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ærlig 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 dokum