Patrones de despliegue y configuración

El KLA Control Plane es una capa de seguridad en tiempo de ejecución, auditoría y gobernanza de tipo govern-in-place para agentes de IA empresariales. Instrumentas los agentes y las API que ya ejecutas (LangChain, FastAPI o código propio) en lugar de migrarlos a otra plataforma. KLA admite dos patrones de integración, y puedes combinarlos dentro de un mismo despliegue: Govern in Place envuelve tu runtime existente con el SDK de OpenTelemetry, mientras que Run through KLA enruta la ejecución a través de un proxy gestionado mediante la Executions API. Esta página compara ambos enfoques, muestra cómo funciona cada uno y te ayuda a elegir.

Comparación de topologías

Patrón 1: Govern in Place

Tus agentes siguen ejecutándose en su propio entorno. El SDK de KLA emite spans de OpenTelemetry de forma asíncrona al Control Plane, de modo que la telemetría nunca queda en la ruta de la solicitud. La aplicación de políticas ocurre en los checkpoints: puntos de tu código donde le preguntas a KLA si una acción está permitida antes de ejecutarla. En cada checkpoint, el motor de políticas devuelve uno de cuatro resultados, evaluados por orden de precedencia: allow, warn, require_approval o block. Un resultado require_approval pausa la ejecución y enruta una Escalation al Decision Desk, la superficie de revisión humana de KLA, donde un revisor resuelve la Decision Request.

flowchart LR
  A["Tu aplicación de agente (envuelta con el SDK)"] --> B["Proveedor de LLM"]
  A -->|checkpoint| C{"Decisión de política"}
  C -->|allow / warn| A
  C -->|require_approval| D["Decision Desk"]
  C -->|block| E["Acción denegada"]
  A -. spans asíncronos .-> F["KLA Control Plane"]

Instrucciones de configuración

1. Instala el SDK para el lenguaje de tu aplicación (Python o Node.js).
2. Inicializa el SDK en el punto de entrada de tu aplicación para que los spans fluyan al Control Plane.
3. Envuelve las acciones de herramientas sensibles o las terminaciones del modelo en un checkpoint de KLA.

# Govern in Place: evaluar una acción en un checkpoint
from kla_sdk import KLACheckpoint

checkpoint = KLACheckpoint(agent_id="agt_9f81a7")

# Si la política devuelve require_approval, esto bloquea y abre una
# Escalation en el Decision Desk hasta que un revisor la resuelve.
decision = checkpoint.evaluate_action(
    tool="process_refund",
    context={"amount": 1250.00},
)

if decision.outcome == "allow":
    execute_refund()
else:
    raise PermissionError(f"Refund {decision.outcome} by governance policy")

Patrón 2: Run through KLA

Aquí tu cliente envía las solicitudes a la Executions API en lugar de llamar directamente a un proveedor de modelos. KLA resuelve las credenciales del proveedor desde el Secrets Vault, aplica la política en línea, ejecuta el agente contra el modelo y registra el Lineage Record, todo en un único salto consolidado. Como la aplicación de políticas es en línea, un resultado block detiene la solicitud antes de que se ejecute cualquier herramienta.

flowchart LR
  A["Frontend del cliente (interfaz de chat)"] -->|Executions API| B["KLA Control Plane"]
  B --> C{"Decisión de política"}
  C -->|allow / warn| D["Proveedor de LLM"]
  C -->|require_approval| E["Decision Desk"]
  C -->|block| F["Solicitud rechazada"]
  D --> B
  B -->|respuesta + Lineage Record| A

Instrucciones de configuración

1. Almacena las credenciales de tu proveedor de modelos en el Secrets Vault.
2. Registra el agente, con sus instrucciones de sistema, parámetros y herramientas, en el Agent Registry.
3. Apunta tu cliente a la Executions API en lugar de a OpenAI o Anthropic.

curl -X POST https://api.kla.digital/v1/executions \
  -H "Authorization: Bearer $KLA_ACCESS_TOKEN" \
  -H "x-tenant-id: $KLA_TENANT" \
  -H "Content-Type: application/json" \
  -d '{
    "agentId": "agt_9f81a7",
    "input": { "prompt": "Summarize outstanding contracts" }
  }'

Un resultado require_approval devuelve una referencia de Escalation y un estado pendiente; sondea la ejecución o suscríbete a los eventos del Decision Desk para continuar una vez que un revisor lo apruebe.

Cómo elegir un patrón

Para los desarrolladores e integradores con un agente de producción ya existente, por ejemplo un flujo de trabajo de clasificación de reclamaciones en LangChain que ya atiende tráfico, Govern in Place es la vía más rápida: añade el SDK y unos cuantos checkpoints, no cambies ningún enrutamiento y conserva intacto tu presupuesto de latencia. Para los operadores de plataforma que ponen en marcha un agente nuevo o una interfaz de chat estándar, Run through KLA elimina la mayor cantidad de código, ya que KLA se encarga de la inyección de credenciales, la aplicación de políticas en línea y la compilación de trazas tras un único endpoint. Para los responsables de cumplimiento y riesgo, la decisión es tranquilizadoramente neutral: ambos patrones alimentan el mismo motor de políticas y el mismo pipeline de evidencias selladas, de modo que tus exportaciones de Control Pack y tus Sealed Evidence Bundles se ven idénticos independientemente de cómo esté cableado el agente. La mayoría de las empresas ejecutan ambos, instrumentando los sistemas heredados en su lugar mientras enrutan los agentes nuevos a través de KLA, y los gobiernan desde un único Control Plane.