Контроль доступа в ИИ-поиске: фильтрация ответов по ролям

Почему это важно

ИИ-поиск может просачивать данные так, что сначала это кажется безобидным. Кто‑то задаёт простой вопрос, получает аккуратное резюме и никогда не открывает файл. Но ответ всё равно может опираться на документы, которые этот человек не должен был читать.

Именно этот разрыв — проблема. В обычной системе с документами пользователь упирается в стену прав. В ИИ-поиске система может взять строки из нескольких файлов, смешать их в одном ответе и представить результат как общеизвестный факт.

Утечка не обязательно должна быть громкой. Один только заголовок цитаты может раскрыть слишком много. Имена файлов вроде 2025 salary review, Project Atlas acquisition plan или customer churn - board update уже многое говорят, даже если тело текста остаётся скрытым. Названия проектов, диапазоны зарплат, проблемы клиентов и юридические материалы часто появляются в заголовках, именах папок и превью фрагментов.

Один плохой ответ быстро подрывает доверие. Люди перестают пользоваться инструментом. Менеджеры начинают спрашивать, в безопасности ли файлы финансов, HR или руководства. Команды безопасности начинают считать всю систему рискованной, даже если ошибка возникла в одном пограничном случае.

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

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

Где происходят утечки в потоке ответа

Многие команды блокируют файлы в Google Drive, SharePoint или внутреннем вики и предполагают, что ассистент будет следовать тем же правилам. Он не будет, если на каждом шаге не проверять права до того, как модель увидит текст.

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

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

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

Цитаты создают ещё одну утечку, даже если сам ответ выглядит безопасным. Ссылка вроде Board-M&A-plan-2025.docx или Layoff-forecast.xlsx сообщает пользователю о существовании файла. В некоторых случаях имя файла, имя папки или короткое превью выдают секрет до того, как пользователь прочитал хоть одну строчку.

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

Контроль доступа должен применяться до поиска, до переранжирования, до сборки цитат и до повторного использования кеша. Если один шаг пропускает проверку, последующие шаги не смогут исправить ошибку.

Установите правила до индексации

Контроль доступа начинается до того, как первый файл попадёт в индекс. Если ждать до времени ответа, чтобы разобраться с правами, вы будете устранять пограничные случаи неделями. Индекс уже должен знать, кто что может читать.

Выберите один источник истины для ролей и членства в группах. Это может быть ваш провайдер идентификации, HR‑система или платформа для документов. Не смешивайте данные о ролях из трёх мест и не надейтесь, что они совпадут. Если finance-manager означает одно в Google Drive и другое в вашем приложении, ассистент рано или поздно покажет неверный файл.

Каждому документу при загрузке нужен понятный отчёт о правах. Сделайте его достаточно простым, чтобы неинженер мог его прочитать. Хороший набор правил отвечает на пять простых вопросов:

• Кто владеет документом?
• Какие пользователи могут его открыть?
• Какие группы могут его открыть?
• Наследует ли он доступ от папки или рабочей области?
• Что происходит, если данные об доступе отсутствуют?

Опишите унаследованные правила простым языком до того, как превращать их в код. «Всё в папке payroll видно только сотрудникам payroll и CFO» гораздо лучше, чем расплывчатая заметка о поведении унаследованных ACL. Простой язык обнаруживает неправильные предположения на ранней стадии, и юристы, безопасность и операционные команды могут проверить правила без чтения логики запросов.

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

Небольшой пример делает тестирование проще. Допустим, в компании есть три папки: All hands, Sales и Board. Сотрудник из отдела продаж может искать файлы из All hands и Sales. Тот же сотрудник никогда не должен извлекать фрагмент из Board, даже если этот фрагмент упоминает тот же план продукта и получает более высокий балл при поиске.

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

Фильтруйте фрагменты и цитаты до генерации

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

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

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

Небольшой пример проясняет мысль. Представьте менеджера, который может читать планы команды, но не обзоры по зарплатам. Если векторный поиск запускается по всему корпоративному индексу, запрос вроде why is this team unhappy может вытащить фрагменты из приватных заметок о производительности. Если поиск останется в пределах одобренных документов менеджера, такие фрагменты никогда не попадут в поток ответа.

Что нужно фильтровать

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

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

Финальная защита

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

Это строго по задумке. Контроль доступа работает лучше всего, когда модель никогда не получает шанс увидеть что‑то за пределами разрешённого набора пользователя.

Используйте простой пример для тестирования дизайна

