Проблем Token Mapping
Организације које користе ХИ за покривене клијента суочавају се са специфичним техничким изазовом са анонимизацијом: сложени ток рада захтева да анонимизирани уноси произведу одговоре који могу бити деанонимизирани за агента човека.
Ток рада без token mapping: жалба клијента која садржи "Maria Schmidt" је анонимизирана у "[CUSTOMER_1]" пре ХИ обраде. Claude обрађује анонимизирану жалбу и нацрта одговор: "Dear [CUSTOMER_1], извињавамо се за кашњење са вашом наруџбином." Рукователац захтева мора ручно да замени "[CUSTOMER_1]" са "Maria Schmidt" пре него што пошаље. На 200 клијента интеракције дневно, ручна замена жетона конзумира значајно време агента - довољно да негира продуктивност користи од ХИ помоћи.
Ток рада са сесијом-трајном token mapping: иста анонимизација производа табелу на картирање задржана у тренутној сесији. "[CUSTOMER_1]" → "Maria Schmidt." Када је Claude-ов нацрт одговора приказан рукователачу захтева, аuto-decrypt слој примени сесиону карту и агент видит "Dear Maria Schmidt" - право име, већ опорављено. Агент преглед и пошаље. Никакве ручне замене жетона. GDPR заштита је радила у пост и потпуно.
Конзистентност сесије
Token mapping мора бити конзистентан унутар сесије. Ако је исто име клијента анонимизирано у два различита дела исте разговора - једном у почетној жалби и једном у праћење - мора да се映射 на исти жетон. "[CUSTOMER_1]" мора увек да се односи на исту особу унутар сесије; Claude-ов разум разговоре зависи од конзистентно слідження идентитета.
Без конзистентности на нивоу сесије, Claude-ови одговори могу да збуња више клијената (ако је "[CUSTOMER_1]" у првој поруци и "[CUSTOMER_1]" у трећој поруци да се односе на различите особе), производећи неуклучене одговоре које агент не може користити.
GDPR Чланак 4(5) препознаје псеудонимизацију као технику обраде која смањује ризик од компатибилности. EDPB смернице из 2022 захтевају да псеудонимизирани кључ (у овом случају, табела token mapping) буде одржана одвојена од псеудонимизираних podataka. Сесиона token mapping задовољава овај захтев: табела на карти је одржана у прегледачу сесији, не пребачена са анонимизираним podacima на Claude-ове серверe.
Случај употребе осигурања преваре
Немачка компанија за осигурање са ХИ-побрајаним системом обраде захтева обрађује е-поште жалби клијената. Имена клијента, број полисе и износи захтева су анонимизирани пре Claude обрађива е-поште. Claude нацрта одговоре користећи анонимизиране жетоне. Аuto-decrypt слој у Chrome Екстензији враћа оригиналне информације клијента у Claude-ов нацрт пре него што је приказан рукователачу захтева. Рукователац преглед нацрт, прави било које неопходне прилагођавања и пошаље финални одговор са правим именима клијента.
GDPR калкулација компатибилности: подаци пребачени на Claude-ове US серверe садржи "[CUSTOMER_1]", "[POLICY_2024-08847]" и "[AMOUNT_1]" - не лични подаци као дефиниција GDPR. Право име и број полисе клијента остају у Немачкој на прегледачу рукователача захтева. GDPR Чланак 46 питање преноса podataka - која заштита се примењује на преносе личних podataka у US? - не настаје јер лични подаци нису били пребачени.
Извори: