Odpowiedzialność za rażące niedbalstwo w umowach IT – perspektywa wykonawcy projektu IT

Kwestia ograniczania odpowiedzialności w umowach IT jest jedną z najczęściej negocjowanych przez strony. Z punktu widzenia zamawiającego istotne jest aby to ograniczenie w ogóle nie występowało i najlepiej aby odpowiedzialność wykonawcy była poddana zasadom ogólnym wynikających z Kodeksu cywilnego, zaś wykonawcy aby tę odpowiedzialność jednak w pewien sposób ograniczyć. 

Bardzo często gdy już strony dochodzą do porozumienia, że jednak tę odpowiedzialność po stronie wykonawcy ograniczą to zamawiający wskazuje istotne ograniczenie takiego podejścia. Ograniczenie to nie powinno dotyczyć szkód wyrządzonych umyślnie lub przez rażące niedbalstwo.

Wydaje się to w pełni zrozumiałe, uzasadnione i racjonalne. 

Często jednak zamawiający twierdzą, że takie ograniczenie wynika wprost z prawa i wykonawca nie powinien robić problemu z jego wprowadzeniem. To nie do końca prawda, o czym dowiesz się z tego artykułu.

Zamów wzory umów IT!

Szkoda wyrządzona umyślnie

Dlaczego we wstępie napisałem, że wyłączenie spod ograniczenia odpowiedzialności szkody wyrządzonej umyślnie lub przez rażące niedbalstwo to nie do końca prawda?

Zgodnie z art. 473 Kodeksu cywilnego nieważne jest zastrzeżenie umowne, zgodnie z którym dana strona (np. wykonawca) nie będzie odpowiedzialna za szkodę, którą może wyrządzić drugiej stronie umyślnie.

Jeśli więc mimo wszystko takie postanowienie znajdzie się w umowie, nie unieważnia to całego postanowienia, a jedynie tę jego część, która zdejmuje odpowiedzialność za działanie umyślne.

Rażące niedbalstwo

Wyżej wspomniany przepis nie dotyczy rażącego niedbalstwa. Co za tym idzie nie należy utożsamiać winy umyślnej z rażącym niedbalstwem. To dwie odrębne kwestie.

W konsekwencji warto tutaj od razu podkreślić, że odpowiedzialność z tytułu rażącego niedbalstwa można zarówno ograniczyć jak i wyłączyć. 

Pojęcie rażącego niedbalstwa nie ma definicji ustawowej. Definicję wypracowało orzecznictwo. Jest to niezachowanie minimalnych (elementarnych) zasad prawidłowego zachowania się w danej sytuacji.

W tym kontekście trzeba przytoczyć treść art. 355 Kodeksu cywilnego. 

„Dłużnik obowiązany jest do staranności ogólnie wymaganej w stosunkach danego rodzaju (należyta staranność). Należytą staranność dłużnika w zakresie prowadzonej przez niego działalności gospodarczej określa się przy uwzględnieniu zawodowego charakteru tej działalności.” 

Powyższy artykuł, wyznacza więc wzorzec, od którego odchylenie stanowi niedbalstwo lub rażące niedbalstwo. 

Zgodnie z orzecznictwem Sądu Najwyższego przez rażące niedbalstwo rozumie się niezachowanie minimalnych zasad prawidłowego zachowania się w danej sytuacji. O przypisaniu pewnej osobie winy w tej postaci decyduje więc zachowanie się przez nią w określonej sytuacji w sposób odbiegający od miernika staranności minimalnej (przykładowo wyrok Sądu Najwyższego z dnia 8 października 2020 r., II CSK 773/18).

Rażące niedbalstwo vs wina umyślna

Rażące niedbalstwo jest postacią winy nieumyślnej, a nie winą umyślną. Różnica od winy umyślnej jest zasadnicza prawnie, choć granica bywa cienka. Można powiedzieć, że wręcz graniczy z umyślnością. 

W taki sposób tłumaczy to Sąd Najwyższy w wyroku z dnia 22 kwietnia 2004 r (II CK 142/03).

