Przewodnik compliance dla firm IT i umów B2B

Model B2B jest dla firm IT naturalnym sposobem współpracy z developerami, testerami, projektantami i specjalistami DevOps. Problem zaczyna się nie przy samym wyborze formy kontraktu, lecz wtedy, gdy codzienna organizacja pracy i zapisy umowy zaczynają przypominać etat. Ten przewodnik compliance dla firm IT pomaga uporządkować obszary, które warto sprawdzać przed podpisaniem kontraktu, w trakcie współpracy i przed możliwą kontrolą PIP.

Nie chodzi o to, aby każdą umowę B2B traktować jak potencjalne naruszenie. Celem jest rozpoznanie konkretnych cech zwiększających ryzyko uznania relacji za stosunek pracy zgodnie z art. 22 §1 Kodeksu pracy. W branży IT ryzyko bywa trudne do zauważenia, ponieważ wygodne operacyjnie zasady - stałe godziny spotkań, przypisanie do zespołu czy wymaganie dostępności - mogą w połączeniu z innymi elementami tworzyć niekorzystny obraz współpracy.

Dlaczego compliance B2B w IT wymaga osobnej procedury

Software house lub wewnętrzny dział technologii działa w rytmie sprintów, release'ów i incydentów produkcyjnych. Zespół musi się komunikować, pracować na wspólnych narzędziach i dotrzymywać terminów. Sama koordynacja projektu nie oznacza jeszcze podporządkowania pracowniczego.

Granica przesuwa się wtedy, gdy firma nie tylko określa rezultat, zakres projektu i standardy bezpieczeństwa, ale stale kieruje sposobem wykonywania zadań, miejscem pracy oraz czasem świadczenia usług. Znaczenie ma również to, czy wykonawca ponosi realne ryzyko gospodarcze, może działać dla innych klientów i organizuje pracę jako niezależny przedsiębiorca.

Compliance nie powinno więc polegać na usunięciu z umowy każdego elementu współpracy. Kontrakt bez zasad realizacji projektu też nie jest dobrym rozwiązaniem. Potrzebna jest spójność między dokumentem, praktyką menedżerską i dowodami faktycznej samodzielności kontraktora.

Przewodnik compliance dla firm IT: od umowy do praktyki

Najczęstszy błąd polega na analizie wyłącznie wzoru umowy. Nawet poprawnie sformułowany kontrakt nie ograniczy ryzyka, jeśli w praktyce manager codziennie wydaje polecenia dotyczące sposobu pracy, zatwierdza każdą godzinę dostępności i nie dopuszcza zastępstwa. Z drugiej strony dobrze prowadzona współpraca operacyjna nie naprawi dokumentu, który wprost opisuje relację typową dla etatu.

Warto prowadzić ocenę w trzech warstwach: treści kontraktu, sposobu zarządzania usługą oraz dokumentów potwierdzających biznesowy charakter relacji. Taki podział pozwala wykryć problem wcześniej niż podczas audytu lub kontroli.

1. Sprawdź, co faktycznie zamawiasz

Umowa B2B powinna możliwie precyzyjnie opisywać usługi, rezultat, odpowiedzialność i zasady współpracy projektowej. W IT nie zawsze da się zdefiniować rezultat jako pojedynczy, zamknięty produkt. Można jednak określić zakres usług, backlog, kamienie milowe, standardy jakości, model raportowania postępu i sposób odbioru prac.

Ryzyko rośnie, gdy dokument koncentruje się na obowiązku osobistego wykonywania pracy pod bieżącym kierownictwem firmy, w wskazanych godzinach i w narzuconym miejscu. Pojedynczy zapis nie przesądza sprawy. Liczy się układ okoliczności, dlatego ocena powinna obejmować cały kontrakt, a nie tylko jedno sformułowanie o czasie pracy.

2. Oddziel koordynację projektu od kierownictwa nad osobą

Product owner może ustalać priorytety produktu, a tech lead może definiować wymagania architektoniczne. To elementy zarządzania projektem. Problem pojawia się, gdy komunikacja zmienia się w stałe wydawanie poleceń co do tego, jak kontraktor ma wykonywać pracę, kiedy ma być dostępny i czy może skorzystać z pomocy innej osoby.

W praktyce warto zadbać, aby komunikaty projektowe odnosiły się do zadania, terminu, jakości i bezpieczeństwa, a nie do pracowniczego nadzoru nad osobą. Zamiast formułować polecenie obecności w biurze od 9:00 do 17:00, firma może uzasadnić spotkanie konkretną potrzebą projektową. Nie jest to zabieg językowy. Za zapisami i komunikacją musi stać rzeczywisty model współpracy.

3. Zbadaj zasady czasu i miejsca wykonywania usług

Stałe godziny pracy należą do elementów, które często wymagają szczególnej uwagi. Współpraca z zespołem może wymagać wspólnego okna dostępności, udziału w daily czy dyżuru podczas wdrożenia. Nie każdy obowiązek czasowy tworzy relację pracowniczą.

