AI-агенты везде: как компании тратят бюджеты на то, что можно было решить проще
Карго-культ 2026 года: агент вместо соломенного самолёта
После Второй мировой меланезийские племена строили деревянные самолёты и взлётные полосы из травы. Они видели: прилетает железная птица, привозит еду и одежду. Логика была железной по-своему: повтори форму, получишь результат. Грузы не прилетали.
В 2026 году эта механика воспроизводится в корпоративном IT с пугающей точностью.
CTO читает кейс: конкурент внедрил агентный AI, сократил операционные расходы на 30%. Через месяц команда пилотирует агента. Через три месяца пилот тихо закрывают, потому что "не пошло". Никто не формулировал задачу до запуска. Метрики успеха придумывали постфактум, когда уже было понятно, что хвастаться нечем.
Gartner в Hype Cycle for Agentic AI 2026 поместил агентный AI прямо на вершину Peak of Inflated Expectations. Это не случайность и не пессимизм аналитиков. Это фиксация реального паттерна: отрасль массово копирует форму, не разбираясь в механике.
Разница между карго-культом и осознанным внедрением умещается в один вопрос: когда поставлены метрики? Если после запуска, это культ. Племя уже строит полосу.
Форма агентного AI хорошо известна: LLM с инструментами, петля planning-action-observation, память между сессиями, возможность вызывать API. Скопировать это технически несложно. Anthropic, OpenAI, Google предоставляют готовые фреймворки. Но форма самолёта из бамбука аэродинамически не работает не потому, что племя плохо её воспроизвело. Она не работает, потому что самолёт летит не за счёт формы.
Агент выдаёт ценность за счёт чёткого контракта с окружением: он знает, что считается успехом, какие инструменты реально работают, где его полномочия заканчиваются и что происходит при ошибке. Без этого контракта агент просто уверенно делает не то. И делает это автономно, в масштабе, с логами, которые никто не читает.
Соломенный самолёт хотя бы не мог навредить.
Копировать форму без понимания смысла, классический карго-культ: соломенный самолёт не полетит, даже если выглядит убедительно.
Цифры, которые не показывают в питч-деках
По данным разных аналитических агентств, большинство enterprise-компаний в 2025-2026 годах запустили хотя бы один AI-пилот. Но разрыв между "экспериментируем" и "работает в проде с измеримым ROI" огромен, и он виден без точных процентов: достаточно попросить любую компанию показать конкретные цифры окупаемости по своим AI-инициативам.
Аналитики фиксируют высокие цифры ROI по успешным внедрениям. Но здесь надо понимать структуру выборки. Такие данные получены по компаниям, у которых внедрение состоялось. Не по всем, кто начал. Это классическая ошибка выжившего: считаем доходность кораблей, которые вернулись в порт, и не считаем те, что утонули ещё в пилоте.
И отдельный момент про успешные кейсы: аналитики прямо фиксируют, что хороший результат показывают компании с чётко ограниченной задачей. Не те, кто внедрял "AI в целом" или "агентизировал бизнес-процессы". Конкретный скоуп даёт измеримый результат. Размытый скоуп даёт красивый питч-дек и зависший проект.
Наблюдаемый паттерн: немалая часть команд разрабатывает агентов для многоэтапных процессов, так и не решив одноэтапные задачи скриптами. Это дорогостоящий способ усложнить то, что могло бы решиться регулярным выражением и парой API-вызовов. Агент с LLM внутри стоит на порядок дороже в обслуживании, медленнее и менее предсказуем, чем детерминированный код. Когда он оправдан, он оправдан. Но не как замена bash-скрипту.
Про разрыв между пилотом и production: значительная часть проектов зависает на стадии MVP значительно дольше, чем планировалось изначально. Я видел несколько таких случаев вблизи. Обычная история выглядит так: демо работает, стейкхолдеры впечатлены, потом начинается интеграция с реальными системами, появляются edge cases, меняются требования к безопасности, и проект переходит в режим вечного "почти готово". Запланированные месяцы удваиваются, команда выгорает, бюджет кончается.
Эти наблюдения не появляются в презентациях вендоров. Там будут впечатляющие ROI и истории успеха. Смотреть на них полезно, но только вместе с остальными числами.
Разрыв между 77% и 12% ROI показывает, что проблема не в технологии, а в выборе задачи для автоматизации.
Пять сценариев, где агент точно не нужен
Прежде чем строить агента, я всегда задаю один вопрос: а что конкретно здесь будет делать модель, чего не сделает скрипт на 50 строк? Если ответа нет, разговор закончен.
Задача решается за два часа. Если человек с Python или даже Excel-макросом закрывает проблему до обеда, агент здесь избыточен по определению. Я видел команды, которые тратили три недели на "интеллектуальную автоматизацию" парсинга CSV-файлов. Один pandas-скрипт сделал бы то же самое без LLM, без API-ключей и без счёта за токены.
Процесс повторяется раз в месяц. Агент оправдывает себя на высокочастотных задачах, где он работает пока вы спите. Отчёт, который формируется в первый понедельник каждого месяца, проще запустить руками или через cron. Содержать живой агент ради двенадцати запусков в год, это накладные расходы без отдачи.
Входные данные хаотичны и меняются каждую неделю. Агент галлюцинирует тем активнее, чем менее предсказуема среда. Если структура входящих документов меняется каждый спринт, а источники данных не стабилизированы, агент на каждом шаге будет принимать решения на основе сломанных предположений. Ошибки копятся и к концу цепочки вы получаете уверенный, но неверный результат.
Процесс требует подписи или юридической ответственности человека. Платёжные поручения, договоры, медицинские назначения, налоговые декларации. Там, где на каждом шаге нужна верифицируемая подпись конкретного человека, агент физически не может быть в цепочке принятия решений. Можно сделать агента, который готовит черновик, но не агента, который закрывает сделку. Это не ограничение технологии, это требование регуляторов. Отдельный разговор о том, где агент для финансовых задач реально окупается: там речь всегда о поддержке решения, а не о его принятии.
Никто не будет следить за агентом после запуска. Это убивает больше проектов, чем плохой промпт. Агент без мониторинга, это не автоматизация, а бомба с часовым механизмом. Если команда не выделила человека, который смотрит на логи, алерты и дрейф качества, агент лучше вообще не запускать.
Общее у всех пяти сценариев одно: задача раскладывается в детерминированное дерево условий. Если вы можете написать if-else-логику и покрыть ей 95% случаев, LLM добавит в процесс вариативность там, где вам нужна предсказуемость. Это не достоинство. Это риск.
n8n против агента: когда хватит автоматизации без AI
Прежде чем строить агента, задай себе один вопрос: можешь ли ты прямо сейчас нарисовать блок-схему всех шагов процесса? Если да, агент тебе не нужен.
n8n, Zapier, Make обрабатывают детерминированные процессы быстрее и дешевле любого агента на LLM. Self-hosted n8n на существующей инфраструктуре стоит $0 в месяц на токены. Агент с сопоставимой нагрузкой через GPT-4o или Claude Sonnet обойдётся в $50-500 в месяц, и это только за API-вызовы, без учёта времени на отладку недетерминированного поведения. Где именно проходит граница между no-code-автоматизацией и кодом в агентных пайплайнах, разобрано детально с конкретными сравнениями.
Разница не в умности, а в природе задачи.
Маршрутизация входящих писем по категориям: берёшь n8n, цепляешь узел с классификатором (хоть простой regex, хоть вызов к LLM за один запрос), настраиваешь ветки. Запустил один раз, работает годами. Обработка претензий, где надо поднять переписку за полгода, понять тональность, сопоставить с историей заказов и решить, эскалировать ли тикет или ответить автоматически: тут нет фиксированного пути. Шаги зависят от того, что агент найдёт на предыдущем шаге.
Вот практический скоринг, который я использую:
# Простая проверка: нужен ли агент?
def need_agent(task):
conditions = {
'steps_unknown_upfront': task.get('dynamic_steps', False),
'requires_reasoning': task.get('ambiguous_input', False),
'runs_daily_or_more': task.get('frequency', 0) >= 1,
'no_deterministic_path': not task.get('has_fixed_flowchart', True)
}
score = sum(conditions.values())
if score >= 3:
return 'Агент оправдан'
elif score == 2:
return 'Рассмотри LLM-узел в n8n'
else:
return 'Хватит n8n или скрипта'
Логика простая: считаем, сколько признаков "неопределённости" у задачи. Если три и больше из четырёх, агент оправдан. Если два, скорее всего хватит одного LLM-узла внутри n8n-воркфлоу. Один или ноль: агент тут избыточен и просто добавит точку отказа.
Частота запусков в этом критерии неочевидна. Задача, которая выполняется 5 раз в день с фиксированными шагами, идеальный кандидат для n8n: ты один раз тщательно отлаживаешь схему и получаешь предсказуемый результат. Агент на той же частоте будет каждый раз генерировать слегка разный путь выполнения, и рано или поздно это превратится в проблему на проде.
Ещё один сигнал, что тебя тянет к агенту зря: если ты описываешь задачу фразой "ну там надо чуть подумать". Это звучит как reasoning, но часто означает просто несколько if-веток, которые ты поленился формализовать. Формализуй сначала. Потом смотри, остался ли хаос.
Выбор между детерминированной автоматизацией и агентом определяет бюджет, сроки и риски всего проекта.
Как считают ROI те, кто его всё-таки получил
Главное правило, которое нарушают почти все: метрики фиксируются до внедрения. Не после. Не "ну мы примерно помним, сколько времени уходило". Baseline. Конкретные числа, снятые до того, как агент запущен в прод.
Без baseline у вас нет ROI. У вас есть ощущение.
Что измерять на старте: среднее время на задачу, процент ошибок или повторных обращений, стоимость одного выполнения операции и нагрузку на команду поддержки. Это четыре цифры, которые потом позволяют считать честно.
Вот реальная структура расчёта. Агент обрабатывает 500 входящих запросов в день. До внедрения сотрудник тратил на каждый запрос в среднем 6 минут, после: 3 минуты на проверку и корректировку ответа агента. Экономия: 3 минуты, то есть 0.05 часа на запрос. Стоимость часа сотрудника: 1500 рублей. Итого: 500 × 0.05 × 1500 = 37 500 рублей в день. Около 1.1 млн в месяц. Цифра выглядит убедительно, и именно поэтому здесь нужно остановиться и добавить то, что обычно выкидывают из расчёта.
Скрытые затраты съедают от 20% до 40% этой красивой суммы. Prompt engineering при запуске и каждый раз при изменении процесса. Мониторинг: кто-то должен смотреть, что агент не галлюцинирует. Исправление ошибок агента, которые доходят до клиента, и последствия от этих ошибок. И токены на повторные попытки: если агент не справился с задачей с первого раза, стоимость запроса удваивается или утраивается. Всё это считать сложнее, чем сэкономленные минуты, поэтому про это предпочитают молчать.
Практика показывает: команды, которые определяют метрики успеха до запуска агента, достигают окупаемости заметно быстрее тех, кто оценивает результат "по ощущениям". Объясняется это просто: когда метрики заданы заранее, команда знает, на что влиять. Когда их нет, оптимизируют что придётся.
По горизонту оценки: минимальный срок для честного расчёта ROI - 90 дней после выхода из пилота. Не считая период обучения и отладки. Пилот всегда работает в тепличных условиях: подготовленные кейсы, вовлечённая команда, повышенное внимание. Реальная операционная нагрузка начинается позже. Кто считает ROI по результатам пилота, тот считает погоду по термометру в теплице.
Скрытые издержки, обслуживание промптов, повторное обучение, отладка граничных случаев, легко перевешивают очевидную экономию.
Психология команды: почему проект глохнет после MVP
Демо прошло хорошо. Все похлопали. Slack заполнился огнями и ракетами. А через три месяца агент тихо умер в продакшене, и никто не взял на себя труд это признать.
Я видел эту картину достаточно раз, чтобы перестать удивляться.
Проблема начинается задолго до запуска. Где-то в 2024-2025 годах давление "нам срочно нужен AI" в enterprise достигло пика: совет директоров читал про GPT, конкуренты публично объявляли о пилотах, и бюджеты полетели в проекты без нормального обоснования. Классический FOMO. Только цена у него корпоративная: команда из пяти человек строит агента, которого никто конкретно не заказывал и за который никто конкретно не отвечает.
Потом срабатывает то, что я называю феноменом планируемой завершённости. Разработчик в голове уже закрыл задачу после демо. Менеджер записал в отчёт "внедрили AI-решение". Бизнес-сторона поставила галочку. А итеративный цикл, обратная связь от пользователей, работа с edge cases, мониторинг деградации модели, ничего из этого не было заложено в план изначально. Потому что план заканчивался на релизе.
Технари построили. Бизнес не взял.
Судя по тому, что регулярно всплывает при разборе упавших AI-проектов, значительная часть из них запускается без назначенного product owner. В компании есть человек, который отвечает за CRM, за логистическую платформу, за сайт. Но агент висит в воздухе, потому что "это же AI, это IT-шники сделали".
И здесь ловушка для разработчика. Он получает признание в момент запуска: оффер на повышение, бонус, упоминание на всеобщем митинге. Бизнес-результат через шесть месяцев, снижение времени обработки заявок, рост конверсии, экономия на саппорте, никак с его мотивацией не связан. Зачем ему беспокоиться о том, что происходит в продакшене в ноябре, если в мае его уже похвалили?
Выход прямой. KPI разработчика и tech lead нужно привязывать к метрикам через 60 дней после выхода в продакшен, не к дате релиза. Это единственный способ сделать так, чтобы у команды был структурный интерес смотреть, как агент работает в реальных условиях, а не только на подготовленных сценариях демо. Некомфортно? Да. Но именно этот дискомфорт заставляет закладывать мониторинг, писать нормальный fallback и договариваться с бизнесом о champion ещё до запуска, а не после того, как всё сломалось.
Четыре реальных кейса: провалы и победы
Начну с неудобного, потому что победы без провалов читаются как маркетинговый буклет.
Ритейл, обработка возвратов. Компания запустила агента, который должен был принимать заявки, проверять статус заказа и выдавать сумму компенсации. Звучит как идеальный кейс. На практике агент регулярно галлюцинировал: путал артикулы, неверно интерпретировал условия возврата, выдавал суммы, которые не соответствовали ни одной бизнес-логике. Клиенты получали письма с цифрами. Потом звонили. Потом писали жалобы. Финансовые и репутационные потери оказались существенными и превысили первоначально планируемую экономию. Проблема была не в модели, а в том, что никто не сделал нормальный eval до запуска в прод: не было ни тестового набора реальных случаев, ни порогового значения точности, при котором вообще можно было выходить к клиентам.
Финтех, KYC-верификация. Агент должен был автоматизировать проверку документов и данных клиентов. Регулятор потребовал ручную проверку каждого решения агента. Формально он прав: в большинстве юрисдикций ответственность за KYC лежит на лицензированном специалисте, не на системе. Агент превратился в дополнительный слой поверх старого процесса. Аналитик теперь проверяет и то, что делал раньше вручную, и то, что сгенерировал агент. Стало медленнее. Компания потратила несколько месяцев на интеграцию и в итоге откатилась к прежней схеме, оставив агента только для предварительной сортировки документов.
Оба провала объединяет одно: задачу выбирали по принципу "это часто повторяется", а не "это поддаётся чёткой верификации".
Логистика, диспетчеризация маршрутов. Агент обрабатывает 1200 маршрутов в день: учитывает загрузку, дорожную обстановку, приоритеты доставки, ограничения по весу. ROI закрылся за 4 месяца, экономия на топливе составила 18%. Почему сработало? Задача математически верифицируемая. Есть входные данные, есть оптимальный результат, есть метрика. Если агент ошибся, это видно сразу по факту поездки. Внутри компании был конкретный владелец процесса, логист с 12-летним стажем, который формулировал требования и проверял первые 3000 маршрутов вручную перед тем, как дать агенту больше автономии.
SaaS, первая линия поддержки. Агент закрывает 67% L1-тикетов без эскалации. CSAT вырос с 3.8 до 4.3, и рост объясняется не тем, что агент отвечает лучше живого человека, а тем, что он отвечает за 40 секунд вместо 4 часов на простые вопросы вроде "как сбросить пароль" или "где найти инвойс". Людей перевели на L2 и L3, где они реально нужны. Похожая механика работает и в голосовых агентах для входящих звонков: там тоже ключевой эффект в скорости первого ответа, а не в замене живого оператора. Текучка в поддержке снизилась, потому что исчез поток однотипных задач, который выматывает.
Паттерн победных кейсов читается чётко. Узкая задача с измеримым baseline до запуска. Владелец процесса внутри бизнеса, который понимает предметную область и отвечает за результат. И готовность потратить время на валидацию перед тем, как убрать человека из цикла.
Четыре квадранта наглядно разделяют задачи, где агент даёт прирост, от задач, где он добавляет только сложность.
Чек-лист: 8 вопросов перед запуском агента
Распечатай и повесь над монитором. Или пришли команде в Slack. Смысл один: если не можешь ответить "да" хотя бы на шесть из восьми, агент уйдёт в прод и вернётся оттуда в виде инцидента.
1. Есть задокументированный baseline? Конкретные цифры: сколько часов в неделю уходит на этот процесс сейчас, сколько стоит один цикл. Без этого ты не узнаешь, помог агент или просто переложил работу.
2. Процесс выполняется чаще раза в неделю? Редкий процесс не окупит ни разработку, ни поддержку. Агенты живут за счёт объёма.
3. Шаги нельзя описать детерминированной блок-схемой? Если можно, напиши скрипт. Агент нужен там, где входные данные непредсказуемы и каждый раз нужно принимать мелкие решения по контексту.
4. Назначен владелец со стороны бизнеса, не IT? Это не формальность. IT настроит агента, но только человек из бизнеса знает, когда ответ "технически правильный, но катастрофически неуместный". Без такого владельца агент деградирует молча. Показательный пример: агент для отдела продаж с квалификацией лидов работает именно потому, что его настраивал руководитель отдела, а не разработчик в вакууме.
5. Заложен бюджет на мониторинг и исправление первые три месяца? Первые 90 дней агент будет ошибаться. Это нормально. Ненормально, если на исправление ошибок нет ни времени, ни людей.
6. Определён порог точности, ниже которого агент эскалирует? Например: если уверенность модели в классификации ниже 0.75, задача уходит к человеку. Без такого порога агент будет галлюцинировать и молча класть результат в базу.
7. Compliance-риски оценены до запуска? Юристы и безопасники должны посмотре
