Samtykke og retten til å bli glemt

🌐 Finnes også på 28 språk

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 · Dansk · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bildet er laget med KI

Oversatt med KI. Fellesskapet har ikke gjennomgått oversettelsen ennå. Les på engelsk

Modul 5 av 6 i kapitlet Datakvalitet og styring, kapittel 5 i kurset Data Architect. Hver modul står på egne ben. Forrige: Personvernlover former designet · Neste: Beskytt, oppbevar og bevis

Spørsmålet denne modulen besvarer: Hvordan designer du for samtykke, og for å slette en person?

Steve Trucking har telefonnummeret til en mottaker. Enkelt spørsmål: kan vi sende dem en SMS? Kanskje. Om dagens levering? Morgendagens? Kan vi bruke nummeret til en kampanje? Hva om de sa nei til SMS, eller ja til leveringsoppdateringer, men nei til markedsføring, og så ombestemte seg?

Så den andre retningen. Mottakeren sier: slett personopplysningene mine. Hvor er de? I Salesforce, sannsynligvis, men vi har lært at det ikke er hele svaret. De kom fra en detaljhandelspartner. De kan ligge i en kundedataplattform, i felthistorikk, i et arkiv, i et leveringsnotat, i en eksport, i en integrasjonslogg, i en agents samtale. Samtykke og sletting høres ut som policyspørsmål, men til slutt må systemet svare på dem. Det er arkitektur.

Samtykke er data

Det første prinsippet: samtykke er data. Ikke reduser det til Has_Opted_In__c = true. Det egentlige spørsmålet er aldri bare «samtykket de?». Det er samtykke til hva, gjennom hvilken kanal, på hvilken adresse eller hvilket nummer, til hvilket formål, når, har det endret seg, og kan vi bevise det? Hvis virksomheten tar beslutninger ut fra de svarene, må de lagres som strukturerte data. Et avsnitt i en personvernerklæring er ikke nok, og det er heller ikke en avkrysningsboks i et nettskjema: avkrysningsboksen fanger opp en hendelse; arkitekturen må ta vare på hva hendelsen betyr.

Bruk modellen Salesforce allerede har bygd

Mitt standpunkt: bruk den innebygde samtykkemodellen der du kan, i stedet for å bygge det samme på nytt i egendefinerte felt. Samtykkedatamodellen i Salesforce håndterer samtykke på fire nivåer, og hvert av dem er et mer spesifikt spørsmål (Understand the Salesforce Consent Data Model (opens in a new tab)):

• Globalt samtykke, på enkeltpersonen (Individual): hvem er denne personen, og har personen sagt nei til alt?
• Samtykke per kanaltype (Contact Point Type Consent): kan vi bruke denne typen kanal, som SMS eller e-post?
• Samtykke per kontaktpunkt: hva med akkurat dette telefonnummeret eller denne e-postadressen?
• Formål med databruken (Data Use Purpose): av hvilken grunn: leveringsvarsler, service, markedsføring?

Satt sammen kan arkitekturen svare på «kan vi bruke opplysningene om denne personen, gjennom dette kontaktpunktet, til dette formålet?», og det er langt mer nyttig enn «samtykke = ja». Enhver post som er knyttet til en enkeltperson, kan være med: kundeemner, kontakter, personkontoer, brukere.

Click to enlarge

Fire spørsmål, hvert smalere enn det forrige. Ett enkelt samtykkeflagg svarer ikke godt på noen av dem.

Formålet betyr noe

En detaljhandelspartner sender Steve Trucking telefonnummeret til en mottaker slik at teamet kan koordinere leveringen. Det gjør ikke mottakeren til et kundeemne for markedsføring. De samme dataene kan ha forskjellige tillatte bruksområder: koordinering av levering, oppfølging fra service, markedsføring, KI-personalisering. Hvis policyen eller loven behandler dem forskjellig, må modellen kunne skille dem fra hverandre. Spørsmålet er ikke har vi telefonnummeret? Det er hva har vi lov til å gjøre med det?

Og samtykke er ikke alltid behandlingsgrunnlaget. Noen bruksområder hviler på andre grunnlag loven gir, og det er juridisk avdelings vurdering. Ikke bygg en arkitektur som antar at hver personvernbeslutning er en avkrysningsboks for samtykke. Støtt det policyen sier: hvis en bruk avhenger av samtykke, modeller og håndhev samtykke; hvis et annet grunnlag gjelder, lagre likevel det som trengs for å avgjøre om bruken er tillatt.

Samtykke har en livssyklus og en autoritet