• Ocena zawsze pozostaje osadzona w okolicznościach konkretnego stanu faktycznego. Chodzi o akty staranności zwykłej miary, jakkolwiek z uwzględnieniem podwyższonych wymagań stawianych profesjonalnemu podmiotowu. Dopiero drastyczne odejście od tego wzorca, a nie zwykły błąd czy przeoczenie, pozwala mówić o rażącym niedbalstwie.
• Fakt, że doszło do szkody, nie przesądza jeszcze o rażącym charakterze zaniedbania.
• Sąd Najwyższy podkreśla, że oceny dokonuje się przez pryzmat przewidywalności skutków. Nie można z góry zakładać, że każda sytuacja niesie ze sobą nadzwyczajne zagrożenia i podwyższone ryzyko. Nawet jeżeli ryzyko jest realne, to wiedza o nim nie zawsze jest powszechnie dostępna, a więc nie można nią automatycznie obciążać dłużnika.
• Uruchomienie wyższych aktów staranności musi mieścić się w regułach przewidywalności, a nie wykraczać poza to, czego rozsądnie można było oczekiwać w danym momencie.

Rażące niedbalstwo a należyta staranność

Dobrą ilustracją do tej tematyki jest także orzeczenie Sądu Najwyższego z 11 maja 2005 r (III CSK 522/04), zgodnie z którym:

• Punktem wyjścia dla oceny stopnia zawinienia musi być art. 355  Kodeksu cywilnego. Przepis ten, wskazując że dłużnik obowiązany jest do zachowania staranności ogólnie wymaganej w stosunkach danego rodzaju (należytej staranności) statuuje generalną zasadę oceny winy w prawie cywilnym w odniesieniu do wszystkich stosunków zobowiązaniowych, niezależnie od źródła ich powstania. Zasada ta, z mocy przepisów szczególnych podlega następnie określonym w tych przepisach modyfikacjom.
• W konsekwencji, by ocenić, czy dopuszczono się rażącego niedbalstwa, w pierwszej kolejności należy ustalić, czy określone zachowanie może być oceniane jako zwykłe niedbalstwo w rozumieniu art. 355 § 1 Kodeksu cywilnego. Dopiero przesądzenie tej kwestii czyni aktualnym dokonywanie oceny, czy niedbalstwo to oceniać można jako rażące.
• Za rażące niedbalstwo uznawać należy nieostrożność graniczącą z rozmyślnym działaniem, a zatem jako rażąco niedbałe należałoby oceniać przede wszystkim zachowanie lekkomyślne, gdyż jako połączone z przewidywaniem skutku jest bliższe umyślności niż klasyczne niedbalstwo.

Czym może być rażące niedbalstwo w umowach i projektach IT?

Wiesz już, że rażące niedbalstwo to nie zwykły błąd, przeoczenie czy niedopatrzenie, ale drastyczne odejście od elementarnych zasad postępowania w danej sytuacji. Jak to jednak wygląda w praktyce projektów IT? Poniżej trzy przykłady sytuacji, w których sąd mógłby dopatrzyć się rażącego niedbalstwa po stronie wykonawcy. Podkreślam słowo „mógłby”, ponieważ ocena zawsze zależy od okoliczności konkretnej sprawy, a samo wystąpienie szkody niczego jeszcze nie przesądza.

Przykład 1: wdrożenie zmian na produkcji bez kopii zapasowej i bez testów

Wykonawca wprowadza istotne zmiany bezpośrednio w środowisku produkcyjnym klienta, z pominięciem środowiska testowego, mimo że umowa i przyjęta u klienta procedura wdrożeniowa wyraźnie tego wymagały.

Dodatkowo nie wykonuje kopii zapasowej bazy danych przed wdrożeniem. Gdy migracja się nie powiedzie i dojdzie do utraty danych, trudno będzie bronić tezy, że to zwykłe niedopatrzenie. Wykonanie backupu przed ingerencją w produkcję i testowanie zmian przed wdrożeniem to absolutne minimum profesjonalnej praktyki, znane każdemu, kto zawodowo zajmuje się utrzymaniem systemów.

Zaniechanie obu tych czynności jednocześnie może zostać ocenione jako niezachowanie minimalnych zasad prawidłowego zachowania.

Przykład 2: zignorowanie znanej, krytycznej podatności bezpieczeństwa

Wykonawca odpowiedzialny umownie za utrzymanie i bezpieczeństwo systemu otrzymuje informację o krytycznej podatności w wykorzystywanej bibliotece (głośnym przykładem z przeszłości jest Log4Shell), wraz z dostępną poprawką.

Mimo to przez wiele tygodni nie podejmuje żadnych działań: nie instaluje poprawki, nie wdraża rozwiązania tymczasowego, nie informuje klienta o ryzyku. Dochodzi do włamania i wycieku danych właśnie przez tę podatność.

Inaczej należałoby ocenić sytuację, w której podatność była nieznana lub poprawka niedostępna. Tu jednak wiedza o zagrożeniu była powszechna, sposób jego usunięcia znany, a wykonawca świadomie pozostał bierny. To zachowanie bliskie lekkomyślności, o której pisałem wyżej: wykonawca mógł przewidzieć skutek i mimo to nic nie zrobił.

