Umowy SaaS i cloud computing – kluczowe ryzyka prawne dla przedsiębiorców

Cyfrowa transformacja przyspiesza. Coraz więcej firm przenosi swoje procesy do chmury, korzystając z gotowych rozwiązań dostępnych online. To wygodne, szybkie i skalowalne. Z perspektywy biznesowej decyzja często wydaje się oczywista. Jednak z naszej praktyki wynika, że właśnie w tym miejscu zaczynają się realne ryzyka – ukryte w zapisach, które na pierwszy rzut oka wydają się standardowe. Dobrze skonstruowana umowa SaaS czy szerzej umowa cloud computing potrafi zadecydować o bezpieczeństwie całego przedsięwzięcia. 

Czym jest umowa SaaS i cloud computing? 

W najprostszym ujęciu umowa SaaS to umowa o korzystanie z oprogramowania, które nie jest instalowane lokalnie, lecz udostępniane przez dostawcę za pośrednictwem internetu – przedsiębiorca nie kupuje systemu, tylko dostęp do niego. Nie nabywa się programu na własność, tylko płaci się za możliwość korzystania z niego online. 

Szerszą kategorią jest umowa chmurowa obejmująca nie tylko oprogramowanie, ale również infrastrukturę czy środowiska programistyczne, co w praktyce oznacza powierzenie istotnych obszarów działalności zewnętrznemu partnerowi – dlatego tak ważne jest, by jasno określić zasady tej współpracy. Im więcej procesów firmowych przenosisz do chmury, tym większe znaczenie ma treść umowy – bo to ona określa, kto realnie za co odpowiada. 

W rozmowach z przedsiębiorcami często słyszymy: „Chcemy szybko uruchomić CRM, nie chcemy długiego wdrożenia, więc wybieramy chmurę”. To rozsądna intuicja – model SaaS pozwala korzystać z gotowej aplikacji, utrzymywanej i rozwijanej przez dostawcę, bez lokalnej instalacji i zdalnie, przez przeglądarkę. Mówiąc prościej: nie kupujesz programu „na własność”, tylko płacisz za możliwość korzystania z niego. Właśnie ta różnica – dostęp zamiast zakupu – pociąga za sobą konsekwencje prawne: co do licencji, odpowiedzialności, przenoszenia danych czy rozwiązywania współpracy. Dlatego umowa ma w tym modelu kluczowe znaczenie – bo to ona zastępuje klasyczne zasady sprzedaży oprogramowania. 

W praktyce, w umowie cloud computing (umowa chmurowa) to dostawca udostępnia swoje oprogramowanie i zarządza jego środowiskiem, a klient nabywa prawo do korzystania z funkcjonalności zgodnie z regulaminem usługi. W praktyce oznacza to, że wiele kwestii – np. odpowiedzialność czy sposób wykonania usługi, zależy przede wszystkim od postanowień umowy, a nie „gotowych” przepisów. Z perspektywy polskiego prawa umowa cloud computing jest co do zasady umową o świadczenie usług (umową nienazwaną), do której odpowiednio stosuje się przepisy o zleceniu z art. 750 k.c. W praktyce oznacza to, że wiele kwestii – np. odpowiedzialność czy sposób wykonania usługi, zależy przede wszystkim od postanowień umowy, a nie ustawowych standardów. To postanowienia umowne w największym stopniu określają prawa i obowiązki stron. 

Dodatkowo – ponieważ usługa świadczona jest drogą elektroniczną – należy uwzględnić obowiązki z ustawy o świadczeniu usług drogą elektroniczną, w tym wymogi regulaminowe i szczególne zasady odpowiedzialności (np. dla hostingu). W skrócie: dostawca musi spełnić określone obowiązki informacyjne, ale jednocześnie często ogranicza swoją odpowiedzialność. Dostawca wprawdzie musi spełnić pewne minimum prawne, ale zakres jego odpowiedzialności jest zazwyczaj szczegółowo zawężany w samej umowie. Te ramy prawne wzmacnia rozwijające się prawo unijne dotyczące danych i chmury – w szczególności Data Act, który promuje możliwość łatwego przeniesienia danych do innego dostawcy, zmianę dostawcy oraz transparentność warunków usług przetwarzania danych. Innymi słowy, prawo coraz bardziej dąży do tego, aby przedsiębiorca nie był przywiązany do jednego systemu. 

