Тендеры на обезличивание

Государственные и корпоративные заказчики всё активнее выносят задачи обезличивания в отдельные закупки: обучающие датасеты для ML, деперсонализация медицинских регистров, подготовка данных для аналитических платформ. Технический директор, получив такой тендер или выпуская собственный продукт под него, сталкивается с двумя слоями требований — законодательным (ФЗ-152, подзаконные акты РКН) и техническим (ФСТЭК, уровни защищённости). Ошибка на любом слое превращает выигранный контракт в административное или уголовное дело.

Что регулирует обезличивание и почему это важно для тендерного ТЗ?

Обезличивание по ст. 3 ФЗ-152 — действия, в результате которых определить принадлежность данных конкретному субъекту становится невозможным без привлечения дополнительной информации. Ключевое слово — «невозможным». Псевдонимизация (замена имени идентификатором при сохранении ключа соответствия) обезличиванием не является: такие данные остаются персональными и требуют полного режима ч. 5 ст. 18 ФЗ-152 о локализации.

Приказ РКН о методах обезличивания (действует с 1 сентября 2025 года) закрепил пять методов: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация. Тендерное ТЗ, не указывающее метод или допускающее только псевдонимизацию, создаёт правовую неопределённость: исполнитель формально выполнит работу, но результат не будет считаться обезличенным по ФЗ-152.

Статья 13.1 ФЗ-152 (введена ФЗ-233 от 8 августа 2024 года) дополнила картину: операторы, передающие обезличенные данные в ЕИП НСУД по запросу Минцифры, обязаны применять только утверждённые методы. Для коммерческих SaaS-платформ, обрабатывающих данные нескольких клиентов-операторов, это создаёт вопрос о роли платформы: является ли она лицом, осуществляющим обработку по поручению (ст. 6 ч. 3 ФЗ-152), или самостоятельным оператором при формировании аналитических датасетов.

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

Постановление Правительства РФ № 1119 от 1 ноября 2012 года делит информационные системы персональных данных на четыре уровня защищённости в зависимости от категории данных, типа угроз и числа субъектов. Для тендеров на обезличивание это имеет прямое значение: исходные данные до начала работ обрабатываются в ИСПДн заказчика с определённым УЗ, и исполнитель, получая доступ к ним, попадает под требования того же уровня.

При числе субъектов более 100 000 и специальных категориях данных (ст. 10 ФЗ-152 — здоровье, биометрия) система заказчика, как правило, имеет УЗ-2 или УЗ-1. Исполнитель по тендеру, подключающийся к такой системе или получающий выгрузку из неё, обязан обеспечить эквивалентный уровень на своей инфраструктуре. Приказ ФСТЭК № 21 от 18 февраля 2013 года задаёт состав организационных и технических мер для каждого уровня: 109 мер в 15 функциональных группах (идентификация и аутентификация, управление доступом, защита носителей информации, регистрация событий безопасности и т. д.).

Тендерное ТЗ, не указывающее УЗ исходной системы, перекладывает риск определения уровня на исполнителя. Если исполнитель ошибается и применяет УЗ-3 к данным УЗ-2, он несёт ответственность по ч. 1 ст. 13.11 КоАП за обработку без надлежащих мер защиты.

Обезличивание для ML: где граница между «обезличено» и «всё ещё персональные данные»?

Машинное обучение создаёт специфический риск реидентификации: модель, обученная даже на формально обезличенных данных, может «запомнить» конкретные записи и воспроизводить их при определённых запросах. Это явление называется утечкой обучающих данных через модель. РКН пока не выпустил отдельных разъяснений по нейросетевым моделям, но базовый принцип ст. 5 ФЗ-152 о недопустимости избыточной обработки применим и здесь.

Для тендеров на подготовку датасетов под ML практически это означает: исполнитель должен подтвердить, что применённый метод обезличивания исключает обратную идентификацию не только прямым сопоставлением, но и через ML-атаки (membership inference). Это требование пока не закреплено в российском праве явно, но заказчики из числа крупных госструктур начинают включать его в ТЗ со ссылкой на «лучшие практики» и международные стандарты.

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

Мультиарендность SaaS и поручение обработки: кто отвечает при тендерных работах?

SaaS-платформа, обрабатывающая данные нескольких операторов-клиентов, находится в правовом статусе лица, осуществляющего обработку по поручению (п. 3 ст. 6 ФЗ-152). Это означает: каждый клиент-оператор обязан заключить с платформой отдельный договор поручения, устанавливающий перечень допустимых действий, цели, категории данных и требования к защите. При тендерных работах на обезличивание заказчик государственного контракта выступает оператором, а исполнитель — обработчиком по поручению.

