IT-Para

NDA и права на код при двух работах

Правовые и налоговые формулировки проверены 7 сентября 2026 года.

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

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

Кому принадлежит код

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

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

NDA защищает не всё подряд

Читайте определение конфиденциальной информации, исключения, срок, территорию, ответственность и порядок возврата данных. «Всё, что вы увидели» звучит грозно, но спор всё равно упирается в конкретные сведения и режим их охраны. Это не повод проверять работодателя на прочность: внутренний код, архитектуру, клиентские данные и документы не переносим никуда.

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

Правило чистого контура

  • отдельный ноутбук или хотя бы отдельная зашифрованная учётная запись и ключи;
  • разные Git identities, SSH-ключи, VPN, password vault и облачные профили;
  • никакой пересылки файлов через личный Telegram, почту и общую папку;
  • разные календари и заметки без названий чужих клиентов в общем уведомлении;
  • запрет копирования кода между работодателями, даже если «там такая же функция»;
  • личный проект — в личной организации, на личной технике и вне служебного задания.

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

AI — это ещё один внешний контур

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

  • используйте только разрешённый компанией AI-аккаунт и утверждённые интеграции;
  • не вставляйте ключи, персональные данные, закрытый код и production-логи;
  • не соединяйте одну AI-историю с задачами двух работодателей;
  • проверяйте происхождение предложенного кода и лицензии зависимостей;
  • сохраняйте человеческое решение: кто проверил diff и почему его приняли.

Условия сервиса и корпоративного тарифа важнее общего обещания «мы не обучаемся на ваших данных». Что видит администратор, DLP и прокси, разобрано в материале о видимости AI-промптов.

Кому принадлежат промпт и сгенерированный код

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

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

Open source не отменяет границы

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

Не публикуйте «обезличенный» фрагмент production-конфига, пока не проверили commit history. Секрет, удалённый последним commit, всё ещё живёт в предыдущих.

Что проверить в двух договорах

  1. Точное описание трудовой функции и служебных заданий.
  2. Условия об исключительных правах и вознаграждении.
  3. NDA, коммерческую тайну, конфликт интересов и прямых конкурентов.
  4. Правила использования техники, аккаунтов и внешнего кода.
  5. Обязанность уведомлять о совместительстве для вашей категории.

Выбор между ТК, ГПХ, НПД и ИП — отдельный интент в гайде по оформлению. Права совместителя по ТК — в разборе главы 44.

Если два проекта похожи

Фиксируйте независимость до конфликта: исходную постановку, даты, архитектурные решения, лицензии зависимостей и историю commits. Не делайте скриншоты закрытых систем «для доказательства» — вы создадите новую утечку.

А если это прямые конкуренты с одинаковой задачей — иногда лучший инженерный контроль риска очень простой: не брать второй контракт. Две зарплаты не стоят одного судебного дела.

Код не должен путешествовать

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

Развести контуры