Usługi IT na B2B – jak zabezpieczyć umowę z klientem?

Umowa B2B w IT – co trzeba zabezpieczyć przed rozpoczęciem współpracy?

Współpraca B2B polega na wykonywaniu usług przez niezależnego przedsiębiorcę na rzecz innego podmiotu. W branży IT może obejmować programowanie, testowanie oprogramowania, administrację systemami, cyberbezpieczeństwo, analizę danych, wdrożenia lub utrzymanie infrastruktury.

Nie istnieje jeden ustawowy wzór umowy B2B dla programisty. Strony mogą ukształtować współpracę w granicach swobody umów przewidzianej w art. 353(1) Kodeksu cywilnego. Jej charakter prawny zależy jednak od rzeczywistych zobowiązań, a nie wyłącznie od nazwy dokumentu.

W zależności od przedmiotu współpracy zastosowanie mogą znaleźć przepisy o świadczeniu usług, do których odpowiednio stosuje się regulacje dotyczące zlecenia, przepisy o umowie o dzieło, prawo autorskie oraz inne regulacje właściwe dla konkretnej działalności.

Inne zabezpieczenia są potrzebne freelancerowi tworzącemu określoną aplikację, a inne administratorowi odpowiadającemu przez cały miesiąc za ciągłość działania systemów. W pierwszym przypadku szczególnego znaczenia nabierają rezultat i odbiór, w drugim dostępność usług, reakcja na awarie i zakres odpowiedzialności.

Przed podpisaniem kontraktu należy ustalić przede wszystkim:

• kto dokładnie jest stroną umowy i czy podpisujący ma prawo reprezentować klienta;
• czy wykonawca zobowiązuje się do starannego działania, określonego rezultatu, czy różnych świadczeń w ramach jednej umowy;
• jakie zadania mieszczą się w uzgodnionym wynagrodzeniu;
• kto udostępnia środowisko, narzędzia, licencje i dokumentację;
• kiedy powstaje prawo do wynagrodzenia i na jakiej podstawie klient może zgłosić zastrzeżenia;
• kto odpowiada za błędy, awarie, utratę danych i działania innych dostawców.

Jeżeli klientem jest spółka z o.o., należy zweryfikować aktualny sposób jej reprezentacji w KRS. W przypadku jednoosobowej działalności kontrahenta trzeba sprawdzić jego dane w CEIDG. Podpis osoby nieuprawnionej może powodować spór o skuteczność umowy.

Zakres usług IT i zmiany wymagań – jak uniknąć dodatkowej pracy bez zapłaty?

Jednym z najczęstszych problemów w kontraktach technologicznych jest zbyt ogólny opis obowiązków, np. świadczenie usług programistycznych zgodnie z bieżącymi potrzebami klienta. Takie postanowienie może prowadzić do sporu o to, czy wykonawca ma obowiązek realizować także nowe funkcjonalności, pilne poprawki i zadania niewchodzące pierwotnie w projekt.

Zakres prac i kryteria wykonania

Umowa powinna wskazywać rodzaj usług, sposób przydzielania zadań i zasady ustalania ich priorytetów. Przy projekcie o określonym rezultacie pomocny będzie załącznik zawierający specyfikację funkcjonalną, wymagania techniczne, harmonogram i kryteria akceptacji.

W modelu rozliczenia godzinowego warto ustalić, kto zatwierdza zadania, jak ewidencjonowany jest czas pracy oraz czy istnieje limit godzin lub budżetu wymagający dodatkowej zgody.

Jeżeli strony stosują Agile lub Scrum, należy odróżnić elastyczne planowanie sprintów od nieograniczonego prawa klienta do rozszerzania zakresu zamówienia.

Procedura zmiany zakresu projektu

Zmiana zakresu projektu powinna następować według uzgodnionej procedury, obejmującej zgłoszenie wymagania, ocenę jego wpływu na koszt i harmonogram oraz akceptację przed rozpoczęciem dodatkowych prac.

Umowa może przewidywać, że bieżące ustalenia operacyjne następują w systemie zgłoszeń lub korespondencji elektronicznej. Trzeba jednak odróżnić takie ustalenia od zmian wymagających szczególnej formy, zwłaszcza dotyczących przeniesienia autorskich praw majątkowych.

Wynagrodzenie i płatności – jakie postanowienia chronią wykonawcę?

