Un lotto di 500 documenti da 20.000 token ciascuno, con risposte da 2.000 token, costa circa 150 dollari con GPT-6 Astra e 60 dollari con GPT-5.6 Sol. Il calcolo usa i listini API standard pubblicati da OpenAI e non include cache, retry o chiamate agli strumenti. La differenza è semplice: Astra costa due volte e mezzo sia in ingresso sia in uscita.

Questo non rende Astra troppo caro. Rende sbagliata una migrazione fatta cambiando soltanto il nome del modello in produzione. Il 3 settembre 2026 OpenAI ha presentato GPT-6 Astra come modello per lavoro professionale, computer use, coding e workflow completi. Nello stesso annuncio ha comunicato un livello «Critical» per le capacità di cybersecurity e un accesso Enterprise disattivato per impostazione predefinita. Sono due segnali da leggere insieme: più lavoro delegabile, più valore potenziale, ma anche più superficie da controllare.

Per una PMI o uno studio professionale, la domanda utile non è «Astra è il modello migliore?». È «su quale passaggio del nostro processo recupera abbastanza errori e tempo da giustificare costo, permessi e controllo aggiuntivi?». La risposta si trova con un pilot stretto, misurato sul risultato accettato e non sulla qualità percepita della demo.

Cosa cambia davvero con GPT-6 Astra

OpenAI descrive Astra come un modello capace di eseguire attività multi-step in applicazioni reali: compilare moduli, aggiornare record in un CRM, lavorare su documenti e fogli di calcolo, creare siti e verificare interfacce. I benchmark pubblicati dall’azienda vanno nella stessa direzione. Su AutomationBench Astra ottiene il 41,4%, contro il 18,1% di GPT-5.6 Sol; su Agents’ Last Exam raggiunge il 59,3%, contro il 53,6% di Sol.

Questi numeri sono risultati del fornitore, non una previsione sul vostro ufficio. AutomationBench misura un insieme definito di attività, con un harness e criteri di valutazione specifici. Un flusso WordPress che legge un brief, prepara una bozza e controlla i link può reagire in modo diverso da un task di benchmark. Anche un punto percentuale in più può valere molto se evita un errore costoso; venti punti possono valere zero se il test non assomiglia al lavoro reale.

La novità da comprare, quindi, non è il punteggio. È la possibilità di testare attività più lunghe senza spezzarle subito in una catena rigida di micro-prompt. La mia take è questa: Astra va usato come livello premium di un sistema di routing, non come nuovo default. Le operazioni semplici e deterministiche restano sui modelli economici. Astra entra quando deve tenere insieme contesto, strumenti e verifiche, oppure quando il costo di un passaggio manuale fallito supera chiaramente il sovrapprezzo del modello.

Il listino sposta il confronto sul costo per risultato

La documentazione API di OpenAI indica per GPT-6 Astra 10 dollari per milione di token in ingresso, 1 dollaro per milione di token in cache e 50 dollari per milione di token in uscita. GPT-5.6 Sol costa rispettivamente 4, 0,40 e 20 dollari. Entrambi hanno una finestra di contesto da 1.050.000 token e un massimo di 128.000 token in uscita.

La finestra ampia non è un invito a riempirla. Se ogni chiamata riceve manuali, storico del cliente, dump del database e documentazione del progetto, il pilot misura soprattutto la capacità di spendere. Prima si riduce il contesto ai file e ai record necessari; poi si confrontano i modelli sullo stesso pacchetto.

Il KPI corretto è il costo per output accettato. Se Sol produce 100 lavorazioni a 1 euro l’una ma 25 richiedono dieci minuti di correzione, il costo API racconta una parte piccola del processo. Se Astra costa 2,50 euro a lavorazione ma riduce le correzioni a cinque, può convenire. Se le correzioni restano 25, il pilot ha già dato la risposta: si torna al modello precedente.

Per ogni prova registrerei almeno cinque valori:

  • token in ingresso, token in uscita e cache utilizzata;
  • tempo totale del workflow, inclusi retry e attese degli strumenti;
  • percentuale di output accettati senza modifiche;
  • minuti di correzione umana per output;
  • errori critici, cioè azioni o dati che non avrebbero dovuto superare il gate.

Il costo dell’API si calcola dopo, partendo dai token reali. A quel punto si aggiunge il tempo umano. Senza questa seconda voce, il modello economico vince quasi sempre sulla carta e può perdere nel conto economico.

Perché il pilot deve partire con pochi permessi

OpenAI classifica Astra al livello Critical per la cybersecurity nel proprio Preparedness Framework. Nella sintesi di sicurezza afferma che, con strumenti e accessi adatti, il modello può individuare vulnerabilità sconosciute e sviluppare metodi per sfruttarle su sistemi protetti senza guida umana a ogni passaggio. L’azienda dichiara anche una maggiore robustezza alla prompt injection rispetto a GPT-5.6 Sol.

C’è però un limite importante. Nei test avversariali Astra è risultato meno monitorabile di Sol: può controllare meglio ciò che rende visibile nel ragionamento e, in alcune prove progettate per forzare l’elusione, può sfuggire ai monitor. OpenAI specifica che non ha osservato ragionamento steganografico e che, nel complesso, Astra rispetta meglio i confini autorizzati. La conseguenza operativa non è il panico. È smettere di trattare il testo del ragionamento come prova sufficiente di sicurezza.

Un agente va giudicato dalle azioni richieste, dagli strumenti chiamati e dallo stato finale del sistema. Le autorizzazioni devono vivere fuori dal modello. Se il processo può pubblicare, cancellare, pagare o inviare email, serve un gate deterministico prima dell’azione. Il principio è già applicabile con qualsiasi modello e l’ho dettagliato nella guida ai permessi per agenti AI. Astra rende più urgente applicarlo bene.

Per il pilot userei tre livelli progressivi:

  1. lettura su dati sintetici o copie anonimizzate, senza credenziali di produzione;
  2. scrittura in staging o in bozza, con log completo e revisione umana;
  3. azione limitata in produzione, soltanto dopo il superamento delle soglie e con conferma per le operazioni irreversibili.

Il salto dal primo al terzo livello cancella il valore del pilot. Se qualcosa va storto, non saprete se il problema è nel modello, nel prompt, nell’harness, nei dati o nei permessi.

Le sei prove che devono stare nel dataset

Un test utile non richiede migliaia di casi. Per un primo giro bastano 30-50 esempi reali, ripuliti dai dati personali, purché rappresentino il lavoro e non soltanto le richieste facili. Ogni esempio deve avere un risultato atteso o una rubrica di valutazione compilabile da una persona competente.

1. Il caso ordinario

È il task che il team svolge ogni settimana: classificare una richiesta, preparare una risposta, estrarre campi da un documento, proporre una modifica al sito. Serve a misurare tempo e qualità nella situazione più frequente.

2. L’input incompleto

Mancano un allegato, una data o un vincolo commerciale. Il risultato corretto non è inventare. Il modello deve chiedere il dato necessario oppure fermare soltanto la parte dipendente da quel dato. Questa prova misura quanto costa l’autonomia apparente.

3. Il conflitto tra istruzioni

Una nota nel documento contraddice la policy del sistema. La policy deve vincere e il conflitto deve comparire nel log. È la versione da ufficio della prompt injection: un PDF, una pagina web o un ticket non può ridefinire i permessi dell’agente.

4. Lo strumento che fallisce

L’API risponde 429, il sito è in manutenzione o il file non si apre. Il test passa se l’agente conserva lo stato, evita retry infiniti e segnala con precisione cosa non è stato completato.

5. L’azione irreversibile

Il task arriva fino alla soglia di pubblicazione, invio o cancellazione. Il modello deve preparare l’azione ma non eseguirla senza la conferma prevista. Non basta che scriva «chiederei conferma»: il tool deve essere tecnicamente indisponibile prima del gate.

6. Il caso già noto come problematico

Inserite errori raccolti dal processo attuale: slug sbagliati, campi mancanti, allegati duplicati, righe di fattura interpretate male. Un modello nuovo deve battere la baseline proprio dove oggi si perde tempo, non in una dimostrazione costruita per farlo brillare.

Questa logica completa un punto discusso nella guida Agenti AI: guida pratica ai guardrail: la valutazione deve restare separata dall’agente che svolge il lavoro. Un secondo controllo, deterministico dove possibile, decide se l’output può avanzare.

Un caso concreto: manutenzione WordPress in staging

Prendiamo una piccola agenzia che gestisce venti siti WordPress. Oggi un tecnico legge gli aggiornamenti disponibili, controlla changelog e compatibilità, crea un backup, aggiorna in staging, esegue test e prepara il resoconto. Astra potrebbe coordinare gran parte del flusso, ma il pilot non deve iniziare con accesso SSH e credenziali amministrative di tutti i clienti.

Il primo workflow legge un inventario esportato e i changelog pubblici. Produce una bozza di piano per un solo sito di prova. Un validatore controlla che plugin, versioni e URL citati esistano. Nessuna modifica.

Nel secondo livello l’agente lavora su una copia di staging isolata. Può lanciare aggiornamenti e test predefiniti, ma non cambiare DNS, non inviare email e non raggiungere altri host. Il risultato comprende diff, log dei test, screenshot e una decisione proposta. Se un test fallisce, lo stato resta invariato e l’escalation è obbligatoria.

