Umowa wdrożeniowa IT. 17 klauzul, które decydują o sukcesie lub porażce Twojego projektu.

Podpisałeś umowę z software house’em. System nie działa. Dostawca mówi, że to Twoja wina. I ma rację — bo tak napisaliście w umowie.

To nie jest wymyślony scenariusz. Badania Polskiego Towarzystwa Informatycznego wskazują, że zaledwie 21% projektów IT w Polsce kończy się pełnym sukcesem. 33% to porażki, a 46% to projekty z poważnymi problemami — przekroczonym budżetem, opóźnieniami lub okrojonym zakresem. Dane globalne potwierdzają ten obraz: według raportu BCG 70% inicjatyw transformacji cyfrowej nie osiąga zakładanych celów.

Przyczyna najczęściej nie leży w technologii. Leży w umowie, której nikt nie przeczytał do końca — albo która nie reguluje tego, co naprawdę się liczy, gdy projekt zaczyna się sypać.

Umowa wdrożeniowa IT jest w polskim prawie umową nienazwaną. Nie istnieje legalna definicja „wdrożenia” ani w polskim, ani w unijnym porządku prawnym. Każda taka umowa musi być konstruowana indywidualnie, na podstawie art. 353¹ Kodeksu cywilnego. Brak „domyślnego” reżimu prawnego oznacza, że to, czego nie zapiszesz w umowie, nie istnieje.

W tym artykule omawiam 17 klauzul, które decydują o tym, czy Twój projekt wdrożeniowy zakończy się sukcesem, czy wielomiesięcznym sporem. Dla każdej klauzuli wskazuję konkretne ryzyko i rekomendację — żebyś wiedział, co wynegocjować, zanim zapłacisz pierwszą fakturę.

Podstawowe pojęcia, które musisz znać

Zanim przejdziesz do klauzul, ustal wspólny język. Poniższe pojęcia pojawiają się w każdej umowie wdrożeniowej — i każde z nich ma konkretne konsekwencje prawne.

Dlaczego kwalifikacja prawna umowy zmienia wszystko

Umowa wdrożeniowa IT łączy elementy co najmniej trzech typów umów: umowy o dzieło (rezultat — działający system), umowy o świadczenie usług (staranne działanie — analizy, szkolenia, wsparcie) oraz umów z zakresu prawa autorskiego (licencje lub przeniesienie praw majątkowych).

To, jak sąd zakwalifikuje Twoją umowę, przesądza o tym, czy wykonawca odpowiada za wynik, czy tylko za to, że „starał się profesjonalnie”.

Konsekwencje dla Twojej firmy:

1. Jeśli umowa zostanie zakwalifikowana jako umowa o dzieło — wykonawca odpowiada za rezultat. Jeśli system nie działa zgodnie ze specyfikacją, masz podstawy do roszczeń z tytułu rękojmi, obniżenia wynagrodzenia lub odstąpienia od umowy.
2. Jeśli umowa zostanie zakwalifikowana jako umowa o świadczenie usług — wykonawca odpowiada za staranne działanie. Musisz udowodnić, że działał nieprofesjonalnie, a nie tylko że wynik Cię nie satysfakcjonuje.
3. Jeśli sąd uzna, że dostarczony system to „aliud” (świadczenie innego rodzaju niż zamówione) — możesz powołać się na niewykonanie umowy i żądać zwrotu świadczeń oraz odszkodowania na zasadach ogólnych (art. 471 i 494 k.c.).

Wyrok Sądu Apelacyjnego we Wrocławiu (sygn. I ACa 796/13) potwierdza tę logikę: wykonawca nie przeprowadził walidacji modułów, nie dostarczył systemu w umówionej wersji jako spójnego kompletu i nie dostarczył kompletnej dokumentacji. Sąd uznał to za niewykonanie umowy — nie za nienależyte wykonanie. Brak testów i dokumentacji oznaczał brak „dzieła” w rozumieniu umowy.

