PowerQuant

EU AI Act Art. 13: Gennemsigtighed og forklarlighed for medarbejdere og kandidater

PowerQuant · EU AI Act compliance for HR-tech

Når en kandidat bliver afvist af en AI-screener, eller en medarbejder ser et performance-score, de ikke forstår, stiller de et naturligt spørgsmål: *Hvorfor?* EU AI Act giver nu dette spørgsmål juridisk vægt. Art. 13 om gennemsigtighed og Art. 86 om retten til forklaring udgør tilsammen et af de mest undervurderede krav i forordningen — og de rammer HR-afdelinger og virksomheder, der bruger AI til personalebeslutninger, direkte.

Denne artikel gennemgår, hvad de to artikler konkret kræver, hvem der er ansvarlig for hvad, og hvad "forklarlighed" rent faktisk betyder i praksis — ikke i lovtekstens abstraktion, men i den situation, hvor en kandidat banker på HR-døren og beder om svar.


Hvad er Art. 13, og hvem er den rettet mod?

Art. 13 i EU AI Act handler om gennemsigtighed over for deployers — altså de virksomheder, der køber og anvender et høj-risiko AI-system. Det er ikke primært en rettighed for slutbrugere eller berørte personer; det er et designkrav rettet mod AI-udbyderne (providers) og en informationsforpligtelse over for dem, der sætter systemet i drift.

Art. 13, stk. 1 fastslår, at høj-risiko AI-systemer skal designes og udvikles på en måde, der sikrer tilstrækkelig gennemsigtighed til, at deployers kan forstå systemets funktionalitet, fortolke dets output og anvende det korrekt. Det er med andre ord et krav om, at systemet ikke er en uigennemskuelig "black box" — i hvert fald ikke for den virksomhed, der bruger det.

Art. 13, stk. 2 specificerer, at dette opnås via en brugervejledning (instructions for use). Selve vejledningen er det konkrete, håndgribelige krav, som AI-udbyderen skal levere som del af systemet. Det er ikke nok at påstå, at systemet er transparent — transparensen skal dokumenteres og formidles i et format, som deployers kan bruge i praksis.


De syv minimumskrav til brugervejledningen

