Modele współpracy B2B a odpowiedzialność za szkody – co musi się znaleźć w umowie

Modele współpracy B2B a odpowiedzialność – jak to się łączy technicznie

Relacja B2B z perspektywy prawa cywilnego

Relacja B2B to z punktu widzenia prawa po prostu umowa cywilnoprawna zawarta między dwoma przedsiębiorcami. Nie istnieje żaden „specjalny” status B2B w kodeksie cywilnym – liczy się treść kontraktu, a nie to, czy dana osoba zgłoszona jest w ZUS jako przedsiębiorca. Odpowiedzialność za szkody w modelu B2B wynika przede wszystkim z przepisów o zobowiązaniach umownych (art. 353–471 i kolejne k.c.) oraz z tego, jak strony zmodyfikują te zasady w umowie.

Podstawowy mechanizm jest prosty: jedna strona zobowiązuje się do określonego świadczenia (wykonania usługi, stworzenia dzieła, dostawy towaru), druga – do zapłaty wynagrodzenia. Jeśli świadczenie jest wykonane wadliwie, z opóźnieniem lub w ogóle nie dojdzie do skutku, powstaje potencjalna odpowiedzialność kontraktowa. Dodatkowo w tle może pojawić się odpowiedzialność deliktowa (za czyn niedozwolony), choć w profesjonalnej współpracy B2B zwykle dąży się do tego, aby większość sytuacji „łapała się” na reżim umowny, bo jest on przewidywalny i można nim zarządzać w umowie.

Z punktu widzenia bezpieczeństwa biznesowego kluczowe jest, że kodeks cywilny daje dużą swobodę w kształtowaniu odpowiedzialności. Strony mogą w granicach prawa modyfikować większość domyślnych reguł: ograniczać odpowiedzialność, ustalać własne zasady naprawiania szkód, różnicować odpowiedzialność za poszczególne obszary działań, wprowadzać kary umowne. To właśnie treść umowy decyduje o tym, jak duże ryzyko bierze na siebie dana firma.

B2B kontra umowa o pracę – dlaczego odpowiedzialność jest ostrzejsza

Największe zaskoczenie dla osób przechodzących z etatu na B2B dotyczy skali odpowiedzialności. Pracownik etatowy jest chroniony przez Kodeks pracy: co do zasady odpowiada do wysokości trzymiesięcznego wynagrodzenia za szkody nieumyślne wyrządzone pracodawcy, a odpowiedzialność za szkody wobec osób trzecich co do zasady spada na pracodawcę. W relacji B2B ta ochrona znika.

W modelu B2B współpracownik (kontraktor, podmiot usługowy, software house, agencja) odpowiada pełnym majątkiem według zasad kodeksu cywilnego, chyba że w umowie wprowadzi ograniczenia. Jeśli więc kontraktor popełni błąd, który spowoduje u klienta wielomilionową stratę, teoretycznie może za to odpowiadać do pełnej wysokości szkody. W praktyce odpowiedzialność może być częściowo ograniczona, ale tylko wtedy, gdy odpowiednie klauzule znajdą się w kontrakcie.

W modelu B2B nie ma też automatycznych limitów odpowiedzialności jak w relacji pracownik–pracodawca. Brak zapisów w umowie oznacza pełną odpowiedzialność z ogólnych zasad. Dla wielu firm kluczowe jest więc przekucie „kodeksowego defaultu” na bardziej przewidywalny schemat: cap odpowiedzialności, wyłączenia za utracone korzyści, wyłączenie odpowiedzialności za określone kategorie ryzyka.

Główne modele współpracy B2B i ich wpływ na łańcuch odpowiedzialności

Choć prawnie wszystko opiera się na umowie, technicznie i biznesowo stosuje się różne modele współpracy B2B, które inaczej rozkładają ryzyka i potencjalną odpowiedzialność za szkody.

• Klasyczny kontrakt usługowy – np. stała obsługa IT, marketing, księgowość. Zwykle odpowiedzialność ma charakter starannego działania (usługa), a nie gwarancji rezultatu. Kluczowe jest precyzyjne opisanie zakresu usług i poziomów świadczenia (SLA), żeby wiedzieć, kiedy faktycznie doszło do nienależytego wykonania.
• Umowa o dzieło / projektowa – np. stworzenie aplikacji, wdrożenie systemu, zaprojektowanie linii technologicznej. Tu częściej mowa o odpowiedzialności za rezultat. Kontrakty tego typu generują zwykle większe ryzyko roszczeń związanych z wadami dzieła, przekroczeniem terminów, niespełnieniem wymagań.
• Podwykonawstwo – gdy jedna firma realizuje kontrakt główny wobec klienta i część zadań zleca dalej. W prawie cywilnym i gospodarczym często pojawia się odpowiedzialność solidarna wobec zamawiającego głównego, a względem podwykonawcy – odpowiedzialność „jak za własne działanie” (art. 474 k.c.). Źle ułożone podwykonawstwo to prosta droga do sytuacji, w której wykonawca główny płaci za błędy podwykonawcy.
• Outsourcing procesów – przejęcie całej funkcji biznesowej (np. obsługa klienta, logistyka, payroll). Tu szkody mogą powstawać na wielu poziomach i dotykać wielu podmiotów (klienci końcowi, partnerzy biznesowi). Zakres odpowiedzialności trzeba rozłożyć: co należy do outsourcera, co zostaje po stronie zlecającego.
• Body leasing / staff augmentation – udostępnianie specjalistów do pracy w strukturach klienta. To model szczególnie ryzykowny, bo granica pomiędzy odpowiedzialnością dostawcy zasobów a odpowiedzialnością klienta za zarządzanie tymi zasobami bywa rozmyta. Jeśli kontrakt tego nie porządkuje, każda ze stron próbuje „zrzucić” odpowiedzialność na drugą.

Każdy z tych modeli inaczej kształtuje łańcuch odpowiedzialności. Największy problem pojawia się w dłuższych łańcuchach: dostawca – integrator – klient – klient końcowy. Bez spójnych zapisów w umowach na każdym poziomie łatwo o sytuację, w której ktoś odpowiada za szkody wygenerowane działaniach, na które realnie nie miał wpływu (np. błąd konfiguracji po stronie klienta, a odpowiedzialność łatwo „przypiąć” dostawcy systemu).

Podstawy odpowiedzialności za szkody w B2B – co faktycznie grozi firmie

Odpowiedzialność kontraktowa a deliktowa w relacjach B2B

W relacjach B2B kluczowe są dwa podstawowe reżimy odpowiedzialności: kontraktowa (za niewykonanie lub nienależyte wykonanie umowy) oraz deliktowa (za czyn niedozwolony – np. wyrządzenie szkody z naruszeniem ogólnych zasad, niezależnie od umowy). W praktyce spory między firmami w zdecydowanej większości toczą się na gruncie odpowiedzialności kontraktowej, bo ta jest przewidywalna i możliwa do modyfikacji w umowie.

