Генеративный ИИ уже стал нормальным инструментом разработки: с его помощью пишут функции, тесты, SQL, документацию и даже архитектурные заготовки. Но как только такой код попадает в продукт, договор с клиентом, инвестиционный due diligence или корпоративную политику безопасности, возникает не технический, а юридический вопрос: кому принадлежит результат и можно ли считать его интеллектуальной собственностью компании или автора.
Короткий ответ: по договору с платформой output чаще всего передаётся пользователю, но по авторскому праву защита зависит от того, есть ли в результате достаточный творческий вклад человека. Именно здесь проходит граница между «могу использовать» и «могу защищать как своё произведение».
Два разных вопроса, которые все путают
В обсуждении AI-кода часто смешивают два разных вопроса. Первый — что разрешает сам сервис в своих условиях использования. Второй — признаёт ли закон такой результат объектом авторского права.
У лидеров рынка позиция в terms в целом похожа: Anthropic в коммерческих условиях закрепляет, что между клиентом и Anthropic права на output принадлежат клиенту; OpenAI указывает, что присваивает пользователю права на output и не претендует на copyright over API outputs. На практике Claude, ChatGPT и аналоги не говорят: «этот код наш». Но это ещё не гарантирует, что итоговый код автоматически получит полную охрану как объект авторского права во всех юрисдикциях.
Поэтому корректно разделять две формулы. Первая: «сервис отдаёт мне output, и я могу использовать его в бизнесе». Вторая: «я правообладатель охраняемого произведения и могу юридически ограничивать копирование другими». Эти формулы не всегда совпадают.
Что обещают лидеры рынка: сравнение terms
| Платформа | Позиция по output | Что это значит на практике |
|---|---|---|
| Claude / Anthropic | В коммерческих terms права на outputs закрепляются за клиентом, насколько это допускает применимое право | Output можно использовать в продукте, передавать заказчику и включать в коммерческую разработку, но copyright-статус всё равно оценивается отдельно |
| OpenAI / ChatGPT / API | OpenAI уступает пользователю права на output и не претендует на copyright over API outputs | Сервисный риск ниже: платформа не спорит за ownership, но вопрос охраноспособности результата остаётся |
| Google / Gemini | Публичные материалы по GenAI ориентируются на пользовательский контроль над input/output при соблюдении правил и прав третьих лиц | Использовать output обычно можно, но для enterprise отдельно оценивают data governance, лицензии и правовой режим конечного результата |
С предпринимательской точки зрения это хорошая новость: рынок уходит от модели, при которой провайдер ИИ претендует на код пользователя. С юридической — этого недостаточно: ownership по договору и охрана по copyright — разные вещи.
США: жёсткий стандарт человеческого авторства
В США базовая позиция после разъяснений U.S. Copyright Office осталась жёсткой: copyright охраняет произведения человеческого авторства, а не результат, созданный машиной без достаточного участия человека. В отчёте 2025 года ведомство прямо подтвердило, что сам по себе prompt обычно недостаточен, а полностью AI-generated output без достаточного человеческого вклада не получает авторско-правовую охрану.
При этом позиция не сводится к запрету. Если человек использует ИИ как инструмент, а затем вносит значимые творческие изменения — комбинирует элементы, определяет структуру, архитектуру, логику и финальное выражение результата — защита может возникнуть именно в части человеческого авторства. Для разработчиков это означает простую вещь: чем больше AI выступает помощником, а не «основным создателем», тем сильнее юридическая позиция владельца результата.
ЕС и Великобритания: фокус смещается к человеку
Для европейского рынка важна не только американская логика. В ЕС правовая дискуссия также строится вокруг человеческого творчества: исследования EUIPO и Европарламента в 2025 году подчёркивают, что авторское право на AI-generated works упирается в human authorship, а также в прозрачность, lawful use of data и границу между AI-assisted и AI-generated результатами.
В Великобритании исторически существовал более необычный режим для computer-generated works: британское право допускало, что автором может считаться лицо, которое предприняло необходимые меры для создания произведения. Это долго воспринималось как более удобная модель для машинно-сгенерированных результатов, включая код. Но даже в UK практический фокус всё сильнее смещается к роли человека, который формирует задачу, организует создание и перерабатывает output в финальный результат.
Если продукт создаётся для UK/EU-рынка, безопаснее исходить не из идеи «AI всё сделал за нас», а из модели «AI ускорил разработку, но ключевой творческий вклад остался у команды». Эта формулировка лучше работает и для контрактов, и для внутреннего compliance, и для разговоров с инвесторами.
Три сценария, которые определяют вашу правовую позицию
С практической точки зрения полезно разделять три сценария.
Первый — сырой output. Разработчик вводит короткий prompt, получает большой блок кода и почти без изменений вставляет его в production. Использовать код обычно можно, но утверждать, что это надёжно охраняемая интеллектуальная собственность автора или компании, уже гораздо сложнее.
Второй — самый сильный. Человек формулирует архитектуру, определяет требования, правит output, переписывает ключевые участки, добавляет тесты, меняет структуру данных, устраняет ошибки и объединяет AI-код со своим. Здесь появляется существенный человеческий вклад, который заметно усиливает аргумент в пользу авторско-правовой защиты.
Третий — корпоративный. Даже если код создаётся с помощью ИИ, права часто определяются не только terms платформы, но и трудовым договором, политикой работодателя, MSA с клиентом, условиями поставки ПО и внутренними правилами безопасности данных. Для бизнеса вопрос ownership почти всегда шире, чем один prompt и один output.
Скрытые слои риска: не только авторство
Юридический риск вокруг AI-кода — это не только вопрос авторства. Есть ещё как минимум три слоя.
Первый — лицензии open source: если сгенерированный код окажется слишком близок к существующим решениям или повторяет лицензируемые фрагменты, могут возникать вопросы совместимости и обязательств по лицензиям (например, копилефт-требования GPL).
Второй — confidentiality и data governance. Для enterprise-заказчиков важно, может ли входной код или контекст использоваться для обучения модели, как устроены retention-политики, auditability и contractual safeguards.
Третий — liability: если код создал баг, security issue или infringement risk, компании нужно заранее понимать, кто за это отвечает по договору и насколько terms поставщика реально помогают в споре.
Именно поэтому зрелый подход к AI coding сегодня — не спор о том, «заменит ли модель программиста», а вопрос о том, как зафиксировать ownership, снизить licensing risk и доказать достаточный человеческий вклад в итоговый артефакт.
Тенденции 2026–2027
На горизонте 2026–2027 видны три устойчивые тенденции.
Первая — платформы продолжат ещё яснее прописывать ownership of output в пользу клиента: enterprise-рынок требует предсказуемости.
Вторая — регуляторы и суды, скорее всего, не откажутся от стандарта human authorship. Полностью AI-generated код останется в более слабой правовой позиции, чем AI-assisted разработка с заметным вкладом инженера.
Третья — рост значения процессной доказуемости. Побеждать будут не те, кто просто использует ИИ, а те, кто умеет показать provenance: кто поставил задачу, кто принимал инженерные решения, кто переписывал код, кто проводил code review и как фиксировался человеческий вклад в системе разработки.
Главный вывод
Код, созданный с помощью Claude, ChatGPT или Gemini, обычно можно использовать как свой по условиям сервиса. Полноценная юридическая защита возникает там, где есть измеримый творческий вклад человека. Поэтому лучший вопрос сегодня — не «мой ли AI-код», а «достаточно ли в нём моего участия, чтобы он был моим не только по terms, но и по авторскому праву».
На практике это означает простые шаги: хранить историю правок, не публиковать в сыром виде чувствительный код, использовать code review, документировать архитектурные решения, а в договорах и внутренних политиках отдельно прописывать режим AI-assisted разработки. Так инструмент превращается в управляемый юридический актив, а не в источник будущих споров.
Что делать уже сейчас
Если вы строите продукт с AI coding tools, публикуете AI-assisted код или внедряете такие инструменты в команду, уже сейчас стоит пересмотреть три документа: developer policy, договор с клиентом и внутренние правила фиксации авторства. В 2026 году вопрос ownership — это уже не футурология, а часть нормальной инженерной и бизнес-гигиены.
Проверьте прямо сегодня: сможете ли вы доказать, что финальный код — результат вашего творческого вклада, а не сырой output модели? Если нет — начните документировать архитектурные решения, коммиты и code review уже со следующего спринта.
Материал не является юридической консультацией и подготовлен в информационных целях. Для конкретной ситуации рекомендуется обратиться к юристу по интеллектуальной собственности в применимой юрисдикции.