Generative AI и согласие пользователей

С 2024 года Роскомнадзор включил AI-продукты в периметр надзора по 152-ФЗ: инспекторы проверяют, на каком основании LLM-сервисы обрабатывают вводимые пользователями данные, где хранятся векторные представления и кто несёт ответственность в мультиарендной SaaS-архитектуре. Для технического директора это означает три пересекающихся задачи: выбрать уровень защищённости (УЗ-1..УЗ-4 по ПП РФ №1119), определить правовое основание обработки и выстроить процесс получения согласий в соответствии с ФЗ-156 от 24.06.2025. В этой статье — анализ каждой из них с опорой на действующие нормы.

Почему generative AI создаёт новые риски по 152-ФЗ?

Генеративные модели отличаются от классических систем обработки данных одним принципиальным свойством: они могут запоминать фрагменты обучающих данных и воспроизводить их в ответах. Исследования показывают, что достаточно большая модель способна дословно воспроизвести участки текста, на котором обучалась. Если в этих данных были персональные данные пользователей — ФИО, адреса, фрагменты переписки — оператор обязан обеспечить их защиту по ст. 19 ФЗ-152.

Второй фактор риска — размытая граница между сервисом и обучением. Пользователь вводит промпт с персональными данными третьего лица («напиши письмо Ивану Петрову, моему клиенту из Москвы»). Эти данные попадают в контекстное окно, затем в логи, затем — при активации опции дообучения — в датасет. На каждом из этих этапов происходит самостоятельное действие по обработке ПДн, каждое требует собственного правового основания по ст. 6 ФЗ-152.

Третий фактор — трансграничная передача данных при инференсе через зарубежные модели. Если SaaS-продукт отправляет пользовательские запросы во внешний API (OpenAI, Anthropic, Google) — каждый запрос, содержащий персональные данные, является трансграничной передачей по ст. 12 ФЗ-152. Уведомление РКН о трансграничной передаче обязательно до начала обработки.

Как правильно получить согласие пользователя на обработку данных в AI-продукте?

С 01.09.2025 согласие на обработку персональных данных существует как самостоятельный документ — его нельзя встроить в пользовательское соглашение, политику конфиденциальности или оферту (ФЗ-156 от 24.06.2025, изменения в ч. 1 ст. 9 ФЗ-152). Для AI-продуктов это означает как минимум два отдельных согласия: на обработку в рамках сервиса и — отдельно — на использование данных для обучения модели.

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

Для продуктов с дообучением на пользовательских данных рекомендуется реализовать гранулярное согласие: отдельный чекбокс или экран для каждой из целей. При этом отказ от согласия на обучение не должен ограничивать доступ к основному функционалу — иначе возникает вопрос о добровольности согласия по ст. 9 ч. 1 ФЗ-152.

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

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

Если пользователи вводят медицинские данные (симптомы, диагнозы, назначения) — они относятся к специальным категориям по ст. 10 ФЗ-152. Это автоматически создаёт основания для УЗ-2 или УЗ-1 в зависимости от типа угрозы. Общедоступные данные (имена, должности, рабочие email) при числе субъектов свыше 100 000 дают УЗ-3.

Для SaaS-архитектуры с мультиарендностью важно разграничить ИСПДн по арендаторам. Если данные клиентов одного тенанта технически изолированы от других — каждая изолированная среда может квалифицироваться как отдельная ИСПДн со своим УЗ. При общем хранилище (shared database) UZ всей системы определяется по наиболее высокому уровню среди всех тенантов.

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

Обезличивание данных для ML: когда оно снимает требования 152-ФЗ?

Обезличенные данные не являются персональными по определению ст. 3 ФЗ-152 — при условии, что идентификация субъекта по ним невозможна. ФЗ-233 от 28.06.2025 ввёл ст. 13.1 ФЗ-152, установившую регулирование обезличенных ПДн: передача обезличенных данных в Единую информационную платформу национальной системы управления данными допустима по требованию Минцифры.

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

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

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

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

Ключевой критерий разграничения — кто определяет цель и состав обработки. Если вендор обрабатывает данные исключительно по инструкциям тенанта — он обработчик. Если вендор использует данные для своих целей (обучение, бенчмаркинг, аналитика) — он становится оператором с полным объёмом обязанностей по ФЗ-152, включая уведомление РКН по ст. 22 и назначение ответственного по ст. 22.1.

Договор поручения обработки по п. 3 ст. 6 ФЗ-152 обязателен в любом случае. В нём фиксируются: конкретный перечень действий с данными, которые вправе выполнять вендор, запрет на использование в собственных целях, обязанность уведомить оператора-тенанта об инциденте, порядок уничтожения данных при расторжении договора. Отсутствие договора поручения — самостоятельное основание для протокола по ч. 1 ст. 13.11 КоАП (150–300 тыс. ₽).