Rekomendacja: W umowie wyraźnie określ, które elementy wdrożenia mają charakter rezultatu (i podlegają reżimowi umowy o dzieło), a które — starannego działania. Nie zostawiaj tej kwalifikacji sądowi.

Skontaktuj się

7 klauzul, bez których nie podpisuj umowy wdrożeniowej

Poniższe klauzule stanowią fundament każdej umowy wdrożeniowej. Ich brak lub niedostateczna precyzja to najczęstsze źródło sporów — zarówno w orzecznictwie, jak i w codziennej praktyce projektowej.

Klauzula 1: opis przedmiotu zamówienia (OPZ)

OPZ to jedyny punkt odniesienia, gdy pojawi się spór o zakres wdrożenia. Jeśli jest ogólnikowy lub nieprecyzyjny, wykonawca będzie twierdził, że dana funkcjonalność „nie była objęta umową”, a Ty nie będziesz miał argumentów.

Ryzyko: Nieprecyzyjny OPZ prowadzi do sporów o zakres, dodatkowych kosztów i wielomiesięcznych opóźnień.

Co powinien zawierać OPZ:

1. Cele biznesowe wdrożenia — po co kupujesz system
2. Wymagania funkcjonalne — co system ma robić (lista funkcjonalności)
3. Wymagania niefunkcjonalne — wydajność, bezpieczeństwo, dostępność, skalowalność
4. Lista integracji z innymi systemami
5. Kryteria akceptacji — jak zmierzysz, że system działa zgodnie z umową
6. Wyłączenia — co NIE jest przedmiotem umowy

Rekomendacja: OPZ powinien być osobnym załącznikiem do umowy, przygotowanym przed rozpoczęciem negocjacji z dostawcą. Nie wpisuj wymagań do treści umowy — to utrudnia zarządzanie zmianami.

Klauzula 2: harmonogram i etapowość

Harmonogram nie jest „orientacyjnym planem”. To zobowiązanie kontraktowe, z którego wynikają terminy odbiorów, płatności i kary umowne.

Klauzula 3: procedura odbiorów

To jedna z klauzul najczęściej kwestionowanych w sporach sądowych. Brak procedury odbiorów lub jej ogólnikowość prowadzi do patów odbiorowych — zamawiający odmawia odbioru, wykonawca twierdzi, że system działa.

Scenariusz: Startup SaaS wdrażał system CRM. Umowa nie zawierała kategoryzacji błędów ani procedury odbioru warunkowego. Zamawiający odmówił odbioru, powołując się na drobne usterki wizualne. Wykonawca twierdził, że system działa zgodnie z OPZ. Spór trwał 4 miesiące, opóźniając launch produktu.

Co musi zawierać procedura odbiorów:

1. Kategoryzację błędów — podział na błędy krytyczne (uniemożliwiające korzystanie), poważne (ograniczające funkcjonalność) i drobne (kosmetyczne)
2. Terminy na testowanie i zgłoszenie uwag — realistyczne, nie 3 dni na przetestowanie systemu ERP
3. Odbiór warunkowy — możliwość przyjęcia systemu mimo drobnych usterek, z zobowiązaniem do ich usunięcia w ustalonym terminie
4. Wzór protokołu odbioru — jako załącznik do umowy
5. Konsekwencje braku odpowiedzi — jeśli zamawiający nie zgłosi uwag w terminie, odbiór uważa się za dokonany (tzw. milczący odbiór)

Uchwała SN z 7 listopada 2014 r. (sygn. III CZP 8/15) potwierdza, że zamawiający nie ma obowiązku odebrania dzieła z wadami istotnymi uniemożliwiającymi korzystanie z niego zgodnie z przeznaczeniem. Ale musi mieć umowną podstawę do odmowy — stąd znaczenie kategoryzacji błędów.

Klauzula 4: prawa własności intelektualnej

