Samtykke og retten til at blive glemt

🌐 Findes også på 28 sprog

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Billedet er lavet med AI

Oversat med AI. Fællesskabet har endnu ikke gennemgået oversættelsen. Læs på engelsk

Modul 5 af 6 i kapitlet Datakvalitet og styring, kapitel 5 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Privatlivslove former designet · Næste: Beskyt, opbevar og bevis

Spørgsmålet, dette modul besvarer: Hvordan designer du til samtykke, og til at slette en person?

Steve Trucking har en modtagers telefonnummer. Enkelt spørgsmål: Må vi sende en sms? Måske. Om dagens levering? Morgendagens? Må vi bruge nummeret til en kampagne? Hvad hvis modtageren sagde nej til sms’er, eller ja til leveringsopdateringer men nej til markedsføring, og så ombestemte sig?

Nu den anden retning. Modtageren siger: Slet mine personoplysninger. Hvor er de? I Salesforce, sandsynligvis, men vi har lært, at det ikke er hele svaret. De kom fra en detailpartner. De kan ligge i en kundedataplatform, felthistorik, et arkiv, en leveringsnote, en eksport, en integrationslog, en agents samtale. Samtykke og sletning lyder som politikspørgsmål, men på et tidspunkt skal systemet besvare dem. Det er arkitektur.

Samtykke er data

Det første princip: Samtykke er data. Reducér det ikke til Has_Opted_In__c = true. Det rigtige spørgsmål er aldrig bare »gav de samtykke?« Det er samtykke til hvad, via hvilken kanal, på hvilken adresse eller hvilket nummer, til hvilket formål, hvornår, har det ændret sig, og kan vi bevise det? Hvis forretningen træffer beslutninger ud fra de svar, skal de gemmes som strukturerede data. Et afsnit i en privatlivspolitik er ikke nok, og det er et afkrydsningsfelt på en webformular heller ikke: Afkrydsningsfeltet fanger en hændelse; arkitekturen skal bevare, hvad hændelsen betyder.

Brug den model, Salesforce allerede har bygget

Min holdning: Brug den indbyggede samtykkemodel, hvor du kan, i stedet for at bygge det samme igen i brugerdefinerede felter. Salesforces datamodel for samtykke håndterer samtykke på fire niveauer, hver et mere specifikt spørgsmål (Understand the Salesforce Consent Data Model (opens in a new tab), på engelsk):

• Globalt samtykke, på Individual (individet): Hvem er denne person, og har personen sagt nej til alt?
• Samtykke pr. kanal (Contact Point Type Consent): Må vi bruge denne type kanal, for eksempel sms eller e-mail?
• Samtykke pr. kontaktpunkt (Contact Point Consent): Hvad med netop dette telefonnummer eller denne e-mailadresse?
• Formål med databrugen (Data Use Purpose): Af hvilken grund: leveringsbeskeder, service, markedsføring?

Sat sammen kan arkitekturen svare på »må vi bruge denne persons oplysninger, via dette kontaktpunkt, til dette formål?«, og det er langt mere nyttigt end »samtykke = ja«. Enhver post, der vedrører et individ, kan indgå: kundeemner, kontakter, personkonti, brugere.

Click to enlarge

Fire spørgsmål, hvert snævrere end det forrige. Et enkelt opt-in-flag besvarer ingen af dem godt.

Formålet betyder noget

En detailpartner sender Steve Trucking en modtagers nummer, så teamet kan koordinere leveringen. Det gør ikke modtageren til et markedsføringsemne. De samme data kan have forskellige tilladte anvendelser: koordinering af levering, opfølgning på service, markedsføring, personalisering med AI. Hvis politikken eller loven behandler dem forskelligt, skal modellen kunne skelne mellem dem. Spørgsmålet er ikke: Har vi telefonnummeret? Det er: Hvad har vi lov til at gøre med det?

Og samtykke er ikke altid retsgrundlaget. Nogle anvendelser hviler på andre grundlag, som loven giver, og det er juras afgørelse. Byg ikke en arkitektur, der antager, at hver beslutning om databeskyttelse er et opt-in-afkrydsningsfelt. Understøt det, politikken siger: Hvis en anvendelse afhænger af samtykke, så modellér og håndhæv samtykke; hvis et andet grundlag gælder, så gem stadig det, der skal til for at afgøre, om anvendelsen er tilladt.

Samtykke har en livscyklus og en autoritet

