Как изменилась индустрия AI Security за 2025 год?

В начале 2026 года мы (авторы телеграм-каналов по безопасности ИИ) собрались, чтобы подвести итоги прошедшего года и обсудить, куда движется безопасность ИИ в общем и целом. Разговор получился честным, на наш взгляд. Без маркетингового глянца, с открытыми разногласиями и скептицизмом там, где скептицизм заслужен.

Участники дискуссии – Я, Артём Семенов, автор PWNAI ^[1]; Борис Захир, автор канала Борис_ь с ml ^[2]; Евгений Кокуйкин, создатель HiveTrace и автор канала Евгений Кокуйкин – Raft ^[3]; и Владислав Тушканов, исследователь безопасности LLM и компьютерный лингвист, автор канала llm security и каланы ^[4].

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

Гардрейлы: от примитивов к цепочкам классификаторов

Если выбирать одно слово, определившее AI Security в 2025 году, это будет «гардрейлы». Ещё два года назад, когда тема только приходила на российский рынок, под гардрейлами понимались простейшие классификаторы – по сути, фильтры на входе и выходе, которые работали без учёта контекста пользователя, содержимого файлов, RAG-пайплайнов и бизнес-логики приложения.

За 2025 год ландшафт изменился радикально. Артём отметил, что появилось множество решений, среди которых выделяется подход Anthropic – не единичный классификатор, а цепочка классификаторов (Constitutional Classifiers ++ ^[5]), выполняющая верификацию в несколько этапов для выявления промпт-атак. В эффективности этого подхода – он убедился на собственном опыте ^[6], потеряв тестовый аккаунт стоимостью 200 долларов при попытке протестировать систему на базовых задачах кибербезопасности. При этом у Google, по его наблюдениям, порог реакции ^[7] значительно мягче.

Важно терминологическое замечание от Евгения: в англоязычной литературе под «guardrails» часто понимают любые меры защиты в широком смысле, тогда как в техническом контексте это именно внешние модели-классификаторы (LlamaGuard ^[8], Qwen3Guard ^[9] и подобные), работающие на входящих и исходящих сообщениях. Это различие существенно, потому что из него следует вопрос: а где именно проходит граница ответственности?

Выравнивание (alignment) модели задаёт общечеловеческие нормы – не генерировать противоправный контент, не помогать в создании опасных веществ. Но выравнивание нельзя гибко настроить под конкретную компанию/бизнес-задачу. Максимум – системный промпт. А гардрейлы добавляют защиту именно бизнес-контекста: чтобы чат-бот не рекламировал продукты конкурентов, чтобы агент не вызывал недопустимые в данной среде инструменты, чтобы утечка данных через RAG не случилась на ровном месте.

Владислав приводит наглядный пример: представьте, что корпоративный помощник Zoom в ответ на жалобу пользователя предлагает «попробовать Google Meet». В общечеловеческом смысле это нормальный совет. В бизнес-контексте – недопустимый. Alignment модели здесь не поможет, а гардрейл – вполне может.

Пять уровней защиты: от данных до red teaming

В ходе дискуссии Артём рассказал о пятиуровневой модели ^[10] защиты ИИ.

Первый уровень – базовое выравнивание (alignment). Это работа с ценностями модели до момента деплоя: RLHF, DPO, формирование векторов правильных и неправильных ответов на конкретные типы вопросов. Фундамент, но фундамент с ограничениями – alignment поставляется вместе с моделью и зачастую несёт политическую специфику страны в которой модель была сделана.

Второй уровень – интерпретируемость и работа с активациями. Сюда входят мониторинг активаций, unlearning (разобучение), а также свежие исследования Anthropic по удалению и добавлению активаций ^[11]на этапе инференса для коррекции поведения ^[12] модели в реальном времени.

Третий уровень – архитектурная защита: подходы к предотвращению отравления данных, очистка датасетов от предвзятости на ранних этапах, системные промпты как дополнительный барьер.

Четвёртый уровень – гардрейлы.

Пятый уровень – red teaming как непрерывный процесс.

В ходе обсуждения был выявлен пробел: отсутствие «нулевого уровня» – защиты данных не в смысле предотвращения утечки, а в смысле подхода к обработке, извлечению небезопасной информации и минимизации факторов, которые могут привести модель к небезопасным действиям. Без этого базового слоя вся вышестоящая архитектура защиты теряет устойчивость.

Борис предложил более сжатую группировку – три-четыре магистральных «пласта безопасности», объединяющих некоторые уровни (первый и второй) и добавляющих слой, связанный с архитектурой моделей, для будущего развития. В него же войдет и безопасность аддитивных архитектурных элементов моделей – как LoRA-адаптеров. Особенно актуальным этот слой безопасности может стать при развитии идей моделей с нераздельным обучением ^[13] и инференсом (спайковые нейросети – 1 ^[14], 2 ^[15], или например Google NL ^[16]). 

Системный промпт: полезен, но не спасёт

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

