OpenAI хоче дати бізнесу доступ до найпотужніших моделей і водночас не змушувати компанії складати конфіденційні промпти в чужу шухляду «про всяк випадок». Для цього існує Zero Data Retention, або ZDR: спеціальний режим OpenAI API, за якого вміст запитів і відповідей не потрапляє до журналів моніторингу зловживань і не зберігається як стан підтримуваних API-функцій.
У серпні 2026 року OpenAI підтвердила, що планує підтримувати ZDR і для frontier-моделей, а також показала Private Safety Processing. Нова система має знаходити небезпечні схеми в серії пов’язаних взаємодій без доступу працівників OpenAI до самого контенту. Звучить привабливо, але одна галочка не перетворює будь-яку ШІ-інтеграцію на банківський сейф. Розбираємо, що саме захищає ZDR, де залишаються винятки та що перевірити до завантаження договорів, медичних записів або внутрішнього коду.
Що таке Zero Data Retention в OpenAI API
За стандартними правилами OpenAI дані, надіслані через API, не використовують для навчання моделей, якщо клієнт сам не погодився ними поділитися. Проте це ще не означає нульове зберігання. Для більшості API-функцій компанія за замовчуванням може формувати журнали моніторингу зловживань із фрагментами запитів і відповідей та зберігати їх до 30 днів.
Zero Data Retention прибирає вміст клієнта з цих журналів для підтримуваних сценаріїв. Для /v1/responses і /v1/chat/completions параметр store примусово поводиться як false, навіть якщо розробник надішле true. Налаштування можна застосувати до всієї API-організації або до окремого проєкту після схвалення OpenAI.
Цей режим призначений для відповідних клієнтів API. У звичайному ChatGPT Plus або Pro немає кнопки «увімкнути ZDR для цього чату». Якщо співробітник вставляє договір у споживчий чат, корпоративна політика API на цю розмову не поширюється.
Чим ZDR відрізняється від store false і заборони навчання
Три схожі формулювання часто змішують в одне, а потім дивуються результату аудиту. Насправді кожне керує іншим шаром обробки даних.
| Механізм | Що він змінює | Чого не гарантує |
|---|---|---|
| API-дані не використовують для навчання | Промпти й відповіді не додають до тренувальних наборів без добровільної згоди клієнта | Не скасовує журнали безпеки або стан окремих API-функцій |
store: false |
Вимикає збереження об’єкта відповіді для подальшого отримання та продовження через API | Сам по собі не вмикає Zero Data Retention і не прибирає стандартні журнали моніторингу |
| Zero Data Retention | Виключає контент із журналів моніторингу та вимикає стан у сумісних функціях | Не поширюється автоматично на несумісні API, зовнішні сервіси й власні логи клієнта |
Практичний висновок простий: store: false корисний для stateless-архітектури, але називати його повноцінним ZDR не можна. OpenAI окремо наголошує на цьому в документації для Programmatic Tool Calling.
Як працює Private Safety Processing
Старі системи безпеки часто оцінюють кожен запит окремо. Для сильніших моделей цього замало: нешкідливі на вигляд кроки можуть скластися в небезпечний сценарій лише після десятка взаємодій. Звідси й конфлікт. Системі потрібно бачити послідовність, а клієнт із ZDR не хоче віддавати провайдеру історію.
У попередньому описі Private Safety Processing OpenAI заявляє, що система аналізує пов’язані взаємодії та виявляє ризикові шаблони, не відкриваючи працівникам компанії промпти й відповіді. Обробка може відбуватися в інфраструктурі клієнта або над зашифрованими даними з ключами під контролем клієнта.
Поки це preview, а не готова універсальна послуга. OpenAI тестує підхід із першими замовниками та планує ширше розгортання разом із технічним документом у вересні 2026 року. До публікації документа варто сприймати Private Safety Processing як напрямок і архітектурну обіцянку, а не як уже сертифікований модуль із відомим переліком моделей, регіонів та стандартів відповідності.
Які функції OpenAI API сумісні із ZDR
Підтримка залежить не лише від моделі. Важливий увесь маршрут запиту: endpoint, увімкнені інструменти, файли, кеш і сторонні сервіси.
- Responses API та Chat Completions. Підтримують ZDR із застереженнями. У цьому режимі
storeпримусово вимкнений. - Embeddings, Moderations, Realtime та більшість аудіофункцій. Позначені в документації як придатні для ZDR.
- Генерація й редагування зображень. Сумісність залежить від моделі. Поточна документація називає GPT Image 2, GPT Image 1.5, GPT Image 1 та GPT Image 1 mini.
- Conversations, Assistants, Threads і Vector Stores. Зберігають стан, тому не придатні для повного ZDR.
- Files, Batches, fine-tuning та Evals. Потребують збереження даних для виконання своєї роботи й не вважаються ZDR-сумісними.
- Videos API. Записує дані під час обробки й зараз блокується для ZDR-проєктів.
Є й менш очевидні деталі. Background mode у Responses API записує стан приблизно на десять хвилин, щоб клієнт міг опитувати довге завдання. Prompt caching може тримати зашифровані внутрішні представлення на локальних GPU до завершення строку кешу. А дані, передані зовнішньому MCP-серверу, вже підпорядковуються політиці цього сервера, а не лише OpenAI.
Для reasoning-моделей stateless-робота не означає втрату всього контексту. OpenAI повертає зашифровані reasoning items, які клієнт може зберігати у себе й повторно надсилати в наступному запиті. Під час обробки вони розшифровуються в пам’яті, а новий стан знову повертається клієнту у зашифрованому вигляді. Докладний механізм описано в гайді Responses API.
Чи можна передавати конфіденційні документи в OpenAI API
ZDR суттєво зменшує ризик зберігання контенту на боці провайдера, але не закриває весь ланцюжок. Дані можуть залишитися у вашій CRM, проксі, системі аналітики, логах сервера, трасуванні агента або сервісі, який викликається через MCP. Найчастіше витік відбувається не всередині моделі, а в якомусь дуже балакучому журналі помилок.
Для медичних даних, фінансових документів і персональної інформації потрібні також договірні та організаційні гарантії: визначена правова підстава обробки, мінімізація даних, контроль доступу, шифрування, строки видалення, аудит і план реагування на інциденти. ZDR не замінює DPA, BAA чи вимоги GDPR. Він лише допомагає побудувати архітектуру, у якій постачальник моделі не накопичує зайвий контент.
Перед інтеграцією варто провести окрему інвентаризацію: що саме надсилається в модель, чи можна прибрати імена й номери документів, де зберігається історія, хто має ключі та що бачить технічна підтримка. Для агентів із доступом до сайтів додатково потрібен захист від prompt injection — про ризик витоку приватних даних через підключені інструменти OpenAI пише в гайді з безпеки агентів.
Як отримати Zero Data Retention і скільки це коштує
ZDR не вмикається для нового API-акаунта автоматично. Організація має звернутися до OpenAI, описати сценарій із чутливими даними, пройти перевірку та погодитися з додатковими вимогами. Після схвалення в налаштуваннях організації з’являється розділ Data Retention, де політику можна задати на рівні організації або окремого проєкту.
Окремої публічної ціни ZDR чи Private Safety Processing OpenAI не назвала. Виклики моделей оплачуються за звичайними тарифами API, а доступ, договірні умови та можливі корпоративні зобов’язання обговорюються з відділом продажів. Якщо хтось пропонує «увімкнути ZDR одним параметром у коді», це хороший момент попросити показати сторінку Data Retention у консолі та підтвердження для конкретного проєкту.
Для вибору моделі можна почати з нашого огляду GPT‑5.6 Sol, Terra і Luna, а для складних API-сценаріїв корисно подивитися, як Responses API використовують у наукових дослідженнях.
Що перевірити перед запуском
- Отримайте письмове підтвердження, що ZDR активований саме для потрібної API-організації та проєкту.
- Звірте endpoint, модель і кожен інструмент із актуальною таблицею сумісності.
- Вимкніть непотрібне збереження стану та перевірте поведінку довгих фонових задач.
- Перегляньте власні логи, трасування, резервні копії й аналітику: ZDR не чистить їх за вас.
- Перевірте політики зовнішніх MCP, хмарних сховищ і всіх сервісів у ланцюжку.
- Мінімізуйте дані до відправлення та відокремте ідентифікатори від робочого контексту.
- Додайте людське підтвердження для дій із грошима, медичними рішеннями, доступами та видаленням.
Zero Data Retention дає бізнесу сильнішу основу для роботи з конфіденційними даними, особливо коли звичайні 30-денні журнали неприйнятні. Найважливіше — не зупинятися на назві режиму. Реальний захист визначає весь маршрут даних: від форми користувача до останнього лога у вашій інфраструктурі.
