Schrems II и пиксели отслеживания: где нас оставляет DPF в 2026 году

В июле 2020 года CJEU вынес решение по делу Schrems II (C-311/18). Privacy Shield, который был механизмом по умолчанию для передачи данных между ЕС и США с 2016 года, был признан недействительным. В одночасье каждая маркетинговая команда, использующая Meta Pixel или Google Tag, либо передавала данные без действующего правового механизма, либо лихорадочно пыталась внедрить Стандартные договорные условия (SCCs), либо полагалась на надежду, что GDPR каким-то образом не распространяется на фрагмент JavaScript в браузере пользователя.

Последовали три года руководств по дополнительным мерам, шаблонов Оценки влияния передачи данных (TIA) и принудительных действий надзорных органов. Затем, в июле 2023 года, Европейская комиссия приняла решение об адекватности EU-US Data Privacy Framework, восстановив адекватность для сертифицированных DPF компаний из США. Meta, Google, Salesforce и HubSpot - все они есть в списке.

Вопрос для маркетинговых и комплаенс-команд в 2026 году заключается не в том, существует ли DPF - он существует. Вопрос в том, что он на самом деле охватывает, где остаются остаточные риски и как на практике выглядит архитектура передачи данных, способная выстоять перед лицом потенциального оспаривания DPF.

TL;DR#

• Privacy Shield (2016) был признан недействительным решением Schrems II в июле 2020 года. Стандартные договорные условия (SCCs) вместе с дополнительными мерами закрывали этот пробел с 2020 по 2023 год.
• EU-US Data Privacy Framework (июль 2023 г.) является текущим решением об адекватности. Передача данных компаниям, сертифицированным DPF, пользуется преимуществом адекватности без необходимости использования SCCs или проведения TIA.
• Пиксели на стороне клиента для вендоров, сертифицированных DPF, юридически оправданы в 2026 году при условии, что принимающая сторона сертифицирована, субъект данных проинформирован и получено согласие в соответствии с ePrivacy, где это необходимо.
• Ожидается, что DPF будет оспорен в суде. Атрибуция через Elido с использованием двухрежимного отслеживания - на стороне клиента под защитой DPF и серверная пересылка из инфраструктуры ЕС в качестве структурного резервного варианта - это архитектура, которая переживет третье решение Schrems.

Что на самом деле сказано в решении Schrems II#

Решение стоит прочитать напрямую, а не в кратком изложении. Основная аргументация содержится в пунктах 180–202. Главный вывод заключается не в том, что передача данных в США сама по себе незаконна. Речь идет о том, что законодательство США о слежке - в частности, FISA 702 и Executive Order 12333 - дает разведывательным службам США доступ к персональным данным субъектов из ЕС таким образом, который не обеспечивает этим субъектам эффективных средств правовой защиты в соответствии со Статьями 77–79 GDPR.

Статья 44 GDPR запрещает передачу данных в третьи страны, если не применяется один из механизмов Главы V. Privacy Shield был решением об адекватности согласно Статье 45. Вывод Суда о недействительности Privacy Shield лишил основания адекватности каждую передачу данных, опирающуюся на него.

Стандартные договорные условия (SCCs) не были аннулированы - но Суд в том же решении постановил, что SCCs не являются автоматически достаточными для передачи данных в США. Контролер или процессор, использующий SCCs, должен в каждом конкретном случае проверять, не помешает ли правовая система страны назначения защите на уровне SCCs на практике. Это требование и есть Оценка влияния передачи данных (Transfer Impact Assessment, TIA): задокументированная оценка законодательства США о слежке и его влияния на передаваемые данные.

Рекомендации EDPB 01/2020 по дополнительным мерам ввели это требование в действие. Они определили шестиэтапный процесс и каталог дополнительных мер - технических (шифрование, псевдонимизация), договорных и организационных - которые контролеры должны оценивать при использовании SCCs для передачи данных в США. Для стандартных маркетинговых пикселей большинство этих технических мер были практически невозможны: вы не можете значимо зашифровать пакет данных, целью которого является позволить Meta приписать конверсию показу рекламы.

Это архитектура, в которой маркетинговые команды жили с июля 2020 по июль 2023 года. Были подписаны SCCs. Предпринимались попытки провести TIA. Надзорные органы в Австрии, Франции и Италии признали конкретные реализации - в первую очередь Google Analytics - несоответствующими требованиям, несмотря на SCCs, поскольку дополнительных мер было недостаточно.

Что изменилось с появлением Data Privacy Framework#

EU-US Data Privacy Framework (Решение Комиссии (EU) 2023/1795, вступившее в силу 10 июля 2023 г.) является решением об адекватности согласно Статье 45 GDPR. Его правовая предпосылка заключается в том, что законодательная база США - с поправками, внесенными Указом президента Байдена 14086, и последующими правилами, устанавливающими Суд по пересмотру защиты данных - обеспечивает уровень защиты, по существу эквивалентный уровню, гарантированному в ЕС.

