Modèles de déploiement et configuration

Le KLA Control Plane est une couche de sécurité d'exécution, d'audit et de gouvernance « govern-in-place » destinée aux agents IA d'entreprise. Vous instrumentez les agents et les API que vous exploitez déjà (LangChain, FastAPI ou code maison) au lieu de les re-plateformiser. KLA prend en charge deux modèles d'intégration, que vous pouvez combiner au sein d'un même déploiement : Govern in Place enveloppe votre runtime existant avec le SDK OpenTelemetry, tandis que Run through KLA fait transiter l'exécution par un proxy managé via l'Executions API. Cette page compare les deux approches, montre comment chacune fonctionne et vous aide à choisir.

Comparaison des topologies

Modèle 1 : Govern in Place

Vos agents continuent de s'exécuter dans leur propre environnement. Le SDK KLA émet de manière asynchrone des spans OpenTelemetry vers le Control Plane, si bien que la télémétrie ne se trouve jamais dans le chemin de la requête. L'application des règles se produit aux checkpoints : les points de votre code où vous demandez à KLA si une action est autorisée avant de l'exécuter. À chaque checkpoint, le moteur de politiques renvoie l'un des quatre résultats, évalués par ordre de priorité : allow, warn, require_approval ou block. Un résultat require_approval met l'exécution en pause et achemine une Escalation vers le Decision Desk, la surface de revue humaine de KLA, où un relecteur traite la Decision Request.

flowchart LR
  A["Votre application agent (encapsulée par le SDK)"] --> B["Fournisseur LLM"]
  A -->|checkpoint| C{"Décision de politique"}
  C -->|allow / warn| A
  C -->|require_approval| D["Decision Desk"]
  C -->|block| E["Action refusée"]
  A -. spans async .-> F["KLA Control Plane"]

Instructions de configuration

1. Installez le SDK correspondant au langage de votre application (Python ou Node.js).
2. Initialisez le SDK au point d'entrée de votre application afin que les spans soient transmis au Control Plane.
3. Encapsulez les actions sensibles des outils ou les complétions de modèle dans un checkpoint KLA.

# Govern in Place: evaluate an action at a checkpoint
from kla_sdk import KLACheckpoint

checkpoint = KLACheckpoint(agent_id="agt_9f81a7")

# If policy returns require_approval, this blocks and opens an
# Escalation on the Decision Desk until a reviewer resolves it.
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")

Modèle 2 : Run through KLA

Ici, votre client envoie ses requêtes à l'Executions API au lieu d'appeler directement un fournisseur de modèle. KLA résout les identifiants du fournisseur depuis le Secrets Vault, applique la politique inline, exécute l'agent face au modèle et enregistre le Lineage Record, le tout en un seul saut consolidé. Comme l'application des règles est inline, un résultat block arrête la requête avant qu'aucun outil ne s'exécute.

flowchart LR
  A["Frontend client (interface de chat)"] -->|Executions API| B["KLA Control Plane"]
  B --> C{"Décision de politique"}
  C -->|allow / warn| D["Fournisseur LLM"]
  C -->|require_approval| E["Decision Desk"]
  C -->|block| F["Requête rejetée"]
  D --> B
  B -->|réponse + Lineage Record| A

Instructions de configuration

1. Stockez les identifiants de votre fournisseur de modèle dans le Secrets Vault.
2. Enregistrez l'agent, avec ses instructions système, ses paramètres et ses outils, dans l'Agent Registry.
3. Pointez votre client vers l'Executions API au lieu d'OpenAI ou d'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 résultat require_approval renvoie une référence d'Escalation et un statut en attente ; interrogez l'exécution ou abonnez-vous aux événements du Decision Desk pour poursuivre dès qu'un relecteur a approuvé.

Choisir un modèle

Pour les développeurs et intégrateurs disposant d'un agent déjà en production, par exemple un workflow LangChain de triage de sinistres qui dessert déjà du trafic, Govern in Place est la voie la plus rapide : ajoutez le SDK et quelques checkpoints, ne modifiez aucun routage et préservez votre budget de latence. Pour les opérateurs de plateforme mettant en place un agent greenfield ou une interface de chat standard, Run through KLA supprime le plus de code, puisque KLA prend en charge l'injection des identifiants, l'application inline des règles et la compilation des traces derrière un seul endpoint. Pour les responsables conformité et risques, le choix est rassurant de neutralité : les deux modèles alimentent le même moteur de politiques et le même pipeline de preuves scellées, de sorte que vos exports de Control Pack et vos Sealed Evidence Bundles sont identiques, quelle que soit la façon dont l'agent est câblé. La plupart des entreprises exploitent les deux, instrumentant sur place les systèmes hérités tout en faisant transiter les nouveaux agents par KLA, et les gouvernent depuis un Control Plane unique.