Umowa B2B w IT: checklista klauzul i czerwonych flag

Umowa B2B w IT: checklista klauzul i czerwonych flag

Umowa B2B IT potrafi wyglądać jak formalność — dopóki nie pojawi się spór o odbiór prac, wstrzymana płatność albo „pilny” dyżur on-call, którego nikt nie doprecyzował. W 2025–2026 rynek IT w Polsce odbił, ale firmy rekrutują ostrożniej i mocniej rozliczają efekty oraz ryzyko (No Fluff Jobs, ITwiz, Antyweb). To przekłada się na kontrakty: więcej klauzul o SLA, karach, odpowiedzialności i IP, a mniej „dogadamy się w praktyce”.

Poniżej dostajesz praktyczny audyt: co sprawdzić, jakie są czerwone flagi i jak zaproponować kontrzapis bez prawniczego żargonu.

Co sprawdzić w kontrakcie B2B w IT przed podpisaniem? (szybka lista)

1. Czy jasno zdefiniowano model rozliczeń: time & material vs fixed price (i konsekwencje dla odbiorów)?
2. Czy zakres usług (deliverables) ma kryteria akceptacji i „definition of done”?
3. Czy są terminy odbioru i co się dzieje, gdy klient milczy?
4. Czy płatność zależy od „akceptacji” bez limitu czasu lub bez kryteriów?
5. Czy terminy płatności są realistyczne (np. 14/30 dni) i czy są odsetki za opóźnienie?
6. Czy klient może wstrzymać płatność w całości z błahego powodu?
7. Czy jest limit odpowiedzialności (cap) i czy obejmuje kary umowne?
8. Czy kary umowne są proporcjonalne (np. % miesięcznego fee) i czy można je kumulować bez limitu?
9. Czy IP jest uregulowane: przeniesienie praw autorskich B2B czy licencja — i kiedy następuje przejście praw?
10. Czy NDA sensownie definiuje poufność, wyjątki i czas trwania?
11. Czy są zapisy o RODO (role, powierzenie) adekwatne do tego, co faktycznie robisz?
12. Jak wygląda wypowiedzenie umowy B2B: okres, rozliczenie prac w toku, rozwiązanie natychmiastowe?
13. Czy są przerwy/przestoje po stronie klienta i co z wynagrodzeniem?
14. Czy zakaz konkurencji B2B ma ograniczony zakres (czas/terytorium/branża) i czy jest rekompensata?
15. Czy umowa reguluje podwykonawców, narzędzia, licencje i sprzęt?

Po co Ci audyt umowy B2B (i kiedy iść do prawnika)

W praktyce audyt kontraktu B2B to zarządzanie ryzykiem: finansowym (płatności i kary), operacyjnym (SLA, dyżury, dostępność), prawnym (IP, poufność, dane) i reputacyjnym (spór z klientem). To, że „rynek odbił”, nie znaczy, że klienci są bardziej skłonni do elastyczności — raczej częściej oczekują mierzalnych rezultatów i zabezpieczeń. W komentarzach do danych rynkowych podkreśla się, że rośnie selektywność i preferencja dla ról doświadczonych (Antyweb), co w kontraktach często oznacza: „skoro jesteś seniorem, to weźmiesz na siebie więcej odpowiedzialności”. Nie zawsze powinieneś.

Kiedy audyt ma sens, a kiedy idź do prawnika

Audyt „samodzielny” ma sens, gdy:

• pracujesz w modelu T&M, bez dyżurów, bez dostępu do danych wrażliwych,
• umowa jest krótka, a klauzule standardowe i proporcjonalne,
• wiesz, co jest dla Ciebie nieprzekraczalne (cap, terminy płatności, zakaz konkurencji).

Do prawnika idź, gdy pojawia się choć jeden z sygnałów:

• nieograniczona odpowiedzialność lub odpowiedzialność „za wszystko, co się wydarzy w projekcie”,
• kary umowne bez limitu, z możliwością kumulacji i potrącania „z automatu”,
• przeniesienie IP „na wszystkich polach eksploatacji, na zawsze” bez warunków i bez powiązania z zapłatą,
• szeroki zakaz konkurencji (np. „branża IT” albo „wszyscy klienci grupy kapitałowej”),
• wchodzisz w obszary regulowane (dane osobowe, bezpieczeństwo, AI governance). W 2026 coraz częściej firmy podkręcają compliance i kontrolę ryzyka wokół AI i danych (Computerworld, Cisco News, Newseria Biznes) — a to często „ląduje” w kontraktach jako dodatkowe obowiązki i odpowiedzialność.

