Veltos.Tech

AI и ML

Почему ИИ-пилоты не доходят до продакшена: разбор на цифрах

Разрыв между «попробовали ИИ» и «ИИ реально работает в компании» — не про технологию. Три конкретные, воспроизводимые причины и как их закрыть до старта пилота.

Коротко

По отраслевым оценкам, 60–70% компаний уже запустили хотя бы один пилот с генеративным ИИ, но лишь 25–30% довели его до устойчивой промышленной эксплуатации. Три повторяющиеся причины разрыва: процесс для пилота выбирают по интересности, а не по измеримому эффекту; стоимость эксплуатации на реальном объёме не считают заранее; у пилота нет владельца, отвечающего за конкретную метрику.

Цифра, с которой стоит начать

По отраслевым оценкам вендоров и консалтинговых компаний, 60–70% организаций уже запустили хотя бы один пилот с генеративным ИИ. Из них до устойчивой промышленной эксплуатации доходит только 25–30%. Это не оценка одного конкретного исследования — это диапазон, который повторяется в нескольких независимых отраслевых источниках 2025–2026 годов, и разумно относиться к нему именно как к ориентиру, а не как к точной статистике.

Показательно то, что причина разрыва почти никогда не в самой модели. Модели за последние два года стали заметно лучше, дешевле и доступнее. Проблема — в том, как выбирается и запускается пилот, и это управляемо гораздо сильнее, чем качество модели.

Три причины, которые повторяются снова и снова

ФакторПилот, который умираетПилот, который выживает
Выбор процессаВыбран за новизну и интерес («давайте попробуем чат-бота»)Выбран за измеримый, скучный эффект (разбор типовых заявок)
Стоимость эксплуатацииИзвестна цена демо на малом объёмеПосчитана заранее на реалистичном производственном объёме
Владение результатом«ИТ в целом» отвечает за пилотОдин named человек отвечает за одну конкретную метрику
Пилоты, которые умирают, и пилоты, которые выживают

Причина 1: интересное против скучного

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

«Давайте автоматизируем разбор однотипных заявок» звучит скучно и почти не годится для эффектной презентации. Но у неё есть то, чего нет у чат-бота: чёткая метрика до (среднее время разбора одной заявки, число заявок в очереди) и такая же чёткая метрика после. Скучные задачи почти всегда окупаются быстрее именно потому, что их эффект однозначно измерим — а значит, легко доказуем перед следующим раундом инвестиций в проект.

Причина 2: разрыв между стоимостью демо и стоимостью продакшена

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

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

Причина 3: диффузное владение результатом

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

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

Как выбрать процесс, у которого есть реальный шанс

Оценивайте кандидата на пилот по четырём осям одновременно: рост выручки, снижение затрат, ускорение цикла выполнения задачи, снижение рисков и ошибок. Кандидат, который набирает очки сразу по двум осям, обычно и есть правильная точка входа — он не только эффектен, но и устойчив к вопросу «а зачем мы это делаем», который неизбежно прозвучит на третий месяц.

  • Есть ли данные для задачи прямо сейчас, без полугода на разметку?
  • Посчитана ли стоимость эксплуатации на реалистичном, а не демо-объёме?
  • Назван ли один человек, отвечающий за одну конкретную метрику?
  • Определена ли метрика успеха и порог для решения «масштабировать или остановить» до старта?
  • Терпима ли задача к ошибке модели, или цена ошибки слишком высока для текущего уровня зрелости?

Частые вопросы

Почему так много ИИ-пилотов не доходят до продакшена?

По отраслевым оценкам, 60–70% компаний уже запустили хотя бы один пилот с генеративным ИИ, но лишь 25–30% довели его до устойчивой эксплуатации. Причина чаще всего не в технологии: процесс выбрали по интересности, а не по измеримому эффекту, стоимость эксплуатации на реальном объёме не посчитали заранее, и у пилота не было владельца, отвечающего за конкретную метрику. Закрыть все три пункта до старта — самый надёжный способ увеличить шансы пилота.

Насколько точна цифра 60–70% и 25–30%?

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

Какой процесс лучше выбрать для первого пилота?

Хороший кандидат — повторяющаяся операция с большим объёмом, терпимостью к ошибке и уже существующими данными: разбор входящих обращений, извлечение полей из документов, поиск по внутренней базе знаний. Практика 2025–2026 годов показывает, что самые быстрые эффекты чаще возникают именно в бэк-офисе и поддержке клиентов — не потому что это самая эффектная задача, а потому что она измеримая и низкорисковая.

Что делать, если пилот уже запущен, но буксует?

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

Нужна помощь с этой задачей?

Мы делаем это на практике, а не только пишем об этом. Опишите задачу — разберём и пришлём смету по этапам.

Услуги по теме

Читать дальше