Архитектура «Архангела»: реализация автономного мультиагентного ИИ в закрытом контуре
Для предприятий, обрабатывающих чувствительные данные, переход на облачные API генеративного искусственного интеллекта часто невозможен из-за требований комплаенса и безопасности. Статья разбирает архитектуру локальной платформы «Архангел», способной развертываться в полностью изолированном (on-premise) контуре заказчика без выхода во внешнюю сеть.

# Архитектура «Архангела»: реализация автономного мультиагентного ИИ в закрытом контуре
В последние годы корпоративный сектор активно исследует потенциал Agentic AI — систем, где нейросети функционируют не просто как реактивные чат-боты, а как автономные цифровые сотрудники, способные планировать и выполнять комплексные задачи. Однако для крупных энтерпрайз-клиентов, работающих с конфиденциальной юридической или финансовой информацией, использование публичных API от ведущих провайдеров часто становится неоправданным риском. Вопросы комплаенса и защиты данных требуют полной физической и логической изоляции вычислений.
В этой публикации технически детально рассмотрена реализация on-premise платформы мультиагентного искусственного интеллекта под названием «Архангел». Данная система спроектирована для работы в условиях, исключающих любой доступ к внешнему интернету, обеспечивая при этом высокую масштабируемость и предсказуемость бизнес-процессов.
Инфраструктурный слой: полный on-premise в Kubernetes
Ключевым требованием для крупных заказчиков является возможность размещения программного обеспечения внутри их собственного защищенного периметра (on-premise) с управлением через стандартные инструменты эксплуатационных команд (Ops). В реализации «Архангела» был сделан выбор в пользу контейнеризации вместо сложных проприетарных установщиков. Платформа поставляется в виде изолированных Helm-чартов, предназначенных для развёртывания на кластерах Kubernetes клиента. Такой подход обеспечивает предсказуемость развертывания и легкое масштабирование ресурсов в зависимости от нагрузки.
Обеспечение изоляции достигается не методом упаковки, а применением строгих сетевых политик и отсутствием маршрутов к внешним ресурсам. Архитектура инфраструктуры включает следующие критические элементы:
* Окружение типа «воздушный разрыв» (Air-gapped): Все базовые Docker-образы платформы и веса локальных языковых моделей (LLM), таких как семейства Llama или Mistral (адаптированные под специфические задачи), зеркалируются во внутренний приватный реестр заказчика. В качестве хранилищ могут выступать Harbor или Nexus. * Управление состоянием и хранилища: Helm-чарты содержат описания StatefulSet для баз данных и брокеров сообщений. Эти компоненты могут использовать встроенные в Kubernetes хранилища через CSI (Container Storage Interface) или подключаться к существующим кластерам PostgreSQL или Redis, уже работающим внутри контура заказчика. * Сетевые политики: На уровне Kubernetes применяются NetworkPolicies, жестко блокирующие любые исходящие запросы наружу. Важно отметить, что для корректной работы этих политик требуется использование соответствующих CNI (например, Calico или Cilium); использование стандартного Flannel, который по умолчанию пропускает трафик, сделает политики неэффективными.
Оркестрация агентов: паттерн событийной архитектуры
Суть подхода Agentic AI заключается в разделении трудовых функций. Попытка использовать один универсальный агент для решения сложных бизнес-задач часто приводит к ошибкам (галлюцинациям) и низкой эффективности. Вместо этого в системе «Архангел» используется принцип разложения задачи на подзадачи, исполняемые узкоспециализированными агентами. Они обмениваются информацией через асинхронную шину данных.
Оркестрация процессов построена на базе паттерна событийно-ориентированной архитектуры (Event-Driven Architecture, EDA). В качестве центрального узла выступает внутренняя шина событий (Event Bus), развернутая внутри кластера.
Пример сценария работы системы
Рассмотрим кейс анализа рисков по сложному контракту в крупной корпорации:
1. Агент-приёмщик (Ingestion Agent): Получает загруженный документ, парсит его, очищает текст от артефактов и отправляет событие document.parsed в шину данных. 2. Юридический агент (Legal Agent): Подписывается на событие, анализирует текст на предмет семантических коллизий (например, выявляет несоответствия в штрафных санкциях) и публикует событие collision.detected. 3. Финансовый агент (Finance Agent): Реагируя на сигнал о коллизии, рассчитывает потенциальный финансовый ущерб в денежном эквиваленте, используя внутренние исторические данные, и отправляет событие risk.calculated. 4. Агент-интегратор (Integration Agent): Агрегирует артефакты от предыдущих этапов и формирует финальный валидированный ответ в формате JSON, готовый для интеграции с ERP-системами или CRM-платформами.
Благодаря такой архитектуре агенты не блокируют друг друга, а сама система обладает высокой горизонтальной масштабируемостью. Например, при увеличении объема юридических документов Kubernetes может автоматически запустить дополнительные поды с кодом юридического агента.
Безопасность векторов и технология RAG
Для минимизации вероятности галлюцинаций и обеспечения актуальности контекста используется технология RAG (Retrieval-Augmented Generation — генерация с усилением через извлечение данных). В облачных решениях документы часто передаются на сторонние серверы для векторизации, что недопустимо в закрытом контуре. В «Архангеле» этот процесс полностью локализован.
Архитектура векторного слоя включает:
* Локальные эмбеддинг-модели: Перевод текста в векторное представление (числовые массивы, отражающие смысловые связи) производится на выделенных GPU-нодах внутри Kubernetes с использованием легковесных open-source моделей (например, на базе архитектуры BERT). Текст никуда не покидает периметр. * Закрытое векторное хранилище: Сгенерированные векторы нормативных актов и внутренней базы знаний сохраняются в специализированной векторной базе данных (таких как pgvector, Qdrant или Milvus), развернутой в соседстве с остальными компонентами. * Отсутствие внешней синхронизации: База знаний находится в том же изолированном контуре и не синхронизируется с облачными провайдерами. Обновление базы происходит локально: при загрузке нового нормативного акта комплаенс-отдел запускает процедуру локальной переиндексации.
ИИ-агент запрашивает нужный контекст через внутренний API, передаёт его локальной LLM и выдает результат со ссылками на источники, оставляя финальное решение за человеческим специалистом.
Заключение
Создание Agentic AI для корпоративного сектора представляет собой сложный инженерный вызов, требующий глубокой проработки вопросов инфраструктуры и безопасности, прежде чем переходить к тонкостям Data Science. Благодаря использованию Helm-чартов, событийно-ориентированной оркестрации агентов и полной локализации векторных хранилищ, платформа «Архангел» обеспечивает предсказуемую работу без исходящего трафика за периметр.
Стоит отметить, что абсолютно безопасной систему сделать невозможно, но поверхность атаки в данной архитектуре фундаментально отличается от облачных интеграций, предлагая уровень защиты, соответствующий требованиям регулируемых отраслей. Эта модель демонстрирует, как передовые технологии искусственного интеллекта могут эффективно работать в условиях строжайшей изоляции, становясь надежным инструментом для внутренней цифровой трансформации крупных предприятий.