Почему 95% внедрений ИИ в бизнес проваливаются — и что отличает успешные 5%

По рынку прошла новость: только 5% корпоративных внедрений искусственного интеллекта успешны и приносят бизнесу реальную прибыль. Остальные 95% остаются на стадии пилотов и красивых презентаций.

Главная проблема таких проектов — не сам запуск AI, а попытка довести его до стабильного качества и окупаемости в реальном бизнес-процессе. 

Почему так происходит и что отличает рабочие внедрения от провальных, рассказал Илья Летунов — основатель компании Manaraga.ai. Его команда довела до промышленной эксплуатации больше 10 ИИ-проектов в страховых, ритейле, телекоме и транспортных компаниях.

Привычная схема внедрения больше не работает

С прошлыми инновациями все было более-менее понятно: есть технология, есть поставщик, который создает продукт под повторяемый сценарий, компания его выбирает и внедряет. 

По этой схеме ставили ERP-системы (управление ресурсами предприятия), CRM (системы управления отношениями с клиентами), облачные сервисы и решения для работы с большими данными — все привыкли, что такая последовательность работает. 

С ИИ привычная схема ломается по трем причинам: 

1. Кастомизация съедает 80% затрат. Нельзя взять готовый повторяемый сценарий, под который уже создан продукт, и просто его внедрить. ИИ не работает по шаблону, а, наоборот, адаптируется под конкретные данные и процессы компании. Во время внедрения он должен дообучаться и работать с тем, что есть у заказчика: бизнес-процессами, интеграциями и людьми. 
2. Технологии меняются быстрее, чем длится цикл внедрения. Продукты устаревают за 3–6 месяцев — то, что Amazon и Google выпустили год назад, сегодня выглядит совсем иначе, платформы постоянно видоизменяются. Привычный подход, при котором компания долго выбирает поставщика и неторопливо разворачивает решение, перестает работать: пока идет проект, технология успевает уйти вперед. 
3. Проект не заканчивается после релиза. Бизнес-процессы меняются, появляются новые данные и возникают новые ситуации — модель приходится непрерывно дообучать и проверять. Это отдельная работа, которую нужно вести параллельно с эксплуатацией. Такой практики на рынке пока почти нет, и многие компании не сразу перестраиваются под новый режим. 

ИИ внедряют не айтишники

Во многих компаниях внедрение технологий выглядит одинаково:

1. бизнес формулирует требования;
2. IT получает ТЗ;
3. подрядчик разрабатывает систему;
4. бизнес принимает результат.

С ИИ эта схема перестает работать, потому что искусственный интеллект использует не только технические данные, но и бизнес-логику принятия решений.

Поэтому AI-проект требует совместной работы бизнеса и разработки с первого дня.

Вместо классического ТЗ команде приходится:

1. собирать датасеты;
2. размечать примеры;
3. формулировать критерии качества;
4. описывать логику принятия решений;
5. постоянно проверять результаты.

Стратегический путь — собрать универсальные команды с T-shape экспертизой, где сотрудники сочетают глубокое знание своей области и широкий кругозор в смежных. Менеджмент, бизнес-экспертиза и IT работают совместно с первого дня, а не разрезают проект на изолированные этапы: сначала создали требования, потом реализовали, потом приняли. Здесь же можно привлечь технологического партнера или собрать такие команды внутри компании.

Как это выглядело в реальном проекте: кейс страховой компании

Один из проектов команды Manaraga.ai — внедрение ИИ-системы в департамент медицинского ассистанса страховой компании. Внутри этого подразделения работает больше 100 операторов, которые помогают клиентам записываться в клиники и согласовывать услуги по страховке. Поток обращений — около 10 тысяч клиентов.

Когда клиент обращается за услугой, оператору нужно:

1. сверить тариф и доступные лимиты; 
2. посмотреть историю обращений;
3. подобрать клинику и врача;
4. оформить гарантийное письмо;
5. подтвердить запись.

Для этого сотрудник вручную собирает информацию из нескольких систем: CRM, переписок, PDF-документов с тарифами и внутренних баз.

На первый взгляд процесс выглядит подходящим для классической автоматизации. Но на практике все оказалось сложнее.

Почему классическая автоматизация не подошла

Процесс был сложен по трем причинам:

1. У каждой клиники свои правила. Одна принимает клиента только после конкретных анализов, другая работает по своему формату гарантийного письма.
2. Часть логики никто не прописал в системах. Критерии решений знали только операторы и тимлиды. Почему конкретный клиент идет в конкретную клинику — нигде не записывали.
3. Данные лежали в разных местах. Тариф в PDF, лимиты в системе, переписка с клиентом в почте — все это надо было собирать вручную для каждой заявки.

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

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

Как итог, были такие проблемы: 

1. ошибки в документах;
2. дубли писем;
3. неверно сверенные лимиты;
4. монотонная нагрузка на операторов.

Все это увеличивало операционные затраты: сотрудники уставали от монотонной работы, а обработка одного обращения могла растягиваться на несколько часов.

Что именно автоматизировали

Команда не пыталась автоматизировать весь процесс целиком. Сначала ИИ внедряли в самые типовые сценарии, на которые приходилось около 60-70% нагрузки.

Система взяла на себя:

1. анализ документов и переписок;
2. сбор контекста из CRM и внутренних систем;
3. проверку лимитов страховой программы;
4. подбор клиники;
5. формирование гарантийных писем;
6. отправку документов в клинику;
7. создание записи на прием.

При этом сложные или новые сценарии возвращались оператору на проверку и разбор.

Команда разделила систему на несколько ИИ-модулей:

ИИ-саммарайзер. Этот модуль собирает данные из разных источников — CRM, переписок, документов и внутренних систем — и формирует краткую сводку по обращению.

