Прямой API, Azure или AWS Bedrock: как сравнить безопасность размещения ИИ
Azure или AWS Bedrock могут лучше вписаться в существующие требования компании к доступу, сети и инфраструктуре. Но они не делают какой-либо сценарий автоматически более безопасным, чем прямой API поставщика модели. Выбор зависит от четырех конкретных вещей: какая модель, где географии обрабатываются данные, какой режим хранения действует для этой модели и какие настройки компания способна поддерживать.
Главное условие: сравнивать следует одинаковую задачу с одинаковой чувствительностью данных, а не бренды. Условия одной модели не распространяются на весь каталог платформы, режим хранения не означает сетевой изоляции.
После статьи вы сможете составить матрицу требований своей компании, проверить три варианта по одинаковым критериям и провести тест в пробном проекте. Это сравнение подходов на основании документации поставщиков, проверенной для этой статьи 11 октября 2026 года, а не аудит вашей учетной записи. Условия меняются, поэтому перед принятием решения проверьте актуальные правила.
Какие требования определяют выбор
Вопрос «что безопаснее» не имеет ответа, пока не названы требования. Вот семь, обычно решающих выбор.
География. Где разрешено обрабатывать и где хранить данные. Это два разных вопроса: данные могут храниться в одной географии, а обрабатываться в другой. Если у компании есть обязанность держать обработку в определенной географии, например, в ЕС, этот пункт становится первым фильтром.
Сеть. Имеет ли трафик к модели идти через частные сетевые соединения или допустим публичный интернет с шифрованием. Для компаний со своей облачной сетью это часто решающее требование.
Доступы. Кто издает и отзывает ключи, как роли привязанные к работникам, используется ли единая система идентификации компании.
Журналы. Какие действия с моделью фиксируются, где хранятся журналы и кто их анализирует. Отдельно: какие журналы ведет сам поставщик и что в них записывается.
Договор. Какой документ регулирует обработку данных, кто является стороной договора и чьи условия действуют для конкретной модели?
Набор моделей. Доступна ли нужная модель на платформе, в нужном регионе и в нужном типе развертывания. Каталоги платформ отличаются, и новая модель может появиться на одной платформе раньше, чем на другой.
Операционная команда. Кто будет настраивать и поддерживать среду. Облачная платформа дает много средств контроля, но каждый из них должен настроить, проверять и обновлять.
Прямой API
Прямой API означает, что компания работает с поставщиком модели напрямую, без посредника-облака. Цепочка кратчайшая: ваше приложение и поставщик. Разберем на примере OpenAI по его документации по данным в API.
Обучение. По документации, с 1 марта 2023 года данные, отправленные в API, не используются для обучения или улучшения моделей OpenAI, если клиент явно не согласился делиться данными.
Журналы мониторинга злоупотреблений. Общая политика предусматривает журналы до 30 дней по умолчанию; таблица документации уточняет сроки и исключения каждого endpoint. Это не означает одинаковый срок для всех объектов и функций. Подольше их могут хранить, если этого требует закон или если это разумно необходимо для защиты сервисов или третьих лиц.
Режимы ZDR и MAM. Zero Data Retention (нулевое хранение) и Modified Abuse Monitoring (измененный мониторинг злоупотреблений) исключают содержимое клиента из журналов мониторинга. Оба режима требуют предварительного одобрения OpenAI и принятия дополнительных условий; действуют исключения для отдельных входных данных и функций. Документация также описывает Private Retention with PSP и Safety Retention: для определенного клиента и модели условия могут изменяться с предварительным уведомлением. Поэтому проверяют фактически назначенный режим, а не только первоначальное одобрение ZDR. ZDR поддерживают не все способности API. Например, Assistants, векторные хранилища, файлы, пакетная обработка и задачи дообучения не входят в список совместимых с ZDR.
Состояние приложения. Отдельно от журналов существуют данные, которые сохраняются, чтобы функции работали. Например, ответы Responses API по умолчанию сохраняются не менее 30 дней, а ассистенты, потоки и векторные хранилища сохраняются до тех пор, пока их не удалят.
География. OpenAI предлагает хранение данных в нескольких регионах, а поддерживаемую региональную обработку на дату исследования в США, Europe (ЕЭС + Швейцария) и ОАЭ. Доступность зависит от endpoint, модели и режима; настройки действуют на уровне проекта. Для регионов вне США необходимы согласованные средства контроля хранения и дополнительное соглашение Modified Retention; ОАЭ нуждаются в дополнительном одобрении.
Что остается на компании. Хранение ключей API, разграничение доступа между командами, собственные журналы приложения, сетевая защита серверов, которые посылают запросы. Особо проверьте способы идентификации администратора, авторизации запросов приложения, сетевого подключения и аудита. Наличие SSO для входа в платформу не равно авторизации каждого API-вызова.
Azure
Для компании, которая уже ведет доступы, сеть и журналы в Azure, преимущество платформы, прежде всего, организационное. Модель попадает в ту же систему управления, которой уже пользуется команда. Это преимущество конфигурации и процессов компании, а не свойство бренда.
Microsoft описывает обработку данных для моделей, которые Azure продает в Microsoft Foundry, так:
- запросы и ответы недоступны OpenAI и другим поставщикам моделей, продаваемых Azure;
- они не используются поставщиками для улучшения их моделей и не используются для обучения базовым генеративным моделям без разрешения клиента;
- модели не взаимодействуют с сервисами, управляемыми их поставщиками, например с ChatGPT или API OpenAI.
География развертывания
Здесь самое важное различие, которое легко пропустить. Название региона ресурса не всегда описывает, где именно обрабатываются данные. Документация различает три варианта:
| Тип развертывания | Где обрабатываются запросы и ответы | Где хранятся данные в состоянии покоя |
|---|---|---|
| Стандартное (региональное) | В географии, которую указал клиент; для операционных нужд возможна обработка между регионами в пределах этой географии | В географии ресурса |
| DataZone | В любой географии внутри зоны данных, определенной Microsoft. Для ресурса в ЕС это страна ресурса или любое другое государство-член; для США где угодно в США | В географии, определенной клиентом |
| Global | В любой географии, где развернута соответствующая модель | В географии, определенной клиентом |
Следовательно, для компании с обязанностью обрабатывать данные в ЕС развертывание Global не отвечает этому требованию, даже если ресурс создан в европейском регионе. DataZone EU ограничивает обработку государствами ЕС, а стандартное развертывание ограничивает ее географией ресурса. Для пакетной обработки документация отдельно указывает, что данные хранятся в географии клиента, но обработка может производиться в любой географии, где развернута модель.
Мониторинг злоупотреблений и сохраненные данные
Запросы и ответы, которые система мониторинга обозначила как подозрительные, могут быть сохранены для проверки людьми. Хранение происходит в географии ресурса. Доступ имеют только уполномоченные сотрудники Microsoft по отдельным защищенным процедурам, а для развертываний в Европейской экономической зоне эти работники находятся в ЕЭС. Клиенты могут подать заявку на измененный мониторинг злоупотреблений: если она одобрена, хранение и проверка людьми не производятся, хотя автоматическая проверка возможна. Срок хранения на этой странице не указан, документация отсылает в отдельную статью о мониторинге злоупотреблений.
Отдельно хранятся данные функций: история сообщений Responses API, потоки ассистентов, сохраненные пары запрос-ответ, загруженные файлы. Они хранятся в ресурсе клиента в той же географии и могут быть удалены клиентом. Документация предупреждает, что модели и функции в предварительном доступе могут не поддерживать всех описанных условий.
Bedrock
AWS применяет к Bedrock модель разделенной ответственности. AWS отвечает за защиту глобальной инфраструктуры, а клиент контролирует свое содержимое и отвечает за настройки безопасности используемых сервисов.
Изоляция от поставщика модели. В каждом регионе, где доступен Bedrock, для каждого поставщика моделей имеется отдельный аккаунт развертывания, которым владеет и управляет команда Bedrock. Поставщики моделей не имеют доступа к этим аккаунтам, а следовательно, по документации, не имеют доступа к журналам Bedrock и запросам и ответам клиентов.
Доступы и журналы. AWS рекомендует предоставлять пользователям только необходимые для работы права через IAM Identity Center или IAM, использовать многофакторную аутентификацию, вести журнал действий через CloudTrail и применять TLS: TLS 1.2 обязателен, TLS 1.3 рекомендован. Отдельно документация предупреждает не вносить конфиденциальные данные в теги и произвольные текстовые поля, поскольку они могут попасть в журналы биллинга или диагностики.
Режимы хранения зависят от модели
Утверждение "Bedrock никогда не сохраняет запросы" в общем виде использовать нельзя. Действующая документация описывает несколько режимов хранения, и то, какой из них действует, зависит от настроек аккаунта и от требований конкретной модели.
| Режим | Что значит по документации |
|---|---|
none | Нулевое хранение: данные запросов и ответов не записываются в долговременное хранилище AWS и не передаются поставщику модели |
default | Действует политика хранения конкретной модели. AWS может хранить данные для безопасности и предотвращения злоупотреблений; поставщик модели их не получает |
aws_review | Входные и исходящие данные могут храниться для проверки людьми со стороны AWS в пределах AWS. Для моделей, требующих этого, до 30 дней |
provider_data_share | Устаревший режим; по документации, содержимое поставщикам моделей пока не передается |
inherit | Решения на этом уровне не заданы, действует настройка более широкого уровня |
Несколько деталей, изменяющих выводы:
- Модель может потребовать определенного режима. Некоторые поставщики требуют проверки людьми как условия доступа к модели. На 11.10.2026 документация называет следующими моделями Claude Fable 5 и Claude Fable 5.1: в стандартных условиях они недоступны в режимах
noneиdefault; отдельный ZDR-допуск возможен только после индивидуального одобрения для аккаунта и модели. Большинство других моделей проверки людьми не требуют. - Приоритет настроек. Действует первое значение, отличное от
inherit, в порядке: проект, учетная запись в конкретном регионе, значение модели по умолчанию. Уровень проекта существует для bedrock-mantle; Bedrock Runtime и control plane не имеют этого понятия. Настройки не распространяются на другие регионы. - Граница
store=false. В режимеdefaultпараметрstore=falseне гарантирует нулевого хранения. Режимnoneпо документации запрещает длительное хранение этих запросов и ответов AWS. Это не отключает ваши собственные журналы или сохранения в отдельных интеграциях. - Межрегиональная обработка. Если используется межрегиональный инференс, сохраненные данные сохраняются в регионе, где запрос фактически обрабатывается.
- Как проверить и закрепить. На дату исследования консольного интерфейса для этой настройки нет, режим задают через API. Сигнал режима для конкретной модели доступен через bedrock-mantle API; Bedrock control plane такого сигнала не дает, а разрешенные режимы можно закрепить политиками организации через условный ключ IAM.
Матрица сравнения
Каждую строчку ниже можно проверить документом или тестом. Клеточки описывают, что именно проверять, а не ставят оценку.
| Требование | Прямой API (OpenAI) | Azure (модели в Microsoft Foundry) | AWS Bedrock |
|---|---|---|---|
| Обучение на ваших данных | Не используются по умолчанию без явного согласия | Не используются для обучения базовым моделям без разрешения клиента | Проверить в документации и условиях конкретной модели |
| География обработки | Региональная обработка по отдельной опции, на дату исследования США, Europe (ЕЭЗ+Швейцария), ОАЭ; зависит от endpoint/модели | Зависит от типа развертывания: стандартное, DataZone, Global | Регион запроса; отдельно проверить межрегиональный инференс |
| Хранение для безопасности | Журналы мониторинга до 30 дней; MAM или ZDR по одобрению | Подозрительное содержимое может храниться для проверки; измененный мониторинг по заявке | зависит от режима и модели; aws_review до 30 дней для требующих этого моделей |
| Данные функций | Responses, ассистенты, файлы хранятся по своим правилам; не все совместимо с ZDR | Сохраняются в ресурсе клиента, удаляются клиентом | Проверить для каждой используемой функции |
| Доступы | Ключи и проекты организации OpenAI | Имеющиеся механизмы Azure компании | IAM, политики организации, ограничение режима хранения |
| Журналы действий | Проверить аудит платформы и дополнить собственными журналами приложения | Средства Azure, которые уже использует компания | CloudTrail и другие средства AWS |
| Доступ поставщика модели | Поставщик и является оператором | Запросы недоступны поставщикам моделей | Поставщики не имеют доступа к аккаунтам развертывания |
| Нужна модель и регион | Проверить доступность | Проверить модель, регион и тип развертывания | Проверить модель, регион и разрешенные режимы |
Учебный пример: два сценария, одна задача
Оба сценария придуманы. Задача одинакова: ИИ кратко подытоживает обращение клиентов в поддержку, содержащих имена и контакты. Чувствительность данных одинакова.
Сценарий А. Компания уже ведет доступы и журналы в Azure и обязана обрабатывать данные в ЕС. Наличие бренда Microsoft здесь ничего не решает. Решает тип развертывания. Global не подходит, потому что обработка возможна в любой географии, где развернута модель. DataZone EU ограничивает обработку государствами ЕС. Стандартное региональное развертывание ограничивает его географией ресурса. Далее команда проверяет, доступна ли нужная модель в соответствующем регионе и типе развертывания, используются ли функции, хранящие данные, и нужен ли измененный мониторинг злоупотреблений. Преимущество Azure в этом сценарии реально, но она происходит из существующих процессов компании.
Сценарий Б. Облачной команды у компании нет. Azure или Bedrock дают много средств контроля, но каждое из них нужно настроить и поддерживать: роли, сеть, журналы, политики режимов хранения. К стоимости модели здесь прилагаются время и деньги на настройки и сопровождение. Без человека, занимающегося этим, сложная платформа может дать меньше реального контроля, чем более простой прямой API с настроенной региональной обработкой. Если же требование строго ограничивает обработку государствами ЕС, регион OpenAI Europe (ЕЭЗ+Швейцария) сам по себе ее не подтверждает. Требуется проверка точных договорных и технических границ; удобство прямого API не компенсирует неподходящую географию.
Вывод из обоих сценариев одинаков: правильный выбор определяют требования и ресурсы компании, а не название платформы.
Процедура проверки
Матрица дает гипотезу. Подтверждает ее тест в пробном проекте на той же задаче и с теми же типами данных (тестовыми, а не реальными).
Модель и регион. Убедитесь, что необходимая модель доступна в нужном регионе и типе развертывания. Для Azure зафиксируйте тип развертывания. Для Bedrock проверьте настройки региона; через bedrock-mantle доступны также эффективный режим модели и allowed_modes. Для Runtime учтите отличия API и проверьте допустимость вызова тестом.
Права. Создайте роли с минимальными правами: отдельно для приложения, отдельно для администраторов. Убедитесь, что работник без нужной роли не может вызывать модель или изменить настройки хранения.
Удаление. Проверьте, какие данные функций сохраняются (история ответов, файлы, потоки, векторные хранилища) и как их удалить. Удалите тестовые объекты и проверьте их недоступность в интерфейсе и API. Это проверка доступа после удаления, а не доказательство очистки всех резервных копий или safety-логов: их сроки устанавливаются отдельными условиями поставщика.
Аудит. Проверьте, что вызовы модели и изменения настроек фиксируются в журналах, реально просматриваемых вашей командой.
Доступность. Проверьте лимиты, задержку и поведение при недоступности модели в выбранном регионе. Если для обхода ограничений понадобится другой регион или тип развертывания, это изменяет заключение о географии.
Что сделать в ближайшее время:
- Укажите семь требований компании: географию, сеть, доступы, журналы, договор, модели, команду.
- Выберите одну задачу с фиксированной чувствительностью для сравнения.
- Заполните матрицу для трех вариантов и укажите дату проверки документации.
- Для Azure зафиксируйте тип развертывания, для Bedrock режим хранения конкретной модели, для прямого API нужны режимы и регион.
- Проведите тест в пробном проекте: модель и регион, права, удаление, аудит, доступность.
- Задокументируйте решение и назначьте человека, который будет повторно проверять условия после изменений в моделях или документации.
Часто задаваемые вопросы
Нет. Архитектура и договор помогают выполнить отдельные требования, например по географии или безопасности, но законность процесса оценивается в целом: основание обработки, минимизацию, роли сторон, международные передачи. Детальнее об этом в нашей статье о персональных данных в облачном ИИ.
Да. В Bedrock, например, некоторые модели в стандартных условиях требуют режима с проверкой людьми; возможность отдельного ZDR-допуска оценивается для конкретного аккаунта и модели. Ознакомьтесь с условиями выбранной модели, режима и функций, а не только на общей странице платформы.
Потому что название региона ресурса не всегда описывает географию обработки. В Azure для Global-развертывания запросы и ответы могут обрабатываться в любой географии, где развернута модель, хотя данные в состоянии покоя хранятся в географии клиента.
Консультация по размещению корпоративного ИИ
За 15 минут со специалистом по AI-интеграциям обсудим вашу задачу, географию обработки и текущую инфраструктуру. Определим, какие требования проверить первыми для прямого API, Azure или Bedrock.
Требования
Размещение ИИ
15 минут со специалистом: определим первые критерии выбора размещения ИИ для вашей компании.
