Zero Data Retention у OpenAI: что на самом деле не хранится

Свежий повод: безопасность пытаются вынести за пределы логов

19 августа 2026 года OpenAI сообщила о тестировании Private Safety Processing, или PSP, для frontier-моделей. Компания пытается решить конфликт, который особенно заметен в крупных организациях: не удерживать промпты и ответы заказчика после обработки, но при этом замечать опасные сценарии, которые проявляются только в длинной последовательности обращений.

Новость важна не потому, что OpenAI впервые говорит о конфиденциальности. Режим Zero Data Retention, ZDR, уже существовал для допущенных API-клиентов при отдельном одобрении. Новым стал заявленный safety-слой: OpenAI обещает анализировать связанные взаимодействия без открытия исходного содержания сотрудникам компании. Это раннее клиентское тестирование, а не общедоступный режим для всех API-проектов, ChatGPT Enterprise и государственных контуров.

В обычной модели модерации провайдеру проще проверять отдельный запрос и при необходимости сохранять его в журналах мониторинга злоупотреблений. Но рискованный сценарий может складываться из множества реплик, аккаунтов, инструментов и шагов агентной задачи. Именно эту проблему OpenAI связывает с PSP.

По описанию OpenAI, архитектура PSP разделяет роли. Контент остаётся в инфраструктуре под контролем клиента либо находится у OpenAI в зашифрованном виде с ключами под контролем клиента. Автоматизированные механизмы должны обнаруживать связанные паттерны, а OpenAI получать узкий сигнал о категории активности, а не текст промптов и ответов. Расследовать алерт предполагается преимущественно силами заказчика; релевантный фрагмент можно добровольно передать для апелляции или проверки подтверждённого злоупотребления.

Это существенная смена модели ответственности, но пока не доказанный результат. OpenAI сообщила о работе с ранними клиентами, намерении расширить развёртывание и выпустить технический white paper в сентябре 2026 года. Axios также описал PSP как preview-технологию для early customers. Публично пока нет криптографического описания схемы, модели угроз, измерений ложноположительных и ложноотрицательных срабатываний или процедуры независимого аудита.

• ZDR для eligible API customers существовал до анонса PSP и требует предварительного одобрения OpenAI.
• PSP находится на этапе раннего клиентского тестирования.
• Более широкий rollout и публикация white paper заявлены на сентябрь 2026 года.
• Нельзя утверждать, что PSP уже доступен всем пользователям API или автоматически действует в ChatGPT Enterprise.

Цитата в переводе

«Внедрение корпоративного ИИ полностью зависит от контроля заказчика над данными: без прямого или производного использования за пределами выбранного сервиса.»

Цитата в переводе

«OpenAI заявила в среду, что считает: новая техника позволит безопасно предоставлять бизнесу её наиболее продвинутые модели без необходимости хранить их данные.»

Что именно обещает Zero Data Retention

В наиболее строгой формулировке OpenAI говорит, что для допущенных API-клиентов не удерживает промпты и ответы после обработки запроса, а сотрудники компании не получают доступ к клиентскому содержимому для ревью. Отдельная корпоративная политика OpenAI закрепляет, что бизнес-данные по умолчанию не используются для обучения моделей; такое использование возможно при явном согласии клиента.

Техническая документация даёт более полезное для инженера определение. ZDR исключает Customer Content из abuse-monitoring logs, то есть журналов, используемых для мониторинга злоупотреблений. В стандартном API-режиме такие журналы могут включать промпты, ответы и производные метаданные, например результаты классификаторов, и по умолчанию храниться до 30 дней. При ZDR клиентский контент из этих журналов исключается.

Слово «по умолчанию» здесь критично. Срок до 30 дней характеризует стандартный режим, а не ZDR. Документация предусматривает исключения, если более длительное удержание требуется законом либо обоснованно необходимо для защиты сервиса или третьих лиц от вреда. Поэтому в договоре, DPIA и внутренней модели рисков нельзя писать, что данные удаляются всегда и без исключений.

Есть и второй слой: application state, или прикладное состояние. Это данные, которые конкретная функция временно либо постоянно хранит, чтобы вообще работать. ZDR не является свойством одной лишь модели. Итог зависит от endpoint’а, параметров запроса, выбранных инструментов и того, куда приложение отправляет данные после ответа модели.

• Корректная формула: ZDR ограничивает удержание корпоративного контента в совместимых сценариях.
• Некорректная формула: ZDR означает отсутствие любой обработки, телеметрии или идентифицирующих сведений.
• Проверять нужно не только название модели, но и весь data flow конкретного продукта.

Какие данные всё равно могут оставаться у сервиса

