Pattern di deployment e configurazione

KLA Control Plane è un livello di sicurezza runtime, audit e governance per agenti AI aziendali, applicato direttamente dove gli agenti operano. Strumenti gli agenti e le API che già esegui (LangChain, FastAPI o codice personalizzato) invece di doverli riportare su una nuova piattaforma. KLA supporta due pattern di integrazione, che puoi combinare all'interno di un singolo deployment: Govern in Place avvolge il tuo runtime esistente con l'SDK OpenTelemetry, mentre Run through KLA instrada l'esecuzione attraverso un proxy gestito tramite la Executions API. Questa pagina mette a confronto i due approcci, mostra come funziona ciascuno e ti aiuta a scegliere.

Confronto delle topologie

Pattern 1: Govern in Place

I tuoi agenti continuano a operare nel proprio ambiente. L'SDK di KLA emette span OpenTelemetry in modo asincrono verso il Control Plane, così la telemetria non si trova mai sul percorso della richiesta. L'enforcement avviene ai checkpoint: i punti del tuo codice in cui chiedi a KLA se un'azione è consentita prima di eseguirla. A ogni checkpoint il motore di policy restituisce uno dei quattro esiti, valutati in ordine di precedenza: allow, warn, require_approval o block. Un esito require_approval mette in pausa l'esecuzione e instrada una Escalation verso il Decision Desk, l'interfaccia di revisione umana di KLA, dove un revisore risolve la Decision Request.

flowchart LR
  A["La tua app agente (avvolta dall'SDK)"] --> B["Provider LLM"]
  A -->|checkpoint| C{"Decisione di policy"}
  C -->|allow / warn| A
  C -->|require_approval| D["Decision Desk"]
  C -->|block| E["Azione negata"]
  A -. span asincroni .-> F["KLA Control Plane"]

Istruzioni di configurazione

1. Installa l'SDK per il linguaggio della tua applicazione (Python o Node.js).
2. Inizializza l'SDK nel punto di ingresso dell'applicazione, così gli span fluiscono verso il Control Plane.
3. Avvolgi le azioni sensibili degli strumenti o i completamenti del modello in un checkpoint di KLA.

# Govern in Place: valuta un'azione a un checkpoint
from kla_sdk import KLACheckpoint

checkpoint = KLACheckpoint(agent_id="agt_9f81a7")

# Se la policy restituisce require_approval, questo blocca e apre una
# Escalation sul Decision Desk finché un revisore non la risolve.
decision = checkpoint.evaluate_action(
    tool="process_refund",
    context={"amount": 1250.00},
)

if decision.outcome == "allow":
    execute_refund()
else:
    raise PermissionError(f"Refund {decision.outcome} by governance policy")

Pattern 2: Run through KLA

In questo caso il tuo client invia le richieste alla Executions API invece di chiamare direttamente un provider di modelli. KLA risolve le credenziali del provider dal Secrets Vault, applica la policy inline, esegue l'agente sul modello e registra il Lineage Record, il tutto in un unico passaggio consolidato. Poiché l'enforcement è inline, un esito block interrompe la richiesta prima che venga eseguito qualsiasi strumento.

flowchart LR
  A["Frontend client (Chat UI)"] -->|Executions API| B["KLA Control Plane"]
  B --> C{"Decisione di policy"}
  C -->|allow / warn| D["Provider LLM"]
  C -->|require_approval| E["Decision Desk"]
  C -->|block| F["Richiesta rifiutata"]
  D --> B
  B -->|risposta + Lineage Record| A

Istruzioni di configurazione

1. Memorizza le credenziali del tuo provider di modelli nel Secrets Vault.
2. Registra l'agente, con le sue istruzioni di sistema, i parametri e gli strumenti, nell'Agent Registry.
3. Punta il tuo client sulla Executions API invece che su OpenAI o Anthropic.

curl -X POST https://api.kla.digital/v1/executions \
  -H "Authorization: Bearer $KLA_ACCESS_TOKEN" \
  -H "x-tenant-id: $KLA_TENANT" \
  -H "Content-Type: application/json" \
  -d '{
    "agentId": "agt_9f81a7",
    "input": { "prompt": "Summarize outstanding contracts" }
  }'

Un esito require_approval restituisce un riferimento a una Escalation e uno stato in attesa; interroga l'esecuzione tramite polling o sottoscrivi gli eventi del Decision Desk per proseguire una volta che un revisore ha approvato.

Come scegliere un pattern

Per sviluppatori e integratori che hanno già un agente in produzione, ad esempio un workflow di triage dei sinistri in LangChain che gestisce già traffico reale, Govern in Place è la strada più rapida: aggiungi l'SDK e qualche checkpoint, non modifichi il routing e mantieni intatto il tuo budget di latenza. Per gli operatori di piattaforma che avviano un agente greenfield o un'interfaccia di chat standard, Run through KLA elimina la maggior quantità di codice, perché KLA si occupa dell'iniezione delle credenziali, dell'enforcement inline e della compilazione delle tracce dietro un unico endpoint. Per i responsabili di compliance e rischio, la decisione è rassicurantemente neutra: entrambi i pattern alimentano lo stesso motore di policy e la stessa pipeline di evidenze sigillate, perciò le tue esportazioni di Control Pack e i tuoi Sealed Evidence Bundle appaiono identici, indipendentemente da come è collegato l'agente. La maggior parte delle aziende adotta entrambi gli approcci, strumentando i sistemi legacy dove operano e instradando i nuovi agenti tramite KLA, governandoli da un unico Control Plane.