DPIA for generativ AI: trin-for-trin guide til vurdering af databeskyttelse

Generativ AI kan give mærkbare gevinster i alt fra kundeservice og marketing til jura, HR og IT-drift. Samtidig har teknologien en tendens til at trække flere personoplysninger ind i processer, end man tror, og den kan skabe nye risici gennem både input, output, logning, træning og leverandørkæder.

En DPIA (konsekvensanalyse for databeskyttelse) er derfor ikke bare “compliance-papirarbejde”. Det er en praktisk metode til at gøre et generativt AI-setup skarpere, sikrere og lettere at forklare for både ledelse, registrerede og tilsyn. Og jo tidligere man gør det, jo billigere bliver det at rette til.

Hvornår er en DPIA relevant for generativ AI?

GDPR artikel 35 kræver en DPIA, når en behandling sandsynligvis medfører høj risiko for fysiske personers rettigheder og frihedsrettigheder. Generativ AI rammer ofte flere af de klassiske risikokriterier på én gang: nye teknologier, store datamængder, profilering, automatisering og uforudsigelige outputs.

Det giver mening at starte med en kort “DPIA-screening”, før man går i gang med den fulde analyse, så teamet tidligt kan beslutte scope og niveau.

Efter en kort indledende afklaring kan følgende typisk udløse DPIA-behov:

• Storskala behandling af personoplysninger
• Profilering, scoring eller segmentering
• Behandling af følsomme oplysninger eller oplysninger om strafbare forhold
• Løsninger der påvirker ansættelse, adgang til ydelser, kredit, sundhed eller uddannelse
• Nye typer angrebsmønstre (prompt injection, dataudtræk, modelangreb) der kan føre til brud eller uretmæssig udlevering

Trin 1: Afgræns formål, roller og AI-arkitektur

Start med at skrive én side, som alle kan være enige om. Ikke marketing, men præcis praksis.

Formål: Hvad skal AI faktisk gøre, og hvad skal den ikke gøre? “Hjælpe medarbejdere med at skrive udkast” er et andet formål end “træffe beslutninger” eller “give rådgivning til borgere/kunder”.

Roller: Hvem er dataansvarlig, og hvem er databehandler? Ved generativ AI er det almindeligt, at en leverandør leverer modeltjenesten, en anden leverer integrationslaget, og organisationen selv ejer data og use case. Den rollefordeling skal være klar, før man taler om risici.

Arkitektur: Er det en offentlig chatbot, en intern assistent, et API-kald fra et fagsystem, eller en løsning med RAG (Retrieval Augmented Generation), hvor modellen slår op i jeres videnbase? Den tekniske form afgør, hvilke data der flyder hvorhen.

Trin 2: Kortlæg dataflow fra input til output (inklusive “skjulte” dataspor)

En god DPIA for generativ AI lever af et konkret dataflow. Tegn det gerne som en simpel boksmodel: bruger, klient, gateway, model-endpoint, logning, videnbase, admins, monitoring, underleverandører.

Husk, at dataflow ved generativ AI ofte har flere lag end klassiske applikationer:

• Input (prompt): kan indeholde personoplysninger, fortrolige oplysninger eller “tilfældig” kontekst, som brugeren ikke tænker over.
• Output: kan indeholde personoplysninger, som modellen gætter, sammenstykker eller henter fra videnbasen.
• Telemetri/logning: prompts og outputs bliver ofte logget til drift, fejlsøgning, kvalitet og sikkerhed.
• Træning/fine-tuning: nogle setups bruger organisationens data til at ændre modellen, andre gør ikke, og det skal dokumenteres.
• Feedback loops: “thumbs up/down” og brugerkommentarer kan blive nye datasæt.

Når dataflowet er synligt, bliver det også realistisk at minimere, afgrænse og kontrollere.

Trin 3: Identificér datatyper og registrerede, og afgør om I rammer særlige kategorier

Generativ AI er kendt for at blande kontekst. En prompt kan indeholde navn, e-mail, medarbejder-ID, helbredsoplysninger i en sygefraværssag og en vurdering af performance i samme tekstfelt.

Derfor bør datakortlægningen gå et niveau dybere end “vi behandler kontaktdata”. Klassificér datatyper og registrerede grupper (kunder, borgere, børn, medarbejdere, leverandørkontakter), og markér straks alt, der kan være særlige kategorier efter artikel 9 eller oplysninger om strafbare forhold.

