AI og persondata: syv tommelfingerregler til dansk praksis

Spørgsmålet »må vi bruge AI til det her?« kan sjældent besvares ud fra værktøjets navn. Svaret afhænger af formålet, oplysningerne, leverandørkæden og den måde, resultatet skal bruges på. Et AI-værktøj til at rette en generel overskrift er én behandling. Det samme værktøj med en komplet personalesag i prompten er en helt anden.

Denne guide er praktisk beslutningsstøtte, ikke en juridisk vurdering af en konkret behandling. Den kan hjælpe med at stille de rigtige spørgsmål tidligt. Når brugen omfatter mange registrerede, særlige kategorier af personoplysninger, systematisk overvågning eller beslutninger med væsentlige følger, bør den dataansvarlige inddrage sin databeskyttelsesrådgiver eller anden relevant juridisk funktion.

Begynd med to forskellige kasser

Personoplysninger er information, der kan knyttes til en identificeret eller identificerbar fysisk person. Navn og CPR-nummer er oplagte eksempler, men en jobtitel, en sjælden hændelse eller en kombination af dato, afdeling og citat kan også gøre en person genkendelig. Fortrolige forretningsoplysninger er noget andet: en endnu ikke offentlig pris, en produktplan eller en kundestrategi er ikke nødvendigvis persondata, men kan stadig være omfattet af tavshedspligt, kontrakt eller sikkerhedspolitik.

De to kasser kan overlappe. En kundeliste kan både være forretningskritisk og indeholde personoplysninger. Derfor er »der står ingen CPR-numre« ikke en tilstrækkelig kontrol, og »det er kun internt« er heller ikke et behandlingsgrundlag. Lav både en databeskyttelsesvurdering og en fortrolighedsvurdering.

1. Tegn datarejsen, før I godkender brugen

Skriv behandlingen som en kæde, der kan læses uden leverandørens salgsmateriale: Hvem indtaster hvad? Hvilke filer vedhæftes? Hvor behandles prompt, output og brugslog? Gemmes samtaler, og i så fald hvor længe? Kan supportmedarbejdere få adgang? Bruges data til træning eller produktevaluering? Hvilke underdatabehandlere indgår? Kan organisationen slette data og dokumentere, at det er sket?

Kortlæg også returrejsen. Et output kan gentage personoplysninger, skabe en ny vurdering af en person eller blive kopieret til sags-, mail- og dokumentationssystemer. Hvis kortet stopper ved »send«, mangler halvdelen af behandlingen.

• Input: prompt, bilag, lyd, billeder, metadata og brugeridentitet.
• Behandling: model, søgefunktion, logning, support og eventuel menneskelig gennemgang.
• Output: tekst, vurderinger, kilder og nye oplysninger, som medarbejderen tilføjer.
• Efterliv: historik, eksport, backup, sletning og kopier i andre systemer.

2. Skriv formål og behandlingsgrundlag hver for sig

Formålet skal være konkret nok til at styre resten. »Effektivisering« er for bredt. »At udarbejde et første udkast til svar på generelle produktspørgsmål, som en medarbejder efterkontrollerer« gør det muligt at vurdere, hvilke data der faktisk er nødvendige.

Når personoplysninger behandles, skal den dataansvarlige også kunne pege på et gyldigt behandlingsgrundlag. Grundlaget følger ikke automatisk med en licens eller en databehandleraftale. En databehandleraftale regulerer leverandørens behandling på organisationens vegne; den skaber ikke i sig selv lovlighed for organisationens eget formål. Hvis behandlingen omfatter særlige kategorier som helbredsoplysninger, politisk overbevisning, religion, fagforeningsforhold, biometriske oplysninger med identifikationsformål eller oplysninger om seksuelle forhold, kræves en særskilt vurdering efter de skærpede regler. Oplysninger om strafbare forhold har også egne krav.

Spørg til sidst, om en ny AI-anvendelse er forenelig med det formål, oplysningerne oprindeligt blev indsamlet til. »Vi har allerede data« er ikke det samme som »vi må bruge dem til dette nye formål«.

3. Minimer før prompten – ikke bagefter

Dataminimering betyder, at behandlingen skal begrænses til det, der er nødvendigt for det konkrete formål. Den stærkeste kontrol er derfor ofte at undlade at sende oplysningerne. Hvis opgaven kan løses med en skabelon, et kort uddrag eller syntetiske eksempeldata, er den fulde sag ikke nødvendig.

Et konkret før/efter-forløb

