LLM Decisionali: quando il modello deve decidere — e quando no

Chiedi ai praticanti cosa va storto nei sistemi di agenti e la risposta raramente riguarda le capacità. Il guasto è più sottile: il modello decide, e nessuno riesce a distinguere ciò che è corretto da ciò che è solo fluente.

L’output di un modello è un campione. Una decisione ha proprietà che un campione non possiede: la determinatezza per un input fisso, gli invarianti che deve soddisfare e una traccia di audit che spieghi perché si è scelto questo e non l’alternativa. Quando queste proprietà mancano, la “decisione” non è altro che un’ipotesi ad alta confidenza vestita con i panni di una vera decisione.

Questo articolo offre un trattamento meccanico per questo divario: una tassonomia di cinque ruoli decisionali, una regola per instradare ogni decisione al modello più piccolo competente per gestirla e la meccanicistica di verifica che trasforma “l’agente ha deciso X” in qualcosa che in seguito puoi provare essere stato corretto. Si conclude con una griglia che puoi applicare a qualsiasi azione nel tuo sistema.

“Per gli agenti locali, il divario che continuo a incontrare non è la capacità, ma la verifica. L’agente afferma di aver letto un file, chiamato uno strumento o preso una decisione…” — r/LocalLLaMA, “Best Local Agents — Jun 2026”

“Quando un agente LLM fallisce, è una scatola nera e nessuno sa perché. Il vero collo di bottiglia per l’adozione non è portare un modello da una precisione del 92% al 96% — [è sapere perché ha deciso X].” — r/AI_Agents, “The gap between decision and execution”

La comunità è converata su tre istinti: non fidare al modello della chiamata finale, instradare la decisione al modello più piccolo competente e rendere la decisione spiegabile. Ciò che mancava era il quadro che rendesse azionabili contemporaneamente tutti e tre gli elementi.

Perché “risponde, ma decide?”

L’output di un modello è una distribuzione di token collassata in una singola sequenza, e la stessa prompt eseguita due volte può produrre due sequenze che divergono esattamente sul token che conta. Una decisione, al contrario, è determinata per un input fisso, soddisfa invarianti espliciti e lascia una traccia di audit che registra quale ramo è stato preso e perché.

Quando un modello “decide” senza meccanicistica intorno, nessuna di queste proprietà esiste. Non esiste un invariante che l’output sia obbligato a rispettare, né un registro del ramo preso, né un modo per riprodurre la decisione e verificare che si sia mantenuta. Il divario non è l’intelligenza — è il fatto che un output probabilistico sia stato posto in uno slot progettato per uno deterministico.

L’istinto del praticante è di tenere il modello completamente fuori dalla decisione:

“L’LLM non prende mai decisioni finali nel sistema. Il suo ruolo è puramente: raffinamento della logica, stress test, generazione di scenari, spiegazione.” — r/AI_Agents, “Using an LLM as a ‘reasoning agent’ for validating price…”

Questa è la postura corretta esposta come massima. Per applicarla, serve un modo per classificare quale ruolo il modello debba svolgere per una data azione — ed è proprio ciò che fornisce la tassonomia seguente.

I cinque ruoli decisionali

Ogni decisione che un sistema compie può essere assegnata a uno di cinque ruoli. Il ruolo determina quanto si possa fidare dell’output del modello, come venga auditato, come fallisca e se un umano debba essere nel loop.

Leggi la tabella come un vincolo, non come un menu. La maggior parte dei sistemi rotti condivide un difetto: un singolo modello ricopre tutti e cinque i ruoli simultaneamente, quindi un ruolo che richiede determinatezza (decidente) viene servito da un componente ottimizzato per la fluidità (generatore). Laddove il modello agisce come generatore, nessuna delle meccanicistiche decisionali è necessaria — lo è la revisione del contenuto. Il guasto da evitare è la confusione tra questi: “l’agente ha deciso di cancellare l’ambiente” è di solito una porta di approvazione mancante, non un problema di qualità decisionale.

Instrada la decisione al modello più piccolo competente

Una volta fissato il ruolo, la domanda di instradamento è quale tier di modelli lo serva. I praticanti riportano direttamente il vantaggio:

“Instradamento modelli: Haiku per decisioni di classificazione/instradamento, Sonnet per esecuzione, Opus solo per design/pianificazione. Il costo è sceso di circa il 60% non appena ho smesso di usare Opus per tutto.” — r/AI_Agents, “What is your full AI Agent stack in 2026”

Questo numero deriva dal trattare la selezione del modello come una decisione per ruolo invece che per sistema. Una chiamata di instradamento — “questa è una triage delle email o un’approvazione di un rimborso?” — è una classificazione, e la classificazione non ha bisogno di un modello di frontiera; ha bisogno di un modello piccolo, veloce e a bassa temperatura, perché viene eseguito migliaia di volte. Le meccaniche del tier — selezione basata sulla capacità, consapevole del costo e della latenza, più le catene di fallback — sono coperte in Model Routing: Smetti di usare un modello per tutto; i pattern di orchestrazione attorno a più modelli sono in Multi-Model System Design.

