RAG (Retrieval-Augmented Generation) даёт языковой модели доступ к корпоративной базе знаний: модель отвечает не из памяти, а по найденным документам. Для бизнеса и госсектора это удобно и одновременно опасно. Если запросы, эмбеддинги или фрагменты документов уходят во внешнее облако, вы теряете контроль над тем, где осели договоры, персональные данные и техническая документация. Закрытый контур снимает этот риск, но требует пересборки всей архитектуры. Разберём, как сделать это без утечек.

Где утекают данные в типовом RAG

В наивной схеме данные покидают периметр в трёх точках. Первая – эмбеддинги: текст документов и пользовательские запросы отправляют в облачный API векторизации. Второе – сама генерация: запрос вместе с найденными фрагментами уходит во внешнюю LLM. Третье – телеметрия и логи SDK, которые незаметно собирают содержимое промптов.

Каждая из этих точек для КИИ и обработчиков персональных данных – нарушение. Облачные модели крупных вендоров недоступны на условиях, приемлемых для российского регулятора, а с учётом курса на технологический суверенитет полагаться на них нельзя в принципе. Логика та же, что и в запрете иностранного ПО на объектах КИИ: данные и инструменты должны оставаться внутри управляемого периметра.

Архитектура закрытого контура

Базовый принцип – ни один байт корпоративных данных не покидает изолированную сеть. Это значит, что все компоненты конвейера работают локально:

  • Модель эмбеддингов разворачивается on-premise. Для русского языка хорошо показывают себя многоязычные энкодеры семейства E5 и BGE, которые запускаются на GPU внутри контура.
  • Векторное хранилище (Qdrant, Weaviate, pgvector) ставится на собственные серверы, без управляемых облачных инстансов.
  • Генеративная LLM – открытая модель (например, из линеек Llama, Qwen, Saiga для русского) на собственном GPU-кластере. Никаких внешних API.
  • Оркестрация – сервис, который связывает поиск и генерацию, отключает телеметрию фреймворков и пишет аудиторские логи внутри периметра.

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

Контроль доступа и защита от утечек

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

Дальше – защита от утечек через сам ответ. Помогают редактирование персональных данных на этапе индексации, проверка ответов на наличие чувствительных сущностей и полное логирование пар «запрос – источники» для разбора инцидентов. Эти меры встраивают не поверх готовой системы, а в проектную дорожную карту с самого начала – по той же логике, что и дорожная карта приведения КИИ в соответствие.

Вывод

RAG в закрытом контуре – это не урезанная версия облачного сервиса, а отдельная инженерная задача: локальные модели, изолированное хранилище, контроль доступа на уровне поиска и аудит. Собранная так система даёт бизнесу и госсектору точные ответы по своим данным, не отдавая их наружу. Всё это сводится к проектированию и внедрению интеллектуальных систем под конкретный периметр и регуляторные требования.