GDPR и приватность для инженеров

01Что считается персональными данными

Персональные данные — это любая информация, относящаяся к идентифицированному или идентифицируемому живому человеку. Имена и email — очевидный пример. Менее очевидные: IP-адреса, ID устройств, ID в cookie, история заказов, точки геолокации, записи голоса и логи чатов поддержки. Если данные можно связать с человеком — сами по себе или вместе с другими данными, которые вы реально можете получить, — они считаются персональными. Некоторые категории «особые» и требуют более сильного обоснования: здоровье, биометрические данные для идентификации, религия, политические взгляды, сексуальная ориентация, членство в профсоюзе, расовое или этническое происхождение, генетические данные. Псевдонимизированные данные, например ID пользователя в таблице аналитики, всё равно остаются персональными, потому что их можно повторно идентифицировать. Вне действия закона находятся только по-настоящему анонимизированные данные, где повторная идентификация практически невозможна, а настоящая анонимизация сложнее, чем кажется.

• Контролёр (controller): решает, зачем и как обрабатываются данные (обычно ваш клиент или компания).
• Обработчик (processor): обрабатывает данные по поручению контролёра (ваш хостинг, сервис email-рассылок или аналитики).
• Субъект данных (data subject): человек, к которому относятся данные.

02Принципы в переводе на язык инженерии

Статья 5 перечисляет принципы, которым должна следовать любая система, и каждый из них превращается в конкретные решения в дизайне. Законность, справедливость и прозрачность: у каждого использования есть законная причина, объяснённая в политике конфиденциальности. Ограничение цели: данные, собранные для доставки, нельзя тихо переиспользовать для несвязанного профилирования. Минимизация данных: не собирайте дату рождения, если вам нужно знать только то, что пользователь совершеннолетний. Точность: дайте пользователям исправлять свои данные. Ограничение хранения: удаляйте или анонимизируйте данные, когда их цель исчерпана, с помощью автоматических задач по сроку хранения. Целостность и конфиденциальность: шифрование, контроль доступа, логирование. Подотчётность: умейте показать, что вы делаете, — через документацию, реестры и журналы аудита. Статья 25 добавляет «защиту данных по умолчанию и при проектировании» (by design and by default): самый приватный вариант должен быть настройкой по умолчанию.

03Правовые основания и правильное согласие

Каждой операции обработки нужно одно из шести правовых оснований: согласие, договор, юридическая обязанность, жизненно важные интересы, публичная задача или законные интересы. Инженеры часто думают, что согласие нужно всегда, — это не так. Обработка заказа опирается на «договор». Хранение счетов — на «юридическую обязанность». Предотвращение мошенничества часто опирается на «законные интересы» после теста на баланс интересов. Согласие подходит для необязательных вещей вроде маркетинговых писем или неосновного трекинга, и оно должно быть свободным, конкретным, информированным и однозначным: никаких заранее проставленных галочек, никаких «используя этот сайт, вы соглашаетесь». Отозвать его должно быть так же легко, как дать. Для cookie и похожего хранения на устройстве отдельные правила ePrivacy требуют согласия на всё, что не является строго необходимым, поэтому cookie аналитики и рекламы ждут, пока пользователь не согласится.

1-- Store consent as an auditable event, never as a single boolean
2CREATE TABLE consent_events (
3  id           BIGSERIAL PRIMARY KEY,
4  user_id      BIGINT NOT NULL REFERENCES users(id),
5  purpose      TEXT NOT NULL,          -- 'marketing_email', 'analytics'
6  granted      BOOLEAN NOT NULL,       -- true = given, false = withdrawn
7  notice_version TEXT NOT NULL,        -- which privacy text the user saw
8  source       TEXT NOT NULL,          -- 'signup_form', 'settings_page'
9  created_at   TIMESTAMPTZ NOT NULL DEFAULT now()
10);
11-- Current state = latest event per (user_id, purpose)

04Права субъектов данных внутри продукта

У людей есть права, которые вы должны уметь соблюсти, обычно в течение одного месяца (с продлением ещё на два месяца для сложных запросов). Доступ: выдать копию их данных и информацию о том, как они используются. Исправление: дать исправить неточные данные. Удаление («право на забвение»): удалить данные, когда больше нет законной причины их хранить, сохранив то, что требует закон, например счета. Переносимость: предоставить данные, которые человек вам дал, в структурированном машиночитаемом формате вроде JSON или CSV. Возражение и ограничение: по запросу прекратить определённую обработку, например прямой маркетинг. С инженерной точки зрения это означает карту данных, которая знает каждую таблицу, бакет, лог и третью сторону, где лежат данные пользователя, плюс протестированные задачи выгрузки и удаления. Сначала проверьте личность запрашивающего, чтобы функция доступа не превратилась в утечку данных.

