# Zero Data Retention в OpenRouter: как ограничить допустимые маршруты

Zero Data Retention в OpenRouter: настройки маршрутизации, границы политик провайдера, отдельные инструменты и журналы, а также объявленное обновление условий от октября 2026.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/openrouter-privacy-zdr/
Language: ru

Zero Data Retention в OpenRouter — набор правил и настроек, связанных с обработкой данных при инференсе. Для выбора маршрута нужно изучать текущие условия платформы и конкретного endpoint, а не считать аббревиатуру универсальной гарантией отсутствия любого хранения во всей системе.

Материал проверен 1 ноября 2026 года. Это техническая карта проверки цепочки обработки; решение о допустимости конкретных данных принимается по требованиям вашей организации.

## Разделите участников обработки

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

[Документация ZDR](https://openrouter.ai/docs/guides/privacy/zdr) описывает ограничения маршрутизации и отдельно отмечает границы их действия для инструментов и plugins. Поэтому проверку следует начинать с схемы фактического пути данных. Список участников важнее короткой отметки «ZDR включён» в карточке проекта.

## Сверьте актуальное обновление условий

На странице ZDR размещено уведомление о планируемом обновлении от 27 октября 2026 года. В [официальном объявлении OpenRouter](https://openrouter.ai/blog/announcements/csam-screening/) объясняется проверка проходящего трафика на CSAM и возможность сохранения отмеченных материалов для проверки и предусмотренных процедур. Объявление прямо относится и к ZDR-трафику.

Это существенное уточнение: не следует писать пользователям абсолютное обещание «данные нигде не сохраняются ни при каких обстоятельствах». При оценке соответствия нужно прочитать текущие документы целиком и сохранить их редакцию. Из технического фильтра нельзя выводить юридическое заключение о любом сценарии обработки.

## Проверьте доступные настройки

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

| Участок | Что нужно подтвердить |
| --- | --- |
| Приложение | Состав собственных журналов и доступ к ним |
| Маршрутизатор | Действующие политики и применённые настройки |
| Исполнитель модели | Политику выбранного endpoint |
| Инструмент или plugin | Отдельные условия передачи и хранения |

Запрос, прошедший по допустимому модельному маршруту, всё равно может передавать сведения инструменту с другими правилами, если приложение его включает.

## Используйте нейтральный тестовый набор

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

Условная лаборатория проверяет длинный контекст на синтетическом отчёте. Такой тест подтверждает технические свойства конфигурации в своих пределах. Он не разрешает автоматически переносить закрытые данные проекта на тот же маршрут без согласования требований.

## Зафиксируйте решение и срок пересмотра

Сохраните список участников, применимые документы, настройки и открытые вопросы. Повторно проверяйте их при добавлении инструмента, смене модели или изменении политики. Успешный тест на прошлой версии цепочки не подтверждает новый путь данных.

Далее полезны [сравнение политик роутеров](/ru/journal/router-data-policy-comparison/) и [границы исследовательского GPU-пилота](/ru/journal/research-data-boundaries-gpu/).