Odpowiedzialność kontraktowa wynika z art. 471 k.c.: dłużnik zobowiązany jest do naprawienia szkody wynikłej z niewykonania lub nienależytego wykonania zobowiązania, chyba że jest to następstwem okoliczności, za które nie ponosi odpowiedzialności. W praktyce oznacza to, że punkt wyjścia jest „domyślnie na niekorzyść” wykonawcy. To wykonawca musi wykazać, że szkoda nie powstała z jego winy albo że wystąpiły okoliczności wyłączające odpowiedzialność (np. siła wyższa, działania klienta sprzeczne z instrukcją).

Odpowiedzialność deliktowa (art. 415 i n. k.c.) pojawia się rzadziej, głównie wtedy, gdy szkoda ma luźniejszy związek z kontraktem albo pokrzywdzonym jest osoba trzecia, która nie jest stroną umowy (np. użytkownik końcowy, osoba fizyczna, inny partner biznesowy). Dla bezpieczeństwa warto w umowie zadbać także o klauzule indemnifikacyjne (zwolnienia z odpowiedzialności / przejęcia roszczeń) na wypadek roszczeń deliktowych osób trzecich.

Elementy odpowiedzialności i typy szkód w B2B

Aby odpowiedzialność za szkodę w modelu B2B w ogóle powstała, trzeba wykazać trzy elementy:

• szkodę – rzeczywistą stratę albo utracone korzyści,
• związek przyczynowy między zachowaniem (niewykonaniem lub nienależytym wykonaniem umowy) a szkodą,
• winy lub obiektywne niewykonanie zobowiązania (w kontraktowej odpowiedzialności przyjmuje się domniemanie winy dłużnika).

W biznesie najczęściej mowa o szkodzie majątkowej. W jej ramach wyróżnia się:

• rzeczywistą stratę (damnum emergens) – np. koszt naprawy błędów, koszty dodatkowego serwisu, zakup zastępczych usług, kary od klienta, których można uniknąć przy prawidłowym wykonaniu świadczenia,
• utracone korzyści (lucrum cessans) – zysk, którego poszkodowany mógłby się spodziewać, gdyby szkoda nie wystąpiła, np. utracone przychody z niedziałającego sklepu internetowego w wyniku błędnego wdrożenia.

W praktyce procesowej najtrudniejsze do udowodnienia są utracone korzyści. Dlatego w umowach B2B często wprost wyłącza się odpowiedzialność za utracone korzyści lub ogranicza się ją poprzez limit kwotowy (cap) albo przez ograniczenie do ściśle wskazanych przypadków. Brak takich zastrzeżeń w umowie oznacza, że poszkodowany może teoretycznie dochodzić pełnego odszkodowania obejmującego także lucrum cessans – co bywa bardzo kosztowne i mocno nieprzewidywalne.

Odpowiedzialność za podwykonawców i osoby, którymi się posługujesz

Art. 474 k.c. wprowadza dla przedsiębiorców bardzo istotną zasadę: „dłużnik odpowiedzialny jest jak za własne działanie lub zaniechanie za działania i zaniechania osób, z których pomocą zobowiązanie wykonuje”. To oznacza, że jeśli jako wykonawca zlecasz część prac podwykonawcy, freelancerowi, agencji, a nawet korzystasz z pracowników, to wobec klienta odpowiadasz za ich błędy tak, jakbyś sam je popełnił.

Przykład: software house przekazuje część frontendu freelancerowi bez informowania klienta. Freelancer popełnia błąd bezpieczeństwa, co prowadzi do wycieku danych. Dla klienta bez znaczenia jest to, kto fizycznie pisał kod – jego kontrahentem jest software house i to on „łapie” pełną odpowiedzialność, a dopiero później może dochodzić regresu względem freelancera.

W praktyce oznacza to konieczność:

• wprowadzenia spójnych klauzul odpowiedzialności zarówno w umowie głównej z klientem, jak i w kontraktach z podwykonawcami (tak, aby to, co bierzesz na siebie wobec klienta, było możliwe do „odtworzenia” w dół łańcucha),
• pilnowania, by podwykonawca nie był słabszym ogniwem – jeśli Twoja odpowiedzialność jest ograniczona, nie podpisuj z podwykonawcą umowy, która uniemożliwia Ci dochodzenie od niego podobnego zakresu odszkodowania.

Konsekwencje braku szczegółowych zapisów w umowie B2B

Jeśli umowa B2B milczy na temat odpowiedzialności, automatycznie wchodzą w grę ogólne zasady kodeksowe. To nie jest stan neutralny – zwykle jest to scenariusz niekorzystny dla dostawcy usług lub wykonawcy dzieła, bo:

• odpowiada on za pełną szkodę (bez limitu cap), w tym potencjalnie za utracone korzyści,
• odpowiada w pełni za działania i zaniechania podwykonawców,
• nie ma z góry ustalonych, zamkniętych katalogów roszczeń – klient może dochodzić odszkodowania na wielu polach równolegle,
• nie ma ograniczenia co do czasu trwania odpowiedzialności poza przedawnieniem roszczeń (często 3 lub 6 lat, zależnie od rodzaju roszczenia).

Brak szczegółowych klauzul odpowiedzialności to w praktyce podpisanie weksla in blanco na wypadek szkód. Dopiero dobrze zaprojektowane zapisy o zakresie, limitach i wyłączeniach odpowiedzialności pozwalają zamienić ten weksel na realny, policzalny poziom ryzyka.

Analiza modelu współpracy – gdzie powstają szkody i kto je „łapie”

Mapowanie ryzyk na procesy i punkty styku

Żeby sensownie ułożyć odpowiedzialność w umowie B2B, trzeba najpierw zrozumieć, gdzie w procesie mogą powstać szkody. Najczęściej pojawiają się one w kilku obszarach:

• błędy wdrożenia – źle przeprowadzona konfiguracja, migracja danych, brak testów wydajnościowych, błędy integracji z innymi systemami,
• przerwy w świadczeniu usług – awarie, niedostępność systemu, przekroczenie czasów reakcji, niedotrzymanie SLA,
• utrata lub uszkodzenie danych – błędne migracje, błędy backupu, nadpisanie danych, nieodwracalne skasowanie,
• naruszenie praw własności intelektualnej – wykorzystanie nielegalnych komponentów, brak licencji, naruszenie praw autorskich osób trzecich,
• wyciek danych i naruszenia RODO – niewłaściwe zabezpieczenia, błędy w konfiguracji dostępu, brak umów powierzenia przetwarzania,
• błędne decyzje na podstawie danych – błędne raporty, algorytmy, kalkulacje, które prowadzą do złych decyzji biznesowych klienta.

Te punkty styku trzeba przełożyć na bardzo konkretne etapy procesu: sprzedaż i pre‑sales (deklaracje handlowe vs realny zakres odpowiedzialności), projektowanie rozwiązania (architektura, dobór technologii), development/konfigurację, testy, wdrożenie, utrzymanie i support. Dla każdego z nich da się zadać proste pytania: co tu może pójść nie tak, jaki typ szkody z tego wynika, kto ma na to realny wpływ i jakie dane są potrzebne, żeby później udowodnić brak winy albo ograniczyć odpowiedzialność.

