GDPR og AI: hvad må du sende til OpenAI og Claude?

Du må godt sende persondata til OpenAI og Claude via deres API'er, men kun når fire ting er på plads: et lovligt formål, en databehandleraftale med udbyderen, et gyldigt grundlag for at sende data til USA, og at du kun sender det opgaven kræver. GDPR og AI udelukker altså ikke hinanden, men den måde en hurtigt bygget prototype typisk sender data på, holder sjældent.

Jeg er udvikler, ikke jurist. Det her er den praktiske og tekniske side som jeg gennemgår når jeg bygger AI-funktioner ind i en app, og det er ikke juridisk rådgivning. Udbydernes vilkår ændrer sig ofte, så oplysningerne er tjekket i oktober 2026 og bør tjekkes igen før du går i drift.

Den korte version: hvad kan du sende?

Min tommelfingerregel: send aldrig mere end den konkrete opgave kræver, og fjern direkte identifikatorer som navn, e-mail, telefonnummer og CPR-nummer før data forlader din server. Det løser ikke alt, men det flytter de fleste AI-funktioner fra risikabelt til håndterbart.

Er du ved at gøre en AI-bygget prototype klar til rigtige brugere, så start med min guide til at få en AI-app i produktion. Denne guide handler kun om de data der sendes videre til sprogmodellen.

Hvad sker der med dine data hos OpenAI og Anthropic?

Skeln først mellem API'et og chat-apps. Når din app kalder OpenAI eller Claude via API'et, gælder udbydernes erhvervsvilkår. Forbrugerversionerne af ChatGPT og Claude har andre vilkår, og her kan samtaler bruges til træning afhængigt af brugerens indstillinger. Den største GDPR-risiko i mange virksomheder er derfor ikke appen, men en medarbejder der indsætter kundedata i en privat chatkonto.

På API'et ser det sådan ud i oktober 2026:

• Træning: OpenAI skriver i sin dokumentation om datakontrol at data sendt til API'et ikke bruges til at træne modeller, medmindre du selv vælger det til. Anthropic siger det samme om API'et og sine andre erhvervsprodukter i sit privatlivscenter.
• Lagring til misbrugskontrol: OpenAI gemmer logfiler til misbrugskontrol i op til 30 dage. Anthropic oplyser i sit privatlivscenter at input og output som udgangspunkt slettes inden for 30 dage, med undtagelser for fx overtrædelser af brugspolitikken.
• Lagring du selv styrer: Nogle funktioner gemmer data længere. Hos OpenAI gemmer Responses API'et som standard svar i 30 dage, og filer du uploader, ligger indtil du sletter dem eller de når en udløbsdato du selv har sat. Anthropic har en tilsvarende undtagelse for sit Files API.
• Ingen lagring: Begge udbydere tilbyder zero data retention, hvor indhold ikke gemmes til misbrugskontrol. Det kræver en særskilt aftale eller godkendelse fra udbyderen.

"De træner ikke på vores data" er altså kun halvdelen af svaret. Data ligger stadig hos en amerikansk udbyder i en periode, og det skal dine aftaler og din privatlivspolitik afspejle. Teknisk kan du ofte selv skrue ned: sæt store til false i OpenAIs Responses API, slet uploadede filer når de er brugt, og gem ikke flere samtaler end nødvendigt.

Databehandleraftalen og overførslen til USA

Når din app sender persondata til en sprogmodel, er du som regel dataansvarlig, og AI-udbyderen er din databehandler. GDPR artikel 28 kræver en databehandleraftale mellem jer. Hos Anthropic er databehandleraftalen, inklusive EU's standardkontraktbestemmelser, automatisk en del af de kommercielle vilkår. OpenAI har også en databehandleraftale til API-kunder, men tjek hvordan den er indgået for jeres konto, og gem en kopi.

Begge udbydere er amerikanske, så du skal også have et grundlag for at overføre data ud af EU. Der er to typiske veje:

• EU-US Data Privacy Framework. EU-Kommissionen vedtog 10. juli 2023 en afgørelse om at amerikanske virksomheder der er certificeret under ordningen, har et tilstrækkeligt beskyttelsesniveau. Tjek på ordningens officielle liste om din udbyder er med.
• Standardkontraktbestemmelser. Er udbyderen ikke certificeret, eller vil du have en ekstra sikring, bruges EU's standardkontrakter, typisk som en del af databehandleraftalen.

Forgængeren Privacy Shield blev underkendt af EU-Domstolen i 2020. Det er derfor klogt at have standardkontrakterne som plan B, også selvom udbyderen er certificeret.

Hvis du selv er databehandler

Bygger du en SaaS hvor dine kunder lægger deres egne kunders data ind, er du databehandler, og AI-udbyderen bliver din underdatabehandler. Så skal dine kunder have godkendt det, typisk via listen over underdatabehandlere i jeres databehandleraftale. Afhængigt af aftalen skal du enten varsle kunderne eller have deres skriftlige godkendelse før en ny AI-funktion tager deres data med. Hvad en SaaS ellers kræver ud over selve koden, gennemgår jeg i mit ærlige svar på om du kan bygge en SaaS med AI alene.

