Personvernlover former designet
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)
Modul 4 av 6 i kapitlet Datakvalitet og styring, kapittel 5 i kurset Data Architect. Hver modul står på egne ben. Forrige: Kjenn dataene dine · Neste: Samtykke og retten til å bli glemt
Spørsmålet denne modulen besvarer: Hva krever personvernlover og bransjeregelverk av et design i Salesforce?
Da jeg jobbet i Australia, møtte jeg mange arkitektspirer som aldri hadde hørt om personvernforordningen, GDPR. Europeere har ofte ikke hørt om personvernloven i California, eller i Canada, eller i Brasil. Det er naturlig: du kjenner reglene der du jobber. Men disse lovene når over landegrensene, og de former systemdesignet selv om ingen av dem handler om Salesforce. Derfor hører de hjemme i et kurs i dataarkitektur.
Du trenger ikke bli advokat. Men du må se at et regelverk kan endre hvor data lagres, hva du samler inn, hvem som ser dem, hvorfor du kan bruke dem, hvor lenge du oppbevarer dem, hvor du sender dem, om du kan slette dem, hvilken historikk du tar vare på, og hva du kan bevise senere. Det er ikke bare juridiske spørsmål. Det er spørsmål om dataarkitektur.
Denne modulen er arkitekturveiledning, ikke juridisk rådgivning. Juridisk avdeling og compliance-teamene bestemmer hvilke lover som gjelder og hva de krever. Arkitekten gjør disse kravene om til et design som kan håndheves.
Lover stopper ikke ved grensen
Section titled “Lover stopper ikke ved grensen ”Den største misforståelsen først: «vi er ikke i Europa, så GDPR gjelder ikke for oss». Kanskje, kanskje ikke. GDPRs territorielle virkeområde omfatter virksomheter utenfor EU som tilbyr varer eller tjenester til personer i EU, eller overvåker deres atferd der (artikkel 3, Regulation (EU) 2016/679 (opens in a new tab)). Så hvor selskapet ditt har hovedkontor, er ikke slutten på spørsmålet. Hvor er kundene dine, de ansatte, personene du har data om, systemene dine, databehandlerne dine? Hvor reiser dataene? Det er landskapet fra kapittel 4 igjen. Du kan ikke ta gode personvernbeslutninger uten å vite hvor dataene går.
Regelverkene du bør kjenne igjen
Section titled “Regelverkene du bør kjenne igjen ”Her er navnene en arkitekt bør kjenne, med hva hvert av dem dekker. Det er en tabell for å kjenne igjen, ikke en matrise over hva som gjelder: ikke les den og bestem at «vi har kunder i California, så krav X gjelder». Det er juridisk avdelings beslutning. Din jobb er å vite nok til å stille spørsmålet før systemet bygges.
| Lov eller standard | Hvor eller hva | Hvorfor en arkitekt bør kjenne den igjen |
|---|---|---|
| GDPR (opens in a new tab) | Den europeiske union | Personopplysninger, lovlig behandling, den registrertes rettigheter, lagringstid, overføringer, innebygd personvern |
| CCPA, as amended by the CPRA (opens in a new tab) | California | Forbrukeres rettigheter over personopplysningene virksomheter samler inn om dem |
| PIPEDA (opens in a new tab) | Canada | Hvordan private virksomheter behandler personopplysninger |
| LGPD (opens in a new tab) | Brasil | Brasils generelle lov om vern av personopplysninger |
| Privacy Act 1988 (opens in a new tab) | Australia | Hvordan virksomheter behandler personopplysninger, etter Australian Privacy Principles |
| HIPAA (opens in a new tab) | Helsesektoren i USA | Beskyttede helseopplysninger i omfattede sammenhenger |
| PCI DSS (opens in a new tab) | Betalingskort | Beskyttelse av kontodata for betalingskort |
| Sarbanes-Oxley (SOX) (opens in a new tab) | Børsnoterte selskaper i USA | Kontrollene og dokumentasjonen bak den finansielle rapporteringen |
| COPPA (opens in a new tab) | USA, barn på nett | Personopplysninger som samles inn på nett fra barn |
Listen vokser (flere amerikanske delstater har sine egne lover), og lovene endres. Derfor vil jeg ikke at du skal pugge en tabell og tro at du har lært personvernarkitektur. Lær navnene, og lær så spørsmålene som overlever dem.
Hva lovene har til felles
Section titled “Hva lovene har til felles ”Detaljene er forskjellige, men de store personvernlovene kommer stadig tilbake til de samme få tingene, og hver av dem lander i arkitekturen.
Rettigheter. Folk kan be om å få se dataene sine, rette dem, slette dem og ta dem med seg; etter lovene i California og Brasil kan de også reservere seg mot at de selges. Hver av de forespørslene betyr å finne personens data, alle sammen.
Overføringer. GDPR og LGPD kontrollerer personopplysninger som forlater deres jurisdiksjon, og krever et tilstrekkelig beskyttelsesnivå der de havner; PIPEDA forventer samme beskyttelsesnivå når en tredjepart behandler dataene, uansett hvor den er. Det er landskapet igjen: hvilke piler krysser en grense?
Varsling av brudd. Når personopplysninger kommer på avveie, forventer lovene at du varsler myndighetene, og noen ganger de berørte, innen en frist som varierer fra lov til lov. Du kan ikke varsle om data du ikke visste du hadde, eller si hva som kom på avveie hvis du ikke finner kopiene.
Ansvarlighet. Du må kunne vise at du etterlever regelverket: protokoller over hva du behandler og hvorfor, vurderinger av personvernkonsekvenser for behandling med høy risiko, og, etter GDPR og LGPD, et personvernombud. Arkitekturen må produsere dokumentasjonen.
Start med det som er personlig
Section titled “Start med det som er personlig ”Før du beskytter personopplysninger, må du finne dem. Noe er opplagt: navn, hjemmeadresse, telefon, e-post. Noe er det ikke: posisjon, enhetsidentifikatorer, IP-adresser, bilder, atferdsdata, alt som kan kobles tilbake til en person. Og konteksten betyr noe. En levering hos Steve Trucking har med seg mottakerens navn, adresse, telefonnummer, leveringsnotater og bilder. Et bilde kan vise en eske på en trapp, eller et menneske, eller innsiden av et hjem. Leveringen er operative data, men noen av attributtene er personopplysninger. Derfor klassifiserte vi felt i modul 3: personvern starter med å vite hva du har.
Hvor bor de?
Section titled “Hvor bor de? ”«I Salesforce.» Sannsynligvis ikke bare i Salesforce. Kom de fra en detaljhandelspartner? Ble de kopiert til Snowflake, tatt inn i Data 360, skrevet til en integrasjonslogg, eksportert av en bruker, liggende igjen i felthistorikken, arkivert, kopiert inn i en sandkasse, sendt til en partner, brukt i en agents samtale? Personopplysninger sprer seg. Så når juridisk avdeling spør «hvor har vi opplysningene om denne personen?», er ikke «vi vet hvor den nåværende verdien er» et svar. Jeg vil ha landskapet og opphavet: hvor kopiene ble av.
Ett telefonnummer, mange kopier. Personvernet gjelder også for kopiene.
Hvorfor har du lov til å bruke dem?
Section titled “Hvorfor har du lov til å bruke dem? ”Å ha data og å ha lov til å bruke dem er ikke det samme. Steve Trucking har telefonnummeret til en mottaker for å koordinere dagens levering. Gjør det nummeret til en markedsføringsliste? Nei. Behandlingsgrunnlaget avhenger av jurisdiksjonen og situasjonen, og det veileder juridisk avdeling om, men arkitekturen må bære svaret: hvorfor opplysningene ble samlet inn, hvilken bruk som ble godkjent, om samtykke trengtes, ble gitt, ble trukket tilbake, og for hvilken kanal, adresse og hvilket formål. Tillatelsen til å bruke data må kunne representeres som data, for et policydokument kan ikke ta en beslutning mens systemet kjører. Neste modul modellerer det.
Å samle inn mindre er en arkitekturbeslutning
Section titled “Å samle inn mindre er en arkitekturbeslutning ”En av de sterkeste personvernkontrollene er å ikke samle inn dataene, eller ikke kopiere dem dit de ikke trengs. Trenger Snowflake mottakerens telefonnummer? Trenger analysen hele gateadressen? Trenger sandkassen ekte leveringsbilder? Trenger en agent mottakerens personopplysninger for å svare på dette spørsmålet? Hvis ikke, kan den sterkeste kontrollen være å ikke legge dem der. Hver kopi du ikke lager, er en du ikke trenger å sikre, oppbevare, slette, spore samtykke for, revidere eller rapportere i et brudd. De billigste sensitive dataene å styre er de du aldri kopierte.
Oppbevaring er en del av modellen
Section titled “Oppbevaring er en del av modellen ”«Vi tar vare på alt inntil videre» er en oppbevaringspolicy. Den er bare dårlig. For viktige data vil jeg vite allerede når vi designer hvor lenge vi trenger dem og hvorfor; om et regelverk setter et minimum, eller et annet setter et maksimum; når klokken begynner å gå; og hva som skjer ved slutten: slette, arkivere, avidentifisere, og hvor er kopiene? Regnskapsopplysninger kan måtte oppbevares i en bestemt periode. En mottakers portkode har ikke noe formål flere år etter leveringen. De beslutningene venter ikke til databasen er blitt stor.
Anonymisert, pseudonymisert, kryptert, maskert
Section titled “Anonymisert, pseudonymisert, kryptert, maskert ”Bytt ut «Jane Smith» med 7F92A1. Er Jane anonymisert? Ikke hvis en annen tabell fortsatt sier 7F92A1 = Jane Smith. Det er pseudonymisering: den direkte identifikatoren er byttet ut, men dataene kan kobles sammen igjen ved hjelp av opplysninger som oppbevares separat, og etter GDPR er pseudonymiserte opplysninger fortsatt personopplysninger (artikkel 4 nr. 5). Anonymisering går lenger: dataene kan ikke lenger med rimelighet knyttes til personen (fortalepunkt 26). Så når noen sier «vi trenger ikke slette det, vi fjerner bare navnet», vær forsiktig. Hvis personen fortsatt med rimelighet kan identifiseres, har du ikke krysset den linjen. Om et resultat oppfyller loven, er juridisk avdelings beslutning; arkitektens jobb er å si nøyaktig hva systemet gjør: kan dataene kobles sammen igjen, hvilke nøkler er igjen, hvor er tilordningene?
Bruk ordene presist, for de løser forskjellige problemer. Kryptering beskytter data mot uautorisert utlevering; en autorisert bruker kan fortsatt dekryptere dem. Maskering endrer hva bestemte brukere eller miljøer ser. Pseudonymisering skiller ut den direkte identiteten, men beholder en vei tilbake. Anonymisering fjerner den rimelige muligheten til å identifisere personen. Bare den siste tar dataene ut av «personopplysninger».
Regelverk blir krav
Section titled “Regelverk blir krav ”Juridisk avdeling trenger ikke å be meg opprette et tillatelsessett; det er min side av linjen. Juridisk kan si at «bare ansatte med et legitimt tjenstlig behov kan få tilgang til denne kategorien personopplysninger». Da oversetter jeg: hvem er de, hvordan identifiserer vi kategorien, hvordan gis tilgangen, hva skjer når noen bytter jobb, kan en integrasjon lese dem, kan en agent, kan de eksporteres, og hvordan beviser vi hvem som så dem? Eierne setter policyen; arkitektene håndhever den. Juridisk og compliance fastsetter forpliktelsen, dataeierne setter forretningspolicyen, og arkitekten designer håndhevingen.
Fra regelverk til dokumentasjon: juridisk tolker, eieren setter policyen, arkitekten får det til å virke og til å kunne bevises.
Og etterlevelse er ikke et produkt. Du kan ikke kjøpe «compliance: på». Kryptering kan støtte et krav, revisjonsfunksjoner gir dokumentasjon, verktøy for oppbevaring gjennomfører policyen, samtykkedata støtter tillatt bruk, men å lisensiere en funksjon gjør ikke en arkitektur etterlevende. Etterlevelse kommer fra hele designet: mennesker, policy, prosess, data, kontroller og dokumentasjon. Salesforce er en del av det, ikke alt. Og hvis en policy er viktig nok til å håndheves, spør om den er viktig nok til å bevises: hvem åpnet denne posten 17. mars, hvem endret dette feltet, hva inneholdt den eksporten? Modul 6 dekker dokumentasjonen.
Personvern endrer landskapet
Section titled “Personvern endrer landskapet ”Hos Steve Trucking kommer mottakerens personopplysninger inn gjennom tre partnerintegrasjoner. Salesforce trenger dem for å kjøre leveringene; teamene trenger noe av dem, bare for sine egne stopp, bare den dagen; Snowflake vil ha leveringsanalyse; økonomi trenger nok til å fakturere, men ikke det teamet ser. Og én detaljhandelspartner skal aldri se en annens mottakere. Personvern endrer pilene: visse felt går ikke til Snowflake, analysen får en mindre identifiserbar versjon, teamene ser bare sine egne stopp, oppbevaringen lenger ned i kjeden er en annen enn den operative. Personvernkravet står ikke ved siden av landskapsdiagrammet. Det endrer det.
Spørsmål som overlever regelverket
Section titled “Spørsmål som overlever regelverket ”Regelverk endres, så ha med deg et varig sett med spørsmål for alle sensitive eller regulerte data:
- Hva er det? Personopplysninger, sensitive opplysninger, finansielle opplysninger, helseopplysninger, betalingsdata, opplysninger om barn eller på annen måte regulert?
- Hvor bor det? Hver kopi: integrasjoner, historikk, analyse, arkiver, sandkasser, logger, KI-bruk.
- Hvorfor kan vi bruke det? Hvilket formål og hvilket behandlingsgrunnlag gjelder? Er samtykke involvert?
- Hvem kan bruke det? Mennesker, systemer, partnere, integrasjoner, agenter.
- Hvor lenge oppbevarer vi det, og hva skjer ved slutten?
- Kan personen utøve rettighetene sine over det? Innsyn, retting, sletting, dataportabilitet, protest, slik loven gir.
- Kan vi bevise hva som skjedde? Tilgang, endringer, eksporter, samtykke, sletting, oppbevaring.
Styring av KI blir lov
Section titled “Styring av KI blir lov ”KI legger til en ny konsument av styrte data. Kan et KI-system bruke disse dataene, til hvilket formål, som grounding (forankring i data), kombinert med hva, gjentatt i det det produserer, logget hvor, hvor lenge? Styring av KI er på vei fra selskapenes policyer inn i lovverket: EUs KI-forordning, AI Act (Regulation (EU) 2024/1689 (opens in a new tab)), er det første brede eksempelet. Hva den krever, avhenger av systemet og bruken. Retningen for arkitekter er klar: KI står ikke utenfor styringen; den er enda en konsument av styrte data.
Hva en arkitekt bestemmer her
Section titled “Hva en arkitekt bestemmer her ”- Hvor regulerte eller sensitive data kommer inn, bor, beveger seg og kopieres på tvers av landskapet.
- Hvordan juridiske policyer og compliance-policyer blir krav som kan håndheves, uten at arkitekten tolker loven.
- Om hvert system som mottar sensitive data, trenger dem, eller om en mindre identifiserbar versjon ville holdt.
- Hvordan oppbevaring, sletting, anonymisering, pseudonymisering, beskyttelse og dokumentasjon former dataenes livssyklus.
- Hvilken dokumentasjon som må finnes for å vise at de viktige kontrollene faktisk virket.
Regelverk blir ikke arkitektur ved at navnene deres står på et lysbilde. De blir arkitektur når de endrer hvordan data samles inn, klassifiseres, flyttes, beskyttes, oppbevares, slettes og bevises.
Les mer
Section titled “Les mer ”- Regelverkenes offisielle kilder er lenket i tabellen over, på engelsk (eller originalspråket), kontrollert 2026-10-14.
- Regulation (EU) 2016/679 (GDPR) (opens in a new tab): artikkel 3 (territorielt virkeområde), artikkel 4 nr. 5 (pseudonymisering), fortalepunkt 26 (anonyme opplysninger).
- Regulation (EU) 2024/1689 (the AI Act) (opens in a new tab), EUR-Lex.