Efektem takiego mapowania powinna być tabelka (choćby wewnętrzna, nie w samej umowie), gdzie po jednej stronie masz „zdarzenie ryzykowne” (np. „błąd migracji danych”), po drugiej – potencjalną szkodę („utrata danych historycznych, przestój sprzedaży online”) i trzecią kolumnę: przeniesienie ryzyka w umowie („odpowiedzialność dostawcy ograniczona do przywrócenia danych z backupu + odszkodowanie do wysokości miesięcznego wynagrodzenia”). Dopiero na takiej matrycy widać, czy model współpracy i rozkład odpowiedzialności są spójne z rzeczywistym procesem.

Drugi krok to przypisanie „właścicieli ryzyka” po obu stronach. Jeśli klient samodzielnie dostarcza dane wejściowe, ma własny zespół IT, integruje systemy lub decyduje o konfiguracji bezpieczeństwa, część ryzyk powinna być wprost przypisana po jego stronie (np. poprzez obowiązki współdziałania i klauzule o odpowiedzialności za jakość materiałów dostarczonych dostawcy). Tip: im bardziej klient ingeruje w proces i wyłącza standardowe procedury dostawcy, tym mocniej trzeba to odnotować w dokumentacji projektowej i w aneksach do umowy.

Na końcu dobrze jest porównać tę mapę ryzyk z przyjętym modelem rozliczeń (time & material, fixed price, success fee, abonament). Inne ryzyka „łapie” dostawca przy stałej opłacie za utrzymanie krytycznego systemu 24/7, a inne przy jednorazowym wdrożeniu bez dalszego supportu. Jeśli odpowiedzialność jest ułożona tak samo dla wszystkich modeli, zwykle oznacza to, że w którymś wariancie ktoś bierze na siebie więcej, niż realnie kontroluje.

Umowa B2B, która dobrze odwzorowuje model współpracy i przepływ odpowiedzialności, działa jak schemat elektryczny – wiadomo, gdzie płynie prąd, gdzie są bezpieczniki i co się stanie przy zwarciu. Dzięki temu szkoda nie jest już abstrakcyjnym „kataklizmem”, tylko zdarzeniem, które da się obsłużyć procedurą, limitem i jasno podzieloną odpowiedzialnością po obu stronach.

Zakres odpowiedzialności w umowie B2B – jak to precyzyjnie opisać

Rozróżnienie odpowiedzialności za rezultat i za należytą staranność

Pierwszy techniczny wybór przy projektowaniu klauzul odpowiedzialności to odpowiedź na pytanie: czy wykonawca odpowiada za konkretny rezultat (np. „działający sklep z określonym SLA”), czy za należyte staranie się przy świadczeniu usług (np. „świadczenie usług programistycznych według najlepszych praktyk”).

Przy umowie rezultatu (często model „fixed price” lub wdrożenie „pod klucz”) wykonawca odpowiada za osiągnięcie z góry zdefiniowanego efektu. Szkoda zwykle powstaje, gdy rezultat nie został osiągnięty w ogóle albo jest wadliwy. Umowa powinna wtedy zawierać:

• precyzyjny opis rezultatu – w załącznikach: specyfikacja funkcjonalna, wymagania niefunkcjonalne, SLA, akceptowalne poziomy błędów,
• jasne kryteria odbioru – scenariusze testowe, protokoły odbioru, terminy na zgłaszanie wad,
• mechanizmy naprawcze – poprawki w ramach wynagrodzenia, tryb usuwania usterek, ewentualne kary umowne za brak usunięcia w terminie.

Przy umowie starannego działania (typowe przy modelu time & material, body leasingu, usługach konsultingowych) kluczowe jest opisanie, jakiego poziomu staranności oczekuje druga strona. Bez tego klient będzie próbował „przekształcić” usługę w rezultat, argumentując, że skoro „programista był seniorem”, to system „powinien działać bezbłędnie”. Tu zakres odpowiedzialności warto oprzeć na:

• standardach branżowych – np. „zgodnie z dobrymi praktykami inżynierii oprogramowania” (i doprecyzować, jakie standardy referencyjne stosujecie),
• zakresie kontroli wykonawcy – jasno zapisać, które elementy procesu są po stronie klienta (np. testy akceptacyjne, konfiguracja produkcyjna),
• klauzulach „reasonable efforts” – opisujących, jakie działania minimalnie muszą zostać podjęte, zanim można mówić o dochowaniu należytej staranności.

Zakres szkód objętych odpowiedzialnością

Kolejny krok to zawężenie (lub świadome pozostawienie szerokiego) katalogu szkód, za które strony odpowiadają. Zamiast ogólnego „strony odpowiadają za szkodę na zasadach ogólnych” da się użyć bardziej granularnego podejścia:

• szkody bezpośrednie – koszty naprawy, przywrócenia stanu poprzedniego, zakup zastępczych usług, kary zapłacone przez klienta wyłącznie z powodu błędu wykonawcy,
• szkody pośrednie – efekt domina, np. utrata reputacji, utrata relacji z kontrahentami klienta, zakłócenie procesów wewnętrznych,
• szkody specyficzne dla danego modelu – np. sankcje regulatora za naruszenie RODO, opłaty za dodatkowe audyty bezpieczeństwa, koszty ręcznego przetwarzania danych zamiast automatycznego.

W praktycznych umowach B2B często stosuje się formułę: wykonawca odpowiada wyłącznie za szkody bezpośrednie poniesione przez klienta, do określonego limitu, zaś wszelka odpowiedzialność za szkody pośrednie i następcze jest wyłączona – z określonymi wyjątkami (np. rażące niedbalstwo, naruszenie praw własności intelektualnej, wyciek danych).

Uwaga: w umowach, w których pojawia się przetwarzanie danych osobowych albo element compliance, nie wystarczy globalne wyłączenie szkód pośrednich. Trzeba wprost rozpisać, jaki typ szkód „regulacyjnych” jest objęty odpowiedzialnością (np. koszty notyfikacji naruszenia, obsługa komunikacji z UODO, praca zespołu prawnego), a jakie nie (np. utrata wyceny spółki na skutek publikacji o incydencie).

Obowiązki współdziałania i ich wpływ na odpowiedzialność

Zakres odpowiedzialności nie istnieje w próżni – zależy od tego, co robi (i czego nie robi) druga strona. Dlatego w dobrze napisanej umowie B2B obowiązki współdziałania klienta nie są „miłym dodatkiem”, tylko kluczowym elementem konstrukcji odpowiedzialności.

Typowy zestaw takich obowiązków obejmuje:

• dostarczanie danych wejściowych w określonym formacie i jakości (np. oczyszczone dane, pliki w ustalonych strukturach),
• zapewnienie dostępu do środowisk, zasobów i osób decyzyjnych,
• testy akceptacyjne po stronie klienta w określonych terminach,
• akceptację lub zgłaszanie zastrzeżeń w ustalonych oknach czasowych (np. 5–10 dni roboczych),
• przestrzeganie polityk bezpieczeństwa i instrukcji producenta/dostawcy.

Następnie trzeba to spiąć z odpowiedzialnością: brak współdziałania powoduje zawieszenie odpowiedzialności wykonawcy za termin lub rezultat w zakresie, w jakim opóźnienie lub wada wynikają z zachowania klienta. Dobrze działa mechanizm „change logu” – każda decyzja klienta, która wyłącza lub modyfikuje standardowe procedury dostawcy (np. pominięcie testów wydajnościowych), jest zapisywana i od razu opisana co do wpływu na odpowiedzialność.

Przykład: klient żąda skrócenia harmonogramu wdrożenia o połowę i rezygnuje z części testów UAT. W aneksie pojawia się zdanie w stylu: „Strony zgodnie przyjmują, że Wykonawca nie ponosi odpowiedzialności za wady ujawnione po wdrożeniu, które mogły zostać wykryte w ramach etapów testów UAT, z których Zamawiający zrezygnował”. To minimalizuje późniejsze spory o „czyja to wina”.

Odpowiedzialność za SLA, czasy reakcji i dostępność

W modelach abonamentowych i utrzymaniowych odpowiedzialność silnie „przykleja się” do SLA (Service Level Agreement). Typowy błąd: zostawić SLA jako miękki załącznik „marketingowy”, bez powiązania go z odpowiedzialnością odszkodowawczą.

Technicznie SLA powinno definiować co najmniej:

• metryki – dostępność (uptime), czasy reakcji, czasy usunięcia awarii,
• klasy incydentów – np. P1 krytyczne, P2 wysokie, P3 średnie, z przypisanymi czasami reakcji,
• okna serwisowe i wyłączenia – kiedy niedostępność nie liczy się do SLA (planowane prace, siła wyższa, awarie po stronie operatorów zewnętrznych).

Potem dopiero dochodzi link do odpowiedzialności:

• mechanizm kredytów serwisowych (service credits) – obniżka wynagrodzenia albo darmowy okres usługi za naruszenie SLA,
• granica między rekompensatą „SLA-ową” a pełnym odszkodowaniem – np. „świadczenia wynikające z niniejszego SLA wyłączają inne roszczenia odszkodowawcze z tytułu naruszenia poziomów dostępności, z wyjątkiem szkód powstałych z winy umyślnej lub rażącego niedbalstwa”.

Jeśli tego nie ma, klient może traktować kredyty SLA jedynie jako bonus, a i tak dochodzić pełnych odszkodowań za każdy przestój – co zwykle zupełnie nie odpowiada kalkulacji abonamentu po stronie dostawcy.

Limity i wyłączenia odpowiedzialności – konstrukcja, która realnie działa

Limity kwotowe (cap) – modele i pułapki

Limit odpowiedzialności (cap) to twardy bezpiecznik. Problem pojawia się, gdy jest narysowany abstrakcyjnie („100 000 zł, bo tak się przyjęło”). Limit powinien wynikać z:

• skali kontraktu – roczna wartość wynagrodzenia,
• charakteru projektu – krytyczność systemu, branża (finanse, medycyna, e‑commerce),
• zidentyfikowanych ryzyk – matryca ryzyk omawiana wcześniej,
• realnego pokrycia w polisach ubezpieczeniowych (OC zawodowe, cyber).

Najczęstsze konstrukcje limitów:

• procent od łącznego wynagrodzenia – np. 100% lub 150% wartości netto wynagrodzenia zapłaconego za ostatnie 12 miesięcy,
• stała kwota – gdy kontrakt jest jednorazowy albo jego wartość jest niewielka, a ryzyka i tak są ograniczone,
• hybryda – „niższa z kwot: łączna wartość wynagrodzenia z ostatnich 12 miesięcy lub X zł”.

Uwaga techniczna: limit powinien jednoznacznie określać, czy dotyczy wszystkich roszczeń łącznie („aggregate”), czy każdego incydentu osobno. Sformułowanie „za każdy przypadek szkody” bez jasnego zdefiniowania „przypadku” otwiera drogę do nadużyć po obu stronach.

Basket i de minimis – filtr na drobne roszczenia

Przy długoterminowej współpracy sensowne jest wprowadzenie progów de minimis i tzw. basketów, znanych z transakcji M&A. Chodzi o to, by uniknąć sytuacji, w której strony „strzelają” do siebie drobnymi roszczeniami po kilkaset złotych.

Dwa typowe mechanizmy:

• de minimis – pojedyncze roszczenie poniżej określonej kwoty (np. 1 000 zł) nie podlega dochodzeniu,
• basket – odpowiedzialność uruchamia się dopiero po przekroczeniu łącznego progu szkód (np. 10 000 zł w danym roku), przy czym można ustalić, czy po przekroczeniu progu liczy się całość szkód, czy tylko nadwyżkę.

To rozwiązanie szczególnie dobrze działa w umowach o utrzymanie i rozwój systemów, gdzie występują drobne incydenty, ale realne „ciężkie” szkody pojawiają się rzadko.

Wyłączenia odpowiedzialności – jak nie przestrzelić

Wyłączenia odpowiedzialności (exclusions) to miejsce, gdzie strony często przesadzają. Zdanie w stylu „Wykonawca nie ponosi odpowiedzialności za jakąkolwiek szkodę” jest w praktyce ryzykowne i nierzadko nieważne w części, zwłaszcza gdy wchodzi w grę rażące niedbalstwo, szkoda na osobie czy naruszenie norm bezwzględnie obowiązujących.

Bezpieczniejszy (i skuteczniejszy) model to:

• ogólne ograniczenie – np. brak odpowiedzialności za szkody pośrednie, utracone korzyści, utratę reputacji,
• katalog wyjątków, gdzie ograniczenia nie działają lub działają inaczej, np.:
  • naruszenie praw własności intelektualnej osób trzecich z winy wykonawcy,
  • umyślne naruszenie obowiązków poufności,
  • umyślne lub rażąco niedbałe naruszenie bezpieczeństwa danych osobowych.

Tip: zamiast próbować „wyłączyć wszystko”, lepiej precyzyjnie nazwać obszary, które akceptujecie jako szczególnie ryzykowne i dla nich ustalić osobne limity (np. wyższy cap dla IP i danych osobowych, niższy dla typowych błędów wdrożeniowych).

Odpowiedzialność za naruszenie praw własności intelektualnej

W projektach IT, marketingowych, kreatywnych i R&D temat IP (intellectual property) generuje osobny, „grubszy” poziom ryzyka. Klient zazwyczaj oczekuje, że:

• materiały, kod i rozwiązania nie naruszają praw osób trzecich,
• w razie roszczeń podmiotów trzecich wykonawca weźmie je „na siebie” (zwolnienie z odpowiedzialności, tzw. indemnity),
• ewentualna szkoda zostanie naprawiona, także wizerunkowo i operacyjnie (np. wymiana komponentu na legalny).

Tu zwykły „cap” bywa niewystarczający. Często stosuje się osobną klauzulę odszkodowawczą obejmującą:

• zobowiązanie wykonawcy do obrony klienta w sporach dotyczących IP,
• pokrycie uzasadnionych kosztów procesu, ugód i odszkodowań,
• obowiązek dostarczenia rozwiązania zastępczego (np. zamiany komponentu na bezkolizyjny licencyjnie),
• często wyższy, odrębny limit odpowiedzialności albo brak ograniczenia dla szkód wynikających z umyślnego naruszenia IP.

Jednocześnie wykonawca powinien zadbać o to, aby roszczenia „IP” nie obejmowały sytuacji, w których to klient wymusił użycie określonych materiałów (np. dostarczonych stocków, fontów, bibliotek open source bez weryfikacji licencji). Tu przydają się klauzule: „wykonawca nie ponosi odpowiedzialności za naruszenia praw osób trzecich wynikające z wykorzystania materiałów, danych lub wytycznych dostarczonych przez klienta”.

Przy bardziej rozbudowanej współpracy sensowne jest też zsynchronizowanie klauzul IP z procesem wytwórczym: kto decyduje o wyborze bibliotek open source, kto weryfikuje licencje, jak wygląda audyt kodu przed releasem. Jeżeli w umowie pojawia się obowiązek stosowania określonego stosu technologicznego albo konkretnego frameworka, dobrze dopisać, która strona bierze na siebie ciężar prawny takiej decyzji. To później zamyka drogę do przerzucania się odpowiedzialnością w sytuacji sporu z podmiotem trzecim.

Praktycznie przydaje się powiązanie odpowiedzialności za IP z polisą ubezpieczeniową (np. IP infringement, cyber). W umowie można wskazać minimalne sumy gwarancyjne i obowiązek utrzymywania ochrony przez cały okres kontraktu, a czasem jeszcze przez określony czas po jego zakończeniu (tzw. okres „tail”). Z jednej strony podnosi to bezpieczeństwo klienta, z drugiej wymusza na wykonawcy realne oszacowanie ryzyk i weryfikację własnego łańcucha dostaw (podwykonawcy, licencje, komponenty SaaS).

Dobrym nawykiem jest też dodanie procedury postępowania przy roszczeniach IP: terminy zgłoszenia, wymóg niepodejmowania samodzielnych negocjacji z podmiotem trzecim bez uzgodnienia z drugą stroną, dostęp do informacji i dokumentów. Bez tego wykonawca formalnie odpowiada za roszczenia, ale de facto dowiaduje się o pozwie wtedy, gdy jest już po ugodzie podpisanej przez klienta – a to prosta droga do konfliktu o zakres odszkodowania.

Wreszcie, klauzule IP warto powiązać z modelem przenoszenia lub licencjonowania praw. Inaczej projekt wygląda, gdy przenoszone są autorskie prawa majątkowe do całości kodu, a inaczej, gdy klient dostaje licencję do rozwiązania opartego o wiele komponentów osób trzecich. Tam, gdzie „czystej” własności po prostu nie da się zbudować, odpowiedzialność za IP powinna być rozłożona proporcjonalnie do tego, kto kontroluje dany fragment układanki.

Jeżeli umowa ma być realnym narzędziem zarządzania ryzykiem, a nie tylko formalnością do szuflady, każda z opisanych wyżej konstrukcji – model współpracy, matryca ryzyk, SLA, limity, wyłączenia i IP – musi ze sobą współgrać. Dopiero wtedy strony wiedzą, gdzie ryzyko powstaje, kto je przejmuje, ile jest w stanie „udźwignąć” i jak technicznie wygląda ścieżka wyjścia, gdy coś pójdzie nie tak.

Odpowiedzialność w łańcuchu podwykonawców i podmiotów powiązanych

Podwykonawcy – kto faktycznie odpowiada wobec klienta

W modelach B2B z udziałem software house’ów, agencji marketingowych czy integratorów systemów standardem jest korzystanie z podwykonawców. Z perspektywy odpowiedzialności za szkody krytyczne jest ustawienie relacji:

• Klient – wykonawca główny (contractor, prime),
• Wykonawca – podwykonawca (subcontractor, vendor).

Podstawowy mechanizm prawa cywilnego: wobec klienta odpowiada wykonawca główny, a z podwykonawcą rozlicza się wewnętrznie (regres). Jeżeli w umowie z klientem znajdzie się ogólny zakaz korzystania z podwykonawców, a w praktyce i tak są używani, tworzy się duży problem dowodowy i ubezpieczeniowy przy sporze.

Bezpieczniejsza konstrukcja niż „zakaz podwykonawców” to:

• obowiązek zgłoszenia i akceptacji kluczowych podwykonawców (np. tych, którzy przetwarzają dane osobowe lub budują kluczowe moduły),
• zasada, że wykonawca odpowiada za działania podwykonawców jak za własne, bez możliwości „rozmywania” winy,
• wymóg, aby umowy z podwykonawcami odzwierciedlały kluczowe obowiązki wobec klienta (back-to-back), w tym limity i wyłączenia odpowiedzialności oraz standardy bezpieczeństwa.

Tip: back-to-back nie oznacza 1:1 skopiowania całej umowy, ale przeniesienie tych fragmentów, które tworzą ryzyko deliktowe (szkody) – SLA, IP, bezpieczeństwo, odpowiedzialność za dane, kary umowne.

Łańcuch SaaS, PaaS, IaaS – rozdzielenie odpowiedzialności

Przy projektach opartych o chmurę (SaaS, PaaS, IaaS) wykonawca często nie kontroluje całego stacku. Klient widzi jedną umowę B2B, ale w tle działa kilka lub kilkanaście serwisów trzecich. Umowa powinna rozróżniać:

• usługi własne wykonawcy (za nie odpowiada pełnym zakresem uzgodnionym w umowie),
• usługi zewnętrznych dostawców, gdzie wykonawca jest głównie integratorem lub resellerem.

Szczególnie przydatne są wtedy klauzule:

• „W zakresie, w jakim wykonawca wykorzystuje usługi dostawców zewnętrznych, odpowiada za ich działanie w granicach, w jakich jest uprawniony do dochodzenia roszczeń wobec tych dostawców” – spina to odpowiedzialność z realnym wpływem na SLA i warunki tych usług,
• „Klient przyjmuje do wiadomości, że obowiązują go regulaminy i warunki dostawców zewnętrznych wymienionych w załączniku nr X” – ale uwaga, taka klauzula nie może całkowicie „zmywać” odpowiedzialności wykonawcy za dobór i integrację tych usług.

