Внедрение ИИ: что предприятия ошибаются в моделях масштабирования

Руководители вкладывают миллионы в искусственный интеллект, однако исследование BCG, проведенное в 2025 году, показало, что только около 5% компаний получают измеримую выгоду от искусственного интеллекта в больших масштабах , тогда как большинство из них практически ничего не видят. В то же время многочисленные опросы показывают, что более половины проектов ИИ никогда не доходят до производства или закрываются после проверки концепции из-за плохих данных, слабого управления и неясной коммерческой ценности.

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

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

Почему масштабирование ИИ не удается большинству предприятий?

Большинство крупных организаций не испытывают недостатка в экспериментах с ИИ. Последнее исследование McKinsey State of AI показывает, что почти все респонденты сообщают об использовании ИИ где-либо, однако лишь небольшое меньшинство видит устойчивый эффект на уровне предприятия.

Что происходит на практике:

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

За этим шаблоном скрываются некоторые предсказуемые проблемы:

• ИИ как разовая «инициатива», а не оперативный потенциал
  ИИ рассматривается как проект с датой начала и окончания. Есть бюджетный цикл, вендор, дашборд, презентация. Чего не хватает, так это взгляда на ИИ как на продукт, которому нужна дорожная карта, право собственности и текущий бюджет.
• Пилотные проекты, игнорирующие производственную среду
  Многие пилоты спокойно зависят от тщательно подобранных наборов данных, ручного проектирования функций или одного опытного пользователя. Ничего из этого не существует в живой экосистеме. Когда команды пытаются перенести один и тот же артефакт в производство, все — от доступа к данным до поведения задержек — сразу меняется.
• Отсутствие экономической точки зрения на масштабирование
  Советы директоров слышат истории о десятикратном увеличении производительности. Чего они редко видят, так это стоимостного представления инфраструктуры, наблюдаемости, обновлений моделей и управления изменениями. Без этого ожидания разрастаются, и ИИ попадает в список «неудавшихся инноваций», когда первая волна проектов разочаровывает.

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

Распространенные эксплуатационные ошибки

Когда я смотрю на неудачные или застопорившиеся инициативы в области ИИ, я почти всегда обнаруживаю одни и те же модели работы.

Подводные камни, которые вы видите в дикой природе

За этими симптомами продолжают проявляться некоторые структурные проблемы:

• Фрагментированные цепочки поставок данных
  Данные для обучения, тестирования и обслуживания поступают из разных источников, но службы управления данными объединяют эти конвейеры, чтобы уменьшить дрейф и нестабильность. Модели хорошо себя ведут в тестах, но плохо себя ведут в продакшене, потому что распределение входных данных и их актуальность совершенно разные.
• Скромное сотрудничество
  Специалисты по обработке данных владеют блокнотами. Команды платформы владеют кластерами. Владельцы бизнеса имеют собственные KPI. Никто не владеет полным жизненным циклом от концепции до выхода на пенсию. Каждая передача приводит к задержкам, переделкам и тонким несоответствиям в ожиданиях.
• Операционный риск рассматривается как второстепенная мысль
  Юридические вопросы, соблюдение требований и безопасность вступают в разговор, как только что-то приближается к запуску. Они видят готовое решение, выражают обоснованную обеспокоенность, и проект застопоривается. Кажется, что «правление блокирует ИИ», тогда как настоящая проблема заключается в позднем вмешательстве.

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

MLOps как недостающее звено в операциях ИИ

MLOps часто называют «DevOps для машинного обучения». Это определение технически правильное, но оно недооценивает то, что происходит. На практике MLOps — это дисциплина, которая превращает модели в готовые к использованию системы и связывает их с реальными бизнес-результатами.

Вы можете думать об операциях ИИ как о трёх слоях, которые MLOps должны удерживать вместе:

• Ресурсы

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

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

Управление и мониторинг, которые работают в реальной жизни

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

Развитые операции ИИ, как правило, объединяют управление в три практических цикла:

• Петля технического мониторинга

Недавний отраслевой анализ показывает, что плохое управление данными и слабый надзор за ИИ уже являются основными причинами, по которым многие проекты ИИ, по прогнозам, потерпят неудачу или будут отменены в ближайшие 1–2 года.

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

Тематические исследования по успешному масштабированию ИИ

Чтобы прояснить это, давайте рассмотрим два часто встречающихся анонимных шаблона.

Пример 1: От экспериментального театра к производственному искусственному интеллекту

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

Ключевые проблемы:

• Каждая команда создавала свои собственные конвейеры и инфраструктурные шаблоны.
• Отсутствие общих стандартов для мониторинга, доступа к данным или развертывания моделей.
• Владельцы бизнеса рассматривали ИИ как «ИТ-проект», а не как часть своих прибылей и убытков.

Компания сменила тактику и создала небольшую центральную группу по управлению искусственным интеллектом с тремя обязанностями:

• Определите и поддерживайте эталонный стек MLOps (шаблоны приема данных, конвейеры обучения и обслуживания, отслеживание экспериментов, реестр моделей).
• Установите и внедрите стандарты наблюдения, управления и отчетности о затратах.
• Научите бизнес-команды относиться к сценариям использования ИИ как к продуктам с владельцами, показателями успеха и дорожными картами.

В течение 18 месяцев:

• Время от идеи до первого выпуска продукции сократилось с 9–12 месяцев примерно до 8 недель.
• Более 20 моделей работали с общими инструментами вместо индивидуальных сценариев.
• Ежеквартальные обзоры связывали каждый вариант использования с измеримым влиянием на прибыль и запасы.

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

Пример 2: Промышленный ИИ, выдерживающий контакт с реальностью

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

Внутренняя проверка выявила три основные причины:

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

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

Они:

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

Мониторинг теперь включал в себя как индикаторы дрейфа, так и обратную связь с места. Когда модель начала деградировать, переподготовка проводилась по тому же стандартизированному конвейеру, а не через разовый спасательный проект.

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

Куда идти дальше?

Если вы серьезно относитесь к масштабированию моделей, начните с рассмотрения операций ИИ как первоклассной дисциплины:

• Составьте карту полного жизненного цикла 2–3 важных вариантов использования — от приема данных до вывода из эксплуатации.
• Определите каждый ручной шаг, передачу и «теневой процесс», который поддерживает работу моделей.
• Решите, какие элементы вашего стека MLOps будут общими и самоуверенными по умолчанию.
• Встраивайте управление и мониторинг в эти настройки по умолчанию, а не накладывайте их сверху.

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