Локальные LLM (LLama, GigaChat): преимущества

Интерес к локальным LLM в российских IT-командах растёт: LLama 3, Mistral, GigaChat On-Premise, Saiga — модели доступны для развёртывания на собственных серверах. Для CTO выбор между облачным API и локальным деплоем — это не только вопрос производительности, но и комплаенс по 152-ФЗ, требования ФСТЭК, уровни защищённости ИСПДн по ПП РФ №1119 и ответственность по ст. 272.1 УК РФ с 11.12.2024. В материале разобраны правовые преимущества локального развёртывания, требования к инфраструктуре и типичные ошибки при интеграции LLM в SaaS-продукты.

Почему локальный деплой LLM снижает риски по 152-ФЗ?

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

Локальная LLM устраняет проблему трансграничной передачи: промпт с данными пользователя не уходит на внешний сервер. Это сокращает периметр соответствия и упрощает документацию поручения. Кроме того, при использовании модели в режиме инференс без дообучения на пользовательских данных — обработка ПДн ограничена одним оператором, что снижает объём необходимой ОРД.

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

Как выбрать уровень защищённости ИСПДн для системы с LLM?

Уровень защищённости (УЗ) информационной системы персональных данных определяется по ПП РФ №1119 от 01.11.2012 исходя из трёх параметров: категория ПДн, тип угроз и количество субъектов. При интеграции LLM в продукт это решение не техническое — оно задаёт весь набор организационных и технических мер по Приказу ФСТЭК №21.

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

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

Важно: если SaaS работает в модели мультиаренды (multitenancy), каждый арендатор может быть отдельным оператором. Данные арендаторов необходимо логически изолировать на уровне базы данных и модели. Логирование обращений к LLM само по себе может содержать ПДн (промпты с именами, идентификаторами), что означает отдельную ИСПДн для логов с соответствующим УЗ.

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

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

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

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

Типичные сценарии для CTO: где возникает ответственность?

Три практические ситуации, с которыми сталкиваются технические директора при внедрении LLM в продукт.

Сценарий 1. SaaS с облачным LLM API и данными конечных пользователей. Компания использует OpenAI API для генерации ответов в чате поддержки. В промпты автоматически подставляются имя, история заказов и email клиента. Договор с OpenAI не содержит условий поручения обработки по российскому праву, уведомление о трансграничной передаче в РКН не подавалось. Ситуация: одновременно нарушены ч. 5 ст. 18 (локализация), ст. 12 (трансграничная передача) и п. 3 ст. 6 (поручение без договора). Вероятный исход: штраф по ч. 8 ст. 13.11 КоАП в диапазоне 1–6 млн ₽ плюс предписание. Стратегия: перейти на локальный деплой модели или GigaChat On-Premise, оформить поручение, провести DPIA.

Сценарий 2. Локальная LLama без документации ОРД. Команда развернула LLama 3 на собственных серверах в российском ЦОД. Данные не покидают периметр. Однако политика обработки ПДн не обновлена, ИСПДн не зарегистрирована в реестре РКН по ст. 22 ФЗ-152, уровень защищённости не определён, меры ФСТЭК не задокументированы. Ситуация: технически соответствие выше, чем в облачном сценарии, но документальная база отсутствует. На плановой проверке РКН это квалифицируется как нарушение ст. 18.1 и ст. 22 ФЗ-152 — штраф по ч. 3 и ч. 10 ст. 13.11 КоАП (30–300 тыс. ₽ суммарно). Стратегия: обновить уведомление в реестре, собрать ОРД, зафиксировать УЗ и меры защиты.

Сценарий 3. Дообучение модели на клиентских данных без обезличивания. Data-команда формирует датасет из обращений в службу поддержки для файнтюнинга модели. Данные содержат имена и контакты клиентов. Согласие на обработку ПДн в целях обучения модели получено не было — цель не была указана в уведомлении РКН и в согласиях клиентов. Ситуация: нарушение ст. 5 ФЗ-152 (принцип целеограниченности) и ст. 9 (обработка без согласия). При наличии утечки датасета — ч. 12–14 ст. 13.11 КоАП (3–15 млн ₽ в зависимости от числа субъектов). Стратегия: ввести обезличивание по методам РКН до формирования датасета, зафиксировать процедуру в ОРД.

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

Кейс 1. Финтех-компания (Центральный ФО, лето 2025) использовала облачный LLM-сервис для автоматической обработки заявок на кредит: в промпты передавались ФИО, дата рождения и кредитная история заявителей. При внеплановой проверке РКН, инициированной жалобой субъекта, регулятор зафиксировал трансграничную передачу без уведомления и отсутствие договора поручения. Компания перевела систему на GigaChat On-Premise, оформила ОРД, получила штраф в диапазоне сотен тысяч рублей по ч. 1 ст. 13.11 КоАП — нарушение было квалифицировано по старой норме, поскольку произошло до 30.05.2025.

Кейс 2 (реестровый кейс case_S2_pkr_analitika). Цифровая платформа инвестиционных проектов «ПКР Аналитика» (Северо-Западный ФО, начало 2026) столкнулась с утечкой около 70 000 субъектов — ФИО, должности, служебные email и телефоны сотрудников — после хакерской атаки. Дело рассмотрено Арбитражным судом Санкт-Петербурга и Ленинградской области (дело № А56-4733/2026 от 10.03.2026). Квалификация — ч. 14 ст. 13.11 КоАП. Смягчающие обстоятельства учтены при назначении наказания. Для CTO вывод однозначный: локальная инфраструктура снижает вектор атаки, но не отменяет необходимость выстроить процедуру реагирования на инцидент за 24/72 часа по Приказу РКН №187.

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

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

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

1. Какой УЗ выбрать для SaaS?

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

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

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

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

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

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

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

5. Какие СЗИ обязательны?

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

Итог

Локальный деплой LLM — LLama, GigaChat On-Premise, Saiga — устраняет проблему трансграничной передачи, упрощает реализацию мер ФСТЭК по Приказу №21 и создаёт контролируемую среду для обезличивания датасетов по ст. 13.1 ФЗ-152. При этом техническое решение не заменяет документальную базу: без актуального уведомления в реестре РКН, акта классификации ИСПДн, модели угроз и процедуры обезличивания локальная модель не обеспечивает соответствие — она лишь создаёт для него предпосылки.

Юристы DATUM сопровождают IT-компании и SaaS-провайдеров при классификации ИСПДн, подготовке ОРД под требования ФСТЭК и РКН, проведении DPIA при интеграции ML-систем и построении процедур обезличивания. Практика по 152-ФЗ ведётся с 2014 года в составе сети «Ветров и партнёры».