Kluczowe ryzyka dla zamawiających w kontraktach IT

W pierwszej kolejności warto wskazać na dwa podstawowe modele umów wdrożeniowych występujące w obrocie. Po pierwsze, model tradycyjny, tzw. waterfall, w którym już na etapie zawarcia umowy jest znany przedmiot umowy i istnieje możliwość jego precyzyjnego określenia. Sprawdzenie rezultatów prac realizowanych w tym modelu ma miejsce najczęściej dopiero na etapie testowania oprogramowania. Po drugie, częściej już stosowany model agile, w którym oprogramowanie jest dostarczane w krótkotrwałych iteracjach (fazach), zakończonych wytworzeniem fragmentów oprogramowania (systemu), które są poddawane testowaniu na bieżąco, po zamknięciu danej fazy. Warto prześledzić, na jakie aspekty umowy wdrożeniowej warto zwrócić szczególną uwagę.

Podstawowym elementem umowy o dostarczenie systemu IT powinno być precyzyjne określenie parametrów samego systemu, co standardowo ma miejsce w załączniku do umowy (wraz z ewentualnym dodatkowym opisem w treści umowy głównej).

Zawarcie prawidłowych postanowień w tym zakresie pozwala na ograniczanie ryzyka sytuacji spornych, gdzie wykonawca odmawia realizacji części prac ze względu na nieprecyzyjne postanowienia umowne lub – z tej samej przyczyny - zamawiający nie płaci wynagrodzenia za konkretną partię prac. W praktyce wypracowanie przedmiotu umowy (systemu IT), głównie w modelu waterfall, jest poprzedzane tzw. analizą przedwdrożeniową, podczas której strony określają przedmiot zapotrzebowania zamawiającego i założenia co do mającego powstać systemu.

O ile jednak kwestia określenia przedmiotu umowy jest oczywista w przypadku prac realizowanych w modelu waterfall, to w odniesieniu do systemów tworzonych w trybie agile, precyzyjne określenie przedmiotu umowy na etapie jej zawierania nastręcza wiele trudności, a często jest niewykonalne, ponieważ istotą umów zawieranych w modelu agile jest brak pewności co do ostatecznego kształtu prac wykonawcy. W konsekwencji, w przypadku realizacji prac w tym modelu konieczne jest sprecyzowanie poszczególnych faz (iteracji) projektu i wskazanie, że szczegóły prac i ewentualne modyfikacje ich pierwotnego zakresu będą uzgadniane podczas spotkań roboczych. Istotne w tym kontekście jest też umożliwienie zamawiającemu prawa odstąpienia od umowy na etapie jej wykonania (np. w razie uznania, że kierunek prac nie jest właściwy), za zapłatą odpowiedniej części wynagrodzenia na rzecz wykonawcy. 

Umowa wdrożeniowa powinna wyraźnie przesądzać, że stanowi ona umowę o osiągnięcie konkretnego rezultatu (umowę o dzieło) a nie umowę o podejmowanie starannych działań (umowa zlecenia). Takie ukształtowanie umowy powinno pozwolić na przesądzenie, że w razie nieosiągnięcia umówionego rezultatu (wytworzenie systemu IT) zamawiający może odmówić wykonawcy zapłaty wynagrodzenia, co najmniej w części. W braku precyzyjnych postanowień w tym zakresie, istnieje ryzyko uznania, że wykonawca był zobowiązany jedynie do podejmowania starannych działań, a nie do wytworzenia rezultatu. Do takich wniosków doszedł Sąd Okręgowy w Łodzi w wyroku z dnia 4 sierpnia 2016 roku w związku z umową o wdrożenie systemu pilotażowego (sygn. akt XIII Ga 442/16). 

Praktycznie w przypadku każdego systemu IT zamawiający powinien mieć zagwarantowane prawa własności intelektualnej umożliwiające (co najmniej) wprowadzanie zmian w jego oprogramowaniu i dokumentacji. Do rzadkości należą sytuacje, gdzie system IT przez cały okres jego gospodarczego wykorzystania ma charakter statyczny; najczęściej będzie on podlegał zmianom, wynikającym chociażby ze standardowych aktualizacji systemu. W konsekwencji, umowa wdrożeniowa powinna bezwarunkowo zawierać postanowienia przenoszące na zamawiającego wszystkie prawa autorskie do systemu IT bądź umożliwiające zamawiającemu korzystanie z systemu z prawem wprowadzania modyfikacji (szeroka licencja). W każdym przypadku konieczne jest precyzyjne wskazanie pól eksploatacji oprogramowania (i jego dokumentacji), na które wyraża zgodę zamawiający, ponieważ w braku ich wskazania umowa w części przenoszącej prawa autorskie będzie nieważna (art. 41 ust. 2 Prawa autorskiego).

