Hvorfor kommuner bør tænke NIS2 og AI Act sammen

Hvis I stadig håndterer cybersikkerhed, AI og lovkrav som tre separate “spor”, betaler I sandsynligvis tre gange for det samme arbejde — og får kun en brøkdel af effekten.

I denne artikel får du en praktisk ramme til, hvorfor kommuner typisk får størst udbytte ved at tænke cybersikkerhed, AI og compliance som ét samlet styringsområde. Du får konkrete eksempler fra kommunal drift, typiske faldgruber, og en handlingsnær plan for, hvordan I kan organisere jer, prioritere og måle på indsatsen uden at drukne i projekter.

Du kan også bruge artiklen som checkliste: Hvad skal være fælles (data, risikovurderinger, kontroller, leverandørkrav), hvad kan ligge decentralt, og hvordan undgår I, at nye AI-initiativer skaber nye sikkerheds- og lovbrudsriskoer.

Hvad betyder “ét samlet styringsområde” — og hvorfor er det vigtigt?

Et samlet styringsområde betyder, at kommunen organiserer cybersikkerhed, brug af AI og opfyldelse af lovkrav (fx GDPR, NIS2 og sektorspecifikke regler) under én fælles governance: samme risikoproces, samme prioriteringslogik, samme kontrolkatalog og samme rapportering til direktion og udvalg. Pointen er ikke centralisering af alt, men at beslutninger træffes ud fra ét sammenhængende risikobillede.

Det betyder noget, fordi de tre områder i praksis er tæt koblet: AI kræver data; data kræver lovlig behandling; og begge dele kræver sikkerhed. Hvis man styrer dem isoleret, opstår der huller mellem ansvar, kontroller og dokumentation — præcis der, hvor hændelser og tilsynsproblemer typisk opstår.

Mini-konklusion: Når I samler styringen, reducerer I dobbeltarbejde og får hurtigere beslutninger, fordi sikkerhed, jura og teknologi vurderer det samme initiativ på samme tid.

Hvorfor isolerede projekter ofte fejler i kommunal virkelighed

I mange kommuner starter det som fornuftige, afgrænsede projekter: et “AI-pilotprojekt” i borgerservice, et “GDPR-oprydningsprojekt” i socialområdet og et “sikkerhedsprojekt” i IT. Problemet er, at virkeligheden på tværs af forvaltninger ikke respekterer projektgrænser: de samme systemer, data og leverandører går igen.

Tre typiske symptomer på silotænkning

• AI-løsninger købes eller afprøves uden fælles krav til datakilder, logning, adgangsstyring og sletning.
• GDPR-indsatsen fokuserer på dokumenter og fortegnelser, men ikke på tekniske kontroller (fx rettighedsstyring, kryptering, backup og segmentering).
• Sikkerhedsindsatsen ender som “IT’s ansvar”, mens forretningen ejer data og processer — og derfor også risikoen.

Den skjulte omkostning: dobbeltarbejde og langsomme beslutninger

Jeg ser ofte, at samme leverandør skal udfylde tre forskellige spørgeskemaer (sikkerhed, databehandleraftale, AI/etik), med overlap på 60–80%. Det giver friktion, længere indkøbstider og større risiko for, at noget bliver overset. Samtidig får ledelsen tre forskellige statusbilleder, som ikke kan sammenlignes.

Mini-konklusion: Siloprojekter skaber flere artefakter, men ikke nødvendigvis bedre kontrol — og de gør det sværere at prioritere de vigtigste risici.

Fællesnævneren: Risiko, data og leverandører

Hvis man skal samle styringen, er det hjælpsomt at forstå, hvad der reelt binder cybersikkerhed, AI og lovkrav sammen. I kommunal kontekst er det især tre ting: risikostyring, data governance og leverandørstyring.

Risikostyring som fælles sprog

Brug samme risikomodel til alt: sandsynlighed/konsekvens, påvirkning på drift, borgere og lovmedholdelighed. Et AI-initiativ bør vurderes på samme skala som en sikkerhedsændring i netværket eller en ny databehandler. Når skalaen er fælles, bliver prioritering endelig meningsfuld.

Data governance: “hvad må vi” og “hvad kan vi sikre”

AI gør data mere værdifulde — og mere risikofyldte. Kommuner har ofte følsomme data i fagsystemer, ESDH, mails, dokumenter og delte drev. Hvis der ikke er klare regler for dataklassifikation, adgangsroller og lagring, kan en ellers nyttig AI-assistent ende med at behandle oplysninger, den ikke burde have adgang til, eller gemme dem på måder, der strider mod slettepolitikker.

