Поза SSN: анонімізація внутрішніх ідентифікаторів вашої організації
Ваш GDPR-інструмент видаляє електронні адреси. Видаляє номери телефонів. Видаляє імена. Ви пропускаєте через нього експорти підтримки. Потім ділитеся результатом із командою аналітики.
Номери рахунків ваших клієнтів усе ще є в кожному тікеті. ID замовлень усе ще там. Внутрішні ID користувачів теж.
Ці ID виглядають нешкідливо самі по собі. Без таблиці пошуку вони не називають особу. Але ваша команда аналітики має цю таблицю. Ваша CRM її має. Ваша база даних підтримки теж. Будь-хто з доступом може знайти людину за кілька секунд.
Це порушення GDPR. Інструмент не зламався. Його просто ніколи не навчили шукати ваші ID.
Що виявляють стандартні PII-інструменти
Стандартні PII-інструменти охоплюють універсальні формати. Вони знаходять те, що є у кожній організації.
Стандартні інструменти виявляють:
- Номери соціального страхування (SSN США, NINO Великобританії, формати національних ID ЄС)
- Електронні адреси
- Номери телефонів
- Номери кредитних карток
- Імена
- Номери паспортів і водійських посвідчень
Стандартні інструменти не виявляють:
- ID співробітників у вашому форматі EMP-XXXXX
- Номери клієнтських рахунків у вашому форматі ACC-XXXXXXXX-XX
- ID замовлень у вашому форматі ORD-XXXXXXX
- Внутрішні ID користувачів у форматі UUID або спеціальному форматі
- Спеціальні коди посилань партнерів
Стандартні інструменти знаходять універсальні патерни. Ваші внутрішні ID не є універсальними. Для їх виявлення потрібне спеціальне налаштування.
Ризик повторної ідентифікації
Компанія експортує тікети підтримки для перегляду якості. Стандартне видалення PII знімає імена, електронні адреси та номери телефонів. Номери рахунків у форматі ACC-XXXXXXXX-XX залишаються недоторканими.
Експорт надходить до команди аналітики. Аналітик об'єднує таблицю тікетів із базою даних клієнтів за номером рахунку. Людина знаходиться миттєво. Жодного спеціального трюку не потрібно. Це звичайне SQL-об'єднання.
Стаття 4(5) GDPR визначає псевдонімізацію як обробку, при якій дані «більше не можуть бути приписані конкретному суб'єкту даних без використання додаткової інформації». Номери рахунків не проходять цей тест. Додаткова інформація — ваша база даних клієнтів — прямо у вашій організації.
«Анонімізований» експорт не був анонімним.
Створення патернів спеціальних сутностей
Налаштування спеціальних сутностей — швидке. Команди з відповідності можуть це зробити без допомоги інженерів.
Крок 1: Перелічіть ваші формати ID.
Запишіть кожен. Наприклад: рахунок ACC-XXXXXXXX-XX, ID замовлення ORD-XXXXXXX, ID співробітника EMP-XXXXX.
Крок 2: Опишіть формат простою мовою.
«Номери рахунків починаються з ACC, потім дефіс, потім 8 цифр, потім дефіс, потім 2 великі літери.»
Генерація патерну за допомогою ШІ повертає: ACC-\d{8}-[A-Z]{2}
Крок 3: Тестуйте на зразкових даних.
Завантажте від 20 до 30 документів. Підтвердіть, що всі екземпляри знайдено. Підтвердіть відсутність хибних спрацювань.
Крок 4: Оберіть метод.
Для ID, що використовуються як ключі з'єднання, де аналіз потребує зв'язування записів:
- Псевдонімізація. Замініть ACC-00123456-AB на ACC-99876543-XY щоразу. Той самий вхід завжди дає той самий результат. З'єднання все ще працюють. Вихідне значення не можна знайти без ключа.
Для ID, що не потрібні в аналізі:
- Редакція. Замініть на [REDACTED]. Просто. Безповоротно.
Крок 5: Збережіть як спільний пресет.
Збережіть спеціальну сутність — або набір з них — у спільному пресеті. Налаштування застосовується до всіх режимів використання: пакетного завантаження, API-викликів, браузерного інтерфейсу. Нові члени команди отримують повну конфігурацію одразу.
Кейс: 180 000 тікетів підтримки
Компанія виявила 180 000 тікетів підтримки у своєму аналітичному сховищі. Імена та адреси електронної пошти були видалені. Номери рахунків — ні. Кожен тікет усе ще містив живе значення ACC-XXXXXXXX-XX.
Часова шкала вирішення:
- Спеціаліст з відповідності визначає патерн ACC — 15 хвилин
- Тестує на 30 зразкових тікетах — 20 хвилин
- Підтверджує точність — 10 хвилин
- Обробляє 180 000 тікетів у нічному пакеті
- Замінює таблиці сховища чистими версіями
Загальний час для спеціаліста з відповідності: 45 хвилин. Без підтримки спеціальних сутностей виправлення потребувало б інженерного завдання, перевірки коду та розгортання. Це тижні, а не години.
Для детальнішого розгляду того, як спеціальні ID створюють ризики в AI-інструментах підтримки, дивіться посібник з GDPR та AI-підтримки.
Де поширюються спеціальні ID
Внутрішні ID з'являються у більшій кількості місць, ніж більшість команд очікує.
Внутрішні документи:
- Нотатки нарад із посиланнями на рахунки або ID замовлень
- Ланцюжки електронних листів про справи клієнтів
- Презентації з даними кейс-стадій
Передані третім сторонам:
- Звіти для регуляторів із номерами посилань справ
- Файли аудиту з посиланнями на клієнтів
- Файли постачальників, що містять ID клієнтів
Дослідження та аналітика:
- Датасети клієнтського шляху
- Експорти для перегляду якості підтримки
- Навчальні дані для внутрішніх ML-моделей
Кожен контекст потребує того самого налаштування спеціальних сутностей для отримання справді анонімного результату.
Псевдонімізація vs. анонімізація
GDPR проводить чітку межу.
Псевдонімізація замінює ID замінниками. Вихідну особу можна знайти знову, якщо хтось має таблицю пошуку. Ці дані все ще є персональними. Вона знижує ризик. Вона не знімає ваших зобов'язань за GDPR.
Анонімізація усуває можливість повторної ідентифікації. Анонімні дані не є персональними. GDPR до них не застосовується.
Номери рахунків і ID замовлень є псевдонімними, коли існують таблиці пошуку. Їх заміна на фіксовані замінники знижує ризик, але GDPR все одно застосовується. Заміна їх на випадкові токени — і видалення ключа — знімає зобов'язання за GDPR, але руйнує аналіз на основі з'єднань.
Для передачі третім сторонам, які не мають ваших таблиць пошуку: псевдонімізація може бути достатньою. Для внутрішньої аналітики потрібна повна анонімізація або суворий контроль доступу. Посібник з юридичної відповідності охоплює, як документувати кожен підхід для вашого ROPA.
Висновок
Прогалина — не збій інструменту. Це прогалина в налаштуванні. Жоден інструмент не може знати ваш формат номера рахунку, якщо ви не скажете йому.
Налаштування спеціальних сутностей закриває прогалину за кілька годин. Команди з відповідності визначають формати, тестують їх на зразкових даних і застосовують до всіх режимів використання. Допомога інженерів не потрібна.
180 000 нередагованих номерів рахунків були там не тому, що інструмент не спрацював. Вони були там тому, що інструменту ніколи не сказали їх шукати.