Tokenų atvaizdavimas BDAR DI darbo eigos procesuose
Atnaujinta 2026 m.
Jūsų komanda naudoja DI klientų atsakymams rengti. Klientas rašo. Jo vardas anonimizuojamas prieš DI tai pamato. DI parengia atsakymą su vietos rezervuotoju. Agentas turi jį rankiniu būdu pakeisti. Esant 200 sąveikų per dieną, tos sąnaudos greitai kaupiasi.
Sesijomis pagrįstas tokenų atvaizdavimas tai išsprendžia. Jis automatiškai atkuria tikrus vardus.
Problema be tokenų atvaizdavimo
Anonimizacijos veiksmas sukuria tokeną. "Maria Schmidt" tampa [CUSTOMER_1]. Claude parengia: "Gerbiama [CUSTOMER_1], atsiprašome už vėlavimą."
Pretenzijų nagrinėtojas dabar turi pakeisti [CUSTOMER_1] "Maria Schmidt" prieš siunčiant. Esant dideliam kiekiui, šis veiksmas panaikina DI pagalbos tikslą. Tai pasikartojantis darbas, kuris niekur nedingsta.
Kaip veikia sesijų tokenai
Sesija saugo peržvalgos lentelę: [CUSTOMER_1] -> "Maria Schmidt". Kai Claude grąžina savo juodraštį, automatinio iššifravimo sluoksnis nuskaito tą lentelę ir atkuria vardą. Agentas mato "Gerbiama Maria Schmidt" - jau teisingai. Jokio rankinio veiksmo. BDAR apsauga veikia tyliai.
Kodėl sesijų nuoseklumas svarbus
Tokenų lentelė turi būti nuosekli visoje sesijoje. Jei "Maria Schmidt" pasirodo pradiniame skunde ir vėl tolesnėje žinutėje, abu turi būti susieti su [CUSTOMER_1]. Be to Claude gali laikyti juos dviem skirtingais žmonėmis. Jo atsakymas tampa nenuoseklus.
Vienas asmuo gauna vieną tokeną vienai sesijai. Claude tada gali teisingai samprotauti apie pokalbį.
BDAR atitiktis pagal dizainą
BDAR 4 straipsnio 5 dalis apibrėžia pseudonimizavimą kaip rizikos mažinimo techniką. EDPB 2022 m. gairės reikalauja vieno dalyko: raktas turi būti laikomas atskirai nuo pseudonimizuotų duomenų.
Sesijų tokenų lentelės atitinka šią taisyklę. Peržvalga lieka naršyklėje. Ji niekada nesiunčiama Claude. Pasibaigus sesijai, ji dingsta. Jokie asmens duomenys nepasiekia išorinių serverių. 46 straipsnio perdavimo klausimas nekyla.
Draudimo pretenzijos: konkretus pavyzdys
Vokietijos draudimo įmonė apdoroja kliento skundo el. laiškus. Kiekviename el. laiške yra vardas, poliso numeris ir pretenzijos suma.
Prieš DI apdorojimą Chrome plėtinys arba MCP serveris anonimizuoja visus tris laukus. Claude mato [CUSTOMER_1], [POLICY_2024-08847] ir [AMOUNT_1]. Jis parengia atsakymą su tais tokenais.
Automatinio iššifravimo sluoksnis tada atkuria visus tris laukus. Pretenzijų nagrinėtojas juodraštyje mato tikrą vardą ir poliso numerį. Jis peržiūri ir siunčia. Jokio vietos rezervuotojo pakeitimo nereikia.
BDAR rezultatas: Claude JAV serveriams išsiųsti duomenys neapėmė jokių asmens duomenų. Tikras kliento vardas ir poliso numeris liko Vokietijoje, nagrinėtojo naršyklėje.
Ko reikia pilnam procesui
Trys komponentai turi veikti kartu sklandžiai:
1. Nuoseklūs tokenai. Kiekvienas objektas vienai sesijai gauna vieną tokeną. Visada tą patį.
2. Vietinė peržvalgos lentelė. Ji gyvena sesijoje. Ji nesiunčiama DI.
3. Automatinis iššifravimas išvestyje. Lentelė taikoma DI juodraštyje prieš agentui jį matant.
Be visų trijų darbo eigos automatizavimas yra nepilnas. Žiūrėkite Chrome plėtinį ir MCP serverio dokumentus, kad sužinotumėte, kaip kiekvienas komponentas integruojamas.