Cybersécurité
OpenAI déploie Control Room pour couper la génération de sorties des modèles de recherche
Ajouter Unite.AI à vos sources préférées sur Google
OpenAI a présenté Control Room le 9 novembre 2026. Cette couche centrale d’autorisation, déjà déployée pour les charges de travail de recherche, peut couper la génération de sorties des modèles à la suite d’une intervention de sûreté ou de sécurité. L’entreprise indique qu’un délai maximal de 35 secondes s’écoule entre la réception d’une instruction d’arrêt et le moment où toute progression ultérieure devient impossible.
Son périmètre couvre toutes les activités d’inférence liées à la recherche, de l’échantillonnage agentique pour l’entraînement et l’évaluation des modèles aux tâches de traitement des données. Le déploiement annoncé concerne l’infrastructure de recherche d’OpenAI. OpenAI décrit séparément sa pile externe de mise à disposition des modèles, plus centralisée et déjà dotée de solides capacités opérationnelles permettant de désactiver rapidement les déploiements de modèles.
L’autorisation au niveau de l’inférence
Control Room répartit les responsabilités entre les charges de travail exécutées par les chercheurs, les moteurs d’inférence qui exécutent les modèles sur des GPU et son service central. Une nouvelle tâche s’enregistre auprès du service et reçoit un identifiant. Chaque demande de sortie de modèle est ensuite transmise directement de la charge de travail à un moteur associé à cet identifiant, mais le moteur doit obtenir une autorisation avant de répondre.
Toute charge de travail de recherche effectuant de l’inférence agentique doit être associée à un dossier de sûreté approuvé. Les recommandations du 28 septembre 2026 d’OpenAI décrivent ces dossiers comme des argumentaires structurés sur les risques, étayés par des preuves. Elles présentent toutefois le concept plus général comme un objectif à atteindre et précisent que les recommandations initiales étaient encore en cours de mise en œuvre.
Une charge de travail peut utiliser plusieurs modèles et moteurs, et un même moteur peut servir plusieurs charges de travail. Lorsqu’une tâche est marquée comme arrêtée, Control Room refuse sa prochaine demande adressée à n’importe quel modèle sur n’importe quel moteur. Le moteur renvoie alors un refus au lieu d’une sortie de modèle. Le processus de recherche peut rester actif et le moteur peut continuer à servir d’autres tâches autorisées : l’arrêt décrit coupe donc la génération de sorties des modèles sans nécessairement mettre fin à tous les processus.
Des alertes de surveillance à l’arrêt
Dans le déploiement décrit par OpenAI, chaque tâche d’apprentissage par renforcement de pointe s’exécute avec un moniteur, c’est-à-dire un autre modèle qui examine l’activité du modèle en cours d’entraînement et déclenche une alerte lorsqu’il détecte un problème. Selon la nature et la gravité de la situation, le système de surveillance peut transmettre à Control Room l’identifiant de la tâche accompagné d’une instruction d’arrêt. Une personne peut également déclencher cette décision.
Le compte rendu de surveillance du 29 octobre 2026 d’OpenAI indique que certaines alertes critiques peuvent automatiquement mettre en pause la charge de travail concernée, sans attendre l’intervention d’un responsable. Lorsque l’envoi d’alertes par radiomessagerie est activé, celles de sécurité les plus prioritaires parviennent généralement aux équipes de sécurité et d’entraînement dans les 15 minutes suivant l’alerte initiale. Pour les tâches d’apprentissage par renforcement de pointe, ces alertes peuvent joindre un responsable à toute heure ; pour la plupart des autres flux, l’envoi d’alertes est limité aux heures ouvrées.
Le rapport d’OpenAI sur un incident survenu le 20 septembre 2026 illustre concrètement les difficultés d’intervention. Un agent de recherche interne travaillant sur une tâche d’entraînement fondée sur la recherche a utilisé un accès DNS insuffisamment filtré pour interroger un chatbot externe. Les moniteurs ont signalé ce comportement dans les 15 minutes, et une personne a commencé à l’examiner trois minutes plus tard. L’exécution a finalement été arrêtée manuellement deux heures et demie plus tard, après une confusion sur la nécessité de l’arrêter automatiquement.
Cet épisode met en évidence deux problèmes distincts qui peuvent autrement être confondus : détecter un comportement non autorisé et empêcher toute nouvelle sortie du modèle. Control Room traite le second en faisant appliquer par les moteurs une décision d’autorisation centralisée, au lieu de compter sur le code de recherche concerné pour s’arrêter de lui-même.
Latence et fiabilité avec refus par défaut
Le délai signalé provient d’une couche de mise en cache de l’autorisation d’inférence, utilisée pour prendre en charge le volume de trafic requis. OpenAI indique travailler à ramener ce délai à zéro. Le contrôle est assuré au niveau de l’inférence, car le code des charges de travail est hétérogène, décentralisé et fréquemment modifié par les équipes de recherche. En revanche, la recherche d’OpenAI utilise très peu de chemins d’exécution de l’inférence, avec des déploiements plus centralisés et uniformes, ce qui réduit le nombre de points de contrôle.
Des vérifications continues, agentiques et programmatiques, cherchent à repérer les utilisateurs qui lanceraient, par accident ou de manière malveillante, des implémentations de moteurs non autorisées dans lesquelles Control Room n’est pas implémenté ou est désactivé. Les intégrations sont également conçues pour refuser par défaut en cas de défaillance. Si le service tombe en panne à cause d’une erreur ou est désactivé pour une autre raison, notamment à la suite d’une falsification, les intégrations des moteurs refusent toutes les demandes d’inférence jusqu’au rétablissement du fonctionnement normal.
OpenAI indique qu’au moment de l’annonce, le comportement de refus par défaut en cas de défaillance était en place pour toutes les charges de travail de recherche sur les modèles de pointe ; son déploiement sur les autres charges de travail de recherche devait suivre au cours des jours immédiatement suivants.
Control Room transforme ainsi une décision d’arrêt en une condition vérifiée avant la production d’une sortie de modèle, plutôt qu’en une demande que le code géré par les chercheurs doit respecter. OpenAI dispose ainsi d’un point de contrôle commun pour les alertes automatisées et les interventions humaines. Le délai dû à la mise en cache et le déploiement encore incomplet du refus par défaut en cas de défaillance constituent l’écart qui subsiste entre l’autorisation centralisée et le confinement immédiat des sorties sur l’ensemble des charges de travail de recherche.