Decyzja „przeniesienie praw czy licencja” to nie kwestia prawnicza — to decyzja biznesowa, która przesądza o tym, czy za rok będziesz mógł zmienić dostawcę, samodzielnie rozwijać system lub sprzedać firmę z pełnymi prawami do technologii.

Scenariusz: Firma e-commerce zamówiła dedykowany system zarządzania zamówieniami. Umowa przewidywała jedynie licencję, bez przeniesienia praw majątkowych i dostępu do kodu źródłowego. Po roku współpracy relacja z dostawcą się pogorszyła. Firma nie mogła zmienić dostawcy ani samodzielnie rozwijać systemu — musiała negocjować nową umowę z pozycji całkowitej zależności.

Rekomendacja: Dla oprogramowania dedykowanego negocjuj przeniesienie autorskich praw majątkowych wraz z dostępem do kodu źródłowego i prawem do modyfikacji. Upewnij się, że wynagrodzenie wyraźnie obejmuje te prawa. Pamiętaj: przeniesienie praw wymaga formy pisemnej pod rygorem nieważności (art. 53 ustawy o prawie autorskim).

Przy oprogramowaniu standardowym licencja jest naturalnym modelem — ale upewnij się, że obejmuje prawo do modyfikacji konfiguracji, tworzenia integracji i korzystania z API.

Klauzula 5: obowiązek współdziałania zamawiającego

To klauzula, o której zamawiający najczęściej zapominają — a która potrafi odwrócić całą odpowiedzialność za porażkę projektu.

Art. 354 § 2 Kodeksu cywilnego nakłada na wierzyciela (zamawiającego) obowiązek współdziałania w wykonaniu zobowiązania. W umowie wdrożeniowej obie strony mogą pełnić rolę dłużnika i wierzyciela jednocześnie — w zależności od konkretnego zobowiązania.

Scenariusz: Firma technologiczna podpisała umowę wdrożeniową ERP, ale osoby decyzyjne po stronie zamawiającego nie uczestniczyły w spotkaniach i nie dostarczały wymaganych danych. Wykonawca po 3 miesiącach przestojów odstąpił od umowy i zażądał pełnego wynagrodzenia — sąd przyznał mu rację.

Co musisz uregulować:

1. Zamkniętą listę obowiązków zamawiającego — udostępnienie infrastruktury, dostarczenie danych, dostępność osób decyzyjnych, odpowiedzi na pytania wykonawcy
2. Konkretne terminy realizacji tych obowiązków
3. Konsekwencje niewykonania — przesunięcie harmonogramu, dodatkowe wynagrodzenie dla wykonawcy, prawo do zawieszenia prac
4. Procedurę eskalacji — co robi wykonawca, gdy zamawiający nie współdziała

Klauzula 6: zarządzanie zmianą (change request)

Każdy projekt IT zmienia się w trakcie realizacji. Nowe wymagania, zmiany priorytetów, odkryte zależności techniczne — to norma. Problem pojawia się, gdy zmiany nie mają formalnej procedury.

Scenariusz: W trakcie wdrożenia platformy e-commerce zamawiający ustnie zlecał dodatkowe funkcjonalności. Brak procedury change request oznaczał, że wykonawca realizował dodatkowe prace bez gwarancji dodatkowego wynagrodzenia. Finalnie spór o nadprogramowe 200 godzin pracy trafił do sądu.

Procedura change request powinna obejmować:

1. Formalne zgłoszenie zmiany — na piśmie, z opisem zakresu
2. Analizę wpływu — wykonawca wycenia wpływ na harmonogram i budżet
3. Pisemną akceptację — obie strony potwierdzają zmianę zakresu, terminu i wynagrodzenia
4. Rejestr zmian — dokumentacja wszystkich zatwierdzonych i odrzuconych zmian

Klauzula 7: kary umowne

Kary umowne (art. 483–484 k.c.) to zryczałtowane odszkodowanie za niewykonanie lub nienależyte wykonanie zobowiązania niepieniężnego. Należą się niezależnie od wykazania szkody — ale sąd może je obniżyć (miarkować), jeśli uzna je za rażąco wygórowane.

Benchmarki rynkowe na podstawie wzorcowych klauzul Ministerstwa Cyfryzacji i orzecznictwa:

Wyrok SN z 20 grudnia 2018 r. (sygn. II CSK 745/17) potwierdza, że stawki powyżej 0,5% dziennie wymagają szczególnego uzasadnienia. Kara 1% dziennie została uznana za rażąco wygórowaną i obniżona do ok. 0,166% dziennie.

Rekomendacja: Skalibruj kary do realnego ryzyka biznesowego. Nadmiernie restrykcyjne kary odstraszają dobrych dostawców i podnoszą ceny ofert. Zbyt niskie — nie chronią. Pamiętaj, że kary umowne co do zasady kumulują się — jeśli umowa tego nie ogranicza, wykonawca może być obciążony karami z kilku tytułów naraz.

5 klauzul zabezpieczających ciągłość projektu

Poniższe klauzule chronią Twoją firmę przed ryzykami, które ujawniają się dopiero w trakcie realizacji lub po zakończeniu wdrożenia.

Klauzula 8: poufność (NDA)

Klauzula poufności powinna być symetryczna — obie strony jednocześnie zobowiązane i uprawnione. Musi obejmować nie tylko strony umowy, ale również pracowników i podwykonawców wykonawcy.

Co powinna zawierać:

1. Precyzyjną definicję informacji poufnych
2. Zakres podmiotowy — kto jest zobowiązany (pracownicy, podwykonawcy, konsultanci)
3. Okres obowiązywania — zazwyczaj 2–5 lat po zakończeniu umowy
4. Adekwatne kary umowne — proporcjonalne do wynagrodzenia
5. Wyłączenia — informacje publicznie dostępne, uzyskane niezależnie, ujawnione na podstawie przepisów prawa

Udział osób technicznych w weryfikacji klauzul NDA jest niezbędny — żeby uniknąć sytuacji, w której klauzule pozostają martwym postanowieniem oderwanym od rzeczywistych możliwości organizacyjnych.

Klauzula 9: umowa powierzenia przetwarzania danych (RODO)

Jeśli wykonawca przetwarza dane osobowe Twoich klientów, pracowników lub kontrahentów w ramach wdrożenia — umowa powierzenia przetwarzania danych (art. 28 RODO) jest obowiązkowa. Jej brak naraża zamawiającego na kary administracyjne do 4% rocznego obrotu lub 20 mln EUR.

Umowa powierzenia musi określać:

1. Kategorie osób, których dane dotyczą
2. Rodzaje przetwarzanych danych
3. Cel i zakres przetwarzania
4. Środki bezpieczeństwa techniczne i organizacyjne
5. Zasady podpowierzenia — czy wykonawca może angażować podwykonawców do przetwarzania danych
6. Obowiązki po zakończeniu umowy — usunięcie lub zwrot danych

Klauzula 10: personel wykonawcy

Zmiana lead developera w połowie projektu potrafi cofnąć wdrożenie o tygodnie. Nowa osoba musi poznać kontekst biznesowy, architekturę, decyzje projektowe — a to kosztuje czas i pieniądze.

Scenariusz: Lead developer odpowiedzialny za wdrożenie systemu fintech został przeniesiony przez wykonawcę do innego projektu po 2 miesiącach. Nowy programista potrzebował 6 tygodni na wdrożenie się. Umowa nie regulowała konsekwencji takiej zmiany — zamawiający nie miał żadnych narzędzi prawnych.

Co uregulować:

1. Listę personelu kluczowego — z imienia i nazwiska, z wymaganymi kwalifikacjami
2. Zakaz zmian bez zgody zamawiającego — z wyjątkiem przyczyn losowych (choroba, odejście z firmy)
3. Obowiązek zapewnienia zastępstwa o porównywalnych kwalifikacjach
4. Kary umowne za nieautoryzowane zmiany

