Microsoft на конференции Build 2026 расширила Azure API Management и фактически предложила корпоративным командам единый вход для работы с разными ИИ-моделями. Ключевая новинка, Unified Model API, позволяет клиентским приложениям говорить в одном формате, пока шлюз сам переводит запросы в нативные схемы Anthropic, Google Vertex AI и других провайдеров. Для российских команд, которые строят мультивендорные AI-стеки или хотя бы не хотят переписывать интеграции при каждой смене модели, это уже не косметическое обновление, а попытка превратить API-шлюз в главный пульт управления ИИ.
О нововведениях сообщает InfoQ. По данным издания, Microsoft вынесла в Azure API Management сразу несколько функций, которые раньше компании обычно собирали по кускам: унификацию форматов запросов к моделям, единые политики безопасности для LLM и агентных сценариев, а также более детальную телеметрию по токенам. Иными словами, корпорация делает ставку на знакомую для enterprise-мира логику: не заводить отдельный зоопарк инструментов для агентов и моделей, а расширить уже существующий API governance на новую инфраструктуру.
Главная деталь здесь в том, что Unified Model API сейчас работает как публичное превью и предлагает единый клиентский формат на базе OpenAI Chat Completions. Дальше Azure API Management сам преобразует запрос в нужный backend-формат, будь то Anthropic Messages API или другая схема. Практический смысл довольно приземленный: команда может держать один контракт на стороне приложения, а выбор провайдера, модели и маршрута вынести на слой шлюза. Это снижает цену экспериментов. Если продуктовая команда хочет переключить часть трафика с одного вендора на другой из-за задержек, цены, региональных ограничений или просто качества ответа, клиентский код трогать не обязательно.
Именно этот момент, вероятно, окажется самым полезным для крупных разработческих команд. В 2024 и 2025 годах мультиоблачная и мульти-модельная стратегия звучала красиво в презентациях, но на практике упиралась в несовместимые API, разные схемы аутентификации, отличающиеся лимиты и отдельную обвязку под каждого поставщика. Microsoft пытается закрыть этот операционный долг на уровне шлюза. Причем речь не только об удобстве. Когда доступ к моделям централизован за одним API-слоем, единообразно применяются rate limit, политики фильтрации, аудит и метрики. Для ИТ-директора это означает меньше самодеятельности по командам, для платформенной разработки — меньше кастомных прокладок, для FinOps — более внятную картину расходов.
Вторая большая новость касается безопасности контента, и она, возможно, даже важнее красивой обертки вокруг моделей. Политика llm-content-safety, которая раньше проверяла входящий и исходящий трафик LLM через Azure Content Safety, теперь распространяется и на MCP tool calls, и на Agent-to-Agent payloads. Это важный сдвиг: Microsoft фактически признает, что риски в агентных системах сидят не только в самом промпте или ответе модели, но и в аргументах вызова инструментов, в тексте ответов от MCP-серверов и в обмене данными между агентами. То есть контроль переместился с уровня отдельной модели на уровень всей цепочки взаимодействий.
Механика при этом достаточно конкретная. Фильтрация работает по категориям Hate, SelfHarm, Sexual и Violence, а степень строгости можно настраивать по шкале от 0 до 7, где 0 — самый жесткий режим, а 7 — самый мягкий. Отдельно есть атрибут shield-prompt, который предназначен для проверки на adversarial prompt injection. Для команд, строящих агентные сценарии поверх внутренних API и корпоративных знаний, это выглядит полезнее любого абстрактного тезиса про Responsible AI. В реальной эксплуатации проблема не в том, что модель скажет что-то лишнее в чате, а в том, что агент может получить вредоносную инструкцию через инструмент, внешнюю систему или другой агент и затем выполнить нежелательное действие уже внутри бизнес-процесса.
Есть и важная оговорка, которую разработчикам лучше не пропустить. Для обычных нестриминговых ответов нарушение политики приводит к понятной блокировке с кодом 403. А вот в streaming-режиме поведение другое: Azure API Management буферизует события в скользящем окне и просто перестает проксировать дальнейшие данные клиенту, не возвращая явную ошибку. Это значит, что клиентские приложения и особенно агентные оркестраторы должны уметь корректно обрабатывать внезапно оборванный поток. Если логика клиента ждет формального error response, можно получить трудноотлавливаемые сбои, которые внешне будут выглядеть как зависший или недоговоривший ассистент. Microsoft также добавила параметры window-size и window-overlap-size, чтобы управлять разбиением контента длиннее 10 000 символов, то есть лимита Azure Content Safety для одной проверки.
Третье направление — деньги и наблюдаемость. Azure API Management расширила token metrics для Application Insights: теперь сервис логирует reasoning tokens, cached tokens и audio tokens для форматов OpenAI Chat Completions, OpenAI Responses и Anthropic Messages API. Поддержка, как пишет InfoQ, распространяется на Microsoft Foundry, OpenAI, Amazon Bedrock, Google Vertex AI и других провайдеров. Для тех, кто уже пытался строить бюджетирование AI-нагрузок по старым метрикам, новость вполне прикладная. Современные модели расходуют бюджет не только на обычные входные и выходные токены: reasoning-часть и кэширование заметно меняют экономику запросов, а без отдельного учета финмодель получается слишком оптимистичной.
Наконец, Microsoft подводит под агентный стек еще и слой обнаружения ресурсов. Azure API Center data plane MCP server вышел в general availability и работает как единая корпоративная точка discovery для MCP-серверов, инструментов, API, агентов и AI-ассетов через одно MCP-подключение. Если команда регистрирует новый MCP server в API Center, он автоматически становится доступен подключенным агентам без перенастройки каждого клиента. Параллельно Azure API Management теперь умеет публиковать существующие REST API как MCP servers. Это довольно прозрачный сигнал рынку: старые корпоративные API никто не собирается переписывать ради модной агентной обвязки, их просто адаптируют в новый протокол доступа.
На этом фоне особенно заметен конкурентный расчет Microsoft. У AWS есть Bedrock Guardrails, но, по оценке InfoQ, у Amazon нет прямого аналога мультипровайдерному Unified Model API и такому же покрытию безопасности для MCP и Agent-to-Agent сценариев. У Google Apigee появились собственные AI gateway-функции, но не в такой широте протоколов. Cloudflare AI Gateway, напротив, сильнее сфокусирован на лимитах расходов и кэшировании. Ставка Microsoft предельно понятна: не создавать еще одну отдельную категорию AI control plane, а доказать, что старый добрый API gateway и есть естественная точка управления ИИ-нагрузками. Если этот подход приживется, через год рынок будет спорить уже не о том, нужен ли AI gateway, а о том, какой шлюз быстрее всех научился понимать агентов, инструменты и экономику токенов.
The post Azure API Management унифицировал доступ к ИИ-моделям appeared first on iTech News.