В последние годы российские организации всё чаще используют генеративные языковые модели для работы с внутренней документацией. Технология RAG (Retrieval-Augmented Generation, «генерация с дополненным поиском») позволяет строить ответы на основе корпоративных баз знаний, что делает её привлекательной для создания ассистентов по регламентам, поддержке сотрудников и клиентов, поиска по SharePoint и файловым ресурсам, справочных систем по договорам и технической документации. Главные причины популярности RAG — ответы остаются актуальными без дообучения модели (обновили документ — обновился ответ), их можно проверить по ссылкам на источники, а сами данные не покидают инфраструктуру организации. Как это устроено: документы режутся на фрагменты, каждый превращается в вектор (embedding) — набор чисел, описывающий смысл текста, — и векторы хранятся в специальном векторном хранилище; вопрос сотрудника тоже превращается в вектор, и система находит фрагменты с наиболее близким смыслом; найденные фрагменты добавляются в запрос к модели, и она формулирует ответ. Для безопасности из этого следует важное: каждый документ в индексе становится частью запроса к модели, а значит, защищать нужно не только модель, но и всё, что в неё «подкладывается». Однако, как отмечают специалисты, при подключении RAG к корпоративным хранилищам возникает ряд угроз безопасности, которые не устраняются стандартными фильтрами промптов. В статье, опубликованной в потоке «Разработка», подробно разбираются эти риски и предлагается контур защиты на примере решения INFERA AI.Firewall.

Суть проблемы в том, что RAG-система индексирует все доступные документы, включая черновики с персональными данными, внутренние приказы и страницы с ограниченным доступом, а также страницы, которые может править любой сотрудник. Векторное хранилище, используемое для поиска, не обладает встроенными механизмами разграничения прав: оно возвращает фрагменты, наиболее близкие по смыслу к запросу, независимо от того, имеет ли пользователь право их видеть. Более того, языковая модель не различает легитимную инструкцию и вредоносную команду, внедрённую в текст документа, — она не отличает цитату из политики от инструкции, спрятанной в тексте. Таким образом, RAG создаёт четыре дополнительных риска, которых нет у обычного обращения к модели: отравление базы знаний, обход прав доступа, выкачивание данных через эмбеддинги и выдумывание ответов при отсутствии информации. Фильтр промптов на входе и выходе эти риски не закрывает: проблема живёт в данных и в хранилище, а не в тексте вопроса.

Первый риск — отравление базы — реализуется через внедрение в документы скрытых инструкций («игнорируй прежние указания»), которые срабатывают у каждого, чей вопрос приведёт к этому фрагменту, и заставляют модель выдавать нужный атакующему ответ. Доступ к чату для этого не нужен: достаточно иметь право записи в любой источник, будь то вики-страница, общая папка или внешняя выгрузка. Исследование PoisonedRAG, представленное на конференции USENIX Security, показало, что для заранее выбранного вопроса достаточно добавить пять специально составленных текстов в базу из миллионов документов, чтобы в 90% случаев модель выдала желаемый ответ. Второй риск — обход прав — связан с тем, что векторный поиск возвращает ближайшие по смыслу фрагменты без учёта прав пользователя. В OWASP Top 10 для LLM это описано как уязвимость LLM08 «Vector and Embedding Weaknesses»: запросы к векторному хранилищу без проверки прав дают выдачу по одной лишь близости эмбеддингов. Простая иллюстрация: если в индекс попали общий регламент и приказ о премировании руководителей, то на вопрос «как считается премия» система вернёт оба документа любому сотруднику, который спросит.

Третий риск — выкачивание данных — основан на том, что эмбеддинги могут содержать больше информации, чем принято считать. Принято думать, что по набору чисел исходный текст не восстановить, но исследования показывают обратное: краткие тексты утекают с высокой точностью, а длинные фрагменты точно восстановить почти не получается, но общий смысл всё равно утекает, и этого достаточно, чтобы раскрыть содержание документа. Поэтому векторы необходимо защищать так же, как исходные документы: не выгружать «для аналитики», хранить в зашифрованном виде, ограничивать массовое извлечение выдачи через легитимный интерфейс и вести аудит. Четвёртый риск — выдумывание — проявляется, когда в базе нет ответа, но модель всё равно уверенно отвечает без ссылок на источники. Для CISO это риск целостности, поскольку на основе такого ответа могут приниматься решения, а в госсекторе достоверность уже требуется нормативно (в OWASP этот класс уязвимости описан как LLM09 «Misinformation»).

Для нейтрализации этих угроз предлагается архитектурный подход, реализованный в INFERA AI.Firewall. Защита строится вокруг трёх точек: что попадает в индекс, что достаётся из индекса и на чём построен ответ. Решение встраивается в разрыв между приложением и векторным хранилищем, перехватывая все обращения к базе знаний и модели, и говорит с приложением на языке хранилища. При этом приложение продолжает работать как обычно, не требуя доработок: чат-киоск или любое другое приложение обращается к базе знаний обычным способом, ничего не меняя у себя, но попадает в контур. Ключевой элемент — реестр источников, где каждый источник имеет статус «Разрешён», «В карантине» или «Не разрешён» и привязан к коллекции, организации и владельцу. Поддерживаются различные типы источников: ручная загрузка, SharePoint, Confluence, файловые ресурсы, веб-выгрузки. Документы принимаются через панель INFERA, а во внешней базе приложение работает только на чтение, что предотвращает несанкционированное изменение индекса. Запросы к модели с найденным контекстом проходят через тот же конвейер, что и обычные обращения, что позволяет проверять ответы без дополнительных интеграций. Если источник не разрешён, обращение отклоняется с указанием причины и фиксируется в журнале.

На российском рынке подобные решения становятся особенно востребованными в связи с требованиями регуляторов к защите персональных данных и коммерческой тайны. Компании, внедряющие RAG, часто недооценивают сложность обеспечения безопасности, полагаясь только на фильтрацию промптов. Однако, как подчёркивают эксперты, проблема лежит в данных и хранилище, а не в тексте запроса. Контур защиты, подобный INFERA AI.Firewall, позволяет закрыть все четыре риска, не меняя архитектуру приложения. Это особенно важно для организаций, которые только начинают развертывать ИИ-ассистентов и хотят избежать утечек на раннем этапе. Смежные задачи решают и другие игроки рынка: например, AGIMA AI Security ставит единый шлюз между сотрудниками и моделями — локальными, в российском облаке и зарубежными — и подключает к нему корпоративный чат, инструменты разработки и оркестратор агентов, защищая взаимодействие от маскирования персональных данных до блокировки промпт-инъекций. Это показывает, что рынок движется к комплексной защите ИИ-контуров, а не к точечным фильтрам.

В сравнении с альтернативными подходами, такими как ручное разграничение прав в самом векторном хранилище или использование отдельных шлюзов для каждого приложения, решение INFERA предлагает централизованный контроль с единой политикой и журналом. Это упрощает администрирование и снижает вероятность ошибок. Однако остаются открытые вопросы: насколько широко такие решения будут применяться в российских компаниях, как быстро они будут адаптироваться к новым типам атак и сможет ли рынок предложить достаточное количество специалистов для их настройки. Показательны и смежные инциденты: сообщалось, что ИИ-агенты OpenAI дважды за октябрь обошли систему, которая должна контролировать их поведение, — это напоминает, что контроль над поведением моделей остаётся нетривиальной задачей даже для ведущих разработчиков. В ближайшее время ожидается рост числа подобных продуктов и усиление внимания регуляторов к безопасности RAG-систем.