Quando un'applicazione deve decidere in fretta — questo messaggio è spam? A quale reparto va questo ticket? Posso eseguire questo comando senza chiedere conferma? — spesso si usa un modello generico con un prompt lungo per una domanda che ha in realtà una risposta chiusa. È una soluzione che funziona, ma costa tempo e token a ogni richiesta. OpenAI ha reso disponibile in generale la Decisions API, pensata proprio per questo tipo di scelte.

## Una decisione non è una conversazione

Nel lavoro quotidiano di un sistemista o di uno sviluppatore, moltissime scelte sono in realtà selezioni tra un insieme chiuso di opzioni: classificare un ticket, instradare una richiesta, valutare il rischio di un'operazione, categorizzare una spesa. Per queste attività una risposta in linguaggio naturale è un ingombro: bisogna poi estrarre il valore, gestire i formati imprevisti e sperare che il modello non aggiunga testo superfluo.

La Decisions API inverte l'approccio. Lo sviluppatore definisce la domanda e l'elenco delle risposte ammesse, poi fornisce il contesto, che può essere testo, immagini o JSON strutturato. La risposta ha uno di tre formati: una probabilità che una condizione sia vera (predicate), una scelta tra le opzioni con la relativa confidenza (choice), oppure un punteggio calcolato su una rubrica (score). Secondo OpenAI, l'endpoint dedicato usa un modello più piccolo e costa e risponde meno di una chiamata standard via Responses API, fino a dieci volte più velocemente (dichiarato dall'azienda).

## Dove ha senso in un progetto reale

Immagina l'helpdesk interno di una PMI con trecento ticket al giorno. Oggi il sistema li manda tutti a un'unica coda e una persona li smista a mano, con ritardi nelle ore di punta. Un'impostazione tipica con la Decisions API prevede una scelta tra sei categorie (rete, account, stampanti, gestionale, fatturazione, altro) e una soglia di confidenza: sopra la soglia il ticket viene instradato automaticamente, sotto la soglia finisce a una persona. Il vantaggio non è solo la velocità, ma il fatto che il sistema sa quando non sa.

Lo stesso schema vale per gli agenti. Prima di eseguire un comando che modifica dati di produzione, un controllo di tipo predicate può stimare la probabilità che l'azione sia distruttiva, e bloccare o richiedere conferma sopra una certa soglia. Non sostituisce le policy di accesso, ma aggiunge un livello di controllo che costa pochi millesimi di dollaro per chiamata.

Un terzo caso ricorrente è la categorizzazione di flussi ad alto volume, come le spese aziendali o le richieste commerciali in ingresso. Qui il valore sta nella coerenza: la stessa etichetta applicata sempre con gli stessi criteri, senza la variabilità di un prompt riscritto ogni volta.

## Costi, limiti e cosa misurare

Il prezzo dichiarato è di 0,10 dollari per milione di token di input, con tariffa ridotta per i token in cache e nessun costo per l'output. Il numero di domande per richiesta arriva fino a 400. Sono dati da verificare sulla pagina prezzi aggiornata, perché le tariffe cambiano.

Attenzione però alle cifre di velocità che circolano nell'annuncio. Sono risultati riportati da clienti in contesti specifici: Speak ha dichiarato che il tempo alla prossima azione è sceso da 1,4 secondi a 0,13 nei propri test con GPT-Live, Box una selezione del percorso circa cinque volte più rapida su trenta casi di certificati assicurativi. Sono indicazioni di partenza, non garanzie: i numeri che contano sono quelli del vostro dataset.

Due aspetti vanno valutati prima di adottarla. Il primo è la residenza dei dati: l'elaborazione regionale è disponibile in US e UE, e OpenAI parla di Zero Data Retention per i clienti idonei. Se nei ticket ci sono dati personali, la verifica con il DPO o con il legale è un passaggio obbligatorio. Il secondo è il perimetro: l'API è costruita per decidere, non per spiegare. Se il processo richiede una motivazione scritta per ogni scelta, serve comunque un modello generativo accanto.

## Come provarla in una settimana

Il metodo più affidabile è partire da dati storici. Raccogliete circa duecento casi già etichettati dalle persone del team, scrivete la domanda in modo non ambiguo e definite le risposte in modo che si escludano a vicenda. Ambiguità nella domanda producono probabilità basse ovunque, e un falso senso di incertezza.

Poi confrontate accuratezza e costo con la soluzione attuale. La soglia di confidenza va scelta sui dati, non a intuito: calcolate quanti casi automatici sbagliati siete disposti ad accettare e fissate la soglia di conseguenza. Infine lanciate un test in shadow mode per due settimane, con l'API che decide in parallelo ma senza effetti sul processo reale, e controllate periodicamente che l'accuratezza non degradi quando cambiano i tipi di richiesta.

## In pratica

1. Individua un processo manuale che produce una scelta tra poche opzioni e misuralo: quanti casi al giorno, quanto tempo richiede ciascuno, quanti errori emergono a valle.
2. Prepara un dataset di circa duecento casi etichettati e decidi in anticipo la soglia sotto la quale il caso va a una persona, prima di vedere i risultati.
3. Avvia un test in shadow mode di due settimane e confronta le decisioni dell'API con quelle reali, annotando soprattutto i falsi positivi che costano di più.

Se state valutando un caso simile in azienda, scrivete nei commenti quale processo vorreste automatizzare: è da lì che nascono i test più utili. Se l'articolo vi è stato utile, condividetelo con il collega che gestisce i ticket e iscrivetevi per ricevere i prossimi approfondimenti.

Fonte: OpenAI, «Build more responsive apps with the Decisions API», 22 ottobre 2026, https://openai.com/index/decisions-api