Når en rekrutteringsalgoritme begynder at frasortere kvalificerede kandidater — ikke fordi de er dårligt egnede, men fordi systemet gradvist har mistet kontakten med virkeligheden — er det ikke blot et teknisk problem. Det er et complianceproblem. Artikel 15 i EU AI Act sætter præcise krav til, hvordan høj-risiko AI-systemer skal præstere, modstå fejl og forsvare sig mod manipulation. For HR-afdelinger, der anvender AI til rekruttering eller performance management, er dette den artikel, der oversætter teknisk kvalitetssikring til juridisk forpligtelse.
Hvad Art. 15 faktisk siger — og hvad det kræver af dig
EU AI Act trådte i kraft 1. august 2024. De generelle forpligtelser under Art. 4 gælder fra 2. februar 2025. For høj-risiko AI-systemer — herunder systemer til rekruttering, udvælgelse og præstationsvurdering, som er oplistet i Annex III — løber den fulde compliance-frist til 2. december 2027.
Art. 15 er en af de mere teknisk tunge bestemmelser i loven. Den handler ikke om dokumentation eller transparens — den handler om selve systemets indre kvalitet.
Artiklen indeholder fire stykker, der tilsammen tegner et billede af, hvad "tilstrækkelig teknisk kvalitet" betyder for et høj-risiko AI-system.
Art. 15 stk. 1: Præstationsniveauer through hele livscyklus
Det første stykke fastslår det grundlæggende princip: Høj-risiko AI-systemer skal designes og udvikles på en måde, der sikrer, at de opnår et passende niveau af nøjagtighed, robusthed og cybersikkerhed — og at disse niveauer opretholdes throughout the entire lifecycle af systemet.
Det er en sætning, der har stor praktisk konsekvens. Det er ikke nok, at systemet præsterede godt ved den initiale test eller ved godkendelsestidspunktet. Lovens krav følger systemet fra deployment til afvikling.
For en HR-deployer betyder det: Du kan ikke købe et rekrutteringssystem, sætte det i drift og lade det køre uovervåget i tre år. Du er — som deployer — forpligtet til at overvåge systemets præstation løbende og gribe ind, hvis den falder. Art. 9 (risikostyring) og Art. 26 (deployerens forpligtelser) supplerer dette krav med konkrete handlingspligter.
Art. 15 stk. 2: Nøjagtighed — hvad det kræver for HR-systemer
Stk. 2 fokuserer på nøjagtighed (*accuracy*). Bestemmelsen kræver, at systemer er trænet og testet med det formål at nå den bedst mulige nøjagtighed — og at nøjagtighedsniveauer deklareres i den tekniske dokumentation.
I HR-kontekst er nøjagtighed ikke abstrakt. Det handler om:
Korrekt klassificering: Klassificerer systemet kandidater korrekt som egnede eller uegnede til en given rolle? Fejlklassificering kan have to typer konsekvenser — falske positiver (ukvalificerede kandidater rykkes frem) og falske negativer (kvalificerede kandidater sættes uretmæssigt ud). Sidstnævnte har direkte overlap med diskriminationsreglerne i Art. 10 og Annex III-kategorierne.
Lav fejlrate over tid: Et system der er nøjagtigt ved launch, men gradvist degraderer, opfylder ikke Art. 15. Lovens krav er ikke et øjebliksbillede — det er en kurve over tid.
Deklarerede metrikker: Leverandøren er forpligtet til at oplyse, hvilke nøjagtighedsmetrikker systemet er testet imod, og hvad resultaterne var. Som deployer bør du insistere på at modtage disse som del af leverandørkontrakt og teknisk dokumentation. Acceptér ikke svar som "systemet er valideret" uden konkrete tal.
Art. 15 stk. 3: Robusthed — modstandsdygtighed over for fejl og afvigelser
Stk. 3 omhandler robusthed (*robustness*). Her præciseres det, at systemer skal designes til at modstå fejl, uregelmæssige inputs og driftsafvigelser — og at de skal have passende mekanismer til at håndtere disse situationer på en sikker måde, inkl. fallback-procedurer.
For HR-AI-systemer er der tre primære robustheds-scenarier:
1. Fejl i inputdata: Hvad sker der, hvis systemet modtager et CV med usædvanlig formatering, manglende felter eller atypiske tegnsæt? Et robust system degraderer ikke pludselig til tilfældig output — det håndterer sådanne inputs forudsigeligt og dokumenteret.
2. Distributional shift: Dette er et af de alvorligste scenarier for HR-AI. Et system trænet på data fra 2021-2023 kan være optimeret til ansøgerprofiler, sproglige mønstre og karriereveje, der gradvist ophører med at afspejle den reelle ansøgerpopulation. Arbejdsmarkedet ændrer sig. Uddannelsesnavne ændrer sig. Branchebetegnelser ændrer sig. Hvis systemet ikke løbende valideres mod aktuelle data, degraderer nøjagtigheden stille og roligt — og du opdager det måske ikke, før skaden er sket.
3. Edge cases og out-of-distribution inputs: En kandidat med en karrierevej, der ikke passer ind i systemets trænede mønstre — eksempelvis en selvstændig med mange kortere projekter, eller en person der har skiftet branche — kan score systematisk lavere end en klassisk profil, selv om vedkommende er mindst ligeså kvalificeret. Et robust system skal håndtere sådanne profiler uden at kollapse i usandsynlige scoringer.
Robusthed er ikke blot en teknisk egenskab — det er et nøgleelement i systemets fairness-profil over for kandidater.
Art. 15 stk. 4: Cybersikkerhed — beskyttelse mod angreb
Stk. 4 indfører et direkte krav om cybersikkerhed. Høj-risiko AI-systemer skal være resiliente over for forsøg på at manipulere deres output ved hjælp af teknikker, der specifikt retter sig mod AI-komponenten.
Dette er et nyt og vigtigt element sammenlignet med traditionel IT-sikkerhed. Det handler ikke (kun) om at beskytte persondata mod databrud — det handler om at beskytte selve beslutningslogikken i systemet.
Tre angrebstyper er særligt relevante:
Adversarial attacks: Input der er konstrueret med det formål at snyde systemet til et bestemt output. I et rekrutteringssystem kan dette eksempelvis være et CV der indeholder skjulte nøgleord (hvide bogstaver på hvid baggrund, eller metadata-felter) der manipulerer systemets scoring uden at være synlige for den menneskelige reviewer.
Data poisoning: Angreb der retter sig mod selve træningsprocessen. Hvis en leverandør løbende genoptræner sit system med brugerdata, kan en aktør der kontrollerer inputdata potentielt påvirke systemets adfærd ved at indsende manipulerede profiler i stor mængde. Dette er et relevant scenarie for SaaS-løsninger, der aggregerer data på tværs af mange kunder.
Model evasion: Teknikker der systematisk udnytter systemets blinde pletter til at opnå høj score. En kandidat der lærer systemets scoring-logik — enten gennem trial-and-error eller via lækket information — kan konstruere sit CV til at score optimalt, uanset faktisk egnethed.
Hvad sker der, når kandidater forsøger at "game" algoritmen?
Model evasion i rekrutteringssammenhæng er ikke hypotetisk. Det er et voksende fænomen. Der eksisterer allerede onlinefora, konsulenttjenester og automatiserede AI-værktøjer, der hjælper kandidater med at optimere deres ansøgning til specifikke ATS-systemer og rekrutteringsalgoritmer.
Dette skaber et konkret dilemma for virksomheder, der anvender HR-AI: Systemet er designet til at identificere de bedst egnede kandidater — men hvis egnetheden måles ved evnen til at score højt i systemet, og scoring kan optimeres uafhængigt af faktisk egnethed, er målevaliditeten kompromitteret.
Art. 15 adresserer dette direkte ved at pålægge leverandøren et ansvar for at designe systemer der er resiliente over for sådanne forsøg. Det indebærer løbende red-team-testning, adversarial testing som del af validationsprocessen, og opdatering af systemet, når nye evasion-teknikker opdages.
Som deployer bør du spørge din lev