Для практических целей DPF означает следующее: передача данных сертифицированным DPF американским компаниям пользуется преимуществом адекватности. Вам не нужны SCCs. Вам не нужна TIA. Вам необходимо убедиться, что принимающая организация включена в список участников DPF, который является публичным, доступным для поиска и обновляется практически в режиме реального времени.

Meta Platforms, Inc. сертифицирована по DPF. Google LLC сертифицирована по DPF. Salesforce, Inc. сертифицирована по DPF. HubSpot, Inc. сертифицирована по DPF. Для этих вендоров передача персональных данных из ЕС в связи с рекламой и аналитикой охватывается адекватностью по состоянию на июль 2023 года, при условии, что они получают данные в своем качестве, сертифицированном по DPF.

Важны два уточнения. Во-первых, сертификация DPF является добровольной. Не каждая американская компания, обрабатывающая данные из ЕС, прошла самосертификацию. Список участников является авторитетным источником; не предполагайте наличие сертификации автоматически. Во-вторых, сертификация DPF охватывает конкретные виды деятельности. Компания, сертифицированная по DPF, может обрабатывать данные вашего пикселя в рамках сертифицированной области или на другом законном основании в зависимости от типа и цели данных. Для стандартной маркетинговой атрибуции через пиксель область действия DPF это покрывает.

Что это значит для маркетинговых пикселей на практике#

С учетом покрытия DPF правовая позиция для клиентских маркетинговых пикселей сертифицированных вендоров выглядит следующим образом.

Клиентский Meta Pixel при передаче данных в Meta Platforms Inc. (сертифицирована по DPF) является передачей в адекватную страну назначения. Механизмом передачи является решение об адекватности DPF, а не SCCs. Ваша запись в Реестре процессов обработки (RoPA) согласно Статье 30 для Meta Pixel документирует основание передачи как «решение об адекватности (DPF)», а не «SCCs». TIA, которая потребовалась бы при использовании пути SCCs, не требуется.

Тот же анализ применим к Google Tag Manager и GA4, передающим данные в Google LLC, отслеживающему пикселю HubSpot, передающему данные в HubSpot Inc., и событиям атрибуции Salesforce Marketing Cloud, передающим данные в Salesforce Inc.

Однако адекватность - это лишь один уровень многоуровневой картины комплаенса. Прежде чем эта позиция станет устойчивой, должны быть выполнены три дополнительных требования.

Согласие в соответствии с ePrivacy. Директива ePrivacy 2002/58/EC, Статья 5(3), требует получения согласия перед любым второстепенным хранением или доступом к оконечному оборудованию пользователя. Маркетинговые пиксели не являются обязательными. Баннеры согласия должны относиться конкретно к данному пикселю, согласие должно быть дано добровольно и быть отзывным. Тот факт, что место передачи данных является адекватным согласно DPF, не влияет на требование согласия ePrivacy. Это отдельные правовые инструменты.

Прозрачность для субъектов данных. Статья 13 GDPR требует, чтобы контролер информировал субъектов данных во время сбора данных о получателях их данных и любой передаче в третьи страны. DPF не меняет это обязательство по обеспечению прозрачности. Если в вашем уведомлении о конфиденциальности указано: «мы используем Meta Pixel» и «передача данных в США покрывается адекватностью», этого достаточно. Если в нем вообще не упоминается передача данных в США, решение об адекватности не устраняет пробел по Статье 13.

DPA по Статье 28 с вендором. Поставщик пикселей остается процессором в соответствии со Статьей 28 GDPR. DPF охватывает механизм передачи; он не заменяет DPA. Стандартные условия обработки данных Meta, Google и HubSpot являются инструментами Статьи 28 для отношений по использованию пикселей. Убедитесь, что они подписаны.

Оставшиеся риски#

DPF не является окончательным решением. Это решение об адекватности, которое может быть оспорено в CJEU любым судом государства-члена, Европейским парламентом или любым национальным надзорным органом. Макс Шремс и NOYB публично заявили о намерении оспорить DPF - потенциальный Schrems III. Правовая теория этого оспаривания аналогична Schrems II: EO 14086 и Data Protection Review Court по существу не предоставляют средств правовой защиты, эквивалентных тем, которые доступны в соответствии с законодательством ЕС.

