«Он же локальный» — не модель угроз

Локальный RAG часто представляют как аккуратный шкаф: документы внутри офиса, модель тоже внутри, значит всё уже безопасно. В реальности шкаф может стоять в серверной, а его виртуальный ключ — подходить ко всем дверцам сразу. Если поиск не учитывает права пользователя, сотрудник задаст вполне невинный вопрос и получит фрагмент чужого договора, зарплатную ведомость или переписку соседнего проекта.

Сам факт локального размещения снижает часть рисков передачи данных внешнему провайдеру, но не отменяет аутентификацию, авторизацию, аудит и минимальные привилегии. NIST в архитектуре Zero Trust прямо рекомендует не давать неявное доверие только из-за сетевого расположения. Сервер «у нас в контуре» — это адрес, а не пропуск.

Хорошая новость: разграничение доступа в RAG не требует учить модель говорить «предъявите удостоверение». Права должны проверяться обычным кодом до того, как документы попадут в контекст модели. Языковая модель в этой схеме отвечает на вопрос, но не работает вахтёром. У неё слишком богатое воображение и нет штатного бейджа.

Где обычно открывается лишняя дверца

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

Есть и менее очевидные варианты:

  • право проверяется после поиска, но запрещённый текст уже попал в журнал, трассировку или контекст модели;
  • доступ описан словами в системном промпте: «не показывай финансы сотрудникам продаж»;
  • фильтр применён к документу, но потерян при разбиении на чанки;
  • сотрудника удалили из группы, а индекс или кэш продолжает жить со старым набором прав;
  • ответы кэшируются только по тексту вопроса, поэтому результат директора получает следующий пользователь с таким же запросом;
  • один технический аккаунт RAG имеет права администратора ко всем источникам, хотя пользователю нужна одна папка;
  • агент умеет не только читать, но и отправлять файлы, а подтверждение человека для этого действия не требуется.

OWASP отдельно предупреждает: RAG и дообучение не устраняют prompt injection. Инструкция внутри загруженного документа может попытаться изменить поведение модели или подтолкнуть её к запросу приватного источника. В рекомендациях OWASP контроль привилегий предлагается реализовывать в коде, выдавать приложению минимальные права и требовать человеческое подтверждение для рискованных действий. Системный промпт — памятка, а не замок.

Базовая архитектура: сначала пропуск, потом сходство

Надёжный запрос проходит последовательную цепочку.

1. Пользователь аутентифицируется через корпоративный провайдер идентификации. Приложение получает стабильный идентификатор, организацию, роли и группы, а не верит полям, присланным браузером.
2. Политический слой рассчитывает допустимую область: tenant, подразделение, проект, класс документа и срок действия доступа.
3. Векторный или гибридный поиск получает эту область как обязательный серверный фильтр. Сначала исключаются недоступные объекты, затем среди оставшихся считается семантическая близость.
4. В контекст модели передаются только разрешённые чанки вместе с идентификаторами документа и версии.
5. Ответ сопровождается ссылками на разрешённые источники. Сервер ещё раз проверяет доступ перед открытием ссылки.
6. Журнал сохраняет пользователя, версию политики, идентификаторы найденных фрагментов и результат проверки — без бездумного копирования полного секретного текста.

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

Какие метаданные нужны каждому чанку

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

  • идентификатор организации или клиента;
  • идентификатор исходного документа и его версии;
  • владельца и список разрешённых групп либо ссылку на централизованную политику;
  • класс конфиденциальности;
  • дату начала и окончания доступа;
  • признак удаления или отзыва;
  • источник и время последней синхронизации прав.

Эти поля должны наследоваться каждым чанком. Иначе получается классическая офисная магия: папка заперта, а вырванные страницы почему-то гуляют по коридору.

В документации Qdrant для многопользовательского размещения описаны варианты изоляции: фильтрация по полю tenant, выделенные шарды и комбинированная схема. Для множества небольших арендаторов фильтр по payload экономичен; для нескольких крупных клиентов отдельный шард даёт более сильную изоляцию ценой ресурсов. Конкретный выбор зависит от объёма, требований к изоляции и модели отказа, но tenant-фильтр должен формироваться сервером, а не приниматься из запроса пользователя как пожелание.

Права живут дольше красивой демонстрации

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

Нужно определить источник истины: файловое хранилище, ECM, CRM, каталог групп или отдельный policy engine. Событие об отзыве доступа должно быстро инвалидировать кэш, исключать чанки из выдачи и запрещать открытие старой ссылки. Полезно задать измеримый срок распространения изменений, например не «оперативно», а не более пяти минут для критичных классов.

Ключ кэша обязан включать tenant, пользователя или набор групп, версию политики и версию индекса. Общий кэш по формулировке вопроса — очень производительный способ устроить очень производительный инцидент.

Российские персональные данные и ответственность

Если база знаний содержит персональные данные, статья 19 Федерального закона № 152-ФЗ требует правовых, организационных и технических мер защиты от неправомерного или случайного доступа, изменения, копирования, предоставления и других неправомерных действий. Закон также упоминает определение угроз, оценку эффективности мер до ввода системы в эксплуатацию, обнаружение несанкционированного доступа и реагирование на инциденты.

Практический состав мер зависит от категории данных, информационной системы и применимых нормативных требований. Архитектуру нужно согласовать со специалистом по информационной безопасности и ответственным за обработку персональных данных. Само слово «локальный» в акте оценки эффективности, увы, не заменяет ни одной таблицы.

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

Как проверить систему до запуска

Обычного набора вопросов «найди положение об отпуске» недостаточно. Нужна матрица негативных тестов.

  • Пользователь отдела продаж спрашивает точную фразу из закрытого финансового документа.
  • Два клиента загружают документы с одинаковыми названиями и похожими формулировками.
  • Сотрудника удаляют из группы и повторяют старый вопрос до и после истечения заданного срока синхронизации.
  • Один и тот же вопрос задают директор и стажёр, затем проверяют кэш.
  • В разрешённый документ помещают инструкцию для модели запросить закрытый источник.
  • Пользователь подменяет tenant или группу в запросе API.
  • Старая ссылка на цитату открывается после отзыва доступа.
  • В логах и трассировке ищут запрещённые фрагменты и персональные данные.

Критерий приёмки прост: запрещённый документ не должен попадать ни в выдачу, ни в контекст, ни в кэш, ни в журнал с полным содержимым. Отказ должен фиксироваться, но не раскрывать существование секретного файла. Для высокорисковых действий агента — отправки документа, изменения записи или запуска процесса — требуется отдельная авторизация и, где уместно, подтверждение человека.

Экономика без золотого турникета

Начать можно с одной базы знаний и двух контрастных ролей. Понадобятся корпоративная аутентификация, обязательный фильтр на уровне поиска, тестовый набор закрытых запросов, аудит кэша и журналов. Если проект обслуживает много небольших клиентов, проверьте payload-фильтрацию и индексы по tenant. Для нескольких крупных клиентов с повышенными требованиями оцените отдельные шарды или физическое разделение.

Главная метрика здесь не «процент красивых ответов», а отсутствие пересечений между областями доступа при приемлемой полноте разрешённого поиска. Дополнительно измеряются задержка проверки, время распространения отзыва, количество ложных отказов и доля ответов с проверяемыми ссылками.

Что взять руководителю

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

Если граница доступа проверяется до поиска, наследуется чанками, обновляется при отзыве и подтверждается негативными тестами, локальный RAG становится полезным корпоративным инструментом. Если вся политика помещается в предложение «модель, пожалуйста, никому не рассказывай», Внутрик уже несёт из архива стопку папок. Хорошо, что у турникета пока дежурит человек.