OpenAI отдельно выделяет System Data. В эту категорию входят сведения об аккаунте, данные профилей конечных пользователей, usage data, аналитика, биллинг, обращения в поддержку и схемы Structured Outputs. Это не Customer Content в терминологии документации. Следовательно, ZDR не превращает использование API в анонимный канал и не отменяет техническую и финансовую операционную информацию, необходимую для работы учётной записи.

Для службы информационной безопасности это означает, что инвентаризация не должна заканчиваться вопросом «сохраняются ли промпты». Нужны отдельные ответы по идентификаторам организации и проекта, IP- и сетевым данным, токенам и объёму потребления, журналам API gateway, данным наблюдаемости, платёжным записям, тикетам поддержки и логам собственных систем заказчика. Часть этих потоков находится не у OpenAI, а у самой компании или её подрядчиков.

Тот же принцип действует для data residency. Эта опция регулирует место хранения Customer Content, а в поддерживаемых сценариях и регионах может регулировать место inference, то есть выполнения вычислений модели. Но OpenAI указывает, что System Data может обрабатываться и храниться вне выбранного региона. Кроме того, regional storage и regional processing не равны друг другу: возможность хранить контент в регионе не всегда означает, что там же выполняется инференс.

В российском контексте отсюда следует узкий, но важный вывод. В опубликованном перечне API-регионов data residency Россия не названа. Поэтому из наличия ZDR нельзя выводить ни локализацию данных в России, ни обработку в российской юрисдикции. Конкретный сценарий требует отдельной юридической проверки трансграничных потоков, договора и состава обрабатываемых персональных данных.

• ZDR не отменяет биллинг, данные аккаунта и usage analytics.
• Data residency не равна ZDR, а regional storage не всегда равен regional processing.
• Логи приложения, SIEM, DLP и прокси заказчика остаются его собственной зоной ответственности.

Endpoint и функция важнее маркетинговой формулы

Самый частый риск корпоративного внедрения появляется после успешного пилота. Команда убеждается, что базовый вызов модели соответствует ZDR, а затем добавляет фоновые задания, состояние диалога, аудио, векторное хранилище или внешний инструмент. В этот момент исходная гарантия может перестать применяться либо стать недостаточной для всего потока данных.

Например, для /v1/responses в обычной конфигурации ответы могут храниться не менее 30 дней, если установлен параметр store=true. В режиме ZDR этот параметр принудительно трактуется как false. Однако background mode удерживает данные примерно 10 минут, чтобы клиент мог опрашивать статус задачи, и поэтому несовместим с ZDR. Для аудиовыходов документация указывает хранение состояния до одного часа для многоходового разговора.

Отдельный случай: prompt caching. Для ускорения повторяющихся обращений OpenAI может временно хранить зашифрованные key/value tensors, то есть промежуточные представления контекста, в локальном GPU-хранилище. Для такого application state указан предел до 24 часов. Это не то же самое, что постоянная запись исходного текста промпта, но для комплаенса важны установленный режим хранения и доступы, а не удобная бытовая аналогия.

Assistants API, threads и vector stores без удаления способны храниться бессрочно; в матрице endpoint’ов они обозначены как не совместимые с ZDR. Наконец, когда приложение отправляет данные на удалённый MCP-сервер или другую стороннюю сетевую службу, условия хранения определяет эта третья сторона. ZDR OpenAI не распространяется по цепочке автоматически.

• В Responses API для ZDR следует подтвердить фактическое значение store=false.
• Background mode нельзя считать ZDR-совместимым.
• Prompt caching, audio state, threads, vector stores и внешние MCP-инструменты нужно включать в отдельную матрицу рисков.
• Фраза «мы используем ZDR» без перечня endpoint’ов и функций не годится для аудита.

Исключения: почему «сотрудники не читают» не равно «система ничего не видит»

OpenAI описывает исключение для потенциального контента сексуальной эксплуатации детей, CSAM. Загруженные изображения и файлы сканируются классификаторами; если материал отмечен как потенциальный CSAM, изображение может быть удержано для ручной проверки даже при ZDR, Modified Abuse Monitoring или Eyes Off. В анонсе компания связывает это с обязанностью сообщать о выявленном контенте такого типа.

Это не малозначимая юридическая сноска. Для регулируемой организации исключение должно быть отражено в схеме потоков данных, документации по оценке воздействия на защиту данных и процедуре реагирования на инциденты. Нужно заранее определить, кто внутри компании получает уведомление, как ограничивается доступ к материалам, что фиксируется в журнале и какие договорные обязательства действуют в таком случае.

С PSP возникает ещё одно различие, важное для точного языка. Компания не заявляет, что OpenAI вообще не обрабатывает содержание на машинном уровне. Напротив, автоматизированная система должна анализировать связанные взаимодействия, чтобы сформировать safety-signal. Заявление касается отсутствия доступа персонала к исходным промптам и ответам, а также модели хранения и управления ключами. Описывать PSP как технологию, при которой поставщик не видит данные вообще, было бы сильнее подтверждённых фактов.

