Разблокировка сайта игровой тематики на территории Казахстана
Юридическая поддержка ИТ проекта. Что начинает ломаться, когда бизнес растет
Хотел бы затронуть важную тему юридического сопровождения ИТ проектов. Тема важная не только с нашей точки зрения, хотя мы, конечно, не будем делать вид, что юристы оказались здесь совершенно случайно.
Как правило, большинство ИТ проектов начинаются не с юридической структуры, а с продукта, первых пользователей, трафика и попытки понять, есть ли у идеи коммерческая жизнь. Это нормальная логика для старта, потому что сначала нужно проверить идею, собрать команду, запустить сайт, подключить платежи, получить обратную связь от рынка и только потом думать о сложной инфраструктуре вокруг бизнеса.
В целом такой подход можно назвать отчасти правильным. Выбор юридической команды сам по себе отдельный большой вопрос, в котором действительно не стоит торопиться. Но задвигать его в дальний ящик тоже не лучшая стратегия, потому что в какой-то момент этот ящик открывается сам, причем обычно в самый неудобный момент.
Проблема начинается тогда, когда проект уже вырос из стадии эксперимента, но продолжает жить так, будто он все еще небольшой тестовый запуск. Пользователи есть, платежи идут, реклама работает, партнеры обо всем договорились в переписке, документы на сайте когда-то были скопированы у похожего сервиса, а юридическая часть воспринимается как вопрос, который можно закрыть позже, когда появится свободное время или случится что-то действительно серьезное.
Ранее я уже разбирал точечные, но важные вопросы, с которыми могут столкнуться ИТ проекты.
Например, почему некоторые сайты быстрее попадают в зону риска, и что делать, чтобы снизить риск блокировки сайта. Отдельно писал о том, как восстановить доступ к заблокированному сайту, если ограничение доступа уже произошло.
Теперь хотелось бы поговорить шире.
Не только о блокировках, а о юридическом сопровождении ИТ проектов в целом и о том, зачем в команде иногда нужны те самые нудные ребята (всем офисом верим, что мы не нудные), которые задают неудобные вопросы до того, как эти вопросы задаст банк, платежная система, партнер, пользователь или государственный орган.
На практике серьезное обычно случается не внезапно, хотя выглядит именно так.
Юридические проблемы в ИТ проектах редко падают с неба. Чаще они долго копятся внутри самой бизнес модели и становятся видны только в момент внешнего давления. Банк запрашивает документы и просит объяснить экономический смысл операций, платежная система интересуется моделью бизнеса, партнеры начинают спорить о долях и доступах, пользователь требует возврат, подрядчик заявляет права на код или дизайн, регулятор направляет уведомление, а потенциальный инвестор перед сделкой задает простой вопрос, кому на самом деле принадлежат продукт, бренд, домен и база пользователей.
В этот момент выясняется, что проект технически работает, но юридически собран слишком слабо. И проблема не в том, что у него нет какой-то одной бумажки. Проблема в том, что документы, платежи, пользовательская механика, права на продукт, отношения между партнерами и публичные обещания проекта существуют сами по себе и плохо связаны друг с другом.
Юридическая поддержка не сводится к оферте и политике на сайте
Одна из типичных ошибок ИТ команд состоит в том, что юридическая поддержка воспринимается как набор документов, которые нужно однажды подготовить и разместить на сайте. Сделали оферту, добавили политику обработки персональных данных, подписали несколько договоров с подрядчиками, и кажется, что юридическая часть закрыта.
На самом деле для ИТ проекта такой подход слишком поверхностный. Юристу недостаточно просто написать текст пользовательского соглашения, если он не понимает, как именно устроен продукт, кто принимает платежи, какие данные собираются, где находятся пользователи, кто владеет кодом, доменом, брендом и аккаунтами, какие подрядчики участвуют в разработке и продвижении, как работает пользовательская механика и какие обещания проект дает в рекламе.
Формально на сайте может быть оферта, но она не описывает фактическую механику сервиса. Политика персональных данных может существовать, но не отражать реальные процессы сбора, хранения и передачи данных. Договор с разработчиком может подтверждать оплату работ, но не передавать проекту права на результат. Партнеры могут считать, что обо всем договорились, хотя юридически их договоренности не выдерживают даже первого серьезного конфликта.
Поэтому юридическая поддержка ИТ проекта должна отвечать не только на вопрос, есть ли у компании документы. Намного важнее другой вопрос. Выдержит ли вся модель проекта проверку со стороны банка, платежной системы, пользователя, инвестора, партнера или регулятора.
Внутренний конфликт часто опаснее внешней проверки
Отдельная боль для ИТ проектов связана с конфликтами внутри команды. Нередко бывает, что крепкий проект начинает тонуть или вовсе тонет не из-за регулятора, банка или злого конкурента, а из-за внутреннего конфликта между людьми, которые еще вчера вместе строили большое будущее.
Многие основатели ждут угроз извне и опасаются прежде всего проверок, блокировок, претензий пользователей и действий регуляторов. Но на практике одна из самых болезненных проблем часто возникает внутри самой команды. На старте партнеры обычно находятся в конструктивном (воодушевленном) настроении. Один отвечает за продукт, другой за маркетинг, третий за деньги, кто-то помогает связями или операционными вопросами. Пока проект не приносит серьезного дохода, все это может работать на доверии.
Когда появляются выручка, трафик, база пользователей, бренд, код, домены, рекламные кабинеты и платежная инфраструктура, доверия становится недостаточно. Возникают вопросы, которые лучше было решить заранее. Кто принимает ключевые решения, кому принадлежат доли, кто контролирует доступы, что происходит при выходе одного из партнеров, можно ли продать проект без согласия остальных, как делится прибыль, кто несет расходы и кто отвечает за претензии пользователей или контрагентов.
В ИТ проекте контроль над доступами иногда оказывается не менее важным, чем формальное распределение долей. Домен, репозиторий, Telegram канал, рекламный кабинет, база пользователей, аккаунт платежной системы или облачная инфраструктура могут стать реальным рычагом давления, если между партнерами начинается конфликт.
Оформление партнерских отношений не заканчивается подготовкой соглашения. Само соглашение описывает, кто за что отвечает, как принимаются решения, кому принадлежат доли и что происходит при конфликте. Но техническая часть нужна для того, чтобы эти договоренности реально исполнялись. Нужно заранее определить, у кого находятся ключевые доступы, кто контролирует домен, репозиторий, рекламные кабинеты, платежную инфраструктуру и базу пользователей, а также как эти доступы передаются или ограничиваются при выходе одного из партнеров. Иначе можно красиво договориться на бумаге, а потом выяснить, что вся судьба проекта находится в руках человека, который просто первым зарегистрировал нужный аккаунт.
Если договоренности не проговорить и не оформить на старте, позже договариваться будет сложнее, потому что у проекта уже появится стоимость, а вместе с ней появятся и разные взгляды на вклад каждого участника. Обычно именно в этот момент выясняется, что все помнят договоренности немного по-разному, причем каждый почему-то в свою пользу.
Платежная модель должна быть понятна не только команде проекта
На старте платежи часто воспринимаются как технический вопрос. Нужно подключить банк, платежного агрегатора, криптокошелек, подписки, донаты, внутренний баланс или иной способ приема средств. Если деньги проходят, значит все работает.
Но для многих ИТ проектов именно платежная часть становится первой серьезной проблемой. Причем вопросы могут появиться не только в случае нарушения закона, но и тогда, когда модель проекта просто непонятна банку, платежной системе или контрагенту.
Кто является продавцом услуги, за что именно платит пользователь, почему деньги приходят от разных лиц, как оформляются возвраты, что происходит при спорной операции, какие документы можно показать платежной системе, как подтверждается происхождение средств, что делать с пользователем, который не прошел KYC, кто несет риск при ошибке с криптокошельком и как проект объясняет экономический смысл своих операций. Все эти вопросы могут казаться второстепенными, пока платежи проходят без сбоев.
Для проектов в сферах iGaming, skin trading, криптообмена, онлайн развлечений, маркетплейсов и международных платформ такие вопросы могут стать критичными. Когда банк или платежная система останавливает операции, проекту нужно быстро объяснить свою модель, показать документы, подтвердить легальность операций и доказать, что внутренние процессы не собраны на коленке.
Если платежная архитектура, пользовательские условия, порядок возвратов, KYC процедуры, AML политика и распределение рисков не были продуманы заранее, исправлять это в момент блокировки операций намного сложнее. В такой ситуации юридическая проблема быстро становится операционной, потому что проект может продолжать существовать технически, но теряет возможность нормально принимать и обрабатывать платежи.
Налоги тоже лучше не вспоминать в последний момент
С налогами, казалось бы, все и так понятно. Нарушения налогового законодательства стоят дорого, а в отдельных случаях могут закончиться не только доначислениями, пенями и штрафами, но и уголовной ответственностью. Новости периодически напоминают, что это не страшилка из методички для бухгалтеров, а вполне рабочий сценарий.
Санкции здесь вполне конкретные. По НК РФ это могут быть пени по статье 75, штраф за непредставление декларации по статье 119, штраф за неуплату или неполную уплату налога по статье 122. Если история становится совсем грустной, включается уже УК РФ, прежде всего статьи 198, 199, 199.1 и 199.2. Там речь идет не о неприятной переписке с налоговой, а об уголовной ответственности за уклонение от уплаты налогов, неисполнение обязанностей налогового агента и сокрытие имущества от взыскания.
Для ИТ проекта налоговые риски часто появляются не там, где их ждут. Деньги могут идти через разные компании, подрядчиков, самозанятых, иностранных контрагентов, криптовалюту, P2P расчеты, партнерские программы или внутренние балансы. На старте это может выглядеть как удобная операционная схема, но при проверке возникает менее романтичный вопрос. Кто получил доход, за что именно были платежи, какие документы это подтверждают и почему налоговая должна поверить, что все было устроено именно так.
Поэтому налоговая часть должна быть связана с реальной бизнес моделью проекта, а не существовать отдельно в голове бухгалтера или в таблице, которую никто не открывал с прошлого квартала. Иначе можно построить хороший продукт, собрать пользователей, наладить платежи, а потом внезапно узнать, что самая дорогая часть проекта находится не в разработке, а в объяснениях перед налоговым органом.
Персональные данные быстро перестают быть бумажной темой
Почти любой ИТ проект работает с персональными данными, даже если команда не воспринимает себя как крупного оператора данных. Регистрация пользователя, email, телефон, IP адрес, cookies, платежные данные, история операций, документы для KYC, переписка с поддержкой, данные из CRM, аналитика, рассылки и рекламные пиксели уже создают юридически значимую картину обработки данных.
На практике многие проекты ограничиваются тем, что размещают на сайте политику обработки персональных данных и добавляют чекбокс при регистрации. Но сам по себе документ на сайте не решает вопрос, если команда не понимает, какие данные реально собираются, для чего они используются, где хранятся, кому передаются, какие сторонние сервисы подключены, есть ли трансграничная передача, как пользователь дает согласие, как он может его отозвать, как удаляются данные и кто внутри проекта имеет к ним доступ.
Особенно внимательно к этой теме нужно относиться проектам, где есть финансовые операции, KYC, игровые аккаунты, международная аудитория, спорные категории товаров или услуг, а также большое количество подрядчиков и внешних сервисов. В таких случаях персональные данные становятся не просто юридической формальностью, а полноценной частью риск модели проекта.
Обычно эта тема кажется скучной до первой жалобы, проверки или утечки. После этого выясняется, что политика на сайте не соответствует реальной обработке данных, согласия собраны неправильно, подрядчики не оформлены, а внутри команды нет понимания, кто отвечает за хранение, передачу и удаление пользовательской информации.
Для ИТ проекта данные пользователей являются активом, но одновременно они являются и источником ответственности. Чем больше проект растет, тем опаснее относиться к ним как к техническому побочному продукту.
Код, дизайн и бренд должны принадлежать проекту не только по ощущениям
Еще одна частая ошибка ИТ проектов состоит в том, что команда считает оплату подрядчику автоматическим получением всех прав. Разработчик написал код, дизайнер сделал интерфейс, маркетолог подготовил креативы, подрядчик собрал лендинг, копирайтер написал тексты, кто-то настроил бота или внутренний инструмент. Деньги заплатили, значит все принадлежит проекту.
Юридически это не всегда так, как бы сильно этого ни хотелось.
Права на код, дизайн, базу данных, бренд, домен, тексты, изображения, музыку, интерфейс, рекламные материалы и внутренние инструменты нужно правильно оформлять. Это особенно важно, если проект планирует привлекать инвестиции, продавать бизнес, выходить на иностранные рынки или масштабироваться за счет партнеров и подрядчиков.
Самая неприятная ситуация обычно возникает перед сделкой. Инвестор или покупатель спрашивает, кому принадлежат ключевые активы проекта, а команда показывает переписку, счета, устные договоренности и несколько разрозненных файлов. Для основателей это может выглядеть как техническая недоработка, но для инвестора это риск, который влияет на оценку проекта и иногда делает сделку невозможной.
В ИТ бизнесе интеллектуальная собственность часто является главным активом. Если права на нее оформлены плохо, бизнес юридически стоит меньше, чем кажется его основателям.
Рекламные формулировки иногда опаснее самой услуги
ИТ проекты часто недооценивают публичные коммуникации. Сайт, лендинг, рекламные объявления, Telegram канал, блогеры, партнерские материалы, SEO страницы, email рассылки, пуши и тексты в интерфейсе формируют представление о проекте не только у пользователей, но и у банков, платежных систем, конкурентов, регуляторов и судов.
Проект мог быть задуман как нейтральная технологическая платформа, но рекламные формулировки создают ощущение заработка, выигрыша, обхода ограничений, финансовой выгоды или доступа к рискованным товарам и услугам. Маркетолог может написать текст, который хорошо продает, но юридически ухудшает положение проекта. Реклама, конечно, должна продавать, но желательно не продавать бизнес вместе с доказательной базой против него.
Для направлений вроде iGaming, skin trading, крипты, онлайн развлечений, образовательных платформ, финансовых сервисов и проектов с пользовательским контентом это особенно важно. В таких сферах один рекламный заголовок, неудачный блок на лендинге или агрессивное обещание у блогера может создать больше риска, чем весь пользовательский договор.
Поэтому юридическая поддержка ИТ проекта не должна ограничиваться договорами. Иногда нужно смотреть на то, как проект говорит о себе публично, какие слова использует в рекламе, какие ожидания формирует у пользователей и как все это будет выглядеть, если текст увидит не лояльный клиент, а банк, конкурент, регулятор или суд.
Блокировка сайта как один из симптомов
Блокировка сайта часто воспринимается как внезапная внешняя атака. Проект работал, а потом доступ ограничили, и команда начинает искать причину, готовить обращения, выяснять инициатора ограничения и пытаться вернуть сайт в нормальный доступ.
Но блокировка не всегда появляется из воздуха. Иногда она становится следствием более ранних ошибок в публичных формулировках, рекламной модели, пользовательском контенте, описании товаров или услуг, правилах сервиса, модерации, документах или самой механике проекта.
Конечно, ограничение доступа можно оспаривать, и в ряде случаев сайт действительно удается вернуть в нормальный режим работы. Но для бизнеса правильнее не только тушить пожар, а понимать, почему проект вообще оказался в зоне риска.
В этом смысле блокировка сайта является не единственной и не главной юридической проблемой ИТ проекта, а одним из возможных симптомов того, что юридическая и продуктовая архитектура давно требовала внимания. Если заранее анализировать механику сервиса, документы, пользовательские правила, рекламные формулировки и порядок работы с жалобами, часть проблем можно заметить до того, как они превратятся в ограничение доступа.
Разовая консультация помогает точечно, но не заменяет сопровождение
Разовая консультация может быть полезна, когда у проекта есть конкретный вопрос. Например, как ответить на запрос, можно ли использовать определенную формулировку, какой договор подписать с подрядчиком, как оформить возврат или что делать с жалобой пользователя.
Но у растущего ИТ проекта проблемы редко существуют отдельно друг от друга. Платежная модель связана с офертой, оферта связана с пользовательской механикой, пользовательская механика связана с рекламой, реклама связана с регуляторными рисками, персональные данные связаны с KYC, аналитикой и подрядчиками, а партнерское соглашение связано с правами на код, бренд, домен и выручку.
Если смотреть на каждый вопрос изолированно, можно не увидеть общую конструкцию. Юридическое сопровождение отличается от разовой консультации тем, что юрист видит проект в динамике и понимает, как меняется модель, какие появляются новые продукты, какие подключаются платежные решения, какие рынки открываются, какие подрядчики входят в процесс и какие риски возникают при росте.
Для ИТ проекта это особенно важно, потому что бизнес может меняться быстрее, чем документы. Сегодня сервис работает как небольшая платформа, завтра добавляет внутренний баланс, потом подключает криптоплатежи, запускает реферальную программу, выходит в другую юрисдикцию и привлекает блогеров. Через несколько месяцев это уже совсем другая модель риска, хотя документы на сайте могут оставаться прежними.
Если юридическая часть не обновляется вместе с продуктом, она быстро устаревает и перестает выполнять свою основную функцию.
Юрист не должен мешать продукту развиваться
У многих основателей есть понятный страх, что юристы начнут все запрещать, усложнять и тормозить запуск. Иногда этот страх оправдан, потому что плохая юридическая поддержка действительно может сводиться к формальным замечаниям и запретам, которые не помогают бизнесу принимать решения.
Юристы не делают ИТ проект богаче сами по себе. Они не приводят трафик, не закрывают продажи, не пишут код и не улучшают продукт, поэтому ждать от юридической поддержки прямого роста выручки было бы странно.
Но хорошая юридическая работа помогает проекту не потерять деньги там, где их обычно теряют незаметно и больно. В споре между партнерами, при блокировке платежей, при претензиях пользователей, при конфликте с подрядчиком, при проверке, при блокировке сайта или перед сделкой с инвестором. Иногда юристы не создают прибыль напрямую, но сохраняют бизнесу активы, доступы, платежи, репутацию и возможность продолжать работать.
Нормальная юридическая поддержка ИТ проекта должна работать именно так. Ее задача не в том, чтобы остановить продукт, а в том, чтобы найти рабочую конструкцию с приемлемым уровнем риска. Хороший юрист не просто говорит, что так делать нельзя, а объясняет, где именно находится слабое место, какие есть варианты, что можно изменить в механике, документах, платежах, рекламе или пользовательском пути.
Бизнесу нужно двигаться, и юрист должен это понимать. Но он также должен видеть точки, где быстрый запуск сегодня может превратиться в дорогой конфликт завтра. В этом смысле юридическая поддержка является не тормозом, а частью нормальной архитектуры проекта, такой же важной, как техническая безопасность, финансовый учет или продуктовая аналитика.
При этом важно, чтобы юридическая команда была не внешним отделом занудства, который появляется только с правками красным цветом, а своими ребятами, которым можно нормально рассказать о проблемах проекта.
За игрой в CS, в кальянке, в кафе или в офисе, место уже вторично. Главное, чтобы юристы подходили проекту по духу, понимали его бизнес модель и не делали вид, что ИТ сервис можно сопровождать так же, как аренду склада.
Юридическая поддержка нужна не для того, чтобы обложить проект документами. Ее задача в том, чтобы бизнес модель выдерживала вопросы извне. От пользователя, партнера, банка, платежной системы, инвестора и регулятора. Для ИТ проекта это не бюрократия, а часть нормальной конструкции бизнеса, которая становится особенно важной в тот момент, когда проект перестает быть маленьким экспериментом и начинает стоить денег.
Мы в Reasons сопровождаем ИТ проекты, игровые и околоигровые сервисы, skin trading и lootbox проекты, криптосервисы и онлайн платформы. Помогаем выстроить юридическую конструкцию проекта, проверить платежную и пользовательскую модель, оформить отношения между партнерами и снизить риск блокировок, претензий и конфликтов.
Как правило, большинство ИТ проектов начинаются не с юридической структуры, а с продукта, первых пользователей, трафика и попытки понять, есть ли у идеи коммерческая жизнь. Это нормальная логика для старта, потому что сначала нужно проверить идею, собрать команду, запустить сайт, подключить платежи, получить обратную связь от рынка и только потом думать о сложной инфраструктуре вокруг бизнеса.
В целом такой подход можно назвать отчасти правильным. Выбор юридической команды сам по себе отдельный большой вопрос, в котором действительно не стоит торопиться. Но задвигать его в дальний ящик тоже не лучшая стратегия, потому что в какой-то момент этот ящик открывается сам, причем обычно в самый неудобный момент.
Проблема начинается тогда, когда проект уже вырос из стадии эксперимента, но продолжает жить так, будто он все еще небольшой тестовый запуск. Пользователи есть, платежи идут, реклама работает, партнеры обо всем договорились в переписке, документы на сайте когда-то были скопированы у похожего сервиса, а юридическая часть воспринимается как вопрос, который можно закрыть позже, когда появится свободное время или случится что-то действительно серьезное.
Ранее я уже разбирал точечные, но важные вопросы, с которыми могут столкнуться ИТ проекты.
Например, почему некоторые сайты быстрее попадают в зону риска, и что делать, чтобы снизить риск блокировки сайта. Отдельно писал о том, как восстановить доступ к заблокированному сайту, если ограничение доступа уже произошло.
Теперь хотелось бы поговорить шире.
Не только о блокировках, а о юридическом сопровождении ИТ проектов в целом и о том, зачем в команде иногда нужны те самые нудные ребята (всем офисом верим, что мы не нудные), которые задают неудобные вопросы до того, как эти вопросы задаст банк, платежная система, партнер, пользователь или государственный орган.
На практике серьезное обычно случается не внезапно, хотя выглядит именно так.
Юридические проблемы в ИТ проектах редко падают с неба. Чаще они долго копятся внутри самой бизнес модели и становятся видны только в момент внешнего давления. Банк запрашивает документы и просит объяснить экономический смысл операций, платежная система интересуется моделью бизнеса, партнеры начинают спорить о долях и доступах, пользователь требует возврат, подрядчик заявляет права на код или дизайн, регулятор направляет уведомление, а потенциальный инвестор перед сделкой задает простой вопрос, кому на самом деле принадлежат продукт, бренд, домен и база пользователей.
В этот момент выясняется, что проект технически работает, но юридически собран слишком слабо. И проблема не в том, что у него нет какой-то одной бумажки. Проблема в том, что документы, платежи, пользовательская механика, права на продукт, отношения между партнерами и публичные обещания проекта существуют сами по себе и плохо связаны друг с другом.
Юридическая поддержка не сводится к оферте и политике на сайте
Одна из типичных ошибок ИТ команд состоит в том, что юридическая поддержка воспринимается как набор документов, которые нужно однажды подготовить и разместить на сайте. Сделали оферту, добавили политику обработки персональных данных, подписали несколько договоров с подрядчиками, и кажется, что юридическая часть закрыта.
На самом деле для ИТ проекта такой подход слишком поверхностный. Юристу недостаточно просто написать текст пользовательского соглашения, если он не понимает, как именно устроен продукт, кто принимает платежи, какие данные собираются, где находятся пользователи, кто владеет кодом, доменом, брендом и аккаунтами, какие подрядчики участвуют в разработке и продвижении, как работает пользовательская механика и какие обещания проект дает в рекламе.
Формально на сайте может быть оферта, но она не описывает фактическую механику сервиса. Политика персональных данных может существовать, но не отражать реальные процессы сбора, хранения и передачи данных. Договор с разработчиком может подтверждать оплату работ, но не передавать проекту права на результат. Партнеры могут считать, что обо всем договорились, хотя юридически их договоренности не выдерживают даже первого серьезного конфликта.
Поэтому юридическая поддержка ИТ проекта должна отвечать не только на вопрос, есть ли у компании документы. Намного важнее другой вопрос. Выдержит ли вся модель проекта проверку со стороны банка, платежной системы, пользователя, инвестора, партнера или регулятора.
Внутренний конфликт часто опаснее внешней проверки
Отдельная боль для ИТ проектов связана с конфликтами внутри команды. Нередко бывает, что крепкий проект начинает тонуть или вовсе тонет не из-за регулятора, банка или злого конкурента, а из-за внутреннего конфликта между людьми, которые еще вчера вместе строили большое будущее.
Многие основатели ждут угроз извне и опасаются прежде всего проверок, блокировок, претензий пользователей и действий регуляторов. Но на практике одна из самых болезненных проблем часто возникает внутри самой команды. На старте партнеры обычно находятся в конструктивном (воодушевленном) настроении. Один отвечает за продукт, другой за маркетинг, третий за деньги, кто-то помогает связями или операционными вопросами. Пока проект не приносит серьезного дохода, все это может работать на доверии.
Когда появляются выручка, трафик, база пользователей, бренд, код, домены, рекламные кабинеты и платежная инфраструктура, доверия становится недостаточно. Возникают вопросы, которые лучше было решить заранее. Кто принимает ключевые решения, кому принадлежат доли, кто контролирует доступы, что происходит при выходе одного из партнеров, можно ли продать проект без согласия остальных, как делится прибыль, кто несет расходы и кто отвечает за претензии пользователей или контрагентов.
В ИТ проекте контроль над доступами иногда оказывается не менее важным, чем формальное распределение долей. Домен, репозиторий, Telegram канал, рекламный кабинет, база пользователей, аккаунт платежной системы или облачная инфраструктура могут стать реальным рычагом давления, если между партнерами начинается конфликт.
Оформление партнерских отношений не заканчивается подготовкой соглашения. Само соглашение описывает, кто за что отвечает, как принимаются решения, кому принадлежат доли и что происходит при конфликте. Но техническая часть нужна для того, чтобы эти договоренности реально исполнялись. Нужно заранее определить, у кого находятся ключевые доступы, кто контролирует домен, репозиторий, рекламные кабинеты, платежную инфраструктуру и базу пользователей, а также как эти доступы передаются или ограничиваются при выходе одного из партнеров. Иначе можно красиво договориться на бумаге, а потом выяснить, что вся судьба проекта находится в руках человека, который просто первым зарегистрировал нужный аккаунт.
Если договоренности не проговорить и не оформить на старте, позже договариваться будет сложнее, потому что у проекта уже появится стоимость, а вместе с ней появятся и разные взгляды на вклад каждого участника. Обычно именно в этот момент выясняется, что все помнят договоренности немного по-разному, причем каждый почему-то в свою пользу.
Платежная модель должна быть понятна не только команде проекта
На старте платежи часто воспринимаются как технический вопрос. Нужно подключить банк, платежного агрегатора, криптокошелек, подписки, донаты, внутренний баланс или иной способ приема средств. Если деньги проходят, значит все работает.
Но для многих ИТ проектов именно платежная часть становится первой серьезной проблемой. Причем вопросы могут появиться не только в случае нарушения закона, но и тогда, когда модель проекта просто непонятна банку, платежной системе или контрагенту.
Кто является продавцом услуги, за что именно платит пользователь, почему деньги приходят от разных лиц, как оформляются возвраты, что происходит при спорной операции, какие документы можно показать платежной системе, как подтверждается происхождение средств, что делать с пользователем, который не прошел KYC, кто несет риск при ошибке с криптокошельком и как проект объясняет экономический смысл своих операций. Все эти вопросы могут казаться второстепенными, пока платежи проходят без сбоев.
Для проектов в сферах iGaming, skin trading, криптообмена, онлайн развлечений, маркетплейсов и международных платформ такие вопросы могут стать критичными. Когда банк или платежная система останавливает операции, проекту нужно быстро объяснить свою модель, показать документы, подтвердить легальность операций и доказать, что внутренние процессы не собраны на коленке.
Если платежная архитектура, пользовательские условия, порядок возвратов, KYC процедуры, AML политика и распределение рисков не были продуманы заранее, исправлять это в момент блокировки операций намного сложнее. В такой ситуации юридическая проблема быстро становится операционной, потому что проект может продолжать существовать технически, но теряет возможность нормально принимать и обрабатывать платежи.
Налоги тоже лучше не вспоминать в последний момент
С налогами, казалось бы, все и так понятно. Нарушения налогового законодательства стоят дорого, а в отдельных случаях могут закончиться не только доначислениями, пенями и штрафами, но и уголовной ответственностью. Новости периодически напоминают, что это не страшилка из методички для бухгалтеров, а вполне рабочий сценарий.
Санкции здесь вполне конкретные. По НК РФ это могут быть пени по статье 75, штраф за непредставление декларации по статье 119, штраф за неуплату или неполную уплату налога по статье 122. Если история становится совсем грустной, включается уже УК РФ, прежде всего статьи 198, 199, 199.1 и 199.2. Там речь идет не о неприятной переписке с налоговой, а об уголовной ответственности за уклонение от уплаты налогов, неисполнение обязанностей налогового агента и сокрытие имущества от взыскания.
Для ИТ проекта налоговые риски часто появляются не там, где их ждут. Деньги могут идти через разные компании, подрядчиков, самозанятых, иностранных контрагентов, криптовалюту, P2P расчеты, партнерские программы или внутренние балансы. На старте это может выглядеть как удобная операционная схема, но при проверке возникает менее романтичный вопрос. Кто получил доход, за что именно были платежи, какие документы это подтверждают и почему налоговая должна поверить, что все было устроено именно так.
Поэтому налоговая часть должна быть связана с реальной бизнес моделью проекта, а не существовать отдельно в голове бухгалтера или в таблице, которую никто не открывал с прошлого квартала. Иначе можно построить хороший продукт, собрать пользователей, наладить платежи, а потом внезапно узнать, что самая дорогая часть проекта находится не в разработке, а в объяснениях перед налоговым органом.
Персональные данные быстро перестают быть бумажной темой
Почти любой ИТ проект работает с персональными данными, даже если команда не воспринимает себя как крупного оператора данных. Регистрация пользователя, email, телефон, IP адрес, cookies, платежные данные, история операций, документы для KYC, переписка с поддержкой, данные из CRM, аналитика, рассылки и рекламные пиксели уже создают юридически значимую картину обработки данных.
На практике многие проекты ограничиваются тем, что размещают на сайте политику обработки персональных данных и добавляют чекбокс при регистрации. Но сам по себе документ на сайте не решает вопрос, если команда не понимает, какие данные реально собираются, для чего они используются, где хранятся, кому передаются, какие сторонние сервисы подключены, есть ли трансграничная передача, как пользователь дает согласие, как он может его отозвать, как удаляются данные и кто внутри проекта имеет к ним доступ.
Особенно внимательно к этой теме нужно относиться проектам, где есть финансовые операции, KYC, игровые аккаунты, международная аудитория, спорные категории товаров или услуг, а также большое количество подрядчиков и внешних сервисов. В таких случаях персональные данные становятся не просто юридической формальностью, а полноценной частью риск модели проекта.
Обычно эта тема кажется скучной до первой жалобы, проверки или утечки. После этого выясняется, что политика на сайте не соответствует реальной обработке данных, согласия собраны неправильно, подрядчики не оформлены, а внутри команды нет понимания, кто отвечает за хранение, передачу и удаление пользовательской информации.
Для ИТ проекта данные пользователей являются активом, но одновременно они являются и источником ответственности. Чем больше проект растет, тем опаснее относиться к ним как к техническому побочному продукту.
Код, дизайн и бренд должны принадлежать проекту не только по ощущениям
Еще одна частая ошибка ИТ проектов состоит в том, что команда считает оплату подрядчику автоматическим получением всех прав. Разработчик написал код, дизайнер сделал интерфейс, маркетолог подготовил креативы, подрядчик собрал лендинг, копирайтер написал тексты, кто-то настроил бота или внутренний инструмент. Деньги заплатили, значит все принадлежит проекту.
Юридически это не всегда так, как бы сильно этого ни хотелось.
Права на код, дизайн, базу данных, бренд, домен, тексты, изображения, музыку, интерфейс, рекламные материалы и внутренние инструменты нужно правильно оформлять. Это особенно важно, если проект планирует привлекать инвестиции, продавать бизнес, выходить на иностранные рынки или масштабироваться за счет партнеров и подрядчиков.
Самая неприятная ситуация обычно возникает перед сделкой. Инвестор или покупатель спрашивает, кому принадлежат ключевые активы проекта, а команда показывает переписку, счета, устные договоренности и несколько разрозненных файлов. Для основателей это может выглядеть как техническая недоработка, но для инвестора это риск, который влияет на оценку проекта и иногда делает сделку невозможной.
В ИТ бизнесе интеллектуальная собственность часто является главным активом. Если права на нее оформлены плохо, бизнес юридически стоит меньше, чем кажется его основателям.
Рекламные формулировки иногда опаснее самой услуги
ИТ проекты часто недооценивают публичные коммуникации. Сайт, лендинг, рекламные объявления, Telegram канал, блогеры, партнерские материалы, SEO страницы, email рассылки, пуши и тексты в интерфейсе формируют представление о проекте не только у пользователей, но и у банков, платежных систем, конкурентов, регуляторов и судов.
Проект мог быть задуман как нейтральная технологическая платформа, но рекламные формулировки создают ощущение заработка, выигрыша, обхода ограничений, финансовой выгоды или доступа к рискованным товарам и услугам. Маркетолог может написать текст, который хорошо продает, но юридически ухудшает положение проекта. Реклама, конечно, должна продавать, но желательно не продавать бизнес вместе с доказательной базой против него.
Для направлений вроде iGaming, skin trading, крипты, онлайн развлечений, образовательных платформ, финансовых сервисов и проектов с пользовательским контентом это особенно важно. В таких сферах один рекламный заголовок, неудачный блок на лендинге или агрессивное обещание у блогера может создать больше риска, чем весь пользовательский договор.
Поэтому юридическая поддержка ИТ проекта не должна ограничиваться договорами. Иногда нужно смотреть на то, как проект говорит о себе публично, какие слова использует в рекламе, какие ожидания формирует у пользователей и как все это будет выглядеть, если текст увидит не лояльный клиент, а банк, конкурент, регулятор или суд.
Блокировка сайта как один из симптомов
Блокировка сайта часто воспринимается как внезапная внешняя атака. Проект работал, а потом доступ ограничили, и команда начинает искать причину, готовить обращения, выяснять инициатора ограничения и пытаться вернуть сайт в нормальный доступ.
Но блокировка не всегда появляется из воздуха. Иногда она становится следствием более ранних ошибок в публичных формулировках, рекламной модели, пользовательском контенте, описании товаров или услуг, правилах сервиса, модерации, документах или самой механике проекта.
Конечно, ограничение доступа можно оспаривать, и в ряде случаев сайт действительно удается вернуть в нормальный режим работы. Но для бизнеса правильнее не только тушить пожар, а понимать, почему проект вообще оказался в зоне риска.
В этом смысле блокировка сайта является не единственной и не главной юридической проблемой ИТ проекта, а одним из возможных симптомов того, что юридическая и продуктовая архитектура давно требовала внимания. Если заранее анализировать механику сервиса, документы, пользовательские правила, рекламные формулировки и порядок работы с жалобами, часть проблем можно заметить до того, как они превратятся в ограничение доступа.
Разовая консультация помогает точечно, но не заменяет сопровождение
Разовая консультация может быть полезна, когда у проекта есть конкретный вопрос. Например, как ответить на запрос, можно ли использовать определенную формулировку, какой договор подписать с подрядчиком, как оформить возврат или что делать с жалобой пользователя.
Но у растущего ИТ проекта проблемы редко существуют отдельно друг от друга. Платежная модель связана с офертой, оферта связана с пользовательской механикой, пользовательская механика связана с рекламой, реклама связана с регуляторными рисками, персональные данные связаны с KYC, аналитикой и подрядчиками, а партнерское соглашение связано с правами на код, бренд, домен и выручку.
Если смотреть на каждый вопрос изолированно, можно не увидеть общую конструкцию. Юридическое сопровождение отличается от разовой консультации тем, что юрист видит проект в динамике и понимает, как меняется модель, какие появляются новые продукты, какие подключаются платежные решения, какие рынки открываются, какие подрядчики входят в процесс и какие риски возникают при росте.
Для ИТ проекта это особенно важно, потому что бизнес может меняться быстрее, чем документы. Сегодня сервис работает как небольшая платформа, завтра добавляет внутренний баланс, потом подключает криптоплатежи, запускает реферальную программу, выходит в другую юрисдикцию и привлекает блогеров. Через несколько месяцев это уже совсем другая модель риска, хотя документы на сайте могут оставаться прежними.
Если юридическая часть не обновляется вместе с продуктом, она быстро устаревает и перестает выполнять свою основную функцию.
Юрист не должен мешать продукту развиваться
У многих основателей есть понятный страх, что юристы начнут все запрещать, усложнять и тормозить запуск. Иногда этот страх оправдан, потому что плохая юридическая поддержка действительно может сводиться к формальным замечаниям и запретам, которые не помогают бизнесу принимать решения.
Юристы не делают ИТ проект богаче сами по себе. Они не приводят трафик, не закрывают продажи, не пишут код и не улучшают продукт, поэтому ждать от юридической поддержки прямого роста выручки было бы странно.
Но хорошая юридическая работа помогает проекту не потерять деньги там, где их обычно теряют незаметно и больно. В споре между партнерами, при блокировке платежей, при претензиях пользователей, при конфликте с подрядчиком, при проверке, при блокировке сайта или перед сделкой с инвестором. Иногда юристы не создают прибыль напрямую, но сохраняют бизнесу активы, доступы, платежи, репутацию и возможность продолжать работать.
Нормальная юридическая поддержка ИТ проекта должна работать именно так. Ее задача не в том, чтобы остановить продукт, а в том, чтобы найти рабочую конструкцию с приемлемым уровнем риска. Хороший юрист не просто говорит, что так делать нельзя, а объясняет, где именно находится слабое место, какие есть варианты, что можно изменить в механике, документах, платежах, рекламе или пользовательском пути.
Бизнесу нужно двигаться, и юрист должен это понимать. Но он также должен видеть точки, где быстрый запуск сегодня может превратиться в дорогой конфликт завтра. В этом смысле юридическая поддержка является не тормозом, а частью нормальной архитектуры проекта, такой же важной, как техническая безопасность, финансовый учет или продуктовая аналитика.
При этом важно, чтобы юридическая команда была не внешним отделом занудства, который появляется только с правками красным цветом, а своими ребятами, которым можно нормально рассказать о проблемах проекта.
За игрой в CS, в кальянке, в кафе или в офисе, место уже вторично. Главное, чтобы юристы подходили проекту по духу, понимали его бизнес модель и не делали вид, что ИТ сервис можно сопровождать так же, как аренду склада.
Юридическая поддержка нужна не для того, чтобы обложить проект документами. Ее задача в том, чтобы бизнес модель выдерживала вопросы извне. От пользователя, партнера, банка, платежной системы, инвестора и регулятора. Для ИТ проекта это не бюрократия, а часть нормальной конструкции бизнеса, которая становится особенно важной в тот момент, когда проект перестает быть маленьким экспериментом и начинает стоить денег.
Мы в Reasons сопровождаем ИТ проекты, игровые и околоигровые сервисы, skin trading и lootbox проекты, криптосервисы и онлайн платформы. Помогаем выстроить юридическую конструкцию проекта, проверить платежную и пользовательскую модель, оформить отношения между партнерами и снизить риск блокировок, претензий и конфликтов.