ИИ агент под ключ: договор, приёмка и ответственность

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

Что «под ключ» означает применительно к агенту

В выдаче по этому запросу подрядчики обещают фиксированную цену, быстрый прототип, интеграцию с 1С и «код и доступы ваши». Ни одно из этих обещаний не описывает, что агенту разрешено делать в вашем контуре, то есть предметом обязательства не является.

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

Предмет договора: перечень инструментов и границ прав

Частая ошибка: предмет формулируют через объём («агент на 15 сценариев», «до 40 веток диалога»). У агента это ничего не ограничивает. Работоспособный предмет это перечень функций, которые агент вправе вызывать, и границы прав в каждой системе. Минимальная форма приложения к договору:

Сценарии на стыке систем, где готовых интеграций нет, закрывают ИИ-агенты и RPA под задачу.

Система	Функция, которую агент вправе вызвать	Границы права	Требуется подтверждение человека
CRM	Создать лид, добавить комментарий	Только новые записи, поле «сумма» недоступно	Нет
CRM	Сменить стадию сделки	Движение только вперёд по воронке	Да, для стадии «отказ»
Почта	Отправить письмо клиенту	Шаблоны из согласованного списка, один домен отправителя	Да, если во вложении документ
Склад	Прочитать остаток	Только чтение, запись запрещена	Нет
Бухгалтерия	Запрещено полностью	Доступ не выдаётся	Не применимо

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

Разработка ии агента на заказ: чем измеряется обязательство исполнителя

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

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

Как заказать разработку ии агента и не потерять право на претензии

Дефект агента редко виден в момент подписания: он отработает десять показанных задач и провалит одиннадцатую, которую не показывали. Статья 720 ГК РФ делит недостатки на явные и скрытые, и по пункту 3 заказчик, принявший работу без проверки, лишается права ссылаться на явные, то есть на те, которые могли быть установлены при обычном способе приёмки.

Для агента «обычный способ приёмки» не задан ничем, кроме самого договора. Если в нём не написано, что приёмка это прогон согласованного набора задач, промах на непоказанном сценарии подрядчик назовёт явным недостатком, который заказчик обязан был увидеть сам, а заказчик скрытым, и разбираться стороны будут задним числом. Поэтому способ приёмки описывается так же подробно, как предмет, а в акт вносится оговорка о праве предъявить требования по итогам наблюдения за первый период работы: пункт 2 той же статьи допускает такую оговорку прямо.

Второе следствие касается пункта 5: при споре о недостатках или их причинах по требованию любой из сторон назначается экспертиза, расходы несёт подрядчик, кроме случаев, когда экспертиза установила отсутствие нарушений или причинной связи. Экспертиза агента возможна только при сохранённых записях запусков. Без журнала вызовов исследовать нечего: повторить прошлое поведение модели на той же задаче эксперт не сможет. Срок хранения трассировки поэтому не техническая мелочь, а условие, от которого зависит, кто заплатит за спор.

Критерий приёмки: эвал-набор с порогом вместо «нам понравилось»

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

• Состав набора. Фиксированное число задач по типам: типовые обращения, пограничные случаи, случаи, где правильное поведение это отказаться и передать человеку, провокации на выход за границы прав из таблицы предмета.
• Доля успешных прогонов по каждому типу отдельно: общая цифра скрывает провал на пограничных случаях, а они стоят дороже всего.
• Доля вызовов с ошибкой инструмента. Агент может дать верный ответ и при этом не записать результат в систему.
• Доля запрещённых действий, которые агент попытался совершить. Единственная метрика с абсолютным порогом: ноль.
• Условия прогона: на каких данных, в какой среде, кем запускается, как фиксируется результат.

Что проверка прогоном это штатная инженерная практика, видно по документации разработчиков агентских фреймворков: в руководстве OpenAI по агентам есть разделы «Guardrails and human review» и «Integrations and observability», а Agents SDK описан как дающий проверки на входе, на выходе и на вызове инструмента плюс возобновляемые сценарии подтверждения.

Кто отвечает деньгами за ошибочное действие агента

Агент отправил не тот счёт, закрыл сделку как проигранную, списал остаток. Кто платит.

Пункт 3 статьи 401 ГК РФ: лицо, не исполнившее обязательство при осуществлении предпринимательской деятельности, отвечает, если не докажет, что исполнение оказалось невозможным вследствие непреодолимой силы. Там же прямо сказано, что к таким обстоятельствам не относится нарушение обязанностей со стороны контрагентов должника. Аргумент «модель поставщика повела себя иначе» под освобождение не подпадает. Пункт 4 той же статьи: заключённое заранее соглашение об устранении или ограничении ответственности за умышленное нарушение ничтожно, поэтому оговорка «исполнитель не отвечает за любые последствия работы агента» в части умысла не работает вовсе.

Работающая конструкция строится не через общий пункт о рисках, а через таблицу прав из предмета договора:

• действие внутри разрешённого перечня, приведшее к убытку, зона исполнителя, убытки возмещаются по статье 15 ГК РФ «Возмещение убытков»;
• действие вне перечня, ставшее возможным из-за доступа, который заказчик выдал сам, зона заказчика;
• действие, требовавшее подтверждения человека и подтверждённое человеком, зона заказчика независимо от того, что предложил агент.

Третий пункт объясняет, почему графа «требуется подтверждение человека» дороже, чем кажется: она не про удобство, а про распределение убытка.

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

Если агент читает переписку с клиентами, карточки в CRM или заявки, подрядчик обрабатывает персональные данные по вашему поручению. Часть 3 статьи 6 Федерального закона от 27.07.2006 № 152-ФЗ задаёт обязательное содержание поручения: перечень персональных данных, перечень действий с ними, цели обработки, обязанность соблюдать конфиденциальность, требования, предусмотренные частью 5 статьи 18 и статьёй 18.1, требования к защите по статье 19 и уведомление оператора об инцидентах.

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

Внешняя модель меняет схему ответственности. По части 5 статьи 6 перед субъектом за действия обработчика отвечает оператор, то есть вы, а обработчик отвечает уже перед вами. По части 6, если обработка поручена иностранному физическому или юридическому лицу, перед субъектом отвечают оба. Добавляется и отдельная обязанность: по части 3 статьи 12 оператор до начала трансграничной передачи уведомляет уполномоченный орган о намерении её осуществлять, причём отдельно от уведомления по статье 22.

Практический вывод для договора: фиксируется, в какой юрисдикции работает модель, и запрет менять поставщика без согласования. Перенос вызовов на зарубежный эндпоинт это не техническое решение подрядчика, а новое основание для уведомления. По той же причине предел ответственности исполнителя, привязанный к стоимости работ, обсуждается отдельно: по части 15 статьи 13.11 КоАП РФ нарушение из числа предусмотренных частями 12-14, совершённое повторно, влечёт для юрлица штраф от 1 до 3 процентов совокупной выручки за предшествующий календарный год, но не менее 20 миллионов и не более 500 миллионов рублей, и взыскивается он с оператора, а не с подрядчика.

Комплект передачи: что физически переходит заказчику

Фраза «код и доступы ваши» ничего не гарантирует, пока в акте не перечислено, что именно передаётся. У агента комплект отличается от обычной разработки: значительная часть поведения хранится не в коде.

1. Системный промпт и все его версии, действовавшие на момент сдачи.
2. Описания инструментов: JSON-схемы функций, которые агент вправе вызывать, вместе с текстами описаний, по которым модель выбирает вызов.
3. Эвал-набор и протокол последнего прогона с датой и результатом по каждой метрике.
4. Экспорт конфигурации из оркестратора в машиночитаемом виде, а не скриншоты рабочего пространства.
5. Доступ к трассировке запусков за согласованный срок хранения: без логов вызовов ошибочное действие постфактум не разобрать.
6. Ключи и учётные записи у поставщика модели с явным ответом, на чьём аккаунте агент работает после сдачи.

Последний пункт пропускают чаще всего. Если после подписания акта агент ходит в модель по ключу подрядчика, заказчик владеет не решением, а его описанием, которое умрёт в день отключения ключа. В акте это одна строка: владелец аккаунта и дата переноса.

Смена версии модели: риск, которого нет у скриптового бота

У обычной программы поведение меняется, только когда кто-то правит код. У агента оно меняется без единой правки, когда поставщик выводит версию модели из обслуживания или публикует новую. Это опубликованный регламент вендоров, а не гипотеза.

• OpenAI. Страница deprecations фиксирует политику: не менее 6 месяцев для общедоступных моделей, не менее 3 месяцев для специализированных вариантов, для preview уведомление может быть короче, вплоть до 2 недель. Пример цикла: 11 июня 2026 объявлено о выводе gpt-5-2025-08-07 и o3-2025-04-16 с отключением 11 декабря 2026. Отдельно на 30 ноября 2026 назначено отключение платформы Evals и Agent Builder: из обслуживания выводят не только модели, но и инструменты вокруг них.
• Anthropic. Минимум уведомления 60 дней. Реальный цикл: claude-opus-4-1-20250805 объявлен устаревшим 5 июня 2026 и выведен 5 августа 2026, запросы к выведенной модели перестают выполняться.
• Yandex AI Studio. В документации прямо сказано: после окончания срока поддержки запросы по устаревшему URI возвращают ошибку 400 Bad Request, автоматическое переключение между версиями не предусмотрено, а при переходе нужно заново проверить промпт и заново дообучить модель, если использовалась дообученная.
• GigaChat. В каталоге Сбера одновременно GigaChat 3 Ultra и линейка GigaChat 2 (Max, Pro, Lite): смена поколения идёт своим темпом и её тоже придётся отрабатывать.

Сценария два. Жёсткий: URI перестал отвечать, агент встал, дата известна заранее. Мягкий и более опасный: версия сменилась в пределах алиаса вроде latest, агент работает, но иначе, и видно это по кривым метрикам через две недели.

Договор на разработку ии агента: пункт про смену версии модели

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

• Триггер: объявление вендора о выводе версии, фактическая смена версии за алиасом, изменение схемы вызова функций.
• Обязанность отслеживания. Кто именно читает страницу deprecations и рассылку вендора. Названная сторона, а не «стороны совместно».
• Повторный прогон эвал-набора на новой версии и передача протокола заказчику. Ровно того набора, иначе сравнивать не с чем.
• Порядок и срок работ, если показатели упали ниже порога приёмки.
• Оплата. Внутри гарантийного срока и вне его это разные деньги, договориться о них надо до первой смены версии.

Ориентир по срокам берётся из политик вендоров: раз минимальное уведомление 60 дней у Anthropic и от 3 до 6 месяцев у OpenAI, обязанность прогнать эвалы и отчитаться разумно уложить в первую треть окна. Остаётся запас на доработку промпта и описаний инструментов.

Частые вопросы

Чем акт приёмки на агента отличается от акта на бота

Приложением с результатами прогона эвал-набора и оговоркой о праве предъявить требования по итогам наблюдения. Без неё пункт 3 статьи 720 ГК РФ лишает заказчика права ссылаться на явные недостатки.

Зачем в договоре срок хранения журналов вызовов агента

Без них не провести экспертизу по пункту 5 статьи 720 ГК РФ. Спор о том, что именно сделал агент и почему, разбирается по записям запусков: повторить прошлое поведение модели на той же задаче постфактум нельзя.

Нужно ли соглашение по персональным данным, если агент только читает CRM

Да. Чтение входит в перечень действий с данными, а часть 3 статьи 6 152-ФЗ требует определить этот перечень в поручении вместе с целями и требованиями к защите по статье 19.

За сколько вендор предупреждает о выводе версии модели

Anthropic: не менее 60 дней для публично выпущенных моделей. OpenAI: не менее 6 месяцев для общедоступных, не менее 3 месяцев для специализированных вариантов и вплоть до 2 недель для preview. Yandex AI Studio сроки числом не фиксирует, но предупреждает в истории изменений и рассылке.

Что будет, если ничего не менять после вывода версии из обслуживания

Агент перестанет работать: в Yandex AI Studio запросы по устаревшему URI возвращают 400 Bad Request и автоматического переключения нет, у Anthropic запросы к выведенной модели не выполняются.