Problem mapowania tokenów
Organizacje wykorzystujące AI do procesów związanych z klientami stają przed specyficznym wyzwaniem technicznym związanym z anonimizacją: pełny przepływ pracy wymaga, aby zanonimizowane dane wejściowe generowały odpowiedzi, które mogą być deanonimizowane dla ludzkiego agenta.
Przepływ pracy bez mapowania tokenów: skarga klienta zawierająca "Maria Schmidt" jest anonimizowana do "[CUSTOMER_1]" przed przetwarzaniem przez AI. Claude przetwarza zanonimizowaną skargę i przygotowuje odpowiedź: "Drogi [CUSTOMER_1], przepraszamy za opóźnienie w realizacji Twojego zamówienia." Pracownik zajmujący się roszczeniami musi ręcznie zastąpić "[CUSTOMER_1]" na "Maria Schmidt" przed wysłaniem. Przy 200 interakcjach z klientami dziennie, ręczna wymiana tokenów pochłania znaczną ilość czasu agenta — wystarczająco, aby zniwelować korzyści z wydajności wynikające z pomocy AI.
Przepływ pracy z mapowaniem tokenów z utrzymaniem sesji: ta sama anonimizacja generuje tabelę mapowania przechowywaną w bieżącej sesji. "[CUSTOMER_1]" → "Maria Schmidt." Gdy robocza odpowiedź Claude'a jest wyświetlana pracownikowi zajmującemu się roszczeniami, warstwa auto-dekryptująca stosuje mapowanie sesji i agent widzi "Droga Maria Schmidt" — prawdziwe imię, już przywrócone. Agent przegląda i wysyła. Brak ręcznej wymiany tokenów. Ochrona GDPR działała cicho i całkowicie.
Spójność sesji
Mapowanie tokenów musi być spójne w ramach sesji. Jeśli imię tego samego klienta jest anonimizowane w dwóch różnych częściach tej samej rozmowy — raz w początkowej skardze, a raz w dalszym kontakcie — musi mapować się do tego samego tokena. "[CUSTOMER_1]" zawsze musi odnosić się do tej samej osoby w ramach sesji; rozumowanie Claude'a na temat rozmowy zależy od spójnego śledzenia tożsamości.
Bez spójności na poziomie sesji, odpowiedzi Claude'a mogą wprowadzać w błąd wielu klientów (jeśli "[CUSTOMER_1]" w pierwszej wiadomości i "[CUSTOMER_1]" w trzeciej wiadomości odnoszą się do różnych osób), co prowadzi do niespójnych odpowiedzi, których agent nie może wykorzystać.
Artykuł 4(5) GDPR uznaje pseudonimizację za technikę przetwarzania, która zmniejsza ryzyko zgodności. Wytyczne EDPB z 2022 roku dotyczące pseudonimizacji wymagają, aby klucz pseudonimizacji (w tym przypadku tabela mapowania tokenów) był przechowywany oddzielnie od danych pseudonimizowanych. Mapowanie tokenów na poziomie sesji spełnia ten wymóg: tabela mapowania jest utrzymywana w sesji przeglądarki, a nie przesyłana z danymi zanonimizowanymi do serwerów Claude'a.
Przykład użycia w roszczeniach ubezpieczeniowych
System przetwarzania roszczeń zasilany AI niemieckiej firmy ubezpieczeniowej przetwarza e-maile ze skargami klientów. Imiona klientów, numery polis i kwoty roszczeń są anonimizowane przed przetwarzaniem e-maili przez Claude'a. Claude przygotowuje odpowiedzi, używając zanonimizowanych tokenów. Warstwa auto-dekryptująca w rozszerzeniu Chrome przywraca oryginalne informacje o kliencie w roboczej wersji Claude'a przed jej wyświetleniem pracownikowi zajmującemu się roszczeniami. Pracownik przegląda roboczą wersję, wprowadza niezbędne poprawki i wysyła ostateczną odpowiedź z prawdziwymi imionami klientów.
Obliczenie zgodności z GDPR: dane przesyłane do amerykańskich serwerów Claude'a zawierają "[CUSTOMER_1]", "[POLICY_2024-08847]" i "[AMOUNT_1]" — nie są to dane osobowe w rozumieniu GDPR. Rzeczywiste imię klienta i numer polisy pozostają w Niemczech na przeglądarce pracownika zajmującego się roszczeniami. Pytanie dotyczące transferu danych zgodnie z artykułem 46 GDPR — jakie zabezpieczenia mają zastosowanie do transferów danych osobowych do USA? — nie występuje, ponieważ dane osobowe nie zostały przesłane.
Źródła: