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