Обезличивание без потери смысла

Из судебного решения убрали фамилии сторон. Остались номер дела, название суда и дата заседания. Документ выглядит обезличенным, но этих сведений может хватить, чтобы найти оригинал в открытой базе и узнать участников спора.

Такую ситуацию приводит Азат Адельмурдин, представляющий проект ГИАТЕРРА, в котором есть инструмент анонимизации юридических документов. Удалить очевидные персональные сведения сравнительно просто. Сложнее понять, что раскрывает оставшийся текст и какую часть подробностей нужно сохранить для работы. Если вычистить всё, что хоть как-то отличает одно дело от другого, юрист потеряет обстоятельства спора и логику решения.

С похожей задачей сталкиваются разработчики и аналитики. Им нужны результаты тестов, поведение пользователей, история обращений. Передавать исходные записи целиком часто избыточно, а свести их к одной средней величине означает потерять различия, ради которых и затевался анализ. Три практика объясняют, как искать этот баланс и где обычно остаются незамеченные связи с человеком.

Почему удаления имени недостаточно

«Удаление поля user_id из таблицы не обезличивает запись», — говорит Тимур Рахматуллин, Senior Software Engineer в Softline Solutions. Вместе с именем или идентификатором исчезает только один способ связать строку с пользователем. В выгрузке могут остаться модель устройства, часовой пояс, язык интерфейса и особенности поведения. По отдельности эти признаки встречаются у многих людей. Их сочетание бывает гораздо более редким.

Рахматуллин рассказывает о подготовке данных для машинного обучения в Mytona. После удаления player_id сочетание модели устройства, часового пояса и частоты покупок всё ещё позволяло выделять конкретного игрока. По его словам, команде пришлось укрупнять значения и добавлять шум в поведенческие показатели.

Рустем Ахмеров, разработчик мобильных приложений, предлагает смотреть на всю запись. Если убрать email, но сохранить точную дату рождения, небольшой населённый пункт и профессию, человека иногда удаётся узнать по оставшимся сведениям. Адельмурдин добавляет: в тексте редкое происшествие и конкретная должность способны раскрыть участника даже без фамилии.

Поэтому перечень удаляемых полей нужно дополнять проверкой их сочетаний. Иначе обработанная таблица будет выглядеть безопаснее исходной, сохранив возможность установить, кому принадлежат данные.

Сначала определить задачу выгрузки

Адельмурдин предлагает начать с цели передачи. Если получателю нужна статистика судебных споров, ему могут быть достаточны количество дел, категории требований и результаты рассмотрения. Подробное описание каждого участника для этого не требуется. Для анализа правовой аргументации, напротив, важны обстоятельства дела и содержание решения.

Этот выбор определяет, что предстоит защищать. Можно передать сводную таблицу, набор обработанных записей или документы с сохранённым контекстом. У каждого варианта своя полезность и свои возможности для сопоставления с другими источниками. Внутренний анализ, работа с конкретным подрядчиком и открытая публикация требуют отдельной оценки: круг получателей и доступная им информация различаются.

Комментарий редакции AiHummer. До обработки полезно записать вопрос, на который должна ответить выгрузка. Например: «На каком шаге пользователи прекращают обучение?» Для этого могут понадобиться номер шага, факт завершения и неделя прохождения. Точная дата рождения и адрес электронной почты ответа не улучшают. Такой список помогает проверить и достаточность данных, и необходимость каждого оставленного поля.

Сохранение пользы тоже нужно проверять предметно. Если после обработки нельзя сравнить результаты нужных групп или восстановить последовательность этапов, задача не решена. Придётся изменить способ подготовки данных либо ограничить доступ к более подробному набору.

Как сохранить нужные различия

Рахматуллин обращает внимание на методы, которые меняют детализацию данных. Вместо точного возраста можно использовать возрастной диапазон, вместо небольшой территории — более крупную. Для некоторых задач достаточно общих итогов по группе. Выбор зависит от того, какие различия существенны для анализа.

Один из подходов — k-анонимность. При заданном наборе косвенных идентификаторов каждая комбинация признаков должна встречаться как минимум у k записей. Например, если анализируют возрастную группу и регион, проверяют, сколько записей соответствует каждому такому сочетанию. Слишком редкие комбинации требуют дополнительного укрупнения или исключения из передаваемого набора.

Комментарий редакции AiHummer. K-анонимность сама по себе не гарантирует защиту от всех способов раскрытия. Если у всех людей в группе одинаковое чувствительное значение, оно может стать известно даже без выделения конкретной строки. Подход l-diversity учитывает разнообразие чувствительных значений внутри групп, но и у него есть ограничения. Универсального значения k, достаточного для любой выгрузки, нет.

Для публикации статистики применяют и дифференциальную приватность, о которой упоминает Рахматуллин. Она позволяет математически ограничивать влияние участия отдельного человека на распределение результатов механизма. Это требует правильно выбранного механизма и параметров приватности. Произвольное добавление случайных чисел к таблице такой гарантии не даёт.

Иногда нужна возможность связать записи одного пользователя между собой. Замена идентификатора токеном помогает сохранить эту связь. Но если существует таблица соответствий или другой способ восстановить исходное значение, такая замена сама по себе не делает набор анонимным. Значение имеют и оставшиеся признаки, и доступ к дополнительным сведениям.

Как проверить возможность узнать человека

Ахмеров предлагает начать с вопроса: сколько ещё людей могут соответствовать оставшемуся набору признаков? В своём приложении, медицинском тренажёре для обучения медперсонала, он проверял поля, которые сохранялись после удаления идентификаторов. Особое внимание требовалось редким сочетаниям характеристик и результатов тестов.

