Три слоя собственности: код, данные, модель
Вопрос «кто владеет» нельзя решать одной фразой, потому что в ИИ-проекте собственности три слоя. Первый — код: шлюзы, интеграции, интерфейсы, скрипты загрузки базы знаний. Второй — данные: ваши документы, обучающая выборка, векторная база, промпты, логи диалогов. Третий — модель: веса нейросети, на которой всё работает. У каждого слоя свой правовой режим, и путать их — типичная ошибка договоров.
Базовая формула НЬЮ-ССТ: исключительные права на разработанный код и результаты генерации передаются заказчику; лицензии компонентов экосистемы ВЫШКА Cloud остаются у правообладателя и передаются по лицензии; данные и база знаний — всегда ваши; судьба модели зависит от выбранной архитектуры. Разберём слой за слоем.
Код: договор разработки ПО или НИОКР
Код оформляется классически: договор на разработку ПО (или НИОКР — частая форма для исследовательских ИИ-проектов) с передачей исключительных прав заказчику. В договоре фиксируются: перечень передаваемых материалов (исходный код в репозитории, документация, инструкции развёртывания), момент передачи (по этапу, а не «когда-нибудь после оплаты») и гарантии отсутствия прав третьих лиц на передаваемое. Мы работаем по прямым договорам и по 44-ФЗ/223-ФЗ — порядок передачи прав одинаков. Как выстраивать поэтапный договор целиком (аудит → прототип → пилот → эксплуатация) — в ответе как заключить договор на разработку ИИ.
Данные и база знаний: всегда заказчика
Ваши регламенты, загруженные в RAG, векторный индекс, собранные промпты, логи диалогов, накопленная обратная связь — всё это ваши активы, созданные на ваших данных. В договоре это фиксируется прямым пунктом, а плюс к нему — обязательство подрядчика удалить копии данных после проекта и передать всё в машиночитаемом виде. Практический совет: требуйте, чтобы репозиторий и векторная база с первого дня жили в контроле заказчика (или передавались ежемесячно), а не «в личном аккаунте подрядчика». Реестр этих активов ведётся в AI BOM — без него к концу проекта никто не вспомнит, что и где лежит (ревизия — от 70 000 ₽).
Модель: API, open-source или дообучение
- Облачный API (GigaChat, YandexGPT и другие). Веса принадлежат вендору; вы владеете договором и аккаунтом. Критично: аккаунт оформляется на юрлицо заказчика, а не подрядчика — иначе доступ к сервису «принадлежит» интегратору.
- Open-source-модель (включая GigaChat Lite). Веса свободно распространяются по лицензии; развёрнутый в вашем контуре экземпляр — ваш: он никуда не «уезжает» и не отключается.
- Дообучение. Веса базовой модели остаются у её правообладателя, но результаты дообучения на ваших данных (адаптеры, датасеты) — ваши и передаются вам. Современная альтернатива дообучению — RAG: знания живут в вашей базе знаний и обновляются перезагрузкой документов.
Пять пунктов, которые нужно проверить в договоре
1) Передача исключительных прав на код — с перечнем материалов и сроками. 2) Судьба каждого слоя: код, данные, промпты, результаты дообучения — поимённо. 3) Лицензии третьих лиц: какие компоненты передаются по лицензии, а не в собственность, и что это значит при смене подрядчика. 4) Экспорт и выход: порядок передачи репозитория, базы знаний и выгрузки данных при завершении договора. 5) Регламент выключения: что происходит с доступами и контуром, если сотрудничество прекращается. Проверить подрядчика до подписания — чек-лист в ответе как проверить подрядчика перед договором.
Типовые ловушки в договорах на ИИ
Ловушка первая — «исключительные права, кроме использованных библиотек»: без приложения со списком таких компонентов через год выясняется, что половина системы «принадлежит» кому-то ещё. Требуйте перечень лицензий третьих лиц приложением к договору. Ловушка вторая — аккаунты на подрядчика: доступы к API, облакам и репозиториям оформлены на сотрудников интегратора; при смене подрядчика вы «выкупаете» собственный проект. Ловушка третья — «результаты генерации принадлежат исполнителю»: генерации на ваших данных должны уходить вам. Ловушка четвёртая — отсутствие порядка выхода: в договоре нет пункта, по которому вам передают репозиторий, базу знаний и выгрузку данных при расторжении. Каждый из этих пунктов стоит ноль рублей при подписании и сотни тысяч при споре.
Чек-лист передачи активов при завершении проекта
Финальная передача — это не письмо «всё готово», а приёмка по описи. Минимальный комплект: репозиторий исходного кода с историей коммитов, документация по развёртыванию (чтобы другой подрядчик поднял систему без археологии), дамп базы знаний и векторного индекса, перечень промптов и настроек, передача административных доступов ко всем внешним сервисам (API-ключи переоформляются на ваше юрлицо), реестр ИИ-активов с владельцами и подписанный акт. Если что-то из этого списка звучит для вашего текущего договора как открытие — тем более зафиксируйте его в следующем. Проверить добросовестность подрядчика до подписания помогает чек-лист из ответа о проверке подрядчика; опись «что у нас вообще есть» — это и есть AI BOM, ревизия от 70 000 ₽.
Лицензия платформы: что остаётся у правообладателя
Классический вопрос: «если часть системы построена на платформе подрядчика — не попадаю ли я в зависимость?» Разумная модель такая: всё, что создано специально для вас — код интеграций, промпты, база знаний, — передаётся заказчику; компоненты платформы (в нашем случае — экосистема ВЫШКА Cloud) принадлежат разработчику и лицензируются. Это не ловушка, а норма рынка: точно так же вы владеете документом, но не владеете текстовым редактором. Зависимость определяется не этим, а тремя практическими вещами: открыт ли формат ваших данных (можете ли выгрузить базу знаний и логи), документированы ли интеграции (может ли другой подрядчик разобраться) и есть ли регламент выхода (что происходит при расторжении договора). Если на три вопроса ответ «да» — платформенная лицензия безопасна и дешевле полной разработки с нуля; если «нет» — вы заложник независимо от того, как называется пункт договора.
Отдельно о результатах генерации: черновики договоров, тексты, картинки, код, которые система создаёт в работе. По договору НЬЮ-ССТ права на них передаются заказчику — вы владеете тем, что произвела система на ваших данных. Нюанс в другом: генерации наследуют права на исходные материалы. Если в базу знаний попал чужой контент без прав использования, «владение ответом» не легализует его использование. Поэтому в регламент загрузки базы знаний входит проверка происхождения документов — это защита не формальная, а судебная: спор о правах на ИИ-контент в 2026 году — уже не теория, и выигрывает тот, у кого описано происхождение каждой части корпуса.
Фиксируйте этот пункт отдельно — «происхождение данных» в реестре ИИ-активов, обновляемом при каждой загрузке.Как не потерять активы в процессе
Чужие незакоммиченные наработки, аккаунты на физлицо подрядчика, база знаний «у разработчика в облаке» — активы, которые заказчик фактически не контролирует. Что делать, если подрядчик уже пропал — разбор в ответе что делать, если подрядчик пропал. Чтобы этого не случалось: репозиторий в вашей организации, аккаунты API на ваше юрлицо, AI BOM как опись всего, ежемесячная передача артефактов. ТЗ, которое фиксирует границы создаваемой собственности, — по шагам в гайде как написать ТЗ на ИИ-разработку; юридическое сопровождение и ревизия активов — услуга ИИ-консалтинг.