Znaczenie ma skala i charakter ograniczenia. Inaczej wygląda zobowiązanie do obecności na zaplanowanym spotkaniu projektowym, a inaczej pełne podporządkowanie harmonogramowi ustalanemu jednostronnie przez firmę. Podobnie jest z miejscem wykonywania usług. Wymóg pracy z biura może wynikać z ochrony informacji lub dostępu do infrastruktury, ale powinien mieć operacyjne uzasadnienie i nie zastępować stałej kontroli nad wykonawcą.

4. Oceń osobiste świadczenie usług i zastępstwo

W branży IT klient często wybiera konkretną osobę ze względu na doświadczenie, znajomość systemu lub certyfikaty. To zrozumiałe, lecz całkowite wyłączenie możliwości zastępstwa może zwiększać ryzyko, zwłaszcza gdy towarzyszą mu inne cechy typowe dla zatrudnienia.

Nie ma jednego bezpiecznego wzoru. W projektach o wysokiej poufności lub dostępie do produkcji zastępstwo może wymagać akceptacji, odpowiednich uprawnień i spełnienia warunków bezpieczeństwa. Kluczowe jest, aby zasady nie były pozorne. Jeżeli umowa dopuszcza zastępstwo, procedura powinna umożliwiać jego realne zastosowanie w uzasadnionych przypadkach.

5. Zweryfikuj rozliczenia, odpowiedzialność i ryzyko gospodarcze

Miesięczne wynagrodzenie samo w sobie nie przesądza o charakterze współpracy. Jest powszechne przy dłuższych projektach IT. Warto jednak sprawdzić, czy rozliczenia są powiązane z usługami, zakresem prac, gotowością projektową lub etapami realizacji, a nie opisane językiem typowym dla pensji.

Istotna jest również odpowiedzialność kontraktora za jakość usług, poufność, bezpieczeństwo oraz skutki nienależytego wykonania zobowiązania. Zapisy o odpowiedzialności muszą być proporcjonalne do realnego wpływu wykonawcy na projekt. Nadmierne i abstrakcyjne kary nie zwiększają automatycznie bezpieczeństwa firmy, a mogą utrudnić pozyskanie specjalistów i nie odpowiadać rzeczywistemu modelowi współpracy.

Jak zorganizować wewnętrzny proces kontroli

Najlepszy moment na ocenę ryzyka to etap przed podpisaniem umowy lub przedłużeniem kontraktu. Wtedy korekta zapisów i zasad współpracy jest prostsza niż po kilku miesiącach pracy w utrwalonym modelu. W firmie IT proces może być krótki, ale powinien być powtarzalny.

Praktyczna procedura obejmuje zebranie aktualnej wersji umowy, aneksów i zasad projektowych, a następnie ocenę zapisów pod kątem kluczowych kryteriów. Kolejny krok to rozmowa z osobą odpowiedzialną za projekt. Ma ona potwierdzić, czy dokument odpowiada rzeczywistości: dostępności, raportowaniu, narzędziom, miejscu wykonywania usług i sposobowi przydzielania zadań.

Dopiero po zestawieniu umowy z praktyką warto ustalić kierunek korekt. Czasem wystarczy uporządkować komunikację i zasady zatwierdzania prac. W innych sytuacjach konieczny będzie aneks lub zmiana modelu współpracy. Nie należy poprawiać dokumentów w oderwaniu od rzeczywistości, ponieważ podczas kontroli znaczenie mają również faktyczne warunki świadczenia usług.

Co powinien zawierać dobry audyt kontraktu B2B

Audyt przydatny operacyjnie nie kończy się ogólną oceną „niskie”, „średnie” lub „wysokie” ryzyko. Osoba odpowiedzialna za HR, operacje lub administrację musi wiedzieć, który fragment dokumentu budzi wątpliwość, z jakim kryterium jest związany i co warto przeanalizować dalej.

Właśnie dlatego użyteczna analiza powinna wskazywać cytaty z umowy, oceniać je w kontekście wielu kryteriów oraz oddzielać problematyczne sformułowania od zapisów neutralnych. PipCheck umożliwia wstępny screening dokumentu PDF, a pełny raport porządkuje ocenę 14 kryteriów ryzyka wraz z odniesieniem do konkretnych zapisów kontraktu. To sposób na szybką selekcję problemów przed skierowaniem sprawy do dalszej analizy prawnej, jeśli jej zakres jest potrzebny.

Dokumentuj decyzje, nie tylko kontrakty

Przygotowanie do kontroli nie zaczyna się w dniu otrzymania zawiadomienia. Firma powinna móc wykazać, że zasady współpracy B2B są przemyślane, a nie przypadkowe. Pomagają w tym aktualne umowy, aneksy, zakresy usług, ustalenia projektowe oraz spójna komunikacja osób zarządzających zespołem.

Nie warto tworzyć dokumentacji pozornej ani kopiować tych samych zapisów dla każdego stanowiska. Kontrakt backend developera pracującego przy systemie krytycznym może wymagać innych zasad niż umowa z niezależnym konsultantem wdrożeniowym. Compliance działa najlepiej wtedy, gdy uwzględnia realia projektu, a jednocześnie pozwala jasno wykazać niezależny charakter współpracy.

Dobrze ustawiony proces nie ma utrudniać pracy zespołu. Ma dać firmie prostą odpowiedź na pytanie, czy jej umowy i codzienna praktyka mówią to samo - zanim to pytanie zada kontrola PIP.