Schrems II i piksele śledzące: gdzie stawia cię DPF w 2026 roku

W lipcu 2020 roku TSUE wydał orzeczenie w sprawie Schrems II (C-311/18). Privacy Shield, który od 2016 roku był domyślnym mechanizmem transferów danych UE-USA, został unieważniony. Z dnia na dzień każdy zespół marketingowy używający Meta Pixel lub Google Tag albo dokonywał transferu danych bez ważnego mechanizmu prawnego, albo gorączkowo podpisywał Standardowe Klauzule Umowne, albo opierał się na życzeniowej interpretacji, że RODO jakoś nie obejmuje fragmentu JavaScript w przeglądarce użytkownika.

Przez trzy lata pojawiały się wytyczne dotyczące środków uzupełniających, szablony ocen skutków transferu (TIA) i działania egzekucyjne organów nadzorczych. Następnie, w lipcu 2023 roku, Komisja Europejska przyjęła decyzję o adekwatności w ramach Transatlantyckiego partnerstwa w dziedzinie ochrony danych UE-USA, przywracając adekwatność dla certyfikowanych przez DPF firm amerykańskich. Meta, Google, Salesforce i HubSpot - wszystkie są na liście.

Pytanie dla zespołów marketingowych i compliance w 2026 roku nie brzmi „czy DPF istnieje" - istnieje. Pytanie dotyczy tego, co tak naprawdę obejmuje, gdzie leży rezydualne ryzyko i jak wygląda architektura transferu, która przetrwa ewentualne zaskarżenie DPF.

TL;DR#

• Privacy Shield (2016) został unieważniony przez Schrems II w lipcu 2020 roku. SCC oraz środki uzupełniające pokrywały lukę od 2020 do 2023 roku.
• Transatlantyckie ramy ochrony prywatności danych UE-USA (lipiec 2023) to aktualna decyzja o adekwatności. Transfery do firm certyfikowanych przez DPF korzystają z adekwatności bez konieczności stosowania SCC lub TIA.
• Piksele po stronie klienta do dostawców certyfikowanych przez DPF są prawnie uzasadnione w 2026 roku, pod warunkiem że podmiot odbierający jest certyfikowany, podmiot danych został poinformowany i tam, gdzie jest wymagana, uzyskano zgodę wymaganą przez dyrektywę ePrivacy.
• DPF jest przedmiotem spodziewanego zaskarżenia prawnego. Śledzenie dwutorowe - po stronie klienta pod ochroną DPF, przekazywanie serwerowe z infrastruktury UE jako strukturalny fallback - to architektura, która przetrwa ewentualny trzeci wyrok Schremsa.

Co faktycznie powiedział Schrems II#

Wyrok warto przeczytać bezpośrednio, a nie przez streszczenia. Operatywne rozumowanie zawarte jest w paragrafach 180–202. Kluczowe ustalenie nie jest takie, że transfery danych do USA są per se nielegalne. Polega ono na tym, że prawo dotyczące nadzoru w USA - konkretnie FISA 702 i Rozporządzenie Wykonawcze 12333 - daje amerykańskim służbom wywiadowczym dostęp do danych osobowych obywateli UE w sposób, który nie zapewnia tym osobom skutecznych środków odwoławczych na mocy art. 77–79 RODO.

Art. 44 RODO zakazuje transferów do państw trzecich, chyba że zastosowanie ma jeden z mechanizmów Rozdziału V. Privacy Shield był decyzją o adekwatności na mocy art. 45. Ustalenie przez Trybunał, że Privacy Shield jest nieważny, pozbawiło podstawy adekwatności każdy transfer, który na nim opierał.

Standardowe Klauzule Umowne nie zostały unieważnione - jednak Trybunał stwierdził w tym samym wyroku, że SCC nie są automatycznie wystarczające dla transferów do USA. Administrator lub podmiot przetwarzający korzystający z SCC musi zweryfikować, dla każdego przypadku z osobna, czy system prawny kraju docelowego uniemożliwiłby funkcjonowanie ochrony przewidzianej w SCC. Ten wymóg to właśnie Ocena Skutków Transferu: udokumentowana ocena prawa dotyczącego nadzoru w USA i jego wpływu na przekazywane dane.