Różnice między SaaS, PaaS i IaaS 

W rozmowach z klientami często widzimy, że pojęcia SaaS, PaaS i IaaS są używane zamiennie, choć ich konsekwencje prawne są zupełnie różne. Dla przedsiębiorcy mogą brzmieć podobnie, ale w praktyce oznaczają zupełnie inny poziom kontroli, odpowiedzialności i ryzyka. 

W modelu SaaS przedsiębiorca otrzymuje gotowe narzędzie – i to dostawca odpowiada za jego działanie. W modelach PaaS i IaaS odpowiedzialność zaczyna się stopniowo przesuwać w stronę klienta. Im większa swoboda technologiczna, tym większa odpowiedzialność po stronie przedsiębiorcy – i tym więcej kwestii trzeba uszczegółowić w umowie chmurowej. Najprościej mówiąc: im bardziej gotowe rozwiązanie, tym mniej masz obowiązków. Im bardziej techniczne i elastyczne – tym więcej rzeczy musisz dopilnować sam.  

Co do zasady – różnice między modelami są następujące: 

• SaaS (Software as a Service): czyli „oprogramowanie jako usługa” – dostajesz gotowy program i po prostu z niego korzystasz; dostawca rozwija i utrzymuje aplikacje chmurowe i udostępnia je klientom przez Internet; infrastrukturą i oprogramowaniem zarządza dostawca, a klient korzysta z funkcji bez lokalnych instalacji. Oznacza to, że nie zajmujesz się techniczną stroną systemu – po prostu logujesz się i pracujesz. To dostawca odpowiada za aktualizacje, bezpieczeństwo i działanie całej aplikacji. 

• PaaS (Platform as a Service): czyli „platforma jako usługa” – dostawca daje środowisko do tworzenia aplikacji, ale to Ty odpowiadasz za to, co na nim zbudujesz; dostawca udostępnia środowisko programistyczne na swojej infrastrukturze; klient kontroluje wdrożone aplikacje, ale nie infrastrukturę i system operacyjny. W tym modelu dostajesz „warsztat pracy” – narzędzia i środowisko – ale to Ty decydujesz, jak z nich skorzystasz i za co bierzesz odpowiedzialność. Jeśli coś nie działa, często trzeba sprawdzić już własną konfigurację, a nie tylko dostawcę. 

• IaaS (Infrastructure as a Service): czyli „infrastruktura jako usługa” – dostajesz serwery i zasoby, ale cała konfiguracja i bezpieczeństwo są po Twojej stronie; dostawca udostępnia zasoby sprzętowe (wirtualne serwery, sieć, pamięć), a klient zarządza systemem operacyjnym i aplikacjami; zakres usług dostawcy jest najmniejszy, a odpowiedzialność za konfigurację i bezpieczeństwo środowiska – największa po stronie klienta. Jest to najbardziej techniczny model – całość ustawień, zabezpieczeń i działania systemu zależy już od Ciebie lub Twojego zespołu 

W praktyce granice między modelami bywają nieostre – nawet dostawcy mogą deklarować „lżejsze” modele, dlatego ważne jest precyzyjne zdefiniowanie w umowie, co faktycznie jest świadczone i jakie są granice obowiązków stron. Bo nazwa usługi w ofercie to jedno, a rzeczywisty podział odpowiedzialności w umowie – to drugie. 

Najprościej zapamiętać to tak: im więcej kontroli masz nad systemem, tym więcej odpowiedzialności bierzesz na siebie. I odwrotnie – im bardziej „gotowe” rozwiązanie, tym więcej ryzyk przejmuje dostawca, ale też tym bardziej jesteś związany jego warunkami. 

Kluczowe postanowienia umów chmurowych 

Z perspektywy kancelarii prawnej najwięcej problemów pojawia się nie wtedy, gdy umowy brakuje, lecz wtedy, gdy jest ona „standardowa”. Typowa umowa SaaS wzór przygotowana przez dostawcę ma jeden cel – zabezpieczyć jego interesy. Innymi słowy: to nie jest dokument „neutralny”, tylko napisany tak, aby chronić drugą stronę. 

