Хранение данных LLM API и Zero Data Retention: как проверить маршрут
Выберите допустимый срок хранения, затем проверьте конкретный маршрут LLM API. Договор ZDR не покрывает автоматически все модели, функции, посредников и ваши логи.
Содержание

Zero Data Retention (ZDR) — режим, при котором содержимое запросов и ответов не сохраняется после обработки в пределах оговорённой услуги. Он относится к конкретному договору, организации, модели и набору функций. ZDR не означает, что данные не проходят через оперативную память, что не остаётся технических метаданных или что ваше приложение перестало записывать запросы в журнал.
Выбирайте ограниченное хранение, если для вашего класса данных разрешены запись, установленный срок удаления и согласованный круг доступа. Выбирайте подтверждённый ZDR, если условия клиента или внутренняя политика требуют этого режима. Если запрещена любая запись содержимого на постоянный носитель, включая ваше облачное хранилище, проверьте и это отдельное требование: некоторые варианты ZDR его не выполняют.
Практический результат проверки — карточка конкретного маршрута с доказательствами и решением «допустить» либо «не допускать до устранения причины». Ниже есть заполняемый пример и программа для проверки логики без обращения к API. Условия продуктов сверены по официальным документам на 6 октября 2026 года; настройки реальных организаций и фактическое удаление данных здесь не проверялись.
Когда достаточно ограниченного хранения, а когда нужен ZDR
Не начинайте с поиска «самого безопасного провайдера». Сначала определите, какие данные разрешено передавать и какое хранение допускается.
| Условия вашей задачи | Что выбирать | Что должно быть подтверждено |
|---|---|---|
| Обработка публичных материалов; установленный срок хранения приемлем | Обычный API с ограниченным хранением | Срок, цель, доступ, исключения и отсутствие нежелательного обучения |
| Клиент разрешает хранить тексты до определённого срока | Маршрут, укладывающийся в этот срок | Все копии, включая журналы, файлы и резервные копии; максимальный срок, а не только настройка истории |
| Договор требует ZDR для передаваемого содержимого | Одобренный ZDR-маршрут | Подтверждение организации и применимости к модели, endpoint и каждой функции |
| Содержимое нельзя сохранять нигде после обработки | Маршрут без записи содержимого во всей цепочке | Также клиентские хранилища, инструменты, ошибки, трассировки и резервные копии |
| Данные вообще нельзя передавать внешнему обработчику | Обработка внутри разрешённого контура | ZDR внешнего API сам по себе это условие не выполняет |
Это пример инженерного выбора, а не универсальная классификация данных. Допустимые сроки устанавливает владелец вашей политики с учётом договоров и применимых требований. Русский язык статьи не подтверждает доступность сервиса в конкретной стране или соответствие местному законодательству.
Отдельно проверьте обещание «не используем для обучения». Оно отвечает на вопрос о назначении данных, но не об их записи. Отключение истории через store=false тоже решает только свой вопрос: оно не отключает автоматически журналы безопасности, хранение инструментов или ваши логи.
Условный пример: сервис делает краткие описания опубликованных пресс-релизов, а владелец разрешил хранение до 30 дней. Проверенный маршрут с таким сроком может быть достаточен. Тот же маршрут нельзя автоматически использовать для документов клиента, запретившего запись содержимого. Для второго случая нужна отдельная проверка и, возможно, другая модель или отказ от функции, создающей состояние.

