Обучение ИИ-моделей на ПДн: правовая основа

Компании, строящие рекомендательные системы, NLP-модели и скоринговые алгоритмы, используют в обучающих выборках реальные транзакции, переписку, медицинские карты и профили пользователей. По данным РКН за 2024 год, более 710 млн записей оказались скомпрометированы — значительная часть через системы, где ML-компонент получал доступ к «сырым» ПДн. Эта статья разбирает, какой правовой режим регулирует обучение ИИ-моделей на ПДн, какой уровень защищённости требуется по ПП РФ №1119, что даёт обезличивание для ML и как правильно выстроить поручение обработки при облачном обучении в России или за рубежом.

Почему обучение ИИ-модели — это обработка ПДн и что из этого следует?

Технический директор нередко считает, что ML-пайплайн работает «внутри» и закон не применяется. Это ошибка. Статья 3 ФЗ-152 определяет обработку как любое действие с персональными данными — в том числе использование, систематизацию и извлечение. Загрузка датасета в фреймворк обучения, передача батчей на GPU-кластер, логирование лосс-функции по записям — всё это обработка. Более того, если модель способна воспроизвести или реконструировать конкретную запись субъекта (memorization), данные так и не стали обезличенными.

Правовое основание выбирается под конкретную цель обучения. Согласие субъекта по ст. 9 ФЗ-152 (с 01.09.2025 — отдельный документ по ФЗ-156) подходит, если обучение прямо указано в согласии как цель. Исполнение договора по п. 5 ч. 1 ст. 6 ФЗ-152 применимо только если ML-компонент — часть обязательства перед пользователем. Законный интерес, который практикуют европейские компании, российским законом не предусмотрен — ни в каком виде. При отсутствии надлежащего основания штраф по ч. 1 ст. 13.11 КоАП составляет 150 000–300 000 ₽, при повторности — до 500 000 ₽.

Отдельный вопрос — специальные категории ПДн по ст. 10 ФЗ-152: состояние здоровья, политические взгляды, биометрия. Если обучающая выборка содержит медицинские записи или аудиозаписи для распознавания голоса, требуется явное письменное согласие по специальному основанию. Нарушение режима специальных категорий квалифицируется по ч. 1 ст. 13.11 как «обработка в случаях, не предусмотренных законом».

Какой уровень защищённости УЗ-1...УЗ-4 нужен для ML-инфраструктуры?

Постановление Правительства №1119 от 01.11.2012 привязывает уровень защищённости к трём параметрам: категория ПДн, тип актуальных угроз и количество субъектов. Для ML-продуктов пороговое значение — 100 000 субъектов: пересечение этой границы автоматически поднимает требования на ступень вверх. Большинство промышленных обучающих датасетов давно превышают этот порог.

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

Ключевая ошибка CTO — определять УЗ «на глаз» или брать минимальный по умолчанию. РКН при проверке запрашивает модель угроз и акт классификации ИСПДн. Если фактический обработчик — GPU-кластер в облаке, модель угроз должна включать его как элемент инфраструктуры.

Что даёт обезличивание для ML и как его применять по требованиям РКН?

Обезличивание — единственный легальный способ исключить обучающий датасет из-под регулирования ФЗ-152. Статья 3 ФЗ-152 определяет обезличенные данные как сведения, по которым невозможно без дополнительной информации определить конкретного субъекта. Если это достигнуто — данные перестают быть персональными, и требования к правовому основанию, уровню защищённости и уведомлению РКН снимаются.

Для ML-задач наиболее релевантны три метода. Введение идентификаторов — замена имён и контактных данных суррогатными ключами — даёт псевдонимизацию, но не полное обезличивание: если ключи хранятся рядом с моделью или в том же облаке, данные реидентифицируемы. Обобщение и агрегация — замена точных значений диапазонами (возраст «28 лет» → «25–30») — хорошо работает для табличных данных и снижает риск реидентификации при достаточной granularity. Перемешивание — разрыв связи между полями одной записи — применяется для аналитики поведения, но разрушает зависимости, нужные модели.

Критически важно: псевдонимизированные данные не считаются обезличенными по российскому праву, если оператор сохраняет ключ соответствия. Использование таких данных в обучении при хранении ключа в той же ИСПДн — обработка в полном объёме ФЗ-152. Исследования memorization в LLM (включая публикации Google DeepMind) показывают: модель способна «запомнить» и воспроизвести записи из обучающей выборки. Это означает, что даже корректно обезличенный на входе датасет может стать источником утечки ПДн через инференс-API.

Как правильно оформить поручение обработки при облачном обучении?

Если GPU-кластер, озеро данных или MLOps-платформа — это сторонний провайдер, оператор обязан оформить поручение обработки по п. 3 ст. 6 ФЗ-152. Поручение — это письменный договор, в котором оператор определяет цели, перечень действий, требования к защите и право проверки. Обработчик не вправе использовать данные для собственных целей и не несёт ответственности перед субъектами напрямую — ответственность остаётся у оператора.

