Prawo o prywatności kształtuje projekt
Dostępne także w 28 językach
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Moduł 4 z 6 w rozdziale Jakość danych i ład danych, rozdziale 5 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Poznaj swoje dane · Dalej: Zgoda i prawo do bycia zapomnianym
Pytanie, na które odpowiada ten moduł: czego przepisy o prywatności i regulacje branżowe wymagają od projektu w Salesforce?
Kiedy pracowałem w Australii, spotkałem wielu aspirujących architektów, którzy nigdy nie słyszeli o RODO (GDPR). Europejczycy często nie słyszeli o kalifornijskim prawie o prywatności ani o kanadyjskim czy brazylijskim. To naturalne: znasz zasady tam, gdzie pracujesz. Ale te przepisy sięgają ponad granicami i kształtują projektowanie systemów, choć żaden z nich nie dotyczy Salesforce. Dlatego należą do kursu architektury danych.
Nie musisz zostawać prawnikiem. Musisz jednak widzieć, że regulacja może zmienić to, gdzie przechowywane są dane, co zbierasz, kto je widzi, dlaczego wolno ci z nich korzystać, jak długo je trzymasz, dokąd je wysyłasz, czy możesz je usunąć, jaką historię zachowujesz i co możesz później udowodnić. To nie tylko pytania prawne. To pytania o architekturę danych.
Ten moduł to wskazówki architektoniczne, a nie porada prawna. Dział prawny i dział zgodności decydują, które przepisy mają zastosowanie i czego wymagają. Architekt zamienia te wymagania w egzekwowalny projekt.
Prawo nie zatrzymuje się na granicy
Dział zatytułowany „Prawo nie zatrzymuje się na granicy ”Najpierw największe nieporozumienie: „nie jesteśmy w Europie, więc RODO nas nie dotyczy”. Może, a może nie. Terytorialny zakres RODO obejmuje organizacje spoza UE, które oferują towary lub usługi osobom w UE albo monitorują ich zachowanie w UE (art. 3, rozporządzenie (UE) 2016/679 (opens in a new tab)). To, gdzie firma ma siedzibę, nie zamyka więc pytania. Gdzie są twoi klienci, pracownicy, ludzie, których dane trzymasz, twoje systemy, twoje podmioty przetwarzające? Dokąd wędrują dane? To znowu krajobraz z rozdziału 4. Nie podejmiesz dobrych decyzji o prywatności, nie wiedząc, dokąd idą dane.
Regulacje, które warto rozpoznawać
Dział zatytułowany „Regulacje, które warto rozpoznawać ”Oto nazwy, które architekt powinien znać, z tym, czego dotyczy każda z nich. To tabela do rozpoznawania, a nie macierz zastosowania: nie czytaj jej i nie decyduj „mamy klientów w Kalifornii, więc obowiązuje wymaganie X”. To decyzja działu prawnego. Twoim zadaniem jest wiedzieć dość, żeby zadać pytanie, zanim system zostanie zbudowany.
| Prawo albo standard | Gdzie albo czego dotyczy | Dlaczego architekt powinien je rozpoznawać |
|---|---|---|
| RODO (GDPR) (opens in a new tab) | Unia Europejska | Dane osobowe, zgodne z prawem przetwarzanie, prawa osób, retencja, przekazywanie, uwzględnianie prywatności w fazie projektowania |
| CCPA, zmieniona przez CPRA (opens in a new tab) | Kalifornia | Prawa konsumentów do danych osobowych, które zbierają o nich firmy |
| PIPEDA (opens in a new tab) | Kanada | Sposób, w jaki organizacje sektora prywatnego postępują z danymi osobowymi |
| LGPD (opens in a new tab) | Brazylia | Brazylijska ogólna ustawa o ochronie danych osobowych |
| Privacy Act 1988 (opens in a new tab) | Australia | Sposób, w jaki organizacje postępują z danymi osobowymi, według Australian Privacy Principles |
| HIPAA (opens in a new tab) | Opieka zdrowotna w USA | Chronione informacje zdrowotne w objętych kontekstach |
| PCI DSS (opens in a new tab) | Karty płatnicze | Ochrona danych kont kart płatniczych |
| Sarbanes-Oxley (SOX) (opens in a new tab) | Spółki publiczne w USA | Mechanizmy kontroli i dowody stojące za sprawozdawczością finansową |
| COPPA (opens in a new tab) | USA, dzieci w internecie | Dane osobowe zbierane online od dzieci |
Lista rośnie (kolejne stany USA mają własne przepisy), a przepisy się zmieniają. Dlatego nie chcę, żeby zapamiętanie tabeli dawało ci poczucie, że znasz już architekturę prywatności. Naucz się nazw, a potem pytań, które je przetrwają.
Co te przepisy mają wspólnego
Dział zatytułowany „Co te przepisy mają wspólnego ”Szczegóły się różnią, ale wielkie przepisy o prywatności wciąż wracają do tych samych kilku rzeczy, a każda z nich ląduje w architekturze.
Prawa. Ludzie mogą poprosić o wgląd w swoje dane, o ich poprawienie, usunięcie i zabranie ze sobą; według przepisów Kalifornii i Brazylii mogą też sprzeciwić się ich sprzedaży. Każde z tych żądań oznacza znalezienie danych tej osoby, wszystkich.
Przekazywanie. RODO i LGPD kontrolują dane osobowe opuszczające ich jurysdykcję i wymagają odpowiedniej ochrony tam, dokąd trafiają; PIPEDA oczekuje tego samego poziomu ochrony, gdy dane przetwarza podmiot trzeci, gdziekolwiek jest. To znowu krajobraz: które strzałki przekraczają granicę?
Zgłaszanie naruszeń. Gdy dane osobowe zostaną ujawnione, przepisy oczekują, że powiadomisz organy nadzorcze, a czasem także osoby, których to dotyczy, w terminie, który zależy od przepisów. Nie da się zgłosić danych, o których posiadaniu się nie wiedziało, ani powiedzieć, co zostało ujawnione, jeśli nie potrafisz znaleźć kopii.
Rozliczalność. Musisz umieć wykazać zgodność: rejestry tego, co przetwarzasz i dlaczego, oceny skutków dla przetwarzania wysokiego ryzyka, a w przypadku RODO i LGPD inspektora ochrony danych. Architektura musi te rejestry wytwarzać.
Zacznij od tego, co jest osobowe
Dział zatytułowany „Zacznij od tego, co jest osobowe ”Zanim zaczniesz chronić dane osobowe, znajdź je. Część jest oczywista: imię i nazwisko, adres domowy, telefon, e-mail. Część nie: lokalizacja, identyfikatory urządzeń, adresy IP, obrazy, dane o zachowaniu, wszystko, co da się powiązać z osobą. I kontekst ma znaczenie. Dostawa Steve Trucking niesie imię i nazwisko odbiorcy, adres, numer telefonu, uwagi do dostawy i zdjęcia. Zdjęcie może pokazywać karton na ganku albo osobę, albo wnętrze domu. Dostawa to dane operacyjne, ale część jej atrybutów to dane osobowe. Dlatego moduł 3 klasyfikował pola: prywatność zaczyna się od wiedzy, co się ma.
Gdzie mieszkają?
Dział zatytułowany „Gdzie mieszkają? ”„W Salesforce”. Pewnie nie tylko w Salesforce. Czy przyszły od partnera detalicznego? Czy skopiowano je do Snowflake, pobrało je Data 360, zapisano je w logu integracji, wyeksportował je użytkownik, zostały w historii pól, zarchiwizowano je, skopiowano do sandboxa, przekazano partnerowi, użyto ich w rozmowie agenta? Dane osobowe się rozprzestrzeniają. Kiedy więc dział prawny pyta „gdzie przechowujemy informacje o tej osobie?”, „wiemy, gdzie jest bieżąca wartość” to nie jest odpowiedź. Chcę krajobrazu i pochodzenia: dokąd poszły kopie.
Jeden numer telefonu, wiele kopii. Prywatność dotyczy też kopii.
Dlaczego wolno ci z nich korzystać?
Dział zatytułowany „Dlaczego wolno ci z nich korzystać? ”Posiadanie danych i prawo do korzystania z nich to nie to samo. Steve Trucking ma numer telefonu odbiorcy, żeby koordynować dzisiejszą dostawę. Czy to czyni go listą marketingową? Nie. Podstawa prawna zależy od jurysdykcji i sytuacji, a kieruje tym dział prawny, ale architektura musi nieść odpowiedź: dlaczego dane zebrano, jakie użycie dopuszczono, czy potrzebna była zgoda, czy jej udzielono, czy ją wycofano i dla jakiego kanału, adresu i celu. Pozwolenie na korzystanie z danych musi dać się zapisać jako dane, bo dokument z polityką nie podejmie decyzji w czasie działania systemu. Następny moduł to modeluje.
Zbieranie mniej to decyzja architektoniczna
Dział zatytułowany „Zbieranie mniej to decyzja architektoniczna ”Jednym z najmocniejszych mechanizmów ochrony prywatności jest niezbieranie danych albo niekopiowanie ich tam, gdzie nie są potrzebne. Czy Snowflake potrzebuje numeru telefonu odbiorcy? Czy analityka potrzebuje pełnego adresu? Czy sandbox potrzebuje prawdziwych zdjęć z dostaw? Czy agent potrzebuje danych osobowych odbiorcy, żeby odpowiedzieć na to pytanie? Jeśli nie, najmocniejszym mechanizmem może być nieumieszczanie ich tam. Każda kopia, której nie zrobisz, to kopia, której nie musisz zabezpieczać, przechowywać, usuwać, śledzić pod kątem zgód, audytować ani zgłaszać przy naruszeniu. Najtańsze w zarządzaniu dane wrażliwe to te, których nigdy nie skopiowano.
Retencja jest częścią modelu
Dział zatytułowany „Retencja jest częścią modelu ”„Na razie trzymamy wszystko” to polityka retencji. Tyle że zła. Dla ważnych danych chcę wiedzieć już w fazie projektu, jak długo ich potrzebujemy i dlaczego; czy jakaś regulacja wyznacza minimum, a inna maksimum; kiedy zaczyna biec termin; i co się dzieje na końcu: usunięcie, archiwizacja, deidentyfikacja, i gdzie są kopie? Dokumenty finansowe mogą wymagać przechowywania przez określony czas. Kod do bramy odbiorcy nie ma żadnego celu lata po dostawie. Te decyzje nie czekają, aż baza danych urośnie.
Anonimizowane, pseudonimizowane, szyfrowane, maskowane
Dział zatytułowany „Anonimizowane, pseudonimizowane, szyfrowane, maskowane ”Zamień „Jane Smith” na 7F92A1. Czy Jane jest zanonimizowana? Nie, jeśli inna tabela nadal mówi 7F92A1 = Jane Smith. To pseudonimizacja: bezpośredni identyfikator zostaje zastąpiony, ale dane da się ponownie powiązać za pomocą informacji przechowywanych osobno, a według RODO dane spseudonimizowane to nadal dane osobowe (art. 4 pkt 5). Anonimizacja idzie dalej: danych nie da się już rozsądnie powiązać z osobą (motyw 26). Kiedy więc ktoś mówi „nie musimy usuwać, po prostu usuniemy nazwisko”, uważaj. Jeśli osobę nadal da się rozsądnie zidentyfikować, ta granica nie została przekroczona. Czy wynik spełnia wymogi prawa, decyduje dział prawny; zadaniem architekta jest powiedzieć dokładnie, co robi system: czy da się to ponownie powiązać, jakie klucze zostają, gdzie są mapowania?
Używaj tych słów precyzyjnie, bo rozwiązują różne problemy. Szyfrowanie chroni dane przed nieuprawnionym ujawnieniem; uprawniony użytkownik nadal może je odszyfrować. Maskowanie zmienia to, co widzą określeni użytkownicy albo środowiska. Pseudonimizacja oddziela bezpośrednią tożsamość, zachowując drogę powrotną. Anonimizacja usuwa rozsądną możliwość zidentyfikowania osoby. Tylko ta ostatnia wyprowadza dane z kategorii „osobowych”.
Regulacja staje się wymaganiami
Dział zatytułowany „Regulacja staje się wymaganiami ”Dział prawny nie musi mówić mi, żebym utworzył zestaw uprawnień; to moja strona linii. Dział prawny może powiedzieć: „tylko pracownicy z uzasadnioną potrzebą biznesową mogą mieć dostęp do tej kategorii danych osobowych”. Wtedy tłumaczę: kim oni są, jak identyfikujemy tę kategorię, jak nadawany jest dostęp, co się dzieje, gdy ktoś zmienia stanowisko, czy integracja może je czytać, czy agent może, czy można je eksportować i jak udowodnimy, kto je widział? Właściciele ustalają politykę; architekci ją egzekwują. Dział prawny i dział zgodności ustalają obowiązek, właściciele danych ustalają politykę biznesową, a architekt projektuje egzekwowanie.
Od regulacji do dowodu: dział prawny interpretuje, właściciel ustala politykę, architekt sprawia, że to działa i da się to udowodnić.
I zgodność to nie produkt. Nie da się kupić „zgodność: włączona”. Szyfrowanie może wspierać wymaganie, funkcje audytu dostarczają dowodów, narzędzia retencji wykonują politykę, dane o zgodach wspierają dozwolone użycie, ale licencja na funkcję nie czyni architektury zgodną z przepisami. Zgodność bierze się z całego projektu: ludzi, polityki, procesu, danych, mechanizmów kontroli i dowodów. Salesforce jest jego częścią, a nie całością. A jeśli polityka jest na tyle ważna, żeby ją egzekwować, zapytaj, czy jest na tyle ważna, żeby ją udowodnić: kto miał dostęp do tego rekordu 17 marca, kto zmienił to pole, co zawierał tamten eksport? Moduł 6 omawia dowody.
Prywatność zmienia krajobraz
Dział zatytułowany „Prywatność zmienia krajobraz ”W Steve Trucking dane osobowe odbiorcy przychodzą przez trzy integracje partnerów. Salesforce potrzebuje ich do realizacji dostaw; ekipy potrzebują części z nich, tylko dla własnych przystanków, tylko w dniu dostawy; Snowflake chce analityki dostaw; finanse potrzebują dość, żeby wystawić fakturę, ale nie tego, co widzi ekipa. A żaden partner detaliczny nigdy nie może widzieć odbiorców innego. Prywatność zmienia strzałki: pewne pola nie idą do Snowflake, analityka dostaje mniej identyfikowalną wersję, ekipy widzą tylko swoje przystanki, retencja w dalszych systemach różni się od operacyjnej. Wymaganie dotyczące prywatności nie stoi obok diagramu krajobrazu. Zmienia go.
Pytania, które przetrwają regulacje
Dział zatytułowany „Pytania, które przetrwają regulacje ”Regulacje się zmieniają, więc noś ze sobą trwały zestaw pytań o każde dane wrażliwe albo regulowane:
- Czym są? Osobowe, wrażliwe, finansowe, zdrowotne, płatnicze, dotyczące dzieci albo regulowane w inny sposób?
- Gdzie mieszkają? Każda kopia: integracje, historia, analityka, archiwa, sandboxy, logi, użycie przez AI.
- Dlaczego wolno nam z nich korzystać? Jaki cel i jaka podstawa prawna obowiązują? Czy w grę wchodzi zgoda?
- Kto może z nich korzystać? Ludzie, systemy, partnerzy, integracje, agenci.
- Jak długo je trzymamy i co się dzieje na końcu?
- Czy osoba może wykonywać swoje prawa do nich? Dostęp, sprostowanie, usunięcie, przenoszenie, sprzeciw, zgodnie z przepisami.
- Czy możemy udowodnić, co się wydarzyło? Dostęp, zmiany, eksporty, zgody, usunięcie, retencja.
Zarządzanie AI staje się prawem
Dział zatytułowany „Zarządzanie AI staje się prawem ”AI dodaje kolejnego odbiorcę zarządzanych danych. Czy system AI może używać tych danych, w jakim celu, jako ugruntowania, w połączeniu z czym, powtarzając je w odpowiedzi, logując gdzie i jak długo? Zarządzanie AI przechodzi z polityk firmowych do prawa: akt w sprawie sztucznej inteligencji Unii Europejskiej (AI Act, rozporządzenie (UE) 2024/1689 (opens in a new tab)) to pierwszy szeroki przykład. To, czego wymaga, zależy od systemu i zastosowania. Kierunek dla architektów jest jasny: AI nie stoi poza ładem danych; to kolejny odbiorca zarządzanych danych.
Co tu decyduje architekt
Dział zatytułowany „Co tu decyduje architekt ”- Gdzie w krajobrazie dane regulowane albo wrażliwe wchodzą, mieszkają, przemieszczają się i są kopiowane.
- Jak polityka prawna i polityka zgodności stają się egzekwowalnymi wymaganiami, bez interpretowania prawa przez architekta.
- Czy każdy system, który otrzymuje dane wrażliwe, ich potrzebuje, czy wystarczyłaby mniej identyfikowalna wersja.
- Jak retencja, usuwanie, anonimizacja, pseudonimizacja, ochrona i dowody kształtują cykl życia danych.
- Jakie dowody muszą istnieć, żeby pokazać, że ważne mechanizmy kontroli naprawdę zadziałały.
Regulacje nie stają się architekturą przez umieszczenie ich nazw na slajdzie. Stają się nią, gdy zmieniają sposób, w jaki dane są zbierane, klasyfikowane, przenoszone, chronione, przechowywane, usuwane i udowadniane.
Do zgłębienia
Dział zatytułowany „Do zgłębienia ”- Oficjalne źródła regulacji są podlinkowane w tabeli powyżej, sprawdzono 2026-10-14.
- Rozporządzenie (UE) 2016/679 (RODO) (opens in a new tab): art. 3 (zakres terytorialny), art. 4 pkt 5 (pseudonimizacja), motyw 26 (informacje anonimowe).
- Rozporządzenie (UE) 2024/1689 (akt w sprawie sztucznej inteligencji) (opens in a new tab), EUR-Lex.