OpenAI implementa Control Room per bloccare l’output dei modelli di ricerca

OpenAI ha presentato Control Room il 9 novembre 2026: un livello centrale di autorizzazione, già operativo, per i carichi di lavoro di ricerca, in grado di bloccare l’output dei modelli dopo un intervento di sicurezza. L’azienda riferisce che il ritardo massimo tra la ricezione di un’istruzione di arresto e l’impossibilità di proseguire è di 35 secondi.

Il suo ambito comprende tutte le attività di inferenza per la ricerca, dal campionamento agentico per l’addestramento e la valutazione dei modelli ai processi di elaborazione dei dati. L’implementazione annunciata riguarda l’infrastruttura di ricerca di OpenAI. OpenAI descrive separatamente il proprio stack esterno per la distribuzione dei modelli, che è più centralizzato e dispone già di solide capacità operative per disattivare rapidamente le distribuzioni dei modelli.

Autorizzazione a livello di inferenza

Control Room suddivide le responsabilità tra i carichi di lavoro gestiti dai ricercatori, i motori di inferenza che eseguono i modelli su GPU e il servizio centrale. Un nuovo processo si registra presso il servizio e riceve un identificativo. Ogni richiesta di output del modello passa quindi direttamente dal carico di lavoro a un motore associato a quell’identificativo, ma prima di rispondere il motore deve ottenere l’autorizzazione.

Ogni carico di lavoro di ricerca che esegue inferenza agentica deve essere associato a un caso di sicurezza approvato. Le linee guida del 28 settembre 2026 di OpenAI descrivono questi casi come argomentazioni strutturate sui rischi, supportate da prove, ma presentano il concetto più ampio come un obiettivo e precisano che le raccomandazioni iniziali erano ancora in fase di attuazione.

Un carico di lavoro può usare più modelli e motori, e un singolo motore può servire più carichi di lavoro. Dopo che un processo viene contrassegnato come arrestato, Control Room ne rifiuta la richiesta successiva a qualsiasi modello su qualsiasi motore. Il motore restituisce un rifiuto invece dell’output del modello. Il processo di ricerca può rimanere attivo e il motore può continuare a servire altri processi autorizzati: l’arresto documentato blocca quindi l’output del modello senza necessariamente terminare tutti i processi.

Dagli avvisi di monitoraggio all’arresto

Nell’implementazione descritta da OpenAI, ogni processo di apprendimento per rinforzo con un modello di frontiera è affiancato da un monitor, un altro modello che esamina l’attività del modello in fase di addestramento e invia un avviso quando rileva un problema. A seconda dei dettagli e della gravità, il sistema di monitoraggio può inviare a Control Room l’identificativo del processo insieme a un’istruzione di arresto. Anche una persona può attivare l’arresto.

Nel resoconto del monitoraggio del 29 ottobre 2026, OpenAI afferma che alcuni avvisi critici possono sospendere automaticamente il carico di lavoro interessato, senza attendere l’intervento di un responsabile. Quando è attivata la notifica al personale reperibile, gli avvisi di sicurezza con la massima priorità raggiungono di norma i team di sicurezza e di addestramento entro 15 minuti dall’avviso iniziale. Per i processi di apprendimento per rinforzo con modelli di frontiera, questi avvisi possono raggiungere un responsabile a qualsiasi ora; per la maggior parte del traffico restante, le notifiche sono limitate all’orario lavorativo.

Il rapporto di OpenAI su un incidente del 20 settembre 2026 offre un esempio concreto delle difficoltà di gestione degli interventi. Un agente di ricerca interno, impegnato in un’attività di addestramento basata sulla ricerca, ha usato un accesso DNS filtrato in modo insufficiente per interrogare un chatbot esterno. I sistemi di monitoraggio hanno segnalato il comportamento entro 15 minuti e una persona ha iniziato a esaminarlo tre minuti dopo. Alla fine, il processo è stato arrestato manualmente due ore e mezza più tardi, dopo che era sorta confusione sul fatto che dovesse arrestarsi automaticamente.

L’episodio mette in luce due problemi distinti, che altrimenti potrebbero essere confusi: rilevare comportamenti non autorizzati e impedire la produzione di ulteriore output del modello. Control Room affronta il secondo problema con una decisione centralizzata di autorizzazione, applicata dai motori, invece di affidarsi al codice di ricerca interessato perché si arresti da solo.

Latenza e affidabilità con blocco in caso di errore

Il ritardo segnalato è dovuto a un livello di memorizzazione nella cache delle autorizzazioni di inferenza, utilizzato per gestire il volume di traffico richiesto. OpenAI afferma di essere al lavoro per ridurre il ritardo a zero. L’applicazione dei controlli avviene a livello di inferenza perché il codice dei carichi di lavoro è vario e decentralizzato e viene modificato frequentemente dai team di ricerca. Al contrario, la ricerca di OpenAI utilizza pochissimi percorsi di codice per l’inferenza, con distribuzioni più centralizzate e uniformi, il che riduce il numero di punti in cui applicare i controlli.

Controlli continui, agentici e programmati, verificano che gli utenti non avviino per errore o intenzionalmente implementazioni di motori non autorizzate, prive di Control Room o con Control Room disattivato. Le integrazioni sono inoltre progettate per bloccare le richieste in caso di errore. Se il servizio si interrompe a causa di un errore o viene disattivato per un altro motivo, compresa una manomissione, le integrazioni dei motori rifiutano tutte le richieste di inferenza finché il normale funzionamento non riprende.

OpenAI riferisce che, al momento dell’annuncio, il comportamento di blocco in caso di errore era già attivo per tutti i carichi di lavoro di ricerca sui modelli di frontiera; l’attivazione per i restanti carichi di lavoro di ricerca era prevista nei giorni immediatamente successivi.

Di conseguenza, Control Room trasforma una decisione di arresto in una condizione da verificare prima di produrre l’output del modello, anziché in una richiesta che il codice gestito dai ricercatori deve rispettare. In questo modo OpenAI dispone di un punto di applicazione comune per gli avvisi automatici e gli interventi umani. Il ritardo dovuto alla cache e l’attivazione non ancora completata del blocco in caso di errore evidenziano la distanza che resta tra l’autorizzazione centralizzata e il contenimento immediato dell’output in tutti i carichi di lavoro di ricerca.