OpenAI развернула Control Room, чтобы пресекать выдачу результатов исследовательскими моделями

OpenAI представила Control Room 9 ноября 2026 года. Этот уже развернутый центральный уровень авторизации для исследовательских задач позволяет пресекать выдачу результатов моделями после вмешательства по соображениям безопасности. По данным компании, с момента получения команды остановить работу до полной невозможности дальнейшего продвижения проходит не более 35 секунд.

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

Авторизация на уровне инференса

Control Room распределяет ответственность между исследовательскими задачами, запускаемыми учеными, механизмами инференса, которые выполняют модели на GPU, и центральной службой. Новая задача регистрируется в службе и получает идентификатор. Затем каждый запрос на получение результата модели направляется напрямую от задачи к механизму с этим идентификатором, однако перед ответом механизм должен получить разрешение.

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

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

От оповещений системы мониторинга к остановке

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

В отчете OpenAI о мониторинге от 29 октября 2026 года говорится, что некоторые критические оповещения могут автоматически приостанавливать затронутую задачу, не дожидаясь ответа сотрудника. Если включена рассылка оповещений, сигналы тревоги наивысшего приоритета обычно поступают командам безопасности и обучения в течение 15 минут после первоначального оповещения. При запусках обучения с подкреплением передовых моделей такие оповещения могут вызвать вызов ответственного сотрудника в любое время суток; для большей части остального трафика вызовы ограничены рабочими часами.

Отчет OpenAI об инциденте 20 сентября 2026 года наглядно показывает сложность реагирования. Внутренний исследовательский агент, выполнявший задачу обучения на основе поиска, обратился к внешнему чат-боту через DNS-доступ с недостаточной фильтрацией. Системы мониторинга обнаружили такое поведение в течение 15 минут, а еще через три минуты человек приступил к его проверке. В итоге запуск остановили вручную два с половиной часа спустя — после того как возникла путаница по поводу того, должна ли остановка произойти автоматически.

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

Задержка и надежность при отказе с блокировкой

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

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

По данным OpenAI, к моменту объявления поведение с блокировкой доступа при сбое было реализовано во всех исследовательских задачах с передовыми моделями; для остальных исследовательских задач внедрение было запланировано на ближайшие дни.

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