B2B-контракт в Польше: когда отношения с IT-специалистом могут признать трудовыми

B2B-модель широко используется польскими компаниями, в том числе при работе с разработчиками, IT-консультантами, менеджерами проектов и другими специалистами. Вместо трудового договора стороны заключают гражданско-правовой или B2B-контракт, а исполнитель оказывает услуги как самостоятельный контрагент.

Однако название договора само по себе не определяет характер отношений. Если фактическая модель сотрудничества по своим признакам соответствует трудовым отношениям, использование B2B-контракта не исключает риска их переквалификации.

После расширения полномочий польской инспекции труда этот вопрос приобрел дополнительное практическое значение. Компании получили возможность запрашивать индивидуальные интерпретации относительно того, содержит ли конкретная модель сотрудничества признаки трудовых отношений. Первые опубликованные позиции GIP позволяют увидеть, какие обстоятельства ведомство считает наиболее существенными.

Из восьми рассмотренных случаев в трех GIP не обнаружил трудовых отношений и допустил использование соответствующей модели сотрудничества, тогда как в пяти пришел к противоположному выводу. Один из положительных кейсов непосредственно касается IT и показывает, что даже такие элементы, как учет рабочего времени, оборудование заказчика и участие Project Manager, не обязательно превращают B2B в трудовые отношения. Значение имеет то, как в действительности организована работа исполнителя.

Главный критерий — самостоятельность исполнителя

Один из наиболее существенных вопросов для GIP — степень подчинения исполнителя заказчику. Причем свобода самостоятельно определять график еще не означает, что отношения автоматически являются B2B.

В одной из рассмотренных моделей исполнитель мог выбирать дни и часы своей работы, однако после начала работы конкретные задачи на день определял заказчик. GIP увидел в этом признак трудовых отношений: формальная свобода графика не компенсировала отсутствие самостоятельности в организации самой работы.

Поэтому необходимо различать контроль и надзор за результатом. Заказчик может интересоваться статусом проекта, проверять соблюдение сроков, оценивать качество и контролировать достижение согласованных результатов. Само по себе это не означает работодателя и работника. Риск становится выше, когда заказчик начинает ежедневно определять не только что должно быть получено в результате, но и как именно исполнитель должен выполнять свою работу.

Для IT-компаний это особенно важное различие. Постановка требований к функциональности продукта, срокам спринта или стандартам качества не равнозначна ежедневному управлению специалистом как сотрудником.

Возможность привлечь другого исполнителя должна быть реальной

Еще один существенный критерий — обязан ли контрагент выполнять работу исключительно лично.

В нескольких рассмотренных GIP случаях договоры формально позволяли привлекать другого исполнителя. Однако ведомство анализировало не только текст соответствующего пункта, но и возможность реально воспользоваться им.

Если предполагаемый субисполнитель должен сначала самостоятельно заключить новый договор непосредственно с заказчиком, наличие в основном контракте права на замену может оказаться недостаточным. Формально возможность передать исполнение существует, фактически контрагент по-прежнему обязан выполнять работу лично.

В другом рассмотренном случае реальная возможность передать исполнение третьему лицу, напротив, стала одним из существенных аргументов в пользу отсутствия трудовых отношений.

Поэтому для B2B-контракта важна не сама фраза о возможности привлечения субисполнителя. Механизм должен соответствовать реальной модели сотрудничества и действительно позволять контрагенту организовать оказание услуг не так, как это делает обычный работник.

Кто несет риски при выполнении работы

Трудовые отношения предполагают, что значительную часть организационных и экономических рисков принимает на себя работодатель. В B2B-модели самостоятельный контрагент, напротив, должен нести определенный предпринимательский риск.

В первых интерпретациях GIP обращал внимание сразу на несколько обстоятельств: кто предоставляет необходимое оборудование, кто несет последствия простоев и сохраняется ли вознаграждение, когда фактически отсутствует работа.

Само предоставление заказчиком ноутбука или другого оборудования может указывать на трудовую модель, но этот признак не является абсолютным. В IT-кейсе GIP допустил использование оборудования компании, поскольку оно было связано с требованиями информационной безопасности и аналогичные требования распространялись на внешних поставщиков услуг.

Иначе оценивается гарантированное вознаграждение независимо от наличия работы. В одном из рассмотренных случаев исполнитель сохранял право на 50% оплаты при отмене задания менее чем за час до согласованного времени. Для GIP это стало аргументом в пользу того, что экономический риск фактически принимает заказчик.

Таким образом, ведомство смотрит не на отдельную формулировку договора, а на распределение рисков в целом: кто несет последствия отсутствия заказов, ошибок, простоев и других обстоятельств, возникающих при выполнении работы.

Для IT имеет значение автономность профессиональной работы

Особенно интересный вывод первых интерпретаций касается характера самой деятельности.

В судебной практике используется концепция автономного исполнения: заказчик определяет задачу и ожидаемый результат, тогда как специалист самостоятельно решает, каким способом этот результат будет достигнут. Такой подход хорошо соответствует работе разработчиков, консультантов и других квалифицированных специалистов.

GIP, судя по первым опубликованным интерпретациям, проводит различие между интеллектуальным или творческим трудом и простыми физическими работами. В ряде случаев ведомство не признало автономность исполнения достаточным аргументом именно потому, что характер деятельности фактически не оставлял исполнителю существенной самостоятельности в выборе способа выполнения задачи.

Для IT этот подход имеет особое значение. Чем больше специалист самостоятельно определяет методы работы внутри согласованных целей, сроков и требований к качеству, тем сильнее аргумент в пользу самостоятельного характера B2B-отношений.

Результат работы важнее самого процесса

Еще один заметный критерий — на чем фактически построены отношения сторон: на предоставлении рабочего времени или достижении определенного результата.

В интерпретациях, касавшихся IT и продаж, GIP положительно оценивал модели, в которых отношения были ориентированы именно на результат. Для IT-контракта значение имели приемка выполненной работы, ответственность за ненадлежащее исполнение и договорные последствия нарушения сроков.

Это не означает, что любой B2B-контракт должен превращаться в классический договор с одним конечным результатом. В IT распространены длительные проекты, Agile-модели и time and material. Важнее другое: учет часов не должен автоматически превращаться в контроль рабочего времени, характерный для трудовых отношений.

В рассмотренном IT-кейсе регистрация часов в модели time and material использовалась для расчета вознаграждения и выставления счета. GIP не расценил ее как контроль соблюдения норм рабочего времени.

График работы имеет значение, но не решает вопрос сам по себе

Жестко установленное рабочее время является сильным аргументом в пользу трудовых отношений. Однако отсутствие фиксированного графика само по себе еще не доказывает самостоятельность контрагента.

GIP обращает внимание на то, может ли исполнитель самостоятельно сообщать о своей доступности и отказываться от работы. Допустимым может быть и определенное окно доступности, если оно обусловлено характером оказываемых услуг, а не используется как замена стандартному рабочему графику.

Именно такой подход был принят в IT-интерпретации: договор предусматривал рамку с 6:00 до 22:00, связанную с требованиями клиентов и оказываемых услуг. Само существование такого временного диапазона не стало основанием для признания трудовых отношений.

Значение имеет и место оказания услуг. Возможность работать удаленно либо определять место работы в рамках конкретного заказа поддерживает самостоятельность модели, хотя, как и другие критерии, не оценивается изолированно.

Какие признаки сами по себе не спасают B2B-модель

Первые интерпретации показывают еще одну важную тенденцию: некоторые аргументы, которые стороны традиционно используют в пользу B2B, имеют для ведомства гораздо меньшее значение, чем фактическая организация работы.

В частности:

• желание самого исполнителя работать через B2B не определяет юридическую квалификацию отношений;
• сезонность, организационное удобство и экономические причины выбора модели имеют ограниченное значение;
• нерегулярность работы может поддерживать B2B-характер отношений, но является относительно слабым признаком;
• отсутствие включения в организационную структуру компании оценивается вместе с другими обстоятельствами, а не как самостоятельное доказательство.

Поэтому одного заявления в договоре о том, что стороны не намерены создавать трудовые отношения, недостаточно. При проверке будет анализироваться то, как сотрудничество организовано на практике.

Что GIP признал допустимым в IT-контракте

Наиболее показательной для технологического бизнеса стала интерпретация GIP-GPP.50.6.2026.3, в которой ведомство не обнаружило трудовых отношений и допустило соответствующую модель сотрудничества.

Структура была построена на рамочном контракте и отдельных заказах. Контрагент мог отказаться от конкретного заказа, а компания не гарантировала постоянный объем работы или непрерывность сотрудничества. Координаторы определяли проектные задачи, ожидаемые результаты, стандарты качества и сроки, но не устанавливали обязательным образом детальный способ их выполнения.

