Как только RAG выходит за пределы публичного справочника, появляется требование: разные сотрудники должны видеть разное. Кадровые документы — не для всех, условия по клиентам — только для своего менеджера, себестоимость — для узкого круга.
И здесь совершается ошибка, которая выглядит безобидно и стоит дорого: права пытаются задать инструкцией модели.
Почему запрет в промпте не работает
Схема выглядит разумно: в корпусе лежит всё, а модели написано «не сообщай сведения о зарплатах тем, кто не из отдела кадров».
Проблема в том, что к моменту, когда модель читает инструкцию, закрытый документ уже у неё в контексте. Он найден, извлечён и передан. Дальше вы полагаетесь на то, что вероятностная система соблюдёт запрет.
Она соблюдёт его в большинстве случаев. Но:
- запрет обходится переформулировкой — это известный класс атак на инструкции;
- модель может процитировать закрытый фрагмент, отвечая на смежный вопрос;
- в ссылках на источники всплывёт название документа, которого человек видеть не должен;
- при обновлении модели поведение меняется, и проверять всё заново придётся с нуля.
Тот же принцип, что и с полномочиями агентов: что нельзя нарушить, должно быть невозможно, а не запрещено — «Ограничение действий ИИ-агента».
Правильное место контроля — поиск. Недоступный документ не должен находиться. Тогда обходить нечего: его нет в контексте.
Как это устроено правильно
Метки доступа проставляются на фрагменты при индексации. Каждый фрагмент наследует права своего документа: отдел, роль, уровень, список групп — что принято в вашей системе прав.
Фильтр применяется в условии поиска, а не после него. Разница существенна и не только в безопасности: если отфильтровывать после, вы просите двадцать кандидатов, отбрасываете восемнадцать недоступных и остаётесь с двумя. Приходится искать повторно с большим лимитом.
Права берутся из вашей системы, а не дублируются вручную. Обычно это связь с существующими группами пользователей: тогда изменение прав сотрудника автоматически меняет то, что он видит в поиске.
Ссылки на источники тоже фильтруются. Очевидно, но забывается: если фрагменты отобраны правильно, а список источников формируется из другого места, название закрытого документа может всплыть.
Права проверяются на момент запроса, а не на момент индексации. Сотрудник перешёл в другой отдел — доступ должен измениться сразу, без переиндексации корпуса.
Разбор: утечка, которой не должно было быть
Задача. Внутренний ассистент компании на 300 человек. Корпус: регламенты, инструкции, кадровые документы, коммерческие условия по клиентам.
Как было сделано. Все документы в одном индексе. В инструкции модели перечислены закрытые темы с указанием, кому что нельзя.
Что произошло. Сотрудник склада спросил про условия работы с крупным клиентом — из любопытства. Система ответила, приведя скидочную сетку, которая была доступна только коммерческому отделу.
Формально запрет в инструкции был. Он не сработал, потому что вопрос был сформулирован не как «покажи закрытые условия», а как обычный рабочий вопрос, и модель не соотнесла его с запретом.
Второй эпизод, более неприятный. Другой сотрудник спросил про порядок начисления премий. Система отказалась отвечать — запрет сработал. Но в блоке источников под ответом осталась ссылка на документ «Положение о премировании руководителей отделов, редакция 3». Само название сообщило больше, чем следовало.
Что сделали.
Проставили метки доступа на все документы при индексации, связав их с существующими группами пользователей в корпоративной системе.
Перенесли фильтрацию в условие поиска: закрытые фрагменты перестали попадать в кандидаты.
Убрали упоминания закрытых тем из инструкции модели. Это контринтуитивно, но правильно: перечень запрещённых тем в промпте сам по себе является утечкой — модель можно расспросить о том, что ей запрещено обсуждать, и получить оглавление закрытой части.
Сделали формирование ссылок на источники из того же отфильтрованного набора, что и контекст.
Добавили журналирование: кто, что спросил, какие фрагменты получил. Для разбора инцидентов и для аудита.
Что осталось нерешённым сознательно. Разграничение внутри документа. Если в одном файле есть и открытая, и закрытая часть, метка ставится на весь файл. Дробить права до уровня абзаца можно, но это резко усложняет сопровождение. Правильнее разделить сам документ на два — организационное решение вместо технического.
Отдельные сложности
Права меняются, корпус нет. Перевод сотрудника не должен требовать переиндексации. Поэтому метки на фрагментах описывают документ, а не пользователя, а сопоставление происходит при запросе.
Иерархия и наследование. Права на папку наследуются документами. Стоит решить заранее, как это отображается в метках, — потом переделывать дорого.
Персональные данные. Отдельный слой поверх прав: часть сведений не должна попадать в корпус вообще, независимо от того, кто спрашивает. Правовая сторона — «152-ФЗ и нейросети».
Куда уходят тексты. Если модель работает по подписке, содержимое закрытых документов покидает контур при каждом запросе. Для части организаций это исключает облачные модели — «Локальное развёртывание LLM».
Журнал сам становится чувствительным. В нём лежат вопросы сотрудников и выдержки из документов. Он требует тех же ограничений доступа, что и корпус.
Где хранить — влияет
Выбор хранилища здесь перестаёт быть безразличным.
Если векторы лежат в той же базе, что и данные о правах, фильтрация — это обычный запрос с соединением таблиц. Права всегда актуальны, потому что источник один.
Если векторы в отдельном хранилище, метки приходится синхронизировать, и появляется класс ошибок «права изменились, а метки нет». Сравнение — «pgvector или Qdrant».
Это один из немногих случаев, когда выбор хранилища действительно меняет архитектуру, а не только скорость.
Частые вопросы
Как ограничить доступ к документам в RAG?
Метками доступа на фрагментах и фильтрацией в условии поиска: недоступный документ не должен попадать в результаты. Запрет в инструкции модели ненадёжен — к моменту, когда модель его читает, закрытый фрагмент уже находится в контексте, и остаётся надеяться, что вероятностная система соблюдёт правило.
Почему нельзя просто запретить модели рассказывать лишнее?
Потому что это пожелание, а не гарантия. Запрет обходится переформулировкой вопроса, модель может процитировать закрытый фрагмент при ответе на смежную тему, а название документа всплывёт в списке источников. Кроме того, сам перечень запретов в промпте становится подсказкой о том, что скрыто.
Как быть, если права сотрудника изменились?
Права должны проверяться в момент запроса, а не фиксироваться при индексации. Тогда перевод в другой отдел меняет видимость сразу и переиндексация корпуса не требуется. Для этого метки на фрагментах описывают документ, а сопоставление с пользователем происходит при поиске.
Можно ли разграничить доступ внутри одного документа?
Технически да, но сопровождать это тяжело: права придётся поддерживать на уровне разделов. Практичнее разделить документ на два — открытую и закрытую часть. Это организационное решение, и оно надёжнее технического.
Попадают ли закрытые документы к разработчику модели?
Если модель вызывается по подписке — содержимое переданных фрагментов покидает ваш контур. Для организаций с требованиями к обработке данных это обычно означает развёртывание модели на своей инфраструктуре. Решение принимается до проектирования, потому что влияет на выбор модели и стоимость.
Нужно ли вести журнал запросов?
Да, по двум причинам: разбор инцидентов и диагностика качества. Важно помнить, что журнал содержит вопросы сотрудников и выдержки из документов, поэтому сам требует ограничения доступа наравне с корпусом.
Что дальше
Метки доступа проставляются при подготовке фрагментов — «Чанкинг документов». Фильтрация встраивается в поиск — «Архитектура RAG по шагам». Прикладной разбор внутреннего ассистента — «ИИ-ассистент для сотрудников».
Проектирование систем с разграничением доступа, включая развёртывание в закрытом контуре, — часть работы по разработке и внедрению ИИ.