Разбираем, кто несёт ответственность за код, написанный AI-ассистентом: судебные прецеденты, условия лицензий и практические шаги для разработчика. Узнайте, как защитить себя и команду.
Представьте: ваш AI-ассистент сгенерировал 200 строк кода. Юридически вы можете не владеть ни одной из них, но отвечаете за каждую ошибку, которая попадёт в продакшн. В этой статье разберём разрыв между этими двумя утверждениями и то, что он значит для кода, который вы merge'ите завтра.
Инструмент, создавший код, нельзя привлечь к суду. Модель не несёт ответственности. Контракт вендора уже чётко дал понять — ответственность спускается вниз, к человеку, который нажал Tab. Самое интересное не в том, что этот разрыв существует, а в том, что почти никто в разработке не относится к нему серьёзно. Два года мы праздновали продуктивность, но потратили гораздо меньше времени на то, что делать, когда скорость сталкивается с претензией об авторских правах, аудитом compliance или инцидентом в продакшне. Давайте разберём: что на самом деле сказали суды, что на самом деле написано в контракте вашего инструмента, где находятся юридические утёсы и как разумная команда разработчиков обрабатывает всё это, не запрещая AI и не делая вид, что проблемы не существует.
Раньше право собственности на код было урегулированным вопросом. Вы писали код, работодатель платил вам, трудовой договор передавал авторские права компании, компания публиковала код под любой лицензией. Три стороны — вы, работодатель, пользователь — и границы между ними были чёткими. Если что-то ломалось, пользователь жаловался компании, компания смотрела историю коммитов, и кто-то получал негромкий разговор на one-on-one.
AI-ассистенты вставляют в эту картину четвёртую сторону, и её контракт не похож ни на один из остальных. Модель не подписывала ваш трудовой договор. Вендор не участвует в вашем процессе релиза. Его EULA похожа не на контракт о найме, а на отказ от ответственности. Вы получаете предложение, вы оставляете предложение, и вы также оставляете всё, что к нему прилагается: баги, лицензионные обязательства, уязвимости безопасности и любого будущего регулятора, который решит проверить, как это предложение туда попало.
Эта передача происходит молча. В вашей IDE нет чекбокса «Я принимаю юридическую ответственность за это завершение». Вы просто нажимаете Tab. Интерфейс сделан так, чтобы напоминать автодополнение, и большинство разработчиков переносят на него ментальную модель автодополнения: редактор помогает печатать быстрее, код остаётся моим, моё владение кодом не меняется. Эта ментальная модель почти верна и почти полностью ошибочна — в зависимости от того, какой вопрос вы задаёте.
Два факта лежат в основе юридической картины в США прямо сейчас, и оба удивляют разработчиков, когда они о них слышат.
Первый: в США защита авторским правом требует человека-автора. Это не новое правило. Это то же правило, по которому обезьяна не могла претендовать на авторские права на селфи в 2018 году, но оно было заново проверено в деле Thaler v. Perlmutter — об изображении, сгенерированном AI без значимого человеческого ввода. В марте 2025 года окружной суд округа Колумбия подтвердил решение нижестоящего суда: Закон об авторском праве 1976 года «требует, чтобы все охраняемые произведения были созданы в первую очередь человеком». Нет человека-автора — нет авторских прав. Результат находится в общественном достоянии.
Второй факт, который непосредственно касается разработчиков: Бюро по авторским правам США в 2024 — начале 2025 года пыталось провести границу для работ, созданных с помощью AI, которые всё же включают человека. В январе 2025 года Бюро опубликовало руководство, согласно которому результаты AI подлежат защите авторским правом только тогда, когда человек вносит «достаточные выразительные элементы». Одного промпта, даже сложного итеративного промпта, недостаточно. Один комментарий, процитированный в отчёте Бюро, использовал метафору, которая ударила по разработчикам сильнее, чем они ожидали: повторяющийся промптинг — это как крутить колесо рулетки. Человек выбрал, но человек не контролировал выразительные элементы результата с достаточной точностью, чтобы считаться автором.
Эта метафора важнее, чем её формулировка. «Tab для принятия» — в терминах авторского права — это крутить колесо. «Tab для принятия, затем переписать четыре строки, изменить структуру функции, добавить guard clause и интегрировать в уже спроектированный класс» — это другое. Здесь человеческий вклад начинает становиться тем видом выразительного контроля, который ищет Бюро.
Практический вывод: код, который выходит из вашего AI-инструмента почти нетронутым, может не быть собственностью вашей компании так, как код, написанный вашим старшим разработчиком на прошлой неделе. Он не украден, но он также не защищён авторским правом вашего работодателя в той степени, которая даёт обычные возможности защиты. Компания не может подать в суд на того, кто его копирует. Не может заявить о нём как об активе. Может публиковать, поставлять, модифицировать — но юридический ров вокруг него тоньше, чем кажется.
Картина меняется при пересечении границы. В Великобритании с конца 1980-х действует статья 9(3) Закона об авторском праве, дизайне и патентах 1988 года, которая прямо касается «компьютерно-сгенерированных произведений», назначая авторство «лицу, которое предприняло необходимые меры для создания произведения». Индия придерживается аналогичного подхода. ЕС находится в процессе более амбициозного переосмысления через AI Act, к которому мы вернёмся. Суть: единого глобального ответа сейчас нет. Код, который ваша команда пишет в лондонском офисе, может иметь более чёткую историю владения, чем тот же код, написанный в Сан-Франциско на той же модели на той же неделе.
Вот предложение из Copilot Product Specific Terms от GitHub, которое делает основную работу, и которое никто не цитирует на собраниях по внедрению AI: «Вы сохраняете всю ответственность за ваш Код, включая Предложения, которые вы включаете в свой Код или используете для его разработки».
Это предложение делает две вещи одновременно. Оно передаёт вам кое-что: GitHub заявляет, что не претендует на право собственности на предложения, так что они не создают конкурирующую претензию к вашей кодовой базе. И оно передаёт вам кое-что ещё: все юридические риски, связанные с этими предложениями. Обязательства по лицензиям с открытым исходным кодом из обучающих данных. Претензии об авторских правах от других разработчиков, чей код оказался похож. Дефекты в самом предложении. Условия вендора явно указывают, что вы несёте ответственность за определение того, требует ли ваше использование результата лицензии третьей стороны, и за соблюдение такой лицензии.
Если вы читаете Клиентское соглашение GitHub так, как разработчики читают README-файлы — бегло в поисках инструкций по установке — вы пропустите эту строку. Если вы читаете его как юрист, эта строка — весь документ.
Эта схема не уникальна для Copilot. Тот же паттерн встречается в условиях почти всех AI-ассистентов кодинга: вендор отказывается от прав на результаты, клиент принимает ответственность за результаты. Причина в том, что это единственная форма, позволяющая вендору работать. Представьте альтернативу: вендор гарантирует, что каждое предложение свободно от лицензионных обязательств, багов и не нарушает авторских прав. Они не могут дать такое обещание для модели, обученной на всём публичном корпусе GitHub. Поэтому контракт перекладывает риск на единственную сторону, которая может его оценить: на человека, делающего merge.
Модель не может прочитать лицензионные условия вашей кодовой базы. Вендор не знает, какому регулятору подчиняется ваша отрасль. IDE не знает, работаете вы над хобби-проектом или платёжным процессором. Единственное место, где может быть закреплена ответственность, — это кнопка merge.
Вот где контракт становится неудобным, и где в большинстве организационных структур разработки есть слепое пятно.
GitHub действительно предлагает защиту от исков об интеллектуальной собственности (indemnification) для предложений, если вы на тарифе Business или Enterprise. Если вас подадут в суд за нарушение авторских прав, потому что Copilot воспроизвёл фрагмент чужого кода, Microsoft вступится за вас и выплатит компенсацию в рамках своего Customer Copyright Commitment. Та же схема действует и в других инструментах: большинство крупных AI-ассистентов предлагают некоторую форму indemnification на корпоративном уровне.
Если вы на индивидуальном тарифе, ничего этого нет. Вы получаете ту же модель, те же предложения, ту же поверхность риска — и нулевую юридическую защиту. Если суд в итоге решит, что фрагмент, предложенный Copilot, был существенным воспроизведением чьего-то кода под GPL, у вас, лично, будут проблемы.
Почему это важно за пределами кабинета юриста: много профессионального софта всё ещё поставляется командами, где инженеры используют личные подписки Copilot — либо потому что компания ещё не стандартизировалась, либо кто-то подписался за полгода до внедрения корпоративного тарифа, либо им больше нравятся настройки личного аккаунта. Код, который пишут эти инженеры, попадает в кодовую базу компании, и индемнификация, которую компания считает имеющейся (потому что платит за Enterprise), на самом деле не покрывает предложения, сделанные через личную подписку.
Руководители разработки почти никогда это не проверяют. Отдел закупок думает, что корпоративный контракт покрывает всё. Разработчики не знают, что контракт проводит границу по тому, какая подписка сгенерировала предложение. CISO узнаёт только если случится суд.
Чистая история ответственности требует, чтобы каждая IDE, каждая машина разработчика и каждое общее окружение работали на тарифе с индемнификацией. «Мы купили Enterprise» — это не то же самое, что «каждое предложение, касающееся нашего репозитория, пришло из Enterprise».
Если вы прочитаете документацию GitHub по безопасности, вы найдёте функцию фильтра обнаружения дубликатов. Фильтр проверяет предложения на совпадение с публичным кодом на GitHub, и если предложение содержит сегмент кода длиной около 65 лексем (примерно 150 символов, длина одного-двух абзацев плотного кода) и достаточно точно совпадает с публичным кодом, предложение подавляется. Администраторы могут включить этот фильтр на уровне предприятия, и большинство разумных рекомендаций по внедрению советуют держать его включённым.
Фильтр — самая часто цитируемая мера защиты, когда команды говорят о рисках лицензирования Copilot. Это также отличный пример разрыва между «функция существует» и «функция решает проблему».
Порог в 65 лексем не случаен. Это компромисс между полнотой и полезностью. Фильтр, который подавлял бы любое совпадение из трёх токенов с публичным кодом, подавил бы почти все предложения Copilot, потому что последовательности из трёх токенов встречаются почти во всех open-source проектах. Поэтому порог установлен значительно выше, в диапазоне, где совпадения, скорее всего, намеренно похожи, а не случайны. Разумный дизайн. Цена — всё, что ниже порога, проходит без фильтрации.
Тело функции из 30 лексем, которое в точности совпадает с фрагментом из репозитория под GPL, может попасть в вашу кодовую базу, и фильтр его не увидит. Идиома из 50 лексем, реализация распространённого алгоритма, фрагмент парсера, хелпер сериализации — могут оказаться идентичными десяткам репозиториев, не пересекая черты. Фильтр не утверждает, что ловит всё. Он утверждает, что ловит длинные почти-дубликаты, которые с наибольшей вероятностью поддержат иск об авторских правах. Короткие фрагменты живут в серой зоне, где закон сам ещё не решил, что значит «существенно похоже».
Здесь вы принимаете обоснованное решение, а не идеальное. Фильтр помогает. Относиться к нему как к полному решению — нет. Относитесь к нему как к спам-фильтру в почте: полезен, часто молчаливо корректен, но не замена тому, чтобы не открывать вложения от незнакомцев.
Американский разговор об авторских правах фокусируется на владении. Европейский регуляторный разговор фокусируется на ответственности за результат.
AI Act Европейского союза, который вступил в силу поэтапно с 2025 года, не задаётся вопросом, кому принадлежит сгенерированный код. Он задаётся вопросом, кто отвечает, если код причиняет вред. В соответствии с AI Act, поставщики AI-систем общего назначения (включая модели, лежащие в основе инструментов кодинга) обязаны документировать обучающие данные и внедрять политику добросовестного использования. Разработчики, которые используют эти системы в профессиональных контекстах, несут ответственность за обеспечение соответствия отраслевым нормам — GDPR, PSD2, Директиве о кибербезопасности (NIS2) и т.д.
Это меняет вопрос с «Кто владеет этим кодом?» на «Кто отвечает, если этот код обрабатывает персональные данные незаконно?» На этот вопрос AI Act даёт чёткий ответ: развёртывающая сторона. То есть вы. Ваша компания. Не модель, не вендор.
Если ваш AI-ассистент предлагает фрагмент кода, который обращается к API, не проверяя авторизацию, и этот код попадает в production, регулятор не примет аргумент «AI это написал». Он увидит код, развёрнутый вашей компанией, обрабатывающий пользовательские данные. Ответственность за утечку данных ляжет на компанию, как если бы код написал человек.
То же самое относится к compliance. Предположим, ваш AI-сгенерированный код использует библиотеку под лицензией AGPL, а ваше приложение — проприетарное. В США это может быть спором об авторских правах. В ЕС, в зависимости от юрисдикции, это может быть нарушением условий лицензии, которое влечёт административные санкции. AI Act не отменяет существующее лицензионное право; он добавляет слой обязательств по прозрачности и документированию. Вы должны быть в состоянии объяснить, как код был создан и какие шаги были предприняты для обеспечения соответствия.
Юридическая картина вокруг AI-сгенерированного кода неопределённа, но не хаотична. Есть чёткие паттерны ответственности, которые вы можете использовать для защиты себя и своей команды. Вот три действия, которые стоит выполнить на этой неделе.
Если кто-то в команде использует индивидуальную подписку для работы над корпоративным кодом, вы несёте риск без защиты. Убедитесь, что все используют корпоративный тариф с индемнификацией. Это легко проверить через консоль администратора.
Фильтр 65 лексем — хорошая первая линия защиты. Дополните его автоматической проверкой лицензий зависимостей (например, с помощью инструментов вроде FOSSA или Snyk). Если AI-сгенерированный код использует библиотеку с несовместимой лицензией, вы должны узнать об этом до merge'а.
Создайте политику, требующую от разработчиков помечать AI-сгенерированные фрагменты в коммитах (например, через комментарии или специальные теги). Это не только помогает при аудите, но и создаёт след, который может быть важен в суде. Если вы можете показать, что существенная часть кода была переработана человеком, ваша позиция по авторским правам становится сильнее.
И последнее: не паникуйте. Да, есть риски. Но они управляемы. Большинство AI-сгенерированного кода не вызовет проблем — если вы принимаете разумные меры предосторожности. Относитесь к AI-ассистенту как к неопытному стажёру: проверяйте его работу, задавайте вопросы, не принимайте всё на веру. И помните: кнопка merge — ваша ответственность.
Хочешь закрепить знания на практике?
Решай задачи на Algolit — интерактивная платформа для обучения
Начать бесплатно →