Uwaga: jeżeli wykonawca „pakuje” usługę SaaS w swój produkt (white-label), a równocześnie próbuje całkowicie wyłączyć odpowiedzialność za jej działanie, mamy klasyczną minę prawną. Klient rozlicza się z wykonawcą, nie z globalnym dostawcą chmury, więc oczekuje choćby minimalnego bufora odpowiedzialności. Rozwiązaniem jest np. ograniczenie odpowiedzialności wykonawcy do:

• należytej staranności w wyborze dostawcy i konfiguracji,
• przekazywania reklamacji i informacji,
• pokrycia szkód wynikłych z błędnej integracji lub konfiguracji po stronie wykonawcy, ale nie z „czystych” awarii po stronie dostawcy IaaS/SaaS.

Grupa kapitałowa, spółki powiązane i „multi-tenant” współpraca

W praktyce B2B do współpracy często dołączają spółki z grupy klienta (np. oddziały zagraniczne) albo wielu klientów korzysta z jednego, współdzielonego rozwiązania (multi-tenant). Generuje to kilka dodatkowych pytań o odpowiedzialność:

• czy wykonawca odpowiada wobec każdej spółki z grupy tak, jak wobec „głównego” klienta,
• jak liczyć limity odpowiedzialności – per podmiot, per grupa, czy wspólny „koszyk”,
• co się dzieje, gdy szkoda jednej spółki wynika z błędu wywołanego działaniem innej spółki (np. wspólna baza danych).

Technicznie da się to ogarnąć dwoma ruchami:

1. Wprowadzić definicję „Grupy Klienta” i „Uprawnionych Podmiotów” (affiliates), z jasno wskazanym zakresem usług i odpowiedzialności wobec każdego z nich.
2. Określić, czy limit odpowiedzialności jest wspólny dla całej grupy (aggregate cap), czy każdy podmiot ma „własny” limit. To pozorny detal, ale przy globalnym wdrożeniu ERP różnica może decydować o przeżyciu mniejszego dostawcy.

Tip: jeżeli limit jest wspólny, dobrze zdefiniować kolejność „konsumpcji” capu (np. na zasadzie „kto pierwszy zgłosi roszczenie, ten korzysta”) lub mechanizm proporcjonalny. Inaczej konflikt między spółkami z grupy może być przeniesiony wprost na wykonawcę.

Odpowiedzialność za dane, bezpieczeństwo i ciągłość działania

Dane osobowe vs. dane biznesowe – dwa różne reżimy ryzyka

W B2B często miesza się odpowiedzialność za dane osobowe (RODO/GDPR) z odpowiedzialnością za dane stricte biznesowe (np. konfiguracje, dane transakcyjne, tajemnice przedsiębiorstwa). Tymczasem to są dwa różne wektory ryzyka:

• dane osobowe – reżim regulacyjny, nadzór PUODO/organów zagranicznych, administracyjne kary pieniężne, zawiadomienia o naruszeniu,
• dane biznesowe – umowne odszkodowania, utrata przewagi konkurencyjnej, zakłócenie operacji, roszczenia kontrahentów klienta.

W umowie B2B obie warstwy powinny mieć odrębne klauzule odpowiedzialności, nawet jeśli technicznie są przechowywane w tym samym systemie. Przykładowo:

• dla danych osobowych – odwołanie do umowy powierzenia (DPA), opis naruszeń danych (data breach), zasady zgłaszania incydentów, współpracy przy postępowaniach regulatora, osobny limit odpowiedzialności, często powiązany z karami administracyjnymi,
• dla danych biznesowych – opis odpowiedzialności za ich utratę, uszkodzenie, nieautoryzowany dostęp, mechanizmy odtworzenia (backup, disaster recovery) i związane z tym SLA.

Uwaga: zbyt ogólne stwierdzenie „wykonawca nie ponosi odpowiedzialności za szkody wynikłe z utraty danych” w połączeniu z DPA potrafi stworzyć sprzeczność wewnętrzną. Dobrze jest jasno napisać, czego dotyczy wyłączenie (np. utraty niezabezpieczonych danych przesłanych niezgodnie z procedurą) i gdzie wykonawca bierze pełną odpowiedzialność (np. zniszczenie danych wskutek braku backupu, choć backup był częścią umowy).

Bezpieczeństwo informacji i cyberincydenty – parametry, a nie ogólniki

„Zapewnimy wysoki poziom bezpieczeństwa” brzmi dobrze marketingowo, ale kontraktowo prawie nic nie znaczy. Klauzule bezpieczeństwa powinny dać się przełożyć na konkretne działania i parametry:

• standardy bezpieczeństwa – np. ISO 27001, SOC 2, NIS2, wybrane normy techniczne (OWASP ASVS dla aplikacji),
• mechanizmy techniczne – szyfrowanie danych w spoczynku i w tranzycie, segmentacja sieci, MFA, logowanie i monitoring,
• procedury reagowania – czas wykrycia i zgłoszenia incydentu (MTTD/MTTR), ścieżka eskalacji, rola każdej strony,
• testy bezpieczeństwa – audyty, testy penetracyjne, skanowanie podatności, częstotliwość i zakres.

Z punktu widzenia odpowiedzialności za szkody ważne jest rozróżnienie:

• incydentu wynikającego z niewdrożenia lub nienależytego stosowania uzgodnionych środków (tu odpowiedzialność wykonawcy jest pełniejsza),
• incydentu, który jest efektem nowej, nieznanej podatności (zero-day), mimo wdrożenia rozsądnych środków bezpieczeństwa – w takim scenariuszu odpowiedzialność często jest ograniczana do „należytej staranności” i kosztów bezpośredniego usuwania skutków.

Tip: doprecyzowanie, że wykonawca odpowiada za szkody wynikłe z rażących zaniedbań w obszarze bezpieczeństwa (np. brak aktualizacji przez długi czas, brak backupu, przechowywanie haseł wprost w bazie) ułatwia późniejszą ocenę, czy incydent mieści się w „normalnym” ryzyku, czy już w niedbalstwie.

Ciągłość działania (BCP/DRP) a odpowiedzialność za przestoje

Umowy B2B dotyczące systemów krytycznych często zawierają wymagania dotyczące planu ciągłości działania (BCP – Business Continuity Plan) i planu odtwarzania po awarii (DRP – Disaster Recovery Plan). Samo istnienie planu nic nie daje, jeśli umowa nie wiąże go z odpowiedzialnością za szkody wynikające z przestoju.

Przydatne są trzy kroki:

1. Zdefiniować kategorie systemów i usług – np. „krytyczne”, „istotne”, „pomocnicze”. Dla każdej kategorii określić docelowe RTO (Recovery Time Objective – czas przywrócenia) i RPO (Recovery Point Objective – utrata danych w czasie).
2. Powiązać RTO/RPO ze SLA – np. przekroczenie RTO o X godzin rodzi odpowiedzialność odszkodowawczą lub kary umowne.
3. Związać odpowiedzialność z realnym wpływem wykonawcy – jeżeli część infrastruktury jest po stronie klienta, brak sensu obciążać wykonawcy pełną odpowiedzialnością za przekroczenie RTO wynikłe z awarii prądu w serwerowni klienta.

