Коротко: Zero Data Retention, или ZDR, означает, что одобренный API-контур не сохраняет клиентские запросы и ответы после обработки в журналах провайдера и совместимом application state. Но это не означает, что во всей корпоративной системе «нет данных»: состояние может храниться в других функциях, содержимое уходит сторонним инструментам, а самой компании нужен минимальный журнал действий. Правильная архитектура разделяет полезную нагрузку, состояние приложения, safety-сигналы и доказательства аудита, вместо того чтобы копировать каждый prompt «на всякий случай».
Статья предназначена для руководителей, CTO, CISO, владельцев ИИ-продуктов, архитекторов и команд данных. Она объясняет продуктовую новость OpenAI от 19 августа 2026 года и предлагает технический метод проектирования. Это не юридическая консультация, не подтверждение соответствия 152-ФЗ, GDPR, HIPAA или другой норме и не независимая сертификация безопасности OpenAI.
Содержание
- Что анонсировала OpenAI
- Что такое Zero Data Retention
- Четыре потока данных в ИИ-системе
- Чем ZDR не является
- Какие ограничения видны в документации
- Почему аудит не должен хранить весь prompt
- Какой audit record действительно нужен
- Метод РАЗДЕЛ
- Как проверить архитектуру на пилоте
- Какие метрики считать
- Ограничения и открытые вопросы
- Частые вопросы
- Как AI рассвет помогает собрать приватный контур ИИ
- Вывод
Что анонсировала OpenAI
19 августа 2026 года OpenAI представила preview Private Safety Processing. Компания описывает задачу так: некоторые риски проявляются не в одном сообщении, а в последовательности связанных взаимодействий — например, при повторном обходе защит или когда ИИ-агент продолжает действовать после команды остановиться. Обычная проверка отдельного запроса не видит такой рисунок целиком.
Private Safety Processing, или PSP, должен находить паттерны между связанными взаимодействиями без доступа сотрудников OpenAI к исходным prompts и ответам. Для ZDR-развёртываний содержание остаётся в инфраструктуре клиента. OpenAI также разрабатывает вариант хранения в своей инфраструктуре с шифрованием ключами, которыми управляет клиент и копии которых нет у сотрудников OpenAI.
При обнаружении риска провайдер, по описанию OpenAI, получает узкий safety-сигнал о типе активности, но не исходное содержимое. Клиент расследует событие по информации в собственных системах и сам решает, делиться ли дополнительными данными для апелляции или подтверждённого расследования.
Важно сохранить границу доказательств. PSP тестируется с ранними клиентами, а технический white paper заявлен на сентябрь 2026 года. Публичный анонс не раскрывает полную threat model, криптографический протокол, измеренную точность детектора, частоту ложных срабатываний или независимый аудит. Поэтому сегодня это направление архитектуры и продуктовый preview, а не основание писать в политике компании «риск решён».
Что такое Zero Data Retention
Zero Data Retention — это режим для одобренных клиентов API, при котором customer content исключается из abuse-monitoring logs, а совместимые endpoint’ы не сохраняют это содержание как application state. В официальной документации OpenAI указано, что ZDR требует предварительного одобрения и дополнительных условий; настройка доступна на уровне организации и проекта.
Документация разделяет два типа хранения:
- Abuse-monitoring logs — журналы для контроля правил использования и злоупотреблений. По умолчанию они могут содержать prompts, ответы и производные metadata и храниться до 30 дней, если нет более длительного основания.
- Application state — данные, которые функции сохраняют, чтобы выполнить задачу: conversation, file, vector store, batch, background response или другой объект.
Для ZDR параметр store в Responses API и Chat Completions принудительно трактуется как false. Но одна эта настройка не делает все функции совместимыми с ZDR. Режим нужно проверять по конкретному endpoint, инструменту, модели, проекту и пути данных.
Принципиальная формула статьи:
Нулевое хранение у провайдера не означает нулевую память всей системы. Оно означает ограниченный режим конкретного обработчика при заявленных условиях.
Четыре потока данных в ИИ-системе
Спор «хранить или не хранить prompts» слишком грубый. В производственном агенте минимум четыре разных потока, и для каждого нужен свой владелец, цель и срок.
| Поток | Примеры | Зачем нужен | Главный риск |
|---|---|---|---|
| Полезная нагрузка | prompt, документ, изображение, ответ модели | выполнить пользовательскую задачу | утечка содержания и персональных данных |
| Состояние приложения | conversation, file, vector store, cache, background result | продолжить или завершить функцию | скрытое длительное хранение вне ожиданий ZDR |
| Safety-сигналы | категория риска, policy decision, alert | обнаружить злоупотребление или уход агента за полномочия | слишком широкий сигнал или непрозрачное enforcement-решение |
| Доказательства аудита | request ID, версия, tool call, approval, effect, hash | воспроизвести решение и расследовать инцидент | журнал превращается в теневую копию payload |
Эти потоки нельзя обслуживать одной политикой. Содержание договора может быть нужно модели несколько секунд, а запись о том, что агент попытался изменить реквизиты без подтверждения, — дольше. Но для расследования часто достаточно идентификатора действия, хеша параметров, результата policy check и бизнес-эффекта; полный договор в audit log необязателен.
Такой подход согласуется с NIST Privacy Framework: обработка данных включает не только хранение, но также сбор, журналирование, передачу и удаление. Минимизация должна охватывать весь lifecycle, а не только базу поставщика модели.
Чем ZDR не является
Четыре понятия часто смешивают в закупке и внутренней политике.
| Понятие | Что подтверждает | Чего не подтверждает |
|---|---|---|
| No training | содержание не используется для обучения модели без opt-in | что оно нигде не хранится для работы или безопасности |
| Zero Data Retention | совместимый API-путь не сохраняет customer content после обработки в заявленных категориях | что сторонний MCP, собственный логгер или несовместимая функция ничего не сохраняет |
| Data residency | определённые данные хранятся и иногда обрабатываются в выбранном регионе | что срок хранения равен нулю или отсутствуют system data |
| Customer-managed keys | клиент контролирует ключ шифрования конкретного слоя | что plaintext никогда не появляется при обработке или что вся цепочка использует этот ключ |
| Собственный аудит | компания может расследовать действия и управлять ответственностью | что нужно хранить полное содержание каждого запроса |
Отсюда следует практическое правило: в договоре, архитектуре и privacy notice нельзя заменять точное описание словом ZDR. Нужно перечислять какие данные, на каком участке, кем, для какой цели и сколько времени обрабатываются.
Для российского контекста полезно отдельно проверить 152-ФЗ и работу с зарубежными ИИ. Сам по себе ZDR не решает вопросы основания обработки, локализации, трансграничной передачи, роли оператора, договора с поставщиком и политики удаления. Эти выводы должен подтвердить юрист для конкретной организации и категории данных.
Какие ограничения видны в документации
Таблица OpenAI показывает, почему проверка должна идти по capability, а не по логотипу поставщика.
| Сценарий | Наблюдаемое поведение | Практический вывод |
|---|---|---|
| Responses / Chat Completions | store принудительно становится false при ZDR |
проверить проектную настройку и не полагаться только на параметр запроса |
| Conversations, Assistants, Threads, Vector Stores | в таблице помечены как не ZDR-eligible | не использовать как скрытое постоянное состояние ZDR-контура |
| Files | хранятся до удаления; поддерживается expires_after в заявленных пределах |
задать expiry и проверять фактическое удаление отдельно |
| Background response | на диске может появляться временный результат для polling | включить временное состояние в data map и тест удаления |
| Prompt caching | возможны зашифрованные key/value tensors в GPU-local storage с ограниченным сроком | не обещать буквальное отсутствие временного state |
| Remote MCP | данные уходят стороннему сервису и подчиняются его retention policy | включить каждый MCP в реестр subprocessors и data-flow review |
| Hosted containers / skills | временные файлы живут в lifecycle контейнера | определить, кто удаляет контейнер и как проверяется expiry |
| Image/file safety scan | потенциальный CSAM может сохраняться для manual review даже при ZDR | зафиксировать законное исключение и не давать абсолютное обещание |
Документация меняется. Приведённые состояния наблюдались 23 августа 2026 года и не заменяют текущую проверку перед запуском. Особенно важно сверять версию модели, регион, tool и режим проекта: совместимость одного endpoint не переносится автоматически на другой.
Внешний инструмент — отдельная зона доверия. Если агент отправил содержание в CRM, поисковый сервис или MCP, ZDR модели не управляет удалением у этого получателя. Подобно рискам prompt injection в AI-агентах, граница безопасности проходит через всю цепочку tool calls.
Почему аудит не должен хранить весь prompt
Команда безопасности часто компенсирует непрозрачность агента полным логированием. Это удобно для отладки: можно открыть prompt, ответ, chain-of-thought surrogate, аргументы инструмента и увидеть ошибку. Но production-лог быстро становится второй базой конфиденциальных данных — иногда с более широкими правами и более длинным сроком, чем исходная система.
Возникают три противоречия:
- минимизация против расследования: чем больше payload сохранено, тем проще ретроспектива и выше privacy attack surface;
- целостность против доступности агенту: если агент может изменить журнал, он не является надёжным доказательством;
- воспроизводимость против секретности: полного текста достаточно для replay, но он может содержать персональные данные, ключи, договоры и коммерческую тайну.
NIST AI RMF рекомендует документировать intended context, privacy risk, production behavior, emergent risks и процессы incident response. Это не требует хранить все входы одинаково. Требование — иметь прослеживаемую основу для решений и контролей, соразмерную риску.
Поэтому полезнее проектировать двухслойный аудит:
- Постоянный или более долгий слой событий без raw payload: идентификаторы, версии, политики, действия, approvals и effects.
- Короткий изолированный payload-буфер только для разрешённых классов риска, если он действительно нужен и имеет основание; доступ к нему не должен быть у самого агента.
Если процесс не позволяет законно сохранять содержание даже коротко, расследование строят на детерминированных идентификаторах, криптографических хешах, снимках состояния исходной бизнес-системы и воспроизводимых тестовых fixtures.
Какой audit record действительно нужен
Минимальный формат зависит от риска, но производственное событие агента обычно можно описать без полного текста.
| Поле | Пример | Зачем | Payload нужен? |
|---|---|---|---|
| Correlation IDs | request, session, workflow, parent action | связать шаги одной задачи | нет |
| Identity | user, service account, agent role | установить полномочия | нет |
| Configuration | model snapshot, prompt version, policy version | воспроизвести логику | текст prompt можно хранить в versioned registry отдельно |
| Data classes | internal, confidential, restricted | проверить разрешённый маршрут | нет |
| Tool event | tool name, operation, target system | восстановить действие | raw arguments не всегда нужны |
| Argument digest | canonicalized hash + selected redacted fields | доказать неизменность без копии содержания | нет, если есть исходник с контролируемым доступом |
| Decision | allow, deny, require approval, escalation | проверить policy engine | нет |
| Human control | approver ID, reason code, timestamp | показать передачу ответственности | комментарий минимизировать |
| Effect | created/updated/deleted object ID, status | проверить фактический результат | нет |
| Safety signal | category, confidence band, enforcement state | расследовать защитное решение | исходное содержание отдельно и только при основании |
| Lifecycle | retention class, expires_at, legal hold | выполнить удаление | нет |
Не каждый процесс требует всех полей. Но любой необратимый tool call должен связываться с тем, кто инициировал задачу, какой агент и policy действовали, что было разрешено, какой объект изменился и как откатить результат.
Сам журнал следует писать в хранилище, которое агент не может редактировать или удалять. OWASP AI Agent Security Cheat Sheet рекомендует ясные audit trails, data classification и retention/deletion policies; это полезная implementation guidance, но не сертификат конкретной системы.
Метод РАЗДЕЛ
РАЗДЕЛ — авторская схема AI рассвет для проектирования приватного и расследуемого контура. Это практический синтез документации OpenAI, NIST и security guidance, а не отраслевой стандарт.
- Р — режим. Зафиксируйте фактический data-control mode на уровне организации и каждого проекта: default, MAM, ZDR или иной режим. Проверяйте его через административный контроль, а не по договорному ярлыку.
- А — активы. Классифицируйте prompts, files, outputs, tool arguments и business effects. Для каждого класса укажите владельца, цель обработки и запрещённые маршруты.
- З — зоны. Нарисуйте путь
пользователь → приложение → модель → hosted tool/MCP → бизнес-система → audit store. На каждой границе запишите собственного оператора хранения и политику удаления. - Д — доказательства. Определите минимальный audit record: IDs, версии, policy decision, approvals, tool/action digest и эффект. Raw payload включайте только по отдельному основанию.
- Е — expiry. Установите TTL, deletion trigger, legal-hold exception и способ проверить, что исчезли также производные файлы, cache, vector entries и резервные копии.
- Л — лимиты. Документируйте несовместимые функции, временный state, safety/legal exceptions, third-party retention и невозможность доказать то, чего поставщик пока не раскрыл.
Метод заканчивается не документом, а тестом. Команда должна показать, что один и тот же request ID можно проследить до бизнес-эффекта, а полный payload после срока действительно недоступен во всех заявленных зонах.
Как проверить архитектуру на пилоте
1. Выберите один процесс и один класс данных
Например, подготовка ответа по внутренней базе без отправки сообщения клиенту. Зафиксируйте текущий baseline, источники, права, ограничения и критерий приёмки. Не начинайте с агента, который одновременно читает почту, меняет CRM и отправляет платежи.
2. Постройте data-flow map
Перечислите API endpoint, модель, store, caching, files, hosted tools, MCP, логи приложения, APM, SIEM, резервные копии и систему назначения. Для каждой стрелки назначьте владельца и retention class.
3. Введите canary-данные
Используйте синтетические маркеры, которые не являются реальными персональными данными или секретами. После запроса ищите эти маркеры во всех разрешённых логах и хранилищах. Отсутствие в одном vendor log не доказывает отсутствие во всей цепочке.
4. Смоделируйте четыре события
- обычный успешный запрос;
- запрещённый tool call;
- команда остановиться посреди длинной agentic task;
- обращение к стороннему MCP с конфиденциальным полем.
Проверьте, что политика блокирует или эскалирует нужный шаг, а журнал объясняет решение без лишнего содержания.
5. Проверьте удаление по времени
После TTL повторите поиск canary в files, caches, vector stores, hosted containers, app logs и backups. Зафиксируйте не только вызов delete, но и наблюдаемый результат либо честный Unknown для зоны, которую нельзя проверить.
6. Проведите расследование вслепую
Дайте инженеру только минимальный audit record и состояние бизнес-системы. Он должен восстановить последовательность, определить owner и понять, было ли действие разрешено. Если это невозможно — добавьте конкретное поле, а не весь payload целиком.
7. Проверьте appeal и legal exception
Смоделируйте ложный safety alert и законное исключение хранения. Кто видит содержание? Кто выдаёт ключ? Кто утверждает legal hold? Как событие закрывается и как удаляются временные копии после решения?
8. Запускайте ограниченно
Сначала read-only или shadow mode, затем обратимые действия с подтверждением. Автономность повышают только после прохождения deletion, audit reconstruction и incident-response tests.
Какие метрики считать
| Метрика | Формула или правило | Что показывает |
|---|---|---|
| Payload replication rate | зоны с найденным canary / проверенные зоны | где содержание копируется вне нужного пути |
| Audit sufficiency | восстановленные события / тестовые события | хватает ли минимальных доказательств |
| Sensitive-field exposure | незамаскированные sensitive fields / audit records | не стал ли журнал источником утечки |
| Deletion verification | подтверждённо очищенные зоны / зоны с TTL | выполняется ли lifecycle фактически |
| Unknown-zone count | зоны без проверяемого retention state | где обещание пока нельзя подтвердить |
| Policy interception | заблокированные опасные действия / все опасные тесты | работает ли control до business effect |
| Orphan effect rate | эффекты без связанного request/approval / все эффекты | можно ли назначить ответственность |
| Appeal reconstruction time | время до воспроизведения safety event | пригоден ли журнал для разбора |
Эти показатели не предсказывают безопасность или соответствие закону. Они измеряют наблюдаемые свойства выбранного пилота. Порог утверждает владелец процесса вместе с security, privacy и legal-функциями по классу риска.
Ограничения и открытые вопросы
Private Safety Processing на дату статьи остаётся preview. OpenAI планирует начать rollout и опубликовать technical white paper в сентябре 2026 года. До него публично не установлены точная криптографическая конструкция, состав cross-interaction state, false-positive/false-negative rates, независимые тесты, модель угроз, доступность по моделям и регионам, стоимость, latency и порядок миграции для каждого клиента.
Описание механизма и продуктовые свойства взяты из источников OpenAI. Это первичные источники о заявленном поведении продукта, но не независимое подтверждение реализации. Документация data controls наблюдалась 23 августа 2026 года и может измениться.
NIST AI RMF и Privacy Framework — добровольные risk-management frameworks, а не сертификаты этой архитектуры. OWASP — практическая security guidance. Ни один из этих источников не подтверждает соответствие конкретной компании российскому или иностранному праву.
В статье не измеряются частота злоупотреблений, production-инциденты, эффективность PSP, ROI, стоимость хранения, latency, вероятность утечки или результат для компании. Search volume, keyword difficulty, rankings, трафик, CTR и AI citations страницы также Unknown.
Частые вопросы
Хранит ли OpenAI запросы при Zero Data Retention?
Для одобренного ZDR-контура OpenAI заявляет исключение customer content из abuse-monitoring logs и отсутствие application state у совместимых endpoint’ов после обработки. Но временное состояние, несовместимые функции, files, сторонние сервисы и законные safety-исключения нужно проверять отдельно.
Чем ZDR отличается от запрета использовать данные для обучения?
No-training ограничивает использование содержания для улучшения моделей. ZDR относится к хранению customer content в определённых категориях и endpoint’ах. Данные могут не использоваться для обучения, но сохраняться для выполнения функции или мониторинга — это разные обещания.
Нужно ли при ZDR отключать журнал аудита ИИ-агента?
Нет. Для управляемого агента нужен аудит действий, решений и эффектов. Но журнал не обязан копировать весь prompt: часто достаточно идентификаторов, версий, redacted metadata, policy decision, хешей аргументов, approvals и object IDs.
Совместимы ли MCP-серверы с ZDR?
ZDR провайдера модели не определяет политику стороннего MCP. Официальная документация OpenAI прямо указывает, что отправленные MCP-серверу данные подчиняются retention policy этого сервиса. Каждый MCP нужно проверять как отдельного получателя.
Означает ли store: false, что данные нигде не сохраняются?
Нет. Этот параметр управляет поведением конкретного API, но не собственными логами приложения, files, caches, hosted tools, SIEM, backups, MCP и целевой бизнес-системой. Нужна полная data-flow map.
Какой первый тест провести компании?
Выбрать один read-only процесс, добавить синтетический canary, проследить его через все зоны, проверить TTL и попробовать расследовать запрещённое действие только по минимальному audit record. Такой тест выявляет скрытые копии и недостаток доказательств.
Как AI рассвет помогает собрать приватный контур ИИ
AI рассвет может связать требования к данным с реальным бизнес-процессом и технической цепочкой:
- провести аудит процесса, источников, текущего baseline и классов данных;
- спроектировать корпоративное AI-пространство, RAG или локальное развёртывание LLM с разделением зон и прав;
- собрать MVP ИИ-агента с интеграциями, минимальным журналом, policy checks и подтверждением действий;
- провести тестирование, запуск, обучение команды и поддержку lifecycle-контролей.
Безопасный первый шаг — выбрать один процесс, описать его baseline, источники данных, ограничения и критерий приёмки. Обсудить задачу.
Вывод
Zero Data Retention полезен не как маркетинговый ярлык, а как проверяемое свойство конкретного пути данных. Свежий preview OpenAI показывает возможный компромисс: анализировать рисковые паттерны между взаимодействиями, не отдавая сотрудникам провайдера исходное содержание. Но до technical white paper и независимой проверки детали реализации остаются открытыми.
Для бизнеса главный вопрос звучит точнее: какие данные должны исчезнуть, а какие минимальные доказательства должны остаться, чтобы действие агента можно было объяснить и оспорить? Метод РАЗДЕЛ переводит ответ в архитектуру: режим, активы, зоны, доказательства, expiry и лимиты. Если команда не может нарисовать эти шесть элементов и проверить их canary-тестом, обещание «ничего не храним» пока не доказано.
Полезно читать вместе: локальный ИИ-агент и безопасность, расследование инцидентов ИИ-агентов и 152-ФЗ и зарубежные ИИ.