Visión general de la arquitectura
Un modelo mental, a nivel de producto, de cómo el KLA Control Plane envuelve sus agentes de IA existentes para gobernar, operar, asegurar y demostrar cada acción.
El KLA Control Plane es una capa de seguridad, auditoría y gobernanza en tiempo de ejecución que gobierna a los agentes de IA empresariales en su lugar de origen. "Gobernar en su lugar de origen" significa que usted instrumenta los agentes que ya ejecuta (cadenas de LangChain, servicios de FastAPI o código totalmente personalizado) en lugar de migrarlos a una nueva plataforma de ejecución. KLA envuelve esos agentes con una capa de instrumentación ligera y un conjunto de planos siempre activos que deciden si cada acción está permitida, capturan lo que ocurrió y sellan una prueba criptográfica de ello.
Esta página es un modelo mental lógico, no un diagrama de infraestructura. Describe los planos que un desarrollador, operador o auditor necesita comprender, y cómo una única acción de un agente los recorre.
Los planos de un vistazo
KLA está organizado en un número reducido de planos que cooperan entre sí. Cada uno se corresponde con uno de los cuatro pilares del producto: Govern. Operate. Assure. Prove.
| Plano | Qué hace | Pilar |
|---|---|---|
| Instrumentación / SDK | Emite spans de OpenTelemetry desde su agente y solicita decisiones de política antes de las acciones de riesgo | Govern |
| Policy Engine | Evalúa cada acción frente a paquetes de políticas firmados y devuelve uno de cuatro resultados | Govern |
| Decision Desk | Retiene las acciones en pausa para revisión humana cuando una política exige aprobación | Govern / Operate |
| Collector | Recibe la telemetría, depura los datos personales (PII) y normaliza los spans | Operate / Prove |
| Evidence Ledger | Ancla los registros sellados a un libro mayor criptográfico de solo anexado | Prove |
| Superficies de la consola | Los módulos web donde las personas operan e inspeccionan el sistema | Los cuatro |
Cómo fluye una acción
Cada acción gobernada sigue el mismo recorrido. El agente llama al KLA SDK antes de ejecutar un paso sensible (una llamada a una herramienta, una escritura en base de datos, un pago). El SDK abre un span de OpenTelemetry y envía un Decision Request al Policy Engine, que devuelve uno de cuatro resultados en orden de precedencia: allow, warn, require_approval o block. Un allow o un warn permiten que la acción continúe; un require_approval pausa la ejecución y enruta una Escalation al Decision Desk para que una persona la apruebe o la deniegue; un block detiene la acción de inmediato. Sea cual sea el resultado, el span fluye a través del Collector hasta el Evidence Ledger.
flowchart LR
A["Acción del agente"] --> SDK["KLA SDK<br/>instrumentación"]
SDK --> PE{"Decisión del<br/>Policy Engine"}
PE -->|allow / warn| EX["Ejecutar acción"]
PE -->|require_approval| DD["Decision Desk<br/>revisión humana"]
PE -->|block| ST["Detener acción"]
DD -->|approved| EX
DD -->|denied| ST
EX --> COL["KLA Collector<br/>depuración de PII"]
ST --> COL
DD --> COL
COL --> LED["Evidence Ledger<br/>pruebas Merkle"]
LED --> EB["Sealed Evidence Bundle"]La capa de instrumentación
Dos patrones de despliegue conectan sus agentes con KLA:
- Govern in Place: usted añade el KLA SDK a su código existente. Emite spans asíncronos de OpenTelemetry y ejecuta controles en proceso, de modo que la decisión de política ocurre en línea antes de la acción. Su agente sigue ejecutándose donde ya reside.
- Run through KLA: usted enruta la ejecución del agente a través de un proxy gestionado mediante la Executions API. KLA observa y controla cada paso de forma centralizada, lo cual resulta útil cuando no puede modificar el código del agente.
Ambos patrones producen la misma telemetría y alimentan los mismos planos posteriores. Los spans transportan atributos semánticos de GenAI que hacen legible el comportamiento del agente: genai.agent.name, genai.system.instructions, genai.tool.name, genai.tool.parameters, genai.cost.usd y genai.token.usage.
from kla import KLA
kla = KLA(api_url="https://api.kla.digital", tenant="acme")
# Solicita una decisión antes de una llamada sensible a una herramienta.
decision = kla.decide(
agent="claims-triage",
action="execute_refund",
attributes={"amount": 240.00, "currency": "USD"},
)
if decision.outcome == "allow":
issue_refund()
elif decision.outcome == "require_approval":
decision.wait() # Pausa hasta que el Decision Desk resuelva la Escalation.
El Policy Engine
KLA utiliza el KLA Policy Engine en la capa de aplicación para evaluar los Decision Requests. Las políticas son reglas declarativas que indican quién puede hacer qué, en qué condiciones y qué comprobaciones deben aplicarse en tiempo de ejecución. Usted las redacta en Policy Builder, ejecuta una Simulation frente al tráfico histórico antes de publicarlas y luego las compila en paquetes de políticas firmados: paquetes a prueba de manipulaciones que el motor carga en tiempo de ejecución. Cada comprobación se resuelve con el mismo modelo de cuatro resultados, de modo que una coincidencia puede permitir la acción, registrar una advertencia, pausar para aprobación humana o bloquear la ejecución.
La canalización de evidencia
La ruta de datos que produce la prueba es deliberadamente lineal y unidireccional:
flowchart LR S["Spans de OpenTelemetry"] --> C["KLA Collector<br/>depuración de PII"] C --> L["Libro mayor ImmuDB<br/>solo anexado, pruebas Merkle"] L --> B["Sealed Evidence Bundle"] B --> P["Exportación de Control Pack"]
Los spans llegan al KLA Collector, que depura los datos personales (correos electrónicos, números de tarjeta, secretos) antes de almacenar nada. Los registros saneados se procesan con hash y se anclan en ImmuDB, un libro mayor criptográfico de solo anexado: los registros no pueden editarse, eliminarse ni reordenarse, y cada uno es verificable mediante una Merkle proof. A partir de ahí, los auditores exportan un Sealed Evidence Bundle (el registro verificable de una sola traza, denominado Lineage Record) o un Control Pack (una exportación de cumplimiento mapeada a un marco normativo) desde el Evidence Room.
Multiinquilinato y la ruta de datos
KLA es multiinquilino por diseño. Cada solicitud lleva una identidad de inquilino, y cada registro (Decision Request, Lineage Record, Escalation, ancla de evidencia) está acotado a un único inquilino. Quienes llaman a la API declaran su inquilino en cada llamada:
curl https://api.kla.digital/v1/decisions \
-H "Authorization: Bearer <token>" \
-H "x-tenant-id: <tenant>"
El aislamiento entre inquilinos se aplica en la capa de datos, de modo que las políticas, las trazas y la evidencia de un inquilino nunca son visibles para otro. El mismo límite se aplica de extremo a extremo: la telemetría de los agentes de un inquilino solo fluye hacia el libro mayor de ese inquilino y solo aparece en la Console de ese inquilino.
Las superficies de la consola
Los planos se operan e inspeccionan a través de siete módulos web, cada uno una ventana hacia una parte del flujo:
- Command: la superficie principal para el estado en vivo de los agentes y la actividad reciente.
- Agents: el Agent Registry y el ciclo de vida: un Release (versión de flujo de trabajo), un Rollout (despliegue) y un Rollback.
- Policy Builder: redactar, simular y publicar políticas.
- Decision Desk: resolver las Escalations en pausa con contexto completo.
- Lineage Explorer: reproducir cualquier Lineage Record paso a paso.
- Assurance Center: rastrear las desviaciones como Assurance Alerts y actuar sobre un Remediation Plan (el pilar "Assure").
- Evidence Room: exportar Sealed Evidence Bundles y Control Packs.
Por dónde continuar
Comience con los dos conceptos fundamentales que esta visión general solo esboza: Ejecución controlada por políticas para el modelo de decisión de cuatro resultados, y Evidencia por defecto para el libro mayor criptográfico. Luego explore los módulos en profundidad, Policy Builder, Decision Desk, Lineage Explorer y Evidence Room, o conecte un agente con el Python SDK o el Node SDK.