ИИ-агенты в своей инфраструктуре: почему контур управления стоит размещать у себя

Создать агента сегодня легко. Управлять агентом с доступом к рабочим системам сложнее.

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

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

С ростом ответственности агента граница размещения становится границей контроля

Демонстрационный агент читает документ и пишет краткое содержание. Агент в рабочей среде создаёт заявки, запрашивает данные клиентов, запускает развёртывания, перемещает деньги и обращается к внутренним API. При таком доступе нужны три вещи:

• Границы доступа: какие инструменты, данные и среды доступны агенту.
• Согласования: какие действия требуют одобрения человека до выполнения.
• Аудит: достоверная история действий агента и причин их выполнения.

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

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

Что даёт самостоятельное размещение

Избежать зависимости от поставщика полезно, но есть и конкретные эксплуатационные причины разместить контур управления агентами у себя.

Доступ внутри собственной границы доверия

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

Аудит, который можно подтвердить

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

Применение политик на своей границе

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

Возможность изучить устройство системы

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

Когда самостоятельное размещение оправдывает затраты

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

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

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

Что должен предоставлять контур управления агентами

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

• Устойчивое выполнение. Длительные задачи требуют оркестрации, повторных попыток и состояния, которое переживает перезапуск процесса. В AgentArea для этого используется Temporal.
• Контроль завершения. Нужно знать, что задача действительно выполнена, и видеть случаи, когда она не завершилась.
• История событий и потоковая передача. Значимые действия должны сохраняться и быть доступны для наблюдения в реальном времени. Это основа аудита и диагностики.
• Управляемые границы инструментов. Через инструменты и MCP-серверы агенты взаимодействуют с внешними системами, поэтому доступ к ним должен быть явным и ограниченным.
• Идентификация, рабочие пространства и согласования. Агентам нужны собственная идентификация, границы рабочего пространства и точки остановки для одобрения человеком.

Если платформа не поддерживает эти возможности, размещение на собственном сервере решает вопрос расположения данных, но оставляет эксплуатационные риски.

Open-core: самостоятельное размещение основы и корпоративное управление

AgentArea строится вокруг этой модели. Открытая редакция задумана как полезная самостоятельная платформа: локальный запуск через Docker Compose, Helm chart для собственного Kubernetes, выполнение агентов и задач, взаимодействие с инструментами и MCP, настройка провайдеров, устойчивое выполнение и сохранение событий. Это позволяет запускать агентов в своей среде без поставщика платформы на пути выполнения.

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

Open-core подходит для такой инфраструктуры, потому что её внедрение зависит от доверия, возможности изучить устройство и локального развёртывания. Командам, отвечающим за рабочие системы, нужно понимать, как устроен их контур управления.

Частые вопросы

Нужно ли размещать модели у себя, чтобы самостоятельно размещать агентов?

Нет. Место размещения контура управления, включая выполнение, доступ к инструментам, политики и аудит, не определяет место размещения модели. Можно развернуть платформу агентов у себя и обращаться к облачному провайдеру моделей. Локальный запуск моделей с открытыми весами остаётся отдельным вариантом.

Разве облачный конструктор агентов не проще?

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

С чего начать?

Запустите открытую редакцию локально через Docker Compose, подключите провайдера и несколько инструментов. Выполните одну реальную задачу от начала до конца, включая сценарий сбоя, чтобы изучить выполнение, события и завершение до подключения к чувствительным системам.

Чем это отличается от конструктора агентов?

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

Управление как часть инфраструктуры

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

AgentArea создаётся для перехода от экспериментов к рабочему использованию агентов. Запустите агентов в своей инфраструктуре →