100+ задач за два месяца: как ИИ-агент сократил время подготовки экономических моделей на 75%
Об ИИ-агентах часто рассказывают через демонстрацию: система получает запрос и быстро выдаёт убедительный результат. Это показывает, что сценарий в принципе запускается, но почти ничего не говорит о работе на реальном потоке. Для решения о внедрении важнее другое: сколько настоящих задач прошло через систему, как изменилось время обработки, где агент обязан остановиться и кто отвечает за итог.
Ниже — результаты реального пилота AiHummer в компании из телеком-сферы. ИИ-агент участвовал в подготовке экономических моделей. За первые два месяца через него прошло более 100 задач, а время их обработки, по внутренней оценке команды проекта, сократилось на 75%. В 5% задач автоматический сценарий останавливался по заранее заданным правилам, после чего работу продолжал специалист.
Название компании не раскрывается: клиент ещё не принимал решения о публичном упоминании проекта. В статье приведены только обезличенное описание процесса и агрегированные операционные показатели. Входные данные, финансовые параметры моделей, внутренние регламенты и абсолютные значения времени не публикуются и не должны выходить за рамки согласованного раскрытия
Какую задачу решали
Предметом автоматизации была не самостоятельная оценка проекта и не право ИИ принимать финансовое решение. Агенту выделили подготовительный участок процесса: получить задачу в рамках согласованного сценария, подготовить рабочий результат и передать его специалисту для проверки.
Такое разделение ролей принципиально. Экономическая модель влияет на управленческие решения, поэтому окончательное утверждение оставалось за человеком во всех случаях. Цель пилота состояла не в том, чтобы убрать специалиста из процесса, а в том, чтобы сократить повторяемую работу перед профессиональной проверкой.
Конкретные входные формы, расчётные параметры и правила клиента конфиденциальны. На уровне процесса проход выглядел так:
- В систему поступала задача на подготовку экономической модели вместе с доступными вводными.
- ИИ-агент выполнял закреплённый за ним подготовительный сценарий и формировал рабочий результат.
- Если задача выходила за заранее определённые условия автоматического прохода, агент останавливался и передавал её специалисту.
- Подготовленный результат проходил обязательную финальную проверку и утверждение человеком.
Что считали одной задачей
Для корректной метрики важно не подменять бизнес-результат внутренней активностью системы. Одной задачей считался не отдельный ответ модели, не сообщение в интерфейсе и не технический вызов. Единицей учёта был запрос на подготовку экономической модели, прошедший через согласованный процесс.
Внутри одной задачи агент мог выполнить несколько действий, но в статистике это по-прежнему оставалось одной задачей. Такой подход не позволяет искусственно увеличить объём эксплуатации и помогает обсуждать эффект на языке бизнеса.
Результатом работы агента считался подготовленный материал для проверки специалистом. Уверенно сформулированный текст сам по себе завершением не являлся: ответственность за итоговую валидацию модели оставалась у человека.
Что показали первые два месяца
Через агента прошло более 100 реальных задач. Это не набор демонстрационных запросов и не прогноз на основе расчётной таблицы, а фактический объём пилота.
Команда проекта сопоставила время обработки задач этого процесса до внедрения и во время пилота. По результатам внутреннего сравнения показатель сократился на 75%. Абсолютные значения времени клиент не разрешал публиковать, поэтому мы не восстанавливаем их по косвенным данным и не превращаем процент в неподтверждённые часы или рубли.
Этот результат относится к конкретному процессу, набору правил и периоду наблюдения. Его нельзя автоматически переносить на любую компанию. Но он отвечает на главный вопрос редакции и заказчика: эффект был получен на реальном потоке задач, а не только рассчитан до внедрения.
Что означают 5% передач человеку
В 5% задач автоматический сценарий останавливался до завершения подготовительного прохода. Агент не продолжал работу за пределами заранее установленных правил, а передавал задачу специалисту. Детальные стоп-условия являются частью внутреннего регламента клиента и в статье не раскрываются.
Эти 5% нельзя трактовать как единственную долю участия человека. Они показывают только случаи досрочного подключения специалиста. Финальная проверка и утверждение подготовленных моделей оставались за человеком во всех задачах. Поэтому из показателя нельзя делать вывод о «95% полной автономности».
Контролируемая остановка — не сбой, если она срабатывает там, где система не должна продолжать сценарий самостоятельно. В корпоративном процессе безопаснее явно показать границу автоматизации, чем получить формально завершённый, но неподтверждённый результат. 
Почему мы не публикуем экономию в рублях
Снижение времени обработки — измеренный операционный эффект. Денежный эффект требует дополнительных данных: полной стоимости рабочего времени, фактической загрузки команды, объёма потока, стоимости платформы и инфраструктуры, а также решения компании о том, как использовать высвобождённый ресурс.
Эти параметры относятся к внутренней экономике клиента и не разрешены к раскрытию. Поэтому в статье нет расчётной суммы, ROI или срока окупаемости. Добавить условную стоимость часа и выдать результат за экономию конкретного заказчика означало бы подменить реальный кейс расчётной гипотезой.
Подтверждённые показатели пилота: более 100 задач за два месяца, сокращение времени обработки на 75% и 5% досрочных передач специалисту. Не публикуются и не заявляются: абсолютная экономия, ROI, сокращение штата, рост выручки, внутренние финансовые данные и название клиента.
Что изменилось в работе специалиста
Специалист не исчез из процесса. Изменилась точка его участия: вместо полного ручного прохождения задачи он получал подготовленный рабочий результат и выполнял финальную проверку. В исключениях он мог подключиться раньше — именно такие случаи и попали в показатель 5%.
Сокращение времени не равно автоматическому сокращению расходов. Высвобождённый ресурс становится экономическим эффектом только тогда, когда компания использует его: обрабатывает больший поток, сокращает очередь, уменьшает сверхурочную нагрузку или перераспределяет специалистов на задачи, которые нельзя автоматизировать. В этом кейсе мы фиксируем измеренное ускорение процесса, не приписывая ему неподтверждённый финансовый результат.
Пять выводов из пилота
- Считать нужно бизнес-задачи, а не сообщения модели и внутренние действия системы.
- Границу ответственности следует определить заранее: что готовит агент и что обязательно утверждает человек.
- Правила остановки — часть рабочего сценария, а не аварийная функция на случай ошибки.
- Метрики нельзя смешивать: объём задач, сокращение времени и досрочные передачи отвечают на разные вопросы.
- Публичный кейс должен отделять измеренные результаты от расчётных допущений и соблюдать согласованные с клиентом границы раскрытия.
Перед запуском похожего проекта полезно письменно ответить на четыре вопроса: что считается одной завершённой задачей, какой участок работы передаётся агенту, когда он обязан остановиться и как будет сопоставляться время обработки до и после внедрения. Без этих определений даже хороший технический результат трудно превратить в доказанный бизнес-кейс.
Итог
Результат первых двух месяцев в телеком-компании: более 100 задач, сокращение времени обработки на 75% и 5% контролируемых досрочных передач специалисту. Финальное утверждение моделей оставалось за человеком.
Этот кейс не обещает такой же процент каждому проекту. Он показывает более практичную вещь: агент приносит измеримую пользу, когда ему выделяют понятный участок процесса, задают правила остановки и проверяют результат на реальном потоке, не подменяя факты расчётными примерами.
