Integritetslagar formar designen

🌐 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 4 av 6 i kapitlet Datakvalitet och styrning, kapitel 5 i kursen Data Architect. Varje modul står på egna ben. Föregående: Känn dina data · Nästa: Samtycke och rätten att bli bortglömd

Frågan den här modulen besvarar: Vad kräver integritetslagar och branschregler av en design i Salesforce?

När jag arbetade i Australien träffade jag massor av blivande arkitekter som aldrig hade hört talas om dataskyddsförordningen, GDPR. Européer har ofta inte hört talas om Kaliforniens integritetslag, eller Kanadas, eller Brasiliens. Det är naturligt: du kan reglerna där du arbetar. Men de här lagarna når över gränser, och de formar systemdesignen trots att ingen av dem handlar om Salesforce. Därför hör de hemma i en kurs i dataarkitektur.

Du behöver inte bli jurist. Men du behöver se att ett regelverk kan ändra var data lagras, vad du samlar in, vem som ser dem, varför du får använda dem, hur länge du sparar dem, vart du skickar dem, om du kan radera dem, vilken historik du sparar och vad du kan bevisa i efterhand. Det är inte bara juridiska frågor. Det är frågor om dataarkitektur.

Den här modulen är vägledning i arkitektur, inte juridisk rådgivning. Juridik- och compliance-teamen avgör vilka lagar som gäller och vad de kräver. Arkitekten gör om de kraven till en design som går att genomdriva.

Lagar stannar inte vid gränsen

Den största missuppfattningen först: ”vi är inte i Europa, så GDPR gäller inte.” Kanske, kanske inte. GDPR:s territoriella tillämpningsområde omfattar organisationer utanför EU som erbjuder varor eller tjänster till personer i EU, eller övervakar deras beteende där (artikel 3, Regulation (EU) 2016/679 (opens in a new tab)). Så var ditt företag har sitt huvudkontor är inte slutet på frågan. Var finns dina kunder, dina anställda, personerna vars data du har, dina system, dina personuppgiftsbiträden? Vart reser data? Det är landskapet från kapitel 4 igen. Du kan inte fatta bra integritetsbeslut utan att veta vart data tar vägen.

Regelverken du bör känna igen

Här är namnen som en arkitekt bör känna till, med vad vart och ett omfattar. Det är en tabell för att känna igen, inte en matris för tillämplighet: läs den inte och bestäm att ”vi har kunder i Kalifornien, så krav X gäller”. Det avgör Juridik. Ditt jobb är att veta tillräckligt för att ställa frågan innan systemet byggs.

Lag eller standard	Var eller vad	Varför en arkitekt bör känna igen den
GDPR (opens in a new tab)	Europeiska unionen	Personuppgifter, laglig behandling, individens rättigheter, lagringstid, överföringar, inbyggt dataskydd
CCPA, as amended by the CPRA (opens in a new tab)	Kalifornien	Konsumenters rättigheter till de personuppgifter som företag samlar in om dem
PIPEDA (opens in a new tab)	Kanada	Hur organisationer i privat sektor hanterar personuppgifter
LGPD (opens in a new tab)	Brasilien	Brasiliens allmänna lag om skydd av personuppgifter
Privacy Act 1988 (opens in a new tab)	Australien	Hur organisationer hanterar personuppgifter, enligt Australian Privacy Principles
HIPAA (opens in a new tab)	Amerikansk hälso- och sjukvård	Skyddad hälsoinformation i de sammanhang lagen omfattar
PCI DSS (opens in a new tab)	Betalkort	Skydd av kontodata för betalkort
Sarbanes-Oxley (SOX) (opens in a new tab)	Börsnoterade bolag i USA	Kontroller och bevis bakom den finansiella rapporteringen
COPPA (opens in a new tab)	USA, barn på nätet	Personuppgifter som samlas in på nätet från barn

Listan växer (fler delstater i USA har egna lagar), och lagarna ändras. Därför vill jag inte att du pluggar in en tabell och tror att du har lärt dig integritetsarkitektur. Lär dig namnen, och lär dig sedan frågorna som överlever dem.

Vad lagarna har gemensamt

Detaljerna skiljer sig åt, men de stora integritetslagarna återkommer hela tiden till samma få saker, och var och en landar i arkitekturen.

Rättigheter. Människor kan begära att få se sina uppgifter, rätta dem, radera dem och ta dem med sig; enligt Kaliforniens och Brasiliens lagar kan de också välja bort att uppgifterna säljs. Varje sådan begäran innebär att hitta personens uppgifter, alla.

Överföringar. GDPR och LGPD kontrollerar personuppgifter som lämnar deras jurisdiktion och kräver adekvat skydd där uppgifterna hamnar; PIPEDA förväntar sig samma skyddsnivå när en tredje part behandlar uppgifterna, var den än finns. Det är landskapet igen: vilka pilar korsar en gräns?

Anmälan av personuppgiftsincidenter. När personuppgifter exponeras förväntar sig lagarna att du informerar myndigheterna, och ibland de berörda personerna, inom en tidsfrist som varierar mellan lagarna. Du kan inte anmäla data du inte visste att du hade, eller säga vad som exponerades om du inte hittar kopiorna.

