Безопасность ИИ: как защитить корпоративные данные при работе с LLM

Большие языковые модели используются не только для ответов на вопросы, но и работают с корпоративными базами данных, документами, внешними инструментами. Вместе с возможностями растут и риски информационной безопасности (ИБ). 

Четыре канала утечки

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

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

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

• Данные для обучения. В выборке может оказаться чувствительная информация, которая не была вовремя обезличена.

• Действия ИИ-агента. В процессе работы он обращается к базам знаний, CRM и другим корпоративным системам. При избыточных правах ошибка может обернуться утечкой. 

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

Теневой ИИ

Привычная картина: сотрудник не идет в ИБ-службу, а просто открывает публичный ИИ-сервис и решает рабочую задачу. Менеджер скидывает в чат переписку с клиентом — пусть нейросеть поможет с ответом. Бухгалтер загружает отчет — пусть поищет ошибки. Никто не спрашивает разрешения, никто не задумывается, куда уходят данные. А компания потом удивляется, откуда утечка.

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

OWASP Top 10 for LLM Applications — международный документ, описывающий самые распространенные и критичные уязвимости для языковых моделей. Актуальная версия опубликована 4 августа 2026 года. По сравнению с редакцией 2025 года в ней переработана категория System Prompt Leakage (утечка системных промптов) — она расширена до Hidden Context Exposure (утечка скрытого контекста). Эта категория охватывает не только системные промпты, но и любые данные, попадающие в контекстное окно модели: извлеченные документы, память диалога, ответы инструментов и внутреннее состояние приложения. Кроме того, Unbounded Consumption (неограниченное потребление ресурсов) поднялась на четыре позиции, а Misinformation (дезинформация) — на две, поскольку инциденты показали, что ошибочные ответы модели все чаще приводят к реальным действиям и финансовым потерям. Разберем ключевые категории, наиболее релевантные для корпоративного использования LLM. 

Prompt injection

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

Языковая модель не может сама отличить вредоносный запрос от обычного. Поэтому защита — задача человека. Против prompt injection работают:

• проверка входных данных на подозрительные команды;

• контекстная фильтрация и ограничение доступа LLM к критическим ресурсам;

• ручное подтверждение важных операций и решений;

• постоянный мониторинг аномалий при взаимодействии с LLM;

• регулярные обновления модели и связанных с ней систем.

System Prompt Leakage (LLM07)

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

Меры защиты:

• не размещайте секреты и критичную логику в системных промптах;

• выносите контроль доступа и фильтрацию во внешние guardrails-системы, работающие вне LLM;

• мониторьте выводы модели на предмет утечки инструкций.

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

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

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

Что предпринять для снижения рисков:

• фильтровать контекст и ответы модели;

• назначить ИИ-ассистентам и агентам минимально достаточные полномочия; 

• мониторить все операции и отслеживать подозрительные.

Отравление базы знаний и цепочка атаки на корпоративный RAG

RAG (Retrieval-Augmented Generation) — генерация, дополненная поиском. Перед выдачей ответа ИИ ищет нужные данные в базе знаний. Злоумышленники могут добавить туда ложную или вредоносную информацию. Например, скрытую инструкцию, которая при определенном запросе заставляет языковую модель раскрыть чувствительные сведения. 

Меры защиты:

• проверка всех источников и документов перед добавлением в базу знаний;

• изоляция и фильтрация контекста;

• постоянное журналирование;

• регулярная актуализация базы знаний;

• разделение документов по уровням доступа.  

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

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

Что должно быть в политике

Основные положения, которые можно адаптировать под свою компанию:

Есть несколько способов контролировать передаваемую информацию и полномочия агентов. 

Guardrails и ИИ-шлюз

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

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

• Фильтрация запросов. Проверка на наличие чувствительной информации, запрещенного контента, инъекций промптов.

• Проверка выходных данных. Обнаружение «галлюцинаций» модели и конфиденциальной информации в ответах.

• Проверка направленности действий. Оценка соответствия ИИ-агентов заданной бизнес-логике и предотвращение несанкционированных операций. 

Если в запросах обнаруживаются чувствительные данные, Guardrails маскирует их с помощью плейсхолдеров типа [ТЕЛЕФОН] или [ИМЯ]. Модель получает обезличенный запрос, а пользователь — ответ с исходными значениями. 

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

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

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

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

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

Ограничение прав агента

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

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

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

Краткая сводка по рискам и обеспечению безопасности:

Требования безопасности к ИИ диктуют выбор сценария развертывания в зависимости от степени чувствительности информации. Доступные варианты:

• Публичный API. Можно передавать только открытые данные и обезличенные технические задания. 

• Облако с аттестацией в РФ. Аттестация по уровню защищенности УЗ-1 является высшим уровнем, предусмотренным 152-ФЗ, и позволяет обрабатывать персональные данные любой категории, а также коммерческую тайну и финансовую отчетность при условии соблюдения дополнительных организационных мер защиты. 

