AI-поиск знаний с учетом прав доступа позволяет сотрудникам задавать вопросы на естественном языке по внутренним политикам, инструкциям, процедурам и рабочим кейсам, но получать подтвержденные сведения только из тех материалов, которые им уже разрешено видеть. Это не «общий чат-бот со всеми файлами компании». Это управляемый внутренний поиск, где запрос оценивается вместе с идентичностью пользователя, его ролью и правами на документы, а ответ можно проверить по первоисточникам.
Такой подход подходит для HR-политик, IT-runbook-ов, регламентов качества, операционных инструкций, утвержденных договорных шаблонов и базы знаний поддержки. Он становится опасным, если конфиденциальные, юридические, финансовые или персональные данные просто загружаются в индекс без сохранения границ доступа. Авторизация должна выполняться до поиска, фильтры — работать во время поиска, а интерфейс ответа — показывать использованные источники и ограничения.
Почему обычного корпоративного чат-бота недостаточно
Обычный чат-бот часто ищет похожие по смыслу фрагменты в широком индексе. Он может найти полезный текст, но смысловая близость не доказывает, что конкретный сотрудник вправе этот текст увидеть. В одном наборе данных могут находиться политика компенсаций для руководителей, юридические материалы и ограниченные клиентские кейсы наряду с общими инструкциями.
Инструкция модели «не раскрывай конфиденциальные данные» в системном промпте не является контролем доступа. Модель не должна решать, имеет ли пользователь право на информацию. Это решение должно приниматься приложением и политикой исходной системы. Рекомендации OWASP для RAG и embedding-систем включают гранулярный контроль доступа, логическое разделение наборов данных, проверку доверенных источников и журналирование поиска. На практике это означает: AI-интерфейс не должен обходить существующую модель безопасности репозитория.
Безопасная архитектура: сначала авторизация, затем ответ
Надежная enterprise AI search implementation обычно строится в такой последовательности:
- Подтвердить идентичность. Используйте корпоративный SSO, доверенную действующую сессию или провайдера идентификации. Анонимный доступ плохо сочетается с поиском по чувствительным внутренним знаниям.
- Сопоставить роли и атрибуты. Передавайте в слой политик подразделение, функцию, регион, юридическое лицо, участие в проекте и статус сотрудника. Ролей «администратор» и «пользователь» для реальной организации обычно недостаточно.
- Подключать только утвержденные источники. Владелец источника должен явно подтвердить, какие библиотеки документов, пространства wiki, папки, кейс-системы или очереди заявок допустимо индексировать.
- Сохранять метаданные при загрузке. Для каждого фрагмента необходимы ID источника и документа, версия, владелец, статус утверждения, классификация, дата вступления в силу и пересмотра, URL источника и метки доступа.
- Фильтровать до retrieval. Поиск выполняется с контекстом пользователя; в векторный, ключевой или гибридный поиск попадают кандидатами только разрешенные фрагменты. Редактирование уже сгенерированного ответа не должно быть главной защитой.
- Генерировать только по отфильтрованным доказательствам. Модели передаются разрешенные выдержки, для утверждений требуются ссылки на источники, а пользователь должен иметь возможность открыть указанный документ и проверить раздел.
Подготовка документов: не просто загрузка файлов в индекс
Качество источников и жизненный цикл контента
Даже сильная модель не превратит устаревшую или противоречивую инструкцию в утвержденную политику. Сначала классифицируйте источники: утвержденная политика, операционная процедура, справочный материал, исторический архив или исключенный контент. Для каждой включенной коллекции назначьте владельца, определите порядок утверждения, период пересмотра и правило исключения из поискового корпуса.
Качество извлечения текста нужно проверять отдельно. В сканированных PDF, презентациях и таблицах могут потеряться заголовки, исключения, сноски и отметки версии. Если при извлечении пропало «кроме случаев, утвержденных…», ответ может выглядеть уверенно, но быть существенно неверным. Делите материал по логическим разделам, а не по произвольной длине страницы: правило применимости, исключения и шаги согласования должны оставаться связанными. Слишком короткие фрагменты теряют контекст, слишком большие ухудшают точность поиска.
Переносите политику доступа, а не копируйте файлы в неконтролируемый индекс
По возможности коннектор должен читать ACL исходной системы, членство в группах и правила общего доступа. Даже если для скорости индекс использует упрощенные метки авторизации, они должны быть управляемым производным от исходных прав. При изменении доступа метки в индексе также должны обновляться. Удаление уволенного сотрудника из проектной группы должно одновременно лишать его возможности находить материалы проекта через AI-поиск.
Не путайте привилегированную сервисную учетную запись, которая читает репозитории, с правом отвечать на вопросы любого пользователя. Каждый downstream-запрос на поиск должен снова проверяться с учетом политики запрашивающего пользователя. OWASP относит чрезмерные разрешения и использование общей привилегированной идентичности к причинам опасного поведения AI-агентов; принцип наименьших привилегий, read-only-доступ и полная проверка каждого обращения являются безопасной базой.
Доверие к ответам: источники, неопределенность и эскалация
Хорошая AI knowledge base with access control не делает вид, что для каждого вопроса есть одно бесспорное правило. Полезный интерфейс ответа показывает:
- краткий ответ понятным языком;
- одну или несколько ссылок на уровень раздела либо абзаца;
- название документа, версию или дату вступления в силу и дату последнего пересмотра, если она доступна;
- область применимости: например, конкретный регион, юридическое лицо или категорию сотрудников;
- ссылку на полный источник и, при необходимости, владельца политики или официальный процесс запроса.
Не используйте самооценку уверенности модели как контроль. Более полезны качество и количество совпадающих утвержденных источников, согласованность или противоречия между ними, возраст документа, статус утверждения, неоднозначность запроса и то, подтверждают ли ссылки сам ответ. Похожий фрагмент может быть найден с высокой релевантностью, но относиться к другой организации или устаревшей версии процедуры.
Если доказательств нет, они слабы или противоречивы, система не должна придумывать ответ. Корректная реакция: «Доступные вам утвержденные источники не описывают это исключение. Создайте запрос владельцу политики». Эскалация может открыть кейс в существующем процессе, направить пользователя в ответственную команду или предоставить структурированную форму. Для юридических трактовок, кадровых решений, исключений безопасности и финансовых обязательств человеческое согласование должно быть стандартным путем.
Обратная связь, контроль устаревания и тестирование в production
Тестирование не должно сводиться к вопросу «правильно ли ответил чат-бот?». Подготовьте набор сценариев по ролям, регионам, проектам и уровням классификации. Выполните один и тот же запрос от имени HR-специалиста, менеджера проекта, внешнего подрядчика и администратора. Каждый должен увидеть только источники, разрешенные его идентичности. Включите в тесты уволенных сотрудников, отозванные группы, общие ссылки, ошибочные метаданные, дубли и конфликтующие версии.
Сохраняйте проверяемый журнал: запрос, идентичность пользователя, примененные фильтры политики, ID извлеченных фрагментов, ответ, ссылки, заблокированные результаты и итог эскалации. Доступ к таким журналам также должен быть ограничен, поскольку сами запросы могут раскрывать чувствительные намерения. Регулярно разбирайте неудачные поиски, отзывы пользователей, ошибки индексации и изменения в источниках. Оценка «не помогло» может указывать не только на слабый ответ модели, но и на неясную политику, отсутствующий источник, плохое деление на фрагменты или пробел в правах.
Контроль актуальности должен включать даты истечения и пересмотра в ранжировании, процесс снятия с публикации замененных версий, переиндексацию после изменения политик доступа и явную маркировку ответов, основанных на справочном, а не утвержденном контенте. Владелец документа должен видеть, где используется его материал, и исправлять его без переобучения модели.
Практический план внедрения
- Выберите один ценный, но ограниченный сценарий: например, поиск по утвержденным IT-процедурам или документации системы качества.
- До выбора модели проведите инвентаризацию источников, владельцев, классификаций, версий и правил хранения.
- Спроектируйте интеграцию SSO, групп и ACL источников до разработки чат-интерфейса.
- Согласуйте схему метаданных и правила retrieval-фильтрации до создания embeddings.
- Запустите ограниченный пилот с ответами со ссылками, безопасным отказом и маршрутом эскалации человеку.
- Расширяйте решение только после тестов на утечку прав, устаревший контент и качество ответов для реальных ролей.
POLADO помогает превратить эту архитектуру в рабочий внутренний продукт: от безопасных коннекторов и поиска с учетом ролей до портала для сотрудников и операционного мониторинга. Изучите услугу AI-решения и автоматизация для контролируемых AI-интеграций, дополните ее услугой Веб-платформы и приложения для удобного внутреннего интерфейса и используйте Техническую поддержку и консалтинг для аудита безопасности и долгосрочной эксплуатации. Чтобы определить источники, роли и границы риска для первого релиза, свяжитесь с POLADO.