Klauzula 11: podwykonawcy

Wykonawca ponosi odpowiedzialność za działania i zaniechania podwykonawców jak za własne. Ale żebyś mógł kontrolować, kto pracuje nad Twoim projektem, potrzebujesz odpowiednich zapisów.

Co uregulować:

1. Obowiązek informowania o podwykonawcach — lista podmiotów z zakresem prac
2. Prawo akceptacji i sprzeciwu — zamawiający musi mieć możliwość odrzucenia podwykonawcy
3. Obowiązek objęcia podwykonawców klauzulą NDA
4. Odpowiedzialność wykonawcy za podwykonawców — wyraźne potwierdzenie w umowie

Klauzula 12: gwarancja i utrzymanie (SLA)

Gwarancja obejmuje okres po odbiorze wdrożenia — wykonawca zobowiązuje się do usuwania wad i usterek. SLA definiuje mierzalne parametry jakości w fazie utrzymania.

Rekomendacja: Powiąż parametry SLA z karami umownymi — ale też z bonusami za przekroczenie gwarantowanych poziomów. To motywuje dostawcę pozytywnie, nie tylko negatywnie.

5 klauzul na wypadek kryzysu

Te klauzule uruchamiają się, gdy projekt idzie źle. Ich brak oznacza, że w momencie kryzysu nie masz narzędzi prawnych do ochrony swoich interesów.

Klauzula 13: odstąpienie od umowy

Odstąpienie to — jak ujmują to praktycy prawa IT — „opcja atomowa”. Wymaga zwrotu wzajemnych świadczeń i powinno być zarezerwowane wyłącznie dla rażących naruszeń.

Wyrok SN z 29 listopada 2006 r. (sygn. II CSK 267/06) potwierdza, że odstąpienie od umowy wdrożeniowej skutkuje rozwiązaniem całej relacji kontraktowej (pakietowy charakter umowy) — całość wynagrodzenia podlega zwrotowi.

Co uregulować:

1. Zamknięty katalog przesłanek odstąpienia — np. opóźnienie przekraczające 30 dni, rażące naruszenie SLA, naruszenie poufności
2. Procedurę poprzedzającą odstąpienie — wezwanie do usunięcia naruszenia z wyznaczeniem dodatkowego terminu
3. Skutki odstąpienia — rozliczenie wykonanych prac, zwrot dokumentacji i kodu źródłowego, kary umowne
4. Termin na wykonanie prawa odstąpienia — art. 395 k.c. wymaga określenia terminu

Klauzula 14: wypowiedzenie umowy

W odróżnieniu od odstąpienia, wypowiedzenie działa na przyszłość (ex nunc) — nie wymaga zwrotu wcześniejszych świadczeń. Jest odpowiednie dla umów o charakterze ciągłym (utrzymanie, SLA) lub gdy chcesz zakończyć współpracę bez „atomowej” eskalacji.

Rekomendacja: Rozdziel w umowie klauzule odstąpienia i wypowiedzenia. Określ odrębne przesłanki, procedury i konsekwencje dla każdej z nich. Wypowiedzenie powinno być możliwe również bez podania przyczyny — z odpowiednim okresem wypowiedzenia i obowiązkiem rozliczenia wykonanych prac.

Klauzula 15: strategia wyjścia (exit plan)

Co się dzieje z Twoimi danymi, kodem źródłowym i dokumentacją, gdy współpraca się kończy? Bez klauzuli exit plan — nic. Wykonawca nie ma obowiązku przekazywać Ci czegokolwiek ponad to, co wynika z umowy.

Exit plan powinien obejmować:

