OpenAI разложила хранение API-данных по срокам. Что это меняет для интеграций

Что именно зафиксировала OpenAI

OpenAI актуализировала документацию Platform о хранении данных в API. На первый взгляд это справочная правка для разработчиков. На практике документ нужно читать вместе engineering-, security-, legal- и product-командам: от него зависит, какие endpoint’ы подходят для чувствительных сценариев, где появляется состояние, сколько живут журналы abuse monitoring и почему Zero Data Retention не означает, что ничего не хранится.

Поводом стал материал OpenAI Platform о data retention, появившийся в новостном контуре 30 июля 2026 года. Корректнее говорить не о громком анонсе, а об эксплуатационной спецификации: документация раскладывает режимы хранения для Responses, Chat Completions, Assistants и Threads, Files, Batches, Videos, аудио, изображений, prompt caching, MCP-коннекторов, audit logs и data residency.

Главный вывод: «30 дней» нельзя считать универсальным ответом на вопрос о retention. У OpenAI есть как минимум два слоя хранения. Первый: abuse monitoring logs, журналы для безопасности и контроля нарушений. По умолчанию они могут содержать customer content и хранятся до 30 дней. Второй: application state, рабочие данные, без которых не работают stateful-функции: треды, файлы, vector stores, background jobs, stored responses и другие объекты платформы.

Документация OpenAI Platform описывает data retention по endpoint’ам и инструментам API: какие данные используются для abuse monitoring, какие сохраняются как application state, какие endpoint’ы совместимы с Zero Data Retention и где ZDR не применяется либо меняет поведение функции.

OpenAI Platform уже трудно описывать как простой вызов «отправил prompt, получил completion». В платформе есть ассистенты, файлы, векторные хранилища, фоновые задачи, инструменты поиска, видео, аудио и коннекторы к внешним системам. Каждый компонент добавляет свой маршрут данных и собственный срок жизни объекта.

Часть настроек остаётся gated. Zero Data Retention и Modified Abuse Monitoring требуют eligibility, approval со стороны OpenAI и выполнения дополнительных условий. После одобрения настройки доступны в Data controls на уровне организации и проекта. Поэтому нужно различать описанный режим и фактическую доступность: режим может быть в документации, но не быть включённым у конкретного клиента.

Для зрелых корпоративных внедрений такая таблица полезнее общей формулы «данные не используются для обучения». Комплаенс ломается не только на training. Он ломается на логах, временных файлах, кэше, trace’ах, внешних инструментах, забытых объектах и исключениях, которые не видны из продуктовой презентации.

Retention надо читать как матрицу, а не как один срок

Ключевое различие проходит между abuse monitoring logs и application state. Abuse monitoring logs нужны платформе для выявления нарушений, расследования злоупотреблений и защиты сервиса. По умолчанию они могут включать prompts, responses и производные метаданные, если это применимо к конкретному endpoint’у. В документации указан срок до 30 дней, кроме случаев, связанных с правовыми или security-исключениями.

Application state устроен иначе. Это не журнал безопасности, а рабочее состояние продукта: сохранённый response, тред в Assistants API, загруженный файл, vector store, batch job, контейнер, видео-результат или другой объект, к которому пользователь или приложение рассчитывает обратиться позже. Такой state живёт по правилам конкретного endpoint’а: иногда до явного удаления, иногда до истечения expires_after, иногда только короткий период для polling, иногда вообще несовместим с ZDR.

Для разработчика меняется сам практический вопрос. Недостаточно спросить: «OpenAI хранит данные или нет?» Нужно понять, какой endpoint вызывается, создаёт ли он объект, можно ли его удалить, как долго он остаётся после deletion, действует ли ZDR, не включён ли store, есть ли background mode и не подключён ли внешний tool. Только такая детализация связывает архитектуру с юридической политикой.

• Abuse monitoring logs: слой безопасности и контроля нарушений, по умолчанию до 30 дней.
• Application state: рабочие данные функции, срок зависит от endpoint’а и объекта.
• ZDR влияет на customer content в abuse monitoring, но не превращает все stateful-функции в stateless.
• Юридическая политика должна быть связана с технической inventory по endpoint’ам.

Chat Completions, Responses и ловушка stateless-подхода

Многие команды всё ещё мыслят API OpenAI через старую модель: отправили запрос в Chat Completions, получили ответ, на стороне OpenAI ничего прикладного не осталось, кроме возможных служебных логов. Для части сценариев такая логика близка к реальности: классический /v1/chat/completions не создаёт application state в том же смысле, в каком его создают треды, файлы или сохранённые responses. Но слой abuse monitoring по умолчанию всё равно остаётся, а режимы с аудио, изображениями, файлами или prompt caching требуют отдельной проверки.

