Odpowiedzialność firmy IT za błędy w oprogramowaniu i umowy SLA

Według raportu Consortium for IT Software Quality z 2023 roku, błędy w oprogramowaniu kosztują globalną gospodarkę ponad 2,08 biliona dolarów rocznie. Dla firm IT świadczących usługi wdrożeniowe i utrzymaniowe, pytanie o zakres odpowiedzialności za defekty w kodzie nie jest teoretyczne – to codzienność, która może zadecydować o przetrwaniu biznesu lub wieloletnim sporze sądowym.

Przedsiębiorca z Lublina, który wdrożył system ERP dla sieci sklepów, otrzymał pozew o odszkodowanie przekraczające wartość kontraktu dziesięciokrotnie. Powód? Błąd w module magazynowym spowodował błędne rozliczenia z dostawcami. Umowa nie precyzowała, co stanowi "błąd krytyczny" i jakie są realne granice odpowiedzialności dostawcy oprogramowania.

Podstawy prawne odpowiedzialności za wadliwe oprogramowanie

Odpowiedzialność firmy IT za błędy w oprogramowaniu wynika z kilku reżimów prawnych, które mogą się nakładać. Kodeks cywilny przewiduje odpowiedzialność z tytułu rękojmi za wady (art. 556 i nast. KC) oraz odpowiedzialność kontraktową za nienależyte wykonanie zobowiązania (art. 471 KC). W przypadku umów B2B, strony mogą modyfikować te zasady, ale nie bez ograniczeń.

Oprogramowanie traktowane jest jako rzecz w rozumieniu prawa cywilnego, gdy jest przekazywane na nośniku lub jako plik. Wada fizyczna występuje, gdy program nie ma właściwości, które powinien mieć ze względu na cel umowy lub jego zwykłe zastosowanie. Nie każdy błąd (bug) stanowi wadę prawną – istotne jest, czy uniemożliwia on użytkowanie zgodne z przeznaczeniem.

Sąd Najwyższy w wyroku z dnia 14 maja 2015 r. (sygn. akt II CSK 768/14) wskazał, że "oprogramowanie komputerowe może być przedmiotem rękojmi, jeżeli nie spełnia funkcji określonych w umowie lub typowych dla tego rodzaju programów". To orzeczenie ma fundamentalne znaczenie dla ustalania, kiedy firma IT ponosi odpowiedzialność za błędy.

Rozróżnienie między błędem a brakiem funkcjonalności

W praktyce sporów między firmami IT a klientami pojawia się problem rozróżnienia między błędem w kodzie a brakiem określonej funkcjonalności. Błąd (defekt) to sytuacja, gdy zaimplementowana funkcja działa niezgodnie z dokumentacją lub specyfikacją. Brak funkcjonalności oznacza, że określone rozwiązanie w ogóle nie zostało zrealizowane.

To rozróżnienie ma znaczenie dla odpowiedzialności. Jeśli umowa wdrożeniowa precyzyjnie określała zakres funkcjonalny, a dana funkcja nie została dostarczona, mamy do czynienia z niewykonaniem umowy. Jeśli funkcja została zaimplementowana, ale działa wadliwie, stosuje się przepisy o rękojmi lub odpowiedzialności kontraktowej.

W mojej praktyce w Kancelarii Radcy Prawnego Joanna Cenkier spotykam się z sytuacjami, gdy klient oczekuje funkcjonalności, która nigdy nie była przedmiotem ustaleń kontraktowych. Dlatego umowa wdrożeniowa powinna zawierać:

• Szczegółową specyfikację funkcjonalną z podziałem na moduły
• Listę funkcji wykluczonych z zakresu projektu (out of scope)
• Procedurę zgłaszania i akceptacji zmian w specyfikacji (change requests)
• Definicję "akceptacji" poszczególnych etapów wdrożenia
• Katalog błędów krytycznych, istotnych i kosmetycznych

Bez tych elementów każda rozbieżność między oczekiwaniami klienta a dostarczoną funkcjonalnością może przerodzić się w spór o to, czy mamy do czynienia z błędem wymagającym naprawy w ramach gwarancji, czy z nową funkcjonalnością wymagającą dodatkowego wynagrodzenia.