Ustal, jaki „typ” kontraktu podpisujesz: T&M vs fixed price

To nie jest detal. Model rozliczeń determinuje, jak powinny wyglądać odbiory, SLA i odpowiedzialność:

• Time & Material (T&M): płacą za czas i kompetencje, a nie za „dowieziony produkt”. Odbiór powinien dotyczyć raczej timesheetu i dostępności, a nie subiektywnej oceny „czy feature jest idealny”.
• Fixed price / outcome-based: płacą za rezultat. Wtedy kryteria akceptacji muszą być bardzo precyzyjne, bo inaczej scope creep (ciągłe dokładanie) zje Twój margin.

Przy okazji: presja na efektywność kosztową w IT rośnie, bo budżety przesuwają się m.in. w stronę AI i bezpieczeństwa (CRN.pl, Computerworld). Dla Ciebie to sygnał, że w umowach częściej zobaczysz mechanizmy „kontroli kosztu”: wstrzymania płatności, KPI, SLA, kary. Tym bardziej warto mieć porządek w klauzulach.

Zakres współpracy: deliverables, odbiory i „definition of done”

Najwięcej konfliktów w B2B w IT nie bierze się z „złej woli”, tylko z nieprecyzyjnych definicji. Umowa mówi „świadczenie usług programistycznych”, a potem okazuje się, że klient oczekuje: dyżurów, dokumentacji, wsparcia produkcji, udziału w incident management, a nawet szkolenia juniorów — „bo to przecież standard w zespole”.

Po co to jest

Dobrze opisany zakres:

• chroni Cię przed scope creep,
• ułatwia odbiór i fakturowanie,
• pozwala sensownie ustawić SLA, dyżury i odpowiedzialność.

Czerwona flaga

• „Wykonawca zobowiązuje się do realizacji wszelkich zadań zleconych przez Zamawiającego” bez ograniczeń.
• Brak definicji „Odbioru” albo „Wady”, a płatność zależy od „braku zastrzeżeń”.
• „Gotowość do pracy w razie potrzeby” bez widełek godzin i bez stawki za dyżur.

Propozycja kontrzapisu (prosto)

• „Zakres Usług obejmuje zadania opisane w backlogu/załączniku. Zmiany zakresu wymagają potwierdzenia w formie mailowej oraz ustalenia wpływu na czas i wynagrodzenie.”
• „Odbiór następuje na podstawie kryteriów akceptacji wskazanych w ticketach/załączniku; brak odpowiedzi w terminie X dni roboczych oznacza odbiór.”

Definition of done: ustal minimalny standard

W IT najprościej „podpiąć” DoD pod realne artefakty:

• kod zreviewowany,
• testy (unit/integration) przechodzą w CI,
• wdrożone na środowisko X,
• zaktualizowana dokumentacja (jeśli wymagana),
• brak błędów krytycznych.

Jeśli klient chce więcej (np. SLO, monitoring, runbooki), to jest OK — ale powinno być to nazwane i wycenione. W 2026 rośnie nacisk na niezawodność i bezpieczeństwo, szczególnie przy systemach opartych o dane i AI; branżowe omówienia trendów wskazują, że organizacje nie nadążają z zabezpieczeniami w tempie wdrożeń (ITReseller, Control Engineering Polska). To często skutkuje „dorzucaniem” wymagań typu: audyt logów, kontrola dostępu, procedury incydentowe. To też powinno trafić do DoD albo do SLA.

SLA w umowie B2B: czasy reakcji, dostępność, dyżury on-call

SLA w umowie B2B ma sens, jeśli faktycznie odpowiadasz za utrzymanie lub wsparcie produkcji. Wtedy doprecyzuj:

• godziny obowiązywania (np. 9–17 w dni robocze),
• definicję incydentu i priorytetów (P1/P2/P3),
• „czas reakcji” vs „czas rozwiązania”,
• czy jest on-call i jak płatny (ryczałt + stawka za interwencję).

Czerwona flaga: SLA „24/7” bez on-call i bez dodatkowego wynagrodzenia albo bez zasobów po stronie klienta (np. brak dostępu, brak runbooków).

Kontrzapis: „SLA obowiązuje wyłącznie w godzinach X. Dyżur on-call wymaga osobnego uzgodnienia i wynagrodzenia zgodnie z załącznikiem.”

Zmiana zakresu (change request): jak uniknąć „scope creep”

Najprostszy mechanizm:

• klient zgłasza zmianę,
• Ty oceniasz wpływ na czas i koszt,
• dopiero po akceptacji zmiana wchodzi do realizacji.

Jeśli klient nie chce formalnych CR-ów, zaproponuj „light version”: mail/Slack + potwierdzenie w Jirze. Ważne, żeby istniał ślad.

Płatności i rozliczenia: faktury, akceptacje, wstrzymanie płatności

Płatności to w B2B Twoje „paliwo”. A w realiach 2025–2026, gdy część firm nadal tnie koszty lub restrukturyzuje zespoły (CRN.pl), warto szczególnie uważać na mechanizmy, które pozwalają opóźniać przelew „zgodnie z umową”.

Po co to jest

Dobre klauzule płatności:

• minimalizują ryzyko zatorów,
• ograniczają uznaniowość odbioru,
• pozwalają Ci planować cashflow (ZUS, VAT, księgowość).

Czerwona flaga

• „Termin płatności liczony od dnia akceptacji faktury”, ale akceptacja nie ma terminu.
• „Zamawiający może wstrzymać płatność do czasu usunięcia wszelkich wad” — bez definicji wady i bez proporcjonalności.
• Potrącenia kar umownych „bezspornie i jednostronnie” z Twoich faktur.

Propozycja kontrzapisu

• „Termin płatności wynosi 14/30 dni od daty doręczenia prawidłowo wystawionej faktury.”
• „Wstrzymanie płatności może dotyczyć wyłącznie części wynagrodzenia odpowiadającej zakwestionowanemu zakresowi, po przedstawieniu uzasadnienia.”

Terminy płatności i odsetki: co wpisać, żeby działało w praktyce

W praktyce najlepiej działają:

• konkretne terminy (np. 14 lub 30 dni),
• zapis o odsetkach ustawowych za opóźnienie,
• możliwość wstrzymania świadczenia usług po przekroczeniu określonego opóźnienia (np. 14 dni), po uprzednim wezwaniu.

To jest szczególnie ważne, jeśli pracujesz dla większych organizacji (np. centra usług), gdzie obieg dokumentów bywa długi. Jednocześnie te organizacje potrafią płacić bardzo konkurencyjnie i intensywnie kupują kompetencje IT (CRN.pl) — więc warto negocjować warunki, bo budżet często „jest”, tylko procesy są sztywne.

Warunki akceptacji prac: kiedy klient może odmówić odbioru

Jeśli odbiór jest warunkiem faktury, musi być:

• mierzalny (kryteria),
• terminowy (deadline na feedback),
• proporcjonalny (brak blokady płatności za całość, gdy spór dotyczy fragmentu).

Dobre praktyki:

• „milczący odbiór” po X dniach,
• rozróżnienie „wady istotnej” i „drobnej usterki” (drobna usterka nie blokuje odbioru),
• protokół odbioru lub akceptacja w narzędziu (Jira, GitHub).

Time & material: timesheet, minimalny wymiar i anulowanie

Jeśli rozliczasz się T&M, doprecyzuj:

• czy jest minimalna liczba godzin miesięcznie (retainer),
• jak raportujesz czas (timesheet tygodniowy/miesięczny),
• co w przypadku odwołania sprintu/zmiany priorytetów po stronie klienta.

Czerwona flaga: „płacimy tylko za zaakceptowane zadania”, mimo że to T&M.

Kontrzapis: „Wynagrodzenie przysługuje za czas świadczenia usług i pozostawanie w dyspozycji w uzgodnionym wymiarze.”

Odpowiedzialność kontraktora B2B i kary umowne

Tu najłatwiej „przepalić” cały sens B2B: świetna stawka dzienna nie ma znaczenia, jeśli jedna klauzula przerzuca na Ciebie ryzyko większe niż Twoje roczne przychody.

