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

Построить работающий пилот — это 10-15% пути. Остальные 85% — это превращение модели в систему, которая приносит бизнесу деньги, а не головную боль. Такой вывод мы вынесли из нашей трехлетней практики реализации проектов по внедрению ИИ в крупных компаниях — от прогнозирования спроса в FMCG до компьютерного зрения на строительных площадках.

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

Почему 70% пилотов не доживают до продуктива

Пилот — это демонстрация возможности, а продуктив — это эксплуатация в сложной системе с экономикой, ответственностью и рисками. Между этими двумя состояниями возникает несколько типовых разрывов. Обычно сценарий выглядит так: команда data science за 2-3 месяца собирает модель на исторических данных, показывает хорошие метрики на тесте, получает одобрение руководства. А затем проект замирает.

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

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

В эксплуатации ситуация принципиально иная. Модель начинает получать данные из операционных систем — «1С», SAP или ERP-решений, где качество информации значительно ниже. В среднем, от 15 до 30% записей могут содержать ошибки, пропуски, дубли или неконсистентные значения.

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

На одном из FMCG-проектов мы обнаружили, что у клиента 12% SKU имели некорректные единицы измерения в учётной системе. Модель прогнозирования спроса на пилоте работала идеально, но при подключении к живым данным точность упала на 25 процентных пунктов за первый же месяц.

Вторая причина — отсутствие «последней мили» до конечного пользователя. Модель может выдавать прекрасные прогнозы, но, если результат приходит в виде CSV-файла на почту, а не встроен в рабочий процесс закупщика или прораба, adoption стремится к нулю. Нет смысла в разработке инновационных моделей и сложных агентов, когда нет системы по использованию инструмента в бизнесе. В строительном проекте мы потратили больше времени на интеграцию результатов детекции дефектов в существующий workflow инспекции, чем на саму модель компьютерного зрения.

Третья — экономика не сходится на масштабе. Пилот на 500 SKU обслуживает один специалист по данным вручную. Когда ассортимент вырастает до 5-10 тыс. позиций, нужна автоматизация переобучения, мониторинг деградации модели и поддержка инфраструктуры. Но расходы на доработку часто превышают ожидаемый эффект.

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

Что ломается технически: данные, инфраструктура, мониторинг

Самый недооценённый этап — это data engineering. В enterprise-среде данные распределены по десяткам систем, каждая из которых имеет собственные форматы, различную частоту обновления, ограничения по доступу и уровень качества. Это создаёт высокую степень фрагментации и усложняет формирование единого, согласованного источника данных для моделей.

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

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

В FMCG-проектах я работал с интеграциями через SOAP API к «1С», где данные обновляются с задержкой в 24-48 часов и могут ретроспективно корректироваться. Это означает, что модель должна уметь работать с «плывущей» историей. Но это требование, которое редко закладывают на этапе пилота.

Инфраструктурно пилот живёт на ноутбуке аналитика или в Jupyter-ноутбуке в облаке. Продуктив требует контейнеризации, CI/CD, автоматического масштабирования и, что критично для российского рынка, — возможности развёртывания в закрытом контуре без доступа в Интернет.

Однако во многих компаниях политика информационной безопасности запрещают любые облачные решения. В итоге вся инфраструктура ML должна работать на внутренних серверах с ограниченными ресурсами.

Отдельная проблема — мониторинг модели в продуктиве. Без системы отслеживания data drift и деградации качества модель тихо угасает за 2-4 месяца. Причем не всегда можно быстро заметить ошибки. Поэтому без постоянного мониторинга есть риск работать с моделью, которая продолжит выдавать рекомендации на основе неверных паттернов.

Как выстроить экономику ИИ-продукта

Экономика ИИ-продукта не возникает сама по себе. Её нужно проектировать так же осознанно, как архитектуру системы. Многие команды сначала делают модель, а уже потом решают её экономический смысл.

Главная ошибка — считать ROI от модели, а не от системы. Метрики вроде WAPE на уровне 55-60% остаются абстракцией и не отражают бизнес-ценность сами по себе. Для принятия инвестиционных решений необходима прямая связка с операционными и финансовыми показателями.

Корректная постановка — перевод качества модели в измеримый экономический эффект: сокращение упущенных продаж на 8-12%, снижение товарных остатков на 15-20%, высвобождение оборотного капитала и т. д.

Такие показатели формируют язык диалога с CFO и служат основанием для принятия решений о масштабировании и бюджетировании.

Мы пришли к следующей структуре затрат для типового enterprise-проекта:

  • 30-40% бюджета уходит на data engineering и интеграции;
  • 15-20% — на ML-разработку;
  • 20-25% — на фронтенд и UX для конечных пользователей;
  • оставшиеся 15-25% — на мониторинг, поддержку и доработку в первый год эксплуатации.

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

Что делать: чеклист перед масштабированием

Прежде, чем переводить пилот в продуктив, стоит проверить несколько вещей.

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

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

И наконец, есть ли «внутренний мотиватор» на стороне клиента, то есть человек, который будет «продавать» систему своим коллегам после того, как подрядчик уйдёт?

Если хотя бы на два вопроса ответ «нет» — проект с высокой вероятностью не переживёт первый квартал после запуска.

ИИ в enterprise — это не про модели. Это про системы, которые работают с грязными данными, вписываются в существующие процессы и приносят измеримый результат. Компаниям, которые это понимают на старте, удаётся сократить путь от пилота до продуктива с 12-18 месяцев до 4-6. И главное, получить возврат инвестиций уже в первый год.

Артем Розинский, СТО Insight AI