Det er også her, mange opdager, at et tilsyneladende “harmløst” skriveværktøj i praksis bruges til HR-tekster, referater eller svar til klager, som kan indeholde meget følsomme elementer.

Trin 4: Fastlæg retsgrundlag og gennemsigtighed, så AI-brug kan forklares i klart sprog

Retsgrundlag skal hænge sammen med formålet og de konkrete funktioner. Et generativt AI-system kan have flere behandlingsaktiviteter, som kræver hver sin vurdering: drift af chatfunktion, logning til sikkerhed, kvalitetsovervågning, eventuel træning.

Transparens er mere end en privatlivspolitik. Brugere og registrerede skal møde tydelig information i konteksten: at de taler med AI, hvad den bruges til, og hvad de bør undlade at skrive.

En enkel måde at gøre det operationelt er at beskrive krav til information på tre niveauer: UI-tekst i produktet, et kort forklaringslink, og et fuldt lag med detaljer til dem, der vil læse mere.

Trin 5: Vurder nødvendighed og proportionalitet (dataminimering i praksis)

Dataminimering bliver konkret, når man binder den til prompts, integrationer og standardflows. Spørgsmålet er ikke “kan modellen håndtere data?”, men “behøver den det?”.

Her kan en DPIA give en stærk, praktisk beslutningsramme: Skal medarbejdere maskere persondata før brug? Skal der indføres skabelonprompts? Skal adgang til visse datakilder i RAG begrænses? Skal nogle use cases helt forbydes?

Et kort sæt designvalg kan reducere risikoen mærkbart, uden at fjerne værdien af AI.

Trin 6: Kortlæg trusler og risici, der er særlige for generativ AI

Risikovurderingen bør dække både klassiske privatlivsrisici (uautoriseret adgang, manglende hjemmel, for lange opbevaringsperioder) og AI-specifikke mønstre (uventet output, angreb på prompts, dataudtræk).

Efter en beskrivende passage er det nyttigt at liste risiciene i et sprog, hvor både jura, IT og forretning kan genkende dem:

• Prompt-lækage: Personoplysninger skrives i prompts og ender i logning, supporttickets eller leverandørsystemer
• Uautoriseret udlevering: Modellen giver svar med interne eller personhenførbare data via RAG eller dårlige adgangskontroller
• Fejl og hallucinering: Output fremstår sikkert, men er faktuelt forkert og kan skade den registrerede (fx i HR eller sagsbehandling)
• Bias og forskelsbehandling: Output skævvrider vurderinger, prioriteringer eller formuleringer om bestemte grupper
• Modelangreb: Prompt injection, jailbreaks eller forsøg på at få modellen til at afsløre data, systemprompts eller konfiguration
• Rettighedsfriktion: Indsigts- og sletteanmodninger kan ikke håndteres, fordi man ikke kan spore data gennem prompt, output og logning

Trin 7: Vurdér sandsynlighed og konsekvens med en enkel matrice, der kan forsvares

Når risici er listet, skal de scores. Mange teams går galt her ved at gøre det for akademisk.

Hold det stramt: sandsynlighed (lav, middel, høj) og konsekvens (lav, middel, høj), og skriv én begrundelse pr. vurdering. Konsekvens bør handle om effekt på individet: diskrimination, tab af kontrol, økonomisk skade, omdømme, fortrolighed, psykologisk påvirkning, risiko for uretmæssige afgørelser.

Lav gerne vurderingen pr. use case, ikke pr. “platform”. En intern AI-assistent til generelle skriveudkast er en anden risikoprofil end en model, der hjælper med rekruttering eller sagsprioritering.

Trin 8: Planlæg foranstaltninger, der faktisk kan implementeres

En DPIA skaber værdi, når den ender som byggeplan for kontroller. Brug en blanding af tekniske og organisatoriske tiltag, og bind dem til de konkrete risici.

Nedenfor er typiske foranstaltninger, som ofte passer godt til generativ AI:

• Dataminimering i brugerflow: Maskering af PII, skabelonprompts, blokering af bestemte datatyper i inputfelter
• Sikker drift: Kryptering, adgangsstyring, rollebaseret admin, private endpoints og klare miljøskel (dev, test, prod)
• Kontrol af RAG: Dokumentadgang efter rettigheder, filtrering af søgeresultater, citationskrav i output
• Leverandørkrav: Ingen brug af jeres data til træning, klare underdatabehandlere, opbevaringsgrænser, auditmuligheder
• Menneskelig kontrol: Review-krav ved højrisiko output, eskalationsveje, stopknap og klare ansvarsplaceringer
• Test og overvågning: Red teaming, prompt-injection tests, monitorering af risikable outputs, hændelsesberedskab

