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

 

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

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

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

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

Роман Стятюгин: «Успех определяет не только модель, но и вся среда вокруг нее»

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

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

Екатерина Торсукова: «Главный принцип — платформенность»

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

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

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

Закладывать в решение нужно не столько технологию, сколько управляемость — такой подход рекомендует Александр Ефимов, директор практики искусственного интеллекта и машинного обучения компании GlowByte. «Уже в самом начале работы над проектом надо определить конкретного владельца процесса — того, кто отвечает за экономический результат ИИ-проекта и разбор возможных инцидентов. Без этого решение в ходе масштабирования попадает в организационную серую зону. Кроме того, “экономику” решения надо посчитать еще до выбора архитектуры. На практике это выглядит так: сначала считаете не деньги вообще, а стоимость одной единицы работы модели (грубо говоря, цену за токен или за обработанный запрос), затем сравниваете эту цифру для облака и для локального размещения на горизонте трех-пяти лет. Как известно, у облака низкий CAPEX и высокий OPEX, у собственной инфраструктуры — наоборот, и на коротком горизонте локальное решение почти всегда по деньгам проигрывает, а на длинном выигрывает, поэтому решение “облако или свой сервер” нужно принять именно на стадии проектирования, причем считать нужно сразу на десять отделов вперед, а не только на пилотный, иначе при масштабировании выбранная архитектура может не окупиться».

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

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

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

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