Kontrakt powinien określać wysokość wynagrodzenia, walutę, zasady doliczania VAT, okres rozliczeniowy, wymagane dokumenty oraz termin zapłaty. W przypadku stawki godzinowej należy wskazać, czy rozliczeniu podlegają spotkania, analiza wymagań, testy, dokumentacja i usuwanie błędów.

W modelu miesięcznego ryczałtu trzeba sprecyzować, jakie świadczenia są nim objęte oraz czy niewykorzystane godziny przechodzą na kolejny miesiąc. Nie należy zakładać, że wynagrodzenie ryczałtowe automatycznie obejmuje dowolną liczbę zadań.

Akceptacja raportu i fakturowanie

Dobrym rozwiązaniem jest określenie terminu na zgłoszenie konkretnych zastrzeżeń do raportu prac, np. pięciu dni roboczych. Strony mogą uzgodnić, że brak reakcji w tym terminie oznacza akceptację raportu rozliczeniowego.

Takie postanowienie nie powinno być bezrefleksyjnie utożsamiane z całkowitym wyłączeniem odpowiedzialności za wady oprogramowania. Akceptacja czasu pracy, odbiór rezultatu i uprawnienia dotyczące wad mogą mieć odrębne skutki.

Przy większych projektach warto ustalić zaliczkę, płatności etapowe albo miesięczne rozliczenia zamiast jednej płatności po zakończeniu całości prac.

Co zrobić, gdy klient nie płaci?

W umowie można przewidzieć procedurę wezwania do zapłaty oraz prawo wstrzymania dalszych prac po bezskutecznym upływie dodatkowego terminu, z uwzględnieniem charakteru usługi i obowiązku bezpiecznego zabezpieczenia systemów.

Samowolne odcięcie klientowi dostępu do działającego systemu, usunięcie danych lub wyłączenie infrastruktury może prowadzić do odpowiedzialności wykonawcy. Uprawnienie do zawieszenia usług powinno być wyraźnie określone i wykonywane proporcjonalnie.

W transakcjach handlowych mogą mieć zastosowanie ustawowe odsetki za opóźnienie w transakcjach handlowych i rekompensata kosztów odzyskiwania należności, jeżeli spełnione są przesłanki właściwej ustawy. Nie są to świadczenia należne automatycznie w każdej umowie określanej jako B2B.

Prawa autorskie do kodu – przeniesienie praw czy licencja?

W branży IT prawa autorskie są jednym z najważniejszych obszarów kontraktu. Zgodnie z art. 74 ustawy o prawie autorskim i prawach pokrewnych programy komputerowe podlegają szczególnej ochronie prawnoautorskiej, jeżeli spełniają przesłanki ochrony.

Sam fakt zamówienia programu, opłacenia faktury albo udostępnienia kodu w repozytorium nie oznacza automatycznego nabycia przez klienta całości autorskich praw majątkowych.

Przepis art. 74 ust. 3 przewiduje szczególną regulację dotyczącą programów komputerowych stworzonych przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy. Nie należy automatycznie przenosić tej zasady na niezależnego przedsiębiorcę świadczącego usługi B2B.

Jak skutecznie przenieść prawa do oprogramowania?

Umowa przenosząca autorskie prawa majątkowe wymaga formy pisemnej pod rygorem nieważności zgodnie z art. 53 prawa autorskiego. Równoważna może być forma elektroniczna z kwalifikowanymi podpisami elektronicznymi, jeżeli spełnia wymagania art. 78(1) Kodeksu cywilnego. Zwykła wiadomość e-mail, skan podpisanej umowy czy standardowy podpis w aplikacji nie zawsze zapewniają wymaganą formę.

Postanowienia dotyczące praw autorskich powinny określać:

• jakie rezultaty prac mają być objęte przeniesieniem praw;
• pola eksploatacji, na których prawa są przenoszone, z uwzględnieniem specyfiki programów komputerowych;
• moment przejścia praw, np. z chwilą zapłaty całości wynagrodzenia za dany rezultat;
• zakres uprawnienia klienta do modyfikowania, rozwijania i dalszego udostępniania oprogramowania;
• zasady korzystania z bibliotek zewnętrznych, komponentów open source i wcześniejszych narzędzi wykonawcy;
• czy wynagrodzenie obejmuje także przeniesienie praw oraz jakie składniki wynagrodzenia są z tym związane.

