Umowa SaaS – czym jest i co powinno się w niej znaleźć? Praktyczny przewodnik dla firm

Firma wdraża nowy system CRM. Dostawca przesyła umowę – 40 stron po angielsku albo regulamin z linkiem w stopce maila. Prawnik zajęty, deadline goni, więc zarząd podpisuje. Rok później okazuje się, że dostawca podniósł cenę o 30% z miesięcznym wyprzedzeniem, dane klientów są przetwarzane przez podwykonawców w USA, a przeniesienie się do konkurencji oznacza utratę dostępu do danych w ciągu 48 godzin od wypowiedzenia.

To nie jest scenariusz z sali sądowej. To codzienność polskich firm, które traktują umowę SaaS jak formalność, a nie jak narzędzie zarządzania ryzykiem.

Umowa SaaS reguluje dostępność systemu, bezpieczeństwo danych Twoich klientów, odpowiedzialność za awarie, warunki wypowiedzenia i dziesiątki innych kwestii, które mogą realnie zaszkodzić działalności firmy. W tym artykule wyjaśniamy, czym umowa SaaS różni się od licencji na oprogramowanie, co musi się w niej znaleźć i – co równie ważne – na jakie klauzule zwrócić szczególną uwagę przed podpisaniem.

Czym jest umowa SaaS – definicja i podstawa prawna

SaaS, czyli Software as a Service, to model dostarczania oprogramowania, w którym usługodawca udostępnia aplikację przez internet, a usługobiorca korzysta z niej w przeglądarce lub przez dedykowaną aplikację, bez instalowania czegokolwiek na własnej infrastrukturze. Płatność ma zazwyczaj charakter subskrypcyjny – miesięczny lub roczny.

Z prawnego punktu widzenia umowa SaaS należy do kategorii umów nienazwanych – nie ma dla niej odrębnego rozdziału w Kodeksie cywilnym. Jej charakter najlepiej oddaje art. 750 KC, który nakazuje stosować do umów o świadczenie usług nieuregulowanych osobno przepisy o umowie zlecenia. Uzupełniającą podstawę stanowi art. 8 ustawy z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną, który nakłada na usługodawcę obowiązek stosowania regulaminu i udostępnienia go usługobiorcy przed zawarciem umowy.

W praktyce oznacza to, że strony mają dużą swobodę w kształtowaniu treści umowy – ale właśnie dlatego jej zapisy mają tak duże znaczenie. Brak precyzji lub przemilczenie kluczowych kwestii to ryzyko, które zawsze wraca w postaci sporu.

Model SaaS a klasyczna licencja – fundamentalna różnica prawna

Najczęstszym błędem przy zawieraniu umów SaaS jest myślenie o nich przez pryzmat licencji. To dwa odrębne reżimy prawne, które różnią się w kilku kluczowych aspektach.

Kryterium	Umowa SaaS	Licencja
Co dostaje klient?	Dostęp do aplikacji przez internet	Kopię oprogramowania do instalacji
Infrastruktura	Dostawca odpowiada za serwery	Klient zarządza własnym sprzętem
Aktualizacje	Wliczone w subskrypcję	Często osobna umowa utrzymaniowa
Własność IP	Dostawca zachowuje pełnię praw do oprogramowania	Dostawca zachowuje prawa, klient otrzymuje kopię oprogramowania oraz prawo korzystania z niej na warunkach określonych w umowie licencyjnej
Dane	Na serwerach dostawcy lub w chmurze	Na infrastrukturze klienta
Elastyczność	Wysoka – skalowanie liczby użytkowników	Niska – renegocjacja warunków

W modelu SaaS klient nie otrzymuje kopii oprogramowania – uzyskuje wyłącznie zdalny dostęp do aplikacji hostowanej przez dostawcę. To ma bezpośrednie przełożenie na to, kto ponosi odpowiedzialność za dostępność systemu, kto przetwarza dane i co się dzieje po zakończeniu umowy.

Brak klasycznej licencji w umowie SaaS nie oznacza jednak, że kwestie prawa autorskiego nie mają znaczenia. Wiele aplikacji SaaS wymaga instalacji wtyczek lub agentów po stronie klienta – a tam już wchodzi się w pole eksploatacji objęte prawem autorskim, które należy wprost uregulować w umowie.

Regulamin czy umowa SaaS – kiedy który dokument wystarczy?

Dostawca SaaS ma do wyboru trzy ścieżki formalne: ogólny regulamin dostępny na stronie, indywidualna umowa z każdym klientem albo model mieszany – regulamin jako baza, umowa jako uzupełnienie dla klientów enterprise.

Regulamin jako jedyny dokument sprawdza się przy usługach B2C i standaryzowanych usługach B2B, gdzie warunki są identyczne dla wszystkich i gdzie klient nie negocjuje poszczególnych zapisów. Warunkiem skuteczności jest jednak to, że klient miał realną możliwość zapoznania się z regulaminem przed zawarciem umowy – samo umieszczenie linku w stopce strony to za mało. Sądy wielokrotnie uznawały, że inkorporacja regulaminu była nieskuteczna właśnie z powodu braku czytelnego poinformowania klienta.

Przy kontraktach B2B – szczególnie gdy w grę wchodzą dane osobowe, niestandardowe SLA, integracje z systemami klienta lub wysoka wartość kontraktu – indywidualna umowa jest koniecznością. Daje obu stronom pewność co do zakresu świadczenia i eliminuje ryzyko sporu o to, co „miało być”.

Co musi zawierać umowa SaaS? Obowiązkowe elementy

Dobra umowa SaaS reguluje co najmniej sześć obszarów. Brak któregokolwiek z nich to potencjalny spór – pytanie tylko, kiedy się pojawi.

Przedmiot umowy i opis funkcjonalności

Przedmiot umowy to pozornie oczywisty element, który w praktyce jest źródłem największej liczby sporów. Zapis w stylu „dostawca zapewnia dostęp do platformy X zgodnie z aktualną ofertą” nie chroni nikogo – ani dostawcy, ani klienta.

Umowa powinna precyzyjnie wskazywać: jakie moduły i funkcjonalności są objęte subskrypcją, w jakiej wersji oprogramowania, czy aktualizacje są wliczone w cenę i czy obejmują nowe funkcje, czy też tylko poprawki bezpieczeństwa, a także jakie są limity użytkowników, przestrzeni dyskowej lub liczby operacji miesięcznie.

Jeżeli aplikacja korzysta z elementów sztucznej inteligencji – na przykład do rekomendacji, scoringu lub automatycznego przetwarzania dokumentów – zakres i zasady działania tych funkcji powinny być opisane wprost. Ma to znaczenie nie tylko dla oczekiwań klienta, ale też w kontekście AI Act, o którym piszemy w dalszej części artykułu.

SLA – gwarantowana dostępność i jej konsekwencje

SLA (Service Level Agreement) to część umowy definiująca parametry jakościowe świadczonej usługi. W umowie SaaS jest to jeden z najważniejszych elementów – bez precyzyjnie określonego SLA klient nie ma skutecznego narzędzia dochodzenia roszczeń za niedostępność systemu.

Kluczowe parametry SLA, które powinny znaleźć się w każdej umowie:

Dostępność – wyrażona procentowo w skali miesiąca lub roku. 99,9% dostępności miesięcznie to prawie 44 minuty dopuszczalnej niedostępności w miesiącu. 99,5% to już ponad 3,5 godziny. Różnica może być istotna dla systemów krytycznych.

Gwarantowana dostępność	Dopuszczalna niedostępność/miesiąc
99,9%	~43 minuty
99,5%	~3,6 godziny
99,0%	~7,2 godziny
98,0%	~14,4 godziny

Definicja niedostępności – czy planowane okna serwisowe wliczają się do czasu niedostępności? Kiedy zgłoszenie jest uznawane za incydent krytyczny? Brak tych definicji oznacza, że dostawca zawsze może argumentować, że przerwa była planowana lub niekrytyczna.

Czas reakcji i czas naprawy – określenie, ile czasu ma dostawca na potwierdzenie przyjęcia zgłoszenia, np. 2 godziny dla incydentu krytycznego i ile na jego rozwiązanie, np. 8 godzin roboczych. Dostawcy często wpisują wyłącznie czas reakcji, pomijając czas rozwiązania – a to ta druga liczba naprawdę ma znaczenie.

Mechanizm kredytów SLA – co klient dostaje w zamian za niedotrzymanie parametrów? Kredyt na kolejny okres subskrypcji jest standardem, ale warto sprawdzić: czy jest przyznawany automatycznie, czy wymaga wniosku klienta, i czy stanowi jedyne dostępne roszczenie z tytułu niedostępności.

