LLM в работе с клиентами: правовые риски

LLM в работе с клиентами стали стандартной практикой: чат-боты на сайте, голосовые ассистенты, автоматические ответы на заявки. При этом каждый запрос пользователя, отправляемый в модель, содержит персональные данные — прямые или косвенные. По данным РКН за 2024 год, более 710 млн записей утекло в результате инцидентов; значительная часть — через интеграции с внешними сервисами обработки данных, к которым относятся и LLM API. В этой статье разбираем четыре ключевых правовых риска для CTO: роль оператора в мультиарендной архитектуре, уровни защищённости для ИСПДн с ML-компонентом, обезличивание данных для обучения, логирование как самостоятельная обработка ПДн.

Кто является оператором, когда LLM обрабатывает данные клиентов?

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

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

Отдельный вопрос — иностранный провайдер LLM API (OpenAI, Anthropic, Google Vertex AI). Передача ПДн на их серверы — трансграничная передача по ст. 12 ФЗ-152. США не входят в перечень стран с адекватной защитой; до передачи необходимо уведомить РКН. Отсутствие уведомления — штраф от 100 000 до 300 000 ₽ по ч. 10 ст. 13.11 КоАП за каждый факт незаконной передачи. При использовании облачного LLM API с обработкой данных за рубежом нарушается также требование локализации по ч. 5 ст. 18 ФЗ-152; штраф по ч. 8 ст. 13.11 — от 1 до 6 млн ₽.

Какой уровень защищённости (УЗ) назначить ИСПДн с LLM-компонентом?

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

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

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

Для облачного развёртывания LLM добавляется требование: облако должно находиться в РФ. С 01.07.2025 (ФЗ-233) требования локализации ужесточены — первичный сбор, запись и систематизация ПДн граждан РФ должны происходить только в базах, расположенных на территории России. Если инференс LLM происходит на зарубежном сервере — это нарушение ч. 5 ст. 18 ФЗ-152 вне зависимости от того, хранятся ли данные там постоянно.

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

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

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

Технически важно: обезличивание должно быть необратимым без ключа. Псевдонимизация (замена имени на токен с сохранением соответствия) — это не обезличивание по позиции РКН; такие данные остаются персональными. Для LLM-систем рекомендуется метод введения идентификаторов с хранением ключа соответствия в отдельном изолированном сегменте сети, недоступном модели.

Как логирование LLM-запросов создаёт самостоятельный риск по ФЗ-152?

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

Типичные ошибки в логировании LLM-систем: хранение полных промптов в неструктурированных text-файлах без шифрования; передача логов в облачные системы мониторинга (Datadog, Elastic Cloud) без оценки трансграничности; отсутствие срока хранения — логи накапливаются бессрочно, что нарушает принцип минимизации по ст. 5 ФЗ-152. Нарушение требований к хранению на материальных носителях при неавтоматизированной обработке квалифицируется по ч. 6 ст. 13.11 КоАП; для систем автоматизированной обработки — по ч. 1 или ч. 8 ст. 13.11 в зависимости от обстоятельств.

Правильная архитектура логирования для LLM: хранить только структурированные метаданные (session_id, timestamp, тип запроса, код ответа) без содержимого промптов; либо — хранить полные промпты в зашифрованном изолированном хранилище с политикой retention не более 30 дней и автоматическим удалением по истечении срока.

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

Сценарий 1. SaaS-вендор без договора поручения. IT-компания (Сибирский ФО, осень 2025) запустила LLM-чат-бот для корпоративных клиентов. Данные клиентских пользователей передавались через API в облачный LLM-сервис без договора поручения и без уведомления РКН о трансграничной передаче. При плановой проверке РКН выявил два нарушения: отсутствие правового основания для трансграничной передачи (ч. 10 ст. 13.11 КоАП) и нарушение требований локализации (ч. 8 ст. 13.11 КоАП). Совокупный размер штрафов составил несколько миллионов рублей. После привлечения юристов удалось обжаловать часть постановлений, ссылаясь на добросовестное заблуждение относительно статуса обработчика. Вывод: юридическое оформление цепочки обработки должно предшествовать техническому запуску.

Кейс 2. Крупный маркетплейс (Центральный ФО, весна 2026) обучал рекомендательную LLM-модель на истории переписки с покупателями без предварительного обезличивания. В обучающей выборке присутствовали имена, адреса доставки и платёжные данные. Регулятор квалифицировал это как обработку ПДн без надлежащего правового основания (ч. 1 ст. 13.11 КоАП) — цель «обучение ML-модели» не была указана в уведомлении о намерении обрабатывать ПДн и в политике конфиденциальности. Компания подала уточнение в реестр РКН и переработала пайплайн с внедрением обезличивания на этапе до передачи данных в обучающий кластер. Штраф составил сотни тысяч рублей; требование об устранении — выполнено в срок.

Матрица рисков: три типовых сценария для CTO

LLM API за рубежом без уведомления РКН. Ситуация: компания подключила OpenAI или аналогичный зарубежный API и передаёт в него данные пользователей. Правовая квалификация: трансграничная передача в страну без адекватной защиты (ст. 12 ФЗ-152) + нарушение локализации (ч. 5 ст. 18 ФЗ-152). Вероятный исход: штраф 1–6 млн ₽ по ч. 8 ст. 13.11 и 100–300 тыс. ₽ по ч. 10 ст. 13.11. Стратегия: перейти на российский облачный инференс или оформить уведомление РКН до начала передачи.

Fine-tuning на клиентских диалогах без обезличивания. Ситуация: команда ML использует переписку пользователей напрямую как обучающую выборку. Квалификация: обработка ПДн с целью, не указанной при сборе (ст. 5 ч. 2 ФЗ-152); нарушение принципа минимизации. Вероятный исход: штраф по ч. 1 ст. 13.11 до 300 тыс. ₽ + предписание об устранении. Стратегия: внедрить обезличивание на входе ML-пайплайна, добавить цель «обучение ML-моделей» в реестровое уведомление и политику конфиденциальности.

Утечка из RAG-базы с ПДн клиентов. Ситуация: RAG-база данных содержит необезличенные клиентские документы; злоумышленник получает к ней доступ через уязвимость в API. Квалификация: утечка ПДн, обязанность уведомить РКН в течение 24 часов (ч. 3.1 ст. 21 ФЗ-152). Вероятный исход: штраф от 3 до 10 млн ₽ в зависимости от числа затронутых субъектов (ч. 12–13 ст. 13.11); при повторности — оборотный по ч. 15. Стратегия: хранить в RAG только обезличенные фрагменты; настроить мониторинг аномальных запросов к базе.

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

LLM в клиентском сервисе создаёт четыре самостоятельных правовых риска: неопределённый статус оператора в мультиарендной архитектуре, неверно назначенный УЗ, обработка необезличенных данных в ML-пайплайне и логирование промптов с ПДн без правового основания. Каждый риск сам по себе квалифицируется по ст. 13.11 КоАП; их сочетание при инциденте с числом субъектов более 10 000 даёт совокупный штраф от 5 до 20 млн ₽.

Практика DATUM по технической стороне 152-ФЗ охватывает определение УЗ для ML-систем, DPIA для LLM-продуктов, оформление договоров поручения в мультиарендных архитектурах и разработку политик обезличивания для обучающих пайплайнов.