Folk giver samtykke, trækker det tilbage, ændrer præferencer, skifter numre. Forretningen tilføjer nye formål; lovene ændrer sig. Så design livscyklussen: hvad der blev valgt, hvornår, hvordan, til hvilket formål, og hvad der sker, når samtykket trækkes tilbage. Og her bliver det interessant: Når en modtager trækker sit samtykke tilbage, ved Salesforce det. Ved beskedplatformen det? Analyserne? Agenten? Samtykke, der bor i ét system, mens andre handler på en forældet tilladelse, er ikke meget af en kontrol.

Det betyder, at du skal spørge, hvilket system der er autoritativt for samtykke. Salesforce, en præferenceplatform, et andet sted? Uanset svaret, så lad ikke fem systemer afgøre hver for sig, om den samme person har sagt ja til den samme anvendelse. Samtykke har brug for det samme som alle andre styrede data: en ejer, en autoritativ post, en måde at synkronisere på og håndhævelse.

Nu siger personen: Glem mig

Det første instinkt er at slette kontakten og kalde det færdigt. Men personens data kan ligge på en kontakt, en levering, en leveringsnote, en sag, et foto, i felthistorikken, i Snowflake, i et arkiv, en integrationslog, et søgeindeks eller en agents samtalehistorik. Derfor starter min holdning til sletning tidligere: Sletning er sjælden og svær i praksis, så styr først, hvor personoplysningerne havner. Design, så de lander så få steder som muligt. Når der så kommer en anmodning, så slør eller afkobl dem, hvor det opfylder politikken, og find hver kopi: felthistorik, arkiver, Data 360 og nu også søgeindekser og agentsamtaler.

Start ikke jagten, når anmodningen kommer. Så er det for sent at begynde at forstå landskabet. Ordbogen, dataoprindelsen og klassifikationen fra modul 3 var ikke papirarbejde; de er det, der gør det muligt. Du ved allerede, hvilke felter der rummer personoplysninger, og hvor kopierne tog hen.

Click to enlarge

En anmodning om at blive glemt er en beslutning for hver kopi.

Uret tikker

Disse anmodninger kommer med frister. Efter GDPR (databeskyttelsesforordningen) skal organisationen reagere på en persons anmodning uden unødig forsinkelse og senest en måned efter modtagelsen af anmodningen; ved komplekse eller mange anmodninger kan fristen forlænges med yderligere to måneder, men personen skal have besked inden for den første måned med angivelse af grundene (artikel 12, stk. 3, i forordning (EU) 2016/679 (opens in a new tab)). Andre love fastsætter deres egne frister; jura fortæller dig, hvilke der gælder. Under alle omstændigheder er en måned ikke lang nok til at opdage landskabet. Det er den frist, kortet over kopierne skal slå.

Slette, afidentificere eller opbevare?

En anmodning betyder ikke nødvendigvis, at alt forsvinder overalt. Nogle poster skal eller må opbevares; nogle driftsposter kan blive, men holde op med at identificere personen; nogle data kan afidentificeres. Den gældende politik og lov afgør det; arkitekturen understøtter hvert udfald, sted for sted: slet det, afidentificér det, eller opbevar det under et godkendt krav (og hvem må så se det, hvor længe og hvorfor?).

Husk skelnen fra modul 4. Afkobling tæller kun som at glemme, når personen ikke med rimelighed kan identificeres igen. Pseudonymiserede data er stadig personoplysninger. Brug ikke sløring som en genvej uden om et lovkrav.

Du kan ikke slette det, du ikke kan finde

Før du kan slette nogen, skal du finde dem. Anmodningen kommer fra en e-mailadresse. Én detailpartner sendte »Jane Smith«, en anden »J. Smith«, og telefonnummeret er ændret. Modtageren er slet ikke en kontakt; oplysningerne ligger på hver levering. Den samme person har fået leveringer for to forskellige partnere. Ét system kender personen på e-mail, et andet på et eksternt id. Sletning afhænger af identitet, og du vil ikke slette en andens data, fordi din matchning var for aggressiv. Identitetsarkitektur er en del af arkitekturen for databeskyttelse.

Steve Trucking gør det endnu sværere. Én detailpartner må aldrig se en andens leveringer eller modtagere. Hvis den samme person har modtaget leveringer for to partnere, skal driften holde de relationer adskilt, mens databeskyttelsen stadig kan have brug for at finde personen på tværs af begge. Løs ikke databeskyttelsen ved at bryde sikkerhedsgrænsen, og beskyt ikke grænsen ved at gøre anmodninger om databeskyttelse umulige. Arkitekturen skal kunne begge dele.

Fotos og fritekst er også data

Det er let at tænke på databeskyttelse som felter: navn, e-mail, telefon, adresse. Men Steve Trucking tager millioner af leveringsfotos om året, og nogle viser mennesker eller indersiden af et hjem. En opbevarings- eller sletningspolitik, der kun kigger på strukturerede felter, er ufuldstændig; det samme er en, der ignorerer filer, dokumenter, transskriptioner, logs og AI-prompts og -svar.

