«IT-юрист» — запрос, за которым ищут очень разные вещи: кто-то хочет составить один договор, кто-то готовится к due diligence перед сделкой с инвестором, а кто-то только что положил трубку после звонка из банка, заблокировавшего счёт. Эта статья — обзор того, что на самом деле входит в работу IT-юриста, когда он реально нужен и куда смотреть дальше, если ваша ситуация требует более глубокого разбора.
На практике — да, это тот же специалист, просто две формы одного запроса. Важнее другая разница: между юристом и адвокатом. Юрист составляет договоры, сопровождает сделки, консультирует по GDPR и структуре бизнеса. Адвокат имеет дополнительный статус, который даёт право представлять компанию в уголовном производстве — при обыске, вызове на допрос, общении со следователем. Подробнее об этой разнице — в материале IT-адвокат: кто это. В ITLex это одна команда, поэтому сопровождение не прерывается, если консультационный вопрос вдруг перерастает в процессуальный.
Большинство компаний обращаются за помощью уже в момент проблемы, а не до неё. Пока заказчик платит, разработчики сдают код, а налоговая молчит — всё выглядит урегулированным и без документов. Пробел обнаруживается не постепенно, а одномоментно, и почти всегда в одной из трёх ситуаций.
Первая — due diligence. Приходит инвестор, покупатель или крупный заказчик и просит показать, кому принадлежат права на продукт, как оформлены отношения с разработчиками, какие персональные данные вы обрабатываете и на каком основании.
Вторая — банк или платёжная система. Иностранный контрагент не может провести оплату, пока комплаенс не увидит договор, соответствующий его внутренним требованиям, или банк запрашивает объяснение экономической сути операций с ФЛП-подрядчиками.
Третья — правоохранители. Обыск в офисе, вызов на допрос, арест счёта. В этот момент выстраивать структуру уже поздно — проверяют ту, которая есть. Подробнее о порядке действий — в материале адвокат при обыске и на допросе.
Юридический due diligence IT-компании, как правило, состоит из нескольких блоков, и именно порядок, в котором они проверяются, показывает, насколько бизнес готов к сделке. Сначала смотрят на права на продукт: есть ли в компании подписанная цепочка передачи прав от каждого, кто писал код, — от первых фрилансеров до нынешней команды. Далее — корпоративную структуру: соответствует ли реестр участников фактическому распределению долей, есть ли партнёрское соглашение и не висит ли неоформленный выход кого-то из сооснователей. Третий блок — договоры с клиентами: согласуются ли обещания в договорах с тем, что продукт реально умеет, и кто отвечает, если есть сбой. Четвёртый — персональные данные: есть ли правовые основания обработки, подписаны ли договоры с процессорами, описана ли в Privacy Policy реальная практика компании. Пробел в любом из этих блоков не обязательно срывает сделку, но почти всегда снижает оценку или останавливает процесс на несколько недель для «доработки домашнего задания».
Три контура договоров ломаются по-разному. Договоры с заказчиками — Fixed Price и Time&Material имеют разную логику ответственности, и подставлять один шаблон под обе модели — самая распространённая ошибка. Договоры с разработчиками — критично, описан ли предмет: что конкретно создаётся и как фиксируется факт передачи, а не просто «оказание услуг по программированию». Публичные документы продукта — оферта, Terms of Use, Privacy Policy — обычно берутся с чужого сайта, и это никому не мешает, пока не появится пользователь из ЕС или платёжная система с требованиями. Вопрос NDA разобран отдельно в материале договор NDA для IT-бизнеса. Отдельно стоит проверить лицензии открытого кода, которые попадают в продукт через библиотеки и фреймворки: некоторые лицензии (copyleft) требуют раскрытия собственного кода при распространении продукта, и это часто выясняется уже на этапе due diligence, когда менять архитектуру поздно и дорого.
Это та часть, где большинство статей в интернете не обновлялось годами. С вступлением в силу нового закона об авторском праве имущественные права на служебное произведение по общему правилу переходят к работодателю или заказчику с момента создания, если иное не установлено договором. Но legacy-код, написанный до изменения правил, подчинён старому режиму, а иностранный покупатель проверяет не презумпции закона, а подписанные документы по каждому, кто касался кода. Полный разбор этой темы, вместе с практическими выводами для ФЛП-подрядчиков и модели Дія.City, — на странице юрист для IT-компании. Отдельная ситуация — выход сооснователя или ключевого разработчика из команды: без письменной фиксации прав на тот код, который он успел написать, компания остаётся с юридической дырой в цепочке прав, которую due diligence обнаруживает мгновенно. Аудит прав на продукт — проверка того, кто и на каком основании писал каждый модуль, — типично предшествует любой серьёзной сделке, и лучше провести его заранее, а не в сжатые сроки под давлением покупателя.
Резидентство Дія.City даёт отдельный налоговый и трудовой режим, в том числе гиг-контракты, которые снимают риск переквалификации отношений с ФЛП-подрядчиками в трудовые. Переход оправдан не всегда — решение зависит от состава команды, распределения дохода и того, планируете ли вы выводить прибыль или реинвестировать. Оба сценария стоит посчитать на конкретных цифрах компании, а не ориентироваться на общие ставки. Подробнее — на странице Дія.City и в материале про налогового юриста.
Большинство украинских IT-компаний работают с разработчиками через ФЛП на упрощённой системе — это удобно и экономично, но юридически несёт риск: если признаки отношений фактически трудовые (постоянный рабочий график, подчинение, отсутствие других заказчиков у подрядчика), налоговая или трудовая инспекция может переквалифицировать договор в трудовой задним числом, с доначислением налогов и сборов. Договор с ФЛП-подрядчиком, который просто скопирован из интернета и не учитывает эту разницу, — один из самых распространённых пробелов, который проверяют и инвесторы, и контролирующие органы. Формат гиг-контракта в рамках Дія.City снимает этот риск системно, но подходит не каждой компании — решение стоит принимать с учётом состава команды.
Договор с заказчиком из ЕС или США обычно содержит условия, которых нет в украинских шаблонах: выбор применимого права, порядок разрешения споров (суд или международный арбитраж, и в какой стране), ограничение ответственности в конкретной валюте, условия о форс-мажоре, которые по-разному трактуются в разных юрисдикциях. Отдельно стоит вопрос оплаты: проходят ли средства через ФЛП напрямую, через компанию-нерезидента, нужен ли escrow-счёт для крупных траншей. Банки и платёжные системы обращают внимание именно на эти детали, когда запрашивают «экономическую суть операции», — и договор, составленный без учёта этого, часто становится причиной задержки платежа, а не сама операция.
Если среди пользователей продукта или сотрудников заказчика есть люди из ЕС, применяется GDPR независимо от того, где зарегистрирована компания. Это означает правовые основания обработки данных, реестр операций, договоры с процессорами и Privacy Policy, которая описывает то, что компания делает на самом деле, а не текст, скопированный с чужого сайта. Отдельно стоит учесть передачу данных за пределы ЕС — она требует дополнительного правового механизма (например, стандартных договорных оговорок), а не только согласия пользователя. Компании, которые просто скопировали Privacy Policy конкурента, обычно не проходят даже поверхностную проверку, потому что текст описывает процессы, которых у них нет, и умалчивает о тех, которые есть на самом деле. Полный разбор — на странице GDPR для украинского бизнеса.
Пока в компании один продукт с одним источником дохода, простой структуры обычно достаточно. Вопрос структуры группы компаний возникает, когда нужно отделить права на продукт от операционных рисков, разделить несколько направлений бизнеса между юридическими лицами или подготовиться ко входу иностранного инвестора. Сюда же относятся партнёрские соглашения между сооснователями — механизм выхода партнёра, распределение долей, разрешение конфликтов — тема, разобранная подробно на странице корпоративный юрист. Если среди инвесторов или партнёров есть иностранные лица, к этому добавляется вопрос холдинговой структуры — регистрации материнской компании в другой юрисдикции, через которую проходит привлечение инвестиций. Решение о такой структуре принимается до входа инвестора, а не после: перестраивать её задним числом существенно дороже и медленнее.
Самая частая ошибка — не отсутствие договоров, а их несоответствие реальности: шаблон, найденный в интернете несколько лет назад, подписывается с каждым новым клиентом без адаптации под конкретную сделку. Вторая — договор существует, но не подписан обеими сторонами или подписан только в переписке, что усложняет его доказывание в споре. Третья — компания меняет модель работы (например, переходит с аутсорса на продукт), а договорная база остаётся старой, рассчитанной на другую структуру отношений. Четвёртая — решение о структуре бизнеса принимается под давлением конкретной сделки, которая уже горит, а не как часть плановой подготовки, из-за чего оно редко бывает оптимальным.
IT-сектор — не исключение для уголовных производств: обыски случаются из-за налоговых подозрений, жалоб контрагентов или проверки третьих лиц, связанных с компанией опосредованно. Закон прямо запрещает изъятие рабочей техники по общему правилу — следователь по умолчанию должен ограничиться копированием информации, а не забирать серверы. Знать эти правила заранее — и иметь номер, по которому адвокат выедет круглосуточно, — лучше, чем узнавать о них в момент обыска. Полный разбор процедуры — в материале обыск и допрос, а о снятии арестов со счетов — на странице снятие ареста со счёта и имущества.
Продукт уже растёт, а договоры и структура ещё «как-то»? Приведём договорную базу, права на продукт и корпоративную структуру в соответствие с тем, чем бизнес уже стал, — чтобы due diligence, банк или проверка это выдержали.
Написать в Telegram →Стоимость зависит от объёма: количества договоров, наличия внешних контрагентов из ЕС, того, нужна ли структура группы компаний. Ориентир по форматам оплаты — на странице Цены, точный расчёт — после короткого аудита текущего состояния документов. Практически сопровождение начинается с аудита того, что уже есть: какие договоры подписаны, с кем, и какие пробелы самые рискованные именно для вашей модели бизнеса.
IT-юрист ежедневно работает с договорами разработки, правами на продукт, GDPR и моделями налогообложения IT-бизнеса — и видит типичные ошибки в этих документах раньше, чем они становятся проблемой. Юрист общей практики тоже может составить договор, но без специализации чаще пропускает детали, специфичные именно для IT.
Дешевле всего — до первого спорного момента: перед подписанием первого договора с разработчиком или заказчиком. Чаще обращаются позже — когда инвестор или покупатель запрашивает документы, банк блокирует счёт или приходит проверка. Во всех трёх случаях исправлять уже дороже и дольше.
Размер команды меньше влияет на потребность, чем наличие внешних контрагентов. Если команда берёт заказы от клиентов или привлекает подрядчиков — договорные риски возникают так же, как у крупной компании, просто в меньшем масштабе.
Это самый частый запрос, а не исключение. Ретроактивно переоформить прошлое невозможно, но можно провести аудит текущего состояния, закрыть самые рискованные пробелы первыми и построить договорную базу так, чтобы она выдержала проверку или due diligence уже сегодня.
В ITLex это одна команда: адвокатский статус даёт право представлять компанию в уголовном производстве — при обыске, вызове на допрос, аресте счёта, — а не только консультировать по документам. Это особенно ценно, когда проверка приходит именно через пробел в договорах, который раньше никто не закрыл.
Зависит от объёма: количества договоров, наличия внешних контрагентов из ЕС, того, нужна ли структура группы компаний. Форматы оплаты — на странице Цены, индивидуальный расчёт после короткого аудита текущего состояния документов.
И так, и так. Разовые задачи — по фиксированной стоимости. Для компаний, где вопросы возникают регулярно, удобнее ежемесячное сопровождение с оговорённым объёмом часов.
Разница между юристом и адвокатом для IT — подробнее в материале IT-адвокат: кто это. О NDA и договорной работе с разработчиками — в материале договор NDA для IT-бизнеса. Об электронной подписи как рабочем инструменте компании — в материале КЭП для IT-компании.
Опишите коротко — вернёмся с перечнем ближайших шагов.
Опишите коротко — вернёмся с перечнем ближайших шагов. В срочных случаях звоните напрямую, отвечаем круглосуточно.
