В последнее время бизнес активно смотрит в сторону Agentic AI — систем, где нейросети не просто отвечают на промпты в чате, а действуют как автономные цифровые сотрудники.

Когда речь заходит о крупном Enterprise, комплаенсе и работе с чувствительными данными (например, юридическими или финансовыми документами), облачные API от OpenAI или Anthropic сразу становятся стоп-фактором. Безопасность требует полной изоляции.

В этой статье я технически разберу, как мы спроектировали и реализовали On-Premise платформу мультиагентного ИИ «Архангел», способную работать без доступа к внешнему интернету.

1. Поставка и инфраструктурный слой: полный On-Premise в Kubernetes

Для крупных заказчиков критически важно, чтобы софт разворачивался в их собственном закрытом периметре (On-Premise) и управлялся стандартными для их Ops-команд инструментами. Мы отказались от сложных проприетарных установщиков в пользу контейнеризации.

Мы поставляем платформу «Архангел» в виде изолированных Helm-чартов для Kubernetes-кластера заказчика. Это даёт предсказуемое разворачивание и лёгкое масштабирование под нагрузкой. Изоляцию при этом обеспечивает не сама упаковка, а сетевые политики и отсутствие маршрута наружу — об этом ниже.

Как это устроено на уровне инфраструктуры:

- Air-gapped окружение. Все базовые Docker-образы платформы и веса локальных LLM (например, семейств Llama или Mistral, адаптированных под наши задачи) зеркалируются во внутренний приватный реестр (Private Registry) заказчика — Harbor или Nexus.

- Стейт и хранилища. Внутри Helm-чартов описаны StatefulSet'ы для баз данных и брокеров сообщений, которые могут использовать как внутренние K8s-хранилища (через CSI), так и подключаться к уже существующим в контуре заказчика кластерам PostgreSQL или Redis.

- Сетевые политики (NetworkPolicies). На уровне Kubernetes жёстко блокируются любые исходящие запросы во внешнюю сеть. Важная оговорка: политики требуют CNI с их поддержкой (Calico, Cilium) — на голом Flannel манифест применится и не сделает ничего, это стоит проверять тестом. Вся работа происходит строго внутри приватного контура.

2. Оркестрация агентов: как ИИ-сотрудники общаются между собой

Суть Agentic AI — в разделении обязанностей. Один универсальный агент не может эффективно решать комплексные бизнес-задачи без галлюцинаций. В «Архангеле» задача дробится на подзадачи, которые выполняют узкоспециализированные ИИ-агенты, общающиеся через асинхронную шину данных.

Мы построили оркестрацию на базе паттерна Event-Driven Architecture (EDA). Роль центрального нервного узла выполняет внутренняя шина данных (Event Bus), развёрнутая внутри кластера.

Сквозной пример работы мультиагентной системы

Давайте разберём реальный бизнес-кейс: крупная компания загружает в систему проект сложного договора для анализа рисков.

1. Агент-приёмщик (Ingestion Agent). Парсит документ, очищает текст от мусора и отправляет событие document.parsed в шину данных.

2. Юридический агент (Legal Agent). Подписывается на это событие, берёт текст, проводит семантический анализ и находит скрытую юридическую коллизию (например, некорректно описанные штрафные санкции). Он публикует в Event Bus структурированное сообщение collision.detected.

3. Финансовый агент (Finance Agent). Реагирует на событие коллизии. Его задача — рассчитать потенциальный финансовый риск в денежном эквиваленте на основе внутренних исторических данных компании. Он проводит калькуляцию и отправляет событие risk.calculated.

4. Агент-интегратор (Integration Agent). Собирает артефакты от предыдущих агентов, агрегирует данные и формирует финальный строго валидированный JSON-ответ для ERP-системы заказчика (или CRM-систем вроде 1С / Битрикс24).

Благодаря такому подходу агенты не блокируют друг друга, а сама система легко масштабируется горизонтально: если юридических документов становится больше, Kubernetes просто поднимает дополнительные поды с юридическим агентом.

3. Безопасность векторов и RAG: локальное хранилище знаний

Чтобы снизить долю галлюцинаций и заставить ИИ-агентов оперировать актуальным контекстом компании (нормативными актами, регламентами, архивом документов), мы используем технологию RAG (Retrieval-Augmented Generation).

В облачных решениях ваши документы отправляются на сторонние сервисы для векторизации и хранения. В «Архангеле» этот процесс полностью локализован.

Архитектура безопасности векторного слоя:

- Локальные эмбеддинг-модели. Перевод текста в векторное представление (числовые массивы, отражающие смысл фраз) происходит на выделенных GPU-нодах внутри того же Kubernetes-кластера с помощью легковесных open-source моделей (например, на базе архитектуры BERT). Ни один байт текста не уходит вовне.

- Закрытое векторное хранилище. Сгенерированные векторы нормативных актов и внутренней памяти компании сохраняются в специализированную векторную базу данных (например, pgvector, Qdrant или Milvus), развёрнутую по соседству.

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

ИИ-агент получает доступ к «памяти» компании через быстрый внутренний API-запрос к векторной БД, извлекает нужный контекст, передаёт его локальной LLM и выдаёт результат со ссылками на конкретные источники — финальное решение остаётся за юристом.

Заключение

Создание Agentic AI для Enterprise — это в первую очередь вызов для инфраструктуры и безопасности, а уже потом — для Data Science. Обернув платформу в Helm-чарты, настроив событийно-ориентированное взаимодействие агентов через Event Bus и изолировав векторные базы данных, мы получили систему, которая работает предсказуемо и не требует ни одного исходящего пакета за периметр. Абсолютно безопасной я её называть не буду — таких не бывает, — но поверхность атаки здесь принципиально другая, чем у облачной интеграции, и это ровно то, за что платят заказчики из регулируемых отраслей.

Если у вас появились вопросы по архитектуре распределённых ИИ-систем или интеграции локальных LLM с корпоративными шинами данных — буду рад обсудить в комментариях!