Дообучение LLM на корпоративных данных

Корпоративный fine-tuning вошёл в стандартную практику IT-команд: модель адаптируется под внутренние регламенты, тикеты, переписку, клиентские обращения. Ни один из этих источников не является технически «анонимным» по умолчанию. Роскомнадзор квалифицирует систематизацию и извлечение сведений о физических лицах как обработку ПДн вне зависимости от того, является ли конечным продуктом текстовый вывод или веса модели. В этой статье — разбор правового режима дообучения, требований ФСТЭК, порядка обезличивания для ML и типовых рисков мультиарендной SaaS-архитектуры.

Почему дообучение LLM попадает под 152-ФЗ?

Формальный порог прост: если в датасете есть строка вида «Иван Петров, телефон 912-…, жалоба на задержку доставки» — это персональные данные, и их систематизация (создание векторной базы, токенизация, формирование батчей) подпадает под понятие «обработка» из ст. 3 ФЗ-152. Вопрос не в том, хранит ли готовая модель эти строки в явном виде, а в том, что они присутствовали в процессе обработки.

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

Наиболее распространённая ошибка CTO: использование производственной базы данных (БД клиентов, БД сотрудников) как источника для формирования обучающей выборки без отдельного правового основания. Существующее согласие на «обработку в целях исполнения договора» не покрывает машинное обучение — это иная цель по ст. 5 ФЗ-152. Изменение цели без переоформления согласия или смены правового основания образует состав ч. 1 ст. 13.11 КоАП (штраф для юрлица 150–300 тыс. ₽ при первичном нарушении, 300–500 тыс. ₽ при повторном по ч. 1.1).

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

Уровень защищённости информационной системы персональных данных (ИСПДн) определяется по матрице ПП РФ №1119 от 01.11.2012: категория ПДн × тип актуальных угроз × численность субъектов. Для ML-системы, которая обрабатывает данные сотрудников и клиентов, характерны следующие варианты.

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

Для ML-пайплайна критичны три группы мер из Приказа №21. Первая — РСБ (регистрация событий безопасности): логи обращений к датасету, к весам модели, к API инференса. Вторая — ЗНИ (защита носителей информации): шифрование дисков и резервных копий, содержащих обучающую выборку. Третья — УПД (управление правами доступа): ролевая модель, разграничение между командой MLOps, DevOps и бизнес-аналитиками. Логирование обращений к ПДн в контексте ML имеет самостоятельное правовое значение: журнал событий может быть запрошен РКН в ходе проверки как доказательство выполнения требований ст. 19 ФЗ-152.

Как обезличить данные для ML так, чтобы это было признано законным?

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

Псевдонимизация — замена ФИО и телефонов на суррогатные ключи — сама по себе не является обезличиванием по смыслу ФЗ-152, если обратное сопоставление технически возможно хотя бы для оператора. Это распространённое заблуждение в MLOps-командах. Данные считаются обезличенными только тогда, когда идентификация субъекта невозможна без привлечения дополнительной информации, которая хранится отдельно и не передаётся вместе с датасетом.

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

Поручение обработки: кто несёт ответственность при работе с облачным вендором?

В типовой ML-архитектуре задействованы три стороны: компания-оператор, облачный GPU-провайдер (хранит и обрабатывает датасет) и вендор базовой модели (принимает датасет для fine-tuning). По ст. 6 ФЗ-152, оператор вправе поручить обработку третьему лицу, но ответственность перед субъектами остаётся за оператором. Это означает: если облачный провайдер допустит утечку датасета — штраф по ч. 12–14 ст. 13.11 КоАП получит ваша компания, а не провайдер.

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

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

Как это работает на практике: типовые сценарии для CTO

Сценарий 1. Датасет из производственной БД, GPU-кластер в иностранном облаке. Компания выгружает историю клиентских обращений в AWS или Azure для дообучения внутренней модели. Ситуация: данные содержат ФИО, email, историю покупок — иные категории ПДн, более 100 000 субъектов. Передача за рубеж без уведомления РКН и оценки адекватности страны — нарушение ст. 12 ФЗ-152. Нарушение локализации (ч. 5 ст. 18 ФЗ-152, запись и хранение в РФ) — состав ч. 8 ст. 13.11 КоАП (1–6 млн ₽). Стратегия: перейти на российский облачный провайдер или выстроить гибридную схему с локальным хранением датасета и передачей только обезличенных векторов.

Сценарий 2. Fine-tuning через API вендора без договора поручения. Команда MLOps передаёт батчи обучающих данных через API OpenAI-совместимого сервиса. Договора поручения нет, цель «машинное обучение» не указана в уведомлении РКН. Доказательства: технические логи передачи данных фиксируют факт. Вероятный исход при проверке — протокол по ч. 1 ст. 13.11 (до 300 тыс. ₽) и предписание уведомить РКН об изменении цели в течение 30 дней. Стратегия: заключить договор поручения с вендором API, обновить уведомление в РКН, проверить, не является ли вендор иностранным лицом.

Сценарий 3. Утечка весов модели через уязвимость в ML-платформе. В веса дообученной модели методами инверсии (model inversion attack) может быть частично восстановлена обучающая выборка — это признаётся утечкой ПДн. Ситуация: модель развёрнута на общедоступном инференс-эндпоинте без ограничения запросов. Вероятный исход: если в датасете было 10 000–100 000 субъектов — штраф по ч. 13 ст. 13.11 (5–10 млн ₽) и обязанность уведомить РКН в течение 24 часов с момента обнаружения (ч. 3.1 ст. 21 ФЗ-152). Стратегия: ограничить rate-limiting на инференс-API, внедрить дифференциальную приватность при обучении, провести DPIA до деплоя модели.

Как влияет 187-ФЗ о КИИ на ML-инфраструктуру?

Если компания является субъектом критической информационной инфраструктуры (КИИ) по ФЗ-187, ML-система, обрабатывающая ПДн на объекте КИИ, подпадает под требования безопасности КИИ дополнительно к требованиям ФЗ-152. Это означает обязательное использование средств защиты информации (СЗИ), сертифицированных ФСБ и ФСТЭК, независимо от того, применяется ли облачная инфраструктура или on-premise. Для значимых объектов КИИ 1-й категории требования безопасности по своему уровню перекрывают УЗ-1 ФЗ-152 — то есть устанавливают более высокую планку.

На практике большинство финтех-компаний, телеком-операторов и медицинских организаций, внедряющих ML, обязаны пройти категорирование объектов КИИ до запуска новой системы обработки данных. Отсутствие категорирования — отдельный состав административного правонарушения, не связанный с ФЗ-152 напрямую, но регулярно фиксируемый в ходе комплексных проверок.

Практика: что происходит с компаниями, нарушившими 152-ФЗ в ML-контексте

Кейс 1. IT-компания (Северо-Западный ФО, осень 2025) запустила fine-tuning модели для внутреннего чат-бота службы поддержки. Датасет содержал переписку с клиентами, включая телефоны и email. Договор поручения с облачным GPU-провайдером отсутствовал. В ходе планового аудита безопасности выяснилось, что данные хранились в иностранном облаке без уведомления РКН. После самостоятельного обращения в РКН компания получила предписание: устранить нарушение локализации (ч. 8 ст. 13.11 КоАП), переоформить уведомление и заключить договоры поручения. Штраф не был назначен — компания устранила нарушения до возбуждения дела об административном правонарушении. Стоимость приведения в соответствие составила порядка 200 тыс. ₽ (аудит + ОРД + миграция данных на российский провайдер).

Кейс 2 (из реестра — case_S2_pkr_analitika). В деле АС Санкт-Петербурга и Ленинградской области (дело № А56-4733/2026) оператор — цифровая платформа — допустил утечку около 70 000 субъектов в результате хакерской атаки. Данные включали ФИО, должности, служебные email и телефоны. Квалификация — ч. 14 ст. 13.11 КоАП (утечка более 100 000 — порог не достигнут, применена ч. 13). Суд применил смягчающие обстоятельства. Кейс демонстрирует: даже «нечувствительные» данные (должность, рабочий телефон) при масштабе утечки дают основание для многомиллионного штрафа — в ML-контексте это означает, что датасет из корпоративной адресной книги или LDAP формирует тот же риск.

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

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

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

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

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

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

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

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

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

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

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

5. Какие СЗИ обязательны для ML-инфраструктуры под обработку ПДн?

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

Итог

Дообучение LLM на корпоративных данных — полноценная обработка ПДн, требующая отдельного правового основания, уведомления РКН, договоров поручения с каждым вендором инфраструктуры и документально подтверждённого обезличивания датасета. Уровень защищённости ИСПДн для ML-инфраструктуры в большинстве корпоративных сценариев — УЗ-3, а при специальных категориях или угрозах 2-го типа — УЗ-2. Логирование событий и ролевая модель доступа по Приказу ФСТЭК №21 — обязательны, а не опциональны.

Практика DATUM включает сопровождение CTO и CISO при запуске ML-пайплайнов: аудит датасетов на предмет ПДн, разработку актов обезличивания, DPIA до деплоя моделей и договоры поручения с облачными провайдерами. Взаимодействие с РКН при изменении уведомления — в рамках того же проекта.