Мультиарендная SaaS-архитектура создаёт правовую неопределённость: кто оператор, если несколько арендаторов загружают данные своих пользователей в одну платформу для обучения совместной или отдельных моделей? По позиции РКН каждый арендатор остаётся самостоятельным оператором своих данных, а SaaS-провайдер — обработчиком на основании поручения. Смешивать датасеты разных арендаторов без их явного согласия нельзя — это нарушение ст. 5 ФЗ-152 (принцип несовместимых целей при объединении баз).

Облачное обучение за рубежом — это трансграничная передача по ст. 12 ФЗ-152. До передачи в страну без адекватной защиты ПДн оператор обязан уведомить РКН. Список стран с адекватной защитой утверждён приказом РКН; США в него не входят. Использование AWS us-east-1 или Google Cloud us-central1 для хранения датасета с ПДн граждан РФ без уведомления РКН — нарушение, квалифицируемое в связке с нарушением локализации. Облако в РФ (Yandex Cloud, VK Cloud, SberCloud, любой аккредитованный провайдер) снимает вопрос о трансграничной передаче, но не снимает вопрос о поручении и составе мер защиты.

Какие сценарии нарушений встречаются чаще всего и чем они заканчиваются?

Сценарий 1. Датасет без правового основания. Компания обучает NLP-модель на архиве переписки пользователей мессенджера (более 500 000 субъектов). Согласие на обработку в рамках приложения не включало цель «обучение алгоритмов». Проверка РКН инициирована после жалобы пользователя. Итог: протокол по ч. 1 ст. 13.11 КоАП, штраф 150 000–300 000 ₽, плюс предписание уничтожить или обезличить датасет в течение 30 дней. При повторном нарушении — ч. 1.1, штраф до 500 000 ₽. Стратегия: до обучения — внести цель ML-обучения в согласие пользователя как отдельный пункт или использовать только обезличенные данные.

Сценарий 2. Утечка обучающего датасета через открытый S3-бакет. CTO стартапа (Центральный ФО, лето 2025) не ограничил доступ к хранилищу датасетов в облаке. В открытом доступе оказалось 15 000 записей с именами, email-адресами и историей действий. Факт утечки зафиксирован сканером утечек. РКН возбудил дело по ч. 13 ст. 13.11 КоАП. Уведомление в 24 часа не было подано — дополнительный протокол по ч. 11 (штраф 1–3 млн ₽). Итоговый диапазон санкций: 6–13 млн ₽. Стратегия: автоматический аудит конфигурации облачного хранилища, регламент уведомления с назначенным ответственным и тестовым сценарием.

Сценарий 3. Иностранное облако без уведомления РКН. Технический директор платформы e-learning (Северо-Западный ФО, начало 2026) использовал AWS eu-west-1 для обучения модели персонализации. Данные российских пользователей хранились и обрабатывались за рубежом без уведомления о трансграничной передаче. Проверка выявила нарушение локализации по ч. 5 ст. 18 ФЗ-152. Протокол по ч. 8 ст. 13.11: штраф 1–6 млн ₽. Параллельно — нарушение режима поручения, так как договор с AWS не содержал обязательных условий по п. 3 ст. 6. Стратегия: мигрировать датасет в российское облако или уведомить РКН о трансграничной передаче до начала обработки.

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

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

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

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

Можно при соблюдении двух условий. Первое: данные граждан РФ должны первично записываться, систематизироваться и храниться в базах на территории РФ (ч. 5 ст. 18 ФЗ-152, ужесточение с 01.07.2025 по ФЗ-233). Второе: передача в страну без адекватной защиты требует предварительного уведомления РКН по ст. 12 ФЗ-152. США, большинство стран ЕС, не присоединившихся к отдельному соглашению с РФ — вне списка адекватных. Нарушение локализации — ч. 8 ст. 13.11, штраф от 1 до 6 млн ₽; при повторности — ч. 9, от 6 до 18 млн ₽.

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

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

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

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

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

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

Итог

Обучение ML-моделей на персональных данных — это полноценная обработка ПДн, требующая правового основания по ст. 6 ФЗ-152, корректного уровня защищённости по ПП РФ №1119, договора поручения с каждым облачным провайдером и локализации датасета в РФ. Обезличивание — единственный способ вывести данные из-под этого режима, но только при строгом применении методов РКН и уничтожении ключей реидентификации. С 30.05.2025 цена ошибки — от 3 до 500 млн ₽ в зависимости от масштаба утечки и повторности.

DATUM сопровождает IT-компании и SaaS-платформы в построении правомерных ML-пайплайнов: классификация ИСПДн, модель угроз, договоры поручения с облачными провайдерами, оценка методов обезличивания и DPIA для высокорисковой обработки.

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

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