Zalecenia 01/2020 EROD w sprawie środków uzupełniających operacjonalizowały ten wymóg. Określają one sześcioetapowy proces i katalog środków uzupełniających - technicznych (szyfrowanie, pseudonimizacja), umownych i organizacyjnych - które administratorzy powinni ocenić przy stosowaniu SCC dla transferów do USA. Dla standardowych pikseli marketingowych większość tych środków technicznych była praktycznie niemożliwa do zastosowania: nie można w sensowny sposób zaszyfrować ładunku, którego celem jest umożliwienie Meta przypisania konwersji do wyświetlenia reklamy.

Taka architektura towarzyszyła zespołom marketingowym od lipca 2020 do lipca 2023 roku. Podpisywano SCC. Podejmowano próby sporządzenia TIA. Organy ochrony danych w Austrii, Francji i Włoszech uznały konkretne implementacje - przede wszystkim Google Analytics - za niezgodne z prawem pomimo SCC, ponieważ środki uzupełniające były niewystarczające.

Co zmieniło się wraz z Ramami Ochrony Prywatności Danych#

Transatlantyckie Ramy Ochrony Prywatności Danych UE-USA (Decyzja Komisji (UE) 2023/1795, obowiązująca od 10 lipca 2023 roku) to decyzja o adekwatności na mocy art. 45 RODO. Jej prawna przesłanka jest taka, że ramy prawne USA - zmienione przez Rozporządzenie Wykonawcze 14086 Prezydenta Bidena oraz późniejsze przepisy ustanawiające Sąd ds. Przeglądu Ochrony Danych - zapewniają zasadniczo równoważny poziom ochrony jak ten gwarantowany w UE.

Dla celów praktycznych DPF oznacza: transfery do firm certyfikowanych przez DPF korzystają z adekwatności. Nie potrzebujesz SCC. Nie potrzebujesz TIA. Musisz zweryfikować, czy podmiot odbierający figuruje na liście uczestników DPF, która jest publicznie dostępna i aktualizowana niemal w czasie rzeczywistym.

Meta Platforms, Inc. jest certyfikowana przez DPF. Google LLC jest certyfikowana przez DPF. Salesforce, Inc. jest certyfikowana przez DPF. HubSpot, Inc. jest certyfikowana przez DPF. Dla tych dostawców transfery danych osobowych z UE w związku z reklamami i analityką są objęte adekwatnością od lipca 2023 roku, o ile otrzymują dane w ramach swojej certyfikowanej przez DPF działalności.

Dwa wyjaśnienia mają znaczenie. Po pierwsze, certyfikacja DPF jest dobrowolna. Nie każda firma z USA przetwarzająca dane z UE dokonała samo-certyfikacji. Lista uczestników jest miarodajnym źródłem; nie zakładaj certyfikacji. Po drugie, certyfikacja DPF obejmuje konkretne działania. Firma certyfikowana przez DPF może przetwarzać dane z twojego piksela w ramach certyfikowanego zakresu lub na innej podstawie prawnej, w zależności od rodzaju danych i celu. W przypadku standardowej atrybucji marketingowej za pomocą piksela zakres DPF to obejmuje.

Co to oznacza w praktyce dla pikseli marketingowych#

Z ochroną DPF w miejscu, prawna pozycja w odniesieniu do pikseli marketingowych po stronie klienta do certyfikowanych dostawców wygląda następująco.

Piksel Meta po stronie klienta, gdy wysyła dane do Meta Platforms Inc. (certyfikowanej przez DPF), to transfer do właściwego miejsca docelowego. Mechanizmem transferu jest decyzja o adekwatności DPF, a nie SCC. W rejestrze czynności przetwarzania zgodnie z art. 30 przy Meta Pixel dokumentujesz podstawę transferu jako „decyzja o adekwatności (DPF)", a nie „SCC". TIA, który byłby wymagany przy ścieżce SCC, nie jest wymagany.

Ta sama analiza dotyczy Google Tag Manager i GA4 wysyłającego dane do Google LLC, piksela śledzącego HubSpot wysyłającego do HubSpot Inc. oraz zdarzeń atrybucji Salesforce Marketing Cloud wysyłanych do Salesforce Inc.

Jednak adekwatność to tylko jedna warstwa wielowarstwowego obrazu zgodności. Trzy dodatkowe wymagania muszą być spełnione, zanim ta pozycja prawna będzie solidna.

