OpenAI ha pubblicato un nuovo approfondimento enterprise su GPT‑6 Astra, il modello introdotto la settimana precedente e reso disponibile in ChatGPT Work, Codex e API.
La fonte ufficiale OpenAI presenta Astra come un modello progettato per il lavoro professionale complesso. Tra le caratteristiche evidenziate c’è la capacità di utilizzare le stesse applicazioni con cui lavorano le persone, anche quando tali applicazioni non espongono un’API specifica.
È un passaggio importante perché riduce una delle barriere tradizionali dell’automazione: la necessità di costruire un’integrazione dedicata per ogni software.
Ma proprio questa maggiore capacità rende molto più importante la governance.
Dalla risposta all’azione
Un chatbot può sbagliare una risposta. Un agente può sbagliare un’azione.
Questa differenza sembra ovvia, ma cambia completamente il modo in cui un sistema AI deve essere progettato. Se un modello può aprire applicazioni, navigare siti, leggere documenti, caricare file o modificare dati, l’errore non rimane confinato nel testo generato.
Può trasformarsi in un documento condiviso con la persona sbagliata, un’informazione modificata, un download non autorizzato o un’azione eseguita senza che l’utente abbia realmente inteso approvarla.
OpenAI dedica infatti una parte importante del nuovo approfondimento su GPT‑6 Astra ai controlli enterprise. Gli amministratori possono limitare quali siti e applicazioni desktop siano accessibili, gestire upload e download e controllare la cronologia di navigazione. ChatGPT Work e Codex includono inoltre policy di conferma che possono richiedere l’approvazione dell’utente prima delle azioni considerate rilevanti, oltre a meccanismi automatici di revisione delle tool call potenzialmente non sicure o non autorizzate.
Il significato è chiaro: quando l’AI entra nei processi reali, la capacità del modello non basta. Serve un sistema di autorizzazioni.
Il principio del minimo privilegio arriva agli agenti AI
La cybersecurity utilizza da anni il principio del least privilege: ogni utente o sistema dovrebbe ricevere soltanto i privilegi necessari per svolgere il proprio compito.
Lo stesso principio deve essere applicato agli agenti AI:
- un agente che deve leggere documenti non dovrebbe automaticamente poterli modificare;
- un agente che prepara una risposta email non deve necessariamente poterla inviare;
- un agente incaricato di interrogare un database potrebbe utilizzare credenziali in sola lettura;
- un workflow che accede a tre siti non dovrebbe avere accesso illimitato a Internet se questo non è necessario.
È una differenza fondamentale rispetto a molti prototipi AI, nei quali il modello riceve accesso a un insieme molto ampio di strumenti perché è più semplice da configurare.
In produzione, invece, ogni capacità aggiunta dovrebbe essere giustificata dal task.
OpenAI esplicita proprio questa logica quando afferma che i nuovi controlli consentono alle aziende di partire da una configurazione limitata ed estendere progressivamente l’accesso nel tempo.
Il controllo umano non scompare
L’obiettivo degli agenti non dovrebbe essere eliminare ogni intervento umano. In molti casi il modello può svolgere autonomamente gran parte del lavoro, mentre la persona mantiene il controllo sui passaggi realmente consequenziali.
Un agente può raccogliere informazioni, confrontare documenti, compilare una bozza e predisporre un’azione. L’ultimo passaggio può però richiedere conferma.
Questa logica permette di automatizzare attività ripetitive senza cedere indiscriminatamente il controllo dei sistemi aziendali.
OpenAI introduce confirmation policy proprio per consentire di richiedere approvazione prima di determinate azioni. È un elemento significativo perché il cosiddetto human in the loop non viene trattato come un ostacolo all’automazione, ma come una componente progettuale dell’agente.
Per le imprese è un principio particolarmente utile. Non è necessario passare immediatamente da zero automazione a un agente completamente autonomo. È possibile costruire livelli intermedi di delega.
Computer use: perché cambia l’integrazione con il software
Un altro elemento rilevante di GPT‑6 Astra è la capacità di lavorare attraverso l’interfaccia delle applicazioni esistenti.
Tradizionalmente, per collegare un sistema AI a un gestionale, un CRM o un’applicazione verticale era necessario disporre di API o costruire un’integrazione specifica.
OpenAI sostiene invece che Astra possa lavorare attraverso le applicazioni utilizzate dalle persone anche quando queste non dispongono di API.
Questo amplia il numero di processi potenzialmente automatizzabili, soprattutto nelle PMI e negli Studi Professionali, dove spesso convivono software moderni, applicazioni legacy e strumenti verticali privi di API complete.
Non significa però che il computer use debba sostituire sempre le API. Quando è disponibile un’integrazione strutturata e controllabile, questa può restare preferibile. Il valore del computer use è soprattutto ampliare il perimetro delle attività raggiungibili.
Il modello non deve vedere tutto
Lo stesso principio vale per i dati.
Un agente non dovrebbe ricevere automaticamente accesso all’intera knowledge base aziendale. Il contesto deve essere selezionato in funzione dell’utente, del progetto e del task.
Un sistema RAG, come Gol-IA, può recuperare soltanto i documenti pertinenti alla richiesta e autorizzati per quell’utente. In questo modo il modello riceve meno informazioni, più rilevanti e più facili da verificare.
Questa separazione è particolarmente importante quando si utilizzano modelli esterni. L’organizzazione può mantenere documenti e retrieval all’interno della propria infrastruttura e inviare al provider soltanto i frammenti strettamente necessari alla generazione della risposta.
Non elimina ogni rischio, ma riduce l’esposizione rispetto all’invio indiscriminato dei documenti completi.
Tracciabilità: sapere cosa ha fatto l’agente
Quando un agente esegue un workflow di più passaggi, diventa importante poter ricostruire l’esecuzione.
Quale utente ha avviato il task? Quale modello è stato utilizzato? Quali fonti sono state recuperate? Quali applicazioni sono state aperte? Quali tool sono stati invocati? Quali azioni hanno richiesto conferma?
Queste informazioni servono sia per il debugging sia per la governance.
Un errore può dipendere dal modello, dal retrieval, da un tool, da una configurazione o da una fonte non aggiornata. Senza una traccia dell’esecuzione diventa difficile capire dove intervenire.
È per questo che l’AI enterprise sta progressivamente assomigliando meno a una semplice chat e più a una vera infrastruttura applicativa.
Sicurezza: il dato interessante va letto con cautela
OpenAI dichiara che, in un proprio benchmark interno dedicato a scenari difficili di computer use — per esempio esposizione di informazioni riservate, condivisione eccessiva di dashboard o cancellazione di dati — Astra avrebbe prodotto risultati indesiderati l’89% meno frequentemente rispetto a GPT‑5.6 Sol e il 74,7% meno frequentemente rispetto a Claude Fable 5.1.
È un dato interessante, ma va interpretato correttamente.
Si tratta di un benchmark interno del produttore. Non equivale a dimostrare che un agente basato su Astra sia automaticamente sicuro in qualunque ambiente.
Anzi, il fatto stesso che OpenAI affianchi al modello confirmation policy, restrizioni applicative e controlli automatici suggerisce la conclusione opposta: anche con modelli più affidabili, la sicurezza deve essere costruita nell’architettura.
Cosa significa per PMI e Studi Professionali
Per una PMI o uno Studio Professionale il valore degli agenti AI non deriva dalla possibilità di costruire sistemi spettacolari, ma dalla capacità di automatizzare attività concrete.
Ricercare informazioni nei documenti, raccogliere dati dalle email, aggiornare una pratica, preparare un report, controllare scadenze o compilare una bozza sono attività che possono essere suddivise in passaggi e affidate parzialmente all’AI.
La differenza tra un esperimento e un sistema realmente utilizzabile sta però nel controllo.
Bisogna decidere quali fonti siano autorizzate, quali utenti possano accedervi, quali azioni siano automatiche e quali richiedano conferma.
Gol‑IA: agenti dentro un perimetro governato
È la direzione su cui è costruito Gol‑IA.
Contattaci per avere informazioni in anteprima su Gol-IA:
Gol‑IA nasce come hub AI locale e ibrido nel quale modelli, knowledge base, documenti, email, siti, database, utenti e workflow possono essere gestiti come componenti separati.
Un agente può lavorare soltanto sulle fonti necessarie a uno specifico progetto. Un workflow può preparare un’azione ma fermarsi prima del passaggio finale. Una knowledge base può rimanere nell’infrastruttura dell’organizzazione mentre un modello esterno riceve soltanto il contesto selezionato necessario per il task.
Allo stesso tempo, modelli locali possono essere utilizzati per attività ripetitive o dati che l’organizzazione preferisce mantenere all’interno del proprio perimetro.
Questo non significa che un’architettura on-premise o ibrida garantisca automaticamente sicurezza o conformità. La conformità dipende dal caso d’uso, dai dati, dai ruoli e dagli obblighi applicabili.
Permette però di lavorare su elementi molto concreti: minimizzazione dell’esposizione, segregazione dei dati, permessi, controllo dei tool, tracciabilità delle fonti e audit delle esecuzioni.
L’AI enterprise non è più soltanto un modello
La nuova pagina di OpenAI su GPT‑6 Astra rende evidente una trasformazione ormai in corso.
La competizione non riguarda soltanto chi produce il modello più intelligente. Riguarda chi riesce a trasformare quel modello in un sistema capace di lavorare nei processi reali senza perdere il controllo.
Quando l’AI può usare applicazioni, navigare, leggere documenti ed eseguire azioni, la domanda più importante non è più soltanto:
“Cosa sa fare questo modello?”
Diventa:
“Cosa gli permettiamo di fare, su quali dati e con quali controlli?”
È su questa risposta che si giocherà una parte importante dell’AI aziendale dei prossimi anni.