Data og ansvar

GDPR i appen: få persondata ud af blinde vinkler

En privatlivspolitik gør ikke i sig selv en app lovlig eller sikker. I skal vide, hvilke personoplysninger appen behandler, hvorfor de er nødvendige, hvem der får dem, hvor længe de ligger, og hvordan de kan rettes, udleveres eller slettes i praksis.

Guiden er en teknisk arbejdsramme – ikke juridisk rådgivning

Den hjælper jer med at finde konkrete huller i en app og stille de rigtige spørgsmål. Behandlingsgrundlag, særlovgivning, følsomme oplysninger, børn, profilering og overførsler uden for EU/EØS kan kræve en konkret juridisk vurdering.

Kortlæg dataflowet før I skriver flere tekster

En personoplysning er ikke kun navn og email. Et kundenummer, en IP-adresse, en lokation, en supportbesked eller en hændelse i en log kan også kunne henføres til en person. Start derfor ved appens formularer, database, filer, logs, analyseværktøjer, email, integrationer, backups og AI-tjenester – ikke ved privatlivspolitikken.

Data og personer	Formål og grundlag	Systemer og modtagere	Adgang og sletning
Kontaktdata om kunder	Oprette og betjene en konto	Database, mailtjeneste og support	Roller, frist og slettejob
Medarbejderes handlinger	Drift, sikkerhed eller dokumentation	Applikationslog og overvågning	Få driftsroller og kort opbevaring
Tekst sendt til en AI-tjeneste	Opsummere eller klassificere indhold	Backend, modeludbyder og underleverandører	Minimering, aftaler og udløb

Skriv også kilde, dataansvarlig, eventuelle databehandlere, placering, backup og den person i virksomheden, som ejer behandlingen. Et simpelt regneark kan være nok til at skabe overblik, hvis det vedligeholdes og hænger sammen med appens faktiske kode og konfiguration.

Placér ansvaret hos virksomheden og leverandørerne

Den dataansvarlige bestemmer hvorfor og hvordan personoplysninger behandles. En databehandler behandler dem på den dataansvarliges vegne. Rollen afgøres af den faktiske behandling – ikke af hvad leverandøren kalder sig i salgsmaterialet.

Virksomheden: Beslut formål, behandlingsgrundlag, datatyper, adgang, slettefrister og håndtering af rettigheder.
Appens ejer: Hold dataoversigten, risikovurderingen og procedurerne ajour, når funktioner eller leverandører ændres.
Cloud- og SaaS-leverandører: Afklar rolle, databehandleraftale, underdatabehandlere, placering, sikkerhed og hvad der sker med data ved opsigelse.

Datatilsynet understreger, at den dataansvarlige skal have overblik over hele leverandørkæden. En kontrakt med den nærmeste cloudleverandør fjerner derfor ikke behovet for at forstå underdatabehandlere og eventuelle overførsler til tredjelande.

Knyt hvert felt til et sagligt formål

GDPR kræver blandt andet lovlighed, gennemsigtighed, formålsbegrænsning, dataminimering, rigtighed, opbevaringsbegrænsning og fortrolighed. Oversat til appen betyder det, at hvert felt og hver integration skal have en begrundelse, som også passer til den måde oplysningerne senere bruges på.

Spørg “hvorfor?” til hvert felt: Fjern oplysninger, som blot er “rare at have”, eller gør dem frivillige, hvis formålet tillader det.
Vælg ikke samtykke automatisk: Der findes flere behandlingsgrundlag. Grundlaget skal passe til det konkrete formål og kunne forklares.
Genbrug ikke data ubemærket: Data indsamlet til drift må ikke bare bruges til et nyt, uforeneligt formål, fordi appen teknisk kan.
Gør informationen forståelig: Brugeren skal kunne se, hvem der behandler hvad, hvorfor, hvor længe og med hvilke rettigheder.

Byg databeskyttelsen ind i standarderne

Databeskyttelse gennem design betyder, at beskyttelsen indarbejdes, når systemet og behandlingen udformes. Standardindstillingerne bør kun gøre de personoplysninger tilgængelige og aktive, som er nødvendige for formålet.

I brugerfladen

• Skjul ikke-valgte delinger som standard
• Vis kun nødvendige felter og historik
• Gør rettelse, eksport og sletning håndterbar

I backend og drift

• Begræns adgang ved API og data
• Undgå persondata i logs og prompts
• Krypter og pseudonymisér, hvor det reducerer risiko

Testmiljøer kræver samme omtanke. Kopiér ikke produktionsdata til udvikling, AI-chat eller fejlrapporter af bekvemmelighed. Brug syntetiske data eller en kontrolleret, dokumenteret anonymisering, når realistiske datasæt er nødvendige.

Sletning skal virke i data – ikke kun på skærmen

En knap, der skjuler en post, er ikke nødvendigvis en reel sletning. Datatilsynet fremhæver, at oplysninger som stadig kan tilgås via databasen eller af en administrator, ikke er slettet. Fastlæg derfor frister efter formål og relevant lovgivning, og afprøv proceduren på tværs af alle kopier.

1. Find alle kopier. Database, filer, søgeindeks, logs, analyseværktøjer, integrationer, eksportfiler og backups.
2. Skeln mellem sletning og anonymisering. Data er kun anonymiseret, hvis personen ikke længere kan identificeres med rimelige midler.
3. Automatisér hvor det er forsvarligt. Kør slettejob efter dokumenterede frister, og log resultatet uden at skabe en ny kopi af persondata.
4. Kontrollér bagefter. Udtræk eller stikprøver skal kunne afsløre poster, som burde være væk.
5. Håndtér gendannelse. Hvis en gammel backup gendannes, skal tidligere sletninger gennemføres igen.

Gør rettigheder til afprøvede arbejdsgange