Co więcej, takie umowy są często przygotowywane masowo – dla tysięcy klientów – więc z założenia nie uwzględniają specyfiki Twojego biznesu, jego skali ani ryzyk. Dlatego tak istotne są zapisy dotyczące dostępności systemu, zasad odpowiedzialności czy możliwości zakończenia współpracy. Przedsiębiorcy często koncentrują się na funkcjonalności narzędzia, pomijając kwestie takie jak migracja danych czy konsekwencje przestojów. To naturalne – na etapie wyboru systemu liczy się to, „co potrafi”, a nie „co się stanie, gdy przestanie działać”. Dopiero w sytuacji kryzysowej okazuje się, że brak jednego zapisu oznacza realne straty finansowe. 

Właśnie dlatego dobrze przygotowana umowa chmurowa powinna odpowiadać nie tylko na pytanie – jak działa usługa – ale przede wszystkim „co robimy, gdy coś pójdzie nie tak”. W praktyce przy umowie SaaS, umowie chmurowej i szerzej umowie cloud computing rekomendujemy, aby zadbać o: 

1. Jasne SLA i dostępność, czyli konkretne zasady, jak często system może nie działać i co się dzieje, gdy przestaje działać – nie tylko wskaźniki procentowe, ale też sposoby pomiaru, wyłączenia, kary umowne, eskalacja i czas reakcji. SLA to w praktyce „gwarancja działania usługi” – i warto wiedzieć, co naprawdę obejmuje. Kluczowe jest to, czy za niedostępność systemu idzie realna odpowiedzialność dostawcy, czy tylko symboliczne „kredyty” na przyszłe usługi. 

2. Portowalność i exit plan, czyli plan wyjścia z usługi – jak odzyskasz swoje dane i w jakiej formie, tak aby zminimalizować przestój i ryzyko vendor lock in (uzależnienia od jednego dostawcy). W praktyce warto doprecyzować: w jakim formacie otrzymasz dane, ile to potrwa, czy dostawca zapewnia wsparcie i czy proces ma określony harmonogram – bo bez tego „prawo do danych” może być tylko teoretyczne. 

3. Dostęp dostawcy do danych i ich bezpieczeństwo w tym zgodność z RODO/NIS2, środki techniczne i organizacyjne adekwatne do ryzyka oraz możliwość ich sprawdzenia. Innymi słowy: powinieneś wiedzieć nie tylko, że dane są bezpieczne, ale jak konkretnie są chronione i czy możesz to zweryfikować (np. audytem lub certyfikatem). 

4. Transparentność – „kto, co, gdzie”, czyli gdzie fizycznie lub prawnie znajdują się Twoje dane i kto może mieć do nich dostęp.To szczególnie istotne przy dostawcach globalnych – bo dane mogą być przetwarzane w różnych krajach, co ma znaczenie prawne i biznesowe. 

5. Precyzję modelu usługi tak, aby nie dochodziło do mylenia SaaS/PaaS/IaaS – co ma bezpośredni wpływ na zakres odpowiedzialności. W praktyce chodzi o to, żeby jasno ustalić: co robi dostawca, a za co odpowiadasz Ty – bez niedomówień, które ujawniają się dopiero przy problemach. 

6. Spójność z prawem krajowym czyli dopasowanie umowy do przepisów, które obowiązują w Twojej branży (np. cyberbezpieczeństwo).W niektórych przypadkach brak takich zapisów może oznaczać nie tylko ryzyko biznesowe, ale też odpowiedzialność regulacyjną – niezależnie od tego, co przewiduje umowa z dostawcą. 

Podsumowując: kluczowe postanowienia umowy chmurowej to nie „dodatki”, ale fundament – to one decydują o tym, czy w sytuacji problemowej masz realne narzędzia działania, czy tylko ogólne deklaracje. 

Odpowiedzialność dostawcy a odpowiedzialność klienta 

Jednym z najbardziej niedocenianych aspektów jest podział odpowiedzialności. W praktyce spotykamy się z przekonaniem, że skoro system jest „w chmurze”, to dostawca odpowiada za wszystko. Niestety, to mit. W rzeczywistości chmura nie oznacza „braku odpowiedzialności po Twojej stronie” – wręcz przeciwnie. Bardzo często jest odwrotnie – dostawca odpowiada za niewiele, a większość ryzyk pozostaje po stronie klienta. 