EU-datalokation: hvor kan data blive i Europa?

GDPR kræver ikke at data bliver i EU, så længe overførslen har et lovligt grundlag. Men mange B2B-kunder, især i den offentlige sektor, sundhed og finans, stiller selv det krav til deres leverandører. Så er valget af udbyder ikke længere kun et spørgsmål om hvilken model der er bedst.

Tre detaljer er lette at overse:

• Azure Global er ikke EU. Microsofts beskrivelse af udrulningstyper er klar: Global-typer kan behandle data i alle Azure-regioner, også selvom din ressource ligger i Sverige. Vil du have behandlingen i Europa, skal du vælge Data Zone EU eller en regional udrulning. Global er standardvalget og det billigste, så det er let at ende der uden at vide det.
• Claudes egen API har ingen EU-region. Ifølge Anthropics dokumentation om datalokation kan behandlingen kun sættes til USA eller global, og data gemmes i USA. Skal Claude køre i Europa, går vejen gennem AWS Bedrock eller Google Cloud, hvor regionen bestemmes af det endpoint du kalder. Her er det cloududbyderen der er din databehandler, så databehandleraftalen skal være på plads med AWS eller Google.
• OpenAI i Europa kræver en aftale. Europæisk behandling kræver at OpenAI har godkendt jeres konto til ændret lagring, og regionen vælges når du opretter et nyt projekt.

Europæisk behandling har en pris. Hos Microsoft kommer nye modeller først til Global, derefter til Data Zone og til sidst til de regionale udrulninger, og regionale varianter kan koste mere. Regn det med i budgettet for AI-funktioner i drift.

Husk også at en EU-region hos en amerikansk udbyder stadig er en amerikansk udbyder. For de fleste virksomheder er europæisk behandling plus en databehandleraftale nok. Kræver en kunde at ingen amerikansk virksomhed er involveret, er det kun en europæisk udbyder eller en model du selv driver på europæisk hosting, der opfylder kravet.

Send mindre: dataminimering og pseudonymisering

Det mest effektive værn er at sende færre persondata. Det er også her mange AI-byggede apps fejler: de sender hele databaserækker eller hele samtaler fordi det var nemmest at skrive prompten sådan.

Sådan ser det ud i praksis:

• Send felter, ikke rækker. Skal modellen kategorisere en supporthenvendelse, har den brug for teksten, ikke kundens navn, adresse og ordrehistorik.
• Erstat identifikatorer før kaldet. Byt navne, e-mails og telefonnumre ud med pladsholdere som KUNDE_1, og sæt de rigtige værdier ind igen når svaret kommer tilbage. Det sker på din egen server, så sprogmodellen aldrig ser dem.
• Rens fritekst. E-mails, telefonnumre og CPR-numre kan fanges med faste mønstre. Navne og adresser i fritekst er sværere og kræver et separat værktøj til at genkende dem, eller en klar regel om hvilke felter der slet ikke sendes.
• Pas på dine egne logfiler. Gemmer appen prompts og svar til fejlfinding, ligger der persondata i dine logfiler. Bruger du et overvågningsværktøj til AI-kald, er det også en databehandler.
• Hold systemprompten fri for persondata. Den sendes med hvert eneste kald, så der hører instrukser hjemme, ikke kundedata.

Pseudonymiserede data, hvor du kan sætte navnene ind igen, er stadig persondata efter GDPR (præambelbetragtning 26). Det mindsker risikoen og styrker din vurdering, men du skal stadig have aftaler og grundlag på plads. Ægte anonymisering, hvor ingen kan finde frem til personen igen, er svær med fritekst. En henvendelse fra "ejeren af den eneste bager i en landsby med 800 indbyggere" peger på én person, selvom navnet er fjernet.

Sådan gør du i praksis: 7 trin

1. Tegn dataflowet. Skriv ned hvilke felter der sendes, fra hvilken del af appen, til hvilken udbyder og region. Tag logfiler, vektordatabaser og overvågningsværktøjer med, for de bliver tit glemt.
2. Fastlæg formål og grundlag. Hvorfor sender du data, og hvilket behandlingsgrundlag i artikel 6 bruger du? Tjek samtidig om der kan optræde følsomme oplysninger efter artikel 9, også i fritekst som brugerne selv skriver.
3. Vælg udbyder og region ud fra kravene. Har dine kunder krav om behandling i Europa, så vælg en løsning der opfylder det fra start. Det er dyrere at skifte bagefter.
4. Få aftalerne på plads. Databehandleraftale, overførselsgrundlag, din fortegnelse over behandlingsaktiviteter efter artikel 30 og, hvis du driver en SaaS, din liste over underdatabehandlere.
5. Byg minimering ind i koden. Filtrering og pseudonymisering før kaldet, lagring slået fra hvor det er muligt, og automatisk sletning af filer og gemte samtaler. Den tekniske side af selve integrationen gennemgår jeg i guiden til at integrere OpenAI eller Claude i dit system.
6. Vurdér om du skal lave en konsekvensanalyse. Artikel 35 kræver en konsekvensanalyse når behandlingen sandsynligvis indebærer en høj risiko, fx ved følsomme oplysninger i større omfang eller systematisk vurdering af personer. Datatilsynet har samlet vejledning og en skabelon til konsekvensanalyse ved AI på sin temaside om kunstig intelligens.
7. Fortæl brugerne det. Opdatér privatlivspolitikken med formål, modtager og overførslen til USA. Træffer AI-funktionen afgørelser om personer uden at et menneske er involveret, så kig også på reglerne om automatiske afgørelser i artikel 22.

Hvornår du ikke skal sende persondata til en sprogmodel

Nogle gange er det rigtige svar at lade være:

• Når opgaven kan løses uden. Produkttekster, opsummering af interne dokumenter og klassificering af generiske henvendelser kræver sjældent persondata. Byg funktionen så den slet ikke får dem.
• Når data er følsomme og ikke kan renses. Patientoplysninger, sager om børn og personalesager hører ikke hjemme hos en generel sprogmodel. Her er en model du selv driver, en europæisk udbyder med de rette aftaler eller ingen AI de realistiske valg.
• Når en kunde kræver at ingen amerikansk virksomhed er involveret. Så hjælper hverken EU-region eller zero data retention.
• Når du ikke kan forklare brugeren hvad der sker. Kan du ikke skrive det i privatlivspolitikken i to klare sætninger, er dataflowet for uklart.

En chatbot på hjemmesiden er et typisk eksempel. Besøgende skriver navne, ordrenumre og nogle gange helbredsoplysninger ind, også selvom du beder dem lade være. Det skal du tage højde for, uanset om du bygger chatbotten selv eller køber en færdig.

Du har heller ikke altid brug for en udvikler som mig. Et lille internt værktøj uden persondata kan du sætte op selv. Er dit spørgsmål rent juridisk, fx om dit behandlingsgrundlag holder, er det en advokat eller en GDPR-rådgiver du skal tale med.

Næste skridt

Vil du have hjælp til at bygge en AI-funktion hvor dataflowet holder, kan du se hvordan jeg arbejder med webapps og platforme. Tag den juridiske vurdering med en rådgiver, især hvis der er følsomme oplysninger i spil.

Ofte stillede spørgsmål

Må mine medarbejdere bruge ChatGPT med kundedata?+

Kun med en erhvervsløsning og klare regler. Gratis og private konti har forbrugervilkår, hvor samtaler kan bruges til træning, og der er ingen databehandleraftale med din virksomhed. Med erhvervsversionerne af ChatGPT og Claude får du en databehandleraftale, og udbyderne træner som standard ikke på dine data. Skriv ned hvilke typer data der må bruges, og hold følsomme oplysninger og CPR-numre ude uanset hvilken konto der bruges.

Er embeddings og vektordatabaser også persondata?+

Ja, i praksis skal du behandle dem som persondata. Teksten sendes til udbyderen for at blive lavet om til embeddings, og vektordatabasen gemmer som regel de oprindelige tekststykker ved siden af. Beder en bruger om at blive slettet, skal du også kunne finde og slette personens data der. Det er lettest hvis hvert tekststykke er mærket med hvilken kunde eller bruger det stammer fra.

Er en open source-model jeg selv driver, den sikre løsning?+

Det kan den være fordi data ikke forlader dit eget miljø, og så forsvinder spørgsmålet om overførsel til USA. Til gengæld overtager du ansvaret for sikkerhed, drift, opdateringer og hardware, og de mindre modeller er typisk svagere end de store. GDPR gælder stadig fuldt ud for de data du behandler. Det er oftest kun pengene værd ved følsomme data eller strenge krav fra kunder.

Hvad gør jeg når en bruger beder om at få slettet sine data?+

Slet data i dine egne systemer først: database, logfiler, vektordatabase og gemte samtaler. Hos udbyderen forsvinder data til misbrugskontrol automatisk efter lagringsperioden, men det du selv har gemt via API'et, fx filer eller gemte svar, skal du slette aktivt. Da API-data ikke bruges til træning, ligger brugerens oplysninger ikke i selve modellen.

Skal jeg fortælle brugerne at jeg bruger AI?+

Ja, når persondata sendes til en AI-udbyder, skal det fremgå af din privatlivspolitik med formål, modtager og overførsel til USA. EU's AI-forordning har desuden regler om gennemsigtighed, fx at folk skal vide at de taler med en chatbot og ikke et menneske. Det er god praksis at skrive det tydeligt i selve brugerfladen, ikke kun i politikken.