Защита ИИ-систем: что нельзя игнорировать в 2026 году

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

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

Когда речь заходит об искусственном интеллекте, большинство представляет себе ту самую языковую модель, которая генерирует ответы. Однако сведение всей системы к одному лишь языковому ядру — опасное упрощение, которое может привести к появлению «слепых зон» в защите.

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

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

Вопрос регулирования искусственного интеллекта в 2026 году остается одним из наиболее динамично развивающихся направлений законодательства. Разные страны подходят к этому вопросу по-своему.

В Евросоюзе принят риск-ориентированный подход, где основное внимание уделяется защите прав человека, а также управлению персональными данными. В США и Великобритании отдельного комплексного стандарта пока не существует — требования варьируются в зависимости от отрасли применения ИИ. В Китае подход иной: там не ограничивают технические особенности работы ИИ, но вводят обязательные требования к наличию механизма отключения системы и к маркировке генерируемого контента.

Российское регулирование ближе к китайской модели и построено в виде иерархической системы.

На верхнем уровне находится Указ Президента № 490, который вводит единую терминологию и базовые требования для всех. Далее следуют документы для государственных информационных систем (ГИС). Базовым здесь является приказ ФСТЭК России № 117, который устанавливает общие требования к системам. Он детализируется двумя ключевыми документами:

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

Кроме того, ФСТЭК России ведет отдельный раздел угроз для систем искусственного интеллекта, причем перечень угроз различается для вендоров и интеграторов.
В ближайшее время ожидается принятие еще двух важных документов:

• Проект ГОСТ Р «Искусственный интеллект в критической информационной инфраструктуре. Общие положения» — описывает требования к жизненному циклу ИИ-систем.
• Проект ГОСТ по безопасной разработке систем ИИ — о безопасной разработке систем, включающих технологии искусственного интеллекта.

Помимо перечисленных документов, существует более 140 различных ГОСТов и предварительных стандартов по ИИ, разведенных по отраслевым доменам, однако они носят достаточно специфический характер.

Атака на LLM принципиально отличается от атаки на классическое ПО. Мы имеем дело не с детерминированной системой, а с вероятностной, работающей по принципам, схожим с человеческим мышлением. И это открывает возможности для атак методами социальной инженерии и психологического воздействия.

Все многообразие атак на LLM можно разделить на две большие категории:

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

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

Он не повторяет, но основан на известных фреймворках, в том числе в части угроз, мер защиты и описания модели нарушителя на таксономии угроз Swordfish Security, проектах ГОСТ по ИБ ИИ, НПА и методических документах ФСТЭК России, использует OWASP Top 10 for LLM Applications и NIST AI RMF в части тест-кейсов и метрик, а также предоставляет возможность адаптации под любую другую методологию.

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

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

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

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

На этом этапе формируется дорожная карта организации защиты.

Для технических мер составляется соответствие между конкретными защитными мерами и инструментами, их реализующими. Для каждого инструмента учитывается несколько критериев:

• тип меры;
• стадия жизненного цикла системы;
• тип системы — инструменты для одной системы могут быть бесполезны для другой;
• возможность интеграции;
• бюджет — open-source или коммерческое решение.

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

Важная особенность: большинство этапов автоматизировано. С использованием средств автоматизации весь процесс может быть выполнен одним человеком в сжатые сроки.

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

Можно выделить четыре категории таких инструментов.

1. Сканеры моделей, пример — Model Scan. Интегрируется в CI/CD, сканирует файлы моделей на наличие известных уязвимостей.
2. LLM-прокси, пример — LiteLLM. Выполняет функции фильтрации контента, подключения внешних файрволов, контроля доступа и биллинга. Один из самых популярных инструментов в своей категории.
3. LLM-файрволы, пример — NeMo Guardrails, LLMGuard. Встраиваются между ядром модели и веб-интерфейсом, контролируя запросы и ответы:
4. LLMGuard работает на основе регулярных выражений, но позволяет дообучать небольшую модель (порядка 0.2-0.3 млрд параметров) для покрытия новых атак.
5. NeMo Guardrails использует LLM для проверки диалога на соответствие требованиям, описанным на специальном языке.
6. Инструменты защиты чувствительных данных, пример — Microsoft Presidio. В отличие от предыдущих категорий, Presidio не обнаруживает атаки, а предотвращает утечки данных. Он находит чувствительную информацию в тексте, маскирует ее перед отправкой в модель и восстанавливает при получении ответа.

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

