Samtycke och rätten att bli bortglömd

🌐 Finns även 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 · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bilden är skapad med AI

Översatt med AI. Gemenskapen har inte granskat översättningen än. Läs på engelska

Modul 5 av 6 i kapitlet Datakvalitet och styrning, kapitel 5 i kursen Data Architect. Varje modul står på egna ben. Föregående: Integritetslagar formar designen · Nästa: Skydda, bevara och bevisa

Frågan den här modulen besvarar: Hur designar du för samtycke, och för att radera en person?

Steve Trucking har en mottagares (Recipient) telefonnummer. Enkel fråga: får vi skicka sms till personen? Kanske. Om dagens leverans? Morgondagens? Får vi använda numret för en kampanj? Vad händer om personen sa nej till sms, eller ja till leveransuppdateringar men nej till marknadsföring, och sedan ändrade sig?

Nu åt andra hållet. Mottagaren säger: radera mina personuppgifter. Var finns de? I Salesforce, förmodligen, men vi har lärt oss att det inte är hela svaret. De kom från en detaljhandelspartner (Retail Partner). De kan finnas i en kunddataplattform, fälthistorik, ett arkiv, en leveransanteckning, en export, en integrationslogg, en agents konversation. Samtycke och radering låter som policyfrågor, men till slut måste systemet besvara dem. Det är arkitektur.

Samtycke är data

Den första principen: samtycke är data. Reducera det inte till Has_Opted_In__c = true. Den verkliga frågan är aldrig bara ”samtyckte personen?”. Det är samtycke till vad, via vilken kanal, till vilken adress eller vilket nummer, för vilket ändamål, när, har det ändrats, och kan vi bevisa det? Om verksamheten fattar beslut utifrån de svaren måste de lagras som strukturerade data. Ett stycke i en integritetspolicy räcker inte, och inte heller en kryssruta i ett webbformulär: kryssrutan fångar en händelse; arkitekturen måste behålla vad händelsen betyder.

Använd modellen som Salesforce redan har byggt

Min hållning: använd den färdiga samtyckesmodellen där du kan, i stället för att bygga samma sak igen i anpassade fält. Samtyckesdatamodellen i Salesforce hanterar samtycke på fyra nivåer, där varje nivå är en mer specifik fråga (Understand the Salesforce Consent Data Model (opens in a new tab)):

• Globalt samtycke, på Individual (individen): vem är den här personen, och har personen sagt nej till allt?
• Samtycke per kanal (Contact Point Type Consent): får vi använda den här typen av kanal, som sms eller e-post?
• Samtycke per kontaktpunkt (Contact Point Consent): hur är det med just det här telefonnumret eller den här e-postadressen?
• Ändamål för dataanvändning (Data Use Purpose): av vilket skäl: leveransaviseringar, service, marknadsföring?

Tillsammans kan arkitekturen svara på ”får vi använda den här personens uppgifter, via den här kontaktpunkten, för det här ändamålet?”, vilket är mycket mer användbart än ”samtycke = ja”. Varje post som hör till en individ kan vara med: leads, kontakter, personkonton, användare.

Click to enlarge

Fyra frågor, var och en snävare än den förra. En enda flagga för samtycke besvarar ingen av dem bra.

Ändamålet spelar roll

En detaljhandelspartner skickar en mottagares nummer till Steve Trucking så att teamet kan samordna leveransen. Det gör inte mottagaren till en marknadsföringslead. Samma data kan ha olika tillåtna användningar: samordning av leveranser, uppföljning i service, marknadsföring, AI-personalisering. Om policyn eller lagen behandlar dem olika måste modellen kunna skilja dem åt. Frågan är inte har vi telefonnumret? Den är vad får vi göra med det?

Och samtycke är inte alltid den rättsliga grunden. Vissa användningar vilar på andra grunder som lagen ger, och det avgör Juridik. Bygg inte en arkitektur som förutsätter att varje integritetsbeslut är en kryssruta för samtycke. Stöd vad policyn än säger: om en användning beror på samtycke, modellera och genomdriv samtycke; om en annan grund gäller, lagra ändå det som behövs för att avgöra om användningen är tillåten.

Samtycke har en livscykel och en auktoritet

Människor ger samtycke, återkallar det, ändrar sina val, byter nummer. Verksamheten lägger till nya ändamål; lagar ändras. Så designa livscykeln: vad som valdes, när, hur, för vilket ändamål, och vad som händer vid återkallelse. Och här blir det intressant: när en mottagare återkallar sitt samtycke vet Salesforce om det. Vet meddelandeplattformen det? Analysen? Agenten? Samtycke som bor i ett system medan andra agerar på inaktuell tillåtelse är ingen vidare kontroll.