Борис предложил рассматривать безопасность в масштабе. Есть два класса угроз: массовые, частые и простые атаки (условные «промпт-кидди», по аналогии со «скрипт-кидди») и редкие, но сложные и эффективные действия APT-группировок. Системный промпт надёжно отсекает первую категорию – снижает нагрузку на гипотетический SOC, который мог бы мониторить промпт-атаки. Но от целенаправленной, продуманной атаки системный промпт не защитит. Его ценность – в снижении шума, а не в обеспечении реальной безопасности.

Владислав добавил практический нюанс, который часто упускают из виду: системный промпт сжирает контекст модели. Он провёл значительное время за написанием защитных системных промптов и обнаружил прямую корреляцию между объёмом защитных инструкций и деградацией качества ответов. Для моделей вроде Claude, способных усваивать большой объём информаци, это терпимо. Но для маленьких моделей в три миллиарда активных параметров (Владислав привёл в пример Qwen 3 Coder 30B) любые дополнительные инструкции по безопасности в системном промпте практически убивают полезность модели – весь контекст внимания ^[17] уходит на обработку ограничений, и на пользовательский запрос ресурса уже не остаётся.

Артём поднял связанный вопрос об утечках системных промптов – в частности, промпта ^[18]Claude Sonnet 3.7. Промпт выглядит объёмным, но далеко не всё в нём может быть своевременно интерпретировано моделью во время сессии. Появляются «слепые зоны», которые делают системный промпт неполноценным средством защиты.

Стоимость атак на GenAI: триада подходов

Один из самых практичных вопросов стрима: как оценить стоимость атаки на GenAI-систему, если в классической кибербезопасности есть прозрачные метрики через даркнет-маркетплейсы?

Борис предложил трёхуровневую классификацию по степени автоматизации:

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

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

Полная автоматизация с использованием LLM – когда одна модель атакует другую, третья выступает судьёй качества атаки. Здесь стоимость конкретна и измерима: расход токенов через API. Можно подсчитать, сколько стоит одна итерация AutoDAN или аналогичного метода.

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

Принципиальное наблюдение Бориса: любая кибератака на GenAI –  это в первую очередь кибератака. Все существующие практики оценки стоимости классической кибератаки здесь применимы и не меняются. GenAI добавляет новую поверхность атаки, но не отменяет старые.

Агенты – главный вектор угроз

Владислав назвал 2025-й годом агентов. Не в маркетинговом смысле, а в смысле реальных систем, выполняющих реальные задачи на продакшене: Cursor, Claude Code и другие агентные среды для разработки – это инструменты, способные навредить, и в которых успешная промпт-инъекция может привести к серьёзным последствиям.

Он напомнил о кейсе с Amazon Q Developer ^[19], когда злоумышленник сумел пропихнуть промпт-инъекцию, которая была нацелена на форматирование дисков у пользователей. Атака не была полностью успешной, но сам факт показателен: атака на цепочку поставок с промпт-инъекцией в качестве вредоносной нагрузки – это уже реальность.

Борис дополнил примером кейса s1ngularity ^[20]: через GitHub Actions вредоносные промпт-атаки попадали в AI-ассистент, который в итоге генерировал вредоносные скрипты. Эксплойт был зафиксирован и закрыт в последующем обновлении GitHub, но это реальный случай, когда LLM стала частью kill chain. С похожими кейсами можно ознакомиться в статье ^[21].

Евгений обратил внимание на эволюцию ^[22] самого понимания рисков на примере фреймворка CyberSecEval ^[23]. В первых версиях основной фокус был на использовании LLM злоумышленниками для написания вредоносного ПО. И только к версии 3.1 были добавлены промпт-инъекции как отдельная категория риска. Понимание угроз раст��т вместе с возможностями моделей и всегда запаздывает.

Security Lingua и проблема стоимости защиты

Отдельного внимания заслуживает подход, который Борис назвал «деджейлбрейкером» – исследование Security Lingua ^[24]от Microsoft. Суть метода: отдельная модель преобразует каждый входящий промпт в «чистую инструкцию», деобфусцируя техники промпт-атак, маскирующие вредоносный intent. Это позволяет основной модели или гардрейлу быстрее и точнее определить, является ли запрос опасным.

Звучит убедительно, но участники дискуссии сошлись во мнении, что у любого наслоения средств защиты есть фундаментальная проблема: стоимость. Одна модель дешифрует и снимает обфускацию с промпта. Вторая определяет, опасен ли «истинный замысел». Третья генерирует ответ. Четвёртую можно поставить на фильтрацию на выходе модели. Надёжно? Вероятно. Но стоимость такой инференс-цепочки – в 4 раза больше от базовой бизнес-системы.

Артём указал на ещё одну проблему: intent-модель, как правило, сама является LLM. Она тратит токены на генерацию summary по промпту и увеличивает latency. Для агента, которому нужно оперативно выявлять угрозы или выполнять задачи в реальном времени, эта просадка может быть критической.

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

LoRA и неожиданная география бэкдоров

Борис поделился результатами своего недавнего погружения в тему безопасности LoRA-адаптеров – область, которая оказалась значительно глубже, чем кажется на первый взгляд.

