Привет, Хабр! Я, Катрушенко Максим, занимаюсь внедрением ИИ в Первой Грузовой компании — крупном железнодорожном операторе на рынке грузовой логистики. Последние полгода активно изучаю тему использования ИИ‑агентов в больших компаниях. Многие рассказывают захватывающими истории, как раньше ничего не работало, а теперь «полетело», кто‑то смело делится провалами. Хочу поделиться, что получилось сделать у нас за довольно ограниченный срок и какой опыт мы извлекли.
Что такое AI‑агент и чем он отличается от чат‑бота
Вокруг слова «агент» много шума, поэтому договоримся о термине. Чат‑бот генерирует текст в ответ на текст. Агент делает больше: он может планировать ход выполнения задачи, выбирать инструмент для ее решения, выполнять набор действий и проверять результат. Это создает массу возможность для автоматизации процессов на совершенно разных сферах применения.
На практике агент — это связка из трёх частей:
Модель (LLM), которая понимает запрос на естественном языке и принимает решения;
Инструменты — функции, через которые агент читает данные, обращается к системам, что‑то считает;
Скрипт оркестрации — цикл, который определяет правила обращения к модели и инструментам, держит контекст и решает, когда ответ готов.
Чат‑бот пересказывает то, что «знает» модель. Агент работает с вашими реальными системами и данными, а значит, к нему применимы совсем другие требования: к точности, к правам доступа, к воспроизводимости. Именно здесь начинается настоящая инженерия, и именно здесь большинство проектов спотыкается.
Как применяют агентов сейчас
Если смотреть на цифры 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 объектов и подготовить по ним сводку. Вручную — это десятки минут монотонной сверки — порядка часа. Агент отдаёт результат за считанные минуты. Разумеется, сотрудник сначала проверил систему на небольшой выборке и только потом доверил ей большой список. И это правильный порядок.
На каком этапе мы сейчас
У нас есть работающий в проде узкий продукт, который реально экономит время на конкретных операциях, и выстроенный контур качества вокруг него. Важно понимать, что его использование — трата дополнительных ресурсов, поэтому границы его применения и доступа строго определяется тем, на каких задачах агент реально может дать эффект и сэкономить часы, а где это будет просто дорогая игрушка.
Чего точно не стоит делать при внедрении
Отдельно хочется проговорить собственные наблюдения (и буду рад обсудить в комментариях ваши) по негативному опыту внедрения ИИ‑агентов:
Путать активность с результатом
Число пользователей, запросов, потраченных токенов — удобная метрика для отчёта совету директоров, но она почти ничего не говорит о ценности продукта. Классика жанра — история, как в одной крупной технологической компании завёлся неофициальный рейтинг по потреблению токенов, а сотрудники начали соревноваться в том, кто «сожжёт» больше, пока это не пришлось выключить. Сожгли за месяц столько, сколько планировали потратить за год. Когда активность становится целью, люди учатся производить активность.
Начать с лозунга «сделайте нам ИИ», а остальное подтянется потом
Такой эксперимент может быть полезной разведкой — если у него заранее есть право остановиться и честное название «прототип», а не «внедрённый продукт». Но если нет нормальных данных, отлаженных процессов — такой старт быстро упрется в реальные ограничения.
Считать скорость прототипа готовностью к продакшену
Быстрое демо решает задачу внимания и обратной связи — и это здорово. Но уже на вторую неделю все перестают удивляться, что «эта штука умеет говорить». Требуется грамотно управлять ожидания заказчика, чтобы закрыть техдолг, который растет также быстро, как пишется проект. А с ИИ он пишется быстро.
Иначе прототип без технической приёмки становится фундаментом боевой системы, цена «дешёвой и быстрой» модели всплывёт позже — временем следующего инженера, который будет разбирать чужие срезанные углы. Скорость до демо и скорость до поддерживаемого продукта — это две совершенно разные величины.
Дать модели слишком много власти и надеяться на промпт
Широкие технические права (произвольный SQL, доступ на запись, автономные действия) при текстовом «пожалуйста, не удаляй данные» в системном промпте — это мина. Принцип минимальных полномочий не зря стоит определять до эксплуатации: роли, пределы действий и человеческий контроль закладываются заранее, а не после первого инцидента.
Безоговорочно доверять ИИ‑агенту
В финансовой модели передача всех полномочий над процессом ИИ‑агенту выглядит убедительно, но в ней обычно нет строки «дорогой хвост исключений». Даже громкие кейсы агрессивной автоматизации поддержки показали: массовый поток автоматизируется прекрасно, а сложные случаи всё равно возвращаются к людям. Устойчивее строить агента как усилитель специалиста, а не как повод от него избавиться.
Масштабировать одного агента во все стороны без подтверждённого спроса
Общий агент «на всё» быстро превращается в платформу со случайным набором функций, где каждое подразделение приносит свои определения одной и той же метрики, а один и тот же вопрос получает разные «правильные» ответы. Уместнее создать несколько узких агентов на общей технической основе.
Что реально помогает, и почему это в первую очередь про культуру
Поговорили о плохом, теперь поговорим о хорошем:
Оптимизируйте плотность ценности, а не охват
Для внутреннего инструмента важна не частота открытия чата, а стоимость решённой задачи. Один дорогой повторяющийся процесс, где можно честно сравнить «до» и «после», стоит сотни поверхностных сценариев. Культурный сдвиг здесь, который поначалу его сложно принять, это перестать мерить успех числом пользователей и начать мерить изменением рабочего процесса, сокращением затрат.
Осознанно ограничивайте агента
Для внутреннего продукта это признак зрелости, а не слабости. Семантический слой, read‑only, явный список метрик — я подаю их как достижения, а не как «недоделки». Умение сказать «такой расчёт пока недоступен» вместо правдоподобной выдумки — это то, что отличает продукт, которому доверяют, от игрушки.
Считайте неоднозначность свойством бизнеса, а не виной пользователя
У многих терминов есть несколько законных трактовок. У нас, например, у показателя оборота вагона их две, и правильное поведение агента не «выбрать одну молча», а уточнить и показать, какие фильтры он применил. Это стоит одного дополнительного вопроса, но экономит часы разбирательств «почему цифры разные».
Стройте контур качества из реальных ошибок
Каждая пользовательская сессия — это материал. Трассировки диалогов, обратная связь, регрессионные наборы, сравнение с эталонными ответами превращают развитие в инженерный процесс. Культурно смещает процесс работы от поиска виноватого / «неправильного» пользователя к эволюции агента.
Наращивайте доверие поэтапно
Сначала узкая выборка доверенных экспертов, потом поэтапное распространение. Для внутренней аналитической системы также важно, чтобы была прозрачность получения информации от агента. Поэтому у себя мы добавили детали от вывода логики рассуждения агента до детализации SQL‑запроса к данным.
Что дальше
Развитие ИИ‑агентов вдохнуло новую жизнь в корпоративную разработку ML в крупных компаниях, где уже внедрили / привыкли и перестали им удивляться. Сейчас новая ветвь технологий снова толкает бизнес в область неизвестного. Это вдохновляет на исследования. Мы прошли самый простой этап — доказали, что технология работает. Сейчас входим в по‑настоящему интересный — учимся встраивать её в процессы так, чтобы она давала измеримую пользу и оставалась управляемой.
Для нашего продукта видим следующие вызовы:
довести текущего агента до регулярного использования,
масштабировать наш опыт на другие процессы внутри компании,
На текущем этапе очень воодушевляет отзывчивость пользователей и бизнес‑заказчиков внутри компании. Приятно наблюдать, что люди приходят уже с опытом работы с подобными инструментами, пониманием их возможностей и слабых мест. Особенно ценно, когда пользователи сами приходят с идеями, какие процессы можно было бы улучшить при помощи ИИ‑агентов. Это мотивирует и заряжает.
Финальный совет для тех, кто только начинает разрабатывать ИИ‑агентов внутри большой компании: забудьте про гонку за количеством пользователей и миллионами токенов. Сначала найдите один узкий процесс, который нужен бизнесу, и объедините одну команду инженеров, готовых пересобирать этот процесс 10 раз. Если вы справитесь с этим пазлом — масштабировать дальше будет гораздо проще.