Responses API сложнее. Он может работать и в stateless-, и в stateful-режимах. В документации указано, что application state для Responses по умолчанию может храниться 30 дней или появляться при использовании store=true. В background mode данные могут сохраняться на диск примерно 10 минут для polling. Это не означает, что каждый вызов Responses становится долгоживущим объектом. Но привычку «API не хранит state» нельзя переносить автоматически.

Для ZDR-проектов есть отдельная деталь. В режиме Zero Data Retention параметр store для Responses и Chat Completions трактуется как false. С точки зрения приватности это ожидаемо. С точки зрения продукта это может сломать сценарий, если приложение рассчитывало на stored responses или последующее получение сохранённых объектов. ZDR здесь ограничивает хранение и одновременно меняет контракт использования отдельных возможностей.

ZDR и MAM: что они дают и чего не дают

Zero Data Retention часто воспринимают как универсальный режим «OpenAI ничего не хранит». Это неточная формулировка. По документации Platform, ZDR исключает customer content из abuse monitoring logs для поддерживаемых endpoint’ов и после одобрения может настраиваться на уровне организации или проекта. Modified Abuse Monitoring, или MAM, тоже меняет режим мониторинга, но не равен отказу от всех видов хранения. Оба режима доступны не всем клиентам API по умолчанию и требуют approval.

Граница проходит по совместимости. Если endpoint или hosted tool требует persistent state, он может быть недоступен в ZDR-режиме или работать с ограничениями. Это особенно существенно для Assistants, Threads, Files, Vector Stores, Batches, Videos, отдельных image- и audio-сценариев, а также интеграций с внешними инструментами. В таблице OpenAI есть endpoint’ы, которые помечены как неподходящие для ZDR, и функции, где ZDR меняет параметры хранения.

Чем детальнее таблица, тем сложнее внедрение. Команде нужен один переключатель privacy и один текст для договора. Но генеративная платформа стала набором разных сервисов, а не одним stateless inference endpoint. Единый переключатель не может честно описать файлы, треды, кэш, видео, аудио и внешние коннекторы одновременно. Для enterprise-команд это неудобно, зато риск становится видимым до запуска, а не после инцидента.

• ZDR не является self-service для всех клиентов API.
• ZDR отключает хранение customer content в abuse monitoring logs только в поддерживаемых сценариях.
• Stateful-функции могут сохранять application state или быть несовместимыми с ZDR.
• Режим нужно проверять на уровне проекта и endpoint’а, а не всей организации в целом.

Файлы, треды, vector stores и видео: где возникают забытые данные

Самая рискованная зона для эксплуатации: объекты, которые живут дольше одного API-вызова. Assistants, Threads и Vector Stores удобны тем, что сохраняют контекст и артефакты между шагами. За это удобство платят retention-риском: не удалённые объекты могут сохраняться до удаления, а после deletion серверная очистка занимает отдельный срок. В документации OpenAI для ряда объектов указано удаление с серверов через 30 дней после deletion. Поэтому delete в API нельзя описывать пользователям как мгновенное физическое исчезновение во всех внутренних системах.

Files требуют собственной политики. Загруженные файлы могут жить до удаления или до срабатывания expires_after, если такой механизм используется. В корпоративном приложении это нельзя оставлять на дисциплину пользователя. Нужны автоматический срок жизни, регламент удаления и инвентаризация: какие файлы попадают в OpenAI, какие копируются в собственное хранилище, какие отправляются в vector store, какие остаются в observability-логах.

Videos API показывает, почему один retention-переключатель не покрывает все продукты. В документации для видео описан отдельный workflow: данные сохраняются на диск для скачивания результата в течение 48 часов, а abuse monitoring может добавлять свой срок до 30 дней. Для MAM/ZDR-запросов у Videos API также указаны ограничения. Это не ошибка приватности, а следствие того, что генерация и выдача видео технически требуют другой инфраструктуры, чем текстовый stateless inference.

Практический вывод: долгоживущие объекты надо вынести в отдельный реестр. В нём должны быть владелец, цель, TTL, способ удаления, совместимость с ZDR/MAM, наличие чувствительных данных, привязка к проекту OpenAI и зеркальные копии в системах клиента. Без такого реестра риск проявится не в день запуска, а через месяцы, когда в production останутся старые треды, файлы и embeddings, о которых уже никто не помнит.

