Firma IT — odpowiedzialność za błędy w oprogramowaniu i umowy SLA

Awaria systemu ERP na 48 godzin kosztowała lubelską firmę produkcyjną 380 000 zł strat. Dostawca oprogramowania twierdził, że błąd nie mieścił się w zakresie gwarancji. Sprawa trafiła do sądu. Problem? Umowa wdrożeniowa miała 3 strony, nie precyzowała poziomu dostępności systemu i nie zawierała żadnego limitu odpowiedzialności. Taka sytuacja to norma, nie wyjątek w polskiej branży IT.

Podstawy prawne odpowiedzialności firmy IT w Polsce

Firma IT odpowiada na podstawie kilku różnych reżimów prawnych jednocześnie — i to jest źródłem wielu nieporozumień:

Odpowiedzialność kontraktowa (art. 471 k.c.) — za niewykonanie lub nienależyte wykonanie zobowiązania umownego. To podstawowy reżim dla relacji B2B.
Rękojmia za wady (art. 556 i nast. k.c.) — stosuje się przy umowie sprzedaży oprogramowania (licencji); przy umowach o świadczenie usług rękojmia może być wyłączona.
Odpowiedzialność za szkodę z produktu niebezpiecznego — dyskusyjna w kontekście oprogramowania, ale rosnąca relevancja po implementacji europejskiego rozporządzenia AI Act (2024/1689).
RODO — jeśli błąd oprogramowania doprowadził do naruszenia ochrony danych osobowych, firma IT jako procesor może odpowiadać solidarnie z administratorem.

Kluczowa zasada: W umowach B2B strony mają szeroką swobodę ograniczania odpowiedzialności (art. 473 k.c.). Firma IT może skutecznie wyłączyć odpowiedzialność za utracone zyski, za przerwy w działalności, za dane klienta — o ile zrobi to w umowie. Bez takich klauzul odpowiada za pełną szkodę.

Co powinna zawierać umowa wdrożeniowa systemu IT

Umowa wdrożeniowa to nie jest "umowa o dzieło z dodatkami". To złożony kontrakt, który musi regulować:

Zakres wdrożenia (scope of work) — dokładny opis funkcjonalności, modułów, integracji. Każda nieokreśloność zakresu to przyszły spór: "to miało być wliczone" vs. "to jest zmiana zakresu".
Harmonogram i kamienie milowe — z konkretnymi datami i warunkami odbioru każdego etapu.
Procedura odbioru i kryteria akceptacji — co to znaczy, że system "działa prawidłowo"? Kto zatwierdza odbiór? Co się dzieje przy odmowie odbioru?
Środowisko testowe i produkcyjne — kto odpowiada za dane testowe, kto za backup przed go-live.
Prawa własności intelektualnej — kto jest właścicielem kodu: firma IT (licencja dla klienta) czy klient (przeniesienie autorskich praw majątkowych)? Każda opcja ma inne implikacje dla przyszłego rozwoju systemu.
Dokumentacja — jaką dokumentację techniczną i użytkownika dostarcza wykonawca.

SLA — Service Level Agreement — kluczowy element umowy IT

SLA (umowa o poziomie usług) to dokument (zazwyczaj załącznik do umowy) definiujący mierzalne parametry jakości usług IT. Bez SLA firma IT może twierdzić, że "system działa prawidłowo", nawet jeśli jest niedostępny przez 8 godzin dziennie.

Kluczowe elementy SLA:

Dostępność systemu (uptime) — wyrażona procentowo: 99,9% = max 8,7 godzin przestoju rocznie; 99,5% = max 43,8 godzin. Różnica może być kolosalna w zakresie ryzyka biznesowego.
Okno serwisowe — kiedy dopuszczalne są przerwy konserwacyjne, na ile z wyprzedzeniem musi być ogłoszona planowana przerwa.
Czas reakcji (response time) — w ciągu ilu godzin firma IT musi potwierdzić przyjęcie zgłoszenia awarii.
Czas naprawy (resolution time) — w ciągu ilu godzin musi usunąć awarię. Różne poziomy dla różnych priorytetów (P1: krytyczna awaria systemu produkcyjnego — 4h; P2: poważna usterka — 8h; P3: drobny błąd — 5 dni roboczych).
Kary umowne za naruszenie SLA — np. 0,5% miesięcznego wynagrodzenia za każdą godzinę niedostępności powyżej ustalonego limitu, nie więcej niż 10% miesięcznej faktury.

Pułapka — "reasonable efforts" zamiast konkretnych parametrów: Wiele umów IT zawiera zwroty: "dołożymy wszelkich starań", "zapewnimy najlepsze możliwe wsparcie". To nie są mierzalne zobowiązania. Każdy parametr SLA musi być liczbowy i weryfikowalny. "Reasonable efforts" to klauzula, która firma IT wygrywa w 9 przypadkach na 10 w sądzie, bo zawsze może powiedzieć "staraliśmy się".

Ograniczenie odpowiedzialności firmy IT — co jest dopuszczalne w umowach B2B

W umowach B2B (z wyłączeniem konsumentów) firma IT może skutecznie ograniczyć odpowiedzialność:

Wyłączenie odpowiedzialności za utracone zyski (lucrum cessans) — standardowa klauzula; bez niej firma IT odpowiadałaby za utratę zysku klienta spowodowaną awarią systemu.
Wyłączenie odpowiedzialności za dane klienta — z obowiązkiem po stronie klienta do robienia backupów.
Limit odpowiedzialności — np. "łączna odpowiedzialność wykonawcy nie może przekroczyć wynagrodzenia netto za ostatnie 3 miesiące świadczenia usług". To standardowe i skuteczne.
Wyłączenie odpowiedzialności za szkody pośrednie — utrata danych, przerwa w działalności, utrata reputacji.

Czego nie można wyłączyć (nawet w B2B): winy umyślnej i rażącego niedbalstwa (art. 473 §2 k.c.), szkód na osobie.

Prawa autorskie do oprogramowania — własne czy licencja

Jeden z najważniejszych aspektów umów IT, często zaniedbany:

Domyślnie — autorskie prawa majątkowe do oprogramowania przysługują wykonawcy, jeśli umowa nie stanowi inaczej (art. 74 prawa autorskiego). Klient dostaje tylko licencję.
Przeniesienie autorskich praw majątkowych wymaga wyraźnego zapisu w umowie z wskazaniem pól eksploatacji. "Przekazujemy kod" bez tego zapisu to jedynie licencja.
Przy systemach custom-dev — warto walczyć o przeniesienie praw do kodu napisanego na zamówienie. Przy gotowych systemach (SaaS, licencja komercyjna) — tylko licencja jest możliwa.
Brak przeniesienia praw oznacza, że zmiana dostawcy wymaga albo nowego oprogramowania, albo negocjacji licencji z poprzednim dostawcą — często w bardzo niekorzystnej pozycji.

Praktyczna rada dla firm IT i ich klientów w Lublinie

Umowa wdrożeniowa i SLA to nie formalność — to mapa ryzyk. Firma IT chroni się limitami odpowiedzialności i wyłączeniami; klient powinien wymagać konkretnych parametrów i kar umownych. Kancelaria Joanny Cenkier w Lublinie przygotowuje i opiniuje umowy IT zarówno dla firm świadczących usługi technologiczne, jak i dla klientów zamawiających systemy. Umów konsultację przed podpisaniem kontraktu — nie po awarii.