Policy as code pour les agents IA
Policy as code exprime les règles opérationnelles dans une forme évaluable par machine. Chaque règle peut être versionnée, testée, approuvée et appliquée à une action d’agent proposée avant que l’action atteigne un outil ou un système de référence.
KLA évalue ensemble l’agent, l’action, l’outil, les autorisations et le contexte métier. Chaque Decision Request se résout en allow, warn, require approval ou block avec des codes de motif explicites.
- 01Action proposéeÉmettre un remboursement · 12 400 EUR
- 02Point de contrôle de politiquerefund.manual_review
- 03Décisionrequire_approval
- 04Enregistrementlin_01K0A7Y9 · policy v4.2.1
- Unité de décision
- Decision Request
- Issues
- Allow · Warn · Require approval · Block
- Surface de création
- Policy Builder
- Surface d’exécution
- KLA Policy Engine
01: Concept
Comment fonctionnent les points de contrôle policy-as-code en pratique
Une politique utile est assez précise pour être exécutée et assez claire pour que les équipes risques, opérations et ingénierie la révisent ensemble.
Policy as code exprime les règles opérationnelles dans une forme évaluable par machine. Chaque règle peut être versionnée, testée, approuvée et appliquée à une action d’agent proposée avant que l’action atteigne un outil ou un système de référence.
- Évaluer le contexte complet de l’action
- Les règles peuvent utiliser dans une même décision l’identité de l’agent, l’autorité déléguée, l’outil, les paramètres, l’environnement, la limite de données et les attributs métier.
- Tester les règles avant publication
- Les simulations exécutent des Decision Requests représentatives sur une politique en brouillon afin que les équipes examinent les issues et les codes de motif avant qu’une Release soit gouvernée par cette politique.
- Renvoyer une issue opérationnelle
- Le modèle à quatre issues donne au runtime une instruction explicite. Une attente crée une Decision Request ; un blocage empêche l’action de se poursuivre.
- Conserver la version de la politique
- Chaque verdict enregistre la politique, la version, les règles correspondantes et les codes de motif qui ont gouverné l’action à cet instant.
02: Mise en œuvre KLA
Comment KLA met en œuvre les points de contrôle policy-as-code
KLA porte un modèle de politique unique de la création collaborative à l’application au moment de la décision et à la capture des preuves.
- 01
Modéliser la règle opérationnelle
Policy Builder définit le sujet, l’action, la ressource, les conditions et l’issue avec le même vocabulaire que les opérateurs reconnaissent.
Résultat · Politique en brouillon
- 02
Simuler des actions représentatives
Les cas de test couvrent le trafic ordinaire, les seuils, l’autorité absente, les données restreintes et les parcours d’exception.
Résultat · Résultats de simulation
- 03
Approuver et publier
La politique révisée est versionnée et publiée pour le tenant, l’environnement, les agents et les outils prévus.
Résultat · Version de politique publiée
- 04
Évaluer au point de contrôle
KLA Policy Engine résout chaque Decision Request avant que l’action gouvernée soit validée et inscrit le verdict dans Execution Lineage.
Résultat · Verdict et codes de motif
Exemple · Remboursement client
Un seuil devient une décision applicable
Un agent de service propose un remboursement supérieur au montant délégué au traitement automatisé. La politique crée une attente contrôlée à la limite de l’action.
Le remboursement reste dans le Process d’origine. KLA reprend l’action en attente après approbation et relie la décision de politique, la justification du réviseur et le résultat en aval.
- Decision Request reçuereçue
refunds.issue · 12 400 EUR · agent customer-resolution-eu
- Règle correspondanteen attente
refund.manual_review.above_10000 · policy v4.2.1
- Réviseur approuveapprouvée
Analyste senior des remboursements · justification et preuve jointes
- Issue enregistréeenregistrée
Remboursement exécuté · résultat source corrélé au Lineage Record
04: Dossier de preuve
Ce que KLA enregistre pour examen
Le verdict devient une preuve durable que la règle publiée a opéré sur l’action précise.
| Couche d’enregistrement | Preuve capturée | Objet de l’examen |
|---|---|---|
| Contexte de décision | Agent, principal, action, outil, paramètres, environnement et attributs métier | Reconstruire les faits évalués par la politique |
| Autorité effective | Autorisation d’outil, limite de données, rôle et instantané d’autorité | Montrer la limite d’accès en vigueur au moment de la décision |
| Verdict de politique | ID de politique, version, issue, règles correspondantes et codes de motif | Expliquer pourquoi le runtime a permis, signalé, retenu ou bloqué l’action |
| Résultat | Decision Request, issue du réviseur, réponse de l’outil et état résultant | Relier la règle à l’effet opérationnel final |
05: Contrôles liés
Suivre le parcours complet de l’action gouvernée
Les quatre concepts interviennent ensemble sur une même action. Continuez avec la couche de contrôle la plus proche de votre prochaine question.
06: Références techniques
Lire les enregistrements exacts derrière cette couche de contrôle
Ces références étayent les affirmations de cette page et relient le comportement du runtime aux schémas et exemples publiés.
07: FAQ
Questions sur les points de contrôle policy-as-code
Définitions, comportement du runtime, intégration et limites de preuve de cette couche de contrôle.
- Qu’est-ce que policy as code pour les agents IA ?
- Policy as code est une représentation versionnée et testable des règles qui gouvernent une action d’agent. Elle évalue l’action proposée et son contexte avant l’exécution, puis renvoie une issue explicite du runtime.
- Quelles issues une politique KLA peut-elle renvoyer ?
- KLA Policy Engine renvoie allow, warn, require approval ou block. Require approval suspend l’action et crée une Decision Request dans Decision Desk. Block empêche l’action d’atteindre l’outil gouverné.
- Une équipe peut-elle tester une politique avant qu’elle gouverne des actions de production ?
- Oui. Les simulations de Policy Builder rejouent des Decision Requests représentatives sur un brouillon. Les équipes peuvent examiner l’issue et les règles correspondantes avant d’approuver et de publier la politique.
- Policy as code exige-t-il un seul framework d’agents ?
- KLA accepte les Decision Requests par des points de contrôle SDK et des API. Le même modèle de politique peut gouverner des agents construits avec différents frameworks et fournisseurs.
- Comment KLA prouve-t-il quelle politique a gouverné une action ?
- Le Lineage Record stocke l’ID de politique, la version, le verdict, les règles correspondantes, les codes de motif et le contexte de l’action. Les approbations et issues en aval liées partagent des identifiants de corrélation stables.
Commencez par une action
Placez une action conséquente derrière un point de contrôle de politique
Cartographiez l’action, l’autorité, les issues et les champs de preuve avec l’équipe KLA, puis validez la politique sur des demandes représentatives.