W 2026 bezpieczeństwo i ryzyko technologiczne są szczególnie na radarze firm — m.in. przez szybkie wdrożenia AI i agentów oraz rosnące obawy o nowe wektory ataku (Cisco News, ITReseller, Control Engineering Polska). To często skutkuje „twardszymi” zapisami o odpowiedzialności — nie zawsze adekwatnymi do roli kontraktora.

Po co to jest

Klauzule odpowiedzialności mają:

• określić, za co realnie odpowiadasz (i za co nie),
• ograniczyć nieprzewidywalne ryzyko,
• ustawić zasady kar i odszkodowań.

Czerwona flaga

• odpowiedzialność „za utracone korzyści” klienta i szkody pośrednie,
• odpowiedzialność za działania osób trzecich (np. infrastruktura klienta, inni dostawcy),
• brak limitu (cap) i jednocześnie kary umowne + odszkodowanie uzupełniające.

Limit odpowiedzialności (cap): jak go ustalić i do czego go odnieść

Najczęstsze, „rynkowe” podejścia w IT:

• cap = 1–3x miesięczne wynagrodzenie,
• cap = wartość wynagrodzenia z ostatnich 3–6 miesięcy,
• cap = łączna wartość umowy, jeśli umowa ma sensowną, krótką perspektywę.

Ustal też, czy cap obejmuje kary umowne (powinien). Jeśli nie obejmuje, klient może „obejść” limit przez naliczenie kar.

Prosty kontrzapis: „Łączna odpowiedzialność Wykonawcy, w tym z tytułu kar umownych, jest ograniczona do kwoty …”.

Kary umowne B2B: za co, ile i czy można je kumulować

Kary umowne w B2B mają sens, gdy:

• dotyczą konkretnych, mierzalnych naruszeń (np. opóźnienie w dostarczeniu konkretnego deliverable),
• są proporcjonalne (np. 0,1–0,5% wynagrodzenia za dany etap za dzień opóźnienia),
• mają limit łączny (np. 10–20% wynagrodzenia za etap lub miesiąc).

Czerwone flagi:

• kary „za nienależyte wykonanie” bez definicji,
• kary za SLA w sytuacji, gdy nie masz wpływu na środowisko/monitoring,
• możliwość naliczania kilku kar za to samo zdarzenie (kumulacja) bez limitu.

Kontrzapis: „Kary nie podlegają kumulacji za to samo naruszenie, a ich łączna wysokość w danym miesiącu nie przekroczy …”.

OC kontraktora: kiedy warto i jak powiązać polisę z umową

Ubezpieczenie OC zawodowe bywa wymagane przez klientów enterprise. Warto je rozważyć, gdy:

• pracujesz przy systemach krytycznych,
• masz dostęp do danych,
• umowa ma wysokie kary lub ryzyko roszczeń.

Ale uwaga: OC nie zastępuje cap. Polisa ma wyłączenia i limity. Dobrze jest powiązać umowę z realną polisą:

• wskazać minimalną sumę gwarancyjną adekwatną do cap,
• doprecyzować, że wymaganie OC nie oznacza automatycznie rozszerzenia Twojej odpowiedzialności ponad cap.

IP, NDA i dane: prawa autorskie, poufność, RODO

W IT „IP” to nie tylko kod. To też dokumentacja, architektura, skrypty infrastruktury, konfiguracje, a czasem prompty i workflowy dla narzędzi AI. W 2026, gdy firmy próbują skalować ROI z GenAI, częściej traktują know-how i dane jako strategiczny zasób (Computerworld). To przekłada się na umowy: szersze NDA, mocniejsze IP, bardziej rozbudowane klauzule o danych.

Po co to jest

Te klauzule mają:

• określić, co klient dostaje (prawa/ licencję),
• zabezpieczyć tajemnice przedsiębiorstwa,
• uregulować dostęp do danych i odpowiedzialność za ich przetwarzanie.

Przeniesienie praw autorskich B2B vs licencja: co wybierasz i dlaczego

Najczęściej spotkasz dwa modele:

1. Przeniesienie praw autorskich do „utworów” wytworzonych w ramach umowy
   Plus dla klienta: pełna kontrola.
   Ryzyko dla Ciebie: jeśli przeniesienie jest zbyt szerokie, możesz oddać także elementy ogólne (np. fragmenty własnych bibliotek) albo stracić możliwość ponownego użycia.

