Особенности защиты ИИ-приложений

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

1. Утечка конфиденциальных данных

При использовании внешних больших языковых моделей (LLM, Large Language Models) или внешних API возникает риск, что данные, отправляемые в модель, станут достоянием третьих лиц. Например, если модель используется для обслуживания клиентов, конкурент или злоумышленник может получить доступ к приватной информации.

2. Недетерминированность и предвзятость

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

3. Атаки через промпты (prompt injection)

Злоумышленник может вставлять специальные подсказки (промпты), которые изменяют поведение модели, заставляют её раскрывать скрытую информацию или исполнять команды, не предусмотренные разработчиком.

4. Отравление обучающего набора данных (data poisoning)

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

5. Неавторизованный доступ и утрата контроля над агентами

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

6. Регуляторные и этические риски

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

Чтобы защитить ИИ-приложения, нужны не просто «привязки к старым методам», но адаптация и целенаправленные меры:

1. Принципы «Security by Design»

Безопасность закладывается в архитектуру ещё до начала обучения модели. Этот подход закреплён в документах:

• ГОСТ Р ИСО/МЭК 27034-1-2014 «Методы и средства обеспечения безопасности. Безопасность приложений»;
  
• NIST AI Risk Management Framework (США, 2023) «Система управления рисками искусственного интеллекта»;
  

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

2. Проверка цепочки поставок и компонентов

Часто модели, таблетки, библиотеки, предобученные веса берутся из внешних репозиториев. Необходимо проверять их на наличие вредоносного кода, бекдоров, нежелательного поведения. Подобные требования формулируются в Методических рекомендациях ФСТЭК по обеспечению безопасности жизненного цикла ПО.

3. Фаерволы для LLM и фильтрация промптов

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

4. Мониторинг и SPM-системы (Security Posture Management)

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

5. Тестирование модели (adversarial testing, robustness)

Имитация атак, в том числе на данные обучения, ввод «вредоносных промптов», тестирование на токсичность, на сбои при некорректных вводах. Регулярное обновление тестов под новые угрозы. Международный опыт закреплён в ISO/IEC 23894:2023 «Информационная технология. Искусственный интеллект. Руководство по менеджменту риска».

6. Регламентирование, документация и права доступа

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

7. Шифрование, сквозная защита данных

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

Для того чтобы на практике уменьшить риски, рекомендуется пройтись по такому чек-листу:

• Составить реестр всех приложений и компонентов, в которых используется ИИ / LLM.
  
• Определить жизненный цикл каждого ИИ-приложения: стадии сборки/обучения, деплоя, эксплуатации, обновлений.
  
• Зафиксировать внешние взаимодействия: с какими системами соединяется модель (APIs, базы данных, веб-интерфейсы).
  
• Убедиться, что исходный код / веса моделей известны, их происхождение проверено.
  
• Проверить, кто является бизнес-владельцем, кто отвечает за безопасность и эксплуатацию.
  
• Наличие документации: спецификации, политики безопасности, инструкции, правила использования.
  
• Использование фаерволов / прокси-слоев / модулей фильтрации введённых запросов и ответов модели.
  
• Мониторинг событий безопасности, логирование, интеграция в SIEM-системы.
  
• Тестирование модели на устойчивость: атаки, манипуляции данными, промпт-атаки.
  
• Регулярный пересмотр и обновление мер защиты по мере появления новых угроз.
  

Защита ИИ-приложений — задача существенно более комплексная, чем защита классического ПО. Поведение моделей зависит не только от кода, но и от данных, пользователей, провайдеров (если используется внешняя модель), от изменений в окружении.

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