Zapis „dołożymy wszelkich starań, aby zapewnić dostępność” nie jest SLA – to deklaracja bez konsekwencji. Dobre SLA zawiera konkretne liczby i konkretne konsekwencje ich niedotrzymania – najczęściej w postaci kar umownych naliczanych za każdy dzień lub godzinę przestoju powyżej gwarantowanego poziomu albo automatycznych kredytów na kolejny okres subskrypcji. Warto zadbać o to, żeby mechanizm był uruchamiany automatycznie – nie na wniosek klienta, który musi udowodnić i upomnieć się o należność.

Prawa autorskie i własność intelektualna – co klient naprawdę dostaje?

W modelu SaaS dostawca zachowuje pełnię autorskich praw majątkowych do oprogramowania. Klient nie nabywa żadnych praw do kodu, layoutu ani architektury systemu – uzyskuje wyłącznie prawo do korzystania z aplikacji w zakresie określonym umową.

Ta zasada ma kilka praktycznych konsekwencji, które warto zrozumieć przed podpisaniem:

Po pierwsze, własność danych wprowadzonych przez klienta to zupełnie osobna kwestia. Dane operacyjne, bazy klientów, dokumenty – to własność klienta, nie dostawcy. Umowa powinna to wprost potwierdzać i precyzować, w jakim formacie i w jakim terminie klient może te dane wyeksportować, zarówno w trakcie trwania umowy, jak i po jej zakończeniu.

Po drugie, jeśli klient zleca dostawcy tworzenie elementów dedykowanych – niestandardowych raportów, integracji, modyfikacji – umowa musi jednoznacznie wskazywać, kto nabywa prawa do tych elementów. Bez takiego zapisu domyślnie pozostają one przy dostawcy.

Po trzecie, jeśli korzystanie z aplikacji wymaga instalacji jakichkolwiek komponentów po stronie klienta, pola eksploatacji objęte licencją muszą być w umowie wymienione wprost – polskie prawo autorskie nie pozwala na domniemywanie pól eksploatacji ani ich określania na przyszłość.

Ochrona danych osobowych i umowa powierzenia przetwarzania

Każda umowa SaaS, w ramach której dostawca przetwarza dane osobowe klientów usługobiorcy, wymaga zawarcia umowy powierzenia przetwarzania danych osobowych – obowiązek ten wynika wprost z art. 28 RODO.

W modelu SaaS dostawca działa najczęściej jako podmiot przetwarzający – przetwarza dane w imieniu klienta, który pozostaje administratorem. To klient odpowiada przed swoimi klientami i organami nadzorczymi za to, jak dane są przetwarzane – dlatego DPA nie jest formalnością, lecz realnym narzędziem zarządzania tym ryzykiem.

Umowa powierzenia przetwarzania danych osobowych powinna precyzować co najmniej:

• kategorie danych osobowych i cel ich przetwarzania,
• czas przetwarzania,
• stosowane środki bezpieczeństwa techniczne i organizacyjne,
• zasady podpowierzania – czy dostawca może angażować podwykonawców i jakich,
• obowiązki dostawcy w razie naruszenia ochrony danych,
• procedurę zwrotu lub usunięcia danych po zakończeniu umowy.

Szczególną uwagę należy poświęcić klauzuli subprocesors – liście podwykonawców, którym dostawca powierza dane. Jeśli aplikacja działa na infrastrukturze chmurowej, dane osobowe klientów mogą być przetwarzane przez dodatkowe podmioty – a administrator musi mieć nad tym kontrolę i wyrazić na to zgodę.

Odpowiedzialność dostawcy – cap, wyłączenia i pułapki

Klauzule ograniczenia odpowiedzialności to jeden z najbardziej negocjowanych elementów umów SaaS. Dostawca chce maksymalnie zawęzić zakres swoich zobowiązań, klient – mieć realną ochronę na wypadek poważnej awarii lub naruszenia danych.

Standardowe mechanizmy stosowane w umowach SaaS:

1. Zakres odpowiedzialności, cap – górna granica odszkodowania, najczęściej wyrażona jako wielokrotność opłat abonamentowych z ostatnich 12 miesięcy. Cap na poziomie rocznej wartości kontraktu jest rozwiązaniem uznanym rynkowo; cap na poziomie jednej opłaty miesięcznej to sygnał, że umowa jest pisana wyłącznie z myślą o dostawcy.
2. Wyłączenie odpowiedzialności za utracone zyski – dostawcy standardowo wyłączają odpowiedzialność za utracone zyski. To akceptowalne o tyle, o ile umowa zachowuje odpowiedzialność za rzeczywistą szkodę.
3. Wyłączenie odpowiedzialności z tytułu rękojmi – możliwe w relacjach B2B, ale powinno być kompensowane precyzyjnym SLA i procedurą reklamacyjną.