Przykład: jeżeli system e‑commerce klienta stoi przez kilka godzin z powodu awarii klastra bazodanowego zarządzanego przez wykonawcę, a w SLA ustalono RTO = 2h, przekroczenie tego parametru może automatycznie generować odpowiedzialność za utracone transakcje w granicach ustalonego limitu. Jeżeli jednak downtime wynika z błędu operatora logistycznego (po stronie klienta), odpowiedzialność wykonawcy nie powinna być uruchamiana.

Mechanizmy naprawcze i procedury zgłaszania szkód

Obowiązek minimalizacji szkody (mitigacja)

Prawo cywilne zakłada ogólny obowiązek zapobiegania zwiększaniu się szkody. Dobrze jednak, gdy umowa operacjonalizuje ten obowiązek, bo w IT liczy się czas i informacja. Bez doprecyzowania strony mogą się wzajemnie oskarżać o „niezrobienie wszystkiego, co możliwe”, co jest mało mierzalne.

Sprawdza się prosty schemat:

• definicja „Incydentu” i „Szkody”,
• obowiązek niezwłocznego (np. w ciągu X godzin) zgłoszenia incydentu odpowiednim kanałem (system zgłoszeń, e‑mail dedykowany),
• minimalne czynności po stronie klienta (np. blokada kont, odłączenie podatnych systemów, zastosowanie obejść – workarounds),
• minimalne czynności po stronie wykonawcy (diagnoza, patch, rollback, wsparcie w kontaktach z innymi dostawcami).

Uwaga: bez takiej procedury klient może utracić prawo do dochodzenia części roszczeń, jeżeli zaniechał podstawowych działań (np. zignorował prośbę o pilną aktualizację). To z kolei powinno być wprost wpisane do katalogu okoliczności ograniczających odpowiedzialność wykonawcy.

Terminy i forma zgłoszenia roszczeń

W praktyce spory o szkody zaczynają się od sporu o… terminy. Kontrakt może wprowadzać umowne przedawnienie roszczeń (oczywiście w granicach dopuszczalnych przez prawo), a także wymogi formalne zgłoszenia:

• termin zgłoszenia roszczenia od momentu powzięcia informacji o szkodzie lub incydencie (np. 30 lub 90 dni),
• wymagany zakres informacji w zgłoszeniu (opis zdarzenia, szacunkowa wysokość szkody, dokumenty),
• związek między zgłoszeniem incydentu a zgłoszeniem roszczenia – nie zawsze musi to być to samo pismo, ale dobrze, żeby umowa wskazywała minimalne etapy.

Tip: zbyt krótkie terminy (np. 7 dni na zgłoszenie czegokolwiek) często są po prostu nierealistyczne przy złożonych usługach. Rozsądny kompromis to rozdzielenie terminu na:

• zgłoszenie incydentu – bardzo krótki, żeby umożliwić reakcję techniczną,
• szczegółowe roszczenie – dłuższy, który pozwala zebrać dane i wyliczyć szkodę.

Priorytet działań: naprawa vs. odszkodowanie pieniężne

W wielu projektach IT czy maintenance bardziej racjonalne jest w pierwszej kolejności naprawienie szkody w naturze (np. przywrócenie danych z backupu, odtworzenie środowiska, poprawki w kodzie), a dopiero potem rozliczenie finansowe. Umowa może to ustrukturyzować:

• pierwszeństwo naprawy (np. obowiązek podjęcia działań naprawczych w ciągu X godzin od zgłoszenia),
• czasowe „zamrożenie” części roszczeń finansowych na czas prób przywrócenia stanu sprzed incydentu,
• jasny moment „przecięcia” – kiedy strony uznają, że szkody nie da się już naprawić w naturze albo byłoby to ekonomicznie nieuzasadnione i przechodzą do pełnego rozliczenia pieniężnego.

Przykład: awaria modułu płatności uniemożliwia klientom finalizowanie zamówień. Wykonawca ma 4 godziny na przywrócenie działania produkcji z backupu lub obejścia (np. przełączenie na bramkę rezerwową). Dopiero jeżeli po tym czasie system nadal nie działa, uruchamiany jest mechanizm naliczania odszkodowania lub kar umownych. Klient nie może od razu żądać maksymalnego limitu odszkodowania, jeśli realnie po 40 minutach wszystko wróciło do normy.

Dobrą praktyką jest wprowadzenie etapowej ścieżki: incydent → działania ratunkowe (hot fix, obejście) → działania trwałe (proper fix, refactor, zmiany architektoniczne) → rozliczenie szkody. Pozwala to oddzielić presję „żeby system wstał” od spokojnej analizy, jakie straty faktycznie powstały i czy mieszczą się w ramach uzgodnionych limitów oraz wyłączeń.

Żeby uniknąć sporów o to, czy proponowana przez wykonawcę naprawa jest „wystarczająca”, przydaje się minimalny opis jakości naprawy: czy „przywrócenie działania” oznacza powrót do pełnej funkcjonalności, czy dopuszcza czasowe ograniczenia (np. wyłączone raporty, mniejsza wydajność). Im bardziej krytyczny system, tym bardziej precyzyjny powinien być ten opis – w przeciwnym razie klient będzie twierdził, że naprawa jest tylko częściowa i należą się pełne roszczenia finansowe.

Na koniec całość trzeba spiąć z biznesową praktyką stron. Modele współpracy B2B, limity i wyłączenia odpowiedzialności, SLA oraz procedury zgłaszania szkód działają dopiero wtedy, gdy są spójne: z architekturą rozwiązania, realnym podziałem obowiązków, ryzykiem regulacyjnym i budżetem na incydenty. Dobrze skonstruowana umowa nie usuwa ryzyka, ale przenosi je tam, gdzie jest na nie faktyczna kontrola – i tam, gdzie opłaca się je finansować.

Najczęściej zadawane pytania (FAQ)

Co to jest odpowiedzialność w umowie B2B i skąd się bierze?

W relacji B2B odpowiedzialność wynika głównie z umowy cywilnoprawnej zawartej między przedsiębiorcami i z ogólnych przepisów Kodeksu cywilnego (głównie art. 471 k.c. i następne). Strony umawiają się na określone świadczenie (usługa, dzieło, dostawa), a jeśli zostanie ono wykonane wadliwie, z opóźnieniem lub w ogóle – pojawia się odpowiedzialność kontraktowa.

Domyślnie wykonawca odpowiada za szkodę w pełnej wysokości, chyba że w umowie wprowadzi limity, wyłączenia lub inne modyfikacje. Brak szczegółowych zapisów nie „zeruje” ryzyka – oznacza stosowanie ogólnych zasad z kodeksu, które zwykle są dla wykonawcy dość surowe.

Czym różni się odpowiedzialność w B2B od odpowiedzialności pracownika na etacie?

