Из каких частей складывается стоимость AI-агента?
AI-агент — это цифровая система, которая получает задачу, обращается к нужным данным и сервисам, выбирает следующее действие по заданным правилам и возвращает результат либо выполняет разрешённую операцию. Например, разбирает входящее обращение, находит сведения о клиенте, готовит ответ и создаёт задачу сотруднику.
Поэтому стоимость агента — это не цена одной нейросети и не плата за красивое окно с перепиской. Бизнес оплачивает весь рабочий контур вокруг неё. Я бы разделил его на несколько частей: описание сценария, подготовку данных, подключения к другим системам, разработку логики, проверку качества, защиту доступа и запуск в реальном процессе.
Сценарий определяет, что именно система получает на входе, какие решения может принимать и каким должен быть итог. Фраза «нужен агент для отдела продаж» почти ничего не говорит о будущей работе. Агент может только составлять черновик ответа, а может проверять CRM, подбирать предложение, менять статус сделки и ставить задачу менеджеру. Это проекты разного масштаба.
Отдельная часть стоимости — исходные данные. Если регламенты, цены и сведения о клиентах хранятся в понятном виде, подготовка будет сравнительно простой. Если информация разбросана по таблицам, перепискам и памяти сотрудников, сначала придётся определить, чему вообще можно доверять. Нейросеть не исправляет беспорядок автоматически: она способна лишь быстрее воспроизводить его последствия.
Подключения нужны, когда агент должен работать не в изоляции. CRM, почта, корпоративная база знаний, телефония, календарь и учётная система имеют разные способы обмена данными. Иногда хватает готового соединения, иногда требуется отдельная программная связка.
Наконец, в стоимость входят проверки. Недостаточно увидеть несколько удачных ответов на демонстрации. Нужно собрать реальные примеры, определить приемлемый результат, проверить спорные случаи и понять, как система ведёт себя при нехватке информации. Именно эта работа превращает эксперимент с нейросетью в рабочий инструмент.
Почему нельзя точно оценить проект по одной фразе?
Есть три внешне похожих подхода, и их легко перепутать при обсуждении бюджета. Первый — чат-бот: он ведёт диалог и отвечает в пределах доступного контекста. Второй — обычная автоматизация: заранее заданное событие запускает фиксированную последовательность действий. Третий — агентный сценарий, где часть промежуточных решений зависит от содержания конкретной задачи.
Допустим, руководитель просит «агента, который обрабатывает заявки». В простом варианте это форма и шаблонное уведомление менеджеру. Более содержательный вариант классифицирует обращение и готовит черновик ответа. Сложный вариант дополнительно ищет клиента в CRM, проверяет историю общения, уточняет недостающие сведения, выбирает маршрут и записывает результат обратно.
На словах все три варианта обрабатывают заявки. Но объём проекта определяется не общей формулировкой, а количеством решений, источников данных, внешних действий и исключений. Даже один глагол может скрывать разную работу. «Проверить договор» иногда означает найти пропущенные поля, а иногда — сопоставить текст с несколькими правилами и объяснить расхождения.
На оценку влияет и состояние процесса до разработки. Если сотрудники одинаково понимают порядок действий, его легче перенести в цифровой сценарий. Если каждый работает по-своему, сначала надо договориться о нормальном маршруте. Такая неопределённость не видна в коротком описании, но заметно меняет объём анализа и тестирования.
Поэтому на вопрос «сколько стоит создать ИИ-агента» нельзя честно ответить по названию отдела или одной желаемой функции. Предварительная оценка появляется после разбора нескольких реальных случаев: от входных данных до результата, который бизнес готов принять.
Какие функции сильнее всего увеличивают бюджет?
Дешевле всего начинать с узкой задачи, где агент готовит материал для дальнейшего решения: сводку, классификацию, черновик письма, список расхождений или заполненную карточку. Здесь понятен результат, а ошибку можно заметить до того, как она повлияет на клиента, деньги или учёт.
Бюджет растёт, когда задача требует свободной работы с неоднородными документами. Одно дело — извлечь одинаковые реквизиты из типовых файлов. Другое — сопоставить договоры разных форматов, переписку, внутренние правила и историю отношений с контрагентом. Чем больше вариантов входных данных и допустимых трактовок, тем больше примеров нужно разобрать и проверить.
Следующий заметный фактор — право совершать действия. Подготовить письмо дешевле и спокойнее, чем отправить его без подтверждения. Показать рекомендуемое изменение в CRM проще, чем самостоятельно менять данные. Особенно дорого обходятся цепочки, где одна неточность запускает несколько последующих операций.
Сильно увеличивают объём проекта задачи с высокой ценой ошибки: финансовые решения, юридически значимые документы, кадровые действия, управление доступами и публичные ответы от имени компании. В таких процессах нужен контроль человека, понятный журнал действий и возможность остановить либо отменить операцию. Полезная граница здесь проста: чем труднее заметить и исправить ошибку, тем осторожнее должна быть самостоятельность системы.
Плохо подходят для первого запуска процессы без ясного результата, устойчивых правил и владельца. Если никто не может уверенно объяснить, как выглядит хороший итог, агенту тоже не на что опереться. Неудачным стартом будет и задача, где редкие исключения важнее обычного потока.
А вот повторяющаяся интеллектуальная работа с проверяемым результатом подходит лучше: разбор обращений, подготовка материалов, поиск по внутренним сведениям, предварительная сверка документов. В таких случаях можно ограничить полномочия, сохранить проверку сотрудником и постепенно оценить реальную пользу.
Какие регулярные расходы останутся после запуска?
После запуска остаётся сама система и её эксплуатация. Первый постоянный расход связан с обращениями к AI-модели. Обычно оплачывается объём обработанного текста и полученных ответов. Чем длиннее документы, история диалога и инструкции, тем выше расход на одну операцию. Если используются распознавание речи, обработка изображений или другие модели, они учитываются отдельно.
Второй слой — инфраструктура: место, где работает логика агента, хранится служебная информация и выполняются фоновые задачи. Сюда могут входить сервер, база данных, файловое хранилище, резервные копии и технические журналы. Журнал нужен, чтобы видеть, что получила система, какое действие выбрала и где возникла проблема.
Третий слой — внешние сервисы. CRM, телефония, рассылки, поиск, электронный документооборот и другие платформы могут брать плату за тариф, пользователя или количество обращений к программному интерфейсу. Программный интерфейс, или API, — это способ, через который одна система запрашивает данные или передаёт команду другой.
Есть и сопровождение. Меняются процессы, документы, тарифы и способы подключения сервисов. Появляются новые типы запросов, которых не было в первоначальной выборке. Поэтому рабочий агент требует наблюдения: проверки ошибок, обновления инструкций и периодического пересмотра тестовых примеров.
Регулярные расходы зависят не только от числа пользователей. Важны частота запусков, объём каждого запроса, количество подключений и требования к хранению данных. При оценке полезно считать не абстрактную цену технологии, а стоимость одной завершённой операции и месячный объём таких операций.
Как сократить первый этап без потери практической пользы?
Я начинаю не со списка желаемых возможностей, а с одного процесса и одного измеримого результата. Хорошая стартовая формулировка звучит примерно так: система получает конкретный набор материалов, готовит определённый результат, а назначенный сотрудник его проверяет. Всё, что не нужно для проверки этой гипотезы, можно временно убрать.
Для первого этапа стоит выбрать частую задачу с относительно одинаковыми входными данными. У неё должен быть владелец — человек, который понимает процесс и может разобрать спорные примеры. Полезно заранее собрать несколько обычных случаев, несколько сложных и хотя бы один неудачный. Это даст для оценки больше, чем длинное описание будущего продукта.
Сократить бюджет помогает ограничение каналов и подключений. Если результат сначала можно отдавать в привычную таблицу или внутренний интерфейс, необязательно сразу связывать агента со всеми системами компании. Если сотрудник готов подтверждать действие, не нужно на первом шаге строить полную самостоятельность. Если ценность можно проверить на одном типе документов, нет смысла сразу охватывать весь архив.
Экономить на первом этапе — не значит убрать проверки или защиту данных. Разумнее уменьшить ширину задачи: один отдел, один сценарий, один источник информации и понятный критерий готовности. После наблюдения за реальной работой станет видно, какие функции действительно нужны, а какие существовали только в первоначальном представлении.
Чтобы проверить применимость идеи к своему процессу, возьмите десять недавних однотипных задач и для каждой запишите входные материалы, действия сотрудника, итог и последствия возможной ошибки. Если маршрут в основном повторяется, результат можно проверить, а опасное действие оставить человеку, у проекта есть хороший кандидат для небольшого первого этапа.