Dostawca zabezpiecza swoją odpowiedzialność bardzo precyzyjnie – często ograniczając ją do niewielkiej części wynagrodzenia. W praktyce może to oznaczać, że nawet poważna awaria systemu daje prawo jedynie do symbolicznej rekompensaty. Jednocześnie przedsiębiorca ponosi pełne ryzyko związane z wykorzystaniem systemu w swojej działalności. W efekcie to klient odpowiada wobec swoich kontrahentów, nawet jeśli problem leży po stronie technologii. Czyli: system zawodzi, ale to Ty tłumaczysz się klientowi i ponosisz konsekwencje. 

Jak to uporządkować w umowie SaaS? 

W SaaS po stronie dostawcy jest utrzymanie aplikacji, bezpieczeństwo środowiska i dostępność – ale w umowach często spotykamy daleko idące ograniczenia odpowiedzialności, wyłączenia pośrednich szkód, niskie limity oraz szeroki katalog siły wyższej. Mówiąc prościej: dostawca z góry określa, za co nie odpowiada – i robi to bardzo szeroko. Te klauzule wymagają zbalansowania karami umownymi, mechanizmami SLA oraz precyzyjnym zdefiniowaniem zdarzeń serwisowych i procedur odszkodowawczych. SLA (czyli gwarancja poziomu usługi) powinno w praktyce dawać realne narzędzia reakcji, a nie być tylko deklaracją marketingową. Dlatego trzeba dokładnie sprawdzić, za co dostawca faktycznie odpowiada „na papierze”. 

W PaaS/IaaS granica przesuwa się w stronę klienta: zarządzanie aplikacją, konfiguracją, a często istotną częścią bezpieczeństwa. To oznacza, że nie tylko korzystasz z systemu, ale w dużej mierze sam odpowiadasz za to, czy działa on bezpiecznie i prawidłowo. Dlatego zakres obowiązków i odpowiedzialności za bezpieczeństwo danych oraz ciągłość działania powinien zostać opisany bezlukowo – wraz z reżimem notyfikacji incydentów, testowaniem i audytami. Brak takich zapisów często prowadzi do sytuacji, w której każda ze stron zakłada, że to ta druga odpowiada za dany obszar. Im bardziej zaawansowane rozwiązanie, tym więcej obowiązków przejmujesz – często nie zdając sobie z tego sprawy. 

W niektórych sektorach dodatkowe ciężary nakładają przepisy o cyberbezpieczeństwie (np. KSC/NIS2) – wymagając albo własnych struktur, albo zawarcia odrębnej umowy na usługi cyberbezpieczeństwa spełniające określone standardy. W praktyce oznacza to, że sama umowa chmurowa może nie wystarczyć – a obowiązki regulacyjne i tak pozostają po stronie przedsiębiorcy. 

Dane osobowe i bezpieczeństwo informacji w chmurze 

W realiach regulacyjnych, w których funkcjonują dziś przedsiębiorcy, nie sposób pominąć kwestii danych osobowych. Każda umowa cloud computing powinna być analizowana również pod kątem zgodności z RODO. 

Z naszego doświadczenia wynika, że wiele firm dopiero w trakcie kontroli lub incydentu odkrywa, gdzie faktycznie znajdują się ich dane i kto ma do nich dostęp. Brak precyzyjnych zapisów dotyczących powierzenia przetwarzania danych czy lokalizacji serwerów może prowadzić nie tylko do sankcji finansowych, ale również do utraty zaufania klientów. To jeden z najczęstszych momentów „zderzenia z rzeczywistością” – gdy okazuje się, że firma nie ma pełnej kontroli nad swoimi danymi. 

Co zatem w praktyce?  

Po pierwsze, właściwa dokumentacja powierzenia czyli formalne określenie, że dostawca przetwarza dane w Twoim imieniu i na jakich zasadach. Wzorce klauzul i praktyki wdrożeniowe są dobrym punktem odniesienia, także przy klauzulach bezpieczeństwa w Data Act. 