То, что раньше занимало у оператора 5–7 минут ручного поиска, система делает за 10–15 секунд.

Суфлеры. Этот модуль автоматизирует типовые действия оператора и подключается к работе после саммарайзера.

Когда система собрала достаточно контекста, суфлеры автоматически:

1. подбирают клинику по бизнес-правилам;
2. заполняют поля в CRM;
3. формируют гарантийные письма;
4. готовят сообщения для клиента;
5. создают запись на прием.

По сути, модуль берет на себя до 80% рутинных действий и снижает количество ошибок при ручной обработке.

Модуль контроля качества. Это отдельный модуль в реальном времени проверяет действия и сообщения операторов на соответствие внутренним стандартам качества.

Система контролирует:

1. корректность данных;
2. соответствие бизнес-правилам;
3. грамотность сообщений;
4. тон коммуникации с клиентом.

Модуль автоматически проверяет все чаты и дает операторам мгновенную обратную связь по качеству коммуникации. Если данных не хватает или возникает новый сценарий, система возвращает обращение оператору для ручной проверки.

Такой подход помогает поддерживать качество сервиса и одновременно дообучать ИИ на сложных кейсах.

Возврат на человека изначально заложили в архитектуру как обязательный элемент, а не аварийный механизм.

Что получилось в результате

После внедрения ИИ-системы:

1. время обработки заявки сократилось на 30%;
2. производительность операторов выросла примерно в 1,5 раза;
3. снизилось количество ошибок;
4. клиенты стали быстрее получать ответ, оставаться довольны сервисом и в результате чаще продлевать договоры.

Для команды неожиданным эффектом стало то, что ИИ не заменил операторов, а снял с них рутину. Сотрудники перестали тратить время на поиск данных, заполнение типовых документов и отправку писем. 

Вместо этого операторы начали больше заниматься сложными кейсами, проверкой качества и разбором ошибок ИИ. По сути, их роль сместилась от рутинной обработки заявок к контролю и обучению системы. 

5 правил успешного внедрения ИИ в бизнес 

На примере этого и других проектов Илья сформулировал пять рекомендаций, которые отличают рабочие внедрения от провальных:

1. Начинать нужно с датасета (dataset)

Датасет — это набор исторических данных с примерами того, как человек принимал решения в похожих ситуациях. По сути, это не жесткий алгоритм работы, а примеры реальных ситуаций с правильными ответами и логикой, на которых ИИ-агент учится повторять процесс принятия решений. 

Самая частая ошибка — собирать такие данные в финале, чтобы свериться с результатом. На практике делать нужно ровно наоборот.

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

Полноценный датасет содержит 200-500 размеченных случаев с входящими данными, эталонным ответом и обоснованием. Сборка занимает 1,5-2 месяца совместной работы бизнеса и команды разработки.

Лайфхак для ускорения. Бизнес-эксперты вручную размечают 50 реальных кейсов с эталонными ответами. После этого эти примеры используют как основу для генерации дополнительных сценариев через нейросеть. ИИ может создать похожие, но не идентичные случаи: с другими тарифами, клиниками или запросами клиента, сохранив при этом ту же логику принятия решения. В результате команда получает еще 250 примеров, которые нужно только проверить и скорректировать, а не размечать полностью вручную.

2. Автоматизация — это ползунок, а не рубильник

Одна из главных ошибок — пытаться сразу передать ИИ весь процесс.

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

Поэтому ИИ лучше внедрять постепенно:

1. сначала автоматизировать самые типовые обращения;
2. проверять качество;
3. собирать обратную связь;
4. только потом расширять покрытие.

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

3. Нужно заранее собирать мета-информацию

В большинстве CRM или ERP фиксируется только результат процесса: что пришло на вход, что записал оператор и какое решение он принял. Но логика, по которой сотрудник принял это решение, обычно нигде не фиксируется. 

Даже если до ИИ-проекта еще далеко: начинайте накапливать мета-информацию — пояснения к решениям в бизнес-процессах. Просите сотрудников фиксировать не только результат, но и обоснование решений.

4. Анонимизировать персональные данные через программу-фильтр 

Частый стопор внедрения — спор со службой информационной безопасности о том, что и как можно передавать в модель. На самом деле большей части этих споров можно избежать.

Чтобы не строить сложных процессов во внутреннем контуре или облачных сервисах, достаточно настроить guard-прокси — программу-фильтр, которая перехватывает запросы и автоматически вырезает из них персональные данные. Решение, какую клинику предложить, модель примет так же корректно. Это сильно расширяет возможности использования нейросетей.

5. С первого дня держать в фокусе бизнес-метрику и порог окупаемости с первого дня

Компания внедряет ИИ-агента не ради внедрения технологии, а для достижения конкретной бизнес-метрики. В случае со страховой компанией такой метрикой было время обработки одной заявки. 

В подобных проектах логика внедрения должна выглядеть так: 

1. замерить текущий процесс;
2. собрать датасет;
3. сделать первую сборку;
4. оценить процент качества;
5. сравнить его с порогом, при котором начинает сходиться ROI (возврат на инвестиции).

В этом и заключается главный риск ИИ-проектов: заранее невозможно предсказать, как нейросеть поведет себя в конкретной предметной области и с данными конкретной компании. 

Внедрять процесс, который работает максимум на 60%, чаще всего невыгодно — расходы на поддержку не окупят бизнес-результат. 

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

До первой сборки ИИ-проект остается экспериментом 

Пока не собрана первая версия решения, любое планирование остается гаданием. 

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

До первой сборки ИИ-проект лучше воспринимать как эксперимент: сначала собрать базовую версию, оценить качество и только потом принимать решение о масштабировании.