2. Licencja (często niewyłączna)
   Plus dla Ciebie: zachowujesz prawa, klient ma prawo korzystać.
   Minus: część klientów enterprise nie akceptuje, bo chcą „pełnych praw”.

Praktyczny kompromis: przeniesienie praw do tego, co powstaje „specyficznie” dla klienta, a do Twoich narzędzi/bibliotek — licencja.

Czerwona flaga: „przeniesienie praw do wszystkiego, co Wykonawca stworzy w czasie obowiązywania umowy”, także poza projektem.

Kontrzapis: „Przeniesienie praw dotyczy wyłącznie utworów wytworzonych w ramach realizacji Usług dla Zamawiającego. Elementy pre-existing (narzędzia, biblioteki) pozostają własnością Wykonawcy, a Zamawiający otrzymuje licencję w zakresie niezbędnym do korzystania z produktu.”

Kiedy przechodzą prawa: powiąż IP z płatnością

Bardzo ważne: moment przejścia praw. Bezpieczny standard:

• prawa przechodzą z chwilą zapłaty wynagrodzenia za dany etap/okres.

Czerwona flaga: prawa przechodzą „z chwilą stworzenia utworu” niezależnie od płatności.

NDA B2B: definicja informacji poufnych, wyjątki i czas trwania

NDA powinno być:

• szerokie na tyle, by chronić klienta,
• ale nie tak szerokie, by uniemożliwić Ci normalną pracę (np. pokazanie portfolio bez ujawniania tajemnic).

Doprecyzuj:

• co jest informacją poufną (np. dane techniczne, biznesowe, roadmapy),
• wyjątki (informacje publiczne, już znane, uzyskane legalnie od strony trzeciej),
• czas trwania (np. 2–5 lat; dla tajemnicy przedsiębiorstwa bywa dłużej, ale powinno to być uzasadnione).

Czerwona flaga: NDA „na zawsze” na wszystko, łącznie z faktem współpracy, bez wyjątków.

Kontrzapis: „Obowiązek poufności nie obejmuje informacji powszechnie znanych lub ujawnionych na podstawie obowiązku prawnego; w takim przypadku Wykonawca w miarę możliwości poinformuje Zamawiającego.”

RODO w kontrakcie B2B: powierzenie, role i minimalne zapisy

Jeśli masz dostęp do danych osobowych (np. logi, dane klientów, dane pracowników), umowa powinna określić:

• czy jesteś procesorem (podmiotem przetwarzającym) czy administratorem (zwykle procesor),
• czy jest potrzebna umowa powierzenia,
• minimalne środki bezpieczeństwa i procedury incydentowe.

Czerwona flaga: przerzucenie na Ciebie obowiązków administratora (np. spełnianie obowiązku informacyjnego) bez sensu operacyjnego.

Kontrzapis: „Wykonawca przetwarza dane osobowe wyłącznie na udokumentowane polecenie Zamawiającego i w zakresie niezbędnym do realizacji Usług.”

Warto też pamiętać o rosnącej roli compliance i audytowalności AI (np. w HR i procesach decyzyjnych), co zwiększa „formalizację” pracy z danymi (Newseria Biznes). Jeśli klient dorzuca obowiązki typu „AI governance”, „model risk”, „audyt promptów” — to powinno być w zakresie i w wycenie.

Wypowiedzenie umowy B2B, przerwy i zmiany współpracy

W B2B „bezpieczeństwo” to nie etatowe gwarancje, tylko dobrze ustawione zasady zakończenia współpracy i rozliczenia prac w toku. W realiach restrukturyzacji i presji kosztowej firmy potrafią szybko ucinać wydatki (CRN.pl). Dlatego klauzule wypowiedzenia są kluczowe.

Po co to jest

Dobre wypowiedzenie:

• daje czas na znalezienie kolejnego kontraktu,
• zapewnia rozliczenie za wykonaną pracę,
• ogranicza „nagłe odcięcie” dostępu bez zapłaty.

Czerwona flaga

• wypowiedzenie „w każdej chwili, ze skutkiem natychmiastowym, bez podania przyczyny” bez rozliczenia,
• brak rozliczenia prac w toku i brak obowiązku odbioru,
• możliwość natychmiastowego rozwiązania umowy za drobne naruszenia (np. spóźnienie z raportem).

