Decision Desk | Developer Docs

Il Decision Desk (/approvals-inbox) è il luogo in cui le persone prendono le decisioni che le macchine non dovrebbero prendere da sole. Quando il KLA policy engine restituisce una decisione require_approval, l'azione dell'agente non procede. L'esecuzione viene messa in pausa e KLA apre un'Escalation, un oggetto di intervento manuale che racchiude tutto ciò che serve a un revisore per agire. L'elemento di lavoro che il revisore risolve in ultima istanza è una Decision Request. Il Decision Desk è la coda, la superficie di revisione e il registro di audit per ognuno di questi momenti.

Tutto questo conta perché require_approval è uno dei quattro esiti di policy di KLA, in ordine di precedenza: allow, warn, require_approval, block. I primi due lasciano proseguire il lavoro; block lo arresta del tutto. Solo require_approval affida la decisione a una persona, e il Decision Desk è il punto in cui quella persona opera.

ℹ️ Note

Il Decision Desk non crea le regole: quelle risiedono in **Policy Builder**. È la destinazione a runtime per le azioni che una policy ha deliberatamente instradato verso le persone invece di risolverle automaticamente.

Come un'Escalation arriva al desk

flowchart LR
  A["Azione dell'agente"] --> B{"Decisione di policy"}
  B -->|allow / warn| C["Continua"]
  B -->|block| D["Arresta"]
  B -->|require_approval| E["Apri Escalation"]
  E --> F["Coda del Decision Desk"]
  F --> G{"Il revisore agisce"}
  G -->|approve| H["Riprendi l'esecuzione"]
  G -->|deny| I["Termina l'esecuzione"]
  G -->|re-route| J["Revisore senior"]
  J --> G

L'esecuzione dell'agente viene trattenuta, non fatta fallire, mentre l'Escalation resta in attesa. L'agente strumentato (tramite il Govern in Place SDK) o il proxy gestito (Run through KLA) si blocca sulla decisione in sospeso, così nessun effetto collaterale si verifica finché una persona non la risolve.

Lavorare la coda

La casella è pensata per il triage ad alto volume. I revisori filtrano e ordinano lungo quattro dimensioni:

Dimensione	Cosa fa
Priorità	Porta in primo piano le Escalation critiche prima delle revisioni di routine prossime al `warn`.
Team	Instrada gli elementi alla coda corretta (triage dei sinistri, approvazione dei rimborsi, revisione dei documenti) così che il team della finanza non veda mai il lavoro di quello legale.
Agente	Isola ogni azione in sospeso proveniente da un singolo agente, utile quando un agente si comporta in modo inatteso.
Stato	Separa le Decision Request aperte dallo storico risolto, per finalità di audit e analisi delle tendenze.

Le regole di instradamento sono dichiarate nella policy, così per impostazione predefinita un'Escalation finisce davanti al team che possiede quel rischio anziché in un mucchio condiviso.

Revisionare una Decision Request

Aprire un elemento fornisce ai revisori il contesto completo dietro l'azione messa in pausa, senza cambiare strumento e senza dover indovinare:

Prompt e istruzioni: l'input che ha guidato l'azione, incluse le genai.system.instructions, così il revisore vede cosa era stato chiesto all'agente di fare.
Payload dello strumento: l'esatto genai.tool.name e i genai.tool.parameters che l'agente intendeva invocare (l'importo del rimborso, il record da scrivere, il documento da inviare).
Regola scatenante: la specifica policy che ha restituito require_approval, con i relativi reason code, così la decisione si fonda su un controllo nominato e non su un'intuizione.
Collegamento alla lineage: un salto diretto in Lineage Explorer per riprodurre l'intero Lineage Record che ha portato a questo passaggio.

Da qui il revisore compie una di tre azioni:

Approve: rilascia il blocco; l'agente riprende esattamente da dove si era fermato.
Deny: termina l'esecuzione; l'azione non viene mai eseguita.
Re-route / escalate: passa la Decision Request a un revisore più senior o a un altro team senza perdere il contesto.

SLA e la prospettiva di audit

Ogni Decision Request porta con sé informazioni temporali. I revisori vedono da quanto tempo un elemento è in attesa, e le Escalation scadute emergono rispetto al loro obiettivo di livello di servizio così che nulla marcisca in coda. Quei tempi fanno parte del record, non sono solo una comodità operativa.

🛡️ Important

Ogni decisione è una prova. Ogni approve, deny e re-route viene catturato come span OpenTelemetry, redatto dal KLA Collector e scritto nel ledger crittografico ImmuDB. Il revisore, l'azione, la regola scatenante e il timestamp confluiscono tutti nei **Sealed Evidence Bundles** e nei **Control Packs**.

Il risultato è una risposta difendibile alla domanda più difficile dell'auditor, chi ha approvato questo, su quale base e quando, senza che nessuno debba ricostruirla a posteriori. Il giudizio umano diventa una parte di prima classe e a prova di manomissione del record di governance.

💡 Tip

Abbina il Decision Desk all'**Assurance Center**. Un tasso crescente di Escalation `require_approval` su un singolo agente è spesso un precoce **Assurance Alert**, un segnale per rivedere la policy o l'agente prima che i revisori vengano sommersi.