OpenAI Presence: agenti AI gestiti, non self-service
OpenAI Presence riunisce policy, simulazioni, azioni approvate, escalation umana e miglioramento con Codex: per chi conviene e quando sviluppare in proprio.
Secondo OpenAI, Presence risolve ormai il 75% delle richieste in entrata sulla linea di assistenza telefonica in inglese senza intervento umano; inoltre, il suo ciclo di miglioramento ha ridotto i passaggi a un operatore di 15 punti percentuali in 10 giorni. Dietro questi risultati non c’è uno strumento self-service per creare agenti AI. Presence è un deployment gestito per aziende che riunisce agente, policy, valutazioni, integrazione con i sistemi e attività operative continuative.
Il verdetto sugli agenti AI: Presence vende il deployment, non il modello
OpenAI Presence merita attenzione quando un flusso vocale o chat rivolto ai clienti deve eseguire azioni reali nel rispetto di policy rigorose e l’azienda vuole condividere con OpenAI l’onere dell’implementazione. Non è invece il punto di partenza adatto per un piccolo team in cerca di un builder self-service, per uno sviluppatore che vuole un SDK o per un’impresa che non ha ancora scelto un singolo flusso ben delimitato di cui assumersi la responsabilità.
Le condizioni di lancio dicono molto: Presence è disponibile solo per clienti enterprise idonei, con disponibilità generale limitata. I Forward Deployed Engineers di OpenAI e alcuni integratori di sistemi globali selezionati guidano i deployment; OpenAI precisa inoltre che il prodotto non è self-service. Né la pagina di lancio né l’attuale pagina di Frontier riportano un listino pubblico.
È quindi il modello di erogazione a costituire il prodotto. Un modello frontier sa già interpretare una richiesta di assistenza. La parte complessa è fornirgli il contesto corretto dell’account, limitarne i permessi, far rispettare una policy sui rimborsi, convalidarne le azioni, stabilire quando serve obbligatoriamente un’approvazione, inoltrare a una persona i casi rischiosi e aggiornare il sistema senza compromettere il comportamento del giorno precedente. Presence racchiude tutte queste attività in un unico incarico gestito.
Che cosa comprende davvero Presence
Presence è l’involucro operativo di produzione per un compito ben definito, non un dipendente digitale generalista. Ogni deployment parte da un workflow specifico. L’agente riceve soltanto le conoscenze e gli accessi ai sistemi necessari per quel compito, mentre il cliente stabilisce policy, punti di approvazione e regole per il passaggio a un operatore.
La parola guardrail può far pensare a un filtro applicato dopo la risposta del modello. In questo caso indica un sistema di controllo più ampio: regole che vincolano input, strumenti, azioni, permessi ed escalation. Presence combina policy e procedure operative standard, guardrail, azioni autorizzate, simulazioni, strumenti di valutazione e un processo di miglioramento basato su Codex.
Delimitare un solo compito
Si sceglie un risultato completo, per esempio risolvere un problema di fatturazione, assistere nella gestione di un sinistro assicurativo o occuparsi di una richiesta IT interna. Un’istruzione generica come «aiuta ogni cliente» non permette di creare né un set di valutazione utile né un confine dei permessi difendibile.
Limitare contesto e accessi
Si collegano soltanto i record e i sistemi necessari per quel compito. Un agente dedicato alla fatturazione può aver bisogno di identità, account, fatture e pagamenti; non gli serve accesso illimitato all’intero patrimonio di dati dei clienti.
Codificare policy e approvazioni
Occorre definire a quali domande l’agente può rispondere, quali azioni può eseguire, quando deve chiedere un’approvazione e quando deve subentrare una persona. Anche una risposta corretta abbinata a un’azione non autorizzata resta un errore in produzione.
Simulare prima del lancio
Le richieste comuni, i casi limite e gli scenari più rischiosi vengono sottoposti a grader. OpenAI afferma che le verifiche coprono qualità del risultato, conformità alle policy, uso degli strumenti e comportamento di escalation.
Migliorare con un processo di change control
Le sessioni in produzione, le escalation e i segnali di qualità fanno emergere le lacune. Codex analizza questi segnali e propone aggiornamenti che il team può confrontare con la versione in produzione prima di autorizzare un rilascio controllato.
Il ciclo conta più della demo. Un agente vocale può sembrare naturale il giorno del lancio e fallire comunque quando cambia un prodotto, compare una nuova eccezione alla policy sui rimborsi o i chiamanti imparano a formulare le richieste in modi non previsti dal set di test iniziale. Presence usa il comportamento in produzione per proporre modifiche, ma inserisce test e approvazione tra la proposta e il sistema attivo.
Per chi dirige l’assistenza clienti, questa è la differenza concreta tra un chatbot e un sistema operativo dedicato a un workflow. Il chatbot risponde. L’agente in produzione verifica, decide, agisce entro i limiti della propria autorità, registra ciò che è accaduto e passa il caso a una persona quando il rischio supera quei limiti.
Le prove sono promettenti, ma ancora circoscritte
I dati del lancio dimostrano che Presence può gestire un vero canale di assistenza, ma non bastano ancora a provare un ritorno generalizzabile per le aziende. OpenAI presenta i risultati ottenuti sulla propria linea telefonica di supporto in inglese, 1-888-GPT-0090: sono quindi sia evidenze utili sul prodotto sia dati comunicati dal fornitore.
L’elenco dei design partner fotografa una fase precedente. BBVA sta esplorando l’assistenza vocale per le esigenze bancarie quotidiane in Messico. SoftBank sta testando conversazioni naturali con i clienti in lingua giapponese. IAG valuta un supporto durante eventi ad alta domanda, come condizioni meteorologiche estreme. Questi programmi mostrano ampiezza sul piano linguistico e nei flussi regolamentati, ma OpenAI non li presenta come risultati di produzione equivalenti.
Nel lancio mancano anche i numeri indispensabili per il procurement: prezzo pubblico, tempi di implementazione, volume minimo, modello di assistenza, tassi di errore per azione e costo per contatto risolto correttamente. È comprensibile in una fase di disponibilità generale limitata, ma significa che non esiste ancora un confronto pubblico dei costi che sia credibile. Senza un contratto e una baseline del workflow, qualsiasi stima precisa del ROI va considerata priva di fondamento.
Presence occupa un livello preciso nello stack di agenti AI di OpenAI
Presence è il percorso gestito per i workflow all’interno di una famiglia di prodotti che comprende anche ChatGPT Workspace Agents, OpenAI Agents SDK e Frontier. Considerare questi nomi intercambiabili porta a un processo d’acquisto sbagliato, perché ogni soluzione assegna la responsabilità a un soggetto diverso.
ChatGPT Workspace Agents: attività interne ripetibili
ChatGPT Workspace Agents è il percorso più leggero per il lavoro ripetibile che già si svolge in un workspace Business o Enterprise. Chi crea l’agente può scegliere modello e livello di ragionamento, collegare app e strumenti, pubblicarlo per i colleghi, usarlo in Slack, programmarne l’esecuzione o attivarlo tramite API.
I controlli sono sostanziali, ma il perimetro di esecuzione è più ristretto. Le azioni di scrittura per app e connettori sono impostate per default su Always ask. Connector Action Constraints può limitare ciò che un’integrazione è autorizzata a fare, anche se OpenAI precisa che questi vincoli non filtrano i dati restituiti da un connettore. Ogni file può pesare al massimo 512 MB e il limite complessivo per agente è 10 GB.
Il limite determinante dell’API è operativo: un trigger mette in coda un’esecuzione e restituisce 202 Accepted senza corpo della risposta. Non fornisce un ID dell’esecuzione e, al momento, il risultato non può essere recuperato tramite la stessa API. Può bastare per attività interne avviate senza attendere l’esito. È invece un contratto inadeguato per un prodotto rivolto ai clienti, dove servono stato sincrono, logica di retry e risultati tracciabili.
OpenAI Agents SDK: controllo di un prodotto personalizzato
OpenAI Agents SDK è adatto a un’azienda che vuole integrare l’agente nel proprio prodotto o nella propria infrastruttura. La guida alla creazione di agenti di OpenAI riduce l’architettura a tre componenti fondamentali: un modello che ragiona, strumenti che leggono o agiscono e istruzioni che definiscono il comportamento.
Questi componenti rappresentano solo il centro del sistema. Chi sviluppa resta responsabile di identità, autorizzazioni, contratti degli strumenti, dati di valutazione, monitoraggio, comportamenti di fallback, risposta agli incidenti e costi. OpenAI consiglia di partire dal modello più potente per stabilire una baseline di valutazione, quindi sostituirlo con modelli più piccoli nei punti in cui l’accuratezza rimane accettabile. Raccomanda inoltre di sfruttare al massimo un singolo agente prima di introdurre un’architettura multi-agente.
Lo sviluppo personalizzato è la scelta giusta quando il workflow differenzia il prodotto, i vincoli di deployment sono insoliti o l’azienda deve ottimizzare in modo granulare i costi di modelli e strumenti. Se la portabilità tra fornitori è importante, il livello di astrazione va progettato al di sopra dell’SDK di qualunque singolo provider. Scegliere un SDK, da solo, non rende il sistema portabile.
OpenAI Frontier: la piattaforma per tutta l’organizzazione
OpenAI Frontier è il percorso di piattaforma più ampio per le aziende che gestiscono numerosi agenti tra reparti e sistemi diversi. I livelli pubblicati sono Business Context, Agent Execution, valutazione e ottimizzazione, sicurezza e governance enterprise.
Frontier è progettato per governare in un’unica piattaforma agenti creati dal cliente, agenti OpenAI e agenti di terze parti. OpenAI descrive identità e gestione degli accessi per gli agenti, permessi espliciti, azioni verificabili tramite audit, monitoraggio e log dettagliati. L’Enterprise Frontier Program affianca inoltre al cliente forward-deployed engineers per progettare l’architettura, rendere operativa la governance e portare gli agenti in produzione.
La mappa dei prodotti è semplice: Workspace Agents offre un’esperienza confezionata per gli agenti interni, l’SDK fornisce i componenti di sviluppo, Presence consegna un workflow implementato e Frontier mette a disposizione il control plane enterprise. OpenAI non ha pubblicato una mappa contrattuale che chiarisca quali componenti di Frontier siano inclusi in un incarico Presence: gli acquirenti dovrebbero chiedere, non dedurre.
Per una prospettiva di mercato più ampia, oltre OpenAI, è utile confrontare piattaforme enterprise e compromessi operativi nella guida ai migliori agenti AI del 2026.
Chi dovrebbe acquistare Presence e chi dovrebbe sviluppare in proprio
Presence conviene quando il workflow è circoscritto, prezioso, orientato all’azione e costoso da sbagliare. Lo sviluppo interno è preferibile quando l’agente costituisce proprietà intellettuale strategica, i vincoli operativi sono insoliti o il controllo di lungo periodo conta più di un percorso gestito verso la produzione.
Presence risulta particolarmente credibile nei flussi di servizio con policy complesse. Si pensi a un assicuratore che gestisce chiamate sullo stato dei sinistri durante condizioni meteorologiche estreme. L’agente deve identificare il chiamante, recuperare polizza e pratica corrette, distinguere una domanda sullo stato da una richiesta di modifica, agire soltanto entro la propria autorità e passare il caso a una persona quando aumenta il rischio. Il linguaggio naturale è solo uno degli elementi: accessi ed escalation determinano la sicurezza del workflow.
Lo sviluppo personalizzato prevale quando è l’agente stesso a creare vantaggio competitivo. Un’azienda di software verticale può aver bisogno di strumenti proprietari, un set di valutazione specifico per il dominio, un’esperienza utente distintiva, supporto per più provider di modelli o un deployment in un ambiente incompatibile con un servizio gestito. In questo scenario, esternalizzare il ciclo operativo può significare esternalizzare anche conoscenze che dovrebbero restare nel team di prodotto.
La prospettiva di chi gestisce l’operatività cambia la risposta. Un CTO di un’azienda di medie dimensioni, con una coda di assistenza vincolata da molte policy e nessuna intenzione di creare una funzione permanente dedicata alle operazioni degli agenti, ha buone ragioni per avviare un progetto pilota con Presence. Un founder finanziato il cui prodotto è l’agente dovrebbe in genere mantenere il controllo di architettura e dati di valutazione. Un senior operator che automatizza approvazioni interne dovrebbe partire da Workspace Agents o da un workflow deterministico. Per uno sviluppatore tecnico indipendente è più indicata la strada dell’SDK, perché Presence non è self-service né pensato per esperimenti leggeri.
Non bisogna creare un agente solo perché un LLM sa interpretare l’input. Se un motore di regole può prendere la decisione in modo affidabile e il livello linguistico deve soltanto raccogliere campi strutturati, la decisione deve restare deterministica. Il ragionamento probabilistico va riservato ai casi in cui l’ambiguità lo richiede davvero.
Prima della firma, pretendere una scorecard del workflow
Il progetto pilota va giudicato sui risultati corretti e sugli errori controllati, non sulla naturalezza della conversazione. Il dato del 75% di risoluzioni è un titolo efficace, ma il contratto deve contenere definizioni che reggano all’esame di finanza, rischio e operations.
Occorre monitorare almeno queste metriche:
- Tasso di risoluzione corretta: la quota di contatti idonei completati con accuratezza, non semplicemente chiusi senza passare a una persona.
- Tasso di falsa risoluzione: i contatti segnati come completati nonostante una risposta errata, un’azione sbagliata o un’esigenza rimasta irrisolta.
- Conformità alle policy: se l’agente ha seguito la regola e il percorso di approvazione applicabili in quel momento.
- Qualità dell’esecuzione degli strumenti: se letture e scritture hanno interessato il record corretto, impiegato i parametri corretti e prodotto il cambiamento di stato previsto.
- Qualità dell’escalation: se i casi rischiosi o incerti sono arrivati alla persona giusta insieme al contesto necessario per proseguire.
- Costo per contatto risolto correttamente: costi di contratto, modello, integrazione, revisione e assistenza divisi per i risultati verificati come positivi.
- Latenza e abbandono: andamento dei tempi di risposta in condizioni di domanda normale e di picco, e quota di chiamanti che abbandonano prima della risoluzione.
- Sicurezza delle modifiche: se un aggiornamento proposto a policy o prompt migliora i casi obiettivo senza peggiorare quelli già consolidati.
Il denominatore è decisivo. Un sistema può aumentare il contenimento occupandosi delle richieste facili e inoltrando tutto ciò che costa di più. Può anche gonfiare il tasso di risoluzione chiudendo conversazioni che in seguito vengono riaperte. I risultati vanno segmentati per intento, tipo di azione, classe di rischio, lingua e canale, così il dato aggregato non può nascondere gli errori più costosi.
Scegliere un risultato completo
Il compito va definito in termini aziendali, indicando dove inizia, come si presenta una conclusione corretta, quali azioni sono consentite e che cosa deve sempre passare a una persona.
Creare il set di valutazione
Documenti di policy reali e schemi storici anonimizzati devono coprire richieste normali, ambiguità, informazioni mancanti, formulazioni avversarie, policy modificate e casi limite ad alto rischio.
Definire la matrice delle autorizzazioni
Ogni azione degli strumenti va elencata e classificata per reversibilità, autorizzazione, impatto finanziario e possibile danno al cliente. Le azioni ad alto rischio o irreversibili devono restare sotto supervisione umana finché le prove non giustificano un perimetro più ampio.
Affiancare l’agente al processo esistente
Prima di permettere all’agente di modificare record reali, si confrontano risposte, azioni ed escalation proposte con quelle del processo corrente. Le divergenze vanno analizzate, non appiattite facendo una media.
Estendere per intento verificato
Le tipologie di richiesta già convalidate passano in produzione per gruppi controllati. È necessario mantenere un percorso di rollback immediato e imporre test di regressione prima del rilascio di modifiche a policy, strumenti o istruzioni.
Prima del lancio, l’acquirente deve anche chiarire le responsabilità. Qualcuno dovrà approvare le modifiche alle policy, esaminare gli incidenti, mantenere le integrazioni, gestire il set di valutazione e decidere quando ampliare l’autorità dell’agente. Presence può fornire tecnologia e competenze di deployment, ma non può eliminare la responsabilità dell’azienda sul workflow.
La lettura strategica
OpenAI Presence è rilevante perché sposta la vendita degli agenti enterprise dall’accesso al modello alla responsabilità operativa. La promessa non è più «usa la nostra intelligenza», ma «lascia che ti aiutiamo a gestire un workflow governato e a migliorarlo dopo il lancio».
È una proposta di prodotto più solida rispetto all’ennesimo builder di agenti generalista. Crea però anche una dipendenza più profonda dal team di deployment, dai modelli, dal processo di miglioramento e dal contratto di OpenAI. Lo scambio è razionale quando velocità gestita e competenze operative condivise valgono più del possesso del sistema. Diventa una dipendenza costosa quando il workflow dovrebbe trasformarsi in una competenza proprietaria.
La domanda decisiva per l’acquisto, dunque, non è se Presence sembri intelligente. Bisogna chiedere chi è responsabile del risultato, chi controlla ogni azione, chi dimostra che un aggiornamento è sicuro e chi sostiene il workflow quando l’agente fallisce. Se il contratto risponde a queste domande e il progetto pilota conferma la sostenibilità economica, Presence può accorciare la fase più difficile nell’adozione degli agenti enterprise. In caso contrario, è meglio costruire un sistema più ristretto, misurabile e controllabile.
OpenAI Presence è disponibile come prodotto self-service?
No. OpenAI afferma che Presence è disponibile per clienti enterprise idonei con disponibilità generale limitata. I Forward Deployed Engineers e alcuni integratori di sistemi globali selezionati guidano i deployment; la pagina di lancio invita gli acquirenti a rivolgersi al proprio account team OpenAI.
In che cosa OpenAI Presence differisce da ChatGPT Workspace Agents?
Workspace Agents sono agenti condivisi, creati all’interno di ChatGPT per attività ripetibili, con app, strumenti, Slack, pianificazioni e trigger API. Presence è un deployment di produzione gestito per workflow vocali e chat in tempo reale che usano i sistemi aziendali, eseguono azioni governate e passano i casi alle persone.
OpenAI pubblica i prezzi di Presence?
No. Né la pagina di lancio del 22 luglio 2026 né l’attuale pagina del prodotto Frontier riportano un listino pubblico. Un preventivo utile deve riferirsi a un workflow definito, al relativo volume, al perimetro delle integrazioni, al modello di assistenza e a criteri di successo misurabili.
Un’azienda dovrebbe acquistare Presence o sviluppare il proprio agente?
Presence conviene quando un workflow vocale o chat, vincolato da molte policy, richiede un deployment gestito e l’azienda accetta OpenAI come partner operativo profondo. Lo sviluppo interno è preferibile quando l’agente differenzia il prodotto, il controllo dell’architettura è strategico, i vincoli di deployment sono insoliti oppure portabilità dei modelli ed economia unitaria contano più della velocità di un servizio gestito.
Per decidere se acquistare un agente gestito o mantenere il controllo del sistema, è utile mappare il workflow e il confine del rischio prima di sviluppare.
3 set 2026
Preferisca questo sito su Google
Segni omidsaffari.com come fonte preferita e Google lo mette in evidenza per lei in Top Stories, AI Overviews e AI Mode.
