Почему растет число судебных споров из-за ИИ-кода

Одновременно ИИ-ассистенты для разработки стали штатным инструментом: они генерируют функции, предлагают исправления, рефакторят legacy-код и создают конфигурации для CI/CD.

Юридический риск растет по той же причине, что и операционный: код появляется быстрее, чем организация успевает проверить его происхождение, лицензию, безопасность и соответствие архитектуре. Авторские права на код ИИ остаются зоной неполной определенности. При этом уже формируется практический подход: чистая генерация не дает автоматической copyright protection, а ответственность за включенный в продукт дефект постепенно смещается к компании, которая этот продукт выпускает.

В России число судебных споров, связанных с применением ИИ, выросло на 60% за год по данным на ноябрь 2025 года. Большинство дел пока касается взыскания долгов, грантов и договоров на разработку IT-продуктов. Но контур рисков для software engineering уже виден.

Правовой вакуум: кому принадлежат права на код нейросети

Главная ошибка компаний — считать, что вопрос решается формулировкой в пользовательском соглашении. Указание на то, что пользователь получает права на output, не превращает автоматически сгенерированный код в произведение, защищенное авторским правом.

Суды в США, Европе и Германии исходят из базового принципа: если результат создан исключительно ИИ и человек не внес достаточного творческого вклада, copyright protection может отсутствовать. Это не означает, что вся программа, в которой использовался ИИ-код, автоматически лишается защиты. Правовая оценка проводится по вкладу человека.

Разница проходит по нескольким уровням:

• Архитектура. Выбор структуры системы, границ сервисов, модели данных и алгоритмического подхода обычно относится к человеческим решениям.
• Постановка задачи. Чем точнее инженер формирует требования, ограничения и критерии результата, тем проще зафиксировать его интеллектуальный вклад.
• Адаптация. Интеграция output в существующий код, изменение логики, оптимизация и рефакторинг создают дополнительный слой человеческой работы.
• Отбор. Выбор одного варианта из нескольких сгенерированных решений сам по себе не всегда достаточен. Нужна содержательная редактура, а не механическое копирование.
• Документирование. Без audit trail компания не сможет доказать, какую часть сделал человек и как был получен итоговый результат.

Практически это означает, что право принадлежит не «нейросети» и не обязательно пользователю целиком. Вопрос решается через цепочку создания software artifact: кто сформировал требования, кто определил архитектуру, кто написал или изменил код, кто провел review и кто принял решение о включении компонента в production.

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

ИИ ускоряет выпуск кода. Он не создает для компании автоматическую доказательную базу.

Проблема усиливается при использовании foundation models, обученных на больших массивах open-source-кода. Юридический вопрос состоит не только в том, кому принадлежит output. Нужно установить, не воспроизводит ли он защищенный фрагмент и не нарушает ли условия исходной лицензии.

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

• длинный фрагмент с узнаваемой структурой;
• редкий алгоритм с оригинальными именами переменных и комментариями;
• код с сохраненной copyright notice;
• компонент, совпадающий с публичным репозиторием;
• файл, в котором присутствуют признаки конкретной лицензии;
• реализацию, полученную из внутреннего или закрытого набора данных.

Для enterprise-разработки это не академический вопрос. Нарушение лицензии может потребовать раскрытия исходников, публикации изменений, указания авторства или прекращения распространения продукта. Лицензионная проверка должна быть частью Software Composition Analysis, а не ручной процедурой после релиза.

Doe v. GitHub: что именно проверяют суды

Коллективный иск Doe v. GitHub был подан в США в ноябре 2022 года против GitHub, Microsoft и OpenAI. Истцы связали GitHub Copilot с нарушением условий open-source лицензий и удалением информации об авторских правах, включая Copyright Management Information.

Сумма требований в деле оценивалась в 9 млрд долларов. Но ранняя оценка иска не равна установленной ответственности. В июне 2024 года окружной суд отклонил большинство требований, связанных с DMCA. Позиция суда была узкой: для признания нарушения генератор должен выдать идентичную копию защищенного кода, а не просто похожий фрагмент.

Это решение не закрывает спор о лицензировании кода нейросетей. Оно ограничивает конкретную правовую теорию, на которой строилась часть претензий. Суд не установил окончательно, что обучение моделей на open-source-коде всегда законно. Апелляция продолжается. 11 февраля 2026 года Апелляционный суд девятого округа США заслушал устные аргументы. Окончательное решение после слушаний не вынесено.

Для архитектурного комитета из этого дела следуют четыре рабочих вывода:

1. Сходство не равно идентичности. Простое совпадение логики или общего паттерна не доказывает копирование. Но длинный буквальный match остается отдельным риском.

2. Лицензия может быть нарушена без буквального совпадения. Если output включает код из конкретного проекта, нужно оценивать не только текст, но и license obligations.

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

4. Юридическая позиция должна подтверждаться техническими логами. Без истории prompt, output, review и изменений компания теряет возможность восстановить происхождение фрагмента.

На практике полезно разделять два класса output.

Отдельный класс риска — код, который выглядит оригинальным, но содержит чужие комментарии, названия классов или строки из документации. Автоматическая проверка должна анализировать не только AST и поведение, но и текстовые совпадения.

В GitHub Actions и других CI/CD-контурах это можно реализовать через комбинацию инструментов:

• SCA для поиска open-source-компонентов и их лицензий;
• secret scanning для credential;
• SAST для типовых уязвимостей;
• policy-as-code для блокировки запрещенных license;
• provenance logs для фиксации происхождения изменений;
• mandatory review для кода из внешних AI tools.

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

Директива ЕС: ответственность перемещается к производителю продукта

Директива ЕС 2024/2853 о ответственности за качество продукции вступила в силу 8 декабря 2024 года. Она расширяет подход к product liability и рассматривает software и AI systems в логике продукта. Срок внедрения директивы государствами ЕС истекает 9 декабря 2026 года.

Ключевое изменение для engineering-команд: дефект ИИ-кода оценивается не как абстрактная ошибка инструмента, а как потенциальный дефект конечного продукта. Если компания встроила сгенерированный компонент в приложение, API, медицинскую систему, промышленный контроллер или другой коммерческий software, претензия может быть направлена к производителю продукта.

Это не означает, что разработчик ИИ-ассистента автоматически отвечает за каждую ошибку. Фактический контур ответственности зависит от продукта, договора, юрисдикции, характера дефекта и поведения участников. Но для компании-владельца системы исчезает удобная позиция «ошибся генератор».

Производитель должен показать, что у него были:

• требования к безопасности;
• процесс human review;
• тесты на known vulnerability classes;
• контроль зависимостей;
• журнал изменений;
• управление версиями модели;
• ограничения для high-risk use cases;
• процедура incident response;
• доказательства корректного deployment.

С инженерной точки зрения AI-generated code следует рассматривать как code from an untrusted external contributor. Модель не имеет ответственности, SLA и обязанности исправить дефект. Значит, ее output нельзя помещать в production pipeline с теми же условиями, что и проверенный внутренний модуль.

Для систем с повышенными требованиями к надежности нужен отдельный release gate. Например:

• код, сгенерированный ИИ, не может напрямую изменять authentication, authorization и secrets management;
• изменения в Terraform, Helm charts и k8s manifests проходят отдельный review;
• security-critical code не принимается без ручного анализа;
• модель не получает доступ к production credentials;
• все обращения к внешним AI API проходят через корпоративный gateway;
• prompt и output сохраняются с учетом требований к конфиденциальности;
• vendor обязан раскрывать правила хранения и использования данных.

Такой режим увеличивает latency разработки. Но он снижает вероятность, что ускорение на этапе coding создаст задержку на этапе incident response или litigation.

Цена удобства: утечки секретов через ИИ-ассистентов

Самая измеримая проблема ИИ в разработке — не copyright, а data leakage. Разработчики вставляют в prompt stack trace, конфигурацию, фрагмент private repository, токен или SQL-запрос с реальными идентификаторами. Модель отвечает корректно. Утечка происходит до момента генерации кода.

По данным GitGuardian State of Secrets Sprawl 2026, использование ИИ-ассистентов удваивает частоту утечек конфиденциальных данных. В 2025 году на публичном GitHub обнаружили 28,65 млн новых секретов. Рост составил 34% год к году.

Есть и более узкий показатель. Для коммитов, созданных при участии Claude Code, доля утечек секретов составила 3,2% против базового уровня 1,5% для всех коммитов. Это не доказывает, что конкретная модель является единственной причиной инцидентов. На результат влияют профиль пользователей, тип проектов, отсутствие review и способ интеграции инструмента. Но разрыв достаточен, чтобы считать AI-assisted coding отдельным security risk.

Типовая причина — неправильная граница контекста:

1. Разработчик копирует ошибку из production log.

2. В лог попадает access token или внутренний URL.

3. Фрагмент отправляется во внешний AI API.

4. Компания теряет контроль над распространением данных.

5. После этого невозможно считать инцидент только внутренним.

Для предотвращения утечек нужен не запрет ИИ, а архитектурное разделение данных и функций. Базовый enterprise-стек выглядит так:

• корпоративный AI gateway с tenant isolation;
• DLP до отправки prompt;
• redaction секретов и персональных данных;
• запрет прямого доступа модели к production;
• short-lived credentials вместо постоянных токенов;
• IAM с минимальными полномочиями;
• audit log всех запросов;
• retention policy для prompt и output;
• secret scanning в pre-commit и CI;
• автоматическая ротация credential при обнаружении утечки.

Особое внимание требуется IDE-плагинам. Они имеют контекст проекта и часто могут индексировать файлы за пределами открытого документа. Если правила repository не отделяют public и private data, разработчик может передать модели больше, чем предполагал.

Проблема усугубляется тем, что AI-generated code часто проходит review быстрее. Инженер видит знакомую структуру, принимает ее как boilerplate и не проверяет, какие внешние вызовы, права доступа и параметры сериализации появились внутри.

Минимальная политика должна разделять операции:

• генерация тестов и документации;
• генерация некритичного application code;
• изменение инфраструктурного кода;
• работа с authentication и authorization;
• работа с платежами и персональными данными;
• работа с криптографией;
• анализ production logs.

Для первых двух категорий допустим standard workflow. Для остальных нужен restricted workflow с контролем данных и обязательным review.

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

Юридический контроль нельзя вынести в отдельный документ legal department. Он должен быть встроен в SDLC. Иначе политика будет существовать отдельно, а код — проходить по обычному pipeline.

Рациональная схема состоит из пяти уровней.

1. Vendor layer

До подключения модели оцениваются:

• условия использования input и output;
• возможность vendor использовать данные для обучения;
• регион хранения;
• DPA и confidentiality terms;
• SLA и incident notification;
• доступность audit logs;
• политика обработки prompts;
• наличие enterprise isolation;
• процедура удаления данных;
• ограничения на reverse engineering и redistribution.

Сравнивать модели только по benchmark quality недостаточно. Для enterprise важны latency, cost per token, context window, rate limits, data governance и стабильность API.

2. Repository layer

В каждом repository должны быть машинно читаемые правила:

• запрещенные license;
• типы файлов, которые нельзя передавать внешним моделям;
• папки с secrets и персональными данными;
• требования к attribution;
• обязательные команды проверки;
• список разрешенных AI tools;
• условия для merge generated code.

Правила должны проверяться автоматически. Если policy находится только в Confluence, это не policy enforcement.

3. Generation layer

Каждый AI-assisted change должен иметь минимальный provenance:

• какой инструмент использован;
• какая версия модели;
• дата и время генерации;
• тип задачи;
• repository и ветка;
• объем принятого output;
• ссылки на review;
• результат тестов и scans.

Хранить полный prompt нужно с учетом confidentiality. Для части проектов достаточно сохранять hash, метаданные и diff. Для regulated environments требования будут жестче.

4. Verification layer

До merge выполняются:

• unit и integration tests;
• SAST;
• dependency scan;
• license scan;
• secret scan;
• проверка на hardcoded credentials;
• анализ новых outbound connections;
• оценка permissions;
• ручной review критических участков.

AI-generated code не должен получать исключения из quality gates. Если команда отключает проверки ради скорости, она меняет SLA разработки на SLA инцидента.

5. Runtime layer

Даже качественно проверенный код может вести себя иначе при изменении конфигурации или данных. Поэтому нужны:

• feature flags;
• canary deployment;
• rollback;
• runtime monitoring;
• tracing;
• rate limits;
• circuit breakers;
• контроль аномального доступа;
• регулярная ротация secrets;
• incident playbooks.

Вопросы copyright и лицензирования требуют одной группы evidence. Вопросы security и product liability — другой. Но source control, CI/CD и audit log являются общей инфраструктурой доказательств.

Судебная практика в России: от споров по грантам к вопросам интеллектуальной собственности

В России специализированного федерального закона, который детально определяет ответственность за AI-generated code, пока нет. Регулирование остается рамочным. Поэтому споры квалифицируются через действующие нормы о договорах, результатах интеллектуальной деятельности, защите информации и ответственности производителя. Через эти нормы суды уже вынуждены подходить к вопросам, для которых в ГК РФ отдельной статьи не написано.

Рост числа дел на 60% за год по данным на ноябрь 2025 года объясняется просто: увеличивается количество проектов, в которых ИИ использовался как часть workflow. По мере того как эти проекты переходят от прототипов к коммерческим продуктам, контур претензий смещается от договорных споров к вопросам интеллектуальной собственности и качества продукта.

Основные категории дел сегодня:

• взыскание задолженности по договорам на разработку, где ИИ применялся как инструмент ускорения, но заказчик не получил обещанного результата;
• споры по грантам и субсидиям, где результаты интеллектуальной деятельности должны были быть переданы в публичный доступ, но не были;
• претензии к качеству программного обеспечения, где заказчик ссылается на дефекты в коде, часть которого была сгенерирована;
• внутренние корпоративные споры, связанные с правами на компоненты, разработанные с использованием ИИ разными командами;
• трудовые споры, в которых возникает вопрос о том, кому принадлежат результаты, созданные сотрудником с использованием корпоративного ИИ-инструмента.

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

Для engineering-команд в России это означает несколько практических следствий.

Документирование вклада человека становится важнее выбора инструмента. Российские суды охотнее признают авторские права на код, если можно показать конкретные решения инженера: выбор архитектуры, написание ключевых модулей, проведение review. Если инженер только отправлял prompt и принимал первый ответ, доказательная база слабеет.

Лицензионная чистота проверяется так же, как в ЕС и США. Если код получен из open-source-репозитория, его лицензия сохраняется вне зависимости от того, кто сгенерировал итоговый текст. Условия GPL, MIT, Apache остаются обязательными, и этот факт не зависит от инструмента, через который прошел текст.

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

Внутренний режим безопасности влияет на исход спора. Если инцидент произошел из-за того, что разработчик отправил конфиденциальную информацию во внешний ИИ, ответственность распределяется между инженером, компанией и провайдером инструмента. Без внутренней политики и audit log эта разница плохо восстанавливается.

В России судебная практика по ИИ-коду только формируется. Решения, которые компания примет сегодня, определят, на какой стороне она окажется в завтрашних спорах.

В ближа