AI og persondata – syv spørgsmål før du deler oplysninger

Det mest almindelige persondataspørgsmål om AI er også det sværeste at svare på med ét ord: “Må vi lægge det her ind i ChatGPT?” Det afhænger både af oplysningerne, formålet, jeres aftale med leverandøren, systemets indstillinger og de regler, der gælder i organisationen.

Guiden her er beslutningsstøtte, ikke en juridisk vurdering af en konkret behandling. Omfatter brugen mange registrerede, særlige kategorier af personoplysninger, systematisk overvågning eller beslutninger med væsentlige følger, skal den dataansvarlige inddrage sin databeskyttelsesrådgiver eller anden relevant juridisk funktion.

Hold desuden to ting adskilt fra start. Personoplysninger er information, der kan knyttes til en identificeret eller identificerbar person – ikke kun navn og CPR-nummer, men også en jobtitel, en sjælden hændelse eller en kombination af dato, afdeling og citat. Fortrolige forretningsoplysninger er noget andet: en pris, en produktplan eller en kundestrategi er ikke nødvendigvis persondata, men kan være omfattet af tavshedspligt, kontrakt eller sikkerhedspolitik. De to kasser overlapper ofte, og “der står ingen CPR-numre” er derfor ikke en tilstrækkelig kontrol.

1. Ved du, hvad materialet indeholder?

Stop før upload, hvis du ikke ved, hvad materialet indeholder. En tekst kan rumme navn, helbredsoplysninger, CPR-numre, økonomi, interne sagsnumre eller oplysninger om andre mennesker, selv om opgaven egentlig bare var “lav et resumé”.

Tegn hele datarejsen, mens du er i gang. Hvem indtaster hvad? Hvilke filer vedhæftes? Hvor behandles prompt, output og log? Gemmes samtaler, og i så fald hvor længe? Kan supportmedarbejdere få adgang? Bruges data til træning eller produktevaluering? Kan organisationen slette og dokumentere, at det er sket? Husk også returrejsen: et output kan gentage personoplysninger, skabe en ny vurdering af en person eller blive kopieret videre til sags-, mail- og dokumentationssystemer. Stopper kortet ved “send”, mangler halvdelen af behandlingen.

2. Er værktøjet godkendt til den type data?

Brug kun et værktøj, som organisationen faktisk har godkendt til den type data. En privat gratis konto og en virksomhedsopsætning med databehandleraftale, styring og relevante indstillinger er ikke det samme.

En erhvervslicens giver nyttige kontraktvilkår, men prisen eller produktnavnet dokumenterer ikke efterlevelse. Afklar rollerne: Er leverandøren databehandler på jeres 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 den etiket kontrakten bruger.

3. Kan opgaven løses med færre oplysninger?

Minimer data. Hvis opgaven kan løses uden navn, adresse eller andre identificerende oplysninger, så fjern dem. Anonymisering er dog mere end at erstatte et navn med “Person A”; kombinationen af detaljer kan stadig gøre en person genkendelig.

Konkret: lav en lokal arbejdskopi, og markér først de direkte identifikatorer – navn, adresse, telefon, mail, sagsnummer. Markér derefter de indirekte: en sjælden diagnose, en præcis dato, et lille arbejdssted, en familiestilling. Fjern hele sætninger, der ikke er nødvendige for opgaven, og erstat resten med brede roller og intervaller. Læs så teksten som en udenforstående: kan en kollega, nabo eller leverandør stadig genkende personen ud fra kombinationen? Kan de det, skal der generaliseres mere – eller vælges en lokal arbejdsgang uden ekstern behandling.

Beholder organisationen en nøgle, der kan koble “[borger A]” tilbage til et rigtigt menneske, er materialet pseudonymiseret – ikke anonymiseret. Pseudonymisering kan mindske risikoen, men oplysningerne er fortsat personoplysninger. 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. Hvad er formålet, og hvad er behandlingsgrundlaget?

