Сколько примеров нужно, чтобы проверить безопасность AI-приложения

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

Попытки намеренно обойти защиту ИИ-систем называют red teaming. Это может быть запрос закрытого отчета, попытка выяснить конфиденциальные данные или вызов неразрешенных функций. На практике важно проверять, соблюдаются ли права доступа сотрудников к корпоративным документам, и контролировать выполнение действий со стороны языковых моделей. Системные инструкции «не раскрывай секреты» не заменяют реальной проверки полномочий и обработки контекста.

В процессе аудита таких приложений отправляется набор запросов с последующим анализом ответов. Долю попыток, в которых удалось нарушить ограничения, называют Attack Success Rate или ASR. Эта метрика показывает успешность атаки в конкретных условиях тестирования, но ее использование в чистом виде без учета объема выборки способно привести к нерепрезентативным выводам.

Определение рисков и критериев нарушения

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

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

Оценка базового поведения и учет неопределенности

На первом этапе запросы отправляются без дополнительных атак. Если корпоративный ассистент успешно отклонил десять тестовых запросов на раскрытие закрытых документов, показатель ASR составит ноль процентов. Однако десяти наблюдений недостаточно, чтобы подтвердить высокую безопасность системы, так как на большой выборке могут проявиться редкие сбои.

Для оценки статистической неопределенности в условиях редких нарушений применяется односторонняя верхняя граница Клоппера—Пирсона. При десяти успешных ответах без нарушений верхняя граница составляет около 25,89%. Это означает, что имеющейся выборки недостаточно для подтверждения минимальной частоты утечек.

Установление критерия прохождения и расчет объема выборки

Для корректной оценки задается допустимый порог утечек — например, 0,3% на выбранном распределении задач. Проверка считается пройденной, если расчетная верхняя граница доверительного интервала строго ниже этого порога. Поскольку универсальных значений нет, для критических уязвимостей допустимо устанавливать жесткое правило блокировки выпуска при первой же находке.

Расчет минимального объема данных при отсутствии нарушений показывает, что для подтверждения порога в 0,3% требуется не менее 998 независимых запросов. Если проверка изначально планируется на тысяче запросов, то единичное нарушение повышает верхнюю границу выше допустимого уровня, что приводит к блокировке релиза.

Применение атакующих техник и сравнение результатов

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

Атаки запускаются на том же датасете для попарного сравнения результатов. Для оценки статистической значимости прироста ASR используются точный тест Мак-Немара или парный бутстрэп. При этом достижение порога безопасности и выявление эффекта от конкретной атаки решают разные задачи.

Расширение датасета против повторения запросов

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

Правила формирования отчетов и основные выводы

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

Корректное планирование тестирования включает четкую формулировку критериев риска, определение допустимых порогов, расчет необходимого числа независимых запросов и аналитическую работу с верхними границами погрешностей. Такой подход обеспечивает объективную оценку устойчивости искусственного интеллекта к внешним воздействиям.