Прямий API, Azure чи AWS Bedrock: як порівняти безпеку розміщення ШІ

Azure або AWS Bedrock можуть краще вписатися в наявні вимоги компанії до доступів, мережі та інфраструктури. Але вони не роблять будь-який сценарій автоматично безпечнішим, ніж прямий API постачальника моделі. Вибір залежить від чотирьох конкретних речей: яка модель, у якій географії обробляються дані, який режим зберігання діє для цієї моделі і які налаштування компанія здатна підтримувати.

Головна умова: порівнювати варто однакову задачу з однаковою чутливістю даних, а не бренди. Умови однієї моделі не поширюються на весь каталог платформи, а режим зберігання не означає мережевої ізоляції.

Після статті ви зможете скласти матрицю вимог своєї компанії, перевірити три варіанти за однаковими пунктами і провести тест у пробному проєкті. Це порівняння підходів за документацією постачальників станом на дослідження від 11.10.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.

Географія розгортання

Тут найважливіше розрізнення, яке легко пропустити. Назва регіону ресурсу не завжди описує, де саме обробляються дані. Документація розрізняє три варіанти:

Отже, для компанії з обов'язком обробляти дані в ЄС розгортання Global не відповідає цій вимозі, навіть якщо ресурс створено в європейському регіоні. DataZone EU обмежує обробку державами ЄС, а стандартне розгортання обмежує її географією ресурсу. Для пакетної обробки документація окремо вказує, що дані зберігаються в географії клієнта, але обробка може відбуватися в будь-якій географії, де розгорнута модель.

Моніторинг зловживань і збережені дані

Запити і відповіді, які система моніторингу позначила як підозрілі, можуть зберігатися для перевірки людьми. Зберігання відбувається в географії ресурсу. Доступ мають лише уповноважені працівники Microsoft через окремі захищені процедури, а для розгортань у Європейській економічній зоні ці працівники перебувають у ЄЕЗ. Клієнти можуть подати заявку на змінений моніторинг зловживань: якщо її схвалено, зберігання і перевірка людьми не проводяться, хоча автоматична перевірка можлива. Строк зберігання на цій сторінці не вказано, документація відсилає до окремої статті про моніторинг зловживань.

Окремо зберігаються дані функцій: історія повідомлень Responses API, потоки асистентів, збережені пари запит-відповідь, завантажені файли. Вони зберігаються в ресурсі клієнта в тій самій географії і можуть бути видалені клієнтом. Документація попереджає, що моделі і функції в попередньому доступі (preview) можуть не підтримувати всіх описаних умов.

Bedrock

AWS застосовує до Bedrock модель розділеної відповідальності. AWS відповідає за захист глобальної інфраструктури, а клієнт контролює свій вміст і відповідає за налаштування безпеки сервісів, якими користується.

Ізоляція від постачальника моделі. У кожному регіоні, де доступний Bedrock, для кожного постачальника моделей є окремий обліковий запис розгортання, яким володіє і керує команда Bedrock. Постачальники моделей не мають доступу до цих облікових записів, а отже, за документацією, не мають доступу до журналів Bedrock і до запитів та відповідей клієнтів.

Доступи і журнали. AWS рекомендує давати користувачам лише потрібні для роботи права через IAM Identity Center або IAM, використовувати багатофакторну автентифікацію, вести журнал дій через CloudTrail і застосовувати TLS: TLS 1.2 обов'язковий, TLS 1.3 рекомендований. Окремо документація застерігає не вносити конфіденційні дані в теги та довільні текстові поля, бо вони можуть потрапити в журнали білінгу чи діагностики.

Режими зберігання залежать від моделі

Твердження «Bedrock ніколи не зберігає запити» в загальному вигляді використовувати не можна. Чинна документація описує кілька режимів зберігання, і те, який з них діє, залежить від налаштувань облікового запису і від вимог конкретної моделі.

Кілька деталей, які змінюють висновки:

• Модель може вимагати певного режиму. Деякі постачальники вимагають перевірки людьми як умови доступу до моделі. На 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.

