Конфиденциальность в IT-проектах: как не потерять бизнес на утечке данных
Ваш партнер по разработке отделился и запустил игру с подозрительно похожей механикой. Бывший разработчик ушел к конкуренту и тот внезапно выпустил свой продукт с вашими фичами. Инвестор после due diligence передумал инвестировать, зато через полгода вы видите ваши наработки в продукте его портфельной компании. Знакомо?
Нарушения конфиденциальности в ИТ случаются чаще, чем хотелось бы признать. И речь не о масштабных хакерских атаках вроде утечки данных 173 млн пользователей Zynga в 2019 году или о крупных спорах, вроде дела Wargaming против бывших работников из Press Fire Games 2020 года, которое рассматривалось в Беларуси, США и на Кипре. Проблема ближе - партнер, подрядчик или инвестор получает доступ к критичной информации, а потом использует ее против вас. Для стартапа или небольшой геймдев-студии такая история может стать фатальной. Юристы Wolja Digital регулярно сталкиваются с подобными делами. Разберем, почему компании чаще всего проигрывают споры о конфиденциальности, и что можно сделать заранее.
Типичные сценарии утечек
В нашей практике встречаются три главных варианта.
Первый - бывший партнер отделяется и запускает собственный продукт, используя техническую документацию или исходный код от совместного проекта. Как правило, это происходит в стартапах, где отношения между партнерами не урегулированы, нередко все доступы к аккаунтам и репозиториям находятся под контролем одного партнера, для которого не составляет труда при минимальных разногласиях выйти из проекта, забрав все наработки.
Второй - работник или подрядчик сливает информацию конкурентам или начинает использовать наработки для собственного бизнеса. В нашей практике были случаи, например, когда тимлид продавал за крипту всю документацию по проекту конкуренту своего нанимателя, чтобы потом к этому же конкуренту устроиться на работу. Чаще бывают истории, когда тимлид увольняется, забирает с собой внутренние разработки компании, а потом запускает на их базе свой продукт.
Третий, особенно болезненный для стартапов - инвестор под предлогом due diligence выкачивает детали технической реализации, а потом решает не вкладываться, но передает информацию другой команде из своего портфолио.
Почему дела проигрываются
Судебная практика по конфиденциальности жестокая. Чтобы доказать нарушение, нужно подтвердить четыре элемента:
- у нарушителя был доступ к информации,
- существовала юридическая обязанность сохранять конфиденциальность,
- информация действительно была конфиденциальной и коммерчески ценной, и
- ответчик ее использовал для себя или раскрыл третьему.
Звучит логично, но на практике компании часто проваливаются на втором и третьем элементах из-за дыр в документах, а также на четвертом элементе из-за объективного отсутствия доказательств наличия нарушения.
Классические ошибки
Первая ошибка - скачанный из Интернета шаблон NDA с формулировкой "вся информация по проекту является конфиденциальной". Такое соглашение суды обычно не воспринимают, так как очевидно не вся информация является конфиденциальной и подлежащей защите. Вряд ли информация, есть ли в офисе печеньки и кофе, представляет подлежащую защите коммерческую ценность.
Нужны конкретные категории информации, и такая информация должна быть действительно неизвестна третьим лицам, и иметь коммерческую ценность: техническая документация, исходный код, бизнес-модель, маркетинговые данные.
Нередко компании ошибочно преувеличивают ценность информации и могут относить к конфиденциальной информацию, которая понятна и известная специалисту в этой области. К примеру, рекламные настройки при продвижении приложения - если обычный опытный ASO специалист сможет их выставить, то это не конфиденциальная информация.
Вторая история - критичная информация лежит в личном аккаунте одного из партнеров. GitHub, AWS, Figma - неважно. Когда отношения портятся, этот человек просто блокирует доступ остальным, а потом спокойно заявляет, что это его личные наработки. Доказать обратное сложно, что в стартапах осложняется ещё и отсутствием документов.
Третий провал - отсутствие технических средств защиты и контроля доступа к ней. Разграничение доступов, логирование действий, двухфакторная аутентификация.
Во-первых, это обеспечивает первичный уровень защиты: лучше иметь замок на двери, чем оставить ее открытой и наклеить объявление, что заходить нельзя. Во-вторых, предполагается, что конфиденциальную информацию компания должна защищать: если информация настолько ценная, то почему вы сами ее не защищали? Достаточно сложно требовать соблюдения конфиденциальности от работников, если критически важные данные лежат на Яндекс Диске.
В-третьих, из нашей практики крайне важно доказывать наличие доступа к информации, что легче доказать через логи и настройки доступа, что конкретный специалист действительно мог получить информацию и заходил на репозиторий, чтобы с ней ознакомиться. Достаточно часто защитная позиция ответчика, что он в силу своей должностной позиции не имел доступа, к примеру, к документации по проекту, и истец не всегда может доказать обратное, что влечет отказ в иске.
Еще нюанс, который многие не учитывают - способ передачи информации. Если отправили конфиденциальные данные через обычный мессенджер или личную почту, суд может отказать в защите. Логика простая: вы знали о рисках незащищенных каналов, но все равно использовали их, значит сами виноваты в утечке.
Как закрыть дыры
Во-первых, должно быть правильно составленное NDA с конкретным перечнем конфиденциальной информации и прописанными мерами ответственности за нарушение, а также четкие положения о конфиденциальности в договорах с подрядчиками и работниками. При работе с внешними партнерами и подрядчиками дополнительно при передаче документации и информации необходимо фиксировать саму передачу (как, когда и каким способом она передавалась), в наиболее критических случаях - с подписанием актов приема-передачи при обмене данными (даже если это отправка файлов).
Для зрелой компании добавляется внутренний регламент работы с коммерческой тайной, журнал учета лиц, имеющих доступ к конфиденциальной информации, и политика классификации данных. Звучит бюрократично, но без этого доказать в суде факт нарушения практически невозможно. Законодательство требует, чтобы компания сама определила режим коммерческой тайны и приняла меры по ее обеспечению - суды не будут делать это за вас.
По технической части минимум такой: все критичные ресурсы на корпоративных аккаунтах с разграничением прав доступа, логирование действий пользователей (кто, когда и к чему обращался), двухфакторная аутентификация, регулярные бэкапы с контролем целостности.
Если используете GitHub - приватные репозитории с ограничением на клонирование и скачивание. Если храните файлы в облаке - защищенные корпоративные хранилища вроде Google Workspace или Microsoft 365 с правами на уровне компании, а не отдельных пользователей.
Отдельно про инвесторов. Перед тем как показывать техническую документацию, заключайте двустороннее NDA и передавайте информацию частями - только то, что необходимо на текущем этапе переговоров. Полный доступ к исходному коду или детальным техническим спецификациям - только после подписания term sheet или инвестиционного соглашения. И обязательно фиксируйте, что и кому передавалось, каким способом.
Что в итоге
Защита конфиденциальности - это не просто подписание NDA, который скинул друг. Это связка правильных документов, технических мер и осознанной работы с информацией. Большинство проблем можно предотвратить на старте, если потратить несколько дней на выстраивание системы. Судебная практика показывает - компании, у которых все это есть, выигрывают споры. Остальные в лучшем случае договариваются о мировой, в худшем - смотрят, как их идеи реализуют конкуренты.
Если у вас стартап, начните с простого: оформите корпоративные аккаунты для всех критичных сервисов, составьте список конфиденциальной информации и закройте его NDA со всеми, кто имеет доступ. Это базовый уровень защиты, который займет пару дней, но может спасти бизнес.
Опубликовано 09.02.2026