Персональные данные клиентов и AI 2026: правовые основания по 152-ФЗ и GDPR для чат-ботов и LLM

Автор: Silvana · Дата: 10.08.2026 · Verified: 01.09.2026 · Reading time: 22 минуты · Prerequisite: базовое понимание, что твой сервис обрабатывает данные клиентов

Эта статья — общая информация, не юридическая консультация. Для юр-решений консультируйся с юристом. Для compliance-аудита — со сертифицированным DPO.

Персональные данные (PII) — любая информация о прямо или косвенно определяемом физическом лице. По 152-ФЗ (статья 3) и GDPR (Article 4) определения близкие, но не идентичные. Использование AI (LLM, чат-боты, ML-модели) для обработки PII — юридически такая же обработка, требует правового основания, соблюдения принципов и мер защиты. Правовые основания по 152-ФЗ (статья 6): согласие, договор, обязанности оператора, витальные интересы, полномочия госорганов. По GDPR (Article 6): согласие, договор, юридическая обязанность, законный интерес контроллера. Согласие как основание — не всегда лучший вариант: часто договор или законный интерес подходят лучше, так как согласие требует отзывности и усложняет архитектуру. Ниже — практика для SaaS, CRM и поддержки.

Кратко

Персональные данные (PII) — любая информация, относящаяся к прямо или косвенно определяемому физическому лицу. По ФЗ № 152 (статья 3) и GDPR (Article 4) определения близкие, но не идентичные.
Использование AI (LLM, ML-модели, чат-боты) для обработки PII — юридически такая же обработка, как любая другая. Требует правового основания, соблюдения принципов, надлежащих мер защиты.
Правовые основания по ФЗ № 152 (статья 6): согласие субъекта, договор, исполнение обязанностей оператора, защита жизненно важных интересов, полномочия государственных органов, общедоступные источники, статистика, судебные акты.
Правовые основания по GDPR (Article 6): согласие, договор, юридическая обязанность, витальные интересы, публичный интерес, законный интерес контроллера. Спецкатегории (Article 9) требуют дополнительных условий.
Согласие как основание — не всегда лучший вариант. Часто договор с клиентом или законный интерес подходят лучше. Согласие требует отзывности, что усложняет архитектуру.
Прозрачность обязательна: субъект должен знать, что его данные обрабатываются AI, для каких целей, кто оператор, куда данные передаются. Формулировки в Privacy Policy — ключевое.
Автоматизированные решения (Article 22 GDPR, статья 16 ФЗ № 152) с юридическими последствиями требуют особых мер: право оспорить, право получить человеческое ревью, право на объяснение.
Права субъектов: доступ, исправление, удаление, ограничение обработки, переносимость, возражение против автоматизированных решений. Реализация в AI-системах — отдельная инженерная задача.

Что такое персональные данные

По ФЗ № 152 статья 3, персональные данные — «любая информация, относящаяся к прямо или косвенно определённому или определяемому физическому лицу (субъекту персональных данных)».

По GDPR Article 4(1) — «any information relating to an identified or identifiable natural person».

Разница минимальна на уровне определений, но важна в интерпретации.

Что точно PII:

Прямые идентификаторы: ФИО, паспорт, СНИЛС, ИНН, номер телефона, email, физический адрес.
Уникальные онлайн-идентификаторы: user ID, cookie ID, device ID, IP-адрес (по позиции CJEU и Роскомнадзора).
Биометрические данные: отпечатки, распознавание лица, голосовые характеристики.
Комбинации данных, позволяющие однозначно идентифицировать: например, дата рождения + почтовый индекс + пол статистически дают уникальность в большинстве случаев.

Что также PII, но часто забывают:

Данные, из которых можно вывести личность через комбинацию: например, «пользователь заказал X товар в Y дату по адресу Z» — если товар и адрес уникальные, это PII.
Метаданные: время активности, паттерны использования, геолокация.
Пользовательский контент: тексты сообщений, фотографии, аудио — как правило PII в силу содержания.
User agents, характеристики устройства, техотпечаток (browser fingerprint).

Что специальные категории (по ФЗ № 152 статья 10 / GDPR Article 9):

Расовая, национальная принадлежность.
Политические взгляды, религиозные и философские убеждения.
Членство в профсоюзе.
Состояние здоровья, генетические, биометрические данные (для идентификации).
Данные о сексуальной жизни, ориентации.
Данные о судимости (в GDPR отдельно, Article 10).

