GigaChat и YandexGPT: 152-ФЗ-friendly

К середине 2026 года российские LLM прочно вошли в продуктовый стек IT-команд: чат-боты, суммаризация обращений, классификация контента, генерация ответов в CRM. Вопрос «можно ли это делать с персональными данными» часто остаётся без ответа до первой проверки. Статья разбирает, что именно требует 152-ФЗ при интеграции GigaChat и YandexGPT, как определить уровень защищённости по ПП РФ №1119 и когда обезличивание для ML становится обязательным условием, а не опцией.

Почему GigaChat и YandexGPT не «автоматически» соответствуют 152-ФЗ?

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

Вторая проблема — цели. По ст. 5 ФЗ-152 нельзя объединять базы с несовместимыми целями. Если данные клиентов собирались для исполнения договора, их нельзя направлять в ИИ-модель для обучения или аналитики без отдельного правового основания. Именно здесь возникает разрыв между тем, что делает продуктовая команда, и тем, что зафиксировано в уведомлении РКН.

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

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

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

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

Тип угроз: угрозы 1-го и 2-го типа (наличие недокументированных возможностей в системном ПО) применяются редко и требуют отдельного обоснования ФСБ. Для большинства коммерческих SaaS актуален тип 3 — угрозы, не связанные с недокументированными возможностями.

Число субъектов: порог 100 000 является ключевым. При угрозах 3-го типа и общих ПДн: до 100 000 субъектов — УЗ-3; свыше 100 000 — УЗ-2. Для спецкатегорий при угрозах 3-го типа: до 100 000 — УЗ-2; свыше — УЗ-1.

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

При мультиарендной SaaS (multi-tenant) возникает дополнительная задача: данные разных операторов-клиентов не должны смешиваться в одном контексте LLM. Это техническое требование, но оно имеет правовое измерение — нарушение принципа несовместимости баз по ст. 5 ФЗ-152.

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

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

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

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

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

Как оформить поручение обработки для GigaChat и YandexGPT?

Поручение обработки — это договорная конструкция, предусмотренная п. 3 ст. 6 ФЗ-152. Оператор остаётся ответственным перед субъектами и РКН; провайдер LLM действует строго в рамках выданного поручения. Если провайдер нарушает условия поручения — ответственность перед субъектами несёт оператор.

Поручение должно содержать: цель обработки, перечень действий с ПДн, перечень самих данных, обязательство провайдера обеспечить конфиденциальность и выполнить требования ст. 19 ФЗ-152. На практике для облачных LLM это означает, что в договоре с Яндексом или Сбером должен быть явный раздел data processing agreement (DPA) с перечнем передаваемых данных.

Сбер предоставляет корпоративный вариант GigaChat Enterprise с возможностью развёртывания в изолированном контуре или в облаке с SLA по безопасности. Яндекс предлагает YandexGPT через Yandex Cloud с аттестованным сегментом для государственных ИС. Наличие таких возможностей не означает автоматического соответствия: интегратор обязан самостоятельно определить УЗ, актуальные угрозы и задокументировать их в модели угроз по методике ФСТЭК.

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

Кейс 1. IT-компания (Приволжский ФО, осень 2025) внедрила GigaChat для суммаризации клиентских обращений в CRM. В модель передавались ФИО, телефоны и тексты обращений — без поручения обработки и без обновления уведомления в РКН. При плановой проверке РКН зафиксировал расхождение между заявленными в реестре целями и фактической обработкой. Оператору выставлен протокол по ч. 1 ст. 13.11 КоАП (штраф до 300 000 ₽). После подключения юристов удалось обосновать минимальный размер санкции и ускорить устранение нарушения.

Кейс 2. SaaS-платформа для HR (Центральный ФО, начало 2026) начала fine-tuning YandexGPT на базе резюме и оценок соискателей — порядка 15 000 записей. Перед запуском провели DPIA: выяснилось, что данные включают сведения об инвалидности (спецкатегория по ст. 10 ФЗ-152). Минимальный УЗ поднялся до УЗ-2 вместо предполагаемого УЗ-3. Потребовалось дополнительно реализовать меры по шести группам Приказа ФСТЭК №21. Бюджет на доработку составил около 800 000 ₽; без DPIA риск штрафа по ч. 13 ст. 13.11 достигал 5–10 млн ₽.

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

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

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

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

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

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

Передача ПДн граждан РФ в иностранный LLM без уведомления РКН по ст. 12 ФЗ-152 нарушает требования трансграничной передачи. Локализация по ч. 5 ст. 18 запрещает первичный сбор и хранение в зарубежных базах. Российские LLM (GigaChat, YandexGPT) по умолчанию соответствуют требованию локализации, однако остальные обязательства — поручение обработки, УЗ, обезличивание — оператор выполняет самостоятельно.

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

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

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

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

5. Какие СЗИ обязательны при интеграции LLM в ИСПДн УЗ-3 и УЗ-2?

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

Итог

GigaChat и YandexGPT соответствуют требованию локализации ч. 5 ст. 18 ФЗ-152, но не закрывают остальные обязанности оператора: правовое основание по ст. 6, поручение обработки, определение УЗ по ПП РФ №1119 и реализацию мер по Приказу ФСТЭК №21. Логирование запросов, fine-tuning на реальных данных и мультиарендная архитектура создают дополнительные правовые риски, каждый из которых требует отдельного решения.

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

14 апреля 2029 года