Policy as code per agenti AI
Policy as code esprime le regole operative in una forma valutabile dalla macchina. Ogni regola può essere versionata, testata, approvata e applicata a un’azione proposta da un agente prima che l’azione raggiunga uno strumento o un sistema di riferimento.
KLA valuta insieme agente, azione, strumento, autorizzazioni e contesto aziendale. Ogni Decision Request si risolve in allow, warn, require approval o block con codici motivazione espliciti.
- 01Azione propostaEmettere rimborso · 12.400 EUR
- 02Punto di controllo della policyrefund.manual_review
- 03Decisionerequire_approval
- 04Recordlin_01K0A7Y9 · policy v4.2.1
- Unità decisionale
- Decision Request
- Esiti
- Allow · Warn · Require approval · Block
- Superficie di creazione
- Policy Builder
- Superficie di runtime
- KLA Policy Engine
01: Concetto
Come funzionano i punti di controllo policy-as-code nella pratica
Una policy utile è abbastanza precisa da poter essere eseguita e abbastanza chiara da permettere a team di rischio, operations e ingegneria di riesaminarla insieme.
Policy as code esprime le regole operative in una forma valutabile dalla macchina. Ogni regola può essere versionata, testata, approvata e applicata a un’azione proposta da un agente prima che l’azione raggiunga uno strumento o un sistema di riferimento.
- Valutare il contesto completo dell’azione
- Le regole possono usare in un’unica decisione l’identità dell’agente, l’autorità delegata, lo strumento, i parametri, l’ambiente, il confine dei dati e gli attributi aziendali.
- Testare le regole prima della pubblicazione
- Le simulazioni eseguono Decision Requests rappresentative rispetto a una policy in bozza, così i team possono esaminare esiti e codici motivazione prima che una Release sia governata da tale policy.
- Restituire un esito operativo
- Il modello a quattro esiti fornisce al runtime un’istruzione esplicita. Un’attesa crea una Decision Request; un blocco impedisce all’azione di proseguire.
- Conservare la versione della policy
- Ogni verdetto registra la policy, la versione, le regole corrispondenti e i codici motivazione che hanno governato l’azione in quel momento.
02: Implementazione KLA
Come KLA implementa i punti di controllo policy-as-code
KLA porta un unico modello di policy dalla creazione collaborativa all’applicazione al momento della decisione e alla raccolta delle prove.
- 01
Modellare la regola operativa
Policy Builder definisce soggetto, azione, risorsa, condizioni ed esito con lo stesso vocabolario riconosciuto dagli operatori.
Risultato · Policy in bozza
- 02
Simulare azioni rappresentative
I casi di test coprono traffico ordinario, soglie, autorità mancante, dati soggetti a restrizioni e percorsi di eccezione.
Risultato · Risultati della simulazione
- 03
Approvare e pubblicare
La policy riesaminata viene versionata e pubblicata per il tenant, l’ambiente, gli agenti e gli strumenti previsti.
Risultato · Versione della policy pubblicata
- 04
Valutare al punto di controllo
KLA Policy Engine risolve ogni Decision Request prima del commit dell’azione governata e scrive il verdetto in Execution Lineage.
Risultato · Verdetto e codici motivazione
Esempio · Rimborso cliente
Una soglia diventa una decisione applicabile
Un agente di assistenza propone un rimborso superiore all’importo delegato all’elaborazione automatizzata. La policy crea un’attesa controllata al confine dell’azione.
Il rimborso rimane nel Process originale. KLA riprende l’azione in attesa dopo l’approvazione e collega la decisione della policy, la motivazione del revisore e il risultato a valle.
- Decision Request ricevutaricevuta
refunds.issue · 12.400 EUR · agente customer-resolution-eu
- Regola corrispondentein attesa
refund.manual_review.above_10000 · policy v4.2.1
- Revisore ha approvatoapprovata
Analista senior dei rimborsi · motivazione e prove allegate
- Esito registratoregistrata
Rimborso eseguito · risultato di origine correlato al Lineage Record
04: Record di evidenza
Cosa registra KLA per la revisione
Il verdetto diventa una prova durevole che la regola pubblicata ha operato sull’azione specifica.
| Livello del record | Evidenza acquisita | Finalità della revisione |
|---|---|---|
| Contesto decisionale | Agente, principal, azione, strumento, parametri, ambiente e attributi aziendali | Ricostruire i fatti valutati dalla policy |
| Autorità effettiva | Concessione dello strumento, confine dei dati, ruolo e istantanea dell’autorità | Mostrare il confine di accesso in vigore al momento della decisione |
| Verdetto della policy | ID della policy, versione, esito, regole corrispondenti e codici motivazione | Spiegare perché il runtime ha consentito, avvisato, sospeso o bloccato l’azione |
| Risultato | Decision Request, esito del revisore, risposta dello strumento e stato risultante | Collegare la regola all’effetto operativo finale |
05: Controlli collegati
Segui il percorso completo dell’azione governata
I quattro concetti operano insieme sulla stessa azione. Prosegui con il livello di controllo più vicino alla tua prossima domanda.
06: Riferimenti tecnici
Leggi i record esatti alla base di questo livello di controllo
Questi riferimenti supportano le affermazioni della pagina e collegano il comportamento runtime a schemi ed esempi pubblicati.
07: FAQ
Domande sui punti di controllo policy-as-code
Definizioni, comportamento runtime, integrazione e limiti delle evidenze per questo livello di controllo.
- Che cos’è policy as code per gli agenti AI?
- Policy as code è una rappresentazione versionata e verificabile delle regole che governano un’azione dell’agente. Valuta l’azione proposta e il relativo contesto prima dell’esecuzione e restituisce un esito di runtime esplicito.
- Quali esiti può restituire una policy KLA?
- KLA Policy Engine restituisce allow, warn, require approval o block. Require approval mette in pausa l’azione e crea una Decision Request in Decision Desk. Block impedisce che l’azione raggiunga lo strumento governato.
- Un team può testare una policy prima che governi azioni di produzione?
- Sì. Le simulazioni di Policy Builder riproducono Decision Requests rappresentative rispetto a una bozza. I team possono esaminare l’esito e le regole corrispondenti prima di approvare e pubblicare la policy.
- Policy as code richiede un unico framework per agenti?
- KLA accetta Decision Requests tramite punti di controllo SDK e API. Lo stesso modello di policy può governare agenti creati con framework e provider diversi.
- Come dimostra KLA quale policy ha governato un’azione?
- Il Lineage Record memorizza ID della policy, versione, verdetto, regole corrispondenti, codici motivazione e contesto dell’azione. Le approvazioni correlate e gli esiti a valle condividono identificatori di correlazione stabili.
Inizia da un’azione
Mettere un’azione rilevante dietro un punto di controllo della policy
Mappa con il team KLA l’azione, l’autorità, gli esiti e i campi di prova; quindi convalida la policy rispetto a richieste rappresentative.