Некоторые наши пользователи сами хотят собирать AI-агентов..
... внутри контура организации.
Пока это ещё скорее запрос продвинутых пользователей, чем массовая практика. Но мне кажется, что движение идёт именно в эту сторону.
Как дать пользователю достаточно свободы для создания собственного агента, но при этом не превратить корпоративную AI-платформу в место, где каждый может запускать что угодно и на каких угодно данных?
Один из механизмов, который позволяет это сделать безопаснее, — Sandbox.
При этом Sandbox - это не отдельный контур рядом с Development, Test или Production. Он встроен в каждый контур системы. Пользователь по-прежнему создаёт агента в Agent Builder в DEV-контуре. Когда необходимо выполнить Custom Code, платформа запускает его не внутри backend самого агента, а в отдельном временном изолированном контейнере. Такой контейнер содержит только необходимый runtime, разрешённые библиотеки, конкретную версию кода и входные данные текущего запуска. Ему задаются ограничения по CPU, памяти и времени жизни, а после выполнения контейнер уничтожается. В DEV агент работает с синтетическими или обезличенными тестовыми данными. Затем проходит validation, security checks и стандартный процесс продвижения версии через Test/Pre-prod в Production. А уже в PROD тот же Custom Code выполняется в production Sandbox. Там он действительно может обрабатывать реальные продуктивные данные — но не получает постоянного доступа, например, ко всей CRM. Агент через контролируемые tools получает только разрешённые данные конкретного запроса и передаёт в Sandbox ровно тот набор данных, который нужен для выполнения операции. Получается примерно такая модель: DEV Agent Builder → Sandbox → Validation → Test/Pre-prod → Production Agent → Production Sandbox
Если пользовательская логика небольшая и укладывается в ограничения платформы, она вполне может дойти до production без обязательного переписывания разработчиками. Иначе self-service быстро превращается просто в ещё один способ написать техническое задание IT-команде.
Но если Custom Code начинает требовать постоянного состояния, прямых интеграций, тяжёлых вычислений, повышенных прав или серьёзного SLA, это уже другая история. Такую логику разумнее превратить в полноценный production-сервис, пройти обычный SDLC и подключить его к агенту как approved tool. Поэтому мне кажется, что Sandbox — это не столько технология исполнения кода, сколько один из механизмов, который позволяет провести границу между корпоративным self-service и промышленной разработкой. А вы уже видите внутри корпоративного контура такую тенденцию — пользователи хотят самостоятельно собирать и доводить до production своих AI-агентов? Или разработка агентов пока остаётся централизованной? #AIAgents #EnterpriseAI #AIPlatform #Sandbox #AgenticAI
· 17.08
Модель с временным изолированным контейнером на каждый вызов Custom Code, а не постоянный доступ агента ко всей CRM, это правильный принцип наименьших привилегий, применённый к AI-агентам. У нас в похожей задаче с вебхуками от партнёров была та же дилемма: постоянный сервисный аккаунт с широкими правами или короткоживущий токен под конкретные данные на каждый запрос. Токен дороже по инфраструктуре, зато утечка одного запроса не превращается в утечку всей базы.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён