Восстановление обезличенных ПДн: запрет

Для CTO вопрос обезличивания — не юридическая формальность, а архитектурное решение. Обезличенные данные формально выведены из-под ряда требований ФЗ-152, но только при условии невозможности их восстановления. Если ML-модель обучена на данных, которые можно деанонимизировать, — весь объём обработки возвращается в статус персональных. С 30.05.2025 ч. 15 ст. 13.11 КоАП устанавливает оборотный штраф до 500 млн ₽ за повторную утечку. В этом материале — как работает запрет восстановления, какие методы его обеспечивают и как выстроить архитектуру данных без правовых рисков.

Что означает запрет восстановления обезличенных ПДн?

Ст. 3 ФЗ-152 определяет обезличивание как действия, в результате которых невозможно определить принадлежность ПДн конкретному субъекту без использования дополнительной информации. Ключевое слово — «невозможно». Если восстановление технически достижимо — данные не считаются обезличенными по закону, независимо от применённых процедур.

Ст. 13.1 ФЗ-152, введённая ФЗ-233 от 08.08.2024, закрепила регулирование обезличенных ПДн. Закон разграничил: обезличенные ПДн находятся за пределами основных требований ФЗ-152, но только при соблюдении методологии. Нарушение метода или применение псевдонимизации вместо обезличивания возвращает массив в правовое поле ФЗ-152 со всеми обязанностями оператора.

Для CTO это означает следующее: усечение идентификатора, замена email на хэш MD5, удаление поля «имя» при сохранении связки телефон+адрес+дата рождения — не обезличивание. Это псевдонимизация, которая по позиции РКН остаётся обработкой ПДн.

Какие методы обезличивания исключают восстановление?

Приказ РКН (действует с 01.09.2025) закрепил пять методов обезличивания, применение которых признаётся достаточным для вывода данных из-под ФЗ-152. Каждый метод решает конкретную техническую задачу.

Введение идентификаторов. Замена прямых идентификаторов (ФИО, СНИЛС, номер телефона) на суррогатные ключи при условии уничтожения таблицы соответствия. Критично: если таблица соответствия сохранена — метод не применён.

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

Декомпозиция. Разделение набора данных на части, каждая из которых по отдельности не позволяет идентифицировать субъекта. Используется при распределённом хранении.

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

Обобщение и агрегация. Замена точных значений диапазонами или агрегатами (возраст 34 → диапазон 30–35; город → федеральный округ). Стандартный метод для ML-датасетов.

Как обезличивание связано с уровнями защищённости УЗ-1...УЗ-4?

ПП РФ №1119 от 01.11.2012 устанавливает четыре уровня защищённости ИСПДн. Уровень определяется пересечением трёх параметров: категория ПДн (специальные / биометрические / иные / общедоступные), тип актуальной угрозы (1–3) и количество субъектов (до 100 000 / свыше 100 000).

Обезличивание меняет категорию данных и тем самым влияет на требуемый уровень защищённости. Если данные корректно обезличены по методам Приказа РКН — они выходят из-под требований ПП №1119. Если обезличивание неполно — система продолжает классифицироваться по исходной категории ПДн.

Типичная ошибка в SaaS-архитектуре: ML-сервис получает выгрузку, которую разработчики считают обезличенной (хэши вместо email), но база сохраняет связанные атрибуты — дату регистрации, IP-адрес, поведенческие события. Комбинация этих атрибутов позволяет повторно идентифицировать субъекта. Система остаётся ИСПДн, требующей минимум УЗ-3 по Приказу ФСТЭК №21.

Для CTO в SaaS-продукте с мультиарендностью (multi-tenancy) вопрос осложняется: данные разных клиентов-операторов обрабатываются в одной инфраструктуре. Поручение обработки по ст. 6 ФЗ-152 обязывает соблюдать требования безопасности, установленные оператором-клиентом. Если хотя бы один клиент обрабатывает специальные категории ПДн — требования ПП №1119 по УЗ распространяются на всю инфраструктуру, используемую для этого клиента.

Что происходит при восстановлении обезличенных данных: риски по КоАП и УК

Если обезличенные данные восстановлены — оператор нарушил ст. 13.1 ФЗ-152 и фактически продолжал обработку ПДн без надлежащих правовых оснований. Это создаёт состав по ч. 1 ст. 13.11 КоАП (обработка ПДн в случаях, не предусмотренных законом) — штраф для юрлица 150 000 – 300 000 ₽.

Если результатом стала утечка — квалификация ужесточается. При объёме от 1 000 до 10 000 субъектов применяется ч. 12 ст. 13.11 КоАП (штраф 3–5 млн ₽), от 10 000 до 100 000 — ч. 13 (5–10 млн ₽), свыше 100 000 — ч. 14 (10–15 млн ₽). При повторном нарушении включается оборотный штраф по ч. 15: 1–3% совокупной годовой выручки, не менее 20 млн ₽ и не более 500 млн ₽.