Такая проверка помогает найти очевидные слабые места, однако одного ответа «подходят многие» недостаточно для окончательного вывода. Нужно учитывать сведения за пределами самой таблицы. Адельмурдин напоминает: у одного получателя нет дополнительной информации, у другого есть собственная база, с которой он сопоставит выгрузку.

Рахматуллин описывает проверку через попытку повторной идентификации: взять подготовленный набор и попробовать связать записи с доступными внешними данными. Для юридического документа это может быть поиск оригинала по номеру дела или редкому описанию события. Для таблицы — проверка необычных сочетаний признаков и устойчивых идентификаторов.

«Поэтому гарантировать абсолютную невозможность восстановления личности я бы не стал», — говорит Адельмурдин. Его оговорка важна для интерпретации результата проверки. Неудачная попытка установить личность показывает, что конкретный способ не сработал в заданных условиях. Она не доказывает невозможность любого сопоставления в будущем.

Практический результат такой работы — перечень проверенных сценариев и оставшихся ограничений. По нему можно решить, нужно ли дополнительно укрупнить сведения, сократить состав выгрузки или изменить условия доступа.

Где остаются незамеченные копии

«Главная ошибка — думать, что данные хранятся в одном месте», — подчёркивает Ахмеров. В его проекте email находился в таблице аккаунтов и дублировался в таблице профилей. Очистка только одной таблицы оставляла вторую копию. При этом профили содержали результаты тестов, необходимые для развития приложения, поэтому удалять их целиком было нежелательно.

Разработчик рассказывает, что удалил аккаунты, а в профилях заменил email заглушкой, сохранив статистику. Этот пример показывает, почему перед обработкой нужно разобраться в связях между хранилищами. О достаточности обезличивания судят по всему оставшемуся набору, включая косвенные признаки.

Ахмеров отдельно проверял резервные копии, журналы, стороннюю аналитику, очереди уведомлений и тестовые базы. Если email попал в адрес запроса, он может сохраниться в журнале веб-сервера. Если его отправляли в CRM или систему регистрации ошибок, очистка основной базы не изменит эти записи. А резервная копия продолжит содержать исходные сведения до предусмотренного удаления или перезаписи.

Рахматуллин приводит похожие наблюдения из аудитов облачной инфраструктуры: основная база уже замаскирована, а журналы содержат IP-адреса и координаты. Состав логов и технических выгрузок приходится проверять отдельно.

Комментарий редакции AiHummer. Стоит различать две задачи: подготовить конкретный файл для передачи и очистить сведения во всей системе. Для первой нужно проверить содержимое файла и возможные связи. Для второй — найти копии, определить порядок их обработки и учесть восстановление из резервной копии. Иначе после восстановления удалённые ранее сведения могут снова оказаться в рабочей базе.

Что может скрываться внутри файла

Адельмурдин обращает внимание на распространённую ошибку с PDF. Фамилию можно закрыть чёрным прямоугольником, сохранив исходный текст под ним. На экране запись не видна, но её по-прежнему удаётся извлечь программно. Поэтому визуального просмотра недостаточно: нужно проверить, действительно ли удалено содержимое.

Сведения могут остаться и в метаданных, комментариях, истории исправлений, скрытых листах таблицы. Отдельной проверки требует описание редкого события, по которому можно найти исходный документ. Удаление имени автора из свойств файла не решает проблему, если сам текст позволяет узнать человека.

Проверять нужно окончательную версию, которую получит адресат. После преобразования формата или сборки нескольких документов результат может отличаться от рабочего файла. Для PDF полезно проверить извлечение текста и скрытое содержимое; для таблицы — все листы и поля, а также связи с дополнительными источниками.

Что проверить перед передачей

Подготовку выгрузки удобно завершать несколькими конкретными вопросами.

1. Задача получателя понятна? Можно ли решить её с меньшим количеством подробностей или по сводным показателям?
2. Редкие сочетания проверены? Есть ли признаки, по которым человека можно выделить или найти в другом источнике?
3. Связи учтены? Остались ли токены, ключи, номера документов и другие способы сопоставления с исходными записями?
4. Окончательный файл проверен? Удалены ли скрытый текст, лишние метаданные, комментарии и ненужные листы?
5. Результат всё ещё полезен? Позволяет ли он ответить на исходный вопрос без возвращения к сырым данным?

Комментарий редакции AiHummer. Техническая обработка не заменяет проверку оснований и условий передачи. Для сведений о здоровье, биометрических и других чувствительных данных требуется отдельная оценка с учётом их содержания и сценария использования. Само название файла «обезличено» не определяет его правовой статус.

Адельмурдин формулирует требование к результату так: качественное обезличивание должно защищать человека и сохранять практическую ценность документа. Проверять эти две стороны нужно вместе. Если после удаления фамилий участника легко найти, обработку нужно продолжить. Если вместе с фамилиями исчезло всё, ради чего документ читали, стоит пересмотреть способ подготовки и состав передаваемых сведений.

Авторы

Тимур Рахматуллин — Senior Software Engineer, Softline Solutions. В комментарии делится опытом подготовки данных для машинного обучения и проверки облачной инфраструктуры.

Рустем Ахмеров — разработчик мобильных приложений. Рассказывает об обработке пользовательских данных в собственном проекте — тренажёре для обучения медперсонала.

Азат Адельмурдин — представляет проект ГИАТЕРРА с инструментом анонимизации юридических документов. Объясняет риски повторной идентификации по содержанию документов и открытым источникам.