Prompt caching, аудио и изображения: временное хранение тоже считается

Prompt caching обычно рассматривают как функцию производительности: повторяющиеся части prompt’а кэшируются, чтобы ускорить работу и снизить стоимость. В retention-дизайне это отдельный объект внимания. В документации описаны encrypted key/value tensors в GPU-local storage, которые не сохраняются после 24-hour expiration. Это не training и не классический лог, но всё равно временное состояние. Если компания обрабатывает чувствительные данные, его нужно отразить в архитектурной схеме.

С аудио ситуация похожая. Для multi-turn voice-сценариев OpenAI может хранить audio outputs как application state в течение одного часа. Это короткий срок по сравнению с тредами или файлами, но для regulated-сценариев важен сам факт временного хранения. Формулировка «данные не используются для обучения» не отвечает на вопрос, где и сколько живёт аудио между ходами диалога.

Изображения добавляют слой исключений, связанных с safety-процессами. В документации отдельно описаны случаи, когда flagged content или files могут обрабатываться иначе. Поэтому privacy-дизайн должен учитывать не только обычный путь запроса, но и safety-path: что происходит, если контент попадает в категорию высокого риска или требует дополнительной проверки. Это часть threat modeling для генеративного ИИ, а не факультативное примечание.

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

«Мы не обучаемся на ваших бизнес-данных по умолчанию.»

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

«OpenAI не использует данные, отправленные клиентами через наш API, для обучения моделей OpenAI или улучшения предложения сервисов OpenAI, если вы явно не решите поделиться с нами своими данными для этой цели.»

Training и retention: почему это разные вопросы

OpenAI отдельно заявляет, что business products, включая API Platform, по умолчанию не используются для обучения моделей на inputs и outputs клиентов. В политике API data usage указано, что данные, отправленные через API, не используются для training или улучшения сервисов OpenAI, если клиент явно не решит поделиться ими для этой цели. Для enterprise-сценариев это значимая гарантия.

Но её нельзя переоценивать. Training и retention отвечают на разные вопросы. Training: использует ли поставщик ваши данные для дообучения или улучшения моделей. Retention: где эти данные временно или постоянно хранятся для безопасности, работы функции, аудита, восстановления, расследований, выполнения закона или предоставления результата пользователю. Данные могут не попадать в обучение и при этом сохраняться до 30 дней в abuse monitoring logs, лежать как файл до удаления или жить в vector store, пока его не очистят.

Для комплаенса это принципиально. Если в DPIA, vendor assessment или internal AI policy написано только «поставщик не обучается на наших данных», документ неполный. Нужно добавить: какие данные уходят в OpenAI, какие endpoint’ы используются, какой режим retention включён, кто имеет право включать store=true, где включён expires_after, как удаляются объекты, куда экспортируются audit logs и какие внешние tools получают данные.

Для российских команд этот разрыв прикладной из-за устройства внутренних согласований. В одном обсуждении обычно участвуют разработчики, ИБ, юристы, владелец продукта и закупки; каждый слышит слово «хранение» по-своему. Матрица retention помогает перевести спор из общего вопроса «можно ли использовать OpenAI» в проверяемый список: какие endpoint’ы включены, какие данные туда уходят, где они живут и кто отвечает за удаление в клиентской системе.

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

«Клиент несёт ответственность за свои конфигурации и проектные решения.»

Audit logs и DPA: ответственность не заканчивается на настройке OpenAI

Отдельный слой: API audit logs. Это административные и конфигурационные метаданные: ключи API, пользователи, проекты, service accounts, настройки организации и события управления. Они не являются customer content в том же смысле, что prompt или response. Поэтому ZDR не меняет их availability, retention behavior или состав событий. В справке OpenAI также указано, что фиксированный TTL для audit logs не гарантируется, а постоянная доступность предоставляется best effort.

Для security-команды вывод прямой: audit logs надо выгружать в собственный SIEM, GRC или другое контролируемое хранилище. Нельзя строить расследования, eDiscovery или отчётность на предположении, что OpenAI будет бесконечно хранить журналы администрирования. При этом хранить их у себя тоже нужно с политикой доступа и сроков: admin metadata может раскрывать структуру проектов, ключей и пользователей.

Data Processing Addendum OpenAI закрепляет ещё одну практическую границу: часть ответственности за конфигурации, design decisions, deletion и retention periods лежит на клиенте в рамках применимого законодательства о данных. Это нормальная модель shared responsibility: поставщик описывает controls, а клиент применяет их так, чтобы система соответствовала его собственным обязательствам.

