Legan Studio
Все статьи
~ 9 мин чтения

GDPR и международные клиенты бота в MAX: трансграничные данные

Что нужно знать о GDPR при разработке бота MAX с европейскими клиентами: согласие, право на удаление, DPA, трансграничная передача данных, штрафы.

  • MAX
  • GDPR
  • 152-ФЗ

Если у вашего бота в MAX есть пользователи из ЕС (или вы планируете выход на европейский рынок), вы автоматически попадаете под GDPR — европейский регламент защиты персональных данных. Штрафы — до 20 млн евро или 4% годового оборота. Российские владельцы ботов часто думают «нас не касается» — это ошибка: GDPR применяется к любому, кто обрабатывает данные жителей ЕС, независимо от расположения сервера. В этой статье — что нужно знать о GDPR при работе с международными клиентами через бот в MAX, как одновременно соответствовать GDPR и российскому 152-ФЗ, и какие технические и правовые шаги обязательны.

К кому применяется GDPR

GDPR применяется, если:

  • ваш бот предлагает товары/услуги жителям ЕС (даже бесплатно);
  • вы трекаете поведение пользователей в ЕС;
  • у вас есть представительство/сервер в ЕС.

«У меня российский бот в MAX, вряд ли там европейцы» — не работает: достаточно одного жителя ЕС среди пользователей, чтобы попасть под GDPR. Если он подаст жалобу в свой надзорный орган — штраф реален.

6 принципов GDPR

  1. Lawfulness — обработка только на законных основаниях (согласие, договор, законная обязанность, жизненные интересы, общественные интересы, легитимные интересы).
  2. Purpose limitation — данные собираются для конкретных целей, нельзя использовать «потом для других задач».
  3. Data minimization — только необходимые данные.
  4. Accuracy — данные актуальные, корректировка по запросу.
  5. Storage limitation — хранение только пока нужно для цели.
  6. Integrity and confidentiality — шифрование, доступ по необходимости.

Lawful basis для бота

Чаще всего — consent (явное согласие) или contract (для оказания услуг). Согласие должно быть:

  • свободным (нельзя «согласие = условие пользования сервисом», если данные не нужны для услуги);
  • информированным (что собираем, зачем, кому передаём);
  • конкретным (не «согласен со всем», а отдельные галочки на отдельные цели);
  • недвусмысленным (явное действие, не pre-checked checkbox);
  • документированным (можно доказать, кто и когда согласился).
@bot.callback_query_handler(lambda c: c.data == "gdpr:consent_yes")
async def on_gdpr_consent(call):
    await db.execute("""
        INSERT INTO gdpr_consents (user_id, scope, version, consented_at, ip)
        VALUES ($1, $2, $3, now(), $4)
    """, call.from_user.id, "service+marketing", PRIVACY_VERSION, call.from_user_ip)
    await proceed_with_service(call)

Хранить нужно: user_id, scope (что согласован), version политики, timestamp, IP/MAX-метаданные.

Right to erasure (right to be forgotten)

Пользователь может потребовать удаления всех своих данных. У вас есть 30 дней на ответ. Реализация:

@bot.message_handler(commands=["delete_my_data"])
async def on_delete(msg):
    request_id = await create_deletion_request(msg.from_user.id)
    await bot.send_message(msg.chat.id,
        f"Запрос на удаление #{request_id} принят. Удаление в течение 30 дней.\n"
        f"Запрос на самостоятельную обработку: privacy@example.com")

async def execute_deletion(user_id: int):
    # Анонимизация в исторических таблицах (для обязательной отчётности)
    await db.execute("UPDATE orders SET user_email = NULL, user_phone = NULL WHERE user_id = $1", user_id)
    # Удаление личных данных
    await db.execute("DELETE FROM user_profile WHERE user_id = $1", user_id)
    await db.execute("DELETE FROM messages WHERE user_id = $1", user_id)
    # Файлы в S3
    files = await list_s3_files(user_id)
    for f in files: s3.delete_object(Bucket=BUCKET, Key=f.key)
    # Из бэкапов — политика retention < 90 дней или явное удаление
    await mark_deletion_complete(user_id)

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

Right to data portability

Пользователь может запросить выгрузку всех своих данных в машиночитаемом формате (JSON/CSV):

@bot.message_handler(commands=["export_my_data"])
async def on_export(msg):
    data = {
        "profile": await db.fetch_one("SELECT * FROM user_profile WHERE user_id = $1", msg.from_user.id),
        "orders": await db.fetch_all("SELECT * FROM orders WHERE user_id = $1", msg.from_user.id),
        "messages": await db.fetch_all("SELECT * FROM messages WHERE user_id = $1", msg.from_user.id),
        "files": await list_user_files(msg.from_user.id),
    }
    payload = json.dumps(data, default=str, ensure_ascii=False, indent=2).encode()
    await bot.send_document(msg.chat.id, document=payload, filename=f"my_data_{msg.from_user.id}.json")

