На вопрос «сколько стоит ИИ в месяц» обычно отвечают про токены. Токены — заметная, но не главная часть. Через год после запуска деньги уходят на обновление базы знаний, проверку качества после смены версии модели, ремонт интеграций и время ваших сотрудников. Мы называем ориентир 15–25% стоимости проекта в год. Разберем, из чего складывается эта цифра, когда бюджет уходит к нижней границе, а когда к верхней, и как проверить смету поддержки до подписания договора.
Откуда берется ориентир 15–25%
Это доля от стоимости проекта, которую мы закладываем на год эксплуатации. Разброс определяют две вещи: как быстро меняются ваши данные и окружение системы и насколько система критична для процесса. Если поток или требования к качеству вырастут, ориентир пересматривают, и это нормально, а не признак ошибки в смете.
В ориентир не входят две статьи, которые считают отдельно: оплата модели — токены облачного сервиса или свое оборудование — и время ваших сотрудников. Ниже — что лежит внутри 15–25% и что рядом с ними.
Статья первая: модель и инфраструктура
Эту статью считают отдельно от 15–25%. В облаке вы платите за каждое обращение токенами. В своем контуре платите за серверы, размещение, питание, резервирование и людей, которые это обслуживают. Такие расходы считают на два-три года, а не на месяц. В контуре к ним добавляются обновления драйверов и библиотек и замена отказавших компонентов. Если сервер с моделью один, его отказ останавливает сервис, а резервный сервер удваивает стоимость оборудования.
Счет за токены растет по трем причинам. Длинный контекст: в ассистенте с поиском по документам в модель уходит не только вопрос, но и найденные фрагменты. Повторные запросы: проверка ответа вторым обращением удваивает счет. Рост потока: пилот на сотне запросов в день стоит копейки, а при десяти тысячах картина другая.
Статья вторая: база знаний и данные
Документы меняются: выходят новые тарифы, регламенты, продукты. Если новые не добавлять, а старые не убирать, ассистент продолжит отвечать по прошлогоднему прайсу — уверенно и со ссылкой на источник. Пользователь увидит ссылку и поверит.
Значит, нужен процесс: кто добавляет документы, кто снимает устаревшие, как часто обновляется поисковый индекс. Переиндексацию автоматизируют, а решение о том, какой документ действует, остается за владельцем базы знаний с вашей стороны.
Для моделей на табличных данных то же самое называется переобучением: данные смещаются, и модель надо обучать на свежих. По расписанию или по сигналу мониторинга — зависит от того, как быстро меняется процесс.
Статья третья: контроль качества
Мониторинг показывает, работает ли система технически: отвечает ли, сколько ждет пользователь, нет ли сбоев. Качество ответов он не показывает. Для этого нужны регулярные проверки.
- Прогон проверочного набора по расписанию и после каждого изменения.
- Выборочный разбор реальных диалогов или решений — например, сотни в месяц.
- Дашборд с долей передач оператору, долей отказов и оценками пользователей.
- Оповещения при резком сдвиге метрик.
Без этого о падении качества узнают из жалоб, когда доверие уже потеряно. Вернуть его дороже, чем держать проверки.
Статья четвертая: смена версий модели
Облачные провайдеры обновляют модели и снимают старые версии с поддержки. Каждый переход — это прогон проверочного набора, сравнение с прежней версией и правка промптов. Даже улучшенная версия может иначе форматировать ответ или чаще отказывать.
С открытыми моделями в своем контуре переход добровольный. Но раз в несколько месяцев выходят заметно более сильные или более дешевые модели, и оставаться на старой бывает невыгодно. Закладывайте хотя бы одну плановую смену модели в год.
Статья пятая: изменения вокруг системы
Интеграции ломаются, когда меняются соседи: вышло обновление CRM, сменилась версия API, в форму добавили поле, учетную систему перевели на новую конфигурацию. Каждое такое изменение — это проверка и правка интеграции. Например, менеджеры начали заводить в CRM новый тип сделок, а интеграция его не знает и молча пропускает.
Сюда же просится развитие. После запуска пользователи хотят больше: новый тип документов, новый канал, еще один отдел. Это не поддержка, а новая разработка. Если ее не отделить, поддержка незаметно превращается в разработку без бюджета, и обе делаются плохо.
Статья шестая: время ваших сотрудников
Этой строки нет в счете подрядчика, но она реальная. Операторы разбирают вопросы, которые бот передал. Специалисты отвечают на новые вопросы и пополняют проверочный набор. Владелец базы знаний следит за актуальностью документов. Владелец системы раз в месяц смотрит на метрики и решает, что делать с отклонениями.
Если бот передает человеку, например, каждый седьмой диалог, операторы остаются частью решения. Их время надо закладывать в расчет окупаемости сразу, а не обнаруживать после запуска.
Первые месяцы дороже остальных
Расходы на поддержку распределены неравномерно. Первые два-три месяца после запуска самые плотные: живые пользователи задают вопросы, которых не было в наборе, всплывают пробелы в базе знаний, интеграции встречают редкие случаи. Разбор идет ежедневно, правок много.
Потом система стабилизируется, и поддержка переходит в регламентный режим: проверки по расписанию, обновление документов, реакция на изменения вокруг. Поэтому годовой бюджет разумно распределять неравно, с большей долей на первый квартал, и договориться об этом заранее, а не спорить потом о переработках.
Где бюджет уходит к нижней границе, а где к верхней
- Ближе к нижней: стабильный процесс, документы меняются редко, одна интеграция, облачная модель. Пример — распознавание документов известных типов.
- Ближе к верхней: данные меняются быстро, цена ошибки высокая, несколько интеграций, свой контур. Пример — ассистент по часто меняющимся тарифам или рекомендации в рознице.
Закладывая бюджет, смотрите не только на модель, но и на окружение: интеграции, которые ломаются после обновлений, и базу знаний без владельца. Именно там появляются незапланированные работы.
Практический прием: разделите бюджет поддержки на две строки — регламентные работы и резерв на изменения вокруг системы, например 15–20% от первой строки. Неизрасходованный резерв переходит на развитие, и спорить о каждой внеплановой правке не придется.
Что поддерживать в разных типах решений
Ассистент с поиском по документам
Основная работа — база знаний и качество ответов: добавление и снятие документов, прогоны проверочного набора, смена версий модели. Плюс оплата модели и время операторов на переданные вопросы.
Модель на табличных данных
Прогноз, оценка клиентов, сопоставление товаров. Здесь главное — дрейф данных и переобучение: следить, не сместились ли входные данные, и переобучать по расписанию или по сигналу. Ломается при этом нередко не модель, а конвейер данных, когда меняется источник.
Компьютерное зрение на линии
Меняется освещение и оснастка, появляются новые типы дефектов. Каждое такое изменение требует новых снимков, разметки и дообучения. Отдельная статья — устройства на линии: камеры и вычислители, их замена и обновление.
Распознавание документов
Контрагенты меняют формы документов, появляются новые типы. Если форм немного и они стабильны, это как раз случай нижней границы ориентира. Основная работа — разбор исправлений операторов и дообучение на них.
Пример расчета
Посчитаем условный ассистент для сотрудников, чтобы цифры стали осязаемыми.
Условный пример. Пилот ассистента обошелся в 2,5 млн ₽ — середина вилки пилота. Поддержка по ориентиру 15–25% — 375–625 тыс. ₽ в год, или около 31–52 тыс. ₽ в месяц. В эту сумму входят мониторинг, ежемесячный прогон проверочного набора, переиндексация базы знаний, разбор ошибок и одна плановая смена версии модели в год. Отдельно — токены: 500 запросов в день по 3 тыс. токенов на модели уровня GigaChat Pro по тарифу Сбера для юрлиц на осень 2026 года. Это около 750 ₽ в день, порядка 16 тыс. ₽ в месяц при 22 рабочих днях. И отдельно — время ваших сотрудников на базу знаний и спорные вопросы.
В этом примере токены — от трети до половины суммы на поддержку. Но стоит увеличить поток в десять раз или перейти на более тяжелую модель, и пропорция меняется. Поэтому оплату модели считают на планируемый объем, а не на объем пилота.
Что записать в договор поддержки
- Состав работ: что входит в ежемесячную часть, а что оплачивается отдельно как развитие.
- Время реакции на инциденты разной критичности.
- Регламент проверки качества: как часто прогоняют проверочный набор и в каком виде вы получаете отчет.
- Порядок смены версии модели: кто инициирует, как проверяют, как откатывают.
- Передачу: что остается у вас, если поддержку переносите к другому подрядчику или в свою команду.
В нашем пакете промышленного внедрения поддержка идет от 12 месяцев, с соглашением об уровне сервиса — SLA. Но такое соглашение ценно, только если в нем перечислены работы, а не обещание «сопровождать».
Что должно быть в ежемесячном отчете
Хороший отчет о поддержке помещается на одну страницу и отвечает на вопрос, стала ли система за месяц лучше или хуже.
- Доля обращений, закрытых без участия человека.
- Доля выдуманных ответов и корректных отказов на проверочном наборе.
- Время ответа и число инцидентов.
- Расходы на модель: токены или загрузка своего оборудования.
- Что изменилось: обновленные документы, правки промптов, новая версия модели.
Отчет без последнего пункта трудно читать: метрики сдвинулись, а причина неизвестна.
Как проверить смету поддержки до подписания
Смета поддержки должна читаться так же, как смета проекта: работы, их частота и цена. Вот признаки, что с ней что-то не так.
- Одна сумма в месяц без перечня работ.
- Нет регулярного отчета о качестве — только о доступности сервиса.
- Не названа ставка на доработки, которые не входят в поддержку.
- Смену версии модели обещают делать «по необходимости», без проверки на наборе.
- Непонятно, что останется у вас при переходе к другому подрядчику.
Задайте подрядчику простой вопрос: что конкретно вы будете делать в обычный месяц, когда ничего не сломалось? Если ответ укладывается в слово «мониторинг», уточняйте.
Как сократить расходы без потери качества
- Короче контекст: меньше фрагментов в запросе при том же качестве ответов.
- Маршрутизация: простые запросы — легкой модели, сложные — тяжелой.
- Повторное использование ответов на частые одинаковые вопросы.
- Автоматическая переиндексация вместо ручной.
- Минимальный набор мониторинга вместо полной платформы, пока модель одна.
Каждую меру проверяют на проверочном наборе. Экономия, которая снижает качество, — не экономия: ее съедят ошибки и время операторов.
Своя команда или подрядчик на поддержке
Поддержку можно забрать в свою команду, но только если в ней есть человек, который знает устройство системы, и у него есть на это время. Часто удобнее гибрид: регламентные проверки и мониторинг делает подрядчик, а базу знаний и разбор спорных случаев ведут ваши сотрудники.
В любом варианте у системы должен быть владелец со стороны бизнеса. Без него поддержка превращается в оплату счетов, которые никто не проверяет.
Почему отказ от поддержки не экономит
Система без поддержки не перестает работать в первый же день. Она тихо стареет: документы устаревают, данные смещаются, провайдер снимает с поддержки версию модели. Через год ее приходится чинить в авральном режиме, часто уже без людей, которые помнят, как она устроена.
Экономия на поддержке похожа на отказ от техобслуживания машины: первые месяцы ничего не происходит, а потом ремонт обходится дороже всех пропущенных визитов в сервис. Срочная доработка через год стоит больше, чем регламентная работа за все это время, и делается в спешке.
Когда поддержка дороже пользы
Честная точка выхода есть и после запуска. Если через год система обрабатывает меньше операций, чем планировали, а поддержка стоит дороже часов, которые она экономит, систему надо упростить или выключить. Сравнение простое: месячная стоимость поддержки и оплаты модели против сэкономленных часов, умноженных на стоимость часа.
Это не провал: процессы меняются, и решение, полезное год назад, может стать лишним. Хуже платить за систему по инерции.
Условный пример: поддержка и оплата модели обходятся в 50 тыс. ₽ в месяц, а система экономит 40 часов работы при стоимости часа 800 ₽, то есть 32 тыс. ₽. Пока поток не вырастет или поддержку не упростят, такая система работает в минус, и это видно в первом же квартальном отчете.
Коротко
- Ориентир на поддержку — 15–25% стоимости проекта в год. Оплата модели и время ваших сотрудников считаются отдельно.
- Деньги уходят на обновление базы знаний, контроль качества, смену версий модели и ремонт интеграций.
- Токены при умеренном потоке — заметная, но не главная статья, а с ростом потока их считают заново.
- Развитие и поддержку разделяют, иначе поддержка тихо превращается в разработку без бюджета.
- В договоре поддержки фиксируют состав работ, регламент проверки качества и порядок смены модели.
- Если поддержка стоит дороже пользы, систему упрощают или выключают.