Как корпоративный AI работает с закрытыми документами

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

Технологически такой сценарий часто строится через RAG – retrieval-augmented generation. Но RAG решает только часть задачи: помогает передать модели релевантный внешний контекст. Версии документов, доступ, достоверность и проверку ответа должна обеспечивать прикладная система.

Что такое RAG простыми словами

В исходной работе Retrieval-Augmented Generation языковая модель совмещается с механизмом поиска по внешней памяти. В корпоративном приложении это обычно выглядит так:

1. документы извлекаются из утверждённых источников;
2. текст очищается и делится на осмысленные фрагменты;
3. для фрагментов создаются поисковые представления – эмбеддинги;
4. вопрос пользователя также преобразуется для поиска;
5. система находит близкие по смыслу фрагменты;
6. модель получает вопрос и найденный контекст;
7. ответ возвращается вместе с источниками.

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

Почему загрузить общую папку недостаточно

В файловой структуре компании могут одновременно находиться:

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

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

Поэтому каждому фрагменту нужны метаданные:

• исходный документ и его стабильный идентификатор;
• версия и дата действия;
• подразделение или владелец;
• уровень доступа;
• тип документа;
• дата индексации;
• статус: черновик, действует, архив;
• страница, раздел или координаты исходного фрагмента.

Права применяются до поиска

Правильная последовательность выглядит так:

пользователь → его роли → разрешённые источники → поиск → модель → ответ

Опасная последовательность:

поиск по всем документам → модель → попытка скрыть лишнее в готовом ответе

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

Практические варианты:

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

Выбор зависит от структуры компании и цены ошибки. Чем чувствительнее данные, тем меньше стоит полагаться на один фильтр в конце цепочки.

Как ответ должен ссылаться на источник

Ссылка на источник нужна не для украшения. Она позволяет сотруднику быстро проверить:

• из какого документа взят факт;
• действует ли эта версия;
• не потеряно ли важное условие;
• относится ли ответ к нужной компании, объекту или периоду;
• не объединила ли модель несовместимые фрагменты.

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

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

Как защищаться от плохих и вредоносных документов

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

• скрытый текст;
• ошибочная или устаревшая инструкция;
• содержимое из непроверенного вложения;
• текстовая команда, которая пытается изменить поведение модели;
• неверно распознанный OCR-фрагмент;
• чужие данные из ошибочной выгрузки.

Перед индексацией полезны:

1. список доверенных источников;
2. проверка типа и размера файла;
3. антивирусная и техническая обработка;
4. извлечение видимого текста без активного содержимого;
5. классификация и назначение владельца;
6. очередь подтверждения для новых источников;
7. журнал добавления, изменения и удаления.

Инструкция внутри документа остаётся данными, а не командой к выполнению. Даже если модель интерпретировала её иначе, прикладной слой не должен выдать дополнительные права или вызвать опасный инструмент.

Как обновляются знания

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

Полезная схема обновления:

• источник сообщает об изменении или проверяется по расписанию;
• документ получает новую версию;
• старые фрагменты помечаются неактивными;
• новая версия проходит извлечение и проверку;
• индекс обновляется атомарно;
• контрольные вопросы выполняются повторно;
• дата знания показывается пользователю.

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

Как измерять качество

Для пилота нужен набор реальных вопросов разных типов:

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

По каждому вопросу оцениваются отдельно:

Средняя оценка не должна скрывать нарушение доступа. Один ответ из чужого документа может быть важнее десятков правильных ответов на обычные вопросы.

Когда этот сценарий подходит

Корпоративный AI-поиск полезен, когда:

• сотрудники регулярно ищут информацию в большом наборе текстовых материалов;
• документы имеют владельцев и понятный жизненный цикл;
• ответ можно проверить по источнику;
• существующий поиск по точным словам не покрывает формулировки пользователей;
• есть возможность перенести или отразить права доступа в AI-контуре.

Когда сначала нужно навести порядок

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

Также RAG не заменяет транзакционный запрос к 1С или CRM. Текущий остаток, статус заказа и сумма задолженности должны приходить из рабочей системы через API, а не из вчерашней выгрузки документа.

Вывод

Диалог с внутренними документами – один из самых понятных сценариев локального AI, но его ценность определяется не красотой чата. Важнее, чтобы пользователь видел источник, права применялись до поиска, устаревшие версии исчезали из выдачи, а система умела честно сказать «в разрешённых данных ответа нет».

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