Если пользователь не вправе читать документ, сведения из него не должны появляться ни в выдаче, ни в пересказе ИИ. Поэтому модель доступа нужно проектировать до загрузки корпоративных материалов.
Составьте карту ролей и источников
Перечислите команды, проекты и категории документов. Для каждого источника задайте владельца, читателей и порядок согласования изменений. Начните с минимально необходимого доступа.
Отдельно рассмотрите общие папки и документы с переменными правами: у вложений и копий ограничения могут отличаться от родительской папки.
Применяйте права на всём пути ответа
Фильтр доступа нужен до отбора фрагментов для модели. Недостаточно скрыть ссылку после генерации: закрытый текст уже мог попасть в ответ.
Проверьте журналирование запросов и ответов. Сами логи могут содержать конфиденциальные фрагменты, поэтому их хранение и доступ к ним тоже следует ограничить.
Проверяйте смену роли и отзыв прав
Протестируйте сценарии нового сотрудника, перехода в другую команду и прекращения доступа. Убедитесь, что поисковый индекс и кэш не продолжают отдавать ранее разрешённые данные.
Добавьте тесты на прямой запрос о закрытом документе и косвенный вопрос, который может раскрыть его содержание.
Проверочный список
- У каждого источника определены читатели и владелец
- Права применяются до передачи фрагментов модели
- Отзыв доступа проверен на индексе и кэше
- Логи защищены по уровню чувствительности данных
Частые вопросы
Можно ли сделать одну общую базу для всех?
Да, если поиск учитывает права на каждый источник и все группы пользователей проверены на тестовых сценариях.
Что происходит после удаления документа?
Проверьте удаление из индекса, кэша и доступных пользователю результатов; порядок зависит от архитектуры сервиса.
Официальные ресурсы
Технические рекомендации и требования к данным могут меняться. Сверяйте подход с условиями вашего процесса и актуальными источниками.
Материал носит информационный характер. Перед внедрением проверьте данные, права доступа и применимость рекомендаций к вашему процессу.