Art. 41 ust. 2 prawa autorskiego wymaga wyraźnego wymienienia pól eksploatacji objętych umową. Niedostatecznie precyzyjne sformułowanie, że klient nabywa wszystkie prawa do wszystkiego, co wykonawca kiedykolwiek stworzy, może być źródłem poważnego sporu.

Umowa dotycząca wszystkich utworów lub wszystkich utworów określonego rodzaju tego samego twórcy mających powstać w przyszłości napotyka ponadto ograniczenia wynikające z art. 41 ust. 3 tej ustawy.

Jak chronić własne biblioteki i wcześniejsze rozwiązania?

Programista może wykorzystywać w kolejnych projektach wcześniej opracowane moduły, narzędzia i elementy kodu. Bez odpowiednich zastrzeżeń klient może oczekiwać wyłącznych praw także do komponentów, które nie zostały stworzone specjalnie na jego zamówienie.

Rozwiązaniem jest rozdzielenie oprogramowania opracowanego dla klienta od istniejących wcześniej komponentów wykonawcy. W odniesieniu do tych drugich można przewidzieć odpowiednią licencję umożliwiającą korzystanie z całego produktu bez odbierania wykonawcy możliwości legalnego używania własnych narzędzi w innych projektach.

Oddzielnej analizy wymagają biblioteki open source. Warunki ich licencji mogą nakładać obowiązki związane z udostępnianiem kodu źródłowego, zachowaniem informacji o autorach lub dalszą dystrybucją. Wykonawca nie powinien obiecywać przeniesienia praw, których sam nie posiada.

Odpowiedzialność za błędy i kary umowne – jak ograniczyć ryzyko finansowe?

Na podstawie art. 471 Kodeksu cywilnego dłużnik co do zasady odpowiada za szkodę wynikłą z niewykonania lub nienależytego wykonania zobowiązania, chyba że nastąpiło to wskutek okoliczności, za które nie ponosi odpowiedzialności.

Jeżeli umowa nie ogranicza odpowiedzialności, roszczenie klienta nie musi kończyć się na wysokości wynagrodzenia za dany miesiąc. Rozmiar potencjalnej odpowiedzialności zależy od przesłanek konkretnego roszczenia, w tym szkody, związku przyczynowego i treści zobowiązania.

Limit odpowiedzialności wykonawcy

W umowach między przedsiębiorcami często negocjuje się maksymalną odpowiedzialność, np. do kwoty wynagrodzenia netto wypłaconego za ostatnie 12 miesięcy współpracy albo do określonej wielokrotności miesięcznego wynagrodzenia.

Nie jest to ustawowy limit, lecz przykładowy mechanizm umowny. Strony muszą uzgodnić, czy obejmuje wszystkie roszczenia łącznie, czy poszczególne zdarzenia, oraz czy dotyczy również kar umownych.

Art. 473 § 2 Kodeksu cywilnego wyklucza skuteczne zastrzeżenie zwalniające dłużnika z odpowiedzialności za szkodę wyrządzoną wierzycielowi umyślnie. Dlatego zapis całkowicie wyłączający wszelką odpowiedzialność bez wyjątku nie zapewnia pełnej ochrony.

Warto również jednoznacznie uregulować odpowiedzialność za utracone korzyści, awarie spowodowane działaniami klienta, błędy dostawców usług chmurowych oraz skutki nieprawidłowych danych wejściowych. Zakres takich wyłączeń musi pozostawać zgodny z prawem.

Kary umowne za opóźnienia, poufność i inne naruszenia

Zgodnie z art. 483 § 1 Kodeksu cywilnego kara umowna może zabezpieczać niewykonanie lub nienależyte wykonanie zobowiązania niepieniężnego. Nie jest właściwym instrumentem naliczania sankcji za sam brak terminowej zapłaty wynagrodzenia pieniężnego.

Przy analizie kar należy ustalić:

• jakie konkretnie naruszenie powoduje obowiązek zapłaty;
• czy istnieje maksymalna łączna wysokość kar;
• czy kara naliczana jest za każdy dzień, przypadek czy jedno zdarzenie;
• czy zastrzeżono odszkodowanie przewyższające wysokość kary;
• czy kara jest powiązana z okolicznościami, za które wykonawca ponosi odpowiedzialność;
• czy przewidziano możliwość usunięcia naruszenia przed naliczeniem sankcji.