L’aggiunta che la cornice decisionale contribuisce è l’escalation basata sulla confidenza, che rende “il più piccolo competente” misurato anziché assunto. Inizia sul tier più piccolo. Se il modello emette una confidenza calibrata — o un autovalutazione strutturata — e supera una soglia, fermati. Se non lo fa, escala di un tier e registra l’escalation. La competenza diventa allora una proprietà verificata per chiamata, non una proprietà assunta per modello.

Un vincolo rimane assoluto indipendentemente dal tier: il ruolo di router stesso non deve essere una chiamata libera a un modello linguistico. Una spina dorsale deterministica — regole sul tipo di task, dimensione del payload, budget di costo — seleziona il ramo, e il modello riempie solo le decisioni foglia al suo interno. La spina dorsale è auditabile e testabile a unità; il modello è contenuto in ciò per cui è effettivamente bravo.

Rendere la decisione verificabile

Qui si chiude il divario di “l’agente dice di aver fatto X”. La correzione è rendere la decisione un artefatto strutturato di primo livello anziché un effetto collaterale di un turno di chat:

1. Un negozio di decisioni strutturato. Ogni decisione che il modello è autorizzato a prendere viene scritta in una tabella, non in una riga di log: l’input, il ruolo, il modello e il tier, la confidenza, le alternative considerate, il timestamp. Una decisione è qualcosa che puoi SELECT in seguito. Se vive solo in una trascrizione di conversazione, è un’ipotesi.
2. Un registro delle decisioni, separato dal registro di esecuzione. Il registro di esecuzione dice cosa è successo; il registro delle decisioni dice cosa è stato deciso e su quali basi. La separazione è importante perché il guasto è di solito nella decisione, non nell’esecuzione — l’agente ha eseguito la cancellazione perfettamente; il bug era decidere di cancellare. Le meccaniche di logging strutturato e solo-append sono le stesse usate per le tracce di audit di conformità in Guardrail LLM in Pratica.
3. Invarianti e asserzioni. Per i ruoli di decidente e valutatore, la decisione deve soddisfare invarianti controllati dopo che il modello li ha emessi, in codice deterministico. Un consiglio sui prezzi può emettere qualsiasi cosa; l’invariante “il prezzo raccomandato deve essere compreso tra [pavimento, soffitto]” è applicato dal codice. Il modello propone; l’invariante dispone.
4. Porte di approvazione umana al confine dell’irreversibilità. La porta è una proprietà del raggio d’azione dell’azione, non della confidenza del modello. Un rimborso sotto una soglia è auto-approvabile; uno sopra di essa non lo è. Un modello con confidenza al 99% non può comunque approvare un’azione irreversibile per cui non ha un record di audit.

Il filo conduttore: la spinta per la precisione dal 92% al 96% non è il collo di bottiglia — lo è la spiegabilità. Un sistema al 92% con ogni decisione registrata, verificata tramite invarianti e gestita al confine viene consegnato in sicurezza, perché l'8% di decisioni sbagliate è rintracciabile prima di causare danni. Un sistema al 99% con un processo decisionale in scatola nera non lo è, perché l'1% è un incidente attivo senza record forense. Dove la porta stessa risieda in un assistente — quale componente detenga l’autorità di approvazione e come le richieste la raggiungano — è delineato in Architettura Assistente AI: LLM, Memoria, Strumenti, Instradamento, Osservabilità.

Esempi pratici

Tre sistemi, un’assegnazione di ruolo ciascuno.

Validazione prezzi — il modello come consigliere, mai decidente. Un agente rivede una modifica dei prezzi di un fornitore e produce una lista classificata: accettare, negoziare a X, rifiutare. La chiamata finale è uno slot di decidente riempito da regole deterministiche: sotto il pavimento dei costi, auto-accettazione; sopra il soffitto, instradamento a un umano; in mezzo, applicare l’invariante “il prezzo negoziato deve battere l’ultimo accettato di Y%.” Il modello non approva mai il proprio consiglio, e il consiglio risiede nel negozio di decisioni con la sua traccia della griglia se va storto.

Instradamento task agent — la spina dorsale come decidente, il modello alle foglie. Una richiesta in entrata (email, ticket, comando) viene assegnata a un percorso dalla forma del payload e dalla categoria di intento — deterministico, testabile a unità. Un modello piccolo riempie solo la decisione foglia all’interno del ramo. Un instradamento errato è un evento di raggio d’azione, ed è esattamente per questo che la selezione del ramo deve essere deterministica.

LLM come giudice — il modello come valutatore, la griglia come vincolo. Un modello punteggia l’output di un altro contro una griglia versionata, e il punteggio più la traccia della griglia vengono memorizzati, non solo il numero. La modalità di guasto nota è il bias di auto-preferenza — un modello che dà un punteggio più alto al proprio stile di generazione — e la mitigazione è strutturale: versionare la griglia in modo che un modello non stia mai silenziosamente punteggiando contro criteri che ha plasmato.

Il confine onesto

