Top.Mail.Ru
РБК Компании
ГлавнаяUmbrella IT15 мая 2026

Почему агенты не доходят до продакшна и при чем здесь правила разработки

Разбираемся, почему пилоты не превращаются в систему и что именно ломается при переходе к продакшну
Почему агенты не доходят до продакшна и при чем здесь правила разработки
Источник изображения: freepik.com
Константин Попандопуло
Константин Попандопуло
Технический директор Umbrella IT

Эксперт по формированию IT-стратегии в соответствии с бизнес-целями.

Подробнее про эксперта

За последний год компании массово начали запускать ИИ-агентов: для поддержки, аналитики, внутренней автоматизации. При этом переход к масштабу остается проблемой. По данным McKinsey, 23% компаний уже масштабируют агентные ИИ-системы хотя бы в одной функции, еще 39% находятся на стадии экспериментов, но ни в одной отдельной бизнес-функции доля масштабирования не превышает 10%. 

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

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

Пилоты не превращаются в систему. В чем причина

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

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

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

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

Что именно ломается при переходе к продакшну

Переход от пилота к продакшну требует не только увеличения нагрузки, но и изменения требований к системе — причин несколько:

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

Если не заложить все эти элементы заранее, любой рост повлечет за собой усложнение системы и возрастание рисков.

Почему дело не в технологиях

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

Главный барьер — отсутствие единых правил разработки.

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

Что меняет ситуацию

Чтобы разрозненные агенты объединились в систему, начинать надо не с очередного ИИ-помощника, а с общих правил, по которым агенты будут создаваться и поддерживаться. Важно сначала зафиксировать общий слой, который потом можно использовать во всех новых сценариях:

  • единые правила работы с моделями;
  • стандарты для сценариев и взаимодействия с пользователем;
  • ограничения и проверки;
  • единый способ работы с данными и внутренними системами;
  • метрики качества и механизм их оценки.

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

Почему это работает

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

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

И главное — появляется управляемость. Компания понимает, как устроены ее ИИ-контуры, какие риски в них заложены и что нужно менять при масштабировании.

Как бизнес использует единые правила прямо сейчас

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

У Сбера развитие ИИ идет через платформенный контур. Модели, инфраструктура и сервисы (включая GigaChat и внутренние ML-платформы) выступают не отдельными продуктами, а базой для других решений. Новые сценарии не создаются изолированно — они подключаются к уже существующей системе с едиными правилами доступа к данным, контролем качества и безопасностью.

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

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

Что в итоге

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

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

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

Рекомендации партнеров:

Новости отрасли:

Все новости:

Достижения

Технологический бизнес-партнернам доверяют METRO, БКС, Лига Ставок, Уралсиб
Ритейл, финтех, промышленностьфокусные отрасли
Более 350 проектов с 2009 годадля лидеров рынка из 25 стран
Крупнейшие разработчики Россиипо версии CNews
Компания-Национальный чемпионпо версии Ассоциации быстрорастущих технологических компаний

Профиль

Дата регистрации
30 мая 2016
Уставной капитал
1 975 444 ₽
Юридический адрес
г. Москва, вн.тер. г. Муниципальный округ Таганский, ул. Воронцовская, д. 49/28, стр. 1
ОГРН
1166196079060
ИНН
6154144170
КПП
770901001
Среднесписочная численность
287 сотрудников

Контакты

Адрес
121205, Россия, г. Москва, ул. Нобеля, д. 7
Телефон

Социальные сети

ГлавноеЭкспертыДобавить
новость
КейсыМероприятия