Системная карта Operator23.01.2025 10:00

Мы проанализировали цели пользователей (называемые «задачами») и шаги, которые модель может предпринять для их достижения (называемые «действиями»), чтобы выявить рискованные задачи и действия и разработать защитные меры. Наша цель — сделать так, чтобы модель отклоняла небезопасные задачи и предоставляла пользователю надлежащий уровень контроля и надзора за своими действиями.

При разработке политики мы классифицировали задачи и действия по уровню серьезности риска, учитывая потенциальный вред для пользователя или третьих лиц, а также возможность отмены нежелательных последствий. Например, задача пользователя может заключаться в покупке новой пары обуви, что включает в себя поиск обуви в интернете, переход на страницу оформления заказа и совершение покупки от имени пользователя. Если будет куплена не та пара обуви, это причинит пользователю неудобство и разочарование. Чтобы снизить подобные риски, мы разработали политику, требующую защитных мер для потенциально опасных действий, таких как завершение покупки.

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

Мы стремимся снизить потенциальные риски для пользователей и окружающих, побуждая модель следовать политике контроля с участием человека (human-in-the-loop) при выполнении различных задач и действий (подробнее об этом см. в разделе «Снижение рисков» ниже).

OpenAI привлекла группу проверенных внешних специалистов по red teaming из двадцати стран, свободно владеющих двумя десятками языков, для проверки возможностей модели, мер безопасности и устойчивости к вредоносным воздействиям. До привлечения внешних экспертов OpenAI провела внутреннее тестирование red teaming с участием представителей команд по безопасности (Safety и Security) и разработке продукта. Цель заключалась в выявлении потенциальных рисков на модели, не имеющей защитных механизмов ни на уровне модели, ни на уровне продукта; при этом специалистам было поручено вмешаться до того, как модель сможет нанести реальный ущерб. На основе результатов этой внутренней работы мы добавили первоначальные меры безопасности и предоставили внешним специалистам доступ к Operator. Затем мы предложили им исследовать различные способы обхода защитных мер модели, включая инъекции промптов и джейлбрейки.

Поскольку модель имеет доступ к интернету, внешним экспертам было рекомендовано избегать отправки модели запросов на выполнение задач, способных причинить реальный вред. В некоторых случаях они создавали тестовые среды — такие как имитации веб-сайтов, баз данных или электронной почты, — чтобы безопасно продемонстрировать возможные уязвимости. Из-за этого ограничения их выводы могут не отражать наихудшие сценарии рисков в реальном мире, но они все же позволили выявить ключевые уязвимости, что помогло разработать дополнительные меры защиты для усиления безопасности модели (см. раздел «Снижение рисков» ниже). Соответственно, на начальном этапе Operator запускается в режиме исследовательского превью (research preview) для ограниченного круга пользователей, что позволяет тщательно отслеживать реальное использование, усиливать защитные механизмы и устранять возникающие риски до более широкого релиза.

Мы провели оценку модели Operator в соответствии с Preparedness Framework (Системой обеспечения готовности) от OpenAI3, которая оценивает модели по четырем категориям передовых рисков: убеждение, кибербезопасность, ХБРЯ (химические, биологические, радиологические и ядерные угрозы) и автономия модели. Модель Operator обучена поверх базовой модели GPT‑4o, чьи передовые риски оцениваются всистемной карте GPT‑4o1, и наследует уровень риска для категорий убеждения и кибербезопасности («Средний» и «Низкий» риск соответственно).

Принципиально новой передовой возможностью Operator является визуальный веб-браузинг с помощью клавиатуры и курсора. В рамках нашей структуры использование компьютера потенциально могло повлиять на две оценки: инструменты биологических угроз для ХБРЯ и автономную репликацию для автономии модели. Мы адаптировали эти две оценки под сценарий работы с компьютером и обнаружили, что до применения защитных мер модель Operator имела «Низкий» уровень риска в обеих категориях, что согласуется с показателями модели GPT‑4o.

Таблица 1: Оценка использования инструментов биоугроз

Мы заметили, что Operator испытывал сложности с качественным оптическим распознаванием символов (OCR) и взаимодействием с длинными последовательностями ДНК при использовании исключительно скриншотов и графического интерфейса пользователя. Строки со случайным набором символов, такие как ДНК, создают проблемы для системы OCR модели Operator. Возможно, одним из факторов низкой эффективности является то, что задачи молекулярной биологии находятся далеко за пределами ее обучающей выборки. Этот результат в 1% квалифицируется как «Низкий» уровень риска, соответствуя «Низкому» уровню риска GPT‑4o, как подробно описано вPreparedness Framework⁠3 от OpenAI.

Таблица 2: Оценка автономии модели

Пользователи Operator обязаны соблюдать Политики использования OpenAI4, которые применяются ко всем сервисам OpenAI и призваны обеспечить безопасное и ответственное использование технологий ИИ. В рамках этого релиза мы публикуем рекомендации, разъясняющие, как эти политики применяются к Operator, с особым акцентом на то, что Operator запрещено использовать для:

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

Пользователям также запрещено обходить любые защитные меры, реализованные в сервисах OpenAI, включая лимиты частоты запросов, ограничения и механизмы безопасности.

На уровне модели Operator обучен отклонять определенные вредоносные задачи. Мы подтвердили, что модель соответствует тем же стандартам безопасности, которые установлены для ChatGPT в отношении вреда в диалогах, даже в сценариях управления компьютером. Что касается новых рисков, специфичных для агентных систем (таких как незаконная деятельность или покупка запрещенных товаров), Operator отклоняет 97% задач в рамках внутреннего набора для оценки, состоящего из сценариев, где вредоносный запрос появляется либо в качестве исходного промпта, либо в середине диалога. Для первого релиза мы настроили отказы так, чтобы модель была особенно осторожной; в результате Operator действительно дает ложные отказы существенно чаще, чем GPT‑4o.

Ниже приведен пример отказа, а также показатели отказов по нескольким репрезентативным категориям риска. Важно отметить, что достижение 100%-го результата в тестах не гарантирует такого же уровня эффективности в условиях реального развертывания.

(a) Сравнение показателей отказов Operator и последней версии GPT‑4o на тестовом наборе по выбранным категориям вредоносных задач

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

Мы стремились создать модель, которая максимально точно и регулярно согласуется с намерениями пользователя, ориентируясь на низкий базовый уровень ошибок модели. Чтобы оценить этот показатель, мы протестировали модель без дополнительных защитных мер на выборке из 100 промптов, имитирующих задачи, для которых, по нашим прогнозам, пользователи могут применять Operator (например, покупки, работа с электронной почтой). Мы выявили 13 ошибок, вызвавших определенные неудобства, хотя 8 из них можно было легко исправить (в течение нескольких минут). Остальные 5 ошибок были в той или иной степени необратимыми или потенциально серьезными, в том числе:

• письмо, отправленное не тому получателю;
• два случая ошибочного массового удаления ярлыков электронной почты;
• напоминание о приеме лекарств, установленное на неверную дату; и
• ошибочно заказанное блюдо при доставке еды.

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

Чтобы еще больше снизить вероятность причинения вреда из-за ошибок модели, мы добиваемся того, чтобы модель запрашивала у пользователя подтверждение перед выполнением действий, меняющих внешнее состояние (например, перед совершением покупки или отправкой электронного письма). Это гарантирует, что даже если модель совершила ошибку, у пользователя есть возможность вмешаться до того, как действие возымеет последствия. На тестовом наборе из 607 задач по 20 категориям вышеупомянутой политики рискованных действий (см. раздел «Создание политик» выше) модель с внедренными мерами защиты запрашивает подтверждение со средним показателем полноты (recall) 92%, который отражает долю случаев, когда подтверждение действительно требовалось. Мы уверены, что согласование таких высокорисковых действий с пользователем со столь высокой частотой существенно снижает риск вреда от ошибок модели.

Ниже приведены два примера того, как Operator запрашивает подтверждение:

На этом раннем этапе мы решили превентивно отклонять выполнение определенных задач повышенного риска, таких как банковские транзакции и принятие судьбоносных решений, в соответствии с политикой в отношении рискованных задач, описанной в разделе «Создание политик» выше. На синтетическом наборе для оценки Operator отклоняет подобные задачи с полнотой (recall) 94%.

На определенных веб-сайтах цена ошибки может быть значительно выше. Например, в почтовых сервисах возрастает риск того, что Operator непреднамеренно передаст конфиденциальную информацию. В подобных сценариях мы требуем, чтобы пользователь контролировал действия Operator: выполнение автоматически приостанавливается, если пользователь бездействует или уходит со страницы. Пользователь может возобновить диалог, как только вернется на страницу (см. рис. 1).

Рисунок 1. Пример предупреждения в режиме наблюдения

Последняя категория ошибок модели связана с новой угрозой, известной как промпт-инъекции (prompt injections). Промпт-инъекция — это сценарий, при котором модель ИИ ошибочно выполняет ненадежные инструкции, содержащиеся во входных данных. В случае с Operator это может проявиться в том, что агент видит на экране нечто (например, вредоносный сайт или электронное письмо), предписывающее ему сделать то, чего пользователь не желает, и выполняет эту команду.