С 11.12.2024 действует ст. 272.1 УК РФ (введена ФЗ-421). Незаконное использование, передача или хранение компьютерной информации, содержащей ПДн, образует уголовный состав. Максимальная санкция по ч. 5 (тяжкие последствия) — лишение свободы до 10 лет. Это прямо касается сценария, когда разработчик или аналитик использует реальные ПДн под видом обезличенных в тестовой или обучающей среде без надлежащего правового основания.

Снижение штрафа возможно при соблюдении условия по ст. 4.1 КоАП: если в течение трёх предшествующих лет организация инвестировала в информационную безопасность не менее 0,1% совокупной выручки — оборотный штраф по ч. 15 снижается до одной десятой минимума, но не менее 15 млн ₽ и не более 50 млн ₽.

Типовые сценарии: как CTO сталкивается с запретом восстановления

Сценарий 1. ML-датасет на псевдонимизированных данных. Команда data science выгружает пользовательские события, заменяет user_id на хэш SHA-256, удаляет поле email. В выгрузке остаётся: дата регистрации, регион, тариф, поведенческие паттерны. Внутренний аналитик восстанавливает связь с оригинальным user_id через join с продовой базой — таблица соответствия не уничтожена, просто хранится в другой схеме. Данные юридически остаются персональными. Применяемые меры защиты не соответствуют УЗ-3 (более 100 000 субъектов, иные ПДн, угроза 2-го типа). При проверке РКН — протокол по ч. 1 ст. 13.11, предписание о приостановке ML-сервиса.

Доказательства: журнал запросов к prod-базе из ML-окружения, схема join-операций в ETL-пайплайне. Вероятный исход: штраф 150 000–300 000 ₽ + предписание + репутационные издержки. Стратегия: внедрить метод обобщения и агрегации для обучающих выборок; уничтожить таблицу соответствия; разделить ML-окружение от prod-базы на уровне сети.

Сценарий 2. SaaS с мультиарендностью и поручением обработки. B2B-SaaS обрабатывает кадровые данные для клиентов-операторов. В договоре с клиентами — стандартное DPA (Data Processing Agreement), поручение обработки по ст. 6 ФЗ-152. Один клиент — медицинская организация, передаёт через API данные о состоянии здоровья сотрудников (специальные категории, ст. 10 ФЗ-152). Инфраструктура SaaS не сегрегирована: данные всех клиентов в одном кластере базы данных. Уровень защищённости для специальных категорий — минимум УЗ-3, возможно УЗ-2. Приказ ФСТЭК №21 требует конкретного набора мер: аутентификация (ИАФ), управление привилегиями (УПД), защита носителей (ЗНИ), регистрация событий (РСБ), антивирус (АВЗ), система обнаружения вторжений (СОВ). Без сегрегации — нарушение условий поручения обработки и требований оператора-клиента. Исход: расторжение договора, претензия клиента, протокол РКН. Стратегия: разделить инфраструктуру по уровням чувствительности данных; провести DPIA для мультиарендной архитектуры; зафиксировать применяемые меры в техническом приложении к DPA.

Сценарий 3. Тестовая среда с production-данными. Разработчики используют дамп prod-базы для воспроизведения бага. Дамп содержит ФИО, email, номера телефонов — данные не обезличены. Тестовая среда развёрнута на облачном провайдере, дата-центр за рубежом. Нарушения: обработка ПДн вне цели (тестирование ≠ цель из уведомления в реестре РКН), трансграничная передача без уведомления РКН по ст. 12 ФЗ-152, нарушение локализации по ч. 5 ст. 18 ФЗ-152. Если провайдер — не страна из перечня адекватной защиты РКН, применяется ч. 8 ст. 13.11 КоАП (1–6 млн ₽). Стратегия: внедрить процедуру обязательного обезличивания для тестовых сред; использовать облачные ресурсы только в российских дата-центрах или убедиться в наличии уведомления о трансграничной передаче.

Как практика реагирует на нарушения при обезличивании

Кейс 1. IT-компания (Центральный ФО, осень 2025) использовала псевдонимизированные данные пользователей для обучения рекомендательной модели. Таблица соответствия хранилась в prod-базе. Внеплановая проверка РКН выявила возможность восстановления идентификаторов. Компания привлечена по ч. 1 ст. 13.11 КоАП; одновременно выдано предписание о приостановке ML-сервиса до устранения нарушения. Штраф для юрлица составил сумму в нижнем диапазоне санкции — с учётом первичности нарушения. Предписание выполнено в течение трёх месяцев: внедрён метод обобщения для обучающей выборки, таблица соответствия уничтожена.

