Red-teaming — стандартна процедура перевірки мовної моделі перед релізом — здебільшого зводиться до технічних прийомів: adversarial-промптів, спеціальних символьних суфіксів і відомих шаблонів jailbreak-запитів. За даними The Decoder, дослідники застосували техніки з психології, щоб показати: цей підхід систематично пропускає цілий клас вразливостей, які не мають нічого спільного з технічним обходом фільтрів.

Йдеться не про черговий спосіб «зламати» чат-бота хитрим промптом, а про сам процес тестування безпеки AI-систем. Команди безпеки здебільшого перевіряють моделі на відомих бібліотеках атак і формальних чек-листах — і саме тому пропускають маніпуляції, які працюють на людях щодня: побудову довіри, поступову ескалацію прохання, апеляцію до авторитету.

Для команд, що виводять AI-продукти в прод, це неприємний, але корисний сигнал: пройдений red-teaming ще не означає, що модель стійка до реального співрозмовника, який діє не за шаблоном атаки, а за логікою переконання.

Що конкретно показали дослідники?

Дослідники продемонстрували, що методи, запозичені з психології — науки про те, як одна людина переконує іншу, — виявляють прогалини саме в методології тестування безпеки, а не лише в конкретних відповідях моделі. Іншими словами, під питанням опинився не окремий фільтр контенту, а сам критерій «модель пройшла red-teaming».

Як психологічні техніки обходять захист моделі?

Механізм спирається на ту саму вразливість, що робить людей піддатливими до соціальної інженерії: моделі навчені бути корисними, послідовними і чемними зі співрозмовником, який поводиться впевнено й доброзичливо. У сфері AI safety це вже фіксували під назвою sycophancy — схильність моделі погоджуватися й підлаштовуватися під тон і рамку, яку задає користувач, замість того, щоб послідовно тримати межу.

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

Що з цим робити командам безпеки і AI-білдерам вже зараз?

Найпростіший практичний висновок: одноразовий прогін бібліотеки jailbreak-промптів більше не можна вважати достатнім доказом безпеки моделі перед релізом. Практичний підхід — розглядати red-teaming як безперервний процес, а не одноразовий гейт перед виходом у прод.

Висновок AiiN

Наша теза проста: red-teaming у нинішньому вигляді перевіряє, чи модель стійка до відомих атак, а не до живого співрозмовника, який вміє переконувати. Це різні навички захисту, і друга з них поки що майже не формалізована в індустрії. Компаніям, які покладаються на разовий аудит безпеки перед релізом, варто розглядати психологічно вмотивовані сценарії як окремий клас тестів — з власними метриками, а не як підрозділ звичайного jailbreak-бенчмарку. Для розробників, які будують AI-агентів з розширеними правами доступу, це особливо критично: чим довший і природніший діалог з агентом, тим більше в нього шансів на поступове «розхитування» через контекст, а не через один шкідливий промпт.

Чим психологічні атаки на AI відрізняються від звичайного jailbreak-промпту?

Звичайний jailbreak-промпт — це один запит або короткий заздалегідь підготовлений ланцюжок, розрахований на обхід фільтра контенту за один-два кроки. Психологічна атака розгортається протягом довшої розмови й спирається на поступове накопичення довіри та контексту, тому одиничний фільтр промпту її здебільшого не помічає.

Що таке red-teaming у контексті безпеки AI?

Red-teaming — це практика навмисного тестування AI-системи на вразливості до релізу: команда імітує зловмисника й намагається змусити модель порушити власні правила безпеки. Традиційно він фокусується на технічних і лінгвістичних прийомах обходу фільтрів, а не на довготривалих сценаріях соціальної інженерії.

Чи можна автоматизувати захист від таких маніпуляцій?

Частково — так: моделі можна додатково тренувати розпізнавати патерни ескалації й апеляції до авторитету в межах діалогу, а не лише в окремому запиті. Але повністю автоматичний захист малоймовірний, доки оцінка безпеки не почне враховувати динаміку всієї розмови, а не тільки останню репліку.