Именно здесь retention становится эксплуатационной задачей, а не только юридическим приложением к договору. Если инженер включает новый tool, создаёт vector store или меняет хранение response, он фактически меняет data flow. Значит, процесс change management должен включать проверку retention, а не только нагрузку, стоимость и качество ответа модели.

MCP, web tools и третьи стороны: данные выходят за периметр OpenAI

Ещё одна деталь в документации OpenAI Platform касается MCP и network-connected tools. MCP, или Model Context Protocol, позволяет подключать модель к внешним источникам и инструментам. Для разработчиков это способ дать агенту доступ к корпоративным системам, поиску, SaaS и внутренним операциям. Для privacy-команды это новый маршрут данных.

OpenAI указывает, что данные, переданные MCP server или стороннему network service, подпадают под retention policies соответствующих третьих сторон. Поэтому даже идеально настроенный ZDR-проект в OpenAI не решает вопрос хранения у внешнего tool provider. Если агент отправил фрагмент договора, тикета или иной пользовательский контент во внешний сервис, retention определяется уже всей цепочкой поставщиков.

В проектной документации это должно отражаться как data flow map. Нужно знать, какие tools доступны модели, какие поля уходят наружу, какие данные маскируются, где включены allowlist и denylist, кто владелец MCP-сервера, где он хостится и как удаляются его логи. Особенно это важно для агентных сценариев, где модель сама выбирает инструмент в ходе выполнения задачи. Чем больше автономии у агента, тем строже должен быть контроль маршрутов данных.

Как это влияет на разработчиков, legal и product

Для разработчиков новая детализация означает меньше пространства для устных допущений. Фразы «OpenAI хранит 30 дней», «API не обучается», «у нас ZDR», «мы ничего не сохраняем» теперь нужно раскладывать на endpoint, режим, объект, срок и исключение. Это защита от ситуации, когда product requirement конфликтует с data policy уже после запуска.

Для security- и legal-команд матрица retention становится checklist для vendor risk assessment. Нужно проверять не только DPA и общую страницу privacy, но и конкретные developer docs. Responses с background mode, Files, Vector Stores, Videos и MCP: разные рисковые профили. Если есть ZDR approval, надо подтвердить, какие проекты и endpoint’ы реально попадают под этот режим, а какие заблокированы или работают иначе.

Для product owners это вопрос UX и обещаний пользователю. Если приложение показывает кнопку «удалить», нужно понимать, что удаляется немедленно, что ставится в очередь на удаление, что может сохраняться до 30 дней для внутренних процессов, а что уже записано в логах самого клиента. Пользовательский privacy notice должен совпадать не с желаемой архитектурой, а с фактической цепочкой обработки данных.

Для инфраструктурных команд это вопрос observability. Prompts и responses могут сохраняться не только у OpenAI, но и в backend-логах, APM, error tracking, prompt tracing, eval-наборах, data lake и BI. Если эти копии живут дольше, спор о 30-дневном retention у OpenAI становится вторичным. Настоящий retention определяется максимальным сроком хранения в цепочке, а не самым коротким сроком у одного поставщика.

Что это означает на практике

Ниже: рабочий чек-лист для команды, которая использует или планирует использовать OpenAI API в сценариях с пользовательскими и корпоративными данными.

Чек-лист проверки retention в OpenAI API

Сохраните этот список как стартовую точку для инвентаризации. Он не заменяет проверку документации конкретных endpoint’ов и действующих настроек организации или проекта.

Инвентаризация API и объектов

Для каждого вызова зафиксируйте endpoint, режим, создаваемые объекты и дальнейший маршрут данных.

• Сделайте endpoint-by-endpoint inventory: Responses, Chat Completions, Assistants, Threads, Files, Vector Stores, Batches, Videos, аудио, изображения, prompt caching, tools и MCP.
• Для каждого endpoint’а укажите три слоя: abuse monitoring retention, application state retention и customer-side retention в ваших логах и хранилищах.
• Для Files, Vector Stores, Threads и других долгоживущих объектов настройте expires_after, регламент удаления или автоматическую очистку. Не полагайтесь на ручную дисциплину пользователей.

Режимы и контроль доступа

Режим ZDR нужно проверять как конкретную конфигурацию, а не как общее свойство всей интеграции.

