Mapowanie tokenów w przepływach AI zgodnych z RODO
Zaktualizowano na rok 2026
Twój zespół używa AI do redagowania odpowiedzi do klientów. Klient pisze wiadomość. Jego dane są anonimizowane, zanim AI je zobaczy. AI redaguje odpowiedź z tokenem zastępczym. Konsultant musi ręcznie zamienić token na prawdziwe dane. Przy 200 interakcjach dziennie koszt ten szybko rośnie.
Mapowanie tokenów oparte na sesji rozwiązuje ten problem — automatycznie przywracając prawdziwe dane.
Problem bez mapowania tokenów
Krok anonimizacji tworzy token. „Maria Kowalska” staje się [CUSTOMER_1]. Claude redaguje: „Szanowna [CUSTOMER_1], przepraszamy za opóźnienie.”
Obsługujący sprawę musi teraz zastąpić [CUSTOMER_1] frazą „Maria Kowalska” przed wysłaniem. W skali masowej ten krok niweczy sens korzystania z AI. To powtarzalna praca, która nie znika.
Jak działają tokeny sesyjne
Sesja przechowuje tablicę przeglądową: [CUSTOMER_1] → „Maria Kowalska”. Gdy Claude zwraca swój szkic, warstwa auto-deszyfrowania odczytuje tę tablicę i przywraca imię. Konsultant widzi „Szanowna Maria Kowalska” — już poprawnie. Żadnego ręcznego kroku. Ochrona zgodna z RODO działa w tle.
Dlaczego spójność sesji ma znaczenie
Tablica tokenów musi być spójna przez całą sesję. Jeśli „Maria Kowalska” pojawia się w pierwotnej wiadomości i ponownie w kolejnym pytaniu, obie wystąpienia muszą mapować się na [CUSTOMER_1]. Bez tego Claude może potraktować je jako dwie różne osoby. Odpowiedź staje się niespójna.
Jedna osoba otrzymuje jeden token na sesję. Dzięki temu Claude może poprawnie wnioskować o przebiegu rozmowy.
Zgodność z RODO w założeniu projektowym
Artykuł 4 ust. 5 RODO definiuje pseudonimizację jako technikę redukcji ryzyka. Wytyczne EDPB z 2022 roku stawiają jeden warunek: klucz musi być przechowywany oddzielnie od pseudonimizowanych danych.
Sesyjne tablice tokenów spełniają tę zasadę. Tablica przeglądowa pozostaje w przeglądarce. Nie trafia do Claude. Po zakończeniu sesji zostaje usunięta. Żadne dane osobowe nie docierają do zewnętrznych serwerów. Kwestia przekazywania danych zgodnie z Artykułem 46 nie pojawia się.
Likwidacja szkód: konkretny przykład
Niemiecki ubezpieczyciel przetwarza wiadomości e-mail od klientów ze skargami. Każda wiadomość zawiera imię i nazwisko, numer polisy i kwotę roszczenia.
Przed przetwarzaniem przez AI Rozszerzenie Chrome lub Serwer MCP anonimizuje wszystkie trzy pola. Claude widzi [CUSTOMER_1], [POLICY_2024-08847] i [AMOUNT_1]. Redaguje odpowiedź z tymi tokenami.
Warstwa auto-deszyfrowania następnie przywraca wszystkie trzy pola. Konsultant widzi prawdziwe imię i numer polisy w szkicu odpowiedzi. Przegląda i wysyła. Żadnego ręcznego zastępowania tokenów.
Wynik z perspektywy RODO: dane przesłane na amerykańskie serwery Claude nie zawierały danych osobowych. Prawdziwe imię klienta i numer polisy pozostały w Niemczech — w przeglądarce konsultanta.
Czego wymaga pełna pętla
Trzy komponenty muszą działać razem, aby zapewnić płynny przepływ pracy:
1. Spójne tokeny. Każda encja otrzymuje jeden token na sesję — zawsze ten sam.
2. Lokalna tablica przeglądowa. Działa w ramach sesji. Nie jest przesyłana do AI.
3. Auto-deszyfrowanie na wyjściu. Tablica jest stosowana do szkicu AI, zanim konsultant go zobaczy.
Bez wszystkich trzech elementów konsultanci ręcznie zastępują tokeny. Z wszystkimi trzema przepływ działa automatycznie i pozostaje zgodny z RODO.
Podsumowanie
To podejście zamyka pętlę w pracy wspomaganej przez AI w obsłudze klientów. Anonimizacja chroni dane, zanim dotrą do AI. Auto-deszyfrowanie przywraca prawdziwe dane w odpowiedzi. Konsultanci widzą poprawne dane na każdym etapie. Zgodność z RODO jest zachowana przez cały czas.
Źródła
- Wytyczne EDPB 01/2025 dotyczące pseudonimizacji — Wymogi pseudonimizacji, w tym separacja klucza od pseudonimizowanych danych.
- RODO Artykuł 4 ust. 5 — Prawna definicja pseudonimizacji.
- IAPP: 10 głównych skutków operacyjnych RODO — Jedynie 23% narzędzi do anonimizacji oferuje prawdziwą odwracalność.