Datasikkerhed: Fra regler til daglig praksis

AI skaber først holdbar værdi, når virksomheden kan styre, hvilke data den bruger, hvem der får adgang, og hvilke handlinger systemet må udføre. Sikkerhed skal derfor indgå i eksperimentet, i MVP’en og i beslutningen om skalering.

Artiklen er et overblik for danske virksomheder med udgangspunkt i EU-regler og dansk myndighedsvejledning. Regelstatus er kontrolleret den 10. september 2026. Den konkrete anvendelse afhænger af virksomhedens rolle, sektor, data og AI-løsning.

1 Beskyt både mennesker og forretning

Datasikkerhed handler om fortrolighed, rigtighed og tilgængelighed. En kundeliste må ikke lækkes, en betalingsoplysning må ikke ændres ubemærket, og ordresystemet skal kunne gendannes. Persondatabeskyttelse omfatter derudover, om oplysninger overhovedet må bruges til det valgte formål. En teknisk sikker løsning kan stadig behandle data ulovligt. [1, 2]

Skeln mellem personoplysninger, forretningshemmeligheder og offentligt materiale. En navngiven kontaktperson hos en erhvervskunde er også en personoplysning. Prisstrategi og kildekode kan være kritiske, selv om de ikke vedrører personer. Offentligt tilgængeligt indhold er heller ikke automatisk frit til enhver behandling eller genbrug.

GDPR: Formål og nødvendighed kommer først

GDPR gælder også små virksomheder, når de behandler personoplysninger. Beskriv formålet, vælg et gyldigt behandlingsgrundlag og begræns data til det nødvendige. Samtykke er én mulighed; eksempelvis kontrakt, retlig pligt eller en dokumenteret interesseafvejning kan være relevante i andre situationer. Følsomme oplysninger kræver desuden en relevant undtagelse fra forbuddet i artikel 9. [1, 2, 3]

At oplysninger allerede ligger i CRM, giver ikke i sig selv ret til at bruge dem til modeltræning eller nye medarbejdervurderinger. Undersøg den nye behandling, oplys de berørte og sørg for rigtighed, sletning og håndtering af deres rettigheder. I RAG skal rettelser og sletninger også nå relevante tekstuddrag, søgeindeks og cache. Det sidste er en praktisk konsekvens af reglerne om rigtighed og opbevaring. [2]

Vurder risikoen før data tages i brug

En konsekvensanalyse, DPIA, skal foretages før en behandling, der sandsynligvis indebærer høj risiko for personers rettigheder. AI udløser ikke automatisk kravet; anvendelsen og risiciene er afgørende. Datatilsynet har en særlig AI-skabelon. Hvis høj risiko består efter beskyttelsestiltag, skal tilsynet høres før behandlingen. [4, 5]

Ved afgørelser, der alene træffes automatisk og har retsvirkning eller tilsvarende væsentlig betydning, skal GDPR artikel 22 vurderes særskilt. Undtagelser kræver relevante betingelser og garantier. Menneskelig kontrol skal være reel og kunne ændre afgørelsen. [19]

2 Reglerne rammer forskellige virksomheder

Begynd med en kort vurdering af, hvilke regelsæt I er omfattet af. Et leverandørkrav i en kontrakt kan være bindende for jer, selv om den bagvedliggende sektorlov ikke gælder direkte. Tabellen viser de vigtigste forskelle.

Regelsæt: GDPR + dansk lov

Hvornår er det relevant?: Behandling af personoplysninger.

Praktisk betydning: Lovligt formål, rettigheder, risikovurdering og passende sikkerhed. [1, 2, 4]

Regelsæt: NIS 2

Hvornår er det relevant?: Omfattede sektorer og enheder; størrelse og særlige undtagelser afgør omfanget.

Praktisk betydning: Ledelsesansvar, risikostyring, forsyningskæde, beredskab og hændelsesrapportering. [6]

Regelsæt: AI-forordningen

Hvornår er det relevant?: Afhænger af rolle og anvendelse: fx udbyder eller anvender af AI.

Praktisk betydning: Klassificér brugen; afklar forbud, transparens og eventuelle højrisikokrav. [7, 8]

Regelsæt: DORA / CRA

Hvornår er det relevant?: DORA: omfattede finansielle enheder. CRA: omfattede produkter med digitale elementer.

Praktisk betydning: DORA styrer digital robusthed og IT-leverandører; CRA omfatter bl.a. producenters produktsikkerhed. [9, 10]

NIS 2 er ikke et generelt krav til alle virksomheder

Den danske NIS 2-lov gælder fra 1. juli 2025. Afgrænsningen kræver kontrol af aktivitet, sektor, størrelse og eventuelle særregler. For omfattede enheder skal ledelsen godkende sikkerhedsforanstaltninger, føre tilsyn og deltage i relevant uddannelse. Underleverandører kan møde dokumentationskrav gennem kundernes forsyningskædestyring. [6]

AI-regler: Brug den opdaterede tidsplan

