Кто отвечает за права доступа внутри RAG?

Часто слышу аргумент:

«Корпоративный AI использует только наши внутренние документы, поэтому риск ограничен».

На мой взгляд, всё наоборот.

Чем больше внутренних источников подключено к AI, тем сложнее сохранить исходные границы данных.

Документы HR, финансов, разработки, службы безопасности и руководства могут находиться в защищённых системах. Но затем их разбивают на фрагменты, преобразуют в embeddings, помещают в индекс и динамически объединяют в контекст модели.

Возникает новая система доступа, которой раньше в компании не существовало.

Критический вопрос: кто и в какой момент проверяет, имеет ли конкретный пользователь право получить каждый найденный фрагмент?

Проверять доступ после генерации недостаточно.

Модель может использовать закрытый документ, не показывая его дословно. В результате сотрудник увидит не сам документ, а вывод, который из него следует.

Например: - что готовится реорганизация; - что определённый продукт признан убыточным; - что в отношении сотрудника ведётся проверка; - что компания обсуждает ещё не объявленную сделку.

Формально документ не раскрыт. Фактически конфиденциальная информация стала частью ответа.

OWASP относит к рискам RAG не только утечки, но и cross-context leakage, data poisoning и слабости embeddings. (OWASP Gen AI Security Project)

При этом embedding иногда воспринимают почти как обезличивание.

Я с этим не согласен.

Embedding — производное представление документа. Он не должен терять классификацию, владельца и ограничения доступа только потому, что его нельзя прочитать глазами.

Ещё сложнее ситуация с agent memory.

Вредоносный или ошибочный документ способен попасть в retrieval, затем — в summary или память, а после удаления источника продолжить влиять на систему. В таком случае мы имеем уже не единичную prompt injection, а устойчивое загрязнение доверенного контекста.

Поэтому RAG нужно проектировать как data platform: - с авторизацией при каждом запросе; - с provenance каждого chunk; - с разделением доменов доверия; - с контролем ingestion; - с управляемым сроком жизни памяти; - с процедурой полного отзыва и удаления производных данных; - с возможностью расследовать, какие ответы были затронуты.

Моя позиция: RAG не наследует безопасность корпоративных систем автоматически. Он создаёт собственную модель доступа и доверия — и именно её компании часто забывают спроектировать.

Как это устроено у вас: права проверяются непосредственно при retrieval или предполагается, что достаточно авторизации пользователя в самом AI-сервисе?

Кто отвечает за права доступа внутри RAG? | Сетка — социальная сеть от hh.ru