Когда разработчик уходит вместе с ИИ-продуктом и патент не спасает бизнес
На этапе создания ИИ-продукта важно определить границы авторских прав — зачастую, чем больше участников вносят свои ноу-хау, тем сложнее потом масштабироваться

Более 10 лет работает с цифровыми активами, контентом, правами и рисками их коммерциализации.
Американская технологическая компания подала в суд на своего бывшего технического директора и его партнера — автора контента с собственной аудиторией.
По версии истца, бывший сотрудник участвовал в создании запатентованных ИИ-технологий, а затем начал развивать конкурирующий сервис. Новый продукт также позиционировался как персональный ИИ-помощник с долговременной памятью, который лучше понимает пользователя по мере общения.
Компания утверждает, что бывший технический директор намеревался переводить пользователей в новый проект и применять там технологии, принадлежащие работодателю.
Суд пока не установил обоснованность этих обвинений. Но сам спор показывает одну из главных проблем ИИ-бизнеса: оформить права на разработку — еще не значит получить над ней реальный контроль.
Соавтор технологии не всегда владеет ею
Бывший технический директор действительно указан среди авторов патентов, ставших предметом спора. Правообладателем при этом значится компания.
Это принципиально разные статусы.
Разработчик может создать техническое решение и быть указан его автором, но право на коммерческое использование разработки может принадлежать работодателю. Если исключительные права переданы компании, авторство само по себе не дает разработчику права забрать технологию и использовать ее в новом бизнесе.
Такая логика существует не только в США. Российское право также разделяет автора служебного результата и владельца исключительного права на него.
Но компании часто впадают в другую крайность. Они считают, что достаточно включить в договор фразу «все созданное работником принадлежит работодателю» — и продукт защищен.На практике это только начало.
Что договор действительно защищает
Договор определяет, кому принадлежат права, и кто может предъявлять требования в случае нарушения. Но он не исключает техническую возможность:
- сохранить исходный код;
- скопировать системные инструкции;
- перенести архитектуру продукта;
- продолжить использовать внутренние аккаунты;
- получить доступ к клиентской базе;
- воспроизвести продукт в новой компании;
- направить пользователей в конкурирующий сервис.
В такой ситуации договор помогает обратиться в суд, но не предотвращает сам конфликт.
Это особенно важно для ИИ-компаний. Их продукт редко состоит только из программного кода. В него могут входить патенты, промпты, базы знаний, модели памяти, пользовательские данные, API-ключи, облачная инфраструктура и накопленная история взаимодействий.
Если компания оформила права только на код, это не означает, что она контролирует весь продукт.
Почему ИИ-продукт сложно «оставить внутри компании»
Обычное программное обеспечение еще можно относительно четко разложить на код, интерфейс и базу данных. С ИИ-продуктами все сложнее.
Значительную часть ценности могут создавать:
- структура системных инструкций;
- логика работы с контекстом;
- способ хранения пользовательской памяти;
- маршрутизация запросов между моделями;
- накопленные базы знаний;
- настройки внешних сервисов;
- история работы с пользователями.
Некоторые из этих элементов можно защитить патентом или авторским правом. Другие целесообразнее охранять как коммерческую тайну. Третьи вообще невозможно контролировать без технического разграничения доступа.
Поэтому спор о том, «кому принадлежит бот», часто поставлен неправильно. Нужно разбирать, из каких элементов состоит продукт, кто их создал, кому переданы права и кто фактически может ими распоряжаться.
Патент не заменяет управление
Патент дает компании право запрещать использование охраняемой технологии и требовать компенсации. Но он не блокирует доступ к репозиторию, не отзывает API-ключи и не сообщает, что бывший сотрудник подключил к инфраструктуре новую аудиторию.
То же самое относится к трудовому договору и соглашению о конфиденциальности.
Документы создают юридическое основание для защиты. Но если внутри компании отсутствует технический контроль, конфликт обнаруживается уже после того, как продукт начал работать в чужих интересах.
И тогда бизнесу приходится не предотвращать нарушение, а доказывать его:
- восстанавливать историю разработки;
- определять происхождение спорных компонентов;
- сопоставлять продукты;
- анализировать журналы доступа;
- считать расходы;
- выяснять, какие пользователи и данные были затронуты.
Это долго, дорого и почти всегда происходит в тот момент, когда технология уже используется за пределами компании.
Где компании ошибаются
Главная ошибка — воспринимать интеллектуальную собственность как комплект документов.
Компания регистрирует патент, подписывает договоры с разработчиками и считает задачу закрытой. При этом права на отдельные элементы продукта могут оставаться неоформленными, доступы — неконтролируемыми, а ключевые знания — сосредоточенными у одного человека.
Формально компания владеет активом. Фактически активом управляет сотрудник, который знает, как продукт устроен, где хранится код, какие сервисы подключены и как запустить систему без участия остальных.
Пока отношения хорошие, это выглядит как доверие и скорость работы. После конфликта выясняется, что бизнес построен вокруг одного человека, а не вокруг управляемой системы.
Что нужно сделать до ухода разработчика
Компания должна заранее определить:
- Из каких элементов состоит ИИ-продукт.
- Кто создал каждый из этих элементов.
- Кому принадлежат права на код, патенты, базы данных, инструкции и интерфейсы.
- Какие элементы охраняются как коммерческая тайна.
- Кто имеет доступ к репозиториям, ключам и облачной инфраструктуре.
- Можно ли запустить продукт без согласования с компанией.
- Что произойдет с доступами сотрудника при смене роли или увольнении.
- Может ли компания доказать происхождение каждой версии продукта
Если на эти вопросы нет документированных ответов, компания не контролирует ИИ-актив. Она просто рассчитывает на добросовестность команды.
Главный вывод
Соавтор технологии не обязательно является ее правообладателем. Но и правообладатель не обязательно контролирует технологию фактически.
Патент позволяет защищать разработку в суде. Договор позволяет предъявлять требования нарушителю. Однако ни патент, ни договор сами по себе не мешают сотруднику сохранить код, перенести архитектуру или использовать полученные знания в другом проекте.
Если компания начинает выяснять, кому принадлежит ИИ-продукт, только после ухода ключевого разработчика, она уже опоздала.
Юридически актив может принадлежать компании. Но фактически управлять им будет тот, у кого остались знания, доступы и техническая возможность запустить продукт заново.
Рекомендации партнеров:
Все новости:
Публикация компании
Профиль
Контакты
