„Tylko dla firm” nie kończy sprawy

Najpierw zdecyduj, kto może kupić abonament. Inaczej przygotowuje się usługę wyłącznie dla spółek, inaczej aplikację dostępną także dla konsumentów. Ta decyzja wpływa na regulamin, ceny widoczne na stronie, zamówienie, reklamacje i sposób zakończenia umowy.

Pomiędzy tymi grupami są osoby prowadzące jednoosobową działalność. Przy umowie związanej z ich firmą, ale niemającej dla nich charakteru zawodowego, mogą korzystać z części ochrony konsumenckiej. Jej zakres zależy od konkretnego przepisu. Sam NIP na fakturze ani napis „B2B” w regulaminie nie rozstrzygają sprawy. Nie buduj więc sprzedaży na założeniu, że każdy zakup z danymi firmy pozwala zastosować te same wyłączenia odpowiedzialności.

Jakich dokumentów rzeczywiście potrzebujesz?

Przy standardowej subskrypcji podstawą będzie zwykle regulamin świadczenia usług drogą elektroniczną. Powinien określać, co udostępniasz, wymagania techniczne, zasady korzystania, zawarcia i rozwiązania umowy oraz reklamacji. Trzeba też uwzględnić zakaz dostarczania treści bezprawnych. Plan i cenę możesz opisać w zamówieniu lub cenniku, ale dokumenty i ekran zakupu muszą do siebie pasować.

Do tego dochodzi informacja o przetwarzaniu danych, najczęściej w polityce prywatności. Jeśli w aplikacji przetwarzasz dane osobowe w imieniu klienta, potrzebne są również warunki powierzenia, czyli DPA. Polityka prywatności ich nie zastępuje. Nie czekaj z dokumentami i ochroną danych do pierwszej opłaty, jeśli już w bezpłatnym teście świadczysz usługę lub przetwarzasz dane.

Nie każdy mały SaaS potrzebuje osobno podpisywanej umowy i wielostronicowego SLA, czyli ustaleń o poziomie usługi. Zasady wsparcia możesz ująć w regulaminie. Osobny dokument ma sens, gdy rzeczywiście oferujesz odrębne, mierzalne zobowiązania. Liczba plików nie świadczy o jakości zabezpieczenia.

Od bezpłatnego testu do kolejnego obciążenia karty

Ustal dokładnie, kiedy powstaje obowiązek zapłaty. Czy klient po teście sam wybiera płatny plan, czy już przy rejestracji zamawia abonament z odroczoną pierwszą opłatą? Powinien znać cenę, okres rozliczeniowy, czas trwania zobowiązania i zasady odnowienia. Miesięczna płatność nie musi przecież oznaczać umowy, z której można wyjść po miesiącu.

Jeżeli nie potrzebujesz automatycznego przejścia na płatny abonament, możesz zacząć od testu bez podawania karty i osobnego zamówienia płatnego planu. To prostszy organizacyjnie wariant, nie wymóg prawny. Nadal wymaga odpowiednich dokumentów, informacji i zgodnego z prawem przetwarzania danych.

Przy sprzedaży konsumentom informacje wymagane bezpośrednio przed zamówieniem nie mogą być schowane wyłącznie w regulaminie. Przycisk musi jednoznacznie wskazywać obowiązek zapłaty. Samo „rozpocznij test” nie wystarczy, jeżeli ten sam krok oznacza zawarcie odpłatnej umowy.

Wyjaśnij, jak zatrzymać odnowienie, do kiedy należy to zrobić i czy dostęp pozostaje do końca opłaconego okresu. Opisz również nieudaną płatność: ponowienie obciążenia, zawiadomienie, ewentualne zawieszenie i rozwiązanie umowy. Zmiana kwoty w panelu operatora płatności nie zastępuje podstawy do podwyżki i właściwego poinformowania klienta. Przy sprzedaży konsumenckiej swoboda jednostronnych zmian jest dodatkowo ograniczona.

Regulamin udostępnij przed zawarciem umowy tak, aby można go było zapisać i odtworzyć. Zachowuj wersję powiązaną z zamówieniem i dowód jej przyjęcia. Konsumentowi przekaż wymagane potwierdzenie umowy na trwałym nośniku; wiadomość z załączonym regulaminem pozwala uniknąć problemu stale zmieniającego się linku.

