Короткий ответ: чтобы вывести ИИ-агентов в продакшен, относитесь к агенту в первую очередь как к программной системе, а уже потом как к ИИ-продукту. Это значит поэтапный раскат — сначала песочница, потом теневой режим, потом канареечный, потом полный трафик — с набором эвалов, который работает в CI и пропускает каждое изменение, наблюдаемостью на уровне трасс для каждого запуска, guardrails, которые проверяют политику до того, как действие выполнится, и бюджетом на стоимость одной задачи, который вы действительно измеряете. Большинство пилотов проваливаются именно здесь — не потому что модель слабая, а потому что всей этой обвязки просто нет. Доведение агента до продакшена — это инженерная и организационная задача, и выигрывают те команды, кто строит обвязку до того, как масштабирует трафик.

Жёсткая правда 2026 года в том, что собрать демо — больше не узкое место. Узкое место — всё, что лежит между демо и системой, которой можно доверить работать без присмотра, тысячи раз в день, на реальных клиентских данных и с реальными побочными эффектами. Ниже — плейбук, по которому мы преодолеваем этот разрыв: что на самом деле требует «продакшен», какая последовательность раската дешевле всего ловит сбои, как сходятся эвалы, наблюдаемость и guardrails, какие статьи расходов появляются только на масштабе и какие организационные пробелы хоронят большинство проектов.

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

Разрыв широк и хорошо задокументирован. По одной из оценок, около 88% корпоративных проектов с агентным ИИ застряли в «чистилище пилотов» — собраны, показаны, одобрены, профинансированы, а затем тихо так и не развёрнуты, — то есть до продакшена доходит лишь около 12%. Оценка McKinsey для организаций, у которых агенты работают на реальном масштабе, — около 11%. Gartner прогнозирует, что к концу 2027 года более 40% проектов агентного ИИ будут свёрнуты из-за растущих затрат, неясной бизнес-ценности и недостаточного контроля рисков.

Вчитайтесь в эти цифры — и проступит закономерность: блокеры почти никогда не модель. Данные опросов называют главными причинами остановки пилотов пробелы в эвалуации (отмечают 64% руководителей), трение в governance (57%) и надёжность модели (51%). Зрелая модель governance для автономных агентов есть лишь у примерно 21% организаций. Разрыв между пилотом, который красиво демонстрируется, и системой, которая держится в продакшене, — это прежде всего разрыв в инфраструктуре и организации, а не в инженерии промптов.

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

Что на самом деле значит «готов к продакшену» для агента

«Готов к продакшену» — это конкретная планка, а не ощущение. Агент готов к продакшену, когда он удовлетворяет условиям, которых у демо никогда не бывает:

  1. Он ведёт себя стабильно на входах, которых никогда не видел. Демо идёт по дружелюбному пути. Продакшен идёт по длинному хвосту — кривые входы, неоднозначные запросы, краевые случаи, враждебные пользователи. Готовность — это когда вы измерили поведение на всём хвосте, а не только на счастливом пути.
  2. Он сбоит безопасно. Когда агент не уверен, наткнулся на ошибку или его просят сделать что-то вне зоны компетенции, он деградирует мягко — эскалирует, отказывается или передаёт дальше — вместо того чтобы угадывать и действовать.
  3. Он наблюдаем. Каждый запуск оставляет трассу, которую можно изучить: входы, шаги рассуждения, каждый вызов инструмента и его результат, финальный вывод и стоимость. Когда что-то ломается в 3 часа ночи, вы видите, что произошло, не перезапуская это.
  4. Его изменения проходят через гейт. Нельзя улучшить промпт, заменить модель или добавить инструмент и выкатить это по наитию. Изменение проходит набор эвалов до того, как доходит до пользователей.
  5. Его стоимость ограничена и известна. Вы знаете стоимость задачи, у вас есть бюджет, а зацикливания или штормы ретраев не могут тихо умножить счёт.
  6. Он соблюдает governance. Контроль доступа, аудит-логи, обработка данных и гейты согласований существуют и применяются, а не остаются на словах.

Если вы не можете ответить «да» на все шесть пунктов — у вас прототип, а не продакшен-система. Работа по выводу в продакшен — это и есть работа по превращению этих шести условий из пожеланий в механизмы.

Раскат по этапам: песочница, теневой, канареечный, полный

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


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

Соберите набор эвалов — и гоняйте его в CI

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

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

Шаг, который превращает эвалы из приятного документа в продакшен-контроль, — прогон в CI. Каждое изменение промпта, замена модели, добавление инструмента или обновление зависимости запускает набор, и регрессия ниже порога блокирует мердж. Это тот же сдвиг, который тесты принесли в обычный софт: изменения безопасно вносить, потому что набор ловит то, что вы сломали. Для агентов, где поведение эмерджентно и однострочная правка промпта может ухудшить десять несвязанных кейсов, это не опция. Подробно разбираем это в статье как оценивать ИИ-агента.

Внедрите наблюдаемость до того, как она понадобится

Вы не поймёте продакшен-поведение агента, читая его код. Агенты недетерминированы, а их сбои часто эмерджентны: инструмент вернул что-то слегка не то, модель чрезмерно ему доверилась, и тремя шагами позже вывод неверен так, что ни один отдельный компонент этого не объясняет. Единственный способ отладить такое — увидеть весь запуск.

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

Внедряйте это до запуска, а не после первого инцидента. Инструментарий быстро повзрослел в 2025–2026 годах — open-source и коммерческие платформы наблюдаемости теперь захватывают трассы агентов с автоматической эвалуацией, мониторингом в реальном времени и разбивкой стоимости по рабочим процессам из коробки, так что летать вслепую почти нет оправданий. Наблюдаемость к тому же замыкает петлю обратно к эвалам: реальные продакшен-трассы — богатейший источник новых эвал-кейсов, потому что показывают входы, которые вам и в голову не пришло протестировать. См. наблюдаемость ИИ-агентов для полной картины.

Поставьте guardrails между агентом и миром

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

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

Это не опциональная бумажка про риски. Gartner прогнозирует, что к концу 2026 года число судебных исков, связанных с ИИ, превысит 2000, отчасти из-за недостаточных guardrails. Агент, который может действовать, — это агент, который может вызвать инцидент, и слой guardrails — это то, что ограничивает радиус поражения. Механику разбираем в guardrails для ИИ-агентов, а смежную поверхность атаки — в безопасность ИИ-агентов и prompt injection.

Контролируйте стоимость, пока она не контролирует вас

Стоимость — это место, где экономика агентов тихо ломается. Демо запускается несколько раз, и счёт незаметен. Продакшен-агент работает непрерывно, и мелкие неэффективности на запуск складываются в числа, топящие кейс по ROI, — те самые «растущие затраты», которые Gartner называет драйвером отмен.

Две истины о стоимости стоит усвоить. Первая: начальная разработка — это доля от затрат за весь срок жизни; по распространённым оценкам лишь 25–35% от трёхлетней стоимости, при этом ежегодное сопровождение составляет 15–30% от первоначальной сборки. Бюджетировать только сборку — это способ остаться без денег на восьмой месяц. Вторая: стоимость задачи должна укладываться в ценность рабочего процесса. Команды, гоняющие высокообъёмные внутренние процессы вроде сортировки тикетов или гигиены CRM, целятся в стоимость модели ниже $0,05 за выполненную задачу, при этом допускают $0,25–$2 для клиентских, близких к выручке задач вроде черновиков предложений или технического траблшутинга. Если ваша стоимость задачи превышает ценность, которую задача производит, никакая точность не спасёт развёртывание.

Контроли конкретны: измеряйте стоимость задачи с первого дня (ваш слой наблюдаемости должен её отдавать), задайте бюджет и оповещение при превышении, ограничьте число итераций цикла, чтобы запутавшийся агент не крутился бесконечно, используйте durable execution, чтобы краш возобновлялся, а не переплачивал за уже сделанную работу, и маршрутизируйте лёгкие шаги на более дешёвые модели. Вопрос стоимости неотделим от архитектуры — полную картину выкладываем в сколько стоит построить ИИ-агента.

Не забывайте про состояние, восстановление и организацию

Три вещи топят развёртывания, которые на бумаге выглядят готовыми.

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

Восстановление. Продакшен полон будничных сбоев: деплой перезапускает процесс, вызов LLM выходит за таймаут, инструмент возвращает 503, на шаге 60 срабатывает лимит запросов. Долго работающий агент должен пережить это, не переделывая завершённую работу и не дублируя действия. Это то, что даёт durable execution — checkpoint-and-replay, чтобы агент, умерший на шаге 47, возобновился на шаге 48, с идемпотентными побочными эффектами, чтобы ретрай не списал с клиента дважды.

