Облачные LLM удобны, но не везде применимы. 152-ФЗ, data residency, air-gapped контур, гостайна — в этих случаях отправка промпта с клиентскими данными в api.openai.com — не «риск», а нарушение. Вопрос не «облако или on-prem», а как сохранить управляемый доступ к данным, не выводя их наружу.
On-prem для агентов — это не «поставили модель локально», а весь стек доступа внутри периметра.
Когда облако не подходит
Триггеры для on-prem:
- 152-ФЗ и локализация ПДн — персональные данные граждан РФ должны обрабатываться на территории РФ, с контролируемым доступом;
- Data residency — договор или регулятор требует, чтобы данные не покидали контур компании или страну;
- Air-gapped / закрытый контур — сеть без выхода в интернет, где любой внешний вызов — исключение.
В этих случаях даже «роутинг чувствительных промптов в Azure OpenAI» — компромисс, а не решение: данные всё равно уходят во внешний сервис, пусть и управляемый.
Что меняется on-prem
On-prem меняет транспорт и IdP, но не принципы:
- Транспорт: для локальных агентов — STDIO (креды из окружения, без OAuth), для HTTP внутри периметра — тот же OAuth 2.1 + PKCE и PRM, но с внутренним authorization server;
- Модель: self-hosted LLM (или VPC-развёртывание) внутри контура — промпт не покидает периметр;
- Сеть: нет зависимости от внешнего интернета для каждого вызова — ниже латентность и предсказуемее SLO.
Ошибка — считать, что on-prem «проще, потому что без OAuth». Внутри периметра те же требования: least privilege scope, audience, аудит. Иначе on-prem станет зоопарком с теми же висячими токенами, только локально.
Те же гарантии: права, аудит, DLP внутри
Перенос в периметр не снимает требования к управлению:
- Права: те же узкие scope из
WWW-Authenticate/scopes_supported, выдача по владельцу из каталога; - Аудит: каждый вызов с identity, scope и ресурсом — внутри, с теми же полями для 152-ФЗ и внутреннего комплаенса;
- DLP: инспекция промпта и ответа на той же HTTP-границе, только внутри — с allow/redact/route/block без выхода наружу.
Без этого on-prem — это «облако, только у себя», с теми же утечками, только без внешнего лога.
Гибрид: on-prem для чувствительного, облако для остального
Чаще всего оптимален гибрид:
- чувствительные данные и ПДн — on-prem модель и шлюз внутри;
- несекретные задачи — облако с теми же политиками, но с DLP-роутингом.
Так вы не платите on-prem за всё, но гарантируете, что регулируемые данные не покидают периметр. Политика решает, куда ушёл промпт, а аудит доказывает это.
Где Codenik: управляемый шлюз внутри периметра
Codenik работает и on-prem как тот же управляемый слой: каталог, права, секреты, аудит и DLP внутри контура — без выхода промптов и контекста наружу. Тот же PRM, тот же audience, тот же журнал — только IdP и модель внутри.
Так on-prem не становится «тёмным лесом» без наблюдения, а остаётся управляемым — с теми же SLO и incident response. Подробнее про DLP — в статье «DLP для AI-агентов», про каталог — в «Каталог MCP-инструментов».
Короткий вывод
Выбирайте on-prem, когда регуляция или контур требуют, чтобы данные не покидали периметр. Сохраните те же гарантии — узкие scope, аудит, DLP — просто внутри.
Гибрид «on-prem для чувствительного + облако для остального» даёт и соответствие, и экономику без компромисса по управлению.