Policy Builder

Policy Builder es el espacio de trabajo de redacción de KLA Control Plane, disponible en la ruta /policy-studio. KLA Control Plane es una capa de seguridad, auditoría y gobernanza en tiempo de ejecución que gobierna en el sitio para agentes de IA empresariales: usted instrumenta sus agentes existentes en lugar de migrarlos a otra plataforma. Policy Builder es donde escribe las reglas que deciden qué pueden hacer esos agentes. Cada acción de un agente con consecuencias importantes, ya sea emitir un reembolso, enviar un documento para revisión o llamar a una API externa, se contrasta con la política que usted publica aquí antes de ejecutarse. Esta página explica cómo configurar una política, las dos formas de editarla, cómo la Simulation demuestra su comportamiento antes de publicar y qué es un paquete de políticas firmado.

Quién lo usa

Policy Builder es un terreno compartido por dos roles. Los responsables de cumplimiento, riesgo y auditoría son los dueños de la intención (qué debe aprobarse, qué debe bloquearse y dónde se sitúan los umbrales) y cada vez redactan reglas de forma más directa. Los desarrolladores e integradores son los dueños de la precisión: los atributos, condiciones y códigos de motivo exactos que evalúa el runtime. El espacio de trabajo está diseñado para que ambos puedan trabajar sobre el mismo borrador sin que uno bloquee al otro: un autor sin perfil técnico puede expresar una intención y un desarrollador puede afinar la condición subyacente.

Configuración guiada por la intención

No empieza desde un archivo YAML en blanco. Policy Builder se abre con categorías de intención: puntos de partida en lenguaje sencillo que generan el esqueleto de una regla funcional que después usted ajusta.

• Enrutar por sensibilidad: dirija las acciones de mayor riesgo por un camino más estricto.
• Requerir aprobación en operaciones de alto riesgo: pause una acción para que una persona decida.
• Bloquear la acción de una herramienta: deniegue por completo una capacidad concreta, como una escritura en base de datos.
• Aplicar límites de datos: mantenga los datos regulados dentro de una región o un sistema aprobado.

Cada intención produce una regla en borrador con la estructura adecuada y valores predeterminados sensatos. Usted asocia los atributos de negocio relevantes para su caso de uso, como el importe de la transacción, el nivel del cliente y la clasificación del documento, y establece los umbrales.

Editor visual o YAML de regla en bruto

Policy Builder le ofrece dos vistas sincronizadas de la misma regla:

• Constructor visual de condiciones: ensamble condiciones a partir de campos, operadores y valores sin escribir YAML. Ideal para una redacción ágil y para revisores que quieren leer la intención, no la sintaxis.
• Editor de YAML en bruto: edite directamente la definición subyacente de la regla para obtener toda su expresividad, incluidas condiciones compuestas, comprobaciones en tiempo de ejecución, códigos de motivo, remediación y rutas de aprobación.

Ambas vistas escriben sobre el mismo borrador, de modo que puede esbozar una intención de forma visual y pasar a YAML para terminarla.

# Draft rule (illustrative): high-value refunds pause for a human
rule: high-value-refund
when:
  tool: execute_refund
  amount: "> 100.00"
then:
  decision: require_approval
  reasonCode: REFUND_OVER_THRESHOLD
  route: Decision Desk

La decisión require_approval es la que indica a KLA que pause la ejecución y enrute la acción al Decision Desk. Una decisión block detendría la acción por completo.

Simule antes de publicar

Un borrador nunca pasa directamente al runtime. Usted ejecuta una Simulation: una ejecución de prueba de la política que reproduce Decision Requests representativos (una acción más su contexto) frente al borrador y muestra cómo se resuelve cada uno. El modelo de decisión de KLA tiene cuatro resultados, en orden de precedencia:

La Simulation le permite confirmar, antes de que nada esté en producción, que un reembolso de $420 se pausa y que uno de $40 pasa, sin tocar un sistema en funcionamiento. KLA impide la publicación de cualquier borrador que no supere el lint, de modo que un resultado require_approval o block al que le falte su código de motivo o su guía de remediación se detecta aquí, no en producción.

Paquetes de políticas compilados y firmados

Cuando se publica un borrador validado, KLA lo compila en un paquete de políticas firmado: un conjunto versionado y firmado criptográficamente que el runtime carga para evaluar la política. La firma significa que la evaluación es a prueba de manipulaciones, ya que el runtime solo aplica los paquetes que puede verificar, y el versionado significa que cada decisión puede rastrearse hasta la política exacta que la produjo. La compilación también hace que la evaluación sea lo bastante rápida como para situarse en el camino de las acciones de agente en vivo.

flowchart LR
  A["Edición de intención o YAML"] --> B["Política en borrador"]
  B --> C{"Simulation"}
  C -->|resultados incorrectos| B
  C -->|resultados correctos| D["Publicar"]
  D --> E["Paquete de políticas firmado"]
  E --> F["Aplicación en el runtime"]

Cómo se conecta

Policy Builder es el origen de las reglas; otros dos módulos son donde esas reglas surten efecto.

• Policy-Gated Execution es el mecanismo en tiempo de ejecución que evalúa cada Decision Request frente al paquete que usted ha publicado y devuelve uno de los cuatro resultados. Las políticas que redacta aquí son exactamente lo que aplica.
• Decision Desk es donde aterriza un resultado require_approval. Cuando una regla pausa una acción, KLA abre una Escalation y la enruta allí para que un revisor autorizado la apruebe o la rechace.

Redacte la regla en Policy Builder, demuéstrela en la Simulation, publique el paquete firmado y, a partir de ese momento, el runtime gobierna cada acción que coincida.