Проблема мультиарендной архитектуры в тендерном контексте: если платформа исполнителя одновременно обслуживает нескольких заказчиков и их данные хранятся в общей инфраструктуре (shared database schema или shared storage), возникает риск нарушения ч. 5 ст. 18 ФЗ-152 (смешение баз с разными целями и операторами) и ст. 5 ФЗ-152 (недопустимость объединения несовместимых баз). Государственные тендеры на обезличивание медицинских или налоговых данных в таком случае требуют изолированной мультиарендной архитектуры — отдельного хранилища на каждого заказчика.

Облако в РФ — обязательное требование при обработке ПДн граждан РФ по ч. 5 ст. 18 ФЗ-152. Иностранные облачные провайдеры, включая локальные зоны AWS и Azure в РФ, допустимы только если физические серверы с первичными базами данных находятся на территории РФ и это подтверждено договором с провайдером. При любых сомнениях заказчик государственного тендера потребует документального подтверждения локализации.

Типовые сценарии при тендерах на обезличивание

Сценарий 1. Исполнитель применил псевдонимизацию вместо обезличивания. IT-компания выиграла тендер на подготовку датасета для медицинской аналитики. В ТЗ был указан «метод замены идентификаторов», который исполнитель реализовал как псевдонимизацию с сохранением ключа соответствия на своём сервере. Заказчик принял работу, но в ходе проверки РКН установил, что данные остаются персональными. Оператор-заказчик получил предписание и штраф по ч. 1 ст. 13.11 КоАП (150–300 тыс. ₽). Исполнитель как обработчик по поручению был привлечён к ответственности солидарно. Ключевой урок: ТЗ должно прямо указывать метод обезличивания из перечня РКН и запрещать сохранение ключей соответствия на инфраструктуре исполнителя.

Сценарий 2. SaaS-платформа без изоляции данных заказчиков. Компания — разработчик аналитической SaaS-платформы участвовала в тендерах нескольких региональных органов здравоохранения. Данные всех заказчиков обрабатывались в единой схеме базы данных с разграничением по tenant_id. После хакерской атаки на платформу данные одного из регионов оказались доступны через уязвимость в изоляции арендаторов. РКН квалифицировал ситуацию как нарушение требований к обработке специальных категорий ПДн по ч. 5 ст. 13.11 КоАП. Стратегия: при участии в государственных тендерах на обработку специальных категорий ПДн SaaS-платформе необходима архитектурная изоляция на уровне отдельных экземпляров базы данных для каждого заказчика, а не только логическое разделение.

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

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

1. Какой УЗ выбрать для SaaS-платформы, участвующей в тендере?

Уровень защищённости определяется характеристиками обрабатываемых данных по ПП РФ № 1119: категория (общие, специальные, биометрические), тип угроз (1–3) и число субъектов (порог 100 000). Для тендеров на обезличивание медицинских или биометрических данных при числе субъектов более 100 000 минимальный уровень — УЗ-2, при угрозах 1-го типа — УЗ-1. SaaS-платформа, не определившая УЗ до начала тендерных работ, принимает на себя риск несоответствия требованиям Приказа ФСТЭК № 21 — это 109 мер защиты в 15 группах, часть которых обязательна для базового набора конкретного УЗ.

2. Можно ли использовать иностранные облака для тендерных работ с ПДн граждан РФ?

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

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

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

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

Клиент-организация, чьи данные обрабатываются на платформе, остаётся оператором по ст. 3 ФЗ-152 и несёт ответственность за законность обработки. SaaS-платформа выступает лицом, осуществляющим обработку по поручению (п. 3 ст. 6 ФЗ-152). Каждый клиент-оператор обязан заключить с платформой отдельный договор поручения с перечнем допустимых действий. Если платформа самостоятельно формирует агрегированные аналитические отчёты, используя данные нескольких клиентов, она приобретает статус самостоятельного оператора в отношении этих производных данных — со всеми вытекающими обязательствами по ФЗ-152.

5. Какие СЗИ обязательны для исполнителя тендера на обезличивание?

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

Итог

Тендеры на обезличивание персональных данных — это пересечение технических требований (УЗ-1..4, Приказ ФСТЭК № 21, методы РКН) и правовых обязательств (ст. 3, 5, 6, 13.1 ФЗ-152, ч. 8 ст. 13.11 КоАП). Ошибка в квалификации метода, архитектуре мультиарендности или локализации инфраструктуры превращает технически выполненную работу в административное нарушение с санкцией до 18 млн ₽ при повторности.

Юристы DATUM сопровождают технические команды на этапе анализа тендерного ТЗ, формирования договора поручения и проверки соответствия инфраструктуры уровням защищённости — до начала работ, а не после проверки РКН.

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

• Аудит соответствия 152-ФЗ — проверка методологии обезличивания, уровней защищённости и договоров поручения
• DPIA (оценка воздействия) — для тендеров на обработку специальных категорий ПДн и биометрии
• Комплект ОРД под ключ — договоры поручения, политики, приказы для исполнителя тендера

13 октября 2028 года