1. Transfer wiedzy — wykonawca przekazuje dokumentację techniczną, architekturę, procedury operacyjne
2. Przekazanie danych — w uzgodnionym formacie, w określonym terminie
3. Przekazanie kodu źródłowego — jeśli umowa przewiduje przeniesienie praw lub escrow
4. Okres przejściowy — wsparcie wykonawcy podczas przejścia do nowego dostawcy
5. Usunięcie danych — wykonawca potwierdza usunięcie danych zamawiającego ze swoich systemów

Klauzula 16: escrow kodu źródłowego

Escrow to mechanizm zabezpieczenia zamawiającego na wypadek, gdy wykonawca nie może lub nie chce kontynuować współpracy — np. z powodu upadłości, likwidacji lub sporu.

Kod źródłowy jest deponowany u niezależnego podmiotu (np. notariusza — koszt: ok. 50 zł za przyjęcie + 20 zł/miesiąc przechowywania) i wydawany zamawiającemu po spełnieniu określonych warunków.

Kiedy stosować escrow:

1. Gdy umowa przewiduje licencję (nie przeniesienie praw) na oprogramowanie dedykowane
2. Gdy wykonawca jest jedynym podmiotem zdolnym do utrzymania systemu
3. Gdy system jest krytyczny dla ciągłości działania Twojej firmy
4. Gdy ryzyko niewypłacalności wykonawcy jest podwyższone

Klauzula 17: limity odpowiedzialności

Limity odpowiedzialności odszkodowawczej chronią obie strony przed nieograniczonym ryzykiem finansowym. Wzorcowe klauzule Ministerstwa Cyfryzacji wskazują limit 100% łącznego wynagrodzenia kontraktowego jako standard.

Rekomendacja:

1. Ustal limit łącznej odpowiedzialności — np. 100% wynagrodzenia
2. Wyłącz z limitu odpowiedzialność za naruszenie poufności i RODO — te ryzyka nie powinny podlegać ograniczeniu
3. Wyłącz odpowiedzialność za utracone korzyści — to standard rynkowy
4. Zróżnicuj limity w zależności od kategorii naruszenia

Waterfall czy Agile — jak metodyka zmienia umowę

Wybór metodyki prowadzenia projektu nie jest kwestią techniczną — bezpośrednio wpływa na konstrukcję umowy. Nie istnieje „jeden wzór” umowy wdrożeniowej. Klauzule muszą być dostosowane do tego, jak projekt będzie realizowany.

Specyfika Agile w umowie:

W projektach prowadzonych w metodyce Agile umowa musi określać obowiązek fizycznej obecności Product Ownera na planowaniu sprintu i przeglądzie sprintu, czas jego dyspozycyjności oraz terminy udzielania odpowiedzi i akceptacji wyników sprintów. Brak dostępności Product Ownera może uzasadniać przesunięcie terminów lub dodatkowe wynagrodzenie dla wykonawcy.

Prawa autorskie w Agile powinny być uregulowane tak, aby było jasne, czy przechodzą po każdym sprincie, po akceptacji przyrostu, czy po osiągnięciu kamienia milowego.

Modele hybrydowe — ogólne ramy planowane kaskadowo (cele, architektura, budżet) z iteracyjną realizacją w sprintach — stają się coraz popularniejsze i wymagają szczególnej uwagi przy konstrukcji klauzul.

SaaS czy on-premise — różnice w zakresie IP i exit strategy

Model wdrożenia (SaaS vs. on-premise) wpływa na kwalifikację prawną umowy, zakres praw IP i sposób zakończenia współpracy.

Rekomendacja: Niezależnie od modelu, upewnij się, że umowa reguluje format eksportu danych, prawo do migracji i obowiązki dostawcy po zakończeniu współpracy. W modelu SaaS szczególnie ważne jest uregulowanie, co dzieje się z danymi po rozwiązaniu umowy — w jakim formacie zostaną zwrócone i w jakim terminie usunięte z infrastruktury dostawcy.

AI Act a umowy wdrożeniowe — nowa warstwa obowiązków