• Частное облако (Private Cloud). Компания получает свою виртуальную инфраструктуру на мощностях провайдера. Риск перекрестного доступа со стороны других клиентов минимальный, поскольку применяется изоляция окружений. Для обработки персональных данных в частном облаке необходимо убедиться, что провайдер имеет соответствующую аттестацию по 152-ФЗ. Публичное облако Cloud.ru Evolution аттестовано по уровню защищенности УЗ-1 и позволяет обрабатывать ПДн любой категории.

• Корпоративный ИИ на серверах компании (on-premise). Считается самым надежным сценарием, поскольку информация остается во внутреннем контуре и полностью контролируется бизнесом. Можно обрабатывать любые критичные данные.  

Локальное развертывание ИИ хоть и дает полный контроль над данными, но оправдано только для стабильно высокой нагрузки, требует времени и значительных ресурсов. Частная модель на платформе, аттестованной для работы с персональными данными, позволит быстро запуститься и при этом не нарушить положения 152-ФЗ. 

Безопасность ИИ зависит не только от выбранной модели, но и от того, как устроены инфраструктура, доступы и взаимодействие компонентов. На GoCloud Tech 2026 эксперты Cloud.ru и технологического сообщества разберут эти вопросы на технических докладах и практических воркшопах.

15 октября в Москве поговорим об инфраструктуре, разработке, данных и ИИ-агентах. В программе — в том числе темы безопасности, надежности и построения ИИ-систем.

Cloud.ru — надежный провайдер облачных решений для бизнеса. В продуктовом портфеле есть сервисы, позволяющие строить работу с искусственным интеллектом как на арендованных мощностях, так и в своей инфраструктуре. 

Guardrails в Evolution Foundation Models

Evolution Foundation Models — сервис, открывающий доступ к готовым open source моделям, которые можно подключить через API и настроить под свои задачи. Вопросы безопасности использования ИИ решаются с помощью Guardrails. 

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

Инфраструктура Cloud.ru размещена на территории России в ЦОД уровня Tier III. Платформа аттестована по уровню защищенности УЗ-1 и соответствует требованиям 152-ФЗ, поэтому подходит для работы с персональными данными. 

Решения для закрытого контура

Платформа Cloud.ru Evolution Stack позволяет построить частное, гибридное или распределенное облако в ЦОД компании. Конфиденциальные данные можно хранить в своем контуре, а масштабироваться за счет ресурсов публичного облака Cloud.ru Evolution. А для систем, относящихся к критической информационной инфраструктуре, есть «Облако для КИИ». 

Для защиты информации используются сертифицированные СЗИ и специализированные сервисы:

• Evolution Container Security для контроля политик безопасности и сканирования уязвимостей контейнерной инфраструктуры, где могут работать корпоративные ИИ-агенты.

• Cloud Logging для централизованного сбора, хранения и анализа логов, отслеживания критических событий.

• Cloud Monitoring для мониторинга облачных ресурсов, визуализации метрик и оповещения об аномалиях.

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

Нужно думать о проблемах безопасности ИИ еще до того, как они появятся. Что сделать превентивно:

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

2. Уберите из базы знаний все лишнее. Проверьте, чтобы не было данных, которые не должны использоваться языковой моделью. 

3. Оцените угрозы информационной безопасности ИИ. Спрогнозируйте возможные риски и распределите их по степени критичности. 

4. Выберите сценарий развертывания модели. Обратите внимание на частное облако или on-premise, если планируете размещать персональные данные и коммерческую тайну. 

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

6. Создайте регламенты использования корпоративной ИИ-платформы. Пропишите классы данных, доступы, меры защиты, ответственных за ИБ, порядок действий при инцидентах. 

7. Проверьте интеграции. Убедитесь, что к LLM не будут подключены лишние системы и критичные ресурсы. 

8. Защитите данные. Предусмотрите фильтрацию запросов и ответов, маскировку, шифрование. 

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

10. Проверьте компоненты LLM-инфраструктуры. Убедитесь в безопасности используемых моделей, библиотек, плагинов и других компонентов. 

Можно провести Red teaming LLM-приложений — имитацию атак на языковые модели. Это позволит найти уязвимости еще до запуска в работу. 

Заключение

Безопасность ИИ строится на трех уровнях одновременно: организационном, техническом и архитектурном. Только комплексный подход снижает риски утечек до управляемого уровня. Часть ответственности можно разделить с провайдером — Cloud.ru предлагает аттестованную инфраструктуру УЗ-1 и Guardrails Filter, доступный как на платформе, так и для собственного контура. Изучите механизмы безопасности Cloud.ru или обсудите архитектуру с командой. 

FAQ

Какие данные нельзя отправлять в нейросети?

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

Что такое prompt injection и как от него защититься?

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

Можно ли использовать LLM с персональными данными по 152-ФЗ?

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

Что такое Guardrails для LLM?

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

Как контролировать использование ИИ сотрудниками?

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

Безопаснее ли локальная LLM, чем облачная?

Безопасность зависит не столько от сценария развертывания модели, сколько от предпринятых  мер защиты со стороны провайдера и самой компании. 

Что должно быть в политике использования ИИ в компании?

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