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

Почему поиск может раскрывать больше, чем думают люди

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

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

Утечка часто начинается до того, как кто‑то откроет исходный файл. Менеджер спрашивает: "Что изменилось в нашем плане найма?" Ассистент отвечает сводкой, в которой упоминается приостановка найма из приватного HR‑листа. У менеджера может не быть доступа к той таблице, но чувствительная деталь уже стала известна.

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

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

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

Люди редко думают о строке поиска как о пути утечки. Именно поэтому ей нужны более строгие правила, чем дереву папок под ней.

Начинайте с команд и реальной работы

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

Для первого запуска держите список команд коротким и конкретным: HR, продажи, инженерия, поддержка, финансы, руководство. Если команда не будет использовать ассистента в ближайшее время — не добавляйте её. Каждое лишнее правило — ещё одна возможность ошибиться с доступом.

Затем запишите вопросы, которые каждая команда задаёт постоянно. Это важнее многих настроек. HR может искать политику отпусков, заметки собеседований и шаги онбординга. Продажи — цены, утверждённые презентации и формулировки контрактов. Инженерия — рука́вики (runbooks), документацию систем и заметки по инцидентам. Эти шаблоны показывают, что людям действительно нужно доставать.

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

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

Доступ между командами требует той же дисциплины. Некоторая перекрываемость нормальна. Менеджеру по продажам может понадобиться утверждённая юридическая формулировка. Техническому руководителю — документация поставщика от закупок. Большинству сотрудников не нужен широкий доступ по всем отделам только потому, что поиск это упрощает.

Лучше спрашивать не "Кто может понадобиться когда‑нибудь?", а "Кто нуждается в этом, чтобы делать свою работу на этой неделе?" Этот сдвиг сокращает неожиданно много рискованного доступа до перехода в продакшн.

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

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

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

Используйте две метки, а не одну

Одной метки недостаточно. Дайте каждому типу документа также метку чувствительности: public, internal, restricted или confidential.

Это упрощает принятие решений. Общая политика может быть internal. Черновик политики о сокращениях — confidential. Шаблон контракта — internal. Подписанные контракты с клиентами — restricted или confidential в зависимости от условий.

Обращайтесь с черновиками как с отдельным классом. В черновиках часто есть комментарии, старые цифры и неподтверждённые формулировки, которые не должны попадать в безопасный AI‑поиск. То же относится к экспортам и заметкам собраний. Экспорты могут объединять поля из нескольких систем. Заметки встреч часто содержат имена, мнения и неформальные решения, не предназначенные для широкой видимости.

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

Чистая карта документов делает настройку прав проще для установки, тестирования и объяснения. Если команда не может сказать, что это за файл, не стоит добавлять его в поиск.

Сопоставляйте правила хранения с правилами доступа

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

Лучшие правила хранения начинаются с типа документа. Место хранения менее важно. Записка собеседования в папке найма и та же заметка, вставленная в чат‑экспорт, должны подчиняться одному правилу — риск исходит из содержания, а не из инструмента.

На практике шаблон обычно простой. Заметки собеседований и обратная связь по кандидатам должны удаляться вскоре после решения по найму. Транскрипты чатов инцидентов могут исчезать раньше, чем финальный отчёт об инциденте. Временные экспорты из HR, финансов или CRM нужно удалять быстро. Черновые планировочные заметки обычно заслуживают более короткого срока жизни, чем утверждённые политики или подписанные контракты.

Точные сроки зависят от юридических и внутренних требований, но для необработанных заметок и копий короче — обычно безопаснее. Люди пишут в таких местах более раскованно. Это делает их полезными в моменте и рискованными позже.

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

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

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

Решите, как ассистент должен отвечать

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

Отказ в ответе должен быть скучным и понятным. "Я не могу получить доступ к этому документу и ответить на основании него" лучше, чем "Я нашёл связанные детали, но не весь файл". Вторая версия всё ещё говорит пользователю слишком много. Когда доступ заблокирован, частичный ответ часто хуже, чем отсутствие ответа.

Заблокировано значит заблокировано

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

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

Возьмём простой пример. Сотрудник спрашивает про отпуск по уходу за ребёнком и сроки выплат. Ассистент может ответить на основе опубликованной HR‑политики, указать тип источника и остановиться. Если тот же сотрудник спрашивает, почему даты отпуска конкретного коллеги изменились, ассистент должен отказать, если это деталь из ограничённого HR‑дела.

Когда правила неясны

Некоторые вопросы должны перенаправляться человеку. Если запрос касается зарплат, юридических споров, клиентских контрактов, отчётов по инцидентам или черновых материалов совета — ассистент должен направить пользователя к владельцу документа или руководителю команды, когда правило неясно.

Такой переход важен. Быстрое «спросите HR» или «свяжитесь с владельцем контракта» предотвращает неправильные догадки. Хороший AI‑поиск не отвечает на всё. Он знает, когда остановиться.

Стройте матрицу доступа шаг за шагом

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

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

Сопоставляйте каждую группу с метками документов, а не с отдельными файлами. Метки вроде "sales-current", "sales-manager", "hr-confidential" и "archive-read-only" намного проще проверять, чем список файлов по одному.

Простой порядок действий обычно работает:

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

