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

 

Сравнивая ИИ-проекты с проектами внедрения бизнес-приложений прежних поколений (ERP, CRM, MES, Workflow и пр.), эксперты единодушно отмечают достаточно высокую предсказуемость хода и результатов масштабирования «традиционных» систем. После того, как найдена оптимальная конфигурация самой системы и рабочей среды для нее, включая инфраструктуру, определена бизнес-логика работы, успешно пройдены различные виды тестирования, отработаны подходы к внедрению и развертыванию, получены экономические оценки и пр., масштабирование прикладной системы происходит по вполне накатанному сценарию. Неожиданности, конечно, возможны, но их масштабы меркнут по сравнению с тем, с чем приходится сталкиваться в ИИ-проектах.

Роман Стятюгин: «Качество работы ИИ определяется не конфигурацией, а контекстом»

«Успешный “пилот” не является гарантом успеха внедрения ИИ-решения в масштабе компании, — делится своими наблюдениями Роман Стятюгин, директор по ИИ-продуктам VK Tech. — Качество работы ИИ определяется не конфигурацией, а контекстом: данными, регламентами и границами предметной области. В соседних подразделениях один и тот же термин может означать разное, данные поступают неочищенными, регламенты разнесены по разным системам, а права доступа у сотрудников со схожими функциями не совпадают. Стоит расширить контур с одного отдела на десять, и меняется все: терминология, качество данных, полнота документов, модели доступа. В результате агент, показавший 90% точности в “пилоте”, в новом контуре может продемонстрировать всего 60%, и причина кроется не в качестве внедрения, а в том, что он столкнулся с другим контекстом».

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

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

Александр Бочкин: «Нужно заранее понять, как изменится весь процесс и какой результат получит бизнес»

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

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

Александр Ефимов: «У лидеров есть умение грамотно ставить задачи ИИ и понимать, каких результатов реалистично ожидать от проекта, причем на уровне всей компании»

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

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

Виталий Агапеев: «Жизненный цикл ИИ-продукта непрерывен: промышленная эксплуатация, разработка и исследовательская работа идут параллельно»

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

Как и его коллеги, Агапеев обращает внимание на необходимость непрерывного мониторинга модели: «Результат работы модели вероятностный, и зависит он не только от программного кода, но и от качества данных и контекста. Со временем данные меняются, и точность прогнозов или ответов может снижаться. Поэтому после запуска нужны постоянный мониторинг качества данных, их валидация, A/B-тестирование новых версий и регулярное переобучение моделей. Жизненный цикл ИИ-продукта фактически непрерывен: промышленная эксплуатация, разработка и исследовательская работа идут параллельно».

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

Максим Андрианов: «При переходе ИИ-систем в промышленную эксплуатацию затраты на токены растут на порядок»

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

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

Василий Борисов: «Позитивный “пилот” часто доказывает лишь то, что технология способна решить задачу в тепличных условиях»

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

Екатерина Торсукова: «ИИ-решение — это динамичная система, нуждающаяся в постоянном наблюдении и адаптации к меняющимся внешним факторам»

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

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