Exécution sous contrôle de politique

Lorsqu'un agent IA d'entreprise tente d'effectuer une action conséquente (émettre un remboursement, envoyer un document pour relecture, appeler une API externe), KLA Control Plane évalue cette action au regard de la politique avant son exécution. KLA Control Plane est une couche de sécurité, d'audit et de gouvernance à l'exécution qui gouverne en place les agents IA : vous instrumentez vos agents existants au lieu de les replateformer. L'exécution sous contrôle de politique est le mécanisme qui décide, en temps réel, si une action se poursuit, se poursuit avec un avertissement, se met en pause pour un humain ou est arrêtée. Cette page explique le modèle de décision et la manière dont une action mise en pause devient une Escalation acheminée vers le Decision Desk.

Les quatre résultats de décision

Chaque évaluation de politique dans KLA se résout en exactement un résultat. Les résultats sont ordonnés par précédence : lorsque plusieurs règles correspondent à une action, le résultat applicable le plus fort l'emporte.

La précédence rend le modèle fail-closed et prévisible. Si une règle large indique allow mais qu'une règle plus restreinte et de précédence supérieure indique require_approval, l'action est mise en pause. Un seul block n'importe où dans l'ensemble des règles correspondantes arrête l'action, quel que soit le nombre de règles allow qui ont également correspondu.

flowchart LR
  A["Action de l'agent"] --> B{"Décision du Policy Engine"}
  B -->|allow| C["Exécuter"]
  B -->|warn| D["Exécuter et enregistrer l'avis"]
  B -->|require_approval| E["Créer une Escalation"]
  E --> F["Decision Desk"]
  F -->|approuvée| C
  F -->|rejetée| G["Arrêter l'action"]
  B -->|block| G

Comment une action est évaluée

L'agent (ou le SDK KLA en son nom) soumet une Decision Request : l'action accompagnée de son contexte. Le contexte inclut l'agent appelant, l'outil invoqué, les paramètres ainsi que tous les attributs métier que vous y attachez (montant de la transaction, niveau du client, classification du document). KLA évalue cette requête au regard des politiques actuellement publiées pour votre tenant et renvoie l'un des quatre résultats.

curl https://api.kla.digital/v1/decisions.evaluate \
  -H "Authorization: Bearer $KLA_ACCESS_TOKEN" \
  -H "x-tenant-id: acme" \
  -H "Content-Type: application/json" \
  -d '{
    "agent": "claims-triage",
    "action": "execute_refund",
    "attributes": { "amount": 420.00, "customer_tier": "standard" }
  }'

Une réponse require_approval inclut l'identifiant de l'Escalation qui a été ouverte, afin que votre intégration puisse indiquer à l'utilisateur final que l'action est en attente de relecture plutôt qu'en échec.

{
  "outcome": "require_approval",
  "reasonCodes": ["REFUND_OVER_THRESHOLD"],
  "remediation": "Refunds above $100 require a reviewer. This request was routed to the Decision Desk.",
  "escalationId": "esc_01HZ8K..."
}

Codes de raison et remédiation

Chaque décision autre que allow porte deux éléments en plus du verdict : un ou plusieurs codes de raison et des conseils de remédiation. Un code de raison est un identifiant stable et lisible par machine (par exemple REFUND_OVER_THRESHOLD) qui explique pourquoi le résultat a été atteint. Les conseils de remédiation constituent une instruction courte et lisible par un humain sur la marche à suivre.

Cet appariement sert les trois lecteurs. Les développeurs branchent leur code sur les codes de raison plutôt que d'analyser du texte. Les relecteurs au Decision Desk disposent d'un contexte en langage clair pour l'action qui leur est présentée. Les responsables conformité bénéficient d'un vocabulaire cohérent qui se rattache proprement aux cadres de contrôle. Les codes de raison et la remédiation sont obligatoires pour les résultats warn, require_approval et block, de sorte qu'aucun refus ni aucune pause ne soit jamais une impasse silencieuse.

Le Policy Engine

KLA évalue les politiques au niveau de la couche applicative, au plus près de l'action de l'agent et de son contexte métier. Le policy engine combine deux types de vérifications :

• Les vérifications d'accès déterminent si l'appelant peut utiliser l'outil, la source de données, le workflow ou l'action.
• Les vérifications à l'exécution évaluent l'action en contexte (l'outil et ses arguments, sa destination, les métadonnées du modèle et les attributs métier que vous attachez) au regard du policy pack que vous avez publié.

Les deux types de vérifications se résolvent vers les mêmes quatre résultats visibles par le client : allow, warn, require_approval ou block. Le résultat correspondant le plus fort l'emporte, de sorte qu'une vérification à l'exécution peut tout de même mettre en pause ou arrêter une action même lorsque l'appelant est par ailleurs autorisé à utiliser l'outil.

# Policy rules (illustrative): refunds over $100 pause for review
- rule: low-value-refund
  when:
    tool: execute_refund
    amount: "<= 100.00"
  then:
    decision: allow
    reasonCode: REFUND_WITHIN_THRESHOLD

- rule: high-value-refund
  when:
    tool: execute_refund
    amount: "> 100.00"
  then:
    decision: require_approval
    reasonCode: REFUND_OVER_THRESHOLD
    route: Decision Desk

Dans cet exemple, un remboursement de $420 correspond à la seconde règle et se résout en require_approval, mettant l'exécution en pause et ouvrant une Escalation. Un remboursement de $40 correspond à la première règle et se poursuit.

Où vont les approbations

Un résultat require_approval crée une Escalation : une unité de travail mise en pause en attente d'une décision humaine. Les Escalations arrivent dans le Decision Desk, où un relecteur autorisé voit l'action, ses attributs, les codes de raison et les conseils de remédiation, puis approuve ou rejette. L'approbation reprend l'exécution d'origine exactement là où elle s'était mise en pause ; le rejet l'arrête. La séquence complète (la requête, la décision, l'Escalation et le verdict du relecteur) est capturée sous forme de Lineage Record, vous offrant une trace défendable pour chaque action sous contrôle.

L'application des politiques chez KLA se situe au niveau de la couche applicative, au plus près de l'action de l'agent, là où le contexte métier comme le montant et le niveau du client est disponible. Des contrôles d'admission au niveau de l'infrastructure peuvent également appliquer la politique à la frontière de la plateforme, mais c'est le contrôle à l'exécution décrit ici qui gouverne le comportement des agents en place.