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

 

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

Технологические барьеры

Екатерина Торсукова: «Самый значимый технический барьер — это отсутствие ИТ-инфраструктуры для разработки и обслуживания ИИ-решений или моделей»

«Самый значимый технический барьер — это отсутствие ИТ-инфраструктуры для разработки и обслуживания ИИ-решений или моделей, — отмечает Екатерина Торсукова, руководитель направления Data Science в компании «ДАР» (входит в ГК «КОРУС Консалтинг»). — Причем речь не только о GPU. Все ИИ-решения включают в себя сложный пайплайн, который может охватывать предобработку данных — структурированных и неструктурированных, создание ML-моделей или ИИ-агентов. На первый план выходит именно платформенный подход с платформой данных и платформами MLOps и LLMOps для автоматизации жизненного цикла ML-моделей и управления ИИ-агентами. Если требуется дополнительная защита ИИ-решения, то понадобится и DevSecOps».

Василий Борисов, генеральный директор «Серч Сентрик», считает, что главный технический барьер следует искать прежде всего в данных и интеграции: «В масштабе предприятия появляются десятки источников: файловые хранилища, ECM/EDMS, почта, CRM, ERP, базы знаний. У них различные форматы, качество, метаданные, владельцы, жизненный цикл, зачастую отсутствуют сквозные права доступа. Если корпоративный поиск не умеет надежно учитывать ACL исходной системы, поддерживать инкрементальную индексацию, фиксировать происхождение ответа и синхронизировать данные после изменения прав, то он превращается в потенциальный канал утечки. Для масштабирования требуется не просто подключить больше источников, а создать управляемую фабрику подключения данных, охватывающую коннекторы, извлечение метаданных и ACL, массовый OCR и средства контроля качества».

Максим Андрианов: «От внедрения ИИ бизнес чаще всего отказывается из-за инфраструктурных и регуляторных ограничений»

Чаще всего бизнес отказывается от внедрения ИИ из-за инфраструктурных и регуляторных ограничений, делится своими наблюдениями Максим Андрианов, директор дирекции разработки и внедрения ПО компании «Инфосистемы Джет»: «По данным нашего исследования, стоимость “железа” становится препятствием для 58% организаций, а юридические риски — для 56%. Чтобы внедрить ИИ, необходимо решить, в частности, где именно обрабатывать персональные данные и коммерческую тайну, а при выстраивании архитектуры учитывать отраслевые требования регулятора, в том числе к объектам КИИ. На практике компании часто отказываются выносить данные за периметр, и в этом случае “пилот”, развернутый в публичном облаке, приходится заново собирать в своем контуре. При переходе от “пилота” к промышленной эксплуатации на первый план выходит другая группа факторов: 46% компаний не видят устойчивого экономического эффекта от ИИ-проектов. Также бизнес смущает нестабильное качество моделей и их галлюцинации — в нашем исследовании это отметили почти 40% респондентов».

И все же основным препятствием на пути внедрения и масштабирования ИИ Андрианов видит неготовность процессов, данных и интеграций: «Без инфраструктуры AI-Ready искусственному интеллекту не с чем работать, следовательно, продемонстрировать ожидаемые результаты он не сможет. Инфраструктура для ИИ, помимо “железа”, включает еще три аспекта. Первый — цифровизация бизнес-процессов в корпоративных системах, которые формируют цифровой “след” процессов компании, в том числе сведения о клиентах, документах, ресурсах, действиях и принятых решениях. Второй — инфраструктура данных, например, озера данных, позволяющие дешево хранить большие объемы неструктурированной информации, и, конечно, экосистема контроля качества данных. Третий аспект — интеграция корпоративных систем с ИИ-платформой, позволяющая ИИ выйти за рамки чата и научиться автономно действовать внутри бизнес-процессов».

Виталий Агапеев: «Для промышленной эксплуатации нужна MLOps-инфраструктура»

