Czy PIP sprawdza freelancerów IT na B2B?

Nie każdy kontrakt B2B w IT jest automatycznie przedmiotem kontroli. Pytanie „czy PIP sprawdza freelancerów IT” jest jednak zasadne, gdy współpraca z kontraktorem zaczyna działać jak zwykłe zatrudnienie: w stałych godzinach, pod bieżącym kierownictwem i w strukturze jednej firmy. W takiej sytuacji inspektor nie ocenia wyłącznie nazwy dokumentu. Patrzy na to, jak strony realizują umowę w praktyce.

Dla software house’u, firmy produktowej czy działu HR oznacza to jedno: ryzyko nie leży wyłącznie w samym fakcie współpracy B2B. Powstaje wtedy, gdy treść kontraktu, sposób organizacji pracy i codzienna komunikacja razem przypominają stosunek pracy opisany w art. 22 §1 Kodeksu pracy.

Czy PIP sprawdza freelancerów IT?

Państwowa Inspekcja Pracy nie prowadzi kontroli dlatego, że ktoś wystawia faktury jako programista, tester lub administrator. Model B2B jest legalny i powszechny. PIP może natomiast badać relację łączącą firmę z wykonawcą, jeśli w toku kontroli powstanie wątpliwość, czy strony nie zastąpiły umowy o pracę kontraktem cywilnoprawnym lub umową między przedsiębiorcami.

Kontrola zwykle dotyczy podmiotu, który organizuje pracę i korzysta z usług wykonawców, a nie freelancera rozumianego jako odrębna osoba „wybrana do sprawdzenia”. W praktyce inspektor może analizować dokumenty firmy, zasady współpracy, ewidencję dostępu do biura i systemów, korespondencję operacyjną oraz wypowiedzi osób zaangażowanych w projekt. Freelancer może zostać poproszony o wyjaśnienia, ponieważ jego sposób wykonywania zlecenia ma znaczenie dla oceny relacji.

Źródłem kontroli może być skarga, informacja uzyskana przy badaniu innego obszaru działalności albo planowa czynność inspekcyjna. Nie warto więc zakładać, że brak konfliktu z kontraktorem usuwa ryzyko. Relacja może zostać oceniona także wtedy, gdy obie strony są z niej zadowolone.

Co PIP ocenia w relacji B2B z freelancerem IT

Punkt wyjścia stanowi art. 22 §1 Kodeksu pracy. Przepis opisuje pracę wykonywaną za wynagrodzeniem, na rzecz pracodawcy, pod jego kierownictwem oraz w miejscu i czasie przez niego wyznaczonym. Żaden pojedynczy element nie przesądza sprawy. Znaczenie ma cały obraz współpracy.

W IT szczególnie często pojawiają się cechy, które mogą budzić pytania. Kontraktor pracuje w jednym zespole, ma dostęp do tych samych narzędzi co pracownicy etatowi, uczestniczy w daily i realizuje zadania w sprintach. Same w sobie nie muszą oznaczać etatu. Projekt technologiczny wymaga koordynacji, bezpieczeństwa informacji oraz pracy według wspólnego rytmu.

Ryzyko rośnie, gdy koordynacja przechodzi w bieżące wydawanie poleceń dotyczących nie tylko rezultatu, lecz także każdego elementu pracy. Podobnie jest z obowiązkową dostępnością od 9:00 do 17:00, koniecznością uzyskiwania zgody na nieobecność, brakiem realnej możliwości zastępstwa czy zakazem współpracy z innymi klientami.

W analizie warto odróżnić wymagania projektowe od podporządkowania pracowniczego. Termin wydania funkcji, wymóg obecności na kluczowym warsztacie lub obowiązek stosowania standardów bezpieczeństwa mogą być uzasadnione kontraktem B2B. Inaczej wygląda sytuacja, w której firma ustala freelancerowi grafik, zatwierdza prywatne wyjścia, rozlicza każdą godzinę jak czas pracy i rozdziela zadania w sposób typowy dla przełożonego.

Zapisy umowne, które wymagają szczególnej uwagi

Najwięcej problemów nie wynika z jednego zdania, lecz z niespójności między deklarowaną niezależnością a pozostałymi postanowieniami. Umowa może nazywać wykonawcę niezależnym przedsiębiorcą, a jednocześnie nakazywać mu świadczenie usług osobiście, w siedzibie klienta, w sztywnym wymiarze godzin i pod kierownictwem wskazanego managera.

Przed podpisaniem lub odnowieniem kontraktu warto przejrzeć w szczególności postanowienia dotyczące sposobu wykonywania usług, czasu i miejsca realizacji, zastępstwa, odpowiedzialności, wynagrodzenia, raportowania oraz zasad nieobecności. Równie istotne są załączniki, regulaminy i procedury, do których odsyła umowa. To w nich często pojawiają się obowiązki zbliżone do pracowniczych.

