Pseudonimizujesz dane od lat. Tylko nie w pracy.

Asia z działu supportu przy pierwszym podejrzliwym spojrzeniu partnera stała się "osobą z helpdesku." Potem "kimś z IT." Potem "no wiesz, tym supportem." Żadnych kursów. Żadnego wdrożenia. Jedna kolacja i gotowy system pseudonimizacji działający w czasie rzeczywistym.

Zanim przejdziemy do definicji z art. 4 RODO – zatrzymajmy się przy tym przykładzie przez chwilę.

Co tak naprawdę zrobiłeś?

Zastąpiłeś dane identyfikujące – imię, nazwisko, stanowisko, dział – czymś co nie zdradza o kogo chodzi, ale nadal pozwala Ci wykonać robotę. Rozmowa przy kolacji nadal ma sens. Wątek jest zrozumiały. Kontekst zachowany.

Tylko że Asia Kowalska oficjalnie nie istnieje w tej narracji.

To jest pseudonimizacja. Intuicyjna, skuteczna, działająca w czasie rzeczywistym bez żadnej dokumentacji i bez żadnego szkolenia.

Problem polega na tym że w systemach produkcyjnych, w modelach AI i w bazach danych do testów – Asia Kowalska wciąż jest Asią Kowalską. Z PESEL-em, adresem i historią zakupów.

Bo nikt przy projektowaniu tych systemów nie patrzył podejrzliwie na arkusz Excela.

Czym jest pseudonimizacja według RODO

Art. 4 pkt 5 RODO definiuje pseudonimizację jako przetwarzanie danych osobowych w taki sposób by nie można ich było już przypisać konkretnej osobie bez użycia dodatkowych informacji – pod warunkiem że te dodatkowe informacje są przechowywane osobno i są objęte środkami technicznymi i organizacyjnymi uniemożliwiającymi ich przypisanie zidentyfikowanej osobie fizycznej.

Przetłumaczmy to na język kolacji.

Asia Kowalska staje się "ID_7734." Gdzieś osobno – w zaszyfrowanej tabeli do której masz tylko Ty dostęp – jest informacja że ID_7734 to Asia Kowalska. Bez tej tabeli ID_7734 to nic. Z tą tabelą – wiesz wszystko.

Pseudonimizacja nie niszczy danych. Rozdziela dane od klucza który je identyfikuje.

I właśnie dlatego RODO ją lubi – ale nie zwalnia z obowiązków tak jak anonimizacja.

Pseudonimizacja to nie anonimizacja. Różnica jest fundamentalna.

Tu jest pułapka w którą wpada większość firm.

Anonimizacja jest nieodwracalna. Dane zostały zniszczone jako dane osobowe. Nie możesz wrócić do Asi Kowalskiej bo klucz nie istnieje. RODO przestaje obowiązywać bo nie ma już danych osobowych.

Pseudonimizacja jest odwracalna. Klucz istnieje. Ktoś go ma. W określonych warunkach można wrócić do Asi Kowalskiej.

Dlatego dane pseudonimizowane nadal są danymi osobowymi w rozumieniu RODO. Nadal wymagają podstawy prawnej przetwarzania. Nadal obowiązuje minimalizacja, retencja i bezpieczeństwo.

Pseudonimizacja zmniejsza ryzyko – ale nie eliminuje obowiązków.

Firma która myśli że pseudonimizacja załatwia RODO jest jak ktoś kto zamienił Asię na "tę z helpdesku" ale zostawił jej numer telefonu przyklejony do lodówki.

Gdzie pseudonimizacja ma realne zastosowanie

Testowanie systemów.

To jest największy i najczęściej ignorowany problem w polskich firmach. Dział IT potrzebuje danych do testowania nowego systemu. Bierze dump produkcyjnej bazy danych bo "tak jest najłatwiej." W środowisku testowym lądują prawdziwe dane klientów z PESEL-ami i historiami transakcji.

Środowisko testowe ma zazwyczaj znacznie słabsze zabezpieczenia niż produkcja. Dostęp ma więcej osób. Logi są mniej dokładne. Backupy mniej rygorystyczne.

Pseudonimizacja przed przekazaniem danych do testów jest tu oczywistym rozwiązaniem. Systemy testowe dostaną dane które wyglądają prawdziwie – właściwy format, właściwa struktura, właściwe relacje między tabelami. Bez prawdziwych danych konkretnych ludzi.

Trenowanie modeli AI.

Model który uczy się na danych klientów nie potrzebuje wiedzieć że Jan Kowalski z Warszawy kupił trzy razy ten sam produkt. Potrzebuje wiedzieć że klient z profilem X kupił trzy razy produkt Y w przedziale cenowym Z.

Pseudonimizacja przed przekazaniem danych do trenowania modelu – gdzie to możliwe – zmniejsza ryzyko wycieku danych osobowych przez sam model. Bo modele językowe mają tendencję do zapamiętywania konkretnych przykładów z danych treningowych.

Analityka i raportowanie.

Raporty sprzedażowe, analizy zachowań klientów, dashboardy dla zarządu – w większości przypadków nie wymagają prawdziwych danych osobowych. Wymagają zagregowanych wzorców. Pseudonimizacja na poziomie hurtowni danych pozwala analitykom robić swoją robotę bez dostępu do pełnych danych identyfikujących.

Badania i rozwój.

Firmy które chcą dzielić się danymi z zewnętrznymi badaczami, partnerami lub uczelniami – pseudonimizacja pozwala zachować wartość analityczną danych przy drastycznym ograniczeniu ryzyka identyfikacji konkretnych osób.

Jak pseudonimizacja działa technicznie

Nie ma jednej metody. Są różne podejścia w zależności od tego czego potrzebujesz.

Tokenizacja. Dane identyfikujące zastępowane są losowymi tokenami. Tabela mapowania token-dane przechowywana osobno z ograniczonym dostępem. Najpopularniejsza metoda w systemach płatniczych.

Haszowanie. Dane przepuszczane przez funkcję haszującą – ten sam input daje zawsze ten sam output ale z outputu nie da się odtworzyć inputu bez tęczowych tablic. Przydatne gdy nie potrzebujesz odwrócenia pseudonimizacji – tylko potwierdzenia że dwa rekordy dotyczą tej samej osoby.

Szyfrowanie deterministyczne. Asia Kowalska zawsze staje się tym samym zaszyfrowanym ciągiem znaków. Pozwala na łączenie rekordów bez ujawniania tożsamości.

Generalizacja i perturbacja. Zamiast usuwać dane – zmniejszasz ich precyzję. Dokładny wiek zastępujesz przedziałem wiekowym. Dokładny adres zastępujesz kodem pocztowym lub dzielnicą. Dokładna kwota transakcji zastępowana jest przedziałem.

Wybór metody zależy od tego do czego dane będą używane po pseudonimizacji i jak bardzo rygorystyczna musi być ochrona.

Gdzie pseudonimizacja nie wystarczy

Pseudonimizacja ma swoje granice których nie wolno ignorować.

Problem re-identyfikacji.

Jeśli masz dość informacji kontekstowych możesz zidentyfikować pseudonimizowaną osobę nawet bez klucza.A.

Pseudonimizacja która usuwa imię i PESEL ale zostawia datę urodzenia, dzielnicę zamieszkania i szczegółową historię zakupów może być bezużyteczna jako ochrona przed re-identyfikacją przez kogoś kto ma dostęp do innych zbiorów danych.

Klucz musi być naprawdę bezpieczny.

Jeśli klucz mapujący pseudonimy na prawdziwe tożsamości wycieknie razem z pseudonimizowanymi danymi – pseudonimizacja jest bezwartościowa. Przechowywanie klucza razem z danymi które miał chronić to jak przyklejenie kombinacji do sejfu.

Nie zastępuje innych środków bezpieczeństwa.

Pseudonimizacja jest jednym z narzędzi a nie kompletnym rozwiązaniem. Art. 25 RODO wymaga privacy by design i privacy by default – pseudonimizacja jest tu wymieniana jako przykład odpowiedniego środka technicznego. Ale nadal potrzebujesz właściwej kontroli dostępu, szyfrowania w spoczynku i w transmisji, logowania i monitorowania.

Twój partner ma rację. Tylko że nie wie że ją ma.

Wróćmy do kolacji.

Intuicja która kazała Ci zamienić Asię Kowalską na "kogoś z helpdesku" była poprawna. Zastosowałeś minimalizację danych – przekazałeś tylko tyle informacji ile było potrzebne do wykonania zadania. Zastosowałeś pseudonimizację – zastąpiłeś dane identyfikujące czymś co nie ujawnia tożsamości.

I zadziałało. Rozmowa była możliwa. Żadna tożsamość nie wyciekła.

W systemach produkcyjnych nikt nie patrzy podejrzliwie na arkusz Excela. Nie ma presji emocjonalnej która wymusza minimalizację danych. Jest presja biznesowa która idzie w przeciwnym kierunku – więcej danych, szybciej, najlepiej produkcyjne żeby były "prawdziwe."

Pseudonimizacja jest technicznym odpowiednikiem tej kolacyjnej intuicji. Mechanizmem który wymusza minimalizację danych nawet gdy nikt nie patrzy podejrzliwie.

I który sprawia że Asia Kowalska może spokojnie jeść kolację nie wiedząc że jej dane właśnie trenują model AI w środowisku testowym bez żadnych zabezpieczeń.

Jaka jest różnica między pseudonimizacją a anonimizacją i która jest lepsza?