Det innebär att fråga vilket system som är auktoritativt för samtycke. Salesforce, en plattform för preferenser, något annat? Vad svaret än är, låt inte fem system var för sig avgöra om samma person har gått med på samma användning. Samtycke behöver det som alla styrda data behöver: en ägare, en auktoritativ post, ett sätt att synka och genomdrivande.

Nu säger personen: glöm mig

Den första instinkten är att radera kontakten och säga att det är klart. Men personens uppgifter kan finnas på en kontakt, en leverans, en leveransanteckning, ett ärende, ett foto, i fälthistoriken, i Snowflake, i ett arkiv, en integrationslogg, ett sökindex eller en agents konversationshistorik. Därför börjar min hållning om radering tidigare: radering är i praktiken ovanlig och svår, så kontrollera först vart personuppgifterna tar vägen. Designa så att de hamnar på så få ställen som möjligt. När en begäran sedan kommer, fördunkla (obfuscate) eller koppla bort dem där det uppfyller policyn, och leta upp varje kopia: fälthistorik, arkiv, Data 360, och nu även sökindex och agentkonversationer.

Börja inte leta när begäran kommer. Då är det för sent att börja förstå landskapet. Ordlistan, härkomsten och klassificeringen i modul 3 var inte pappersarbete; det är de som gör det här möjligt. Du vet redan vilka fält som innehåller personuppgifter och vart kopiorna tog vägen.

Click to enlarge

En begäran om att bli glömd är ett beslut för varje kopia.

Klockan tickar

De här begärandena kommer med tidsfrister. Enligt dataskyddsförordningen (GDPR) måste organisationen hantera en persons begäran utan onödigt dröjsmål och senast en månad efter att ha tagit emot den; vid komplicerade eller många begäranden kan den tiden förlängas med ytterligare två månader, men personen måste informeras inom den första månaden, med skälen (artikel 12.3, Regulation (EU) 2016/679 (opens in a new tab)). Andra lagar sätter sina egna tidsfrister; Juridik talar om vilka som gäller. Hur som helst räcker en månad inte för att upptäcka landskapet. Det är tidsfristen som kartan över kopiorna måste slå.

Radera, avidentifiera eller behålla?

En begäran betyder inte nödvändigtvis att allt försvinner överallt. Vissa poster måste eller får sparas; vissa operativa poster kan stanna kvar men sluta identifiera personen; vissa data kan avidentifieras. Tillämplig policy och lag avgör; arkitekturen stöder varje utfall, plats för plats: radera, avidentifiera eller behåll enligt ett godkänt krav (och vem får då se uppgifterna, hur länge, varför?).

Kom ihåg skillnaden från modul 4. Att koppla bort uppgifter räknas som att glömma bara när personen inte rimligen kan identifieras igen. Pseudonymiserade uppgifter är fortfarande personuppgifter. Använd inte fördunkling som en genväg runt ett rättsligt krav.

Du kan inte radera det du inte hittar

Innan du kan radera någon måste du hitta personen. Begäran kommer från en e-postadress. En detaljhandelspartner skickade ”Jane Smith”, en annan ”J. Smith”, och telefonnumret har ändrats. Mottagaren är inte ens en kontakt; uppgifterna ligger på varje leverans. Samma person fick leveranser för två olika partner. Ett system känner personen via e-post, ett annat via ett externt ID. Radering beror på identitet, och du vill inte radera någon annans uppgifter för att din matchning var för aggressiv. Identitetsarkitektur är en del av integritetsarkitekturen.

Steve Trucking gör det ännu svårare. En detaljhandelspartner får aldrig se en annans leveranser eller mottagare. Om samma person tog emot leveranser för två partner måste driften hålla de relationerna isär, medan integriteten ändå kan behöva hitta personen i båda. Lös inte integriteten genom att bryta säkerhetsgränsen, och skydda inte gränsen genom att göra integritetsbegäranden omöjliga. Arkitekturen måste klara båda.

Foton och fritext är också data

Det är lätt att tänka på integritet som fält: namn, e-post, telefon, adress. Men Steve Trucking tar miljontals leveransfoton om året, och en del visar människor eller insidan av ett hem. En policy för lagringstid eller radering som bara tittar på strukturerade fält är ofullständig; det är också en som ignorerar filer, dokument, transkriptioner, loggar och AI-prompter och AI-svar.