Po drugie, transparentność co do jurysdykcji i środków zabezpieczeń – dostawca powinien publikować informację, gdzie (prawnie) „leży” infrastruktura dla danej usługi oraz jak ogranicza ryzyka nieuprawnionego dostępu do danych, w tym nieosobowych, przez podmioty trzecie spoza UE. Najprościej mówiąc – przed zawarciem umowy musisz dokładnie wiedzieć, gdzie dane są przechowywane i kto może je zobaczyć 

Po trzecie, bezpieczeństwo i ciągłość działania, czyli co się dzieje w razie awarii i jak szybko system wraca do działania. W tym zakresie ważne jest by w pełno zrozumieć i odnotować  czy w umowie znajdują się procedury zarządzania ciągłością działania (ang. Business Continuity Management, BCM) testy odtworzeniowe, krótka ścieżka notyfikacji incydentów – wszystko to można wprost uregulować w umowie i egzekwować kontraktowo. 

Po czwarte, plan wyjścia i możliwość przeniesienia danych, czyli jak odzyskasz dane po zakończeniu współpracy i czy faktycznie będziesz w stanie dalej z nich korzystać. W praktyce chodzi nie tylko o samo „oddanie danych”, ale o ich format, kompletność i użyteczność. Dane powinny być przekazane w formacie, który pozwala na ich łatwe przeniesienie do innego systemu, bez konieczności ręcznego przetwarzania czy kosztownych konwersji. Warto też ustalić, ile czasu po zakończeniu umowy masz dostęp do danych, czy dostawca zapewnia wsparcie przy migracji oraz czy proces ten ma określony harmonogram. Bez takich ustaleń może się okazać, że formalnie masz prawo do danych, ale w praktyce ich odzyskanie będzie trudne, czasochłonne lub kosztowne. 

Najczęstsze ryzyka prawne w umowach SaaS 

Przedsiębiorcy, którzy trafiają do naszej kancelarii, często zaczynają rozmowę bardzo podobnie. „Na początku wszystko działało bez zarzutu” – słyszymy. System był wygodny, zespół szybko się wdrożył, a decyzja o wyborze dostawcy wydawała się trafiona. 

Problemy pojawiają się dopiero później – zwykle w najmniej odpowiednim momencie. System przestaje działać, dostęp do danych jest ograniczony albo firma chce zmienić dostawcę. Wtedy przedsiębiorca wraca do umowy i… odkrywa, że postanowienia, które wcześniej wyglądały „standardowo”, w praktyce działają na jego niekorzyść. 

Nagle okazuje się, że odpowiedzialność dostawcy została ograniczona do niewielkiej części miesięcznego wynagrodzenia. Czyli nawet jeśli przestój powoduje realne straty biznesowe, rekompensata jest symboliczna. Zdarza się też, że gwarancje dostępności usług istnieją tylko „na papierze” – a brak precyzyjnych zapisów sprawia, że trudno dochodzić jakichkolwiek roszczeń. 

W innych przypadkach wychodzi na jaw tzw. vendor lock-in, czyli uzależnienie od jednego dostawcy. Firma chce zmienić system, ale okazuje się, że nie ma prostego sposobu na przeniesienie danych. Nie wiadomo, w jakim formacie zostaną udostępnione, ile to potrwa ani czy dostawca realnie pomoże w migracji. Formalnie dane należą do przedsiębiorcy, ale w praktyce ich odzyskanie jest trudne, kosztowne albo czasochłonne. 

Często brakuje też jasno opisanego planu wyjścia (exit planu) – czyli co dokładnie dzieje się po zakończeniu umowy. Czy system działa jeszcze przez jakiś czas? Czy dane są dostępne? Czy można je pobrać w całości? Bez tych zapisów zakończenie współpracy może sparaliżować operacyjnie firmę. 

Kolejnym problemem jest brak przejrzystości po stronie dostawcy. Dokumenty są rozproszone, informacje o danych niepełne, a klient tak naprawdę nie wie, gdzie jego dane są przechowywane i kto ma do nich dostęp. W sytuacji incydentu lub kontroli to właśnie przedsiębiorca ponosi konsekwencje. 

Nie można też pominąć kwestii bezpieczeństwa i ciągłości działania. W wielu umowach brakuje konkretnych procedur na wypadek awarii – nie ma jasnych zasad informowania o incydentach, testów bezpieczeństwa czy planów przywracania systemu. Dopóki wszystko działa, nie jest to widoczne. Ale gdy pojawia się problem, brak tych mechanizmów staje się bardzo odczuwalny. 

