Sicurezza IA Certificabile: Porte di Deployment Con Prova per LLM Che Usano Strumenti
C'è una specifica modalità di fallimento negli LLM moderni che usano strumenti che non riceve abbastanza attenzione: i dati che il sistema genera non sono statisticamente indipendenti dai dati che il monitor vede dopo. L'LLM emette una distribuzione di token. Il sistema campiona da essa. Alcuni campioni invocano strumenti. Gli output degli strumenti tornano nel contesto. La successiva distribuzione di token è condizionata su quegli output. Tutto è adattivo, dipendente, ricorsivo.
Il monitoraggio statistico standard assume osservazioni indipendenti. La rilevazione di drift standard assume una distribuzione di riferimento fissa. Il testing A/B standard assume che il test non influenzi i dati. Nessuna di queste assunzioni regge per un LLM che usa strumenti in produzione. Il comportamento stesso dell'agente — e le risposte degli strumenti — cambia la distribuzione che il monitor sta osservando.
Il recente paper Certifiable AI Safety Theory (CAST): Convex-Analytic, Measure-Theoretic, and Proof-Carrying Deployment Gates for Tool-Using LLM Systems (Fradelos, febbraio 2026) affronta questo direttamente. Il contributo è un framework matematico per certificare la sicurezza esattamente di questa classe di sistemi, usando monitoraggio statistico anytime-valid (e-processi) esplicitamente progettato per dati adattivi e dipendenti.
La matematica è densa. Il pattern di ingegneria è più accessibile. Vale la pena capirlo perché l'alternativa — fingere che il problema di dipendenza non esista — è la modalità di fallimento silenziosa della maggior parte del monitoraggio attuale di IA in produzione.
Perché "Con Prova" Conta
L'idea centrale: in ogni punto di decisione — ogni volta che l'agente vuole prendere un'azione, invocare uno strumento, emettere una risposta — viene costruito un certificato che mostra che l'azione appartiene a un insieme sicuro. Il runtime verifica il certificato in tempo polinomiale. Se il certificato è valido, l'azione procede. Se non lo è, il sistema o cade su un default sicuro ("dummy output") o proietta l'azione su un'alternativa sicura vicina ("convex repair").
Questa è la stessa idea del codice con prova nel software di sistema: il produttore di un'azione fornisce un certificato che un verificatore può controllare a basso costo. La fiducia si sposta da "il produttore si comporta bene" a "il certificato è valido".
Per i sistemi IA, è operativamente importante perché:
- La verifica è più economica del riaddestramento. Una volta fissato il formato del certificato, la verifica è veloce. Riaddestrare un modello per renderlo più sicuro è costoso e incerto.
- Il verificatore può essere fidato indipendentemente dal modello. Un verificatore piccolo, semplice, formalmente specificato può essere fidato a un livello di confidenza più alto di un grande modello opaco.
- Il fallback è di principio. Quando il certificato fallisce, il sistema sa fallire in sicurezza, sia emettendo un output dummy sia proiettando su un'alternativa sicura.
Il Problema dei Dati Adattivi
La mossa tecnica centrale del paper è usare e-processi (un tipo specifico di accumulatore di evidenza statistica basato su supermartingale) per il monitoraggio. Gli e-processi hanno una proprietà che i p-valori regolari non hanno: rimangono validi sotto stopping opzionale e raccolta dati adattiva.
In termini semplici: con i test statistici regolari, la validità del test dipende dal tuo impegno in anticipo su quanti dati raccoglierai e cosa testerai. Se sbirci i dati e decidi se continuare a raccogliere in base a ciò che hai visto, hai rotto le garanzie del test. Questo è il problema dell'"early stopping".
Per un sistema IA in produzione, non puoi evitare l'early stopping. Stai monitorando continuamente, agirai sul monitoraggio (alerting, throttling, blocking), e le tue azioni influenzano i dati che il monitor osserva. I test statistici regolari ti danno garanzie che non reggono in questo regime.
Gli e-processi reggono. Danno validità uniforme nel tempo: puoi monitorare continuamente, fermarti quando vuoi, e la garanzia di falso positivo si applica ancora. Questa è la base matematica che fa funzionare il monitoraggio continuo di sicurezza IA.
L'implicazione pratica: se stai usando rilevazione di drift basata su p-valori in un sistema IA in produzione, stai operando fuori dal regime valido del metodo statistico. Questo è qualcosa a cui quasi nessuno sta prestando attenzione nel 2026, ed è il tipo di errore che produce sia falsa fiducia (quando non morde) sia falsi allarmi inspiegati (quando lo fa).
Lo Strato di Costruzione del Monitor
Il paper specifica una costruzione canonica del monitor con quattro componenti:
1. Logging fidato
Ogni input, ogni output del modello, ogni tool call, ogni risposta dello strumento è loggato in un modo che l'agente non può falsificare. Il log è il substrato per tutto il resto.
2. Casualità privata del monitor
Il monitor usa numeri casuali a cui l'agente non ha accesso. Questa è la stessa idea di tenere segreto il seed di un audit basato sulla casualità rispetto all'audit. Impedisce all'agente di giocare con il monitor anticipando ciò che il monitor controllerà.
3. Shadow sampling
Per alcuni controlli, il monitor campiona output addizionali dal modello con lo stesso prompt per stimare la distribuzione di output. Questi campioni ombra non raggiungono l'utente; esistono solo per caratterizzare la distribuzione di comportamento che il modello sta producendo.
4. Ri-esecuzione di strumenti
Per controlli che coinvolgono risultati di strumenti, il monitor può ri-eseguire le tool call deterministicamente (o in un ambiente sandbox) per verificare che la risposta era ciò che doveva essere.
Questi quattro insieme danno al monitor abbastanza evidenza indipendente per costruire i certificati che il runtime richiede. Nessuno di essi è esotico; tutti e quattro sono alla portata di qualsiasi team che prende il monitoraggio sul serio. Il contributo è specificare esattamente cosa serve e perché.
Composizione Modulare: Perché Conta
Un mal di testa pratico nella sicurezza IA è la composizione. Puoi certificare che due componenti sono sicuri individualmente e avere un sistema composito non sicuro. Il caso classico: uno strumento che è sicuro chiamare individualmente, chiamato molte volte in rapida successione, può produrre effetti aggregati non sicuri (denial-of-service contro un sistema downstream, escalation tramite chiamate ripetute, ecc.).
Il paper fornisce un teorema di composizione modulare: sotto condizioni specifiche, i certificati di sicurezza dei componenti si compongono in un certificato di sicurezza per il sistema. Le condizioni sono reali e non banali, ma esplicite. Un team che costruisce sistemi agentici compositi può controllare le condizioni e sapere se la loro composizione è nel regime in cui la sicurezza dei componenti implica la sicurezza del sistema.
L'inquadramento onesto conta. Il paper etichetta questo come "un primo regime composizionale" — significa un punto di partenza utile, non una teoria completa di sicurezza composizionale. I team di ingegneria dovrebbero trattarlo allo stesso modo: utile per i casi che copre, non una garanzia per i casi che non copre.
Il Budget Globale di Rischio
Un contributo sottile ma importante: un corollario che alloca un budget globale di rischio attraverso i tempi di decisione runtime. Questo affronta la modalità di fallimento "sicuro per passo, non sicuro in aggregato".
Ogni punto di decisione ha una piccola probabilità di produrre un'azione non sicura. Sommato su migliaia o milioni di decisioni, la probabilità aggregata di almeno un'azione non sicura diventa grande. Il paper fornisce un modo di allocare il budget globale di rischio attraverso lo schedule di decisioni perché l'aggregato resti limitato.
In pratica, questo significa impostare soglie di sicurezza per azione basate su quante azioni ti aspetti che il sistema prenda, con tracking esplicito del budget. Un sistema che prende un milione di azioni al giorno e vuole probabilità aggregata di azione non sicura ≤1% richiede una soglia per azione molto più stretta di un sistema che prende mille azioni.
Questo è il tipo di contabilità che la maggior parte dei sistemi IA in produzione non fa esplicitamente. Impostano una soglia per azione basata sull'intuizione e non verificano l'aggregato. CAST dà il framework per farlo correttamente.
Convex Repair: Quando il Certificato Fallisce
Quando un'azione fallisce la certificazione, esistono due opzioni:
- Fallback dummy: emette un output di default sicuro. Conservativo, semplice, spesso degrada l'esperienza utente.
- Convex repair: proietta l'output non sicuro al punto più vicino nell'insieme sicuro. Richiede che l'insieme sicuro sia convesso e che la proiezione sia trattabile.
Il paper fornisce teoremi di proiezione alla sicurezza in geometrie KL/Bregman e di trasporto ottimo, con un percorso di trattabilità esplicito per la riparazione basata sul trasporto. La matematica dice: sotto condizioni specifiche, puoi calcolare un'azione che è "il più vicino possibile" all'azione originale non sicura mentre è dentro l'insieme sicuro.
Il take-away di ingegneria: quando progetti il tuo insieme sicuro, progettalo convesso. Gli insiemi sicuri convessi ammettono proiezione in tempo polinomiale. Gli insiemi sicuri non convessi generalmente no. Questa è una scelta di design che fai quando specifichi la politica di sicurezza, e determina se il convex repair è anche disponibile.
Cosa Significa per i Team IA in Produzione
Tre azioni pratiche per qualsiasi team che esegue sistemi LLM con uso di strumenti in produzione:
1. Verifica la tua metodologia di monitoraggio
Se la tua rilevazione di drift o monitoraggio di sicurezza usa metodi standard basati su p-valori su dati raccolti adattivamente, le garanzie statistiche non reggono. O passa a monitoraggio basato su e-processi (la risposta giusta) o sii esplicito che il tuo monitoraggio è euristico piuttosto che statisticamente rigoroso (una risposta provvisoria difendibile).
2. Specifica l'insieme sicuro esplicitamente
La frase "il modello è sicuro" non ha un significato preciso. "Gli output sono membri dell'insieme S" ce l'ha. Specifica S in codice o descrizione formale. Poi puoi verificare l'appartenenza, proiettare i fallimenti in S e ragionare sulla composizione.
3. Tieni conto del rischio globale
Se il tuo sistema prende molte azioni, imposta soglie per azione basate su budget di rischio aggregato, non su intuizione per azione. La matematica non è difficile una volta che hai deciso il budget; la disciplina è decidere di farlo.
Dove CAST Non Si Applica
Il paper è esplicito sullo scope: non è una teoria di robotica, non assume superintelligenza, ed è posizionato come "contenimento e certificazione finance-grade / scientific-computing-grade". È per leggi di sicurezza esplicitamente specificate su sistemi LLM con uso di strumenti.
Questo è il regime in cui vive la maggior parte del deployment IA in produzione nel 2026. CAST è ben mirato al problema pratico. I team che rilasciano agenti basati su LLM che toccano strumenti reali — la maggior parte dell'IA agentica in produzione — dovrebbero leggere questo paper e adattare i pattern.
L'alternativa è monitoraggio matematicamente sbagliato sui dati che processa. Questo è il tipo di errore che produce incidenti che nessuno può spiegare a posteriori.
Fonte: Fradelos, G. Certifiable AI Safety Theory (CAST): Convex-Analytic, Measure-Theoretic, and Proof-Carrying Deployment Gates for Tool-Using LLM Systems (Ginevra, 12 febbraio 2026). SSRN 6307158.
Stai eseguendo LLM con uso di strumenti in produzione e vuoi un monitoraggio che sia davvero statisticamente valido per i dati che stai raccogliendo? Parla con un CTO sul dispiegamento di capacità di ingegneria nearshore che possa costruire sicurezza certificabile nel runtime.