Обработка специальных категорий требует более строгих оснований и мер защиты.

Что не PII:

Полностью анонимные данные — из которых невозможно восстановить личность даже теоретически.
Полностью синтетические данные, сгенерированные без реальных субъектов.
Данные о юридических лицах (кроме ИП, которые часто пересекаются с личностью).
Данные умерших (по большинству юрисдикций, хотя есть нюансы в GDPR для некоторых стран ЕС).

Обезличивание (псевдонимизация с удалением ключа обратимости) — грань. По ФЗ № 152 и GDPR обезличенные данные могут быть выведены из-под регулирования, но только при доказательстве необратимости.

AI-обработка: юридически то же самое

Ключевая мысль, которую часто пропускают: использование AI/LLM для обработки данных клиентов юридически ничем не отличается от любой другой обработки. Все требования ФЗ № 152 и GDPR применяются.

Оператор (по ФЗ № 152) / контроллер (по GDPR) — организация, которая определяет цели и средства обработки. Если ты определил, что твой сервис использует OpenAI API для суммаризации обращений клиентов, то ты оператор/контроллер этой обработки, независимо от того, что технически суммаризация происходит на серверах OpenAI.

Обработчик (по ФЗ № 152 статья 6, часть 3) / процессор (по GDPR Article 28) — организация, которая обрабатывает данные по поручению оператора. OpenAI, Anthropic, Google в такой роли для тебя, если ты используешь их API для обработки PII. Требуется договор (Data Processing Agreement, DPA) с условиями обработки.

Что это значит:

Ты обязан иметь правовое основание для обработки (см. следующую секцию).
Ты обязан информировать субъектов, что их данные обрабатываются, включая цели, категории получателей, срок хранения (детально в статье про AI compliance).
Ты обязан обеспечить меры защиты, адекватные рискам.
Ты обязан заключить DPA с вендорами AI.
Ты обязан вести реестр обработки.
Ты обязан реализовать права субъектов: доступ, исправление, удаление, и т. д.
При инциденте — обязан уведомить регулятора и субъектов.

Всё это — не рекомендации, а обязанности оператора. Штрафы за нарушение (после ужесточения КоАП в 2025 году в РФ) — до 15 миллионов рублей для юрлиц за неуведомление об инциденте, до 500 тысяч за отсутствие мер защиты, повторные — кратно больше.

Правовые основания по ФЗ № 152

Статья 6 ФЗ № 152 устанавливает исчерпывающий перечень оснований. Обработка PII правомерна только при наличии хотя бы одного.

1. Согласие субъекта (пункт 1 части 1). Классический вариант. Согласие должно быть конкретным, информированным, сознательным, однозначным. По статье 9 — форма согласия: письменно (в том числе через галочку с явной формулировкой), простая электронная подпись, УКЭП. Молчаливое согласие не допускается.

Ограничения согласия:

Отзывается в любой момент (часть 2 статьи 9).
Должно быть отдельным для разных целей.
Не может быть условием предоставления услуги, если данные не необходимы для услуги (часть 4 статьи 9).

2. Договор с субъектом (пункт 5 части 1). Обработка необходима для исполнения договора, стороной которого является субъект. Не нужно отдельного согласия — обработка правомерна в силу договора.

Пример: клиент купил у тебя SaaS-подписку. Обработка его email и данных биллинга необходима для оказания услуги. Согласие отдельно не требуется — договор основание.

Ограничение: обработка ограничена целями договора. Если ты хочешь использовать те же данные для маркетинга — нужно отдельное основание (согласие или законный интерес).

3. Исполнение обязанностей оператора, установленных законом (пункт 2 части 1). Например, налоговый учёт — обязан по НК, поэтому данные бухгалтерии обрабатываешь без согласия.

4. Правосудие, исполнение судебного акта (пункт 3 части 1).

5. Государственные функции (пункт 4 части 1).

6. Защита жизни, здоровья или иных жизненно важных интересов (пункт 6 части 1).

7. Достижение общественно значимых целей (пункт 7 части 1). С 2024 года — включает case, когда обработка необходима для реализации прав и законных интересов оператора или третьих лиц. Аналог законного интереса из GDPR, но уже.

8. Общедоступные ПД (пункт 9 части 1). Данные, которые субъект сделал общедоступными или которые подлежат опубликованию.

9. Статистика (пункт 10 части 1). С условием обезличивания.

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

