On-prem AI и 152-ФЗ — как развернуть AGONTS в своём контуре

К нам приходят с двух сторон. С одной — фаундер с двумя ноутами и желанием «попробовать AI быстро». С другой — CIO крупного производства, у которого корпоративная политика безопасности на 80 страниц и явный запрет на внешние SaaS под персональные данные. Этот пост — про вторую сторону.

Что такое on-prem AGONTS

«On-prem» — это разворачивание платформы целиком на инфраструктуре заказчика. Никаких внешних соединений, никакой телеметрии в наше облако, никакого трафика модели в OpenAI/Anthropic. Всё работает в вашем периметре: API, веб-приложение, очереди Redis, Postgres, MinIO для файлов, Qdrant для векторного поиска и сама LLM (vLLM, llama.cpp, Ollama).

Технически это Docker-Compose или Kubernetes-манифест. На обычном сервере с 2× A100 / H100 (или 4× RTX 4090) запускается одна нода, обслуживающая 50–200 сотрудников и тысячи диалогов в день. На больших объёмах — кластер.

Почему это важно для 152-ФЗ

ФЗ-152 «О персональных данных» среди прочего требует:

• Локализации обработки ПДн граждан РФ на территории России (ст. 18, ч. 5).
• Согласия субъекта на трансграничную передачу.
• Защиты ПДн при автоматизированной обработке — прозрачность алгоритмов и право на пересмотр решения.

Если ваш AI-сотрудник тащит фрагменты карточек клиентов в OpenAI или Anthropic — это трансграничная передача в третьи страны. Юридически это требует согласия субъекта на отдельной строке, фактически — мало кто это делает. Регулятор пока не штрафует за такое массово, но прецеденты уже есть, и в 2026 году вектор внимания к LLM-провайдерам очевиден.

On-prem-вариант снимает вопрос: данные физически не выходят из вашего ЦОД.

Локальные LLM, которые мы поддерживаем

На нашей собственной машине (cards-vm в внутренней сети) мы крутим связку:

• Gemma 3 12B Instruct — основная рабочая модель. Думает, отвечает на русском, понимает русский кейс лучше, чем многие коммерческие.
• Qwen 3 32B — для тяжёлых задач с длинным контекстом.
• DeepSeek V3 — кодинг и SQL-генерация.
• Embeddings — bge-m3 локально, для RAG-поиска по документам.
• STT/TTS — Whisper-Large + Silero TTS.

Всё это OpenAI-совместимое (через llama.cpp server или vLLM), поэтому на стороне платформы работает тот же код, что и для облачной OpenAI. Разница только в base URL и api-key.

Если у заказчика своё железо или своя любимая модель (например, GigaChat от Сбера, YandexGPT) — мы поддерживаем любой OpenAI-совместимый endpoint. На последнем enterprise-проекте крутили YandexGPT 5 Pro поверх локального YandexCloud private deployment — работало стабильно.

Что видит ваша служба безопасности

Когда мы разворачиваем on-prem, это обычно проходит через ИБ-аудит. Вот что им нужно показать:

• Сетевая схема: только внутренние подсети. Наружу через прокси с allowlist (если хочется тянуть обновления embeddings и веса моделей).
• Реестр компонентов: все open-source с MIT/Apache-2 лицензиями, никаких закрытых бинарников. Полный SBOM в комплекте.
• Аудит-лог: каждый запрос к LLM, каждый MCP-инструмент, каждое решение модели логируются в platform_audit_logs с retention по политике клиента (минимум 6 месяцев — стандарт под 152-ФЗ).
• RBAC: тонкая ролевая модель, кто из ваших сотрудников может видеть/менять что.
• Encryption-at-rest: секреты (API-ключи MCP, TOTP, ключи к LLM) шифруются AES-256-GCM. Ключ — из переменной окружения, не из БД.
• Backups: restic-pipeline пишет в две параллельные локации (локальная + offsite через SFTP/S3-совместимое хранилище). Скрипты в scripts/ops/backup/.

Что НЕ работает on-prem

Честно про ограничения:

• Облачные LLM — очевидно, OpenAI и Anthropic локально не запускаются. Если проект требует именно GPT-5 — ставится опциональный egress через ваш прокси к одобренному списку endpoints, и в инструкции сотрудника прописывается, какие данные не отправлять наружу.
• Голосовая телефония через внешний SIP — мы можем дать вам собственный SIP-стек, но если нужен оператор связи в РФ для голоса, это всё равно outbound к нему.
• Telegram/WhatsApp — это всегда внешние API. Мессенджер-канал не может быть on-prem по определению. Если корпорат жёстко запретил мессенджеры — остаются голос, email, виджет на корпоративном сайте, MS Teams.

Как мы это разворачиваем

Через интегратора. У нас есть партнёр-программа, обычно проект идёт так:

1. Архитектурная сессия (2–3 дня): что подключаем, какие данные, какие требования ИБ.
2. Pilot (4–6 недель): развёртывание в тестовой подсети, два сценария на проверку, обучение нескольких операторов.
3. Production (2–4 недели после пилота): миграция в продуктив, интеграция с MES/ERP/LIMS через MCP, аудит ИБ.
4. SLA-поддержка: 24/7, RTO 4 часа, RPO 1 час.

Стоимость лицензии — от 450 000 ₽/мес за on-prem с базовым SLA, плюс работа интегратора. Для крупных энтерпрайзов есть perpetual license с разовой оплатой.

Кому это подходит

• Производственные компании с MES/ERP и 152-ФЗ-обязательствами.
• Госкорпорации и компании, выходящие на КИИ-инфраструктуру.
• Финтех с банковской лицензией и требованиями ЦБ по локализации.
• Медицинские холдинги с врачебной тайной.
• Компании, у которых корпоративная политика безопасности явно запрещает SaaS под data, не классифицированную как public.

Кому это не подходит

• Стартапам и SMB до 100 человек — overkill, дорого и медленно. Для вас работает облачный AGONTS с шифрованием и стандартными SLA.
• Сценариям, где данных условно нет (генерация креативов, переводы) — там нет смысла в локальной установке.

Что попробовать сначала

Если вы CIO и читаете это — прежде чем заказывать pilot, заведите облачный аккаунт, прокатайте сценарий на синтетических данных, поймите, что хотите получить. Только после этого имеет смысл разговор про on-prem. Развернуть локально что-то, что ещё не работает в облаке, — типичная ошибка, которая раздувает проект на месяцы.

Если уже определились — напишите нам через форму партнёра, передадим интегратору в вашем регионе.