OpenAI aggiorna la Model Spec. Ma chi verifica gli agenti?

Un documento può descrivere perfettamente come dovrebbe comportarsi un agente AI. Può spiegare che deve rispettare l’intenzione dell’utente, evitare danni, essere trasparente e lasciare il controllo alle persone. Tutto corretto. Ma il documento non dimostra che il sistema si comporterà così quando incontra un’istruzione ambigua, un permesso troppo ampio o un’operazione che fallisce a metà.

Il 29 ottobre 2026 OpenAI ha aggiornato la propria Model Spec, organizzandola intorno a cinque valori. Negli stessi giorni ha comunicato modifiche alle quote di utilizzo di Work e Codex per alcuni abbonamenti. Due notizie che sembrano appartenere a reparti diversi: una parla di comportamento, l’altra di consumo. Per chi costruisce sistemi agentici, invece, descrivono due facce dello stesso problema. Un agente deve fare la cosa giusta, ma deve anche poterla completare, interrompere e rendicontare.

Cinque valori non sono cinque test superati

La nuova struttura della Model Spec mette al centro la fedeltà all’intenzione umana, la minimizzazione del danno, l’onestà e la trasparenza, la capacità delle persone di scegliere e agire, e la cura per chi subisce le conseguenze del lavoro svolto. OpenAI ha inoltre chiarito la gestione del contesto, della supervisione, degli effetti collaterali e delle istruzioni in conflitto. Il changelog pubblico permette di distinguere queste modifiche da una semplice operazione di comunicazione.

È un passo interessante perché sposta il discorso dal comando isolato alla situazione in cui il comando viene eseguito. Ma c’è una distinzione fondamentale: una specifica è una descrizione del comportamento atteso, non una certificazione del comportamento osservato. OpenAI stessa precisa che i modelli non riflettono ancora completamente quanto descritto nel documento. Questa frase dovrebbe comparire idealmente sopra qualsiasi dashboard che promette un agente “autonomo”.

Nel software tradizionale nessuno confonderebbe un requisito scritto con un test di integrazione riuscito. Se una funzione deve impedire due addebiti per lo stesso ordine, scrivere la regola non basta. Si prepara un caso riproducibile, si provoca un retry, si controllano database e log. Per gli agenti la situazione non cambia solo perché al posto di una funzione deterministica c’è un modello linguistico.

L’intenzione dell’utente non è una variabile già risolta

Dire a un agente di essere fedele all’intenzione umana sembra semplice finché l’intenzione non va ricostruita. “Sistema gli ordini in sospeso” può significare classificare, correggere dati, inviare email oppure procedere a rimborsi. Un sistema che sceglie autonomamente l’ultima interpretazione non ha dimostrato maggiore intelligenza: ha preso una decisione operativa che forse non gli apparteneva.

Qui il punto tecnico è progettare un confine tra interpretazione e autorizzazione. L’agente può proporre un piano e motivare perché ritiene una certa azione pertinente; il sistema deve però sapere quali azioni sono leggibili, quali sono reversibili, quali richiedono una conferma e quali non devono essere disponibili. La Model Spec può guidare il giudizio del modello, ma i permessi devono esistere anche fuori dal prompt.

In un gestionale, per esempio, distinguerei un’operazione di lettura da una modifica contabile e da un invio a un servizio esterno. Non perché ogni agente sia inaffidabile, ma perché nessun componente applicativo dovrebbe poter trasformare un’interpretazione probabilistica in un effetto irreversibile senza un controllo coerente con il rischio.

Gli effetti collaterali sono il vero banco di prova

La revisione della Model Spec dà maggiore spazio al controllo e alla comunicazione degli effetti collaterali. Tradotto in architettura: prima di una scrittura serve conoscere l’oggetto interessato, la portata dell’operazione e il modo in cui si verifica l’esito. Dopo la scrittura serve poter distinguere un successo reale da un messaggio rassicurante generato dal modello.

Immaginiamo un agente incaricato di pubblicare un articolo. La chiamata remota riesce, ma la risposta si perde. Al retry il modello potrebbe creare un secondo articolo, perché non sa che il primo esiste già. Una frase nella specifica che invita a essere prudente non risolve il problema. Lo risolvono un identificatore canonico, un checkpoint persistente, una ricerca di duplicati e un’operazione idempotente.

Un agente non è affidabile perché sa spiegare che cosa dovrebbe fare. Lo diventa quando il sistema può verificare che cosa ha fatto davvero.

Lo stesso vale per gli errori. Un timeout non dimostra che l’azione non sia stata eseguita. Un messaggio di successo non dimostra che il dato finale sia corretto. Serve un percorso osservabile: input, autorizzazione, esecuzione, verifica, eventuale compensazione. È lo stesso principio che emerge quando un agente trova un bug e deve portare un test eseguibile: la spiegazione è utile, la prova è un’altra cosa.