Umowy SLA jako narzędzie ograniczania ryzyka

Service Level Agreement (SLA) to umowa określająca parametry świadczenia usług IT, w tym czasy reakcji na zgłoszenia, dostępność systemu oraz procedury eskalacji problemów. Dla firm IT świadczących usługi utrzymaniowe, dobrze skonstruowana umowa SLA stanowi podstawowe narzędzie zarządzania odpowiedzialnością.

Typowa umowa SLA w zakresie utrzymania oprogramowania powinna określać:

• Poziomy krytyczności błędów (np. P1 – krytyczny, P2 – istotny, P3 – drobny)
• Czasy reakcji dla każdego poziomu (np. P1 – 2 godziny, P2 – 8 godzin, P3 – 48 godzin)
• Czasy rozwiązania problemu (resolution time)
• Gwarantowaną dostępność systemu (np. 99,5% uptime w skali miesiąca)
• Procedury zgłaszania incydentów
• Konsekwencje niedotrzymania parametrów SLA (kary umowne, bonifikaty)
• Wyłączenia z SLA (planned maintenance, siła wyższa, problemy po stronie klienta)

Istotne jest, że umowa SLA nie zastępuje odpowiedzialności z tytułu rękojmi czy gwarancji – uzupełnia ją o proceduralne ramy świadczenia usług. Firma IT nie może w SLA całkowicie wyłączyć odpowiedzialności za wady, ale może określić sposób ich usuwania i realistyczne terminy.

Klauzule ograniczające odpowiedzialność w umowach IT

W relacjach B2B strony mają znaczną swobodę w kształtowaniu zakresu odpowiedzialności kontraktowej. Firmy IT regularnie stosują klauzule ograniczające odpowiedzialność (limitation of liability), które mają chronić przed roszczeniami przewyższającymi wartość kontraktu.

Typowe klauzule ograniczające obejmują:

• Ograniczenie kwotowe odpowiedzialności (np. do wysokości wynagrodzenia za ostatnie 12 miesięcy)
• Wyłączenie odpowiedzialności za szkody pośrednie (utracone korzyści, szkody wizerunkowe)
• Wyłączenie odpowiedzialności za działania osób trzecich
• Ograniczenie odpowiedzialności do przypadków rażącego niedbalstwa lub winy umyślnej
• Określenie maksymalnego okresu odpowiedzialności po zakończeniu współpracy

Skuteczność tych klauzul zależy od ich sformułowania i kontekstu umowy. Sąd Najwyższy w wyroku z 4 kwietnia 2014 r. (sygn. akt I CSK 374/13) uznał, że "klauzule ograniczające odpowiedzialność są dopuszczalne w obrocie profesjonalnym, o ile nie prowadzą do całkowitego wyłączenia odpowiedzialności za niewykonanie głównego świadczenia".

Oznacza to, że firma IT nie może skutecznie wyłączyć odpowiedzialności za całkowite niedostarczenie funkcjonującego oprogramowania, ale może ograniczyć odpowiedzialność za drobne błędy czy opóźnienia w ich usuwaniu. Granica przebiega tam, gdzie klauzula uniemożliwiałaby realizację celu umowy.

Odpowiedzialność za naruszenie bezpieczeństwa danych

Od wejścia w życie RODO w 2018 roku, odpowiedzialność firm IT za błędy w oprogramowaniu zyskała nowy wymiar. Luka bezpieczeństwa w systemie informatycznym może prowadzić do naruszenia ochrony danych osobowych, za co odpowiedzialność ponosi administrator danych – zazwyczaj klient firmy IT.

Administrator może jednak dochodzić roszczeń regresowych od dostawcy oprogramowania, jeśli naruszenie wynikało z błędu w kodzie lub zaniedbań w zakresie bezpieczeństwa. Umowa powinna precyzować:

• Standardy bezpieczeństwa, które będą stosowane (np. OWASP Top 10, ISO 27001)
• Procedury testowania bezpieczeństwa (penetration testing, code review)
• Obowiązki informacyjne w przypadku wykrycia luki
• Terminy dostarczania poprawek bezpieczeństwa
• Podział odpowiedzialności między dostawcę oprogramowania a administratora infrastruktury

W praktyce często spotykam się z sytuacją, gdy umowa wdrożeniowa milczy na temat bezpieczeństwa, zakładając że "oprogramowanie będzie bezpieczne". To niewystarczające. Firma IT powinna dokumentować zastosowane środki bezpieczeństwa i uzyskać akceptację klienta dla przyjętego poziomu zabezpieczeń.

Prezes UODO może nałożyć karę do 20 mln euro lub 4% globalnego obrotu za naruszenia RODO. Jeśli naruszenie wynikało z błędu w oprogramowaniu, klient będzie dążył do przerzucenia tej odpowiedzialności na dostawcę IT. Dlatego umowa powinna zawierać klauzulę o podziale odpowiedzialności za naruszenia wynikające z wad oprogramowania.

Gwarancja i rękojmia w umowach na oprogramowanie

Rękojmia za wady to ustawowa forma odpowiedzialności sprzedawcy, która w relacjach B2B może być modyfikowana umownie. Gwarancja to dobrowolne zobowiązanie gwaranta do naprawy lub wymiany wadliwego produktu. W umowach IT oba te reżimy często się przeplatają, co prowadzi do niejasności.

Podstawowa różnica: rękojmia działa z mocy ustawy (chyba że została wyłączona w umowie B2B), gwarancja wymaga wyraźnego oświadczenia gwaranta. Terminy również się różnią – rękojmia w relacjach B2B może być skrócona do roku, gwarancja trwa przez okres określony w oświadczeniu gwarancyjnym.

W praktyce firm IT obsługiwanych przez moją kancelarię w Lublinie rekomenduje się następujące rozwiązanie: umowa wdrożeniowa zawiera okres gwarancji (np. 12 miesięcy od odbioru), w ramach którego dostawca zobowiązuje się do bezpłatnego usuwania błędów. Jednocześnie umowa ogranicza lub wyłącza rękojmię, zastępując ją precyzyjnie określonymi obowiązkami gwarancyjnymi.

Oświadczenie gwarancyjne powinno określać:

• Okres gwarancji dla różnych kategorii błędów
• Procedurę zgłaszania wad
• Terminy usuwania błędów w zależności od ich krytyczności
• Wyłączenia z gwarancji (modyfikacje kodu przez klienta, niewłaściwe użytkowanie)
• Konsekwencje nieusunięcia wady w terminie (prawo do odstąpienia, obniżenie ceny)

Istotne jest, że gwarancja nie może całkowicie zastąpić rękojmi w sposób niekorzystny dla klienta. Jeśli warunki gwarancji są znacznie gorsze niż uprawnienia z rękojmi, klient może powoływać się na rękojmię mimo formalnego jej wyłączenia w umowie.

Dokumentacja jako dowód w sporach o odpowiedzialność

W sporach dotyczących odpowiedzialności za błędy w oprogramowaniu, dokumentacja projektowa i komunikacja między stronami mają znaczenie dowodowe. Brak odpowiedniej dokumentacji zazwyczaj działa na niekorzyść firmy IT, która jako profesjonalista powinna dokumentować proces wytwarzania oprogramowania.

Dokumentacja, która chroni firmę IT przed nieuzasadnionymi roszczeniami:

• Specyfikacja funkcjonalna zaakceptowana przez klienta (podpisana, z datą)
• Protokoły z testów akceptacyjnych potwierdzające działanie funkcji
• Protokoły odbioru poszczególnych etapów projektu
• Dokumentacja techniczna opisująca architekturę i ograniczenia systemu
• Logi zgłoszeń błędów i podjętych działań naprawczych
• Korespondencja mailowa dokumentująca zmiany w wymaganiach
• Protokoły ze spotkań projektowych

W jednej ze spraw, którą prowadziłam, klient domagał się odszkodowania za "niewdrożenie modułu raportowania". Firma IT przedstawiła protokół z testów akceptacyjnych, w którym klient potwierdził prawidłowe działanie tego modułu. Okazało się, że problem dotyczył nie błędu, ale braku przeszkolenia użytkowników – co nie było objęte umową wdrożeniową. Bez dokumentacji sprawa mogłaby zakończyć się niekorzystnie dla dostawcy.

Równie istotna jest dokumentacja procesu usuwania błędów. System ticketowy rejestrujący zgłoszenia, podjęte działania i czasy reakcji stanowi dowód dotrzymania warunków SLA. W przypadku sporu o niedotrzymanie parametrów serwisowych, to klient powinien udowodnić naruszenie, ale praktyka pokazuje, że sądy oczekują od profesjonalnego dostawcy IT udokumentowania świadczonych usług.

Ubezpieczenie odpowiedzialności cywilnej firm IT

Nawet najlepsza umowa nie wyeliminuje całkowicie ryzyka odpowiedzialności za błędy w oprogramowaniu. Dlatego firmy IT powinny rozważyć ubezpieczenie odpowiedzialności cywilnej (OC) z rozszerzeniem o szkody związane z działalnością informatyczną.

Standardowe ubezpieczenie OC prowadzenia działalności gospodarczej często nie obejmuje szkód wynikających z błędów w oprogramowaniu, szczególnie szkód finansowych (pure economic loss). Firmy IT potrzebują specjalistycznych polis obejmujących:

• Szkody wynikłe z błędów w kodzie (errors and omissions)
• Naruszenia praw własności intelektualnej
• Naruszenia ochrony danych osobowych (cyber liability)
• Koszty obrony w postępowaniach sądowych
• Szkody w mieniu klienta spowodowane wadliwym oprogramowaniem

Składka za takie ubezpieczenie zależy od wartości projektów, branży klientów i sumy ubezpieczenia. Dla małej firmy IT z Lublina realizującej projekty do 500 tys. zł rocznie, roczna składka może wynosić 3-8 tys. zł przy sumie ubezpieczenia 1 mln zł. To niewielki koszt w porównaniu z potencjalnym roszczeniem odszkodowawczym.

Ubezpieczenie nie zwalnia z odpowiedzialności, ale zapewnia środki na pokrycie roszczeń i kosztów obrony. Co istotne, posiadanie ubezpieczenia OC może być argumentem w negocjacjach z klientem, który obawia się ryzyka związanego z wdrożeniem – pokazuje profesjonalizm i gotowość do poniesienia odpowiedzialności.

Praktyczne zalecenia dla firm IT przy konstruowaniu umów

Na podstawie wieloletniej praktyki w obsłudze firm IT mogę wskazać elementy umowy wdrożeniowej i SLA, które realnie minimalizują ryzyko sporów i niekontrolowanej odpowiedzialności:

1. Precyzyjna specyfikacja funkcjonalna – dokument opisujący szczegółowo, co system ma robić, zaakceptowany przez obie strony przed rozpoczęciem prac. Każda zmiana wymaga aneksu z określeniem wpływu na termin i cenę.

2. Definicja poziomów błędów – podział na błędy krytyczne (uniemożliwiające pracę), istotne (utrudniające pracę) i kosmetyczne (nie wpływające na funkcjonalność). Różne terminy naprawy dla każdej kategorii.

3. Procedura akceptacji – określenie, jak przebiega odbiór oprogramowania, ile trwa okres testów, jakie kryteria muszą być spełnione. Milczenie klienta po określonym terminie = akceptacja.

4. Ograniczenie kwotowe odpowiedzialności – np. do wysokości wynagrodzenia za projekt lub rocznego wynagrodzenia za utrzymanie. Wyłączenie odpowiedzialności za szkody pośrednie.

5. Wyłączenia z odpowiedzialności – brak odpowiedzialności za problemy wynikające z: modyfikacji kodu przez klienta, użycia niezgodnie z dokumentacją, problemów z infrastrukturą klienta, działań osób trzecich.

6. Okres gwarancji i warunki – jasno określony okres (np. 12 miesięcy) i warunki (bezpłatne usuwanie błędów zgłoszonych w tym okresie, w określonych terminach zależnych od krytyczności).

7. Procedura zgłaszania błędów – wymaganie zgłaszania przez określony kanał (np. system ticketowy), z opisem problemu, krokami do reprodukcji, logami. Zgłoszenia niekompletne nie uruchamiają terminów SLA.