Организация. Самые жёсткие блокеры часто человеческие. Кто владеет агентом в продакшене? Кто на дежурстве, когда он чудит? Каков путь согласования для высокорисковых действий? Как обрабатывать тикеты поддержки, которые он не может решить? Зрелость governance — редкость (она есть лишь у примерно одной из пяти организаций), и её отсутствие — причина, по которой технически здоровые агенты так и не получают зелёный свет. Развёртывание не закончено, когда выкачен код; оно закончено, когда у работающей системы и процесса вокруг неё есть владелец.

Как к этому подходит Moai Team

Мы проектируем агентов под продакшен с первого разговора, а не после того, как пилот встал. Это значит, что мы рано определяем, что «готов к продакшену» значит для вашего конкретного сценария — те шесть условий выше, переведённые в конкретику, — и строим обвязку рядом с агентом, а не прикручиваем её потом.

На практике это выглядит так. Мы определяем набор эвалов до того, как настраиваем агента, чтобы оптимизировать против измеримой цели и пропускать каждое изменение через гейт в CI. Мы внедряем наблюдаемость на уровне трасс с первой сборки, чтобы видеть поведение на реальных входах в момент старта теневого режима. Мы проектируем guardrails и доступ по принципу наименьших привилегий вокруг действий, которые агент может совершать, с подтверждением человека на действиях с наибольшими последствиями. Мы измеряем стоимость задачи с первого дня и архитектурим под неё — ограничения цикла, маршрутизация моделей, durable execution там, где запуски длинные или с побочными эффектами. И мы идём по поэтапному раскату осознанно — песочница, теневой, канареечный, полный — с явными триггерами отката на каждом гейте. Агент — это половина результата; система, которая безопасно запускает его на масштабе, — вторая половина, и именно она решает, окажетесь ли вы в тех 12%, что доходят до продакшена, или в тех 88%, что нет.

Часто задаваемые вопросы

Как вывести ИИ-агента в продакшен?

Выводите через поэтапный раскат, а не разом: песочница для внутренних тестов на краевых случаях, теневой режим для работы на реальном трафике со скрытыми выводами и отключёнными побочными эффектами, канареечный для обслуживания небольшого процента реального трафика с взведёнными триггерами отката, затем полный трафик с сохранённым мониторингом. Под раскатом нужны четыре вещи: набор эвалов в CI для прохождения изменений через гейт, наблюдаемость на уровне трасс для каждого запуска, guardrails, применяющие политику до выполнения действий, и измеряемый бюджет стоимости задачи. Последовательность раската дёшево ловит сбои; обвязка делает агента достаточно надёжным, чтобы расширять трафик.

Почему так много ИИ-агентов не доходят до продакшена?

Потому что блокеры организационные и инфраструктурные, а не качество модели. Данные опросов называют главными причинами остановки пилотов пробелы в эвалуации (отмечают 64% руководителей), трение в governance (57%) и надёжность (51%), и лишь около 21% организаций имеют зрелую модель governance для автономных агентов. Gartner ожидает, что к концу 2027 года более 40% проектов агентного ИИ будут свёрнуты из-за затрат, неясной ценности и слабого контроля рисков. Команды, ставящие задачу как «собрать агента», выпускают демо и встают; команды, ставящие «собрать агента и систему, которая безопасно его запускает», доходят до продакшена.

В чём разница между теневым и канареечным развёртыванием?

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

Что нужно, чтобы держать ИИ-агента надёжным в продакшене?

Надёжность даёт четыре постоянные дисциплины: эвалы в CI, чтобы регрессии ловились до мерджа, наблюдаемость, чтобы каждый запуск можно было изучить, а продакшен-трассы питали новые тест-кейсы, guardrails и доступ по наименьшим привилегиям, чтобы агент не мог совершать вредные действия, и durable execution плюс управление состоянием, чтобы краши возобновлялись, а не перезапускались и не дублировали побочные эффекты. Добавьте мониторинг стоимости с ограничением цикла, чтобы убежавшие запуски не множили счёт, и ясное владение, чтобы кто-то отвечал, когда агент чудит. Надёжность — это не веха запуска, а постоянная практика вокруг работающей системы.

Moai Team строит ИИ-агентов, спроектированных под продакшен с этапа скоупинга — эвалы в CI, наблюдаемость на уровне трасс, guardrails, контроль стоимости и поэтапный раскат, — чтобы они держались на десятитысячном реальном запуске, а не только в демо. Запланировать звонок.