Юридическое сопровождение IT-проектов. Что начинает ломаться, когда бизнес растет

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

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

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

Оферта может описывать одну модель расчетов, хотя деньги фактически принимает другая компания. Политика обработки персональных данных может не учитывать подключенную аналитику, CRM или KYC-сервис. Разработчику заплатили за код, но права на него нормально не передали. Пользовательские возвраты обрабатываются совсем не так, как написано в правилах сервиса.

Поэтому юристу для IT-компании недостаточно просто получить список документов, которые нужно подготовить.

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

Документы должны описывать реальную модель проекта, а не параллельную юридическую вселенную, существующую исключительно для галочки.

Растущий IT-проект может получить проблемы не только от Роскомнадзора, налоговой или платежной системы. Иногда значительно эффективнее бизнес способны остановить его собственные основатели.

На старте отношения между партнерами часто строятся на доверии. Один отвечает за продукт, другой за маркетинг, третий занимается финансами. Пока стоимость бизнеса невелика, такой подход действительно может работать.

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

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

Для IT-компании важно договориться не только о процентах.

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

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

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

На этапе запуска прием платежей часто воспринимается как техническая задача. Нужно подключить эквайринг, платежного агрегатора, криптовалюту, подписки или внутренний баланс.

Если деньги проходят, кажется, что система работает.

Но у банка и платежной системы может быть свое мнение.

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

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

Особенно чувствительны к платежной архитектуре маркетплейсы, международные платформы, игровые сервисы, iGaming, skin trading и проекты с цифровыми активами.

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

Когда платежная система уже остановила операции, срочно придумывать эту историю значительно сложнее.

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

У IT-проектов налоговые риски часто возникают не из-за какой-то особенно изощренной схемы.

Просто со временем деньги начинают двигаться значительно сложнее, чем на старте.

Платежи принимают разные компании, часть команды работает как ИП или самозанятые, появляются зарубежные подрядчики, криптовалюта, партнерские программы и P2P-расчеты.

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

При налоговой проверке объяснять ее придется уже не друг другу.

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

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

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

Практически любой цифровой сервис работает с персональными данными.

Регистрация пользователя, email, телефон, IP-адрес, cookies, аналитика, CRM, переписка с поддержкой, история операций и документы для KYC формируют достаточно серьезный объем обработки.

Поэтому одной политики на сайте и чекбокса при регистрации обычно недостаточно.

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

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

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

Мы выделяем работу с такими процессами в отдельную практику по защите персональных данных и Data Privacy.

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

Еще одна знакомая ситуация выглядит примерно так.

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

Юридически это работает не всегда так удобно.

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

Для небольшого проекта проблема может годами оставаться незаметной.

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

Если в ответ основатели показывают несколько счетов, переписку в Telegram и объясняют, что «разработчик вроде наш знакомый», это уже не просто техническая недоработка.

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

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

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

Лендинг, рекламные объявления, посты блогеров, SEO-страницы, Telegram-канал, рассылки и даже отдельные фразы внутри интерфейса могут иметь значение для банка, платежной системы, конкурента или регулятора.

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

Маркетолог свою задачу в этот момент, возможно, выполнил прекрасно.

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

Реклама, конечно, должна продавать. Желательно только не продавать проект вместе с доказательной базой.

Особенно внимательно к формулировкам приходится относиться iGaming-проектам, криптосервисам, финансовым продуктам и игровым платформам. Отдельно мы работаем с iGaming-проектами и skin trading и lootbox-сервисами.

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

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

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

Дальше начинается поиск решения суда или ведомства, переписка с Роскомнадзором, анализ контента и попытка восстановить доступ.

Но сама причина блокировки иногда появилась значительно раньше.

Ею могут стать формулировки на сайте, реклама, пользовательский контент, описание товаров или услуг, правила платформы либо сама механика сервиса.

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

Для проектов в чувствительных сферах имеет смысл заранее проверять публичный контент, пользовательскую механику и изменения регулирования. В Reasons Law для этого есть отдельная практика разблокировки сайтов и сервис мониторинга доступа и риска блокировки.

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

Разовая консультация прекрасно работает, когда существует конкретная задача.

Проверить договор, подготовить ответ на претензию, оценить рекламную формулировку или разобраться с возвратом пользователя.

Но по мере роста IT-проекта юридические вопросы начинают пересекаться.

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

Если каждый вопрос рассматривать отдельно, легко получить набор юридически нормальных решений, которые плохо работают вместе.

Именно здесь появляется смысл абонентского юридического сопровождения IT-компании.

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

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

Бизнес изменился несколько раз, а оферта от первого релиза почему-то сама не обновилась. Удивительно, но такое иногда случается.

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

У основателей иногда есть понятное опасение, что появление юристов превратит простой продуктовый процесс в бесконечный поток согласований.

Опасение не совсем беспочвенное. Плохая юридическая поддержка действительно способна работать именно так.

Но задача юриста по IT-праву не заключается в том, чтобы объяснить бизнесу, почему очередную идею реализовывать нельзя.

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

Иногда нужно изменить договор. Иногда пользовательский путь, платежную модель или рекламу. Иногда от конкретной механики действительно придется отказаться, потому что хорошего способа легализовать ее нет.

Но это должно быть осознанное бизнес-решение, а не автоматический ответ «запрещено».

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

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

За игрой в CS, в кальянке, в кафе или в офисе, место уже вторично. Главное, чтобы юристы подходили проекту по духу, понимали его бизнес модель и не делали вид, что ИТ сервис можно сопровождать так же, как аренду склада.

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

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

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

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

Чем позже бизнес занимается этими вопросами, тем интереснее обычно получается задача для юристов.

Для клиента, к сожалению, слово «интереснее» часто означает еще и «дороже».