Co sprawdzić w umowie IT, w SLA i w licencji na oprogramowanie?

Dlaczego przegląd umów IT jest szczególnie ryzykowny

Umowy o dzieło w IT i umowy serwisowe należą do obszarów, w których rzeczywistość prawna i techniczna często się ścierają. Programista lub dostawca oprogramowania obiecuje działający system, ale co się stanie, gdy projekt opóźni się o miesiące? Jakie mają Państwo prawa, jeśli oprogramowanie nie odpowiada uzgodnionej specyfikacji?

Prawnicy z kancelarii adwokackiej ARROWS spotykają się z przypadkami, w których organy statutowe firm podpisały umowę bez dokładnej analizy prawnej, a później odkryły poważne braki. Często chodzi o sytuacje, w których dostawca zastrzegł sobie prawo do jednostronnej zmiany funkcjonalności lub cennika bez zgody klienta.

Kolejnym częstym problemem jest kara umowna za przedterminowe rozwiązanie umowy, która jest nieproporcjonalnie wysoka i w praktyce uniemożliwia zmianę dostawcy. Gdy umowa zostanie podpisana, Państwa pozycja negocjacyjna dramatycznie słabnie, a zmiany trudno przeforsować. W kontraktach IT warto więc zająć się ustaleniem procedur zmian, klauzul wyjścia i sankcji w ramach umów i negocjacji.

Główne ryzyka prawne w umowach IT

Nieokreśloność zakresu prac

Scope (przedmiot świadczenia) jest najważniejszą częścią umowy, ale zarazem najczęstszym źródłem sporów. Jeśli w załączniku technicznym nie określono precyzyjnie, co jest częścią wdrożenia, a co należy już do płatnego rozwoju, dochodzi do konfliktów.

Typowy przypadek to sytuacja, w której umowa mówi o „wdrożeniu systemu informatycznego”, ale nie reguluje migracji danych historycznych ani integracji z API podmiotów trzecich, co następnie prowadzi do naliczania prac dodatkowych.

Prawnicy kancelarii adwokackiej ARROWS zalecają strukturyzowanie umowy według faz analizy, projektowania, rozwoju, testowania, wdrożenia i stabilizacji, przy czym w każdej fazie muszą być określone konkretne rezultaty.

Brak lub niewykonalność SLA

SLA to prawnie wiążący parametr jakości usługi, który określa czasy reakcji, czas rozwiązania incydentu i gwarantowaną dostępność. Bez dobrego SLA nie mają Państwo praktycznej możliwości egzekwowania świadczenia. Jeśli dostawca wielokrotnie popada w zwłokę lub nie dotrzymuje SLA, warto ocenić także strategię procesową, w tym dowody i roszczenia, co należy do obszaru sporów handlowych i sądowych.

Skuteczne SLA zawiera:

• Czas reakcji : Czas, w którym dostawca musi potwierdzić przyjęcie incydentu.
• Czas rozwiązania : Maksymalny czas na usunięcie wady lub zapewnienie rozwiązania zastępczego.
• RTO i RPO : Maksymalny dopuszczalny czas przestoju i maksymalna dopuszczalna utrata danych.
• Dostępność : Gwarantowany procent czasu, w którym system działa.
• Sankcje : Konkretne kary umowne lub rabaty za nieprzestrzeganie parametrów.

Odpowiedzialność za dane i bezpieczeństwo

Chodzi tu o granicę prawną, którą strony umowy muszą jasno określić. Incydent bezpieczeństwa ma nie tylko techniczne, ale i prawne skutki na gruncie RODO oraz czeskiej ustawy o cyberbezpieczeństwie (dalej „ZKB”). Praktyczne ramy umownego ustalenia ról administratora i podmiotu przetwarzającego oraz minimalizacji ryzyk przy zaangażowaniu podmiotów trzecich podsumowuje także artykuł Platforma SaaS w UE: prawne uregulowanie OWU, RODO i postanowień licencyjnych dla wyników AI.

Typowy problem prawny pojawia się, gdy umowa stanowi, że dostawca nie odpowiada za utratę danych. Takie postanowienie może być sprzeczne z bezwzględnie obowiązującymi przepisami czeskiej ustawy Kodeks cywilny (ustawa nr 89/2012 Sb., dalej „OZ”) o naprawieniu szkody. Muszą Państwo mieć określone:

• Standardy bezpieczeństwa : Obowiązek przestrzegania konkretnych norm.
• Współdziałanie przy incydencie : Obowiązek dostawcy niezwłocznego zgłaszania incydentów.
• Kopie zapasowe i odtwarzanie : Zasady tworzenia kopii zapasowych i testowania odtwarzania.
• Ubezpieczenie : Obowiązek dostawcy posiadania ubezpieczenia odpowiedzialności zawodowej.

Własność intelektualna i vendor lock-in

Kto wykonuje autorskie prawa majątkowe do powstałego kodu, projektu graficznego i baz danych? Zgodnie z czeską ustawą o prawie autorskim, jeśli nie uzgodniono inaczej, autor udziela jedynie licencji na korzystanie z utworu, a nie prawa do ingerowania w niego.

Proszę wyobrazić sobie sytuację, w której po latach chcą Państwo zmodernizować system, ale pierwotny dostawca już nie istnieje, a Państwo nie mają dostępu do kodów źródłowych – w ten sposób wpadają Państwo w pułapkę tzw. vendor lock-in.

Prawnicy z ARROWS zalecają wynegocjowanie możliwie najszerszej licencji z prawem do dokonywania modyfikacji, a w przypadku oprogramowania na zamówienie nalegać na przekazanie kodów źródłowych lub skorzystanie z instytucji depozytu kodu. Praktyczne skutki źle ustalonych stosunków umownych i zapobieganie przyszłym sporom omawia również artykuł Zapobieganie sporom w holdingu: ustalanie stosunków umownych między spółkami powiązanymi.

Procedura odbioru

Moment odbioru ma kluczowe znaczenie prawne, ponieważ przechodzi wówczas ryzyko szkody na rzeczy i zaczyna biec okres gwarancji. Jeśli umowa nie zawiera obiektywnych kryteriów, dostawca może twierdzić, że dzieło jest gotowe, nawet gdy system wykazuje wady.

Właściwe podejście obejmuje:

• Kryteria odbioru : Listę warunków, które system musi spełnić.
• Testy odbiorcze : Prawo klienta do przeprowadzenia testów w rozsądnym terminie.
• Kategoryzacja wad : Podział wad na krytyczne i drobne.
• Płatności warunkowe : Powiązanie ostatniej części ceny z pomyślnym podpisaniem protokołu.

Proces eskalacji i rozwiązywania sporów

W trakcie wdrożenia mogą pojawić się nieporozumienia, a bez określonego procesu spór często niepotrzebnie się zaostrza. Dobra umowa przewiduje szczeble rozwiązywania od eskalacji do komitetu sterującego, przez mediację, aż po postępowanie sądowe.

Prawnicy z kancelarii adwokackiej ARROWS zauważają, że skutecznie ustalona eskalacja często oszczędza miesiące czasu i setki tysięcy koron czeskich na opłatach sądowych.

Praktyczny przebieg przeglądu umowy IT

Faza 1: Audyt prawny

Zanim cokolwiek Państwo zmienią, trzeba zidentyfikować ryzyka. Prawnicy z ARROWS analizują projekt umowy i oznaczają krytyczne miejsca, które są sprzeczne z Państwa interesami lub obowiązującymi przepisami. Przykładem może być niedopuszczalna klauzula ograniczająca odszkodowanie do symbolicznej kwoty.

Faza 2: Negocjacje i uwagi

Dostawcy często twierdzą, że używają „standardowych wzorów korporacyjnych”, których nie można zmieniać. Doświadczenie ARROWS pokazuje, że każda umowa podlega negocjacjom, zwłaszcza jeśli argumentują Państwo zgodnością z czeskimi przepisami i symetrią praw i obowiązków.

Faza 3: Finalizacja i podpis

Zmiany wprowadza się w formie rewizji lub aneksów. Ważne jest zapewnienie, aby załączniki techniczne nie były sprzeczne z główną częścią prawną umowy, co jest częstym błędem przy kompletowaniu dokumentacji.