Uwzględnij też prawo odstąpienia, co do zasady przysługujące konsumentowi przez 14 dni od zawarcia internetowej umowy o usługę. To co innego niż wyłączenie odnowienia; sam koniec testu nie rozpoczyna automatycznie nowego terminu. Uruchomienie ciągłej usługi nie oznacza jej pełnego wykonania. Nie kopiuj mechanizmu utraty tego prawa z regulaminu sprzedaży e-booków. Osobnej oceny wymagają rozpoczęcie świadczenia przed upływem terminu, ewentualne rozliczenie oraz ustawowe uprawnienia dotyczące zgodności usługi cyfrowej z umową.

Abonament nie powinien przypadkiem obejmować pracy na zamówienie

Opisz funkcje dostępne w kupowanym planie, limity i potrzebne integracje. Oddziel to, co już działa, od planów rozwoju. Zapowiedź funkcji w rozmowie sprzedażowej może mieć znaczenie dla tego, czego klient ma prawo oczekiwać. Zastrzeżenie ukryte w regulaminie nie naprawia każdej obietnicy z oferty.

Sprawdź, skąd pochodzi kod

Jeśli piszesz samodzielnie, ustal, czy wykorzystujesz wyłącznie własną pracę i składniki, na które masz odpowiednie uprawnienia. Kod przygotowany wcześniej w ramach zatrudnienia albo objęty umową z innym podmiotem nie staje się swobodnie dostępny tylko dlatego, że to Ty go napisałeś.

Przy pomocy programisty na B2B zapłacona faktura nie oznacza automatycznego nabycia autorskich praw majątkowych. Potrzebujesz właściwej umowy: przeniesienia praw albo licencji wystarczającej do planowanego wykorzystania. Przy przeniesieniu określ zakres i moment nabycia oraz zachowaj formę pisemną pod rygorem nieważności. Może ją zastąpić kwalifikowany podpis elektroniczny; zwykła wymiana skanów lub standardowy podpis elektroniczny nie są z nim tożsame.

Biblioteki open source nie oznaczają zakazu komercyjnego SaaS. Obowiązki zależą jednak od konkretnej licencji i sposobu użycia składnika. Przy kodzie powstającym z pomocą AI sprawdź warunki narzędzia, pochodzenie wykorzystywanych fragmentów i wkład człowieka. Płatne konto nie jest gwarancją wyłączności ani braku cudzych praw.

PRAKTYKA

Jak ten problem wygląda w praktyce

Przykład

Przykład hipotetyczny

Tworzysz aplikację z asystentem AI, który przygotowuje moduł rezerwacji. Dodajesz go do SaaS i zakładasz, że możesz sprzedawać abonament, a cały kod należy wyłącznie do Ciebie. To jednak dwie różne sprawy. Nawet jeśli warunki narzędzia pozwalają używać wyniku komercyjnie, nie oznacza to automatycznie, że przysługują Ci do niego prawa autorskie. Ochrona zależy od tego, czy i w jakim zakresie kod odzwierciedla twórczy wkład człowieka. Osobno trzeba sprawdzić, czy wykorzystanie wygenerowanych fragmentów nie narusza cudzych praw. Korzystanie z AI nie odbiera ochrony Twoim własnym twórczym fragmentom aplikacji. Nie zakładaj jednak wyłączności do całego wygenerowanego kodu i nie obiecuj jej bez sprawdzenia.

RODO: najpierw przepływ danych, potem polityka

Rozpisz, jakie dane trafiają do aplikacji i dokąd wychodzą. Przy kontach i własnych rozliczeniach zwykle działasz jako administrator. Przy danych, które klient wykorzystuje w swojej działalności, możesz działać jako podmiot przetwarzający na jego rzecz. Role ustala się dla poszczególnych operacji, a nie jedną etykietą dla całego produktu.

DPA powinno odpowiadać rzeczywistej usłudze: określać przetwarzanie, instrukcje, zabezpieczenia, pomoc klientowi i dalszych dostawców. Sprawdź hosting, narzędzia wsparcia oraz zewnętrzne API, w tym AI. Znaczenie mają odbiorcy danych, cele ich wykorzystania i warunki dalszego powierzenia. Sam wybór serwera w EOG nie wyklucza transferów poza ten obszar, choćby przez zdalny dostęp.