Правовые основания по GDPR

Article 6(1) GDPR — шесть оснований.

(a) Consent — согласие. Аналог российского согласия, но требования GDPR строже: должно быть freely given, specific, informed, unambiguous, verifiable. Withdrawable в любой момент, что должно быть так же легко, как дать.

(b) Contract — исполнение контракта или преддоговорные меры по просьбе субъекта. Аналог российского пункта 5.

© Legal obligation — юридическая обязанность контроллера. Аналог российского пункта 2.

(d) Vital interests — витальные интересы субъекта или другого физлица.

(e) Public interest — задача, выполняемая в общественных интересах или в осуществление официальных полномочий.

(f) Legitimate interests — законный интерес контроллера или третьей стороны, если не перевешивают права и свободы субъекта. Требуется balancing test.

Legitimate interests — часто используемое основание для аналитики, безопасности, direct marketing существующим клиентам, некоторых аспектов профилирования. Тест на баланс интересов — обязательный шаг, документируется в LIA (Legitimate Interest Assessment).

Специальные категории (Article 9): обработка запрещена, кроме случаев из Article 9(2). Основные: явное согласие, необходимость для трудовых отношений, витальные интересы, деятельность некоммерческих организаций, публичность данных субъектом, судебное разбирательство, публичный интерес в области здоровья.

Практика для SaaS с AI: обычно комбинация (b) contract для core-функций, (f) legitimate interests для аналитики и безопасности, (a) consent для маркетинга. Каждая обработка требует одного из них.

Прозрачность: что говорить клиентам

По ФЗ № 152 (статья 18) и GDPR (Articles 13-14) оператор обязан информировать субъектов. Информация должна быть предоставлена в момент сбора данных, в понятной и доступной форме.

Что раскрывать (общий чек-лист):

Название и контакты оператора/контроллера.
Название и контакты DPO (если назначен).
Цели обработки — для каждой цели отдельно.
Правовое основание (по GDPR — обязательно; по ФЗ № 152 — как правило).
Категории обрабатываемых данных.
Категории получателей данных, включая третьих лиц (например, LLM-вендоры).
Международная передача данных (transborder-transfer): куда, на каких основаниях.
Срок хранения.
Права субъекта и как их реализовать.
Право на отзыв согласия, если основание — согласие.
Право на подачу жалобы в надзорный орган.
Наличие автоматизированного принятия решений с юридическими последствиями (Article 22 GDPR / статья 16 ФЗ № 152), логика решения, значимость и последствия.

Формулировки для AI (примеры):

Что часто пропускают в Privacy Policy старого образца:

«Мы используем AI-инструменты (включая LLM-модели от OpenAI, Anthropic, Google) для [конкретных задач]».
«Ваши данные передаются нашим обработчикам, включая [список AI-вендоров], для целей [указано]. Обработчики связаны договорами о защите данных».
«Данные могут передаваться за пределы РФ в [страны]. Мы применяем следующие меры защиты: [DPA с вендорами, redaction, ZDR-контракты]».
«Некоторые процессы автоматизированы с помощью AI: [конкретно, что автоматизировано]. Вы имеете право запросить человеческое ревью такого решения».

Что не работает:

«Мы можем использовать ваши данные для улучшения наших сервисов, включая обучение AI-моделей» — слишком широко, невалидно как согласие по GDPR.
«Продолжая использование сайта, вы соглашаетесь» — не valid consent по GDPR (нет unambiguous action).
Умолчание о использовании AI-вендоров — нарушение принципа прозрачности.

Практика: после внедрения AI-функции ты обычно обновляешь Privacy Policy и уведомляешь существующих пользователей. По GDPR — обычно уведомление о существенном изменении требуется заранее. По ФЗ № 152 — тоже необходимо информировать.

Права субъектов в AI-контексте

По ФЗ № 152 (глава 3) и GDPR (Chapter 3) у субъекта есть набор прав, которые оператор обязан реализовать.

Право на доступ (Article 15 GDPR / статья 14 ФЗ № 152). Субъект может запросить: какие его данные обрабатываются, для каких целей, кому передаются, срок хранения, источник получения.

Инженерная задача: быть готовым выгрузить все данные конкретного пользователя из твоей системы, включая логи взаимодействия с AI, промпты и ответы, метаданные. Стандартный ответ — в течение 30 дней (по GDPR), до 30 дней (по ФЗ № 152).

