Umowy wdrożeniowe w chmurze (cloud computing)

Umowy wdrożeniowe coraz częściej dotyczą projektów realizowanych w środowiskach chmurowych. Warto więc zadać sobie pytanie, czy i w jaki sposób wpływa to na kształt i treść samej umowy.

Z jednej strony nadal mamy do czynienia z klasyczną umową wdrożeniową. Wciąż musimy wybrać model umowy, wraz z jego zaletami i wadami: model predykcyjny oparty na metodyce Waterfall, w którym z góry określamy kluczowe parametry rozwiązania, albo model adaptacyjny oparty na metodyce Agile, ze zwinnym podejściem do zarządzania projektem (więcej o tym pisaliśmy tutaj i tutaj)

Tak jak dotychczas, konieczne jest również udzielenie sobie odpowiedzi na kluczowe pytania i precyzyjne opisanie w umowie najważniejszych elementów projektu, które omawialiśmy w ostatnim artykule.

Z drugiej jednak strony wdrożenie w środowisku chmurowym wprowadza dodatkowe, nowe elementy, na które musimy zwrócić szczególną uwagę. Przede wszystkim integralną częścią takiego wdrożenia, która powinna zostać uregulowana już w umowie wdrożeniowej, są zasady korzystania z rozwiązania oraz zasady dostępu do systemu i jego dalszego utrzymania.

Dostawca usług chmurowych

Po pierwsze, należy jednoznacznie określić, kto jest dostawcą platformy chmurowej, na której zostanie wdrożone rozwiązanie, oraz kto odpowiada za jej udostępnienie. Może to być Wykonawca realizujący wdrożenie na własnych zasobach chmurowych albo podmiot trzeci, który udostępnia swoje zasoby Wykonawcy, a w konsekwencji także Zamawiającemu. Równie istotne jest jednoznaczne wskazanie, czy serwery, na których zainstalowane jest środowisko chmurowe, znajdują się fizycznie na terenie UE, czy poza Unią.

Z punktu widzenia odpowiedzialności Wykonawcy wobec Zamawiającego, jak też z punktu widzenia odpowiedzialności za dane osobowe, będą to ustalenia o kluczowym znaczeniu.

Licencja czy usługa?

W dalszej kolejności pojawia się kluczowe pytanie o podstawę prawną korzystania z wdrożonego rozwiązania chmurowego. Według części umów – powinna to być licencja na dostęp do oprogramowania. Według pozostałych umów – nie ma żadnej licencji, a dochodzi wyłącznie do korzystania usług Wykonawcy. Jak zatem do tego podejść?

Odpowiedź będzie godna prawnika – to zależy.

Jako punkt wyjścia przyjmijmy sposób korzystania z oprogramowania działającego w infrastrukturze chmurowej oraz „głębokość” dostępu do zasobów chmurowych, jaką otrzymuje użytkownik biznesowy.

• Po pierwsze, może to być model SaaS (Software as a Service), w którym korzystamy wyłącznie z gotowej aplikacji dostarczanej przez dostawcę i odpowiadamy de facto jedynie za dane wprowadzane do aplikacji, podczas gdy za wszystkie procesy związane z instalacją i udostępnieniem aplikacji, w tym za system i infrastrukturę, odpowiada dostawca chmury.
• Po drugie, może to być model PaaS (Platform as a Service), w którym od dostawcy otrzymujemy gotowe środowisko do tworzenia i wdrażania aplikacji; dostawca odpowiada za utrzymanie platformy i infrastrukturę, a my koncentrujemy się na samym oprogramowaniu i jego kodzie.
• Po trzecie, możliwy jest model IaaS (Infrastructure as a Service), w którym dostawca udostępnia jedynie zasoby infrastruktury w chmurze, a my sami odpowiadamy za całą instalowaną w tym środowisku architekturę, system i oprogramowanie.