Mini-konklusion: Ét governance-setup gør det muligt at styre AI ud fra de samme data- og risikoprincipper, som I allerede skal have for at være robuste på sikkerhed og compliance.

Lovkrav og standarder: når NIS2, GDPR og AI-krav mødes

Mange oplever lovkrav som “endnu en ting”, men i praksis kan de fungere som et fælles minimumsniveau. GDPR kræver passende sikkerhed og dokumentation; NIS2 skærper krav til ledelsesansvar, hændelseshåndtering og leverandørkæde; og AI-relaterede krav (fx interne politikker for generativ AI og kommende regulering) kræver styr på data, transparens og risiko.

Sådan overlapper kravene i praksis

1. Adgangsstyring og logging understøtter både sikkerhed, revisionsspor og dokumentation af behandling.
2. Hændelseshåndtering er relevant for både driftsstabilitet, brud på persondatasikkerheden og rapportering.
3. Leverandørkrav dækker både databehandleraftaler, sikkerhedsniveau og AI-brug (fx træningsdata og dataplacering).
4. Ledelsesrapportering samler risici og prioriteringer, så direktionen kan træffe beslutninger og tage ansvar.

Mini-konklusion: Når I genbruger kontroller og dokumentation på tværs af krav, får I et mere robust setup med færre “engangsløsninger”.

Hvordan en samlet styring ser ud i praksis (uden at blive tungt)

Den bedste model, jeg har set fungere i kommuner, er en “fælles ramme med decentral udførelse”: centrale minimumskrav og fælles processer, men med plads til fagområdernes tempo og behov.

Et konkret styringssetup (simpelt, men effektivt)

• Fælles policy-lag: AI-politik, informationssikkerhedspolitik, dataklassifikation, indkøbs- og leverandørkrav.
• Én risikoproces: samme skabelon for risikovurdering af nye systemer, AI-cases og ændringer i drift.
• Fælles kontrolkatalog: fx adgangsstyring, backup, logning, sårbarhedshåndtering, dataminimering, sletning.
• Én godkendelsesgate: en tværgående vurdering før pilot og før produktion (sikkerhed, jura, arkitektur, drift).
• Fælles rapportering: få, skarpe KPI’er og risikopunkter til direktion/udvalg hver kvartal.

Hvem gør hvad? Klare roller uden nye “superteams”

Typisk kan man få langt ved at tydeliggøre roller: IT-sikkerhed sætter tekniske standarder og kontroller, DPO/jura sikrer lovlighed og dokumentation, arkitektur/IT-drift sikrer implementering og stabilitet, og fagområderne ejer processen og data. Nøglen er, at ejerskab for risiko ligger hos forretningen, mens metoder og kontroller ligger i den fælles ramme.

Mini-konklusion: En let governance med faste gates og genbrugelige kontroller giver høj effekt uden at bremse innovation.

Midtvejs: derfor bør I samle cybersikkerhed i kommunen med AI og compliance

Når kommuner arbejder seriøst med cybersikkerhed i kommuner, bliver det hurtigt tydeligt, at AI-initiativer og lovkrav ikke kan være “sideløbende”. De deler de samme data, de samme leverandører og de samme driftsmiljøer. Jo tidligere I samler styringen, jo færre akutte stopklodser får I senere.

Mini-konklusion: Samlet styring handler om at undgå, at AI bliver en genvej uden sikkerhedssele — og at compliance bliver papir uden driftseffekt.

Hvad koster det — og hvad sparer man typisk?

Et naturligt spørgsmål er: Hvad koster det at etablere et samlet styringsområde? Svaret afhænger af modenhed. Hvis I allerede har noget informationssikkerhed og GDPR-arbejde, handler det ofte mere om samling og prioritering end om store nyanskaffelser.

Jeg plejer at skelne mellem tre omkostningskategorier:

• Organisering og tid: mødestruktur, gates, risikovurderinger og fælles skabeloner (typisk 0,2–1,0 årsværk fordelt på flere nøglepersoner i opstart).
• Kompetenceløft: træning i sikker adfærd, AI-brug og databehandling (ofte billigere end man tror, hvis det standardiseres).
• Tekniske kontroller: logning, MFA, segmentering, backup, enhedsstyring, sårbarhedsscanning (her varierer det mest).