Контроль доступа легче оценивать, когда у вас есть один простой тест. Выберите двух людей с разными правами, задайте им одинаковый вопрос и проверьте, меняются ли и ответ, и цитаты.

Представьте сотрудников: торгового представителя и менеджера HR в одной компании. Торговый представитель может открывать прайс‑листы и утверждённые отчёты по выручке. Он не может открывать файлы по зарплатам. HR‑менеджер может открывать файлы по зарплатам и бюджеты штата, но не может читать черновые условия сделок отдела продаж.

Теперь оба спрашивают: What drove quarterly costs up?

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

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

Вот весь тест в сокращении:

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

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

Тестируйте реальные роли и пограничные случаи

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

Начните с простого сравнения. Задайте один и тот же вопрос с правами админа и с обычным аккаунтом. У администратора может быть пять релевантных фрагментов и три цитаты. Обычный пользователь должен видеть только то, что он может открыть вручную в исходной системе. Если ответ звучит корректно, но ссылается на заблокированный документ, фильтр провалился.

Небольшой набор тестов ловит большинство проблем:

• Выполните одинаковые запросы с аккаунтами с высокими и низкими правами.
• Проверьте пользователя с двумя ролями и подтвердите, какое правило побеждает.
• Уберите доступ к документу, затем задайте тот же вопрос снова.
• Повреждайте или удаляйте метаданные прав для нескольких записей.
• Повторно проверьте сохранённые и кешированные ответы после любого изменения ролей.

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

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

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

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

Если вы протестируете смену ролей, сломанные метаданные и кеши до запуска, вы поймаете утечки, которые обычно проскальзывают в демо.

Ошибки, которые приводят к утечкам данных

Большинство утечек не начинается с громкого взлома. Они начинаются с упрощения, которое во время разработки казалось безобидным. Небольшие ошибки меняют, кто что может видеть, и модель этого не исправит за вас.

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

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

Устаревшие права дают более тихие утечки, и их легко пропустить. Система может копировать правила доступа в индекс раз в день, тогда как в приложении роли меняются каждые несколько минут. Кто‑то выходит из проекта в 12:00, задаёт вопрос в 12:05, а слой поиска всё ещё считает, что он там состоит. Этого достаточно.

Имена папок — ещё одна ловушка. Люди часто относятся к меткам вроде HR, finance или private как к настоящим правилам безопасности. Это не так. Папка может содержать смешанные файлы, унаследованные права или один документ, поделённый с особой группой. Извлечение должно проверять фактическое правило доступа для каждого фрагмента, а не догадываться по месту расположения файла.

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

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

Быстрые проверки перед запуском

Безопасная система «закрывается». Если слой поиска не может подтвердить, кто может читать фрагмент, он должен ничего не возвращать из этого фрагмента и переходить дальше.

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

Перед запуском проверьте базовые вещи:

• У каждого индексированного фрагмента есть document ID.
• У каждого фрагмента есть актуальный тег прав.
• Извлечение останавливается, когда метаданные прав отсутствуют или нечитаемы.
• Цитаты берутся только из фрагментов, которые пользователь может открыть.
• Логи фиксируют заблокированные результаты, не сохраняя заблокированный текст.

Цитаты заслуживают отдельной проверки, потому что через них команды часто пролетают. Модель может написать безопасный ответ, а затем прикрепить цитату из файла, к которому пользователь не имеет доступа. Это по‑прежнему даёт утечку. Слой цитирования должен использовать те же правила одобрения, что и извлечение, и отвергать любой источник, который не прошёл проверку прав.

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

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

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

Что делать дальше

Если ваша команда ещё не выпустила фильтрацию по ролям, не беритесь сразу за весь корпоративный набор знаний. Выберите одну коллекцию, утечка которой навредила бы больше всего, например HR‑файлы или контракты с клиентами. Меньший объём проще проверять, и рецензенты могут вручную сверять реальные ответы.

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

Простой план развёртывания достаточен:

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

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

Рассматривайте контроль доступа как правило безопасности продукта, а не как приём с подсказками. Делайте первый выпуск узким, тестируйте при каждом релизе и расширяйте сферу только после того, как базовые вещи устоят.

Если вам нужен второй взгляд, Oleg Sotnikov на oleg.is работает как Fractional CTO и советник стартапов по разработке ПО с фокусом на ИИ, RAG и развёртывания в продакшен. Это помогает, когда слабое место находится между индексированием, извлечением, цитированием и финальным ответом, а не в одной очевидной компоненте.