Må vi lægge det her i ChatGPT? En praktisk guide til AI og persondata

En medarbejder vil have hjælp til at besvare en lang kundemail. Hun kopierer mailen ind i en chatbot og beder om et venligt udkast. Det tager 30 sekunder.

Men mailen indeholder kundens navn, ordrenummer, helbredsoplysninger om et familiemedlem og en beskrivelse af en konflikt. Hvem har nu modtaget oplysningerne? Hvor behandles de? Hvor længe gemmes de? Bruges de til at forbedre tjenesten? Og havde virksomheden overhovedet lov og behov for at sende dem videre?

Det er de spørgsmål, der gør AI og persondata til mere end en indstilling i et produkt.

Begynd med materialet – ikke med værktøjet

Det første spørgsmål er ikke “Er ChatGPT GDPR-sikker?” Et værktøj er ikke lovligt eller ulovligt i et vakuum. Vurderingen afhænger blandt andet af, hvilke oplysninger der behandles, til hvilket formål, på hvilket grundlag, med hvilken aftale og med hvilke sikkerhedsforanstaltninger.

Start derfor med materialet. Personoplysninger er enhver oplysning, der kan knyttes til en identificeret eller identificerbar person. Et navn og en mailadresse er oplagte eksempler, men også et kundenummer, en IP-adresse, en stemmeoptagelse, et billede eller en præcis kombination af jobtitel og hændelse kan pege på en person.

Nogle oplysninger kræver særlig opmærksomhed. Det gælder blandt andet oplysninger om helbred, religion, politisk overbevisning, fagforeningsforhold, seksuelle forhold og biometriske oplysninger anvendt til entydig identifikation. Oplysninger om strafbare forhold har også særlige regler.

Derudover findes materiale, som måske ikke er persondata, men stadig ikke bør deles: kontraktudkast, opkøbsplaner, kildekode, adgangsoplysninger, prisstrategi og andre forretningshemmeligheder.

Kortlæg dataens rejse

Når tekst sættes ind i en AI-tjeneste, sker der mere end det, brugeren ser i chatvinduet. Oplysninger kan blive sendt til en ekstern leverandør, behandlet af underleverandører, registreret i logfiler og opbevaret i en periode. Tjenesten kan have forskellige vilkår for private konti, virksomhedsprodukter og API-brug.

Tegn den konkrete datarejse:

1. Hvem indsamlede oplysningerne, og hvad fik personen at vide?
2. Hvilken medarbejder eller hvilket system sender dem til AI-tjenesten?
3. Hvilken juridisk enhed leverer tjenesten?
4. Hvilke underdatabehandlere, regioner og overførsler indgår?
5. Hvilke input, output og tekniske logdata gemmes – og hvor længe?
6. Kan organisationen slette, udlevere og kontrollere oplysningerne igen?

Et skærmbillede med teksten “vi træner ikke på dine data” besvarer kun ét af flere spørgsmål. Det siger ikke nødvendigvis noget om logning, opbevaring, supportadgang, internationale overførsler eller underleverandører.

Kend rollerne og aftalerne

Den organisation, der bestemmer hvorfor og hvordan personoplysninger skal bruges, vil typisk være dataansvarlig. En leverandør, der behandler oplysninger på organisationens instruks, kan være databehandler. Det kræver en databehandleraftale, der beskriver behandlingen og de relevante forpligtelser.

Rollerne kan dog ikke afgøres alene ud fra produktets markedsføring. Det Europæiske Databeskyttelsesråd har i sin udtalelse om AI-modeller understreget, at vurderingen skal være konkret. Det samme gælder spørgsmålet om behandlingsgrundlag og om en model reelt kan betragtes som anonym.

Kontrollér mindst:

• Hvilket produkt og hvilken kontotype bruger medarbejderne faktisk?
• Hvilke vilkår, databehandleraftaler og underdatabehandlere gælder for netop den løsning?
• Er brug af input til træning eller produktforbedring slået fra, og kan indstillingen ændres af brugeren?
• Er opbevaringsperioder og sletning dokumenteret?
• Hvordan håndteres registreredes rettigheder og sikkerhedshændelser?
• Er eventuelle overførsler til lande uden for EU/EØS vurderet?

Leverandøren kan levere sikkerhedsfunktioner og kontraktvilkår. Organisationen beholder ansvaret for at vælge et lovligt formål, begrænse data og instruere medarbejderne.

Gratis konto, firmakonto og API er ikke det samme

Mange fejl opstår, fordi en medarbejder bruger sin private konto til arbejdsopgaver. Organisationen har måske vurderet en virksomhedsudgave, men ikke den private tjeneste. De kan have forskellige standardindstillinger, kontrakter, administratorfunktioner og muligheder for datastyring.

OpenAI oplyser eksempelvis, at data fra virksomhedsløsninger og API-platformen ikke bruges til modeltræning som standard. For personlige ChatGPT-konti findes der særskilte datakontroller, hvor brugeren kan ændre, om samtaler bidrager til forbedring af modellerne. Det er en vigtig forskel – men stadig ikke en generel tilladelse til at dele persondata.

En anvendelig intern regel skal derfor nævne produktet præcist. “Vi må bruge AI” er ikke en instruktion. “Vi må bruge den godkendte virksomhedskonto til disse tre opgavetyper og disse dataklasser” er langt tættere på.

Dataminimering før anonymisering

Den sikreste oplysning er ofte den, der aldrig bliver sendt.

Spørg, om opgaven kan løses uden originalmaterialet. En kundemail kan måske omskrives til en kort, generisk beskrivelse: “En kunde klager over tre ugers leveringstid og ønsker pengene tilbage.” Modellen behøver sjældent navn, telefonnummer, ordrenummer eller en hel korrespondance for at foreslå en høflig struktur.

At fjerne et navn er ikke nødvendigvis anonymisering. “Den eneste kvindelige økonomichef i kommunens forvaltning, der blev sygemeldt efter mødet den 12. maj” kan være let at genkende. Ægte anonymisering betyder, at personen ikke længere med rimelige midler kan identificeres – også når oplysninger kombineres med anden viden.

Pseudonymisering, hvor navnet erstattes af eksempelvis “Kunde 17”, reducerer risikoen, men materialet er fortsat persondata, hvis nøglen eller konteksten kan føre tilbage til personen.

Brug derfor denne rækkefølge:

1. Fjern hele oplysninger, der ikke er nødvendige.
2. Generalisér detaljer som dato, sted, alder og stilling.
3. Erstat identificerende betegnelser.
4. Læs teksten som en kollega: Kan personen stadig genkendes?
5. Brug kun det reducerede materiale i et godkendt værktøj.

En grøn, gul og rød arbejdsregel

En enkel trafiklysmodel kan hjælpe i hverdagen, hvis den tilpasses organisationens egne data og systemer.

Grøn: Lav risiko og ingen fortrolige oplysninger

Eksempler kan være idéer til en mødeagenda, sproglig forbedring af en offentlig tekst eller et resumé af materiale, der allerede er lovligt offentliggjort. Brug stadig den godkendte konto og kontrollér output.

Gul: Interne eller begrænset følsomme oplysninger

Det kan være interne arbejdsnoter, pseudonymiserede kundesager eller dokumenter, hvor enkelte detaljer kan afsløre mere end forventet. Stop og kontrollér den interne instruks, formålet, dataminimeringen og aftalegrundlaget. Spørg den ansvarlige ved tvivl.

Rød: Følsomt, hemmeligt eller højkonsekvens

Helbredsoplysninger, personalesager, børns oplysninger, CPR-numre, adgangskoder, aktive retssager og uanmeldte forretningsbeslutninger bør ikke kopieres ind i en generel AI-chat, blot fordi opgaven føles praktisk. En eventuel løsning kræver en specifikt godkendt arkitektur, klare roller og en dokumenteret vurdering.