Практика: типовые сценарии для AI-продуктов

Сценарий 1. LLM-ассистент с дообучением на переписке пользователей. Ситуация: продукт предлагает персонализацию за счёт анализа истории чатов. Пользователь принял оферту с формулировкой «данные используются для улучшения сервиса». Доказательства проблемы: история чатов содержит ПДн третьих лиц, цель «обучение модели» не указана в согласии явно, согласие не является отдельным документом (нарушение ФЗ-156). Вероятный исход: при проверке РКН — протокол по ч. 2 ст. 13.11 (300–700 тыс. ₽), при утечке обучающего датасета — ч. 12–14 ст. 13.11 в зависимости от числа субъектов. Стратегия: ввести отдельное согласие на обучение с отказом по умолчанию, реализовать pipeline без сохранения ПДн или с обезличиванием одним из пяти утверждённых методов.

Сценарий 2. SaaS с инференсом через внешний API. Ситуация: CTO подключил OpenAI API для генерации ответов; пользовательские запросы передаются напрямую без предобработки. Доказательства проблемы: каждый запрос с ПДн — трансграничная передача по ст. 12 ФЗ-152; США не входят в перечень стран с адекватной защитой; уведомление в РКН не подавалось. Вероятный исход: штраф по ч. 8 ст. 13.11 КоАП за нарушение требований локализации (1–6 млн ₽) или отдельный штраф за трансграничную передачу без уведомления. Стратегия: либо перейти на российский LLM-провайдер с инфраструктурой в РФ, либо подать уведомление в РКН по ст. 12 ФЗ-152 и обеспечить договорные гарантии защиты данных с зарубежным провайдером.

Сценарий 3. Облачная ML-платформа с несколькими арендаторами. Ситуация: платформа позволяет тенантам загружать датасеты и дообучать модели. Общий GPU-кластер, изолированные хранилища. Проблема: вендор имеет технический доступ к данным тенантов; договоры поручения с частью тенантов отсутствуют. Вероятный исход: в части тенантов без договора поручения вендор квалифицируется как самостоятельный оператор; при проверке — требование уведомить РКН и предоставить пакет ОРД по каждой ИСПДн тенанта, где вендор является оператором. Стратегия: заключить договоры поручения со всеми тенантами, описав в них запрет на использование данных в целях вендора; при необходимости — разграничить роли через архитектурные решения (zero-knowledge доступ).

Кейс 1. IT-компания (Центральный ФО, осень 2025) разрабатывала корпоративный AI-ассистент. При аудите выявлено: промпты пользователей сохранялись в облаке AWS Frankfurt, договор поручения с AWS отсутствовал, уведомление о трансграничной передаче в РКН не подавалось. После досудебного урегулирования с участием юристов компания перенесла хранилище промптов на российский облачный провайдер, подала уведомление, заключила договоры поручения с тремя подрядчиками. Штраф по ч. 1 ст. 13.11 КоАП составил сотни тысяч рублей; повторный протокол не выдвигался.

Кейс 2. SaaS-вендор (Северо-Западный ФО, начало 2026) использовал агрегированные данные тенантов для дообучения собственной LLM. Договоры поручения с тенантами не содержали разрешения на обучение в целях вендора. При внеплановой проверке РКН установил, что вендор является самостоятельным оператором без уведомления в реестре. Составлен протокол по ч. 1 ст. 13.11 и по ч. 10 (неуведомление о намерении обрабатывать, 100–300 тыс. ₽). Вендор прошёл аудит, переработал архитектуру дообучения и зарегистрировался в реестре операторов ПДн.

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

• DPIA (оценка воздействия) — оценка рисков AI-обработки, выбор УЗ, меры по Приказу ФСТЭК №21
• Аудит соответствия 152-ФЗ — полный чек-лист из 38 пунктов для IT-продуктов с ML-компонентом
• Комплект ОРД под ключ — договоры поручения, согласия на обучение, регламент реагирования на утечки

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

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

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

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

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

3. Что такое обезличивание для ML и когда оно снимает требования 152-ФЗ?

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

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

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

5. Какие средства защиты информации (СЗИ) обязательны для AI-инфраструктуры?

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

Итог

Generative AI в B2B SaaS создаёт как минимум три самостоятельных направления риска по 152-ФЗ: правовое основание для обучения на пользовательских данных, определение УЗ для AI-инфраструктуры и разграничение ролей оператора и обработчика в мультиарендной архитектуре. После ФЗ-156 и ФЗ-233 каждый из этих рисков стал более конкретным и более дорогостоящим при нарушении.

Юристы DATUM специализируются на технической стороне 152-ФЗ для IT-продуктов: DPIA для AI-систем, выбор УЗ по ПП РФ №1119, договоры поручения для облачных стеков, согласия на обучение по ФЗ-156. Более 300 операторов сопровождено с 2014 года.