Umowa SaaS z klientem biznesowym — co uregulować przed rozpoczęciem sprzedaży?

Jeden kontrakt czy zestaw dokumentów

Umowa SaaS najczęściej składa się z kilku współpracujących dokumentów. Główna umowa albo ogólne warunki określają zasady korzystania z usługi, odpowiedzialność i zakończenie współpracy. Formularz zamówienia wskazuje wybrany plan, liczbę użytkowników, cenę i okres subskrypcji. SLA opisuje dostępność i wsparcie, natomiast umowa powierzenia reguluje przetwarzanie danych osobowych.

Przy większych klientach dochodzą załączniki bezpieczeństwa, wymagania wdrożeniowe i opis integracji. Dokumenty powinny wskazywać kolejność pierwszeństwa na wypadek rozbieżności. Bez tego indywidualne uzgodnienia handlowe mogą pozostawać w konflikcie ze standardowym regulaminem dostawcy.

Model zawierania umowy musi odpowiadać procesowi sprzedaży. Inaczej wygląda kontrakt negocjowany z dużą firmą, a inaczej samoobsługowy zakup przez stronę internetową. W tym drugim przypadku trzeba zapewnić możliwość zapoznania się z regulaminem przed zamówieniem oraz zachować dowód zaakceptowania właściwej wersji dokumentu.

Zakres usługi powinien odpowiadać produktowi

Umowa nie powinna obiecywać więcej, niż system faktycznie zapewnia. Należy opisać główne funkcje, sposób uzyskania dostępu, obsługiwane środowiska oraz wymagania techniczne po stronie klienta. Jeżeli część funkcjonalności znajduje się w dokumentacji internetowej, umowa powinna jednoznacznie ją wskazywać.

Ważne jest rozróżnienie standardowej usługi od prac dodatkowych. Migracja danych, konfiguracja, szkolenia, integracja z systemem klienta albo rozwój indywidualnej funkcji mogą wymagać osobnego zamówienia i harmonogramu.

Trzeba również ustalić zasady wprowadzania zmian do produktu. Dostawca powinien móc rozwijać usługę i aktualizować jej interfejs, ale nie powinien jednostronnie usuwać funkcji, które były istotnym powodem zawarcia umowy. Przy większej zmianie warto przewidzieć wcześniejsze zawiadomienie klienta, okres przejściowy albo możliwość rozwiązania umowy.

Użytkownicy, konta i dozwolony sposób korzystania

W modelu SaaS rozliczenie może zależeć od liczby użytkowników, aktywnych kont, przetworzonych operacji, miejsca w pamięci lub innych parametrów. Umowa powinna wyjaśniać, jak są one mierzone i co się stanie po przekroczeniu limitu.

Klient zwykle odpowiada za zarządzanie dostępami w swojej organizacji, prawidłowe uprawnienia użytkowników i ochronę danych logowania. Dostawca powinien z kolei określić zasady odzyskiwania konta, uwierzytelniania i reagowania na podejrzaną aktywność.

Postanowienia o dozwolonym korzystaniu nie powinny ograniczać się do ogólnego zakazu działań sprzecznych z prawem. Warto wskazać zasady dotyczące automatycznych zapytań, obchodzenia zabezpieczeń, udostępniania kont, przetwarzania niedozwolonych treści i korzystania z API.

Cena, subskrypcja i automatyczne odnowienie

Warunki finansowe powinny określać nie tylko cenę, lecz także sposób jej naliczania. Przy modelu usage-based potrzebna jest możliwość zweryfikowania wykorzystania usługi. Jeżeli opłata zależy od liczby użytkowników, trzeba ustalić, czy liczone są wszystkie utworzone konta, aktywni użytkownicy czy maksymalna liczba dostępów w danym okresie.

Umowa powinna wskazywać długość okresu rozliczeniowego, termin płatności, walutę, podatki i konsekwencje opóźnienia. Czasowe zablokowanie usługi nie powinno następować bez ostrzeżenia, szczególnie gdy system ma znaczenie dla bieżącej działalności klienta.

Przy automatycznym odnowieniu należy określić termin rezygnacji oraz sposób informowania o zmianie ceny. Możliwość jednostronnej podwyżki powinna mieć obiektywne podstawy i zapewniać klientowi odpowiedni czas na podjęcie decyzji przed kolejnym okresem subskrypcji.

SLA powinno mierzyć to, co ma znaczenie

Samo zapewnienie dostępności na poziomie 99,9% niewiele mówi, jeżeli umowa nie określa sposobu jej obliczania. Trzeba ustalić okres pomiaru, źródło danych oraz zdarzenia wyłączone z kalkulacji, takie jak zapowiedziane prace serwisowe, awaria infrastruktury klienta albo działanie siły wyższej.

SLA powinno rozróżniać czas reakcji od czasu usunięcia problemu. Dostawca może być w stanie szybko rozpocząć analizę awarii, ale nie zawsze może zagwarantować jej zakończenie w krótkim terminie. Realistyczne zobowiązanie może obejmować czas pierwszej odpowiedzi, częstotliwość aktualizacji i docelowe przywrócenie działania zależne od priorytetu incydentu.

