Работа под названием The Fragility of Jailbreak Robustness Across Operational States, принятая в EMNLP 2026 Findings, выдвигает узкий и неприятный тезис: показатель устойчивости модели — это свойство той конфигурации, в которой его измеряли, а не самой модели. Если оставить атаку неизменной и поменять только обычный системный промпт — никак не связанный с безопасностью, — показатель успешности атаки в одном случае вырос с 2% до 58%, то есть на 56 процентных пунктов. Результат охватывает семь выровненных моделей и три репрезентативные атаки.

Предлагаемый механизм

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

Чего в статье не утверждается

В ней не говорится, что модели стали менее безопасными, и заголовок в духе «модели легко подвергаются jailbreak» переворачивает аргумент. Речь идет об измерении: отчет об устойчивости как об одной цифре ASR в стандартной конфигурации создает ложную уверенность, потому что это число не выдерживает столкновения с операционным промптом. Это критика методологии, используемой в safety card от вендоров и публичных бенчмарках, а не новая атака.

Две детали, которые важно не перепутать

Речь идет о принятии в Findings, а не в основной трек EMNLP — различие, которое пресс-резюме часто опускают. И дата на arXiv относится к подаче конкретной версии: это v1, отправленная 31 августа, без более поздних ревизий, так что это не старая работа, всплывшая заново под новой датой в списке.

Почему практикам стоит обратить внимание

При развертывании системный промпт пишет интегратор, а не лаборатория. Если устойчивость, измеренная с лабораторным промптом по умолчанию, не переносится, то каждое значение безопасности, которое видит покупатель, описывает конфигурацию, которой в его продукте не будет. Практический вывод таков: red-teaming нужно проводить на реальном продакшн-промпте и повторять каждый раз, когда этот промпт меняется, — а сегодня это считают обычной правкой копии.