Pełne wyłączenie odpowiedzialności dostawcy – czyli zapis w stylu „dostawca nie ponosi żadnej odpowiedzialności za jakiekolwiek szkody” – nie tylko jest trudny do obrony przed sądem, ale też sygnalizuje złą wiarę drugiej strony. Umowa, w której jedna ze stron nie ponosi żadnej odpowiedzialności, nie jest umową wzajemną.

Wypowiedzenie umowy i migracja danych – klucz do bezpiecznego wyjścia

Klauzule dotyczące zakończenia umowy to element, o którym firmy myślą zbyt późno – zazwyczaj dopiero wtedy, gdy chcą zmienić dostawcę albo gdy dostawca ich wyprzedza.

Umowa powinna precyzyjnie regulować:

1. Okres wypowiedzenia – standardem rynkowym dla umów na usługi B2B jest wypowiedzenie ze skutkiem na koniec okresu rozliczeniowego z wyprzedzeniem co najmniej 30 dni. Krótszy termin działa na korzyść dostawcy; dłuższy może być pułapką dla klienta, który chce się przenieść.
2. Prawo do natychmiastowego rozwiązania umowy – obustronnie, w przypadku istotnego naruszenia umowy przez drugą stronę. Warto zdefiniować, co jest istotnym naruszeniem np. naruszenie poufności, nieuprawniony dostęp do danych, upadłość dostawcy.
3. Migracja danych – co dzieje się z danymi po zakończeniu umowy? Umowa powinna określać: format eksportu np. CSV, JSON, XML, termin dostępności danych po wypowiedzeniu np. 30 lub 90 dni, zobowiązanie dostawcy do usunięcia danych po upływie tego terminu z potwierdzeniem pisemnym. Brak tych zapisów oznacza, że klient jest zdany na dobrą wolę dostawcy w momencie, gdy ta dobra wola może być już historią.
4. Uzależnienie od dostawcy – vendor lock to realne ryzyko biznesowe i prawne. Dostawcy, którzy wiedzą, że przeniesienie się do konkurencji jest kosztowne lub niemożliwe bez utraty danych, mają silniejszą pozycję negocjacyjną przy kolejnym odnowieniu umowy. Dlatego klauzula o migracji danych powinna być negocjowana przed podpisaniem – nie rok później.

Klauzule, które warto negocjować jako klient

To, co dostawca wpisuje do wzoru umowy, jest punktem startowym negocjacji – nie dokumentem do podpisania. Poniżej omawiamy klauzule, które mają największe znaczenie praktyczne, a które firmy najczęściej pomijają podczas negocjacji.

Zmiana cennika w trakcie trwania umowy

Standardowe wzory umów SaaS przyznają dostawcy prawo do zmiany cennika z określonym wyprzedzeniem – najczęściej 30 dni. Oznacza to, że dostawca może podnieść cenę bez Twojej zgody, a Ty możesz tylko wypowiedzieć umowę.

Jako klient warto negocjować: dłuższy okres wyprzedzenia np. 60 lub 90 dni, ograniczenie maksymalnej podwyżki w roku np. do wskaźnika inflacji lub określonego procentu, a w kontraktach długoterminowych – zamrożenie ceny na określony czas. W relacjach B2B jest to standardowy element negocjacji, który większość dostawców zaakceptuje, jeśli o niego wprost zapyta.

Podpowierzanie danych i podwykonawcy chmurowi

Większość aplikacji SaaS działa na infrastrukturze zewnętrznych dostawców chmury, takich jak Amazon Web Services, Microsoft Azure czy Google Cloud. Dane Twoich klientów mogą być przetwarzane na serwerach w Irlandii, Frankfurcie albo – jeśli umowa milczy na ten temat – przez serwery poza Europejskim Obszarem Gospodarczym.. To nie jest hipotetyczne ryzyko: Prezes UODO nakładał kary właśnie za brak kontroli nad subprocesors i transfer danych do krajów trzecich bez odpowiednich zabezpieczeń.