Uwaga powinna objąć także praktykę. Dobrze sformułowana umowa nie ochroni firmy, jeżeli jej postanowienia pozostają wyłącznie na papierze. Jeżeli kontraktor formalnie może wyznaczać sposób realizacji usługi, ale w rzeczywistości codziennie otrzymuje szczegółowe polecenia i nie może odmówić pracy poza ustalonymi godzinami, inspektor będzie badał właśnie ten faktyczny model.

Kiedy B2B w IT nie powinno budzić nadmiernych obaw

Współpraca z freelancerem może być właściwie ułożona także wtedy, gdy trwa długo i dotyczy kluczowego produktu. Długoterminowość nie oznacza automatycznie stosunku pracy. Liczy się, czy wykonawca zachowuje cechy samodzielnego przedsiębiorcy oraz czy strony rzeczywiście rozliczają usługę biznesową.

Za bardziej typowym modelem B2B może przemawiać samodzielne organizowanie pracy, odpowiedzialność za uzgodniony zakres lub rezultat, możliwość korzystania z zastępcy w rozsądnym zakresie, własne narzędzia albo własna organizacja świadczenia usług. Znaczenie może mieć również działanie na rzecz innych klientów, ale nie jest to warunek obowiązkowy w każdej relacji.

Trzeba jednak zachować ostrożność przy kopiowaniu „bezpiecznych” klauzul. Na przykład prawo do zastępstwa, którego firma nigdy nie zaakceptuje w realnej sytuacji, będzie jedynie pozorną ochroną. Tak samo zapis o swobodzie miejsca pracy nie zmieni oceny, jeśli kontraktor musi codziennie pojawiać się w biurze bez uzasadnienia projektowego.

Jak przygotować kontrakt B2B na ewentualną kontrolę

Najskuteczniejsze jest podejście operacyjne: najpierw sprawdzenie modelu współpracy, potem umowy, a na końcu codziennych procedur. Nie chodzi o tworzenie dokumentu, który ma „przejść kontrolę” za wszelką cenę. Chodzi o to, by dokumentacja uczciwie i precyzyjnie opisywała relację biznesową, którą strony faktycznie realizują.

W firmie warto ustalić, kto może wydawać kontraktorom instrukcje i w jakim zakresie. Manager projektu powinien koordynować rezultat, priorytety, bezpieczeństwo oraz zależności w zespole, ale nie automatycznie zarządzać freelancerem tak jak pracownikiem. Przydatne są jasne reguły dotyczące dostępności, odbioru usług, zgłaszania przeszkód i zastępstwa.

Następnie należy sprawdzić, czy wzory umów nie zawierają mechanicznie przeniesionych zapisów z dokumentów pracowniczych. Dotyczy to zwłaszcza urlopów, przełożonych, godzin pracy, obowiązkowej obecności i sankcji za nieobecność. Nie każdy taki zapis musi przesądzać o ryzyku, ale każdy powinien mieć uzasadnienie zgodne z biznesowym charakterem współpracy.

Dobrą praktyką jest także okresowy przegląd kontraktów, ponieważ model projektu zmienia się szybciej niż dokumentacja. Freelancer zatrudniony początkowo do wykonania konkretnego modułu może po roku pełnić stałą funkcję w zespole, pracować wyłącznie dla jednego klienta i podlegać coraz większej kontroli operacyjnej. To moment, w którym warto ponownie ocenić relację, zamiast zakładać, że pierwotna umowa nadal odpowiada rzeczywistości.

PipCheck pozwala wykonać taki pierwszy screening na podstawie PDF-a umowy. Narzędzie analizuje ryzyko reklasyfikacji według 14 kryteriów, wskazuje konkretne fragmenty dokumentu i porządkuje obszary wymagające weryfikacji. Nie zastępuje indywidualnej porady prawnej ani nie ocenia faktycznej organizacji pracy, ale pomaga szybko wychwycić zapisy, które warto zestawić z praktyką projektu.

Co zrobić po kontroli lub przed zmianą modelu współpracy

Jeżeli firma otrzyma pytania dotyczące kontraktów B2B, nie należy improwizować ani poprawiać dokumentów bez analizy ich skutków. Najpierw trzeba ustalić, jakie umowy obowiązują, jak współpraca wygląda w praktyce i czy te dwa obrazy są spójne. Następnie można przygotować uporządkowane wyjaśnienia oraz zdecydować, które procesy lub zapisy wymagają korekty.

Przedsiębiorcy IT nie muszą rezygnować z B2B tylko dlatego, że PIP może badać takie relacje. Powinni natomiast traktować kontrakt jako element rzeczywistego modelu współpracy, a nie formalną etykietę. Najbezpieczniejszy dokument to taki, który precyzyjnie opisuje niezależną usługę i da się obronić także w codziennym działaniu zespołu.