Private Safety Processing від OpenAI: як працює виявлення зловживань без доступу до контенту клієнтів

OpenAI тестує Private Safety Processing — архітектуру безпеки для окремих клієнтів API, які користуються режимом Zero Data Retention (ZDR). Її головна ідея проста: знаходити ознаки зловживань, помітні лише у сукупності кількох пов’язаних взаємодій, але не надавати співробітникам OpenAI доступу до самого контенту клієнта за замовчуванням.

Це важливо, оскільки дедалі потужніші моделі використовуються у тривалих і розподілених робочих процесах. Небезпечну мету можна розбити між різними обліковими записами, сесіями або запитами — так, щоб жодна окрема взаємодія не показувала повної картини. Private Safety Processing має додати цей ширший контекст, не скасовуючи захист ZDR.

Як працює Private Safety Processing

Наявні механізми ZDR оцінюють запити й відповіді окремо. У тестовій версії OpenAI розширює цей підхід: автоматизовані системи аналізують зв’язки між кількома взаємодіями. Мета — виявляти закономірності, пов’язані з потенційним зловживанням, зокрема скоординовані спроби обійти захисні обмеження або розподілити завдання зі створення шкідливого програмного забезпечення між різними запитами.

Ключова відмінність — між аналізом і зберіганням. Private Safety Processing призначена для аналізу пов’язаної активності з міркувань безпеки, однак OpenAI заявляє, що система не відкриває її співробітникам вихідні запити та відповіді моделей.

OpenAI описує два можливі варіанти контролю даних у розгортаннях із ZDR:

• контент клієнта може залишатися на інфраструктурі, яку контролює сам клієнт;
• якщо дані зберігаються на інфраструктурі OpenAI, вони можуть бути зашифровані ключами, контрольованими клієнтом, а не співробітниками OpenAI.

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

Що саме отримує OpenAI у разі загрози

Згідно з описом тестової версії, OpenAI отримує вузько визначене сповіщення про тип активності. На схемі системи цей результат описаний як категорія та рівень серйозності сповіщення, а не як сама розмова.

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

1. Автоматизовані системи аналізують пов’язані взаємодії на предмет потенційно небезпечної закономірності.
2. Якщо закономірність перевищує встановлений поріг ризику, система формує обмежену класифікацію безпеки.
3. OpenAI отримує цю класифікацію, а не запити, відповіді чи стенограму розмови.
4. Клієнт зберігає можливість дослідити відповідну активність у власному середовищі.

Це все ще тестова версія, тому для корпоративних клієнтів матимуть значення точна реалізація, пороги спрацьовування та процедури роботи з помилковими сигналами. OpenAI заявила, що планує ширше розгортання і технічний опис системи у вересні 2026 року.

Чому співробітники OpenAI зазвичай не бачать позначену розмову

Сам факт спрацьовування системи не надає співробітникам OpenAI автоматичного доступу до розмови. За описаними умовами ZDR компанія не зберігає контент клієнта, а у варіанті зі зберіганням на інфраструктурі OpenAI не володіє ключами розшифрування, контрольованими клієнтом.

Клієнти можуть самостійно перевірити відповідну активність і, за бажання, передати матеріали для оскарження обмеження, пояснення легітимного використання або розслідування підтвердженого зловживання. Без такого добровільного розкриття саме сповіщення містить лише машинно сформовану інформацію про безпеку й не відкриває OpenAI доступу до розмови.

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

Хто тестує систему

OpenAI назвала Glean, Databricks, Abridge і Microsoft серед клієнтів, які допомагають розробляти або тестувати попередню версію. Інші публікації також називають Microsoft і Databricks ранніми клієнтами, залученими до тестування.

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

OpenAI та Anthropic: різні компроміси у сфері безпеки

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

У документації Anthropic зазначено, що вимога стосується таких моделей, як моделі класу Mythos, і що вони недоступні в режимі ZDR. Водночас збережені дані не використовуються для навчання моделей без чіткого дозволу клієнта.

Операційна різниця виглядає так:

• Private Safety Processing від OpenAI: автоматизований аналіз пов’язаних взаємодій; за описом тестової версії, OpenAI отримує обмежений сигнал безпеки, а не сам контент.
• Політика Anthropic для відповідних моделей: запити й відповіді зберігаються 30 днів, щоб підтримувати роботу з безпекою та контрольовану перевірку.

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

Чому це важливо для регульованих компаній

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

Це не означає, що 30-денне зберігання автоматично заборонене, або що одного лише ZDR достатньо для відповідності вимогам. Різниця полягає в наборі запитань, які доведеться поставити командам безпеки та юристам. Умови Anthropic для відповідних моделей вимагають враховувати зберігання і перевірку даних постачальником, тоді як OpenAI позиціонує ZDR і Private Safety Processing як спосіб обмежити доступ постачальника саме до контенту.

Для корпоративного клієнта особливо важливі такі питання:

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

Ширше значення для продукту

Private Safety Processing перетворює приватність на частину самого продукту безпеки ШІ. Тепер питання полягає не лише в тому, чи здатна модель заблокувати небезпечний запит. Не менш важливо, чи може постачальник виявити скоординоване зловживання у тривалому робочому процесі, не отримуючи доступу до кожної розмови клієнта.

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

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

Вибір між цими моделями залежатиме від допустимого для клієнта рівня ризику, чутливості робочих процесів і того, наскільки широкої видимості для розслідувань він очікує від постачальника передових моделей. Обіцяні OpenAI технічний опис і ширше розгортання мають дати змогу перевірити, як заявлені гарантії приватності працюватимуть у реальних системах.