Mapování tokenů pro pracovní postupy AI v souladu s GDPR
Aktualizováno pro rok 2026
Váš tým používá AI k sestavování odpovědí zákazníkům. Zákazník napíše. Jeho jméno je anonymizováno, než AI text uvidí. AI sestaví odpověď se zástupným symbolem. Pracovník ho musí ručně nahradit. Při 200 interakcích denně se tyto náklady rychle nasčítají.
Mapování tokenů na úrovni relace tento problém řeší — skutečná jména se obnoví automaticky.
Problém bez mapování tokenů
Krok anonymizace vytvoří token. „Maria Schmidtová” se stane [CUSTOMER_1]. Claude sestaví: „Vážená [CUSTOMER_1], omlouváme se za prodlení.”
Pracovník vyřizování stížností musí nyní nahradit [CUSTOMER_1] za „Maria Schmidtová” před odesláním. Ve velkém měřítku tento krok popírá smysl asistence AI. Je to opakující se práce, která nezmizí.
Jak fungují tokeny relace
Relace uchovává vyhledávací tabulku: [CUSTOMER_1] → „Maria Schmidtová”. Když Claude vrátí svůj návrh, vrstva automatického dešifrování přečte tuto tabulku a jméno obnoví. Pracovník vidí „Vážená Maria Schmidtová” — již správně. Žádný ruční krok. Ochrana GDPR běží tiše na pozadí.
Proč záleží na konzistenci relace
Tabulka tokenů musí být konzistentní po celou dobu relace. Pokud se „Maria Schmidtová” objeví v původní stížnosti a znovu v navazující zprávě, obě musí být přiřazeny k [CUSTOMER_1]. Bez toho může Claude zacházet s nimi jako se dvěma různými osobami. Odpověď se stane nesouvislou.
Jedna osoba dostane jeden token na relaci. Claude pak může o konverzaci správně uvažovat.
Soulad s GDPR by design
Článek 4 odst. 5 GDPR definuje pseudonymizaci jako techniku snižování rizik. Pokyny EDPB z roku 2022 vyžadují jedno: klíč musí být uchováván odděleně od pseudonymizovaných dat.
Tabulky tokenů relace toto pravidlo splňují. Vyhledávací tabulka zůstává v prohlížeči. Nikdy není odeslána Claudovi. Po skončení relace zmizí. Žádné osobní údaje se nedostanou na externí servery. Otázka přenosu podle článku 46 nevyvstane.
Pojišťovací nároky: konkrétní příklad
Německá pojišťovna zpracovává e-maily se stížnostmi zákazníků. Každý e-mail obsahuje jméno, číslo pojistky a výši nároku.
Před zpracováním AI anonymizuje Rozšíření pro Chrome nebo MCP Server všechna tři pole. Claude vidí [CUSTOMER_1], [POLICY_2024-08847] a [AMOUNT_1]. Sestaví odpověď s těmito tokeny.
Vrstva automatického dešifrování pak obnoví všechna tři pole. Pracovník vyřizování stížností vidí v návrhu skutečné jméno a číslo pojistky. Zkontroluje a odešle. Žádné ruční nahrazování zástupných symbolů.
Výsledek z hlediska GDPR: data odeslaná na servery Claude v USA neobsahovala žádné osobní údaje. Skutečné jméno zákazníka a číslo pojistky zůstaly v Německu v prohlížeči pracovníka.
Co vyžaduje celý cyklus
Tři komponenty musí spolupracovat pro bezproblémový pracovní postup:
1. Konzistentní tokeny. Každá entita dostane jeden token na relaci. Vždy stejný.
2. Místní vyhledávací tabulka. Žije v relaci. Není odesílána AI.
3. Automatické dešifrování výstupu. Tabulka se aplikuje na návrh AI, než ho pracovník uvidí.
Bez všech tří pracovníci nahrazují tokeny ručně. Se všemi třemi pracovní postup běží samostatně a zůstává v souladu s GDPR.
Závěr
Tento přístup uzavírá smyčku v práci zákaznického servisu asistovaného AI. Anonymizace chrání data, než se dostanou k AI. Automatické dešifrování vrací skutečná jména do odpovědi. Pracovníci vidí správná jména na každém kroku. Soulad s GDPR je zachován po celou dobu.
Zdroje
- EDPB Guidelines 01/2025 on Pseudonymization — Požadavky pseudonymizace včetně oddělení klíče od pseudonymizovaných dat. OVĚŘENO-EXTERNĚ.
- GDPR Article 4(5) — Právní definice pseudonymizace. OVĚŘENO-EXTERNĚ.
- IAPP: Top 10 operational impacts of GDPR — Pouze 23 % nástrojů anonymizace nabízí skutečnou reverzibilitu. UPOZORNĚNÍ: přesné číslo nebylo nezávisle ověřeno; považujte za orientační.