Tilbake til BloggGDPR & Overholdelse

Token-mapping for GDPR AI-arbeidsflyter

Nar kundenavn anonymiseres for AI-behandling, inneholder AI-svaret anonymiserte tokens. Det endelige svaret ma inneholde virkelige navn — ikke.

April 25, 20268 min lesing
token mapping AIGDPR customer service AIauto-decryptsession-based anonymizationAI workflow pseudonymization

Token-mapping for GDPR AI-arbeidsflyter

Oppdatert for 2026

Teamet ditt bruker AI til a utarbeide kundesvar. En kunde skriver inn. Navnet deres anonymiseres for AI-en ser det. AI-en utarbeider et svar med en plassholder. Saksbehandleren ma bytte det tilbake manuelt. Ved 200 interaksjoner per dag akkumuleres den kostnaden raskt.

Sesjonsbasert token-mapping loser dette. Den gjenoppretter virkelige navn automatisk.

Problemet uten token-mapping

Anonymiseringstrinnet oppretter et token. "Maria Schmidt" blir `[CUSTOMER_1]`. Claude utkaster: "Kjaere [CUSTOMER_1], vi beklager forsinkelsen."

Saksbehandleren ma na erstatte `[CUSTOMER_1]` med "Maria Schmidt" for sending. I stor skala avvikler dette trinnet formalet med AI-assistanse. Det er repeterende arbeid som ikke forsvinner.

Hvordan sesjonstokens fungerer

Sesjonen lagrer en oppslagstabell: `[CUSTOMER_1]` → "Maria Schmidt." Nar Claude returnerer sitt utkast, leser automatisk-dekrypteringslaget den tabellen og gjenoppretter navnet. Saksbehandleren ser "Kjaere Maria Schmidt" — allerede korrekt. Ingen manuelt trinn. GDPR-beskyttelsen kjorer lydlost.

Hvorfor sesjonskonsistens er viktig

Token-tabellen ma vaere konsistent gjennom hele sesjonen. Hvis "Maria Schmidt" vises i den innledende klagen og igjen i en oppfolging, ma begge lose til `[CUSTOMER_1]`. Uten dette kan Claude behandle dem som to forskjellige personer. Svaret blir usammenhengende.

En person far ett token per sesjon. Claude kan da resonnere korrekt om samtalen.

GDPR-samsvar etter design

GDPR artikkel 4(5) definerer pseudonymisering som en teknikk for risikosreduksjon. EDPBs retningslinjer fra 2022 stiller ett krav: nokkkelen ma oppbevares atskilt fra de pseudonymiserte dataene.

Sesjonstoken-tabeller oppfyller denne regelen. Oppslagstabellen forblir i nettleseren. Den sendes aldri til Claude. Etter at sesjonen avsluttes, er den borte. Ingen personopplysninger nar eksterne servere. Sporsmal om overforsel etter artikkel 46 oppstar ikke.

Forsikringsreklamasjoner: Et konkret eksempel

Et tysk forsikringsselskap behandler kundeklage-e-poster. Hver e-post inneholder et navn, et policynummer og et kravbelop.

For AI-behandling anonymiserer Chrome-utvidelsen eller MCP-serveren alle tre feltene. Claude ser `[CUSTOMER_1]`, `[POLICY_2024-08847]` og `[AMOUNT_1]`. Den utarbeider et svar med disse tokenene.

Automatisk-dekrypteringslaget gjenoppretter deretter alle tre feltene. Saksbehandleren ser det virkelige navnet og policynummeret i utkastet. De gjennomgar og sender. Ingen plassholdererstatning er nodvendig.

GDPR-resultatet: data sendt til Claudes amerikanske servere inneholdt ingen personopplysninger. Kundens virkelige navn og policynummer forble i Tyskland pa saksbehandlerens nettleser.

Hva den fullstendige sloyfen krever

Tre komponenter ma fungere sammen for en smidig arbeidsflyt:

1. Konsistente tokens. Hver enhet far ett token per sesjon. Alltid det samme.

2. En lokal oppslagstabell. Den lever i sesjonen. Den sendes ikke til AI-en.

3. Automatisk dekryptering pa utdata. Tabellen anvendes pa AI-utkastet for saksbehandleren ser det.

Uten alle tre erstatter saksbehandlere tokens manuelt. Med alle tre kjorer arbeidsflyten pa egenhhand og forblir GDPR-kompatibel.

Konklusjon

Denne tilnarmingen lukker sloyfeen i AI-assistert kundearbeid. Anonymisering beskytter data for de nar AI-en. Automatisk dekryptering setter virkelige navn tilbake i svaret. Saksbehandlere ser korrekte navn i hvert trinn. GDPR-samsvar opprettholdes gjennom hele prosessen.

Kilder

Limitations / When this doesn't apply

The guarantee is only as good as what got tokenized. The local table protects the name, policy number, and amount the system actually flagged — but a free-text complaint also carries addresses, account references, dates, and incidental third-party names that may not be detected, and any of those reaches the model in the clear. Review what the detector caught on real messages, not just the structured fields, before relying on the privacy claim.

  • Tokens reduce risk; they rarely make text non-personal. Even with the name replaced, the surrounding details of a single complaint can describe one identifiable customer, so GDPR treats this as pseudonymized, not anonymized, data — the Article 46 transfer question does not simply disappear, and the residual content sent to the model still warrants a documented transfer basis.
  • A session table is a custody arrangement, not deletion. While it exists, it is the link back to every real identity in the conversation; a compromised browser, a persisted log, or an exported draft can carry plaintext names outside the intended boundary, so local custody controls where the key sits, not whether the data was ever exposed.

Klar til å beskytte dataene dine?

Begynn å anonymisere PII med 273 enhetstyper på 48 språk.