Ejecución regida por políticas | Developer Docs

Cuando un agente de IA empresarial intenta realizar algo de relevancia (emitir un reembolso, enviar un documento para revisión, llamar a una API externa), KLA Control Plane evalúa esa acción frente a la política antes de que se ejecute. KLA Control Plane es una capa de seguridad en tiempo de ejecución, auditoría y gobierno para agentes de IA que gobierna en el lugar: instrumentas tus agentes existentes en lugar de reconstruirlos sobre una nueva plataforma. La ejecución regida por políticas es el mecanismo que decide, en tiempo real, si una acción procede, procede con una advertencia, se pausa para que intervenga una persona o se detiene. Esta página explica el modelo de decisión y cómo una acción pausada se convierte en una Escalation que se enruta al Decision Desk.

Los cuatro resultados de la decisión

Cada evaluación de política en KLA se resuelve en exactamente un resultado. Los resultados se ordenan por precedencia: cuando varias reglas coinciden con una acción, prevalece el resultado aplicable más estricto.

Resultado	Precedencia	Qué ocurre	Ejecución
`allow`	La más baja	La acción se permite sin fricción.	Procede
`warn`	Baja	La acción procede, pero se registra un código de motivo y un aviso para revisarlos más adelante.	Procede
`require_approval`	Alta	La ejecución se pausa. Se crea una Escalation y se enruta al Decision Desk para que una persona decida.	Pausada
`block`	La más alta	La acción se deniega. El agente recibe una denegación estructurada que puede gestionar de forma controlada.	Detenida

La precedencia hace que el modelo sea fail-closed y predecible. Si una regla amplia indica allow pero una regla más específica y de mayor precedencia indica require_approval, la acción se pausa. Un único block en cualquier parte del conjunto coincidente detiene la acción, sin importar cuántas reglas allow también hayan coincidido.

flowchart LR
  A["Acción del agente"] --> B{"Decisión del Policy Engine"}
  B -->|allow| C["Ejecutar"]
  B -->|warn| D["Ejecutar y registrar aviso"]
  B -->|require_approval| E["Crear Escalation"]
  E --> F["Decision Desk"]
  F -->|approved| C
  F -->|rejected| G["Detener acción"]
  B -->|block| G

Cómo se evalúa una acción

El agente (o el SDK de KLA en su nombre) envía un Decision Request: la acción junto con su contexto. El contexto incluye el agente que llama, la herramienta que se invoca, los parámetros y cualquier atributo de negocio que adjuntes (importe de la transacción, nivel del cliente, clasificación del documento). KLA evalúa esta solicitud frente a las políticas publicadas actualmente para tu tenant y devuelve uno de los cuatro resultados.

curl https://api.kla.digital/v1/decisions.evaluate \
  -H "Authorization: Bearer $KLA_ACCESS_TOKEN" \
  -H "x-tenant-id: acme" \
  -H "Content-Type: application/json" \
  -d '{
    "agent": "claims-triage",
    "action": "execute_refund",
    "attributes": { "amount": 420.00, "customer_tier": "standard" }
  }'

Una respuesta require_approval incluye el identificador de la Escalation que se abrió, de modo que tu integración pueda mostrar al usuario final que la acción está pendiente de revisión en lugar de fallar.

{
  "outcome": "require_approval",
  "reasonCodes": ["REFUND_OVER_THRESHOLD"],
  "remediation": "Los reembolsos superiores a $100 requieren un revisor. Esta solicitud se enrutó al Decision Desk.",
  "escalationId": "esc_01HZ8K..."
}

Códigos de motivo y remediación

Toda decisión distinta de allow lleva dos elementos además del veredicto: uno o más códigos de motivo y orientación de remediación. Un código de motivo es un identificador estable y legible por máquina (por ejemplo REFUND_OVER_THRESHOLD) que explica por qué se alcanzó el resultado. La orientación de remediación es una instrucción breve y legible para personas sobre qué hacer a continuación.