• Исключение для потенциального CSAM действует даже при режимах с особыми настройками удержания.
• Отсутствие доступа человека к исходному контенту не исключает автоматизированной обработки.
• Эффективность PSP и состав его safety-signal пока не подтверждены публичными техническими измерениями.

ChatGPT Enterprise и API: нельзя переносить обещания механически

Анонс OpenAI сформулирован для eligible API customers. Из этого не следует, что у ChatGPT Enterprise действует тот же режим и те же ограничения. В HIPAA Implementation and Configuration Guide указано, что контент ChatGPT Enterprise хранится в течение срока действия соглашения, если клиент не удалил его раньше или не выбрал сокращённый срок хранения.

Для медицинских организаций путаница особенно рискованна. Руководство OpenAI указывает, что работа с PHI, защищённой медицинской информацией, через API требует BAA, то есть соглашения об обработке такой информации, и активации Modified Retention для нужных Org ID и проекта. Modified Retention включает ZDR, Modified Abuse Monitoring, Safety Retention и Eyes Off. Сам по себе выбор ZDR не заменяет BAA, техническую конфигурацию проекта и собственные меры контроля доступа.

Есть и функциональные границы. Live Web Search в Responses API не относится к HIPAA-eligible возможностям и не покрывается BAA; документация отдельно описывает исключение для offline/cache-only режима в ZDR-проекте. Поэтому применимость к регулируемому процессу определяется не общим названием платформы, а точной комбинацией проекта, endpoint’а, инструмента и режима работы.

Эта дисциплина нужна не только здравоохранению. Финансовая организация, страховая компания или госсектор обычно должны одновременно минимизировать внешнее хранение чувствительного контента, расследовать нарушения, контролировать географию обработки и предоставлять аудиторам воспроизводимые доказательства настроек. ZDR уменьшает один класс рисков, но не является готовым сертификатом соответствия отраслевым нормам.

• Проверяйте ChatGPT Enterprise и API как разные продуктовые контуры с разными правилами retention.
• Для PHI необходимы BAA и корректная настройка Modified Retention, а не только декларация о ZDR.
• Использование внешнего поиска и других инструментов нужно оценивать отдельно от базового вызова модели.

Почему спор о ZDR стал отраслевым, а не только продуктовым

В основе дискуссии лежит реальный компромисс. Чем меньше провайдер хранит исходного контента, тем сложнее ему проводить ретроспективные расследования и улучшать выявление злоупотреблений на фактических примерах. Чем больше контента доступно для мониторинга, тем выше барьер для компаний, которые не могут допустить его штатное удержание у внешнего поставщика.

Anthropic в обновлениях Responsible Scaling Policy также признаёт, что всеобщий ZDR может ухудшать обнаружение злоупотреблений и обучение на основании реального использования. Одновременно его коммерческая политика предусматривает стандартное удаление входов и выходов в пределах 30 дней, если стороны не согласовали другой режим, включая ZDR. Это не доказывает превосходство одного поставщика над другим, но показывает: выбор между приватностью, наблюдаемостью и safety перестал быть второстепенной настройкой API.

Подход OpenAI интересен попыткой разделить содержимое и сигнал о риске. Если PSP подтвердит заявленные свойства, компания сможет предложить заказчику более строгий контроль над текстом запросов, не отказываясь полностью от межсессионной безопасности. Пока это гипотеза продукта, которую следует проверять по будущему white paper, условиям пилота и результатам независимой оценки.

• Отраслевой конфликт не сводится к вопросу «приватность или безопасность». Важны место хранения доказательств, доступ к контенту и порядок расследования инцидента.
• PSP следует оценивать как заявленный способ перераспределить эти функции, а не как уже доказанный универсальный ответ.

Что запросить до запуска: чек-лист для CIO, CISO и закупок

Корпоративной команде не стоит принимать ZDR как абстрактное свойство поставщика. Нужна письменная привязка режима к конкретным идентификаторам организации и проекта, техническая матрица вызовов и проверяемая конфигурация. Особенно важно сделать это до того, как пилот начнёт обрастать агентами, RAG-поиском, внешними инструментами и системами наблюдаемости.

Архитектурно полезно разделить четыре вопроса: удерживается ли Customer Content; создаётся ли application state; какие System Data остаются; куда данные уходят за периметром OpenAI. Такая схема снимает ложную альтернативу между «данные полностью исчезают» и «провайдер хранит всё»: в реальной системе одновременно работают несколько режимов и владельцев журналов.

Для PSP-пилота до появления white paper имеет смысл требовать документированное описание модели угроз, перечня safety-signals, порядка управления ключами, сроков хранения сигналов, метрик ошибок и процедуры обжалования. Если поставщик не может дать ответ, риск нельзя закрыть формулировкой «private».

