Почему большинство проектов с ИИ-агентами проваливаются (и как сделать ваш исключением)

Большинство компаний, попробовавших ИИ-агентов в 2024–2025 годах, получили что-то, что работало на демо, вызвало овации в Slack-канале и умерло в течение трёх месяцев. В 2026 году паттерны не изменились. Провалы предсказуемы и почти полностью организационные, а не технические.

Мы собрали десятки агентов и изучили ещё больше развёртываний. Пять причин провалов ниже объясняют, вероятно, 80% умерших проектов. Каждую из них можно избежать, если распознать её заранее.

Причина 1: слишком широкий масштаб

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

Решение: ваш первый агент должен иметь ровно один триггер, менее пяти шагов и один проверяемый результат. Если не можете записать ТЗ на одной странице, масштаб слишком широк. Разбейте на более мелких агентов и запустите сначала самого узкого.

Первый агент должен быть неловко маленьким. Каждый следующий может быть амбициознее, потому что вы узнали, что работает.

Причина 2: нет назначенного ответственного

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

Решение: один конкретный человек в вашей команде, ответственный. Его работа включает: оценку 20 результатов агента в неделю, настройку промптов при дрейфе и присутствие в Slack, когда агент перестаёт работать. Если не можете назвать этого человека до начала сборки, сборку начинать не следует.

Причина 3: чрезмерно широкие права доступа коннекторов

Соблазн: «Дадим агенту полный доступ к Drive, чтобы не беспокоиться об ограничениях». Последствие: в какой-то момент агент делает с этим доступом что-то незапланированное, и разговор переключается с ценности агента на права доступа.

Решение: агрессивно ограничивайте область на уровне коннектора. Одна папка, один пайплайн, один канал, не «весь Drive» или «весь HubSpot». Расширяйте доступ только тогда, когда конкретный процесс этого требует, а не превентивно. Цена слишком узкого доступа, 10-минутный разговор для расширения; цена слишком широкого, инцидент с безопасностью.

Причина 4: нет цикла проверки при запуске

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

Решение: в первые 4 недели ответственный оценивает 20 случайных результатов каждую неделю. Правильно / неправильно / требует настройки. Случаи «неправильно» и «требует настройки» возвращаются в работу как корректировки промптов. После четвёртой недели переходите на ежемесячные проверки. Агенты без еженедельной проверки при запуске деградируют незаметно.

Причина 5: неправильная метрика успеха

Команда измеряет «запуски агента в неделю» или «обработанные тикеты». Эти числа растут; никто не спрашивает, привели ли они к экономии человеческих часов. В итоге руководство задаёт очевидный вопрос («что вообще делает этот агент?»), и ответ слабый.

Решение: измеряйте возвращённые человеческие часы, а не активность агента. До запуска агента замерьте, сколько времени занимает аналогичная задача у человека. После запуска отслеживайте дельту. Если через 4 недели число явно не положительное, что-то не так: либо агент не заменяет то человеческое время, на которое вы рассчитывали, либо команда всё равно делает работу вручную и не использует агента.

Общий паттерн

Заметьте: ни одна из пяти причин не связана с возможностями ИИ. Модели в порядке. Платформы (OpenAI Workspace Agents, Microsoft Copilot Studio, Vertex AI) в порядке. Что не работает, так это то, что окружает агента: масштаб, ответственность, управление, проверка, измерение. Всё это проблемы человеческих процессов.

Это на самом деле хорошая новость. Если бы провалы были техническими, если бы качество модели было узким местом, нужно было бы ждать улучшений модели. Поскольку они организационные, их можно исправить уже завтра. Ничего в вашем AI-стеке не меняется; меняется подход к развёртыванию агентов.

Читкод

Если хотите одну практику, которая сразу решает большинство этих проблем: напишите ТЗ, назначьте ответственного и зафиксируйте ритм проверок до того, как касаетесь платформы. Дисциплина делать это до сборки заставляет замечать слишком широкий масштаб, отсутствие реального ответственного, размытую метрику успеха.

Команды, которые это делают, запускают успешных агентов. Команды, которые перескакивают сразу к сборке, в лучшем случае выигрывают в одном случае из двух. Потратьте 30 минут на написание ТЗ. Это самые высокоэффективные 30 минут в проекте.