• Самостоятельная выгрузка и удаление в настройках аккаунта снижают нагрузку на поддержку.
• Удаление должно доходить до бэкапов, поисковых индексов, кэшей и обработчиков по известному графику.
• Логируйте каждый запрос и его выполнение ради подотчётности.

05Безопасность, утечки и 72 часа

GDPR требует «надлежащих технических и организационных мер» безопасности, оцениваемых по уровню риска. Типичные ожидания: шифрование при передаче (TLS) и при хранении, доступ по принципу наименьших привилегий, многофакторная аутентификация для сотрудников, журналы аудита доступа к персональным данным, безопасные практики разработки и проверенные бэкапы. Утечка персональных данных — это любой инцидент безопасности, ведущий к случайному или незаконному уничтожению, потере, изменению, раскрытию персональных данных или доступу к ним, и не только взлом: письмо не тому получателю тоже считается. Контролёр должен уведомить надзорный орган в течение 72 часов с момента, когда узнал об утечке, если только она вряд ли создаёт риск для людей, и обязан напрямую сообщить затронутым людям, когда риск высокий. Обработчики должны сообщить контролёру без неоправданной задержки. Каждую утечку, даже ту, о которой не сообщали, нужно задокументировать внутри компании.

06Подрядчики, трансграничная передача и важные документы

Каждый подрядчик, который обрабатывает для вас персональные данные — хостинг, отправка email, аналитика или трекинг ошибок, — является обработчиком, и с ним нужен договор об обработке данных (DPA, статья 28). Ведите их список; он же служит списком субобработчиков для ваших клиентов. Передача персональных данных за пределы Европейской экономической зоны (EEA) требует механизма передачи: решения об адекватности (включая EU-US Data Privacy Framework для сертифицированных американских компаний), стандартных договорных условий (SCC) или другого инструмента из главы V. Организации должны вести реестр операций обработки (статья 30), а для обработки с высоким риском, например масштабного мониторинга или чувствительных данных, до запуска нужна оценка воздействия на защиту данных (DPIA, статья 35). Инженеры редко пишут эти документы, но именно они дают факты: что собирается, где хранится, у кого есть доступ и как долго.

07Privacy by design в модели данных

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

1// Retention job: anonymise inactive guest orders after the retention period
2await db.order.updateMany({
3  where: {
4    userId: null,
5    createdAt: { lt: subMonths(new Date(), RETENTION_MONTHS) },
6    anonymisedAt: null,
7  },
8  data: {
9    guestEmail: null,
10    guestPhone: null,
11    shippingAddress: null,
12    anonymisedAt: new Date(),
13  },
14});

08Логи, observability и AI-инструменты

Логи — самое частое скрытое хранилище персональных данных. Логи запросов захватывают email, токены и IP-адреса; трекеры ошибок — содержимое форм; инструменты session replay могут записывать всё, что вводится. Настройте очистку у источника: используйте allow-list полей вместо block-list, маскируйте query string и задайте короткий срок хранения сырых логов. Относитесь к observability-подрядчикам как к обработчикам — с договорами и регионами, которые выбрали вы. То же касается AI-сервисов: отправка тикетов поддержки или документов пользователей в API большой языковой модели — это передача обработчику, поэтому проверьте условия обработки данных у подрядчика, сроки хранения, использование для обучения и регион, и вырезайте идентификаторы, когда задаче они не нужны.

09Трансграничная передача на практике

Глава V ограничивает передачу персональных данных за пределы EEA. Самый чистый путь — решение об адекватности: ЕС признал такие страны, как Великобритания, Швейцария, Япония и Южная Корея, а EU-US Data Privacy Framework покрывает американские компании, прошедшие самосертификацию; в 2025 году он выдержал первое оспаривание в Общем суде ЕС, хотя возможны дальнейшие апелляции. В остальных случаях обычный инструмент — стандартные договорные условия плюс оценка воздействия передачи (TIA). Инженерные решения уменьшают проблему: выбирайте регионы ЕС для основного хранения, проверяйте, откуда к данным обращаются поддержка и субобработчики, и не отправляйте сырые персональные данные в инструменты, которым они не нужны. Держите список подрядчиков и регионов актуальным, потому что клиенты будут спрашивать.

10Грядут изменения: следите за реформами

Законодательство о приватности не стоит на месте. В ноябре 2025 года Европейская комиссия предложила пакет «Digital Omnibus», который изменил бы части GDPR и правил о cookie; на момент написания (ноябрь 2026) часть о защите данных всё ещё обсуждается Парламентом и Советом, поэтому текущий текст GDPR действует без изменений. Национальные регуляторы тоже публикуют разъяснения, которые меняют практику, например по cookie-баннерам, псевдонимизации и законным интересам. Как инженер, стройте системы, которые легко адаптировать: настраиваемые сроки хранения, согласия с привязкой к целям, центральная карта данных и feature flags вокруг трекеров. Тогда при изменении правил вы меняете настройки, а не переписываете систему.