Ansvarsskyldighet. Du måste kunna visa att du följer reglerna: register över vad du behandlar och varför, konsekvensbedömningar för behandling med hög risk och, enligt GDPR och LGPD, ett dataskyddsombud. Arkitekturen måste ta fram underlagen.

Börja med det som är personligt

Innan du skyddar personuppgifter, hitta dem. En del är uppenbart: namn, hemadress, telefon, e-post. En del är det inte: plats, enhetsidentifierare, IP-adresser, bilder, beteendedata, allt som kan kopplas tillbaka till en person. Och sammanhanget spelar roll. En leverans hos Steve Trucking bär mottagarens (Recipient) namn, adress, telefonnummer, leveransanteckningar och foton. Ett foto kan visa en kartong på en veranda, eller en person, eller insidan av ett hem. Leveransen är operativa data, men några av dess attribut är personuppgifter. Därför klassificerade modul 3 fälten: integritet börjar med att veta vad du har.

Var bor de?

”I Salesforce.” Förmodligen inte bara i Salesforce. Kom uppgifterna från en detaljhandelspartner (Retail Partner)? Kopierades de till Snowflake, laddades de in i Data 360, skrevs de till en integrationslogg, exporterades de av en användare, blev de kvar i fälthistoriken, arkiverades de, kopierades de till en sandbox, skickades de vidare till en partner, användes de i en agents konversation? Personuppgifter sprider sig. Så när Juridik frågar ”var har vi den här personens uppgifter?” är ”vi vet var det nuvarande värdet finns” inget svar. Jag vill ha landskapet och härkomsten: vart kopiorna tog vägen.

Click to enlarge

Ett telefonnummer, många kopior. Integritet gäller också kopiorna.

Varför får du använda dem?

Att ha data och att få använda dem är inte samma sak. Steve Trucking har en mottagares telefonnummer för att samordna dagens leverans. Gör det numret till en marknadsföringslista? Nej. Den rättsliga grunden beror på jurisdiktionen och situationen, och där vägleder Juridik, men arkitekturen måste bära svaret: varför uppgifterna samlades in, vilken användning som godkändes, om samtycke behövdes, gavs eller återkallades, och för vilken kanal, adress och vilket ändamål. Tillåtelsen att använda data måste kunna representeras som data, eftersom ett policydokument inte kan fatta ett beslut när systemet körs. Nästa modul modellerar det.

Att samla in mindre är ett arkitekturbeslut

En av de starkaste integritetskontrollerna är att inte samla in uppgifterna, eller att inte kopiera dem dit de inte behövs. Behöver Snowflake mottagarens telefonnummer? Behöver analysen hela gatuadressen? Behöver sandboxen riktiga leveransfoton? Behöver en agent mottagarens personuppgifter för att besvara den här frågan? Om inte, kan den starkaste kontrollen vara att inte lägga dem där. Varje kopia du inte gör är en som du inte behöver säkra, bevara, radera, spåra samtycke för, granska eller rapportera vid en incident. De billigaste känsliga data att styra är de data du aldrig kopierade.

Lagringstid är en del av modellen

”Vi sparar allt så länge” är en policy för lagringstid. Den är bara dålig. För viktiga data vill jag veta redan vid designen hur länge vi behöver dem och varför; om ett regelverk sätter ett minimum eller ett annat sätter ett maximum; när klockan börjar ticka; och vad som händer i slutet: radera, arkivera, avidentifiera, och var finns kopiorna? Finansiella poster kan behöva sparas en bestämd tid. En mottagares portkod har inget syfte flera år efter leveransen. De besluten väntar inte tills databasen har blivit stor.

Anonymiserat, pseudonymiserat, krypterat, maskerat

Byt ut ”Jane Smith” mot 7F92A1. Är Jane anonymiserad? Inte om en annan tabell fortfarande säger 7F92A1 = Jane Smith. Det är pseudonymisering: den direkta identifieraren ersätts, men uppgifterna kan kopplas ihop igen med hjälp av information som förvaras separat, och enligt GDPR är pseudonymiserade uppgifter fortfarande personuppgifter (artikel 4.5). Anonymisering går längre: uppgifterna kan inte längre rimligen kopplas till personen (skäl 26). Så när någon säger ”vi behöver inte radera dem, vi tar bara bort namnet”, var försiktig. Om personen fortfarande rimligen kan identifieras har du inte korsat den linjen. Om resultatet uppfyller lagen avgör Juridik; arkitektens jobb är att säga exakt vad systemet gör: kan uppgifterna kopplas ihop igen, vilka nycklar finns kvar, var finns mappningarna?

Använd orden exakt, för de löser olika problem. Kryptering skyddar data mot obehörigt röjande; en behörig användare kan fortfarande dekryptera dem. Maskering ändrar vad vissa användare eller miljöer ser. Pseudonymisering skiljer ut den direkta identiteten men behåller en väg tillbaka. Anonymisering tar bort den rimliga möjligheten att identifiera personen. Bara den sista gör att data inte längre är ”personuppgifter”.

