Что скрывается в контракте на внедрение AI-агента

На стол легло техзадание и договор на 3,8 млн рублей: внедрить AI-агента в клиентскую поддержку интернет-магазина. Продавец обещает «автоматизацию до 80% обращений», интеграцию с CRM и запуск за восемь недель. Заказчик — средний ретейл, около 12 тысяч обращений в месяц. Имена и цифры оборота я изменил, структуру договора и формулировки оставил как есть, потому что именно в них вся суть. Ниже — что в таком документе работает против заказчика и что нужно вписать до подписи.

Что вообще заказали

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

• LLM — сама языковая модель. В договоре она чужая: подрядчик использует API стороннего провайдера. Значит, часть расходов и рисков — не его.
• RAG-слой — то, что подтягивает в ответ модели вашу базу знаний: карточки товаров, условия доставки, регламенты возврата.¹ Именно здесь живёт качество ответов.
• Оркестрация агента — логика, которая решает, когда бот отвечает сам, когда зовёт человека, когда лезет в CRM создавать заявку.

В смете подрядчик разбил стоимость на «разработку» (2,1 млн), «интеграцию» (0,9 млн) и «обучение и настройку» (0,8 млн). Строчки про оплату API модели в смете не было вообще. Это первая ловушка.

Где прячутся деньги: расходы на модель

Языковые модели тарифицируются по токенам — условным кускам текста на входе и выходе. Один диалог поддержки с подтягиванием базы знаний легко съедает несколько тысяч токенов на входе. При 12 тысячах обращений в месяц счёт провайдеру модели становится отдельной постоянной статьёй расходов, и платит его обычно заказчик со своего аккаунта.

В разобранном договоре об этом не было ни слова. На вопрос «а сколько будет стоить эксплуатация» подрядчик ответил устно: «копейки, зависит от нагрузки». Точную сумму назвать невозможно без пилота, и это нормально — ненормально, что её не заложили в договор даже диапазоном.

Цена внедрения — это разовый чек. Цена эксплуатации — это то, что вы будете платить каждый месяц годами. В плохом договоре первая цифра крупная и в рамке, вторая — устная и «копейки».

Что стоит потребовать до подписи: оценку месячных расходов на API при трёх сценариях нагрузки (низкая, плановая, пиковая) и указание, на чьём аккаунте провайдера крутится решение. Если на аккаунте подрядчика — вы привязаны к нему навсегда.

«До 80% автоматизации» — это не метрика

Ключевое обещание из коммерческого предложения — «автоматизация до 80% обращений». В теле договора этой цифры нет: она осталась в презентации. А в приёмке написано «работоспособность подтверждается успешной обработкой тестовых сценариев из Приложения №3». Приложение №3 — двадцать примеров, которые подрядчик составил сам.

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

1. Доля полностью автоматизированных диалогов — сколько обращений закрыто без участия оператора, за период не меньше двух недель на реальном трафике.
2. Доля некорректных ответов — считается на случайной выборке диалогов, которую проверяет заказчик, а не подрядчик.
3. Доля корректных эскалаций — как часто агент вовремя передаёт диалог человеку, вместо того чтобы выдумывать ответ.

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

Кто отвечает за ошибки агента

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

Полностью убрать эту оговорку подрядчик не согласится — и отчасти он прав, гарантировать поведение вероятностной модели на 100% нельзя. Но здоровый компромисс существует: подрядчик отвечает за то, что агент действует в рамках заданных ограничений. То есть не «бот всегда прав», а «бот не совершает действий, которые мы прямо запретили в конфигурации» — не оформляет возвраты сам, не называет цены вне прайса, не обещает сроки вне регламента.

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

Прежде чем платить 3,8 млн за кастомную разработку, стоит понять, чем она отличается от готовых путей. Сравнение — по состоянию на начало 2025 года, конкретные цены и лимиты меняются, сверяйте на сайтах вендоров.

Главная мысль: за 3,8 млн вы покупаете гибкость и интеграции, которых нет в коробочных решениях. Если ваши процессы типовые, эти деньги можно не тратить.

Кому такой контракт пригодится, а кому нет

Пригодится, если:

• у вас нестандартный процесс: агент должен ходить в собственную CRM, склад и платёжку одновременно, а коробочные боты этого не умеют;
• объём обращений большой и стабильный — тогда экономия на операторах перекрывает и разработку, и ежемесячные расходы на модель;
• у вас есть человек, который сможет владеть решением после сдачи: читать логи, править базу знаний, отслеживать метрики.

Не пригодится, если:

• обращений мало или они сезонные — фиксированный чек за разработку не отобьётся;
• процессы типовые: «где заказ», «как вернуть» — с этим справится готовая платформа за подписку;
• внутри некому поддерживать систему, а подрядчик берёт за сопровождение отдельные деньги, о которых в договоре опять же ни слова.

Чек-лист перед подписью

1. Расходы на API модели — заложены в договор диапазоном и указано, на чьём аккаунте всё работает.
2. Метрики приёмки — измеримые, замер на реальном трафике, выборку для проверки формирует заказчик.
3. Ограничения агента — прямо перечислено, чего бот не делает никогда.
4. Права на код и конфигурацию — переходят к вам, а не остаются у подрядчика.
5. Стоимость сопровождения после запуска — отдельным пунктом, а не «обсудим потом».
6. Выход из зависимости — что вы получаете на руки, если решите сменить подрядчика.

¹ RAG (retrieval-augmented generation) — подход, при котором модель перед ответом подтягивает релевантные куски из вашей базы знаний и опирается на них. Снижает выдумывание, но качество ответа напрямую зависит от того, насколько чисто и полно собрана база.