Внедрение ИИ: договорная структура проекта

Внедрение ИИ в компании: договорная структура проекта

Почему внедрение ИИ — это не один договор, а связка документов

Внедрение ИИ в компании почти никогда не укладывается в один договор. Между «мы хотим подключить нейросеть» и «модель работает в продуктиве и приносит пользу» лежит цепочка совершенно разных по природе обязательств: кто-то проводит обследование процессов и пишет техническое задание, кто-то разрабатывает или настраивает модель, кто-то предоставляет права на её использование, кто-то интегрирует её с учётными системами заказчика, и кто-то потом всё это сопровождает. Каждый из этих этапов тянет за собой свою правовую конструкцию, свои риски и свой способ приёмки. Если попытаться запихнуть всё в один универсальный «договор на внедрение ИИ», получится документ, который не отвечает ни на один важный вопрос: где заканчивается ответственность подрядчика за результат и начинается лицензия, кому принадлежит обученная модель, что считать сданным этапом.

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

На практике сложилось три базовых блока. Первый — создание и доработка: всё, что приводит к фиксируемому результату (модель, коннектор, отчётный модуль), тяготеет к подряду по ст. 702 ГК РФ или к договору авторского заказа на создание программы. Второй — предоставление прав на готовую ИИ-платформу: это лицензия по ст. 1235 ГК РФ, когда заказчик получает право использовать чужой продукт, а не создаёт свой. Третий — сопровождение, поддержка и обеспечение уровня сервиса: это возмездные услуги по ст. 779 ГК РФ с приложением в виде соглашения об уровне сервиса. Понимание, в каком блоке вы находитесь в каждый момент проекта, — это и есть договорная грамотность во внедрении ИИ.

Выбор модели договора: подряд, услуги, лицензия или смешанная конструкция

Первый вопрос, который команда задаёт юристу: «нам нужен договор подряда или оказания услуг?». Ответ зависит от того, что является предметом. Подряд предполагает овеществлённый, проверяемый результат, который можно сдать и принять; именно поэтому к разработке модели и интеграций тяготеет подрядная модель с её правилами о сроках по ст. 708 ГК РФ, о цене и смете по ст. 709 ГК РФ и об ответственности за качество по ст. 723 ГК РФ. Услуги — это деятельность как таковая (консалтинг, обучение пользователей, мониторинг, поддержка), где ценность в самом процессе, а не в отделимом результате; здесь работают правила ст. 779 ГК РФ и право заказчика на односторонний отказ с компенсацией фактических расходов по ст. 782 ГК РФ.

Разница не академическая. По подряду заказчик может отказаться от исполнения только до сдачи результата с оплатой выполненной части и возмещением убытков в пределах разницы по ст. 717 ГК РФ; по услугам — практически в любой момент, компенсировав лишь фактические расходы по ст. 782 ГК РФ. По подряду действует развитый институт приёмки и ответственности за скрытые недостатки; по услугам приёмка часто формальна. Для ИИ-проекта это означает, что этап разработки модели разумнее оформить подрядной (или близкой к ней авторско-заказной) конструкцией с жёсткой приёмкой, а сопровождение — сервисной с гибким выходом. Смешивать их в одном неструктурированном договоре — значит лишить себя преимуществ обеих моделей.

Отдельный пласт — лицензирование. Если в основе внедрения лежит готовая ИИ-платформа поставщика, заказчик не создаёт продукт, а получает право им пользоваться. Это лицензионный договор по ст. 1235 ГК РФ, и к нему предъявляются специфические требования: должны быть определены способы использования, иначе договор рискует не охватить нужные сценарии; если умолчать о размере вознаграждения в возмездном договоре, он может быть признан незаключённым в силу п. 5 ст. 1235 ГК РФ. Программа для ЭВМ и связанные с ней базы данных охраняются как объекты авторских прав по ст. 1259 ГК РФ и ст. 1261 ГК РФ, а пределы использования любого результата интеллектуальной деятельности задаёт правообладатель в рамках ст. 1229 ГК РФ. Поэтому лицензионный блок нельзя писать «по аналогии с арендой» — у него своя логика.

Этапы и техническое задание: где проект чаще всего рассыпается

Техническое задание — сердце ИИ-проекта и одновременно его самое слабое место. В классической разработке ТЗ описывает функции; в ИИ-проекте этого мало, потому что результат вероятностен. ТЗ для внедрения ИИ обязано содержать не только перечень функций, но и измеримые критерии качества модели: на каком наборе данных, какими метриками и с каким пороговым значением будет оцениваться готовность. Без этого приёмка превращается в спор о вкусах. Юридически ТЗ — это согласование предмета и существенных условий: предмет договора подряда и требования к результату должны быть определены настолько, чтобы исполнение можно было проверить, иначе договор рискует быть признанным незаключённым из-за несогласованности существенных условий по ст. 432 ГК РФ.

Внедрение почти всегда идёт итерациями — командам удобно работать спринтами, выкатывать промежуточные версии, дообучать модель по мере накопления данных. Договор должен это отражать через этапность. Подряд прямо допускает промежуточные сроки выполнения отдельных этапов в рамках ст. 708 ГК РФ, и разбивка проекта на этапы с самостоятельной приёмкой каждого решает сразу несколько задач: фиксирует прогресс, позволяет привязать оплату к достигнутому результату, ограничивает риск заказчика суммой уже оплаченных этапов. Я всегда рекомендую делать этапы атомарными и завершаемыми: «обследование и ТЗ», «пилот на ограниченном объёме данных», «промышленная модель», «интеграция», «опытная эксплуатация». Каждый этап имеет вход, выход и критерий приёмки — тогда даже при срыве проекта стороны понимают, что сделано и за что заплачено.

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

Приёмка результата: как принимать то, что ошибается по своей природе

Приёмка ИИ-результата — это место, где сталкиваются юридическая формальность и технологическая реальность. По общим правилам подряда заказчик обязан осмотреть и принять результат, а обнаруженные недостатки зафиксировать; порядок приёмки регулируется ст. 720 ГК РФ. Проблема в том, что «недостаток» применительно к модели нельзя определить как единичную ошибку — модель ошибается всегда. Поэтому критерием приёмки должно быть не отсутствие ошибок, а достижение согласованного уровня качества на согласованном тестовом наборе. Если этот критерий прописан в ТЗ, приёмка становится объективной процедурой: запустили эталонный набор, измерили метрику, сравнили с порогом.

Ответственность за ненадлежащее качество по подряду серьёзна: при существенных и неустранимых недостатках заказчик вправе отказаться от исполнения и потребовать возмещения убытков по ст. 723 ГК РФ. Но чтобы этим правом можно было воспользоваться, «надлежащее качество» должно иметь измеримое выражение. Я видел десятки споров, где заказчик был недоволен моделью, но не мог ничего доказать, потому что в договоре качество описывалось словами «высокая точность» и «приемлемый уровень ошибок». В арбитражном споре каждая сторона доказывает обстоятельства, на которые ссылается, в силу ст. 65 АПК РФ — и без зафиксированной методики замера заказчик проигрывает доказывание, даже будучи по существу правым.

Практичный механизм — приёмка в два шага: предварительная (модель соответствует ТЗ по метрикам на тестовом наборе) и финальная по итогам опытной эксплуатации (модель держит качество на реальном потоке в течение согласованного периода). Опытная эксплуатация защищает заказчика от ситуации, когда модель блестяще проходит лабораторный тест, но деградирует на живых данных. Если результат — программа, созданная по заказу, важно синхронизировать момент приёмки с моментом перехода прав, потому что исключительное право на программу, разработанную по договору заказа, принадлежит заказчику в силу ст. 1296 ГК РФ, если договором не предусмотрено иное, — и эту привязку нельзя оставлять неопределённой.

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

Вопрос «кому принадлежит то, что получилось» — самый дорогой в ИИ-проекте, и интуиция здесь подводит. Заказчик часто уверен, что раз он заплатил, всё созданное принадлежит ему. Это верно лишь отчасти. Если речь о программе, специально созданной по его заказу, исключительное право по общему правилу ст. 1296 ГК РФ действительно у заказчика, но норма диспозитивна и легко перекрывается условием «иное» в пользу исполнителя. Если же внедрение строится на доработке существующей платформы исполнителя, никакого автоматического перехода прав не происходит: заказчик получает лицензию по ст. 1235 ГК РФ, и объём его прав ровно такой, какой выторгован в договоре.

ИИ-проект устроен слоями, и права разумно распределять послойно. Базовая модель и инструментарий исполнителя остаются за ним. Код интеграций и коннекторов, написанных под конкретного заказчика, обычно переходит заказчику или предоставляется ему по широкой лицензии — иначе он попадает в полную зависимость от одного поставщика. Самый спорный слой — результаты дообучения модели на данных заказчика. Здесь сталкиваются интерес исполнителя переиспользовать улучшения и интерес заказчика не делиться конкурентным преимуществом. Компромисс: общие улучшения базовой модели остаются у исполнителя, а специфические для заказчика веса и наборы данных либо передаются заказчику, либо лицензируются ему с запретом использования в пользу третьих лиц. Распоряжение исключительным правом оформляется по ст. 1233 ГК РФ — либо отчуждением, либо лицензией, и смешивать эти конструкции нельзя.

Нельзя забывать про данные как таковые. Структурированный массив данных заказчика, на котором обучается модель, может охраняться как база данных, и право её изготовителя, понёсшего существенные затраты, защищается отдельно. Кроме того, договор должен прямо урегулировать право исполнителя использовать данные заказчика для обучения: без явного разрешения такое использование за пределами оказания услуги конкретному заказчику спорно. Если в проекте используются открытые компоненты и сторонние библиотеки, стоит проверить их лицензионную чистоту — открытые лицензии могут накладывать обязательства, в том числе требование раскрытия производного кода, и игнорировать их рискованно. Свободное воспроизведение программы её законным пользователем в технических целях допускается в пределах ст. 1280 ГК РФ, но это узкое исключение, а не основание для свободного использования чужого кода в продукте.

Персональные данные и поручение обработки во внедрении

ИИ во внедрении почти всегда соприкасается с персональными данными: на них обучают, их обрабатывают в продуктиве, их видит исполнитель в ходе сопровождения. Как только исполнитель обрабатывает персональные данные по заданию заказчика, возникает связка «оператор — обработчик»: заказчик остаётся оператором, а исполнитель действует по его поручению. Такое поручение обязательно оформляется и должно содержать перечень условий, прямо предусмотренный ч. 5 ст. 18 152-ФЗ: перечень действий с данными, цели обработки, обязанности по конфиденциальности и безопасности. Условия обработки и её правовые основания закреплены в ст. 6 152-ФЗ, и без надлежащего основания обработка незаконна, каким бы полезным ни был ИИ-проект.

Распределение ответственности здесь устроено так: перед гражданином за обработку отвечает оператор, то есть заказчик, а обработчик отвечает перед оператором. Значит, в договоре нужна регрессная оговорка, перекладывающая на исполнителя санкции и убытки, вызванные его нарушениями. Меры безопасности не факультативны: обязанность принимать правовые, организационные и технические меры установлена ст. 19 152-ФЗ, а перечень организационных мер — ст. 18.1 152-ФЗ. С 30 мая 2025 года ответственность за нарушения в этой сфере ужесточена Федеральным законом от 30.11.2024 № 420-ФЗ, который ввёл оборотные штрафы за повторную утечку и повысил санкции по ст. 13.11 КоАП РФ. Если обрабатываются данные граждан России, действует требование локализации первичной обработки в стране по ч. 5 ст. 18 152-ФЗ — и место размещения инфраструктуры исполнителя становится прямым условием договора.

Распределение рисков, заверения и ответственность

ИИ-проект — это управление рисками не меньше, чем управление кодом. Часть рисков снимается заверениями об обстоятельствах по ст. 431.2 ГК РФ: исполнитель заверяет, что обладает правами на передаваемые компоненты и что они не нарушают прав третьих лиц; заказчик заверяет, что данные, которые он передаёт для обучения, получены законно и могут использоваться в проекте. Недостоверное заверение даёт пострадавшей стороне право на возмещение убытков или неустойку, а в существенных случаях — на отказ от договора. Это мощный инструмент: он переносит риск на ту сторону, которая лучше им управляет, и делает её ответственной за собственные обещания.

Для рисков, которые невозможно предотвратить, но можно распределить, удобна конструкция возмещения потерь по ст. 406.1 ГК РФ: стороны заранее договариваются, что одна возмещает другой определённые потери, возникшие при наступлении согласованных обстоятельств, независимо от нарушения обязательства. Классический пример — претензии третьих лиц о нарушении их интеллектуальных прав использованными компонентами: исполнитель берёт на себя возмещение таких потерь заказчику. Ответственность за нарушение самих обязательств наступает по общим правилам: возмещение убытков по ст. 393 ГК РФ, для предпринимателя — независимо от вины с освобождением лишь при непреодолимой силе по п. 3 ст. 401 ГК РФ. Ограничение ответственности потолком возможно по ст. 400 ГК РФ, но оно ничтожно в части умышленного нарушения в силу п. 4 ст. 401 ГК РФ — это предел, который нельзя обойти.

При толковании спорных условий суд исходит из буквального значения слов и выражений договора, а при неясности — из действительной общей воли сторон с учётом цели договора, как предписывает ст. 431 ГК РФ. Для ИИ-проектов с их незрелой терминологией это означает практический вывод: определяйте термины в самом договоре. Что такое «модель», «версия», «инцидент», «деградация качества», «производственная среда» — всё это должно быть зафиксировано, иначе каждая сторона вложит в слова удобный ей смысл, а суд выберет свой. Хорошая договорная архитектура ИИ-внедрения начинается со словаря и заканчивается процедурой выхода.

Сопровождение, обновления и выход из проекта

Внедрение не заканчивается запуском — дальше начинается жизнь системы, и она оформляется сервисным блоком. Здесь работают правила о возмездных услугах по ст. 779 ГК РФ, а к ним пристёгивается соглашение об уровне сервиса с показателями доступности, временем реакции и восстановления, метриками качества и сервисными кредитами. Обновления модели — отдельный риск: новая версия может улучшить одни метрики и ухудшить другие, поэтому разумно предусмотреть тестирование обновлений на эталонном наборе перед выкаткой и право заказчика на откат. Поддержание согласованного уровня после обновления — это продолжение обязанности надлежащего исполнения по ст. 309 ГК РФ, а не повод для новой оплаты.

Финальный и недооценённый элемент архитектуры — выход. Договор должен описывать, что происходит при расторжении: в каком формате и в какой срок исполнитель возвращает данные заказчика и результаты обработки, как организован переходный период для миграции к другому поставщику, в какой срок исполнитель удаляет данные с подтверждением. Право заказчика на односторонний отказ от сервисного договора реализуется по ст. 782 ГК РФ, общий порядок отказа — по ст. 450.1 ГК РФ, а последствия расторжения в части возврата предоставленного определяются с учётом ст. 453 ГК РФ. Без проработанного выхода заказчик оказывается в технологическом плену, а это сводит на нет всю выгоду от внедрения.

Краткое заключение

Внедрение ИИ — это договорная архитектура, а не один документ. Создание модели и интеграций тяготеет к подряду по ст. 702 ГК РФ с жёсткой приёмкой по ст. 720 ГК РФ; предоставление прав на готовую платформу — это лицензия по ст. 1235 ГК РФ; сопровождение — возмездные услуги по ст. 779 ГК РФ с приложением в виде SLA. Связывает всё это свобода договора и допустимость смешанных конструкций по ст. 421 ГК РФ. Успех проекта решается тремя вещами: измеримым ТЗ с критериями качества, осознанным распределением прав по слоям системы и проработанной процедурой выхода с возвратом данных. Юрист во внедрении ИИ — не тот, кто пишет красивый текст, а тот, кто заранее отвечает на вопросы, которые иначе всплывут в суде: что сдано, кому принадлежит и что будет, когда стороны разойдутся.