Problemet med Token Mapping
Organisationer, der bruger AI til kundevendte workflows, står over for en specifik teknisk udfordring med anonymisering: den fulde workflow kræver, at anonymiserede input producerer svar, der kan de-anonymiseres for den menneskelige agent.
Workflow uden token mapping: kundeklage indeholdende "Maria Schmidt" anonymiseres til "[CUSTOMER_1]" før AI-behandling. Claude behandler den anonymiserede klage og udarbejder et svar: "Kære [CUSTOMER_1], vi beklager forsinkelsen med din ordre." Sagsbehandleren skal manuelt erstatte "[CUSTOMER_1]" med "Maria Schmidt" før afsendelse. Ved 200 kundeinteraktioner om dagen forbruger manuel token-erstatning betydelig agenttid — nok til at negere produktivitetsfordelen ved AI-assistance.
Workflow med session-persistent token mapping: den samme anonymisering producerer en mappingtabel, der holdes i den aktuelle session. "[CUSTOMER_1]" → "Maria Schmidt." Når Claudes udkast til svar vises for sagsbehandleren, anvender auto-decrypt-laget sessionmappingen, og agenten ser "Kære Maria Schmidt" — det rigtige navn, allerede gendannet. Agenten gennemgår og sender. Ingen manuel token-erstatning. GDPR-beskyttelsen fungerede stille og fuldstændigt.
Session Konsistens
Token mapping skal være konsistent inden for en session. Hvis den samme kundes navn anonymiseres i to forskellige dele af den samme samtale — én gang i den indledende klage og én gang i en opfølgning — skal det kortlægges til den samme token. "[CUSTOMER_1]" skal altid referere til den samme person inden for en session; Claudes ræsonnering om samtalen afhænger af konsistent identitetssporing.
Uden session-niveau konsistens kan Claudes svar forvirre flere kunder (hvis "[CUSTOMER_1]" i den første besked og "[CUSTOMER_1]" i den tredje besked refererer til forskellige personer), hvilket producerer incoherente svar, som agenten ikke kan bruge.
GDPR Artikel 4(5) anerkender pseudonymisering som en behandlingsteknik, der reducerer overholdelsesrisiko. EDPB's pseudonymiseringsretningslinjer fra 2022 kræver, at pseudonymiseringsnøglen (i dette tilfælde token mappingtabelen) opbevares adskilt fra de pseudonymiserede data. Session-niveau token mapping opfylder dette krav: mappingtabelen opbevares i browsersessionen, ikke transmitteret med de anonymiserede data til Claudes servere.
Forsikringskrav Brugs Case
Et tysk forsikringsselskabs AI-drevne kravbehandlingssystem behandler kundeklage-e-mails. Kundenavne, policenumre og kravbeløb anonymiseres, før Claude behandler e-mails. Claude udarbejder svar ved hjælp af de anonymiserede tokens. Auto-decrypt-laget i Chrome-udvidelsen gendanner den oprindelige kundeinformation i Claudes udkast, før det vises for sagsbehandleren. Sagsbehandleren gennemgår udkastet, foretager eventuelle nødvendige justeringer og sender det endelige svar med rigtige kundenavne.
GDPR-overholdelsesberegningen: de data, der overføres til Claudes amerikanske servere, indeholder "[CUSTOMER_1]", "[POLICY_2024-08847]" og "[AMOUNT_1]" — ikke personlige data som defineret af GDPR. Den faktiske kundes navn og policenummer forbliver i Tyskland på sagsbehandlerens browser. GDPR Artikel 46 datatransfer spørgsmål — hvilke sikkerhedsforanstaltninger gælder for overførsel af personlige data til USA? — opstår ikke, fordi personlige data ikke blev overført.
Kilder: