В мае 2026 года независимые исследователи опубликовали пугающе простой отчёт: публичный медицинский чат-бот для пациентов раскрывал полные текстовые записи последних 1000 разговоров с людьми. Диалоги содержали симптомы, схемы приёма лекарств, репродуктивные планы и эмоциональные состояния. Для доступа не нужен был взлом, специальный софт или учётная запись — достаточно было открыть Chrome DevTools.

Проблема не в слабой модели или плохом промпте. Проблема в том, что RAG-архитектура (Retrieval-Augmented Generation) — конвейер из десятков компонентов — создаёт так много точек утечки, что даже начинающий разработчик может случайно оставить их все открытыми. А с помощью коммерческих LLM найти такие дыры становится тривиальной задачей.

Что такое RAG-чат-бот и почему его безопасность — отдельная история

RAG (Retrieval-Augmented Generation) — это подход, при котором языковая модель не просто генерирует ответ из памяти, а сначала находит релевантные документы в базе знаний, а потом формирует ответ на их основе. В медицинском контексте это особенно привлекательно: чат-бот цитирует не выдуманные факты, а реальные клинические руководства и образовательные материалы.

Но RAG — это не одна модель. Это целый конвейер: клиент-серверный интерфейс, API-эндпоинты, базы данных, модель эмбеддингов, векторное хранилище, пайплайн ретрива, репозиторий документов, логирование и конфигурация. Каждый из этих компонентов — потенциальная дверь для утечки. Когда разработчик собирает такого бота за выходные с помощью ChatGPT и open-source фреймворка, безопасность почти всегда остаётся за кадром.

Как исследователи нашли уязвимость

Исследователи Альфредо Мадрид-Гарсия и Мигель Руяс из Политехнического университета Мадрида использовали двухэтапную стратегию. На первом этапе они поручили Claude Opus 4.6 провести эксплораторное тестирование — LLM генерировала гипотезы уязвимостей и тестировала чат-бот через промпты. На втором этапе — вручную проверяли каждую находку через Chrome Developer Tools: смотрели сетевой трафик, payload запросов и ответов, схемы API, объекты конфигурации и метаданные бэкенда.

Ключевой момент: исследователи не использовали никаких специальных инструментов. Никакого Burp Suite, никакого Nmap, никакого сканирования портов. Только браузер и DevTools — то, что доступно любому пользователю. И это не требовало аутентификации.

Что именно утекло

Результаты систематизированы в пять категорий, и каждая выглядит всё тревожнее предыдущей.

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

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

Записи 1000 последних диалогов. Это самая шокирующая часть. Через обычный запрос к API исследователи получили доступ к последним 1000 пациентских разговоров с ботом. Диалоги содержали медицинские запросы, описания симптомов, приёмы препаратов, репродуктивные планы. Без авторизации. Без шифрования. Без удаления.

Расхождение с публичными обещаниями. На сайте чат-бота было заявлено, что разговоры не сохраняются и приватность гарантирована. В реальности — полные записи хранились и были доступны через API. Это прямое нарушение GDPR и HIPAA.

LLM помогала даже от лица «разработчика». Исследователи просили Claude помочь с аудитом безопасности от имени вымышленного разработчика — и модель охотно помогала. Та же помощь доступна любому злоумышленнику.

Почему это произошло именно с RAG

Проблема не ограничивается одним неумелым разработчиком. Это системная уязвимость архитектуры RAG.

Client-server архитектура раскрывает промежуточные данные. В RAG-системе клиент получает не только финальный ответ модели, но и промежуточные данные — ретривленные чанки, метаданные документов, конфигурацию пайплайна. Если фронтенд не фильтрует эти данные перед отображением, они утекают в DevTools. Это классическая ошибка, но в RAG-контексте она особенно опасна, потому что ретривленные чанки могут содержать конфиденциальные фрагменты базы знаний.