Pracownik etatowy jest chroniony przez Kodeks pracy – za szkody nieumyślne wyrządzone pracodawcy odpowiada co do zasady do wysokości trzymiesięcznego wynagrodzenia, a za szkody wobec osób trzecich zasadniczo odpowiada pracodawca. Współpracownik B2B takich limitów z automatu nie ma.

W modelu B2B przedsiębiorca odpowiada całym swoim majątkiem na zasadach Kodeksu cywilnego. Jeżeli nie ograniczy tego w umowie (np. cap odpowiedzialności, wyłączenie utraconych korzyści), teoretycznie może odpowiadać za pełną wysokość szkody, nawet jeśli przekracza ona jego roczne przychody czy majątek firmowy.

Jakie zapisy o odpowiedzialności powinny znaleźć się w umowie B2B?

Minimum techniczne w kontrakcie to:

• jasne określenie zakresu świadczenia (co dokładnie robisz) i standardu wykonania (np. SLA, parametry jakościowe),
• limit odpowiedzialności (cap) – np. do określonej kwoty, procentu wynagrodzenia rocznego itp.,
• wyłączenie odpowiedzialności za utracone korzyści (lucrum cessans), jeśli to możliwe biznesowo,
• zdefiniowanie kategorii szkód, za które strona nie odpowiada (np. szkody pośrednie, utrata reputacji),
• zasady kar umownych – za co, w jakiej wysokości, czy wyczerpują całą odpowiedzialność za dany typ naruszenia.

Tip: dobra praktyka to powiązanie odpowiedzialności z obiektywnymi miernikami (logi systemowe, KPI, raporty z SLA). Ułatwia to późniejsze dowodzenie, czy doszło do nienależytego wykonania umowy.

Na czym polega różnica między odpowiedzialnością kontraktową a deliktową w B2B?

Odpowiedzialność kontraktowa dotyczy sytuacji, w których szkoda wynika z niewykonania lub nienależytego wykonania umowy (art. 471 k.c.). To podstawowy tryb w relacjach B2B – da się go dość mocno modyfikować w kontrakcie (limity, wyłączenia, kary umowne).

Odpowiedzialność deliktowa (art. 415 k.c. i nast.) odnosi się do czynów niedozwolonych – szkód wyrządzonych z naruszeniem ogólnych zasad prawa, niezależnie od treści umowy. Pojawia się np. gdy szkodę ponosi osoba trzecia, która nie jest stroną kontraktu (klient końcowy, inny partner). Dlatego w umowach B2B stosuje się klauzule indemnifikacyjne (przejęcie roszczeń, zwolnienie z odpowiedzialności), które mają uporządkować, kto finalnie ponosi koszty takich roszczeń.

Jak model współpracy (usługa, dzieło, outsourcing, body leasing) wpływa na odpowiedzialność?

Przy klasycznej umowie usługowej zwykle chodzi o „należytą staranność” – odpowiadasz za to, że działasz profesjonalnie, ale nie gwarantujesz konkretnego rezultatu biznesowego. W umowie o dzieło czy projekcie IT częściej odpowiadasz już za konkretny rezultat (np. działający system zgodny ze specyfikacją), więc ryzyko roszczeń za wady, opóźnienia czy niespełnienie wymogów jest wyższe.

W podwykonawstwie i dłuższych łańcuchach (dostawca – integrator – klient – klient końcowy) pojawia się odpowiedzialność solidarna i odpowiedzialność „jak za własne działanie” za podwykonawcę (art. 474 k.c.). W body leasingu granica, kto odpowiada za błędy „wypożyczonego” specjalisty – dostawca czy klient, który nim zarządza – bywa rozmyta, jeśli umowa nie opisze tego precyzyjnie.

Jak można ograniczyć swoją odpowiedzialność w umowie B2B, żeby nie zbankrutować przy jednej szkodzie?

Podstawowe narzędzia to:

• limit (cap) odpowiedzialności – np. do wysokości rocznego wynagrodzenia z umowy lub konkretnej kwoty,
• wyłączenie odpowiedzialności za utracone korzyści oraz szkody pośrednie,
• podział odpowiedzialności za różne obszary – np. dostawca odpowiada za software, klient za infrastrukturę i konfigurację,
• klauzule o sile wyższej oraz o obowiązku współdziałania klienta (brak współdziałania = ograniczenie odpowiedzialności dostawcy),
• obowiązek posiadania określonego ubezpieczenia OC po stronie wykonawcy lub obu stron.

Uwaga: samo ogólne zdanie typu „Strony nie ponoszą odpowiedzialności za szkody” zwykle nie zadziała – takie klauzule mogą zostać uznane za sprzeczne z ustawą. Lepiej precyzyjnie nazwać, za jaki typ szkód i do jakiego pułapu odpowiadasz.

Kiedy w relacji B2B powstaje w ogóle prawo do odszkodowania?

Aby druga strona mogła skutecznie domagać się odszkodowania, musi wykazać trzy elementy:

• szkodę – rzeczywistą stratę (damnum emergens) lub utracone korzyści (lucrum cessans),
• związek przyczynowy między Twoim działaniem/zaniechaniem a tą szkodą,
• niewykonanie lub nienależyte wykonanie umowy po Twojej stronie (przy czym w odpowiedzialności kontraktowej istnieje domniemanie Twojej winy).

Przykład: jeśli klient poniósł karę od swojego kontrahenta, bo z Twojej winy system nie działał przez kilka dni, może próbować przerzucić na Ciebie tę karę jako część szkody. Jeżeli w umowie dobrze opisałeś SLA, cap odpowiedzialności i wyłączenia, masz twarde ramy, w jakich taki spór się rozegra.

Źródła informacji

• Kodeks cywilny. Komentarz. Tom III. Zobowiązania – część ogólna. C.H. Beck (2018) – Komentarz do art. 353–471 k.c., zasady odpowiedzialności kontraktowej
• Kodeks cywilny. Komentarz. Tom I. Część ogólna. Wolters Kluwer Polska (2021) – Zakres swobody umów w B2B, modyfikacja odpowiedzialności
• Kodeks pracy. Komentarz. LexisNexis Polska (2014) – Odpowiedzialność materialna pracownika, limity odszkodowań
• Prawo zobowiązań – część ogólna. Wydawnictwo Prawnicze PWN (2010) – Relacja odpowiedzialności kontraktowej i deliktowej, art. 471 i 415 k.c.
• Odpowiedzialność kontraktowa w obrocie profesjonalnym. Oficyna a Wolters Kluwer business (2012) – Odpowiedzialność w relacjach między przedsiębiorcami, ryzyka B2B
• Umowy w obrocie gospodarczym. Difin (2019) – Modele umów B2B: usługi, dzieło, outsourcing, podwykonawstwo
• Prawo pracy i prawo cywilne w zatrudnieniu niepracowniczym. Uniwersytet Warszawski (2016) – Porównanie etatu i B2B, zakres odpowiedzialności stron