Folk gir samtykke, trekker det tilbake, endrer preferanser, bytter nummer. Virksomheten legger til nye formål; lover endres. Så design livssyklusen: hva som ble valgt, når, hvordan, til hvilket formål, og hva som skjer når samtykket trekkes tilbake. Og det er her det blir interessant: når en mottaker trekker tilbake samtykket, vet Salesforce det. Vet meldingsplattformen det? Analysen? Agenten? Samtykke som bor i ett system mens andre handler på utdatert tillatelse, er ikke mye til kontroll.

Det betyr å spørre hvilket system som er autoritativt for samtykke. Salesforce, en preferanseplattform, noe annet? Uansett svar: ikke la fem systemer hver for seg avgjøre om samme person har godtatt samme bruk. Samtykke trenger det alle styrte data trenger: en eier, en autoritativ post, en måte å synkronisere på, og håndheving.

Så sier personen: glem meg

Det første instinktet er å slette kontakten og si seg ferdig. Men personens data kan ligge på en kontakt, en levering, et leveringsnotat, en sak, et bilde, i felthistorikk, i Snowflake, i et arkiv, en integrasjonslogg, en søkeindeks eller en agents samtalehistorikk. Derfor starter standpunktet mitt om sletting tidligere: sletting er sjelden og vanskelig i praksis, så kontroller først hvor personopplysningene havner. Design slik at de havner på så få steder som mulig. Når en forespørsel så kommer, tilslør eller frakoble dem der det oppfyller policyen, og spor opp hver kopi: felthistorikk, arkiver, Data 360, og nå også søkeindekser og agentsamtaler.

Ikke start jakten når forespørselen kommer. Da er det for sent å begynne å forstå landskapet. Ordboken, opphavet og klassifiseringen fra modul 3 var ikke papirarbeid; det er de som gjør dette mulig. Du vet allerede hvilke felt som har personopplysninger, og hvor kopiene ble av.

Click to enlarge

En glem-meg-forespørsel er en beslutning for hver kopi.

Klokken går

Disse forespørslene kommer med frister. Etter personvernforordningen (GDPR) må virksomheten behandle en persons anmodning uten ugrunnet opphold og senest én måned etter at anmodningen er mottatt; for sammensatte eller mange anmodninger kan fristen forlenges med ytterligere to måneder, men personen må få beskjed innen den første måneden, med begrunnelse (artikkel 12 nr. 3, Regulation (EU) 2016/679 (opens in a new tab)). Andre lover setter sine egne frister; juridisk avdeling forteller deg hvilke som gjelder. Uansett er en måned ikke lang nok tid til å oppdage landskapet. Det er fristen kartet over kopiene må slå.

Slette, avidentifisere eller oppbevare?

En forespørsel betyr ikke nødvendigvis at alt overalt forsvinner. Noen poster må eller kan oppbevares; noen operative poster kan bli liggende, men slutte å identifisere personen; noen data kan avidentifiseres. Gjeldende policy og lov avgjør; arkitekturen støtter hvert utfall, sted for sted: slett dem, avidentifiser dem, eller oppbevar dem etter et godkjent krav (og hvem kan da se dem, hvor lenge, og hvorfor?).

Husk skillet fra modul 4. Frakobling teller som å glemme bare når personen ikke med rimelighet kan identifiseres igjen. Pseudonymiserte opplysninger er fortsatt personopplysninger. Ikke bruk tilsløring som en snarvei rundt et rettslig krav.

Du kan ikke slette det du ikke finner

Før du kan slette noen, må du finne dem. Forespørselen kommer fra en e-postadresse. Én detaljhandelspartner sendte «Jane Smith», en annen «J. Smith», og telefonnummeret er endret. Mottakeren er ikke en kontakt i det hele tatt; opplysningene ligger på hver levering. Den samme personen har fått leveringer for to forskjellige partnere. Ett system kjenner personen ved e-post, et annet ved en ekstern ID. Sletting avhenger av identitet, og du vil ikke slette noen andres data fordi matchingen din var for aggressiv. Identitetsarkitektur er en del av personvernarkitekturen.

Steve Trucking gjør det enda vanskeligere. Én detaljhandelspartner skal aldri se en annens leveringer eller mottakere. Hvis samme person har mottatt leveringer for to partnere, må driften holde de relasjonene atskilt, mens personvernet likevel kan trenge å finne personen på tvers av begge. Ikke løs personvernet ved å bryte sikkerhetsgrensen, og ikke beskytt grensen ved å gjøre personvernforespørsler umulige. Arkitekturen må gjøre begge deler.

