Zgoda i prawo do bycia zapomnianym

🌐 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)

Obraz wygenerowany przez AI

Przetłumaczone przez AI. Jeszcze niesprawdzone przez społeczność. Czytaj po angielsku

Moduł 5 z 6 w rozdziale Jakość danych i ład danych, rozdziale 5 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Prawo o prywatności kształtuje projekt · Dalej: Chroń, przechowuj, udowadniaj

Pytanie, na które odpowiada ten moduł: jak projektować pod zgody i pod usuwanie danych osoby?

Steve Trucking ma numer telefonu odbiorcy. Proste pytanie: czy możemy wysłać mu SMS-a? Może. W sprawie dzisiejszej dostawy? Jutrzejszej? Czy możemy użyć numeru do promocji? A jeśli powiedział „żadnych SMS-ów” albo „tak” dla informacji o dostawie, a „nie” dla marketingu, a potem zmienił zdanie?

Teraz w drugą stronę. Odbiorca mówi: usuńcie moje dane osobowe. Gdzie są? Pewnie w Salesforce, ale już wiemy, że to nie cała odpowiedź. Przyszły od partnera detalicznego. Mogą być w platformie danych klientów, w historii pól, w archiwum, w uwadze do dostawy, w eksporcie, w logu integracji, w rozmowie agenta. Zgoda i usuwanie brzmią jak pytania o politykę, ale w końcu system musi na nie odpowiedzieć. To jest architektura.

Zgoda to dane

Pierwsza zasada: zgoda to dane. Nie sprowadzaj jej do Has_Opted_In__c = true. Prawdziwe pytanie nigdy nie brzmi tylko „czy wyraził zgodę?”. Brzmi: zgoda na co, przez jaki kanał, na jaki adres albo numer, w jakim celu, kiedy, czy się zmieniła i czy potrafimy to udowodnić? Jeśli biznes podejmuje decyzje na podstawie tych odpowiedzi, muszą być przechowywane jako dane ustrukturyzowane. Akapit w polityce prywatności nie wystarczy, pole wyboru w formularzu internetowym też nie: pole wyboru rejestruje zdarzenie; architektura musi zachować to, co to zdarzenie znaczy.

Użyj modelu, który Salesforce już zbudował

Moje stanowisko: używaj standardowego modelu zgód wszędzie, gdzie się da, zamiast budować to samo od nowa w polach niestandardowych. Model danych zgód Salesforce zarządza zgodami na czterech poziomach, a każdy to bardziej szczegółowe pytanie (Understand the Salesforce Consent Data Model (opens in a new tab), po angielsku):

• Zgoda globalna, na osobie (Individual): kim jest ta osoba i czy powiedziała „nie” wszystkiemu?
• Zgoda dla kanału kontaktu (Contact Point Type Consent): czy możemy używać tego rodzaju kanału, na przykład SMS-ów albo e-maili?
• Zgoda dla punktu kontaktu: a co z tym konkretnym numerem telefonu czy adresem e-mail?
• Cel wykorzystania danych (Data Use Purpose): z jakiego powodu: powiadomienia o dostawie, serwis, marketing?

Razem architektura może odpowiedzieć na pytanie „czy możemy użyć informacji o tej osobie, przez ten punkt kontaktu, w tym celu?”, co jest dużo bardziej przydatne niż „zgoda = tak”. Udział może brać każdy rekord związany z osobą: leady, kontakty, konta osób, użytkownicy.

Click to enlarge

Cztery pytania, każde węższe od poprzedniego. Jedna flaga opt-in nie odpowiada dobrze na żadne z nich.

Cel ma znaczenie

Partner detaliczny wysyła Steve Trucking numer odbiorcy, żeby ekipa mogła koordynować dostawę. To nie czyni odbiorcy leadem marketingowym. Te same dane mogą mieć różne dozwolone zastosowania: koordynacja dostawy, kontakt serwisowy, marketing, personalizacja przez AI. Jeśli polityka albo prawo traktuje je różnie, model musi je odróżniać. Pytanie nie brzmi: czy mamy numer telefonu? Brzmi: co wolno nam z nim zrobić?

