Как приручить зоопарк AI‑агентов: референс‑архитектура Microsoft на Azure

Что нового

Microsoft описала референс‑архитектуру для управления «расползанием» AI‑агентов в крупных компаниях. Это не один новый сервис, а связка из трёх уровней управления, которые работают поверх уже знакомых продуктов Azure и Microsoft 365:

1. Azure AI Gateway в Azure API Management

   • Новый режим работы API Management как AI‑шлюза.
   • Поддерживает:
     • деплойменты моделей Microsoft Foundry;
     • Azure AI Model Inference API;
     • OpenAI‑совместимые сторонние модели;
     • самохостинг моделей;
     • MCP‑серверы и A2A‑агентные API (сейчас в режиме preview).
   • Встроенные политики для AI:
     • llm-token-limit (GA) — жёсткие лимиты по токенам в минуту или по месячной квоте для каждого потребителя до обращения к бэкенду;
     • llm-content-safety (GA) — автоматическая модерация промптов через Azure AI Content Safety, небезопасные запросы не доходят до модели;
     • llm-emit-token-metric — логирование использования токенов, промптов и ответов в Azure Monitor и Application Insights.
   • Multi‑region‑режим (Premium‑тариф API Management): шлюзы поднимаются в нескольких регионах Azure, при падении одного трафик уходит в ближайший доступный.

2. Azure AI Foundry Control Plane (Public Preview)

   • Единый контрольный контур для агентов, моделей и тулов в разных проектах и подписках Azure.
   • Что даёт:
     • инвентаризация всех агентов, моделей и инструментов в одном интерфейсе;
     • непрерывную оценку поведения агентов на боевом трафике:
       • соответствие задаче (task adherence),
       • «заземлённость» ответов (groundedness),
       • точность вызова инструментов,
       • утечки чувствительных данных и другие риски;
     • централизованные guardrails на вход, выход и вызовы инструментов с возможностью массового применения к целому «флоту» агентов;
     • интеграцию с безопасностью:
       • Microsoft Entra (Entra Agent ID для агентов),
       • Microsoft Defender (сигналы угроз),
       • Microsoft Purview (видимость по данным и соответствию требованиям).
   • Для продвинутых сценариев Foundry Control Plane требует настроенный AI Gateway — уровни управления завязаны друг на друга.

3. Microsoft Agent 365 (Frontier Preview, GA — 1 мая 2026)

   • Тенант‑уровневый контрольный слой для AI‑агентов в экосистеме Microsoft 365.
   • Ключевые функции:
     • реестр агентов на уровне всего арендатора Microsoft 365, включая «теневых» несанкционированных агентов; таких агентов можно отправить в карантин;
     • identity‑first‑подход: каждому агенту выдаётся собственный Entra Agent ID, к нему применяются Conditional Access‑политики так же, как к пользователям;
     • human‑in‑the‑loop‑надзор: администраторы видят агентов в привычных админ‑центрах Microsoft 365, а не только в порталах Azure;
     • безопасность и соответствие: Defender и Purview распространяют свои политики и детекцию угроз на действия агентов.

Архитектура опирается на стандартный подход Azure landing zones: контрольный план (policy, RBAC, identity) отделён от плоскости исполнения (runtime). Управление — глобальное и регион‑агностичное, вычисления — по регионам.

Как это работает

Базовый принцип: разделить управление и выполнение

Microsoft предлагает рассматривать AI‑агентов как полноценные рабочие нагрузки с теми же требованиями, что и к обычным приложениям: кто владеет, какие данные доступны, какие лимиты, как мониторить. Для этого архитектура делит систему на две плоскости:

• Runtime‑плоскость — где реально крутятся агенты, идут запросы к моделям, читаются и пишутся данные. Обычно сразу в нескольких регионах Azure.
• Control‑плоскость — где живут идентичности, политики, безопасность, оценка качества и наблюдаемость. Она не привязана к региону.

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

Layer 1: Azure AI Gateway — жёсткий фильтр на входе

Azure AI Gateway — это режим Azure API Management, который вставляется прямо в траекторию каждого AI‑запроса.

Что проходит через шлюз:

• вызовы к деплойментам моделей в Microsoft Foundry;
• запросы к Azure AI Model Inference API;
• OpenAI‑совместимые сторонние модели (через совместимый API);
• самохостинговые модели;
• MCP‑серверы и A2A‑агентные API (preview).

Что он контролирует:

1. Токены и квоты
   Политика llm-token-limit в режиме GA. Можно задать:

   • лимит токенов в минуту;
   • потолок месячной квоты по токенам для конкретного потребителя (приложения, агента, ключа).

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

2. Контент‑модерация на входе
   Политика llm-content-safety (GA) подключает Azure AI Content Safety. Промпты проходят проверку, и если запрос нарушает политики безопасности, он не попадает к модели.

3. Маршрутизация и отказоустойчивость
   На Premium‑тарифе Azure API Management можно развернуть шлюз в нескольких регионах. Если один регион недоступен, трафик автоматически уходит в следующий ближайший.

4. Наблюдаемость
   Через llm-emit-token-metric и другие политики шлюз пишет в Azure Monitor и Application Insights:

   • количество токенов;
   • сами промпты и ответы (с учётом настроек приватности);
   • технические метрики.

AI Gateway не пытается понимать смысл запроса или бизнес‑контекст. Его задача — управлять трафиком и ресурсами, а не логикой агента.

Layer 2: Azure AI Foundry Control Plane — управление поведением агентов

Foundry Control Plane работает уже не с отдельными запросами, а с целым «флотом» агентов и моделей.

Ключевые функции:

• Инвентаризация: все агенты, модели и инструменты, развёрнутые через Foundry, попадают в единый каталог. Их можно искать и фильтровать по проектам и подпискам.

• Непрерывная оценка на боевом трафике. Foundry запускает оценки, которые измеряют:

  • насколько агент выполняет поставленную задачу;
  • насколько ответы опираются на доступные источники (groundedness);
  • насколько корректно агент вызывает инструменты (tool‑call accuracy);
  • есть ли признаки утечки чувствительных данных;
  • другие риск‑показатели, специфичные для агентов.

• Централизованные guardrails: политики можно навесить не только на текст промпта, но и на:

  • выход модели;
  • параметры и результаты вызовов инструментов;
  • цепочки действий агента.

  При необходимости можно провести массовую ремедиацию — изменить политику сразу для большого числа агентов.

• Интеграция с безопасностью и данными:

  • Microsoft Entra — выдаёт Entra Agent ID, агенты становятся полноценными субъектами в системе идентичности;
  • Microsoft Defender — подхватывает сигналы угроз, связанные с действиями агентов;
  • Microsoft Purview — даёт обзор по тому, как агенты работают с данными, и помогает соблюдать требования регуляторов.

Foundry Control Plane ожидает, что трафик агентов проходит через AI Gateway, чтобы иметь полную картину запросов и ограничений.

Layer 3: Microsoft Agent 365 — контроль на уровне арендатора Microsoft 365

Когда агенты начинают действовать от имени пользователей, работать с документами и почтой и встраиваться в процессы Microsoft 365, одного Azure уже мало. Здесь включается Microsoft Agent 365.

Что делает Agent 365:

• ведёт единый реестр всех агентов в арендатора Microsoft 365, включая несанкционированные;
• позволяет карантинировать нежелательных агентов;
• выдаёт каждому агенту Entra Agent ID и применяет к нему Conditional Access как к пользователю;
• встраивает агентов в админ‑процессы Microsoft 365 — администраторы видят их в привычных консолях;
• расширяет политику Defender и Purview на действия агентов: угрозы, утечки, использование конфиденциальных данных.

Agent 365 не подменяет собой Foundry Control Plane, а дополняет его: Foundry управляет агентами как рабочими нагрузками Azure, Agent 365 — как «цифровыми субъектами» внутри Microsoft 365.

Как всё связывается в единый конвейер

1. Внешнее одобрение кейса
   Бизнес‑или риск‑комитет одобряет новый сценарий для агента в своей системе управления (GRC‑система, внутренний портал и т.п.).

2. Триггер Azure DevOps‑пайплайна через REST API
   После одобрения автоматически запускается пайплайн, который:

   • создаёт нужные подписки и resource group‑ы;
   • разворачивает проекты в Azure AI Foundry;
   • настраивает Azure API Management с политиками AI Gateway;
   • включает мониторинг и логирование.

3. Глобальная политика, локальное исполнение

   • Azure landing zones задают политику и RBAC глобально, без привязки к региону;
   • AI Gateway реализует лимиты и безопасность локально в каждом регионе;
   • runtime‑сервисы масштабируются по регионам по мере роста нагрузки.

   Подключение нового региона добавляет вычислительные мощности, но не требует новой модели управления.

4. Единая операционная картина
   Сигналы поднимаются по слоям:

   • AI Gateway отдаёт метрики трафика и использования токенов;
   • Foundry Control Plane добавляет результаты оценок, срабатывания guardrails и алерты безопасности;
   • Agent 365 агрегирует всё это на уровне арендатора: идентичности, комплаенс, угрозы.

   Операционные команды работают из приоритезированного единого обзора, а не бегают между десятком разрозненных дашбордов.

Что это значит для вас

Кому это реально нужно