По мнению Виталия Агапеева, руководителя центра ИИ-экспертизы ИТ-группы N3.Tech, основные технические сложности связаны с данными, инфраструктурой и безопасностью: «В “пилоте” модель обычно работает на базе заранее подготовленной выборки и в изолированной среде. При масштабировании приходится подключать данные из множества систем, а они могут различаться по структуре, полноте и качеству. Поэтому решение должно одновременно обеспечивать целый ряд важных свойств: выдерживать промышленную нагрузку, интегрироваться с корпоративными системами и соответствовать требованиям информационной безопасности — разграничивать доступ, вести журнал действий и проходить необходимые проверки. Для промышленной эксплуатации также нужна MLOps-инфраструктура: контроль версий моделей, данных и окружения, автоматизация обновлений, возможность воспроизвести результат и при необходимости откатить изменения. Отдельного мониторинга требуют дрейф данных, снижение качества модели и аномалии. Кроме того, у ИИ появляются специфические угрозы, в том числе намеренное искажение входных данных и попытки заставить модель выдать некорректный результат».

Роман Стятюгин: «Резкий рост нагрузки требует оптимизации архитектуры»

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

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

Организационные и экономические барьеры

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

«Организационные барьеры часто проявляются уже после успешного “пилота”, — рассказывает Виталий Агапеев, руководитель центра ИИ-экспертизы ИТ-группы N3.Tech. — Его эффект может быть понятен на уровне общей пользы, но не переведен аккуратно в деньги, а полная стоимость владения, включая затраты на вычислительные мощности, интеграцию, сопровождение и контроль качества, становится вполне понятной только при масштабировании. Поэтому при автоматической обработке тысяч обращений “экономика” потребует нового расчета. Есть и кадровая проблема: команда, способная быстро собрать прототип, не всегда обладает компетенциями для промышленной разработки, выстраивания архитектуры и MLOps. При этом для масштабного решения нужен полный состав специалистов, а собрать его бывает сложно. Наконец, ИИ меняет привычные рабочие процессы. Сотрудники при этом могут воспринимать автоматические рекомендации как угрозу своей экспертизе, не доверять модели или, наоборот, пытаться подстроить ее ответы под ожидаемый результат. Если заранее не определить правила проверки, границы применения модели, участие человека и ответственность за ошибки, риски внедрения становятся слишком высокими».

Василий Борисов: «Организационное решение состоит в закреплении продуктовой модели»

По наблюдениям Борисова, предприятия часто сталкиваются с ловушкой распределенной ответственности: «Бизнес считает ИИ инструментом ИТ-службы; ИТ ожидает от бизнеса четкого описания процесса и владельца; служба безопасности видит риск того, что “модель все помнит”; юридический отдел отмечает непрозрачность лицензий, персональных и коммерческих данных; пользователи не понимают, где ИИ можно доверять, а где его ответ нужно проверять. Организационное решение состоит в закреплении продуктовой модели: для каждого промышленного ИИ-сервиса должны быть определены владелец бизнес-результата, владелец данных, технический владелец, владелец рисков, пользовательские группы, допустимые сценарии и границы автоматизации, что на пилотных проектах не происходит практически никогда».

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

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

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

Александр Ефимов: «“Пилот” без бизнес-владельца автоматизирует не реальный рабочий процесс, а его удобную версию»

В качестве второго серьезного барьера Ефимов отмечает отсутствие владельца процесса и ответственности за результат. «Довольно типичная история: “пилот” выполняется ИТ-командой с охватом части подключенных систем, задача решается, метрики получаются хорошие. Полученное в ходе “пилота” решение демонстрируют бизнесу, все воодушевляются — а затем при подготовке к масштабированию выясняется, что агенту в продуктиве нужны данные еще из двух-трех систем, к которым в пилотной версии просто не подключались, потому что для узкого демо-кейса это было не обязательно, — делится опытом эксперт. — И тут начинается совсем другая история: выясняется, что просто “включить” еще одну интеграцию недостаточно — нужно пересматривать саму логику работы агента, потому что с новыми источниками данных меняются и возможные сценарии, и условия, при которых агент должен остановиться и передать принятие решения человеку. По сути, вся эта ситуация — прямое следствие того, что у “пилота” с самого начала не было бизнес-владельца процесса и будущего агента: если бы он был, требования по интеграции и особенностям процесса всплыли бы еще на старте. Отсюда вывод: “пилот” без бизнес-владельца автоматизирует не реальный рабочий процесс, а его удобную версию. Но дело в том, что масштабировать нужно именно реальный процесс».

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

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

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