Okres wypowiedzenia, rozwiązanie natychmiastowe i rozliczenie prac

Rynkowo w IT spotkasz 14–30 dni, czasem 1–2 miesiące przy rolach krytycznych. Kluczowe są dwa elementy:

1. Rozliczenie: „Strony rozliczą usługi wykonane do dnia rozwiązania umowy.”
2. Przekazanie: krótki, realny handover (np. dokumentacja + przekazanie repozytoriów).

Kontrzapis: „W przypadku wypowiedzenia Zamawiający dokona odbioru prac wykonanych do dnia zakończenia oraz zapłaci wynagrodzenie proporcjonalnie do wykonanych usług.”

Siła wyższa i przestoje po stronie klienta: co z wynagrodzeniem

W IT częste są przestoje „nie z Twojej winy”: brak dostępu, blokady bezpieczeństwa, opóźnienia po stronie innych zespołów. Ustal:

• czy masz płatność za gotowość (w T&M),
• czy termin realizacji przesuwa się automatycznie,
• czy można zawiesić umowę bez konsekwencji.

Czerwona flaga: klient może „zawiesić projekt” i nie płacić, ale Ty masz zakaz konkurencji i dostępność „na żądanie”.

Zmiana zakresu i stawek w trakcie

Warto dodać mechanizm rewizji stawek (np. po 6–12 miesiącach) albo przy istotnym rozszerzeniu zakresu (np. dołączenie on-call, przejęcie odpowiedzialności za produkcję). W 2026 rośnie popyt na kompetencje związane z danymi, platformą i bezpieczeństwem (No Fluff Jobs, ITwiz) — jeśli Twoja rola „ewoluuje” w tę stronę, stawka też powinna.

Zakaz konkurencji B2B i non-solicit: kiedy ma sens i jak go ograniczyć

Zakaz konkurencji w B2B bywa nadużywany: klient wrzuca szeroki zapis „na wszelki wypadek”, bo ma taki wzór. Dla Ciebie to realny koszt alternatywny — szczególnie, gdy pracujesz w niszy.

Po co to jest

W sensownej wersji:

• chroni klienta przed sytuacją, w której od razu przechodzisz do bezpośredniego konkurenta i wykorzystujesz know-how,
• stabilizuje zespół (w połączeniu z non-solicit).

Czerwona flaga

• zakaz konkurencji obejmuje całą „branżę IT” albo „wszystkie spółki z grupy kapitałowej”,
• czas trwania 12–24 miesiące bez rekompensaty,
• brak ograniczenia terytorialnego lub branżowego,
• zakaz dotyczy także projektów, które nie mają związku z tym klientem.

Jak to ograniczyć: zakres, czas, terytorium i rekompensata

Negocjuj cztery dźwignie:

1. Zakres klientów: lista konkretnych podmiotów (np. konkurenci klienta) zamiast „wszyscy”.
2. Branża/produkt: tylko segment, w którym faktycznie pracujesz.
3. Czas: zwykle 3–6 miesięcy (czasem 0, jeśli NDA i IP są wystarczające).
4. Rekompensata: jeśli zakaz jest realnie dotkliwy, powinien być płatny.

Kontrzapis: „Zakaz konkurencji dotyczy wyłącznie świadczenia usług na rzecz podmiotów wskazanych w załączniku, w zakresie produktów X, przez okres 3 miesięcy od zakończenia umowy, za wynagrodzeniem …”.

Non-solicit: zakaz podbierania ludzi i klientów

Non-solicit (zakaz nakłaniania pracowników/kontraktorów klienta do przejścia) bywa łatwiejszy do zaakceptowania niż zakaz konkurencji, ale też powinien być wąski:

• dotyczy aktywnego „podkupywania”, nie przypadkowych aplikacji,
• ma limit czasu (np. 6–12 miesięcy),
• ma proporcjonalną karę (jeśli w ogóle).

Jak negocjować kontrakt B2B: pytania i gotowe wiadomości

Negocjacje w IT w 2026 dzieją się w kontekście: firmy ostrożniej zatrudniają, preferują seniorów i oczekują większej przewidywalności dowozu (No Fluff Jobs, Antyweb). To nie znaczy, że nie negocjujesz. To znaczy, że negocjujesz mądrze: pokazujesz, że Twoje propozycje zmniejszają ryzyko sporu i ułatwiają współpracę.