A zgoda nie zawsze jest podstawą prawną. Niektóre zastosowania opierają się na innych podstawach przewidzianych przez prawo, a to ustala dział prawny. Nie buduj architektury, która zakłada, że każda decyzja o prywatności to pole wyboru „wyrażam zgodę”. Wspieraj to, co mówi polityka: jeśli zastosowanie zależy od zgody, modeluj i egzekwuj zgodę; jeśli obowiązuje inna podstawa, nadal przechowuj to, co potrzebne, żeby zdecydować, czy zastosowanie jest dozwolone.

Zgoda ma cykl życia i autorytet

Ludzie udzielają zgody, wycofują ją, zmieniają preferencje, zmieniają numery. Biznes dodaje nowe cele; prawo się zmienia. Zaprojektuj więc cykl życia: co wybrano, kiedy, jak, w jakim celu i co się dzieje przy wycofaniu. I tu robi się ciekawie: gdy odbiorca wycofuje zgodę, Salesforce o tym wie. Czy wie platforma do wysyłki wiadomości? Analityka? Agent? Zgoda, która mieszka w jednym systemie, podczas gdy inne działają na nieaktualnym pozwoleniu, to słaby mechanizm kontroli.

To oznacza pytanie, który system jest nadrzędny dla zgód. Salesforce, platforma preferencji, coś innego? Bez względu na odpowiedź nie pozwól, żeby pięć systemów niezależnie decydowało, czy ta sama osoba zgodziła się na to samo zastosowanie. Zgoda potrzebuje tego, czego potrzebują wszystkie zarządzane dane: właściciela, nadrzędnego rekordu, sposobu synchronizacji i egzekwowania.

Teraz osoba mówi: zapomnijcie mnie

Pierwszy odruch to usunąć kontakt i uznać sprawę za zamkniętą. Ale dane osoby mogą być na kontakcie, na dostawie, w uwadze do dostawy, w zgłoszeniu, na zdjęciu, w historii pól, w Snowflake, w archiwum, w logu integracji, w indeksie wyszukiwania albo w historii rozmów agenta. Dlatego moje stanowisko w sprawie usuwania zaczyna się wcześniej: usuwanie jest w praktyce rzadkie i trudne, więc najpierw kontroluj, dokąd trafiają dane osobowe. Projektuj tak, żeby lądowały w jak najmniejszej liczbie miejsc. Potem, gdy przyjdzie żądanie, zaciemnij je albo odłącz tam, gdzie to spełnia politykę, i wyśledź każdą kopię: historię pól, archiwa, Data 360, a teraz także indeksy wyszukiwania i rozmowy agentów.

Nie zaczynaj tropienia, gdy przyjdzie żądanie. Wtedy jest już za późno, żeby zacząć rozumieć krajobraz. Słownik, pochodzenie i klasyfikacja z modułu 3 to nie była papierologia; to one to umożliwiają. Wiesz już, które pola zawierają dane osobowe i dokąd poszły kopie.

Click to enlarge

Żądanie „zapomnijcie mnie” to decyzja dla każdej kopii.

Zegar tyka

Te żądania mają terminy. Według RODO organizacja musi zareagować na żądanie osoby bez zbędnej zwłoki i w ciągu miesiąca od jego otrzymania; przy żądaniach złożonych albo licznych termin można przedłużyć o kolejne dwa miesiące, ale osobę trzeba o tym poinformować w ciągu pierwszego miesiąca, podając powody (art. 12 ust. 3, rozporządzenie (UE) 2016/679 (opens in a new tab)). Inne przepisy ustalają własne terminy; dział prawny powie ci, które mają zastosowanie. Tak czy inaczej, miesiąc to za mało, żeby odkryć krajobraz. To termin, który mapa kopii musi pobić.