• Крупным компаниям и холдингам с десятками команд, которые уже делают своих агентов: чат‑боты, ассистенты для сотрудников, агенты с доступом к внутренним API.
• Интеграторам и in‑house AI‑платформенным командам, которые отвечают за общую платформу на Azure для множества продуктовых команд.
• Организациям с жёстким комплаенсом (финансы, госсектор, здравоохранение), где каждый агент должен быть учтён, ограничен и наблюдаем.

Если у вас один‑два бота на тестовом стенде, эта архитектура будет избыточной. Она рассчитана на момент, когда агентов уже десятки и вы больше боитесь не «что умеет GPT‑модель», а «куда она полезет и сколько это будет стоить».

Практические плюсы

• Контроль затрат по токенам: llm-token-limit позволяет задать потолок и не бояться, что экспериментальный агент за ночь выжжет бюджет на месяц.
• Единый обзор агентов: Foundry Control Plane и Agent 365 убирают «теневых» агентов, которые кто‑то тихо поднял в отдельной подписке или подключил к Microsoft 365.
• Безопасность с первого дня: политики на AI Gateway и guardrails в Foundry применяются ещё до первого пользовательского запроса. Не нужно «догонять» безопасность постфактум.
• Масштабирование без перенастройки governance: добавляете новые регионы Azure — получаете больше мощности, но не городите новый зоопарк политик.

Ограничения и где лучше не использовать

• Архитектура завязана на Azure и Microsoft 365. Если вы строите всё на других облаках или on‑prem без Azure, этот подход напрямую не применим.
• Для малых команд и стартапов без требований по комплаенсу и аудиту подобная многоуровневая конструкция может быть излишней. Проще использовать один API Gateway и мониторинг.
• Если вы делаете разовые эксперименты или PoC с одним агентом, настройка трёх уровней контроля отнимет больше времени, чем даст пользы.

Доступность из России

Сервисы Azure и Microsoft 365, включая Azure API Management, Azure AI Foundry и Microsoft Agent 365, относятся к экосистеме Microsoft. Для российских юрлиц и пользователей действуют ограничения и санкционные риски. Для работы часто требуется регистрация в зарубежном тенанте и доступ к зарубежным регионам Azure, что на практике обычно означает использование VPN и нероссийской платёжной инфраструктуры. Перед внедрением придётся отдельно оценить юридические и технические риски.

Место на рынке

Прямых числовых сравнений с конкурентами Microsoft не приводит. Здесь речь не о скорости модели или цене токена, а об архитектуре управления.

Если смотреть по классам решений:

• API‑шлюзы и лимиты токенов.
  Многие компании используют собственные API‑шлюзы или продукты вроде Kong / Apigee. Azure AI Gateway делает похожую работу, но с готовыми LLM‑политиками (llm-token-limit, llm-content-safety, llm-emit-token-metric) и глубокой интеграцией с Azure Monitor. Для тех, кто уже в Azure, это меньше интеграционной работы.

• Платформы управления агентами.
  На рынке есть сторонние платформы для оркестрации и мониторинга агентов, но Microsoft делает ставку на то, что Foundry Control Plane «знает» Azure по‑родному: подписки, RBAC, Entra, Defender, Purview. Это уменьшает разрыв между DevOps, SecOps и AI‑командой в экосистеме Microsoft.

• Управление на уровне арендатора.
  Идея Agent 365 — подчинить агентов тем же правилам, что и пользователей и приложения в Microsoft 365. В экосистемах конкурентов похожие инициативы только формируются, но прямого функционального сравнения Microsoft не даёт.

По сути, Microsoft предлагает не «ещё один AI‑сервис», а схему, как собрать из уже существующих кирпичей Azure и Microsoft 365 управляемую среду для большого числа агентов. Это особенно логично для компаний, которые уже строят инфраструктуру по принципам Azure landing zones и не хотят плодить параллельные системы управления.

Итог

Microsoft формализовала подход к борьбе с расползанием AI‑агентов: разделить контроль и исполнение, добавить три слоя управления (AI Gateway, Foundry Control Plane, Agent 365) и связать их с Azure DevOps и существующими контурами безопасности. Это не снимает с вас задачи назначать владельцев агентов, выстраивать бизнес‑процессы одобрения и регулярно проверять, приносят ли агенты пользу. Но даёт технический фундамент, на котором можно масштабировать агентные решения без превращения инфраструктуры в неконтролируемый зоопарк.

---

Читайте также

• Microsoft Foundry IQ: как превратить экспертные знания в топливо для AI-агентов
• Anthropic наращивает мощности: сделка со SpaceX и повышенные лимиты для Claude
• Addy Osmani научил AI-агентов работать как сеньор-инженеры