Обучение моделей на отзывах клиентов

Отзывы клиентов содержат имена, контакты, мнения о здоровье, финансовом положении и поведении — всё это персональные данные по ст. 3 ФЗ-152. Когда IT-команда передаёт такой датасет в обучающий пайплайн, компания выступает оператором ПДн и принимает на себя весь объём требований закона. С 30.05.2025 требования существенно ужесточились: ст. 13.11 КоАП теперь насчитывает 18 частей, а оборотный штраф за повторную утечку достигает 500 млн ₽. В этой статье — последовательность шагов, которую CTO должен пройти до запуска обучения на клиентских данных.

Почему отзывы клиентов — это персональные данные?

Персональные данные по ст. 3 ФЗ-152 — любая информация, которая прямо или косвенно идентифицирует физическое лицо. Отзыв, привязанный к аккаунту, email-адресу, номеру заказа или IP-адресу, однозначно попадает под это определение. Обезличенный отзыв без идентификаторов — не ПДн, но только при условии, что повторная идентификация технически невозможна.

Проблема большинства ML-пайплайнов в том, что датасет формируется из операционной базы данных, где каждая строка привязана к user_id или order_id. Даже если в обучающую выборку передаётся только текст отзыва, модель может запомнить уникальные паттерны и стать источником утечки через adversarial-атаки или prompt injection. Регулятор квалифицирует такую ситуацию как хранение ПДн в ИСПДн.

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

Как определить уровень защищённости ИСПДн для ML-пайплайна?

Уровень защищённости (УЗ) определяется по ПП РФ №1119 от 01.11.2012 на пересечении трёх параметров: категория ПДн, тип актуальных угроз и число субъектов в системе. Для обучающего пайплайна важно учитывать не только production-базу, но и все промежуточные хранилища: S3-бакеты с датасетами, MLflow с логами экспериментов, векторные базы с эмбеддингами.

• УЗ-4 — общедоступные ПДн или менее 100 000 субъектов без спецкатегорий, угрозы 3-го типа. Минимальный набор мер ФСТЭК.
• УЗ-3 — общие ПДн более 100 000 субъектов или любые ПДн с угрозами 2-го типа. Большинство SaaS-платформ с клиентскими отзывами попадают именно сюда.
• УЗ-2 — специальные или биометрические ПДн при угрозах 2-го типа или общие ПДн при угрозах 1-го типа.
• УЗ-1 — специальные/биометрические ПДн с угрозами 1-го типа. Встречается редко, требует максимального набора СЗИ.

Порог в 100 000 субъектов критичен для ML-команд: датасет из отзывов интернет-магазина или мобильного приложения практически всегда его превышает. Это автоматически поднимает минимальный уровень с УЗ-4 до УЗ-3 при отсутствии спецкатегорий. Угрозы 2-го типа (связанные с недокументированными возможностями системного ПО) при использовании open-source фреймворков — PyTorch, TensorFlow, Hugging Face — регулятор нередко квалифицирует как актуальные.

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

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

С 2025 года методы обезличивания регламентированы подзаконным актом РКН. Применяются пять методов: введение идентификаторов (замена прямых ключей на псевдонимы), изменение состава или семантики (удаление или обобщение атрибутов), декомпозиция (разделение данных между несвязанными хранилищами), перемешивание (нарушение связности записей) и обобщение или агрегация (замена точных значений диапазонами). Для обучающих выборок из отзывов наиболее применимы первые два метода.

Важный нюанс: обезличивание необходимо верифицировать. Модель, обученная на тексте без прямых идентификаторов, может воспроизводить уникальные фрагменты из обучающих данных — это называется memorization. Технической проверкой на memorization (membership inference attack) следует закрывать цикл обезличивания до деплоя модели в production.

Как правильно оформить поручение обработки для ML-инфраструктуры?

Если обучение происходит в облаке (Yandex Cloud, SberCloud, VK Cloud) или на стороннем GPU-кластере, то провайдер является лицом, осуществляющим обработку ПДн по поручению оператора, в терминологии ст. 3 и ч. 3 ст. 6 ФЗ-152. Это не снимает ответственность с оператора: за действия подрядчика отвечает сам оператор.