Och fritext är farlig. Du tar bort namnet, telefonnumret och adressen, och hittar sedan den här leveransanteckningen: ”Ring Jane på 602-555-0198. Portkod 4821. Hunden är på gården.” Där är de. Att klassificera leveransanteckningar som känsliga säger dig att det kan finnas ett problem; det hittar och tar inte bort personuppgifterna i texten. Ibland är det bästa svaret att över huvud taget stoppa onödiga personuppgifter från att hamna där. Kontrollera först vart personuppgifterna tar vägen.

Privacy Center är ett verktyg, inte hela arkitekturen

Privacy Center i Salesforce hjälper till att driva de här processerna. Dess policyer för rätten att bli bortglömd byggs per objekt, för att fånga allt du vill ta bort, och körs mot en specifik kundpost (Delete Data with Right to Be Forgotten Policies (opens in a new tab)). Det är användbart. Men ”vi köpte Privacy Center, så vi är klara” är ingen arkitektur. Personens uppgifter kan bo utanför räckhåll för ett enskilt verktyg: Data 360, datalagret, partnersystem, arkiv, loggar, sökning, filer, agentkonversationer. Företaget behöver fortfarande ett svar för hela företaget, och du behöver kontrollera vad varje verktyg faktiskt täcker innan du förlitar dig på det.

Dataportabilitet och bevis

Vissa lagar ger också människor rätt att få en kopia av sina uppgifter. Lägg märke till att det är samma upptäcktsproblem: radering frågar var finns den här personens uppgifter, så att vi kan agera på dem? Dataportabilitet frågar var finns de, så att vi kan lämna ut dem? Båda vilar på identitet, klassificering, härkomst, systeminventeringen och ägarskap.

Och sedan: hur bevisar du att du gjorde det? Begäran mottagen, identitet verifierad, system genomsökta, åtgärder vidtagna, undantag registrerade, sparade uppgifter motiverade, slutförandet loggat. Det finns en verklig spänning här: du tar bort någons personuppgifter samtidigt som du behåller tillräckligt med bevis för att visa att du hanterade begäran korrekt. Det är just därför arkitekter inte ska hitta på regler för lagringstid på egen hand. Juridik och compliance avgör vilka bevis som måste finnas kvar; arkitekturen behåller dem utan att behålla de uppgifter som skulle tas bort.

Bortom provet: vad AI ändrar. AI skapar nya ändamål och nya kopior. Tillåtelse att använda data för att tillhandahålla en tjänst täcker inte automatiskt grounding för en agent, personalisering eller träning; Data Use Purpose är den naturliga platsen att skilja dem åt. Och personuppgifter kan överleva i prompter, groundingkontext, konversationer, sammanfattningar, sök- och vektorindex och loggar. ”Vi raderade källposten” är inget fullständigt svar om AI-lagret fortfarande minns.

Vad en arkitekt bestämmer här

• Hur samtycke och tillåten användning modelleras, så att system kan svara på vem, vilken kanal, vilken kontaktpunkt och vilket ändamål.
• Vilket system som är auktoritativt för samtycke, och hur återkallelser når varje system som agerar på det.
• Vart personuppgifter kan spridas: fält, fritext, filer, historik, analys, arkiv, integrationer, sökning och AI.
• Hur en begäran hittar rätt person och leder till radering, avidentifiering eller godkänd lagring på varje plats.
• Vilka bevis som finns kvar för att visa att samtycke och integritetsbegäranden hanterades.

Samtycke och radering ser ut som motsatser (får vi använda de här data? kan vi sluta och ta bort dem?), men de vilar på samma grund: identitet, ändamål, klassificering, härkomst, ägarskap, genomdrivande och bevis. Använd standardmodellen för samtycke, kontrollera vart personuppgifterna tar vägen, vet var kopiorna finns, och designa raderingsprocessen innan den första begäran kommer. När någon frågar ”kan ni glömma mig?” behöver arkitekturen ett bättre svar än ”vi tror det”.

Utforska vidare

• Salesforce Help, Understand the Salesforce Consent Data Model (opens in a new tab) (på engelska, kontrollerad 2026-10-14).
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab), artikel 12.3, tidsfristen för att hantera en begäran (på engelska, kontrollerad 2026-10-14).
• Salesforce Help, Delete Data with Right to Be Forgotten Policies (opens in a new tab) (Privacy Center) (på engelska, kontrollerad 2026-10-14).