32 
Содержание
Разберёмся, как обеспечить приватность данных в OpenRouter и держать доступ под контролем в команде. Для бизнеса это два главных вопроса к любому LLM-шлюзу: не утекут ли промпты и как ограничить, кто и сколько может тратить. OpenRouter отвечает на оба набором инструментов: политики данных и ZDR, свой ключ провайдера по схеме BYOK, рабочие пространства и ключи с лимитом и белым списком IP. Часть проверим кодом на стенде, часть разберём по документации с готовыми шаблонами запросов.
Что важно бизнесу в приватности
Когда запрос уходит к модели, он проходит через провайдера, и вопрос в том, что провайдер с ним делает. Одни не хранят ничего, другие могут логировать. Вторая сторона это контроль внутри команды: у каждого сервиса должен быть свой ключ, свой потолок расхода и понятный след, кто что потратил. OpenRouter закрывает обе стороны, и ниже мы пройдём по ним по порядку.
Пример из жизни. У вас чат-бот на сайте и внутренний ассистент по документам. Первому хватит обычных провайдеров. Второй работает с чувствительными данными и требует строгого режима. Эти два случая можно развести по политике и по ключам, не меняя код.
Если вы ещё не выпустили ключ, начните со статьи про старт с OpenRouter. Управление провайдером мы затрагивали в статье про маршрутизацию, здесь смотрим на него под углом приватности. Материал ориентирован на техлидов и команды, которым важен контроль, а не только первый запрос.
Дальше по каждому элементу этой схемы отдельно: политика данных, свой ключ, пространства и лимиты.
ИИ-агенты для оптимизации бизнес-процессов
Код курса
AGENT
Ближайшая дата курса
26 октября, 2026
Продолжительность
24 ак.часов
Стоимость обучения
66 000
ZDR и политики данных
ZDR это режим нулевого хранения: провайдер не сохраняет ни запрос, ни ответ. В аккаунте OpenRouter можно задать политику данных, и роутер будет отправлять запросы только к тем провайдерам, что ей удовлетворяют. Тот же выбор доступен и в самом запросе через поле data_collection.
Уровней у политики два. В аккаунте это глобальная настройка на все запросы. В запросе это поле data_collection. Значение allow пускает провайдеров с логированием, deny оставляет только тех, кто ничего не хранит. Строгий режим так включается точечно, где он нужен.
Маршрутизация только через провайдеров без хранения
Значение data_collection равное deny исключает провайдеров, которые собирают данные. Проверим на одной модели: с ограничением и без него запрос уходит к разным провайдерам.
Все примеры кода используемый в статье вы можете посмотреть на нашем GitHub репозиторий
# протестировано на EU-ноде (AWS Stockholm) 2026-08-04: Python 3.12.3, httpx 0.28.1, OpenRouter API
import os, httpx
key = os.environ["OPENROUTER_API_KEY"]
H = {"Authorization": f"Bearer {key}"}
MODEL = "meta-llama/llama-3.3-70b-instruct"
def who(extra):
# Один и тот же запрос, разные настройки провайдера. Возвращаем, кто обслужил.
p = {"model": MODEL, "messages": [{"role": "user", "content": "ок"}], "max_tokens": 5}
p.update(extra)
return httpx.post("https://openrouter.ai/api/v1/chat/completions", headers=H, json=p, timeout=60).json()["provider"]
# data_collection="deny": исключаем провайдеров, которые сохраняют промпты.
print("data_collection=deny ->", who({"provider": {"data_collection": "deny"}}))
# Без ограничения политики данных провайдером может стать кто угодно.
print("без ограничения ->", who({"provider": {"sort": "throughput"}}))
data_collection=deny -> Nebius без ограничения -> Groq
С deny запрос ушёл к провайдеру из списка тех, кто не хранит данные, без ограничения роутер выбрал по скорости. Так политику приватности можно применять точечно на уровне запроса, а не только глобально. Полный сценарий в файле privacy_routing.py.
Что значит не хранит на практике. Провайдер обрабатывает запрос в памяти. В логи он его не пишет и у себя не оставляет. Для аудита это ключевой момент. Строгий режим разумно держать по умолчанию для всего, что касается персональных или коммерческих данных.
BYOK, свой ключ провайдера
BYOK это Bring Your Own Key: вы подключаете собственный ключ провайдера, а OpenRouter лишь маршрутизирует через него. Промпты идут по вашему договору с поставщиком, а вы сохраняете прямые отношения, скидки и лимиты провайдера. По условиям на дату проверки первый миллион BYOK-запросов в месяц бесплатен, дальше OpenRouter берёт 5 процентов от того, во сколько тот же вызов обошёлся бы на платформе. На тарифе Enterprise бесплатный порог выше, до пяти миллионов запросов в месяц.
Ключи провайдеров добавляются в настройках аккаунта, а управлять ими можно и программно через отдельный API. Это удобно, когда ключей много и их надо раздавать по рабочим пространствам.
Зачем это компании. У вас уже есть договор с поставщиком и свои цены. BYOK их сохраняет, а OpenRouter добавляет маршрутизацию и единый интерфейс поверх. Данные идут по вашему каналу, а не через чужой счёт. Прямые скидки и лимиты провайдера тоже остаются вашими.
Рабочие пространства и scoped-ключи
Рабочие пространства делят аккаунт на изолированные окружения. У каждого пространства свои ключи и свой BYOK, так что команды и проекты не мешают друг другу. Ключи при этом бывают ограниченными: с потолком расхода и с белым списком IP.
Для команды это снимает бардак с ключами. У каждого проекта своё пространство и свои креды. Уволился человек или скомпрометировался сервис, и вы гасите его ключ, не трогая остальных. Общий баланс при этом защищён лимитами.
Ключ с лимитом и белым списком IP
Выпуск таких ключей идёт через Provisioning API и требует management-ключа. На стенде статьи его нет, поэтому ниже проверенный шаблон запроса, а не прогон: без management-ключа эндпоинт отвечает кодом 401.
# шаблон для OpenRouter Provisioning API (проверено 2026-08-04): требует management-ключ.
# Без management-ключа эндпоинт /api/v1/keys отвечает 401, поэтому это форма запроса, а не прогон.
import os, httpx
# Здесь нужен именно management (provisioning) ключ, а не обычный ключ инференса.
mgmt = os.environ["OPENROUTER_PROVISIONING_KEY"]
# Выпускаем ключ с ограничениями: имя, потолок расхода и белый список IP.
payload = {
"name": "service-bot", # понятное имя ключа
"limit": 50, # потолок расхода в долларах
"include_byok_in_limit": False, # BYOK-трафик не учитывать в лимите
"allowed_ips": ["203.0.113.10"], # запросы только с этих адресов
}
r = httpx.post(
"https://openrouter.ai/api/v1/keys",
headers={"Authorization": f"Bearer {mgmt}"},
json=payload,
timeout=30,
)
r.raise_for_status()
print("создан ключ с лимитом и IP-allowlist:", r.json().get("name"))
Смысл в том, что скомпрометированный ключ бесполезен вне разрешённых адресов: запрос с чужого IP отклоняется с кодом 403. Плюс у каждого ключа свой потолок, поэтому один сервис не съест бюджет всего аккаунта. Полный шаблон в файле scoped_key.py.
Ключи стоит регулярно ротировать. Выпустили новый, перевели сервис, старый отозвали. Через Provisioning API это делается скриптом, а не руками. Для боевых систем это обычная гигиена.
Контроль расхода по ключу
Даже без management-ключа расход по обычному ключу виден через API. Эндпоинт /auth/key отдаёт лимит, признак free-tier и траты в разрезах. На эти числа удобно повесить алерт или дашборд для комплаенса.
# протестировано на EU-ноде (AWS Stockholm) 2026-08-04: Python 3.12.3, httpx 0.28.1, OpenRouter API
import os, httpx
key = os.environ["OPENROUTER_API_KEY"]
# /auth/key отдаёт метаданные конкретного ключа: лимит, тариф и расход.
d = httpx.get(
"https://openrouter.ai/api/v1/auth/key",
headers={"Authorization": f"Bearer {key}"},
timeout=15,
).json()["data"]
# limit=None означает, что жёсткого потолка нет и расход упирается только в баланс.
print("limit:", d["limit"])
print("is_free_tier:", d["is_free_tier"])
print(f"usage: {d['usage']:.5f}")
print(f"usage_daily: {d['usage_daily']:.6f}")
limit: None is_free_tier: False usage: 5.89960 usage_daily: 0.000037
Здесь на ключе нет жёсткого лимита, поэтому потолок только по балансу. В команде разумно выпускать ключи с лимитом, тогда это поле сразу показывает остаток. Полный сценарий в файле key_usage.py.
На практике это вешают на расписание. Раз в час скрипт читает расход и шлёт алерт при подходе к лимиту. Перерасход так ловится заранее, а не по факту. Те же числа удобно складывать в дашборд для отчётности.
Для учёта и комплаенса поверх этого работают классификаторы: OpenRouter умеет помечать трафик, чтобы разносить расход по проектам и командам. Вместе со scoped-ключами это даёт понятную картину, кто и на что тратит.
ИИ-агенты для оптимизации бизнес-процессов
Код курса
AGENT
Ближайшая дата курса
26 октября, 2026
Продолжительность
24 ак.часов
Стоимость обучения
66 000
Что дальше в серии
Итог такой. Приватность в OpenRouter это политика данных и ZDR на уровне запроса, свой ключ провайдера по BYOK и контроль доступа через рабочие пространства и ограниченные ключи. Расход виден по каждому ключу, а классификаторы раскладывают его по командам. Возражения про утечку данных и контроль в команде это закрывает. В следующей и заключительной статье серии сравним OpenRouter с альтернативами: self-hosted LiteLLM, прямые подключения к провайдерам и российские шлюзы, и выведем простую схему выбора.
