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