Læg mærke til, at nogle tiltag både er privatliv og kvalitet. Krav om kildehenvisninger i RAG kan både mindske risikoen for fejl og gøre det lettere at forklare behandlingen.

Trin 9: Leverandørstyring, tredjelandsoverførsler og kontrakter der matcher AI-virkeligheden

Mange generative AI-løsninger købes som service. DPIA’en skal derfor hænge tæt sammen med databehandleraftale, sikkerhedsbilag og overførselsgrundlag.

Spørg konkret: Hvor behandles data fysisk og logisk? Hvilke underleverandører er i kæden? Hvilke logdata gemmes, hvor længe, og hvem kan tilgå dem? Kan man konfigurere “no training” og “no retention”, og gælder det også for support?

Det er også klogt at tænke i exit allerede her: Kan prompts, outputs, embeddings og konfigurationer flyttes eller slettes kontrolleret, hvis leverandøren skiftes?

Trin 10: Dokumentér, godkend og gør DPIA’en til et levende artefakt

DPIA’en skal gennemføres før behandlingen, men den stopper ikke ved go-live. Generativ AI ændrer sig: modelversioner skifter, promptbiblioteker vokser, videnbaser udvides, og use cases flytter sig fra “hjælp” til “beslutningsstøtte”.

Planlæg derfor faste triggere for revidering: nye datakilder, ny leverandør, ny model, ny brugergruppe, eller ændring i formål. Og sørg for logning og sporbarhed, så rettighedsanmodninger og hændelser kan håndteres i praksis.

Mange organisationer får god effekt af at koble DPIA-arbejdet med en simpel governance-proces og kompetenceløft på tværs af jura, IT og forretning. Nordisk Business Academy arbejder netop praksisnært med AI og ansvarlig brug, hvor skabeloner, tjeklister og cases hjælper teams med at gøre kravene operationelle i hverdagen.

En kompakt arbejdsoversigt (som kan sættes ind i jeres DPIA-skabelon)

Tabellen her kan bruges som “rygrad” i en DPIA for generativ AI, så intet centralt glemmes.

Trin i DPIA	Hvad I beskriver	Typiske output-artefakter
1. Formål og scope	Use cases, brugergrupper, hvad AI må og ikke må	Formålsbeskrivelse, scope-notat
2. Roller	Dataansvarlig, databehandler, underdatabehandlere	RACI, leverandøroversigt
3. Dataflow	Input, output, logning, RAG, træning	Dataflowdiagram, behandlingsfortegnelse
4. Datatyper	Almindelige, følsomme, strafbare, børn	Dataklassifikation, adgangsmodel
5. Retsgrundlag og info	Artikel 6 og evt. 9, informationslag	Privatlivstekst, UI-labels
6. Risici	AI-specifikke og klassiske privatlivsrisici	Risikolog, trusselkatalog
7. Vurdering	Sandsynlighed og konsekvens pr. risiko	Risikomatrice, begrundelser
8. Foranstaltninger	Tekniske og organisatoriske kontroller	Kontrolplan, testplan
9. Leverandør og overførsler	DPA, SCC, sikkerhed, retention	Kontraktbilag, transfer-vurdering
10. Drift og opfølgning	Logging, audit, ændringsstyring, DSAR	Revisionsplan, beredskab

Små genveje der gør arbejdet lettere uden at gøre det løst

En DPIA bliver hurtigt tung, hvis man prøver at skrive alt på én gang. Det hjælper at strukturere arbejdet som korte, tværfaglige workshops med klare leverancer: dataflow først, så retsgrundlag og transparens, så risici og kontroller.

Og husk, at DPIA’en ikke skal bevise, at der ingen risiko er. Den skal vise, at I har set risiciene, vurderet dem ærligt og valgt foranstaltninger, der passer til både teknologien og de mennesker, der kan blive ramt.

Når det lykkes, bliver generativ AI ikke bare et eksperiment, men en stabil kapabilitet, som kan skaleres med ro i maven og et sprog, der kan deles med både kolleger, ledelse og omverdenen.