Подтверждение и конфигурация

Проверьте, что режим ZDR письменно подтверждён для конкретных Org ID и Projects, а не заявлен только на общей странице документации.

• Составьте матрицу model × endpoint × tool × retention.
• Подтвердите store=false в Responses API и запретите несовместимые сценарии там, где ZDR обязателен.
• Включите в матрицу background mode, audio, caching, threads, vector stores и внешние MCP-серверы.

Контуры данных и исключения

Зафиксируйте состав System Data и логи, которые остаются в API gateway, observability-платформе, SIEM, DLP и службе поддержки.

• Для PHI подтвердите BAA, статус endpoint’ов и настройки Modified Retention.
• Не распространяйте выводы на live Web Search без отдельной проверки.
• Отдельно документируйте data residency, регион inference и трансграничные потоки.
• Проверьте процесс обработки исключений, включая потенциальный CSAM, legal hold и взаимодействие при инциденте.

Вывод

Zero Data Retention у OpenAI стоит воспринимать не как обещание исчезновения данных, а как более узкий и практически ценный контроль. В совместимых API-сценариях поставщик не должен штатно удерживать корпоративный контент после обработки и использовать его в abuse-monitoring logs.

Для компаний, работающих с чувствительными данными, этого достаточно, чтобы пересмотреть часть архитектурных решений. Но ZDR не отменяет System Data, application state, исключения для потенциального CSAM, внешние инструменты, логи самого заказчика и требования к региону обработки.

Объявление OpenAI задаёт не новую универсальную норму конфиденциальности, а новую планку зрелости закупок. Вопрос к поставщику должен звучать не «есть ли у вас zero retention?», а «для каких потоков, на каких условиях, с какими исключениями и какими проверяемыми доказательствами?».

Источники

• OpenAI News: Offering Zero Data Retention for frontier models
• Axios: OpenAI previews zero-retention safety system as Anthropic requires data logs
• OpenAI Platform: Default usage policies by endpoint
• OpenAI: HIPAA endpoints
• OpenAI: Business data
• Anthropic: Responsible Scaling Policy updates

Частые вопросы

Что означает Zero Data Retention у OpenAI?

В совместимых и одобренных API-сценариях ZDR исключает Customer Content, включая промпты и ответы, из журналов мониторинга злоупотреблений. Это не означает отсутствия всех остальных данных и процессов.

Можно ли считать ZDR свойством модели OpenAI?

Нет. Режим зависит от конфигурации проекта, endpoint’а, параметров запроса, подключённых инструментов и внешних интеграций.

Какие данные могут оставаться при ZDR?

System Data: сведения об аккаунте, usage data, аналитика, биллинг, обращения в поддержку и другие служебные данные. Также отдельные функции могут создавать application state.

Совместим ли background mode с ZDR?

Нет. По документации OpenAI, background mode временно удерживает данные для опроса статуса задачи и потому несовместим с ZDR.

Распространяется ли анонс PSP автоматически на ChatGPT Enterprise?

Нет. Анонс сформулирован для eligible API customers. Правила хранения и договорные условия ChatGPT Enterprise необходимо проверять отдельно.

Что нужно проверить перед запуском ZDR в регулируемой организации?

Нужно подтвердить режим для конкретных Org ID и Projects, составить матрицу endpoint’ов и инструментов, описать System Data и собственные логи, а для PHI дополнительно подтвердить BAA и настройки Modified Retention.

Практический чек-лист

Чек-лист проверки Zero Data Retention

Сохраните памятку для технической и закупочной проверки конфигурации. PDF должен повторять пункты чек-листа из статьи и не содержать редакционных комментариев.

Подтверждение режима

• Получить письменное подтверждение ZDR для конкретных Org ID и Projects.
• Проверить, что в Responses API фактически действует store=false.
• Составить матрицу model × endpoint × tool × retention.
• Исключить background mode из сценариев, где ZDR обязателен.

Потоки и хранение данных

• Отдельно учесть prompt caching, audio state, threads и vector stores.
• Зафиксировать состав System Data: аккаунтные сведения, usage data, аналитику, биллинг и обращения в поддержку.
• Описать логи в API gateway, observability-платформе, SIEM, DLP и службе поддержки.
• Проверить, куда данные передаются внешним MCP-серверам и другим сторонним службам.

Регулируемые сценарии

• Для PHI подтвердить BAA, статус endpoint’ов и настройки Modified Retention.
• Не распространять выводы на live Web Search без отдельной проверки.
• Документировать data residency, регион inference и трансграничные потоки.
• Подготовить процесс обработки исключений, включая потенциальный CSAM, legal hold и инциденты.