Что это за проверка и чем она не является
Тест устойчивости — целенаправленный прогон вашего ИИ-сервиса атаками класса промпт-инъекций с фиксацией результатов. Это техническая процедура для инженеров: она отвечает на вопрос «сколько из предъявленных атак прошли и что именно они смогли сделать».
Не путайте с соседними активностями. Самооценка зрелости защиты ИИ — управление уровнем: инвентаризация, политика, процессы; она не требует атак и не измеряет конвейер. Полноценный ИИ-RED шире: там инъекции — один из разделов наряду с извлечением данных, атаками на агентов и инфраструктурные предпосылки. Наша тема — узкий и самый частый первый шаг: воспроизводимая проверка именно на инъекции.
Тестовый контур
Проверять продакшен атаками — плохая идея: страдают реальные пользователи, данные и статистика. Стенд собирается как уменьшенная копия боевого конвейера:
- та же версия модели и тот же системный промпт;
- те же слои защиты и те же права инструментов — насколько это возможно без риска;
- имитированные данные: правдоподобные, но не настоящие персональные и коммерческие сведения;
- фиксация полного следа: запрос, контекст, действия инструментов, ответ.
Расхождение стенда и продакшена — главный источник самообмана. Любое отличие, влияющее на поведение модели (другая температура, другой размер контекста, отсутствующий фильтр), обесценивает результат. Проще всего держать автоматическую сборку стенда из тех же артефактов, что уходят в релиз.
Корпус атак
Основа измеримости — фиксированный набор инъекций, который живёт в репозитории рядом с кодом. Рабочая структура:
| Раздел корпуса | Что содержит | Откуда берётся |
|---|---|---|
| Прямые базовые | просьбы игнорировать правила, мнимые служебные сообщения | публичные наборы атак |
| Прямые социальные | ролевые и легенды о полномочиях | адаптация под ваш домен |
| Косвенные файловые | закладки в PDF, таблицах, офисных форматах | генерация тестовых документов |
| Косвенные контентные | скрытый текст страниц, память, базы знаний | ваш контент-конвейер |
| Кодированные | упакованные команды, редкие языки, разбиения | расширение по итогам инцидентов |
| Регрессионные | реальные атаки, замеченные в эксплуатации | журнал инцидентов |
Корпус пополняется после каждого инцидента и каждого изменения в защите — так накапливается ваша собственная база знаний об атаках, и повторные прогоны становятся строже.
Метрики
Ключевая метрика — доля успешных атак: сколько инъекций из корпуса достигли цели. «Достигли цели» определяется отдельно для каждого класса последствий:
- раскрытие — в ответе появились служебные данные или чужой контекст;
- манипуляция — ответ содержит навязанное содержание или ссылку;
- действие — выполнена несанкционированная операция через инструменты;
- эскалация — недостоверная информация ушла в машинной сводке человеку.
Дополнительно фиксируются полнота журналирования (какая доля атак оставила распознаваемый след) и стоимость прогона. Смешивать классы в один процент не стоит: сервис с нулевыми действиями и высокой манипуляцией и сервис наоборот — это разные приоритеты доработок.
Протокол прогона
- Зафиксируйте конфигурацию: модель, промпт, слои защиты, версия корпуса. Без этого сравнение прогонов бессмысленно.
- Прогоняйте каждую атаку серией с вариациями формулировок: единичная попытка меряет удачу, серия — устойчивость.
- Каждое срабатывание сопровождайте сохранением полного следа сессии — это материал для разбора, а не просто галочка.
- Сведите результаты по классам последствий и компонентам конвейера: где именно проскочило — вход, разметка, инструменты, выход.
- Сформируйте отчёт: таблица результатов, топ уязвимых мест, рекомендации с приоритетом по тяжести последствия.
Регламент повторений
Прогон имеет срок годности. Повторять обязательно: при смене версии модели, изменении системного промпта, добавлении инструментов и прав, расширении каналов данных, после каждого внедрённого контрмеры — чтобы подтвердить эффект. Организационно удобен двойной ритм: быстрый дымовой корпус на каждый релиз и полный корпус по расписанию.
Результаты стоит вплетать в цикл разработки: отчёт теста — это вход для задач разработки, а не документ для архива. Там, где доля успешных атак по классу «действия» не снижается после двух итераций защит, корректный вывод архитектурный — убирать полномочия, а не шлифовать фильтры.
Типичные ошибки внедрения
Первая — тестирование модели вместо системы: прогон голого интерфейса модели показывает одну картину, а продакшен-конвейер с фильтрами, правами и интеграциями — принципиально другую; мерить нужно вторую. Вторая — несравнимые прогоны: корпус пополнился, стенд обновился, конфигурация другая — и динамика «стало лучше» превращается в самообман; лечится жёсткой фиксацией конфигурации в каждом отчёте. Третья — однобокие метрики: доля успешных атак без разбивки по классам последствий скрывает самое дорогое — действия и раскрытия. Четвёртая — тест как событие: одиночный прогон перед запуском даёт снимок момента, который устаревает с первым же изменением конвейера. Пятая — отсутствие владельца: отчёты есть, ответственных за закрытие находок нет, и картина рисуется только на бумаге. Избегание этих пяти ошибок само по себе поднимает ценность проверки сильнее, чем наращивание корпуса атак.