Agentic AI: conformità formale vs governance reale — perché le aziende italiane devono ripensare audit, energia e architetture

L'entusiasmo per l'AI agentiva ha superato la fase della prova di concetto. Oggi, nei dipartimenti IT delle grandi imprese italiane — dalla finanza alla manifattura avanzata — si discute di come orchestrare flussi di lavoro autonomi che prendono decisioni consequenziali: approvare un fido, riassettare una supply chain, generare codice per sistemi critici. Ma mentre i progetti pilota proliferano, la letteratura scientifica più recente segnala un fenomeno sottile e pericoloso: la conformità verificata a livello di singolo passo non garantisce la conformità del flusso complessivo. È il paradosso che i ricercatori chiamano Compositional Policy Violation (CPV), e che costringe a ripensare dall'architettura di runtime ai modelli di audit, fino al posizionamento fisico degli agenti lungo il continuum edge-cloud (Compositional Policy Violations: When Step-Level Compliance Fails In Agentic AI Workflows).

Non si tratta solo di una questione accademica. L'AI Act europeo, nella sua formulazione aggiornata, richiede che i sistemi ad alto rischio siano sottoposti a valutazioni di conformità continue e verificabili. Se gli strumenti di controllo oggi disponibili — classificatori input-output, guardrail a livello di turno, evaluator a livello di span — sono ciechi rispetto alle politiche che emergono solo nella composizione, le aziende si espongono a rischi regolatori e operativi che nessun dashboard attuale riesce a intercettare. La sfida, dunque, non è "far funzionare l'agente", ma costruire l'infrastruttura di governance che renda il suo operato tracciabile, auditabile e sostenibile.

Il paradosso della conformità: quando i singoli passi non bastano