Право на исправление (Article 16 GDPR / статья 14 ФЗ № 152). Неточные данные должны быть исправлены. Проблема с AI: данные, «запечатанные» в fine-tuning или в embedded векторах, сложно поправить точечно. Практика — регулярный retrain и удаление устаревших индексов.

Право на удаление (right to be forgotten, Article 17 GDPR / статья 14 ФЗ № 152). Субъект может потребовать удаления. Требования — конкретные, есть исключения (юридические обязанности, публичный интерес).

Инженерная задача: удалить пользователя из всех мест: primary DB, аналитика, кеши, backups (по мере ротации), логи LLM-запросов, embeddings в векторных БД, fine-tuned модели. Последний пункт — самый сложный. Если данные пользователя попали в тренировочный датасет — их удаление из уже обученной модели практически невозможно. Решение — не использовать PII в тренировке.

Право на ограничение обработки (Article 18 GDPR). Промежуточное состояние между обработкой и удалением. Данные хранятся, но не обрабатываются (кроме исключений).

Право на переносимость (Article 20 GDPR). Получить свои данные в структурированном, машиночитаемом формате и передать другому контроллеру. Обычно применимо для core данных, не для derived (AI-inference результатов).

Право на возражение (Article 21 GDPR). Возражать против обработки на основании законного интереса или общественного интереса. Direct marketing — абсолютное право возражения.

Право не подпадать под автоматизированное решение (Article 22 GDPR / статья 16 ФЗ № 152). Ключевое для AI-систем. Если решение принимается исключительно автоматизированным способом (без осмысленного человеческого участия) и имеет юридические или существенные последствия — субъект имеет право оспорить и потребовать человеческого ревью.

Примеры автоматизированных решений с последствиями:

Автоматический отказ в кредите на основании ML-скоринга.
Автоматический бан аккаунта на основании AI-модерации.
Автоматическое повышение цены на основании профилирования (dynamic pricing).
Автоматический отказ в приёме на работу на основании CV-скрининга.

Если у тебя есть такие процессы — нужны специальные меры: явное информирование субъекта, право оспорить, право получить объяснение (по крайней мере, значимую логику), доступное человеческое ревью.

Меры защиты: что «адекватно»

По ФЗ № 152 (статья 19) оператор обязан принимать необходимые правовые, организационные и технические меры для защиты данных от неправомерного доступа, уничтожения, изменения, копирования, распространения. Постановление Правительства № 1119 и приказы ФСТЭК/ФСБ конкретизируют требования по уровням защищённости.

По GDPR (Article 32) — «appropriate technical and organisational measures», включая псевдонимизацию, шифрование, обеспечение конфиденциальности, целостности, доступности, устойчивости, восстановление после инцидента, регулярное тестирование.

Технические меры (типовой минимум для AI-сервисов):

Шифрование данных в покое (at rest) и при передаче (in transit). TLS 1.2+, AES-256 для дисков.
Контроль доступа с ролевой моделью. Least privilege. MFA для чувствительных ролей.
Логирование доступа к PII. Retention логов минимум 6-12 месяцев (зависит от юрисдикции).
Регулярные бэкапы с шифрованием.
Segregation окружений: prod / staging / dev. PII только в prod.
Redaction перед отправкой в LLM (см. статью про data leaks).
Sandbox для tool execution в AI-агентах.
Мониторинг аномалий, alerts на подозрительные паттерны.
Регулярные security-обновления инфраструктуры.
Ротация ключей и секретов.

Организационные меры:

Назначение DPO (для крупных операторов и специальных случаев обязательно).
Реестр обработки данных.
Политики: Privacy Policy для внешних, Data Processing Policy для внутренних, AI Usage Policy для сотрудников.
Обучение сотрудников (регулярное, документированное).
Договоры с обработчиками (DPA).
Процесс incident response.
Регулярные аудиты и оценка воздействия (DPIA).

Оценка воздействия (DPIA): обязательна по GDPR (Article 35) для операций с высоким риском. Использование AI для профилирования, автоматизированных решений, обработки специальных категорий обычно попадает под требование DPIA. По ФЗ № 152 — ОРПД (Оценка рисков персональных данных) с 2024 года также обязательна для операторов, обрабатывающих специальные категории и биометрию.

Transborder transfer при AI-обработке

Если данные российских граждан передаются в иностранные LLM (OpenAI, Anthropic, Google) — это transborder-transfer, регулируемый статьёй 12 ФЗ № 152.

Основные требования (редакция 2026 года):

Уведомление Роскомнадзора о трансграничной передаче до её начала.
Уведомление содержит: цели, категории данных, категории субъектов, страны-получатели, правовые основания.
Роскомнадзор в срок до 10 рабочих дней может запретить или ограничить transfer.
Для стран без адекватного уровня защиты (США там нет) — согласие субъекта на конкретную операцию с указанием получателя.
Договор с получателем данных с гарантиями защиты (аналог DPA).

Локализация первичной обработки (статья 18 ФЗ № 152): при сборе PII российских граждан оператор обязан обеспечить обработку и хранение в базах данных на территории РФ.

Практическая интерпретация: если первичный сбор и хранение — в РФ (у тебя своя база в РФ), а дальше данные передаются в иностранный LLM для обработки — это не нарушение локализации, но остаётся вопрос transborder-transfer.

Практические стратегии:

Обезличивание перед отправкой. Данные, потерявшие идентифицирующие свойства, перестают быть PII. Обработка обезличенных данных не регулируется ФЗ № 152. Redaction на клиенте — техническая реализация.
Российские провайдеры. Yandex Cloud, Sber (GigaChat), MTS (Cotype) хранят и обрабатывают данные в РФ. Transborder-transfer не возникает.
Локальные модели (Llama, Qwen) на своей инфраструктуре в РФ. Данные не покидают контур.
Уведомление Роскомнадзора + согласие субъектов + DPA с вендором. Возможно, но громоздко.
Enterprise-планы иностранных вендоров с EU-регионом хранения. Не решает проблему трансграничной передачи для российских субъектов, но добавляет один уровень защиты.

GDPR-контекст: трансграничная передача из ЕС в третьи страны (в том числе в РФ) регулируется Chapter V GDPR. Требуются: adequacy decision (для РФ нет), Standard Contractual Clauses (SCC), Binding Corporate Rules (BCR), или derogations. После вторжения РФ в Украину адекватности не будет, поэтому transfer из ЕС в РФ фактически заблокирован, кроме исключений.

Инциденты: что делать

По ФЗ № 152 (статья 21) при обнаружении неправомерной передачи или иного инцидента с PII оператор обязан уведомить Роскомнадзор.

Сроки (редакция 2026 года):

Первичное уведомление — в течение 24 часов с момента обнаружения инцидента.
Расширенное уведомление с результатами внутреннего расследования — в течение 72 часов.
Уведомление субъектов — если инцидент может причинить существенный вред, «в разумный срок».

Содержание уведомления:

Описание инцидента, дата и время обнаружения.
Категории и приблизительное число субъектов и данных.
Возможные последствия.
Меры, принятые для устранения и mitigation.
Контакты для получения дополнительной информации.

По GDPR (Article 33-34):

Уведомление supervisory authority — 72 часа с момента обнаружения (unless unlikely to result in a risk).
Уведомление субъектов — если high risk.
Записи в внутреннем реестре инцидентов.

Практика для AI-инцидентов:

Если prompt injection привёл к утечке данных других пользователей — это инцидент.
Если ошибка в конфигурации привела к тому, что модель отвечала на промпты чужими данными — это инцидент.
Если API-ключ утёк и был использован кем-то — это инцидент.
Если сотрудник случайно залил PII в chat-интерфейс без соответствующего контура — потенциальный инцидент, оценивай риск.

Готовность: заранее подготовь incident response plan с юридической частью. Знай, кому звонить, что писать в Роскомнадзор, как коммуницировать с субъектами и клиентами.

Практическая схема для SaaS с AI

Типовой контур для B2B SaaS, использующего LLM для обработки клиентских данных.

Слой 1: категоризация данных.

Технические данные (user ID, IP, session) — обрабатываются по договору + законный интерес.
Пользовательский контент (документы, сообщения, задачи) — по договору.
PII клиентов (email, ФИО) — по договору.
Специальные категории — только с явным согласием и специальным обоснованием.

Слой 2: правовые документы.

Terms of Service с ясным описанием сервиса.
Privacy Policy с раскрытием AI-обработки, вендоров, целей, сроков, прав.
Cookie Policy (если применимо).
Data Processing Agreement (DPA) — для B2B, где клиент — контроллер, ты — процессор.

Слой 3: технический контур.

