For en dansk HR-tech-leverandør eller en HR-afdeling, der ruller AI-værktøjer ud til 200+ medarbejdere, er 2026 året, hvor to vidt forskellige reguleringsregimer møder hinanden. NIS2-direktivet — som i Danmark er implementeret gennem NIS2-loven (lov nr. 434 af 6. maj 2025) med ikrafttræden 1. juli 2025 — adresserer cybersikkerhed og driftsmodstandskraft. EU AI Act adresserer AI-systemers risici for grundlæggende rettigheder og sikkerhed. På overfladen er det to verdener. I praksis overlapper de markant — særligt på incident-rapportering, leverandørstyring, governance og dokumentation.
Denne artikel kortlægger overlappet konkret for HR-tech-domænet og giver et bud på, hvordan en deployer kan bygge én sammenhængende compliance-arkitektur frem for to parallelle. Det er hverken juridisk rådgivning eller en udtømmende gennemgang — men det er det praktiske startpunkt, vi bruger med danske deployers i M1-leverancen.
1. Hvem rammes faktisk af NIS2 i HR-tech-konteksten?
Først det vigtige nuance-spørgsmål: NIS2 rammer ikke alle. Direktivet (Directive (EU) 2022/2555) opdeler omfattede enheder i væsentlige (essential) og vigtige (important) baseret på sektor og størrelse. Den danske NIS2-lov gælder for store og mellemstore virksomheder i Annex I- og Annex II-sektorerne. For HR-tech-domænet er der typisk to relevante adgange:
(a) Deployeren er selv NIS2-omfattet. Hvis HR-afdelingen er placeret i en virksomhed eller offentlig myndighed, der i forvejen er NIS2-omfattet — fx en bank (finans/digitale tjenester), en hospitalsregion (sundhed), et energiselskab, et transportselskab, en kommune eller en statslig styrelse — så er HR-systemerne en del af den NIS2-omfattede infrastruktur. Cyberhændelser i HR-systemet kan udløse incident-rapportering, og leverandørstyring af HR-tech-vendoren er en del af forsyningskæde-disciplinen.
(b) HR-tech-leverandøren er en kritisk leverandør til en NIS2-omfattet kunde. NIS2 stiller krav til, at omfattede enheder håndterer cyberrisici i forsyningskæden (Art. 21, stk. 2, litra d). Det betyder, at den NIS2-omfattede kunde vil stille kontraktuelle krav til sin HR-leverandør om sikkerhedsforanstaltninger, incident-notifikation og audit-ret — selv hvis leverandøren ikke i sig selv er NIS2-omfattet. Effekten er reel: en lille dansk HR-tech-leverandør bliver de facto trukket ind i NIS2-regimet via sine kundekontrakter.
Hertil kommer ICT-tjenesteudbydere (managed service providers, datacentre, cloud) i Annex I, der eksplicit er omfattet. Hvis HR-tech-leverandøren er en SaaS, der i praksis fungerer som en managed service for kunden, ligger der en selvstændig vurdering.
2. Hvor overlapper de to regimer konkret?
Overlappet er ikke teoretisk. Det er konkret nok til, at en HR-tech-deployer kan ende med at skulle dokumentere det samme ad to spor, hvis der ikke bygges sammenhæng. De fem mest udtalte overlapzoner er:
(i) Incident-rapportering. NIS2 (Art. 23) kræver, at omfattede enheder rapporterer betydelige hændelser til CSIRT/kompetent myndighed — typisk en tidlig varsel inden for 24 timer, en mere fuldstændig rapport inden for 72 timer og en endelig rapport inden for en måned. EU AI Act (Art. 73) kræver, at providers af høj-risiko AI rapporterer alvorlige hændelser til markedsovervågningsmyndigheden inden for 15 dage (eller hurtigere ved bestemte typer). For deployers udløses ofte en kæde: en oplevet hændelse i HR-systemet kan både være en cyberhændelse (NIS2-spor) og en AI-systemhændelse (AI Act-spor), der skal rapporteres til to forskellige myndigheder med to forskellige frister og to forskellige format-krav.
(ii) Leverandør- og forsyningskædestyring. NIS2 Art. 21, stk. 2, litra d kræver formel risikohåndtering i forsyningskæden — herunder vurdering af leverandørens sikkerhedspraksis. EU AI Act Art. 25 og Art. 26 fordeler ansvar mellem provider, importør, distributør og deployer. Begge regimer kræver, at deployeren har styr på, hvem leverandøren er, hvad de leverer, og hvilke aftaler der gælder. Et fælles leverandørregister med både cyber- og AI-attributter er typisk mere effektivt end to parallelle.
(iii) Governance og ledelsesansvar. NIS2 Art. 20 placerer eksplicit ansvar for cybersikkerhed hos ledelsesorganet — og kræver, at ledelsen modtager regelmæssig træning. EU AI Act har ikke en lignende eksplicit ledelsesparagraf, men Art. 4 (AI-literacy, i kraft siden 2. februar 2025) udgør i praksis et analogt krav: organisationen — inklusive ledelsen, hvor relevant — skal have tilstrækkelig AI-forståelse. En fælles governance-struktur med AI- og cybersikkerhedsrapportering til samme komité reducerer både omkostning og siloer.
(iv) Dokumentation og audits. Begge regimer forudsætter, at compliance kan dokumenteres på anmodning. NIS2 lader CSIRT/tilsynet udføre audits og kræve dokumentation; EU AI Act lader markedsovervågningsmyndigheden gøre det samme. Hvis dokumentationsarkitekturen er fælles — fx ét system-of-record med politikker, registre, logs og evidens — kan begge tilsyn betjenes uden ekstra arbejde.
(v) Logs og opbevaringsperioder. EU AI Act Art. 26, stk. 6 kræver mindst 6 måneders logopbevaring for høj-risiko AI. NIS2 kræver ikke en specifik periode, men forventer logs, der er tilstrækkelige til at understøtte incident-respons. For HR-systemer ligger den effektive opbevaringstid ofte længere pga. ansættelsesretlige hensyn (5 års bogføring, GDPR-formålsbestemte perioder). Én logging-arkitektur, der dækker alle tre krav, er typisk billigere end tre.
3. Hvor er de IKKE overlappende — og hvor man skal være forsigtig
Det er lige så vigtigt at notere, hvor de to regimer går hver sin vej, så man ikke ved et uheld antager, at NIS2-compliance dækker AI Act-spørgsmål eller omvendt.
Bias og diskrimination: NIS2 har intet at sige om, hvorvidt et HR-screeningsystem behandler kvinder anderledes end mænd. EU AI Act Art. 10 (data governance og bias-test) og den implicitte ikke-diskriminationsvurdering i en FRIA (Art. 27) er de relevante spor. Cybersikkerhedsteamet vil typisk ikke have kompetence eller mandat til at føre denne del.
Forklaringsret og transparens: EU AI Act Art. 86 (forklaring) og Art. 13 (transparens over for deployer) er specifikke for AI-output. NIS2 har ingen tilsvarende mekanisme; den orienterer sig mod sikkerhed og driftskontinuitet.
Bøde-niveauer: NIS2 fastsætter et loft på 10 mio. EUR for væsentlige enheder og 7 mio. EUR for vigtige enheder; de tilsvarende omsætningssatser er 2 % og 1,4 % (det højeste beløb gælder). EU AI Act har sit eget tre-niveau-regime (Art. 99) med op til 35 mio. EUR eller 7 % i den strengeste kategori. Bøderne er kumulative — én hændelse kan udløse to bødeforløb.
Personlig haftung: NIS2 Art. 20 åbner i visse tilfælde for, at ledelsesmedlemmer kan blive personligt holdt ansvarlige (afhængig af national gennemførelse). EU AI Act adresserer ikke personlig ledelseshaftung direkte, men nationale strafferetlige regler kan komme i spil ved grove overtrædelser.
4. Praktisk arkitektur: én compliance-stak, to reguleringsspor
Den arkitektur, vi anbefaler danske HR-tech-deployers, der både er NIS2- og AI Act-eksponerede, har fire fælles fundamenter:
(1) Ét leverandørregister. Inkluder for hver leverandør: navn, CVR, kontraktansvarlig, NIS2-relevans (er de selv omfattet? er de kritiske for vores drift?), AI Act-rolle (provider, importør, distributør), seneste sikkerheds- og AI-vurdering, DPA-status, og kontraktansvarlig hos jer. Skab attributter — ikke parallelle registre.
(2) Ét systeminventar med dual-tagging. For hvert IT-system: er det NIS2-kritisk? Er det høj-risiko AI under Annex III? Er det både? Tagging gør det muligt at filtrere for begge tilsyn fra samme database. PowerQuant M1 producerer typisk dette inventar som første leverance — med både AI Act- og GDPR-attributter; NIS2-attributter tilføjes typisk for kunder, der er NIS2-eksponeret.
(3) Én incident-pipeline med dobbelt-vurdering. Når en hændelse opstår, kører den gennem én triage-proces, hvor vurderingen eksplicit afklarer: er dette en NIS2-betydende hændelse? Er dette en AI Act Art. 73-hændelse? Skal vi rapportere til CSIRT, markedsovervågningsmyndighed, eller begge? Frister og format-krav genereres pr. spor. Pipelinen dokumenterer beslutningen — også når svaret er "ingen rapportering kræves".
(4) Én governance-forum. Etabler en compliance-komité, der dækker både AI, cyber, GDPR og — hvor relevant — sektor-specifik regulering. Mødefrekvens og deltagerkreds varierer, men princippet er, at man ikke skal have to parallelle udvalg, der træffer overlappende beslutninger om de samme systemer.
5. NIS2-tidslinjen for danske HR-tech-deployers
For danske aktører er det værd at huske den specifikke tidslinje. EU-deadlinen for transposition var 17. oktober 2024. Danmark vedtog NIS2-loven (lov nr. 434 af 6. maj 2025), og hovedloven trådte i kraft 1. juli 2025. Omfattede enheder skulle registrere sig senest 1. oktober 2025. Den danske implementering er sektor-opdelt: én generel cross-sektor-lov suppleret med sektorspecifikke regelsæt (energi, tele, finansielle digitale tjenester). En NIS2-omfattet HR-tech-deployer skal således kende både den generelle ramme og den sektorspecifikke gennemførelse, der gælder for sin egen sektor.
EU AI Acts hovedkrav til høj-risiko AI bliver fuldt anvendelige fra 2. august 2026 — kun ca. ét år efter NIS2-loven. For mange deployers betyder det, at de to compliance-projekter overlapper også i tid, og at det er økonomisk og organisatorisk rationelt at planlægge dem som ét.
Konklusion: behandl dem som ét compliance-system med to udsigtsvinduer
NIS2 og EU AI Act er ikke det samme. De har forskellige formål, forskellige myndigheder og forskellige bøde-skalaer. Men de stiller mange af de samme operationelle krav — leverandørstyring, dokumentation, hændelseshåndtering, governance — og en HR-tech-deployer, der bygger to parallelle compliance-systemer, betaler dobbelt og får friktion mellem dem.
Den effektive vej er én compliance-arkitektur med dual-attribution: ét leverandørregister, ét systeminventar, én incident-pipeline, én governance-forum — med eksplicit markering af, hvad der er NIS2-relevant, hvad der er AI Act-relevant, og hvad der er begge dele. Det er ikke et magisk projekt. Det er disciplinen i at lade arkitekturen reflektere virkeligheden frem for reguleringssiloerne.