Токен-маппінг для AI-процесів відповідно до GDPR
Оновлено у 2026 році
Ваша команда використовує ШІ для підготовки відповідей клієнтам. Клієнт пише звернення. Його ім'я анонімізується перед тим, як ШІ його бачить. ШІ готує відповідь із заповнювачем. Агент повинен замінити його вручну. При 200 зверненнях на день ці витрати швидко накопичуються.
Сесійний токен-маппінг вирішує цю проблему. Він автоматично відновлює реальні імена.
Проблема без токен-маппінгу
Крок анонімізації створює токен. «Марія Шмідт» стає [CUSTOMER_1]. Claude складає: «Шановна [CUSTOMER_1], перепрошуємо за затримку.»
Оператор по роботі з претензіями тепер повинен замінити [CUSTOMER_1] на «Марія Шмідт» перед надсиланням. У масштабі цей крок нівелює переваги використання ШІ. Це повторювана робота, яка нікуди не зникає.
Як працюють сесійні токени
Сесія зберігає таблицю відповідності: [CUSTOMER_1] → «Марія Шмідт». Коли Claude повертає свій чернетковий варіант, шар автоматичного розшифрування зчитує цю таблицю і відновлює ім'я. Агент бачить «Шановна Маріє Шмідт» — вже правильно. Жодного ручного кроку. Захист за GDPR працює непомітно.
Чому важлива узгодженість у межах сесії
Таблиця токенів повинна бути узгодженою протягом усієї сесії. Якщо «Марія Шмідт» з'являється у первинній скарзі та знову в подальшому зверненні, обидва входження мають відповідати [CUSTOMER_1]. Без цього Claude може сприйняти їх як двох різних людей. Відповідь стає незв'язною.
Одна людина отримує один токен за сесію. Тоді Claude може правильно аналізувати розмову.
Відповідність GDPR за замовчуванням
Стаття 4(5) GDPR визначає псевдонімізацію як метод зниження ризиків. Настанови EDPB 2022 року ставлять одну умову: ключ має зберігатися окремо від псевдонімізованих даних.
Сесійні таблиці токенів відповідають цьому правилу. Таблиця відповідності залишається у браузері. Вона ніколи не надходить до Claude. Після завершення сесії вона видаляється. Жодні персональні дані не потрапляють на зовнішні сервери. Питання передачі за Статтею 46 не виникає.
Страхові претензії: конкретний приклад
Німецька страхова компанія обробляє електронні листи зі скаргами клієнтів. Кожен лист містить ім'я, номер полісу та суму претензії.
Перед обробкою ШІ Chrome Extension або MCP Server анонімізує всі три поля. Claude бачить [CUSTOMER_1], [POLICY_2024-08847] та [AMOUNT_1]. Він складає відповідь із цими токенами.
Потім шар автоматичного розшифрування відновлює всі три поля. Оператор по роботі з претензіями бачить реальне ім'я та номер полісу в чернетці. Він перевіряє і надсилає. Жодної ручної заміни заповнювачів не потрібно.
Результат для GDPR: дані, надіслані на сервери Claude у США, не містили персональних даних. Реальне ім'я клієнта та номер полісу залишилися в Германії, у браузері оператора.
Що потрібно для повного циклу
Три компоненти повинні працювати разом для безперебійного процесу:
1. Узгоджені токени. Кожна сутність отримує один токен за сесію. Завжди той самий.
2. Локальна таблиця відповідності. Вона зберігається в сесії. Вона не надсилається до ШІ.
3. Автоматичне розшифрування вихідних даних. Таблиця застосовується до чернетки ШІ перед тим, як агент її бачить.
Без усіх трьох компонентів агенти замінюють токени вручну. З усіма трьома процес працює самостійно і залишається відповідним вимогам GDPR.
Висновок
Цей підхід замикає контур у AI-підтримці клієнтів. Анонімізація захищає дані до того, як вони досягають ШІ. Автоматичне розшифрування повертає реальні імена у відповідь. Агенти бачать правильні імена на кожному кроці. Відповідність GDPR зберігається протягом усього процесу.
Джерела
- Настанови EDPB 01/2025 щодо псевдонімізації — Вимоги до псевдонімізації, включаючи розмежування ключа та псевдонімізованих даних. VERIFIED-EXTERNAL.
- GDPR Стаття 4(5) — Юридичне визначення псевдонімізації. VERIFIED-EXTERNAL.
- IAPP: 10 операційних наслідків GDPR — Лише 23% інструментів анонімізації пропонують справжню зворотність. FLAGGED: точна цифра не перевірена незалежно; вважати орієнтовною.