Regelverk blir krav

Juridik behöver inte säga åt mig att skapa en behörighetsuppsättning; det är min sida av linjen. Juridik kanske säger ”bara anställda med ett legitimt verksamhetsbehov får komma åt den här kategorin av personuppgifter”. Då översätter jag: vilka är de, hur identifierar vi kategorin, hur ges åtkomst, vad händer när någon byter jobb, kan en integration läsa den, kan en agent, kan den exporteras, och hur bevisar vi vem som såg den? Ägarna sätter policyn; arkitekterna genomdriver den. Juridik och compliance fastställer skyldigheten, dataägarna sätter verksamhetens policy, och arkitekten designar genomdrivandet.

Click to enlarge

Från regelverk till bevis: Juridik tolkar, ägaren sätter policyn, arkitekten får det att fungera och att gå att bevisa.

Och regelefterlevnad är ingen produkt. Du kan inte köpa ”compliance: på”. Kryptering kan stödja ett krav, granskningsfunktioner ger bevis, verktyg för lagringstid verkställer policyer, samtyckesdata stöder tillåten användning, men att licensiera en funktion gör inte en arkitektur regelefterlevande. Regelefterlevnad kommer från hela designen: människor, policy, process, data, kontroller och bevis. Salesforce är en del av det, inte allt. Och om en policy är viktig nog att genomdriva, fråga om den är viktig nog att bevisa: vem öppnade den här posten den 17 mars, vem ändrade det här fältet, vad innehöll den exporten? Modul 6 handlar om bevisen.

Integritet ändrar landskapet

Hos Steve Trucking kommer mottagarens personuppgifter in via tre partnerintegrationer. Salesforce behöver dem för att driva leveranserna; teamen behöver en del av dem, bara för sina egna stopp, bara under dagen; Snowflake vill ha leveransanalys; ekonomi behöver tillräckligt för att fakturera, men inte det teamet ser. Och en detaljhandelspartner får aldrig se en annans mottagare. Integriteten ändrar pilarna: vissa fält går inte till Snowflake, analysen får en mindre identifierbar version, teamen ser bara sina stopp, lagringstiden längre ned i kedjan skiljer sig från den operativa. Integritetskravet står inte bredvid landskapsdiagrammet. Det ändrar det.

Frågor som överlever regelverken

Regelverk ändras, så bär med dig en hållbar uppsättning frågor för alla känsliga eller reglerade data:

• Vad är det? Personuppgifter, känsliga uppgifter, finansiella uppgifter, hälsouppgifter, betaluppgifter, barns uppgifter eller på annat sätt reglerade?
• Var bor de? Varje kopia: integrationer, historik, analys, arkiv, sandboxar, loggar, AI-användning.
• Varför får vi använda dem? Vilket ändamål och vilken rättslig grund gäller? Är samtycke inblandat?
• Vem får använda dem? Människor, system, partner, integrationer, agenter.
• Hur länge sparar vi dem, och vad händer i slutet?
• Kan personen utöva sina rättigheter till dem? Tillgång, rättelse, radering, dataportabilitet, invändning, enligt vad lagen ger.
• Kan vi bevisa vad som hände? Åtkomst, ändringar, exporter, samtycke, radering, lagringstid.

Styrning av AI håller på att bli lag

AI tillför ytterligare en konsument av styrda data. Får ett AI-system använda de här data, för vilket ändamål, som grounding (förankring i data), kombinerat med vad, upprepat i sitt svar, loggat var, och hur länge? Styrningen av AI håller på att flytta från företagens policyer in i lagen: EU:s AI-förordning (Regulation (EU) 2024/1689 (opens in a new tab)) är det första breda exemplet. Vad den kräver beror på systemet och användningen. Riktningen för arkitekter är tydlig: AI står inte utanför styrningen; det är ytterligare en konsument av styrda data.

Vad en arkitekt bestämmer här

• Var reglerade eller känsliga data kommer in, bor, rör sig och kopieras i landskapet.
• Hur policyer från juridik och compliance blir krav som går att genomdriva, utan att arkitekten tolkar lagen.
• Om varje system som tar emot känsliga data behöver dem, eller om en mindre identifierbar version skulle räcka.
• Hur lagringstid, radering, anonymisering, pseudonymisering, skydd och bevis formar datas livscykel.
• Vilka bevis som måste finnas för att visa att de viktiga kontrollerna faktiskt fungerade.

Regelverk blir inte arkitektur genom att deras namn hamnar på en bild. De blir arkitektur när de ändrar hur data samlas in, klassificeras, flyttas, skyddas, bevaras, raderas och bevisas.

Utforska vidare

• Regelverkens officiella källor är länkade i tabellen ovan, kontrollerade 2026-10-14.
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab): artikel 3 (territoriellt tillämpningsområde), artikel 4.5 (pseudonymisering), skäl 26 (anonyma uppgifter).
• Regulation (EU) 2024/1689 (the AI Act) (opens in a new tab), EUR-Lex.