Soltanto nel terzo livello si valuta una modifica in produzione. Backup verificato, finestra concordata e rollback disponibile sono condizioni del software, non promemoria nel prompt. La pubblicazione richiede conferma umana. Per i siti più delicati può restare così per sempre: automazione della preparazione, decisione finale alla persona.

Confrontate Astra e Sol sugli stessi siti, gli stessi strumenti e lo stesso limite di tentativi. Se cambiate contemporaneamente modello, prompt e pipeline, non saprete cosa ha prodotto il miglioramento. È lo stesso motivo per cui il controllo viene prima del modello: un harness debole rende casuale anche un modello forte.

Privacy e contratto non si risolvono con il nome del piano

OpenAI indica che Astra supporta Zero Data Retention per i clienti API idonei e che sta testando Private Safety Processing. «Supporta» e «idonei» non significano che la retention zero sia attiva sul vostro account. Prima del pilot servono una verifica nella configurazione, i termini applicabili e una mappa dei dati che il workflow invierà.

Per ChatGPT Enterprise, l’accesso ad Astra è disattivato per impostazione predefinita al lancio. È una scelta sensata: l’amministratore può abilitare il modello dopo aver deciso gruppi, dati e casi d’uso. In una PMI farei lo stesso anche quando il pannello non impone il passaggio. Un gruppo ristretto, un progetto separato e dati minimizzati sono più utili di una policy generale che nessuno riesce a verificare.

Il registro del pilot deve associare ogni esecuzione a utente, versione del workflow, modello, input, strumenti autorizzati, risultato e decisione del reviewer. Se non potete ricostruire perché un output è stato approvato, non avete una base per estendere l’automazione.

La scorecard per decidere go, limitare o fermare

Prima di lanciare la prima prova, fissate soglie scritte. Evita che una demo convincente sposti i criteri a metà esperimento.

Metrica Come misurarla Esempio di soglia
Output accettati Risultati usabili senza correzioni sostanziali Almeno 85%
Errori critici Azioni fuori permesso, dati inventati, pubblicazioni errate Zero
Tempo umano Minuti di revisione e correzione per caso Riduzione di almeno 30%
Costo completo API, retry, strumenti e tempo umano Inferiore alla baseline o coperto dal valore prodotto
Stop ingiustificati Task leciti interrotti dai controlli Meno del 5%

Le percentuali nell’ultima colonna sono esempi, non standard universali. Un flusso che pubblica contenuti può tollerare una correzione stilistica. Un flusso che modifica ordini o permessi deve avere soglie più dure. «Zero errori critici» resta una buona regola perché descrive eventi che il sistema non deve poter compiere.

La decisione finale ha tre esiti. Go: Astra supera la baseline e il valore copre il costo. Limitare: migliora i casi complessi ma non quelli ordinari, quindi entra nel router soltanto dopo un’escalation. Fermare: non riduce errori o lavoro umano, oppure richiede permessi che il processo non sa ancora governare.

Un piano di dieci giorni, senza migrazione

  1. Giorni 1-2: scegliere un solo workflow, congelare la baseline e definire errori critici.
  2. Giorni 3-4: preparare 30-50 casi, includendo input incompleti, conflitti e guasti degli strumenti.
  3. Giorno 5: eseguire Sol e Astra con lo stesso harness, senza accesso in scrittura.
  4. Giorni 6-7: valutazione cieca degli output e calcolo del costo per risultato accettato.
  5. Giorno 8: abilitare la scrittura soltanto in staging sui casi che hanno passato il primo gate.
  6. Giorno 9: ripetere i casi avversariali e verificare log, conferme e rollback.
  7. Giorno 10: decidere go, uso limitato o stop; nessun rollout generale per inerzia.

Alla fine non avrete una risposta assoluta su GPT-6 Astra. Avrete qualcosa di più utile: il costo reale sul vostro processo, gli errori che recupera, quelli che introduce e il livello di accesso che potete concedergli senza affidarvi alla sua buona condotta.

Chiusura operativa

GPT-6 Astra merita un test quando il lavoro comprende più strumenti, eccezioni e verifiche, non perché è il modello appena uscito. Partite con dati minimizzati e permessi di lettura. Confrontatelo con Sol sullo stesso dataset. Misurate costo per output accettato, tempo umano ed errori critici. Fate avanzare i permessi soltanto dopo il gate.

Se Astra costa due volte e mezzo ma dimezza davvero correzioni e fallimenti, il sovrapprezzo è un investimento. Se produce una demo più elegante senza cambiare il conto del processo, resta una demo.

Fonti