Когда компания обсуждает корпоративный ИИ, разговор часто начинается с модели: какая точнее, быстрее или дешевле. Но для рабочего внедрения не менее важны другие вопросы: где обрабатываются данные, кто управляет средой, какие системы можно подключить и кто отвечает за обновления. Один и тот же сценарий может потребовать разной архитектуры в разных организациях.
Ниже — способ сравнить варианты без обещания, что один из них подходит всем. Архитектурные варианты не равны перечню уже доступных конфигураций Yasnora: статус продукта указан отдельно.
Сначала нарисуйте путь данных
Возьмите один конкретный процесс — например, ответы по внутренним инструкциям. Отметьте источник документов, место хранения индекса, место выполнения поиска, модель, журналы, получателя ответа и людей, которые могут менять настройки. Если часть обработки проходит за пределами вашей инфраструктуры, это должно быть видно на схеме, а не оставаться за словом «гибрид».
Проверьте право на использование каждого источника. Для клиентских данных, коммерческой тайны и персональных данных условия доступа и обработки могут различаться. Размещение само по себе не доказывает соответствие требованиям: нужны конкретная конфигурация, договорённости и проверка.
Четыре архитектурных варианта
Управляемое облако. Поставщик ведёт сервисную инфраструктуру, а команда клиента начинает с аккаунта, настроек доступа и ограниченного пилота. Это уменьшает собственную эксплуатационную нагрузку, но требует проверить маршруты данных, интеграции, доступность сервиса и договорные условия. Управляемый SaaS Yasnora помечен как Beta; публичной гарантии высокой доступности или SLA нет.
Customer Cloud. Компоненты размещаются в облачной среде, которой управляет заказчик или которую он выделяет под проект. Это может дать больше контроля над сетью и интеграциями, но создаёт работу для команды эксплуатации: доступы, обновления, наблюдение, резервирование. В актуальном каталоге Yasnora частный облачный и выделенный клиентский контуры имеют статус Planned. Здесь это вариант для технического обследования, а не готовая поставка.
On-premise. Компоненты работают в инфраструктуре заказчика. Нужно заранее определить вычислительные ресурсы, допустимые модели, обновления, мониторинг, восстановление и исходящие соединения. On-Prem Yasnora обозначен как Beta; упаковка предусматривает закрытый по умолчанию исходящий доступ, но подписанные артефакты и проверка восстановления в контуре заказчика ещё требуются. On-premise нельзя автоматически назвать безопасным или соответствующим любому стандарту.
Hybrid. Часть компонентов остаётся внутри, другая работает в облаке. Например, локальный поиск по разрешённым документам может сочетаться с удалённым выводом модели, если правила обработки это допускают. Такая схема добавляет границы сети, задержки, наблюдение и согласование ответственности. Это иллюстрация архитектуры, а не заявленный универсальный профиль Yasnora.
| Критерий | Управляемое облако | Customer Cloud | On-premise | Hybrid |
|---|---|---|---|---|
| Начало пилота | Обычно меньше работы с инфраструктурой | Нужна подготовка среды | Нужны локальные ресурсы и установка | Нужны обе стороны и их соединение |
| Эксплуатация | Основная сервисная часть у поставщика | По договорённости, значительная роль заказчика | В основном у заказчика | Разделённая ответственность |
| Контур данных | Проверяется по маршрутам и условиям | Определяется конфигурацией облака заказчика | Определяется локальной конфигурацией | Зависит от каждого потока |
| Интеграции | По доступным и разрешённым подключениям | Через согласованную сеть и доступы | Через внутренний контур | Через обе границы |
| Масштабирование | Зависит от сервиса и плана | Зависит от ресурсов облака заказчика | Зависит от локальных ресурсов | Сложнее прогнозировать заранее |
| Главный вопрос | Достаточны ли правила обработки? | Кто ведёт среду и обновления? | Есть ли команда и ресурсы? | Какие данные пересекают границу? |
Эта таблица показывает типичные инженерные последствия, а не сравнительный рейтинг продукта.
Десять вопросов для выбора
- Какие данные ИИ должен читать и где разрешено их обрабатывать?
- Нужно ли хранить исходные файлы, индекс и историю в одном контуре?
- С какими внутренними системами нужен обмен — чтение или запись?
- Кто отвечает за установку, ключи, обновления и инциденты?
- Есть ли доступные GPU/вычислительные ресурсы и специалисты по ним?
- Какая задержка приемлема в конкретном процессе?
- Какие требования к доступности и восстановлению закреплены договором?
- Как часто меняются модели, инструкции и источники знаний?
- Нагрузка постоянная или возникает пиками?
- Что действительно нужно настраивать под компанию: модель, правила, источники, интерфейс?
Начните с одного процесса и одного владельца решения. Зафиксируйте разрешённые данные, критерии качества и способ проверки результата. После пилота появится основание обсуждать профиль размещения, стоимость эксплуатации и договорные обязательства, а не выбирать их по названию.
Если в процессе участвует агент, дополнительно разделите право прочитать данные и право изменить их. Разбор прав и контроля AI-агента помогает составить эту часть схемы.
Обсудить архитектуру Yasnora для компании. Команда «Виксора» может рассмотреть требования и подходящий пилот; конкретная конфигурация и условия подтверждаются отдельно.
