Безопасность LLM и RAG: 4 критических риска и чек-лист контроля до production

Как раскладывали риски

Мы сгруппировали риски LLM/RAG по 5 уровням: (1) данные — что попадает в индекс и как защищено; (2) модель — какая используется, где работает, какие у неё ограничения; (3) приложение — как настроены права, RBAC, фильтры; (4) пользователь — кто и как взаимодействует с системой; (5) эксплуатация — мониторинг, обновления, реагирование на инциденты. Для каждого уровня описали типичные риски и контрмеры.

Для каждого риска оценили вероятность реализации в типичной B2B-компании и потенциальный ущерб (репутационный, финансовый, регуляторный). Получилась карта приоритетов: 4 риска требуют обязательной проработки до production-запуска, 6 — желательной, остальные — приемлемых при базовых мерах. Источник — публичные инциденты с LLM-системами 2023–2025 годов, наблюдения за внедрениями в РФ и СНГ, опыт red team-тестирования RAG-систем.

Безопасность — это не один NDA

NDA с подрядчиком важен и нужен, но он не ограничивает доступ модели к корпоративным документам и не проверяет, кто конкретно получил ответ системы. Production-система должна технически разделять права на уровне индекса (RBAC до retrieval), хранить детальные логи всех запросов и ответов, фильтровать чувствительные данные на входе и выходе, и иметь механизм быстрого отключения рискованных сценариев без полной остановки сервиса.

Типичная история: компания запускает RAG-систему с RBAC только на уровне UI («у пользователя X нет кнопки на закрытый документ»). Через месяц обнаруживается, что в индекс попали закрытые документы, и через специально сформулированный запрос пользователь Y получает выдержки из них в ответе. Технически это утечка, формально — нарушение политики безопасности. Решение единственное: применять RBAC до индексации и до retrieval — это требует правильной архитектуры с самого начала.

• Составьте карту типов данных в одной таблице: публичные, внутренние, персональные, коммерческая тайна, особо чувствительные. Для каждого типа — отдельный регламент.
• Разделите пользователей по ролям и проверьте, что RAG соблюдает эти роли на уровне retrieval, а не только в интерфейсе.
• Проведите red team-тестирование: prompt injection через документы, утечки через формулировки цитат, ответы на запрещённые темы — минимум 100 тестовых сценариев.
• Настройте мониторинг типичных аномалий: рост числа запросов от одного пользователя, неожиданные источники в ответах, попытки обхода фильтров.

Как применить материал

Материал связывает RAG, AI-внедрение и enterprise-запросы. Он должен вести на рейтинг RAG-систем, рейтинг AI-интеграторов и материал по стоимости RAG-внедрения. Для бизнеса работает как pre-sales-чеклист: при выборе подрядчика спросите про каждый из 4 критических рисков и попросите конкретные технические ответы (а не общие фразы «обеспечим безопасность»). Сильный подрядчик отвечает развёрнуто, ссылаясь на свой опыт; слабый — переводит разговор на «у нас есть NDA». Для внутренней команды это чек-лист на сдачу-приёмку: ни один RAG-проект не должен идти в production без прохождения всех 4 пунктов.

Связь с хабом, рейтингом и сервисной страницей

Материал относится к хабу «RAG и LLM-архитектура» и должен работать как вход в следующий выбор: понять интент, проверить ограничения и перейти к сравнению подрядчиков. Для shortlist используйте «Рейтинг RAG-подрядчиков», а для постановки задачи — страницу «RAG-системы». Такой маршрут уменьшает риск малоценной страницы: пользователь видит ответ, критерии, источники, дату обновления и следующий практический шаг.

• Хаб: RAG и LLM-архитектура
• Рейтинг для сравнения: Рейтинг RAG-подрядчиков
• Сервисная страница для постановки задачи: RAG-системы