Векторные хранилища не имеют встроенной авторизации. Большинство open-source векторных БД (Chroma, FAISS, Qdrant в конфигурации по умолчанию) не имеют системы авторизации. Если API-эндпоинт ретрива доступен публично — доступна и вся база. Разработчик, который собирает MVP за выходные, почти никогда не настраивает доступы к векторному хранилищу.

Логирование и хранение диалогов — по умолчанию. Многие фреймворки для создания чат-ботов (LangChain, LlamaIndex) логируют взаимодействия по умолчанию. Разработчик может даже не осознавать, что полные тексты диалогов сохраняются в базе данных — и что эта база доступна через API. В описанном случае чат-бот хранил диалоги, хотя публично заявлял об обратном. Скорее всего, разработчик просто не отключил стандартное логирование фреймворка.

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

Масштаб проблемы: AI-ассистированная разработка снижает порог входа

В 2025–2026 годах создание RAG-чат-бота стало доступно каждому. Пациентские организации, независимые разработчики, некоммерческие фонды — все они могут собрать функционального медицинского бота за несколько дней, используя ChatGPT для написания кода и open-source фреймворки для сборки.

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

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

Как защищаться: минимум, который должен быть

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

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

Фильтрация ответов API. Ретривленные чанки и метаданные документов должны фильтроваться до отправки на клиент. Пользователь должен видеть только финальный сгенерированный ответ — не промежуточные данные.

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

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

Независимый аудит безопасности. Перед деплоем в продакшен любой RAG-чат-бот, работающий с чувствительными данными, должен пройти независимый аудит безопасности. Не code review от коллеги — а полноценный penetration testing от специалиста по безопасности.

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

Что это значит для индустрии

Исследование появилось в нужный момент. В 2026 году RAG-чат-боты стали стандартным архитектурным паттерном — их используют от медицинских стартапов до корпоративных систем поддержки. Практически каждый крупный AI-фреймворк включает RAG «из коробки». И практически никто не говорит о безопасности этого конвейера.

Регуляторы начинают обращать внимание. GDPR требует защиты персональных данных, HIPAA регулирует медицинскую информацию, а новые AI-регуляции (EU AI Act) вводят требования к прозрачности и безопасности. Но между законом и реальной практикой — огромная дистанция. Разработчик, который собрал чат-бот на выходных и забыл про безопасность, вряд ли изучал EU AI Act.

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

Двойная природа LLM в безопасности

Отдельный инсайт исследования — роль коммерческих LLM в аудите безопасности. Claude Opus 4.6 ускорил процесс оценки на порядки: модель генерировала гипотезы уязвимостей, структурировала подход к тестированию и даже помогала интерпретировать сетевой трафик.

Но тот же инструмент доступен злоумышленникам. Исследователи показали, что LLM помогает с аудитом даже когда запрос формулируется от имени вымышленного разработчика — модель не проверяет, кто её просит и зачем. Это классическая двойная стратегия: инструменты защиты и инструменты атаки — одни и те же.

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

Часто задаваемые вопросы

Что такое RAG-чат-бот?

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

Насколько распространены такие уязвимости?

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

Может ли обычный пользователь проверить безопасность чат-бота?

Да, базовую проверку можно провести, открыв Chrome DevTools (F12) и посмотрев вкладку Network. Если в ответах API видны системные промпты, конфигурация или чужие диалоги — чат-бот уязвим. Полный аудит требует специалиста, но критические дыры часто видны невооружённым глазом.

Итог

Исследование «When RAG Chatbots Expose Their Backend» — не теоретический анализ и не абстрактная угроза. Это конкретный случай, в котором публичный медицинский RAG-чат-бот раскрывал полные записи 1000 пациентских диалогов через обычный браузер. Проблема системная: RAG-архитектура создаёт множество точек утечки, AI-ассистированная разработка снижает порог входа, а независимый аудит безопасности не проводится почти никогда.

Если вы разрабатываете RAG-чат-бот или планируете его деплой — начните с проверки того, что видит пользователь в DevTools. Это займёт пять минут и может спасти вас от утечки, которая сто́ит репутации, денег и доверия пациентов.