• Не описывайте ZDR как универсальное «ничего не хранится». Проверьте eligibility, project-level настройки, несовместимые endpoint’ы и поведение параметра store.
• Экспортируйте API audit logs в собственный SIEM или GRC-контур: OpenAI не обещает фиксированный TTL и постоянную доступность этих журналов.
• Проверьте внешние tools и MCP-серверы. Данные, ушедшие в сторонний сервис, живут по правилам этого сервиса, а не только по политике OpenAI.

Документы и собственная инфраструктура

Политика поставщика не охватывает автоматически копии данных, которые создаёт собственная инфраструктура клиента.

• Обновите DPIA, DPA-приложения, data flow maps и privacy notices так, чтобы они различали training, abuse monitoring, application state, audit logs и third-party processing.
• Проведите ревизию собственных backend-логов, prompt traces, APM и eval-наборов: часто именно они хранят пользовательский контент дольше, чем поставщик модели.

Вывод

Обновлённая матрица retention OpenAI Platform важна не потому, что в ней появился один новый срок. Существеннее сама структура: API-данные живут в разных слоях, с разными целями и ограничениями. Для статического текстового вызова это один профиль риска; для агента с файлами, векторным хранилищем, web-инструментом и MCP: другой.

Это прикладной сюжет о зрелости AI-инфраструктуры. Пока интеграции были экспериментами, многим хватало общего ответа «данные не используются для обучения». В production этого мало. Нужны inventory, TTL, deletion workflow, audit-log export, vendor assessment и проверка каждого stateful-компонента.

OpenAI не снимает с клиента ответственность за архитектуру. Она делает её видимой. Чем подробнее описаны сроки хранения, тем меньше соблазн строить комплаенс на догадках. Вопрос к разработчикам и enterprise-командам теперь звучит жёстче: можете ли вы доказать, где живёт каждый фрагмент пользовательского контента после запроса к API?

Источники

• OpenAI: Business data
• OpenAI Help Center: API data usage policies
• OpenAI: Data Processing Addendum
• OpenAI Platform: Data retention
• OpenAI Help Center: Audit logs
• OpenAI: Sub-processors
• OpenAI News: Data retention - OpenAI Platform

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

Что OpenAI хранит в abuse monitoring logs?

По умолчанию журналы abuse monitoring могут включать customer content, включая prompts, responses и применимые производные метаданные. В документации указан срок до 30 дней, кроме правовых или security-исключений.

Означает ли Zero Data Retention, что OpenAI ничего не хранит?

Нет. ZDR исключает customer content из abuse monitoring logs для поддерживаемых endpoint’ов, но не делает все stateful-функции stateless. Режим требует approval и может ограничивать отдельные возможности.

Чем application state отличается от журналов abuse monitoring?

Application state нужен для работы функции и включает, например, сохранённые responses, треды, файлы, vector stores и фоновые задачи. Его срок зависит от конкретного endpoint’а и объекта, а не от единого срока журналов безопасности.

Почему нужно отдельно проверять MCP и внешние tools?

Данные, переданные MCP server или стороннему network service, подпадают под retention policies третьей стороны. Настройки ZDR в OpenAI не определяют хранение у такого поставщика.

Нужно ли экспортировать API audit logs в собственную систему?

Да, если они нужны для расследований, eDiscovery или отчётности. OpenAI не гарантирует фиксированный TTL и постоянную доступность audit logs, поэтому их стоит выгружать в контролируемый SIEM, GRC или другое хранилище.

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

Чек-лист: retention-проверка для интеграции с OpenAI API

PDF-версия чек-листа предназначена для сохранения, печати и использования в технической, security- и legal-проверке интеграции.

Инвентаризация API и объектов

• Составить перечень используемых endpoint’ов и инструментов.
• Зафиксировать создаваемые объекты и их владельцев.
• Разделить abuse monitoring retention, application state и хранение на стороне клиента.
• Настроить TTL, expires_after или автоматическое удаление долгоживущих объектов.

Режимы и внешние сервисы

• Проверить eligibility и фактическое включение ZDR или MAM для проекта.
• Проверить совместимость endpoint’ов с ZDR и поведение параметра store.
• Проверить все MCP-серверы и внешние tools, получающие пользовательские данные.
• Настроить выгрузку audit logs в контролируемое хранилище.

Документация и наблюдаемость

• Обновить data flow map, DPIA, DPA-приложения и privacy notices.
• Проверить backend-логи, APM, error tracking, prompt tracing и eval-наборы.
• Назначить владельцев deletion workflow и периодической ревизии объектов.