Esecuzione regolata da policy

Quando un agente AI aziendale tenta di compiere un'azione rilevante (emettere un rimborso, inviare un documento per revisione, chiamare una API esterna), KLA Control Plane valuta quell'azione rispetto alla policy prima che venga eseguita. KLA Control Plane è un livello di sicurezza, audit e governance del runtime che governa gli agenti AI dove già si trovano: applichi la strumentazione ai tuoi agenti esistenti invece di ricostruirli su una nuova piattaforma. L'esecuzione regolata da policy è il meccanismo che decide, in tempo reale, se un'azione procede, procede con un avviso, viene messa in pausa per un intervento umano o viene bloccata. Questa pagina illustra il modello decisionale e come un'azione messa in pausa diventa una Escalation instradata al Decision Desk.

I quattro esiti decisionali

Ogni valutazione di policy in KLA si risolve in esattamente un esito. Gli esiti sono ordinati per precedenza: quando più regole corrispondono a un'azione, prevale l'esito applicabile più forte.

La precedenza rende il modello fail-closed e prevedibile. Se una regola ampia dice allow ma una regola più specifica e con precedenza più alta dice require_approval, l'azione viene messa in pausa. Un singolo block ovunque nell'insieme delle regole corrispondenti interrompe l'azione, indipendentemente da quante regole allow abbiano anch'esse corrisposto.

flowchart LR
  A["Azione dell'agente"] --> B{"Decisione del Policy Engine"}
  B -->|allow| C["Esegui"]
  B -->|warn| D["Esegui e registra l'avviso"]
  B -->|require_approval| E["Crea Escalation"]
  E --> F["Decision Desk"]
  F -->|approvato| C
  F -->|rifiutato| G["Interrompi azione"]
  B -->|block| G

Come viene valutata un'azione

L'agente (o l'SDK di KLA per suo conto) invia una Decision Request: l'azione più il suo contesto. Il contesto comprende l'agente chiamante, lo strumento invocato, i parametri e qualsiasi attributo di business che alleghi (importo della transazione, livello del cliente, classificazione del documento). KLA valuta questa richiesta rispetto alle policy attualmente pubblicate per il tuo tenant e restituisce uno dei quattro esiti.

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" }
  }'

Una risposta require_approval include l'identificativo della Escalation che è stata aperta, così la tua integrazione può mostrare all'utente finale che l'azione è in attesa di revisione, invece di apparire come un errore.

{
  "outcome": "require_approval",
  "reasonCodes": ["REFUND_OVER_THRESHOLD"],
  "remediation": "I rimborsi superiori a $100 richiedono un revisore. Questa richiesta è stata instradata al Decision Desk.",
  "escalationId": "esc_01HZ8K..."
}

Codici di motivazione e rimedio

Ogni decisione diversa da allow porta con sé due elementi oltre al verdetto: uno o più codici di motivazione e una guida al rimedio. Un codice di motivazione è un identificativo stabile e leggibile dalla macchina (ad esempio REFUND_OVER_THRESHOLD) che spiega perché si è arrivati a quell'esito. La guida al rimedio è un'istruzione breve e leggibile dall'uomo su cosa fare in seguito.

Questo abbinamento è utile a tutti e tre i destinatari. Gli sviluppatori si diramano sui codici di motivazione invece di analizzare il testo descrittivo. I revisori del Decision Desk vedono un contesto in linguaggio naturale per l'azione che hanno davanti. I responsabili della compliance ottengono un vocabolario coerente che si mappa in modo pulito sui framework di controllo. I codici di motivazione e il rimedio sono obbligatori per gli esiti warn, require_approval e block, in modo che nessun diniego o pausa sia mai un vicolo cieco silenzioso.

Il Policy Engine

KLA valuta le policy a livello applicativo, vicino all'azione dell'agente e al suo contesto di business. Il policy engine combina due tipi di controlli:

• I controlli di accesso decidono se il chiamante può usare lo strumento, la fonte dati, il workflow o l'azione.
• I controlli a runtime valutano l'azione nel contesto (lo strumento e i suoi argomenti, la sua destinazione, i metadati del modello e gli attributi di business che alleghi) rispetto al policy pack che hai pubblicato.

Entrambi i tipi di controllo si risolvono negli stessi quattro esiti rivolti al cliente: allow, warn, require_approval o block. Prevale l'esito corrispondente più forte, quindi un controllo a runtime può comunque mettere in pausa o interrompere un'azione anche quando il chiamante sarebbe altrimenti autorizzato a usare lo strumento.

# 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

In questo esempio, un rimborso di $420 corrisponde alla seconda regola e si risolve in require_approval, mettendo in pausa l'esecuzione e aprendo una Escalation. Un rimborso di $40 corrisponde alla prima regola e procede.

Dove vanno le approvazioni

Un esito require_approval crea una Escalation: un'unità di lavoro in pausa in attesa di una decisione umana. Le Escalation arrivano nel Decision Desk, dove un revisore autorizzato vede l'azione, i suoi attributi, i codici di motivazione e la guida al rimedio, quindi approva o rifiuta. L'approvazione riprende l'esecuzione originale esattamente nel punto in cui si era fermata; il rifiuto la interrompe. L'intera sequenza (la richiesta, la decisione, la Escalation e il verdetto del revisore) viene acquisita come Lineage Record, fornendoti una traccia difendibile per ogni azione regolata.

L'applicazione delle policy in KLA risiede a livello applicativo, vicino all'azione dell'agente, dove è disponibile il contesto di business come l'importo e il livello del cliente. Anche i controlli di ammissione a livello di infrastruttura possono applicare policy al confine della piattaforma, ma il gating a runtime descritto qui è ciò che governa il comportamento dell'agente dove già si trova.