Tænkt eksempel: En medarbejder vil have hjælp til at gøre et svarbrev lettere at forstå. Det oprindelige udkast nævner »Anna Madsen«, en præcis adresse, et sagsnummer, en sjælden diagnose, datoen for en hændelse og navnet på en lille arbejdsplads. Målet er sproglig redigering, ikke en vurdering af personen.

1. Lav en lokal arbejdskopi og markér alle direkte identifikatorer: navn, adresse, telefon, mail og sagsnummer.
2. Markér indirekte identifikatorer: sjælden diagnose, præcis dato, arbejdssted, familiestilling og andre detaljer, der sammen kan udpege personen.
3. Fjern hele sætninger, som ikke er nødvendige for sprogarbejdet. Erstat resten med brede roller og intervaller, for eksempel »[borger]«, »[måned]« og »[arbejdsplads]«.
4. Læs den rensede tekst som en udenforstående. Kan en kollega, nabo eller leverandør stadig genkende personen ud fra kombinationen? Hvis ja, generalisér yderligere eller vælg en lokal, godkendt arbejdsgang uden ekstern behandling.
5. Send kun den rensede tekst til det godkendte værktøj. Kontrollér output for nye antagelser og skjulte personhenvisninger.
6. Flet den redigerede formulering tilbage i originalsystemet. Indsæt identifikatorer lokalt, og gem ikke koblingsnøglen sammen med den tekst, der blev sendt.

Hvis organisationen beholder en nøgle, der kan koble »[borger A]« tilbage til Anna, er materialet som udgangspunkt pseudonymiseret, ikke anonymiseret. Pseudonymisering kan mindske risikoen, men oplysningerne er fortsat personoplysninger i den relevante behandlingskontekst. Reel anonymisering kræver, at ingen med rimeligt tilgængelige midler kan identificere personen, heller ikke ved at kombinere materialet med andre oplysninger. Det er en konkret og ofte vanskelig vurdering.

4. Undersøg leverandørkæden, ikke kun forsiden

En erhvervslicens kan give nyttige kontraktvilkår, men prisen eller produktnavnet dokumenterer ikke efterlevelse. Afklar først rollerne: Er leverandøren databehandler på organisationens dokumenterede instruks, selvstændigt dataansvarlig for dele af behandlingen eller noget forskelligt afhængigt af funktionen? Rollen følger de faktiske beslutninger om formål og hjælpemidler, ikke alene den etiket, kontrakten bruger.

Hvis leverandøren er databehandler, skal den relevante databehandleraftale blandt andet beskrive genstand, varighed, formål, datatyper, registrerede grupper, sikkerhed, bistand, sletning og kontrol. Gennemgå også underdatabehandlerne. Hvem driver model, hosting, logning, support og sikkerhed? Hvordan varsles ændringer, og kan organisationen gøre indsigelse? Den dataansvarlige skal kunne føre et risikobaseret tilsyn; en liste, der ændrer sig uden reel inddragelse, bør ikke stå uimodsagt.

Kontrollér desuden, hvorfra data kan tilgås. Behandling eller adgang uden for EU/EØS kan udløse reglerne om tredjelandsoverførsler. Spørg efter det konkrete overførselsgrundlag, de relevante lande, eventuelle supplerende foranstaltninger og den faktiske instruks. »Servere i Europa« besvarer ikke nødvendigvis spørgsmålet om supportadgang eller underleverandører.

5. Fastlæg opbevaring og en efterprøvbar sletning

Vælg slettefrist ud fra formålet, ikke ud fra leverandørens standard. Der kan være forskellige frister for samtalehistorik, sikkerhedslog, eksport, feedbackdata og backup. Beskriv, hvem der kan ændre indstillingerne, hvordan en bruger sletter en samtale, hvad der sker ved kontolukning, og hvordan organisationen kontrollerer, at sletteproceduren virker.

»Data bruges ikke til træning« betyder ikke nødvendigvis »data gemmes ikke«. Omvendt er kort opbevaring ikke tilstrækkelig, hvis formål eller behandlingsgrundlag mangler. Træning, logning, support og sikkerhed er forskellige behandlingsaktiviteter, som skal beskrives hver for sig.

6. Lav en DPIA-risikoscreening tidligt

En konsekvensanalyse vedrørende databeskyttelse, ofte kaldet DPIA, er påkrævet, når en planlagt behandling sandsynligvis indebærer høj risiko for fysiske personers rettigheder og frihedsrettigheder. En kort screening bør derfor ske, før pilotdata kopieres ind. Se blandt andet på omfang, systematik, sårbare personer, nye teknologier, sammenstilling af datasæt, følsomhed, overvågning, manglende valgmulighed og konsekvenserne af et forkert output.

