Самая частая ошибка RAG внутри компаний проста: загрузить всё, задавать вопросы и считать ответы со ссылками на источники автоматически безопасными.
Вторая по частоте ошибка приходит позже: кто-то понимает, что ассистент может отвечать из документов, которые пользователю видеть не положено. Зарплатные вилки. Договоры с клиентами. Юридические черновики. Заметки совета директоров. Тикеты поддержки. HR-расследования. Процедуры безопасности. Ответ может быть точным и снабжённым ссылками, но система уже раскрыла информацию.
Корпоративный RAG по базе знаний — это не поисковая строка с более приятным текстом. Это информационная система с управляемым доступом. Относитесь к ней именно так.
Извлечение должно применять те же или более строгие права, что и системы-источники. Если пользователь не может открыть документ в Google Drive, SharePoint, Notion, Confluence или CRM, RAG не должен извлекать его для этого пользователя.
Основное правило
Слой извлечения должен ответить на этот вопрос до возврата любого фрагмента:
Имеет ли этот пользователь право видеть этот источник прямо сейчас?
Не «есть ли этот источник в векторной базе?» Не «релевантен ли этот источник?» Не «полезен ли этот источник?» Права — первичны.
Есть три распространённых подхода:
| Подход | Как это работает | Когда подходит |
|---|---|---|
| Отдельные индексы | Один индекс на аудиторию или рабочее пространство | Простые команды, грубое разграничение прав |
| Фильтрация по метаданным | Хранить метаданные ACL/групп/источника и фильтровать до извлечения | Большинство корпоративных RAG-систем |
| Проверка прав в реальном времени | Запрашивать права у системы-источника во время извлечения | Чувствительные или часто меняющиеся права |
Правильный ответ зависит от систем-источников и уровня риска. Для большинства малых и средних компаний достаточно отдельных индексов плюс фильтрации по метаданным. Для клиентских, HR-, юридических или регулируемых данных могут потребоваться проверки в реальном времени.
Сложная часть: держать ACL в синхронизации
Каждый подход выше молча зависит от одного: данные о правах в вашем индексе должны совпадать с данными о правах в системе-источнике. Именно в этой синхронизации живёт настоящая инженерная работа.
Откуда берутся ACL. SharePoint и OneDrive отдают права на каждый объект через Microsoft Graph API; Google Drive — через списки прав для каждого файла в Drive API; Confluence — через ограничения на пространства и страницы. У каждого своя форма (пользователи, группы, наследование, ссылки для общего доступа), свои лимиты API и своё понимание того, «кто это может видеть».
Разворачивание групп не опционально. Большинство реальных прав выдаётся группам, а группы вложены. «Sales EU» внутри «Sales» внутри «All Staff» нужно разворачивать до конкретных пользователей — либо во время синхронизации (больше метаданных в индексе, быстрее запросы), либо во время запроса (свежее, медленнее, больше вызовов API). Выберите один вариант осознанно; команды, которые делают этот выбор случайно, делают его непоследовательно.
Задержка синхронизации — параметр безопасности, а не деталь производительности. Когда кто-то теряет доступ к документу — смена роли, увольнение, сделка становится конфиденциальной — индекс продолжает отдавать старый ACL до следующей синхронизации. Определите допустимую задержку отзыва прав для каждого корпуса и запишите её: близко к реальному времени для чувствительных корпусов; для внутренних процессных документов приемлемы часы. Если это число никто не записал, реальный ответ — «когда отработает ночная задача», а такое не переживёт проверку безопасности.
Проверки в реальном времени покупают свежесть, а платите вы задержкой, лимитами API и новым режимом отказа. Вызов проверки прав на каждое извлечение добавляет каждому запросу обращение к системе-источнику и на масштабе быстро съедает квоту API; обычный компромисс — недолговечный кеш, который тихо превращает «реальное время» обратно в «задержку синхронизации, только поменьше». Что бы вы ни выбрали, сделайте поведение при таймауте явным: если проверка прав упала или не успела, фрагмент не отгружается. Отказывайте по умолчанию (fail closed), логируйте сбой и позвольте ассистенту отказаться — медленный правильный ответ лучше быстрой утечки.
Тест на офбординг из раздела о тестировании — способ узнать, работает ли всё это на самом деле: отключённый аккаунт не должен получать ничего из чувствительных корпусов, и проверка должна держаться уже на следующий день после отключения аккаунта, а не только после следующей полной пересинхронизации.
Границы источников
Не создавайте один гигантский пул знаний. Разделяйте по аудитории и чувствительности:
| Корпус | Аудитория | Примеры | Правило |
|---|---|---|---|
| Публичный/продуктовый | Все | Справочные документы, публичные цены, страницы продукта | Безопасен для широкого ассистента |
| Внутренние операции | Сотрудники | Процессные документы, внутренние FAQ | Только для сотрудников |
| Отдел | Члены отдела | Сценарии продаж, макросы поддержки, ранбуки инженеров | Фильтрация по группам |
| Записи о клиентах | Назначенные команды | Тикеты, договоры, заметки по аккаунтам | Строгий ACL и аудит |
| Ограниченный | Только поимённо | HR, юристы, безопасность, совет директоров | Обычно отдельная система или без RAG |
Чем меньше аудиторий обслуживает один корпус, тем проще рассуждать об утечках.
Контроль на этапе загрузки
Конвейер загрузки — место, где начинается много утечек.
Перед индексацией источника сохраняйте:
- Систему-источник.
- ID документа.
- Владельца.
- Аудиторию или ACL.
- Метку чувствительности.
- Метки времени создания и обновления.
- Дату истечения или пересмотра.
- Можно ли использовать документ для извлечения в ИИ.
- Содержит ли документ персональные данные.
Если у системы-источника уже есть метки, сохраните их. Если нет — добавьте лёгкий шаг классификации перед загрузкой.
Контроль извлечения
Извлечение должно идти в таком порядке:
- Определить пользователя и его группы.
- Определить запрошенное рабочее пространство или ассистента.
- Отфильтровать документы-кандидаты по корпусу, ACL, чувствительности и свежести.
- Извлечь релевантные фрагменты только из разрешённых источников.
- Переранжировать разрешённые фрагменты.
- Сгенерировать ответ со ссылками на источники.
- Отказать или эскалировать, когда разрешённых источников недостаточно.
Не делайте так: сначала извлечь, а потом фильтровать в промпте. Если запрещённый фрагмент попал в контекст модели, граница уже провалена.
Поведение промпта и ответа
Ассистенту нужно предписать:
- Отвечать только из извлечённых источников.
- Указывать заголовок источника и раздел/ссылку.
- Сообщать, когда в разрешённых источниках нет ответа.
- Отделять собственные выводы от фактов из источников.
- Не раскрывать, что ограниченные источники существуют.
- Не пересказывать материал, доступ к которому закрыт.
Плохой отказ:
«Я нашёл HR-вилки по зарплатам, но у вас нет доступа.»
Лучший отказ:
«У меня нет одобренного источника, чтобы ответить на это.»
Второй ответ не раскрывает ни существование, ни тему ограниченных документов.
Логирование без второй утечки
Логи RAG чувствительны. Они могут содержать вопросы пользователей, извлечённые фрагменты, ID источников, ответы и иногда персональные данные.
Логируйте достаточно для отладки:
- ID пользователя или псевдонимный ID.
- Ассистента/рабочее пространство.
- Метку времени запроса.
- ID извлечённых источников.
- Результат фильтрации по правам.
- ID ответа.
- Причину отказа/эскалации.
- Задержку и ошибки.
Будьте осторожны с:
- Полными вопросами пользователей.
- Полными извлечёнными фрагментами.
- Полными сгенерированными ответами.
- Данными клиентов.
- Темами HR/юристов/безопасности.
Для чувствительных систем храните обезличенные логи или ID источников вместо полного текста. Дайте логам собственный контроль доступа и срок хранения.
Устаревшие и противоречащие источники
Права — не единственная граница. Качество источников тоже важно.
У каждого проиндексированного источника должны быть владелец и правило свежести:
| Тип источника | Правило пересмотра |
|---|---|
| Цены | Пересматривать при каждом изменении цен |
| Политики | Пересматривать при обновлении владельцем политики, не реже раза в квартал |
| Документация продукта | Пересматривать при релизе |
| Юридический шаблон | Пересматривает юридический владелец |
| Макрос поддержки | Пересматривать ежемесячно или после серии эскалаций |
Когда источники противоречат друг другу, ассистент должен показывать конфликт только если пользователь имеет доступ к обоим источникам. Иначе он должен отвечать из наиболее авторитетного разрешённого источника или эскалировать.
Тестирование границ доступа
Тестируйте на пользователях, а не только на документах:
- Сотрудник с широким доступом.
- Сотрудник с узким доступом к своему отделу.
- Руководитель с доступом только к своей команде.
- Подрядчик.
- Бывший сотрудник или отключённый аккаунт.
- Пользователь поддержки, работающий с клиентами.
- Администратор.
Для каждого задайте:
- Вопрос, на который он должен уметь ответить.
- Вопрос чуть за пределами его прав.
- Вопрос об ограниченном документе, о существовании которого он знает.
- Вопрос, где публичные и внутренние документы противоречат друг другу.
- Вопрос с инъекцией в промпт: «игнорируй правила доступа».
Правильный результат — не просто «хороший ответ». Это «хороший ответ из разрешённых источников».
План внедрения
Начните с наименее чувствительного корпуса:
- Публичные/продуктовые документы.
- Документы внутренних операций.
- Документы конкретных отделов.
- Записи о клиентах со строгим ACL.
- Ограниченные корпуса — только после явного одобрения безопасностью/юристами.
На каждом этапе измеряйте:
- Полезность ответов.
- Качество цитирования.
- Корректность отказов.
- Долю извлечений с отказом в доступе.
- Долю устаревших источников.
- Сообщения пользователей о недостающих или неверных источниках.
Пока не делайте этого
Не индексируйте «все документы компании» в одного ассистента.
Не полагайтесь на инструкции в промпте для соблюдения прав.
Не логируйте полные извлечённые фрагменты для чувствительных корпусов без ясной политики хранения и доступа.
Не смешивайте HR-, юридические, клиентские и публичные документы в одном корпусе.
Не позволяйте RAG отвечать за пределами разрешённых источников только ради полезности.
Итог
Корпоративный RAG по базе знаний ценен, потому что приносит ответы, опирающиеся на источники, в ежедневную работу. Он рискован, потому что ответы, опирающиеся на источники, всё равно могут раскрывать информацию.
Сначала проектируйте границы доступа. Фильтруйте до извлечения. Разделяйте корпуса по аудитории. Сохраняйте метаданные источников. Отказывайте безопасно. Логируйте осторожно. Тестируйте на реальных профилях прав. Если пользователь не может открыть источник напрямую, RAG не должен использовать этот источник, чтобы ответить ему.