Данные хранятся в РФ (для российских клиентов).
LLM-обработка через API с ZDR или через Enterprise-план с гарантиями.
Redaction перед отправкой в LLM.
Логирование, мониторинг, alerts.

Слой 4: организация.

DPO назначен (для операторов от 100 сотрудников или обрабатывающих специальные категории — обязательно).
Реестр обработки заполнен и актуализирован.
Обучение сотрудников по AI Usage Policy.
Договоры с AI-вендорами (DPA).
DPIA/ОРПД для высокорисковых операций.

Слой 5: обязательства перед регуляторами.

Уведомление о начале обработки (по ФЗ № 152).
Уведомление о transborder-transfer (если applicable).
Готовность к проверкам и запросам.
Incident response plan.

Слой 6: реализация прав субъектов.

Endpoint для доступа к своим данным (self-service или через запрос).
Механизм удаления с полным охватом (включая логи AI-запросов и embeddings).
Механизм согласия и отзыва (если основание — согласие).
Возможность запросить человеческое ревью автоматизированного решения.

Специфика для разных сценариев AI

Не каждый AI-сценарий требует одинаковых мер.

Chatbot поддержки, отвечающий на вопросы клиентов. Обычно PII клиента (email, ID) идёт в промпт вместе с историей обращений. Требования: DPA с LLM-вендором, redaction прямых идентификаторов, логирование, retention policy. Правовое основание — договор с клиентом.

Автоматизация обработки резюме кандидатов. PII кандидатов, включая контакты и биографию. Если решение о приёме принимается автоматически — попадает под Article 22 GDPR (автоматизированные решения). Требования: явное согласие или другое основание, право на human review, объяснение логики, регулярные оценки на bias.

Анализ обращений клиентов для sentiment analysis. Обычно PII можно обезличить (нужен только сам текст обращения без имён). Redaction. Если для аналитики достаточно агрегатов — использовать только их.

Персонализация контента на основе профиля. Профилирование. По GDPR требует прозрачности и права возражения. Не должно приводить к автоматизированным решениям с существенными последствиями без соответствующих мер.

AI-модерация контента. Автоматическая, часто с последствиями для пользователя (бан, скрытие). Article 22 GDPR применим. Нужны: право оспорить, human review, transparent policy.

Копилот для сотрудников (внутренний). Данные сотрудников и клиентов проходят через LLM. Требования те же, что для внешнего сервиса. Дополнительно — трудовое право (в РФ — ТК, в ЕС — местные аналоги).

Fine-tuning на клиентских данных. Если модель дообучается на данных клиентов, эти данные становятся частью модели. Удаление конкретного клиента из fine-tuned модели практически невозможно. Стратегии: не использовать PII в fine-tuning; периодический full retrain с исключением удалённых клиентов; RAG вместо fine-tuning для актуальных данных.

FAQ

Нужно ли отдельное согласие клиента на то, что я использую LLM для обработки его данных?

Не всегда. Если обработка входит в цели, для которых уже есть основание (договор, законный интерес), отдельное согласие может не требоваться. Обязательно — прозрачность: в Privacy Policy должно быть сказано, что для реализации сервиса используются AI-обработчики, включая их перечень.

Что если клиент попросил удалить свои данные, но они уже прошли через LLM?

Данные, прошедшие через LLM в inference-режиме (без обучения) и удалённые из логов вендора по истечении retention — практически считаются удалёнными. Данные, использованные для fine-tuning — практически неудаляемы из модели. Правильное решение — не использовать PII в fine-tuning.

Является ли IP-адрес персональными данными?

По решениям CJEU (для GDPR) и позиции Роскомнадзора (для ФЗ № 152) — динамический IP-адрес считается PII, если оператор имеет возможность его связать с личностью. Практически — почти всегда PII в контексте веб-сервисов.

Могу ли я анонимизировать данные и потом использовать без ограничений?

Только если анонимизация полная и необратимая — данные не могут быть восстановлены даже теоретически. Псевдонимизация (замена на ID с сохранением ключа обратимости) — недостаточна: такие данные остаются PII. Полная анонимизация — сложная задача, часто требует агрегации и удаления мелких деталей.

Нужен ли DPO, если у меня всего 10 сотрудников?

По ФЗ № 152 — не обязательно (обязательно для операторов, обрабатывающих специальные категории или биометрию систематически). По GDPR — тоже не обязательно для маленьких компаний, если нет large scale обработки специальных категорий. Но de facto — назначить ответственного за data protection полезно даже в маленькой команде.

