Aplikacja jest prawie gotowa. Development się kończy, projekty graficzne są zaakceptowane, płatności działają na środowisku testowym, a premiera ma się odbyć za kilka tygodni. Na tym etapie founder zwykle przypomina sobie o regulaminie i polityce prywatności i szuka kogoś, kto „szybko je przygotuje”.
Dokumenty dla użytkowników są jednak tylko jednym z elementów prawnego przygotowania produktu i zwykle nie powinny powstawać jako pierwsze. Zanim się je napisze, trzeba odpowiedzieć na kilka pytań. Czy spółka ma prawa do wszystkich elementów aplikacji? Jakie dane zbiera produkt i dokąd je wysyła? Z jakich zewnętrznych narzędzi korzysta? Jak zarabia? Kto z niego korzysta? Czy jego funkcje nie uruchamiają przepisów, o których nikt w zespole nie pomyślał?
Dlatego audyt prawny aplikacji mobilnej nie powinien zaczynać się od pytania „czy mamy regulamin i politykę prywatności?”, tylko od pytania „jak ten produkt naprawdę działa?”. Poniżej pokazuję mapę obszarów, które warto przeanalizować przed premierą, skalowaniem albo rozmowami z inwestorem.
Model biznesowy – od tego zaczyna się audyt
Zakres audytu nie wynika z tego, że produkt jest „aplikacją mobilną”, tylko z tego, co robi i jak zarabia. Zanim prawnik zajrzy do jakiegokolwiek dokumentu, powinien ustalić:
- kto jest właścicielem i operatorem produktu (spółka, jednoosobowa działalność, kilka podmiotów),
- kto korzysta z aplikacji: konsumenci, przedsiębiorcy czy obie grupy,
- co aplikacja faktycznie umożliwia użytkownikowi,
- na czym przedsiębiorca zarabia,
- czy to on świadczy usługę, czy tylko pośredniczy między użytkownikami a innymi podmiotami.
Prostą aplikację użytkową analizuje się inaczej niż marketplace, aplikację subskrypcyjną, platformę SaaS dla firm, aplikację związaną ze zdrowiem czy produkt z funkcjami opartymi na AI. To, czy odbiorcą jest konsument, zmienia zakres obowiązków informacyjnych i zasady zawierania umów. To, czy aplikacja pośredniczy w transakcjach, może zmienić jej status regulacyjny. Model biznesowy determinuje zakres audytu, a nie odwrotnie.
Prawa do aplikacji i wszystkich jej elementów
Drugie pytanie brzmi: czy spółka rzeczywiście dysponuje prawami potrzebnymi do korzystania z produktu, jego rozwijania i komercjalizacji?
Nie chodzi wyłącznie o kod. Audyt może obejmować także:
- grafikę, projekt interfejsu i teksty w aplikacji,
- dokumentację techniczną i bazy danych,
- nazwę produktu, logo i domeny (w tym to, czy nazwa nie koliduje z cudzymi znakami towarowymi),
- komponenty przygotowane przez software house, w tym jego własne biblioteki używane w wielu projektach,
- elementy third-party i biblioteki open source.
Szczegółowo o tym, dlaczego zapłata za aplikację nie oznacza automatycznie praw do kodu, piszę w artykule Prawa autorskie do aplikacji mobilnej – czy zapłata za aplikację oznacza, że masz prawa do kodu?. Przy audycie przed premierą najważniejsze jest ustalenie, czy łańcuch praw jest kompletny i udokumentowany. Luka wykryta teraz jest zwykle łatwiejsza do uzupełnienia niż ta sama luka wykryta przez inwestora.
Dane osobowe i rzeczywisty przepływ danych
W tym obszarze najczęściej widać różnicę między „mamy politykę prywatności” a „wiemy, co się dzieje z danymi”. Polityka prywatności ma opisywać rzeczywiste działanie aplikacji, a nie być tekstem przygotowanym w oderwaniu od technologii. Najpierw trzeba więc ustalić:
- jakie dane aplikacja zbiera i od kogo,
- w jakich celach,
- gdzie są przechowywane,
- komu są przekazywane,
- jakie zewnętrzne narzędzia je otrzymują: SDK analityczne, narzędzia do raportowania błędów, systemy reklamowe, narzędzia marketingowe,
- czy dane trafiają poza Europejski Obszar Gospodarczy,
- czy aplikacja przetwarza szczególne kategorie danych (np. dane o zdrowiu, dane biometryczne służące identyfikacji) albo inne dane wymagające zwiększonej ostrożności, np. dokładną lokalizację.
W praktyce często okazuje się, że aplikacja wysyła dane do większej liczby podmiotów, niż zakładał zespół, bo część SDK robi to domyślnie. Dlatego rzetelny audyt zaczyna się od rozmowy z zespołem technicznym, a nie od szablonu polityki. Dopiero na tej podstawie można ustalić właściwe podstawy prawne na gruncie RODO, ocenić, czy potrzebne są zgody, oraz określić role poszczególnych dostawców i potrzebną dokumentację, w tym ewentualne umowy powierzenia.
Dokumentacja dla użytkownika
Dopiero na tym etapie przychodzi czas na dokumenty. W zależności od produktu mogą być potrzebne m.in.:
- regulamin określający zasady korzystania z aplikacji,
- polityka prywatności,
- informacje dotyczące płatności i subskrypcji,
- komunikaty i zgody w interfejsie, np. przy rejestracji, zakupie czy włączaniu powiadomień,
- inne dokumenty wynikające z funkcji produktu, np. zasady publikowania treści przez użytkowników.
Nie istnieje jeden zestaw dokumentów odpowiedni dla każdej aplikacji. Aplikacja B2B bez płatności w aplikacji i marketplace dla konsumentów potrzebują zupełnie innej dokumentacji. Ważne jest też miejsce, w którym użytkownik widzi informacje. Część obowiązków spełnia się nie dokumentem, tylko właściwie zaprojektowanym ekranem w aplikacji.
Płatności, subskrypcje i monetyzacja
Sposób zarabiania aplikacji w dużej mierze wyznacza zakres obowiązków. Inne pytania pojawiają się przy jednorazowej płatności, inne przy subskrypcji z automatycznym odnowieniem, zakupach w aplikacji, modelu freemium, prowizjach od transakcji czy reklamach.
Monetyzacja może wpływać na:
- obowiązki informacyjne przed zawarciem umowy, zwłaszcza wobec konsumentów,
- zasady zawierania umowy, jej odnawiania i rezygnacji,
- treść regulaminu i komunikatów w aplikacji,
- projekt ścieżki zakupowej, np. oznaczenie przycisku zakupu czy sposób prezentowania ceny,
- wymagania platform dystrybucyjnych dotyczące płatności.
Jeśli aplikacja przyjmuje środki od użytkowników po to, żeby przekazać je innym (np. w marketplace), trzeba też sprawdzić, czy model nie wchodzi w zakres usług płatniczych wymagających zezwolenia. W praktyce modele marketplace często projektuje się z wykorzystaniem licencjonowanego dostawcy usług płatniczych. Sam udział takiego dostawcy nie zwalnia jednak z analizy roli platformy i rzeczywistego przepływu środków.
Zewnętrzni dostawcy i infrastruktura
Aplikacja rzadko działa samodzielnie. Korzysta z hostingu i chmury, operatorów płatności, narzędzi analitycznych, usług mailingowych, systemów CRM, zewnętrznych API, a coraz częściej także z modeli AI dostarczanych przez inne firmy.
Audyt powinien ustalić:
- jakie podmioty uczestniczą w działaniu produktu,
- jakie dane otrzymują i na jakiej podstawie,
- jakie umowy lub regulaminy obowiązują w relacji z nimi,
- czy zależność od konkretnego dostawcy nie tworzy ryzyka biznesowego, np. gdy dostawca może jednostronnie zmienić warunki, ograniczyć dostęp albo korzystać z przekazanych danych do własnych celów.
Nie chodzi o katalog kilkudziesięciu umów, tylko o świadomość, na czym opiera się produkt i gdzie są słabe punkty.
App Store i Google Play
Publikacja aplikacji wymaga też zgodności z warunkami platform dystrybucyjnych. Ich wymagania zmieniają się regularnie, dlatego przed premierą trzeba je sprawdzić w aktualnym brzmieniu. Do obszarów, które zwykle wymagają uwagi, należą m.in.:
- deklaracje dotyczące prywatności i danych: w App Store informacje o prywatności aplikacji, w Google Play sekcja „Bezpieczeństwo danych”. Muszą być spójne z polityką prywatności i z tym, co aplikacja faktycznie robi, włącznie z działaniem SDK,
- link do polityki prywatności,
- możliwość usunięcia konta, jeśli aplikacja pozwala je założyć. Google Play wymaga przy tym nie tylko ścieżki umożliwiającej zainicjowanie usunięcia konta w aplikacji, ale również zewnętrznego zasobu internetowego, za pośrednictwem którego użytkownik może zażądać usunięcia konta,
- zasady płatności i subskrypcji, w tym korzystania z systemów płatności platformy,
- informacje o statusie przedsiębiorcy przy dystrybucji w UE,
- dodatkowe wymagania dla określonych kategorii aplikacji, np. kierowanych do dzieci, związanych ze zdrowiem czy finansami.
Niezgodność deklaracji w sklepie z rzeczywistym działaniem aplikacji to nie tylko ryzyko odrzucenia w weryfikacji. Może to być także problem na gruncie przepisów o ochronie danych i ochronie konsumentów.
Czy aplikacja podlega dodatkowym regulacjom?
To obszar, w którym audyt daje często najwięcej wartości, bo dotyczy ryzyk, o których zespół zwykle nie wie. Niektóre funkcje powinny uruchomić dodatkowe sprawdzenie regulacyjne. Nie oznacza to automatycznie, że dana ustawa ma zastosowanie, tylko że trzeba to przeanalizować:
- finanse i płatności: przechowywanie środków użytkowników, płatności między użytkownikami, elementy inwestycyjne lub kredytowe,
- zdrowie: aplikacja wspierająca diagnozę, monitorowanie lub leczenie może w zależności od przeznaczenia zostać uznana za wyrób medyczny. Nie dotyczy to jednak każdej aplikacji „o zdrowiu”,
- dzieci: szczególne kwestie dotyczące przetwarzania danych dzieci, w tym w określonych przypadkach warunki skuteczności zgody, a także projektowania usług i wymagania platform,
- marketplace’y i treści użytkowników: obowiązki wynikające z aktu o usługach cyfrowych (DSA), przepisów o ochronie konsumentów czy relacjach z użytkownikami biznesowymi. Ich zakres zależy od charakteru usługi i wielkości podmiotu,
- AI: obowiązki z AI Act zależą od kategorii systemu i roli podmiotu. Samo wykorzystanie funkcji AI nie oznacza, że aplikacja zawiera system wysokiego ryzyka. Kwalifikacja wymaga analizy konkretnego systemu, jego przeznaczenia oraz roli danego podmiotu. Harmonogram stosowania części przepisów zmieniono w 2026 r., więc trzeba go sprawdzać na bieżąco,
- dostępność: określone usługi cyfrowe, np. z zakresu handlu elektronicznego, muszą spełniać wymagania dostępności, z wyjątkami m.in. dla mikroprzedsiębiorców,
- lokalizacja, biometria i inne szczególnie wrażliwe dane.
Cyberbezpieczeństwo w ujęciu prawnym
Bezpieczeństwo aplikacji to nie tylko test penetracyjny. Z perspektywy prawnej znaczenie mogą mieć m.in. odpowiednie zabezpieczenie danych osobowych, podział odpowiedzialności z dostawcami infrastruktury, procedura postępowania przy incydentach (w tym przy naruszeniu ochrony danych, które może wymagać zgłoszenia do organu nadzorczego) oraz obowiązki z przepisów sektorowych.
Samo prowadzenie aplikacji nie oznacza jeszcze podlegania obowiązkom ustawy o krajowym systemie cyberbezpieczeństwa. Trzeba ustalić, czy operator produktu jest podmiotem kluczowym lub ważnym w rozumieniu ustawy, biorąc pod uwagę m.in. sektor działalności, charakter świadczonych usług i kryteria dotyczące podmiotu. Nawet gdy przedsiębiorca nie podlega tym obowiązkom bezpośrednio, wymagania bezpieczeństwa mogą pojawić się w relacjach B2B z klientami objętymi regulacją.
Co powinien dać przedsiębiorcy audyt prawny aplikacji mobilnej?
Dobry audyt nie kończy się stwierdzeniem „dokumenty są zgodne z prawem” albo listą kilkudziesięciu uwag bez hierarchii. Jego wynikiem powinna być uporządkowana mapa, która pozwala podjąć decyzje biznesowe:
- jakie ryzyka zidentyfikowano i jak są istotne,
- co trzeba poprawić przed premierą,
- co można zaplanować na później,
- jakich dokumentów brakuje lub które wymagają zmiany,
- które kwestie wymagają pogłębionej analizy, np. kwalifikacji regulacyjnej.
W praktyce dobrze sprawdza się układ: obszar → ryzyko → poziom istotności → rekomendacja → priorytet. Na przykład:
| Obszar | Ryzyko | Istotność | Rekomendacja | Priorytet |
|---|---|---|---|---|
| Dane osobowe | SDK reklamowe uruchamia się bez zweryfikowanego mechanizmu zgód i podstaw przetwarzania | Wysoka | Ustalić podstawy przetwarzania i, jeśli są wymagane, zgody; uruchamiać SDK dopiero po spełnieniu tych warunków; zaktualizować politykę i deklaracje w sklepach | Przed premierą |
| Prawa do produktu | Brak udokumentowanego tytułu prawnego do grafik przygotowanych przez freelancera | Średnia | Uzyskać umowę przenoszącą prawa lub licencję w zakresie potrzebnym do korzystania z produktu i jego rozwoju | Przed premierą lub rundą |
| Dostawcy | Nieustalona rola dostawcy narzędzia mailingowego i brak wymaganej dokumentacji dotyczącej przetwarzania danych | Średnia | Ustalić rolę dostawcy i przygotować wymaganą dokumentację, np. umowę powierzenia, jeśli dostawca przetwarza dane w imieniu spółki | W ciągu 30 dni |
Audyt nie daje gwarancji braku ryzyka. Pozwala jednak wiedzieć, jakie ryzyka się podejmuje, i świadomie zdecydować, które z nich wyeliminować teraz.
Warto też odróżnić audyt od legal due diligence. Analiza przeprowadzana przy rundzie finansowania, sprzedaży produktu czy przejęciu spółki obejmuje podobne obszary, ale ma inny cel. Bada produkt z perspektywy inwestora lub kupującego i zwykle szerzej obejmuje sprawy korporacyjne i kontraktowe. Audyt zrobiony wcześniej znacznie ułatwia due diligence.
Audyt prawny aplikacji mobilnej – checklista obszarów
Przed premierą lub skalowaniem warto sprawdzić, czy potrafisz odpowiedzieć na pytania z każdego obszaru:
- Model biznesowy: kto jest użytkownikiem, kto świadczy usługę i na czym zarabiasz?
- Prawa: czy spółka ma udokumentowane prawa do kodu, grafiki, nazwy i pozostałych elementów?
- Dane: jakie dane zbierasz, gdzie trafiają i na jakiej podstawie?
- Dokumenty: czy regulamin, polityka i komunikaty w aplikacji opisują rzeczywiste działanie produktu?
- Monetyzacja: czy ścieżka zakupu i zasady subskrypcji spełniają obowiązki informacyjne?
- Dostawcy: z kim współpracujesz i na jakich warunkach?
- Sklepy: czy deklaracje w App Store i Google Play są zgodne z rzeczywistością?
- Regulacje: czy funkcje produktu nie uruchamiają przepisów sektorowych?
- Bezpieczeństwo: czy wiesz, co zrobić w razie incydentu?
Umowy z wykonawcą to osobny temat, który warto mieć uporządkowany jeszcze przed rozpoczęciem developmentu. Pisałam o nim w artykułach o umowie na stworzenie aplikacji mobilnej i o odbiorze aplikacji.
Podsumowanie
Audyt prawny aplikacji to analiza całego produktu i jego modelu biznesowego, a nie tylko sprawdzenie regulaminu i polityki prywatności. Dokumenty są efektem tej analizy, a nie jej punktem wyjścia. Audyt przeprowadzony przed premierą daje więcej przestrzeni na wprowadzenie zmian, zanim produkt trafi do użytkowników lub stanie się przedmiotem rozmów z inwestorem.
Przygotowujesz aplikację do premiery?
Jeśli przygotowujesz aplikację do uruchomienia, masz już działający produkt albo planujesz rozmowy z inwestorem, kancelaria Prawnik dla IT może przeprowadzić kompleksowy audyt prawny produktu cyfrowego. Wynikiem jest uporządkowana mapa ryzyk z określeniem priorytetów, rekomendowanymi działaniami i wskazaniem brakujących dokumentów lub potrzebnych zmian. Skontaktuj się z nami, aby omówić swój produkt.