RODO w e-commerce i SaaS nie „boli”, dopóki nie przyjdzie kontrola albo incydent. W latach 2024–2026 widać wyraźnie jedną rzecz: organy nadzorcze przestały tolerować półśrodki. Dotyczy to szczególnie obszarów, które jeszcze niedawno były traktowane jako „szara strefa” – cookies, tracking, integracje marketingowe i transfery danych poza EOG.
Ten artykuł nie jest przeglądem teorii. To zestawienie najczęstszych naruszeń realnie sankcjonowanych przez UODO, CNIL, ICO i inne organy UE — wraz z wnioskami, które można przełożyć na konkretne działania w produkcie, marketingu i architekturze danych.
1. Dark patterns w cookie bannerach i wadliwy consent management
To obecnie jeden z najintensywniej egzekwowanych obszarów. Organy nadzorcze nie kwestionują już samego obowiązku zbierania zgody — kwestionują sposób jej uzyskiwania.
CNIL wielokrotnie karał duże podmioty (m.in. Google i Facebook) za brak równoważności przycisków „akceptuj” i „odrzuć”. W decyzjach wskazano wprost, że utrudnianie odmowy zgody narusza zasadę dobrowolności (art. 4 pkt 11 RODO).
W Polsce UODO również sygnalizuje zaostrzenie podejścia — szczególnie wobec sklepów internetowych korzystających z gotowych CMP, które nie są poprawnie skonfigurowane. Problemem nie jest narzędzie, tylko implementacja.
Najczęstsze naruszenia:
- brak opcji „odrzuć wszystkie” na pierwszej warstwie banera
- domyślnie zaznaczone zgody
- niejasne kategorie cookies („ulepszenie doświadczenia użytkownika”)
- ładowanie skryptów marketingowych przed uzyskaniem zgody
Wniosek praktyczny: sprawdź, czy Twój banner cookies faktycznie blokuje skrypty (Meta Pixel, GA4, Hotjar) przed zgodą. Sam interfejs to za mało — liczy się realne zachowanie kodu.
2. Google Analytics 4 i transfery danych do USA po Schrems II
To temat, który wraca w każdej kontroli. Po wyroku Schrems II wiele organów (m.in. w Austrii, Francji i Włoszech) uznało korzystanie z Google Analytics za niezgodne z RODO, gdy dane trafiają do USA bez odpowiednich zabezpieczeń.
Wprowadzenie EU–US Data Privacy Framework nie rozwiązało wszystkich problemów. Organy nadal badają, czy konkretna implementacja zapewnia odpowiedni poziom ochrony.
W praktyce e-commerce i SaaS oznacza to:
- adres IP (nawet skrócony) nadal może być uznany za dane osobowe
- identyfikatory użytkowników (client ID, user ID) mogą prowadzić do identyfikacji
- integracje server-side nie eliminują problemu transferu
EDPB jasno wskazuje: samo zawarcie SCC (standardowych klauzul umownych) nie wystarcza, jeśli nie ma realnych środków technicznych ograniczających dostęp do danych.
Wniosek praktyczny: przeanalizuj, czy Twoje narzędzia analityczne faktycznie wymagają transferu danych poza EOG. Rozważ alternatywy hostowane w UE lub wdrożenie dodatkowych środków (np. proxy, anonimizacja).
3. Remarketing i tracking bez podstawy prawnej
Remarketing to obszar, gdzie naruszenia są często „ukryte” w marketing stacku. Pixel Meta, Google Ads, TikTok – wszystkie działają na podobnym mechanizmie: śledzenie użytkownika i profilowanie.
Problem zaczyna się wtedy, gdy:
- tracking uruchamia się przed zgodą
- zgoda nie obejmuje profilowania
- brak transparentnej informacji o odbiorcach danych
Organy nadzorcze (szczególnie CNIL i ICO) wskazują, że remarketing wymaga wyraźnej zgody, a nie może być oparty na uzasadnionym interesie administratora.
W kontekście SaaS dodatkowym problemem są integracje API – np. przekazywanie danych klientów do HubSpot czy Salesforce bez odpowiedniej podstawy prawnej.
Wniosek praktyczny: zmapuj wszystkie narzędzia marketingowe i sprawdź, które z nich faktycznie przetwarzają dane osobowe. W większości przypadków lista jest dłuższa, niż zakłada zespół produktowy.
4. Retencja danych klientów – „trzymamy, bo może się przyda”
To jedno z najczęstszych naruszeń wykrywanych przez UODO. Dane klientów w e-commerce i SaaS są przechowywane znacznie dłużej, niż wynika to z celu przetwarzania.
Problem dotyczy m.in.:
- nieaktywnych kont użytkowników
- starych leadów marketingowych
- danych z systemów CRM i helpdesk
RODO wymaga, aby dane były przechowywane nie dłużej, niż jest to niezbędne. Brak polityki retencji to realne ryzyko kary.
Wniosek praktyczny: wdroż automatyczne mechanizmy usuwania lub anonimizacji danych. Manualne procesy w tym obszarze nie działają.
5. Subprocesorzy w SaaS – brak kontroli nad łańcuchem przetwarzania
Model SaaS opiera się na zewnętrznych dostawcach: hosting, mailing, analytics, support. Każdy z nich to potencjalny podmiot przetwarzający.
Najczęstsze naruszenia:
- brak umów powierzenia (DPA)
- brak listy subprocesorów
- brak kontroli nad dalszym przekazywaniem danych
UODO podkreśla, że administrator musi mieć realną kontrolę nad przetwarzaniem danych – nie tylko formalną.
Wniosek praktyczny: stwórz aktualną mapę subprocesorów i sprawdź, gdzie faktycznie trafiają dane użytkowników. Szczególnie w integracjach API i webhookach.
6. Incydenty bezpieczeństwa i brak zgłoszeń do UODO
Wycieki danych nadal się zdarzają. Problem polega na tym, że wiele firm nie zgłasza incydentów, zakładając, że „nie są poważne”.
RODO jest tu jednoznaczne: jeśli istnieje ryzyko naruszenia praw lub wolności osób fizycznych, incydent należy zgłosić w ciągu 72 godzin.
W Polsce głośnym przykładem była kara dla Morele.net (ok. 2,8 mln zł), gdzie UODO wskazał na niewystarczające środki bezpieczeństwa i brak odpowiedniej reakcji na incydent.
Wniosek praktyczny: przygotuj procedurę reagowania na incydenty. W praktyce liczy się pierwsze 24–48 godzin.
Podsumowanie: gdzie dziś jest największe ryzyko?
Największe ryzyka w e-commerce i SaaS w 2025/2026 nie wynikają z braku wiedzy o RODO. Wynikają z:
- złożoności stacku technologicznego
- automatyzacji marketingu
- braku kontroli nad przepływem danych
Organy nadzorcze koncentrują się dziś na obszarach, gdzie dane są przetwarzane masowo i często nieświadomie: tracking, analityka, integracje.
To nie jest już kwestia dokumentacji. To jest kwestia realnego działania systemów.
Co dalej?
Audyt RODO w e-commerce lub SaaS nie polega dziś na sprawdzeniu polityki prywatności. Polega na analizie tego, co faktycznie dzieje się z danymi w Twoim systemie.
Jeżeli chcesz zweryfikować swój model przetwarzania danych – zacznij od mapy przepływów i stacku narzędzi. To punkt wyjścia do każdej sensownej analizy prawnej.