Проверьте договор и настройки для точного маршрута
Запишите фактическую цепочку: приложение → шлюз → оператор API → модель → подключённые инструменты. Добавьте запасные маршруты: при ошибке основной модели запрос может уйти другому обработчику.
Для каждого участка выясните, кто отвечает за данные, какая организация или проект используется, в каком регионе происходит обработка и что именно сохраняется. Нужны два вида подтверждений: документ с условиями услуги и свидетельство настройки вашего ресурса. Страница продукта не доказывает, что режим включён у вас; экспорт настроек без условий не объясняет исключения.
OpenAI: store=false, ZDR и PSP имеют разные границы
OpenAI описывает обычные журналы контроля злоупотреблений со сроком до 30 дней и отдельно одобряемые режимы MAM/ZDR. Проверяйте настройки организации и проекта, применимость модели, endpoint и функций. ZDR принудительно отключает store для Responses и Chat Completions, но не превращает Files, Batch и другие неподходящие функции в ZDR. Фоновый режим Responses создаёт временное состояние для опроса результата и не подходит для строгого ZDR. Правила кэша зависят от модели и выбранного режима. Сохраняются предусмотренные документом исключения безопасности и закона.
У ZDR with Private Safety Processing (PSP) есть дополнительный участок. Описание PSP предусматривает выбранные зашифрованные записи и результаты проверки безопасности в облачном хранилище клиента, с 30-дневным TTL. Отзыв доступа к ключу не удаляет уже записанный объект. Поэтому проверьте хранилище, срок и разрешённый доступ. Это отличается от Private Retention with PSP, где используется управляемое OpenAI хранилище: название похожее, но режим и место хранения другие.
Если политика разрешает клиентское зашифрованное хранение, PSP оценивается с этим условием. При запрете любой постоянной записи содержимого наличие клиентского хранилища меняет решение, даже если услуга называется ZDR.
Claude: неподходящая функция может успешно выполниться
В документации Claude API ZDR привязан к отдельной организации, модели и функциям. Некоторые модели требуют 30-дневного хранения, если Anthropic явно не согласовал исключение. Messages и подсчёт токенов не дают общего разрешения на Files, Batch, выполнение кода или MCP connector.
Особенно важно: функция с отметкой No в таблице ZDR может принять запрос и сохранить данные по своим правилам. Отсутствие ошибки API не доказывает соответствие. Такие функции необходимо ограничивать в приложении. Для structured outputs и strict-схем предусмотрено хранение схемы до 24 часов после последнего использования; не помещайте чувствительные значения в имена, перечисления и другие элементы схемы. Допустимый кэш и диагностические артефакты также не равнозначны отсутствию любых метаданных.
Коммерческая политика Claude описывает удаление входов и выходов API в пределах 30 дней с оговорками, а техническая страница уточняет режимы по функциям и моделям. Максимальное окно удаления не означает, что каждый запрос обязательно хранится всё это время. Не сводите их к единому «по умолчанию 0, 7 или 30 дней»; фиксируйте условия вашего использования и исключения.
Gemini API Zero Data Retention: Developer и Vertex нужно разделять
Если нужен гарантированный ZDR или корпоративный DPA, текущая страница Gemini Developer API направляет к Vertex AI. Платный Developer API с запретом использования данных для улучшения продуктов не следует выдавать за уже одобренный ZDR-маршрут. В Developer API поиск Google и Maps предусматривают 30-дневное хранение, а Files, явный кэш и восстановление Live-сессии создают отдельное состояние.
Проверьте и журналы проекта Gemini Developer. Для Interactions хранение по умолчанию включено, для Generate Content — выключено, но настройки могут переопределяться. Включённые продуктовые журналы имеют срок 55 дней по умолчанию с альтернативами 7, 14 и 28 дней. Сохранённые datasets автоматически не истекают. Эти сроки относятся к указанной функции журналов, а не ко всем данным любого запроса.
У Google Cloud Agent Platform / Vertex другие условия. Для соответствующего контроля злоупотреблений предусмотрено согласование исключения; отдельные Advanced AI модели и функции имеют дополнительные ограничения. Cloud-поиск Google сохраняет производные запросы и контекст до 3 дней, Developer-поиск — до 30 дней: переносить цифру между продуктами нельзя. У Cloud Maps срок 30 дней, у Deep Research состояние сохраняется 7 дней. Проверяйте конкретную функцию даже после согласования ZDR.
Azure и Bedrock: облачный регион не заменяет режим хранения
Для моделей, продаваемых Azure, Microsoft описывает собственную обработку и отдельно одобряемое изменение контроля злоупотреблений. Признак ContentLogging=false появляется, когда соответствующее хранение отключено; отсутствие поля не равно false. История, файлы и диагностика ресурса проверяются отдельно. Уточняйте продавца и обработчика: условия Azure-продаваемой модели нельзя автоматически переносить на Claude в Foundry. Регион хранения и география обработки тоже могут различаться.
У Amazon Bedrock важны Region, эффективный режим и allowed_modes конкретной модели. Эффективная настройка определяется применимой последовательностью проекта, региональной настройки аккаунта и модели. none означает отсутствие постоянного хранения в описанном режиме; другие режимы могут допускать проверку AWS. store=false не заменяет none. Если модель не допускает none, переход на aws_review ради успешного запроса меняет условие хранения. Для обязательного ZDR выбирайте разрешённую модель, получите явное согласование исключения либо остановите этот маршрут. Проверяйте также места хранения при межрегиональной обработке.
Шлюз ограничивает маршрутизацию, но не проверяет всю цепочку за вас
OpenRouter позволяет ограничить маршрутизацию endpoints своей классификацией ZDR. Принудительное требование на уровне аккаунта или группы нельзя снять одним provider.zdr=false. Однако правило для вызова модели не покрывает автоматически плагины и инструменты. Для BYOK и частного развёртывания декларация клиента о ZDR не является независимой проверкой OpenRouter.
Запишите фактический endpoint и все запасные варианты, условия самого шлюза, подключённые инструменты и собственное логирование. В рамках этой проверки нет подтверждений ZDR для laozhang.ai, поэтому рекомендовать его для данных с обязательным ZDR оснований нет. После проверки условий данных можно отдельно сравнить стоимость каналов доступа к LLM API; цена не подтверждает режим хранения.
Примечание: laozhang.ai — наш собственный сервис; его цены — наши тарифы, а не независимое сравнение.
Не забудьте собственные журналы и технические артефакты
Даже подходящий договор провайдера не удалит копию запроса из вашего приложения. Проверьте access logs, трассировки APM, обработчики исключений, SIEM, обращения в поддержку и резервные копии. Разрешённый список полей обычно понятнее запрета «не логировать секреты»: например, фиксировать ID операции, модель, время и статус, исключая текст запроса и ответа. Допустимость этих метаданных тоже нужно оценить.
Разделяйте содержимое, метаданные и технические артефакты. Схема JSON может содержать имя клиента в enum; ошибка — фрагмент входного текста; сохранённый инструментом URL — чувствительный идентификатор. Кэш в памяти, зашифрованный объект и журнал без текста имеют разные свойства. Укажите, какие из них разрешает именно ваша политика.
Для ограниченного хранения учитывайте самую долгоживущую копию. Удаление записи из основного журнала не сокращает срок резервной копии. Если сроки, доступ или содержимое неизвестны, соответствующий участок карточки остаётся неподтверждённым.
Заполняемая карточка и проверка без вызова API
Сохраните карточку для одной среды и одного маршрута. Укажите класс данных, ответственного и дату следующей проверки. В приложениях к карточке нужны условия договора, одобрение организации, настройки проекта, таблица применимости модели и функций, перечень посредников и доказательства правил собственных журналов. Не включайте ключи и тексты клиентов.
Пример ниже полностью вымышленный: fixture-* — обозначения учебных свидетельств, а не документы реального аккаунта. Он показывает маршрут с разрешённым 30-дневным хранением. Замените эти значения результатами своей проверки. Добавляйте отдельные строки для файлов, кэшей, инструментов и резервных копий, если они присутствуют. inventoryComplete=true означает, что ответственный подтвердил полноту перечня; программа не обнаруживает скрытые узлы сама.
Сохраните JSON в card.json:
{
"dataClass": "public-materials-example",
"owner": "example-security-owner",
"reviewBy": "2026-11-01",
"policy": {
"mode": "bounded",
"maxHours": 720,
"allowCustomerStorage": false,
"customerMaxHours": 0
},
"route": {
"host": "api.example.invalid",
"org": "example-org",
"project": "example-project",
"apiVersion": "example-version",
"region": "example-region",
"endpoint": "/example/messages",
"model": "example-model-v1",
"features": ["text", "store=false"],
"fallbacks": []
},
"approvedRoute": {
"host": "api.example.invalid",
"org": "example-org",
"project": "example-project",
"apiVersion": "example-version",
"region": "example-region",
"endpoint": "/example/messages",
"model": "example-model-v1",
"features": ["text", "store=false"],
"fallbacks": []
},
"inventoryComplete": true,
"metadataApproved": true,
"exceptionsReviewed": true,
"zdr": {
"orgApproved": false,
"modelEndpointFeaturesEligible": false,
"evidence": []
},
"nodes": [
{
"id": "provider-safety",
"owner": "provider",
"hours": 720,
"training": false,
"evidence": ["fixture-policy", "fixture-resource-setting"]
},
{
"id": "application-logs-and-backups",
"owner": "customer",
"hours": 0,
"training": false,
"evidence": ["fixture-log-check"]
}
]
}Поле hours здесь означает подтверждённый максимальный срок записи содержимого на постоянный носитель. Ноль — отсутствие такой записи, а не просто отсутствие сохранённой истории. Исключения и метаданные рассматриваются отдельно. Режим bounded в примере требует отсутствия обучения; если ваша политика разрешает его, её нужно сформулировать отдельно.
Сохраните следующий код в audit-route.mjs. Нужен установленный Node.js; программа читает только указанный локальный JSON. Она проверяет согласованность заполненной карточки, а не достоверность приложенных документов.
import { readFileSync } from 'node:fs';
export function audit(card) {
const reasons = [];
const policy = card.policy ?? {};
const evidence = value => Array.isArray(value) &&
value.length > 0 && value.every(x => typeof x === 'string' && x.trim());
if (!['bounded', 'zdr'].includes(policy.mode)) reasons.push('policy');
if (!Number.isFinite(policy.maxHours) || policy.maxHours < 0)
reasons.push('maxHours');
const keys = ['host', 'org', 'project', 'apiVersion', 'region', 'endpoint', 'model', 'features', 'fallbacks'];
for (const key of keys) {
const value = card.route?.[key];
const valid = ['features', 'fallbacks'].includes(key)
? Array.isArray(value) && value.every(x => typeof x === 'string' && x.trim())
: typeof value === 'string' && value.trim();
if (!valid || JSON.stringify(value) !== JSON.stringify(card.approvedRoute?.[key]))
reasons.push(`route:${key}`);
}
for (const key of ['inventoryComplete', 'metadataApproved', 'exceptionsReviewed'])
if (card[key] !== true) reasons.push(key);
if (policy.mode === 'zdr' &&
(card.zdr?.orgApproved !== true ||
card.zdr?.modelEndpointFeaturesEligible !== true ||
!evidence(card.zdr?.evidence))) reasons.push('zdr-scope');
if (!Array.isArray(card.nodes) || card.nodes.length === 0) reasons.push('nodes');
for (const node of card.nodes ?? []) {
let limit = policy.mode === 'zdr' ? 0 : policy.maxHours;
if (policy.mode === 'zdr' && node.owner === 'customer' &&
policy.allowCustomerStorage === true) limit = policy.customerMaxHours;
if (!node.id || !['provider', 'customer'].includes(node.owner) ||
!evidence(node.evidence) || node.training !== false ||
!Number.isFinite(limit) || limit < 0 ||
!Number.isFinite(node.hours) || node.hours < 0 || node.hours > limit)
reasons.push(`node:${node.id ?? 'unknown'}`);
}
return { allow: reasons.length === 0, reasons };
}
const card = JSON.parse(readFileSync(process.argv[2], 'utf8'));
const result = audit(card);
console.log(JSON.stringify(result, null, 2));
process.exitCode = result.allow ? 0 : 1;Запуск: node audit-route.mjs card.json. Учебный JSON возвращает allow: true: лимит 720 часов соблюдён. Ошибка чтения или формата завершает процесс с ошибкой; такой результат тоже не является допуском.
Проверьте три изменения в отдельных копиях карточки:
| Изменение учебного JSON | Ожидаемый результат | Что проверяется |
|---|---|---|
policy.maxHours заменить на 168 | Отказ, node:provider-safety | 30 дней превышают разрешённую неделю |
Только route.model заменить на example-model-v2 | Отказ, route:model | Новая модель не наследует допуск |
metadataApproved заменить на null | Отказ, metadataApproved | Неизвестное не считается подтверждением |
Для учебного ZDR-сценария установите policy.mode="zdr", обе отметки в zdr в true, добавьте учебное свидетельство и замените срок провайдера на 0. Это даёт допуск по заполненным условиям. Верните ему 720 — получите отказ. В реальной карточке эти отметки можно поставить лишь после подтверждения точной организации, модели, endpoint и функций.
Клиентское хранение, например в архитектуре PSP, задаётся отдельным узлом с owner="customer". Для ZDR-политики, явно допускающей такую запись, используйте allowCustomerStorage=true и согласованный customerMaxHours. При запрете любой записи оставьте false. Программа не выводит эти значения из названия услуги.

