Una richiesta clienti classificata male non produce solo una risposta sbagliata: può finire al reparto errato, attivare un rimborso non dovuto o lasciare un’urgenza in coda. Il punto non è affidare l’intero processo a un modello più grande. È isolare la singola decisione ripetitiva, limitarne le risposte possibili e misurarla prima che possa modificare qualcosa.

La Decisions API, resa generalmente disponibile da OpenAI il 22 ottobre 2026, nasce per questo tipo di passaggio. Riceve testo, immagini o dati strutturati e restituisce una probabilità, una scelta oppure un punteggio. Per una PMI può diventare un componente di routing veloce; non è però un sostituto delle regole deterministiche, delle autorizzazioni o della revisione umana.

La mia tesi è semplice: una decision API ha valore quando restringe l’ambiguità in un punto preciso del workflow. Se le si chiede di capire l’intero processo, si ricrea lo stesso problema di un agente generico, aggiungendo soltanto un altro endpoint.

Che cosa cambia rispetto a un prompt libero

Con una normale chiamata a un modello linguistico, l’applicazione chiede una risposta aperta e poi deve interpretarla. Anche quando si usa un output strutturato, il modello può produrre spiegazioni, campi accessori o una classificazione che l’applicazione non aveva previsto. Una decisione delimitata inverte il contratto: prima si stabiliscono le domande e l’insieme delle risposte ammesse, poi si fornisce il contesto necessario.

La documentazione della Decisions API definisce tre tipi di domanda:

  • predicate stima la probabilità che una condizione sia vera, per esempio che una foto mostri un prodotto danneggiato;
  • choice seleziona un valore tra opzioni definite dall’applicazione, come vendite, supporto, amministrazione o revisione;
  • score valuta l’input su livelli ordinati di una rubrica, per esempio la severità di un incidente.

La differenza operativa non è cosmetica. Il software non deve estrarre una decisione da una frase: riceve un risultato previsto dal contratto e può applicare una soglia esplicita. Resta comunque necessario gestire rifiuti, errori di rete e casi fuori distribuzione. “Output strutturato” non significa “output corretto”.

OpenAI dichiara che il servizio, basato su GPT‑6 Luna, può essere fino a dieci volte più veloce dello stesso modello usato tramite Responses API. Il dato descrive l’implementazione del fornitore, non una garanzia per ogni applicazione. Va verificato sul proprio traffico, includendo rete, serializzazione, code e chiamate ai sistemi a valle.

Il caso PMI: smistare richieste senza automatizzare il giudizio

Prendiamo un’azienda che riceve richieste da modulo WordPress, email e area clienti. Oggi una persona legge l’oggetto, apre il CRM e assegna ogni pratica. L’automazione utile non consiste nel far rispondere l’AI al cliente. Consiste nel proporre una destinazione e decidere quando la proposta è abbastanza affidabile per essere applicata.

Un primo contratto può avere quattro scelte: commerciale, supporto, amministrazione e revisione_umana. L’input dovrebbe contenere soltanto i dati necessari: oggetto, testo ripulito, tipo di cliente, prodotto e stato del contratto. Non servono l’intera cronologia del CRM, documenti non pertinenti o dati personali raccolti “nel dubbio”.

Il flusso diventa così:

  1. WordPress o il gestionale valida e normalizza la richiesta;
  2. le regole certe intercettano casi banali, blocchi e consensi mancanti;
  3. la Decisions API propone una categoria con le probabilità associate;
  4. l’applicazione confronta il risultato con soglie definite sui test;
  5. i casi ambigui vanno in una coda umana, non nella categoria più probabile per forza;
  6. l’esito corretto viene registrato per aggiornare il set di valutazione.

Questa architettura mantiene l’AI fuori dal punto in cui si concedono permessi o si eseguono azioni irreversibili. È lo stesso principio che ho descritto parlando di controllo ed evaluator nei workflow AI: il modello propone, mentre il sistema applica regole, autorizzazioni e fallback.

Un payload minimo e un fallback esplicito

L’endpoint dedicato è POST /v1/decisions. Un payload concettuale per lo smistamento può essere ridotto a pochi campi:

{
  "model": "gpt-6-luna",
  "input": {
    "oggetto": "Doppio addebito fattura 1842",
    "messaggio": "Vedo due movimenti dello stesso importo",
    "cliente_attivo": true
  },
  "questions": [{
    "type": "choice",
    "name": "destinazione",
    "instructions": "Scegli il reparto che deve verificare la richiesta.",
    "choices": [
      {"value": "commerciale"},
      {"value": "supporto"},
      {"value": "amministrazione"},
      {"value": "revisione_umana"}
    ]
  }]
}

Il valore importante non è la sintassi: è il comportamento dell’applicazione dopo la risposta. Se il servizio non risponde entro il budget di latenza, il ticket deve comunque essere salvato. Se la scelta è inattesa, manca un campo o la fiducia non supera la soglia validata, il percorso deve convergere su revisione_umana. Non si ritenta all’infinito e non si trasforma un’incertezza in un’azione.

La documentazione indica che una richiesta può contenere fino a 400 domande, il doppio rispetto alla beta pubblica. Questo limite permette di valutare più aspetti sullo stesso contesto, ma non è un obiettivo progettuale. Per una PMI partirei da una domanda per workflow. Raggruppare centinaia di controlli rende più difficile capire quale istruzione, dato o modifica del modello abbia causato una regressione.

Anche il caching va trattato come ottimizzazione successiva. OpenAI offre prompt caching per il contesto riutilizzato, ma prima bisogna rendere stabile il contratto, misurare l’accuratezza e osservare gli errori. Ridurre il costo di una decisione sbagliata non la rende più utile.

Come misurare una soglia senza inventarla

Una soglia del 70%, 80% o 95% non ha significato universale. Deve derivare dagli errori che l’azienda può tollerare. Smistare una richiesta commerciale nel reparto supporto ha un costo diverso dal classificare come sicuro un comando generato da un agente.

Serve un set di casi reali già risolti. Per un primo test operativo raccoglierei almeno alcune decine di esempi per ogni classe frequente, separando i casi usati per scrivere le istruzioni da quelli usati per valutarle. Ogni esempio deve avere un esito corretto stabilito da chi conosce il processo, non prodotto da un altro modello senza verifica.

Le metriche minime sono quattro:

  • accuratezza per classe, perché una media può nascondere una categoria debole;
  • tasso di invio a revisione, che misura il carico umano residuo;
  • falsi automatismi, cioè casi applicati automaticamente ma corretti in seguito;
  • latenza p50 e p95 end-to-end, misurata dal sistema chiamante e non soltanto dall’API.

La soglia va scelta confrontando due costi: quante pratiche restano manuali e quanti errori entrano nel processo. In shadow mode il modello produce la decisione, ma il routing reale continua a essere quello umano. Dopo due o quattro settimane si può confrontare il risultato senza aver esposto clienti e reparti a un’automazione non calibrata.

I benchmark pubblicati da OpenAI mostrano perché vale la pena fare il test, non quale risultato aspettarsi. Nella pagina di lancio Box riferisce una selezione del percorso circa cinque volte più rapida su 30 casi di certificati assicurativi, con la stessa accuratezza della Responses API. Sierra dichiara meno di 280 millisecondi al p95 nel proprio scenario. Sono misure di clienti su casi specifici: non sostituiscono un benchmark interno.

Costi, dati e sicurezza da decidere prima

Al lancio, OpenAI indica un prezzo di 0,10 dollari per milione di token in input e 0,01 dollari per milione di token cached, senza addebito per token di output. Il costo unitario rende plausibile inserire una decisione in passaggi frequenti, ma il budget deve includere osservabilità, revisioni umane, test e manutenzione. La chiamata è spesso la parte meno costosa del sistema.

Per i dati, la tabella ufficiale sui controlli della piattaforma indica che /v1/decisions non usa i dati per l’addestramento, prevede di default log di abuse monitoring conservati fino a 30 giorni e può essere idoneo allo Zero Data Retention per clienti approvati. OpenAI segnala inoltre disponibilità di elaborazione regionale negli Stati Uniti e nell’Unione europea. Prima del go-live bisogna verificare configurazione effettiva dell’account, contratto e requisiti del titolare del trattamento: leggere “EU” in una pagina prodotto non sostituisce una valutazione privacy.

Tre controlli non vanno delegati al modello:

  • autenticazione e autorizzazione devono avvenire nel software, prima di costruire l’input;
  • i dati vanno minimizzati e mascherati quando l’identità non serve alla decisione;
  • azioni irreversibili, pagamenti, cancellazioni e modifiche dei permessi richiedono regole più forti o approvazione umana.

Per gli agenti vale anche un limite economico. Una decisione che autorizza una chiamata esterna non deve poter aggirare budget e policy. Il circuito pratico combina una valutazione probabilistica con i limiti su chiavi API, permessi e spesa.

Un piano di adozione in dieci giorni

Giorni 1-2: scegliere una sola decisione. Deve essere frequente, delimitata e reversibile. Scrivere le opzioni ammesse, il proprietario del processo e il danno massimo di un errore. Se due persone esperte non concordano sull’esito corretto, il problema non è ancora pronto per l’automazione.

Giorni 3-4: costruire il set di valutazione. Estrarre casi storici, rimuovere dati non necessari e assegnare un’etichetta verificata. Conservare anche esempi ambigui, input vuoti, lingue diverse, allegati mancanti e tentativi di manipolare le istruzioni.

Giorni 5-6: integrare senza effetti. Chiamare l’API in shadow mode, registrando versione delle istruzioni, hash dell’input, risposta, latenza ed esito umano. Non salvare nei log il contenuto completo se non è necessario.

Giorni 7-8: calibrare soglie e fallback. Analizzare errori per classe. Le decisioni sopra soglia possono essere candidate all’automazione; le altre devono convergere sulla coda umana. Impostare timeout, circuit breaker e un limite di spesa per progetto.

Giorni 9-10: attivare un perimetro ristretto. Automatizzare una percentuale limitata dei casi a basso rischio, mantenendo un campione revisionato. Preparare un interruttore per disabilitare la funzione senza fermare il modulo WordPress, il CRM o l’assistenza.

La decisione finale non è “usare o non usare l’AI”. È stabilire dove una classificazione probabilistica migliora il flusso e dove serve ancora una regola certa. La Decisions API è interessante proprio quando resta piccola: una domanda delimitata, risposte note, soglie misurate e una via d’uscita umana. Se questi quattro elementi non stanno in una pagina, il workflow va semplificato prima di collegare l’endpoint.

Fonti