3 причины, почему почти 90% ИИ‑пилотов не становятся рабочими инструментами

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

Для таких подмен уже прижился термин agent washing — по образцу greenwashing. Поставщик переименовывает привычный инструмент (чат‑бот, скрипт или RPA‑цепочку) в «ИИ‑агента», но под капотом ничего не меняется. Это только одна из причин, почему пилоты «умирают», и зачастую не самая важная.

Исследование MIT «The GenAI Divide: State of AI in Business 2025», основанное на 52 глубинных интервью, показало: 95% пилотных проектов с генеративным ИИ останавливаются на ранних этапах, и лишь около 5% дают заметный эффект. Дело не в модели — модели работают. Проблема в отсутствии дисциплины вокруг внедрения.

«ИИ пробовали почти все, но работает он у единиц. 90% пилотов так и не выходят в продакшн и не приносят отдачи. Причина не в том, что ИИ не работает, а в том, что вокруг модели не выстроены процессы. Чаще всего проваливается одно из трёх: постановка задачи, качество данных или доверие к инструменту», — констатирует Олег Кемаев

Разберём каждый барьер и способы его обхода — а пока коротко о точках отказа. Подробнее каждый барьер и способы его обойти разберём на вебинаре 9 июля, а пока пройдёмся по основным точкам отказа.

Причина 1. Нечёткая формулировка задачи

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

В одном проекте проблему решили, сузив задачу до конкретной роли: ИИ‑помощник для нового менеджера. Показатель успеха - скорость выхода на план и снижение нагрузки наставника. Только после такой конкретизации стало ясно, какие данные загружать и какие сценарии первыми автоматизировать.

Правило простое: автоматизируйте то, что можно измерить. Сначала вводят метрики, затем подключают ИИ. Если у пилота нет единого владельца и одной конкретной метрики успеха, это не пилот - это дорогостоящий эксперимент. Перед запуском задайте себе главный вопрос: в какой операции сотрудник теряет больше всего времени и как мы будем измерять улучшение?

Причина 2. Плохие или неполные данные

Ум ассистента определяется данными. Мощная модель на слабом датасете выдаст слабый результат. Проблема проявляется в двух направлениях: внешних и внутренних данных.

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

Внутренние данные - это часто неполнота и «потерянность» контекста. Например, менеджер провёл часовой разговор с клиентом, записал в CRM «перезвонить», и всё остальное исчезло. Аудиозапись разговора - ценный ресурс, сравнимый по значимости с цифрами в карточке сделки, но её никто не использует вручную. Тут помогает распознавание речи и аналитика, которые извлекают из звонка возражения, настроение, ключевые договорённости и превращают разговор в структурированные данные, тогда ассистент строит рекомендации на фактах, а не на догадках.

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

Но даже при хороших данных остаётся третья, самая досадная причина провала.

Причина 3. Подмена. Чат‑бот вместо настоящего агента

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

Пример: сверка с контрагентом. Чат‑бот объяснит алгоритм: «выгрузите файл, сравните, исправьте». Дальше всё делают вручную. Агент получит файл, сам распознает структуру, приведёт её к формату учёта, сформирует документ сверки, заполнит совпадающие позиции и выделит спорные строки для проверки. Он не станет учить вас, как делать — он сделает.

Путаница между этими подходами отражается в цифрах. Gartner оценивает, что из тысяч заявлений о «агентном ИИ» подлинно агентных решений — лишь небольшая сотня. Gartner также прогнозирует, что более 40% проектов агентного ИИ закроют до конца 2027 года — причины те же: рост расходов, неочевидность бизнес‑выгоды и слабый риск‑контроль.

Короткий чек‑лист перед пилотом

1. Постановка задачи. Есть ли один измеримый процесс? Назначен ли один владелец и одна метрика успеха?

2. Данные. Нужны ли внешние источники или дополнительные внутренние данные (например, расшифровки звонков)? Как заполнить пробелы, чтобы ассистент видел полную картину?

3. Тип решения. Где система должна принимать решения самостоятельно, а где ограничиться подготовкой черновика для человека? Каков коридор полномочий и кто подписывает результат в спорных ситуациях?

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