Распространённое заблуждение: единственный вектор опасности LoRA – это внесение вредоносного поведения ^[25] через fine-tuning. На практике ландшафт угроз богаче. Борис обратил внимание на исследования (1 ^[26], 2 ^[27], 3 ^[28]), показывающие, что бэкдоры, внесённые через обучение в LoRA-адаптеры, концентрируются преимущественно в feed-forward слоях. Поскольку LoRA – это, по сути, небольшой трансформерный слой, можно «снести» feed-forward-голову, оставив только attention-слои (key, query, value), и сохранить полезные знания, удалив бэкдор. Более того, feed-forward-слой можно заменить на аналогичный от легитимного адаптера — и модель сохраняет качество, теряя закладку.

Этот инсайт указывает на более глубокий тренд: архитектурное понимание безопасности моделей. Пока это скорее передний край науки, чем инструментарий для индустрии. Но именно здесь, по мнению Бориса, лежит самое значимое направление безопасности ближайших пяти лет – архитектура, интерпретация и гардрейлы, основанные на активациях.

MLSecOps: как собрать команду с нуля

В ответ на вопрос аудитории о структуре команды MLSecOps участники сформулировали минимальный состав:

ML/MLOps-инженер или Data Scientist – человек, который понимает, как модели создаются, деплоятся и обслуживаются. Без этого фундамента разговор о безопасности ML бессмыслен.

VM-эксперт в области ML – специалист, формирующий подход к управлению уязвимостями, определяющий требования и перечень инструментов для каждого этапа жизненного цикла модели.

Offensive-специалист – человек с атакующим складом ума, способный проводить продолжительный red teaming. Артём подчеркнул: это база, потому что невозможно построить единый ландшафт угроз для разных систем – его нужно выявлять для каждой.

Аналитик – специалист, поставляющий информацию «с полей»: свежие уязвимости, новые векторы атак, актуальные публикации. Индустрия развивается стремительно, и без выделенного ресурса на мониторинг можно отстать за квартал.

Защитник, настраивающий гардрейлы и выстраивающий взаимодействие с классическими экспертами кибербезопасности.

Евгений обозначил проблему разделения ролей. Процесс MLSecOps требует людей, которые хорошо понимают, как создаются модели, и основы информационной безопасности. Но те, кто создаёт модели, не хотят заниматься безопасностью – они хотят делать модели лучше и быстрее выводить их в релиз. А специалисты по безопасности не всегда выбирают карьеру в data science и статистике. Борис подтвердил, что сейчас вакансий значительно больше, чем людей, компетентных одновременно в безопасности, ML и бизнес-контексте.

Прогнозы: что ждёт AI Security

В завершении каждый из участников поделился прогнозом.

Евгений предсказал появление в продакшен агентов, которые активно читают почту и отвечают на входящие письма, таких, как Gemini-ассистент. Для таких систем станут актуальны атаки, при которых злоумышленник, зная только email-адрес, может через промпт-инъекцию во входящем письме повлиять на поведение системы или спровоцировать утечку данных. Спрос на безопасность ИИ уже растёт и сейчас, и это видно по статистике поисковых запросов в Яндекс ^[29]. Но настоящий всплеск произойдёт, когда эти решения массово встанут на продакшен.

Владислав сформулировал «грустный прогноз»: в 2026 году мы увидим первый крупный кейс, когда корпоративная инфраструктура будет скомпрометирована через атаку на LLM, и атака на модель станет частью kill chain. Пока, за пределами DEF CON и Black Hat, конкретных публичных демонстраций реальной эксплуатации не было. Появление такого кейса кардинально изменит отношение к промпт-инъекциям – от академического любопытства к операционной необходимости защиты.

Артём подсветил вектор, зависящий от политики стран: по мере того как национальн��е модели становятся инфраструктурой, на которой работают сервисы целых стран, внешние акторы получают мотивацию ^[30] для их отравления, атаки и вывода из строя. Это создаёт целевую картину: зачем нужна безопасность ML на государственном уровне. 2026–2029 годы — период, когда эта тема будет набирать «жирок, кожу и кости».

Борис сделал ставку на долгосрочный тренд: самое значимое направление ближайших пяти лет — архитектурная безопасность и интерпретируемость, включая гардрейлы, основанные на активациях. Текущая парадигма GenAI — это пузырь с точки зрения ^[31] архитектурной зрелости. Когда пузырь схлопнется и архитектуры стабилизируются, появится реальная возможность строить безопасность на уровне внутренней структуры моделей, а не наложенных костылей.

Вместо заключения

Сквозная мысль дискуссии, с которой согласились все участники: безопасность — это процесс, а не состояние. Ни один подход не является панацеей. Гардрейлы не спасут от целевой атаки. Alignment не адаптируется под бизнес-контекст. Системный промпт деградирует с уменьшением модели. Автоматизация red teaming не равно полноценная безопасность, а лишь один из необходимых компонент.

Индустрия AI Security повторяет путь классической кибербезопасности – от наложенных средств к архитектурным решениям, от реактивной защиты к проактивному мониторингу. С одним отличием: скорость развития самих моделей опережает скорость развития средств их защиты. И пока этот разрыв сохраняется, каждый из обсуждаемых подходов остается компромиссом.

Но компромиссы – это и есть кибербезопасность.