Riepilogo Tecnico: SARC – Un Framework di Governance per Architettura per Sistemi di IA Agente

1. Enunciato del Problema

I sistemi di IA agente, che percepiscono, pianificano e agiscono tramite strumenti e sub-agenti, stanno entrando in ambienti regolamentati più rapidamente di quanto l'infrastruttura di governance non sia maturata. Esiste un disallineamento strutturale critico: gli obblighi normativi (ad esempio, supervisione umana, gestione del rischio) sono tipicamente valutati tramite documentazione ex-post o allegati a prompt e dashboard. Ciò crea un "disallineamento strutturale" in cui i vincoli destinati a limitare l'esecuzione sono spesso valutati solo dopo che l'azione è avvenuta.

Gli approcci attuali soffrono di specifici modi di fallimento:

• Sicurezze dei Prompt: I modelli possono ignorare, reinterpretare o aggirare le istruzioni tramite strumenti.
• Filtraggio dell'Output: Non riesce a catturare violazioni realizzate attraverso effetti collaterali sul mondo piuttosto che tramite testo visibile.
• Audit Ex-Post: Documenta le violazioni ma non può prevenirle.
• Regole di Flusso di Lavoro: Spesso insufficienti in spazi di azione in espansione dinamica a meno che non siano collegati a un registro completo e applicati alla distribuzione.

Il documento sostiene che i controlli di governance devono passare dall'essere allegati agli artefatti (prompt, log) all'essere allegati all'esecuzione all'interno dell'architettura del sistema.

2. Metodologia: Il Framework SARC

Gli autori introducono SARC (Stato, Spazio di Azione, Ricompensa, Vincoli), un framework di governance per architettura. Mentre $S$, $A$ e $R$ sono primitivi standard dell'Apprendimento per Rinforzo (RL), $C$ (Vincoli) è il contributo innovativo. Tratta i vincoli come oggetti di specifica di prima classe, pari a stato e ricompensa, e li applica in punti dichiarati durante l'esecuzione dell'agente.

2.1 La Tupla di Specifica

Una specifica SARC è definita come $\Sigma = \langle S, A, R, C \rangle$.

• Vincoli ($C$): Partizionati in tre classi:
  • $C_h$ (Rigidi): Le violazioni non sono consentite sotto alcuna politica.
  • $C_s$ (Morbidi): Le violazioni sono ammissibili a un costo marginale dichiarato.
  • $C_e$ (Escalation): Condizioni che richiedono il trasferimento del controllo a un operatore umano.
• Struttura del Vincolo: Ogni vincolo $c \in C$ è una quintupla $\langle src, class, pred, verif, resp \rangle$, dove:
  • $src$: Origine (normativa, contrattuale, ecc.).
  • $class$:$h$, $s,$ o $e$.
  • $pred$: Predicato su stato, azione e tempo.
  • $verif$: Meccanismo di verifica (pre-condizione, monitoraggio runtime, ex-post).
  • $resp$: Protocollo di risposta (blocco, log, escalation, aborto).

2.2 Architettura di Applicazione Runtime

I vincoli si compilano in quattro siti di applicazione nominati all'interno del ciclo dell'agente:

1. Cancello Pre-Azione (PAG): Valuta prima della distribuzione. Utilizzato per vincoli rigidi ed escalation predittive decidibili solo da stato e azione.
2. Monitor Tempo-Azione (ATM): Valuta durante l'esecuzione (ad esempio, avvolgendo le chiamate agli strumenti). Utilizzato per vincoli dipendenti da output parziali (accumulo di costi, contenuto in streaming).
3. Auditor Post-Azione (PAA): Valuta dopo il completamento. Utilizzato per confrontare lo stato post-azione con lo stato pre-azione (deriva, verifica degli effetti collaterali).
4. Router di Escalation (ER): Instrada le azioni segnalate agli operatori umani con latenza di accodamento limitata rispetto alla finestra di reversibilità dell'azione.

2.3 Estensione Multi-Agente

Per i flussi di lavoro multi-agente, SARC introduce:

• Propagazione dei Vincoli: I vincoli ereditano lungo la catena di chiamata. Se un vincolo non è decidibile al livello di un sub-agente, viene valutato al livello decidibile più profondo ("salvataggio della decidibilità").
• Intersezione dell'Autorità: L'autorità è l'intersezione di tutti i principi e gli agenti nella catena di chiamata; è monotonicamente non crescente.
• Alberi di Traccia che Preservano l'Attribuzione: La traccia di audit è un albero gerarchico, non una sequenza piatta, che preserva l'intera catena delle relazioni principio-agente per prevenire la diluizione dell'attribuzione.

2.4 Proprietà Formali

