Вы собрали стек. Кто отвечает за запуск?

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

Вы гордитесь тем, что создала команда, и устали объяснять, почему никто до сих пор не может этим пользоваться. Теперь финансовый директор хочет знать, почему проект, одобренный 12–18 месяцев назад, все еще находится на стадии тестирования. Вы можете указать на выполненную работу при каждом обзоре. Чего команда не создала, так это владельца.

Решение о разработке было верным

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

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

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

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

Управление и соответствие требованиям

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

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

Операционное владение

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

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

Каждая из этих команд может добавить условие в список требований. Это не означает, что какой-то конкретный стейкхолдер был назначен для его закрытия. Разработчики сделали ровно то, для чего их наняли. Чего собранный стек никогда не предусматривал, так это кого-то с полномочиями объединить эти одобрения и выпустить продукт.

Интеграционный долг

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

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

Другие команды сталкиваются с теми же производственными препятствиями

Повторяющиеся задержки позволяют легко заподозрить, что ваша команда работает медленнее всех остальных. Факты говорят об обратном. В опросе Unmet AI Needs Survey 2026 94% респондентов сообщили об операционных сбоях после развертывания. Не во время пилота.

Пробелы, с которыми вы сталкиваетесь — управление, владение, интеграция — являются структурными. Они проявляются независимо от того, как был построен стек.

Тот же опрос показал, что 72% превысили свои ожидаемые операционные бюджеты. Бюджет прототипа, который обосновал решение о разработке, никогда не был надежным ориентиром того, сколько будет стоить эксплуатация. Это не делает решение неверным. Это просто означает, что реальная стоимость в любом случае проявилась бы позже.

Каждый месяц тестирования стоит денег

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

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

Назначьте владельца до запуска

Разработка сработала. Агент работает. Не хватает человека, который отвечает за то, чтобы запустить его и поддерживать в рабочем состоянии. Назначьте этого человека прежде всего остального.

Если ваши пилоты работают, но эксплуатация еще не началась, прочитайте Agentic AI deployment for enterprises от DataRobot — практический взгляд на то, чего не хватает большинству собранных стеков.