C’è una classe di decisioni che un LLM non deve prendere, e non è una questione di scala: azioni che sono irreversibili, ad alto rischio e senza fallback — cancellazione di dati, movimento di fondi, impegni esterni. La verifica è impossibile per un’azione che non puoi roll back, ed è per questo che “agente autonomo” continua a sbattere contro la stessa parete indipendentemente dalla qualità del modello.

L’umano-nel-loop che non è teatro sta esattamente a quel confine e da nessuna altra parte. Un umano che rivede ogni decisione a basso rischio aggiunge attrito e nessuna sicurezza; un umano assente da ogni decisione ad alto rischio è l’incidente. Lo stesso principio appare in forma più ristretta nella memoria degli agenti: i loop di memoria auto-rinforzanti pongono le scritture di memoria candidate dietro un’approvazione umana esplicita prima che qualsiasi cosa raggiunga lo stato durevole — la porta dimensionata su ciò che la scrittura può rompere. Per i sistemi multi-agente, la domanda corrispondente è chi possa agire in nome di chi, e la meccanicistica di identità, delega e traccia di audit per questo è in Sicurezza Agent A2A e MCP.

La griglia delle decisioni

Applica questo a qualsiasi azione nel tuo sistema:

1. Classifica il ruolo. Decidente, consigliere, valutatore, generatore o router? Un ruolo non nominato è un bug — un modello in uno slot di decidente che indossa la confidenza di un generatore.
2. Scegli il tier per quel ruolo. Il più piccolo competente, con escalation basata sulla confidenza in modo che la competenza sia misurata per chiamata.
3. Definisci la verifica. Quali invarianti devono mantenersi? Cosa va nel negozio di decisioni? Qual è la traccia di audit? Un ruolo senza percorso di verifica è un decidente di default.
4. Imposta la porta umana dal raggio d’azione, non dalla confidenza. Irreversibile o ad alto rischio → gestita. Altrimenti → auto, con la decisione registrata in modo che sia rintracciabile.

La stessa disciplina, applicata a scelte ingegneristiche anziché ad azioni di runtime, è ciò che fanno i record delle decisioni — Record delle Decisioni per lo Sviluppo Guidato da AI cattura perché una scelta è stata fatta in modo che possa essere rivista in seguito; la griglia sopra fa lo stesso per le decisioni che un sistema in esecuzione compie.

Cosa sta arrivando: il decidente come prodotto

Il quadro predice la sua stessa comoditizzazione: una volta che “instrada la decisione al modello più piccolo competente” è diventato un pattern, il passo successivo è stata una classe di modelli che fa nient’altro che decidere. Quel passo è ora arrivato.

Fino a ottobre 2026, diversi vendor hanno rilasciato modelli costruiti su una ricetta condivisa — una spina dorsale Qwen congelata, un adattatore LoRA di rango 256 e una testa di schema congiunta — che emettono decisioni tipizzate in un singolo passaggio in avanti: una scelta da un insieme enumerato, un sì/no, o un punteggio, con probabilità calibrate e nessun testo libero. Non c’è una catena di pensiero di cui aspettare, perché non c’è generazione. La latenza riportata dai vendor si colloca tra circa 8 e 210 ms attraverso la classe — dalla variante più piccola (d1-3B, circa 8 ms) fino alla più grande (d3, circa 209 ms) — e le impronte sono territorio di GPU piccole: d1-3B a circa 1,67 GB, d3-flash a circa 6,6 GB a Q4_K_M. Anche il supporto si è mosso velocemente: llama.cpp ha integrato il supporto nativo per l’architettura per diversi di questi modelli entro circa due settimane dal rilascio.

Due conseguenze per il quadro sopra. Primo, la regola di instradamento ottiene un’espressione hardware che non aveva prima: il ruolo di decidente può essere servito da un modello piccolo dedicato invece che da una modalità prompt di un modello generale, il che rende la decisione del tier più piccolo competente parzialmente automatica — il tier esiste per il tuo tipo di decisione o non esiste. Secondo, nulla cambia riguardo alla verifica. Una decisione tipizzata in 8 ms ha ancora bisogno del negozio di decisioni, degli invarianti e della porta al confine dell’irreversibilità; ciò che la classe di modelli rimuove è il costo di generazione e la non-determinismo, non l’onere di audit. Decisioni più veloci moltiplicano il numero di record decisionali da auditare — il collo di bottiglia non è mai stata la velocità del modello, e non è nemmeno l’intelligenza del modello.

Le altre direzioni da tenere d’occhio sono più tranquille. La affidabilità delle chiamate agli strumenti per i modelli piccoli sta avvicinando la saturazione — il post-training sull’uso degli strumenti è il passo a più alto impatto meno costoso dello stack, il che sposta l’attenzione sulle righe superiori. Gli orizzonti di pianificazione affidabili continuano ad estendersi, il che rende il ruolo di decidente raggiungibile per task più lunghi e fa crescere l’onere di verifica con l’orizzonte. Entrambi alimentano la stessa conclusione: la risorsa scarsa nei sistemi di agenti sono decisioni che puoi successivamente provare essere state corrette, e tutto il resto sta rincorrendo quel punto.