W praktyce wykonawcy niechętnie przenoszą na zamawiających całość praw własności intelektualnej do systemu, ponieważ w takim przypadku nie mają możliwości, w uproszczeniu, wielokrotnej sprzedaży tego samego oprogramowania (co może obniżać rentowność ich prac). W konsekwencji, w umowach o wykonanie systemu IT znacznie częściej spotykane jest rozwiązanie polegające na udzieleniu zamawiającemu niewyłącznej licencji umożliwiające mu korzystanie z oprogramowania. W takich przypadkach mogą pojawiać się jednak problemy prawne, w szczególności wynikające z przepisów Prawa autorskiego ograniczenie, zgodnie z którym umowa licencyjna uprawnia do korzystania z utworu w okresie 5 lat na terytorium państwa siedziby licencjobiorcy, chyba że w umowie postanowiono inaczej (art. 66 ust. 1 Prawa autorskiego). Jednocześnie, w razie postanowienia inaczej, czyli zawarcia umowy licencyjnej na czas nieoznaczony, należy mieć na uwadze kolejny przepis, tj. art. 68 Prawa autorskiego, przewidujący, że w braku odmiennych postanowień umownych licencję udzieloną na czas nieoznaczony twórca może wypowiedzieć z zachowaniem terminów umownych, a w ich braku – z zachowaniem rocznego okresu wypowiedzenia, rozpoczynającego bieg na koniec roku kalendarzowego (w którym złożono wypowiedzenie).

Przepis art. 68 ust. 2 Prawa autorskiego wskazuje z kolei, że licencję udzieloną na okres dłuższy niż 5 lat uważa się, po upływie tego terminu, za udzieloną na czas nieoznaczony (co implikowałoby konsekwencje, o których mowa powyżej, czyli możliwość wypowiedzenia licencji przez wykonawcę). Przepisy te oznaczają swego rodzaju dead-lock dla zamawiającego, którego interes nie jest w pełni zabezpieczony ani w przypadku zawarcia umowy na czas nieoznaczony (ze względu na możliwość jej wypowiedzenia przez wykonawcę) ani na czas oznaczony przekraczający 5 lat (ponieważ po tym czasie umowa przekształci się w zawartą na czas nieoznaczony).

W praktyce powyższy problem prawny jest często rozwiązywany poprzez zawarcie umowy na okres znacznie przekraczający 5 lat, z możliwością jej wypowiedzenia po wskazanym okresie czasu. Spotyka się również umowy w których możliwość wypowiedzenia umowy licencyjnej jest wyłączona. Nie ulega wątpliwości, że wypracowanie rozwiązania w tym zakresie wymaga analizy okoliczności konkretnego przypadku i wyważenia interesów stron.  

W zależności od ustaleń między stronami, wykonawca może mieć dostęp do danych osobowych, w odniesieniu do których zamawiający jest administratorem i które znajdą się w systemie (np. w przypadku umowy o wykonanie systemu ds. kadrowo-płacowych). W takim przypadku bardzo istotne jest zawarcie umowy powierzenia przetwarzania danych osobowych, o stopniu szczegółowości odpowiednim dla rozmiaru i znaczenia danego systemu IT dla zamawiającego. Szczególnie ważne jest poprzedzenie zawarcia takiej umowy odpowiednim sprawdzeniem wykonawcy (procesora) pod kątem zapewnienia zgodności jego działań z przepisami Ogólnego Rozporządzenia o Ochronie Danych nr 2016/679.

Chodzi głównie o takie kwestie, jak stosowanie przez wykonawcę właściwych zabezpieczeń organizacyjnych i technicznych przetwarzanych danych, takie jak procedury i polityki ochrony danych czy mechanizmy uwierzytelniające (np. dwupoziomowe systemy logowania). Należy pamiętać, że w razie ewentualnych naruszeń podmiotem ponoszącym odpowiedzialność w „pierwszej linii”, narażonym na kary ze strony organu nadzorczego (PUODO) jest zamawiający (jako administrator danych). Kara może zostać nałożona w szczególności za niedołożenie starań mających na celu ustalenie, czy procesor (tu: wykonawca) gwarantuje właściwy poziom ochrony danych osobowych. Przykładem takiego działania jest decyzja Prezesa UODO o sygn. DKN.5130.2215.2020, w której jednym z powodów nałożenia na administratora kary administracyjnej w wysokości ok. 4,9 mln złotych był właśnie brak weryfikacji podmiotu przetwarzającego przez administratora.