Art. 484 § 2 Kodeksu cywilnego przewiduje możliwość żądania zmniejszenia kary umownej, gdy zobowiązanie zostało w znacznej części wykonane albo kara jest rażąco wygórowana. Nie należy jednak zakładać, że sąd automatycznie obniży wysoką karę.

Poufność, RODO i bezpieczeństwo danych w kontrakcie IT

Wykonawca IT często uzyskuje dostęp do kodu źródłowego, infrastruktury, informacji handlowych i baz danych klienta. Dlatego umowa powinna regulować zarówno poufność, jak i techniczne zasady korzystania z systemów.

Klauzula NDA powinna definiować informacje poufne i wyjątki dotyczące informacji publicznie dostępnych, znanych wcześniej wykonawcy lub ujawnianych na podstawie obowiązującego prawa. Należy też wskazać czas trwania obowiązku poufności, zasady udostępniania informacji współpracownikom i sposób postępowania po zakończeniu kontraktu.

Nie każda usługa IT automatycznie oznacza powierzenie przetwarzania danych osobowych. Jeżeli jednak wykonawca przetwarza dane osobowe w imieniu administratora, zastosowanie może mieć art. 28 RODO, wymagający odpowiedniego uregulowania powierzenia przetwarzania.

Dokumentacja powinna wtedy określać m.in. przedmiot i czas przetwarzania, charakter czynności, kategorie danych, obowiązki stron, zasady korzystania z dalszych podmiotów przetwarzających oraz procedury dotyczące bezpieczeństwa i zakończenia współpracy.

Warto ustalić także minimalne wymagania dotyczące uwierzytelniania wieloskładnikowego, szyfrowania, dostępu z urządzeń prywatnych, zgłaszania incydentów i korzystania z narzędzi sztucznej inteligencji. Udostępnienie kodu lub danych klienta zewnętrznej usłudze AI bez sprawdzenia warunków i zgody wymaganej umową może naruszać obowiązki wykonawcy.

Terminy zgłoszenia incydentu przez wykonawcę powinny umożliwiać administratorowi realizację jego obowiązków wynikających z RODO. Nie należy utożsamiać umownego terminu informowania klienta z ustawowym terminem zgłoszenia naruszenia organowi nadzorczemu.

Zakaz konkurencji i wyłączność – czego nie podpisywać bez analizy?

W kontraktach IT zdarzają się zapisy zabraniające świadczenia usług na rzecz innych podmiotów, także po zakończeniu współpracy. Dla niezależnego przedsiębiorcy może to oznaczać poważne ograniczenie możliwości uzyskiwania przychodów.

W relacji B2B nie należy automatycznie stosować zasad rekompensaty za pracowniczy zakaz konkurencji po ustaniu zatrudnienia. Ocenę postanowień kontraktu cywilnoprawnego przeprowadza się według właściwych przepisów, w szczególności zasad swobody umów, natury stosunku zobowiązaniowego oraz przepisów chroniących konkurencję, jeżeli mają zastosowanie.

Przed zaakceptowaniem zakazu warto sprawdzić jego:

• zakres podmiotowy, czyli jakich klientów i konkurentów dotyczy;
• zakres przedmiotowy, czyli jakie usługi są ograniczone;
• terytorium obowiązywania;
• czas trwania w trakcie umowy i po jej zakończeniu;
• ewentualne wynagrodzenie za ograniczenie działalności;
• kary umowne i możliwość uzyskania zgody na konkretną współpracę.

Zakaz obejmujący wszelkie usługi informatyczne dla dowolnego przedsiębiorcy przez kilka lat może być znacznie bardziej dotkliwy niż ograniczenie dotyczące bezpośrednich konkurentów klienta przez krótki okres. Nie oznacza to jednak, że każdy szeroki zakaz jest automatycznie nieważny. Ocena wymaga analizy całego kontraktu i okoliczności jego zawarcia.

Oddzielnie można uregulować zakaz pozyskiwania pracowników lub klientów kontrahenta. Taka klauzula również powinna mieć odpowiednio określony zakres, zamiast prowadzić do niejasnego i nieproporcjonalnego ograniczenia działalności wykonawcy.

Wypowiedzenie umowy B2B i rozliczenie po zakończeniu projektu

Niebezpieczny jest kontrakt, który pozwala klientowi zakończyć współpracę natychmiast, ale zobowiązuje wykonawcę do kilkumiesięcznego wypowiedzenia. Podobne ryzyko powstaje, gdy strony nie ustaliły zasad przekazania prac oraz płatności za wykonane zadania.

Umowa powinna określać okres wypowiedzenia, sposób składania oświadczeń, zasady zakończenia aktywnych zadań i rozliczenia wynagrodzenia. Przy umowach o świadczenie usług, do których stosuje się przepisy o zleceniu, trzeba uwzględnić art. 746 i art. 750 Kodeksu cywilnego, w tym ograniczenie możliwości zrzeczenia się z góry prawa wypowiedzenia z ważnych powodów.

Nie można więc zakładać, że zapis przewidujący sztywny okres wypowiedzenia całkowicie wyklucza wcześniejsze rozwiązanie każdej umowy IT.

Po zakończeniu współpracy strony powinny uzgodnić:

• termin przekazania aktualnego kodu, dokumentacji i rezultatów prac;
• sposób rozliczenia rozpoczętych, lecz niezakończonych zadań;
• przekazanie lub odebranie dostępów administracyjnych;
• zasady zwrotu sprzętu oraz usuwania lub zwracania danych;
• okres i zakres ewentualnego wsparcia przy przekazaniu projektu następcy;
• obowiązki pozostające w mocy po zakończeniu umowy, w tym poufność i niektóre ograniczenia konkurencyjne.

Wykonawca nie powinien przyjmować nieograniczonego obowiązku bezpłatnej pomocy przy przekazaniu projektu. Jeżeli klient oczekuje dodatkowego wsparcia migracyjnego lub szkolenia nowego zespołu, warto ustalić zakres tych prac i sposób wynagradzania.

CEIDG, PKD, ZUS i status przedsiębiorcy świadczącego usługi IT

Bezpieczna umowa to nie tylko właściwe zapisy cywilnoprawne. Trzeba również sprawdzić, czy forma prowadzenia działalności odpowiada rzeczywistemu modelowi współpracy.

Programista prowadzący jednoosobową działalność gospodarczą jest stroną umowy jako przedsiębiorca będący osobą fizyczną. Jeżeli usługi świadczy spółka z o.o., stroną jest spółka, a umowę podpisują osoby uprawnione do jej reprezentacji. Nie należy utożsamiać zobowiązań spółki z osobistymi zobowiązaniami jej wspólnika lub członka zarządu.

PKD i rejestracja działalności

Osoba rozpoczynająca działalność IT powinna dobrać kody PKD odpowiadające rzeczywistemu zakresowi usług. Od 1 stycznia 2025 r. obowiązuje PKD 2025, a przedsiębiorcy korzystający jeszcze z wcześniejszej klasyfikacji powinni uwzględnić okres przejściowy kończący się 31 grudnia 2026 r.

Rodzaj działalności może wpływać na obowiązki rejestrowe, podatkowe i organizacyjne, ale sam wpis odpowiedniego PKD nie rozstrzyga treści zobowiązań wobec klienta.

W innych branżach, zwłaszcza przy działalności prowadzonej w określonym lokalu, powstają dodatkowe zagadnienia administracyjne. Ilustruje je problem warsztat samochodowy a usługi nieuciążliwe. Przy typowych usługach programistycznych zagadnienia lokalizacyjne mają zwykle mniejsze znaczenie, choć charakter działalności i sposób korzystania z nieruchomości nadal mogą być istotne.

ZUS, działalność nierejestrowana i przejście z etatu

Przedsiębiorca powinien ustalić właściwy tytuł do ubezpieczeń, wysokość składek i ewentualne warunki korzystania z ulg. Nie każda osoba rozpoczynająca działalność może korzystać z ulgi na start lub preferencyjnych składek, szczególnie gdy współpraca dotyczy czynności wykonywanych wcześniej dla pracodawcy.

W przypadku niewielkich, okazjonalnych usług można rozważyć działalność nierejestrowaną, jeżeli są spełnione ustawowe przesłanki. Sama dopuszczalność działalności nierejestrowanej nie oznacza jednak automatycznego zwolnienia z obowiązków wynikających z konkretnej umowy cywilnoprawnej, podatków lub ubezpieczeń. Porównywalne zagadnienia opisuje artykuł o usługach BHP w działalności nierejestrowanej.