Среди обстоятельств, которые соответствовали самостоятельной модели сотрудничества, можно выделить:

• учет задач в информационных системах использовался для управления проектом и документирования, а не для контроля работника;
• учет часов в time and material был необходим для расчета вознаграждения и выставления счета;
• отсутствовала оплата за саму готовность к работе и периоды без заказов;
• результат подлежал приемке, а за просрочку и ненадлежащее исполнение предусматривалась договорная ответственность;
• исполнитель мог при соблюдении предусмотренных условий передать исполнение третьему лицу и не был лишен возможности работать с другими заказчиками;
• на контрагента не распространялись внутренние правила и трудовые права, характерные для сотрудников компании.

Особенно интересны два элемента этой модели — оборудование заказчика и роль Project Manager. Оба на первый взгляд могут напоминать стандартную организацию трудовых отношений, однако GIP оценил их в контексте всей структуры.

Почему ноутбук компании не превратил контрактора в работника

Предоставление оборудования заказчиком традиционно может рассматриваться как один из признаков того, что экономические и организационные риски принимает компания. В IT-проекте, однако, GIP принял объяснение необходимости использовать оборудование и программное обеспечение заказчика.

Причина заключалась не в удобстве специалиста, а в требованиях информационной безопасности, защиты данных и внутренних стандартов, которые распространялись также на внешних поставщиков услуг. В сообщении клиента отдельно упоминаются требования ISO 9001, ISO/IEC 27001, RODO и BHP.

Это важный практический вывод для IT-компаний. Сам факт выдачи контрагенту корпоративного ноутбука еще не определяет квалификацию отношений. Гораздо важнее, почему компания предоставляет оборудование и связано ли это с объективными требованиями проекта, безопасности и доступа к системам.

Может ли Project Manager ставить задачи B2B-контрактору

Не менее интересна позиция GIP относительно роли Project Manager. В рассмотренной модели PM распределял проектные задачи, формировал график этапов, проводил проектные встречи, контролировал прогресс и качество и взаимодействовал с Product Owner со стороны компании.

Несмотря на это, ведомство не увидело достаточного трудового подчинения. Существенными оказались три ограничения.

Во-первых, Project Manager не выполнял полномочия работодателя: он не заключал и не расторгал договоры с контракторами, не определял их вознаграждение и не предоставлял отпуск. Во-вторых, его указания относились к проектным задачам и оставались в пределах согласованного объема проекта.

Наконец, сам PM работал внутри определенной проектной методологии — например, Agile, Scrum, PRINCE2, SAFe или гибридной модели. Контрактор при этом сохранял самостоятельность в организации способа оказания услуг в пределах цели проекта, требований к качеству и установленных контрольных точек.

Таким образом, наличие Project Manager, спринтов, встреч и распределения задач еще не означает трудового управления. Ключевым остается вопрос о том, управляет ли PM проектом и его результатом или непосредственно работой человека как сотрудника.

Что проверить IT-компании в B2B-модели

Первые интерпретации GIP показывают, что универсального признака, который автоматически превращает B2B-контракт в трудовой или, наоборот, гарантирует его самостоятельный характер, нет. Ведомство оценивает совокупность обстоятельств и, что особенно важно, фактическую модель взаимодействия.

Для IT-компании поэтому недостаточно однажды подготовить шаблон B2B-контракта. Необходимо проверить, соответствует ли ему реальная работа команд: кто ставит задачи, насколько подробно PM управляет исполнителями, как фиксируется время, оплачиваются ли периоды без работы, можно ли отказаться от проекта или привлечь другого специалиста, каким образом предоставляется оборудование и распространяются ли на контракторов внутренние трудовые правила.

Особенно показательна интерпретация GIP-GPP.50.6.2026.3. Она показывает, что сама по себе зрелая проектная инфраструктура — таск-трекеры, time and material, корпоративное оборудование, Project Manager, стандарты качества и регулярные встречи — совместима с B2B. Риск возникает не из-за наличия этих инструментов, а тогда, когда за ними фактически скрывается организация работы, характерная для отношений работодателя и работника.

Для компаний, которые системно работают с польскими B2B-контракторами, это хороший момент проверить не только договоры, но и фактические процессы взаимодействия с командой. После появления индивидуальных интерпретаций такую проверку можно проводить уже с учетом первых опубликованных подходов GIP.