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

Персональные данные и 152-ФЗ: что учитывать при работе с ИИ

Когда мы внедряем языковые модели и автономных AI-агентов в бизнес-процессы компаний, постоянно возникает один и тот же вопрос: как обрабатывать клиентскую информацию через ИИ и при этом соблюдать нормы Федерального закона № 152-ФЗ «О персональных данных»? Я подготовил этот разбор в первую очередь для инженеров, продуктовых менеджеров и IT-архитекторов, чтобы показать техническую и процессуальную логику решений. Однако помните, что это технический взгляд на проблему, а не официальная юридическая консультация — перед запуском проектов в продакшен обязательно проконсультируйтесь с юристами вашей компании.

Регуляторная база и судебная практика в сфере ИИ меняются довольно быстро. К примеру, только за прошедшее лето произошло сразу несколько существенных обновлений в подходе к регулированию. Поэтому перед применением предложенных схем обязательно сверяйте актуальность законодательства.

Что по закону относится к персональным данным

Законодательное определение персональных данных (ПД) зафиксировано в пункте 1 статьи 3 закона № 152-ФЗ. Согласно норме, к ПД относится абсолютно любая информация, которая прямо или косвенно указывает на конкретное физическое лицо (субъекта данных). На практике под эту формулировку попадает огромный массив сведений: от имени, номера телефона и адреса электронной почты до должности, рабочего адреса и идентификаторов в системах.

Единственный ключевой критерий — это возможность идентифицировать конкретного человека. Покольку эта формулировка крайне широкая, трактовки часто вызывают споры даже между государственными ведомствами. Наглядный пример — отношение к ИНН физического лица:

• Минкомсвязь придерживается позиции, что ИНН сам по себе позволяет однозначно определить гражданина без привлечения дополнительных сведений.
• Минфин занимает противоположную сторону, декларируя, что ИНН не входит в перечень сведений, составляющих персональные данные.

Аналогичные расхождения постоянно встречаются и в решениях российских судов разных инстанций. Учитывая непостоянство судебной практики, в своей работе я советую опираться на наиболее безопасный подход: считать персональными данными абсолютно любые сведения, включая пользовательские ID, электронную почту, хэши и технические атрибуты. Это позволяет обезопасить проект от рисков, связанных с неоднозначностью трактовок закона.

Правила и требования к обработке ПД

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

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

В экосистеме популярных российских сервисов подобное поручение часто уже вшито в пользовательские соглашения (например, у Битрикса). Однако ситуация принципиально усложняется, когда данные планируется передавать на серверы за пределы Российской Федерации.

В терминах закона это называется трансграничной передачей персональных данных. Для ее проведения требуется направить отдельное уведомление в Роскомнадзор. Ведомство разделяет зарубежные страны на две категории:

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

Варианты использования LLM: от зарубежных сервисов до собственного сервера

Давайте рассмотрим основные сценарии работы с ИИ-моделями и степень их соответствия требованиям закона.

1. Прямая отправка запросов в зарубежные облака (OpenAI, Claude, оригинальный DeepSeek).
В данном сценарии я не вижу законного способа обрабатывать конфиденциальные персональные данные пользователей. Даже если дата-центр провайдера расположен в стране из «адекватного» списка РКН, вы не сможете корректно подписать с зарубежным вендором поручение на обработку ПД по правилам 152-ФЗ. Это непреодолимый стоп-фактор для использования оригинальных иностранной API напрямую.

2. Использование коммерческих российских LLM.
Здесь решение полностью зависит от юридических условий конкретного провайдера. Например, платформы Яндекса позволяют обрабатывать персональные данные в рамках соответствующих корпоративных договоров. А вот в условиях использования Сбер GigaChat прямо прописан запрет: сервис не предназначен для обработки запросов, содержащих персональные данные как самого пользователя, так и третьих лиц.

3. Open-source модели в инфраструктуре российских облачных провайдеров.
Этот подход вполне жизнеспособен, но также требует изучения документов площадки. В частности, Яндекс предоставляет доступ к модели DeepSeek через собственную облачную инфраструктуру в РФ (хотя стоимость токенов там существенно выше оригинального API), и условия сервиса допускают работу с ПД.

4. Open-source модели на собственном или арендованном железе в РФ.
Максимально надежный вариант с точки зрения комплаенса. Локальный контур на базе Llama, Qwen или DeepSeek полностью подконтролен вам и отвечает всем нормам локализации.

Важная деталь: 152-ФЗ требует обеспечения права пользователя на отзыв согласия и удаление сведений. Поэтому при работе с любыми внешними или публичными нейросетями вы обязаны гарантированно отключать логирование запросов и запрещать провайдеру использовать ваши промпты для дообучения моделей.

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

Анонимизация или обезличивание — это ключевая техника, которую я рекомендую использовать всегда, даже если вы работаете исключительно внутри российского облачного контура. Смысл метода заключается в том, чтобы трансформировать входящий текст перед отправкой в ИИ таким образом, чтобы модель вообще не получала персональных данных.

Рассмотрим два наглядных примера реализации:

Сценарий 1: Корректировка или анализ юридического документа.
Вам нужно проверить текст договора, содержащий ФИО, паспортные данные и ИНН клиента. Перед отправкой промпта в нейросеть скрипт на вашей стороне заменяет реальные значения на безопасные маркеры (например, {{CLIENT_NAME}}, {{PASSPORT_NUM}}, {{INN}}). LLM обрабатывает структурированный шаблон, а при получении ответа ваша система автоматически подставляет исходные значения на свои места.

Сценарий 2: Анализ обратной связи из клиентской базы.
Имеется выгрузка отзывов со столбцами user_id, name, email, phone, feedback. Перед передачей массива в нейросеть вы полностью вырезаете колонки с ПД (имя, почту, телефон), оставляя только системный ID и текст отзыва. Нейросеть категоризирует негатив, а затем результаты объединяются с исходной базой по ключу user_id.

Стоит понимать, что ни один алгоритм маскирования не дает абсолютной 100% гарантии очистки (особенно в сложных неструктурированных текстах). Однако эта процедура снижает риски утечки персональных данных до минимального уровня.

Инструменты и способы обезличивания

Релизовать маскирование сведений можно двумя способами:

1. Собственная разработка или Open-Source решения. Вы можете написать собственные парсеры на базе регулярных выражений и NLP-библиотек или развернуть готовые инструменты маскирования с открытым исходным кодом (например, Microsoft Presidio).
2. Специализированные российские прокси-сервисы. На рынке есть сервисы (KodikRouter, Jaycopilot и др.), которые выступают прослойкой между вашей системой и LLM. Они физически расположены в РФ, подписывают поручение на обработку данных по 152-ФЗ и автоматически вырезают ПД из входящих запросов на лету. Главное — убедиться, что прокси-сервис действительно очищает текст, а не просто пересылает его в исходном виде.

Итоговая шпаргалка для бизнеса

• Данные не содержат ПД: можно использовать любые нейросети, включая зарубежные сервисы (OpenAI, Anthropic и др.).
• Данные предварительно обезличены: риски снижены до минимума, допускается использование внешних моделей при соблюдении мер предосторожности.
• Данные содержат необработанные ПД: работа допустима только внутри российского контура — на собственном железе в РФ или в локальном облаке с оформленным поручением на обработку.

Источник: habr.com