Jeżeli specjalista rezygnuje z zatrudnienia pracowniczego i podpisuje umowę B2B z dotychczasowym pracodawcą, należy dodatkowo zbadać rzeczywisty sposób wykonywania obowiązków. Art. 22 Kodeksu pracy przewiduje, że zatrudnienie w warunkach stosunku pracy jest zatrudnieniem pracowniczym niezależnie od nazwy zawartej umowy.

Sam jeden klient, stałe miesięczne wynagrodzenie albo udział w spotkaniach zespołu nie przesądzają jeszcze o istnieniu stosunku pracy. Znaczenie ma całokształt okoliczności, zwłaszcza podporządkowanie kierownictwu, wyznaczanie miejsca i czasu pracy oraz rzeczywista samodzielność przedsiębiorcy.

Szczegółowe konsekwencje tego modelu przedstawia poradnik przejście z etatu na B2B a ZUS, podatki i ryzyka.

Jak sprawdzić kontrakt IT przed podpisaniem?

Najlepiej analizować umowę razem z załącznikami, regulaminami, politykami bezpieczeństwa i dokumentami dotyczącymi praw autorskich. Szczególnie niebezpieczne bywają postanowienia odsyłające do zasad, które klient może jednostronnie zmieniać.

W przypadku kontraktu z zagraniczną spółką szczególnej uwagi wymagają prawo właściwe, waluta rozliczeń, podatki, jurysdykcja oraz sposób egzekwowania roszczeń. Nie należy zakładać, że polskie przepisy o karach umownych, odpowiedzialności czy wypowiedzeniu będą zawsze stosowane do takiej współpracy.

Najczęstsze pytania dotyczące umów B2B w branży IT

Czy umowa B2B dla programisty musi być podpisana na papierze?

Nie każda umowa o świadczenie usług IT wymaga formy pisemnej. Jednak skuteczne przeniesienie autorskich praw majątkowych wymaga zachowania formy pisemnej pod rygorem nieważności. Możliwe jest też zastosowanie kwalifikowanych podpisów elektronicznych spełniających wymagania formy elektronicznej. Zwykłe zatwierdzenie umowy przez e-mail nie zapewnia automatycznie tego samego skutku.

Czy programista może pracować jednocześnie dla kilku klientów?

Co do zasady niezależny przedsiębiorca może współpracować z wieloma kontrahentami. Ograniczenia mogą jednak wynikać z ważnych postanowień umownych dotyczących wyłączności, zakazu konkurencji, konfliktu interesów i poufności. Należy sprawdzić ich konkretny zakres.

Czy klient może nie zapłacić za cały miesiąc z powodu jednego błędu?

Nie ma jednej odpowiedzi. Znaczenie mają model rozliczeń, charakter błędu, postanowienia dotyczące odbioru, ewentualne uprawnienia klienta z tytułu wad oraz możliwość potrącenia roszczeń. Wstrzymanie całego wynagrodzenia nie zawsze będzie uzasadnione samym stwierdzeniem usterki.

Czy kontrakt B2B może przewidywać pracę zdalną i określone godziny dostępności?

Tak, strony mogą uzgodnić godziny kontaktu, dyżury lub wymagany czas reakcji na zgłoszenia. Należy jednak odróżniać uzasadnioną koordynację usług od podporządkowania właściwego stosunkowi pracy. W przypadku stałych dyżurów warto określić dodatkowe wynagrodzenie oraz maksymalny zakres obowiązków.

Czy można wykorzystać fragmenty kodu stworzonego dla klienta w innym projekcie?

Zależy to od tego, komu przysługują prawa autorskie, jak określono zakres przeniesienia praw lub licencji oraz czy kod zawiera informacje poufne. Jeżeli majątkowe prawa autorskie do konkretnego komponentu zostały skutecznie przeniesione na klienta, wykonawca nie może zakładać swobody jego ponownego wykorzystania. Inaczej może być w przypadku własnych, wcześniej opracowanych bibliotek, do których wykonawca zachował prawa.

Czy ubezpieczenie OC działalności IT zastępuje ograniczenie odpowiedzialności w umowie?

Nie. Polisa OC może zapewniać ochronę w granicach sumy gwarancyjnej i warunków ubezpieczenia, ale często zawiera wyłączenia dotyczące określonych ryzyk, kar umownych czy odpowiedzialności przyjętej ponad standard wynikający z przepisów. Limit odpowiedzialności w kontrakcie oraz zakres polisy należy analizować łącznie.