Et rekrutteringssystem sorterer 3.000 ansøgere fra. En dag opdager HR-chefen, at systemet konsekvent har nedvægtet kvindelige ansøgere til tekniske stillinger. Hvad nu? Hvem kontakter I myndigheder — og inden for hvilken frist?
Det er ikke et hypotetisk scenarie. Det er præcis den situation, EU AI Act er designet til at adressere via artikel 73 om indberetning af alvorlige hændelser. Og for virksomheder, der anvender eller udbyder AI-systemer i Annex III-kategorier — herunder rekruttering og HR — gælder reglerne fuldt ud fra 2. december 2027.
Denne artikel gennemgår, hvad loven kræver, hvornår en AI-fejl er "alvorlig" nok til at udløse indberetningspligt, og hvad din HR-afdeling bør have på plads allerede nu.
Hvad siger artikel 73 egentlig?
Artikel 73 i EU AI Act pålægger providers af høj-risiko AI-systemer en klar pligt: alvorlige hændelser skal indberettes til de kompetente nationale myndigheder. Det er ikke en kan-bestemmelse. Det er en skal-bestemmelse med faste tidsfrister.
Loven definerer en "alvorlig hændelse" (*serious incident*) som en hændelse, der har forårsaget — eller rimeligvis kunne have forårsaget — én af følgende konsekvenser:
Læs definitionen to gange. Bemærk, at loven ikke kun dækker faktisk indtrufne skader. Den dækker også potentielle skader — situationer, der *kunne* have ført til alvorlige konsekvenser. Det er en væsentlig udvidelse af indberetningspligten.
For de fleste HR-afdelinger er den naturlige reaktion: "Rekruttering dræber da ikke folk." Den reaktion er forståelig, men den overser en vigtig nuance.
Hvornår kan en AI-rekrutteringsfejl være "alvorlig"?
Koblingen mellem HR-AI og alvorlig hændelse er ikke åbenlys. Den kræver analyse af to scenarier, som retspraksis og tilsynsmyndighedernes vejledninger gradvist udformer.
Scenarie 1: Systematisk diskrimination med sundhedsmæssige konsekvenser
Forestil dig et AI-system, der konsekvent frafiltrerer ansøgere med visse navnetyper, aldersgrupper eller CV-mønstre korreleret med etnicitet. Hvis en person som følge af gentagen, AI-drevet afvisning oplever dokumenteret psykisk skade — f.eks. alvorlig depression diagnosticeret af læge — kan kæden fra AI-fejl til "alvorlig skade på persons sundhed" potentielt lukkes.
Det er endnu ikke etableret retspraksis under AI Act, men det er retningen i tilsynsmyndighedernes fortolkningsdokumenter. Systematisk bias kombineret med dokumenterbar personskade er det scenarie, compliance-jurister vurderer som det mest sandsynlige til at udløse artikel 73.
Scenarie 2: Fejl med direkte personalemæssige konsekvenser
Et AI-system anvendt til intern performance-evaluering fejlvurderer en medarbejder og anbefaler afskedigelse. Medarbejderen afskediges. Efterfølgende viser det sig, at systemet havde en grundlæggende datafejl. Afhængigt af omstændighederne — og national implementering af loven — kan dette potentielt udgøre en hændelse med "alvorlig og uoprettelig skade".
Det centrale spørgsmål er altid: *Var skaden uoprettelig?* Et jobafslag til en enkelt ansøger i en åben stilling er sandsynligvis ikke uopretteligt. Systematisk bias over måneder, der faktisk har forhindret hundredevis af kandidater i ansættelse, kan være det.
Deployers rolle: Artikel 26, stk. 4
Her er en sondring, som mange virksomheder misforstår: Indberetningspligten i artikel 73 hviler primært på provideren — altså den virksomhed, der har udviklet og bragt AI-systemet på markedet. Det er ikke deployers direkte opgave at indberette til myndighederne.
Men det betyder ikke, at deployers er fri for ansvar.
Artikel 26, stk. 4 fastslår klart, at deployers skal:
Med andre ord: Din virksomhed er ikke ansvarlig for selve indberetningen til tilsynsmyndigheden, men du er ansvarlig for at opdage, dokumentere og eskalere hændelsen til din leverandør — og for at stoppe systemet, hvis situationen kræver det.
Det kræver, at du har en intern incident response-procedure.
Provider vs. deployer: En oversigt
Sondringen kan virke abstrakt. Her er en konkret oversigt over, hvem der gør hvad:
| Situation | Provider | Deployer |
|---|---|---|
| AI-fejl opdages af deployer | Modtager notifikation fra deployer | Notificerer provider straks |
| Hændelse vurderes alvorlig | Indberetter til national myndighed inden 15 dage | Stopper brugen af systemet |
| Trussel mod liv identificeret | Indberetter inden 3 dage | Stopper brugen omgående |
| Post-incident korrektion | Implementerer korrigerende foranstaltninger | Dokumenterer og evaluerer genoptagelse |
| Tilsynsundersøgelse | Primær part over for myndighed | Samarbejder med provider, fremlægger egne logs |
Deployers, der fejlfortolker loven og selv forsøger at indberette direkte til tilsynsmyndigheden uden om provideren, risikerer at skabe juridisk forvirring. Artikel 26 er klar: deployers kanal er provideren.
Intern incident response: Hvad HR-afdelingen bør have på plads
En compliance-forpligtelse, der ikke er operationaliseret, er et juridisk vakuum. Her er de konkrete elementer, HR-afdelingen bør etablere inden 2. december 2027.
1. En navngivet AI-incident-ansvarlig
Udpeg én person — typisk en HR-compliance-ansvarlig eller IT/legal-hybrid — med klar myndighedsbeskrivelse. Vedkommende er det første kontaktpunkt ved AI-fejl og ansvarlig for at eskalere til provideren. Rollen skal fremgå af virksomhedens AI-governance-dokumentation.
2. En skriftlig incident response-procedure
Proceduren behøver ikke være lang, men den skal eksistere og være kendt. Den bør som minimum indeholde:
3. Et hændelseslog
Al kommunikation om potentielle hændelser skal logges. Dato, beskrivelse, involverede systemer, trufne foranstaltninger, kontakt med provider. Loggen er din dokumentation over for tilsynsmyndigheder, hvis det nogensinde kommer til en undersøgelse.
4. Kontraktuelle forpligtelser med AI-leverandøren
Hændelseshåndtering fungerer kun, hvis leverandøren samarbejder. Sørg for, at jeres leverandøraftaler eksplicit regulerer:
Mange standard SaaS-kontrakter er tavse om dette. Det bør de ikke være fra 2027.
Tidsfrister: Hvornår skal der indberettes?
For providers er tidsfristerne i artikel 73 klare og stramme:
| Hændelsestype | Frist |
|---|---|
| Alvorlig hændelse (general) | 15 dage efter provider er bekendt |
| Hændelse der udgør trussel mod liv | 3 dage efter provider er bekendt |
| Hændelse der har ført til dødsfald | Straks (hurtigst muligt, efterfulgt af fuld rapport) |
For deployers starter uret, når I opdager hændelsen. Jo hurtigere I informerer provideren, jo bedre — båd