Il paper che formalizza le Compositional Policy Violations identifica quattro classi di fallimento che nessun monitor step-level può intercettare: Authority Creep (l'agente accumula poteri decisionali oltre la soglia consentita), Threshold Laundering (un limite — ad esempio l'importo massimo di un bonifico senza approvazione — viene aggirato spezzando l'operazione in più step singolarmente conformi), Cumulative Sum Violation (la somma di azioni lecite supera un tetto globale), e Context Collapse (informazioni critiche perse tra uno step e l'altro alterano il significato complessivo dell'esecuzione) (Compositional Policy Violations: When Step-Level Compliance Fails In Agentic AI Workflows).

La radice del problema è architetturale: le policy aziendali reali — limiti di autorità, soglie di revisione, requisiti di approvazione — sono proprietà dell'esecuzione intera, non di un singolo turno. Un predicato su uno step non può valutare una quantità che quello step non determina. Di conseguenza, nessun miglioramento nell'accuratezza dei monitor step-scoped risolve la classe di difetti. La soluzione proposta dai ricercatori è un'architettura runtime provenance-aware: invece di fidarsi delle rappresentazioni derivate dalla pipeline, il sistema ricalcola le grandezze sorvegliate (importi, contatori, stati di autorità) direttamente dalla traccia di provenienza grezza, valutando le policy su trace completi.

Per un CISO o un Chief Risk Officer italiano, l'implicazione è immediata: i tool di guardrailing oggi sul mercato (spesso venduti come "compliance-ready") coprono solo la superficie. Serve uno strato di policy evaluation che operi a livello di grafo di esecuzione, con accesso alla provenienza completa — tool invocati, dati letti, decisioni intermedie, contesto condiviso tra agenti. È un salto architetturale che ricorda il passaggio dal logging per-servizio al distributed tracing: chi non lo fa oggi, si troverà domani con evidenze inammissibili in sede di audit o contenzioso.

Auditare l'inauditabile: il nuovo framework di indipendenza graduale

Se la governance interna fatica a comporre, l'audit esterno affronta un problema ancora più radicale: chi audita l'auditor quando l'auditor è esso stesso un agente? Il lavoro sull'Independence-Graded Audit Protocol sostiene che l'indipendenza — fondamento di ogni assurance — non può essere trattata come binaria (indipendente / non indipendente), ma va graduata su tre assi ortogonali (Who Audits Whom, on What Substrate, with What Evidence? An Independence-Graded Audit Protocol for Agentic AI):

1. Principal independence: chi controlla l'auditor? Un auditor interno all'organizzazione che ha commissionato il sistema, o un terzo pagato dal fornitore del modello fondazionale, ha un conflitto strutturale.
2. Substrate independence: se l'auditor condivide la stessa foundation-model family, toolchain o guardrail dell'auditee, i due falliscono insieme per common-cause failure — lo stesso bias, la stessa vulnerabilità di prompt injection, la stessa lacuna nei dati di addestramento.
3. Evidence independence: l'evidenza è attestabile (log firmati, trace immutabili, SBOM verificabili) o self-reported ("l'agente dice di aver fatto X")?

Gli autori applicano il beta-factor model dall'ingegneria dell'affidabilità per quantificare il rischio di fallimento comune, e definiscono un protocollo a sette passi i cui output sono verificabili da terze parti. Applicato a un caso reale — un agente di procurement controls auditato a tre gradi di indipendenza — il modello mostra che un audit interno convenzionale (team umano + secondo agente + log del provider) rileva solo il 5,9% dei difetti che in principio potrebbero essere visti, e zero difetti in metà delle classi di guasto.

La mappatura normativa è esplicita: il triplice asse si allinea all'AI Act emendato, a ISO/IEC 42006, alle linee guida UK per il settore pubblico e alle prassi dei regolatori dell'audit. Per le imprese italiane che si preparano alla compliance AI Act, il messaggio è chiaro: un audit fatto "in casa" o dal fornitore del modello non è un audit. Serve una catena di custodia dell'evidenza (substrate independence), un mandato formale che separi l'auditor dal committente (principal independence), e log tamper-evident che non dipendano dall'agente stesso (evidence independence). AegisCore ha già iniziato a integrare questi principi nei propri framework di continuous assurance per clienti bancari e della PA.

Affidabilità energetica e computazionale: dove far "vivere" gli agenti

Mentre governance e audit affrontano la dimensione logica, c'è una dimensione fisica che rischia di diventare il collo di bottiglia operativo: l'energia e la memoria necessarie per eseguire workflow multi-agente su scala. Lo studio agentic-eCAL generalizza la metrica Energy Cost of AI Lifecycle ai grafi di esecuzione multi-agente, accoppiando un modello a due tassi (prefill compute-bound, decode memory-bound) con lo stack OSI a 7 livelli per il trasporto dati (Where Should Agents Live? Energy-Memory Characterization of Agentic AI for the Edge-Cloud Continuum).

I numeri, validati su centinaia di configurazioni GPU (A100, H100), 16 modelli open-weight e 8 topologie di orchestrazione, sorprendono: il trasporto testuale inter-agente incide solo per lo 0,25% dell'energia totale su link 5G RAN, metro e ottici. Il costo dominante della distribuzione non è la trasmissione, ma **l'inferenza e l'elaborazione di contesto aggiuntive indotte dalla comunicazione stessa** — sincronizzazione, ridondanza, repliche di KV cache. Significa che spostare agenti sull'edge per "risparmiare banda" può paradossalmente aumentare il consumo energetico complessivo se non si modella l'intero grafo di esecuzione.

A completare il quadro, il lavoro LYREO affronta lo scheduling delle richieste su edge server eterogenei per inference LLM in servizi agentici, minimizzando latenza end-to-end e bilanciando carico via ottimizzazione di Lyapunov e reward redistribution con predizione sequence-based (End-to-End Latency-Minimizing and Load-Balanced Request Scheduling for Edge LLM Inference in Agentic AI Services). Il modello cross-slot cattura trasmissione, prefill, decoding a livello di iterazione ed evoluzione della KV cache per richiesta, usando una metrica KV cache memory-time consumption per caratterizzare il carico server. Le simulazioni mostrano latenze costantemente inferiori e distribuzione più bilanciata rispetto a baseline learning-based ed euristiche.

Per un'azienda italiana che progetta un'architettura agentic-first — pensiamo a un grande operatore telco che vuole agenti diagnostici distribuiti sui siti 5G, o a un gruppo manifatturiero con agenti di controllo qualità su linee edge — la lezione è duplice: non si può decidere il placement su intuizione o solo su latenza di rete. Serve un digital twin energetico-computazionale del workflow agentico, che modelli KV cache dynamics, context growth, e topologia di comunicazione. Solo così si evita che la sostenibilità economica (e ambientale) del deployment collassi sotto il peso di overhead nascosti.

Dalla teoria alla pratica: portfolio di workflow e validazione sul campo

C'è infine un fronte dove la ricerca incontra direttamente l'ingegneria del software: come scegliere, combinare e validare i workflow agentici che risolvono lo stesso task con strategie diverse. Il paper sui workflow portfolios formalizza il problema: lanciare più esecuzioni (portfolio) e selezionare l'output migliore dopo aver osservato i risultati (Designing Agentic AI Workflow Portfolios under Imperfect Selection and Compute Cost). Il trade-off è sottile: più esecuzioni scoprono risposte corrette che il miglior workflow standalone mancherebbe, ma consumano compute e introducono plausible distractors che complicano la selezione finale.

La soluzione usa un odds-lift index per quantificare la qualità del selettore, deriva limiti stretti (bound) sul valore della varietà, e per classi di workflow implicite (di grandi dimensioni) propone un metodo duale guidato da pricing oracle che identifica workflow ad alta weighted accuracy net of recurring compute cost. Su tre benchmark (ABCD, Schema-Guided Dialogue, HotpotQA), l'ottimizzazione del portfolio migliora l'accuratezza del selettore di 3,1, 7,5 e 0,9 punti percentuali rispetto al miglior workflow standalone; la generazione duale-guidata aggiunge 3,5 punti su ABCD e 24,1 su HotpotQA.

Ma la validazione reale arriva dallo studio sull'affidabilità del codice generato da agentic AI: dieci utility Linux release-quality, sviluppate con workflow best-practice e testate con fuzz testing (black-box generazionale + AFL++ coverage-guided) (A Study of the Reliability of Agentic AI-Generated Programs). Risultato: le versioni AI-generated erano tipicamente affidabili quanto — spesso più — le controparti umane latest-release. Meno memory error (buffer overflow), più hang (infinite loop). Cruciale: la qualità dipende criticamente da prompt, skill e supervisione umana; il workflow agentico stesso (con i suoi prompt e skill) diventa specifica eseguibile che rende il software sostenibile nel tempo.

Per un CTO italiano, la sintesi operativa è: non puntate su un singolo workflow "migliore". Costruite un portfolio di strategie agentiche diverse (chain-of-thought, ReAct, plan-and-solve, multi-agent debate), dotatevi di un selettore addestrato (odds-lift), e validate in produzione con fuzz testing continuo. Il workflow agentico non è solo codice: è specifica, test oracle, e documento di architettura tutto in uno. Chi lo tratta come "black box che genera codice" perde il vantaggio sistemico; chi lo ingegnerizza come pipeline governata, auditabile, energy-aware e portfolio-ottimizzata trasforma l'AI agentiva da esperimento a asset industriale.