Cosa il key management bancario insegna sugli eval harness per agenti

Perché conta

La maggior parte dei sistemi agentici in produzione oggi viene valutata come si valutano le demo: un umano legge una traccia, alza le spalle, rilascia. In domini regolamentati — banking, fintech, compliance, assicurazioni — quel pattern non è rilasciabile. La domanda non è "l'agente sembra ragionevole?", ma "possiamo dimostrare, a posteriori, perché ha fatto quello che ha fatto — e rieseguire gli stessi input per riprodurlo?"

Per gran parte degli anni pre-2024 ho costruito architetture wallet, prototipi UI Lightning e soluzioni di custodia per banche. Il modello mentale che mi è rimasto non è "crittografia per la crittografia" ma sistemi progettati perché ogni affermazione possa essere verificata da chi non si fida di te. Quel mindset si trasferisce quasi 1-a-1 agli agenti LLM in produzione, ed è il gap che vedo più spesso nei team che vengono dall'ingegneria web.

Ecco le cinque discipline che porto con me, con la mappatura sui sistemi agentici.

1. Stato persistente, non contesto effimero

Banking: una chiave non vive mai solo in memoria. Esiste in un HSM, in un HSM di backup, in un set di shard cifrati e in un audit log che registra ogni accesso. Niente di effimero è considerato affidabile.

Parallelo agentico: lo stato dell'agente va persistito prima di qualsiasi tool call con effetti collaterali, non dopo. Il checkpointer di LangGraph è il livello minimo. Senza stato persistente non puoi rispondere a "cosa sapeva l'agente al passo N?" — che è la prima domanda di ogni post-mortem.

# Non così:
result = agent.invoke(input)  # stato solo in RAM

# Così:
checkpoint = graph.invoke(
    input,
    config={"configurable": {"thread_id": session_id}},  # persistito
)

Costo: ~100ms per step. Beneficio: puoi replay, audit e debug di ogni traiettoria.

2. Failure mode deterministici

Banking: le operazioni sulle chiavi o riescono o falliscono in modo pulito. Non esiste "successo parziale". Una firma a metà è un incidente di sicurezza.

Parallelo agentico: ogni tool contract deve avere failure mode tipizzati ed esaustivi. Niente except Exception: pass. Niente "tanto l'LLM riprova" senza terminazione esplicita. Uso schema Pydantic per ogni I/O di tool, con union type per i casi di errore che l'LLM deve gestire:

class SearchResult(BaseModel):
    status: Literal["ok", "rate_limited", "empty", "auth_error"]
    hits: list[Hit] = []
    retry_after_s: int | None = None

L'LLM può ragionare su status: rate_limited → aspetta. Non può ragionare su uno stack trace mezzo cotto.

3. Dual control per azioni ad alto impatto

Banking: muovere denaro sopra una soglia richiede due autorizzazioni. Nessuna chiave singola, nessun umano singolo, può farlo da solo.

Parallelo agentico: ogni azione con impatto finanziario, legale o customer-facing deve passare da un human-in-the-loop checkpoint OPPURE da un agente validator deterministico — non lo stesso agente che l'ha proposta. Questo è il singolo gap più grande nei deployment agentici enterprise che faccio audit. I team rilasciano agenti che mandano email, committano codice, aprono ticket senza una seconda firma.

La primitiva interrupt di LangGraph è il meccanismo. Usala su: comunicazioni esterne, scritture su sistemi di record, qualunque azione reversibile solo con scuse.

4. Audit trail come evidenza, non log

Banking: ogni azione produce un'evidenza che reggerebbe in uno studio di un regolatore. Significa firmata, timestamped, tamper-evident — non solo "abbiamo i log".

Parallelo agentico: il tuo eval harness e il tuo trace store di produzione sono lo stesso artefatto, ruotato nel tempo. Ogni run dell'agente deve scrivere: input, hash del prompt template, model name + version, invocazioni dei tool con argomenti e ritorni, output finale e un timestamp di chain-of-custody. OpenTelemetry + LangSmith è adeguato. Una tabella postgres con colonne jsonb e un constraint append-only è adeguata. Cercare con grep nelle trascrizioni Slack non lo è.

Perché conta: le regressioni nei sistemi LLM sono quasi sempre invisibili nelle metriche aggregate ma evidenti nei singoli trace. Senza evidenza riproducibile diagnostichi a sentimento.

5. Recovery playbook per i fallimenti, non solo per i successi

Banking: ogni servizio di custodia ha un runbook per compromissione di chiavi, perdita di chiavi, compromissione dell'operatore. Il playbook viene scritto prima dell'incidente, non dopo.

Parallelo agentico: prima del rilascio, scrivi i failure mode che vedrai davvero in produzione e l'azione di recovery per ognuno:

• Modello deprecato / rate-limited → fallback model routing
• Tool che restituisce output malformato → circuit breaker + escalation
• Prompt injection rilevata → abort della traiettoria + voce di audit
• State store non disponibile → modalità read-only, non degrado silenzioso

Se non sai nominare tre failure mode plausibili con recovery path scritti, non sei pronto per la produzione.

Il framing di categoria

Chiamo questa cosa sistemi agentici verificabili per domini regolamentati. Non sono "evals" (Hamel Husain ha quel framing molto bene, e consiglio il suo lavoro). È più stretto e più specifico: sistemi agentici progettati dal giorno uno con gli stessi vincoli che la custodia bancaria impone — durabilità, determinismo, dual control, audit con valore probatorio, recovery.

È dove penso si posizionerà la prossima ondata di adozione enterprise degli LLM, perché i frutti bassi più ovvi (chatbot di customer support, Q&A su knowledge base interne) sono in larga parte presi dalle piattaforme orizzontali. Il budget rimanente si sposta su workflow dove il blast radius di un'azione sbagliata è reale — e questo significa che la soglia di valutazione si sposta da "sembra ragionevole?" a "possiamo dimostrare perché ha fatto quello che ha fatto?".

Se stai valutando un sistema agentico contro queste cinque discipline e trovi dei gap, scrivimi. Volentieri due chiacchiere.