OpenAI mette nero su bianco chi può usare l’AI con meno freni

OpenAI ha aggiornato il 24 ottobre la documentazione di Daybreak, il programma che consente a utenti e organizzazioni verificati di usare alcuni modelli con meno rifiuti nelle attività di cybersecurity autorizzate. La novità più interessante non è un nuovo chatbot: è la tabella degli accessi. La stessa famiglia di modelli può offrire capacità diverse a seconda del livello di approvazione assegnato a chi la usa.

Daybreak esiste già da mesi. Con l’ultima documentazione, però, OpenAI rende molto più leggibile la gerarchia tra uso standard, Daybreak Blue e Daybreak Red, indicando quali modelli possono ridurre i rifiuti e quali restano dietro un’ulteriore autorizzazione. In pratica, la domanda non è più soltanto quale modello hai a disposizione, ma con quale identità e con quali permessi puoi usarlo.

Daybreak Blue e Red: la stessa AI non risponde allo stesso modo a tutti

Con l’accesso standard, i modelli generalisti mantengono le normali protezioni. Daybreak Blue, pensato come livello d’ingresso per il lavoro difensivo, riduce i rifiuti su modelli supportati come GPT-5.5, GPT-5.6 Sol, GPT-6 Sol e GPT-6 Luna. OpenAI lo indica per attività come revisione sicura del codice, analisi di malware, incident response, vulnerability triage e verifica delle patch.

Salendo a Daybreak Red, il perimetro cambia. GPT-6.1 Sol e Astra possono operare con rifiuti ridotti soltanto per organizzazioni che hanno ottenuto l’approvazione Red; GPT-5.5-Cyber diventa accessibile con quel livello, mentre GPT-5.6-Cyber richiede anche un’approvazione aggiuntiva specifica per il modello. Il programma continua a imporre policy, controlli e limiti: l’accesso non equivale a una modalità senza regole, né autorizza test su sistemi per i quali l’utente non possiede un permesso esplicito.

La differenza, nelle attività più sensibili, può essere enorme. Quando OpenAI presentò GPT-5.6-Cyber nell’agosto 2026, pubblicò una valutazione interna su richieste avanzate che comprendevano sviluppo di exploit chain, bypass dell’autenticazione e privilege escalation: il modello cyber completava il 95% delle richieste del test, contro l’1,5% di GPT-5.6 Sol standard e il 2% di Sol con Daybreak Blue. È un benchmark aziendale, non una misura universale della capacità offensiva, ma chiarisce perché un livello di accesso possa contare quasi quanto il nome del modello.

Per ottenere meno rifiuti serve prima dimostrare chi sei

La procedura per gli utenti individuali assomiglia poco al normale acquisto di un abbonamento. Per candidarsi a Daybreak Blue servono un piano a pagamento idoneo, la verifica dell’identità, Advanced Account Security e almeno una chiave hardware FIDO2 fisica; OpenAI valuta inoltre identità, affidabilità, rischio, caso d’uso dichiarato e capacità del richiedente di contribuire all’ecosistema della sicurezza. Completare i requisiti tecnici non garantisce l’approvazione.

Daybreak Red è più stretto: la documentazione lo riserva attualmente alle organizzazioni business ed enterprise approvate. Anche dopo il via libera, il proprietario del workspace o del progetto API deve abilitare il programma per gli utenti o i progetti interessati. L’autorizzazione, insomma, ha più cancelli: persona, organizzazione, progetto e modello.

È una versione molto concreta di un tema già visibile nella sicurezza degli agenti AI: quando il software può fare di più, la sicurezza smette di coincidere soltanto con il filtro applicato all’output e si sposta sull’identità di chi chiede l’azione, sui suoi permessi e sul contesto in cui quella capacità viene concessa.

Il nuovo confine non è soltanto tra modelli potenti e modelli deboli

Per anni la corsa all’AI è stata raccontata attraverso benchmark, parametri e finestre di contesto. Daybreak mostra un’altra variabile, meno appariscente: due clienti possono arrivare davanti a modelli della stessa famiglia e trovare porte diverse. Una parte del prodotto diventa il diritto di oltrepassare un certo livello di cautela.

È una trasformazione che OpenAI sta rendendo esplicita proprio nel settore in cui il confine tra uso difensivo e offensivo è più sottile. Un ricercatore può avere bisogno di riprodurre un exploit per verificare una falla; la stessa capacità può essere usata contro un sistema senza autorizzazione. La soluzione scelta sposta una parte della decisione a monte, nella verifica dell’utente e nell’amministrazione degli accessi.

La documentazione API arriva a codificare questa gerarchia in un parametro dedicato. E l’approvazione, da sola, non basta: per ottenere il comportamento meno restrittivo Daybreak deve essere attivato nel workspace o nel progetto autorizzato. Il modello resta importante. Anche la chiave che apre la porta, ormai, fa parte del prodotto.