8. Klauzula o współpracy – zobowiązanie klienta do współpracy przy diagnozowaniu i usuwaniu błędów, udostępniania dostępu do systemu, logów, środowiska testowego.

9. Postanowienia o danych osobowych – określenie ról (administrator/procesor), zakresu przetwarzania, środków bezpieczeństwa, odpowiedzialności za naruszenia.

10. Klauzula mediacyjna – zobowiązanie do próby rozwiązania sporu w mediacji przed wniesieniem sprawy do sądu. Skraca to czas i obniża koszty ewentualnego konfliktu.

Postępowanie w przypadku roszczenia klienta

Gdy klient zgłasza roszczenie odszkodowawcze związane z błędem w oprogramowaniu, sposób reakcji firmy IT ma znaczenie dla dalszego przebiegu sprawy. Błędy w komunikacji na tym etapie mogą pogorszyć sytuację prawną dostawcy.

Nie przyznawaj się do winy pochopnie. Wyrażenie "przepraszamy za błąd, naprawimy to" w kontekście roszczenia może być interpretowane jako przyznanie się do odpowiedzialności. Lepsze sformułowanie: "przyjęliśmy zgłoszenie do analizy, sprawdzimy przyczynę problemu".

Dokumentuj wszystko. Każda rozmowa z klientem powinna być podsumowana mailem. Jeśli klient zgłasza ustnie roszczenie, poproś o przesłanie go na piśmie z uzasadnieniem i wyliczeniem szkody.

Zweryfikuj zasadność roszczenia. Czy zgłoszony problem rzeczywiście wynika z błędu w kodzie? Czy jest objęty umową i gwarancją? Czy klient dotrzymał warunków umowy (np. terminowe zgłoszenie, współpraca przy diagnozowaniu)?

Sprawdź umowę. Jakie są postanowienia dotyczące odpowiedzialności, limitów odszkodowania, procedur reklamacyjnych? Czy klient zachował wymagane terminy i formy zgłoszenia?

Zgłoś sprawę ubezpieczycielowi. Jeśli masz ubezpieczenie OC, niezwłocznie poinformuj ubezpieczyciela o potencjalnym roszczeniu. Opóźnienie w zgłoszeniu może skutkować odmową wypłaty odszkodowania.

Rozważ polubowne rozwiązanie. Spór sądowy to koszty (często kilkanaście tysięcy złotych), czas (2-3 lata do prawomocnego wyroku) i niepewność wyniku. Jeśli roszczenie ma częściowe uzasadnienie, negocjacje mogą być korzystniejsze niż proces.

Zasięgnij porady prawnej. Nie czekaj, aż klient wniesie pozew. Wczesna konsultacja z radcą prawnym specjalizującym się w prawie IT pozwala ocenić ryzyko i przygotować strategię obrony lub negocjacji.

W mojej praktyce w Kancelarii Radcy Prawnego Joanna Cenkier wielokrotnie udawało się uniknąć postępowania sądowego dzięki wczesnemu zaangażowaniu prawnika, który pomógł stronom zrozumieć ich rzeczywiste pozycje prawne i wypracować kompromis. Klient często nie zdaje sobie sprawy z ograniczeń odpowiedzialności wynikających z umowy, a firma IT – z tego, że niektóre postanowienia umowy mogą być nieskuteczne.

Odpowiedzialność firmy IT za błędy w oprogramowaniu nie jest nieograniczona, ale wymaga świadomego zarządzania przez odpowiednią konstrukcję umów wdrożeniowych i SLA. Precyzyjna specyfikacja funkcjonalna, realistyczne terminy, jasne procedury zgłaszania błędów i ograniczenia odpowiedzialności to fundamenty bezpiecznej współpracy z klientem. Dokumentacja każdego etapu projektu i profesjonalna reakcja na reklamacje minimalizują ryzyko niekontrolowanych roszczeń. Jeśli prowadzisz firmę IT i chcesz zabezpieczyć się przed odpowiedzialnością przekraczającą rozsądne granice, umów konsultację – przeanalizujemy Twoje umowy i wskażemy obszary wymagające poprawy.