Как подтвердить карточку и сохранить допуск при изменениях
Офлайн-проверка выше помогает найти противоречия. Для реального допуска дополнительно нужен разрешённый технический тест вашей среды:
- Сопоставьте параметры приложения с организацией, регионом, моделью, функциями и запасными маршрутами из карточки. Условие должно проверяться до передачи содержимого.
- Используйте синтетическую метку без клиентских данных. В разрешённой тестовой среде проверьте, появляется ли она в ваших журналах, трассировках, ошибках и хранилищах функций.
- Для разрешённого ограниченного хранения проверьте процедуру удаления и сроки резервных копий. Отсутствие метки в доступном журнале не доказывает удаление у внешнего обработчика.
- Сохраните результат, настройки и границы наблюдения. Договорное обещание провайдера подтверждается документами; недоступное внутреннее хранилище нельзя считать проверенным по одному ответу API.
В этом материале выполнены только локальные проверки JSON и логики на синтетических данных. Реальные запросы, изменение облачных настроек и проверка удаления не выполнялись.
Любое изменение модели, региона, endpoint, инструмента, шлюза, резервного маршрута, логирования или договора требует сопоставления с карточкой. Если изменение затрагивает условия хранения, обновите доказательства и решение. При отказе не направляйте чувствительное содержимое в непроверенный fallback: используйте заранее допущенный маршрут, разрешённое обезличивание либо понятную ошибку. Само приложение должно применять результат проверки; локальная программа ничего не переключает у провайдера.
Частые вопросы
Zero Data Retention — это полное отсутствие данных у провайдера?
Нет. Это обещание об обработке определённого содержимого в установленной области. Оперативная память, метаданные, исключения и артефакты функций проверяются отдельно. Например, Claude допускает отдельное хранение схем structured outputs, а OpenAI ZDR with PSP предусматривает зашифрованные записи в хранилище клиента.
Достаточно ли store=false для ZDR?
Нет. Параметр управляет определённым состоянием приложения. Нужны условия организации и проверка функций, журналов безопасности, посредников и собственных логов. OpenAI прямо разделяет состояние приложения и контроль хранения для мониторинга злоупотреблений.
Можно ли получить гарантированный ZDR в Gemini Developer API?
Текущая документация Gemini Developer направляет за гарантированным ZDR и корпоративным DPA к Vertex AI. Платный Developer API сам по себе не подтверждает такой режим; поиск, журналы, файлы и состояние диалога имеют отдельные правила.
Успешный ответ Claude означает, что функция подходит для ZDR?
Нет. Документация Claude предупреждает, что неподходящие функции могут выполняться по своим правилам хранения. Применимость нужно проверить заранее и ограничить вызовы на стороне приложения.
Можно ли в Bedrock включить aws_review, если модель не работает с none?
Технический запуск не решает требование ZDR. Режимы Bedrock имеют разные условия хранения. Если нужен none, проверьте allowed_modes модели в нужном регионе, выберите подходящую модель или получите явное согласование. Не допускайте новый режим молча.
Источники10
Внешние страницы, на которые ссылается это руководство, в порядке упоминания. Последнее обновление: 7 окт. 2026 г..
Источники10
Внешние страницы, на которые ссылается это руководство, в порядке упоминания. Последнее обновление: 7 окт. 2026 г..
- 1.OpenAI описываетdevelopers.openai.com/api/docs/guides/your-data
- 2.Описание PSPdevelopers.openai.com/api/docs/guides/private-safety-processing
- 3.документации Claude APIplatform.claude.com/docs/en/manage-claude/api-and-data-retention
- 4.Коммерческая политика Claudeprivacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data
- 5.страница Gemini Developer APIai.google.dev/gemini-api/docs/zdr
- 6.журналы проекта Gemini Developerai.google.dev/gemini-api/docs/logs-datasets
- 7.Google Cloud Agent Platform / Vertexdocs.cloud.google.com/gemini-enterprise-agent-platform/resources/zero-data-retention
- 8.Microsoft описываетlearn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy
- 9.Amazon Bedrockdocs.aws.amazon.com/bedrock/latest/userguide/data-retention.html
- 10.OpenRouteropenrouter.ai/docs/guides/features/zdr