Матриця порівняння

Кожен рядок нижче можна перевірити документом або тестом. Клітинки описують, що саме перевіряти, а не ставлять оцінку.

Навчальний приклад: два сценарії, одна задача

Обидва сценарії вигадані. Задача однакова: ШІ стисло підсумовує звернення клієнтів у підтримку, які містять імена й контакти. Чутливість даних однакова.

Сценарій А. Компанія вже веде доступи і журнали в Azure і має обов'язок обробляти дані в ЄС. Наявність бренду Microsoft тут нічого не вирішує. Вирішує тип розгортання. Global не підходить, бо обробка можлива в будь-якій географії, де розгорнута модель. DataZone EU обмежує обробку державами ЄС. Стандартне регіональне розгортання обмежує її географією ресурсу. Далі команда перевіряє, чи доступна потрібна модель у відповідному регіоні й типі розгортання, чи використовуються функції, які зберігають дані, і чи потрібен змінений моніторинг зловживань. Перевага Azure в цьому сценарії реальна, але вона походить з наявних процесів компанії.

Сценарій Б. Хмарної команди в компанії немає. Azure чи Bedrock дають багато засобів контролю, але кожен з них треба налаштувати і підтримувати: ролі, мережу, журнали, політики режимів зберігання. До вартості моделі тут додаються час і гроші на налаштування і супровід. Без людини, яка цим займатиметься, складна платформа може дати менше реального контролю, ніж простіший прямий API з налаштованою регіональною обробкою. Якщо ж вимога суворо обмежує обробку державами ЄС, регіон OpenAI Europe (ЄЕЗ + Швейцарія) сам по собі її не підтверджує. Потрібна перевірка точних договірних і технічних меж; зручність прямого API не компенсує невідповідну географію.

Висновок з обох сценаріїв однаковий: правильний вибір визначають вимоги і ресурси компанії, а не назва платформи.

Процедура перевірки

Матриця дає гіпотезу. Підтверджує її тест у пробному проєкті на тій самій задачі і з тими самими типами даних (тестовими, а не реальними).

Модель і регіон. Перевірте, що потрібна модель доступна в потрібному регіоні й типі розгортання. Для Azure зафіксуйте тип розгортання. Для Bedrock перевірте налаштування свого регіону; через bedrock-mantle доступні також ефективний режим моделі та allowed_modes. Для Runtime врахуйте відмінності API й перевірте допустимість виклику тестом.

Права. Створіть ролі з мінімальними правами: окремо для застосунку, окремо для адміністраторів. Перевірте, що працівник без потрібної ролі не може викликати модель чи змінити налаштування зберігання.

Видалення. Перевірте, які дані функцій зберігаються (історія відповідей, файли, потоки, векторні сховища) і як їх видалити. Видаліть тестові об’єкти і перевірте їх недоступність в інтерфейсі та API. Це перевірка доступу після видалення, а не доказ очищення всіх резервних копій або safety-логів: їхні строки встановлюються окремими умовами постачальника.

Аудит. Перевірте, що виклики моделі і зміни налаштувань фіксуються в журналах, які ваша команда реально переглядає.

Доступність. Перевірте ліміти, затримку і поведінку при недоступності моделі в обраному регіоні. Якщо для обходу обмежень знадобиться інший регіон чи тип розгортання, це змінює висновок про географію.

Що зробити найближчим часом:

1. Запишіть сім вимог компанії: географію, мережу, доступи, журнали, договір, моделі, команду.
2. Оберіть одну задачу з фіксованою чутливістю даних для порівняння.
3. Заповніть матрицю для трьох варіантів з прямими посиланнями на документацію і датою перевірки.
4. Для Azure зафіксуйте тип розгортання, для Bedrock режим зберігання конкретної моделі, для прямого API потрібні режими і регіон.
5. Проведіть тест у пробному проєкті: модель і регіон, права, видалення, аудит, доступність.
6. Задокументуйте рішення і призначте людину, яка повторно перевірятиме умови після змін у моделях чи документації.

Часті питання