Что делать, если субъект — гражданин РФ, а данные обрабатываются на серверах в США?

Это transborder-transfer, требует уведомления Роскомнадзора и (для стран без адекватного уровня, включая США) согласия субъекта на конкретную операцию. Практическая альтернатива — обезличивание перед отправкой или использование российских провайдеров для PII.

Как оформить согласие на AI-обработку правильно?

По ФЗ № 152 (статья 9) — конкретно, информированно, сознательно. Формулировка должна упоминать: цели, категории данных, категории получателей (включая AI-вендоров), срок, право отзыва. По GDPR — те же требования плюс unambiguous action (галочка, а не «продолжая пользоваться»). Формулировку согласуй с юристом.

Обязан ли я упоминать конкретных LLM-вендоров в Privacy Policy?

По принципу прозрачности — да, категории получателей данных должны раскрываться. Практика — упомянуть или конкретных вендоров (OpenAI, Anthropic, Google), или категории («AI-сервисы аналитики и поддержки») со ссылкой на актуальный перечень. Полное умолчание — нарушение прозрачности.

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

Data Protection Impact Assessment — документированная оценка воздействия обработки на права субъектов. По GDPR (Article 35) обязательна при высоком риске: систематическое профилирование, обработка специальных категорий в больших масштабах, автоматизированные решения с юридическими последствиями. По ФЗ № 152 аналог — ОРПД (Оценка рисков персональных данных) с 2024 года для аналогичных случаев.

Штрафы за нарушение — насколько серьёзно?

По КоАП (редакция 2025 года) в РФ: до 500 000 рублей за отсутствие согласия, до 15 миллионов за неуведомление об инциденте с большим числом субъектов, до 3% годовой выручки за повторные нарушения. По GDPR: до 4% годового мирового оборота или 20 миллионов евро (что больше). Это не гипотетика — регулярно применяются реальные крупные штрафы.

Если я использую только OpenAI Enterprise с ZDR, всё ли нормально с точки зрения ФЗ № 152?

Не полностью. Даже с ZDR это transborder-transfer, требующий уведомления Роскомнадзора для российских субъектов. ZDR решает проблему retention, но не географию. Плюс остаётся ответственность за прозрачность, права субъектов и организационные меры на твоей стороне.

Какие штрафы за отсутствие уведомления Роскомнадзора об инциденте?

По КоАП статья 13.11 часть 12 (редакция 2025–2026 года) штрафы за неуведомление об инциденте достигают 15 миллионов рублей для юрлиц. Точный размер зависит от масштаба инцидента и числа затронутых субъектов. Уведомляй в срок — экономия несопоставима с риском.

Актуальность

Актуально на 10.08.2026. Модели, цены и условия доступа меняются часто. Перед бизнес-решением всегда сверяйся с первоисточником — все ссылки в разделе Sources ниже.

Sources

https://pravo.gov.ru — консультативная копия ФЗ № 152 «О персональных данных», актуальная редакция (проверено 10.08.2026)
https://pravo.gov.ru — консультативная копия ФЗ № 149 «Об информации, информационных технологиях и о защите информации» (проверено 10.08.2026)
https://pravo.gov.ru — Постановление Правительства РФ № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах» (проверено 10.08.2026)
https://edpb.europa.eu — European Data Protection Board, guidance и решения по GDPR (проверено 10.08.2026)
https://gdpr-info.eu — консолидированный текст GDPR со ссылками на официальный EUR-Lex (проверено 10.08.2026)
https://openai.com/policies/business-terms — OpenAI Business Terms с разделом Data Processing Agreement (проверено 10.08.2026)
https://openai.com/enterprise-privacy — Enterprise Privacy policy OpenAI (проверено 10.08.2026)
https://www.anthropic.com/legal — все юридические документы Anthropic, включая Terms и DPA-шаблоны (проверено 10.08.2026)
https://policies.google.com/privacy — Privacy Policy Google (проверено 10.08.2026)
https://cloud.google.com/gemini/docs/discover/data-governance — data governance Gemini API (проверено 10.08.2026)
https://yandex.cloud/ru/docs/yandexgpt — документация YandexGPT (проверено 13.09.2026)
https://developers.sber.ru — документация GigaChat API (проверено 10.08.2026)
https://owasp.org/www-project-top-10-for-large-language-model-applications/ — OWASP Top 10 for LLM, включая privacy-related риски (проверено 10.08.2026)