Usunąć, zdeidentyfikować czy zachować?

Żądanie nie musi oznaczać, że wszystko wszędzie znika. Niektóre rekordy trzeba albo wolno zachować; niektóre rekordy operacyjne mogą zostać, ale przestać identyfikować osobę; niektóre dane da się zdeidentyfikować. Decydują obowiązująca polityka i prawo; architektura wspiera każdy wynik, miejsce po miejscu: usuń, zdeidentyfikuj albo zachowaj w ramach zatwierdzonego wymagania (a wtedy kto może je widzieć, jak długo, dlaczego?).

Pamiętaj rozróżnienie z modułu 4. Odłączenie liczy się jako zapomnienie tylko wtedy, gdy osoby nie da się rozsądnie ponownie zidentyfikować. Dane spseudonimizowane to nadal dane osobowe. Nie używaj zaciemniania jako skrótu omijającego wymóg prawny.

Nie usuniesz tego, czego nie znajdziesz

Zanim kogoś usuniesz, musisz go znaleźć. Żądanie przychodzi z adresu e-mail. Jeden partner detaliczny przysłał „Jane Smith”, drugi „J. Smith”, a numer telefonu się zmienił. Odbiorca w ogóle nie jest kontaktem; jego dane leżą na każdej dostawie. Ta sama osoba dostała dostawy dla dwóch różnych partnerów. Jeden system zna ją po e-mailu, inny po identyfikatorze zewnętrznym. Usuwanie zależy od tożsamości, a nie chcesz usunąć danych kogoś innego, bo dopasowanie było zbyt agresywne. Architektura tożsamości jest częścią architektury prywatności.

Steve Trucking jeszcze to utrudnia. Żaden partner detaliczny nigdy nie może widzieć dostaw ani odbiorców innego. Jeśli ta sama osoba dostała dostawy dla dwóch partnerów, operacje muszą trzymać te relacje osobno, a prywatność może nadal potrzebować znaleźć osobę w obu. Nie rozwiązuj prywatności, łamiąc granicę bezpieczeństwa, i nie chroń granicy, czyniąc żądania dotyczące prywatności niemożliwymi. Architektura musi robić jedno i drugie.

Zdjęcia i dowolny tekst to też dane

Łatwo myśleć o prywatności jak o polach: imię i nazwisko, e-mail, telefon, adres. Ale Steve Trucking robi miliony zdjęć z dostaw rocznie, a część z nich pokazuje ludzi albo wnętrze domu. Polityka retencji albo usuwania, która patrzy tylko na pola ustrukturyzowane, jest niekompletna; tak samo taka, która ignoruje pliki, dokumenty, transkrypcje, logi oraz prompty i odpowiedzi AI.

A dowolny tekst jest niebezpieczny. Usuwasz imię i nazwisko, telefon i adres, a potem znajdujesz taką uwagę do dostawy: „Zadzwonić do Jane pod 602-555-0198. Kod do bramy 4821. Pies na podwórku”. Oto i one. Sklasyfikowanie uwag do dostawy jako wrażliwych mówi ci, że może być problem; nie znajduje i nie usuwa danych osobowych z tekstu. Czasem najlepszą odpowiedzią jest w ogóle nie dopuścić, żeby trafiały tam zbędne dane osobowe. Najpierw kontroluj, dokąd trafiają dane osobowe.

Privacy Center to narzędzie, a nie cała architektura

Salesforce Privacy Center pomaga prowadzić te procesy. Jego polityki prawa do bycia zapomnianym buduje się dla każdego obiektu, żeby objąć wszystko, co chcesz usunąć, i uruchamia na konkretnym rekordzie klienta (Delete Data with Right to Be Forgotten Policies (opens in a new tab), po angielsku). To przydatne. Ale „kupiliśmy Privacy Center, więc mamy z głowy” to nie jest architektura. Dane osoby mogą mieszkać poza zasięgiem jakiegokolwiek pojedynczego narzędzia: w Data 360, hurtowni, systemach partnerów, archiwach, logach, wyszukiwarce, plikach, rozmowach agentów. Przedsiębiorstwo nadal potrzebuje odpowiedzi na poziomie przedsiębiorstwa, a ty musisz sprawdzić, co każde narzędzie naprawdę obejmuje, zanim się na nim oprzesz.

