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