ИИ-агенты в проде: почему пилоты работают, а промышленная эксплуатация ломается
Переход ИИ-агентов от демо-стенда к реальной корпоративной среде часто сопровождается сбоями, которые не проявляются на этапе пилота. Проблема кроется не в модели, а в отсутствии инфраструктуры для непрерывного доступа к данным и контроля безопасности.
На демо-стенде ИИ-агент демонстрирует впечатляющие результаты: все необходимые данные уже загружены в контекст, а корпоративные системы остаются за пределами тестовой среды. Однако в реальной эксплуатации агенту приходится самостоятельно извлекать актуальную информацию из CRM, legacy-систем, внутренних документов и других сервисов. Именно в этот момент выясняется, что успешный пилот подтвердил лишь возможности языковой модели, но ничего не сказал о системе, которая должна снабжать агента данными, ограничивать его полномочия и контролировать действия. Основное противоречие внедрения заключается в том, что лишенный доступа ИИ-агент бесполезен для бизнеса, но вместе с наделением полномочиями он превращается в потенциально опасного внутреннего пользователя, чья ошибка может привести к реальным последствиям в корпоративных системах. Текстовые ограничения в системном промпте, например «не запрашивать чужие данные», не способны заменить полноценную политику безопасности, поэтому проверку прав необходимо выносить за рамки LLM, разделять данные по изолированным контурам и контролировать работу агента с той же строгостью, что и критически важные продакшен-сервисы.
Ключевая проблема, как отмечает руководитель решения Digital Q.Integration компании «Диасофт» Виктор Овчинников, возникает при тиражировании пилота в постоянно работающую систему. На демо-стенде данные подготавливаются заранее, но в проде их нужно передавать ИИ сразу после появления. Корпоративные ландшафты, особенно в банковской сфере, проектировались иначе: аналитические хранилища обновляются раз в сутки или даже раз в неделю. Информация меняется сегодня, но модель видит её завтра, поэтому оперативный ответ строится на устаревшей картине. Если сведения о клиенте изменились в одной системе, они должны мгновенно попасть в каталог, с которым работает ИИ, иначе модель остаётся быстрой только с точки зрения вычислений, но для бизнеса она отвечает вчерашними данными. ИИ-архитектор Андрей Носов добавляет, что промышленная эксплуатация требует не просто однократного получения данных, а целой фабрики, которая непрерывно снабжает ИИ информацией, обрабатывает её и поддерживает качество. На большинстве предприятий такой фабрики нет, а работа с данными не выстроена как ежедневный процесс, поэтому пилот подтверждает возможности модели, но у компании ещё нет инфраструктуры, способной поддерживать эти возможности в проде.
Технические сложности усугубляются при интеграции с legacy-системами, которые используются в крупных банках и других консервативных отраслях. Данные об одном клиенте могут быть распределены по сотням систем, которые никак не подготовлены для ИИ и находятся в разных контурах. Многие старые автоматизированные банковские системы работают по pull-модели: они сами ничего не отправляют и отвечают только на прямой запрос. Поэтому до поиска и анализа нужен интеграционный слой, который обратится к источникам, соберёт ответы, приведёт разные форматы к общей структуре и только после этого передаст данные ИИ. Как подчёркивает Овчинников, задача решаемая, но решается она не внутри модели. Тимлид и пентестер Сергей Зыбнев уточняет, что подключать агента к каждой legacy-системе нет смысла: если источник стабилен, интеграцию можно сделать обычными скриптами, что дёшево и надёжно. Агент становится полезен там, где система активно меняется, а данные приходится нормализовать на ходу. Однако вместе с этим появляется риск: в одном из проверенных проектов любой текст, попадавший в контекст LLM, считался доверенным, и модель не различала системную инструкцию, документ из базы знаний и пользовательский ввод. Для безопасности достаточно прав read-only, а до обращения к источнику и перед выдачей результата нужны детерминированные проверки полномочий — RBAC или ABAC, причём сама LLM не должна принимать решение о доступе, иначе клиент может запросить чужие данные, и это приведёт к утечке персональных данных.
Контекст дискуссии, развернувшейся на канале Ai4Dev, показывает, что проблема носит системный характер. В ней приняли участие ведущие эксперты, включая руководителя решения Digital Q.Integration компании «Диасофт» Виктора Овчинникова, ИИ-архитектора Андрея Носова, тимлида и пентестера Сергея Зыбнева, а также директора по информационной безопасности «Вебмониторэкс» Льва Палея. Они сошлись во мнении, что разрыв между пилотом и продуктом обусловлен отсутствием инфраструктурных слоёв, которые должны находиться между моделью и корпоративной системой. На российском рынке эта проблема особенно актуальна, поскольку многие компании стремятся внедрить ИИ-агентов для автоматизации процессов, но сталкиваются с устаревшей ИТ-инфраструктурой и нехваткой стандартизированных подходов к интеграции. В отличие от западных аналогов, где экосистемы более унифицированы, в российских реалиях приходится адаптировать решения под каждую legacy-систему, что увеличивает стоимость и сроки внедрения.
Сравнение с альтернативными подходами показывает, что некоторые компании пытаются решить проблему путём полной замены legacy-систем на современные платформы, но это требует значительных инвестиций и времени. Другие выбирают гибридный путь, используя ИИ-агентов только для задач, где данные уже структурированы и доступны в реальном времени, например, для обработки заявок в колл-центрах. Однако, как отмечают эксперты, такой подход ограничивает потенциал технологии. Более перспективным видится создание специализированных интеграционных слоёв, которые берут на себя функции сбора, нормализации и контроля данных, а LLM остаётся лишь инструментом для анализа и генерации ответов. Это позволяет сохранить существующую инфраструктуру и минимизировать риски безопасности.
Перспективы дальнейшего развития ИИ-агентов в корпоративной среде зависят от того, насколько быстро компании смогут построить недостающие инфраструктурные компоненты. Открытыми остаются вопросы стандартизации протоколов интеграции, разработки эффективных механизмов контроля доступа и создания систем мониторинга, которые позволят своевременно выявлять аномалии в работе агентов. Без решения этих задач пилотные проекты рискуют остаться лишь демонстрацией возможностей, не переходя в стадию промышленной эксплуатации. Как показывает практика, успешное внедрение ИИ-агентов требует не столько совершенствования моделей, сколько перестройки корпоративной архитектуры данных и безопасности, что является вызовом для большинства российских компаний.