Token-mapping ongelma
Organisaatiot, jotka käyttävät AI:ta asiakasrajapinnassa, kohtaavat erityisen teknisen haasteen anonymisoinnin kanssa: täydellinen työnkulku vaatii, että anonymisoidut syötteet tuottavat vastauksia, jotka voidaan de-anonymisoida ihmisedustajalle.
Työnkulku ilman token-mappingia: asiakasvalitus, joka sisältää "Maria Schmidt", anonymisoidaan muotoon "[CUSTOMER_1]" ennen AI-käsittelyä. Claude käsittelee anonymisoitua valitusta ja laatii vastauksen: "Hyvä [CUSTOMER_1], pahoittelemme tilaustasi viivästystä." Vakuutusasiamiehen on manuaalisesti vaihdettava "[CUSTOMER_1]" muotoon "Maria Schmidt" ennen lähettämistä. 200 asiakasvuorovaikutuksessa päivässä manuaalinen token-vaihto vie merkittävästi edustajan aikaa — riittävästi kumoamaan AI-avun tuottavuus hyöty.
Työnkulku istuntokohtaisella token-mappingilla: sama anonymisointi tuottaa karttatiedoston, joka pidetään nykyisessä istunnossa. "[CUSTOMER_1]" → "Maria Schmidt." Kun Clauden luonnosvastaus näytetään vakuutusasiamiehelle, automaattinen purkamiskerros soveltaa istuntokarttaa ja edustaja näkee "Hyvä Maria Schmidt" — oikea nimi, joka on jo palautettu. Edustaja tarkistaa ja lähettää. Ei manuaalista token-vaihtoa. GDPR-suojaus toimi hiljaa ja täysin.
Istuntokonsistenssi
Token-mappingin on oltava johdonmukainen istunnon sisällä. Jos saman asiakkaan nimi anonymisoidaan kahdessa eri osassa samaa keskustelua — kerran alkuperäisessä valituksessa ja kerran jatkokysymyksessä — sen on kartoituttava samaan tokeniin. "[CUSTOMER_1]" on aina viitattava samaan henkilöön istunnon aikana; Clauden päättely keskustelusta riippuu johdonmukaisesta identiteettiseurannasta.
Ilman istuntotason johdonmukaisuutta Clauden vastaukset voivat sekoittaa useita asiakkaita (jos "[CUSTOMER_1]" ensimmäisessä viestissä ja "[CUSTOMER_1]" kolmannessa viestissä viittaavat eri henkilöihin), tuottaen epäjohdonmukaisia vastauksia, joita edustaja ei voi käyttää.
GDPR:n artikla 4(5) tunnustaa pseudonymisoinnin käsittelytekniikkana, joka vähentää vaatimustenmukaisuuden riskiä. EDPB:n 2022 pseudonymisointiohjeet edellyttävät, että pseudonymisointiavain (tässä tapauksessa token-mapping taulukko) pidetään erillään pseudonymisoidusta datasta. Istuntotason token-mapping täyttää tämän vaatimuksen: karttatiedosto säilytetään selainistunnossa, eikä sitä siirretä anonymisoidun datan mukana Clauden palvelimille.
Vakuutusvaatimusten käyttötapaus
Saksalaisen vakuutusyhtiön AI-pohjainen vaatimusten käsittelyjärjestelmä käsittelee asiakasvalitus-sähköposteja. Asiakkaiden nimet, vakuutustunnukset ja vaatimussummat anonymisoidaan ennen kuin Claude käsittelee sähköposteja. Claude laatii vastauksia käyttäen anonymisoituja tokeneita. Automaattinen purkamiskerros Chrome-laajennuksessa palauttaa alkuperäiset asiakastiedot Clauden luonnoksessa ennen kuin se näytetään vakuutusasiamiehelle. Asiamies tarkistaa luonnoksen, tekee tarvittavat muutokset ja lähettää lopullisen vastauksen oikeilla asiakastiedoilla.
GDPR-yhteensopivuuden laskenta: data, joka siirretään Clauden Yhdysvaltojen palvelimille, sisältää "[CUSTOMER_1]", "[POLICY_2024-08847]" ja "[AMOUNT_1]" — ei henkilötietoja GDPR:n määritelmän mukaan. Asiakkaan todellinen nimi ja vakuutustunnus pysyvät Saksassa vakuutusasiamiehen selaimessa. GDPR:n artikla 46 tietojen siirto kysymys — mitä suojatoimia sovelletaan henkilötietojen siirtoon Yhdysvaltoihin? — ei nouse esiin, koska henkilötietoja ei siirretty.
Lähteet: