Больше 40% проектов агентного ИИ будут свёрнуты до конца 2027 года — такой прогноз Gartner дал в июне 2025 года по опросу более 3400 организаций и подтвердил в 2026-м. Причина почти никогда не в слабой модели: агент работает как задумано, а результат компании не получает. Ниже — девять ошибок, которые встречаются чаще всего, с цифрами и способами проверки, чтобы не повторить их у себя.
Что такое ошибка внедрения ИИ-агента
Ошибка внедрения ИИ-агента — это управленческое или организационное решение, из-за которого работающий агент не приносит измеримой пользы бизнесу. Она возникает до первой строчки кода и проявляется позже: пилот идёт 4–5 месяцев, показывает красивые демо, а затем останавливается, потому что непонятно, кому он принадлежит, что считается успехом и кто отвечает за его ошибки.
Ключевое отличие от технической неисправности: техническую ловят тестами и мониторингом, организационную — только заранее написанным документом о том, какого результата мы ждём и кто его принимает. По опросу 650 руководителей технологических направлений (Digital Applied, февраль–март 2026), 78% компаний имеют хотя бы один пилот ИИ-агента, но только 14% довели агента до промышленной эксплуатации — то есть до обработки более половины целевого объёма задач с автоматическим контролем качества и прописанной процедурой реагирования на сбои.
Почему пилоты не доходят до продакшена: что говорят цифры
Три цифры, которые стоит держать в голове перед стартом.
95% пилотов генеративного ИИ не дают измеримого эффекта — исследование MIT Project NANDA, август 2025. Это про генеративный ИИ в целом, не только про агентов, но масштаб показателен.
5 причин объясняют 89% провалов масштабирования — тот же опрос Digital Applied 2026. В порядке частоты упоминаний: сложность интеграций с legacy-системами (63%), нестабильное качество на объёме (58%), отсутствие мониторинга (54%), неясный организационный владелец (49%), нехватка доменных данных (41%). Причины связаны: там, где нет владельца, обычно нет и мониторинга, а без мониторинга проблемы качества всплывают только через недели, когда ошибки уже разошлись по зависимым системам.
Средний срок пилота до остановки — 4,7 месяца. Из компаний, которые попытались расширить охват или объём, 64% упёрлись в блокирующие проблемы, и 72% из них стоят больше полугода без понятного пути решения.
Показательно и то, что успешные и застрявшие компании тратят на ИИ сопоставимые бюджеты. Разница в распределении: первые больше вкладывают в инфраструктуру оценки качества, мониторинг и операционную команду, меньше — в выбор модели и промпт-инжиниринг.
Ошибка 1. У проекта нет владельца результата
Самая частая и самая незаметная. Формально за внедрение отвечают все: ИТ даёт доступы, бизнес-подразделение формулирует задачу, подрядчик пишет агента. Фактически не отвечает никто. В опросе 2026 года неясную ответственность между ИТ, дата-командой и бизнесом назвали 49% респондентов.
Как выглядит провал на практике. Агент раз в день собирает сводку по просроченным заявкам. Сводка приходит, но в ней неверно определяется приоритет. ИТ говорит: «логика согласована с бизнесом». Бизнес говорит: «мы такого не просили». Дальше агент либо выключают, либо он годами висит в статусе «экспериментальный».
Что делать. До старта назначить одного человека — не отдел — который отвечает за результат и имеет право менять правила работы агента. Второй человек, из ИТ или эксплуатации, отвечает за работоспособность: доступы, интеграции, инциденты. Двое, с именами и зонами, а не «рабочая группа». По данным того же исследования, компании, прошедшие путь до продакшена, завели отдельную функцию ИИ-эксплуатации — не внутри ИТ и не внутри бизнес-подразделения, — которая отвечает за регламент оценки, мониторинг и реагирование на сбои. Там, где эту ответственность размазали по существующим отделам, масштабирование стабильно не удавалось.
Ошибка 2. Слишком широкий охват на старте
«Сделайте нам ИИ-сотрудника, который закрывает продажи, поддержку и документы» — типичная постановка. Она гарантирует провал, потому что качество агента падает нелинейно с ростом числа сценариев: каждая дополнительная система и каждая дополнительная ветка логики добавляют редкие, нетестируемые случаи.
В том же опросе вывод сформулирован прямо: узкие агенты под одну функцию масштабируются надёжнее, чем широкие. Успешные внедрения начинались с одного чётко ограниченного процесса с измеримым выходом — классификатор документов, обогащение данных, маршрутизация заявок. Расширение охвата начиналось только после 90+ дней стабильной работы узкой версии.
Есть и российское подтверждение с другой стороны: по обзору рынка на shtab.app, главный барьер внедрения — не технологии, а качество данных и отсутствие описанных процессов. Если процесс не описан, широкий агент просто воспроизводит хаос в отчётах.
Что делать. Один процесс, один результат, один способ проверки. Формулировка задачи должна содержать не глагол «автоматизировать», а измеримый выход: «сократить время на разбор входящего письма с 6 минут до 1» или «снизить долю ошибок при переносе накладной в учётную систему с 8% до 2%». Если выход нельзя посчитать в цифрах за месяц — это ещё не задача для агента, а пожелание.
Ошибка 3. Нет критериев приёмки — есть только демонстрация
Демо и приёмка — разные вещи. На демонстрации агент обрабатывает десять заранее подобранных примеров, которые готовила команда внедрения. На приёмке он должен обработать выборку, которую готовил владелец процесса, включая неудобные случаи.
Типовой провал: пилот принимают «на глаз», потому что «в целом работает». Через два месяца выясняется, что 3% входных данных агент обрабатывает неверно. При объёме 10 000 задач в день это 300 ошибок ежедневно — и если эти ошибки уходят в CRM или в бухгалтерию, разгребать их придётся вручную, уже задним числом.
Что делать. До старта зафиксировать три вещи: набор сложных тестовых примеров (краевые случаи, битые файлы, двусмысленные формулировки), допустимый процент ошибок по каждому типу задачи и правило, что происходит при неуверенности — например, вывод с низкой уверенностью уходит человеку, а не в систему. Критерий приёмки подписывает владелец процесса, а не подрядчик.
Ошибка 4. Агент получает больше автономии, чем выдерживает его надёжность
Формулировка Gartner из обзора, опубликованного 2 октября 2026 года: главный риск — развернуть агента с большей автономией, чем позволяет уровень его надёжности. Успех агента зависит от надёжности, а не от степени самостоятельности.
На практике это выглядит так. Агент, который готовит черновик ответа клиенту, — безопасен: ошибку поймает человек. Того же агента «за компанию» наделяют правом отправлять письма и менять статусы в CRM. Теперь каждая ошибка классификации становится действием с последствиями. Формально модель та же, риск — другой на порядок.
Отдельно Gartner указывает (пресс-релиз от 26 мая 2026), что единые правила управления для всех агентов — независимо от уровня автономии и объёма доступов — сами ведут к провалу. Политика должна зависеть от того, что агенту разрешено делать, а не быть общей на всю компанию. Прогноз там же: к 2027 году 40% компаний понизят статус или выведут из эксплуатации автономных агентов из-за провалов в управлении.
Про безопасность стоит сказать отдельно: по данным исследования «Информзащита» 2026 года, 42% организаций столкнулись с инцидентами безопасности из-за ИИ-агентов — против 31% годом ранее. Речь не только о взломе: чаще это избыточные права, случайные удаления и утечки.
Что делать. Разделить действия агента на три уровня: читает — делает сам; меняет данные — делает с логированием и уведомлением; отправляет наружу или удаляет — только после подтверждения человеком. Права выдавать по минимуму, необходимому для задачи, и пересматривать при каждом расширении охвата. Правила доступа к данным проектировать до запуска, а не после первого инцидента.
Ошибка 5. Данные не готовы, а пилот делали на «чистых» данных
Классика: пилот собирали на выгрузке, которую специально подготовили для теста. В продакшене агент подключается к реальной базе — с дублями, пустыми полями, тремя вариантами написания одного контрагента и справочником, который последний раз обновляли в 2023 году.
По обобщённой статистике провалов 2026 года, 85% неудачных ИИ-проектов связывают с качеством данных. Нехватку доменных данных для дообучения назвали 41% респондентов опроса Digital Applied.
Что делать. Перед стартом — ревизия тех данных, которые агент реально будет читать, а не всех данных компании. Проверить три вещи: сколько в источнике дублей, сколько записей с пустыми обязательными полями, есть ли единый справочник значений. Если дублей больше нескольких процентов, сначала чистка — иначе агент будет уверенно тиражировать мусор.
Ошибка 6. Интеграции планировали «как получится»
Сложность интеграций — причина номер один в списке (63%). Пилот обычно работает с удобным источником: папка, отдельное представление в базе, тестовый API с предсказуемым JSON. Продакшен — это ERP двадцатилетней давности, у которой единственный способ доступа — ночная выгрузка, и CRM с сотней кастомных полей без документации.
Отдельная ловушка — тихие сбои. Если внешний API отвечает таймаутом, агент не всегда падает с ошибкой: он может вернуть правдоподобный, но неверный ответ. Без мониторинга такой случай невидим.
Что делать. Составить полный перечень систем, которые агент будет читать и куда писать: способ доступа, авторизация, лимиты, гарантии качества данных. Этот перечень почти никогда не существует до того, как его потребуют, — и его отсутствие надёжнее всего предсказывает остановку проекта. Каждую интеграцию строить, тестировать и стабилизировать отдельно, а не одновременно с доводкой самого агента. Между агентом и legacy-системой ставить промежуточный слой с обработкой ошибок и повторов, чтобы агент не ходил в старую систему напрямую.
Ошибка 7. Мониторинга нет — есть только уверенность, что «всё работает»
54% респондентов назвали отсутствие производственного контроля качества блокирующей проблемой. Без него деградация качества не видна: агент продолжает работать, ошибки накапливаются, а обнаруживаются через недели — по жалобе клиента или по расхождению в отчёте.
Что делать. Минимум три вещи. Ежедневная выборка 1–5% результатов и сверка с эталонными примерами — с оповещением, если доля правильных ответов упала более чем на 5 процентных пунктов от базовой линии. Журнал действий агента: что прочитал, что записал, на основании чего. Ограничение на объём автоматических изменений — например, не больше N записей в час, чтобы ошибка не разошлась по всей базе за ночь. Плюс фиксация версии модели и промпта: после обновления модели поведение меняется, и без привязки версии непонятно, почему качество просело.
Ошибка 8. Команду не предупредили, и она саботирует
Сопротивление сотрудников — одна из главных проблем при внедрении, и она же самая дешёвая в устранении. Люди боятся, что их заменят, и начинают проверять агента на самых сложных запросах, чтобы доказать его бесполезность. Формально это выглядит как «агент не работает».
Что делать. Заранее ответить команде на три вопроса: что агент забирает, что остаётся человеку, что меняется в оценке работы. Если агент снимает рутину, а не людей, — сказать это прямо и показать на цифрах. Полезно назначить из команды человека, который собирает ошибки агента: это переводит сопротивление в улучшение.
Ошибка 9. Отсутствие управления как процесса
Только 21% организаций имеют зрелую модель управления автономными агентами — оценка Gartner на 2026 год. У остальных нет ответа на вопросы: кто утверждает новые сценарии, кто проверяет доступы, что происходит при инциденте, где хранится журнал действий.
Отдельный российский контекст — персональные данные. Если агент читает письма клиентов, записи звонков или заявки с ФИО и телефоном, он попадает в периметр 152-ФЗ. Практический вывод простой: определять, какие данные агент видит, нужно до запуска, а не после того, как он их уже прочитал.
Что делать. Один документ на одну страницу: перечень сценариев агента, уровень автономии по каждому, кто владелец, какие данные доступны, куда пишется журнал, кто и как останавливает агента при сбое. Пересматривать раз в квартал. Если документ невозможно заполнить — внедрение ещё не готово.
Чек-лист перед стартом пилота
Проверка занимает час и экономит месяцы. Пункт считается закрытым только при наличии письменного ответа.
Задача. Один процесс, один измеримый результат, срок оценки — не больше 6 недель (средний пилот до остановки — 4,7 месяца, и это уже поздно).
Владелец. Имя человека, который принимает результат. Имя человека, который отвечает за работоспособность.
Метрика. Базовая линия «как сейчас» в цифрах (время, доля ошибок, стоимость операции) и целевое значение. Если базовой линии нет — сначала замер, потом агент.
Приёмка. Набор из 30–50 сложных примеров от владельца процесса, а не от внедренца. Допустимый процент ошибок по типам.
Данные. Перечень источников, оценка дублей и пустых полей, единый справочник значений.
Интеграции. Список систем, способ доступа, авторизация, лимиты. Каждая интеграция проверена отдельно.
Права. Что агент читает, что меняет, что отправляет. Разделение по трём уровням, подтверждение человеком на критичных действиях.
Мониторинг. Где журнал, кто смотрит выборку результатов, какой порог для оповещения, как остановить агента.
Люди. Кому и что сказали про изменения в работе. Кто собирает ошибки агента.
Откат. Как вернуть ручной процесс за один день, если агент придётся выключить.
FAQ
Почему большинство пилотов ИИ-агентов не доходят до продакшена?
Потому что провал почти всегда организационный, а не технический. В опросе 650 руководителей 2026 года 89% проблем масштабирования объяснялись пятью причинами: интеграции, нестабильное качество на объёме, отсутствие мониторинга, неясный владелец и нехватка доменных данных. Модель при этом работает как задумано — не хватает эксплуатационной обвязки.
Сколько времени должен длиться пилот ИИ-агента?
Достаточно, чтобы набрать статистику по реальным данным, но не настолько, чтобы потерять импульс: ориентир — 4–6 недель до первого измеримого результата и 90 дней стабильной работы перед расширением охвата. Средний срок пилота до остановки по рынку — 4,7 месяца, и это признак того, что решение о расширении принимали слишком поздно.
С чего начать, чтобы не повторять типовые ошибки?
С одного узкого процесса, у которого есть владелец и измеримый результат. Не с «ИИ-сотрудника для всех отделов». Успешные внедрения начинались с одной функции — классификации документов, маршрутизации заявок, обогащения данных — и расширялись только после того, как узкая версия отработала три месяца без сюрпризов.
Можно ли дать агенту право менять данные в CRM без подтверждения?
Можно, если ошибка обратима и логируется. Gartner формулирует правило так: автономия не должна превышать надёжность. Практический критерий — цена ошибки. Черновик письма, сортировка заявки, подготовка сводки переносятся легко. Изменение статуса сделки, отправка документов клиенту и удаление записей требуют подтверждения человеком.
Нужен ли отдельный сотрудник для сопровождения агента?
На старте — нет, достаточно назначить ответственного в рамках текущих ролей. При переходе к промышленной эксплуатации — да. Компании, дошедшие до масштаба, заводили отдельную функцию ИИ-эксплуатации: оценка качества, мониторинг, реагирование на инциденты. Без неё эти задачи не делает никто, и агент тихо деградирует.
Что почитать дальше на hermeswiki
Внедрение агента — это не только про процессы, но и про границы: что вообще стоит передавать машине, а что нет. Об этом — материал «ИИ-сотрудник или человек: что передать агенту, а что нельзя».
Как выглядит такой агент в работе на конкретном участке: контроль звонков и CRM в отделе продаж и заявки с базой знаний в поддержке.
Про доступы, права и защиту данных — «Безопасность AI-агента: как Hermes защищает данные и ограничивает доступ». Про выбор между собственной инфраструктурой и сервисом — «Локальный или облачный Hermes Agent: что выбрать».
Если нужно понять, с чего вообще начинать знакомство с агентом, — «Что такое Hermes Agent: возможности и для кого он».