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. 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).
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:
- Død hos én eller flere personer
- Alvorlig skade på en persons sundhed (fysisk eller psykisk)
- Alvorlig og uoprettelig skade på ejendom eller miljø
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:
- Informere provideren om hændelser og mistænkte alvorlige hændelser, de er bekendt med
- Stoppe brugen af systemet, hvis hændelsen udgør en risiko for personers sundhed, sikkerhed eller grundlæggende rettigheder
- Samarbejde med provideren om efterforskning og korrigerende foranstaltninger
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. 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).
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:
- Hvad udgør en potentiel hændelse (definitioner tilpasset de konkrete AI-systemer I anvender)
- Hvem modtager intern indberetning (AI-incident-ansvarlig)
- Trin for vurdering: Er det en alvorlig hændelse? Er brugen stoppet?
- Kommunikationsflow til provider: Hvem kontakter I, og hvordan?
- Dokumentationskrav: Hvad logges, og hvordan opbevares det?
3. En 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:
- Leverandørens forpligtelse til at modtage og behandle incident-notifikationer fra jer
- Leverandørens forpligtelse til at informere jer om kendte fejl og risici
- SLA for respons ved hændelser (24 timer? 48 timer?)
Mange standard SaaS-kontrakter er tavse om dette. Det bør de ikke være, når Annex III-kravene får virkning.
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åde fordi det starter leverandørens lovpligtige frister, og fordi det dokumenterer, at I selv har reageret uden ugrundet ophold. Hændelsen bliver ikke mindre af at vente — men jeres ansvar kan blive større.