Zero Data Retention нужно проверять для конкретного маршрута запроса, а не для названия провайдера. Одной фразы «API-данные не используются для обучения» недостаточно: запрос всё ещё может попасть в abuse-журнал, историю диалога, файл, кэш, инструмент, API-шлюз или ваш собственный observability-стек.
Для чувствительных данных начните с трёх действий:
- зафиксируйте полный путь от приложения до модели и обратно;
- проверьте шесть независимых плоскостей хранения;
- сохраните доказательство настройки для точного проекта, endpoint и набора функций.
Маршрут можно допускать только тогда, когда каждый слой подтверждён. Если хотя бы один слой неизвестен, статус — «условно» или «запрещено», пока пробел не закрыт. Это техническая методика допуска, а не юридическое заключение или сертификация провайдера.
«Не обучаем», ограниченное хранение и ZDR — разные обещания
Три формулировки часто выглядят одинаково в коммерческой презентации, но отвечают на разные вопросы.
| Формулировка | Что она действительно отвечает | Чего она не доказывает |
|---|---|---|
| Данные не используются для обучения | Провайдер не улучшает foundation model на ваших prompts и outputs в описанной услуге | Что payload нигде не записывается |
| Ограниченное хранение | Контент или metadata удаляются после определённого срока | Что срок равен нулю и все функции имеют один режим |
| Zero Data Retention | В рамках определённого договора и eligible-маршрута контент не сохраняется после обработки | Что ZDR распространяется на файлы, поиск, агентов, batch, шлюзы и ваши логи |
Практический пример: платный Gemini Developer API может не использовать prompts и responses для улучшения продуктов, но это ещё не ZDR. Одобренный проект ZDR добавляет отдельный режим abuse monitoring, а функции вроде Grounding with Google Search или Maps имеют собственное 30-дневное хранение. Точно так же store=false в одном вызове не заменяет договорный режим организации и аудит подключённых функций.
Шесть мест, где запрос может остаться
Удобнее рассматривать retention не как один переключатель, а как шесть плоскостей. Каждая имеет отдельного владельца, срок и доказательство.
1. Использование для обучения
Проверьте условия именно коммерческого API, тарифа и региона. Не переносите политику consumer-чата на API и наоборот. Это самый заметный пункт, но он отвечает только на вопрос об обучении.
2. Abuse- и safety-журналы
Провайдер может временно хранить customer content для расследования злоупотреблений. Например, OpenAI указывает срок до 30 дней по умолчанию; Modified Abuse Monitoring и ZDR доступны подходящим организациям после одобрения. Возможны отдельные legal и safety-исключения.
3. Состояние приложения у провайдера
История conversations, threads, responses или session resumption может быть продуктовой функцией, а не abuse-логом. Она управляется отдельными параметрами и жизненным циклом. Утверждение «abuse logs отключены» ничего не говорит о сохранённой истории.
4. Хранилища конкретных функций
Files, vector stores, batch jobs, fine-tuning data, caches, code execution и agent workspaces требуют состояния. В текущей таблице OpenAI часть таких endpoints помечена как ZDR-ineligible. Anthropic отдельно исключает Managed Agents, Files, batch, code execution и MCP connector.
5. Шлюзы, инструменты и субпроцессоры
Запрос может пройти через gateway, tracing service, MCP server, web search или другого model provider. Политика основной модели не покрывает эти узлы автоматически. Нужны условия и конфигурация каждого участника цепочки.
6. Ваши логи и базы
Даже идеальный upstream ZDR не удалит payload из API gateway access logs, APM traces, error reports, SIEM, support tickets, prompt history или резервных копий. Часто именно здесь остаётся самая полная копия запроса. Нужны redaction, allowlist полей, сроки удаления и тест восстановления.
Текущая матрица маршрутов: проверяйте строку, а не бренд
Состояние ниже проверено 27 июля 2026 года. Это отправная точка для повторной проверки, а не бессрочная гарантия.
| Маршрут | Что подтверждено официально | Главная граница | Минимальное доказательство |
|---|---|---|---|
| OpenAI API | У подходящих организаций есть MAM/ZDR; при ZDR /v1/responses и /v1/chat/completions обрабатывают store как false | Conversations, ChatKit Threads, Assistants/Threads, files, vector stores, batches и другие stateful-поверхности могут быть ZDR-ineligible | Одобрение организации, project ID, endpoint, feature inventory и текущая строка retention-table |
| Anthropic API | ZDR включается для организации; eligible Messages и Token Counting не сохраняют prompts/responses at rest после ответа | Managed Agents, Files, batch, code execution и MCP connector исключены; отдельные модели требуют 30 дней | Подтверждение организации, точная модель, endpoint и список функций |
| Gemini Developer API | Paid Services не используют контент для улучшения продуктов; одобренный project-level ZDR очищает user content и identifiable metadata перед abuse logging | Search/Maps grounding — 30 дней; Live, Files и explicit cache имеют отдельное состояние. В AI Studio logs and datasets Interactions по умолчанию использует store=true, Generate Content — store=false, но logging можно включить; logs имеют 7/14/28/55 дней (55 по умолчанию), а сохранённые datasets автоматически не истекают | Project ID, подтверждение ZDR, фактический store, project logging, datasets/export/share, срок и удаление |
| Azure OpenAI / Azure Direct Models | Microsoft не обучает foundation models на prompts/outputs без разрешения; stateful data остаются в Azure resource | Microsoft описывает modified abuse monitoring, а не универсальный ZDR; preview-функции могут отличаться | Resource/region, одобрение, проверка ContentLogging=false, список Azure resources |
| Amazon Bedrock | AWS заявляет, что model providers не получают доступ к Bedrock prompts, completions, logs и deployment accounts | Invocation logging, CloudTrail, agents, knowledge bases и sessions остаются в вашем AWS-контуре | Account/region, service inventory, logging config, KMS/IAM и deletion policy |
| API-шлюз | Некоторые шлюзы умеют маршрутизировать только к endpoints, отмеченным как ZDR | Классификация шлюза не является независимой сертификацией upstream; собственные логи и tools остаются | Политика шлюза, точный upstream, provider route, log settings и договор всей цепочки |
OpenRouter, например, отделяет no-training от no-retention и позволяет ограничивать routing endpoints своей классификацией ZDR. Это полезный контроль маршрутизации, но не основание пропустить проверку upstream endpoint, provider logging и собственных приложений.
Для laozhang.ai в этом обзоре публичные условия ZDR не были подтверждены. Поэтому его нельзя рекомендовать для workload с обязательным ZDR, пока не проверены собственная политика хранения шлюза, точный upstream, subprocessor chain, настройки логов и договор. Если задача сначала в выборе типа маршрута и цены, используйте отдельное сравнение LLM API-провайдеров, но не переносите вывод о стоимости на режим данных.
Карточка допуска: минимальное доказательство перед production
Скриншота маркетинговой страницы недостаточно. Создайте одну карточку для каждого реально используемого маршрута.
textКласс данных: Приложение и среда: Организация / project / workspace: Регион: Gateway и upstream provider: Endpoint и модель: Включённые функции и инструменты: Режим обучения: Abuse/safety retention: Application state: Files/cache/batch retention: Project logging и фактический `store`: Datasets, export/share и deletion: Собственные logs/traces/backups: Официальный документ и дата: Экспорт настройки или admin evidence: Исключения и stop rule: Владелец: Дата следующей проверки:
Карточка должна позволить другому инженеру воспроизвести вывод. Фраза «в консоли всё выключено» не воспроизводима; нужны идентификатор ресурса, экспорт параметров или зафиксированная admin-проверка без секретов и персональных данных.
Как провести технический тест
Политику нельзя полностью доказать одним API-вызовом, но тест обнаружит расхождение между заявленной и фактической конфигурацией.
- Используйте синтетический маркер. Отправьте уникальную строку без реальных секретов и персональных данных.
- Проверьте активный маршрут. Зафиксируйте DNS/host, gateway, endpoint, model ID, region и feature flags.
- Найдите маркер в своих системах. Проверьте API gateway, application logs, traces, error reporting, SIEM и data warehouse.
- Проверьте stateful-поверхности. Убедитесь, что не создались conversation, file, cache, batch, agent session или search artifact.
- Выполните удаление. Если продукт требует явного delete, проверьте результат и срок, включая backup policy.
- Сопоставьте с договором. API-ответ
200доказывает работу endpoint, но не доказывает retention policy.
Не отправляйте реальные секреты «для проверки утечки». Синтетическая метка даёт наблюдаемость без создания нового инцидента.
Fail-closed правило для релиза и изменений
Допуск должен быть частью release gate. Повторяйте проверку, если меняется хотя бы один элемент:
- model ID или provider;
- endpoint, API version или region;
- gateway/provider route;
- web search, MCP, code execution, file, cache, batch или agent feature;
- project logging, значение
store, срок logs, создание, export или sharing dataset; - режим логирования, observability vendor или срок backup;
- договор, DPA, retention table или eligibility организации.
Если новый маршрут не имеет полной карточки, чувствительные поля не должны попадать в него. Приложение может перейти на локальную модель, маскированный payload или отказ с понятной ошибкой. Такой fail-closed режим безопаснее, чем молча использовать fallback без проверенной политики.
Для сценариев, где данные нельзя выводить из доверенной зоны вообще, ZDR внешнего API может быть недостаточен по внутренней модели угроз. Тогда сравните внешний маршрут с локальным LLM для 16 ГБ VRAM или другой управляемой инфраструктурой, учитывая собственные логи, обновления и эксплуатацию.
Решение в одной строке
Не спрашивайте «есть ли у провайдера ZDR?». Спрашивайте: «какой точный маршрут, для какого проекта, endpoint, модели и функций не сохраняет content, и чем это доказано?»
Допускайте маршрут только при совпадении официальной eligibility, фактической конфигурации, всей цепочки субпроцессоров и ваших собственных правил удаления. При любом неизвестном слое остановите чувствительный трафик, а не подменяйте доказательство обещанием бренда.