Trafiklyset erstatter ikke en juridisk vurdering. Det gør medarbejderen i stand til at stoppe tidligere.

Hvornår kræver brugen en større vurdering?

Jo mere systematisk og indgribende brugen er, desto mindre ligner den en enkelt skrivehjælp. Hvis AI bruges til at vurdere mennesker, prioritere sager, opdage svindel, behandle store mængder følsomme oplysninger eller træffe beslutninger med mærkbare konsekvenser, kan der være behov for en konsekvensanalyse vedrørende databeskyttelse – en DPIA.

En DPIA er ikke en formular, der udfyldes efter lanceringen. Den er en proces til at beskrive nødvendighed, proportionalitet, risici for mennesker og de foranstaltninger, der reducerer dem. Datatilsynet anbefaler at tænke databeskyttelse ind fra begyndelsen, og EDPB’s materiale om store sprogmodeller beskriver både typiske risici og mulige afværgeforanstaltninger.

Inddrag relevante kompetencer tidligt: den faglige ejer, informationssikkerhed, jura, indkøb, databeskyttelsesrådgiver og de medarbejdere, der kender arbejdsgangen. De ser forskellige risici.

En sikker rutine før du trykker send

Brug denne korte kontrol ved hver opgave:

1. Er værktøjet godkendt?

Kontrollér produkt, konto og opgavetype. Et logo, du kender, er ikke det samme som en godkendelse.

2. Er data nødvendige?

Fjern alt, der ikke ændrer kvaliteten af svaret. Lav om muligt et kunstigt eksempel.

3. Kan en person genkendes?

Se på helheden, ikke kun navn og mailadresse.

4. Er formål og grundlag på plads?

Data må ikke genbruges til et nyt formål alene, fordi AI gør det nemt.

5. Kan resultatet skade nogen?

Vurder både læk, fejl, skævhed og efterfølgende brug. Et AI-udkast kan indeholde persondata, som ikke stod tydeligt i inputtet.

6. Hvem kontrollerer og sletter?

Placér ansvar for kvalitet, adgang, opbevaring og eventuel oprydning.

Hvis du ikke kan besvare punkterne, er den rigtige handling at stoppe – ikke at gætte.

Gør det nemt at vælge rigtigt

Medarbejdere bruger ofte private AI-konti, fordi den godkendte vej er uklar eller besværlig. Forbud uden et brugbart alternativ flytter derfor let brugen ud i skyggen.

En god organisation giver medarbejderne:

• en kort liste over godkendte værktøjer og tilladte opgaver
• konkrete eksempler på grønne, gule og røde data
• en enkel kontaktvej ved tvivl
• skabeloner med kunstige data til øvelse
• tekniske standardindstillinger, der ikke afhænger af den enkelte
• en proces for nye behov og sikker rapportering af fejl

Målet er ikke, at alle skal kunne citere GDPR. Målet er, at de kan genkende det øjeblik, hvor et praktisk AI-forsøg bliver til behandling af andre menneskers oplysninger – og ved, hvad de skal gøre bagefter.

Kilder og videre læsning

• Datatilsynet: Kunstig intelligens – dansk myndighedsvejledning, cases og materiale om databeskyttelse ved AI.
• EDPB: Opinion 28/2024 om AI-modeller – officiel EU-udtalelse om blandt andet anonymitet, behandlingsgrundlag og udvikling af AI-modeller.
• EDPB: AI Privacy Risks & Mitigations for Large Language Models – rapport om databeskyttelsesrisici og mulige afværgeforanstaltninger.
• OpenAI: Business data privacy, security, and compliance – leverandøroplysninger om behandling af virksomhedsdata.
• OpenAI: Enterprise privacy – leverandøroplysninger om kontrol, ejerskab og modeltræning for virksomhedsprodukter.
• OpenAI: Data Controls FAQ – indstillinger for data i personlige ChatGPT-konti.