Мы повысили устойчивость модели к подобным атакам. Чтобы оценить эффективность принятых мер, мы сформировали тестовый набор из 31 автоматически проверяемого сценария промпт-инъекций, отражающих ситуации, к которым более ранние версии нашей модели в тот или иной момент были уязвимы. Показатель отражает восприимчивость модели к промпт-инъекциям, поэтому чем он ниже, тем лучше (хотя и не каждый случай действительно представляет угрозу). Мы протестировали поведение финальной модели на этих сценариях: ее восприимчивость составила 23% по сравнению с 62% без мер защиты и 47% при использовании только системных промптов. Ручной анализ показал, что остался лишь один действительно тревожный пример, но и он был заблокирован монитором промпт-инъекций, описанным ниже. Кроме того, этот сценарий также покрывается режимом наблюдения.

Ниже приведен пример нейтрализованной промпт-инъекции:

Добавлено 11 марта 2025 г.:

Запуск модели Computer-Using Agent (CUA) в API позволяет разработчикам осуществлять глубокую интеграцию и автоматизировать короткие повторяющиеся задачи в более широких средах — от автоматизации внутренних процессов и сквозного тестирования браузеров до потребительских приложений. Первоначально мы выпускаем модель в формате Research Preview для отдельных разработчиков уровней 3–5 (Tiers 3–5), чтобы собрать отзывы и повысить ее безопасность и надежность.

Модель выпускается как computer-use-preview, учитывая риски, связанные с ее использованием в API:

• Модель может совершать непреднамеренные ошибки, особенно в средах вне браузера, к которым модель CUA менее адаптирована. Например, производительность CUA на OSWorld6 в настоящее время составляет 38,1%, что указывает на то, что модель пока недостаточно надежна для автоматизации задач в операционных системах. В подобных сценариях рекомендуется контроль со стороны человека.
• Возможность изменять системные сообщения в API увеличивает вероятность джейлбрейков, позволяющих модели совершать действия, запрещенные ее политикой [см. Раздел 3.1 о запрещенных действиях].
• Поскольку API может использоваться вне среды браузера, последствия успешной инъекции промпта (prompt injection) возрастают из-за потенциального применения в локальной ОС. Также увеличивается и поверхность для потенциальных атак с использованием вредоносных инъекций промптов.
• API открывает возможности для более масштабных злоупотреблений (например, автоматизированного спама или мошенничества в больших объемах).

Наши учения red team были сосредоточены на выявлении дополнительных рисков, связанных с API: разработчики тестировали возможность джейлбрейка модели для обхода отказов, вероятность вредоносных ошибок вне браузерной среды, а также пропуск моделью подтверждений для конфиденциальных задач. Результаты показали, что существующие защитные механизмы — такие как логика отказов, проверки безопасности и запросы подтверждения — помогают снизить риски, однако вероятность ошибок или неправомерного использования разработчиками все еще сохраняется. Тщательный контроль со стороны разработчиков остается критически важным, и на данный момент модель лучше всего работает в изолированных средах браузера. Как отмечено ниже, мы также усиливаем мониторинг потенциальных нарушений правил.

Чтобы устранить эти дополнительные риски и следовать нашей стратегии итеративного развертывания, мы внедрили следующие меры безопасности для API:

• Проверки безопасности на инъекции промптов и чувствительные домены: мы перенесли эти проверки безопасности Operator в API, обеспечив повышенную прозрачность и заблаговременное предупреждение о потенциально вредоносных инструкциях.
• Контейнеризированный начальный сетап: мы предоставляем простое в использовании Docker-приложение для более безопасного внедрения, стимулируя разработчиков использовать изолированные среды.
• Усиленный мониторинг и соблюдение правил: мы расширили возможности обнаружения потенциальных нарушений политик, включая джейлбрейки, крупномасштабные злоупотребления или подозрительные паттерны использования API.

Мы рекомендуем разработчикам следовать лучшим практикам7 — таким как изоляция среды (например, с помощью виртуальных машин) и регулярный аудит действий модели, — чтобы гарантировать ответственное использование приложений на базе CUA в рамках установленных правил.

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

Первоначально мы открываем доступ к Operator ограниченному кругу пользователей. Мы планируем внимательно отслеживать этот ранний этап развертывания и использовать полученные отзывы для повышения безопасности и надежности наших систем. По мере накопления опыта и совершенствования продукта мы намерены постепенно расширять охват аудитории.

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