Panoramica dell'architettura

Il KLA Control Plane è un livello di sicurezza runtime, audit e governance che governa-in-loco gli agenti AI aziendali. "Governare in loco" significa strumentare gli agenti che già esegui (catene LangChain, servizi FastAPI o codice interamente personalizzato) invece di migrarli su un nuovo runtime. KLA avvolge questi agenti con un sottile livello di strumentazione e una serie di piani sempre attivi che decidono se ogni azione è consentita, registrano cosa è accaduto e ne sigillano una prova crittografica.

Questa pagina è un modello mentale logico, non un diagramma infrastrutturale. Descrive i piani che uno sviluppatore, un operatore o un auditor deve comprendere e il percorso che una singola azione dell'agente compie attraverso di essi.

I piani in sintesi

KLA è organizzato in un numero ridotto di piani cooperanti. Ciascuno corrisponde a uno dei quattro pilastri del prodotto: Govern. Operate. Assure. Prove.

Come scorre un'azione

Ogni azione governata segue lo stesso percorso. L'agente chiama il KLA SDK prima di eseguire un passaggio sensibile (una chiamata a uno strumento, una scrittura su database, un pagamento). L'SDK apre uno span OpenTelemetry e invia una Decision Request al Policy Engine, che restituisce uno di quattro esiti in ordine di precedenza: allow, warn, require_approval o block. Un allow o un warn lascia procedere l'azione; un require_approval mette in pausa l'esecuzione e instrada un'Escalation verso il Decision Desk affinché una persona la approvi o la neghi; un block arresta l'azione immediatamente. Qualunque sia l'esito, lo span scorre attraverso il Collector fino all'Evidence Ledger.

flowchart LR
  A["Azione dell'agente"] --> SDK["KLA SDK<br/>strumentazione"]
  SDK --> PE{"Policy Engine<br/>decisione"}
  PE -->|allow / warn| EX["Esegui azione"]
  PE -->|require_approval| DD["Decision Desk<br/>revisione umana"]
  PE -->|block| ST["Arresta azione"]
  DD -->|approvata| EX
  DD -->|negata| ST
  EX --> COL["KLA Collector<br/>oscuramento PII"]
  ST --> COL
  DD --> COL
  COL --> LED["Evidence Ledger<br/>Merkle proof"]
  LED --> EB["Sealed Evidence Bundle"]

Il livello di strumentazione

Due pattern di deployment collegano i tuoi agenti a KLA:

• Govern in Place: aggiungi il KLA SDK al tuo codice esistente. Emette span OpenTelemetry asincroni ed esegue gate in-process, così una decisione di policy avviene inline prima dell'azione. Il tuo agente continua a girare dove già risiede.
• Run through KLA: instradi l'esecuzione dell'agente attraverso un proxy gestito tramite l'Executions API. KLA osserva e regola centralmente ogni passaggio, il che è utile quando non puoi modificare il codice dell'agente.

Entrambi i pattern producono la stessa telemetria e alimentano gli stessi piani a valle. Gli span portano attributi semantici GenAI che rendono leggibile il comportamento dell'agente: genai.agent.name, genai.system.instructions, genai.tool.name, genai.tool.parameters, genai.cost.usd e genai.token.usage.

from kla import KLA

kla = KLA(api_url="https://api.kla.digital", tenant="acme")

# Richiede una decisione prima di una chiamata sensibile a uno strumento.
decision = kla.decide(
    agent="claims-triage",
    action="execute_refund",
    attributes={"amount": 240.00, "currency": "USD"},
)

if decision.outcome == "allow":
    issue_refund()
elif decision.outcome == "require_approval":
    decision.wait()  # Resta in pausa finché il Decision Desk non risolve l'Escalation.

Il Policy Engine

KLA utilizza il KLA Policy Engine a livello applicativo per valutare le Decision Request. Le policy sono regole dichiarative che stabiliscono chi può fare cosa, a quali condizioni e quali controlli runtime devono applicarsi. Le crei in Policy Builder, esegui una Simulation sul traffico storico prima della pubblicazione, poi le compili in policy pack firmati: bundle a prova di manomissione che il motore carica a runtime. Ogni controllo si risolve nello stesso modello a quattro esiti, così una corrispondenza può consentire l'azione, registrare un avviso, mettere in pausa per l'approvazione umana o bloccare l'esecuzione.

La pipeline delle evidenze

Il percorso dei dati che produce le prove è deliberatamente lineare e unidirezionale:

flowchart LR
  S["span OpenTelemetry"] --> C["KLA Collector<br/>oscuramento PII"]
  C --> L["ledger ImmuDB<br/>in sola aggiunta, Merkle proof"]
  L --> B["Sealed Evidence Bundle"]
  B --> P["esportazione Control Pack"]

Gli span arrivano al KLA Collector, che oscura le PII (email, numeri di carta, segreti) prima che qualsiasi cosa venga archiviata. I record ripuliti vengono sottoposti ad hashing e ancorati in ImmuDB, un ledger crittografico in sola aggiunta: i record non possono essere modificati, eliminati o riordinati, e ciascuno è verificabile tramite un Merkle proof. Da lì, gli auditor esportano un Sealed Evidence Bundle (il record verificabile di una singola traccia, chiamato Lineage Record) o un Control Pack (un'esportazione di conformità mappata su un framework) dall'Evidence Room.

Multi-tenancy e percorso dei dati

KLA è multi-tenant by design. Ogni richiesta porta con sé un'identità tenant, e ogni record (Decision Request, Lineage Record, Escalation, ancoraggio di evidenza) è circoscritto a un singolo tenant. I chiamanti dichiarano il proprio tenant a ogni chiamata API:

curl https://api.kla.digital/v1/decisions \
  -H "Authorization: Bearer <token>" \
  -H "x-tenant-id: <tenant>"

L'isolamento dei tenant è applicato a livello dei dati, così le policy, le tracce e le evidenze di un tenant non sono mai visibili a un altro. Lo stesso confine si applica end to end: la telemetria degli agenti di un tenant confluisce solo nel ledger di quel tenant e affiora solo nella Console di quel tenant.

I moduli della Console

I piani vengono guidati e ispezionati attraverso sette moduli web, ciascuno una finestra su una parte del flusso:

• Command: la superficie principale per lo stato di salute degli agenti in tempo reale e l'attività recente.
• Agents: l'Agent Registry e il ciclo di vita: una Release (versione del workflow), un Rollout (deployment) e il Rollback.
• Policy Builder: crea, simula e pubblica le policy.
• Decision Desk: risolvi le Escalations in sospeso con il contesto completo.
• Lineage Explorer: ripercorri qualsiasi Lineage Record passo dopo passo.
• Assurance Center: monitora la deriva tramite gli Assurance Alerts e agisci su un Remediation Plan (il pilastro "Assure").
• Evidence Room: esporta Sealed Evidence Bundles e Control Packs.

Dove andare ora

Inizia dai due concetti fondamentali che questa panoramica si limita ad abbozzare: Esecuzione regolata da policy per il modello decisionale a quattro esiti e Evidence-by-Default per il ledger crittografico. Poi esplora i moduli in dettaglio, Policy Builder, Decision Desk, Lineage Explorer ed Evidence Room, oppure collega un agente con il Python SDK o il Node SDK.