Надзорные органы не стали ждать решения CJEU. Австрийский DSB вынес решение в отношении реализации Google Analytics совсем недавно, в 2022 году - до вступления в силу DPF - о том, что передача была незаконной, поскольку SCCs и принятые дополнительные меры были недостаточны. Французский CNIL и итальянский Garante вынесли аналогичные заключения. Эти решения были приняты в рамках режима, предшествовавшего DPF, но они устанавливают закономерность надзора: надзорные органы готовы изучать техническую механику передачи данных через пиксели, а не только договорные документы. Будущее решение по делу против DPF, вероятно, будет изучать, действительно ли правовой порядок, установленный EO 14086, ограничивает доступ FISA 702 к сохраненным данным сертифицированных компаний.

Специфическая проблема с пикселями отслеживания выходит за рамки юридического механизма. Пиксель на стороне клиента делает больше, чем просто передает данные сертифицированной компании. Он выполняет JavaScript в браузере пользователя, устанавливает собственные и сторонние куки в контексте домена пикселя и отправляет данные напрямую из браузера. Данные, покидающие браузер, находятся вне вашего контроля - вы не можете применить хеширование идентификаторов до их отправки, не можете ограничить заполнение полей и не можете проверить, что пиксель на самом деле отправляет во время выполнения, без проверки сети. Адекватность DPF распространяется на пункт назначения; она не касается того, что пиксель собирает перед передачей.

Это сочетание - потенциальное оспаривание DPF, пристальное внимание надзорных органов к механике, а не только к документам, и структурные ограничения того, что контролер может проверить в поведении пикселя на стороне клиента - именно поэтому одноканальная стратегия на стороне клиента остается архитектурно хрупкой.

Практическая позиция: двухрежимное отслеживание#

Архитектура, которая сохраняет устойчивость как при наличии DPF, так и в случае его потенциальной отмены, является двухрежимной.

Первый режим - это пиксели на стороне клиента, передающие данные сертифицированным по DPF вендорам, работающие в рамках текущей адекватности при наличии согласия ePrivacy. Это обеспечивает максимально широкий сигнал атрибуции до тех пор, пока действует DPF. Для большинства маркетинговых команд это тот режим, который сегодня наполняет ваши дашборды атрибуции.

Второй режим - серверная пересылка конверсий из инфраструктуры ЕС. Когда пользователь переходит по ссылке, узел Elido в регионе ЕС принимает клик, регистрирует его в нашем аналитическом хранилище в ЕС и пересылает сигнал конверсии с сервера на сервер в API рекламной платформы - Meta CAPI, GA4 Measurement Protocol или эквивалент. Браузер пользователя не связывается с конечной точкой в США. Данные, покидающие инфраструктуру ЕС, были хешированы (SHA-256 для адресов электронной почты и номеров телефонов, как того требует Meta CAPI), и передача инициируется из инфраструктуры под вашим контролем, а не из кода, работающего в браузере пользователя.

Если DPF будет признан недействительным, пиксель на стороне клиента станет несоответствующим механизмом передачи до тех пор, пока не будет создана заменяющая его база. Серверный путь, работающий через SCCs с применением дополнительных мер - зашифрованный при транзите, с хешированием идентификаторов до отправки, узко ограниченный сигналом атрибуции - является резервным вариантом, который ваша юридическая команда может защитить с помощью последовательной TIA. Поскольку серверный путь сначала обрабатывает данные в инфраструктуре ЕС, передача может быть задокументирована как отношение контролер-процессор, а не как прямая передача из браузера в конечную точку в США.

Где это возможно, отдавайте предпочтение конечной точке вендора в ЕС. GA4 с data_collection_endpoint, направленной на region1.google-analytics.com, оставляет больше процессов обработки в инфраструктуре Google в ЕС, хотя некоторая обработка все же происходит в инфраструктуре США согласно собственной документации Google. Meta CAPI в настоящее время не предлагает конечную точку в регионе ЕС; передача с сервера на сервер в любом случае направлена в США. Дополнительной мерой здесь является хеширование идентификаторов, а не география конечной точки.

Для подробного изучения механики пути серверной пересылки и того, как она интегрируется с атрибуцией кликов по коротким ссылкам, объяснение атрибуции без куки охватывает техническую архитектуру. Для более широкой картины резидентности в ЕС - где «хостинг в ЕС» начинается и заканчивается в стеке маркетинговых инструментов - EU-резидентность данных для маркетинга является сопутствующим постом.

Согласие на использование субпроцессоров в рамках DPF#

Каждый сертифицированный по DPF поставщик пикселей по-прежнему является процессором в соответствии со Статьей 28 GDPR. Решение об адекватности DPF охватывает механизм передачи; оно ничего не говорит об обязательствах процессора, которые применяются параллельно.