Art. 13, stk. 3 opstiller en liste over, hvad brugervejledningen som minimum skal indeholde. Det er værd at gennemgå punkterne konkret, fordi de i praksis fungerer som en tjekliste for virksomheder, der skal vurdere, om en AI-leverandør overholder forordningen:

  • Identitet og kontaktoplysninger — Navn og adresse på udbyder samt eventuel autoriseret repræsentant i EU. Grundlæggende, men en hurdle for ikke-EU-leverandører, der mangler en officiel EU-repræsentation.
  • Systemets formål og anvendelsesområde — En klar beskrivelse af, hvad systemet er designet til, hvilke opgaver det løser, og i hvilke kontekster det er testet og valideret. For et rekrutteringssystem betyder det en præcis afgrænsning af, hvilke stillingsprofiler og kandidatpopulationer modellen er valideret på.
  • Begrænsninger og kendte risici — Vejledningen skal eksplicit beskrive, hvad systemet *ikke* kan, hvilke situationer det er dårligt til at håndtere, og hvilke fejlmodes der er identificeret. I rekruttering kan det fx være, at systemet underpræsterer for kandidater fra bestemte uddannelsesbaggrunde eller med atypiske karriereforløb.
  • Performance-niveau og evalueringsmetrikker — Konkrete tal for systemets præcision, recall, eller hvad der nu er den relevante metrik for den pågældende opgave. Generelle udsagn som "systemet er meget præcist" er ikke tilstrækkeligt. Deployers har brug for tallene, så de kan vurdere, om systemet er godt nok til den specifikke kontekst.
  • Data og træningsgrundlag — Oplysninger om de datasæt, systemet er trænet og valideret på, herunder relevant information om mulige bias. Her er koblingen til ligebehandlingslovgivningen og GDPR tydelig: Et system trænet på historisk ansættelsesdata risikerer at reproducere tidligere diskrimination.
  • Overvågning og logning — Vejledningen skal beskrive, hvilke logdata systemet genererer, og hvordan deployers skal overvåge systemet under drift. Det er ikke nok at installere systemet og håbe, at det fungerer — Art. 13 kræver, at der er et fundament for løbende tilsyn.
  • Ændringer og versionsstyring — Oplysninger om, hvilke typer ændringer til systemet der kræver ny overensstemmelsesvurdering, og hvad deployers skal gøre, hvis der opdateres. En stille opdatering til en scoring-model kan have store konsekvenser for, hvilke kandidater der går videre — deployers har krav på at vide, hvornår det sker.
  • Disse syv punkter er ikke vejledende anbefalinger. De er minimumskrav. En brugervejledning, der mangler et eller flere af dem, er ikke i overensstemmelse med Art. 13.


    Art. 86: Retten til forklaring — en anden forpligtelse, en anden ansvarlig

    Mens Art. 13 handler om transparens *ind i* systemet over for deployers, handler Art. 86 om transparens *ud af* systemet over for de berørte personer. Det er to forskellige retssituationer med to forskellige ansvarlige.

    Art. 86 giver fysiske personer, der er genstand for en afgørelse truffet af en deployer på baggrund af et høj-risiko AI-systems output, ret til at bede om en meningsfuld forklaring af den pågældende afgørelse. Det gælder specifikt beslutninger, der vedrører dem selv.

    Hvem har retten?

    Retten tilkommer de *berørte personer* — konkret kandidater og medarbejdere, hvis der er tale om AI-systemer til rekruttering, udvælgelse, forfremmelse, opsigelse, arbejdstildeling eller præstationsvurdering. Annex III til EU AI Act kategoriserer netop disse anvendelsestilfælde som høj-risiko, og fristen for fuld overholdelse er 2. december 2027.

    Hvornår udløses retten?

    Retten udløses, når der er truffet en afgørelse, der i væsentlig grad påvirker den pågældende person. I HR-sammenhæng dækker det typisk:

  • En kandidat afvises fra videre behandling i en rekrutteringsproces på baggrund af en AI-screening.
  • En medarbejder modtager et negativt performance-score, der danner grundlag for en advarsel, nedrykning eller afskedigelse.
  • En medarbejder forbigås ved en forfremmelse, og AI-output har indgået i beslutningsgrundlaget.
  • Det centrale er, at det er en *afgørelse*, der er truffet. Hvis AI-systemet blot præsenterer data som informationsgrundlag for en menneskelig beslutningstager, der foretager en selvstændig vurdering, er situationen mere nuanceret — men de fleste virksomheder vil have svært ved at løfte bevisbyrden for, at AI-output reelt er holdt adskilt fra afgørelsen.

    Hvad skal forklaringen indeholde?

    Art. 86 kræver ikke, at deployers afslører kildekode, proprietære algoritmer eller detaljer, der udgør forretningshemmeligheder. Men forklaringen skal være *meningsfuld* — et krav, der reelt sætter en minimumsstandard for indhold.

    En meningsfuld forklaring skal typisk:

  • Identificere de væsentligste faktorer, der har haft indflydelse på outputtet eller afgørelsen.
  • Forklare, i hvilken retning disse faktorer har påvirket resultatet (positivt eller negativt).
  • Angive, hvilken rolle AI-systemets output har spillet i den samlede afgørelse.
  • Det er altså ikke tilstrækkeligt at sige: "Vi bruger et AI-system til screening, og du er desværre ikke kommet videre." Det er heller ikke tilstrækkeligt at sige: "Systemet vurderede, at din profil ikke matchede stillingen." Forklaringen skal gå et niveau dybere: Hvilke faktorer? Hvilken vægtning? Hvad var det konkret, der trak i den forkerte retning?


    Forskel på Art. 13 og Art. 86: Provider mod deployer

    En vigtig distinktion, som virksomheder ofte overser: Art. 13 er en provider-forpligtelse, mens Art. 86 er en deployer-forpligtelse.

    Det betyder, at selv hvis AI-leverandøren har leveret en perfekt brugervejledning i henhold til Art. 13, er det stadig den virksomhed, der *bruger* systemet, som bærer ansvaret over for de berørte medarbejde

    Klar til at komme i gang?

    PowerQuant leverer AI-inventar, Article 4-register og gap-analyse på 5 arbejdsdage.

    Start med M1 — 10.999 kr