Сохранение результатов экспериментов
В ML-разработке сохранение результатов экспериментов включает датасеты, чекпойнты моделей, логи метрик, feature stores и артефакты версионирования. Если в любом из этих элементов содержатся персональные данные граждан России — возникает полноценный цикл обработки ПДн со всеми требованиями ФЗ-152. По данным InfoWatch за 2025 год, технические команды остаются источником инцидентов в 38% случаев утечек в IT-секторе: причина — неконтролируемые артефакты экспериментов. Ниже — разбор нормативной рамки, типовых архитектурных решений и стратегии снижения рисков для CTO.
Какой уровень защищённости (УЗ) применяется к хранилищу экспериментов?
Уровень защищённости определяется пересечением трёх параметров: категория ПДн, тип актуальных угроз и количество субъектов. Для ML-задач чаще всего актуальны два сценария.
Первый — обучающая выборка содержит только общедоступные или обезличенные данные. Формально требования ПП РФ №1119 не применяются. Второй — выборка включает имена, телефоны, адреса, поведенческие профили или медицинские показатели. Здесь категория «общие ПДн» при числе субъектов свыше 100 000 и угрозах 3-го типа даёт минимум УЗ-3; при угрозах 2-го типа — УЗ-2. Спецкатегории (здоровье, биометрия) поднимают планку до УЗ-1 или УЗ-2 вне зависимости от объёма.
Практическая проблема: хранилище экспериментов (MLflow, DVC, Weights & Biases) почти никогда не проходит через процедуру классификации ИСПДн. Команда воспринимает его как инструмент разработчика, а не как информационную систему. Между тем именно в артефактах экспериментов накапливаются необработанные выборки с полными ПДн — до момента, когда продакшн-конвейер их обезличивает.
Для CTO ключевой вопрос — зафиксировать границу ИСПДн: входит ли хранилище экспериментов в периметр аттестованной системы или существует как «серая зона». Любая серая зона — основание для предписания РКН при проверке.
Как правильно выстроить обезличивание для ML и сохранить исследовательскую ценность данных?
С 01.09.2025 Приказ РКН №140 закрепил 5 методов обезличивания: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация. Для ML-задач наиболее применимы введение идентификаторов (замена прямых идентификаторов суррогатными ключами) и обобщение (замена точных значений диапазонами).
Обезличивание должно быть необратимым или условно-необратимым в зависимости от задачи. Если обратное восстановление субъекта технически возможно — данные остаются ПДн по ст. 3 ФЗ-152, даже если прямой идентификатор удалён. Судебная практика и позиция РКН исходят из того, что «псевдонимизация» без удаления связки ключей не снимает статус оператора.
Архитектурно для ML-экспериментов рекомендуется следующая схема: продакшн-хранилище с исходными ПДн → pipeline обезличивания с ведением журнала операций → раздельное хранилище обезличенных выборок для экспериментов. Ключевой элемент — журнал операций обезличивания как доказательство выполнения требований на случай проверки или инцидента.
Логи самих экспериментов — отдельная точка риска. Если в лог попадают входные образцы, предсказания по конкретным субъектам или feature values с идентификаторами — это обработка ПДн. Требование: логи экспериментов должны содержать только агрегированные метрики, без строчных данных субъектов.
Ваш ML-стек хранит артефакты экспериментов с ПДн?
Если CTO не уверен, входит ли хранилище экспериментов в периметр ИСПДн, — это уже риск. Несоответствие уровня защищённости фактической категории данных создаёт основание для штрафа по ч. 1 ст. 13.11 КоАП (150–300 тыс. ₽) и предписания об устранении. При утечке обучающей выборки от 1 000 субъектов — ч. 12 ст. 13.11 (3–5 млн ₽). Юристы DATUM проведут аудит обработки ПДн по чек-листу из 38 пунктов и классифицируют ваши ИСПДн, включая ML-инфраструктуру.
Заказать аудит 152-ФЗОтветим за 2 часа · +7 (983) 510-38-76 · info@vitveteam.ru · Telegram
Кто является оператором в мультиарендной SaaS с ML-модулем?
В SaaS-архитектуре с мультиарендностью возникает многоуровневая цепочка ответственности. Клиент SaaS-платформы (тенант) является оператором в отношении ПДн своих пользователей. Платформа как таковая — обработчик по поручению (п. 3 ст. 6 ФЗ-152), если обрабатывает данные тенанта в рамках договора.
Ключевой вопрос — наличие письменного поручения обработки. Без него платформа фактически является самостоятельным оператором без правового основания по ст. 6 ФЗ-152. Типовое SaaS-соглашение (Terms of Service, DPA) должно содержать перечень операций, цели, состав ПДн и требования по безопасности, передаваемые исполнителю.
В ML-контексте ситуация усложняется: если платформа использует данные тенантов для дообучения общей модели — это выходит за рамки поручения. Использование ПДн одного тенанта для улучшения сервиса для другого тенанта нарушает принцип совместимости целей по ст. 5 ФЗ-152. Необходимо явное отдельное согласие или полное обезличивание до использования в обучении.
Отдельный вопрос — локализация. По ч. 5 ст. 18 ФЗ-152 первичные операции (запись, систематизация, накопление, хранение, уточнение, извлечение) с ПДн граждан России должны выполняться на серверах в РФ. С 01.07.2025 требования ужесточены: облачная инфраструктура для ML-экспериментов с российскими ПДн должна быть расположена у российского провайдера либо в российском регионе облака. Использование AWS/GCP/Azure без российского региона для хранения исходных выборок — нарушение ч. 8 ст. 13.11 КоАП (1–6 млн ₽).
Что подготовить CTO для соответствия 152-ФЗ в ML-инфраструктуре
- Провести инвентаризацию хранилищ экспериментов (MLflow, DVC, S3-совместимые) и определить, содержат ли они ПДн граждан РФ в необезличенном виде.
- Классифицировать ИСПДн, включая ML-хранилище: категория данных × тип угроз × число субъектов → уровень УЗ по ПП РФ №1119.
- Реализовать pipeline обезличивания до передачи данных в хранилище экспериментов; обеспечить раздельное хранение ключей деанонимизации.
- Проверить наличие письменного поручения обработки с каждым облачным провайдером, использующим российские ПДн; убедиться, что серверы хранения находятся в РФ.
- Настроить логирование операций обезличивания и доступа к ML-хранилищу как доказательную базу для проверки РКН.
Какие технические меры по Приказу ФСТЭК №21 обязательны для ML-систем?
Приказ ФСТЭК №21 устанавливает 109 мер в 15 группах. Базовый набор определяется уровнем защищённости. Для ML-инфраструктуры наиболее критичны четыре группы.
Идентификация и аутентификация (ИАФ): доступ к хранилищу экспериментов — только через корпоративный IAM с многофакторной аутентификацией. Сервисные аккаунты CI/CD-конвейеров должны иметь минимальные привилегии по принципу least privilege.
Управление доступом (УПД): разграничение доступа к сырым данным и обезличенным выборкам. Датасайентист работает только с обезличенной копией; доступ к исходным данным — по заявке с логированием.
Регистрация событий (РСБ): все операции чтения, записи и копирования ПДн из хранилища должны фиксироваться в защищённом журнале. Срок хранения журналов — не менее 3 лет для УЗ-3 и выше. Логи экспериментов (MLflow tracking server, wandb) при наличии в них ПДн входят в периметр РСБ.
Защита носителей (ЗНИ): шифрование данных на носителях обязательно с УЗ-2. Для объектных хранилищ (S3-совместимых) — шифрование на уровне bucket с управляемыми ключами в российском KMS.
Если CTO планирует аттестацию ML-инфраструктуры или готовится к проверке РКН — оценка воздействия (DPIA) позволит выявить риски до инцидента. По ФЗ-152 DPIA не является формально обязательной для всех операторов, но при наличии автоматизированных решений по ст. 16 и обработке данных в масштабе — её отсутствие создаёт регуляторный риск. Юристы DATUM проведут оценку воздействия и идентифицируют меры снижения рисков.
Провести DPIAТиповые сценарии и стратегия реагирования для CTO
Сценарий 1. Хранилище экспериментов содержит необезличенные ПДн, облако — иностранное. Ситуация: команда использует AWS S3 (регион eu-west-1) для хранения артефактов MLflow с выборками, содержащими email и поведенческие профили пользователей. Доказательства нарушения: факт хранения необезличенных ПДн граждан РФ за пределами РФ фиксируется при проверке РКН по индикатору риска «иностранное облако». Вероятный исход: предписание об устранении + штраф по ч. 8 ст. 13.11 КоАП (1–6 млн ₽). При систематическом характере — повторное нарушение по ч. 9 (6–18 млн ₽). Стратегия: миграция хранилища артефактов в российский облачный регион (Яндекс Cloud, SberCloud, МТС Cloud); параллельно — внедрение pipeline обезличивания.
Сценарий 2. SaaS-платформа дообучает модель на данных тенантов без отдельного основания. Ситуация: платформа агрегирует логи взаимодействий всех тенантов для улучшения рекомендательной модели; в DPA это не зафиксировано. Доказательства нарушения: обработка ПДн с несовместимой целью по ст. 5 ФЗ-152 + отсутствие самостоятельного правового основания по ст. 6. Исход: штраф по ч. 1 ст. 13.11 (150–300 тыс. ₽) + предписание о прекращении обработки. Стратегия: обновить DPA с тенантами, добавив явное основание для обезличенного использования данных в целях улучшения сервиса; реализовать обезличивание до агрегации.
Сценарий 3. Утечка обучающей выборки через публичный репозиторий. Ситуация: датасайентист случайно закоммитил файл с необезличенной выборкой в публичный GitHub-репозиторий. Файл содержал 15 000 строк с email и идентификаторами пользователей. Доказательства: публичный доступ к файлу, индексирование поисковиками. Исход: ч. 13 ст. 13.11 КоАП (5–10 млн ₽) + обязательное уведомление РКН за 24 часа по ч. 3.1 ст. 21 ФЗ-152; просрочка уведомления — дополнительно ч. 11 ст. 13.11 (1–3 млн ₽). Стратегия: pre-commit hook для детектирования ПДн в коммитах (аналог git-secrets с ML-специфичными паттернами); политика запрета сырых данных в репозиториях кода; немедленная процедура реагирования на инцидент.
Как это применяется на практике
Кейс 1. IT-компания (Центральный ФО, начало 2026 года) использовала self-hosted MLflow с S3-совместимым хранилищем на базе MinIO, развёрнутым в иностранном облаке. При внеплановой проверке РКН выявил хранение необезличенных данных регистрации пользователей (около 200 000 субъектов) за пределами РФ. Технический директор не мог предъявить классификацию ИСПДн и документы о поручении обработки облачному провайдеру. Компании выдано предписание и возбуждено дело по ч. 8 ст. 13.11 КоАП. После миграции в российский регион и подготовки ОРД производство было прекращено в части предписания, штраф составил несколько миллионов рублей. Аналитики DATUM сопровождали подготовку документации для РКН.
Кейс 2. SaaS-платформа для HR-аналитики (Северо-Западный ФО, осень 2025 года) агрегировала данные соискателей от корпоративных клиентов для обучения модели оценки резюме. Один из тенантов обнаружил использование данных своих кандидатов в общей модели и подал жалобу в РКН. Проверка выявила отсутствие в договорах с тенантами основания для такой обработки. CTO платформы был вынужден остановить дообучение и обезличить накопленные обучающие выборки. Компания получила предписание и штраф по ч. 1 ст. 13.11. По результатам работы с DATUM были обновлены DPA со всеми тенантами и внедрён pipeline обезличивания перед агрегацией.
Услуги DATUM по теме
- Аудит соответствия 152-ФЗ — классификация ИСПДн, включая ML-инфраструктуру, чек-лист из 38 пунктов
- DPIA (оценка воздействия) — оценка рисков для автоматизированных систем и ML-обработки
- Комплект ОРД под ключ — политика, поручения обработки, регламенты для IT-команды
Частые вопросы
1. Какой УЗ выбрать для SaaS с ML-модулем?
Уровень защищённости определяется по ПП РФ №1119: пересечение категории ПДн, типа актуальных угроз и числа субъектов. Для общих ПДн (email, поведение) при числе субъектов свыше 100 000 и угрозах 3-го типа — минимум УЗ-3. Угрозы 2-го типа — УЗ-2. Спецкатегории (здоровье, биометрия) независимо от объёма — УЗ-1 или УЗ-2. Ключевой шаг — формальная классификация ИСПДн с документальным закреплением, а не оценка «на глаз».
2. Можно ли использовать иностранные облака для ML-экспериментов?
Для хранения необезличенных ПДн граждан РФ — нет, если сервер расположен за пределами России. По ч. 5 ст. 18 ФЗ-152 первичные операции должны выполняться на серверах в РФ. Нарушение с 30.05.2025 влечёт штраф по ч. 8 ст. 13.11 КоАП (1–6 млн ₽). Иностранное облако допустимо только для обезличенных данных, если обезличивание необратимо и осуществлено до передачи за рубеж. Российские регионы международных облаков (при наличии) требуют проверки договорной цепочки на соответствие требованиям локализации.
3. Что такое обезличивание для ML и как оно отличается от псевдонимизации?
Обезличивание по ст. 3 ФЗ-152 — это действия, после которых без дополнительной информации невозможно установить принадлежность данных субъекту. Псевдонимизация (замена идентификатора суррогатным ключом при сохранении связки ключей) не снимает статус ПДн: данные остаются персональными. Для ML с 01.09.2025 применяются 5 методов по Приказу РКН №140; введение идентификаторов без уничтожения связки — лишь псевдонимизация, не обезличивание. Рабочий подход для датасета: обобщение + удаление прямых идентификаторов + отдельное хранение таблицы соответствия с ограниченным доступом.
4. Кто является оператором в мультиарендной SaaS?
Тенант (корпоративный клиент) является оператором в отношении ПДн своих пользователей. SaaS-платформа выступает обработчиком по поручению (п. 3 ст. 6 ФЗ-152) при наличии письменного договора с перечнем операций, целей и мер защиты. Без такого договора платформа де-факто является самостоятельным оператором без правового основания. Если платформа использует данные для своих целей (дообучение общей модели) — это самостоятельная обработка, требующая отдельного основания по ст. 6 ФЗ-152.
5. Какие СЗИ обязательны для ML-инфраструктуры по Приказу ФСТЭК №21?
Обязательный базовый набор зависит от уровня УЗ. Для УЗ-3 ключевые группы: ИАФ (многофакторная аутентификация сервисных аккаунтов), УПД (разграничение доступа к сырым и обезличенным данным), РСБ (журналирование всех операций с ПДн, хранение не менее 3 лет), ЗНИ (шифрование объектных хранилищ). Для УЗ-2 добавляются требования к СОВ (системы обнаружения вторжений) и АВЗ (антивирусная защита). Сертифицированные СЗИ ФСТЭК обязательны при обработке спецкатегорий (ст. 10 ФЗ-152) или при угрозах 1–2-го типа.
Итог
Сохранение результатов ML-экспериментов — полноценный цикл обработки ПДн, если в хранилище попадают необезличенные данные. Три ключевых требования: классификация ИСПДн с присвоением уровня УЗ по ПП РФ №1119, реализация мер по Приказу ФСТЭК №21 и обезличивание выборок до передачи в хранилище экспериментов. Локализация на серверах в РФ и наличие письменного поручения обработки с облачным провайдером — обязательные условия для любой SaaS-архитектуры с российскими ПДн.
DATUM сопровождает IT-компании и SaaS-платформы по техническому периметру 152-ФЗ: классификация ИСПДн, разработка ОРД для ML-инфраструктуры, DPIA для автоматизированных систем, подготовка к проверкам РКН в IT-секторе.