Zespół prosi o politykę prywatności do aplikacji tak, jakby to był jeden plik do podpięcia w stopce. Problem w tym, że w aplikacji mobilnej z subskrypcją większość danych nie pochodzi z formularza – a część nawet nie od użytkownika. Telemetria, logi techniczne, identyfikatory instalacji, status subskrypcji potwierdzany przez sklep z aplikacjami, identyfikator z logowania zewnętrznego, informacja o transakcji od operatora płatności. I właśnie ta część jest w większości polityk pominięta.
Polityka prywatności aplikacji mobilnej to nie dokument redakcyjny. To wynik decyzji o architekturze produktu. Jeśli te decyzje nie zapadną przed napisaniem pierwszego akapitu, dokument będzie niezgodny z tym, co robi aplikacja – a niezgodność między polityką a rzeczywistością to ryzyko naruszenia zasady rzetelności i przejrzystości z art. 5 ust. 1 lit. a RODO.
W tym artykule przejdziemy przez pięć decyzji, które musisz podjąć z zespołem produktowym i technicznym, zanim zaczniesz pisać politykę prywatności. Każda z nich wpływa na treść dokumentu, ale przede wszystkim – na sposób działania Twojego produktu.
Podstawowe pojęcia, które pojawiają się w artykule
Zanim przejdziemy do decyzji, warto uporządkować kilka terminów. Nie chodzi o akademickie definicje – chodzi o to, żebyś wiedział, co oznaczają w kontekście Twojej aplikacji.
| Pojęcie | Co oznacza w kontekście aplikacji mobilnej |
|---|---|
| Art. 13 RODO | Obowiązek informacyjny, gdy zbierasz dane bezpośrednio od użytkownika (formularz rejestracji, dane podane w profilu) |
| Art. 14 RODO | Obowiązek informacyjny, gdy dane przychodzą z innego źródła – np. od sklepu z aplikacjami, operatora płatności, dostawcy logowania zewnętrznego |
| Administrator danych | Podmiot, który sam ustala cele i sposoby przetwarzania danych – kryterium funkcjonalne, nie formalne (art. 4 pkt 7 RODO) |
| Podmiot przetwarzający (procesor) | Podmiot, który przetwarza dane wyłącznie w imieniu administratora i na jego polecenie |
| Art. 399 PKE | Przepis Prawa komunikacji elektronicznej regulujący przechowywanie informacji w urządzeniu końcowym i dostęp do nich – odpowiednik dawnych przepisów o cookies, ale szerszy: obejmuje też SDK w aplikacji |
| Art. 22 RODO | Zakaz podejmowania decyzji opartych wyłącznie na zautomatyzowanym przetwarzaniu, jeżeli wywołują skutki prawne lub istotnie wpływają na osobę |
| CMP | Platforma zarządzania zgodami – narzędzie do zbierania, rejestrowania i wycofywania zgód użytkowników |
Decyzja 1: ile kanałów, ile dokumentów
Jeśli Twój produkt działa w dwóch kanałach – aplikacja mobilna i serwis internetowy (witryna sprzedażowa, panel użytkownika) – to jeden uniwersalny dokument rodzi konkretny problem. Użytkownik witryny czyta o synchronizacji między urządzeniami i trybie offline. Użytkownik aplikacji – o plikach cookie przeglądarki. Żaden z nich nie dostaje informacji dopasowanej do kontekstu, w którym korzysta z usługi.
Co rozstrzygnąć:
- Czy Twoja aplikacja i witryna zbierają te same dane, w ten sam sposób, do tych samych celów
- Czy użytkownik witryny i użytkownik aplikacji to ta sama persona z punktu widzenia przetwarzania danych
- Czy jeden dokument da się napisać tak, żeby nie wprowadzał w błąd żadnego z tych użytkowników
W większości przypadków odpowiedź na trzecie pytanie brzmi: nie. Lepszym rozwiązaniem jest osobny, krótszy dokument informacyjny dla witryny i osobna polityka dla aplikacji i usługi. W polityce aplikacji dodajesz jedno zdanie kierujące użytkownika witryny do drugiego dokumentu.
To nie podwójna praca – to dwa różne konteksty przetwarzania. Jeden dokument, który próbuje obsłużyć oba, jest dłuższy, mniej czytelny i trudniejszy do utrzymania.
Decyzja 2: skąd przychodzą dane i kto za nie odpowiada
To decyzja, która najczęściej wypada z pola widzenia. W aplikacji mobilnej mniejszość danych pochodzi z formularza. Większość powstaje automatycznie lub przychodzi od podmiotów trzecich.
Trzy koszyki danych w aplikacji mobilnej
| Koszyk | Przykłady | Obowiązek informacyjny |
|---|---|---|
| Dane podane świadomie | Imię, e-mail, dane profilu, preferencje | Art. 13 RODO |
| Dane generowane automatycznie | Telemetria, logi techniczne, dane o awariach, identyfikatory instalacji, parametry systemu | Art. 13 RODO (zbierane w ramach korzystania z usługi) |
| Dane otrzymane od podmiotów trzecich | Status subskrypcji od platformy dystrybucji, identyfikator i e-mail od dostawcy tożsamości, informacja o transakcji od operatora płatności | Art. 14 RODO |
Trzeci koszyk to element najczęściej pomijany w politykach przepisywanych z wzorów dla serwisów internetowych, gdzie stosuje się wyłącznie art. 13. Tymczasem art. 14 RODO wymaga podania źródła danych, zakresu i celu – a naruszenie tego obowiązku może być podstawą kary z najwyższego pułapu sankcyjnego RODO: do 20 mln EUR lub 4% globalnego rocznego obrotu (art. 83 ust. 5 lit. b RODO).
Kim naprawdę są Twoi partnerzy
Druga część tej decyzji dotyczy statusu prawnego podmiotów, z którymi współpracujesz. Sklep z aplikacjami i dostawca logowania zewnętrznego nie są podmiotami przetwarzającymi. Działają we własnym celu i na podstawie własnych polityk – wobec tych samych danych są odrębnymi administratorami.
TSUE interpretuje pojęcie administratora szeroko – kryterium jest funkcjonalne, nie formalne (sprawy C-604/22, C-683/21). Jeśli dany podmiot ustala własne cele przetwarzania, umowa powierzenia nie jest właściwym instrumentem.
Co to zmienia w polityce: zamiast wpisywać sklep z aplikacjami na listę procesorów, opisz go jako odrębnego administratora. Dodaj warunkowe zdanie o współadministrowaniu z art. 26 RODO tam, gdzie wspólnie z partnerem ustalacie cele przetwarzania.
Co to zmienia w organizacji: nie możesz obiecać użytkownikowi kontroli nad danymi przetwarzanymi przez sklep z aplikacjami – bo tej kontroli nie masz.
Napisz do nas, jeśli chcesz zweryfikować status prawny swoich partnerów technologicznych przed publikacją polityki.
Decyzja 3: gdzie przebiega granica zgody
To decyzja, która bezpośrednio wpływa na architekturę interfejsu i na legalność Twojej analityki.
Dwie warstwy: RODO i Prawo komunikacji elektronicznej
Prawo komunikacji elektronicznej (PKE) weszło w życie 10 listopada 2024 r. Art. 399 PKE reguluje przechowywanie informacji w urządzeniu końcowym i dostęp do nich. Przepis nie ogranicza się do plików cookies w przeglądarce – obejmuje każdą technologię, która zapisuje informacje na urządzeniu lub uzyskuje dostęp do informacji już tam przechowywanych.
W aplikacji mobilnej oznacza to, że SDK analityczne i marketingowe, które sięgają do identyfikatora urządzenia, mogą wchodzić w zakres art. 399 PKE. Zgoda na instalację aplikacji lub akceptacja regulaminu nie zastępuje zgody wymaganej przez ten przepis.
Granicą między analityką na uzasadnionym interesie (lit. f) a analityką wymagającą zgody nie jest cel przetwarzania, lecz to, czy dochodzi do sięgnięcia do urządzenia końcowego. To dwie osobne warstwy:
| Warstwa | Przepis | Co reguluje | Kiedy zgoda |
|---|---|---|---|
| Dostęp do urządzenia | Art. 399 PKE | Czynność techniczna – zapis/odczyt na urządzeniu | Wymagana, chyba że wyjątek (np. niezbędność do świadczenia usługi) |
| Przetwarzanie danych | Art. 6 RODO | Dalsze wykorzystanie danych pozyskanych z urządzenia | Zależy od celu – lit. a (zgoda), lit. b (umowa), lit. f (uzasadniony interes) |
Uwaga: brak urzędowego stanowiska UKE lub UODO, które wprost rozstrzygałoby, że konkretny typ SDK podlega art. 399 PKE. Wniosek o objęciu SDK tym przepisem jest interpretacją funkcjonalną wynikającą z brzmienia przepisu – ale nie potwierdzoną decyzją organu (Dz.U. 2024 poz. 1221).
Powiadomienia push: dwa przełączniki, nie jeden
Zgoda systemowa na wyświetlanie powiadomień (ustawienia urządzenia) to zgoda techniczna. Nie zastępuje zgody marketingowej.
Jeśli Twoja aplikacja ma jeden przełącznik powiadomień, użytkownik wyłączający marketing traci komunikaty o nieudanej płatności i alerty bezpieczeństwa. Albo odwrotnie – marketing idzie bez zgody.
Co wdrożyć:
- Powiadomienia transakcyjne i funkcjonalne – na podstawie wykonania umowy (art. 6 ust. 1 lit. b RODO)
- Powiadomienia marketingowe – wyłącznie na podstawie zgody (art. 6 ust. 1 lit. a RODO + art. 398 PKE dla marketingu bezpośredniego kanałem elektronicznym)
- Dwa osobne przełączniki w interfejsie aplikacji
- Wycofanie zgody marketingowej równie łatwe jak jej udzielenie – konkretny ekran w aplikacji, nie adres e-mail w dokumencie
Mechanizm zarządzania zgodami
Polityka prywatności powinna opisywać, jak działa mechanizm zgód: jakie kategorie technologii obejmuje, gdzie użytkownik udziela i wycofuje zgodę w obu kanałach, co stanowi dowód zgody (identyfikator, moment, zakres) i jak długo ten dowód jest przechowywany.
Administrator musi być w stanie wykazać, że osoba wyraziła zgodę (art. 7 ust. 1 RODO). Brak blokady SDK przed decyzją użytkownika lub brak dowodu treści zgody to ryzyka naruszenia zarówno art. 7 RODO, jak i art. 399 PKE.
Decyzja 4: ile zegarów retencji działa w Twoim produkcie
Jedno zdanie o przechowywaniu danych „przez okres niezbędny do realizacji celu” nie opisuje żadnego z zegarów retencji działających w aplikacji subskrypcyjnej. Przy skardze użytkownika lub kontroli taki zapis nie da się zweryfikować.
Tabela retencji dla aplikacji z subskrypcją
| Zegar | Co obejmuje | Podstawa okresu | Uwagi |
|---|---|---|---|
| Życie konta | Dane profilu, preferencje, historia aktywności | Czas trwania umowy (lit. b) | Usuwane po zamknięciu konta + karencja |
| Karencja po zgłoszeniu usunięcia | Dane konta w stanie „do usunięcia” | Uzasadniony interes (lit. f) – ochrona przed przypadkowym usunięciem | Ustal konkretny okres (np. 14 lub 30 dni) |
| Logi i dane diagnostyczne | Logi techniczne, dane o awariach, telemetria | Uzasadniony interes (lit. f) – stabilność usługi | Okres zależny od potrzeb technicznych – np. 90 dni |
| Kopie zapasowe | Pełne kopie środowiska | Uzasadniony interes (lit. f) | Reguła: danych usuniętych na żądanie nie przywraca się z backupu |
| Dokumentacja rachunkowo-podatkowa | Faktury, dowody księgowe | Art. 74 ustawy o rachunkowości – min. 5 lat od końca roku obrotowego; art. 70 § 1 Ordynacji podatkowej – 5 lat od końca roku, w którym upłynął termin płatności | Okres liczony od końca roku |
| Przedawnienie roszczeń | Dane niezbędne do obrony przed roszczeniami | Art. 118 Kodeksu cywilnego – 3 lata dla roszczeń okresowych (np. zapłata za subskrypcję); koniec terminu na ostatni dzień roku kalendarzowego | Każda rata subskrypcyjna ma własny bieg przedawnienia |
| Dowody zgód | Identyfikator, moment, zakres, wersja zgody | Art. 7 ust. 1 RODO w zw. z art. 6 ust. 1 lit. c | Przechowuj co najmniej do końca okresu, w którym zgoda mogłaby być kwestionowana |
Każdy z tych zegarów musisz potwierdzić z zespołem technicznym. Polityka prywatności opisuje okresy retencji, ale to konfiguracja systemów decyduje, czy dane faktycznie są usuwane.
Reguła dla kopii zapasowych zasługuje na osobne zdanie w polityce: danych usuniętych na żądanie użytkownika nie przywraca się z backupu. To rzadko spotykana deklaracja – ale bez niej dane usunięte po karencji mogą wrócić przy odtworzeniu środowiska.
Decyzja 5: gdzie w produkcie decyduje człowiek, a gdzie algorytm
Jeśli Twoja aplikacja ma mechanizmy antyfraudowe – wykrywanie podejrzanych kont, porównywanie identyfikatorów, analiza wzorców korzystania – musisz rozstrzygnąć, gdzie przebiega granica art. 22 RODO.
Zasada: automatyczna analiza sygnałów technicznych jest dopuszczalna. Ale decyzja o ograniczeniu funkcji, zawieszeniu lub usunięciu konta musi przejść przez realną weryfikację człowieka, jeśli wywołuje skutki prawne lub istotnie wpływa na użytkownika.
„Realna weryfikacja” to nie formalne zatwierdzenie wyniku systemu. Wytyczne Grupy Roboczej Art. 29 (poprzednika EROD) wskazują, że osoba dokonująca przeglądu musi mieć kompetencje, uprawnienia i możliwość zmiany decyzji (UODO – zautomatyzowane podejmowanie decyzji).
Co wdrożyć:
- Zidentyfikuj punkt w procesie, w którym decyzję zatwierdza człowiek
- Opisz w regulaminie ścieżkę wyjaśnień dla użytkownika – prawo do interwencji ludzkiej, wyrażenia stanowiska i zakwestionowania decyzji (art. 22 ust. 3 RODO)
- Przygotuj dokumentację wewnętrzną: identyfikator sprawy, wersja modelu, tożsamość weryfikatora, zakres uprawnień, indywidualne uzasadnienie i wynik przeglądu
- Upewnij się, że mechanizmy antyfraudowe nie opierają się na szczególnych kategoriach danych z art. 9 ust. 1 RODO (dane wrażliwe)
Dodatkowe ograniczenia: profilowanie reklamowe, małoletni, treści AI
Trzy dodatkowe warstwy regulacyjne wpływają na politykę prywatności aplikacji:
| Obszar | Przepis | Obowiązek |
|---|---|---|
| Dane wrażliwe w profilowaniu reklamowym | Art. 26 ust. 3 DSA + art. 9 RODO | Zakaz reklam opartych na profilowaniu z użyciem szczególnych kategorii danych – również wywnioskowanych z aktywności użytkownika |
| Reklama wobec małoletnich | Art. 28 ust. 2 DSA | Zakaz reklam opartych na profilowaniu, gdy dostawca wie z wystarczającą pewnością, że odbiorca jest małoletni; wytyczne KE |
| Komponent generatywny | Art. 50 AI Act (stosowany od 2 sierpnia 2026 r.) | Informacja o interakcji z systemem AI i o treściach wygenerowanych; oznaczenie wyników w formacie nadającym się do odczytu maszynowego |
Jeśli Twoja aplikacja ma komponent generatywny (chatbot, generator treści), ustal w polityce: czy dane użytkowników zasilają trenowanie modeli – również po stronie dostawców – i gdzie pojawia się komunikat o interakcji z AI.
Co jeszcze powinno znaleźć się w polityce
Poza pięcioma decyzjami opisanymi wyżej, polityka prywatności aplikacji mobilnej powinna zawierać kilka elementów, które łatwo pominąć:
- Procedura realizacji praw – nie lista uprawnień, lecz opis procesu: kanał wniosku, weryfikacja tożsamości (art. 12 ust. 6 RODO pozwala żądać dodatkowych informacji przy wątpliwościach), miesiąc na odpowiedź z możliwością przedłużenia o dwa miesiące i obowiązkiem poinformowania o przedłużeniu jeszcze w pierwszym miesiącu
- Dwa tryby sprzeciwu z art. 21 RODO – sprzeciw z przyczyn związanych ze szczególną sytuacją (administrator może wykazać nadrzędne podstawy) oraz sprzeciw wobec marketingu bezpośredniego (bezwarunkowy, po wniesieniu danych nie wolno już przetwarzać do takich celów)
- Prawa realizowane samodzielnie w ustawieniach aplikacji – wskaż, które operacje użytkownik wykonuje sam (zmiana danych profilu, wycofanie zgody marketingowej, usunięcie konta), a które wymagają wniosku
- Los treści użytkownika po usunięciu konta – opinie, recenzje: czy zostają, na jakiej podstawie, w jakiej formie (np. bez oznaczenia autora), jaka jest ścieżka sprzeciwu
- Transfery poza EOG – opisuj mechanizmem (decyzja o adekwatności albo standardowe klauzule umowne ze środkami dodatkowymi), nie listą państw i dostawców – taki opis nie starzeje się przy zmianie vendora
- Wersjonowanie – numer wersji, data wejścia w życie, równoległa publikacja w aplikacji i w serwisie, archiwum wersji na żądanie, kanał uprzedzania o zmianach dotykających celów, podstaw prawnych, odbiorców lub transferów
- Spójność z etykietami sklepowymi – deklaracja w App Store (Prywatność w aplikacji) i Google Play (Data safety) musi odpowiadać temu, co opisujesz w polityce; rozbieżność może naruszać zasadę rzetelności z art. 5 ust. 1 lit. a RODO
Lista kontrolna do przejścia z zespołem technicznym
Zanim zaczniesz pisać politykę, przejdź tę listę z CTO lub osobą odpowiedzialną za architekturę aplikacji:
| Nr | Pytanie | Kto odpowiada | Status |
|---|---|---|---|
| 1 | Które SDK w aplikacji zapisują informacje na urządzeniu lub odczytują identyfikatory? | CTO / Lead Developer | ☐ |
| 2 | Jakie dane przychodzą od sklepu z aplikacjami, operatora płatności i dostawcy logowania? | Backend / Integracje | ☐ |
| 3 | Czy każdy z tych partnerów jest opisany jako administrator, procesor czy współadministrator? | Legal + CTO | ☐ |
| 4 | Ile przełączników zgód jest w interfejsie? Czy powiadomienia transakcyjne i marketingowe są rozdzielone? | Product / UX | ☐ |
| 5 | Czy SDK analityczne i marketingowe są blokowane przed decyzją użytkownika o zgodzie? | CTO / DevOps | ☐ |
| 6 | Jakie są faktyczne okresy retencji dla: konta, logów, backupów, dokumentów rachunkowych? | CTO + Finanse | ☐ |
| 7 | Czy backupy mają regułę zakazującą przywracania danych usuniętych na żądanie? | DevOps / Infra | ☐ |
| 8 | Czy w procesie antyfraudowym jest punkt, w którym decyzję zatwierdza człowiek? | Product / Security | ☐ |
| 9 | Czy profilowanie reklamowe wyklucza dane wrażliwe i osoby małoletnie? | Marketing / AdOps | ☐ |
| 10 | Czy etykieta w sklepie z aplikacjami odpowiada temu, co opisuje polityka? | Product / Legal | ☐ |
Uporządkuj politykę prywatności zanim zablokuje Twój produkt
Polityka prywatności aplikacji mobilnej to nie tekst do napisania na koniec sprintu. To dokument, który wynika z pięciu decyzji o architekturze produktu – i który trzeba uzgodnić z zespołem technicznym, zanim trafi do użytkownika.
Najczęstsze błędy – pominięcie art. 14 RODO, wpisanie sklepu z aplikacjami jako procesora, jeden przełącznik push, jedno zdanie o retencji – nie są błędami redakcyjnymi. To błędy produktowe, których naprawa po fakcie wymaga zmian w kodzie, ponownego zebrania zgód i nowelizacji dokumentów.
Jeśli wypuszczasz nową aplikację, dodajesz subskrypcję do istniejącego produktu lub chcesz zweryfikować, czy Twoja obecna polityka odpowiada temu, co robi aplikacja – napisz do nas. Przeprowadzimy warsztat mapowania źródeł danych i celów z Twoim zespołem produktowym, zweryfikujemy status partnerów i umów, uzgodnimy tabelę retencji z technologią, a na tej podstawie przygotujemy politykę prywatności dopasowaną do Twojego produktu.
Najczęściej zadawane pytania
Czy jeden dokument może obsłużyć aplikację i stronę internetową?
Technicznie tak, ale w większości przypadków jeden dokument wprowadza w błąd przynajmniej jedną grupę użytkowników. Użytkownik witryny czyta o telemetrii i synchronizacji między urządzeniami, użytkownik aplikacji – o plikach cookie. Lepsze rozwiązanie: osobny dokument dla witryny i osobna polityka dla aplikacji, z wzajemnym odesłaniem.
Czy sklep z aplikacjami jest podmiotem przetwarzającym i czy muszę mieć z nim umowę powierzenia?
Nie. Sklep z aplikacjami ustala własne cele przetwarzania (konto użytkownika, płatności, analityka platformy) – jest odrębnym administratorem. Umowa powierzenia nie jest tu właściwym instrumentem. Polityka prywatności powinna odzwierciedlać ten podział ról, a nie obiecywać użytkownikowi kontroli, której nie masz.
Które narzędzia analityczne mogę uruchomić bez zgody?
Analitykę własną, która nie sięga do urządzenia końcowego ponad zakres niezbędny do świadczenia usługi, możesz oprzeć na uzasadnionym interesie (art. 6 ust. 1 lit. f RODO). Zewnętrzne SDK, które zapisują informacje na urządzeniu lub odczytują identyfikatory, mogą wymagać zgody na podstawie art. 399 PKE – niezależnie od podstawy z RODO. Sprawdź w kodzie, które narzędzia sięgają do urządzenia, zanim przypiszesz im podstawę prawną.
Czy zgoda użytkownika na powiadomienia w ustawieniach telefonu wystarczy do wysyłania promocji?
Nie. Zgoda systemowa to zgoda techniczna na wyświetlanie powiadomień. Nie zastępuje zgody marketingowej wymaganej przez RODO i PKE. Potrzebujesz dwóch osobnych przełączników: jeden dla powiadomień transakcyjnych i funkcjonalnych, drugi dla marketingowych.
Jak długo mam trzymać dane konta, logi i backupy?
Nie ma jednej odpowiedzi – w aplikacji subskrypcyjnej działa kilka niezależnych zegarów retencji. Dane konta usuwasz po zamknięciu + karencja. Logi techniczne – np. 90 dni. Dokumenty rachunkowe – minimum 5 lat od końca roku obrotowego. Roszczenia o zapłatę za subskrypcję przedawniają się po 3 latach (art. 118 KC). Każdy z tych zegarów powinien być opisany w polityce i potwierdzony z zespołem technicznym.
Czy mogę automatycznie blokować konta podejrzane o nadużycie?
Automatyczna analiza sygnałów jest dopuszczalna. Ale decyzja o zablokowaniu lub usunięciu konta, która istotnie wpływa na użytkownika, wymaga realnej weryfikacji człowieka – chyba że stosujesz wyjątek z art. 22 ust. 2 RODO i wdrażasz środki ochrony z ust. 3 (prawo do interwencji ludzkiej, wyrażenia stanowiska, zakwestionowania decyzji). Opisz tę ścieżkę w regulaminie.