Dodatkowo w bardziej zaawansowanych modelach (PaaS, IaaS) często dochodzi do niejasnego podziału odpowiedzialności. W praktyce oznacza to, że ani dostawca, ani klient nie mają pełnej kontroli nad niektórymi obszarami – co tworzy luki w bezpieczeństwie i utrudnia ustalenie, kto odpowiada za ewentualne błędy. 

Szczególnie często widzimy te problemy przy dokumentach typu „umowa SaaS wzór”. Wyglądają profesjonalnie, ale są tworzone jako uniwersalne – czyli niedopasowane do konkretnego biznesu i jego ryzyk. 

Dlatego w praktyce wygląda to tak: dopóki wszystko działa, umowa „nie przeszkadza”. Ale gdy coś pójdzie nie tak – to właśnie ona decyduje o tym, czy firma ma realne narzędzia ochrony, czy zostaje z problemem sama. 

I to jest najważniejsze ryzyko: przekonanie, że standardowa umowa SaaS wystarczy – podczas gdy w rzeczywistości to właśnie ona często przesądza o skali problemów. 

Dlaczego warto negocjować umowę SaaS z prawnikiem 

Z biznesowego punktu widzenia negocjowanie umowy to element zarządzania ryzykiem. To moment, w którym można realnie wpłynąć na przyszłe bezpieczeństwo operacyjne firmy. Właśnie tutaj – jeszcze przed podpisaniem – rozstrzyga się, czy w sytuacji kryzysowej masz narzędzia działania, czy tylko dobre intencje drugiej strony. 

W praktyce wielu przedsiębiorców traktuje umowę jako ostatni etap wdrożenia – formalność, którą trzeba „odhaczyć”, żeby zacząć korzystać z systemu. Tymczasem to jeden z najważniejszych momentów całego procesu – bo to wtedy ustala się zasady gry na kolejne lata współpracy. 

Przedsiębiorcy, którzy mają za sobą trudne doświadczenia z dostawcami usług chmurowych, bardzo często podkreślają jedno – że żałują, iż nie poświęcili więcej uwagi umowie na etapie jej zawierania. Bo kiedy pojawia się problem, na negocjacje jest już za późno – zostają tylko postanowienia umowne, które wcześniej wydawały się „standardowe”. 

W praktyce kilka dobrze sformułowanych postanowień może zdecydować o tym, czy problem techniczny pozostanie jedynie niedogodnością, czy przerodzi się w poważny kryzys biznesowy. To różnica między kilkugodzinną przerwą w działaniu systemu a realną utratą klientów, danych lub przychodów. 

Dlatego umowa SaaS czy umowa chmurowa nie powinna być traktowana jako formalność. To dokument, który realnie chroni interesy przedsiębiorcy – o ile zostanie właściwie przygotowany i świadomie wynegocjowany. 

Rola prawnika w tym procesie nie polega na „komplikowaniu umowy”, ale na zadawaniu właściwych pytań: 

– co się stanie, jeśli system przestanie działać? 

– jak odzyskasz dane? 

– kto ponosi odpowiedzialność i w jakim zakresie? 

– czy możesz bezpiecznie zmienić dostawcę? 

To właśnie te pytania najczęściej nie padają – a później okazują się kluczowe. Na etapie negocjacji warto wprost sięgnąć po dobre praktyki i standardowe klauzule opracowywane na gruncie rynku usług chmurowych – czyli gotowe, sprawdzone rozwiązania, które można dostosować do swojej sytuacji. Nie chodzi o wymyślanie umowy od zera, ale o świadome wykorzystanie tego, co już działa i zostało przetestowane w praktyce. 

Dzięki temu można szybko i konkretnie doprecyzować najważniejsze obszary: sposób zmiany dostawcy, zasady dostępu do danych, poziom bezpieczeństwa czy odpowiedzialność za przestoje. A przede wszystkim – przełożyć techniczne i ogólne zapisy na realne zabezpieczenia biznesowe. W efekcie dobrze wynegocjowana umowa SaaS nie jest kosztem, ale inwestycją – która zwraca się dokładnie w tym momencie, w którym pojawia się pierwszy problem. 

Bartosz Bilicz

Partner, adwokat