W przypadku modelu SaaS, najczęściej spotykanego przy codziennym, biznesowym korzystaniu z systemów informatycznych, „korzystanie” z aplikacji po stronie użytkownika co do zasady nie dotyczy ani kodu, ani samej aplikacji. Sprowadza się ono głównie do wprowadzania danych do aplikacji i wykonywania na nich operacji. W związku z tym możemy bez większych wątpliwości przyjąć, że w tym modelu zwielokrotnienia oprogramowania dokonuje zasadniczo dostawca, a po naszej stronie pojawia się przede wszystkim usługa dostępu do aplikacji, w ramach której możemy wprowadzać określone dane i na nich pracować. [Na potrzeby tego artykułu celowo pomijam bardziej złożone aspekty zwielokrotniania w pamięci roboczej i w tle, dla których odpowiedzią jest m.in. instytucja dozwolonego użytku z art. 75 ust. 1 Prawa autorskiego).

Inaczej wygląda to w przypadku modeli PaaS i IaaS, w których otrzymujemy kontrolę – odpowiednio – nad aplikacjami lub nad całym systemem. Uzyskujemy wtedy możliwość ingerowania w samo oprogramowanie, jego instalacji i modyfikacji, w tym zmian w kodzie. W takich sytuacjach trudno jest obronić tezę, że po naszej stronie nie dochodzi do zwielokrotnienia lub zmiany programu komputerowego. Dlatego przy korzystaniu z formuły PaaS lub IaaS konieczne jest zapewnienie odpowiednich uprawnień licencyjnych.

Czy to oznacza, że korzystanie z usług chmurowych w formule SaaS nie może odbywać się na podstawie licencji udzielanej przez dostawcę? Niekoniecznie. Również w przypadku SaaS można przyjąć konstrukcję umowną, w której korzystamy nie tyle z samej usługi, ile z utworu komputerowego – konkretnego programu udostępnianego przez Internet. Choć w mojej ocenie nie jest to rozwiązanie w pełni prawidłowe, w praktyce jest ono powszechnie stosowane i akceptowane zarówno przez doktrynę, jak i orzecznictwo oraz organy podatkowe (przy czym skutki podatkowe takiego podejścia są zgoła odmienne).

Odpowiedzialność za dostęp

Kolejnym kluczowym zagadnieniem, które należy uwzględnić w umowie, jest odpowiedzialność za dostęp do systemu oraz za zapewnienie ciągłości tego dostępu. W relacji Zamawiającego z Wykonawcą wdrożenia trzeba jednoznacznie określić, kto odpowiada za poszczególne etapy dostępu do aplikacji i danych:

• do jakiego poziomu dostępu odpowiada Zamawiający,
• w jakim zakresie odpowiada Wykonawca,
• od jakiego poziomu dostępu odpowiada wyłącznie dostawca chmury.

W ślad za tym Zamawiający powinien jednoznacznie ustalić i potwierdzić z Wykonawcą, po pierwsze – w jakich sytuacjach może wystąpić brak dostępu do wdrożonego systemu (np. w przypadku niedostępności usług chmurowych), a po drugie – jakie są zasady reakcji Wykonawcy lub dostawcy chmury na niedostępność systemu, za którą odpowiedzialność ponosi, odpowiednio, Wykonawca lub dostawca usług chmurowych.

Powyższe kwestie są zwykle uregulowane w standardowych warunkach kontraktowych stosowanych przez Wykonawców i dostawców usług chmurowych, określanych jako SLA (service level agreement). Z punktu widzenia bezpieczeństwa realizacji umowy wdrożeniowej kluczowe jest jednak, aby już na etapie jej zawierania Zamawiający miał pełną świadomość i rozumiał, jakie będą zasady dostępności wdrażanego rozwiązania. W praktyce często zdarza się bowiem, że SLA zapewniane przez Wykonawcę znacząco różni się od SLA oferowanego przez dostawcę chmury, o czym Zamawiający dowiaduje się dopiero w przypadku awarii systemu.

Konkluzja

Podsumowując, specyfika umowy wdrożeniowej dla projektu realizowanego w chmurze wymaga szczególnego podejścia. Choć formalnie mamy do czynienia z „klasyczną” umową wdrożeniową, to jednak, aby zapewnić bezpieczeństwo całego przedsięwzięcia, nie wystarczy przeredagowanie tradycyjnej umowy wdrożeniowej on‑premise i dopisanie kilku ogólnych wzmianek o „dostępie chmurowym”. Wdrożenie chmurowe oznacza bowiem inny zakres standaryzacji po stronie Wykonawcy, inne możliwości kontroli po stronie Zamawiającego i inny model dystrybucji ryzyka.