Это означает, что контролеру необходимо иметь Соглашение об обработке данных (DPA) с каждым поставщиком пикселей, охватывающее обязательства по Статье 28(3)(a)-(h). Стандартные условия Meta для рекламных данных, дополнение об обработке данных Google и DPA HubSpot являются инструментами здесь. Они предварительно подписаны и включены путем отсылки, когда вы соглашаетесь с условиями обслуживания вендора; вопрос в том, задокументировали ли вы это соглашение в своих записях о комплаенсе.

Список субпроцессоров, о котором спросит ваш DPO, включает этих вендоров. Каждый поставщик пикселей становится субпроцессором в цепочке атрибуции между вашей платформой отслеживания ссылок и рекламной платформой. В публичном списке субпроцессоров Elido названы пять его вендоров; поставщики пикселей являются субпроцессоров на уровне контролера, а не на уровне Elido. В вашем RoPA по Статье 30 они должны быть перечислены отдельно.

Один нюанс: Статья 28(2) GDPR требует, чтобы процессор получил разрешение контролера перед привлечением субпроцессоров. В отношениях по пикселям вы являетесь контролером, привлекающим Meta или Google напрямую - это отношения контролер-процессор, а не цепочка субпроцессоров через Elido. DPA по Статье 28 заключается между вами и поставщиком пикселя. Серверная часть пересылки - где узел Elido пересылает события в Meta CAPI от вашего имени - является отношениями с субпроцессором: Elido - это процессор, Meta CAPI - это субпроцессор, и обязательство по DPA вытекает из стандартного DPA Elido.

Это различие имеет значение для вашего RoPA. Команда комплаенса, проверяющая ваши записи, хочет видеть две отдельные записи: одну для отношений с процессором Elido (охватывающую события кликов на уровне ссылок) и по одной для каждого поставщика пикселей (охватывающую данные атрибуции на стороне браузера). Их смешивание приводит к записи в RoPA, которая не является точной ни в одном из направлений.

Для ознакомления с полным списком обязательств процессора по статьям GDPR, GDPR для сокращателей ссылок является краеугольным постом в этом кластере.

Чек-лист DPO по закупкам у поставщиков пикселей#

Пять вопросов, которые следует задать каждому поставщику пикселей отслеживания при закупке. Они написаны для проверки в эпоху DPF; скорректируйте вопрос о механизме передачи, если статус DPF изменился к моменту вашего прочтения.

1. Включена ли ваша компания в настоящее время в список участников DPF и какие виды деятельности охватывает ваша сертификация?

Список находится по адресу dataprivacyframework.gov. Запрашивайте конкретную область сертификации, а не общее «да, мы сертифицированы». Сертификация привязана к деятельности; вендор может быть сертифицирован по DPF для данных о персонале, но не для коммерческих данных об атрибуции кликов.

2. Где на самом деле хранятся данные, которые я отправляю через пиксель, и есть ли конечная точка в регионе ЕС, которую я могу использовать?

DPF охватывает передачу сертифицированному получателю в США. Если доступна конечная точка в регионе ЕС, ее использование снижает риски передачи и может повлиять на анализ TIA, если DPF позже будет оспорен. Задокументируйте ответ в вашей записи RoPA.

3. Каково ваше стандартное Соглашение об обработке данных (DPA) и охватывает ли оно явно обязательства по Статье 28(3)(a)-(h)?

Предварительно подписанные DPA, включенные путем отсылки в условия обслуживания, допустимы; вам нужно знать, что DPA существует и где его найти. DPA регулирует отношения процессора независимо от механизма передачи.

4. Как вы обрабатываете запросы субъектов данных на реализацию их прав - в частности, на удаление согласно Статье 17 - для данных, собранных пикселем?

Для пикселей на стороне клиента удаление обычно обрабатывается средствами контроля конфиденциальности платформы (Центр конфиденциальности Meta, Мой центр объявлений Google). Задокументируйте процесс, чтобы вы могли ответить на запрос субъекта данных без импровизации.

5. Если DPF будет признан недействительным, какой резервный механизм передачи вы предложите и в какие сроки?

Этот вопрос проверяет, есть ли у вендора план на случай непредвиденных обстоятельств. При переходе от Privacy Shield к SCCs (2020–2021 гг.) некоторые вендоры медлили с обновлением своих соглашений. Вендор, который уже задокументировал SCCs в качестве запасного варианта при отмене DPF - с указанием дополнительных мер - проделал эту работу. Вендор, который говорит «мы обновим наш DPA, когда это станет необходимо», - нет.

Для реализации, специфичной для Elido: серверная пересылка конверсий доступна уже сегодня с хешированием идентификаторов SHA-256 до того, как любые данные покинут инфраструктуру ЕС. Конфигурация задается для каждого рабочего пространства и задокументирована в стандартном DPA по адресу /legal/dpa. Если ваша толерантность к рискам DPF низка, серверный путь доступен в качестве основного механизма пересылки, а не только резервного.