Zależy od celu. Anonimizacja jest nieodwracalna – dane przestają być danymi osobowymi i RODO przestaje obowiązywać. Pseudonimizacja jest odwracalna – dane nadal są danymi osobowymi ale ryzyko ich ujawnienia jest znacznie mniejsze. Anonimizacja jest "lepsza" jeśli nie potrzebujesz wracać do tożsamości. Pseudonimizacja jest lepsza gdy potrzebujesz zachować możliwość powiązania rekordów – na przykład przy śledzeniu historii klienta w systemie analitycznym bez ujawniania kto to jest. W praktyce prawdziwa anonimizacja jest trudniejsza do osiągnięcia niż się wydaje – zbyt wiele kontekstu pozwala na re-identyfikację.

Czy pseudonimizacja zwalnia z obowiązku informacyjnego wobec klientów?

Nie. Dane pseudonimizowane nadal są danymi osobowymi w rozumieniu RODO bo klucz istnieje i re-identyfikacja jest możliwa. Obowiązek informacyjny z art. 13 i 14 RODO obowiązuje dla danych pseudonimizowanych tak samo jak dla danych jawnych. Pseudonimizacja wpływa na ocenę ryzyka i może zmniejszyć obowiązki przy naruszeniu ochrony danych – ale nie eliminuje podstawowych obowiązków administratora.

Dział IT chce użyć produkcyjnych danych klientów do testów. Co im odpowiedzieć?

Że to bardzo bardzo zła praktyka. Dane produkcyjne w środowisku testowym to klasyczne naruszenie zasady minimalizacji danych i zasady integralności i poufności z art. 5 RODO. Środowiska testowe mają słabsze zabezpieczenia, dostęp ma więcej osób, logi są mniej dokładne. Rozwiązanie jest jedno: dane testowe powinny być pseudonimizowane lub syntetyczne – wygenerowane w sposób który zachowuje strukturę i właściwości statystyczne danych produkcyjnych bez użycia prawdziwych danych osobowych. Narzędzi do generowania syntetycznych danych jest coraz więcej i coraz są prostsze w użyciu.

Czy klucz do pseudonimizacji może leżeć w tej samej bazie co pseudonimizowane dane?

Nie – i to jest jeden z błędów implementacyjnych. Klucz przechowywany razem z danymi które miał chronić jest jak kombinacja przyklejona do sejfu. Jeśli baza wycieknie – wyciekają dane i klucz jednocześnie. Pseudonimizacja przestaje mieć jakąkolwiek wartość ochronną. Klucz musi być przechowywany osobno z ograniczonym dostępem i silnym szyfrowaniem. Dostęp do klucza powinien być logowany i regularnie audytowany.

Jak pseudonimizacja wpływa na obowiązki przy naruszeniu ochrony danych?

Pozytywnie – i to jest jeden z praktycznych argumentów za jej wdrożeniem. Art. 34 RODO zwalnia z obowiązku powiadamiania osób których dane dotyczą gdy dane były odpowiednio zabezpieczone – na przykład zaszyfrowane lub pseudonimizowane. Jeśli wyciekły dane pseudonimizowane bez klucza – ryzyko dla osób fizycznych jest znacznie niższe i obowiązek powiadomienia może nie powstać. Możliwe że nadal masz obowiązek zgłoszenia naruszenia do UODO jeśli stanowi ono ryzyko dla praw i wolności – ale skala konsekwencji jest inna niż przy wycieku danych jawnych.

Czy model AI wytrenowany na pseudonimizowanych danych może "odtworzyć" prawdziwe dane?

To jest bardziej realne niż większość firm zakłada. Modele językowe i inne modele uczenia maszynowego mają tendencję do zapamiętywania konkretnych przykładów z danych treningowych – szczególnie gdy te przykłady są unikalne lub rzadkie. Zjawisko nazywa się memorization i jest aktywnym obszarem badań w dziedzinie prywatności AI. Pseudonimizacja zmniejsza to ryzyko ale go nie eliminuje. Dodatkowe zabezpieczenie to differential privacy – technika która dodaje statystyczny szum do danych treningowych utrudniając odtworzenie konkretnych rekordów z modelu.

Czy pseudonimizacja jest wymagana przez RODO czy tylko zalecana?

RODO nie nakazuje pseudonimizacji wprost – ale wymienia ją jako przykład odpowiedniego środka technicznego w art. 25 privacy by design i w art. 32 bezpieczeństwo przetwarzania. W praktyce przy przetwarzaniu danych wrażliwych lub danych na dużą skalę brak pseudonimizacji tam gdzie byłoby to możliwe może być traktowany przez UODO jako brak odpowiednich środków bezpieczeństwa. Szczególnie gdy dojdzie do incydentu i organ nadzorczy zapyta dlaczego dane testowe zawierały prawdziwe dane klientów.

Artykuł powstał przy wsparciu AI. Weryfikacja merytoryczna i redakcja: Damian Bielecki, Typ od RODO.