• Limitazione della Modellazione della Ricompensa: Il documento fornisce un controesempio formale (Proposizione 1) che mostra come penalità di ricompensa finite non possano generalmente garantire la soddisfazione di vincoli rigidi per violazioni a bassa probabilità e alto guadagno. Pertanto, i vincoli rigidi devono essere predicati architetturali, non termini di ricompensa.
• Corrispondenza Specifica-Traccia: Un sistema è "conforme a SARC" se soddisfa otto invarianti (ad esempio, ammissibilità pre-azione, derivazione della traccia, completezza dell'applicazione). Ciò garantisce che per ogni azione in una traccia, un auditor possa verificare meccanicamente quali vincoli si applicavano e quale risposta è stata presa, senza accedere al modello o ai prompt.

3. Contributi Chiave

1. Modello di Specifica dei Vincoli: Un modello tipizzato per classe ($\langle src, class, pred, verif, resp \rangle$) che è agnostico rispetto all'implementazione ma richiede metadati specifici per l'esecutabilità e l'auditabilità.
2. Architettura di Applicazione del Ciclo Agente: Una disciplina che mappa le classi di vincoli su punti di applicazione specifici (PAG, ATM, PAA, ER), convertendo la governance dalla documentazione al controllo dell'esecuzione.
3. Auditabilità Verificabile: Una definizione formale di "auditabile per costruzione" e un controllore prototipale che verifica le tracce runtime rispetto alle specifiche in tempo $O(|T| \cdot |C|)$.
4. Estensione Multi-Agente: Meccanismi per la propagazione dei vincoli, l'intersezione dell'autorità e gli alberi di traccia per gestire topologie aziendali complesse.
5. Percorso di Compilazione Normativa: Un metodo per mappare le clausole normative (ad esempio, Articolo 14 dell'AI Act dell'UE) in predicati eseguibili e controlli runtime.

4. Valutazione Empirica

Gli autori hanno condotto una valutazione sintetica riproducibile su un compito di approvvigionamento ($H=1.000$ ordini, 50 semi) confrontando SARC con quattro baseline: Audit Ex-Post, Filtraggio dell'Output, Regole di Flusso di Lavoro e solo Policy-as-Code (PaC).

Risultati:

• Violazioni Rigide: SARC ha eseguito zero violazioni di vincoli rigidi sotto predicati esatti, eguagliando la baseline Policy-as-Code ma superando il Filtraggio dell'Output e l'Audit Ex-Post.
• Vincoli Morbidi: SARC ha ridotto le eccedenze della finestra morbida del 89,5% rispetto alla baseline solo Policy-as-Code. Ciò è stato attribuito al posizionamento esplicito di una risposta di limitazione (throttling) presso l'Auditor Post-Azione (PAA) piuttosto che affidarsi alle prestazioni intrinseche.
• Violazioni Residue: Sotto applicazione imperfetta (rumore del predicato o fallimento dell'applicazione), le violazioni residue sono scalate con l'errore dello stack di applicazione ($\epsilon_{pred} + \epsilon_{exec}$) piuttosto che con il tasso di opportunità di violazione ambientale.
• Compromesso Latenza: SARC ha comportato una latenza per passaggio di ~21ms (vs 0ms per ex-post), dimostrando il costo esplicito della governance runtime.

5. Significato e Affermazioni

Il documento posiziona SARC non come una garanzia di sicurezza o una certificazione di conformità legale, ma come un substrato architetturale che rende gli obblighi eseguibili, ispezionabili e auditabili in runtime.

• Spostamento dall'Artefatto all'Esecuzione: Il contributo principale è lo spostamento dall'allegare vincoli agli artefatti (prompt, log) all'allegarli ai percorsi di esecuzione.
• Auditabile per Costruzione: SARC abilita l'"auditabile per costruzione", dove la traccia di audit è generata dall'aderenza del sistema alla sua specifica, piuttosto che ricostruita dai log a posteriori.
• Regime B: Il framework è progettato per distribuzioni del "Regime B" (ambienti regolamentati, irreversibili o con perdita asimmetrica) in cui l'omissione del componente vincolo $C$ rende una specifica incompleta.
• Chiarezza Economica: Costringendo alla dichiarazione esplicita dei punti operativi e delle finestre di reversibilità, SARC rende visibili i compromessi tra falsi positivi, falsi negativi e capacità degli operatori come decisioni di allocazione del capitale.

Gli autori concludono che SARC non rende i sistemi sicuri di per sé; piuttosto, fornisce la disciplina strutturale necessaria per ingegnerizzare sicurezza e conformità, separando l'ottimizzazione ($R$), la capacità ($A$) e l'ammissibilità ($C$) per prevenire che i sistemi falliscano come anomalie non osservabili.