Jeśli wdrażany system zawiera komponenty AI, musisz uwzględnić obowiązki wynikające z Rozporządzenia (UE) 2024/1689 (AI Act), które wchodzi w życie etapami:

1. Od 2 lutego 2025 r. — zakazy dotyczące systemów AI o niedopuszczalnym ryzyku
2. Od 2 sierpnia 2025 r. — obowiązki dotyczące modeli AI ogólnego przeznaczenia
3. Od 2 sierpnia 2026 r. — pełne obowiązki dla systemów AI wysokiego ryzyka

Zatrudnienie jest klasyfikowane jako obszar wysokiego ryzyka — systemy AI wysokiego ryzyka wspierające rekrutację, ocenę pracowników czy zarządzanie zasobami ludzkimi podlegają szczególnym wymogom.

Kary za naruszenia AI Act:

Co dodać do umowy wdrożeniowej przy systemach z AI:

1. Klasyfikację ryzyka systemu AI zgodnie z AI Act
2. Obowiązki wykonawcy w zakresie dokumentacji technicznej i oceny zgodności
3. Odpowiedzialność za naruszenie wymogów AI Act — podział między zamawiającego i wykonawcę
4. Obowiązek informowania o zmianach regulacyjnych wpływających na system

Checklista: 12 pytań kontrolnych przed podpisaniem umowy

Przed podpisaniem umowy wdrożeniowej przeprowadź wewnętrzny „przegląd zamknięcia”. Poniższa checklista obejmuje najważniejsze obszary weryfikacji.

Jak możemy pomóc Twojej firmie

Negocjowanie umów wdrożeniowych IT wymaga połączenia kompetencji z trzech obszarów: prawnego, biznesowego i technologicznego. Sam prawnik nie wystarczy — potrzebujesz doradcy, który rozumie, jak działają projekty IT, jakie ryzyka generują i jak przekładają się na konkretne klauzule.

Wspieramy founderów, CTO i osoby odpowiedzialne za projekty IT w:

1. Przygotowaniu umów wdrożeniowych — od OPZ przez klauzule IP po procedury odbiorów i exit plan
2. Przeglądzie umów proponowanych przez dostawców — identyfikacja luk, ryzyk i niekorzystnych zapisów
3. Negocjacjach z software house’ami i dostawcami IT — wsparcie w rozmowach o zakresie, karach, SLA i prawach IP
4. Audycie istniejących umów — weryfikacja, czy Twoje obecne kontrakty chronią Twoją firmę
5. Przygotowaniu umów powierzenia przetwarzania danych — zgodność z art. 28 RODO
6. Doradztwie przy wyborze modelu IP — przeniesienie praw vs. licencja vs. escrow

Pracujemy na rzeczywistych scenariuszach projektowych — nie tworzymy dokumentów „na zapas”, ale projektujemy zasady tam, gdzie faktycznie powstaje ryzyko lub wartość.

Jeśli przygotowujesz się do podpisania umowy wdrożeniowej lub chcesz zweryfikować istniejący kontrakt — napisz do nas.

Podsumowanie: umowa wdrożeniowa to Twoje jedyne zabezpieczenie

Projekt IT może się nie udać z wielu powodów — zmiana wymagań, rotacja zespołu, niedoszacowanie złożoności. Ale Twoja umowa powinna być przygotowana na każdy z tych scenariuszy.

17 klauzul opisanych w tym artykule nie gwarantuje sukcesu wdrożenia. Ale ich brak niemal gwarantuje, że w momencie kryzysu nie będziesz miał narzędzi do ochrony swoich interesów — ani prawnych, ani negocjacyjnych.

Zacznij od checklisty. Zweryfikuj, które z 17 klauzul są w Twojej umowie, a które brakują. Jeśli potrzebujesz wsparcia w przygotowaniu, przeglądzie lub negocjacji umowy wdrożeniowej IT — napisz do nas.

Najczęściej zadawane pytania

