Una richiesta classificata male può aprire un ticket inutile, inviare una pratica al reparto sbagliato o far partire un’automazione che nessuno voleva. Il problema non è chiedere all’AI di “capire meglio”: è trasformare una risposta probabilistica in una decisione controllabile. Con Gemini Decisions API si può costruire un gate per il workflow AI che restituisce opzioni definite e un livello di confidenza, lasciando al codice — e non al testo generato — la scelta tra azione automatica e revisione umana.

Quando una risposta generativa è troppo

Molti workflow usano un modello generativo anche quando serve soltanto una scelta chiusa: approvare o bloccare, assegnare una categoria, stimare una priorità. Il risultato arriva come testo, quindi bisogna interpretarlo, gestire variazioni lessicali e sperare che il formato rimanga stabile. La documentazione ufficiale della Decisions API propone invece tre tipi di domanda: noul per sì/no, choice per scegliere tra opzioni fisse e score per applicare una scala ordinata. Ogni risposta include una probabilità o una distribuzione tra le opzioni, più un valore di confidence. Per una PMI significa poter descrivere una regola verificabile: il sistema non “scrive cosa fare”, ma valuta alternative già ammesse. Questa distinzione riduce il parsing fragile e rende visibile il punto in cui l’automazione deve fermarsi. Non sostituisce le regole aziendali: le rende eseguibili.

Costruisci tre uscite, non un prompt

Parti da un caso ristretto, per esempio lo smistamento delle richieste ricevute da un form WordPress. Definisci prima le uscite che esistono davvero nel processo, come commerciale, assistenza, amministrazione e revisione_umana. Poi descrivi per ogni opzione i segnali che la rendono corretta. La domanda deve essere atomica: “Quale reparto deve gestire questa richiesta?” è più controllabile di “Analizza il messaggio e dimmi cosa dovremmo fare”. Aggiungi un controllo separato per verificare se il contenuto rientra nel perimetro accettato. Google indica che le domande sono valutate in modo isolato sullo stesso input; le dipendenze vanno quindi composte nel codice con normali condizioni. Il flusso essenziale è questo:

  • normalizza i dati del form e rimuovi ciò che non serve;
  • chiedi una scelta tra categorie definite;
  • leggi categoria e confidenza;
  • inoltra i casi incerti alla coda umana.

La soglia decide chi può agire

Non copiare una soglia da un esempio online e non trattare confidence come una garanzia. Raccogli un campione di richieste già classificate da una persona, esegui il nuovo controllo senza attivare azioni e confronta le risposte con l’esito corretto. La documentazione raccomanda di impostare le soglie su esempi etichettati del proprio traffico e di pesare il costo dei falsi positivi rispetto ai falsi negativi. In pratica, un errore che invia una richiesta commerciale all’assistenza può essere recuperabile; un errore che approva un rimborso o pubblica un contenuto richiede una soglia più prudente e un secondo controllo. Conserva input minimizzato, decisione, confidenza, versione delle istruzioni ed esito umano. Dopo un periodo di prova puoi automatizzare soltanto la fascia ad alta affidabilità, mantenere una fascia intermedia in revisione e respingere i casi chiaramente fuori perimetro. È questo registro, non il nome del modello, a rendere il workflow governabile.

L’errore da evitare è nascondere l’incertezza

La scorciatoia pericolosa è prendere sempre l’opzione con probabilità maggiore. Una domanda di tipo choice distribuisce comunque la probabilità tra le alternative disponibili, anche quando nessuna descrive bene il caso. Per questo serve un’uscita esplicita come “altro” o “revisione umana”, accompagnata da un controllo di perimetro e da una soglia. Evita anche di collegare subito la decisione a operazioni irreversibili: nella prima fase mantieni l’agente in un perimetro controllato e scrivi il risultato in un log o in una coda, senza inviare email, modificare ordini o pubblicare contenuti. Il take finale è semplice: usa l’AI per restringere la scelta, ma lascia al codice la regola e a una persona l’eccezione. La Decisions API può rendere questo schema più diretto perché restituisce valori tipizzati invece di prosa; la qualità operativa dipende però dalle categorie, dai test e dal fallback che progetti prima di accendere l’automazione.