Policy Builder

Policy Builder est l'espace de rédaction du KLA Control Plane, accessible sur la route /policy-studio. Le KLA Control Plane est une couche de sécurité d'exécution, d'audit et de gouvernance de type govern-in-place pour les agents IA d'entreprise : vous instrumentez vos agents existants au lieu de les replateformer. Policy Builder est l'endroit où vous écrivez les règles qui déterminent ce que ces agents sont autorisés à faire. Chaque action conséquente d'un agent, qu'il s'agisse d'émettre un remboursement, d'envoyer un document pour relecture ou d'appeler une API externe, est contrôlée par rapport à la politique que vous publiez ici avant son exécution. Cette page explique comment configurer une politique, les deux façons de la modifier, comment la Simulation prouve son comportement avant publication, et ce qu'est un policy pack signé.

Qui l'utilise

Policy Builder est un terrain partagé par deux rôles. Les responsables conformité, risque et audit détiennent l'intention (ce qui doit être approuvé, ce qui doit être bloqué, où se situent les seuils) et rédigent de plus en plus les règles directement. Les développeurs et intégrateurs détiennent la précision : les attributs, conditions et codes de raison exacts que le runtime évalue. L'espace de travail est conçu pour que les deux puissent travailler sur le même brouillon sans se bloquer mutuellement : un auteur non technique peut exprimer une intention et un développeur peut affiner la condition sous-jacente.

Configuration guidée par l'intention

Vous ne partez pas d'un fichier YAML vierge. Policy Builder s'ouvre avec des catégories d'intention : des points de départ en langage clair qui génèrent une règle fonctionnelle que vous ajustez ensuite.

• Router selon la sensibilité : diriger les actions à plus haut risque vers un parcours plus strict.
• Exiger une approbation pour les opérations à haut risque : suspendre une action en attente d'une décision humaine.
• Bloquer une action d'outil : refuser purement et simplement une capacité spécifique, comme une écriture en base de données.
• Appliquer les Data Boundaries : maintenir les données réglementées à l'intérieur d'une région ou d'un système approuvés.

Chaque intention produit une règle brouillon dotée de la structure adéquate et de valeurs par défaut pertinentes. Vous y attachez les attributs métier qui comptent pour votre cas d'usage, tels que le montant de la transaction, le niveau du client et la classification du document, puis vous définissez les seuils.

Éditeur visuel ou YAML brut de la règle

Policy Builder vous offre deux vues synchronisées de la même règle :

• Constructeur visuel de conditions : assemblez les conditions à partir de champs, d'opérateurs et de valeurs sans écrire de YAML. Idéal pour une rédaction rapide et pour les relecteurs qui veulent lire l'intention plutôt que la syntaxe.
• Éditeur YAML brut : modifiez directement la définition sous-jacente de la règle pour bénéficier d'une expressivité complète, incluant les conditions composées, les contrôles d'exécution, les codes de raison, la remédiation et les parcours d'approbation.

Les deux vues écrivent dans le même brouillon, vous pouvez donc esquisser une intention visuellement puis passer au YAML pour la finaliser.

# 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 décision require_approval est ce qui indique à KLA de suspendre l'exécution et de router l'action vers le Decision Desk. Une décision block arrêterait l'action purement et simplement.

Simulez avant de publier

Un brouillon ne passe jamais directement au runtime. Vous lancez une Simulation : un test de politique qui rejoue des Decision Requests représentatives (une action accompagnée de son contexte) sur le brouillon et montre comment chacune se résout. Le modèle de décision de KLA comporte quatre issues, par ordre de priorité :

La Simulation vous permet de confirmer, avant toute mise en production, qu'un remboursement de $420 est suspendu et qu'un remboursement de $40 passe, sans toucher à un système en fonctionnement. KLA bloque la publication de tout brouillon qui échoue au lint : ainsi, une issue require_approval ou block à laquelle il manque son code de raison ou ses consignes de remédiation est détectée ici, et non en production.

Policy packs compilés et signés

Lorsqu'un brouillon validé est publié, KLA le compile en un policy pack signé : un bundle versionné et signé cryptographiquement que le runtime charge pour évaluer la politique. La signature signifie que l'évaluation est inviolable, car le runtime n'applique que les packs qu'il peut vérifier, et le versionnement signifie que chaque décision peut être retracée jusqu'à la politique exacte qui l'a produite. La compilation rend également l'évaluation suffisamment rapide pour se placer sur le chemin des actions d'agent en direct.

flowchart LR
  A["Édition d'intention ou de YAML"] --> B["Politique brouillon"]
  B --> C{"Simulation"}
  C -->|issues incorrectes| B
  C -->|issues correctes| D["Publier"]
  D --> E["Policy pack signé"]
  E --> F["Application par le runtime"]

Comment cela s'articule

Policy Builder est la source des règles ; deux autres modules sont l'endroit où ces règles prennent effet.

• Policy-Gated Execution est le mécanisme d'exécution qui évalue chaque Decision Request par rapport à votre pack publié et renvoie l'une des quatre issues. Les politiques que vous rédigez ici sont exactement ce qu'il applique.
• Decision Desk est l'endroit où aboutit une issue require_approval. Lorsqu'une règle suspend une action, KLA ouvre une Escalation et la route vers ce module afin qu'un relecteur autorisé l'approuve ou la rejette.

Rédigez la règle dans Policy Builder, prouvez-la en Simulation, publiez le pack signé, et le runtime gouverne dès lors chaque action correspondante.