Корпоративный ИИ с разграничением доступа: безопасная работа с внутренними документами

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

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

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

Что означает разграничение доступа в корпоративном ИИ

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

Для обычного файлового хранилища правило выглядит очевидно: сотрудник отдела продаж открывает коммерческие материалы, но не видит зарплатные ведомости. В ИИ-системе граница становится менее заметной. Пользователь может не запрашивать закрытый файл напрямую, а попросить: «Сравни условия оплаты по последним договорам» или «Назови медианную зарплату в моем подразделении». Если поисковый слой имеет доступ ко всему массиву, модель способна пересказать сведения из документов, которые пользователь открыть не может.

Корректная схема строится по принципу сквозной авторизации:

1. Система устанавливает личность сотрудника через корпоративный провайдер идентификации.
2. Запрос связывается с его ролями, подразделением, проектами и иными атрибутами доступа.
3. Поиск выполняется только среди разрешенных источников или отфильтровывает недоступные документы до передачи контекста модели.
4. Каждый вызов внешней системы повторно проверяется ее средствами авторизации.
5. Ответ проходит фильтрацию и сопровождается ссылками на доступные пользователю первоисточники.

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

Почему внутренний ИИ-чат не становится безопасным автоматически

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

Основные каналы риска возникают в разных частях системы:

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

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

OWASP относит к основным рискам LLM-приложений prompt injection, раскрытие чувствительной информации, отравление данных, избыточную автономность и уязвимости векторных хранилищ. В актуальной редакции OWASP Top 10 for LLM Applications 2026 отдельно учитываются угрозы, связанные с контекстом, агентными сценариями и подключенными инструментами.

Прямая и косвенная prompt injection

Прямая prompt injection содержится в запросе пользователя: например, он требует игнорировать правила и показать скрытые инструкции. Косвенная инъекция находится в обрабатываемом источнике — документе, письме, веб-странице или записи базы знаний. Сотрудник может не видеть вредоносный текст, но модель получит его вместе с остальным контекстом.

Для RAG-систем косвенная инъекция критична: база знаний одновременно служит источником фактов и каналом доставки инструкций. Вредоносный документ может потребовать раскрыть найденные сведения, обратиться к внешнему адресу или вызвать подключенный инструмент. Фильтрация входных данных снижает риск, но не устраняет фундаментальную проблему: модель обрабатывает команды и данные в одном текстовом контексте.

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

Утечка скрытого контекста

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

Системный промпт нельзя считать хранилищем секретов или надежным механизмом безопасности. В нем не должно быть паролей, API-ключей, строк подключения и правил, раскрытие которых позволяет обойти защиту. OWASP прямо рекомендует не полагаться на секретность системного промпта: авторизацию, фильтрацию и разделение привилегий нужно реализовывать на уровне приложения и подключенных систем.

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

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

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

Где проверять права

Предпочтительная схема — security trimming до формирования контекста. Поиск должен учитывать идентификатор пользователя, его группы, атрибуты и списки доступа к документам. Модель получает только те фрагменты, которые сотрудник вправе прочитать.

Возможны два базовых варианта:

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

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

Как синхронизировать права

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

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

Фрагменты одного документа должны наследовать его ограничения. Иначе закрытая таблица или приложение могут попасть в общий индекс отдельно от файла, которому принадлежали. Те же правила распространяются на изображения, результаты OCR, резюме документов и заранее созданные эмбеддинги.

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

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

On-premise уменьшает зависимость от внешнего поставщика, но не защищает от внутреннего нарушителя, общего индекса, prompt injection и чрезмерных прав агента. Облачная корпоративная платформа, в свою очередь, может иметь развитые средства администрирования и договорные ограничения на использование данных, однако ее условия нельзя переносить с одного продукта или тарифа на другой.

Для персональных данных российских граждан необходимо отдельно оценивать требования Федерального закона № 152-ФЗ. Часть 5 статьи 18 ограничивает использование зарубежных баз при сборе и выполнении ряда операций с персональными данными, а статья 12 регулирует трансграничную передачу. Передача данных иностранному поставщику LLM требует анализа фактического маршрута, ролей сторон, оснований обработки и необходимости уведомления уполномоченного органа. Актуальные формулировки содержатся в статье 18 и статье 12 закона № 152-ФЗ.

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

Какие защитные слои нужны корпоративному ИИ

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

IAM, SSO и авторизация в источниках

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

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

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

AI Secure Gateway и guardrails

AI Secure Gateway — это промежуточный слой между корпоративными приложениями и языковыми моделями. Он может маршрутизировать запросы, применять политики доступа, обнаруживать чувствительные сведения, блокировать подозрительные промпты, проверять ответы и передавать события в SIEM или SOC.

Классический сетевой экран анализирует адреса, соединения и протоколы. AI-шлюз работает с содержанием и контекстом взаимодействия: ищет признаки prompt injection, секреты, персональные данные, запрещенные темы или необычную последовательность действий.

Guardrails могут:

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

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

Маскирование и минимизация контекста

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

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

Обезличивание отличается от маскирования. Маскирование обычно обратимо внутри системы, а полноценное обезличивание должно препятствовать определению субъекта без дополнительной информации. Простая замена имени на «Сотрудник А» не делает набор обезличенным, если сочетание подразделения, должности и даты позволяет восстановить личность.

Журналирование без создания новой утечки

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

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

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

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

Какие документы можно передавать ИИ

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

Практическую политику удобно строить вокруг классов данных.

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

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

Как ограничить ИИ-агентов при работе с документами

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

OWASP связывает excessive agency с тремя причинами: избыточной функциональностью, избыточными разрешениями и избыточной автономностью. Защита должна сокращать все три составляющие.

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

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

1. Чтение разрешенных данных и подготовка ответа.
2. Создание черновика без отправки или публикации.
3. Выполнение обратимого действия после подтверждения сотрудником.
4. Необратимые и критичные операции только через установленный бизнес-процесс с дополнительной авторизацией.

Инструменты агента должны иметь строгие схемы параметров. Вместо универсального доступа к базе или произвольного HTTP-запроса безопаснее предоставить узкую функцию: например, «получить статус договора по идентификатору». Исходящие сетевые соединения ограничивают разрешенным списком адресов, а рабочую среду изолируют от основной пользовательской сессии.

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

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

1. Описать сценарий и модель угроз

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

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

2. Провести инвентаризацию данных и прав

Для документов устанавливают владельцев, классы конфиденциальности, сроки актуальности и действующие ACL. Дубли и устаревшие редакции исключают из индекса или явно маркируют.

Если неизвестно, какая версия регламента действует, RAG лишь ускорит распространение противоречивой информации. Качество корпоративного ИИ напрямую зависит от управления знаниями: назначения владельцев, версионности, дат пересмотра и правил удаления.

3. Выбрать архитектуру и контрольные точки

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

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

4. Проверить систему на реальные и враждебные запросы

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

NIST рассматривает управление рисками генеративного ИИ как процесс всего жизненного цикла, включая измерение, документирование, человеческий контроль и регулярную переоценку. Эти принципы изложены в Generative AI Profile к NIST AI RMF.

5. Запустить ограниченный пилот и измерить результат

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

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

Безопасный корпоративный ИИ начинается с управляемого доступа

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

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

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

Об авторе

Игорь М.

Chief Editor

Игорь М. — Chief Editor в компании Полигант, отвечает за редакционную стратегию и качество публикуемого контента. Работает в сфере цифровых финансов, блокчейн-технологий и ИИ более 6 лет.

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