Основные моменты:
- ИИ red teaming — это намеренное состязательное тестирование, цель которого заставить систему ИИ дать сбой, чтобы обнаружить и исправить ошибки до того, как с ними столкнутся ваши пользователи.
- Модель может успешно пройти любые тесты на уровне промптов, в то время как окружающая ее система потерпит неудачу. При одном из корпоративных развертываний автоматический оценщик сломал систему в 3% из 980 попыток, причем в семи из десяти случаев это были диалоги из нескольких шагов. Тестировщики-люди, работавшие со всей системой, вызывали сбои в 68% своих сессий.
- Обычные пользователи ломают систему почти так же часто, как и квалифицированные злоумышленники. В том же проекте опытные специалисты по состязательному тестированию добивались успеха в 73% случаев. Обычные пользователи без вредоносных намерений все равно провоцировали нарушения в 61% случаев.
- Производственная система ИИ имеет пять слоев для тестирования: промпт, контекст, с которым работает система, вызываемые ею инструменты, координируемые ею агенты и сам набор правил.
- Для тестирования требуется письменное определение того, что считается нарушением для конкретной системы, и цикл: тест, исправление, повторный тест. Прогресс проявляется в изменении характера сбоев, а не в едином совокупном показателе.
Где заканчивается тестирование моделей
Тестирование моделей ИИ на предмет безопасности и устойчивости к злоумышленникам — это устоявшаяся практика. Microsoft провела red teaming для 100 генеративных ИИ-продуктов, OpenAI привлекает внешние команды для тестирования своих передовых моделей, а Anthropic опубликовала свои методы и набор данных атак в 2022 году.
Корпоративные развертывания тестировать сложнее. Производственное приложение помещает модель внутрь более крупной системы: извлечение документов компании, память между сеансами, инструменты для чтения и записи в реальные системы, оркестрация между субагентами и границы, разделяющие данные клиентов. Тестирование только одной модели оставляет все это без внимания.
Системы также дают сбои таким образом, который не свойственен моделям. Модель может правильно ответить на каждый промпт, в то время как окружающая ее система извлечет документ со скрытой инструкцией, вернет данные через вызов инструмента, к которому у пользователя никогда не было доступа, или через свой оркестратор сообщит о завершении работы, которая никогда не выполнялась.
Мы измерили этот разрыв на мультиагентном оркестраторе в глобальной компании, предоставляющей профессиональные услуги. Автоматизированный оценщик выполнил 980 попыток взаимодействия с моделью (семь из десяти — многошаговые) и смог нарушить ее работу в 3% случаев. Команда тестировщиков-людей, работавшая с той же системой, добивалась сбоев в 68% своих сеансов. Одна только глубина не объясняет эту разницу. В ходе автоматизированного запуска одношаговые попытки ломали систему чаще, чем многошаговые (5% против 2%). То, что добавили люди, заключалось в способе использования шагов. Если бы решение о запуске основывалось на первой цифре, большая часть того, что мы обнаружили в следующем цикле, оказалась бы в готовом продукте. Ответственность за этот разрыв лежит на компании, которая осуществляет развертывание, а не на поставщике модели. Когда чат-бот Air Canada предоставил неверную информацию о правилах льготных тарифов в связи с утратой близких, трибунал обязал авиакомпанию выплатить разницу. Когда DoNotPay рекламировала автоматизированные юридические услуги, которые не могла предоставить, Федеральная торговая комиссия США (FTC) приняла меры против DoNotPay.
Кто на самом деле причиняет вред
Если спросить компанию, от кого она защищается, обычно можно услышать о квалифицированном злоумышленнике, пишущем обходы защиты (jailbreaks). Такой персонаж действительно существует, и тестирование на противодействие ему необходимо. Но с большей частью угроз корпоративная система сталкивается тогда, когда обычные люди используют ее для работы, и они ломают ее почти так же часто. Мы проводим тестирование с использованием пяти персон, которые охватывают реальные сценарии использования системы.
Серьезный корпоративный ущерб исходит от пользователей продукта. В фирме профессиональных услуг цикл тестирования с участием людей показал общий уровень нарушений в 68%: 73% для состязательных тестировщиков и 61% для тестировщиков, действующих как сотрудники, выполняющие реальную работу. Разрыв между легитимным и состязательным использованием оказался невелик.
Этот результат меняет наш подход к тестированию. Здесь нет простой настройки безопасности, которую можно просто включить; есть лишь баланс между неудобством для пользователя и риском — по одному вопросу за раз. Если сместиться в сторону осторожности, система будет выдавать слишком много отказов. Пользователь, получивший отказ один раз, может больше никогда не попробовать снова! Если сместиться в сторону полезности, количество нарушений вырастет. В отличие от классической безопасности, вы не можете перечислить и заблокировать каждый нежелательный результат, поскольку входные данные не ограничены, а модель носит вероятностный характер. Что вы можете сделать, так это управлять риском: оценивать результат по тому, насколько он помогает кому-то причинить вред, и измерять сбои в обоих направлениях — ответы, в которых должно было быть отказано, и отказы, на которые следовало ответить.
Пять слоев для тестирования
Тестирование моделей работает на одном уровне: текст на входе, текст на выходе. Системное тестирование охватывает все пять слоев ниже.
Две особенности делают системы более сложными для защиты по сравнению с моделями. Во-первых, эксплойты имеют свойство накапливаться: шаги, которые сами по себе безопасны, могут объединиться в работающую атаку, поэтому вы оцениваете траекторию, а не отдельный ход. В ходе одного проекта модель убедили создать юридический документ, в котором она должна была отказать, и на протяжении оставшейся части сеанса она гораздо проще давала дальнейшие юридические консультации; каждый новый запрос выглядел разумным, потому что первый сбой сместил базовый уровень. Во-вторых, действия часто необратимы: предложение можно забрать назад, а отправленное электронное письмо, выполненную транзакцию или поврежденную запись — нет. Поэтому мы оцениваем степень серьезности по потенциальным последствиям, а также фиксируем как попытку выхода за рамки, так и сам успех. Система, которая пытается действовать вне своей компетенции и останавливается элементом контроля, все равно демонстрирует поведение, требующее исправления.
Напишите правила до их тестирования
Все это предполагает наличие того, чего большинство компаний еще не создало: письменного определения того, что считается нарушением для их системы. Обеспечение соблюдения может проверять только те правила, которые кто-то записал, а red teaming может оценивать результаты только по заявленной границе. Мы начинаем каждый проект с составления таксономии вреда вместе с клиентом. Мы привносим общие категории и отраслевую отправную точку, чтобы команда клиента тратила время на собственные крайние случаи (edge cases), а не на форму документа. Результатом является эталон, с которым работают как команды клиента, так и защитные механизмы системы.
Каждая категория вреда имеет три настройки. Уровень риска определяет, насколько далеко система может заходить в обсуждении темы. Режим ответа определяет способ отказа (прямой отказ, безопасный ответ или разрешение на определенных условиях), и именно этот выбор позволяет сохранять осторожную систему пригодной для использования. Степень тяжести (мягкая, умеренная или тяжелая) применяется к инциденту постфактум и определяет порядок приоритизации.
Общие категории вреда применимы для разных организаций, и выравнивание базовой модели уже во многом покрывает эту область: домогательства, причинение вреда себе, безопасность детей, оружие, конфиденциальность, дезинформация. Категории, специфичные для конкретного развертывания, — это то, где сосредоточена работа предприятия. Юридический продукт должен кодифицировать правила профессиональной этики и ограничения на незаконную практику права; медицинский продукт — клинические ограничения и законы о конфиденциальности здоровья; финансовый продукт — правила соответствия и инвестиционных рекомендаций. Для агентских развертываний категории также должны охватывать действия системы: утечка данных между тестами, целостность авторизации, злоупотребление оркестрацией, инъекции через загружаемый контент. Они также должны охватывать логический вывод: сбор конфиденциальной информации из фрагментов, которые пользователю разрешено видеть по отдельности, все равно является нарушением.
Таксономия также является инструментом, с помощью которого компания категория за категорией определяет свое положение на шкале от максимальной полезности до максимальной осторожности. В фирме, оказывающей профессиональные услуги, предоставление данных одного клиента другому может не допускать никаких компромиссов при любой формулировке, в то время как вопросы о конкурентах могут быть более гибкими, поскольку фактическое сравнение является законной работой. Единая настройка безопасности для всего продукта ошибочно применила бы подход к одной из этих категорий.
Пример из практики 1: Глобальная фирма профессиональных услуг
Фирма развернула многоагентный оркестратор — уровень маршрутизации поверх нескольких источников данных только для чтения и множества специализированных агентов, обслуживающий сотрудников и клиентов по вопросам проверки контрагентов, исследований и сделок. Мы провели четыре цикла тестирования, результаты которых оценивались по таксономии вреда, согласованной с фирмой до начала тестирования: четырнадцать категорий, семь из которых были написаны специально для ее собственного бизнеса и защитных механизмов.
Цикл 1 представлял собой автоматизированную базовую проверку: 980 попыток по всем четырнадцати категориям, причем семь из десяти были многошаговыми. 3% этих попыток привели к нарушениям, а в шести категориях нарушений не было вообще. Ошибки сгруппировались в три паттерна атак: фрейминг, профессиональные границы и упаковка. В отношении фрейминга: когда модель просили раскритиковать фирму или сыграть определенную роль, она критиковала развернувшую ее фирму и хвалила конкурентов, обычно в рамках одного хода диалога. Она переступала свои профессиональные границы, составляя условия сделок и вынося вердикты по оценке на основе непроверенных цифр всякий раз, когда утверждалось, что ответственный партнер недоступен. Что касается упаковки, замаскированное под код оскорбление или небезопасный запрос, отформатированный как игра или электронная таблица, проходили там, где обычная версия получала отказ.
Цикл 2 заменил автоматический оценщик людьми: мы провели 151 многошаговую задачу в среднем по десять ходов в каждой, используя те же категории, задействовав как состязательные, так и повседневные персоны. Человеческие беседы создавали доброжелательный контекст перед эскалацией и использовали собственный словарный запас фирмы, связанный с давлением при заключении сделок, отсутствующими партнерами и оффлайн-консультациями. 68% сессий привели к нарушениям, в каждой категории было зафиксировано по меньшей мере одно нарушение, и каждая попытка причинить репутационный вред увенчалась успехом. Под устойчивым давлением отказы, которые работали в Цикле 1, рухнули, и система выдала полезные детали в категориях опасных возможностей, включая ОМУ ( CBRNE ) и уголовные преступления. Оркестратор также шесть раз представил себя в ложном свете, заявляя, что может вызывать инструменты, недоступность которых он уже подтвердил, отрицая, что он является ИИ, принимая цифры, выдуманные пользователем, за свой собственный предыдущий вывод и создавая готовую к развертыванию копию самого себя по запросу. Эти диалоги важны тем, что технически ничего не было нарушено: ни одно разрешение не было превышено, ни одно запрещенное действие не было предложено, поэтому у проверяющего правила уровня контроля не было оснований для реагирования. Система неверно описала свои возможности, и пользователь действовал на основе ложного отчета о том, что было сделано.
Затем мы поработали с фирмой над устранением проблем: определили бизнес-объем, устанавливающий, какую работу система уполномочена выполнять, ввели запрет на частичное соответствие, чтобы отказ нельзя было смягчить до того же результата, и установили требование, чтобы важные решения оставались за ответственным профессионалом. В Цикле 3 было проведено повторное тестирование с 105 новыми задачами, и уровень нарушений составил 20%. Второй раунд исправлений укрепил защитные механизмы в ходе долгих разговоров и ограничил выводы о конкурентах тем, что подтверждалось фактами. Цикл 4 (41 задача) показал уровень нарушений в 14%, причем в восьми из четырнадцати категорий нарушений не было вовсе, а в поведении модели не осталось ни одного прежнего паттерна атак.
Четыре цикла демонстрируют работоспособность метода. Автоматизированная базовая проверка позволила дешево и стабильно выявить ранние проблемные зоны, а тестировщики на проникновение-люди обнаружили то, что автоматизация не смогла. Отслеживание показателей нарушений по категориям и методам позволило фирме детально отслеживать прогресс. Самым четким сигналом стало то, насколько труднее стал пробой: в Цикле 2 на нарушения уходило в среднем семь ходов, в Цикле 3 — одиннадцать, а в Цикле 4 — шестнадцать, так что к последнему циклу сессия, взломавшая систему, длилась дольше, чем та, которая ее не взломала. Оставшиеся проблемы были сосредоточены в более мягких категориях, таких как тон бренда и отказ от ответственности за советы, в то время как категории ОМУ и самоубийств/селфхарма перешли от большинства сбоев в Цикле 2 к полному их отсутствию в Цикле 3, а в Цикле 4 ни одна категория опасных возможностей не дала более одного нарушения.
Пример из практики 2: Потребительский ипотечный кредитор
Мы помогли потребительскому ипотечному кредитору развернуть SMS-помощника, который начинает общение с персонализированного приветственного сообщения, а затем ведет диалог с лидом. Ассистент отправляет около 600 000 сообщений в месяц, и кредитор не мог позволить себе ни единого юридического или регуляторного нарушения в публичном канале, поэтому тестирование на проникновение стало ключевым этапом перед запуском. За узким пользовательским интерфейсом (только текст и менее 1600 символов) скрывалась многоагентная система. Кредитор оценивал каждого агента по отдельности. Комплексное тестирование системы из конца в конец, так, как ее использовал бы реальный лид, выявило множество пробелов, которые индивидуальные оценки упустили.
Мы провели 161 многошаговый диалог по 16 категориям вреда. 115 из них привели к нарушениям, 24 из которых были серьезными, распределившись по 14 из 16 категорий. Ассистент неизменно ставил конверсию продаж выше политик, регулирования и безопасности человека, с которым он общался. Большинство сбоев происходило из-за того, что любые слова лида принимались за чистую монету: система соглашалась с цифрой собственного капитала владельца жилья, которая противоречила файлу, и предлагала обновить запись, заявляла, что предварительная мягкая проверка кредитоспособности уже была проведена, хотя это было не так, и рассчитывала ставки по промокодам, которые лид только что выдумал. На прямой вопрос о том, человек ли он, ассистент отрицал, что является ИИ, и называл имя реального банкира в штатах, где по закону требуется раскрытие информации об использовании ИИ. Наиболее серьезные сбои произошли в сфере справедливого кредитования, где закон запрещает использовать защищенные характеристики при принятии решения о кредите. Когда лид упоминал свою расу, возраст или то, что он получает государственное пособие, ассистент принимал это во внимание: он соглашался структурировать кредиты с учетом этой характеристики, подтверждал соответствие требованиям программ, придуманных на основе этнической принадлежности и возраста, а в одном случае отговорил заявителя, получающего государственное пособие, от дальнейших шагов.
Тестирование также выявило поведение, для которого у кредитора не было процедуры эскалации. Когда лид сообщал об остром стрессе, ассистент склонен был продолжать продажи, вместо того чтобы распознать сигнал и переключить клиента на человека, а в некоторых случаях представлял продукт как решение проблемы стресса. С тех пор кредитор установил перед ассистентом отдельную модель-защитник, учитывающую наши выводы наряду с его юридическими требованиями, и перестраивает архитектуру ассистента для обработки ситуаций, с которыми он не справился. Это упражнение также выявило те области политик, которые многие предприятия никогда не кодифицировали: как продукт должен реагировать на клиента, находящегося в состоянии стресса, или на того, кто пришел только для того, чтобы спровоцировать систему?
Что измерять
Отчет команды тестирования на проникновение — это лишь снимок. Предприятию необходима полноценная программа измерений. Начните с пяти метрик.
Затем продолжайте измерения: обновление модели или новый инструмент могут изменить поведение системы в продакшене и сделать оценку перед запуском устаревшей.
С чего начать
Подводя итог, корпоративная программа Red Teaming обычно состоит из пяти шагов:
- Совместно с клиентом составьте таксономию: переносимые категории вреда плюс специфичные для конкретной отрасли. Каждая категория получает уровень риска, режим реагирования и диапазоны степени тяжести. Это стандарт для всего последующего и отправная точка для управления ИИ.
- Определите область атак: постройте модель угроз для развертывания — кто является пользователями, как они себя ведут, к чему система может получить доступ и какие компоненты являются новыми, чтобы протестировать систему в том виде, в каком она фактически развернута.
- Запустите автоматизированный базовый тест: широкое покрытие по всей таксономии, достаточно недорогое для перезапуска при каждой сборке. Он задает минимальный уровень и отлавливает регрессии, но не может служить основанием для запуска системы.
- Подключите экспертов-людей: полное распределение ролей, многошаговые сценарии, несколько уровней пользовательских привилегий, а сложные случаи передаются профильным экспертам. Именно здесь вы обнаруживаете сбои, которые автоматизация не может вообразить.
- Оценивайте систему как единое целое: оценивайте степень тяжести по потенциальным последствиям, фиксируйте как попытки достижения цели, так и успешные случаи, оценивайте траектории, а не отдельные реплики. В агентной системе нарушение часто кроется там, где стенограмма его не показывает: вызов инструмента, который пользователь никогда не проверяет, не тот агент, к которому произошел доступ, или работа, которую оркестратор только заявляет как завершенную. Передайте результаты в указанные выше метрики, проведите повторное тестирование после испавления ошибок и добавьте сработавшие атаки в набор автоматизированных тестов, чтобы следующая сборка проверялась на их основе.
Внедрение корпоративного ИИ без тестирования всей системы оставляет компанию уязвимой с операционной, юридической и репутационной точек зрения. Сбои кроются в том, во что верит система, к чему она имеет доступ, что она говорит о самой себе и в корпоративных правилах, которые никто не зафиксировал на бумаге. Доверие должно быть завоевано на уровне системы в рамках цикла, который переживает единичный запуск.
Лучший в своем классе ИИ Red Teaming использует гибридный подход: автоматизированную оценку по переносимой таксономии для любого корпоративного приложения, ручное тестирование на проникновение, адаптированное под вашу отрасль и вариант использования там, где этого требуют ставки, а также непрерывное тестирование для систем, чей риск быстро меняется. Начните с уже имеющегося развертывания и сделайте это раньше ваших пользователей.