Przykład 3: przechowywanie danych dostępowych klienta w publicznym repozytorium

Programista wykonawcy umieszcza w publicznym repozytorium kodu (np. na GitHubie) pliki konfiguracyjne zawierające hasła, klucze API i dane dostępowe do infrastruktury produkcyjnej klienta. Zasada, że danych uwierzytelniających nie umieszcza się w kodzie, a tym bardziej w kodzie publicznie dostępnym, należy do elementarza pracy programisty i jest standardowo ujmowana w politykach bezpieczeństwa.

Jeżeli w następstwie takiego ujawnienia osoba trzecia uzyska dostęp do systemów klienta, wykonawcy trudno będzie się bronić argumentem, że doszło jedynie do zwykłego błędu ludzkiego. Zwłaszcza gdy w organizacji wykonawcy nie funkcjonowały żadne mechanizmy kontrolne, takie jak przegląd kodu czy automatyczne skanowanie repozytoriów pod kątem sekretów.

Wspólny mianownik tych przykładów jest taki, że w każdym z nich wykonawca łamie regułę, którą zna (lub musi znać) każdy profesjonalista w branży, a dostępne środki zapobiegawcze są proste i tanie. To właśnie odróżnia rażące niedbalstwo od zwykłego niedbalstwa, czyli na przykład pojedynczego błędu w kodzie, który przeszedł przez testy, albo przeoczenia w dokumentacji. Błędy zdarzają się w każdym projekcie i samo ich popełnienie nie oznacza jeszcze rażącego niedbalstwa.

Podsumowanie, czyli ściąga na stół negocjacyjny

Wróćmy do sytuacji ze wstępu. Siedzisz przy stole (albo na callu) i negocjujesz klauzulę ograniczenia odpowiedzialności. Oto trzy zdania, które najczęściej wtedy padają, i to, co warto na nie odpowiedzieć.

„Wyłączenie ograniczenia przy winie umyślnej i rażącym niedbalstwie wynika wprost z prawa.”

Nie do końca. Z prawa (art. 473 § 2 Kodeksu cywilnego) wynika tylko tyle, że nie można wyłączyć odpowiedzialności za szkodę wyrządzoną umyślnie. Rażące niedbalstwo to odrębna kategoria i przepis o nim milczy. Odpowiedzialność za rażące niedbalstwo można umownie ograniczyć, a nawet wyłączyć. Jeżeli więc godzisz się na wyjęcie rażącego niedbalstwa spod limitu odpowiedzialności, to jest to Twoja decyzja biznesowa, a nie wymóg ustawy.

„Przecież rażące niedbalstwo to prawie to samo co umyślność.”

Prawnie to dwie różne rzeczy. Rażące niedbalstwo pozostaje winą nieumyślną. To prawda, że graniczy z umyślnością, ale właśnie dlatego poprzeczka jest zawieszona wysoko: chodzi o drastyczne odejście od elementarnych zasad postępowania, a nie o zwykły błąd, przeoczenie czy nieudane wdrożenie. Sam fakt, że powstała szkoda, niczego jeszcze nie przesądza.

„Bez tego wyłączenia nie mamy żadnej ochrony.”

Mają. Po pierwsze, odpowiedzialności za winę umyślną i tak nie da się wyłączyć. Po drugie, granice wyznacza również ocena konkretnego zachowania na tle art. 355 Kodeksu cywilnego, z uwzględnieniem zawodowego charakteru działalności wykonawcy. Profesjonalista, który wdraża zmiany na produkcji bez backupu, ignoruje znaną krytyczną podatność albo trzyma dane dostępowe klienta w publicznym repozytorium, nie schowa się za klauzulą, jeśli sąd uzna jego zachowanie za umyślne albo jeśli klauzula w ogóle rażącego niedbalstwa nie obejmuje.

I na koniec myśl, którą warto zabrać z tego artykułu, nawet jeśli wszystko inne umknie. Klauzula ograniczenia odpowiedzialności to nie formalność przepisywana z wzoru, tylko realny podział ryzyka między strony. Zanim podpiszesz, odpowiedz sobie na jedno pytanie: czy wiem, za co dokładnie będę odpowiadać bez limitu? Jeżeli w umowie pojawia się rażące niedbalstwo, odpowiedź na to pytanie właśnie stała się dużo droższa.

Potrzebujesz wsparcia prawnika IT? Napisz do mnie!