Amazon Quick и Amazon Bedrock Knowledge Bases применяют контроль доступа к документам в реальном времени: права проверяются напрямую у авторитетного источника в момент запроса, а не только по копии ACL, лежащей в индексе. В блоге AWS это описано как ответ на слабости классической схемы replicate-and-filter.
Ставки высоки. Корпоративные RAG-системы тянут знания из Microsoft SharePoint, Google Drive и Atlassian Confluence. Там хранится конфиденциальная информация, а доступ устроен сложно: права наследуются по цепочке сайт, библиотека, папка, файл, плюс вложенные группы и временные разрешения. Один документ, попавший в ответ AI без разрешения, способен вынести наружу стратегию, неопубликованные финансовые данные или информацию из HR.
Дальше — как устроена двухэтапная проверка прав, где у неё остаются слабые места и что это значит для команд, которые уже строят RAG на внутренних знаниях.
Почему контроль доступа в корпоративном RAG — это не просто фильтр
Классическая схема, которую называют replicate-and-filter, работает в три шага. Коннектор источника (например, коннектор SharePoint) тянет ACL во время периодической синхронизации. Эти ACL сохраняются как атрибуты в индексе. В момент запроса AI-система сопоставляет вошедшего пользователя с сохранёнными атрибутами ACL и фильтрует результаты. Материал AWS разбирает эту логику и показывает, где она ломается.
Выглядит разумно, пока права не начинают меняться быстрее, чем идёт синхронизация. Тогда схема даёт сбой, и у неё три конкретных слабых места.
Три слабых места подхода replicate-and-filter
Первое: AI-система не владеет истиной о правах, но отвечает за их применение. В этой модели система берёт на себя единоличную ответственность за принудительное применение ACL, не будучи авторитетным источником прав. Коннекторам приходится точно воспроизводить сложную, зависящую от источника логику ACL. Каждый источник трактует наследование, группы и исключения по-своему, и любое расхождение в маппинге превращается в дыру.
Второе: ACL в AI-решении — это снапшот. Они отражают состояние на момент последней синхронизации. Между синхронизациями пользователь, у которого доступ отозвали, всё ещё может получать ответы AI по документам, которые видеть уже не должен. Именно этот разрыв во времени закрывает проверка прав в реальном времени.
Третье: источники меняют модели доступа. SharePoint, Google Drive и Confluence регулярно вводят новые механизмы контроля доступа к контенту. Когда источник добавляет новый тип разрешения или меняет логику групп, реплицированные ACL и логика фильтрации перестают соответствовать оригиналу. Появляются пробелы в маппинге, и их никто не замечает до инцидента.
Почему Confluence ломает event-based обновления ACL
Логичный способ бороться с устареванием снапшота — обновлять ACL по событиям: изменились права, пришло событие, индекс обновился. На практике это работает не везде. Confluence, например, не генерирует событие при изменении членства в группе. Если пользователя добавили в группу или исключили из неё, событийного сигнала не будет, а значит, и событийное обновление ACL не сработает.
Отсюда вывод: полагаться только на периодическую синхронизацию или только на события нельзя. Confluence — не единственный такой источник, поэтому AWS и предлагает проверять права в реальном времени у самого источника, а не доверять одной лишь копии ACL.
Как Amazon Quick и Bedrock Knowledge Bases проверяют права в реальном времени
Схема от AWS двухэтапная. Сначала система делает семантический поиск с фильтрацией по уже сохранённым в индексе ACL. Затем проверяет отобранные документы напрямую через API авторитетного источника в момент запроса. Это позволяет проверять права в реальном времени, не полагаясь только на снапшоты ACL, и отсекать документы без прав до того, как они попадут в контекст LLM. Публикация AWS описывает принудительное применение ACL в реальном времени именно так.
Этап 1: семантический поиск с фильтрацией по индексированным ACL
На первом этапе система ищет по индексу семантически близкие фрагменты и заодно фильтрует их по атрибутам ACL, которые уже лежат в индексе. Это предварительный отбор: он быстро сужает пул кандидатов. Ограничение в том, что эти ACL по-прежнему снапшот, поэтому финальной проверкой прав они не служат. Их задача — убрать заведомо недоступное и уменьшить объём данных для следующего шага.
Этап 2: проверка прав через API авторитетного источника в момент запроса
После предварительного отбора система сверяет права на каждый оставшийся документ напрямую с источником: SharePoint, Google Drive или Confluence. Проверка идёт через API источника в момент запроса, а не по расписанию. Документы без прав исключаются до передачи контекста в LLM.
Что это даёт на практике: даже если индексированный снапшот ACL успел устареть, пользователь не получит документ, который ему больше не разрешён. Ответственность за применение прав больше не лежит только на AI-системе — она сверяется с тем самым источником, который изначально управляет доступом.
Пример с Google Drive: имперсонация и пользовательский токен
Для Google Drive описанная логика выглядит так: сервисный аккаунт через имперсонацию получает пользовательский токен и с ним обращается к API Google Drive, проверяя права на отобранные документы. Документы без прав исключаются до передачи контекста в LLM. Имперсонация здесь ключевая: система действует от имени конкретного пользователя, не храня его учётные данные и не получая лишних привилегий.
Встраивается это в ту же двухэтапную схему. Сначала семантический поиск с фильтрацией по индексированным ACL отбирает кандидатов. Потом проверка через API с пользовательским токеном подтверждает, что каждый документ действительно доступен этому сотруднику.
У этого фрагмента есть граница: в доступном публичном описании AWS детали реализации не раскрыты, а именно конкретные вызовы API, формат проверки прав и параметры имперсонации остаются за кадром. Концепцию можно взять как ориентир, но точные шаги интеграции сверяйте с документацией AWS и Google, а не с пересказом.
Ограничения и компромиссы подхода
Проверка в реальном времени не бесплатна и не универсальна. Ниже — следствия, которые прямо вытекают из устройства схемы.
- Дополнительный сетевой вызов. Каждый запрос к API источника добавляет задержку и зависит от доступности и производительности этого API. Если SharePoint или Google Drive отвечают медленно, страдает и ответ AI.
- Требования к API источника. Чтобы проверять права в момент запроса, источник должен предоставлять подходящий API и поддерживать работу от имени пользователя (имперсонацию). Не все системы это умеют, и не для всех есть готовый коннектор.
- Пробелы в event-based обновлениях. Confluence не шлёт событие при изменении членства в группе. Значит, часть изменений прав не видна до самого запроса. Проверка в реальном времени это компенсирует, но лишь при условии, что она действительно выполняется на нужных документах.
- Зависимость от корректного сопоставления пользователя. Система должна однозначно понимать, от чьего имени проверять права. Ошибка в маппинге identity отправит проверку не к тому пользователю.
Задержки и стоимость: почему проверка только отобранных документов выгоднее
Проверять права на каждый документ в индексе через API источника — заведомо дорогой и медленный путь. Если в базе знаний тысячи документов, вы получите тысячи сетевых вызовов на один запрос.
Двухэтапная схема обходит это. Сначала семантический поиск с фильтрацией по индексированным ACL сужает пул до небольшого числа релевантных фрагментов. Затем проверка в реальном времени идёт только по ним. Разница арифметическая: десяток проверок вместо тысяч. Меньше вызовов API — меньше задержка и ниже стоимость, при этом актуальность прав на финальном шаге сохраняется.
Конкретные значения задержек и стоимости зависят от источника, объёма индекса и профиля запросов. Их разумно измерять на своём пилоте, а не брать из общих обещаний.
Ответственные AI-контроли Bedrock: Guardrails, проверки на галлюцинации и политики безопасности
Контроль доступа решает один вопрос: какие документы вообще попадают в контекст модели. Это нужный, но не единственный слой защиты.
Bedrock дополняет его набором ответственных AI-контролей: Guardrails, проверки на галлюцинации и настраиваемые политики безопасности. Логика такая: даже если документ прошёл проверку прав, Guardrails ограничивают, что модель может выдать в ответе, а проверки на галлюцинации снижают риск уверенно звучащих, но неверных утверждений.
В доступном публичном описании AWS эти механизмы не разобраны, поэтому конкретные настройки Guardrails и оценок качества сверяйте с документацией Amazon Bedrock и уже под неё проектируйте политики.
Что это меняет для организаций, внедряющих RAG на корпоративных знаниях
Подход с проверкой прав в реальном времени меняет распределение ответственности. Вместо того чтобы держать в AI-системе идеально точную копию всех ACL, вы сверяетесь с источником, который этими правами и управляет. Риск утечек снижается, но растут требования к инфраструктуре.
- Инвентаризация источников. Соберите список систем, откуда RAG тянет знания: SharePoint, Google Drive, Confluence. Для каждой выясните, есть ли API для проверки прав и поддержка имперсонации.
- Проверка на пилоте. Начните с одного источника и измерьте реальные задержки и стоимость проверок в момент запроса на своём профиле нагрузки.
- Identity. Убедитесь, что система корректно сопоставляет пользователя и проверяет права именно от его имени.
- Пробелы в событиях. Учтите источники вроде Confluence, которые не шлют события при изменении групп, и не рассчитывайте только на событийные обновления ACL.
- Слои защиты. Соедините контроль доступа с Guardrails и проверками качества, чтобы ограничить и то, что попадает в контекст, и то, что выходит в ответ.
Универсального рецепта нет. Если у вас один источник с простыми правами и редкими изменениями, классической синхронизации ACL может хватить. Чем больше источников и чем чаще меняются права, тем выше цена ошибки и тем полезнее проверка в реальном времени.