Każda umowa B2B w branży IT to mapa ryzyk, które w razie błędu mogą kosztować programistę więcej niż całoroczne zarobki. Jednym z najbardziej niedocenianych zapisów jest Klauzula indemnifikacyjna – postanowienie oznaczające obowiązek „zwolnienia z odpowiedzialności” zleceniodawcy wobec osób trzecich. W artykule pokażemy jak czytać klauzulę przez pryzmat odpowiedzialności cywilnej zawodowej i kiedy Polisa OC IT jest jedynym realnym zabezpieczeniem.
Podstawą zawierania umów jest zasada swobody kontraktowania wyrażona w art. 353¹ k.c. To ona sprawia, że strony mogą w zasadzie dowolnie kształtować treść umowy, o ile nie narusza ona ustawy ani zasad współżycia społecznego. W praktyce umowa z software house’em może wyglądać skrajnie różnie – od wyważonego dokumentu po kontrakt, w którym odpowiedzialność wykonawcy jest praktycznie nieograniczona.
Programista jako przedsiębiorca odpowiada całym majątkiem osobistym. Nie chroni go kodeks pracy limitujący roszczenie do trzech pensji, a zasady odpowiedzialności stron oraz odpowiedzialność stron umowy wynikają wyłącznie z tego, co zapisano w kontrakcie. Każde postanowienia umowne wymagają chłodnej analizy – umowa powinna zawierać klauzule ochronne dla obu stron. Samo zawarcie umowy bez takiej analizy to częsta przyczyna sporów; dobre postanowienia umowne chronią obie strony.
Klauzula indemnifikacyjna (indemnity, hold harmless) to zobowiązanie jednej strony do pokrycia szkód, kosztów i roszczeń, jakie druga strona umowy poniesie w związku z określonymi zdarzeniami. W polskich realiach występuje też jako klauzula odszkodowawcza lub klauzula zabezpieczenia. Cel klauzuli jest prosty: przerzucić ryzyko finansowe na wykonawcę, gdy podmiot zlecający prace IT zostanie pozwany przez osobę trzecią.
W kontraktach IT typowe obszary objęte taką klauzulą odszkodowawczą to: wyciek danych osobowych, naruszenie praw autorskich, nieprawidłowe użycie dostarczonego oprogramowania, roszczenia podwykonawców oraz roszczenia pracowników zleceniodawcy. Wyciek danych osobowych jest szczególnie niebezpieczny – wystarczy jeden podatny endpoint API, by kary RODO i pozwy klientów końcowych sięgnęły milionów złotych. Klauzula odszkodowawcza bywa wtedy jedynym mechanizmem kierującym odpowiedzialność finansową na konkretny podmiot.
Warto odróżnić tę konstrukcję od innych klauzul. Tzw. klauzula mac (material adverse change) to postanowienie umowne, które pozwala jednej ze stron wycofać się z umowy, renegocjować jej warunki lub odmówić jej wykonania, jeśli między podpisaniem umowy a jej zamknięciem (closing) lub w trakcie jej trwania nastąpi zdarzenie istotnie pogarszające sytuację drugiej strony. Jest to klauzula zabezpieczenia funkcjonująca głównie na rynku fuzji i przejęć – to typowa dla umowy inwestycyjnej klauzula, pozwalająca inwestorowi wycofać się z transakcji w razie istotnej negatywnej zmiany sytuacji spółki. Klauzula mac nie dotyczy umów B2B programisty, ale warto znać różnicę, ponieważ bywa czasami mylona z klauzulami ochronnymi o innym charakterze.
Każda dobrze skonstruowana umowa zawiera precyzyjnie opisaną klauzule zakresu prac. To ona wyznacza granice, za co wykonawca odpowiada, a za co już nie. Gdy umowa zawiera ogólniki typu „pełne wsparcie techniczne”, praktycznie każdy incydent może zostać potraktowany jako naruszenie. Treść umowy w tej części musi być konkretna – technologie, moduły, środowiska, SLA.
Równolegle musi pojawić się ograniczenie odpowiedzialności – zapis pozwalająca stronom umowy ustalić górną granicę roszczeń, np. do wysokości rocznego wynagrodzenia. Bez takiego limitu odpowiedzialność wykonawcy jest teoretycznie nieograniczona, a pojedynczy błąd w trakcie wykonanie umowy może doprowadzić do bankructwa. Odpowiedzialność wykonawcy powinna być proporcjonalna do wynagrodzenia i realnego wpływu na projekt – o ten zapis warto walczyć, nawet gdy zleceniodawca początkowo się opiera.
Prawa autorskie do kodu to drugi filar umów IT. Zasady przeniesienia praw autorskich powinny być jasno opisane – z wskazaniem pól eksploatacji, momentu przejścia praw (zazwyczaj z chwilą zapłaty wynagrodzenia) oraz wynagrodzenia za przeniesienie. Umowa bez tych elementów generuje ryzyko sporu po latach. Dodatkowo klauzule umowne dotyczące kodu open source powinny rozstrzygać, czy wykonawca może korzystać z bibliotek na licencjach typu GPL.
Klauzula poufności (NDA) jest standardem i nie budzi kontrowersji, dopóki nie zostanie obudowana rażąco wysokimi karami umownymi. Zleceniobiorca powinien sprawdzić, czy poufność obowiązuje symetrycznie i jak długo po zakończeniu współpracy.
Zakaz konkurencji na kontrakcie działa inaczej niż w kodeksie pracy. Sąd Najwyższy w wyroku (sygn. akt V CSK 30/13) potwierdził, że w umowach B2B można zawrzeć zakaz konkurencji również bez ekwiwalentu finansowego po jej zakończeniu – konstrukcja taka mieści się w granicach lojalności kontraktowej. Dla wielu programistów to zaskoczenie, gdyż często uważa się, że klauzula zakazu konkurencji po zakończeniu prac i rozwiązaniu kontraktu, bez dodatkowego wynagrodzenia jest w B2B niedopuszczalna. Jak widać warunki zakazu konkurencji mogą mieć dalekosiężne skutki. Zanim zdecydujesz się zawrzeć zakaz konkurencji w proponowanym kształcie, sprawdź proponowane warunki zakazu konkurencji punkt po punkcie.
Gdy umowa zawierająca klauzulę zakazu konkurencji trafia na biurko zweryfikuj: zakres terytorialny i katalog usług nią objęty, długość okresu przez który obowiązuje zakaz konkurencji po współpracy oraz kary umowne. Zapis typu „cała branża IT w Europie na 24 miesiące bez wynagrodzenia” to sygnał ostrzegawczy. Jeśli po rozwiązaniu kontraktu ma obowiązywać zakaz konkurencji warto wynegocjować odpowiedni ekwiwalent pieniężny z tego tytułu. Zawarta umowa bez ekwiwalentu, za to z karą 200 000 zł to sytuacja, w której zleceniodawca zyskuje wszystko, a wykonawca – tylko ryzyko.
Dobrze napisana umowa musi przewidywać jasne reguły modyfikacji. Zmiana warunków umowy powinna wymagać formy pisemnej – określać, kto i w jakim trybie może proponować zmiany umowy. Symetryczność jest kluczowa: jeśli tylko zleceniodawca jednostronnie zmienia stawki lub zakres, umowa musi zostać skorygowana przed podpisem.
Rozwiązanie umowy powinno być możliwe wyłącznie z zastosowaniem okresu wypowiedzenia. Im dłuższy, tym stabilniejsza jest sytuacja programisty. Umowa musi jasno opisywać, co dzieje się z danymi, dokumentacją i sprzętem po zakończeniu współpracy. Obowiązywanie umowy kończy się z datą jej rozwiązania, ale zobowiązania z tytułu poufności, indemnifikacji czy praw autorskich trwają dalej – to one generują największe ryzyka procesowe.
W tym momencie wraca pytanie: jak realnie zabezpieczyć się finansowo, skoro przepisy dotyczące umowy B2B pozwalają tak szeroko przerzucać ryzyko na wykonawcę? Odpowiedzią jest polisa OC IT – ubezpieczenie odpowiedzialności cywilnej zawodowej dostosowane do specyfiki świadczenie usług informatycznych. Dobrze skonstruowana polisa obejmuje czyste straty finansowe klienta, koszty obrony prawnej, a w wariantach rozszerzonych także naruszenia RODO i odpowiedzialność za podwykonawców. Jeśli zawarta umowa nakłada dodatkowo obowiązek pokrycia szkód z tytułu wycieku danych, naruszenia poufności czy praw własności intelektualnej, bez odpowiednio zaaranżowanej polisy OC IT wykonanie umowy staje się finansową ruletką.
Często w kontraktach zawieranych w branży IT stosuje się zapisy o różnego typu karach umownych. Należy pamiętać, że obowiązywanie umowy z takimi zapisami powoduje ogromne ryzyko dla programisty na B2B. Wynika to z faktu, że standardowym wyłączeniem odpowiedzialności ubezpieczycieli w polisach OC zawodowego jest brak ochrony w zakresie przekraczającym ustawowy zakres odpowiedzialności określony przepisami prawa oraz w zakresie kar umownych, chyba że odpowiedzialność taka zachodziłaby w identycznym zakresie także przy braku takich postanowień. W praktyce oznacza to, że każdy zapis w umowie kontraktowej, który rozszerza odpowiedzialność wykonawcy względem zleceniodawcy ponad to, co przewidują przepisy prawne (odpowiedzialność ponadustawowa) lub przewiduje kary umowne za zdarzenia, które w normalnym reżimie prawnym nie podlegałyby obowiązkowi odszkodowawczemu, nie będą objęte ochroną z polisy OC.
Przed podpisem sprawdź, czy umowa zawiera: precyzyjny opis zakresu, kwotowe ograniczenie odpowiedzialności, realistyczną klauzulę indemnifikacji, proporcjonalny zakaz konkurencji oraz jasne zasady wypowiedzenia. Zasady odpowiedzialności w B2B są tym, na co się zgodzisz – brak tu automatycznej ochrony ustawowej. Druga strona będzie dążyła do jak najszerszego zabezpieczenia swoich interesów – Twoim zadaniem jest wynegocjować równowagę praw i obowiązków wynikającą z umowy i zabezpieczyć swoją sytuację odpowiednio dobraną polisą OC.
Źródła:
