Decision Desk | Developer Docs

El Decision Desk (/approvals-inbox) es donde las personas toman las decisiones que las máquinas no deberían tomar por sí solas. Cuando el motor de políticas de KLA devuelve una decisión require_approval, la acción del agente no continúa. La ejecución se pausa y KLA abre una Escalation, un objeto de intervención manual que incluye todo lo que un revisor necesita para actuar. El elemento de trabajo que el revisor finalmente resuelve es una Decision Request. El Decision Desk es la cola, la superficie de revisión y el registro de auditoría de cada uno de estos momentos.

Esto importa porque require_approval es uno de los cuatro resultados de política de KLA, en orden de precedencia: allow, warn, require_approval, block. Los dos primeros permiten que el trabajo continúe; block lo detiene por completo. Solo require_approval entrega la decisión a una persona, y el Decision Desk es donde se sitúa esa persona.

ℹ️ Note

El Decision Desk no crea las reglas; estas viven en **Policy Builder**. Es el destino en tiempo de ejecución para las acciones que una política dirigió deliberadamente a las personas en lugar de resolverlas automáticamente.

Cómo llega una Escalation al Decision Desk

flowchart LR
  A["Acción del agente"] --> B{"Decisión de política"}
  B -->|allow / warn| C["Continuar"]
  B -->|block| D["Detener"]
  B -->|require_approval| E["Abrir Escalation"]
  E --> F["Cola del Decision Desk"]
  F --> G{"El revisor actúa"}
  G -->|approve| H["Reanudar ejecución"]
  G -->|deny| I["Terminar la ejecución"]
  G -->|re-route| J["Revisor sénior"]
  J --> G

La ejecución del agente queda retenida, no fallida, mientras la Escalation espera. El agente instrumentado (mediante el Govern in Place SDK) o el proxy gestionado (Run through KLA) se bloquea ante la decisión pendiente, de modo que no se produce ningún efecto colateral hasta que una persona la resuelve.

Trabajar la cola

La bandeja de entrada está diseñada para el triaje a gran volumen. Los revisores filtran y ordenan según cuatro dimensiones:

Dimensión	Qué hace
Prioridad	Hace aflorar las Escalations críticas por delante de las revisiones rutinarias cercanas a `warn`.
Equipo	Dirige los elementos a la cola correcta (triaje de reclamaciones, aprobación de reembolsos, revisión de documentos) para que finanzas nunca vea el trabajo de legal.
Agente	Aísla cada acción pendiente de un único agente, lo cual resulta útil cuando un agente se comporta de forma inesperada.
Estado	Separa las Decision Requests abiertas del historial resuelto, para auditoría y análisis de tendencias.

Las reglas de enrutamiento se declaran en la política, de modo que una Escalation llega por defecto al equipo responsable de ese riesgo, en lugar de a un montón compartido.

Revisar una Decision Request

Abrir un elemento ofrece a los revisores todo el contexto detrás de la acción pausada, sin cambiar de herramienta y sin tener que adivinar:

Prompt e instrucciones: la entrada que motivó la acción, incluidas genai.system.instructions, para que el revisor vea qué se le indicó hacer al agente.
Payload de la herramienta: el genai.tool.name y los genai.tool.parameters exactos que el agente pretendía invocar (el importe del reembolso, el registro que se va a escribir, el documento que se va a enviar).
Regla desencadenante: la política concreta que devolvió require_approval, con sus reason codes, para que la decisión se fundamente en un control con nombre y no en una corazonada.
Enlace de linaje: un salto directo a Lineage Explorer para reproducir el Lineage Record completo que condujo a este paso.

A partir de aquí, el revisor toma una de tres acciones:

Aprobar: libera la retención; el agente se reanuda exactamente donde se pausó.
Denegar: termina la ejecución; la acción nunca se ejecuta.
Redirigir / escalar: entrega la Decision Request a un revisor más sénior o a otro equipo sin perder el contexto.

El SLA y la perspectiva de auditoría

Cada Decision Request lleva consigo información de tiempo. Los revisores ven cuánto tiempo ha esperado un elemento, y las Escalations vencidas afloran frente a su objetivo de nivel de servicio para que nada se pudra en la cola. Ese registro temporal forma parte del expediente, no es solo una comodidad operativa.

🛡️ Important

Cada decisión es evidencia. Cada aprobación, denegación y redirección se captura como un span de OpenTelemetry, se redacta mediante el KLA Collector y se escribe en el libro mayor criptográfico de ImmuDB. El revisor, la acción, la regla desencadenante y la marca de tiempo fluyen todos hacia los **Sealed Evidence Bundles** y los **Control Packs**.

El resultado es una respuesta defendible a la pregunta más difícil del auditor, quién aprobó esto, sobre qué base y cuándo, sin que nadie tenga que reconstruirla a posteriori. El criterio humano se convierte en una parte de primera clase del registro de gobernanza, a prueba de manipulaciones.

💡 Tip

Combine el Decision Desk con el **Assurance Center**. Una tasa creciente de Escalations `require_approval` en un mismo agente suele ser una **Assurance Alert** temprana, una señal para revisar la política o el agente antes de que los revisores se vean desbordados.