Problemet med tokenkartlegging
Organisasjoner som bruker AI for kundevendte arbeidsflyter står overfor en spesifikk teknisk utfordring med anonymisering: full-loop arbeidsflyten krever at anonymiserte innganger produserer svar som kan de-anonymiseres for den menneskelige agenten.
Arbeidsflyten uten tokenkartlegging: kundeklage som inneholder "Maria Schmidt" anonymiseres til "[CUSTOMER_1]" før AI-behandling. Claude behandler den anonymiserte klagen og utarbeider et svar: "Kjære [CUSTOMER_1], vi beklager forsinkelsen med bestillingen din." Saksbehandleren må manuelt erstatte "[CUSTOMER_1]" med "Maria Schmidt" før sending. Ved 200 kundekontakter per dag, bruker manuell token-erstatning betydelig tid for agenten — nok til å negere produktivitetsfordelen ved AI-assistanse.
Arbeidsflyten med sesjonspersistent tokenkartlegging: den samme anonymiseringen produserer en kartleggingstabell som holdes i den nåværende sesjonen. "[CUSTOMER_1]" → "Maria Schmidt." Når Claudes utkast til svar vises for saksbehandleren, anvender auto-dekrypteringslaget sesjonskartleggingen og agenten ser "Kjære Maria Schmidt" — det ekte navnet, allerede gjenopprettet. Agenten gjennomgår og sender. Ingen manuell token-erstatning. GDPR-beskyttelsen opererte stille og fullstendig.
Sesjonskonsistens
Tokenkartleggingen må være konsistent innen en sesjon. Hvis det samme kundens navn anonymiseres i to forskjellige deler av den samme samtalen — en gang i den innledende klagen og en gang i en oppfølging — må det kartlegges til den samme token. "[CUSTOMER_1]" må alltid referere til den samme personen innen en sesjon; Claudes resonnement om samtalen avhenger av konsistent identitetssporing.
Uten konsistens på sesjonsnivå, kan Claudes svar forvirre flere kunder (hvis "[CUSTOMER_1]" i den første meldingen og "[CUSTOMER_1]" i den tredje meldingen refererer til forskjellige personer), noe som produserer inkohærente svar som agenten ikke kan bruke.
GDPR Artikkel 4(5) anerkjenner pseudonymisering som en behandlingsteknikk som reduserer samsvarsrisiko. EDPBs retningslinjer for pseudonymisering fra 2022 krever at pseudonymiseringsnøkkelen (i dette tilfellet, tokenkartleggingstabellen) holdes separat fra de pseudonymiserte dataene. Tokenkartlegging på sesjonsnivå oppfyller dette kravet: kartleggingstabellen opprettholdes i nettlesersesjonen, ikke overført med de anonymiserte dataene til Claudes servere.
Brukstilfellet for forsikringskrav
Et tysk forsikringsselskaps AI-drevne kravbehandlingssystem behandler kundeklage-e-poster. Kundenavn, policynumre og kravbeløp anonymiseres før Claude behandler e-postene. Claude utarbeider svar ved hjelp av de anonymiserte token. Auto-dekrypteringslaget i Chrome-utvidelsen gjenoppretter original kundinformasjon i Claudes utkast før det vises for saksbehandleren. Saksbehandleren gjennomgår utkastet, gjør nødvendige justeringer, og sender det endelige svaret med ekte kundenavn.
GDPR-samsvarsberegningen: dataene som overføres til Claudes servere i USA inneholder "[CUSTOMER_1]", "[POLICY_2024-08847]", og "[AMOUNT_1]" — ikke personopplysninger som definert av GDPR. Den faktiske navnet og policynummeret til kunden forblir i Tyskland på saksbehandlerens nettleser. Spørsmålet om datatransfer i henhold til GDPR Artikkel 46 — hvilke sikkerhetstiltak gjelder for overføring av personopplysninger til USA? — oppstår ikke fordi personopplysninger ikke ble overført.
Kilder: