Обычный договор на разработку описывает мир, в котором программа ломается по вине исполнителя. Отсюда гарантийный срок, порядок приёмки, ответственность за дефекты. Всё это держится, пока продукт состоит из кода, который обе стороны видят и контролируют.
AI-агент устроен иначе. Кроме кода в нём есть арендованная модель, набор текстовых инструкций к ней и права доступа к вашим системам. Код никуда не денется, а вот у модели свой график жизни. Пишет его поставщик.
Почему у модели, на которой работает ваш агент, есть дата снятия?
Поставщики моделей описывают этот график публично. Anthropic делит модели на четыре состояния: active — полная поддержка; legacy — обновлений больше не будет; deprecated — модель ещё работает, но ей уже назначена дата снятия и рекомендована замена; retired — запросы падают с ошибкой.
О снятии публично выпущенной модели Anthropic предупреждает минимум за 60 дней тех клиентов, у кого она работает в проде. OpenAI ведёт такой же публичный список устаревших моделей с датами отключения. Отдельно в документации сказано, что партнёрские платформы, Amazon Bedrock и Google Cloud, назначают собственные даты. Статус одной и той же модели в облаке, где крутится ваш агент, может отличаться от статуса в API поставщика, и узнаете вы об этом в самый неудачный момент.
Второе, что стоит знать до подписания: переход на новую версию требует работы — и не той, которую закладывает заказчик. У себя мы измерили это так. Весной 2026 года в Grow2.ai, нашем AI-подразделении, переводили собственный парк агентов на следующую версию модели: пришлось переписать системные промпты и починить несколько багов в обвязке вокруг модели, которые предыдущая, более медленная версия успешно маскировала. Отдельно правили API-конфиги: фиксированный бюджет на «размышления» модели уступил место адаптивному — то есть лимит, в который мы раньше укладывали расходы, в новой версии считается иначе. Это наш собственный замер на собственном парке, а не отраслевая норма.
Ни одна из этих работ не выглядит как «поменять строку с названием модели». И ни одна не описана в типовом SOW.
Блок 1. Почему промпты — это продукт и им место в deliverables?
В SOW есть таблица результатов работ с колонкой критериев приёмки. Для CRM-проекта в ней стоят понятные вещи: отчёт об обследовании, настроенная воронка, импортированная база. У агента большая часть ценности лежит в текстах, которые до этой таблицы не доходят.
Что должно попасть в перечень:
- системные промпты всех ролей агента с историей версий, а не последний файл на момент сдачи
- конфигурация модели: идентификатор, параметры вызова, лимиты и ограничения
- evaluation-набор — сценарии с заранее описанным ожидаемым результатом
- описания инструментов и схемы вызовов, включая права, которые учётная запись агента получает в ваших системах
- журнал решений: почему промпт сформулирован именно так, какие варианты отбросили и по какой причине
Самая ценная строка здесь — третья. Evaluation-набор — это то, чем вы через полгода докажете, что после обновления модели агент ведёт себя иначе. Без него обе стороны будут описывать качество словами, а слова в споре ничего не весят. Составить такой набор — отдельная работа на несколько дней, и она должна либо входить в объём работ, либо быть честно вынесена за его пределы с отдельным ценником.
Приёмку стоит привязать к тому же набору. В типовых шаблонах у заказчика есть несколько рабочих дней на письменную приёмку или мотивированный отказ, и молчание нередко засчитывается как приёмка. Для агента «посмотреть глазами» за эти дни почти ничего не даёт: приёмка должна означать прогон evaluation-набора и зафиксированный результат по каждому сценарию.
Блок 2. Чем лицензия на промпты отличается от права собственности на них?
Раздел об интеллектуальной собственности в типовом IT-договоре устроен так. Каждая сторона сохраняет за собой то, что имела до начала работ или создала независимо от них, — это background IP. А на результаты работ заказчик получает лицензию: после полной оплаты, всемирную, бессрочную.
Дальше идут три слова. В CRM-проекте их никто не читает, в агентском стоит прочитать дважды: неисключительная, без права передачи, без права сублицензирования. И ещё уточнение «для внутренних нужд заказчика». Пользоваться промптами можно. Отдать их другой команде на доработку — по букве текста нельзя.
По другую сторону текста стоит право исполнителя на повторное использование. Стандартная формулировка позволяет ему забирать из проекта общие знания, приёмы, обобщённые библиотеки и фрагменты кода при условии, что конфиденциальная информация заказчика не раскрывается. Без этого пункта работа подрядчика теряет экономический смысл: он не может изобретать роутер заново под каждого клиента.
Разграничивать нужно по содержанию. Специфичным для заказчика стоит считать то, что содержит его терминологию, названия этапов сделок, правила скидок, скрипты отдела продаж, перечень исключений из политики. Общим — архитектуру решения и шаблоны, из которых всё перечисленное вырезано. Эту границу лучше описать двумя-тремя примерами прямо в SOW: в абстрактной формулировке она расползается за первый же месяц работы.
Блок 3. Как прописать процедуру миграции модели?
Каркас для этого блока в договоре уже есть — раздел об управлении изменениями. Любая сторона подаёт письменный запрос, исполнитель оценивает влияние на объём, сроки и стоимость, изменение вступает в силу после подписания обеими сторонами. Не хватает одного: триггера, который не зависит от желания сторон.
Триггер здесь — публикация поставщиком даты снятия или перевод модели в deprecated. Дальше описывается, кто что делает:
- кто отслеживает объявления поставщика и в какой срок уведомляет другую сторону
- сколько времени отводится на анализ влияния с момента объявления
- прогон evaluation-набора на новой модели до переключения, с письменным отчётом о расхождениях
- будет ли окно параллельной работы старой и новой версий и кто его оплачивает
Деньги — там, где чаще всего дыра. Слово «поддержка» в договоре обычно не имеет определения, и каждая сторона понимает его в свою пользу. Разделять стоит так: прогон набора и отчёт о расхождениях входят в поддержку, а переписывание промптов сверх согласованного объёма часов идёт отдельным change order по ставке из договора. Количество часов ставите своё, исходя из размера агента, только не оставляйте его неназванным.
О гарантии отдельно. Гарантийный срок на соответствие спецификации в типовых договорах считается неделями после приёмки, а не месяцами. Миграция, которая случится через восемь месяцев, в это окно не попадает ни при каком толковании, так что ссылаться на гарантию в таком разговоре бесполезно. Либо вы договорились о миграции отдельным блоком, либо вы о ней не договорились.
Блок 4. Что считать неудачной миграцией?
«Агент работает после обновления» — не критерий приёмки: критерий должен быть сравнительным и числовым. Как снять базовый замер, из которого берётся это число, и как сформулировать порог в SOW, разобрано отдельно, в материале о доле приёмки; здесь важно только одно: в договоре должна стоять цифра, а не прилагательное.
Выглядит это примерно так: на том же evaluation-наборе доля сценариев, пройденных без вмешательства человека, не ниже базового значения, зафиксированного до миграции, с допуском, который вы согласовали заранее. Базу фиксируют протоколом: дата, идентификатор модели, результат по каждому сценарию отдельно.
Здесь же стоит расписать, что происходит, когда показатель не достигнут. Наш порядок приёмки даёт два цикла доработки, после чего заказчик вправе расторгнуть SOW. Переносить эту схему в миграцию напрямую рискованно для обеих сторон: расхождение может оказаться свойством новой модели, а не качеством работы исполнителя. Более разумный выход — откат на предыдущую модель, пока она ещё доступна, и пересмотр объёма до даты её снятия.
Бывает вариант и хуже: часть сценариев на новой модели не восстанавливается вообще, сколько ни переписывай промпт. Именно поэтому в договоре должно быть записано, кто оплачивает выяснение этого факта. Иначе выяснение превращается в спор о том, кто виноват, и длится дольше самой миграции.
Чего договор всё равно не гарантирует?
Отдельный «договор на AI» для этого не нужен: все четыре блока ложатся в существующие разделы рамочного договора и SOW. Но граница есть, и о ней лучше сказать вслух до подписания.
Чего мы не делаем: не обещаем, что миграция будет бесплатной, и не гарантируем, что поведение агента сохранится один в один после смены модели. Такую гарантию не может дать никто, кто не пишет модель сам. Договориться можно о порядке действий, распределении расходов и критерии — этого достаточно, чтобы обновление модели не превратилось в конфликт.
Что проверить в действующем договоре
- откройте действующий договор и поищите в перечне результатов работ слово «промпт» — если его там нет, это первая правка
- спросите подрядчика, существует ли evaluation-набор для вашего агента и где он хранится
- проверьте в документации поставщика, какой статус у модели, на которой вы работаете сейчас
Третий пункт занимает пять минут и регулярно оказывается самым неприятным: модель, на которой запускались полгода назад, уже стоит в списке deprecated с назначенной датой.
Если после этой проверки у вас на руках договор, в котором нет ни одного из четырёх блоков, — пришлите его нам. За одну встречу разберём, каких блоков не хватает, что править первым и что из этого вообще подлежит переговорам.
И мелочь, которая почему-то никогда не попадает в договор, а потом стоит недели: у кого лежат ключи API и на какое юридическое лицо оформлен аккаунт у поставщика модели. Проверьте это при случае.