AI Omnibus trådte i kraft den 27. juli 2026. Højrisikoregler for anvendelser i bilag III får anvendelse fra 2. december 2027; for omfattede regulerede produkter i bilag I fra 2. august 2028. Transparenskrav gælder fra 2. august 2026, bl.a. oplysning om interaktion med AI, med relevante undtagelser. Rekruttering eller kreditvurdering kan være højrisikobrug; en intern dokumentassistent er ikke automatisk det. En udskudt AI-frist fritager ikke virksomheden for GDPR eller sikkerhedsarbejde. [7, 8]

DORA gælder allerede for omfattede finansielle enheder. CRA’s rapporteringspligt for producenter om aktivt udnyttede sårbarheder og alvorlige produktsikkerhedshændelser starter den 11. september 2026. Det er særskilte ordninger; en almindelig køber af et AI-abonnement bliver ikke alene af den grund producent efter CRA. [9, 10]

3 Gør sikkerhed til en del af arbejdsgangen

Start med en navngiven ejer for hver vigtig proces, datakilde og integration. Registrér, hvor data kommer fra, hvor de sendes hen, hvem der bruger dem, og hvornår de skal slettes. Vurder både sandsynlighed og konsekvens. For personoplysninger skal konsekvensen for de berørte personer vurderes, ikke kun virksomhedens tab. [11]

Et praktisk minimum

• Adgang: Brug individuelle konti, multifaktorlogin og mindst mulige rettigheder. Luk adgang ved jobskifte og fratrædelse. Gennemgå også servicekonti og eksterne leverandører.

• Drift: Opdatér systemer, beskyt enheder og hemmelige nøgler, og adskil test fra produktion. Kryptering skal omfatte relevante overførsler og lagring; den hjælper ikke mod en bruger med for brede rettigheder.

• Gendannelse: Hav beskyttede sikkerhedskopier og afprøv en reel gendannelse. Beslut, hvor længe processen må være nede, og hvor meget data virksomheden kan tåle at miste.

• Opfølgning: Overvåg usædvanlig adgang og fejl, og aftal hvem der reagerer. Træn medarbejdere i konkrete situationer som phishing og forkert deling. NIST’s SMV-guide giver en praktisk ramme. [12]

Cloud og AI-leverandører skal kunne dokumentere aftalen

Afklar dataansvar og databehandlerrolle, og indgå databehandleraftale, når leverandøren behandler på jeres vegne. Gennemgå underleverandører, formål, opbevaring, sletning, sikkerhed og hændelsesvarsling. Kontroller præcis produktudgave og aftale: vilkår for en privat chatkonto kan ikke overføres til virksomhedens abonnement eller API. Leverandørens egne formål kræver særskilt vurdering. [13]

Lagring i EU er ikke alene tilstrækkeligt. Undersøg også supportadgang og overførsler til lande uden for EU/EØS. Afklar relevant overførselsgrundlag og eventuelle supplerende foranstaltninger. Datatilsynets praksis kræver aktiv stillingtagen til uklare overførselsklausuler; en bred kontraktformulering bør ikke stå uafklaret. [13, 14]

Standarder er hjælp til styring

ISO/IEC 27001 beskriver et ledelsessystem for informationssikkerhed. NIST CSF 2.0 organiserer arbejdet i styring, overblik, beskyttelse, opdagelse, respons og gendannelse. De er nyttige arbejdsrammer, men er ikke i sig selv dansk lov. Et certifikat dokumenterer heller ikke automatisk lovligheden af en konkret AI-anvendelse. [12, 15]

Vedtag en enkel datapolitik: hvilke oplysninger må bruges i hvilke godkendte AI-værktøjer, og hvem afklarer tvivl? Følg op på faktisk efterlevelse. En politik uden ejerskab, hjælp og kontrol ændrer sjældent medarbejdernes daglige valg.

4 AI kræver kontrol med både viden og handlinger

RAG gør viden lettere tilgængelig og kan dermed forstærke gamle adgangsfejl. En mappe, som mange teknisk kan åbne, kan blive langt lettere at udforske gennem spørgsmål. Afklar derfor adgang før indlæsning, og kontrollér brugerens rettigheder, før uddrag sendes til modellen. Test også adgang på tværs af kunder, afdelinger og sprog.

Embeddings, altså numeriske repræsentationer af tekst, er ikke automatisk anonyme. Vurder, om de sammen med tilgængelig kontekst kan henføres til personer. Brug samme disciplin for feedback og træningsdata som for de oprindelige kilder; genbrug til forbedring er en behandling, der skal vurderes. [2, 20]

Et dokument eller værktøjssvar kan indeholde instruktioner, der forsøger at overtage agentens opgave. Denne prompt injection skal håndteres i flere lag: adskil data og instruktioner, begræns værktøjer, kontrollér output og kræv godkendelse ved kritiske handlinger. En instruks om at ignorere ondsindet tekst er ikke tilstrækkelig beskyttelse. [16]