Срок — те же 30 дней максимум, но автоматизация позволяет отдавать сразу.

Трансграничная передача данных

GDPR разрешает передачу за пределы ЕС только при наличии:

  • решения Еврокомиссии о признании adequate (Россия — не в списке);
  • стандартных договорных условий (SCC) — на 2026 год это standard contractual clauses 2021/914;
  • BCR (binding corporate rules) для крупных корпораций;
  • explicit derogation (явное согласие пользователя на конкретную передачу).

В реальности для российского бота с EU-пользователями — explicit consent на трансграничную передачу с указанием страны и LLM/CRM, которым передаются данные.

DPA (Data Processing Agreement)

Если вы используете third-party (Yandex Cloud, Selectel, OpenAI, GigaChat) — нужен DPA с каждым: договор о порядке обработки. У крупных провайдеров есть готовые DPA, подписываемые в личном кабинете. Для российских провайдеров — обычно отдельным приложением к договору.

Российский 152-ФЗ vs GDPR

Сходства:

  • согласие на обработку;
  • право на удаление;
  • ответственность оператора.

Различия:

  • 152-ФЗ требует уведомления в РКН до начала обработки; GDPR — нет такой обязанности (только DPIA для рисковых).
  • 152-ФЗ требует хранения персональных данных российских граждан в РФ; GDPR требует «адекватного уровня защиты» при трансграничной передаче.
  • Штрафы: 152-ФЗ — до 700 тыс. ₽ (повторно — до 18 млн); GDPR — до 20 млн евро или 4% оборота.

Для бота с пользователями из РФ и ЕС нужны оба комплекса требований одновременно.

DPIA (Data Protection Impact Assessment)

Для рисковых обработок (биометрия, профилирование, large-scale spec categories) GDPR требует провести оценку защиты. Для бота это актуально, если:

  • используете facial recognition;
  • автоматизированно принимаете решения с правовыми последствиями (отказ в кредите, найм);
  • обрабатываете данные о здоровье, расе, политических взглядах.

DPIA — отдельный документ с описанием рисков и мер. Для типичного маркетингового бота не требуется.

Privacy by design

Это фундаментальный принцип GDPR: защита данных встроена в систему с самого начала, а не «прикручена потом». Практические шаги:

  • minimize collection: спрашивайте только необходимое;
  • pseudonymization: внутри системы используйте user_id, а не email;
  • encryption at rest и in transit;
  • access controls: принцип least privilege;
  • audit logs: кто, когда, какие данные смотрел;
  • regular reviews: раз в полгода оценка процессов.

В мессенджере cookie нет, но есть аналог — UTM-метки в deep links и идентификация пользователя. Для GDPR:

  • если трекаете пользователей ЕС для маркетинга — нужно отдельное согласие;
  • если используете Yandex.Metrika / Google Analytics — IP анонимизация, согласие;
  • список cookie/трекеров в Privacy Policy.

Privacy Policy: что должно быть

Минимум:

  1. Кто оператор (юр. лицо, ИНН, контакт DPO/ответственного).
  2. Какие данные собираем (категории).
  3. Цели обработки.
  4. Правовые основания (GDPR Art. 6).
  5. Кому передаём (партнёры, third-party с указанием стран).
  6. Срок хранения.
  7. Права пользователя (доступ, исправление, удаление, портация, возражение).
  8. Контакты для запросов.
  9. Право на жалобу в надзорный орган (для ЕС — указывается).

Реакция на data breach

При утечке ПДн — уведомление надзорного органа в течение 72 часов и пользователей «без неоправданной задержки», если есть высокий риск. План действий:

  1. Определить scope (что утекло, чьё, как).
  2. Остановить утечку.
  3. Уведомить надзорный орган (через форму на сайте).
  4. Уведомить пользователей.
  5. Задокументировать инцидент (incident report).

Без подготовленного incident response plan компании регулярно срывают 72-часовое окно и получают повышенный штраф.

Common pitfalls

  1. Считают «GDPR не про нас» — пока не получают жалобу.
  2. Pre-checked согласие — невалидно по GDPR.
  3. Один общий «accept all» — нужны отдельные согласия по целям.
  4. Удаление только из «горячих» таблиц — забывают про бэкапы, аналитику, S3.
  5. Нет DPA с провайдерами — каждый сторонний сервис должен быть охвачен.
  6. Хранение «на всякий случай» — нарушение storage limitation.

