Mapiranje tokena za GDPR AI tijekove rada
Azurirano za 2026.
Vas tim koristi AI za pisanje odgovora klijentima. Klijent se javi. Njihovo ime se anonimizira prije nego sto AI to vidi. AI napiše odgovor s rezerviranim mjestom. Agent mora rucno zamijeniti token. Pri 200 interakcija dnevno, taj trosak se brzo zbraja.
Mapiranje tokena temeljeno na sesiji rjesava to. Automatski vraca stvarna imena.
Problem bez mapiranja tokena
Korak anonimizacije stvara token. "Marija Horvat" postaje [KUPAC_1]. Claude sastavlja: "Dragi [KUPAC_1], ispricavamo se zbog kasnjenja."
Agent sada mora zamijeniti [KUPAC_1] s "Marija Horvat" prije slanja. U velikom mjerilu, ovaj korak ponistava svrhu AI pomoci. To je ponavljajuci posao koji ne nestaje.
Kako funkcioniraju sesijski tokeni
Sesija pohranjuje tablicu pretrazivanja: [KUPAC_1] -> "Marija Horvat." Kad Claude vrati nacrt, sloj auto-dekriptiranja cita tu tablicu i vraca ime. Agent vidi "Draga Marija Horvat" -- vec ispravno. Nema rucnog koraka. GDPR zastita odvija se u pozadini.
Zasto je konzistentnost sesije vazna
Tablica tokena mora biti konzistentna kroz cijelu sesiju. Ako se "Marija Horvat" pojavljuje u pocetnoj prituzbi i opet u naknadnom obracan, oboje mora razrijesiti u [KUPAC_1]. Bez toga, Claude ih moze tretirati kao dvije razlicite osobe. Njegov odgovor postaje nekoherentan.
Jedna osoba dobiva jedan token po sesiji. Claude tada moze ispravno razmisljati o razgovoru.
GDPR uskladenost po dizajnu
GDPR Clanak 4(5) definira pseudonimizaciju kao tehniku smanjenja rizika. Smjernice EDPB-a iz 2022. zahtijevaju jednu stvar: kljuc mora biti pohranjen odvojeno od pseudonimiziranih podataka.
Sesijske tablice tokena ispunjavaju to pravilo. Pretrazivanje ostaje u pregledniku. Nikad ne odlazi Claudeu. Nakon sto sesija zavrsi, nestaje. Osobni podaci ne dospu na vanjske posluzitelje. Pitanje prijenosa prema Clanku 46 ne pojavljuje se.
Primjer iz osiguranja: konkretan slucaj
Njemacki osiguravatelj obradjuje e-poruke prituzbi klijenata. Svaka e-poruka sadrzi ime, broj police i iznos stete.
Prije AI obrade, Chrome prosirenje ili MCP posluzitelj anonimizira sva tri polja. Claude vidi [KUPAC_1], [POLICA_2024-08847] i [IZNOS_1]. Sastavlja odgovor s tim tokenima.
Sloj auto-dekriptiranja tada vraca sva tri polja. Agent za stete vidi stvarno ime i broj police u nacrtu. Pregledava i salje. Nema potrebe za rucnom zamjenom rezerviranih mjesta.
Ishod po GDPR-u: podaci poslani Claudeovim americkim posluziteljima nisu sadrzavali osobne podatke. Stvarno ime i broj police klijenta ostali su u Njemackoj u pregledniku agenta.
Sto zahtijeva cijeli krug
Tri komponente moraju funkcionirati zajedno za besprijekoran tijek rada:
1. Konzistentni tokeni. Svaki entitet dobiva jedan token po sesiji. Uvijek isti.
2. Lokalna tablica pretrazivanja. Zivi u sesiji. Ne salje se AI-u.
3. Auto-dekriptiranje na izlazu. Tablica se primjenjuje na nacrt AI-a prije nego sto ga agent vidi.
Bez sve tri komponente, agenti rucno zamjenjuju tokene. Sa sve tri, tijek rada se odvija sam od sebe i ostaje u skladu s GDPR-om.
Zakljucak
Ovaj pristup zatvara petlju u AI-potpomognutom radu s klijentima. Anonimizacija stiti podatke prije nego dosegnu AI. Auto-dekriptiranje vraca stvarna imena u odgovor. Agenti vide ispravna imena na svakom koraku. GDPR uskladenost se odrzava cijelo vrijeme.