Кейс 2. SaaS-провайдер (Северо-Западный ФО, начало 2026) хранил дампы клиентских баз для нужд техподдержки на облачном сервере в юрисдикции страны, не входящей в перечень адекватной защиты РКН. Клиент-оператор подал жалобу в РКН. По результатам проверки возбуждено дело по ч. 8 ст. 13.11 КоАП (нарушение локализации). Параллельно РКН направил уведомление о несоответствии условий поручения обработки ФЗ-152. Арбитражный суд региона применил смягчающие обстоятельства (добровольное устранение нарушения, первичность), штраф назначен в нижней части диапазона 1–6 млн ₽.

Услуги DATUM по теме

• DPIA (оценка воздействия) — оценка архитектуры обработки ПДн в ML-сервисах и SaaS с выявлением рисков восстановления.
• Аудит соответствия 152-ФЗ — проверка методов обезличивания, уровней защищённости, соответствия Приказу ФСТЭК №21.
• Комплект ОРД под ключ — политика обработки ПДн, регламент обезличивания, техническое приложение к DPA.

Частые вопросы

1. Какой УЗ выбрать для SaaS?

Уровень защищённости определяется по ПП РФ №1119 исходя из наиболее чувствительной категории данных среди всех обрабатываемых клиентов. Если хотя бы один клиент-оператор передаёт специальные категории ПДн (здоровье, биометрия), минимальный уровень — УЗ-3, при объёме свыше 100 000 субъектов или угрозе 1-го типа — УЗ-2 или УЗ-1. Мультиарендная архитектура не позволяет применять разные УЗ к одному кластеру инфраструктуры — требуется физическая или логическая сегрегация по уровню чувствительности данных.

2. Можно ли использовать иностранные облака?

Запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ обязаны выполняться в базах данных на территории России — ч. 5 ст. 18 ФЗ-152. Хранение дампов, резервных копий или тестовых сред с ПДн за рубежом нарушает требование локализации. Нарушение квалифицируется по ч. 8 ст. 13.11 КоАП: штраф 1–6 млн ₽, при повторном нарушении — 6–18 млн ₽. Зарубежные облака допустимы только для данных, которые корректно обезличены по методам Приказа РКН — при условии, что восстановление невозможно.

3. Что такое обезличивание для ML?

Обезличивание для ML — это приведение обучающей выборки к виду, при котором невозможно установить принадлежность записи конкретному субъекту ПДн. Применяются методы из Приказа РКН: обобщение (точные значения заменяются диапазонами), перемешивание (атрибуты перераспределяются между записями), декомпозиция (датасет разбивается на части без сквозного ключа). Замена идентификатора на хэш без уничтожения таблицы соответствия — псевдонимизация, не обезличивание. Обученная ML-модель, способная реконструировать исходные ПДн, также считается обработкой ПДн.

4. Кто оператор в мультиарендной SaaS?

В мультиарендной SaaS клиент-бизнес является оператором ПДн своих пользователей. SaaS-провайдер — лицо, осуществляющее обработку по поручению оператора в соответствии со ст. 6 ФЗ-152. Это означает: провайдер не вправе использовать данные клиентов за пределами целей, определённых оператором; обязан соблюдать требования безопасности, установленные оператором; несёт ответственность перед оператором за нарушения условий поручения. При этом РКН при проверке вправе предъявлять требования непосредственно провайдеру как лицу, фактически обрабатывающему ПДн.

5. Какие СЗИ обязательны?

Состав средств защиты информации определяется Приказом ФСТЭК №21 от 18.02.2013 исходя из установленного уровня защищённости (УЗ). Обязательные группы мер: идентификация и аутентификация (ИАФ), управление правами доступа (УПД), защита носителей (ЗНИ), регистрация событий безопасности (РСБ), антивирусная защита (АВЗ). Для УЗ-1 и УЗ-2 дополнительно требуется система обнаружения вторжений (СОВ) и контроль целостности (ОЦЛ). Применяемые СЗИ должны иметь сертификаты ФСТЭК России в соответствии с классом защиты, соответствующим УЗ системы.

Итог

Запрет восстановления обезличенных ПДн — это техническое требование с правовыми последствиями. Некорректное обезличивание возвращает весь массив в статус персональных данных, создавая основания для штрафов от 150 000 ₽ до 500 млн ₽ (оборотный) и уголовной ответственности по ст. 272.1 УК. Для CTO это означает необходимость верификации методов обезличивания, сегрегацию инфраструктуры по уровням чувствительности и процедурный запрет на использование prod-данных в тестовых и обучающих средах без предварительного обезличивания по Приказу РКН.

DATUM сопровождает IT-компании и SaaS-провайдеров в выстраивании архитектуры обработки ПДн: от DPIA до аудита технических мер по Приказу ФСТЭК №21 и комплекта ОРД с политикой обезличивания.