Lista pytań do klienta (płatności, odbiory, IP, odpowiedzialność)

1. Jaki jest model rozliczeń: T&M czy fixed price? Co jest podstawą faktury?
2. Kto i w jakim terminie akceptuje timesheet/odbiór prac?
3. Co jest uznawane za „wadę istotną”, która blokuje odbiór?
4. Czy klient dopuszcza milczący odbiór po X dniach?
5. Czy klient przewiduje wstrzymanie płatności — w jakich przypadkach i w jakiej części?
6. Czy jest cap odpowiedzialności? Czy obejmuje kary umowne?
7. Czy są szkody pośrednie/utracone korzyści — czy można je wyłączyć?
8. Czy IP przechodzi po zapłacie? Czy są elementy pre-existing?
9. Czy przewidziane są dyżury on-call i SLA? Jak płatne?
10. Czy zakaz konkurencji ma rekompensatę i czy da się go zawęzić do listy podmiotów?

Propozycje zapisów i krótkie skrypty maili

Poniżej dwa gotowce: krótki, „biznesowy” i bardziej konkretny.

Czerwone flagi w umowie B2B w IT — szybka lista

Poniżej „ściąga” do ostatniego skanu przed podpisaniem.

Najczęstsze pułapki

• Brak definicji odbioru i jednocześnie płatność zależna od „akceptacji”.
• Wstrzymanie płatności w całości z powodu sporu o fragment prac.
• Kary umowne bez limitu łącznego i z możliwością kumulacji.
• Brak cap lub cap, który nie obejmuje kar umownych.
• Odpowiedzialność za szkody pośrednie i utracone korzyści klienta.
• SLA 24/7 bez on-call i bez dodatkowego wynagrodzenia.
• Przeniesienie praw autorskich „z chwilą stworzenia” (bez związku z zapłatą).
• Zakaz konkurencji szeroki jak „branża IT”, długi i bez rekompensaty.
• NDA „na zawsze” bez wyjątków i bez sensownej definicji poufności.
• Niejasne zapisy o danych/RODO, przerzucające na Ciebie rolę administratora.

Na koniec: jeśli dopiero szukasz współpracy, przeglądaj oferty z jasnymi warunkami (widełki, model pracy, zakres). Zobacz też oferty pracy IT na B2B i, jeśli to dla Ciebie ważne, praca zdalna w IT. Więcej materiałów o przygotowaniu do rozmów i dokumentach znajdziesz w sekcji porady o CV i rekrutacji w IT.

Źródła

1. [RAPORT] Rynek pracy IT 2025/2026. Powrót do stabilności (No Fluff Jobs) — kontekst odbicia rynku IT i zmiany preferencji (m.in. większa selektywność).
2. IT w Polsce wraca do gry – rynek pracy odbił w 2025 roku (ITwiz) — omówienie trendów rekrutacyjnych i kompetencji.
3. Odbicie na rynku pracy IT: więcej ofert, mniej CV, seniorzy rządzą (Antyweb) — komentarz do zmian po stronie popytu i podaży na rynku IT.
4. Paradoks AI: Bilans miejsc pracy pozostaje dodatni, ale dane hamują skalowanie ROI (Computerworld) — kontekst presji na ROI, danych i wpływu na wymagania w projektach.
5. Cisco redefiniuje bezpieczeństwo w erze agentowej AI (Cisco News, PL) — tło zmian ryzyka i bezpieczeństwa przy agentowej AI.
6. Cisco analizuje globalne zagrożenia AI: „State of AI Security 2026” (ITReseller) — omówienie wniosków o tempie wdrożeń vs zabezpieczeń.
7. Bezpieczeństwo AI pod presją: raport „State of AI Security 2026” (Control Engineering Polska) — dodatkowa interpretacja trendów bezpieczeństwa AI.
8. Sztuczna inteligencja w rekrutacji pod lupą… (Newseria Biznes) — kontekst regulacyjny i rosnącej roli compliance/gov w systemach AI.
9. Nawet 35 tys. zł dla specjalisty IT w centrum usług (CRN.pl) — kontekst popytu i płac w centrach usług IT.
10. 45 tys. zwolnień w sektorze technologicznym (CRN.pl) — tło restrukturyzacji i presji kosztowej w branży tech.