Итого

GDPR применяется к любому боту в MAX, у которого есть пользователи из ЕС, независимо от страны разработчика. Ключевые требования: явное согласие на обработку с фиксацией версии политики и timestamp, право на удаление в 30 дней с реальной зачисткой во всех системах (БД, S3, бэкапы, аналитика), право на data portability через экспорт в JSON/CSV, DPA с каждым third-party провайдером, для трансграничной передачи в РФ — explicit consent или SCC, уведомление о data breach в 72 часа. Параллельно соблюдайте 152-ФЗ (хранение ПДн россиян на серверах РФ, уведомление РКН). Privacy Policy с обязательным набором разделов, privacy by design в архитектуре. Штрафы GDPR до 20 млн евро мотивируют относиться к этому серьёзно с первого дня.

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

Должен ли я соблюдать GDPR, если мой бот в MAX и я в России?

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

Как реализовать right to erasure (право на удаление)?

Команда /delete_my_data в боте создаёт запрос на удаление с дедлайном 30 дней. Скрипт удаляет данные из всех систем: основная БД (DELETE из user_profile, messages), исторические таблицы (анонимизация полей, которые обязаны хранить — orders.user_email = NULL), файлы в S3 (delete_object), кеши Redis. Для бэкапов — политика retention ≤ 90 дней или ручное удаление по запросу. Аналитика (Yandex Metrika, GA) — удаление через их API. После завершения — уведомление пользователю и фиксация в audit log даты исполнения.

Что такое DPA и нужен ли он мне?

DPA (Data Processing Agreement) — договор между controller (вы, как оператор) и processor (third-party провайдер: Yandex Cloud, OpenAI, GigaChat, ЮKassa), регламентирующий обработку персональных данных. По GDPR Art. 28 обязателен с каждым third-party, обрабатывающим ПДн ваших пользователей. У крупных провайдеров есть готовые DPA, подписываемые в личном кабинете. Без DPA — нарушение GDPR с штрафом, даже если провайдер технически безопасен.

Как одновременно соблюдать GDPR и 152-ФЗ?

Главное противоречие: 152-ФЗ требует хранения ПДн россиян в РФ, а GDPR требует «адекватного уровня защиты» при передаче за пределы ЕС. Для бота с обоими аудиториями — две отдельных БД (или схемы): российские пользователи в Yandex Object Storage / Selectel, европейские — в EU-провайдере (например, Hetzner Frankfurt). Сегментация на уровне tenant_id или region. LLM: для российских пользователей — GigaChat/YandexGPT (РФ), для европейских — европейский endpoint OpenAI или Mistral. Это удваивает инфраструктурные затраты, но юридически корректно.

Какие штрафы за нарушение GDPR?

До 20 млн евро или 4% годового мирового оборота — что больше. На практике для среднего бизнеса штрафы 50K – 5M евро. Самые частые причины: отсутствие согласия (или невалидное согласие), неисполнение запроса на удаление, утечки данных без уведомления в 72 часа, отсутствие DPA с third-party. Известные кейсы: Meta — 1.2 млрд евро (2023), Amazon — 746 млн евро (2021), TikTok — 345 млн евро (2023). Для маленького бота вероятный штраф — 50–500K евро при первом нарушении, но это всё равно может разорить.

Что такое privacy by design и как его реализовать?

Принцип: защита данных встроена в систему с самого начала, а не добавлена потом. Практически: минимизация сбора (не запрашивайте email, если не нужен), псевдонимизация (внутри системы используйте user_id, не email), шифрование at rest (PostgreSQL + pgcrypto или приложением AES-256) и in transit (HTTPS only), access controls (least privilege для сервисов и людей), audit logs (кто и когда смотрел персональные данные), регулярные reviews процессов раз в полгода. Это не один-разовая работа, а постоянная практика.

Что должно быть в Privacy Policy для бота MAX?

Минимум: кто оператор (юр. лицо, ИНН, контакт DPO для GDPR / ответственного по 152-ФЗ), какие данные собираем (категории), цели обработки, правовые основания (по GDPR Art. 6 и по 152-ФЗ), кому передаём (партнёры с указанием стран), срок хранения каждого типа данных, права пользователя (доступ, исправление, удаление, портация, возражение, отзыв согласия), контакты для запросов, право на жалобу в надзорный орган (для ЕС — указать европейские DPA). Отдельная страница на сайте + ссылка в боте через /privacy. Версионирование с датой последнего обновления — обязательно.