Policy Builder

Policy Builder è lo spazio di authoring del KLA Control Plane, disponibile alla route /policy-studio. Il KLA Control Plane è un livello di sicurezza, audit e governance a runtime che opera govern-in-place per gli agenti AI aziendali: applichi la strumentazione ai tuoi agenti esistenti invece di riportarli su una nuova piattaforma. Policy Builder è dove scrivi le regole che decidono cosa quegli agenti possono fare. Ogni azione significativa di un agente, che si tratti di emettere un rimborso, inviare un documento per la revisione o chiamare un'API esterna, viene verificata rispetto alla policy che pubblichi qui prima di essere eseguita. Questa pagina spiega come configurare una policy, i due modi per modificarla, come la Simulation dimostra il suo comportamento prima della pubblicazione e cos'è un policy pack firmato.

Chi lo usa

Policy Builder è un terreno condiviso da due ruoli. I responsabili di compliance, rischio e audit sono titolari dell'intento (cosa deve essere approvato, cosa deve essere bloccato, dove collocare le soglie) e sempre più spesso scrivono le regole direttamente. Gli sviluppatori e gli integratori sono titolari della precisione: gli esatti attributi, condizioni e reason code che il runtime valuta. Lo spazio di lavoro è progettato in modo che entrambi possano lavorare sulla stessa bozza senza bloccarsi a vicenda: un autore non tecnico può esprimere un intento e uno sviluppatore può perfezionare la condizione sottostante.

Configurazione guidata dall'intento

Non parti da un file YAML vuoto. Policy Builder si apre con le categorie di intento: punti di partenza in linguaggio naturale che predispongono l'impalcatura di una regola funzionante che poi affini.

• Instradare in base alla sensibilità: indirizza le azioni a maggior rischio su un percorso più rigoroso.
• Richiedere l'approvazione sulle operazioni ad alto rischio: metti in pausa un'azione per una decisione umana.
• Bloccare un'azione di uno strumento: nega del tutto una specifica capacità, come una scrittura su database.
• Applicare i confini dei dati: mantieni i dati regolamentati all'interno di una regione o di un sistema approvati.

Ogni intento produce una regola in bozza con la struttura corretta e impostazioni predefinite sensate. Colleghi gli attributi di business rilevanti per il tuo caso d'uso, come l'importo della transazione, la fascia del cliente e la classificazione del documento, e imposti le soglie.

Editor visuale o YAML grezzo della regola

Policy Builder ti offre due viste sincronizzate della stessa regola:

• Generatore visuale di condizioni: assembla le condizioni a partire da campi, operatori e valori senza scrivere YAML. Ideale per un authoring rapido e per i revisori che vogliono leggere l'intento, non la sintassi.
• Editor YAML grezzo: modifica direttamente la definizione sottostante della regola per la massima espressività, comprese condizioni composte, controlli a runtime, reason code, remediation e percorsi di approvazione.

Entrambe le viste scrivono sulla stessa bozza, così puoi abbozzare un intento visivamente e passare allo YAML per completarlo.

# 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 decisione require_approval è ciò che dice a KLA di mettere in pausa l'esecuzione e instradare l'azione al Decision Desk. Una decisione block fermerebbe l'azione del tutto.

Simula prima di pubblicare

Una bozza non passa mai direttamente al runtime. Esegui una Simulation: una prova di test della policy che riproduce Decision Request rappresentative (un'azione più il suo contesto) rispetto alla bozza e mostra come ciascuna si risolve. Il modello decisionale di KLA prevede quattro esiti in ordine di precedenza:

La Simulation ti permette di confermare, prima che qualsiasi cosa sia in produzione, che un rimborso da $420 viene messo in pausa e un rimborso da $40 passa, senza toccare un sistema in esecuzione. KLA blocca la pubblicazione di qualsiasi bozza che non supera il lint, così un esito require_approval o block a cui manca il reason code o le indicazioni di remediation viene intercettato qui, non in produzione.

Policy pack compilati e firmati

Quando una bozza validata viene pubblicata, KLA la compila in un policy pack firmato: un bundle versionato e firmato crittograficamente che il runtime carica per valutare la policy. La firma garantisce che la valutazione sia a prova di manomissione, poiché il runtime applica solo i pack che è in grado di verificare, e la versionatura significa che ogni decisione può essere ricondotta all'esatta policy che l'ha prodotta. La compilazione rende inoltre la valutazione abbastanza veloce da poter stare nel percorso delle azioni live degli agenti.

flowchart LR
  A["Modifica di intento o YAML"] --> B["Policy in bozza"]
  B --> C{"Simulation"}
  C -->|esiti errati| B
  C -->|esiti corretti| D["Pubblica"]
  D --> E["Policy pack firmato"]
  E --> F["Applicazione a runtime"]

Come si collega

Policy Builder è l'origine delle regole; altri due moduli sono il punto in cui quelle regole entrano in vigore.

• Policy-Gated Execution è il meccanismo a runtime che valuta ogni Decision Request rispetto al pack che hai pubblicato e restituisce uno dei quattro esiti. Le policy che scrivi qui sono esattamente ciò che esso applica.
• Decision Desk è dove arriva un esito require_approval. Quando una regola mette in pausa un'azione, KLA apre un'Escalation e la instrada lì perché un revisore autorizzato la approvi o la rifiuti.

Scrivi la regola in Policy Builder, dimostrala con la Simulation, pubblica il pack firmato e da quel momento il runtime governa ogni azione corrispondente.