Umowa powinna zawierać pełną listę podwykonawców z możliwością przetwarzania danych, procedurę powiadamiania klienta o planowanych zmianach w tej liście, a także wskazanie, w jakich krajach dane są przechowywane.

Prawo do audytu bezpieczeństwa

Duże firmy i regulowane sektory takie jak finanse, zdrowie, energetyka, wymagają prawa do weryfikacji bezpieczeństwa dostawcy – bezpośrednio lub przez zewnętrznych audytorów. Warto, żeby umowa przewidywała prawo do przeprowadzenia audytu bezpieczeństwa raz w roku albo żeby dostawca zobowiązał się do regularnego przedstawiania raportów z certyfikacji (ISO 27001, SOC 2 Type II).

Dostawca, który kategorycznie odmawia jakiejkolwiek formy weryfikacji bezpieczeństwa, to dostawca wysokiego ryzyka – niezależnie od tego, jak wyglądają jego materiały marketingowe.

Kary umowne i kredyty SLA

Jak wspomniano wyżej, mechanizm kredytów SLA przyznawany automatycznie jest standardem rynkowym. Warto jednak sprawdzić: czy kredyt SLA jest jedynym dostępnym roszczeniem klienta z tytułu niedostępności, czy też klient zachowuje prawo do dochodzenia odszkodowania uzupełniającego na zasadach ogólnych.

Zapis, który wyłącza wszelkie inne roszczenia poza kredytem SLA, oznacza w praktyce, że za wielogodzinną awarię w krytycznym momencie klient dostanie kilka procent miesięcznej opłaty. To może być akceptowalne przy niskiej wartości kontraktu; przy systemach krytycznych – jest nie do przyjęcia.

Umowa SaaS a nowe regulacje UE

Otoczenie regulacyjne dla umów SaaS zmienia się szybciej niż kiedykolwiek. Trzy rozporządzenia UE, które weszły w życie w ostatnich latach, mają bezpośrednie przełożenie na treść umów SaaS – a ich ignorowanie to realne ryzyko prawne.

AI Act a umowy SaaS z elementami sztucznej inteligencji

Rozporządzenie 2024/1689 “akt w sprawie sztucznej inteligencji” (AI Act) wprowadza obowiązki zarówno dla dostawców systemów AI, jak i dla firm, które te systemy wdrażają. Jeśli kupujesz SaaS, który zawiera elementy AI – systemy do scoringu, automatycznej klasyfikacji dokumentów, rekomendacji kadrowych, analizy ryzyka – musisz wiedzieć, że część obowiązków compliance spada na Ciebie jako deployer’a.

W praktyce oznacza to, że umowa SaaS powinna:

• wskazywać, czy aplikacja zawiera systemy AI wysokiego ryzyka w rozumieniu AI Act,
• określać, jakie informacje dostawca przekazuje klientowi na potrzeby wypełnienia obowiązków strony odpowiadającej za wdrożenie (dokumentacja techniczna, instrukcja użytkowania, informacje o ograniczeniach systemu),
• regulować odpowiedzialność za zapewnienie nadzoru ludzkiego nad decyzjami podejmowanymi z udziałem AI.