Lad backend kontrollere modtager, beløb og adgang, før agenten kan sende oplysninger eller ændre et system. Hold legitimationsoplysninger ude af prompts. Log handlinger og beslutningsgrundlag med passende adgang og opbevaring; rå samtalelogning kan selv skabe et nyt lager af følsomme oplysninger. Et menneskes godkendelse skal vise den faktiske handling og konsekvens.

Et konkret eksempel

En kundeserviceagent læser ordrer og foreslår svar. Første version må kun se brugerens kundesager. Den kan klargøre en kreditnota, men økonomisystemet kontrollerer beløbsgrænse og kundetilhørsforhold, og en medarbejder godkender bogføringen. Test med en forkert kunde, tilbagekaldt adgang og et manipuleret dokument. Det er EnableAI’s forslag til en afgrænset MVP.

Når en hændelse opstår

Stop eller begræns skaden, bevar relevante spor og aktivér en ansvarlig med en stedfortræder. Registrér tidspunktet, hvor I fik kendskab til hændelsen. Undersøg derefter de relevante rapporteringspligter hver for sig; flere kan gælde samtidig.

• GDPR: Anmeld et persondatasikkerhedsbrud uden unødig forsinkelse og om muligt inden 72 timer fra kendskab, medmindre risiko for personers rettigheder er usandsynlig. Ved sandsynlig høj risiko skal de berørte som udgangspunkt underrettes uden unødig forsinkelse. Dokumentér også brud, der ikke anmeldes. [17, 18]

• NIS 2: For omfattede enheders væsentlige hændelser gælder som hovedregel tidlig varsling inden 24 timer, hændelsesunderretning inden 72 timer og endelig rapport senest en måned efter hændelsesunderretningen. Der findes særregler, bl.a. for tillidstjenester og igangværende hændelser. [6]

En databehandler skal varsle den dataansvarlige uden unødig forsinkelse; den bør ikke vente på at bruge en påstået egen 72-timersfrist. Øv beredskabet, også uden for kontortid. [18]

5 Byg sikkerheden gennem de tre stadier

Eksperiment: Vælg en afgrænset opgave, få data og helst syntetiske eller reelt anonymiserede testdata. Fastlæg forbudte handlinger og ejer. Pseudonymiserede data er fortsat personoplysninger, hvis de kan henføres til personer. [20]

MVP: Dokumentér formål, relevante regler og leverandørvilkår. Test adgang, sletning, kritiske handlinger og beredskab. Mål både nytte, fejl og tiden til menneskelig kontrol. Ved sandsynlig høj risiko skal DPIA være gennemført før behandlingen.

Skalering: Gør kontroller gentagelige, følg ændringer og afprøv gendannelse. Budgettér med kendt arbejde samt usikkerhed om datakvalitet, integration og krav. Fælles adgangsstyring og bedre data har også indirekte værdi for næste initiativ. Det er EnableAI’s anbefalede udviklingsforløb.

Kundeeksempel med mål og opfølgning

I beredskabseksemplet antages sandsynligheden for én alvorlig årlig driftsafbrydelse at falde fra 10 % til 3 %, med en konsekvens på 2 mio. kr. Den forventede årlige risikoreduktion bliver 140.000 kr. før omkostninger.

Antagelserne skal begrundes, og gendannelse skal testes. Et år uden hændelser beviser ikke en kontant besparelse på 140.000 kr. Følg teknisk beredskab, faktisk gendannelsestid og reviderede risikoscenarier. En eventuel lavere forsikringspræmie er en separat direkte gevinst.

Brug den samlede VP/SE-model, VP-vejledningen og SE-vejledningen. Begge estimater revurderes før Hypotese, MVP og Skalering. VP/SE er et lokalt præferenceindeks, ikke økonomisk ROI eller WSJF. Lær anvendelsen på halvdag 1 om VP og halvdag 2 om SE og prioritering, hver fire timer inklusive pause.

Kilder og videre læsning

[1] Datatilsynet · GDPR for små virksomheder

[2] Datatilsynet · Grundlæggende principper

[3] Datatilsynet · Behandlingsgrundlag

[4] Datatilsynet · Konsekvensanalyse

[5] Datatilsynet · Skabeloner, herunder AI

[6] NIS 2-loven · §§ 1–7 og 12–13

[7] EU-Kommissionen · AI-forordningens anvendelse

[8] EU-Kommissionen · AI Omnibus trådt i kraft

[9] Finanstilsynet · DORA

[10] EU-Kommissionen · CRA-rapportering

[11] Datatilsynet · Risikovurdering

[12] NIST · CSF 2.0, SMV-guide

[13] Datatilsynet · Cloud og leverandørkæden

[14] Datatilsynet · Overførselsklausuler i aftaler

[15] ISO · ISO/IEC 27001

[16] OWASP · Forebyggelse af prompt injection

[17] Datatilsynet · Anmeld sikkerhedsbrud

[18] Datatilsynet · Håndtering af persondatasikkerhedsbrud

[19] Datatilsynet / Artikel 29-gruppen · Automatiske afgørelser

[20] Datatilsynet · Personoplysninger og anonymisering