Корпоративная AI-платформа

Без явной access-зоны AI-платформа превращается в общий чат без владельцев, ролей и понятной границы входа.

Доступ отделен от frontend, чтобы менять SSO, VPN, API-токены и группы без перепроектирования пользовательского интерфейса.

Контроль пользователей, разделение ролей, подключение корпоративных каналов и возможность закрыть платформу внутри нужного контура.

Единый вход, least privilege, audit и разделение admin/user-сценариев удерживают доступ управляемым даже при нескольких каналах входа.

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

Frontend не должен напрямую знать, какая модель или tool реально выполнит запрос; он передает задачу в policy/gateway-слои.

Снижает хаос из разных чатов и клиентов, дает единый UX и позволяет подключать разные backend-сценарии без переобучения пользователей.

Frontend остается легким рабочим местом: без секретов и прямых model endpoints, с передачей запросов в gateway и role-based доступом.

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

Firewall вынесен отдельно, чтобы политики безопасности жили независимо от frontend, RAG, tools и конкретного LLM backend.

Блокирует опасные инструкции, ограничивает tool-вызовы, проверяет ответы, маскирует чувствительные данные и оставляет трассу решения.

Политики применяются по этапам: вход, контекст, tool-output и ответ модели проходят классификацию, audit и управляемый ручной override.

Без gateway вся логика выбора модели, контекста, инструментов и fallback расползется по frontend и backend-сервисам.

Отдельный gateway позволяет централизованно управлять маршрутизацией: локальная модель, серверный runtime, OpenRouter или другой внешний API.

Мультимодельность, tenant-политики, fallback, rate limits, управление контекстом и предсказуемое подключение новых провайдеров.

Маршруты закрепляются через data classification, provider allowlist, quotas и logs, чтобы выбор backend был предсказуемым и проверяемым.

Разные задачи требуют разных моделей: где-то важна приватность, где-то скорость, стоимость, качество reasoning или доступ к hosted/open models.

LLM backend отделен от gateway, чтобы можно было менять runtime, GPU-пул или внешнего провайдера без переписывания интерфейса.

Закрывает локальные и облачные сценарии, разделяет sensitive/open workloads и дает путь к OpenRouter для открытых моделей.

Runtime-профили, health checks, fallback и мониторинг latency/GPU/RAM помогают разделять sensitive/open workloads и держать SLA.

LLM сама по себе не знает актуальные корпоративные документы, регламенты, проекты и внутренние решения.

RAG вынесен отдельной зоной, чтобы knowledge pipeline масштабировался и проверялся независимо от frontend и model runtime.

Дает ответы по актуальным источникам, снижает hallucination, позволяет ссылаться на документы и обновлять знания без fine-tuning.

Reindex, source scoring, document-level ACL и проверка качества retrieval поддерживают актуальность контекста и корректные ссылки на источники.

Без tools AI только отвечает текстом. С tools он может найти issue в Redmine, открыть PR, проверить статус, создать заявку или запустить workflow.

Gateway строит tool call, проверяет права, вызывает MCP/OpenAPI/HTTP tool, получает результат или stream событий и возвращает его в LLM как контролируемый контекст.

Связывает LLM с реальными процессами, сохраняет контроль над side effects и дает трассируемую автоматизацию вместо ручного копирования между системами.

Scopes, read/write separation, approval, dry-run, rollback и audit trail делают tool-вызовы управляемыми и понятными для владельцев процессов.

Внешние модели, OpenRouter, внешние API, webhooks и web-поиск требуют контролируемого outbound-доступа, иначе каждый сервис начинает выходить наружу по-своему.

AI Gateway или tools отправляют внешний запрос через egress policy. Дальше secure gateway выбирает разрешенный маршрут: корпоративный provider/SWG/SASE/VPN или Docker proxy.

Единая точка outbound-контроля, allowlist внешних endpoints, разделение sensitive/open workloads, аудит внешних вызовов и предсказуемое подключение провайдеров.

Domain allowlist, DNS policy, rate limits, egress logs, secret isolation и network policy показывают, куда реально уходит трафик и кто инициировал вызов.

Без логов, метрик и evaluation невозможно понять, почему платформа дала такой ответ или почему выбран такой backend.

Observability проходит через все зоны: access, frontend, firewall, gateway, RAG, tools и backend должны оставлять связанный trace.

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

Redaction, retention policy, role-based access и отдельный audit trail позволяют хранить эксплуатационные данные аккуратно и проверяемо.