Warto też określić środki przysługujące klientowi. Service credits mogą stanowić podstawową rekompensatę za niedotrzymanie SLA, ale przy powtarzających się albo długotrwałych awariach klient powinien mieć prawo do zakończenia umowy. Dostawca musi natomiast uważać, aby katalog gwarancji nie pozostawał w sprzeczności z realnymi możliwościami technicznymi produktu.

Dane osobowe, bezpieczeństwo i podwykonawcy

Jeżeli dostawca przetwarza dane osobowe w imieniu klienta, potrzebna jest umowa powierzenia odpowiadająca rzeczywistemu podziałowi ról. Powinna określać przedmiot i czas przetwarzania, rodzaje danych, kategorie osób oraz prawa i obowiązki klienta.

W dokumencie należy również uregulować środki bezpieczeństwa, korzystanie z dalszych podmiotów przetwarzających, obsługę żądań osób, audyty i postępowanie po zakończeniu współpracy. Termin zgłoszenia incydentu klientowi powinien umożliwiać mu realizację własnych obowiązków, a jednocześnie uwzględniać czas potrzebny dostawcy na wstępną weryfikację zdarzenia.

Lista podwykonawców powinna odpowiadać faktycznej architekturze usługi. Jeżeli dane trafiają poza Europejski Obszar Gospodarczy, trzeba ustalić mechanizm transferu i zapewnić klientowi informacje potrzebne do jego oceny. Sama deklaracja, że dostawca „przestrzega RODO”, nie zastępuje odpowiedniej dokumentacji.

Prawa do produktu, danych i rezultatów

Dostawca zachowuje prawa do oprogramowania, interfejsu, dokumentacji i rozwijanych funkcji. Klient otrzymuje prawo korzystania z usługi w zakresie wynikającym z abonamentu. Umowa powinna określać, czy dostęp obejmuje spółki z grupy, zewnętrznych współpracowników i integratorów.

Dane wprowadzane przez klienta powinny pozostać pod jego kontrolą. Dostawca potrzebuje natomiast uprawnienia do ich przetwarzania w zakresie koniecznym do świadczenia usługi, zapewnienia bezpieczeństwa i realizacji wsparcia.

Osobno warto uregulować dane telemetryczne i statystyczne. Jeżeli dostawca chce wykorzystywać zagregowane informacje do rozwijania produktu, zakres takiego użycia powinien być przejrzysty i nie pozwalać na odtworzenie poufnych danych klienta.

Jeżeli produkt wykorzystuje generatywną sztuczną inteligencję, trzeba dodatkowo odpowiedzieć na pytania o wykorzystanie danych do trenowania, prawa do wyników, dopuszczalne zastosowania i sposób informowania o ograniczeniach systemu.

Odpowiedzialność powinna odpowiadać ryzyku usługi

Typowa umowa SaaS przewiduje limit odpowiedzialności powiązany z wartością opłat uiszczonych w określonym okresie. Sam limit nie rozwiązuje jednak wszystkich problemów. Trzeba ustalić, jakie roszczenia obejmuje, a jakie sytuacje pozostają poza nim.

Szczególnej analizy wymagają naruszenia poufności, utrata danych, incydenty bezpieczeństwa oraz roszczenia dotyczące praw własności intelektualnej. Dostawca powinien ocenić, które ryzyka może kontrolować, a które wynikają z nieprawidłowego używania systemu przez klienta lub działania zewnętrznej infrastruktury.

Nie warto kopiować nieograniczonej odpowiedzialności z kontraktu przygotowanego dla zupełnie innego produktu. Poziom zabezpieczeń powinien uwzględniać rodzaj przetwarzanych danych, znaczenie systemu dla działalności klienta, wartość umowy i dostępne ubezpieczenie.

Zakończenie umowy i eksport danych po Data Act

Plan wyjścia powinien być częścią umowy od początku. Należy określić dostępne formaty eksportu, czas na pobranie danych, zakres wsparcia migracyjnego oraz termin ich usunięcia. Bez tych ustaleń klient może zostać uzależniony od dostawcy, a dostawca — zobowiązany do nieograniczonego przechowywania danych po zakończeniu abonamentu.

Od 12 września 2025 r. obowiązuje unijny Data Act. Część usług SaaS może mieścić się w pojęciu usługi przetwarzania danych objętej regulacją. W takim przypadku umowa musi wspierać zmianę dostawcy lub przejście na własną infrastrukturę klienta i nie może tworzyć nieuzasadnionych przeszkód technicznych, organizacyjnych ani kontraktowych.

Regulacja wymaga między innymi określenia procedury zmiany dostawcy, kategorii danych możliwych do przeniesienia, okresu przejściowego, czasu na ich pobranie oraz zasad późniejszego usunięcia. Maksymalny okres wypowiedzenia inicjujący zmianę dostawcy nie powinien przekraczać dwóch miesięcy, a podstawowy okres przejściowy wynosi maksymalnie 30 dni. Po jego zakończeniu klient powinien mieć co najmniej 30 dni na pobranie danych.

Do 12 stycznia 2027 r. dostawca może jeszcze przewidywać ograniczone opłaty związane ze zmianą usługi, ale nie powinny one przekraczać kosztów bezpośrednio związanych z tym procesem. Od tej daty opłaty za zmianę dostawcy mają zostać wycofane. Dlatego regulaminy przygotowane kilka lat temu mogą wymagać istotnej aktualizacji.