AI Act jest w fazie stopniowego wdrożenia – pełne stosowanie przepisów AI Act  nastąpi w 2027 r. (o ile terminy wejścia w życie przepisów nie zostaną wydłużone przez dyskutowane obecnie propozycje zawarte w projekcie rozporządzenia zmieniającego rozporządzenie ws. sztucznej inteligencji (tzw. Digital Omnibus AI).  Firmy, które kupują lub wdrażają SaaS z elementami AI, powinny już teraz weryfikować, czy umowy spełniają te wymagania.

Data Act i przenoszalność danych

Przepisy rozporządzenia Parlamentu Europejskiego i Rady (UE) 2023/2854 z dnia 13 grudnia 2023 r. (akt w sprawie danych), (Data Act), które stosuje się  od września 2025 r., mają na celu m. in. ułatwienie użytkownikom usług chmurowych zmianę dostawcy tych usług, co należy rozumieć jako możliwość eksportu danych do konkurencyjnego dostawcy w standardowym, maszynowo czytelnym formacie, bez zbędnych przeszkód technicznych i bez dodatkowych opłat (począwszy od 12 stycznia 2027 r. – do tej daty dostawcy mogą nakładać na klienta obniżone opłaty z tytułu zmiany dostawcy).

Dla umów SaaS oznacza to, że klauzule dotyczące migracji danych muszą być teraz zgodne z Data Act – nie wystarczy ogólny zapis o możliwości eksportu na wniosek. Dostawca świadczący usługi chmurowe w UE jest zobowiązany do zapewnienia technicznej możliwości przeniesienia danych, a umowa powinna to wprost potwierdzać.

Data Act wzmacnia też pozycję negocjacyjną klientów wobec dostawców, którzy dotychczas stosowali vendor lock-in jako świadomą strategię biznesową. Jeśli Twoja obecna umowa SaaS jest starsza niż rok, warto sprawdzić, czy klauzule dotyczące danych są zgodne z nowymi przepisami.

DSA i obowiązki platform SaaS

Rozporządzenie 2022/2065 o usługach cyfrowych (DSA) obowiązuje od 2024 r. i dotyczy przede wszystkim platform internetowych udostępnianych szerszemu gronu odbiorców. Dla większości aplikacji SaaS działających w modelu B2B wyłącznie wobec przedsiębiorców DSA nie ma bezpośredniego zastosowania. Natomiast jeśli Twoja platforma SaaS pozwala użytkownikom na publikowanie treści, udostępnianie danych osobom trzecim lub zawiera funkcje o charakterze platformy pośredniej – zakres obowiązków wynikających z DSA należy zweryfikować indywidualnie.

Checklista – 12 pytań przed podpisaniem umowy SaaS

Zanim podpiszesz umowę SaaS, zweryfikuj następujące kwestie:

1. Czy umowa precyzyjnie opisuje zakres funkcjonalności i co się dzieje, gdy dostawca wycofuje poszczególne funkcje?
2. Czy SLA zawiera konkretne liczby dotyczące dostępności, czasu reakcji i czasu rozwiązania incydentów?
3. Czy umowa zawiera lub odsyła do umowy powierzenia przetwarzania danych osobowych?
4. Czy jest lista podwykonawców przetwarzających dane i procedura powiadamiania o jej zmianach?
5. Czy wiesz, w jakich krajach są przechowywane dane Twoich klientów?
6. Czy zakres odpowiedzialności dostawcy jest adekwatny do wartości kontraktu i ryzyka biznesowego?
7. Czy umowa gwarantuje Ci eksport danych w standardowym formacie i przez jaki czas po jej zakończeniu?
8. Jakie są warunki zmiany cennika i z jakim wyprzedzeniem dostawca musi Cię powiadomić?
9. Czy masz prawo do wypowiedzenia umowy w przypadku istotnego naruszenia przez dostawcę bez konieczności czekania na koniec okresu rozliczeniowego?
10. Jeśli aplikacja zawiera elementy AI – czy umowa zawiera informacje wymagane przez AI Act dla deployerów?
11. Czy klauzule dotyczące przenoszalności danych są zgodne z Data Act?
12. Czy umowa określa sąd właściwy i prawo właściwe, szczególnie jeśli dostawca ma siedzibę poza Polską?

FAQ – najczęściej zadawane pytania o umowę SaaS

1. Czym różni się umowa SaaS od licencji na oprogramowanie?

W umowie SaaS klient uzyskuje zdalny dostęp do aplikacji hostowanej przez dostawcę – nie otrzymuje kopii oprogramowania ani nie instaluje go we własnej infrastrukturze. Licencja na oprogramowanie przenosi na klienta prawo do korzystania z konkretnej kopii programu zainstalowanej lokalnie. Różnica ma istotne znaczenie prawne: odpowiedzialność za dostępność systemu, przetwarzanie danych i utrzymanie leży po stronie dostawcy SaaS, nie klienta.

2. Czy regulamin może zastąpić umowę SaaS?

W relacjach B2C i przy standaryzowanych usługach B2B – tak, pod warunkiem że klient miał realną możliwość zapoznania się z regulaminem przed zawarciem umowy. Przy kontraktach enterprise, usługach wymagających indywidualnego SLA lub przetwarzaniu danych wrażliwych regulamin jako jedyny dokument jest niewystarczający. Konieczna jest indywidualna umowa, która precyzuje warunki współpracy i zawiera DPA.

3. Co to jest SLA i jakie parametry powinno zawierać?

SLA Service Level Agreement to część umowy definiująca mierzalne parametry jakości usługi: gwarantowaną dostępność, czas reakcji na incydenty krytyczne, czas ich rozwiązania, sposób powiadamiania o przerwach oraz konsekwencje niedotrzymania zobowiązań – najczęściej kredyty na kolejny okres subskrypcji.

4. Czy dostawca SaaS musi zawrzeć umowę powierzenia przetwarzania danych?

Tak, jeśli w ramach świadczonej usługi przetwarza dane osobowe klientów usługobiorcy. Obowiązek ten wynika z art. 28 RODO i dotyczy każdego przypadku, gdy dostawca ma dostęp do danych osobowych w imieniu klienta – bez względu na to, czy dane są aktywnie przetwarzane, czy jedynie przechowywane.

5. Co dzieje się z danymi po zakończeniu umowy SaaS?

To zależy wyłącznie od tego, co reguluje umowa. Bez odpowiednich zapisów klient jest zdany na dobrą wolę dostawcy. Dobrze skonstruowana umowa powinna określać: termin dostępności danych po wypowiedzeniu np. 30 lub 90 dni, format eksportu, zobowiązanie dostawcy do usunięcia danych po upływie tego terminu z pisemnym potwierdzeniem. Data Act wzmacnia te uprawnienia dla usług chmurowych – ale konkretne warunki nadal zależą od zapisów umownych.

6. Jak ograniczyć ryzyko tzw. vendor lock-in?

Przede wszystkim: negocjując umowę przed jej podpisaniem, a nie po roku użytkowania. Kluczowe zapisy to: precyzyjne warunki eksportu danych w standardowym formacie, rozsądny termin dostępu do danych po zakończeniu umowy, zakaz stosowania przez dostawcę technicznych barier utrudniających migrację. Data Act z 2025 r. przyznaje firmom prawo do przenoszalności danych – można się na nie powoływać wprost w negocjacjach.

7. Czy AI Act dotyczy firm korzystających z SaaS opartego na sztucznej inteligencji?

Tak. AI Act nakłada obowiązki nie tylko na dostawców systemów AI, ale też na firmy, które wdrażają te systemy we własnej działalności. Jeśli korzystasz z SaaS zawierającego systemy AI wysokiego ryzyka np. do oceny pracowników, scoringu kredytowego, diagnostyki medycznej, masz obowiązki w zakresie nadzoru ludzkiego, prowadzenia dokumentacji i – w określonych przypadkach – rejestracji systemu. Szczegółowy zakres tych obowiązków zależy od kategorii ryzyka systemu.

8. Czy umowa SaaS musi mieć formę pisemną?

Przepisy Kodeksu cywilnego nie wymagają formy pisemnej dla umów o świadczenie usług. Umowa SaaS może być zawarta elektronicznie – przez akceptację regulaminu, kliknięcie przycisku „Akceptuję warunki” lub wymianę maili. W relacjach B2B, szczególnie przy wyższej wartości kontraktu, forma pisemna lub elektroniczna z kwalifikowanym podpisem jest jednak zdecydowanie rekomendowana – ułatwia dowodzenie treści umowy w ewentualnym sporze.

Podsumowanie

Umowa SaaS to nie formalność towarzysząca zakupowi oprogramowania – to dokument regulujący dostępność kluczowych systemów biznesowych, bezpieczeństwo danych Twoich klientów i warunki wyjścia ze współpracy, gdy ta przestanie służyć interesom firmy. Źle skonstruowana umowa to ryzyko, które materializuje się dokładnie wtedy, gdy jest najbardziej kosztowne: podczas awarii, naruszenia danych lub zmiany dostawcy.

Kluczowe zasady, o których warto pamiętać: SLA bez konkretnych liczb to deklaracja bez wartości; DPA to nie opcja, lecz wymóg RODO; klauzule o migracji danych należy negocjować przed podpisaniem, nie po roku użytkowania; AI Act i Data Act zmieniają realia umów SaaS – niezależnie od tego, czy dostawca o tym wspomina.

Prawnicy Rubicon Legal specjalizują się w obsłudze firm IT i przedsiębiorstw wdrażających nowe technologie – w tym w negocjowaniu, opiniowaniu i konstruowaniu umów SaaS zarówno po stronie dostawcy, jak i nabywcy. Jeśli stoisz przed podpisaniem istotnej umowy SaaS lub chcesz zweryfikować obowiązujące kontrakty pod kątem zgodności z AI Act i Data Act, zapraszamy do kontaktu.