Persondata må ikke bare bruges, fordi teknologien kan. Behandlingsgrundlag, formål og nødvendighed skal passe sammen, og organisationens databeskyttelsesansvarlige bør inddrages, når der er tvivl.

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. Grundlaget følger heller ikke automatisk med en licens: en databehandleraftale regulerer leverandørens behandling på jeres vegne, men skaber ikke i sig selv lovlighed for jeres eget formål.

Omfatter behandlingen særlige kategorier som helbredsoplysninger, politisk overbevisning, religion, fagforeningsforhold, biometri til identifikation eller oplysninger om seksuelle forhold, kræves en særskilt vurdering efter de skærpede regler. Oplysninger om strafbare forhold har også deres egne krav. Og spørg til sidst, om den nye anvendelse overhovedet 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”.

5. Hvor behandles data, og hvem har adgang?

Tjek hvor data behandles, hvor længe de opbevares, og hvem der kan få adgang. Gennemgå underdatabehandlerne: Hvem driver model, hosting, logning, support og sikkerhed? Hvordan varsles ændringer, og kan I gøre indsigelse? Den dataansvarlige skal kunne føre et risikobaseret tilsyn, og en liste, der ændrer sig uden reel inddragelse, bør ikke stå uimodsagt.

Kontrollér også, hvorfra data kan tilgås. Behandling eller adgang uden for EU og EØS kan udløse reglerne om tredjelandsoverførsler, og “servere i Europa” besvarer ikke nødvendigvis spørgsmålet om supportadgang eller underleverandører.

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, og nogen skal kunne beskrive, hvem der ændrer indstillingerne, og hvordan sletningen kontrolleres. “Data bruges ikke til træning” betyder i øvrigt ikke nødvendigvis “data gemmes ikke”. Træning, logning, support og sikkerhed er forskellige behandlingsaktiviteter.

6. Er der følsomme oplysninger eller vurderinger af mennesker?

Vær særligt forsigtig med følsomme oplysninger og med beslutninger om mennesker. 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.

Lav derfor en kort screening, før pilotdata overhovedet kopieres ind: omfang, systematik, sårbare personer, ny teknologi, sammenstilling af datasæt, følsomhed, overvågning, manglende valgmulighed og konsekvenserne af et forkert output. Peger screeningen på sandsynlig høj risiko, skal analysen laves før behandlingen. Viser den, at risikoen fortsat vil være høj efter de planlagte foranstaltninger, skal Datatilsynet høres, før behandlingen begynder. Pligten gælder, når netop den betingelse er opfyldt – ikke ved enhver AI-anvendelse.

Hold også 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 – og omvendt gør en AI-retlig klassifikation ikke GDPR-vurderingen overflødig.

7. Kan medarbejderne bruge rammerne i praksis?

Dokumentér de rammer, medarbejderne faktisk skal følge, så ansvaret ikke ligger hos den enkelte i et chatvindue. Og placer den menneskelige 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 eller et fagligt kriterium. Metoden står i artiklen om hallucinationer, bias og kildekontrol, og selve grænsen mellem forarbejde og ansvar i Hvad AI ikke kan.

Dokumentér også, hvem der ejer hændelserne. Sætter en medarbejder data ind 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. I undervisningssektoren gælder de samme spørgsmål med en ekstra dimension, fordi eleverne selv bruger værktøjerne – se AI i klasselokalet.

Denne artikel er en praktisk indgang og ikke juridisk rådgivning. Regler, leverandørvilkår og tekniske opsætninger ændrer sig, så kilderne nedenfor bør åbnes, hver gang noget nyt skal vurderes. Det, der holder, er rækkefølgen: beskriv formålet, tegn datavejen, fjern det unødvendige, kontrollér leverandørkæden, og stop, hvis risikoen ikke kan forklares.

Flere tekster om det står under temaet AI, data og ansvar. Skal rammerne skrives ned sammen med de medarbejdere, der skal bruge dem, er workshoppen Fælles spilleregler for AI formatet.

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.