Gevinsten kommer typisk i form af færre parallelle assessments, kortere indkøbs- og godkendelsesforløb og færre “brandøvelser”. Mange kommuner kan reelt hente en mærkbar effektivisering ved at genbruge leverandørkrav og kontroller på tværs — især hvis de i dag kører flere spørgeskemaer, flere godkendelsesfora og flere dokumentpakker for samme løsning.

Mini-konklusion: Omkostningen ligger ofte i koordinering og disciplin — besparelsen ligger i genbrug, færre fejl og hurtigere beslutninger.

De mest almindelige faldgruber (og hvordan I undgår dem)

Selv med gode intentioner kan samlet styring ende i enten bureaukrati eller “alt er tilladt”. Her er de fejl, jeg oftest møder — og hvad der virker i praksis.

Faldgrube 1: AI-piloter uden drifts- og sikkerhedslandingsbane

En pilot, der virker i et lukket testmiljø, kan fejle i drift, hvis den kræver adgang til mails, dokumenter eller fagsystemer uden klare rettigheder og logning. Løsning: lav to gates — én før pilot (datagrundlag, formål, lovlighed) og én før produktion (drift, sikkerhed, leverandørkrav, monitorering).

Faldgrube 2: Compliance bliver en dokumentfabrik

Hvis fokus er på at “have papirerne i orden” fremfor at have reelle kontroller, får I falsk tryghed. Løsning: bind dokumentation til konkrete kontroller, og mål på implementering (fx MFA-dækning, patching-SLA, backup-test, logreview).

Faldgrube 3: Uklare dataejere og rettigheder

Når ingen ejer data, er der heller ingen, der kan godkende brugen i AI eller definere slette- og adgangskrav. Løsning: udpeg dataejere pr. domæne (social, børn/unge, teknik, HR), og gør det til en del af governance at godkende databrug.

Mini-konklusion: De fleste fejl skyldes uklare gates, uklare ejerskaber og mangel på målbare kontroller — ikke manglende vilje.

Bedste praksis: en 90-dages plan der samler trådene

Hvis du skal i gang uden at starte et “mega-program”, så brug 90 dage på at skabe den fælles ramme og få de første synlige resultater. Det vigtigste er at vælge få, høj-effekt tiltag.

Dag 1–30: Skab fælles overblik og minimumskrav

• Lav en fælles definition af dataklasser og de minimumskontroller, hver klasse kræver.
• Enig om en standard risikomodel og en enkel skabelon til AI-/systemvurdering.
• Beslut en midlertidig “AI-brugsregel” for medarbejdere: hvad må deles, hvad må ikke, og hvordan man håndterer følsomme data.

Dag 31–60: Byg gates og leverandørkrav

• Indfør en fast vurderingsgate for nye AI-cases og nye leverandører (30–60 min møde, fast agenda).
• Standardisér leverandørkrav: sikkerhed, databehandling, underleverandører, dataplacering, logning, sletning.
• Udpeg dataejere og gør dem til del af godkendelsesflowet.

Dag 61–90: Mål, justér og skaler

• Vælg 5–8 KPI’er, der kan måles kvartalsvist (fx MFA, backup-test, patching, leverandørstatus, antal AI-cases med risikovurdering).
• Kør to konkrete AI-cases igennem den nye proces og dokumentér læring.
• Lav en “kontrolkalender” for de vigtigste kontroller, så det ikke bliver ad hoc.

Mini-konklusion: En kort, fokuseret plan skaber fælles sprog og fælles krav hurtigt — og det er ofte nok til at bryde siloerne.

Hvad skal ledelsen spørge om for at sikre effekt?

Samlet styring lykkes, når ledelsen efterspørger de rigtige svar. Her er spørgsmål, der typisk flytter noget i kommunal kontekst:

1. Hvilke 10 risici kan påvirke borgernes service og vores drift mest — og hvad gør vi ved dem i år?
2. Hvilke data bruges i vores AI-løsninger, og hvem har godkendt formål og adgang?
3. Hvilke leverandører udgør størst risiko, og har vi ensartede krav og opfølgning?
4. Hvordan måler vi sikkerhed og compliance med få, men meningsfulde KPI’er?
5. Hvad er vores standard for at gå fra pilot til drift — og hvem kan sige stop?

Mini-konklusion: Når ledelsen spørger på tværs af AI, sikkerhed og lovkrav, tvinger det organisationen til at levere ét samlet svar — og dermed én samlet retning.