- Дата публикации
Как Microsoft проектирует «ограждения» для ИИ‑приложений и агентов в Marketplace
Что появилось / что изменилось
Microsoft описала, как она ожидает проектировать защитные «ограждения» (guardrails) для ИИ‑приложений и агентов, которые выходят в Microsoft Marketplace. Речь не про одну конкретную фичу, а про набор архитектурных практик, которые авторы предлагают считать обязательными элементами дизайна.
Ключевые изменения в подходе:
- Guardrails становятся частью архитектуры ИИ‑продукта, а не заплатками «после инцидента».
- В качестве основы для проектирования рисков Microsoft использует список OWASP GenAI Top 10 — отдельный набор угроз именно для генеративного ИИ.
- Для ИИ‑агентов, которые умеют сами вызывать инструменты и API, guardrails приравнивают к базовым требованиям безопасности и надежности, без которых продукт не пройдет по ожиданиям корпоративных клиентов и правилам Marketplace.
- Фокус — на трех вещах: конфиденциальность, целостность и доступность ИИ‑систем, плюс соответствие принципам Responsible AI.
Четких чисел по скорости, стоимости или лимитам контекста Microsoft не приводит: речь про архитектурный каркас, а не про конкретную модель или тариф.
Как это работает
Microsoft предлагает смотреть на безопасность ИИ через призму OWASP GenAI Top 10. Это список типовых рисков, которые почти не покрывает классическая веб‑безопасность: prompt injection, утечки системных подсказок, неконтролируемые действия агентов, пересечение границ данных и так далее.
Важно: Microsoft не предлагает тупо «отчек-листить» все 10 пунктов. Вместо этого OWASP используют как линзу проектирования: он помогает понять, где именно в системе нужны жесткие границы.
Три фактора, от которых зависит набор рисков:
- Автономность агента: может ли он действовать без подтверждения пользователя.
- Паттерны доступа к данным: работает ли он с несколькими арендаторами, подписками, внешними системами.
- Интеграции: сколько у него инструментов, API и внешних сервисов.
На этой основе Microsoft предлагает строить архитектурные guardrails в четырех слоях:
-
Ввод и промпты
Структурировать и валидировать запросы, контролировать, как они смешиваются с системным контекстом. Цель — снизить риск prompt injection, утечки системного промпта и подмены инструкций. -
Действия и инструменты
Явно описать, какие инструменты агент может вызывать, при каких условиях и с какими ограничениями по объему и частоте. Это сдерживает «разбегающиеся» цепочки вызовов и неожиданные действия. -
Доступ к данным
Применять доступ, зависящий от личности и контекста, а не от формулировки промпта. То есть не «модель догадалась, что ей можно», а четкие политики для кросс‑тенант, кросс‑подписки и внешних источников. -
Вывод и модерация
Считать ответ ИИ недоверенным до проверки. Валидировать, фильтровать и модерать выходные данные перед тем, как что‑то выполнить или показать пользователю.
Ключевая идея: guardrails должны находиться на границах доверия — между пользователями и моделями, моделями и инструментами, агентами и источниками данных.
Что это значит для вас
Если вы делаете ИИ‑приложение или агента под Microsoft Marketplace, Microsoft фактически говорит: guardrails — это не «опция для галочки», а часть базового дизайна.
Где это полезно:
- Корпоративные ассистенты. Когда агент ходит по нескольким базам, тенантам и подпискам, вам нужны жесткие правила, кто и что видит. Иначе легко нарушить конфиденциальность.
- Автономные агенты с доступом к API. Если агент может создавать тикеты, изменять настройки или дергать внешние системы, без четких ограничений вы рискуете неконтролируемыми действиями и счетами за ресурсы.
- Мультисервисные интеграции. Чем больше инструментов подключено, тем выше шанс, что связка «промпт → инструмент → данные → действия» поведет себя неожиданно. Архитектурные guardrails уменьшают этот риск.
Где можно не усложнять:
- Простой чат‑бот без доступа к чувствительным данным и без инструментов. Для него достаточно базовой фильтрации ввода/вывода, а тяжелую архитектуру можно отложить.
Практический вывод: сначала описываете архитектуру — какие данные, какие инструменты, какая автономность. Потом по OWASP GenAI Top 10 находите слабые места и именно там строите guardrails. Не наоборот.
Если вы работаете из России, доступ к Microsoft Marketplace и облачным сервисам может потребовать VPN и юридическую инфраструктуру за пределами страны. Это нужно учитывать на этапе планирования продукта.
Место на рынке
Здесь речь не про конкуренцию конкретных моделей вроде GPT‑4o или Claude 3, а про подход к безопасности ИИ‑систем в экосистеме Microsoft.
Фактически Microsoft предлагает стандарт проектирования для всего, что выходит в ее Marketplace: ИИ‑продукт должен иметь явные архитектурные границы по вводу, действиям, данным и выводам, спроектированные с опорой на OWASP GenAI Top 10.
Это ближе к методологиям и фреймворкам, чем к «еще одной модели» или «еще одному ассистенту». Если вы уже живете в Azure и планируете публиковаться в Microsoft Marketplace, этот подход становится отправной точкой. Если ваша инфраструктура завязана на других облаках или вы не выпускаете продукты в маркетплейсы, эти практики все равно можно перенести как общий каркас безопасности для любых ИИ‑агентов и приложений.