Договор поручения должен содержать перечень допустимых действий с ПДн, цель обработки, обязанность обеспечить конфиденциальность и соответствующий УЗ, запрет передачи данных третьим лицам и порядок уничтожения после завершения задачи. При использовании иностранных облачных сервисов (AWS, GCP, Azure) возникает вопрос трансграничной передачи и локализации.

Требование локализации означает, что первичный сбор и хранение данных для обучающего датасета должны происходить в российском контуре. Передача обезличенного датасета в иностранное облако формально допустима — при условии, что обезличивание было проведено корректно и повторная идентификация исключена. Необезличенные данные в AWS S3 или Google Cloud Storage — прямое нарушение ч. 5 ст. 18 и штраф по ч. 8 ст. 13.11 КоАП от 1 до 6 млн ₽.

Кто оператор в мультиарендной SaaS и кто несёт ответственность за ML?

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

Смешение данных разных арендаторов в одной обучающей выборке без согласования с каждым из них нарушает принцип совместимости целей обработки по ст. 5 ФЗ-152. Данные, собранные для предоставления сервиса клиенту А, не могут быть использованы для обучения модели, которая будет обслуживать клиента Б, без отдельного правового основания.

Практика: как это выглядит при проверке и в суде

Кейс 1. IT-компания (Центральный ФО, осень 2025): обучала модель классификации тональности на массиве из 850 000 отзывов пользователей без обезличивания. При плановой проверке РКН инспектор запросил документацию по ИСПДн обучающего кластера. Компания не смогла предоставить модель угроз и определение УЗ. Протокол по ч. 1 ст. 13.11 КоАП. Параллельно зафиксировано отсутствие договора поручения с облачным провайдером. Суд назначил штраф в диапазоне низкой части санкции с учётом первичности нарушения и устранения до вынесения постановления.

Кейс 2. SaaS-платформа для ритейла (Северо-Западный ФО, начало 2026): данные отзывов клиентов нескольких арендаторов объединены в общий датасет для обучения рекомендательной системы. После жалобы одного из арендаторов РКН провёл внеплановую проверку. Нарушение — совмещение баз с несовместимыми целями (ст. 5 ФЗ-152) и отсутствие правового основания для обработки данных субъектов арендатора в интересах платформы. Дело рассматривалось по ч. 1 ст. 13.11 КоАП. Применение ст. 4.1.1 КоАП (замена штрафа на предупреждение) не удалось — компания не являлась микропредприятием. Штраф в сотни тысяч рублей, предписание об устранении в 30-дневный срок.

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

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

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

1. Какой УЗ выбрать для SaaS с клиентскими отзывами?

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

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

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

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

Обезличивание для ML — это преобразование датасета по методам, регламентированным подзаконным актом РКН: введение идентификаторов (замена user_id на случайный хэш без возможности обратного преобразования), изменение состава или семантики (удаление email, телефона, имени из текста отзыва), декомпозиция или перемешивание. После обезличивания необходимо провести membership inference test, чтобы убедиться, что модель не воспроизводит исходные записи. Результат обезличивания фиксируется протоколом с хэшами файлов до и после.

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

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

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

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

Итог

Обучение моделей на отзывах клиентов — законная практика при соблюдении трёх условий: правовое основание по ст. 6 ФЗ-152, корректное обезличивание датасета до передачи в пайплайн и соответствие ИСПДн определённому УЗ с набором мер ФСТЭК. Нарушение любого из них создаёт риск штрафа от 150 000 до 6 000 000 ₽ и более — в зависимости от числа субъектов и повторности.

DATUM сопровождает IT-компании и SaaS-платформы в оценке воздействия (DPIA), определении УЗ, формировании ОРД для ML-инфраструктуры и подготовке договоров поручения с облачными провайдерами. Практика по 152-ФЗ ведётся с 2014 года.