Le quote aumentano. Ma il consumo resta un problema architetturale

Il 29 ottobre OpenAI ha annunciato un aumento dei limiti d’uso per i piani Pro 100, Pro 200, Pro 500 e Business Premium. La comunicazione, riportata anche da BleepingComputer, parla di un raddoppio nominale e della cancellazione di una riduzione prevista per gli utenti Pro 200. Per questi ultimi la conseguenza concreta può essere la conservazione della disponibilità precedente, non necessariamente un raddoppio rispetto al giorno prima. Non ci sono, nell’annuncio citato, soglie numeriche universali con cui calcolare quante esecuzioni aggiuntive completerà un singolo account.

Un altro cambiamento è previsto a partire da dicembre 2026: per Plus, Pro e Business l’allowance sarà condivisa tra ChatGPT e Codex nel percorso di integrazione delle capacità agentiche di Work nell’esperienza principale. OpenAI descrive una misurazione in token, con consumo influenzato dal modello scelto e dalla complessità del task. Le conversazioni Instant, secondo la documentazione corrente, non preleveranno da quella quota. Il residuo e i reset dovrebbero essere consultabili in Settings > Usage. È una transizione annunciata, non qualcosa da dare per già attivo su ogni account il 1° novembre.

Qui bisogna evitare l’equazione più comoda: quota doppia uguale lavoro doppio. Un workflow può consumare più token del previsto perché ripete ricerche, legge file grandi, produce verifiche o corregge errori. Può anche fermarsi su un permesso, una dipendenza o un limite di tempo prima di esaurire il budget. La quantità di lavoro utile completato dipende dall’intera pipeline, non soltanto dal contatore di utilizzo.

Come si progetta un agente quando la quota è condivisa

Se più flussi consumano la stessa allowance, il problema assomiglia alla gestione di una risorsa condivisa in un sistema distribuito. Non serve immaginare scenari fantascientifici: bastano un agente che analizza documenti, uno che scrive codice e uno che verifica risultati. Se lavorano senza priorità e senza checkpoint, il consumo di un task può impedire a un altro di terminare.

Il modello operativo sensato è molto meno spettacolare di una demo: budget per attività, limite ai retry, checkpoint dopo le operazioni importanti, priorità esplicite, possibilità di riprendere il lavoro e log sufficienti a spiegare perché è stato interrotto. La quota residua visibile nell’interfaccia è un’informazione utile, ma non sostituisce la contabilità del singolo processo. Una sessione può aver consumato risorse senza aver prodotto un risultato accettabile.

È un tema vicino a quello già discusso sul costo reale del clic di un agente: il prezzo unitario di una capacità non misura il costo di un errore o di un’azione da rifare. Quando un flusso dura ore, la domanda corretta non è soltanto quanti token siano disponibili, ma quanto lavoro verificato riesca a conservare se qualcosa si interrompe.

Cinque verifiche che valgono più di una promessa

La Model Spec può diventare utile anche per chi sviluppa, a patto di tradurre i principi in scenari testabili. Non significa ridurre valori umani a cinque booleani; significa almeno rendere osservabili alcune proprietà del sistema.

• Intenzione ambigua: l’agente chiede chiarimenti o propone un piano quando l’azione ha effetti importanti, invece di indovinare una delega.
• Permessi e confini: una richiesta fuori scope viene respinta dal livello applicativo anche se il modello prova a eseguirla.
• Effetti collaterali: un retry dopo timeout non duplica pagamenti, post, email o modifiche.
• Trasparenza: lo stato mostrato deriva da risposte e verifiche reali, non dalla sola descrizione dell’agente.
• Interruzione e budget: il task può fermarsi, conservare il lavoro valido e riprendere senza ripartire da zero.

Queste prove non esauriscono il tema della sicurezza o dell’allineamento. Però trasformano un discorso generico sulla “responsabilità dell’AI” in requisiti che un team può mettere sotto test, monitorare e discutere con un cliente. Sono anche un modo concreto per separare un agente capace di parlare di un processo da un sistema autorizzato a gestirlo.

La specifica è necessaria. L’architettura deve mantenerne le promesse

L’aggiornamento del 29 ottobre ha un valore: esplicita meglio il comportamento che OpenAI vuole ottenere dai propri modelli, compreso il rispetto della supervisione umana. L’aumento delle quote e la futura unificazione dei consumi rendono intanto più importante capire come quei modelli vengano usati in flussi di lavoro reali.

Il salto di qualità, però, non avviene quando si aggiunge un’altra frase al prompt, si cambia il nome di una funzionalità o si compra un piano con più capacità. Avviene quando intenzioni, autorizzazioni, verifiche, budget e ripresa degli errori diventano parti dello stesso sistema. Una specifica ti dice verso quale comportamento tendere. Un’architettura verificabile ti permette di capire quanto ci sei davvero vicino.