На коммерческом рынке представлены два основных типа продуктов:

• Сканеры — для оценки защищенности.
• Защитники — для активной защиты.

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

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

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

Обработка запроса:

1. Нормализация — приведение текста, приведение к нормальной форме, разворачивание сленга, чтобы восстановить то, что пользователь на самом деле хотел сказать.
2. Параллельная проверка детекторами — детектор угроз, детектор чувствительных данных, контентные политики.
3. Принятие решения — пропустить, заблокировать или санкционировать/замаскировать персональные данные.
4. Проверка ответа — контентная безопасность и поиск утечек в ответе модели.

Решение может работать в режиме reverse-proxy или как внешний guardrail. Также поддерживается режим мониторинга, когда трафик идет через систему, события создаются, но ничего не блокируется. В случае недоступности шлюза настраивается стратегия fail-open или fail-close.

Линии защиты:

1. Threat Detector — обнаружение джейлбрейков и промт-инъекций. Настраивается индивидуально под систему с регулировкой порогов чувствительности.
2. Детектор чувствительных данных — обнаруживает передачу чувствительных данных. Использует регулярные выражения с валидаторами, семантический анализ, контекстный поиск с поддержкой русского языка. Более 25 типов данных, включая паспортные данные, ИНН, СНИЛС, ФИО, а также секреты (ключи, токены, пароли). Возможны блокировка, санитизация или мониторинг, а на выходе — обратимое маскирование.
3. Content Safety — определяет тему запроса и ответа по категориям (нелегальная деятельность, политика и т.д.). Можно задать, на какие темы система может общаться, а на какие нет.
4. Защита от обфускации — очистка от гомоглифов, скрытых символов, кодирований (Base64, ROT), разбиений слов. Можно либо очистить запрос, либо заблокировать его.
5. Пользовательские детекторы — возможность добавлять кастомную логику: словари, стоп-фразы, регулярные выражения или подключение собственных моделей для учета корпоративной специфики.

В ближайшее время планируется запуск еще двух направлений:

• RAG — инспекция контекста из базы знаний, поиск промт-инъекций в чанках.
• Агенты — инспекция вызовов инструментов, политики по имени и параметрам, трассировка цепочек действий.

Защита не может быть разовым мероприятием. Сегодняшняя защищенность не гарантирует защищенности завтра — ландшафт угроз меняется стремительно, и то, что работало вчера, может оказаться бесполезным уже завтра.
Что можно сделать в ближайшее время:

• В течение получаса. Если в вашей системе используется агент, первым делом ограничьте его права. Делать это следует классическими методами управления доступом, а не с помощью LLM-методов, которые сам агент мог бы обойти. Кроме того, добавьте в системную инструкцию модели жесткие ограничивающие формулировки — четко пропишите, что модели запрещено делать, какие действия выходят за рамки дозволенного. Это даст хотя бы минимальный уровень безопасности.
• В течение часа. Внедрите LLM-прокси, например LiteLLM, и подключите к нему LLM-файрвол. Выбор между open-source и коммерческим решением зависит от ваших требований и бюджета, но сам факт наличия такой связки критически важен для контроля трафика и фильтрации угроз.
• На постоянной основе. Регулярно настраивайте логирование и мониторинг, создавайте резервные копии, разрабатывайте плейбуки для реагирования на инциденты, тестируйте различные сценарии нарушений и проводите регулярные упражнения по Red Teaming — моделированию действий злоумышленников. Только непрерывный процесс позволит поддерживать адекватный уровень защиты.

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

Начать можно с малого — и это лучше, чем не начать вовсе. Ограничить права агентов, внедрить прокси и файрвол, настроить мониторинг. А дальше — выстраивать защиту системно, тестировать, обновлять, не останавливаться. Угрозы не стоят на месте — и защита не должна стоять на месте вместе с ними.