Bilder og fritekst er også data

Det er lett å tenke på personvern som felt: navn, e-post, telefon, adresse. Men Steve Trucking tar millioner av leveringsbilder i året, og noen viser mennesker eller innsiden av et hjem. En policy for oppbevaring eller sletting som bare ser på strukturerte felt, er ufullstendig; det er også en som overser filer, dokumenter, transkripsjoner, logger og KI-ledetekster og -svar.

Og fritekst er farlig. Du fjerner navnet, telefonen og adressen, og finner så dette leveringsnotatet: «Ring Jane på 602-555-0198. Portkode 4821. Hunden er i hagen.» Der er det. Å klassifisere leveringsnotater som sensitive forteller deg at det kan være et problem; det finner og fjerner ikke personopplysningene inne i teksten. Noen ganger er det beste svaret å hindre at unødvendige personopplysninger havner der i det hele tatt. Kontroller først hvor personopplysningene havner.

Privacy Center er et verktøy, ikke hele arkitekturen

Privacy Center i Salesforce hjelper deg å kjøre disse prosessene. Policyene for retten til å bli glemt bygges per objekt, for å fange opp alt du vil ha fjernet, og kjøres mot en bestemt kundepost (Delete Data with Right to Be Forgotten Policies (opens in a new tab)). Det er nyttig. Men «vi kjøpte Privacy Center, så vi er ferdige» er ikke en arkitektur. Personens data kan ligge utenfor rekkevidden til ett enkelt verktøy: Data 360, datavarehuset, partnersystemer, arkiver, logger, søk, filer, agentsamtaler. Virksomheten trenger fortsatt et svar for hele virksomheten, og du må sjekke hva hvert verktøy faktisk dekker før du stoler på det.

Dataportabilitet og bevis

Noen lover gir også folk rett til å få en kopi av dataene sine. Legg merke til at det er det samme letingsproblemet: sletting spør hvor er dataene til denne personen, slik at vi kan handle på dem? Dataportabilitet spør hvor er de, slik at vi kan utlevere dem? Begge hviler på identitet, klassifisering, opphav, systemoversikten og eierskap.

Og så: hvordan beviser du at du gjorde det? Forespørsel mottatt, identitet bekreftet, systemer gjennomsøkt, tiltak utført, unntak registrert, oppbevarte data begrunnet, fullføring logget. Det er en reell spenning her: du fjerner noens personopplysninger samtidig som du tar vare på nok dokumentasjon til å vise at du behandlet forespørselen riktig. Det er nettopp derfor arkitekter ikke skal finne på oppbevaringsregler på egen hånd. Juridisk og compliance avgjør hvilken dokumentasjon som må bli igjen; arkitekturen tar vare på den uten å ta vare på dataene som skulle fjernes.

Utover eksamen: hva KI endrer. KI skaper nye formål og nye kopier. Tillatelse til å bruke data for å levere en tjeneste dekker ikke automatisk grounding av en agent, personalisering eller trening; Data Use Purpose er det naturlige stedet å skille dem fra hverandre. Og personopplysninger kan overleve i ledetekster, grounding-kontekst, samtaler, sammendrag, søke- og vektorindekser og logger. «Vi slettet kildeposten» er ikke et fullstendig svar hvis KI-laget fortsatt husker.

Hva en arkitekt bestemmer her

• Hvordan samtykke og tillatt bruk modelleres, slik at systemene kan svare på hvem, hvilken kanal, hvilket kontaktpunkt og hvilket formål.
• Hvilket system som er autoritativt for samtykke, og hvordan tilbaketrekkinger når hvert system som handler på det.
• Hvor personopplysninger kan spre seg: felt, fritekst, filer, historikk, analyse, arkiver, integrasjoner, søk og KI.
• Hvordan en forespørsel finner riktig person og utløser sletting, avidentifisering eller godkjent oppbevaring på hvert sted.
• Hvilken dokumentasjon som blir igjen for å bevise at samtykke og personvernforespørsler ble håndtert.

Samtykke og sletting ser ut som motsetninger (kan vi bruke disse dataene? kan vi stoppe og fjerne dem?), men de hviler på det samme grunnlaget: identitet, formål, klassifisering, opphav, eierskap, håndheving og dokumentasjon. Bruk standardmodellen for samtykke, kontroller hvor personopplysningene havner, vit hvor kopiene er, og design slettingsprosessen før den første forespørselen kommer. Når noen spør «kan dere glemme meg?», trenger arkitekturen et bedre svar enn «vi tror det».

Les mer

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