Den dataansvarlige skal kunne håndtere blandt andet oplysning, indsigt, rettelse og – når betingelserne er opfyldt – sletning eller dataportabilitet. Appen behøver ikke altid selvbetjening til alt, men virksomheden skal kunne finde den rigtige person, samle relevante data og gennemføre beslutningen sikkert.

Modtagelse: Aftal én kanal og en ansvarlig, så henvendelsen ikke bliver liggende i en privat indbakke.
Identitet: Kontrollér den anmodende uden at indsamle flere oplysninger end nødvendigt.
Søgning: Find data på tværs af app, integrationer, filer og leverandører – ikke kun i brugerprofilen.
Udlevering: Beskyt andre personers data, interne secrets og selve overførslen.
Dokumentation: Registrér anmodning, vurdering og resultat uden at kopiere hele datasættet til et nyt arkiv.

Afprøv én ufarlig indsigt, rettelse og sletning før rigtige brugere bliver afhængige af appen. En procedure, der kun virker ved direkte databaseadgang fra den oprindelige udvikler, er en driftsrisiko.

Vurdér risikoen for mennesker – ikke kun for serveren

Behandlingssikkerhed skal passe til risikoen. Vurdér hvad tab af fortrolighed, integritet eller tilgængelighed kan betyde for de personer, oplysningerne handler om. Det kan eksempelvis være identitetstyveri, diskrimination, økonomisk tab, tab af fortrolighed eller at en nødvendig tjeneste ikke kan bruges.

Scenarie: Hvad kan konkret gå galt – forkert kunde ser data, eksport sendes forkert, konto overtages eller data går tabt?
Konsekvens og sandsynlighed: Hvem rammes, hvor alvorligt og hvor let kan hændelsen ske?
Kontrol: Hvilken teknisk eller organisatorisk foranstaltning reducerer risikoen, og hvordan ved I, at den virker?

Hvis en type behandling sandsynligvis indebærer høj risiko for personers rettigheder og frihedsrettigheder, kan en konsekvensanalyse vedrørende databeskyttelse – en DPIA – være påkrævet før behandlingen. Brug Datatilsynets værktøjer til den konkrete vurdering.

Forbered sikkerhedsbrud før de sker

Et brud er ikke kun datalæk. Utilsigtet sletning, tab, ændring, uautoriseret videregivelse eller adgang kan også være et brud på persondatasikkerheden. Lav en kort procedure med kontaktvej, ansvar, bevisbevaring, begrænsning af skade og risikovurdering.

Den dataansvarlige skal anmelde et brud til Datatilsynet uden unødig forsinkelse og om muligt inden 72 timer, medmindre det er usandsynligt, at bruddet medfører risiko for personers rettigheder eller frihedsrettigheder. Fristen er derfor ikke en grund til at vente på en fuld teknisk analyse; eskalér mistanken med det samme.

Typiske fejl i AI-byggede apps

Privatlivspolitikken er dataoversigten: Teksten nævner brede kategorier, men ingen kan pege på de konkrete tabeller, logs, integrationer og backups.
Alt bygger på samtykke: Appen viser en afkrydsning uden at vurdere, om samtykke er det rigtige og reelt frivillige grundlag.
AI-prompts glemmes: Kunde- eller medarbejderdata sendes til en modeludbyder uden minimering, aftaler eller overblik over leverandørkæden.
Sletning er soft delete: Rækken skjules i brugerfladen, men ligger fortsat søgbar i database, logs, filer og integrationer.
Test bruger produktion: Udviklere får brede adgange, og rigtige data kopieres til laptops, preview-miljøer eller fejlrapporter.
Ingen ejer henvendelser og brud: Tekniske og juridiske vurderinger starter for sent, fordi beskeden ikke har en aftalt modtager.

Tjekliste før medarbejdere eller kunder bruger appen

☐ Dataflowet dækker formularer, database, filer, logs, analyse, integrationer, AI-tjenester, eksport og backup.
☐ Hvert felt har et dokumenteret formål, et vurderet behandlingsgrundlag og en ansvarlig.
☐ Unødvendige personoplysninger er fjernet fra standardindstillinger, logs, prompts og testdata.
☐ Dataansvarlig, databehandlere, underdatabehandlere, placering og eventuelle tredjelandsoverførsler er afklaret.
☐ Adgang, sikkerhed og leverandørvalg hænger sammen med en dokumenteret risikovurdering.
☐ Slettefrister og slettejob dækker alle relevante systemer og bliver kontrolleret.
☐ Indsigt, rettelse, eksport og sletning er afprøvet som samlede arbejdsgange.
☐ Privatlivsinformationen beskriver den faktiske app og opdateres ved væsentlige ændringer.
☐ Mistanke om sikkerhedsbrud har en tydelig kontaktvej, ansvarlig og procedure.
☐ Behovet for en DPIA og konkret juridisk rådgivning er vurderet efter behandlingens risiko.

Relaterede guides

Roller og rettigheder til funktioner og data Logning uden unødige persondata Backup, gendannelse og slettede oplysninger API-sikkerhed ved input og dataudlevering Se hele guidebiblioteket

Når overblikket skal passe til den faktiske app

Startklar er relevant, hvis appen allerede virker, men dataflow, leverandører, rettigheder, sletning og driftsansvar stadig ligger spredt i kode, konti og AI-chats. Vi kan gennemgå den konkrete løsning og omsætte hullerne til en prioriteret, dokumenteret plan uden at tvinge appen over på en bestemt teknologistak.

Se Startklar-forløbet

Officielle kilder

Guiden er kontrolleret mod Datatilsynets aktuelle vejledning og den danske tekst af GDPR. Brug altid den konkrete behandling og den seneste officielle vejledning som grundlag for beslutninger.