Zgoda ePrivacy. Dyrektywa ePrivacy 2002/58/WE, art. 5 ust. 3, wymaga zgody przed jakimkolwiek niezbędnym przechowywaniem lub dostępem na urządzeniu końcowym użytkownika. Piksele marketingowe są nieistotne. Banery wyrażania zgody muszą być specyficzne dla danego piksela, dobrowolne i odwoływalne. Fakt, że miejsce docelowe transferu jest adekwatne w ramach DPF, nie wpływa na wymóg zgody ePrivacy. Są to odrębne instrumenty prawne.

Przejrzystość wobec podmiotów danych. Art. 13 RODO nakłada na administratora obowiązek poinformowania podmiotów danych, w chwili zbierania danych, o odbiorcach ich danych i wszelkich transferach do państw trzecich. DPF nie zmienia tego obowiązku przejrzystości. Jeśli twoja informacja o prywatności stwierdza, że „używamy Meta Pixel" i że „transfery do USA są objęte adekwatnością", to jest wystarczające. Jeśli w ogóle nie wspomina o transferze do USA, decyzja o adekwatności nie naprawia luki wynikającej z art. 13.

Umowa o powierzeniu przetwarzania (DPA) z art. 28 z dostawcą. Dostawca piksela pozostaje podmiotem przetwarzającym na mocy art. 28 RODO. DPF obejmuje mechanizm transferu; nie zastępuje DPA. Standardowe warunki przetwarzania danych Meta, Meta, Googl'a i HubSpot to instrumenty z art. 28 dla relacji z pikselem. Upewnij się, że są podpisane.

Pozostałe ryzyka#

DPF nie jest trwałym rozwiązaniem. To decyzja o adekwatności, która może zostać zaskarżona przed TSUE przez dowolny sąd państwa członkowskiego, Parlament Europejski lub dowolny krajowy organ nadzorczy. Max Schrems i NOYB publicznie sygnalizowali zamiar zaskarżenia DPF - potencjalny Schrems III. Teoria prawna dla tego zaskarżenia jest podobna do tej w Schrems II: że EO 14086 i Sąd ds. Przeglądu Ochrony Danych de facto nie zapewniają środków odwoławczych równoważnych tym dostępnym na mocy prawa UE.

Organy nadzorcze nie czekały na orzeczenie TSUE. Austriacki DSB orzekł w sprawie implementacji Google Analytics jeszcze w 2022 roku - przed wejściem w życie DPF - że transfer był niezgodny z prawem, ponieważ SCC i środki uzupełniające były niewystarczające. Francuski CNIL i włoski Garante wydały podobne ustalenia. Te orzeczenia były wydane w reżimie sprzed DPF, ale ustalają wzorzec nadzorczy: organy ochrony danych są gotowe badać mechanikę techniczną transferów opartych na pikselach, a nie tylko dokumentację umowną. Przyszłe orzeczenie w ramach zaskarżenia post-DPF prawdopodobnie sprawdziłoby, czy porządek prawny ustanowiony przez EO 14086 rzeczywiście ogranicza dostęp FISA 702 do przechowywanych danych certyfikowanych firm.

Specyficzne obawy związane z pikselami śledzącymi wykraczają poza mechanizm prawny. Piksel po stronie klienta robi więcej niż tylko transfer danych do certyfikowanej firmy. Wykonuje JavaScript w przeglądarce użytkownika, ustawia pliki cookie first-party i third-party w kontekście domeny piksela i wysyła dane bezpośrednio z przeglądarki. Dane opuszczające przeglądarkę są poza twoją kontrolą - nie możesz zastosować hashowania identyfikatorów przed ich wysłaniem, nie możesz ograniczyć, które pola są wypełniane i nie możesz zweryfikować, co piksel faktycznie wysyła w czasie działania bez inspekcji sieci. Adekwatność DPF obejmuje miejsce docelowe; nie odnosi się do tego, co piksel zbiera przed transferem.

Połączenie tych elementów - potencjalne zaskarżenie DPF, skrupulatne badanie mechaniki przez organy nadzorcze, a nie tylko dokumentacji, oraz strukturalne ograniczenia w weryfikacji przez administratora zachowania pikseli po stronie klienta - sprawia, że strategia jednokanałowa opierająca się wyłącznie na pikselach po stronie klienta pozostaje architektonicznie krucha.

Praktyczna pozycja: śledzenie dwutorowe#

Architektura, która sprawdzi się zarówno przy DPF, jak i przy ewentualnym jego unieważnieniu, to tryb dualny.

Pierwszy tryb to piksele po stronie klienta do dostawców certyfikowanych przez DPF, działające w oparciu o aktualną adekwatność z zachowaniem zgody ePrivacy. Zapewnia to najszerszy sygnał atrybucji, dopóki DPF obowiązuje. Dla większości zespołów marketingowych to tryb, który dziś wypełnia dashboardy atrybucji.

Drugi tryb to serwerowe przekazywanie konwersji z infrastruktury UE. Gdy użytkownik klika link, edge Elido w regionie UE odbiera kliknięcie, rejestruje je w magazynie analitycznym w infrastrukturze UE i przekazuje sygnał konwersji serwer-do-serwera do API konwersji platformy reklamowej - Meta CAPI, GA4 Measurement Protocol lub podobnego. Przeglądarka użytkownika nie kontaktuje się z endpointem w USA. Dane opuszczające infrastrukturę UE zostały zahashowane (SHA-256 dla adresów e-mail i numerów telefonów, jak wymaga Meta CAPI), a transfer pochodzi z infrastruktury pod twoją kontrolą, a nie z kodu działającego w przeglądarce użytkownika.

Jeśli DPF zostanie unieważniony, piksel po stronie klienta staje się niezgodnym mechanizmem transferu do czasu, aż nowe ramy zostaną wprowadzone. Ścieżka serwerowa, działająca przez SCC ze stosowanymi środkami uzupełniającymi - zaszyfrowana podczas transmisji, identyfikatory zahashowane przed wysłaniem, ograniczona do sygnału atrybucji - to fallback, który twój zespół prawny może obronić spójną TIA. Ponieważ ścieżka serwerowa najpierw przetwarza dane w infrastrukturze UE, transfer można udokumentować jako relację administrator-procesor, a nie jako transfer bezpośredni z przeglądarki do endpointu w USA.

Tam, gdzie jest dostępny, preferuj endpoint EU dostawcy. GA4 z data_collection_endpoint wskazującym na region1.google-analytics.com utrzymuje więcej przetwarzania w infrastrukturze UE Google, nawet jeśli część przetwarzania nadal odbywa się w infrastrukturze USA zgodnie z dokumentacją Google. Meta CAPI nie oferuje obecnie endpointu w regionie UE; transfer serwer-do-serwera i tak trafia do USA. Środkiem uzupełniającym jest hashowanie identyfikatorów, a nie geografia endpointu.

Pełna mechanika ścieżki przekazywania serwerowego i jej integracja z atrybucją kliknięć skróconych linków jest omówiona w atrybucja bez plików cookie - wyjaśnienie. Dla szerszego obrazu rezydencji danych w UE - gdzie zaczyna i kończy się „hostowanie w UE" w stosie narzędzi marketingowych - rezydencja danych w UE dla marketingu to wpis uzupełniający.

Zgoda na podmiot przetwarzający pod DPF#

Każdy certyfikowany przez DPF dostawca pikseli jest nadal podmiotem przetwarzającym na mocy art. 28 RODO. Decyzja o adekwatności DPF obejmuje mechanizm transferu; nie mówi nic o obowiązkach podmiotu przetwarzającego, które stosują się równolegle.

Oznacza to, że administrator musi mieć podpisaną Umowę o Przetwarzaniu Danych z każdym dostawcą pikseli, obejmującą obowiązki z art. 28 ust. 3 lit. a-h. Standardowe warunki reklamowego przetwarzania danych Meta, aneks przetwarzania danych Google i DPA HubSpot to instrumenty dla relacji z pikselami. Są wstępnie podpisane i włączone przez odniesienie, gdy akceptujesz warunki korzystania z usług dostawcy; pytanie dotyczy tego, czy udokumentowałeś tę umowę w swoich rejestrach zgodności.

Lista podmiotów przetwarzających, o którą zapyta twój inspektor ochrony danych, obejmuje tych dostawców. Każdy dostawca pikseli staje się podprocesorem w łańcuchu atrybucji między twoją platformą śledzenia linków a platformą reklamową. Publiczna lista podmiotów przetwarzających Elido wymienia swoich pięciu dostawców; dostawcy pikseli są podmiotami przetwarzającymi na poziomie administratora, nie na poziomie Elido. Twój rejestr czynności przetwarzania z art. 30 powinien wymieniać ich oddzielnie.

