Lezioni dalla gestione delle chiavi bancarie per gli harness di eval degli agenti

Perché conta

Molti sistemi agent che vedo vengono valutati come demo: una persona legge una trascrizione, accetta il risultato e rilascia. Nei domini regolamentati — banking, fintech, compliance, insurance — non rilascerei questo schema. La domanda utile non è «l'agent sembra corretto?» È: «posso dimostrare, a posteriori, perché ha fatto ciò che ha fatto — e rieseguire gli stessi input per riprodurlo?»

Prima del 2024 ho lavorato soprattutto ad architetture wallet, prototipi di interfaccia Lightning e soluzioni di custodia per banche. Il principio che ho portato con me non era la «crittografia fine a se stessa», ma progettare sistemi in cui anche chi non si fida di me possa verificare ogni affermazione. Applico lo stesso principio agli agent LLM in produzione. È una lacuna che vedo spesso nei team provenienti dallo sviluppo web.

Di seguito riporto cinque discipline che trasferisco, con la corrispondente mappatura ai sistemi agent.

1. Stato persistente, non contesto transitorio

Banking: una chiave non risiede 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 volta che viene utilizzata. Non considero lo stato effimero come stato fidato.

Analogia con gli agenti: persisto lo stato dell'agente prima di qualsiasi tool call con side effect, non dopo. Il checkpointer di LangGraph è una base pratica. Senza stato persistente, non posso rispondere a «cosa sapeva l'agente allo step N?» — una domanda che vedo spesso nelle post-incident review.

# Not this:
result = agent.invoke(input)  # state only in RAM

# This:
checkpoint = graph.invoke(
    input,
    config={"configurable": {"thread_id": session_id}},  # persisted
)

Costo: latenza e storage aggiuntivi per step. Beneficio: posso fare replay, audit e debug di ogni traiettoria.

2. Modalità di failure deterministiche

Banking: le operazioni sulle chiavi hanno successo o falliscono in modo pulito. Non voglio un percorso di successo parziale. Una firma parziale è un incidente di sicurezza.

Analogia con gli agenti: faccio in modo che ogni contratto del tool esponga modalità di failure tipizzate ed esaustive. Nessun except Exception: pass. Nessun «lascia semplicemente che l'LLM riprovi» senza terminazione esplicita. Uso schema Pydantic per ogni tool I/O, con union type per i casi di failure che prevedo l'LLM debba 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 → attendere. Non può ragionare in modo affidabile su un exception trace non strutturato.

3. Dual control per azioni ad alto impatto

Banking: spostare denaro oltre una soglia richiede due autorizzazioni. Nessuna singola chiave, e nessuna singola persona, può farlo da sola.

Analogia con gli agenti: tratto qualsiasi azione con impatto finanziario, legale o rivolto al cliente come un'azione che richiede un checkpoint human-in-the-loop o un agente di validazione separato con regole fisse — non lo stesso agente che l'ha proposta. Vedo spesso questa lacuna nei deployment enterprise di agenti. I team rilasciano agenti che inviano automaticamente email, fanno automaticamente commit di codice o aprono automaticamente ticket senza una seconda firma.

La primitiva interrupt di LangGraph è il meccanismo che uso. La uso per comunicazioni esterne, scritture nei system of record e qualsiasi cosa influenzi sistemi esterni o stato visibile al cliente.

4. Audit trail come evidenza, non log

Banking: ogni azione produce evidenza che sarebbe utile durante una review di un regolatore. Questo significa firmata, con timestamp e a prova di manomissione — non soltanto «esistono dei log».

Analogia con gli agenti: voglio che l'eval harness e il production trace store condividano nel tempo lo stesso schema e lo stesso modello di evidenza. Voglio che ogni esecuzione dell'agente scriva: input, hash del prompt template, nome + versione del modello, tool invocation con argomenti e return, output finale e un timestamp chain-of-custody. Ho usato OpenTelemetry + LangSmith in alcuni team come base funzionale. Ho anche trovato funzionale, in setup più ristretti, una tabella Postgres con colonne jsonb e un vincolo append-only. Non considero le trascrizioni Slack un evidence store affidabile.

