Vue d'ensemble de l'architecture
Un modèle mental, au niveau produit, de la manière dont le KLA Control Plane encapsule vos agents IA existants pour gouverner, exploiter, garantir et prouver chaque action.
Le KLA Control Plane est une couche de sécurité d'exécution, d'audit et de gouvernance qui gouverne sur place les agents IA d'entreprise. « Gouverner sur place » signifie que vous instrumentez les agents que vous exploitez déjà (chaînes LangChain, services FastAPI ou code entièrement sur mesure) au lieu de les redéployer sur un nouveau runtime. KLA encapsule ces agents avec une fine couche d'instrumentation et un ensemble de plans toujours actifs qui décident si chaque action est autorisée, capturent ce qui s'est produit et scellent une preuve cryptographique de l'action.
Cette page présente un modèle mental logique, et non un schéma d'infrastructure. Elle décrit les plans qu'un développeur, un opérateur ou un auditeur doit comprendre, ainsi que le parcours d'une action d'agent à travers ces plans.
Les plans en un coup d'œil
KLA s'organise autour d'un petit nombre de plans coopérants. Chacun correspond à l'un des quatre piliers produit : Govern. Operate. Assure. Prove.
| Plan | Rôle | Pilier |
|---|---|---|
| Instrumentation / SDK | Émet des spans OpenTelemetry depuis votre agent et demande des décisions de politique avant les actions à risque | Govern |
| Policy Engine | Évalue chaque action au regard de packs de politiques signés et renvoie l'un des quatre résultats | Govern |
| Decision Desk | Conserve les actions suspendues en attente de revue humaine lorsqu'une politique exige une approbation | Govern / Operate |
| Collector | Reçoit la télémétrie, expurge les données personnelles, normalise les spans | Operate / Prove |
| Evidence Ledger | Ancre les enregistrements scellés dans un registre cryptographique en ajout seul | Prove |
| Surfaces Console | Les modules web où les humains pilotent et inspectent le système | Les quatre |
Le parcours d'une action
Toute action gouvernée suit le même chemin. L'agent appelle le KLA SDK avant d'exécuter une étape sensible (un appel d'outil, une écriture en base de données, un paiement). Le SDK ouvre un span OpenTelemetry et soumet une Decision Request au Policy Engine, qui renvoie l'un des quatre résultats, par ordre de priorité : allow, warn, require_approval ou block. Un résultat allow ou warn laisse l'action se poursuivre ; un require_approval suspend l'exécution et achemine une Escalation vers le Decision Desk afin qu'un humain l'approuve ou la refuse ; un block arrête l'action net. Quel que soit le résultat, le span transite par le Collector jusqu'à l'Evidence Ledger.
flowchart LR
A["Action d'agent"] --> SDK["KLA SDK<br/>instrumentation"]
SDK --> PE{"Policy Engine<br/>décision"}
PE -->|allow / warn| EX["Exécuter l'action"]
PE -->|require_approval| DD["Decision Desk<br/>revue humaine"]
PE -->|block| ST["Arrêter l'action"]
DD -->|approved| EX
DD -->|denied| ST
EX --> COL["KLA Collector<br/>expurgation des données personnelles"]
ST --> COL
DD --> COL
COL --> LED["Evidence Ledger<br/>preuves Merkle"]
LED --> EB["Sealed Evidence Bundle"]La couche d'instrumentation
Deux modèles de déploiement relient vos agents à KLA :
- Govern in Place : vous ajoutez le KLA SDK à votre code existant. Il émet des spans OpenTelemetry asynchrones et exécute des contrôles en cours de processus, de sorte qu'une décision de politique intervient en ligne avant l'action. Votre agent continue de fonctionner là où il réside déjà.
- Run through KLA : vous routez l'exécution de l'agent à travers un proxy géré via l'Executions API. KLA observe et contrôle chaque étape de façon centralisée, ce qui est utile lorsque vous ne pouvez pas modifier le code de l'agent.
Les deux modèles produisent la même télémétrie et alimentent les mêmes plans en aval. Les spans portent des attributs sémantiques GenAI qui rendent le comportement de l'agent lisible : genai.agent.name, genai.system.instructions, genai.tool.name, genai.tool.parameters, genai.cost.usd et genai.token.usage.
from kla import KLA
kla = KLA(api_url="https://api.kla.digital", tenant="acme")
# Demander une décision avant un appel d'outil sensible.
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() # Suspend jusqu'à ce que le Decision Desk résolve l'Escalation.
Le Policy Engine
KLA utilise le KLA Policy Engine au niveau de la couche applicative pour évaluer les Decision Requests. Les politiques sont des règles déclaratives qui définissent qui peut faire quoi, dans quelles conditions, et quels contrôles d'exécution doivent s'appliquer. Vous les rédigez dans Policy Builder, vous lancez une Simulation sur le trafic historique avant publication, puis vous les compilez en packs de politiques signés : des bundles infalsifiables que le moteur charge à l'exécution. Chaque contrôle se résout selon le même modèle à quatre résultats : une correspondance peut autoriser l'action, consigner un avertissement, suspendre pour approbation humaine ou bloquer l'exécution.
Le pipeline de preuve
Le chemin de données qui produit la preuve est volontairement linéaire et unidirectionnel :
flowchart LR S["Spans OpenTelemetry"] --> C["KLA Collector<br/>expurgation des données personnelles"] C --> L["Registre ImmuDB<br/>ajout seul, preuves Merkle"] L --> B["Sealed Evidence Bundle"] B --> P["Export Control Pack"]
Les spans arrivent au KLA Collector, qui expurge les données personnelles (e-mails, numéros de carte, secrets) avant tout stockage. Les enregistrements assainis sont hachés et ancrés dans ImmuDB, un registre cryptographique en ajout seul : les enregistrements ne peuvent être ni modifiés, ni supprimés, ni réordonnés, et chacun est démontrable via une Merkle proof. À partir de là, les auditeurs exportent un Sealed Evidence Bundle (l'enregistrement vérifiable d'une trace unique, appelé Lineage Record) ou un Control Pack (un export de conformité rattaché à un référentiel) depuis l'Evidence Room.
Multi-tenant et chemin de données
KLA est multi-tenant par conception. Chaque requête porte une identité de tenant, et chaque enregistrement (Decision Request, Lineage Record, Escalation, ancre de preuve) est rattaché à un seul tenant. Les appelants déclarent leur tenant à chaque appel d'API :
curl https://api.kla.digital/v1/decisions \
-H "Authorization: Bearer <token>" \
-H "x-tenant-id: <tenant>"
L'isolation des tenants est appliquée au niveau de la couche de données, de sorte que les politiques, traces et preuves d'un tenant ne sont jamais visibles par un autre. La même frontière s'applique de bout en bout : la télémétrie des agents d'un tenant n'alimente que le registre de ce tenant et n'apparaît que dans la Console de ce tenant.
Les surfaces de la Console
Les plans sont pilotés et inspectés à travers sept modules web, chacun étant une fenêtre sur une partie du flux :
- Command : la surface d'accueil pour la santé en temps réel des agents et l'activité récente.
- Agents : l'Agent Registry et le cycle de vie : une Release (version de workflow), un Rollout (déploiement) et un Rollback.
- Policy Builder : rédiger, simuler et publier des politiques.
- Decision Desk : résoudre les Escalations suspendues avec tout le contexte.
- Lineage Explorer : rejouer n'importe quel Lineage Record étape par étape.
- Assurance Center : suivre la dérive sous forme d'Assurance Alerts et agir sur un Remediation Plan (le pilier « Assure »).
- Evidence Room : exporter des Sealed Evidence Bundles et des Control Packs.
Pour aller plus loin
Commencez par les deux concepts fondamentaux que cette vue d'ensemble ne fait qu'esquisser : Exécution sous contrôle de politiques pour le modèle de décision à quatre résultats, et La preuve par défaut pour le registre cryptographique. Explorez ensuite les modules en profondeur, Policy Builder, Decision Desk, Lineage Explorer et Evidence Room, ou raccordez un agent avec le Python SDK ou le Node SDK.