Bezpieczeństwo i RODO w umowach IT

Wdrożenie oprogramowania niemal zawsze wiąże się z dostępem do danych osobowych. Jeśli dostawca uzyskuje dostęp do danych Państwa klientów lub pracowników, staje się podmiotem przetwarzającym i konieczne jest zawarcie umowy powierzenia przetwarzania.

Jeśli dostawca uzyskuje dostęp do danych osobowych Państwa klientów lub pracowników, staje się zgodnie z art. 28 RODO podmiotem przetwarzającym i muszą Państwo zawrzeć z nim umowę powierzenia przetwarzania.

Umowa powinna gwarantować Państwu prawo do przeprowadzenia audytu bezpieczeństwa u dostawcy, czego wymaga także dyrektywa NIS2 transponowana do ZKB.

Umowny termin na zgłoszenie incydentu bezpieczeństwa przez dostawcę musi być krótszy niż 72 godziny, aby Państwo jako administrator zdążyli wypełnić swój ustawowy obowiązek wobec organu nadzorczego.

Szczególne sytuacje i kluczowe elementy

Chmura vs. on-premise

W przypadku chmury (SaaS) kluczowe są dostępność, miejsce przechowywania danych i proces exit managementu, czyli sposób odzyskania danych po zakończeniu umowy. Dane są w tym przypadku przechowywane u dostawcy, co wymaga szczególnych gwarancji.

W przypadku rozwiązań on-premise, czyli instalacji na Państwa infrastrukturze, decydujący jest zakres licencji (bezterminowa vs. czasowa). Należy także uregulować gwarancję za dzieło i maintenance, obejmujący prawo do nowych wersji i poprawek bezpieczeństwa.

Rozwój zwinny vs. Waterfall

Metoda Waterfall charakteryzuje się stałym zakresem, ceną i terminem, a prawnie zwykle ujmuje się ją jako umowę o dzieło z naciskiem na odbiór całości. Sprawdza się w jasno zdefiniowanych projektach.

Rozwój zwinny jest prawnie bardziej złożony, ponieważ często rozlicza się go według wykazanego czasu. Tu trzeba umownie uregulować prawo klienta do zmiany priorytetów, definicję ukończenia zadania oraz mechanizm limitu budżetu, aby projekt nie podrożał nadmiernie.

Jak postępować w razie problemów podczas wdrożenia

Jeśli dopiero w trakcie projektu odkryją Państwo, że umowa jest niekorzystna, warto spróbować wynegocjować aneks. Często można wymienić ustępstwo w harmonogramie na zaostrzenie SLA lub uzupełnienie brakującej licencji.

Jeżeli dostawca nie wykonuje zobowiązań, trzeba formalnie zgłosić wady zgodnie z umową i ustawą, ponieważ dokumentacja ma kluczowe znaczenie dla ewentualnego sporu sądowego. Jeśli naruszenie jest istotne, OZ umożliwia odstąpienie od umowy, jest to jednak rozwiązanie ostateczne, wymagające analizy.

Prawnicy z kancelarii adwokackiej ARROWS pomogą Państwu przeanalizować sytuację i wybrać strategię minimalizującą szkody.

Podsumowanie

Przegląd umowy IT to podstawowy element zarządzania ryzykiem, który chroni inwestycję w technologie przed wadami prawnymi. Te mogą ostatecznie okazać się droższe niż samo oprogramowanie.

Typowe ryzyko zaniedbania obejmuje podpisanie umowy bez przeglądu, następnie vendor lock-in, brak możliwości migracji danych i wysokie koszty sporów prawnych w razie zawodu dostawcy.

Prawnicy kancelarii adwokackiej ARROWS specjalizują się w prawie IT i własności intelektualnej. Naszym celem jest nie tylko poprawność prawna, ale przede wszystkim funkcjonalność biznesowa i egzekwowalność umowy w praktyce.

Jeśli planują Państwo projekt IT lub potrzebują przeglądu istniejących stosunków umownych, kancelaria adwokacka ARROWS pomoże ustalić uczciwe i bezpieczne warunki. Prosimy o kontakt pod adresem konsultacja@arws.cz w celu niewiążącej konsultacji.