Открытые модели и встроенные ПДн

Открытые ML-модели стали стандартным артефактом разработки: команды публикуют чекпоинты на Hugging Face, передают модели клиентам в рамках SaaS-договоров, дообучают базовые модели на пользовательских данных. До 2025 года правовой риск этой практики оставался теоретическим. После вступления в силу ФЗ-420 от 30.11.2024 он стал измеримым: штрафы по ст. 13.11 КоАП выросли на порядок, а ст. 272.1 УК РФ, действующая с 11.12.2024, распространяется на незаконное хранение компьютерной информации с ПДн — включая веса модели. Этот материал объясняет, как ПДн оказываются в модели, как это проверить и что делать, чтобы не нарушить ФЗ-152.

Как персональные данные оказываются в весах модели?

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

Второй канал встраивания — fine-tuning на клиентских данных. Команда берёт базовую модель, дообучает её на внутренней переписке, CRM-выгрузке или логах сервиса. ПДн из этих данных переходят в дельта-веса адаптера (LoRA, QLoRA). Если адаптер публикуется отдельно, он несёт те же риски, что и полная модель.

Третий канал — embedding-базы и векторные индексы. Семантические эмбеддинги сохраняют смысловые связи исходных текстов. Косинусное расстояние между векторами позволяет восстанавливать исходные фрагменты через инверсию эмбеддингов. Векторная БД, выгруженная в облако, — это тоже база ПДн, если документы содержали персональные сведения.

Что требует ФЗ-152 перед публикацией модели?

Обязанности оператора при обработке ПДн для целей ML регулируются несколькими нормами одновременно. Ст. 5 ФЗ-152 закрепляет принцип соответствия объёма обработки заявленной цели: если цель — построить рекомендательную систему, хранить сырые ПДн в весах после достижения этой цели не правомерно. Ст. 21 ФЗ-152 обязывает оператора уничтожить ПДн при достижении цели обработки.

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

Трансграничная передача модели — отдельный риск. Если модель размещается на зарубежной платформе (Hugging Face расположен в США), это квалифицируется как трансграничная передача ПДн по ст. 12 ФЗ-152. До передачи в страну без адекватной защиты оператор обязан уведомить РКН. Уведомление подаётся через pd.rkn.gov.ru по форме приказа РКН №180.

Какой уровень защищённости выбрать для ML-инфраструктуры?

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

Для типичной ML-платформы, обрабатывающей общие ПДн клиентов (имя, email, поведенческие события), при угрозах 3-го типа (актуальны только НДВ прикладного ПО) — применяется УЗ-3. При угрозах 2-го типа (НДВ системного ПО) тот же состав данных требует УЗ-2. Специальные категории — состояние здоровья, биометрия — автоматически повышают уровень до УЗ-1 или УЗ-2 вне зависимости от числа субъектов.

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

Как мультиарендность SaaS меняет схему ответственности?

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

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

Какова уголовная и административная ответственность за встроенные ПДн?

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

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

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

Как это применяется на практике

Кейс 1. IT-компания Сибирского федерального округа (осень 2025) публично выложила fine-tuned модель на основе корпоративной переписки. Исследователи обнаружили, что через специально сформированные промпты модель воспроизводит имена и должности сотрудников клиентов. РКН инициировал проверку по ч. 12 ст. 13.11 КоАП. Компания доказала применение частичного обезличивания на этапе подготовки данных — суд учёл это как смягчающее обстоятельство при назначении штрафа в нижней части диапазона 3–5 млн ₽. После инцидента компания внедрила процедуру тестирования на меморизацию как обязательный этап перед каждым релизом.

Кейс 2. SaaS-платформа Центрального федерального округа (начало 2026) использовала агрегированные данные клиентов для дообучения сквозного рекомендательного движка. При плановой проверке РКН установил отсутствие договоров поручения с 14 клиентами-операторами и факт объединения баз с несовместимыми целями (ст. 5 ФЗ-152). Штраф назначен по ч. 1 ст. 13.11 (150–300 тыс. ₽). Параллельно клиенты предъявили претензии по условиям SaaS-договора. Совокупные затраты на урегулирование превысили стоимость годового DPO-аутсорсинга.

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

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

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

1. Какой УЗ выбрать для SaaS-платформы с ML?

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

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

Хранение весов, содержащих ПДн граждан РФ, на зарубежных серверах нарушает ч. 5 ст. 18 ФЗ-152 (локализация). Первичные операции — запись, систематизация, накопление, хранение, уточнение и извлечение — должны выполняться в базах данных на территории РФ. Если модель не содержит извлекаемых ПДн (обезличена должным образом), ограничение локализации формально не применяется к самим весам. Тем не менее инфраструктура обучения и хранения чекпоинтов с необезличенными данными обязана быть в российском облаке или собственном дата-центре.

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

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

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

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

5. Какие СЗИ обязательны для ML-систем по Приказу ФСТЭК №21?

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

Итог

Открытые модели и встроенные ПДн — это не гипотетический риск, а измеримая правовая экспозиция. Меморизация в LLM, fine-tuning на необезличенных данных и агрегация клиентских датасетов в мультиарендной SaaS создают составы по ст. 13.11 КоАП (от 3 до 500 млн ₽) и ст. 272.1 УК (до 10 лет). Устранение риска требует трёх шагов: обезличивание до обучения по методам приказа РКН, DPIA перед публикацией, договоры поручения с каждым клиентом-оператором.

DATUM сопровождает IT-команды и SaaS-провайдеров в построении архитектуры данных, соответствующей ФЗ-152: от аудита обучающих корпусов до оформления ОРД и прохождения проверок РКН по технической части.