Przenoszenie i dowód

Niektóre przepisy dają też ludziom prawo do otrzymania kopii swoich danych. Zauważ, że to ten sam problem odnajdywania: usuwanie pyta, gdzie są dane tej osoby, żebyśmy mogli coś z nimi zrobić? Przenoszenie pyta, gdzie są, żebyśmy mogli je przekazać? Oba opierają się na tożsamości, klasyfikacji, pochodzeniu, inwentarzu systemów i własności.

A potem: jak udowodnisz, że to zrobiono? Żądanie przyjęte, tożsamość zweryfikowana, systemy przeszukane, działania podjęte, wyjątki zapisane, zachowane dane uzasadnione, zakończenie zarejestrowane. Jest tu prawdziwe napięcie: usuwasz czyjeś dane osobowe, zachowując dość dowodów, żeby pokazać, że żądanie obsłużono właściwie. Właśnie dlatego architekci nie powinni sami wymyślać reguł retencji. Dział prawny i dział zgodności decydują, jakie dowody muszą pozostać; architektura je zachowuje, nie zachowując danych, które miały zostać usunięte.

Poza egzaminem: co zmienia AI. AI tworzy nowe cele i nowe kopie. Pozwolenie na użycie danych do świadczenia usługi nie obejmuje automatycznie ugruntowania agenta, personalizacji ani trenowania; cel wykorzystania danych (Data Use Purpose) to naturalne miejsce, żeby je rozróżnić. A dane osobowe mogą przetrwać w promptach, kontekście ugruntowania, rozmowach, podsumowaniach, indeksach wyszukiwania i indeksach wektorowych oraz w logach. „Usunęliśmy rekord źródłowy” to niepełna odpowiedź, jeśli warstwa AI nadal pamięta.

Co tu decyduje architekt

• Jak modeluje się zgody i dozwolone użycie, żeby systemy mogły odpowiedzieć: kto, jaki kanał, jaki punkt kontaktu i jaki cel.
• Który system jest nadrzędny dla zgód i jak wycofania docierają do każdego systemu, który na nich działa.
• Gdzie mogą rozprzestrzeniać się dane osobowe: pola, dowolny tekst, pliki, historia, analityka, archiwa, integracje, wyszukiwanie i AI.
• Jak żądanie odnajduje właściwą osobę i prowadzi do usunięcia, deidentyfikacji albo zatwierdzonej retencji w każdym miejscu.
• Jakie dowody zostają, żeby udowodnić, że zgody i żądania dotyczące prywatności zostały obsłużone.

Zgoda i usuwanie wyglądają na przeciwieństwa (czy możemy używać tych danych? czy możemy przestać i je usunąć?), ale opierają się na tych samych fundamentach: tożsamości, celu, klasyfikacji, pochodzeniu, własności, egzekwowaniu i dowodach. Używaj standardowego modelu zgód, kontroluj, dokąd trafiają dane osobowe, wiedz, gdzie są kopie, i zaprojektuj proces usuwania, zanim przyjdzie pierwsze żądanie. Gdy ktoś pyta „czy możecie mnie zapomnieć?”, architektura potrzebuje lepszej odpowiedzi niż „chyba tak”.

Do zgłębienia

• Pomoc Salesforce, Understand the Salesforce Consent Data Model (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.
• Rozporządzenie (UE) 2016/679 (RODO) (opens in a new tab), art. 12 ust. 3, termin na reakcję na żądanie, sprawdzono 2026-10-14.
• Pomoc Salesforce, Delete Data with Right to Be Forgotten Policies (opens in a new tab) (Privacy Center, po angielsku), sprawdzono 2026-10-14.