AI-агенты в продакшене: экономия или новая статья расходов

Привет, я — Антон Фокин, CEO Qtim. За последний год запрос «хотим AI-агента» стал для бизнеса почти таким же типовым, как раньше «хотим приложение» или «можно нам личный кабинет». На презентации все выглядит просто: модель подключают к CRM, базе знаний, почте и нескольким сервисам, после чего она якобы сама начинает закрывать поддержку, разбирать документы и двигать процессы быстрее.

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

Интерес к теме при этом большой. Microsoft пишет, что 82% руководителей считают этот момент поворотным для пересмотра стратегии, а 81% ждут заметной интеграции агентов в контур компании в ближайшие 12–18 месяцев. Однако Deloitte показывает другую сторону: доступ сотрудников к GenAI растет, но лишь около 20% организаций действительно готовы управлять автономными агентными системами. Иначе говоря, денег и интереса уже много, а зрелых процессов вокруг технологии пока заметно меньше.

Главная ошибка начинается в формулировке задачи. Компания хочет не сократить конкретную ручную операцию, не ускорить понятный сценарий и не убрать узкое место, а просто «внедрить AI». Такая формулировка тз плохо годится для продакшена.

Рабочая постановка звучит иначе, например:

Вот с такими задачами уже можно работать.

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

Лучше всего AI функционирует там, где у бизнеса уже есть понятный процесс, большой поток однотипной работы и дорогой ручной труд.

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

Вторая зона — документы и заявки. Счета, договоры, анкеты, обращения, внутренние запросы. Там, где сотрудник тратит время не на решение по существу, а на классификацию, извлечение данных, проверку комплектности, сверку с регламентом и подготовку следующего шага, агент может заметно сократить нагрузку.

Третья зона — внутренние операционные сценарии, где данные лежат в нескольких системах. Например, когда нужно собрать контекст по клиенту, подготовить черновик ответа, проверить комплектность кейса. Эффект здесь возникает за счет того, что агент сокращает и объем ручных действий, и паузы между ними: быстрее собирает контекст и передает задачу дальше без лишних переключений.

LangChain в отчете по агентной инженерии пишет, что команды чаще всего спотыкаются о качество, надежность и наблюдаемость, а 89% респондентов прямо связывают успех агентных систем с нормальной трассировкой и контролем работы. Это хороший маркер зрелости темы: рынок уже обсуждает не «умеет ли ИИ отвечать», а «можно ли встроить его в рабочий процесс без потери контроля».

AI-ассистент обычно ошибается в одной и той же конфигурации:

В такой конструкции агент почти всегда начинает не экономить деньги, а создавать новую дорогую прослойку ручного контроля.

Anthropic в Economic Index пишет, что для сложных задач узким местом часто оказывается не сама модель, а доступ к нужному контексту. Для бизнеса это означает неприятный факт: слабая зона проекта часто находится не в AI-части, а в устройстве самой компании. Пока знания живут в переписке, а правила разбросаны по документам и людям, агенту просто не на что опереться.

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

Самая частая ошибка — считать только стоимость модели, токенов и пилота. Это логика демо, продакшен живет по другой математике.

Первая статья расходов — качество. Нужно собрать реальные кейсы, описать хороший и плохой результат, прогонять проверку после каждого изменения модели, промпта, инструмента или базы знаний. В Anthropic называют отсутствие такой системы состоянием, когда приходится действовать вслепую после завершения раннего прототипирования. Если нельзя понять, стало решение лучше или хуже, значит им невозможно управлять.

Вторая статья — наблюдаемость. Google Cloud отдельно подчеркивает, что в агентных сервисах недостаточно смотреть только на финальный ответ: нужно проверять и промежуточные шаги, обращения к инструментам, срывы ограничений и ошибки маршрутизации. Иначе проблемы копятся незаметно и проявляются уже в бизнес-результате.

Третья статья — права доступа и безопасность. Чем ближе агент к CRM, финансам, документам и внутренним действиям, тем меньше он похож на «умный чат» и тем больше — на сотрудника с доступами. Значит, появляются подтверждения действий, ограничения по инструментам, журналы событий, сценарии отката и отдельная работа по политике доступа. Именно этот слой расходов нельзя забыть в первом расчете.

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

В рабочем смысле это не «подключить модель». Это перестроить кусок операционной логики так, чтобы он мог работать с LLM эффективнее.

Нужно описать сценарий по шагам:

LLM-интеграция — не надстройка над существующим процессом. На практике приходится пересобирать роли, маршруты, правила, исключения и ответственность. Поэтому агент в продакшене — не демонстрация возможностей модели, а часть операционной схемы бизнеса.

Если у вас сейчас что-то похожее, задумываетесь о внедрении агента, пишите. Возможно, сэкономлю вам пару неправильных решений.