OpenAI scrive il regolamento prima dei regolatori, e nessuno la ferma (per ora)

OpenAI ha pubblicato il Frontier Governance Framework, il documento che descrive come l’azienda intende rispondere alle nuove leggi sull’AI di frontiera. Il testo arriva in coincidenza con due scadenze regolatorie: il Code of Practice for General Purpose AI dell’AI Act europeo e il Transparency in Frontier AI Act della California, firmato in autunno e operativo da inizio anno. Il framework copre quattro aree di rischio (cyber offence, CBRN, manipolazione, perdita di controllo) e descrive la pipeline di valutazione interna che l’azienda applica ai propri modelli prima del rilascio.

Il framework è operazione di posizionamento regolatorio, non gesto di trasparenza spontanea. Pubblicare il proprio framework prima che i regolatori chiudano le proprie linee guida significa scrivere lo standard di fatto a cui i futuri obblighi normativi finiranno per allinearsi. È il manuale di un’industria che ha imparato a giocare d’anticipo sui propri regolatori, e che da almeno due anni ha capito di poter scegliere quale forma daranno gli obblighi che la riguardano.

Il Frontier Governance Framework deriva dal precedente Preparedness Framework, che resta il documento operativo interno. La novità è che la parte pubblica viene ora confezionata come oggetto di compliance: classifica delle capability, soglie di rischio, procedure di red teaming, deployment policy, model reporting. Il linguaggio tecnico copia la struttura dei requisiti AI Act, in particolare per i modelli di General Purpose AI con rischio sistemico.

Anthropic, Google DeepMind e il club dei frontier framework

OpenAI non è la prima a muoversi. Anthropic ha pubblicato la versione 3 della Responsible Scaling Policy a febbraio, con quattro capability thresholds e safety standard ASL-2/ASL-3 che modulano i requisiti tecnici di security in funzione del livello di rischio del modello. Google DeepMind aggiorna periodicamente il proprio Frontier Safety Framework, arrivato alla versione 3.0 nel terzo trimestre del 2025. I tre framework convergono per struttura: definizione di soglie di capability, valutazioni periodiche, soglie di rischio, mitigazioni progressive.

La convergenza non è casuale. METR, l’organizzazione che traccia i Frontier AI Safety Policies, riporta nel suo portfolio comparativo che le tre big AI hanno standardizzato il vocabolario su capability thresholds, evaluations, deployment standards. Tom’s Hardware ha già descritto come Anthropic, nello stesso mese in cui rifiutava un contratto da 200 milioni con il Pentagono per non rimuovere i limiti etici, abbia attenuato il safety veto che la distingueva dal resto del settore.

La traiettoria è chiara. I tre vendor allineano il proprio linguaggio di rischio in modo da poter dire al regolatore: la nostra struttura è già lo standard. Il regolatore eredita la tassonomia, il vendor eredita la legittimità della propria politica interna. GovAI nel suo commento alla RSP v3 ha registrato lo spostamento di responsabilità: i framework volontari diventano materia di negoziazione regolatoria.

La doppia compliance arriva al C-Suite enterprise

Per il responsabile IT che ha già acquistato licenze enterprise di GPT o di Claude, il framework non è un documento accademico. È il presupposto della propria audit trail. L’azienda che compra modelli di frontiera deve dimostrare al proprio Data Protection Officer, al proprio compliance manager, all’eventuale auditor esterno, quale classificazione di rischio applica il vendor ai sistemi che sta integrando in produzione. Senza quel pezzo di documentazione, la posizione di rischio rimane indeterminata.

In Italia il quadro si complica. La Legge 132/2025 sull’intelligenza artificiale è in vigore da ottobre, con sanzioni fino a 35 milioni di euro per le violazioni più serie. Le aziende che adottano modelli di frontiera devono rispondere insieme all’AI Act europeo e alla normativa nazionale. Tom’s Hardware ha descritto la doppia compliance che inchioda le imprese davanti a due livelli regolatori che si sovrappongono parzialmente. Il framework OpenAI copre alcune zone della mappa e ne lascia altre scoperte, e la zona scoperta resta a carico del cliente enterprise.

Chi acquista deve sapere chi classifica il rischio del modello, con quali metriche, su quali capability. Il framework risponde alla prima domanda solo per la parte di rischio sistemico sui modelli di General Purpose AI. Per il rischio specifico dell’applicazione enterprise (dati di training del cliente, integrazione con sistemi proprietari, agenti che scrivono in database aziendali) la zona grigia resta, e va negoziata in contratto.

Capability thresholds e il problema della verifica indipendente

Le capability thresholds descritte nel framework sono soglie autoriferite. Significa che OpenAI valuta da sola se un proprio modello ha raggiunto livelli di capability che richiedono mitigazioni aggiuntive. Il documento prevede red teaming interno ed esterno, pubblicazione di system card, model reporting periodico. Manca, per ora, un auditor terzo indipendente con accesso ai pesi del modello e al protocollo di valutazione.

L’AI Now Institute nelle sue analisi sui frontier policies osserva da tempo che la trasparenza unilaterale non sostituisce il controllo terzo, e che l’autoregolazione delle big AI ha una funzione politica oltre che tecnica. La Code of Practice dell’AI Act spinge verso valutazioni esterne sui modelli a rischio sistemico, ma i criteri di accreditamento degli auditor restano in via di definizione.

Resta il fatto che il Frontier Governance Framework è il documento contrattuale più dettagliato a disposizione delle aziende clienti per istruire la propria due diligence sui modelli OpenAI. Va letto come materiale di compliance da archiviare, non come comunicato di marketing da ignorare. Il responsabile IT che integra GPT in workflow regolati deve allegarlo alla propria documentazione interna, con il riferimento alla versione esatta del framework citata.

Chi paga il regolatore-vendor

La traiettoria che si sta consolidando è quella di una regolazione co-scritta dal regolato. Gli stessi tre vendor che hanno costruito i modelli di frontiera offrono ai regolatori la grammatica con cui descrivere il rischio. Il regolatore arriva tardi, eredita la tassonomia, validandola. Il vendor che ha posto la tassonomia è in posizione di vantaggio competitivo strutturale: il proprio framework è già la baseline da cui partono le verifiche.

Il cliente enterprise paga questa dinamica due volte. Una prima volta sul prezzo del modello, che incorpora i costi crescenti della funzione compliance interna del vendor. Una seconda volta sui costi della propria due diligence, perché la documentazione del vendor copre i rischi di sistema, non quelli applicativi del cliente. Le agenzie di consulenza che già intermediano deployment di GPT enterprise stanno costruendo l’offerta di AI compliance advisory proprio su questo gap.

In fase di rinegoziazione contrattuale la domanda è semplice: quale versione del Frontier Governance Framework si applica al modello acquistato, quali clausole di update e quali clausole di responsabilità in caso di modifica? La risposta è ciò che separa una compliance reale da un esercizio di carta.

L’autoregolazione delle big AI ha la funzione politica di dissuadere governi dal regolare con mano pesante. Funziona quando il regolatore si convince che la materia è troppo tecnica, troppo veloce, troppo complessa. La compliance del cliente enterprise, però, non si dissolve nel buon senso del vendor. Resta scritta nei contratti e nelle audit trail. Chi non la pretende oggi, la pagherà domani quando l’auditor chiede di vedere le carte.

OpenAI ha pubblicato il Frontier Governance Framework il 28 maggio 2026. Il documento è consultabile sul sito dell’azienda e si applica ai modelli di General Purpose AI con rischio sistemico secondo la classificazione AI Act.