Este emparejamiento sirve a los tres destinatarios. Los desarrolladores ramifican su lógica según los códigos de motivo en lugar de analizar texto. Los revisores en el Decision Desk ven el contexto en lenguaje claro de la acción que tienen delante. Los responsables de cumplimiento disponen de un vocabulario coherente que se asigna de forma limpia a los marcos de control. Los códigos de motivo y la remediación son obligatorios en los resultados warn, require_approval y block, de modo que ninguna denegación o pausa termine nunca en un callejón sin salida silencioso.

ℹ️ Note

Los códigos de motivo se registran en el Lineage Record de la acción. Meses después, un auditor puede reconstruir con exactitud qué política se activó y por qué, sin necesidad de acceder a los registros de tu aplicación.

El Policy Engine

KLA evalúa las políticas en la capa de aplicación, cerca de la acción del agente y de su contexto de negocio. El motor de políticas combina dos tipos de comprobaciones:

Las comprobaciones de acceso deciden si quien llama puede usar la herramienta, la fuente de datos, el flujo de trabajo o la acción en absoluto.
Las comprobaciones en tiempo de ejecución evalúan la acción en su contexto (la herramienta y sus argumentos, su destino, los metadatos del modelo y los atributos de negocio que adjuntas) frente al policy pack que publicaste.

Ambos tipos de comprobaciones se resuelven en los mismos cuatro resultados de cara al cliente: allow, warn, require_approval o block. Prevalece el resultado coincidente más estricto, de modo que una comprobación en tiempo de ejecución todavía puede pausar o detener una acción aunque quien llama tenga permitido usar la herramienta.

# Reglas de política (ilustrativas): los reembolsos superiores a $100 se pausan para revisión
- rule: low-value-refund
  when:
    tool: execute_refund
    amount: "<= 100.00"
  then:
    decision: allow
    reasonCode: REFUND_WITHIN_THRESHOLD

- rule: high-value-refund
  when:
    tool: execute_refund
    amount: "> 100.00"
  then:
    decision: require_approval
    reasonCode: REFUND_OVER_THRESHOLD
    route: Decision Desk

En este ejemplo, un reembolso de $420 coincide con la segunda regla y se resuelve en require_approval, lo que pausa la ejecución y abre una Escalation. Un reembolso de $40 coincide con la primera regla y procede.

💡 Tip

Crea y prueba las políticas en el Policy Builder antes de ponerlas en producción. Ejecuta una **Simulation** para reproducir Decision Requests representativos frente a una política en borrador y confirmar que cada uno se resuelve en el resultado que esperas. Una vez validadas, las políticas se compilan en policy packs firmados y se publican.

🛡️ Important

Los cuatro resultados son el contrato con el que tu integración debe programarse. Trata `block` como una respuesta terminal y esperada (preséntala al usuario de forma controlada) y trata `require_approval` como una pausa asíncrona, no como un error.

Adónde van las aprobaciones

Un resultado require_approval crea una Escalation: una unidad de trabajo pausada que espera la decisión de una persona. Las Escalations llegan al Decision Desk, donde un revisor autorizado ve la acción, sus atributos, los códigos de motivo y la orientación de remediación, y luego aprueba o rechaza. La aprobación reanuda la ejecución original exactamente donde se pausó; el rechazo la detiene. La secuencia completa (la solicitud, la decisión, la Escalation y el veredicto del revisor) se registra como un Lineage Record, lo que te proporciona un rastro defendible para cada acción regida por políticas.

La aplicación de políticas en KLA reside en la capa de aplicación, cerca de la acción del agente, que es donde está disponible el contexto de negocio como el importe y el nivel del cliente. Los controles de admisión a nivel de infraestructura también pueden aplicar políticas en el límite de la plataforma, pero el control en tiempo de ejecución descrito aquí es lo que gobierna el comportamiento del agente en el lugar.