OpenAI расширила Zero Data Retention для frontier-моделей: что меняется
19 августа OpenAI опубликовала материал Offering Zero Data Retention for frontier models. Компания уточнила, что для подходящих клиентов API режим Zero Data Retention (ZDR) означает: промпты и ответы не сохраняются после обработки запроса, а содержимое клиента недоступно сотрудникам OpenAI для ручного просмотра. Это важное обновление для организаций, работающих с медицинскими, финансовыми, исследовательскими и коммерческими данными, но оно не решает все проблемы приватности автоматически.
Что такое ZDR
ZDR — договорный и технический режим для определённых API-сценариев. Он ограничивает хранение содержимого на стороне OpenAI после выполнения запроса. Во время обработки данные всё равно проходят через инфраструктуру, поэтому клиент должен ограничить доступ к ключам, проверить endpoint-ы и самостоятельно контролировать логи, трассировки, прокси и резервные копии.
Не смешивайте отсутствие хранения содержимого, отсутствие обучения на данных и полное отсутствие технических метаданных. Это разные свойства. Перед подключением запросите актуальный список совместимых моделей, endpoint-ов и функций: отдельные инструменты могут иметь собственные требования к хранению и аудиту.
Что такое Private Safety Processing
OpenAI представила предварительный подход Private Safety Processing. Компания хочет находить опасные шаблоны между связанными взаимодействиями, не открывая исходный контент сотрудникам. Это должно исправить ограничение оценки каждого запроса по отдельности: система сможет видеть повторяющиеся попытки злоупотребления.
На момент публикации это preview. OpenAI планирует раскрыть технические детали и white paper позже, поэтому функцию нельзя считать готовой сертифицированной заменой собственной системе мониторинга. DLP, журналирование событий и реагирование на инциденты остаются обязанностью клиента.
Кому это полезно
Режим особенно важен для приложений, которые отправляют исходный код, договоры, финансовые записи, медицинские сведения или закрытые исследования. Но сначала проверьте законность передачи данных, регион обработки и основание доступа. Если продукт отправляет в модель больше данных, чем нужно, ZDR не исправит архитектурную ошибку.
Чек-лист перед включением
- Составьте карту данных: какие поля уходят в API и зачем.
- Удалите идентификаторы, токены и поля, не влияющие на ответ.
- Проверьте договор, совместимые модели и endpoint-ы.
- Отдельно настройте срок хранения собственных логов и backup-копий.
- Ограничьте API-ключи по проектам, ролям, IP и бюджету.
- Проведите тест на утечки через ошибки, трассировки и сторонние SDK.
- Зафиксируйте процедуру удаления и аварийного отключения интеграции.
Частые ошибки
Самая частая ошибка — включить ZDR, но оставить промпты в логах приложения. Вторая — отправлять документ целиком, хотя для ответа достаточно нескольких фрагментов. Третья — забыть о подрядчиках: системы аналитики, мониторинга и поддержки могут сохранять запросы независимо от провайдера модели.
FAQ
ZDR означает, что данные нигде не сохраняются?
Нет. Режим касается хранения на стороне OpenAI в рамках подходящей конфигурации. Ваше приложение, прокси, логи и резервные копии требуют отдельной проверки.
Это сертификация безопасности?
Нет. ZDR контролирует хранение, но не подтверждает правильность ответа модели и не заменяет аудит всего процесса обработки данных.
Нужно ли обезличивать запросы?
Да. Минимизация данных снижает последствия ошибки, утечки ключа или неправильной настройки собственной инфраструктуры.
Как проверить, что ZDR действительно включён
Начните с договора и списка совместимых endpoint-ов, а не с переключателя в панели. Зафиксируйте идентификатор проекта, дату активации, версии SDK и исключения для файлов, потоков и инструментальных вызовов. Затем отправьте тестовый запрос с уникальным маркером и проверьте все места, где он может появиться: приложение, прокси, трассировку, систему аналитики и резервную копию. Отсутствие строки в одном логе не доказывает, что она нигде не сохранилась.
Проверьте сценарий ошибки. Намеренно отправьте неверный параметр и убедитесь, что диагностическое сообщение не содержит полный промпт или документ. Отдельно протестируйте тайм-аут и повторный вызов: SDK может записать тело запроса до того, как провайдер применит политику ZDR. Результаты сохраняйте в журнале тестов, не используя настоящие персональные данные.
Что остаётся у клиента
Zero Data Retention не удаляет собственную ответственность за минимизацию. Ваш сервис по-прежнему может хранить промпт в access-логе, менеджер ошибок — прикреплять снимок экрана, а подрядчик поддержки — видеть историю чата. Составьте карту потоков данных и укажите владельца каждого журнала. Для резервных копий задайте срок удаления, шифрование и процедуру восстановления без возврата устаревших файлов.
Private Safety Processing следует оценивать отдельно. Если функция находится в preview, запросите описание того, какие сигналы собираются, как долго хранятся и кто имеет доступ к агрегированной информации. Нельзя заменять DLP, контроль ключей и реагирование на инциденты обещанием «приватной проверки».
Как подготовить корпоративный пилот
Выберите один процесс и обезличьте двадцать-тридцать примеров. Сначала проверьте, что ответ можно получить без лишних полей, затем включите ZDR и сравните задержку, ошибки и поведение SDK. После этого попросите независимого коллегу пройти путь от запроса до удаления и отметить все места, где мог остаться текст. Если один компонент нельзя проверить или отключить, пилот не готов к рабочим данным.
Закрепите роли: владелец данных утверждает поля, инженер отвечает за конфигурацию, безопасность проверяет логи, а руководитель принимает решение о допуске. При смене модели, региона или посредника повторяйте тест — одинаковое название endpoint-а не гарантирует одинаковый режим хранения.
Для команды, которая использует закрытые документы, полезно иметь резервный локальный маршрут и процедуру аварийного отключения. Сравнить подходы к локальному и облачному запуску можно в нашем разборе, а актуальные модели — в каталоге.