Тестирование обычно выявляет слабые места. Задавайте те же вопросы, которые люди задают ежедневно: "Какой сейчас шаблон контракта?" или "Какую скидку я могу дать без одобрения?" Если ассистент отвечает из устаревшей презентации, чернового предложения или приватной заметки — удалите этот источник из поиска немедленно.

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

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

Простой пример для HR, продаж и инженерии

Представьте компанию на 120 человек с одним ассистентом, подключённым к Google Drive, вики, тикет‑системе и папке с контрактами. Все используют одну строку поиска. Они не должны получать одинаковые результаты.

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

HR‑менеджер может запросить "документы для нового сотрудника в Германии" и получить политики, чек‑листы онбординга и утверждённые локальные процессы. Тот же менеджер не должен видеть обзоры зарплат из других регионов только потому, что в этих файлах упоминается компенсация или найм.

Менеджер по продажам может искать "enterprise pricing" и найти актуальную утверждённую таблицу цен, политику скидок и клиентские условия. Этот сотрудник не должен видеть черновые контракты юриста или тикеты поддержки с описанием споров по ценам.

Инженер может спросить "как мы устраняли последний сбой БД" и получить рука́вики, заметки по инциденту и финальный отчёт. Он не должен получать обзоры эффективности сотрудников, даже если менеджер упомянул сбой в оценке.

Разница становится ещё явнее, когда люди задают одинаковый вопрос. Представьте, что три сотрудника пишут: "покажите последние документы обзоров."

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

Одинаковые слова — разные ответы. Это нормально. Ассистент должен применять правила для команды и метки документов прежде, чем формировать ответ.

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

Ошибки, превращающие поиск в утечку

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

Первая ошибка — дать ассистенту админ‑доступ, потому что так экономнее. Сначала кажется проще: подключить всё, индексировать всё и разбирать крайние случаи позже. Позже редко наступает. Если ассистент может читать заметки совета директоров, файлы по зарплатам, документы по безопасности и приватные юридические папки, один неосторожный запрос может раскрыть то, что обычный сотрудник никогда не должен видеть.

Общие ботовые аккаунты создают ту же проблему более тихо. Когда пять команд используют одну учётную запись, никто не может чётко сказать, кто что должен видеть. Журналы аудита становятся нечёткими. Процедура увольнения усложняется: уволился человек, но общий аккаунт всё ещё видит те же папки, чаты и экспорты.

Копии данных — ещё одна распространённая ошибка. Команды жёстко закрывают исходные системы, но забывают про таблицу, экспортированную для совещания, CSV на рабочем столе или личные заметки, вставленные в планировочный документ. Поисковые инструменты часто находят такие копии первыми, потому что их легко индексировать. Один экспорт с зарплатами, контактами клиентов или заметками об инцидентах может распространиться дальше, чем оригинал.

Дешёвое хранение создаёт отдельный риск. Если вы храните историю чатов вечно, вы сохраняете старый контекст доступа навсегда. Люди меняют роли. Подрядчики уходят. Проекты заканчиваются. Старые беседы всё ещё содержат имена, бюджеты, детали дорожной карты и фрагменты приватных файлов. У хранения должен быть срок, а не только план резервного копирования.

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

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

Короткий чек‑лист для запуска

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

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

Перед запуском убедитесь, что у каждого набора документов есть назначенный владелец и простая метка, которую люди могут быстро проверить. Дайте каждой пользовательской группе согласующего, чтобы смена роли не расширяла доступ молча. Установите расписание удаления, которое можно объяснить одним предложением. Если кто‑то удаляет файл сегодня, люди должны знать, исчезнет ли он из поиска через минуты, часы или при следующей синхронизации. Ведите журналы аудита настолько подробно, чтобы было видно, кто искал, какой источник использовал ассистент и был ли доступ разрешён или заблокирован. В то же время не храните приватный текст в логах дольше, чем позволяет ваша политика хранения.

Затем тестируйте реальными пользователями. Попросите HR найти политику по отпускам, продажи — презентацию с ценами, инженерию — рука́вик. Потом поменяйте запросы и подтвердите, что каждая команда блокируется там, где нужно.

Простой тест лучше длинной политики. Если хотя бы один заблокированный тест возвращает полезный фрагмент, остановитесь и исправьте до широкого запуска. Безопасный AI‑поиск — это в основном аккуратная повседневная работа. Это та часть, которая не даёт поиску превратиться в тихую утечку.

Следующие шаги для безопасного запуска

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

Перед добавлением новых источников решите, кто может утверждать три вещи: новый источник контента, новую метку документа и любые изменения в правилах хранения. Если за этими решениями никто не отвечает, настройка быстро рассредоточится. Запись утверждений в документах по безопасности или операциях обычно достаточна, если кто‑то поддерживает её в актуальном состоянии.

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

Делайте ревью конкретным. Проверьте, принадлежит ли источник всё ещё ассистенту. Сравните доступ команд с записями в HR или системе идентификации. Выберите несколько документов, чтобы подтвердить метки и сроки хранения. Удалите устаревшие группы, старые проекты и дублирующие коннекторы. Потом протестируйте несколько реальных запросов, чтобы увидеть, что каждая команда на самом деле может найти.

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

Некоторые компании могут проводить ревью самостоятельно. Другие хотят второго взгляда перед тем, как открывать доступ новым командам. В таком случае Олег Сотников на oleg.is консультирует стартапы и небольшие компании по планированию AI‑запусков, технической архитектуре и моделям прав в роли Fractional CTO или советника.

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