Perché conta: le regressioni nei sistemi LLM possono essere difficili da vedere nelle metriche aggregate, ma visibili in trace specifici. Senza evidenza riproducibile tramite replay, durante la diagnosi mi resta solo fare ipotesi.

5. Recovery playbook per il failure, non solo per il successo

Banking: ogni servizio custodial dispone di un runbook per compromissione della chiave, perdita della chiave e compromissione dell'operatore. Voglio che il playbook sia scritto prima dell'incident, non dopo.

Analogia con gli agenti: prima di rilasciare, metto per iscritto le modalità di failure che prevedo di vedere in produzione e l'azione di recovery per ciascuna:

• Modello deprecato / rate-limited → fallback model routing
• Tool che restituisce output malformato → circuit breaker + escalation
• Prompt injection rilevata → trajectory abort + audit entry
• State store non disponibile → modalità read-only, non degradazione silenziosa

Se non riesco a nominare tre modalità di failure plausibili con percorsi di ripristino scritti, non rilascerei il sistema.

Il termine che uso

Lo chiamo verifiable agent systems for regulated domains. Non sono «evals» (Hamel Husain presidia bene questo framing e consiglio il suo lavoro). È più ristretto: sistemi agent progettati fin dal primo giorno attorno ai vincoli che impone anche la custody bancaria — durabilità, determinismo, dual control, audit probatorio, recovery.

La mia opinione è che parte del lavoro enterprise sugli LLM si sposterà in questa categoria, man mano che casi d'uso a rischio inferiore, come customer support bot e Q&A sulla conoscenza interna, verranno coperti adeguatamente da piattaforme orizzontali. Per workflow in cui gli errori hanno impatto materiale, cambio la domanda di valutazione da «sembra corretto» a «posso dimostrare perché ha fatto ciò che ha fatto».

Se stai valutando un sistema agent rispetto a queste cinque discipline e riscontri lacune, scrivimi.

FAQ

Perché persistere lo stato dell'agent prima delle tool call con side effect?

Persisto lo stato dell'agent prima di qualsiasi tool call con side effect perché altrimenti non posso rispondere a cosa sapeva l'agent allo step N. Lo stato persistente aggiunge latenza e storage per step, ma rende possibili replay, audit e debug della traiettoria dopo un incident.

Come dovrebbero essere rappresentati i failure dei tool per un agent LLM?

Faccio in modo che ogni tool contract esponga modalità di failure tipizzate ed esaustive invece di eccezioni non strutturate o catch silenziosi. Con uno schema come un campo status per ok, rate_limited, empty o auth_error, fornisco all'LLM casi previsti che può gestire, come attendere dopo il rate limiting.

Quando un agent dovrebbe richiedere approvazione human-in-the-loop?

Richiedo un checkpoint human-in-the-loop o un validation agent separato con regole fisse per azioni con impatto finanziario, legale o rivolto al cliente. Per me, questo include comunicazioni esterne, scritture nei system of record e qualsiasi cosa influenzi sistemi esterni o stato visibile al cliente.

Quale evidenza dovrebbe registrare un'esecuzione dell'agent per l'auditabilità?

Voglio che ogni esecuzione registri l'input, l'hash del prompt template, il nome e la versione del modello, tool invocation con argomenti e return, output finale e un timestamp chain-of-custody. Non mi affido ai soli log; voglio che il trace supporti evidenza riproducibile tramite replay per la diagnosi.

Quali percorsi di ripristino dovrebbero esistere prima del rilascio in produzione?

Prima di rilasciare, metto per iscritto modalità di failure plausibili in produzione e l'azione di recovery per ciascuna. Gli esempi includono fallback model routing per deprecazione o rate limit, un circuit breaker e escalation per output malformato del tool, trajectory abort in caso di prompt injection e modalità read-only quando lo state store non è disponibile.