Генеративный ИИ и 152-ФЗ совместимы — если выстроить правильную архитектуру до запуска. Главные рычаги: анонимизация данных перед отправкой в API, выбор между on-prem и российским облаком, обновлённые формы согласия и регламент логирования. Статья — практический чеклист, не юридическая консультация. ```yaml --- slug: 152-fz-generativnyy-ii type: radar format: flagship title: "152-ФЗ и генеративный ИИ: что учесть до запуска" summary: "Чеклист для ЛПР: какие данные нельзя отправлять в LLM-API, on-prem vs облако, согласие субъекта, логирование и паттерны анонимизации." seoTitle: "152-ФЗ и генеративный ИИ: чеклист до запуска" datePublished: 2026-07-09 tags: - 152-ФЗ - персональные данные - LLM - генеративный ИИ - регуляторика - on-prem - анонимизация - безопасность данных relatedService: /uslugi relatedServiceLabel: Услуги brezatech relatedCase: relatedCaseLabel: ogImage: /assets/blog/152-fz-generativnyy-ii-og.svg imagePrompt: "Офисный стол с двумя мониторами: на левом — документ с пометками и чеклистом, на правом — дашборд с потоками данных и иконками замков. Стиль flat illustration, цвета серо-синие, без абстрактного AI-свечения." keyFacts: - "Передача персональных данных в зарубежный LLM-API без согласия субъекта и уведомления Роскомнадзора — нарушение 152-ФЗ, штраф до 6 млн ₽ за повторное нарушение (с 2024 г.)." - "Обезличенные данные по ГОСТ Р 57580 и внутренним методикам РКН выведены из-под действия 152-ФЗ — это главный рабочий паттерн для LLM-интеграций." - "On-prem-развёртывание LLM (Ollama, vLLM, локальные веса) полностью снимает вопрос трансграничной передачи данных, но требует GPU-инфраструктуры." - "Логи промптов и ответов LLM могут сами по себе стать персональными данными — их хранение и доступ нужно регламентировать отдельно." - "Согласие субъекта на обработку ПД «с использованием ИИ» — отдельный пункт: стандартная форма согласия 2019–2022 годов его не покрывает." faq: - q: "Можно ли отправлять ФИО клиента в ChatGPT или YandexGPT API?" a: "Напрямую — нет, без выполнения требований 152-ФЗ: локализации, согласия субъекта и (для зарубежных API) уведомления РКН о трансграничной передаче. Безопасный путь — анонимизировать или псевдонимизировать данные до отправки." - q: "Чем псевдонимизация отличается от анонимизации в контексте 152-ФЗ?" a: "Псевдонимизированные данные остаются персональными — субъекта можно восстановить по ключу. Анонимизированные данные необратимо обезличены и выходят из-под действия закона. Для передачи в LLM-API нужна именно анонимизация." - q: "Нужно ли согласие сотрудника на обработку его данных внутренним корпоративным ИИ?" a: "Да, если система обрабатывает ПД сотрудников (переписка, голос, биометрия). Трудовой договор покрывает только цели, прямо связанные с исполнением обязанностей. Использование данных для обучения или анализа ИИ — отдельное основание." - q: "Что считается трансграничной передачей данных при работе с LLM?" a: "Любая отправка ПД на серверы, физически расположенные за пределами РФ. Это касается API OpenAI, Anthropic, Google и других зарубежных провайдеров. Российские облака (Yandex Cloud, SberCloud) и on-prem не создают этой проблемы." - q: "Как правильно логировать промпты, чтобы не нарушить 152-ФЗ?" a: "Логи с ПД — это отдельная база ПД. Нужны: ограниченный доступ, срок хранения в политике, возможность удаления по запросу субъекта. Лучшая практика — логировать только хэши или обезличенные метаданные, а не сырые промпты." sources: - title: "Федеральный закон № 152-ФЗ «О персональных данных» (ред. 2024)" url: "https://www.consultant.ru/document/cons_doc_LAW_61801/" - title: "Разъяснения Роскомнадзора по трансграничной передаче ПД (2023)" url: "https://rkn.gov.ru/personal-data/p872/" - title: "ГОСТ Р 57580.1-2017 — Безопасность финансовых операций" url: "https://www.consultant.ru/document/cons_doc_LAW_278618/" mentions: - Роскомнадзор - OpenAI - YandexGPT - Yandex Cloud - SberCloud - Ollama - vLLM - ГОСТ Р 57580 aboutBrezatech: "brezatech — интегратор ИИ в данные и бизнес-процессы: разработка LLM-решений, BI, автоматизация документооборота для B2B-компаний в РФ." --- ``` --- Почему это стало проблемой именно сейчас Два года назад вопрос «можно ли отправить данные клиента в ChatGPT» звучал абстрактно. Сегодня это операционный риск: компании запускают пилоты с LLM в поддержке, HR, юридическом анализе — и нередко обнаруживают, что в промптах оказываются ФИО, паспортные данные, медицинские сведения. Регуляторная рамка при этом ужесточилась. С 2024 года штрафы за повторные нарушения 152-ФЗ выросли до 6 млн ₽, а Роскомнадзор начал активнее проверять трансграничную передачу данных. Параллельно появились первые разъяснения РКН именно по теме ИИ-систем. Хорошая новость: большинство сценариев решаемы без отказа от LLM. Нужно понять, где именно возникает риск. --- Что такое персональные данные в контексте LLM 152-ФЗ определяет персональные данные широко: любая информация, относящаяся к прямо или косвенно определённому физическому лицу. Это означает, что под определение попадает не только ФИО + паспорт, но и: • email или телефон в сочетании с любым другим атрибутом, • история заказов конкретного клиента, • переписка сотрудника во внутреннем чате, • голосовые записи звонков в поддержку, • IP-адрес в связке с идентификатором сессии. Когда вы формируете промпт для LLM, в него нередко попадают именно такие данные — из CRM, тикет-системы, ERP. Это и есть точка риска. --- Чеклист: что нельзя отправлять в API без подготовки Ниже — категории данных, которые требуют специальной обработки до отправки в любой LLM-API (зарубежный или российский облачный). Красная зона — без анонимизации не отправлять: • ФИО + любой идентификатор (телефон, email, ИНН), • паспортные данные, СНИЛС, ИНН физлица, • медицинские и биометрические данные, • данные о судимостях, политических взглядах, вероисповедании, • данные несовершеннолетних. Жёлтая зона — оценить контекст: • внутренние ID клиентов (если маппинг хранится в системе), • тексты обращений без ФИО, но с деталями, позволяющими идентифицировать человека, • агрегированные данные с малой выборкой (< 5 человек в группе). Зелёная зона — можно передавать: • полностью анонимизированные тексты (необратимо), • синтетические данные, • внутренние справочники без привязки к физлицам, • публично доступные нормативные документы. --- On-prem vs облако: архитектурный выбор Это не вопрос вкуса — это вопрос регуляторной архитектуры. Критерий | On-prem LLM | Российское облако (Yandex Cloud, SberCloud) | Зарубежный API (OpenAI, Anthropic) Трансграничная передача | Нет | Нет | Да — требует уведомления РКН Локализация ПД | Выполнена | Выполнена | Требует отдельного анализа Контроль над логами | Полный | Частичный (по SLA) | Минимальный Качество моделей | Зависит от весов | Высокое (GPT-4 класс) | Максимальное Стоимость инфраструктуры | Высокая (GPU) | Средняя | Низкая (pay-per-token) Подходит для ПД | Да | Да (при правильной конфигурации) | Только с анонимизацией Вывод: on-prem (Ollama, vLLM с открытыми весами Mistral, LLaMA, Qwen) полностью снимает вопрос трансграничной передачи. Это оправдано для чувствительных данных: медицина, финансы, HR. Для задач, где данные можно анонимизировать, зарубежные API остаются рабочим вариантом. --- Паттерны анонимизации: как это работает на практике Анонимизация — не «удалить ФИО из текста вручную». Это системный процесс. Вот четыре рабочих паттерна. 1. NER-замена (Named Entity Replacement) Перед отправкой промпта в LLM запускается модель распознавания именованных сущностей (NER). Она находит имена, организации, адреса, телефоны и заменяет их на плейсхолдеры. Пример: • Исходный текст: *«Клиент Иванов Пётр из Екатеринбурга жалуется на задержку заказа №45231»* • После NER: *«Клиент [PERSON] из [CITY] жалуется на задержку заказа [ORDER_ID]»* LLM получает смысловую структуру, но не персональные данные. Ответ LLM возвращается, плейсхолдеры при необходимости восстанавливаются на стороне вашей системы. 2. Псевдонимизация с локальным ключом Вместо удаления данных — замена на детерминированный псевдоним (хэш или UUID). Ключ маппинга хранится только внутри периметра компании. LLM работает с псевдонимами, результат возвращается и декодируется локально. Важно: псевдонимизированные данные по 152-ФЗ остаются персональными. Этот паттерн снижает риск утечки, но не выводит данные из-под закона. Используйте его в связке с on-prem или российским облаком. 3. Синтетическая генерация для обучения и тестирования Если задача — дообучить модель или протестировать промпты на реальных паттернах — генерируйте синтетические данные. Современные LLM хорошо справляются с созданием реалистичных, но вымышленных датасетов. Это полностью исключает риск утечки реальных ПД. 4. Дифференциальная приватность (для аналитических задач) Если LLM используется для анализа агрегированных данных, добавление статистического шума (дифференциальная приватность) позволяет получать достоверные инсайты без возможности восстановить данные конкретного человека. Применимо в BI-сценариях, не в диалоговых. --- Согласие субъекта: что изменилось Стандартная форма согласия на обработку персональных данных, которую компании используют с 2019–2021 годов, почти наверняка не покрывает обработку с использованием ИИ. Что нужно добавить в форму согласия: • Явное указание на автоматизированную обработку с использованием систем ИИ, • Перечень целей — если ИИ используется для профилирования, принятия решений или анализа поведения, это должно быть прописано, • Указание на трансграничную передачу — если данные уходят в зарубежный API, субъект должен быть об этом уведомлён, • Право на отказ от автоматизированного решения — ст. 16 152-ФЗ даёт субъекту право требовать, чтобы значимое решение о нём принималось человеком, а не алгоритмом. Практически это означает: перед запуском LLM-системы, работающей с клиентскими данными, юридическая служба должна пересмотреть все действующие формы согласия. --- Логирование: скрытый источник риска Логи — это то, о чём думают в последнюю очередь, и именно здесь возникают проблемы при аудите. Когда LLM-система логирует промпты и ответы «для отладки», эти логи могут содержать персональные данные. Де-факто вы создаёте ещё одну базу ПД — со своими требованиями к хранению, доступу и удалению. Минимальный регламент логирования: • Не логировать сырые промпты с ПД — только хэши или обезличенные метаданные (длина, тип запроса, время), • Ограничить доступ к логам: только технические роли с обоснованной необходимостью, • Установить срок хранения — и автоматически удалять по истечении, • Включить логи в реестр баз ПД — Роскомнадзор при проверке запрашивает именно реестр, • Обеспечить возможность удаления по запросу субъекта — если в логах есть его данные. Если система использует RAG (Retrieval-Augmented Generation) с корпоративной базой знаний — проверьте, не попадают ли ПД в векторное хранилище. Эмбеддинги не являются анонимизацией: при наличии исходных данных текст восстанавливается. --- Быстрый чеклист перед запуском Перед тем как вывести LLM-систему в продакшн, пройдитесь по этому списку. Данные: • [ ] Определены категории ПД, которые могут попасть в промпты • [ ] Настроена NER-замена или иной механизм анонимизации на входе • [ ] Синтетические данные используются для тестирования и обучения Инфраструктура: • [ ] Выбран провайдер: on-prem / российское облако / зарубежный API с анонимизацией • [ ] Для зарубежного API подано уведомление в РКН о трансграничной передаче (если ПД всё же передаются) • [ ] Серверы с ПД физически расположены в РФ Юридика: • [ ] Формы согласия обновлены с учётом ИИ-обработки • [ ] Прописано право субъекта на отказ от автоматизированного решения • [ ] Внутренняя политика обработки ПД актуализирована Логирование: • [ ] Логи промптов не содержат сырых ПД • [ ] Срок хранения логов установлен и автоматизирован • [ ] Логи включены в реестр баз ПД Процессы: • [ ] Назначен ответственный за соответствие ИИ-системы 152-ФЗ • [ ] Проведён внутренний аудит или оценка рисков (DPIA) --- Итог 152-ФЗ не запрещает использовать генеративный ИИ с реальными данными. Он требует, чтобы вы понимали, какие данные куда уходят и на каком основании. Большинство рисков закрываются на архитектурном уровне — анонимизация на входе, правильный выбор инфраструктуры, обновлённые согласия и регламент логирования. Проблемы возникают не у тех, кто использует LLM, а у тех, кто запускает пилот «быстро», не задав себе эти вопросы заранее. --- *Связанные материалы в блоге brezatech:* • Как выбрать LLM для корпоративных задач: on-prem vs API • Данные как актив: с чего начать выстраивать data-стратегию