Как Microsoft строит архитектуру AI‑агентов: Governance Hub, Agent 365 и AI Landing Zones — VogueTech

Что нового

Microsoft собрала разрозненные сервисы для разработки AI‑агентов в цельную архитектуру, которую можно развернуть как готовый шаблон:

Governance Hub — общий центр управления:
- единая точка входа для всех запросов к AI‑моделям через AI Gateway в Azure API Management;
- MCP Gateway с каталогом MCP‑серверов и инструментов (Model Context Protocol);
- Agent 365 как единая плоскость управления агентами в составе Microsoft 365 Admin Center;
- интеграция с Microsoft Entra, Defender, Purview, Azure Policy, Azure Monitor.
Agent 365 даёт каждому агенту:
- отдельную, отслеживаемую идентичность;
- runtime‑защиту через Microsoft Defender (трассировка, детекция аномалий);
- data governance через Microsoft Purview (политики доступа, аудит работы с чувствительными данными).
Microsoft Fabric IQ + Ontologies:
- знания оформляются как управляемые объекты, а не «папка с PDF»;
- онтологии описывают сущности бизнеса (клиенты, заказы, логистика), связи и метрики в машиночитаемом виде;
- агенты опираются не только на сырые данные, но и на бизнес‑контекст.
Три формата рантайма для агентов:
1. No‑code / low‑code в Microsoft Copilot Studio и Microsoft Foundry Agent Service.
2. Хостинг контейнеров в Foundry (управляемые контейнеры с готовой телеметрией, историей диалогов, IAM).
3. Кастомные контейнеры во внешних средах: Azure Container Apps, Azure Kubernetes Service (AKS), Amazon EKS и другие.
AI Landing Zone Accelerator:
- готовые Infrastructure‑as‑Code шаблоны и CI/CD‑пайплайны для развёртывания AI‑ландшафтов;
- поддержка Azure CLI, Terraform, развёртывания через Azure Portal;
- за один прогон создаётся десятки ресурсов и более сотни деплойментов: сеть, Foundry, контейнеры, Cosmos DB, мониторинг, хранилища, jump‑VM.
Интеллектуальная дата‑платформа на базе Microsoft Fabric:
- единый OneLake как корпоративное озеро данных;
- database mirroring для постоянной репликации данных из on‑prem и облачных БД;
- shortcuts к Databricks, Snowflake и облачным object storage без физического копирования данных;
- всё хранится в формате Delta, доступно через SQL и Spark;
- доступ контролируется через Microsoft Entra до уровня строк и столбцов.

Никаких конкретных бенчмарков производительности или цен в материале Microsoft не приводила. Основной акцент — на архитектуре, управлении и масштабировании.

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

1. Governance Hub: единый «шлюз» для всего AI‑трафика

AI Gateway в Azure API Management:

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

MCP Gateway:

хранит централизованный каталог MCP‑серверов и инструментов;
управляет доступом агентов к этим источникам через Model Context Protocol;
даёт инвентаризацию: какие источники есть, кто их использует.

Agent 365 как единая плоскость управления:

интегрирован в Microsoft 365 Admin Center;
позволяет регистрировать агентов, назначать им владельцев, права и политики;
связывает агентов с Entra‑идентичностями, Defender‑защитой и Purview‑политиками.

Microsoft Entra:

каждому агенту — собственная идентичность (managed identity);
принцип наименьших привилегий: агент видит только то, что нужно конкретному сценарию;
понятная «владельческая» модель: кто отвечает за агента и его поведение.

Microsoft Defender:

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

Microsoft Purview:

сканирует и классифицирует данные (PII, финансы, коммерческая тайна и т.д.);
вешает политики, которые агенты обязаны соблюдать;
ведёт аудит: какой агент, когда и к каким чувствительным данным обращался.

Azure Policy + Azure Arc + Azure Monitor:

Azure Policy навешивает обязательные настройки на ресурсы в Azure;
Azure Arc расширяет эти правила на on‑prem и другие облака;
Azure Monitor собирает единый лог и метрики по инфраструктуре, приложениям и самим агентам, включая потреблённые токены.

2. Intelligent Data Platform: на чём агенты «думают»

Задача этого слоя — дать агентам доверенные и понятные данные.

Компоненты:

Work IQ API — контекст работы пользователя:
- почта, календарь, встречи, чаты в Teams, файлы;
- агент понимает, как конкретный человек работает, что уже обсуждалось, какие документы связаны.
Foundry IQ — объединение разных источников знаний:
- структурированные данные (БД);
- неструктурированные данные в облачных хранилищах;
- изображения;
- всё это доступно для retrieval‑процессов агентов.
Fabric IQ — слой бизнес‑контекста:
- добавляет поверх данных информацию об операциях бизнеса: продажи, клиенты, логистика и т.п.;
- позволяет комбинировать несколько IQ‑источников для более насыщенных ответов.

Базовый уровень — OneLake в Microsoft Fabric:

собирает операционные данные из разных систем в единое озеро;
database mirroring реплицирует данные из on‑prem и облачных БД без сложных ETL;
shortcuts дают виртуальный доступ к внешним платформам (Databricks, Snowflake, object storage крупных облаков) без копирования;
всё хранится в Delta‑файлах, к которым можно обращаться через SQL или Spark;
доступ контролируется через Microsoft Entra до уровня строк и столбцов.

Над этим работают Microsoft Purview и Fabric IQ:

Purview:
- делает каталог данных, автоматическую классификацию и политику доступа;
- показывает lineage: откуда пришли данные, как они трансформировались;
- даёт аудит для требований комплаенса.
Fabric IQ и онтологии:
- превращают знания о бизнесе в машиночитаемые модели;
- онтологии описывают сущности (клиент, заказ, продукт), связи и метрики;
- агенты видят не просто таблицы, а структуру бизнеса и могут делать более точные выводы.

3. AI Application Landing Zones: отдельные «коробочки» для проектов

AI Landing Zone — это изолированная подписка/споук для одного агента или группы агентов с похожими требованиями.

Каждый Landing Zone содержит:

собственную конфигурацию приватной сети (VNet, private endpoints, NSG, private DNS);
AI‑ресурсы (модели, хранилища, сервисы оркестрации);
мониторинг и телеметрию (Log Analytics, App Insights, OpenTelemetry);
application services, включая контейнерную инфраструктуру;
управление через Azure Resource Groups с чёткими RBAC‑границами.

Все Landing Zones подключены к:

Governance Hub — общие политики, шлюзы, идентичности;
Intelligent Data Platform — общие источники данных и онтологии.

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

4. Рантаймы: где живут агенты

Microsoft поддерживает три основных варианта.

4.1. No‑code / low‑code агенты

Реализуются как prompt‑агенты и воркфлоу в Microsoft Copilot Studio и Microsoft Foundry Agent Service.
Платформа берёт на себя:
- оркестрацию;
- оценку и телеметрию;
- подключение MCP‑инструментов и источников знаний;
- наблюдаемость в рамках проекта.

Подходит, когда:

сценарий типовой;
важна скорость запуска;
нет жёстких требований к кастомной логике.

4.2. Хостинг контейнеров в Microsoft Foundry

Агент пишется в коде и упаковывается в контейнер.
Foundry даёт «из коробки»:
- хранение истории диалогов;
- управление идентичностью и доступом;
- приватную сетевую связность;
- телеметрию и трассировку на уровне агента и «флота» агентов;
- проектный уровень оркестрации и централизованные политики.

Политики включают:

фильтрацию контента;
защиту от prompt injection;
меры по авторскому праву.

4.3. Кастомные контейнеры во внешних средах

Агенты работают вне Foundry:
- Azure Container Apps;
- Azure Kubernetes Service (AKS);
- Amazon EKS и другие среды.

Общее для всех трёх вариантов:

доступ к моделям и инструментам идёт через Governance Hub;
используются паттерны с managed identity вместо раздачи ключей и URL в коде;
телеметрия стекается в общую систему для end‑to‑end наблюдаемости.

5. AI Landing Zone Accelerator: как это разворачивается

Microsoft предлагает готовый набор шаблонов и пайплайнов:

GitHub‑репозиторий по адресу aka.ms/AILandingZone;
разделы с Reference Architectures и Extensible Implementations;
поддержка развёртывания через:
- Azure CLI;
- Terraform;
- Azure Portal.

Пример развертывания через портал:

Выбираете проект и инстанс.
Определяете, нужен ли Platform Landing Zone Integration (в примере Microsoft — «нет»).
Отмечаете нужные AI‑сервисы, бэкенд данных, Key Vault, storage.
Настраиваете application services, включая контейнерную инфраструктуру.
Выбираете DevOps‑конфигурацию и jumpbox‑опции.
Включаете мониторинг: Log Analytics, Application Insights, OpenTelemetry‑пайплайны.
Настраиваете сеть: firewall, VNet, private endpoints, NSG, private DNS.
Добавляете теги проекта.
Запускаете деплой.

В результате в одной ресурсной группе появятся:

сеть;
Foundry AI;
контейнерные приложения;
Cosmos DB;
мониторинг;
хранилища;
jump‑VM.

Все сервисы используют managed identities для сервис‑ту‑сервис доступа, без раздачи паролей и ключей.

6. Масштабирование агентной сети

Для масштабируемости архитектура опирается на несколько принципов:

Уникальные идентичности агентов:
- у каждого агента — свой объект в Entra;
- понятно, кто владелец, какие права и статус жизненного цикла;
- любые действия можно привязать к конкретному агенту, даже при автономном выполнении.
Общие базовые политики и guardrails:
- обязательная аутентификация и авторизация;
- контролируемый доступ к данным;
- единые правила контент‑безопасности для всех рантаймов.
Определённая наблюдаемость:
- трассировка взаимодействий каждого агента;
- логирование используемых инструментов и источников данных;
- привязка сбоев, затрат и рисков к конкретным агентам.
Шаблоны агентов:
- разработчики не собирают всё с нуля;
- переиспользуют проверенные паттерны с уже настроенными политиками и телеметрией;
- ускоряют вывод в прод без потери контроля.

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

Для кого эта архитектура

Подход Microsoft рассчитан прежде всего на:

крупные и средние компании, у которых уже есть Azure, Microsoft 365 и/или Microsoft Fabric;
команды CIO/CTO, отвечающие за стандартизацию AI‑инициатив;
платформенные команды, строящие общий AI‑фреймворк для десятков внутренних продуктов;
безопасность и комплаенс, которым нужно контролировать, что делают агенты с данными.

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

Практические сценарии

Где подход особенно полезен:

Корпоративные Copilot‑подобные решения:
- помощники для сотрудников, которые одновременно видят почту, календарь, документы, CRM и ERP;
- агент работает с Work IQ, Foundry IQ и Fabric IQ, при этом Purview и Entra ограничивают доступ по ролям.
Автономные операционные агенты:
- боты, которые сами создают заявки, заказы, тикеты в ITSM, обновляют CRM;
- благодаря онтологиям в Fabric IQ они понимают, как связаны сущности бизнеса.
Межагентные mesh‑архитектуры:
- несколько агентов с разной специализацией (финансы, логистика, HR), которые вызывают друг друга как инструменты;
- Governance Hub даёт общий контроль над трафиком и затратами.
AI‑расширения для существующих приложений:
- когда вы добавляете агента внутрь уже работающего сервиса и не хотите ломать текущую инфраструктуру;
- кастомные контейнеры в AKS/EKS, подключённые к Governance Hub, позволяют встроить агента без «зоопарка» ключей и URL.

Где лучше не использовать

Небольшие стартапы без Azure и Microsoft 365, которым важнее скорость, чем корпоративный контроль.
Проекты, где нет доступа к Microsoft‑облаку по юридическим причинам.
Прототипы на 1–2 недели, когда дешевле собрать всё на одном сервере и выкинуть.

Доступность и ограничения

Архитектура целиком опирается на Azure, Microsoft 365, Microsoft Fabric, Microsoft Purview, Microsoft Defender, Microsoft Entra.
Для развёртывания AI Landing Zones и Governance Hub нужен доступ к Azure Portal или возможность работать с Azure CLI / Terraform.
В ряде регионов, включая Россию, доступ к Azure и связанным облачным сервисам Microsoft может быть ограничен. В этом случае для работы с этим стеком потребуется как минимум надёжный доступ к зарубежным ресурсам, а юридические и санкционные риски нужно оценивать отдельно.

Что делать сейчас

Если вы уже в экосистеме Microsoft:

Соберите Governance Hub:
- заведите единый AI Gateway в Azure API Management;
- настройте MCP Gateway и каталог MCP‑серверов;
- введите Agent 365 как обязательную точку регистрации агентов.
Опишите и каталогизируйте данные:
- подключите OneLake и Microsoft Fabric, если их ещё нет;
- включите Purview для каталогизации и классификации;
- начните строить онтологии Fabric IQ для ключевых доменов (продажи, клиенты, логистика).
Внедрите AI Landing Zones:
- возьмите шаблоны с aka.ms/AILandingZone;
- сделайте один‑два пилотных Landing Zone под реальные проекты;
- обкатайте политику, мониторинг и процесс онбординга агентов.
Определите стандарты рантайма:
- где использовать no‑code Copilot Studio;
- где нужны управляемые контейнеры в Foundry;
- где допустимы внешние кластеры AKS/EKS.

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

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

Microsoft не приводит прямых сравнений с GPT‑4o, Claude 3 или другими моделями, потому что речь не о самой модели, а об архитектуре вокруг агентов.

По сути, это ответ на вопросы, которые сейчас каждая крупная компания решает по‑своему:

как централизовать доступ к моделям;
как управлять MCP‑инструментами и их каталогом;
как обеспечить единые политики безопасности и комплаенса для десятков агентов;
как сделать так, чтобы агенты работали не по сырым данным, а по бизнес‑онтологиям.

Если сравнивать по подходу:

Многие вендоры дают конструкторы ботов и SDK, но не предлагают:
- полноценный governance‑слой уровня Azure API Management + Purview + Defender;
- онтологии и Fabric IQ‑подобный слой бизнес‑знаний;
- готовые Landing Zones с IaC‑шаблонами для типовых архитектур.
Платформы вроде отдельных AI‑PaaS‑решений концентрируются на удобстве разработки и оркестрации. Microsoft делает акцент на интеграции с существующей корпоративной инфраструктурой: идентичности, сети, data lake, SIEM/SOAR.

Вывод: если ваша компания уже живёт в Azure и Microsoft 365, архитектура AI Landing Zones и Governance Hub — наиболее логичный путь к массовому запуску агентов без ручной сборки «платформы вокруг платформы». Если вы в другой экосистеме, это хороший ориентир, какие блоки нужно предусмотреть, чтобы агентный зоопарк не превратился в неконтролируемый хаос.

Как запустить и с чего начать

1. Изучить референс‑архитектуру

Перейдите по адресу https://aka.ms/AIArchitecture — там собрана концепция архитектуры AI‑агентов в стеке Microsoft.
Для практики по Landing Zones — https://aka.ms/AILandingZone (GitHub‑репозиторий с документацией и шаблонами).

2. Развёртывание AI Landing Zone через Azure Portal

Шаги, которые демонстрирует Microsoft:

Зайти в Azure Portal и выбрать шаблон AI Landing Zone из репозитория (портал сам подхватывает ARM/Bicep‑шаблон).
Заполнить Project details и Instance details.
В блоке интеграции с Platform Landing Zone выбрать, нужен ли вам общий платформенный слой (в примере — «No»).
В разделе AI services отметить нужные сервисы, выбрать data backend, Key Vault, Storage.
В разделе Application services включить контейнерную инфраструктуру.
В разделе DevOps configuration настроить CI/CD и jumpbox‑опции.
В разделе Monitoring включить Log Analytics и Application Insights, убедиться, что включён сбор OpenTelemetry.
В разделе Networking настроить VNet, private endpoints, NSG, private DNS, запретить публичный доступ ко внутренним сервисам.
Добавить tags для проекта.
Запустить валидацию и нажать Create.

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

3. Подключить агентов

Для no‑code: использовать Microsoft Copilot Studio и Foundry Agent Service, подключив их к Governance Hub и IQ‑источникам.
Для кода и контейнеров:
- собрать контейнер с агентом;
- задеплоить его в Foundry или в AKS/Container Apps/EKS;
- выдать ему managed identity и подключить к AI Gateway и MCP Gateway;
- настроить телеметрию по OpenTelemetry в Log Analytics/App Insights.

Дальше можно масштабировать: добавлять новые Landing Zones, шаблоны агентов и расширять онтологии Fabric IQ под новые бизнес‑домены.