Обезличивание персональных данных: где проходит граница между законом и аналитикой

Эпоха «просто удали ФИО» закончилась. В 2026 году обезличивание превратилось из технической рутины в высокорисковую стратегию на стыке математики и права. Ошибка в архитектуре данных сегодня стоит компании не просто лояльности клиентов, а реальных процентов от годовой выручки. Пока аналитики требуют «сырые» датасеты для обучения ИИ, а юристы настаивают на жестком соблюдении ФЗ-152, ИБ-специалист обязан найти работающий баланс. Кибер Медиа разбирает, где проходит юридическая граница между персональными и обезличенными данными, достаточно ли заменить ФИО на ID и можно ли «вытащить» конкретного человека из уже обученной модели.

Содержание

1. Почему тема обезличивания снова в центре внимания
2. Что считается обезличиванием с точки зрения закона
3. Методы обезличивания: от классических подходов к формализованным метрикам
4. Обезличивание и обучение ИИ: где возникают реальные риски
5. Трансграничная передача: если данные «обезличены», но не до конца
6. Документы и доказательная база: как защитить компанию
7. Практическая архитектура: как совместить аналитику и комплаенс
8. Заключение

Почему тема обезличивания снова в центре внимания

Еще недавно обезличивание воспринималось как техническая процедура: убрать ФИО, заменить паспорт на ID, ограничить доступ к таблице соответствия — и можно передавать датасет аналитикам. Сегодня такой подход слишком рискованный. Изменилась регуляторная среда, технологи и цена ошибки.

Внимание к обезличиванию усилилось по трем причинам:

1. Рост регуляторного давления и оборотные штрафы. Проверяют не только факт утечки, но и зрелость процессов. Важно не заявить «мы обезличили», а доказать, что риск повторной идентификации оценен и снижен. Обезличивание превращается из технической операции в элемент риск-менеджмента.
2. Массовое использование данных для аналитики и ИИ. Чем больше признаков в датасете, тем выше риск реидентификации. Удаление прямых идентификаторов уже не гарантирует безопасности: косвенные признаки могут «собрать» человека обратно.
3. Требования к доказуемости. Необходимо показать методику, оценку риска, контроль ключей соответствия и регламент передачи данных. Без этого обезличивание выглядит как декларация, а не подтвержденный процесс.

По сути, произошел переход от бинарной логики «персональные/неперсональные» к вероятностной модели риска. Обезличивание — это уже не состояние, а результат оценки. И для ИБ-специалиста это означает новую роль: не просто закрыть доступ к столбцу с ФИО, а выстроить воспроизводимый процесс, который выдержит аудит, проверку регулятора и, при необходимости, судебный спор.

Что считается обезличиванием с точки зрения закона

В российском праве обезличивание — это не финальное состояние данных, а лишь временная мера защиты. Согласно ФЗ-152, это процесс, который делает невозможным определение личности без «дополнительной информации». Главная ловушка для бизнеса: обезличенные данные остаются персональными. Вы обязаны защищать их так же строго, как и прямые контакты клиентов, пока сохраняется техническая возможность «отката» к исходному состоянию.

Дмитрий Келин

Основатель и руководитель юридической компании Kelin

Нет, замена ФИО и других прямых идентификаторов на код при наличии у оператора ключа соответствия не является обезличиванием в смысле 152-ФЗ.

Новый приказ РКН №140 от 19.06.2025 прямо закрепляет это в нормативной конструкции: метод введения идентификаторов (п. 2 Приложения №2) предусматривает обязательное создание ключа соответствия, который хранится оператором отдельно и не передается третьим лицам. При этом п. 4 Приложения №1 требует, чтобы результат обезличивания исключал возможность определить принадлежность данных субъекту без использования дополнительной информации. Пока ключ существует у оператора — это условие не выполнено.

Таким образом, данные с сохраненным ключом соответствия остаются персональными, и все обязанности по 152-ФЗ сохраняются в полном объеме. Введение идентификаторов без уничтожения ключа — это псевдонимизация, снижающая риски утечки, но не меняющая правовой статус данных.

Юридическая легитимность процедуры держится на «ключе соответствия» (алгоритмы, таблицы связей, «соль» для хэша). Если администратор БД может сопоставить ID с реальным ФИО в один клик, данные признаются необезличенными, что мгновенно создает риски по ст. 13.11 КоАП РФ. Чтобы избежать претензий регулятора, оператор обязан обеспечить режим раздельного хранения: ключ и основной массив данных не могут находиться в одном контуре доступа.

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

Методы обезличивания: от классических подходов к формализованным метрикам

На практике обезличивание редко ограничивается одной техникой. Это всегда комбинация методов, выбранная с учетом целей обработки и допустимого уровня риска. И если раньше достаточно было «почистить» таблицу, то сегодня ИБ-команде приходится мыслить категориями вероятности реидентификации и измеряемых метрик.

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

Следующий слой — маскирование, агрегация и обобщение:

• Маскирование скрывает часть значения, например, дата рождения → только год.
• Агрегация поднимает уровень детализации, например, точный адрес → район.
• Обобщение расширяет диапазоны, например, возраст 37 → категория 35–40.

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

Наталья Абрамова

Независимый эксперт

Даже без имени и паспортных данных человека можно вычислить по совокупности косвенных характеристик: по возрасту, региону, профессии, редким параметрам. Представьте запись: «женщина, 39 лет, живет в небольшом северном городе, пилот гражданской авиации». Таких людей единицы. Именно поэтому перед передачей данных любому аналитику или разработчику GenAI необходимо проверять датасет на так называемые квази-идентификаторы, то есть комбинации признаков, которые в совокупности раскрывают личность. Если в ходе проверки удается восстановить хотя бы одного человека, то этот метод обезличивания признается недостаточным. Это прямое требование Роскомнадзора.

Здесь на помощь приходят количественные модели:

• k-anonymity — каждая запись неотличима как минимум от k–1 других по выбранным признакам.
• l-diversity — внутри группы с одинаковыми квази-идентификаторами сохраняется разнообразие чувствительных атрибутов.
• t-closeness — распределение чувствительных данных в группе близко к распределению в общем датасете.

Эти модели позволяют оценить, насколько легко выделить конкретного человека из массива данных. Однако они не универсальны и плохо работают в высокоразмерных датасетах, характерных для ИИ-задач.

Более продвинутый подход — differential privacy. Он предполагает добавление контролируемого шума в данные или результаты запросов таким образом, чтобы присутствие или отсутствие конкретного человека практически не влияло на итог. Это уже не просто модификация таблицы, а математически обоснованная модель ограничения утечки информации. Минус — сложность внедрения и влияние на точность аналитики.

Максим Захаренко

СЕО «Облакотека»

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

Используем и формальные подходы — k-anonymity, оценка риска реидентификации, в отдельных проектах элементы differential privacy. Но важно понимать: это не галочка в чек-листе, а управляемый риск, который надо регулярно пересматривать.

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

Обезличивание и обучение ИИ: где возникают реальные риски

Как только данные попадают в обучение модели, логика обезличивания меняется. В классической ИТ-системе мы работаем с записями: строка есть — строку можно удалить. В машинном обучении данные превращаются в параметры, веса и статистические зависимости. И это уже другая плоскость рисков.

Во-первых, ИИ повышает риск обратной идентификации. Чем больше признаков использует модель, тем выше вероятность уникальных комбинаций. Даже без прямых идентификаторов редкое сочетание атрибутов может позволить выделить человека при сопоставлении с внешними источниками. Модель усиливает скрытые корреляции — и тем самым расширяет поверхность риска.

Во-вторых, существует проблема data leakage и memorization. Модель способна «запоминать» редкие или чувствительные фрагменты обучающих данных и при определенных запросах воспроизводить их. Формально датасет обезличен, но утечка происходит через поведение алгоритма — и это уже риск не на уровне хранения, а на уровне самой модели.

Третья особенность — эффект «вечной памяти». Если субъект отозвал согласие или потребовал прекратить обработку, удалить его запись из базы технически несложно. Но вклад этой записи уже распределен по параметрам модели. Статистическое влияние остается, даже если исходная строка стерта. С точки зрения жизненного цикла данных это означает, что ИБ-команда должна учитывать не только хранилища, но и все производные артефакты: модели, эмбеддинги, кэши, бэкапы.

В этой точке возникает вопрос о machine unlearning — возможности удалить вклад конкретного человека из обученной модели. Такие подходы в теории существуют, но на практике, они часто сводятся к одному из вариантов:

• полное переобучение модели на очищенном датасете;
• частичное переобучение с изоляцией сегмента данных;
• использование специальных алгоритмов, изначально спроектированных с возможностью «отката» влияния отдельных записей.

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

Станислав Ежов

Директор по ИИ «Группы Астра»

Machine unlearning существует, но переоценивать его не стоит. NIST описывает концепцию, практика же намного жестче, так как для большой модели «забыть» одного человека означает недели переобучения и никаких твердых гарантий. Поэтому правильный момент думать о защите все же до обучения, а не после жалобы субъекта.