Og fritekst er farlig. Du fjerner navn, telefon og adresse og finder så denne leveringsnote: »Ring til Jane på 602-555-0198. Lågekode 4821. Hunden er i haven.« Dér er de. At klassificere leveringsnoter som følsomme fortæller dig, at der kan være et problem; det finder og fjerner ikke personoplysningerne inde i teksten. Nogle gange er det bedste svar at forhindre, at unødvendige personlige oplysninger overhovedet lander dér. Styr først, hvor personoplysningerne havner.

Privacy Center er et værktøj, ikke hele arkitekturen

Salesforce Privacy Center hjælper med at køre disse processer. Dens politikker for retten til at blive glemt bygges pr. objekt, så de fanger alt det, du vil have fjernet, og køres mod en bestemt kundepost (Delete Data with Right to Be Forgotten Policies (opens in a new tab), på engelsk). Det er nyttigt. Men »vi har købt Privacy Center, så vi er færdige« er ikke en arkitektur. Personens data kan ligge uden for et enkelt værktøjs rækkevidde: Data 360, datavarehuset, partnersystemer, arkiver, logs, søgning, filer, agentsamtaler. Virksomheden har stadig brug for et svar for hele virksomheden, og du skal tjekke, hvad hvert værktøj faktisk dækker, før du stoler på det.

Dataportabilitet og bevis

Nogle love giver også personer ret til at få en kopi af deres data. Læg mærke til, at det er det samme opsporingsproblem: Sletning spørger: Hvor er denne persons data, så vi kan handle på dem? Dataportabilitet spørger: Hvor er de, så vi kan udlevere dem? Begge hviler på identitet, klassifikation, dataoprindelse, oversigten over systemer og ejerskab.

Og så: Hvordan beviser du, at du gjorde det? Anmodning modtaget, identitet bekræftet, systemer gennemsøgt, handlinger udført, undtagelser registreret, opbevarede data begrundet, afslutning logget. Der er en reel spænding her: Du fjerner en persons personoplysninger, mens du bevarer nok dokumentation til at vise, at du håndterede anmodningen korrekt. Det er netop derfor, arkitekter ikke selv skal opfinde opbevaringsregler. Jura og compliance afgør, hvilken dokumentation der skal blive tilbage; arkitekturen bevarer den uden at bevare de data, der skulle fjernes.

Ud over eksamen: hvad AI ændrer. AI skaber nye formål og nye kopier. Tilladelse til at bruge data til at levere en tjeneste dækker ikke automatisk grounding af en agent, personalisering eller træning; Data Use Purpose er det naturlige sted at skelne mellem dem. Og personoplysninger kan overleve i prompts, grounding-kontekst, samtaler, opsummeringer, søge- og vektorindekser og logs. »Vi slettede kildeposten« er ikke et fuldstændigt svar, hvis AI-laget stadig husker.

Hvad en arkitekt beslutter her

• Hvordan samtykke og tilladt brug modelleres, så systemerne kan svare på hvem, hvilken kanal, hvilket kontaktpunkt og hvilket formål.
• Hvilket system der er autoritativt for samtykke, og hvordan tilbagetrækninger når frem til hvert system, der handler på det.
• Hvor personoplysninger kan sprede sig: felter, fritekst, filer, historik, analyser, arkiver, integrationer, søgning og AI.
• Hvordan en anmodning finder den rigtige person og driver sletning, afidentificering eller godkendt opbevaring hvert sted.
• Hvilken dokumentation der bliver tilbage for at bevise, at samtykke og anmodninger om databeskyttelse blev håndteret.

Samtykke og sletning ligner hinandens modsætninger (må vi bruge disse data? kan vi stoppe og fjerne dem?), men de hviler på det samme fundament: identitet, formål, klassifikation, dataoprindelse, ejerskab, håndhævelse og dokumentation. Brug standardmodellen for samtykke, styr, hvor personoplysninger havner, ved, hvor kopierne er, og design sletningsprocessen, før den første anmodning kommer. Når nogen spørger »kan I glemme mig?«, har arkitekturen brug for et bedre svar end »det tror vi«.

Læs mere

• Salesforce Help, Understand the Salesforce Consent Data Model (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab), artikel 12, stk. 3, fristen for at reagere på en anmodning (kontrolleret 2026-10-14).
• Salesforce Help, Delete Data with Right to Be Forgotten Policies (opens in a new tab) (Privacy Center) (på engelsk, kontrolleret 2026-10-14).