AI‑агенты в крупном бизнесе: где сейчас рынок, что построили мы и как внедрять, чтобы взлетело

Я, Катрушенко Максим, занимаюсь внедрением ИИ в Первой Грузовой компании — крупном железнодорожном операторе на рынке грузовой логистики. Последние полгода активно изучаю тему использования ИИ‑агентов в больших компаниях. Многие рассказывают захватывающими истории, как раньше ничего не работало, а теперь «полетело», кто‑то смело делится провалами. Хочу поделиться, что получилось сделать у нас за довольно ограниченный срок и какой опыт мы извлекли.

Что такое AI‑агент и чем он отличается от чат‑бота

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

На практике агент — это связка из трёх частей:

1. Модель (LLM), которая понимает запрос на естественном языке и принимает решения;

2. Инструменты — функции, через которые агент читает данные, обращается к системам, что‑то считает;

3. Скрипт оркестрации — цикл, который определяет правила обращения к модели и инструментам, держит контекст и решает, когда ответ готов.

Разница принципиальная. Чат‑бот пересказывает то, что «знает» модель. Агент работает с вашими реальными системами и данными, а значит, к нему применимы совсем другие требования: к точности, к правам доступа, к воспроизводимости. Именно здесь начинается настоящая инженерия, и именно здесь большинство проектов спотыкается.

Как применяют агентов сейчас

Если смотреть на цифры 2025–2026 годов, картина одновременно впечатляющая и отрезвляющая.

Распространение AI‑агентов выросло взрывообразно. По отраслевым опросам, к началу 2026 года около 80% крупных компаний имеют хотя бы одно продакшн‑приложение со встроенным AI‑агентом — против примерно трети двумя годами ранее. Такой скорости распространения корпоративный софт не показывал со времён прихода облачных решений. Аналитики закладывают, что к концу 2026 года агенты под специфические задачи будут встроены примерно в 40% корпоративных приложений.

Встроены — отлично, но будут ли они приносить пользу? McKinsey в свежем «State of AI» фиксирует яркий разрыв ожиданий и фактического результата: ИИ так или иначе используют почти 90% компаний из опроса, но заметное влияние на прибыль на уровне компании видят меньше половины из них, а в группу «высоких исполнителей» с ощутимым финансовым эффектом попадают немногим больше 5% (McKinsey, The State of AI). Две трети компаний заявляют, что всё ещё находятся в режиме пилота, а не масштабирования.

Здесь первое важное замечание. Неверно говорить: «ИИ не работает», он как раз работает. Ценно другое: доступ к технологии перестал быть конкурентным преимуществом. Модель сегодня есть у всех. Преимущество даёт то, что вокруг модели: выбор правильного процесса, качество данных, перестройка ролей и дисциплина проверки результата. Выигрывают те, кто умеет пользоваться инструментом и делает это лучше других. Утверждение подтверждается и в свежем эссе Кагана (https://www.svpg.com/the‑ai‑productivity‑paradox/). Сильнее всего с финансовым эффектом коррелирует не сам факт внедрения, а фундаментальная перестройка рабочего процесса под ИИ.

Ещё пара трендов, о которых стоит помнить

Лидируют отрасли с чёткими повторяющимися процессами — банки и страхование впереди. Там, где операция стандартизирована и измерима, агент приносит эффект быстрее.

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

Иными словами, рынок прошёл фазу «вау, оно разговаривает» и входит в фазу «покажите эффект». На этом этапе приносить результат будут быстрее, кто умел налаживать корп. процессы, чистить данные и находить бизнес‑ценность. Просто теперь они это делают еще быстрее.

Разрушилось ожидание, что специалиста можно заменить стажером с ИИ‑агентом. Уже множество исследований доказало, что есть существенный разрыв в понимании проекта моделью в зависимости от того, насколько качественно была устроена архитектура проекта. В бизнес‑ процессах аналогично. Как если дать плохому гонщику возможность жать на нитро, он только быстрее врежется в стену, а не доедет до финиша.

Что построили мы

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

Что делает агент 

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

Как это устроено внутри — и почему именно так 

Модель не пишет SQL. Это, наверное, ключевое решение. Вместо того чтобы позволить LLM генерировать произвольные запросы к базе, мы построили семантический слой: набор доступных доменов, метрик, измерений и фильтров задан явно, а безопасный параметризованный запрос собирает контролируемый конструктор. Модель лишь выбирает, что спросить из заранее разрешённого списка. А как спросить базу, решает наш код. Это снимает целый класс рисков — от инъекций до тихих ошибок в агрегациях — и делает поведение агента тестируемым.

База данных доступна только для чтения. Агент не меняет данные и в принципе не имеет на это прав. Граница проведена на уровне архитектуры, что позволяет не беспокоиться о рисках случайного удаления агентом всех данных с прода.

Отдельный плюс — удобство добавления новых витрин. Добавить домен, метрику или фильтр можно декларативно и соответствующий инструмент появляется автоматически. 

Всё наблюдаемо и проверяемо 

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

Измеримый эффект 

Агент охватывает широкий диапазон данных и инструментов работы с ними. Пока мы прорабатываем варианты получения экономического эффекта, но уже есть наглядные сценарии сокращения трудозатрат на решения задач: сотруднику нужно получить информацию по состоянию примерно 150 объектов и подготовить по ним сводку. Вручную — это десятки минут монотонной сверки — порядка часа. Агент отдаёт результат за считанные минуты. Разумеется, сотрудник сначала проверил систему на небольшой выборке и только потом доверил ей большой список. И это правильный порядок.

На каком этапе мы сейчас 

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

Чего точно не стоит делать при внедрении

Отдельно хочется проговорить собственные наблюдения (и буду рад обсудить в комментариях ваши) по негативному опыту внедрения ИИ‑агентов:

1. Путать активность с результатом

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

2. Начать с лозунга «сделайте нам ИИ», а остальное подтянется потом 

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

3. Считать скорость прототипа готовностью к продакшену

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

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

4. Дать модели слишком много власти и надеяться на промпт 

   Широкие технические права (произвольный SQL, доступ на запись, автономные действия) при текстовом «пожалуйста, не удаляй данные» в системном промпте — это мина. Принцип минимальных полномочий не зря стоит определять до эксплуатации: роли, пределы действий и человеческий контроль закладываются заранее, а не после первого инцидента.

5. Безоговорочно доверять ИИ‑агенту

   В финансовой модели передача всех полномочий над процессом ИИ‑агенту выглядит убедительно, но в ней обычно нет строки «дорогой хвост исключений». Даже громкие кейсы агрессивной автоматизации поддержки показали: массовый поток автоматизируется прекрасно, а сложные случаи всё равно возвращаются к людям. Устойчивее строить агента как усилитель специалиста, а не как повод от него избавиться.

6. Масштабировать одного агента во все стороны без подтверждённого спроса 

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

Что реально помогает, и почему это в первую очередь про культуру

Поговорили о плохом, теперь поговорим о хорошем: 

1. Оптимизируйте плотность ценности, а не охват 

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

2. Осознанно ограничивайте агента 

   Для внутреннего продукта это признак зрелости, а не слабости. Семантический слой, read‑only, явный список метрик — я подаю их как достижения, а не как «недоделки». Умение сказать «такой расчёт пока недоступен» вместо правдоподобной выдумки — это то, что отличает продукт, которому доверяют, от игрушки.

3. Считайте неоднозначность свойством бизнеса, а не виной пользователя 

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

4. Стройте контур качества из реальных ошибок 

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

5. Наращивайте доверие поэтапно 

   Сначала узкая выборка доверенных экспертов, потом поэтапное распространение. Для внутренней аналитической системы также важно, чтобы была прозрачность получения информации от агента. Поэтому у себя мы добавили детали от вывода логики рассуждения агента до детализации SQL‑запроса к данным.

Что дальше

Развитие ИИ‑агентов вдохнуло новую жизнь в корпоративную разработку ML в крупных компаниях, где уже внедрили / привыкли и перестали им удивляться. Сейчас новая ветвь технологий снова толкает бизнес в область неизвестного. Это вдохновляет на исследования. Мы прошли самый простой этап — доказали, что технология работает. Сейчас входим в по‑настоящему интересный — учимся встраивать её в процессы так, чтобы она давала измеримую пользу и оставалась управляемой.

Для нашего продукта видим следующие вызовы:

• довести текущего агента до регулярного использования, 

• масштабировать наш опыт на другие процессы внутри компании,

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

Финальный совет для тех, кто только начинает разрабатывать ИИ‑агентов внутри большой компании: забудьте про гонку за количеством пользователей и миллионами токенов. Сначала найдите один узкий процесс, который нужен бизнесу, и объедините одну команду инженеров, готовых пересобирать этот процесс 10 раз. Если вы справитесь с этим пазлом — масштабировать дальше будет гораздо проще.