Таким образом, в контуре ИИ обезличивание — это не финальный шаг перед передачей данных разработчикам. Это часть архитектуры всей ML-инфраструктуры. Нужно заранее оценивать риски реидентификации через модель, учитывать вероятность memorization и понимать, что «удалить строку» не равно «удалить влияние». Иначе юридические обязательства и техническая реальность могут разойтись слишком далеко.

Трансграничная передача: если данные «обезличены», но не до конца

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

Ключевой вопрос — действительно ли данные перестали быть персональными. Если сохраняется возможность обратной идентификации, то формально режим персональных данных продолжает действовать. А значит, и требования к трансграничной передаче тоже.

На практике обезличенные данные подпадают под трансграничный режим в трех типовых ситуациях:

1. У оператора или группы компаний сохраняется возможность восстановить идентификацию.
2. Принимающая сторона теоретически может сопоставить массив с другими имеющимися у нее данными.
3. Уровень обезличивания не подтвержден формализованной оценкой риска и может быть оспорен.

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

Василий Сеничев

Основатель сервиса автоматизации информационной безопасности «Кибероснова»

Если данные действительно обезличены необратимо — формально это уже не персональные данные и режим трансграничной передачи не применяется. Но ключевой вопрос — кто и как подтверждает необратимость. В российском законодательстве пока нет четкой процедуры сертификации обезличивания. Это значит, что при любом сомнении регулятор может признать данные персональными. Мой совет: если передаете за рубеж — оформляйте как трансграничную передачу. Спокойнее для всех, и точно дешевле, чем оборотный штраф.

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

Алексей Колодка

Директор по работе с государственными заказчиками компании «ГИГАНТ Компьютерные системы»

Если данные были обезличены в России и затем переданы в иностранную компанию или группу, такая передача не является трансграничной, потому что в этом случае не считается, что обезличенные данные пересекают границу назначения. Все эти действия также регулируются федеральным законом «О персональных данных» (152-ФЗ от 27.07.2006 года). После обезличивания данные теряют свою конфиденциальность и могут передаваться в любом направлении, в том числе через границу. И естественно к таким данным не применяется законодательное регулирование в принципе.
Хотел бы заметить, что трансграничная передача, согласно статье 12 152-ФЗ, касается только ПДн, то есть информации, которая прямо или косвенно относится к определенному физическому лицу. Оператор обязан использовать методы обезличивания, предусмотренные приказом Роскомнадзора от 19.06.2025 №140. Организация, которая занимается обезличиванием данных, должна зафиксировать в своих локальных нормативных актах применение методов обезличивания и убедиться, что они соответствуют основным требованиям законодательства. И оператору персональных данных, и организации, которая занимается обезличиванием, важно понимать, чем они должны руководствоваться и как убедиться, что данные действительно обезличены.

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

Документы и доказательная база: как защитить компанию

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

Минимальный «каркас» зрелого процесса обычно включает:

• Политику обезличивания. Документ, который описывает цели, принципы, применяемые методы и зоны ответственности. Это не абстрактная декларация, а рабочий документ, на который можно сослаться при проверке.
• Методику оценки риска реидентификации. Формализованный подход к анализу квази-идентификаторов, уникальности записей и сценариев возможной деанонимизации. Именно здесь фиксируется, почему компания считает уровень риска допустимым.
• DPIA / оценку воздействия. Особенно актуально при использовании данных для ИИ или трансграничной передачи. Такой документ показывает, что риски были проанализированы заранее, а не «постфактум».
• Регламент работы с ключами соответствия. Если псевдонимизация используется как этап обработки, должно быть четко определено, где хранится ключ, кто имеет доступ, как логируются обращения и при каких условиях возможна обратная идентификация.
• Договорные условия при передаче данных. Фиксация статуса данных, запрета на попытки реидентификации, требований к защите и уведомлению об инцидентах. Особенно важно при передаче аналитикам или зарубежным структурам группы.
• Логирование и контроль доступа. Технические меры, подтверждающие, что доступ к данным и ключам действительно ограничен и контролируется, а не только описан в политике.

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

Практическая архитектура: как совместить аналитику и комплаенс

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

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

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

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

И наконец, распределение ролей. DPO задает правовые рамки, ИБ отвечает за техническую реализуемость и устойчивость, data-команда — за качество и применимость данных. Если архитектура выстроена правильно, эти роли не конфликтуют, а дополняют друг друга. Тогда комплаенс не тормозит аналитику, а задает понятные границы, внутри которых можно безопасно работать.

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

Заключение

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

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