Mapiranje tokena za AI radne tokove uskladjene s GDPR-om
Azurirano za 2026. godinu
Vas tim koristi AI za kreiranje odgovora klijentima. Klijent se javlja. Njegovo ime se anonimizuje pre nego sto ga AI vidi. AI kreira odgovor sa oznakom-cuvarom mesta. Agent mora rucno da ga zameni. Pri 200 interakcija dnevno, taj trosak se brzo sabira.
Mapiranje tokena zasnovano na sesiji resava ovo. Automatski vraca prava imena.
Problem bez mapiranja tokena
Korak anonimizacije kreira token. "Maria Schmidt" postaje [CUSTOMER_1]. Claude kreira: "Postovana [CUSTOMER_1], izvinjavamo se zbog kasnjenja."
Obradivac zahteva sada mora da zameni [CUSTOMER_1] sa "Maria Schmidt" pre slanja. U obimu, ovaj korak ponistava svrhu AI pomoci. To je ponavljajuci posao koji ne nestaje.
Kako funkcionisu tokeni sesije
Sesija cuva tabelu pretrazivanja: [CUSTOMER_1] -> "Maria Schmidt". Kada Claude vrati nacrt, sloj automatskog desifrovanja cita tu tabelu i vraca ime. Agent vidi "Postovana Maria Schmidt" - vec tacno. Nema rucnog koraka. GDPR zastita radi u pozadini.
Zasto je konzistentnost sesije vazna
Tabela tokena mora biti konzistentna tokom cele sesije. Ako se "Maria Schmidt" pojavljuje u pocetnoj zalbi i ponovo u naknadnoj poruci, oba moraju razresiti na [CUSTOMER_1]. Bez ovoga, Claude ih moze tretirati kao dve razlicite osobe. Njegov odgovor postaje nekoherentan.
Jedna osoba dobija jedan token po sesiji. Claude tada moze ispravno da razmislja o razgovoru.
GDPR uskladjenost po dizajnu
GDPR clan 4(5) definise pseudonimizaciju kao tehniku smanjenja rizika. EDPB smernice iz 2022. zahtevaju jednu stvar: kljuc mora biti cuvan odvojeno od pseudonimizovanih podataka.
Tabele tokena sesije ispunjavaju ovo pravilo. Tabela pretrazivanja ostaje u pretrazivacu. Nikada ne odlazi Claude-u. Kada sesija zavrsi, nestaje. Nikakvi licni podaci ne stizu do spoljnih servera. Pitanje o prenosu po clanu 46 se ne pojavljuje.
Zahtevi osiguranja: Konkretan primer
Nemacki osiguravac obraduje imejlove prituzbi klijenata. Svaki imejl sadrzi ime, broj polise i iznos zahteva.
Pre AI obrade, Chrome Extension ili MCP Server anonimizuje sva tri polja. Claude vidi [CUSTOMER_1], [POLICY_2024-08847] i [AMOUNT_1]. Kreira odgovor sa tim tokenima.
Sloj automatskog desifrovanja zatim vraca sva tri polja. Obradivac zahteva vidi pravo ime i broj polise u nacrtu. Pregledava i salje. Nije potrebna zamena oznaka-cuvara mesta.
GDPR ishod: podaci poslati Claude-ovim americkim serverima nisu sadrzali licne podatke. Pravo ime i broj polise klijenta ostali su u Nemackoj, u pretrazivacu obradivaca.
Sta zahteva ceo krug
Tri komponente moraju da rade zajedno za nesmetani radni tok:
1. Konzistentni tokeni. Svaki entitet dobija jedan token po sesiji. Uvek isti.
2. Lokalna tabela pretrazivanja. Zivi u sesiji. Ne salje se AI-ju.
3. Automatsko desifrovanje na izlazu. Tabela se primenjuje na AI nacrt pre nego sto ga agent vidi.
Bez sva tri, agenti rucno zamenjuju tokene. Sa sva tri, radni tok funkcionise samostalno i ostaje uskladen s GDPR-om.
Zakljucak
Ovaj pristup zatvara petlju u AI-podrzanom radu sa klijentima. Anonimizacija stiti podatke pre nego sto stignu do AI-ja. Automatsko desifrovanje vraca prava imena u odgovor. Agenti vide tacna imena u svakom koraku. GDPR uskladjenost se odrza tokom celog procesa.
Izvori
- EDPB Smernice 01/2025 o pseudonimizaciji - Zahtevi pseudonimizacije ukljucujuci odvajanje kljuca od pseudonimizovanih podataka. VERIFIED-EXTERNAL.
- GDPR clan 4(5) - Pravna definicija pseudonimizacije. VERIFIED-EXTERNAL.
- IAPP: Top 10 operativnih uticaja GDPR-a - Samo 23% alata za anonimizaciju nudi pravu reverzibilnost. FLAGGED: tacna cifra nije nezavisno verifikovana; tretirati kao indikativnu.