Brug personoplysninger lovligt i AI
Personoplysninger kan indgå i en AI-løsning, når den konkrete behandling har et lovligt grundlag og opfylder de øvrige databeskyttelseskrav. At oplysningerne allerede findes i virksomheden, giver ikke i sig selv ret til enhver ny AI-anvendelse. Afklar formål, nødvendighed, leverandører og risiko før brug.
Artiklen tager udgangspunkt i danske virksomheder og EU-regler. Regelgrundlaget er kontrolleret den 10. september 2026. Den konkrete vurdering afhænger af oplysninger, formål, sektor og løsning. Datasikkerhed fra regler til daglig praksis (AI-11-001) giver det bredere overblik, mens Beskyt fortrolige oplysninger når I bruger AI (Q16) behandler teknisk og organisatorisk sikkerhed.
GDPR gælder også små virksomheder, når de behandler personoplysninger. [1] En navngiven erhvervskontakt, en kundemail eller oplysninger om en medarbejders arbejdsindsats kan være persondata. Det er derfor vigtigt at undersøge de faktiske data og ikke alene dokumentets titel.
Beskriv behandlingen før I vælger grundlag
Skriv, hvad virksomheden ønsker at gøre, hvilke oplysninger der er nødvendige, og hvem der berøres. Hjælp til at besvare en kundes spørgsmål er en anden behandling end at bruge alle kundesamtaler til at træne en model. En analyse af medarbejderes præstationer kræver også sin egen vurdering.
Datatilsynet beskriver flere mulige behandlingsgrundlag, herunder kontrakt, retlig pligt, samtykke og legitim interesse. [2] Det relevante grundlag afhænger af situationen. Samtykke er ikke en universel løsning, og ved følsomme oplysninger skal der desuden være en relevant undtagelse fra forbuddet i artikel 9.
| Afklaring | Det virksomheden skal kunne forklare | Eksempel på en mangelfuld begrundelse |
|---|---|---|
| Formål | Hvilket konkret behov behandlingen opfylder | Vi vil bruge AI generelt |
| Nødvendighed | Hvorfor de valgte oplysninger behøves | Det er lettere at sende alt |
| Grundlag | Hvilken hjemmel der passer til behandlingen | Data ligger allerede i CRM |
| Modtagere | Hvilke tjenester og personer får adgang | Leverandøren siger at den er sikker |
| Opbevaring | Hvor længe data og afledte kopier behøves | Vi sletter når nogen spørger |
Afklar spørgsmålene med en person, som har relevant databeskyttelseskompetence. Artiklen kan strukturere arbejdet, men kan ikke fastlægge virksomhedens konkrete behandlingsgrundlag uden de nødvendige oplysninger.
Begræns data og gør rettigheder praktiske
Brug kun de oplysninger, formålet kræver. Overvej, om navne eller andre identifikatorer kan udelades. Pseudonymisering kan mindske risikoen, men oplysningerne er fortsat persondata, hvis de kan henføres til personer. Reel anonymisering kræver en vurdering af muligheden for identifikation.
Principper om blandt andet formålsbegrænsning, dataminimering, rigtighed og opbevaring gælder også ved AI. [6] Vores praktiske konsekvens er, at rettelser og sletninger skal kunne nå relevante tekstkopier, søgeindeks og logs. Embeddings er ikke automatisk anonyme, blot fordi de består af tal.
De berørte skal have de relevante oplysninger om behandlingen, og virksomheden skal kunne håndtere deres rettigheder efter reglerne. [5] Afprøv arbejdsgangen: Kan I finde, rette eller slette de nødvendige data i både kilden og den nye løsning? Gør virksomhedens data klar til AI (Q13) og Brug virksomhedens viden med RAG (Q14) behandler sporbarhed og dokumentlivscyklus.
Undersøg leverandørens rolle og overførsler
Afklar, om leverandøren behandler oplysninger på virksomhedens vegne, og indgå en databehandleraftale, når det er den relevante rolle. Hvis leverandøren bruger data til egne formål, kræver det særskilt vurdering. Gennemgå underleverandører, opbevaring, sikkerhed og hjælp til rettigheder og hændelser.
Datatilsynets cloudvejledning viser, at overførsler og ansvar skal vurderes i hele leverandørkæden. [4] EU-lagring alene afgør ikke spørgsmålet, hvis eksempelvis support eller underleverandører får adgang fra et tredjeland. Vælg AI leverandør og bevar handlefriheden (Q23) giver en praktisk indkøbsramme.
En indstilling, der fravælger træning, besvarer kun ét spørgsmål. Den siger ikke nødvendigvis noget om lovligt grundlag, opbevaring, supportadgang eller det formål, virksomheden selv har. Vurder den samlede behandling.
Vurder risiko før en MVP med persondata
En konsekvensanalyse, DPIA, er påkrævet, når behandlingen sandsynligvis indebærer høj risiko for personers rettigheder. AI udløser ikke automatisk kravet. Hvis høj risiko består efter beskyttelsestiltag, kræves forudgående høring af Datatilsynet. [3]
Vurder konsekvensen for de berørte personer, ikke kun risikoen for virksomhedens økonomi. Forkerte oplysninger i rekruttering, kreditvurdering eller medarbejderkontrol kan få væsentlige følger. En lille pilot kan også behandle persondata og skal derfor afklares før brug.
Ved afgørelser, der alene træffes automatisk og har retsvirkning eller tilsvarende væsentlig betydning, skal artikel 22 vurderes særskilt. Undtagelser kræver relevante betingelser og garantier. [5] Et menneske, der blot bekræfter modellens forslag uden reel vurdering, er ikke en meningsfuld kontrol. Fastlæg menneskelig kontrol med AI agenter (Q25) uddyber dette.
Et eksempel med kundeservice
Virksomheden i dette eksempel vil sammenfatte kundemails. Den afklarer først formål og nødvendige felter. Et eksperiment bruger syntetiske eller reelt anonymiserede eksempler. Det kan vise tekniske muligheder, men dokumenterer ikke alene, at den senere behandling af virkelige mails er afklaret.
Før MVP’en beskriver virksomheden databehandling, relevante grundlag, leverandørrolle og opbevaring. Den begrænser adgang, tester sletning og instruerer medarbejderne i håndtering af særlige oplysninger. Ved skalering kontrolleres nye datakilder og ændrede formål igen.
Næste ledelsesbeslutning: Få en kort, dokumenteret vurdering af den konkrete behandling og eventuelt DPIA-behov. Afgræns data og anvendelse, indtil de nødvendige forhold er afklaret, og knyt opfølgningen til den ansvarlige procesejer.
Kundeeksempel med mål og opfølgning
I kundeserviceeksemplet er målet kortere arbejde med 4.000 månedlige sager. Første test kan bruge konstruerede sager uden rigtige kundeidentiteter til at afprøve teknisk funktion. En senere test på faktiske sager kræver særskilt afklaring af behandlingen og de nødvendige oplysninger.
Mål både tid inklusive kontrol og om irrelevante kundeoplysninger følger med i svaret. Et godt tidsresultat dokumenterer ikke i sig selv, at databehandlingen er lovlig. Brug den konkrete regelvurdering i denne artikel som ramme for testen.
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
Eksempler og handlingsforslag er EnableAIs faglige vurdering. Virksomhedseksempler og regnetal er illustrative. Artiklen er opdateret med konkrete regneeksempler og henvisninger den 15. september 2026.
[1] Datatilsynet · GDPR for små virksomheder
[2] Datatilsynet · Behandlingsgrundlag
[3] Datatilsynet · Konsekvensanalyse
[4] Datatilsynet · Cloud og leverandørkæder