88% пилотных проектов с искусственным интеллектом не доходят до промышленной эксплуатации. Такой вывод сделало совместное исследование IDC и Lenovo, сообщает The New Stack. Для российских команд это не повод отменять эксперименты с моделями и агентами, а довольно ясный сигнал: ИИ-пилоты в продакшене проваливаются чаще не из-за качества демо, а из-за отсутствия понятного пути от презентации к работающему процессу.
Цифра особенно неприятна потому, что proof of concept обычно выглядит убедительно. Команда быстро собирает чат-бота для поддержки, ассистента для разработчиков или агента для разбора документов, показывает экономию нескольких часов в неделю — и получает одобрение на следующий созвон. Затем проект упирается в доступ к данным, интеграции с внутренними системами, требования безопасности, стоимость эксплуатации и вопрос, на который на этапе демо никто не хотел отвечать: кто владелец результата и по какому показателю он считается полезным.
IDC и Lenovo связывают высокий процент неудач с неясными целями и недостаточной готовностью компаний к внедрению. Иными словами, организация может купить инфраструктуру, выбрать модель и собрать прототип, но не иметь согласованного процесса принятия решений вокруг него. Для ИИ это критично: модель не существует отдельно от источников данных, прав доступа, правил обработки ошибок и людей, которые будут разбирать спорные случаи.
Пилот — ещё не продукт
Главная ловушка в том, что к ИИ-проекту часто применяют логику демонстрации, а не продукта. На тестовом наборе запросов ассистент отвечает аккуратно; в реальном контуре появляются устаревшие документы, неполные карточки клиентов, конфиденциальные данные и пользователи, которые формулируют запросы совсем не так, как команда ожидала. Если агент может создавать заявку, менять запись в CRM или запускать действие во внутренней системе, к качеству интеграции добавляется вопрос контроля: какие операции допустимы без подтверждения, а какие должен проверить человек.
Успех пилота сам по себе тоже легко измерить неправильно. Метрики вроде числа диалогов, времени, проведённого в интерфейсе, или доли положительных оценок говорят о любопытстве пользователей, но не обязательно о бизнес-эффекте. Гораздо полезнее заранее выбрать измеримый результат конкретного процесса: сократилось ли время первичной обработки обращения, снизилась ли доля ручной классификации документов, уменьшилось ли количество ошибок при поиске внутренней информации. Без базовой линии сравнения даже удачный пилот превращается в дорогую демонстрацию возможностей модели.
Для разработчиков это означает, что ИИ-пилоты в продакшене нужно проектировать как обычную, но более капризную сервисную систему. Нужны наблюдаемость, журналирование действий, оценка качества ответов, контроль версий промптов и моделей, лимиты на расходы и сценарии деградации. Система должна предсказуемо вести себя не только при удачном запросе, но и при отсутствии данных, сбое внешнего API, галлюцинации модели или попытке пользователя получить доступ к закрытой информации. У LLM есть привычка впечатлять на демо и требовать инженерной дисциплины после первого же реального понедельника.
Для бизнеса задача начинается ещё раньше — с выбора процесса. Внедрение не стоит начинать с формулировки «нам нужен ИИ-агент». Полезнее назвать узкое место: например, сотрудники поддержки вручную ищут ответы в нескольких базах знаний или аналитики тратят часы на подготовку типовых сводок. После этого можно определить владельца процесса, допустимый уровень ошибок, набор данных и экономический эффект. Если процесс нельзя описать без фразы «ну, сотрудники обычно сами понимают», автоматизировать его агентом будет особенно весело — и, вероятно, дорого.
Что отличает проекты, которые всё-таки доходят до эксплуатации
Переход от POC к рабочему сервису требует не масштабировать модель любой ценой, а последовательно снимать риски. Начать можно с ограниченного контура и задач, где ответ модели не выполняет необратимое действие. Затем — добавить проверку человеком, собрать реальные примеры ошибок, наладить оценку качества и только после этого расширять полномочия системы. Такой подход медленнее красивого ролика с автономным агентом, но позволяет понять, где ИИ действительно сокращает трудозатраты, а где лишь переносит их в очередь на ручную проверку.
Отдельная проблема — разрыв между ИТ, безопасностью и владельцем бизнес-процесса. Если разработчики отвечают за прототип, служба безопасности подключается перед запуском, а бизнес ждёт мгновенного эффекта, проект почти гарантированно остановится на согласованиях. Команде нужен общий договор: какие данные разрешены для обработки, где они хранятся, как устроен доступ, кто разбирает инциденты и кто принимает решение об отключении системы. Это не бюрократия вокруг модели, а часть её эксплуатационного контура.
Российским компаниям к универсальным проблемам добавляется выбор платформ, моделей и способа размещения. В зависимости от требований к данным и регуляторных ограничений придётся заранее решать, возможна ли внешняя модель, нужен ли закрытый контур и кто будет поддерживать инфраструктуру. Эти вопросы не стоит оставлять «на этап внедрения»: именно они часто определяют, можно ли вообще перенести удачный прототип в рабочую среду без полной переделки.
Вывод исследования IDC и Lenovo не в том, что от ИИ нужно ждать меньше. Скорее, компании должны перестать считать пилот финальной проверкой идеи. Настоящая проверка начинается после него: выдерживает ли решение реальные данные, понятна ли его экономика и готов ли бизнес менять процесс, а не просто добавить к старому ещё один чат. Пока ответы на эти вопросы появляются слишком поздно, ИИ-пилоты в продакшене будут оставаться редким исключением, а не нормой.