Jedna subtelność: art. 28 ust. 2 RODO wymaga od podmiotu przetwarzającego uzyskania zgody administratora przed zaangażowaniem podmiotów przetwarzających podmioty przetwarzające. W relacji z pikselami jesteś administratorem angażującym Meta lub Google bezpośrednio - to jest relacja administrator-procesor, a nie relacja łańcucha podprocesora przez Elido. DPA z art. 28 jest między tobą a dostawcą pikseli. Noga przekazywania serwerowego - gdzie edge Elido przekazuje zdarzenia do Meta CAPI w twoim imieniu - to relacja podprocesora: Elido jest procesorem, Meta CAPI jest podprocesorem, a obowiązek DPA przepływa przez standardową DPA Elido.

To rozróżnienie ma znaczenie dla twojego rejestru czynności przetwarzania. Zespół ds. zgodności z DPA, przeglądający twoje rejestry, chce zobaczyć dwa oddzielne wpisy: jeden dla relacji procesora Elido (obejmujący zdarzenia kliknięć na poziomie linku) i jeden dla każdej relacji z dostawcą pikseli (obejmujący dane atrybucji po stronie przeglądarki). Połączenie ich daje wpis w rejestrze czynności przetwarzania, który jest niedokładny w obu kierunkach.

Dla pełnego zakresu obowiązków procesora RODO na poziomie artykułu, RODO dla skracarek URL to główny wpis w tym klastrze.

Lista kontrolna IOD przy zakupie dostawców pikseli#

Pięć pytań, które należy zadać każdemu dostawcy pikseli śledzących przy zakupie. Są one napisane dla przeglądu w erze DPF; dostosuj pytanie o mechanizm transferu, jeśli status DPF zmienił się w czasie, gdy to czytasz.

1. Czy twoja firma figuruje na liście uczestników DPF i jakie działania obejmuje twoja certyfikacja?

Lista jest na dataprivacyframework.gov. Poproś o konkretny zakres certyfikacji, a nie ogólne „tak, jesteśmy certyfikowani." Certyfikacja ma określony zakres działalności; dostawca może być certyfikowany przez DPF dla danych kadrowych, ale nie dla danych handlowych dotyczących atrybucji kliknięć.

2. Gdzie faktycznie są przechowywane dane, które wysyłam przez piksel, i czy jest dostępny endpoint w regionie UE?

DPF obejmuje transfer do certyfikowanego odbiorcy z USA. Jeśli endpoint w regionie UE jest dostępny, jego użycie zmniejsza ekspozycję na transfer i może wpłynąć na analizę TIA, jeśli DPF zostanie później zakwestionowany. Udokumentuj odpowiedź w swoim wpisie w rejestrze czynności przetwarzania.

3. Jaka jest twoja standardowa Umowa o Przetwarzaniu Danych i czy wyraźnie obejmuje obowiązki z art. 28 ust. 3 lit. a-h?

Wstępnie podpisane DPA włączone przez odniesienie w warunkach korzystania z usług są w porządku; musisz wiedzieć, że DPA istnieje i gdzie je znaleźć. DPA reguluje relację procesora niezależnie od mechanizmu transferu.

4. Jak obsługujesz żądania praw podmiotów danych - w szczególności usunięcie danych zgodnie z art. 17 - dla danych zebranych przez piksel?

W przypadku pikseli po stronie klienta usunięcie jest zazwyczaj obsługiwane przez kontrolki prywatności platformy (Centrum Prywatności Meta, Moje Centrum Reklam Google). Udokumentuj proces, żebyś mógł odpowiedzieć na żądanie podmiotu danych bez improwizowania.

5. Jeśli DPF zostanie unieważniony, jaki fallbackowy mechanizm transferu zaoferujesz i w jakim terminie?

To pytanie sprawdza, czy dostawca ma plan awaryjny. Podczas przejścia z Privacy Shield na SCC (2020–2021) niektórzy dostawcy byli powolni w aktualizowaniu swoich umów. Dostawca, który już udokumentował SCC jako fallback przy unieważnieniu DPF - z określonymi środkami uzupełniającymi - wykonał tę pracę. Dostawca, który mówi „zaktualizujemy naszą DPA, gdy będzie to konieczne", tego nie zrobił.

Dla implementacji specyficznej dla Elido: serwerowe przekazywanie konwersji jest dostępne już dziś, z hashowaniem SHA-256 identyfikatorów przed opuszczeniem infrastruktury UE przez jakiekolwiek dane. Konfiguracja jest per-workspace i udokumentowana w standardowej DPA pod adresem /legal/dpa. Jeśli twoja tolerancja na ryzyko DPF jest niska, ścieżka serwerowa jest dostępna jako podstawowy mechanizm przekazywania, a nie tylko fallback.