En DPIA er ikke blot en leverandørrapport. Den skal beskrive organisationens egen behandling, nødvendighed og proportionalitet, risici for de registrerede og de foranstaltninger, der faktisk reducerer dem. Hvis screeningen peger på sandsynlig høj risiko, skal analysen udføres før behandlingen. Viser analysen, at der fortsat vil være høj risiko efter de planlagte risikobegrænsende foranstaltninger, skal den dataansvarlige høre Datatilsynet, før behandlingen begynder. Pligten gælder, når netop denne betingelse er opfyldt – ikke ved enhver AI-anvendelse eller enhver DPIA.

Hold to betydninger af »høj risiko« adskilt. GDPR-spørgsmålet handler om risikoen ved behandling af personoplysninger. AI-forordningen klassificerer bestemte AI-systemer og anvendelser efter andre kriterier. En almindelig skriveassistent er ikke automatisk et højrisikosystem efter AI-forordningen, men dens behandling af persondata skal stadig være lovlig. Omvendt gør en AI-retlig klassifikation ikke GDPR-vurderingen overflødig. Siden 27. juli 2026 har AI-forordningens artikel 4 krævet, at udbydere og idriftsættere træffer foranstaltninger til at støtte udviklingen af AI-færdigheder hos personale og andre, der driver eller anvender systemerne på deres vegne. Foranstaltningerne skal tage hensyn til deres viden, erfaring og uddannelse, anvendelseskonteksten og de personer, systemerne anvendes på. Organisationen skal ikke garantere et bestemt niveau af AI-færdigheder hos den enkelte.

7. Placer menneskelig kontrol dér, hvor fejlen får virkning

Et menneske i arbejdsgangen er kun en reel kontrol, hvis personen har tid, information, kompetence og mandat til at ændre eller afvise outputtet. Definér derfor, hvad kontrolløren skal sammenholde med: originaldokumentet, en autoritativ kilde, et fagligt kriterium eller en anden registrering. Artiklen om hallucinationer og bias giver en konkret metode til at kontrollere påstande og skævheder.

Dokumentér også, hvem der ejer hændelser. Hvis en medarbejder indsætter data i et ikke-godkendt værktøj, skal vedkommende vide, hvem der kontaktes, og oplysningerne skal kunne sikres hurtigt. En kort, øvet vej er bedre end en lang politik, ingen kan finde.

En enkel beslutning før hver ny brug

• Fortsæt til afgrænset pilot: Formål, datakategorier, grundlag, leverandørkæde, opbevaring og menneskelig kontrol er dokumenteret, og kun nødvendige data indgår.
• Pause og afklar: Der er persondata, men roller, underdatabehandlere, overførsler, sletning eller risikoniveau er uklare.
• Stop den konkrete arbejdsgang: Opgaven kræver flere data end formålet kan begrunde, særlige kategorier indsættes uden særskilt vurdering, eller output får virkning for en person uden reel faglig kontrol.

Den praktiske gevinst ligger ikke i at kalde alt anonymt eller sikkert. Den ligger i at gøre datavejen synlig, fjerne det unødvendige og give nogen et tydeligt ansvar. Hvis I vil træne vurderingen på konkrete arbejdsgange, kan et oplæg om hvad man kan stole på i AI skabe et fælles sprog, og ved en konkret forespørgsel kan I tage kontakt her.

Konklusion: God persondatapraksis begynder før prompten. Beskriv formålet, tegn datarejsen, minimer materialet, kontrollér hele leverandørkæden og stop, hvis risikoen ikke kan forklares og håndteres. Det gør ikke enhver AI-anvendelse lovlig, men det gør den konkrete vurdering mulig.

Kilder og videre læsning

• EUR-Lex: Databeskyttelsesforordningen, især artikel 5, 6, 9, 28, 35, 36 og kapitel V.
• Datatilsynet: Pseudonymisering og anonymisering.
• Datatilsynet: Rollefordeling mellem dataansvarlig og databehandler.
• Datatilsynet: Konsekvensanalyse og AI-skabelon.
• Datatilsynet: Databehandleraftaler, underdatabehandlere og tredjelandsoverførsler.
• EUR-Lex: Forordning (EU) 2026/1744, der ændrer AI-forordningens artikel 4 om AI-færdigheder.
• EU-Kommissionen: Spørgsmål og svar om AI-færdigheder efter AI-forordningen.