Nie opieraj wszystkiego na jednej „zgodzie na RODO”. Dla każdego celu potrzebna jest właściwa podstawa prawna, a zgoda nie zawsze nią będzie. Osobno działają reguły cookies i podobnych technologii: mechanizmy analityczne lub reklamowe, które nie są niezbędne, wymagają właściwej uprzedniej zgody na zapis lub dostęp do informacji w urządzeniu.

Polityka prywatności nie zastąpi kontroli dostępu, zasad przechowywania danych ani przygotowania do incydentu. Mała liczba klientów nie daje ogólnego zwolnienia z RODO.

Obiecuj wsparcie, które możesz zapewnić

Jeżeli pracujesz sam, nie deklaruj całodobowej obsługi, której nie zorganizowałeś. Podaj kanał i godziny wsparcia. Rozróżnij czas reakcji, czyli rozpoczęcia obsługi zgłoszenia, od przywrócenia działania i od usunięcia przyczyny błędu. To trzy różne zobowiązania.

Podobnie z kopiami zapasowymi: ich tworzenie nie dowodzi jeszcze, że potrafisz odtworzyć usługę w obiecanym czasie. Sprawdź odtwarzanie, zakres kopii i możliwą utratę ostatnich zmian. Zależność od hostingu lub innego API również trzeba uwzględnić w obietnicach składanych klientowi.

Odpowiedzialność w B2B można odpowiednio ułożyć, ale nie dowolnie usunąć. Nieważne jest wyłączenie odpowiedzialności za szkodę wyrządzoną umyślnie. Ograniczenia wymagają też odrębnej oceny przy klientach objętych ochroną konsumencką. Ogólne „korzystasz na własne ryzyko” nie zastępuje takiej pracy.

Co klient zabierze, kiedy zrezygnuje?

Ustal, jakie dane można wyeksportować, w jakim formacie i kiedy dostęp zostanie zamknięty. Termin usunięcia danych powinien uwzględniać możliwość ich odebrania, obowiązki prawne oraz sposób wygaszania kopii zapasowych. Regulamin i DPA muszą tu mówić to samo.

Sprawdź również, czy Twój SaaS kwalifikuje się jako usługa przetwarzania danych objęta zasadami zmiany dostawcy z Data Act, stosowanego od 12 września 2025 r. Obowiązki mogą dotyczyć usunięcia przeszkód w zmianie dostawcy i odpowiedniego eksportu. Nie oznacza to obowiązku stworzenia każdej żądanej integracji. Od 12 stycznia 2027 r. zakazane będą objęte tym reżimem opłaty za zmianę dostawcy; wcześniej podlegają ograniczeniu do kosztów bezpośrednich. Nie odkładaj kwalifikacji usługi do chwili odejścia pierwszego klienta.

PODSTAWY PRAWNE

Podstawy prawne

  • Kodeks cywilny — w szczególności przepisy o wzorcach umów, formie czynności prawnych, niedozwolonych postanowieniach i odpowiedzialności kontraktowej.
  • Ustawa o świadczeniu usług drogą elektroniczną — w szczególności art. 8.
  • Ustawa o prawach konsumenta — w szczególności art. 7aa, art. 12, art. 17, przepisy o odstąpieniu i rozdział 5b.
  • Ustawa o prawie autorskim i prawach pokrewnych - w szczególności art. 1, art. 41, art. 53 i przepisy o programach komputerowych.
  • Rozporządzenie (UE) 2016/679 — RODO, w szczególności art. 28, art. 32 i rozdział V.
  • Prawo komunikacji elektronicznej — w szczególności art. 399.
  • Rozporządzenie (UE) 2023/2854 — Data Act, w szczególności regulacje zmiany dostawcy usług przetwarzania danych.
Rozwiń tematE-commerce i technologie ↗RODO i compliance ↗

Materiał ma charakter ogólny i nie stanowi porady prawnej w konkretnej sprawie. Właściwe rozwiązanie zależy od stanu faktycznego, dokumentów i celu biznesowego.

Podsumowanie

Na start potrzebujesz spójnego sposobu sprzedaży, dokumentów odpowiadających produktowi, uporządkowanych praw do kodu i zasad pracy z danymi. Rozbudowane warianty umów, indywidualne SLA i obsługę większych wdrożeń możesz przygotowywać, gdy pojawi się konkretna potrzeba. Nie odkładaj natomiast kwestii, które już dziś dotyczą Twojego modelu sprzedaży.