Jednym z kluczowych elementów w umowach IT są również postanowienia dotyczące odbioru prac wykonawcy. Z reguły prace wykonawców podzielone są na poszczególne etapy (fazy) i wykonawca będzie oczekiwał płatności cząstkowych po ukończeniu każdej z faz. W tym kontekście istotne jest, aby umowa IT przewidywała, że warunkiem rozpoczęcia kolejnej fazy prac jest należyte wykonanie i bezwarunkowy odbiór prac objętych poprzedzającą fazą. Nic nie stoi również na przeszkodzie, aby przewidzieć, że w ramach zabezpieczenia część należności z faktur za poszczególne fazy (etapy) prac będzie potrącana i wypłacana po ostatecznym odbiorze całości projektu. 

Niejednokrotnie dochodzi do sytuacji, gdy zamówiony system IT nie działa zgodnie z oczekiwaniami zamawiającego. Aby odpowiednio zabezpieczyć interesy zamawiającego na taką okoliczność, konieczne jest wprowadzenie odpowiednich postanowień umownych. Istotną rolę w tym zakresie odgrywa mechanizm kar umownych, który umożliwia bieżące obniżanie należności wykonawcy za poszczególne etapy umowy, w razie jej niewykonywania lub nienależytego wykonywania przez wykonawcę. Takie zaniechania wykonawcy mogą przejawiać się w opóźnieniu w realizacji poszczególnych etapów prac czy usterkach w funkcjonowaniu systemu na etapie jego wykonania. W razie gdyby ewentualna szkoda poniesiona przez zamawiającego przekraczała wysokość kar umownych, zamawiający powinien mieć zapewnioną możliwość dochodzenia od wykonawcy odszkodowania w pełnej wysokości szkody. Jest to kwestia, o której warto pamiętać, ponieważ zgodnie z przepisami kodeksu cywilnego (art. 484 § 1 k.c.) brak zastrzeżenia umownego w tym zakresie wyklucza możliwość dochodzenia takiego dodatkowego odszkodowania.

Istotne jest również uregulowanie odpowiedzialności wykonawcy za wady i usterki systemu IT, które mogą ujawnić się po odbiorze oprogramowania. Pomimo, iż zgodnie z przepisami kodeksu cywilnego zamawiającemu w takich przypadkach co do zasady przysługują uprawnienia na podstawie przepisów o rękojmi za wady, zastosowanie tych przepisów jest w kontraktach IT często wyłączane. W zamian za to, strony zawierają osobne umowy serwisowe, przewidujące odrębne wynagrodzenie dla wykonawcy za gotowość do usunięcia usterek. Oczywiście nic nie stoi natomiast na przeszkodzie, aby w umowie wdrożeniowej strony utrzymały odpowiedzialność wykonawcy na podstawie przepisów o rękojmi. 

Nie ulega wątpliwości, że umowy wdrożeniowe powinny przewidywać możliwość jej rozwiązania przez każdą ze stron. Z perspektywy zamawiającego, o ile oczywiste jest, że powinien on mieć możliwość rozwiązania umowy w sytuacjach obiektywnych, takich jak niewykonywanie czy nienależyte wykonywanie umowy przez wykonawcę (np. rażące opóźnienia względem przewidzianego harmonogramu prac), bądź rażące pogorszenie sytuacji finansowej wykonawcy, to warto jeszcze rozważyć przyznanie zamawiającemu prawa do przedterminowego rozwiązania umowy z przyczyn nieleżących po stronie wykonawcy. Powodem skorzystania z tego prawa może być choćby zmiana planów zamawiającego co do korzystania z danego systemu IT. Kwestia ta jest szczególnie istotna w przypadku umów realizowanych w modelu agile, w których z istoty rzeczy strony mają świadomość, że po wykonaniu kilku faz projektu zamawiający może uznać, że dany system nie spełnia jego oczekiwań lub zmierza w niepożądanym kierunku (nawet w braku zaniedbań po stronie wykonawcy). Aby zminimalizować ryzyko chaosu, który może powstać w przypadku odstąpienia od umowy, warto aby umowa przewidywała w miarę możliwości szczegółowy scenariusz wyjścia (tzw. exit plan), w którym strony uregulują m.in., co stanie się z kodami źródłowymi czy dokumentacją systemu IT, którą wykonawca stworzył oraz zasady rozliczeń między stronami. 

Tak jak wskazano powyżej, prawidłowa konstrukcja umowy wdrożeniowej niesie ze sobą wiele wyzwań, ze względu na stopień komplikacji tego rodzaju kontraktów i dynamicznie zmieniające się otoczenie gospodarcze. Warto zadbać o ich właściwą treść, zabezpieczającą interesy obu stron, już na etapie zawierania umowy, tak aby uniknąć wątpliwości i sporów związanych z wykonaniem czy rozliczeniem umów wdrożeniowych.