AI помог написать код: студии нужно разделить права на 3 части продукта

Клиент прислал договор: передайте все права на результат и подтвердите, что внутри нет сторонних материалов. Команда писала интеграцию с Cursor, Claude Code или Codex и теперь пытается понять, можно ли это подписать. Начать стоит с содержимого релиза. Если там есть чужая библиотека, собственная платформа студии и новый адаптер, одна фраза про «все права» скрывает три разных договорённости.

Для разработчика это задача учёта компонентов. Для основателя студии — вопрос, сможет ли команда использовать свои наработки в следующем проекте. Для заказчика — сможет ли он поддерживать оплаченную систему после расставания с исполнителем. Участие AI добавляет вопросы, но значительная часть работы знакома и по обычной разработке.

Сначала разберите поставку на части

Возьмём студию, которая подключает платёжную систему клиента к своей платформе. В проекте появляются адаптер, библиотека под MIT и ускоренная очередь обработки платежей. Помощник участвовал в написании адаптера и переделке очереди.

Библиотека остаётся сторонним компонентом. Возможность использовать её в коммерческом продукте не превращает студию в обладателя исключительных прав на неё. Поэтому утверждение «сторонних материалов нет» требует исправления независимо от того, кто выбрал пакет — человек или помощник.

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

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

Что проверить в коде и условиях помощника

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

В исходном материале предложены два инструмента: Syft для ведомости компонентов, или SBOM, и ScanCode Toolkit для поиска сведений о лицензиях и авторах в файлах. Такой учёт помогает собрать картину поставки. Встроенный в собственный файл сторонний фрагмент потребует дополнительной проверки кода и истории изменений. Пустой отчёт сканера не закрывает все вопросы о происхождении материала.

Следующий документ — условия использованного AI-сервиса. Статья обращает внимание на принципиальную границу: положения о правах пользователя регулируют его отношения с поставщиком помощника. Из них нельзя автоматически вывести права на библиотеки, материалы клиента и весь собранный продукт.

Отдельной проверки требуют возможная защита от претензий и её исключения. Для этого нужны точный продукт, тариф и применимая редакция условий. Записи «у нас платная подписка» для сравнения обязательств недостаточно: обещания студии заказчику могут оказаться шире обязательств поставщика AI.

Дайте клиенту понятные возможности

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

Ещё до подключения помощника стоит проверить, можно ли передавать ему клиентские исходники, спецификации и данные. Отключённое обучение само по себе не отвечает на вопрос о допустимости передачи. Рабочий вариант может включать согласованный инструмент, ограниченный доступ к файлам и синтетические записи вместо реальных.

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