Czy umowa wdrożeniowa IT to umowa o dzieło czy umowa o świadczenie usług?
Umowa wdrożeniowa IT jest umową nienazwaną o charakterze mieszanym — łączy elementy umowy o dzieło (rezultat: działający system), umowy o świadczenie usług (staranne działanie: analizy, szkolenia) oraz umów z zakresu prawa autorskiego (licencje lub przeniesienie praw). Kwalifikacja zależy od tego, jak skonstruujesz poszczególne zobowiązania. Przy umowie o dzieło wykonawca odpowiada za rezultat, przy umowie o świadczenie usług — za staranne działanie. Dlatego warto wyraźnie rozdzielić w umowie, które elementy mają charakter rezultatu, a które — starannego działania.

Czy mogę odstąpić od umowy, jeśli dostawca nie dotrzymuje terminów?
Tak, ale pod warunkiem, że umowa precyzyjnie określa przesłanki odstąpienia i procedurę poprzedzającą (wezwanie do usunięcia naruszenia z dodatkowym terminem). Art. 635 k.c. daje prawo odstąpienia przed terminem, jeśli wykonawca opóźnia się tak dalece, że nie jest prawdopodobne ukończenie dzieła w czasie. Pamiętaj, że odstąpienie wymaga zwrotu wzajemnych świadczeń — to poważna decyzja, zarezerwowana dla rażących naruszeń.

Jakie kary umowne są standardem rynkowym w umowach wdrożeniowych IT?
Wzorcowe klauzule Ministerstwa Cyfryzacji wskazują stawkę 0,1% wynagrodzenia za każdy dzień opóźnienia jako standard. Sąd Najwyższy (sygn. II CSK 745/17) potwierdził, że typowy poziom to 0,1–0,2% dziennie. Stawki powyżej 0,5% dziennie są obarczone ryzykiem miarkowania przez sąd. Limit łączny kar we wzorcach MC to 100% wynagrodzenia kontraktowego. Kara za odstąpienie z winy wykonawcy: 30% łącznego wynagrodzenia.

Czy muszę podpisywać osobną umowę powierzenia danych z firmą wdrożeniową?
Tak — jeśli wykonawca przetwarza dane osobowe Twoich klientów, pracowników lub kontrahentów w ramach wdrożenia. Umowa powierzenia przetwarzania danych (art. 28 RODO) jest obowiązkowa i musi określać kategorie osób, rodzaje danych, cel i zakres przetwarzania, zasady podpowierzenia oraz obowiązki po zakończeniu umowy. Jej brak naraża Twoją firmę na kary administracyjne do 4% rocznego obrotu lub 20 mln EUR.

Jak zabezpieczyć się przed vendor lock-in?
Dla oprogramowania dedykowanego negocjuj przeniesienie autorskich praw majątkowych (nie licencję) wraz z dostępem do kodu źródłowego i prawem do modyfikacji. Jeśli przeniesienie praw nie jest możliwe, rozważ escrow kodu źródłowego — deponowanie kodu u niezależnego podmiotu z określonymi warunkami wydania. Niezależnie od modelu, zadbaj o klauzulę exit plan regulującą transfer wiedzy, dokumentacji i danych po zakończeniu współpracy, oraz o otwarte formaty danych.

Kto ponosi odpowiedzialność, gdy wdrożenie opóźnia się z winy zamawiającego?
Art. 354 § 2 Kodeksu cywilnego nakłada na zamawiającego obowiązek współdziałania w wykonaniu zobowiązania. Jeśli Twój zespół nie uczestniczy w spotkaniach, nie dostarcza wymaganych danych lub nie podejmuje decyzji w ustalonych terminach — wykonawca może skutecznie bronić się przed karami, a w skrajnym przypadku odstąpić od umowy i żądać pełnego wynagrodzenia. Dlatego obowiązki współdziałania zamawiającego powinny być wyraźnie określone w umowie z konkretnymi terminami i konsekwencjami.