Lascia parlare l'LLM, non toccare: l'architettura ad anello chiuso che sopravvive davvero in produzione (3/3)

Questo è il post 3 di 3 di una serie sul paper AI Infrastructure Sovereignty di Sergio Cruzes. La parte 1 ha inquadrato perché la sovranità è infrastruttura, non residenza dei dati; la parte 2 ha coperto la Feasible Sovereign Operating Region.

Il terzo pezzo del paper AI Infrastructure Sovereignty di Sergio Cruzes che dovrebbe viaggiare più di quanto stia viaggiando è quello in cui traccia una linea architetturale dura: in un sistema di infrastruttura IA ad anello chiuso, gli LLM sono consultivi e interpretativi. Non eseguono. L'esecuzione è il lavoro di agenti deterministici e limitati, validati da un gemello digitale, con due percorsi di feedback strettamente separati.

Faccio deploy di IA agentica in ambienti regolamentati per vivere. Sono "investito" in questa tecnologia nel senso più letterale possibile, fatturabile. E penso che l'architettura del paper sia quella corretta — che è esattamente perché voglio segnalare che la maggior parte dei prodotti venduti come piattaforme agentiche nel 2026 la viola in silenzio. Mettono l'LLM più vicino all'attuatore di quanto il disegno del paper permetta, e poi marchettano quella vicinanza come la feature.

Questo è il terzo post sul paper, dopo i pezzi su la sovranità che non è residenza dei dati e la FSOR. Se quelli coprivano cosa devi controllare, questo riguarda come il control loop deve essere cablato senza dar fuoco alla data hall.

L'architettura di riferimento a quattro livelli, in un paragrafo

Il paper propone quattro livelli sovrapposti:

1. Fisico — data center IA, reti ottiche, sistemi energetici. Il substrato.
2. Osservabilità — normalizzazione streaming, allineamento dei timestamp, certificazione di freschezza, fusione cross-domain. Produce il vettore di stato unificato θ(t).
3. Controllo coordinato — agenti di dominio (compute, power, cooling, ottico) + tier di coordinamento + gemello digitale + un livello di assistenza LLM.
4. Esecuzione sicura — solo le azioni validate dal gemello digitale raggiungono l'infrastruttura live.

Il confine interessante è tra 3 e 4. Il non-confine interessante — quello che il livello hype vuole sfumare — è tra l'assistenza LLM e tutto il resto dentro il livello 3.

Cosa dice davvero Cruzes sugli LLM

Il paper è insolitamente esplicito. Il livello LLM ha "solo ruolo consultivo e interpretativo." Esiste per:

• Tradurre l'intento umano in obiettivi strutturati che gli agenti deterministici possono consumare.
• Generare spiegazioni di cosa il sistema agentico ha deciso e perché.
• Essere una superficie in linguaggio naturale sopra il sistema di controllo reale, non un partecipante.

E poi il paper dice la parte non detta a voce alta:

Permettere agli output dell'LLM di guidare azioni dell'infrastruttura direttamente — senza validazione attraverso il constraint-checking deterministico del sistema agentico e la simulazione pre-esecuzione del gemello digitale — introduce una modalità di fallimento in cui istruzioni plausibili ma scorrette vengono eseguite su infrastruttura live.

Questa è la modalità di fallimento LLM-in-produzione che ho personalmente visto in cinque diverse revisioni di incidenti negli ultimi diciotto mesi, nessuna nel controllo di data center ma tutte in ambienti regolamentati: l'LLM produce qualcosa che sembra il comando giusto, il sistema circostante è troppo entusiasta nell'eseguirlo, e il post-mortem si trasforma in un esercizio "abbiamo fidato del testo dove avremmo dovuto fidarci della policy". La versione data center di quell'incidente non sarebbe un imbarazzo da slack-bot. Sarebbe un evento termico.

La struttura agentica a due livelli

Dentro il livello di controllo coordinato, il paper separa:

• Tier 1 — agenti di dominio. Ragionatori specializzati per piazzamento compute, gestione power, controllo cooling, routing ottico. Ognuno ha conoscenza hard-coded dei vincoli e della fisica del proprio dominio. Sono questi a proporre effettivamente le azioni.
• Tier 2 — livello di coordinamento. Controllo di feasibility congiunta su tutte le proposte tier 1. Se il compute vuole piazzare un workload al sito A, ma l'agente cooling dice che A è fuori budget dato il bulbo umido corrente, e l'agente ottico dice che il link verso A è in modalità degradata, il coordinatore coglie la contraddizione. Se non esiste un'azione congiuntamente fattibile, escala agli umani invece di scegliere in silenzio l'opzione meno peggio.

L'LLM non è tier 1 e non è tier 2. L'LLM sta fuori da questo loop. Spiega cosa il loop ha fatto. Accetta l'intento umano e lo riformula come obiettivo strutturato dato in pasto al loop. Non piazza workload. Non strozza i rack. Non re-instrada percorsi ottici.

Questo è un design difendibile e regulator-friendly. È anche un design che la maggior parte delle piattaforme "agentiche" sul mercato oggi non rispetta, perché la pressione di marketing è di includere l'LLM nella decisione — è lì che vive la demo da numero di magia.

Due percorsi di feedback, tenuti strettamente separati

Il dettaglio che un ingegnere apprezzerà e un marketer sorvolerà è la disciplina dei due percorsi di feedback:

• Feedback A — outcome misurati fluiscono dal livello fisico verso l'alto attraverso l'osservabilità. Questo chiude il control loop. Gli agenti imparano che l'azione che hanno preso ha prodotto (o non ha prodotto) il cambiamento di stato atteso.
• Feedback B — residui di predizione (la differenza tra ciò che il gemello digitale si aspettava e ciò che è effettivamente accaduto) fluiscono solo nel gemello digitale. È così che il gemello rileva la propria deriva dalla realtà fisica.

Il paper insiste che questi canali restino strettamente separati. Confondili e distruggi la drift detection. Se il gemello digitale riceve lo stesso stream di misurazione del control loop degli agenti, senza isolamento, allora una deriva lenta nell'accuratezza del gemello sembrerà ai vari agenti una normale varianza operativa, e non vedrai la deriva finché il gemello non prenderà una decisione che il sistema fisico rifiuterà in un incidente.

È il tipo di rigore architetturale che non vende licenze di piattaforma ma che ti tiene fuori da un post-mortem.

Dove la maggior parte delle attuali piattaforme "agentiche" rompe questo in silenzio

Generalizzo da ciò che vedo in architetture clienti e demo vendor, senza fare nomi:

1. LLM nel percorso di azione. Il prodotto vende "un agente che opera la tua infrastruttura." Sotto il cofano, l'LLM sia interpreta la richiesta sia emette il comando. Non c'è un agente tier 1 deterministico con vincoli hard-coded tra l'LLM e l'attuatore. Questa è la modalità di fallimento che il paper nomina esplicitamente.

2. Gemello digitale come asset di marketing, non come gate di validazione. Molti prodotti mostrano un "gemello digitale" 3D-renderizzato nella demo. Pochi richiedono che il gemello validi ogni azione proposta prima dell'esecuzione. Il gemello è decorativo. Nell'architettura del paper, il gemello è un gate; se la simulazione del gemello diverge dalla policy, l'azione è bloccata.

3. Telemetria a singolo loop. Sia l'agente sia il gemello consumano lo stesso stream senza separazione. I feedback A e B sono confusi, la drift detection è inaffidabile, e il sistema perde in silenzio la proprietà su cui il paper insiste.

4. Nessun contratto di escalation. Quando il livello di coordinamento non trova un'azione congiuntamente fattibile, cosa succede? Nel paper, degradazione elegante con escalation strutturata agli umani, che mantengono autorità finale. In molti prodotti, il sistema sceglie semplicemente l'azione a costo minimo sotto un'euristica di fallback e scrive un debug log. Non è degradazione elegante; è fallimento silenzioso con un sistema di logging.

5. Human-on-the-loop come checkbox. Esiste una dashboard umana; viene rivista settimanalmente. Operativamente, gli agenti si muovono più velocemente della cadenza di revisione da mesi. Questa è la versione data-centro di HITL teatrale che il rapporto McKinsey segnalava per i sistemi agentici in generale. Stessa malattia, raggio di esplosione maggiore.

Se la tua piattaforma fallisce anche solo uno di questi test, hai un sistema di infrastruttura agentica in senso marketing e una demo con permessi elevati in senso operativo.

Perché penso che l'architettura del paper sia corretta

Tre ragioni, dedotte da come questo si gioca davvero in clienti che devono difendere lo stack:

1. L'LLM è eccellente al livello in cui i suoi errori sono recuperabili. Tradurre "voglio schedulare il prossimo training run da qualche parte dentro il nostro envelope di carbonio" in un obiettivo strutturato è un ottimo uso di un LLM. Se la traduzione è sbagliata, l'obiettivo strutturato fallisce la validazione e la richiesta torna con un errore. Nessuna azione fisica è stata presa. Recuperabile. Eccellente.

2. L'LLM è pericoloso al livello in cui i suoi errori non sono recuperabili. Generare il comando esatto di throttling del rack è il posto sbagliato per usare l'LLM, perché se il comando generato è plausibile-ma-sbagliato e si esegue, il sistema fisico si è già mosso. Non c'è "undo" su un ciclo termico. La separazione del paper mette l'LLM esattamente dove atterrano i suoi punti di forza e lo rimuove da dove mordono le sue debolezze.

3. Vocabolario a forma di regolatore. Un supervisore in un settore regolamentato chiederà, in qualunque revisione di incidente: cosa ha preso la decisione, cosa l'ha validata, quale evidenza hai? Il design del paper ha una risposta pulita per ciascuna. Il design LLM-nel-percorso-di-azione ha, al meglio, "il modello ha deciso," che è la risposta che fa partire i prossimi due anni di lavoro di remediation.

Voglio essere chiaro: sono positivo sugli LLM. Li deploy, ho skin in the game sul fatto che l'IA funzioni in produzione. Non sto facendo un argomento "gli LLM sono inaffidabili, non usarli." Sto facendo un argomento di piazzamento: gli LLM sono lo strumento giusto al livello di linguaggio naturale e spiegazione, e lo strumento sbagliato al livello di esecuzione. Il paper formalizza il piazzamento su cui i buoni operatori stavano già convergendo informalmente.

Cosa significa per il resto dell'IA agentica, non solo per i data center

Il paper è specificamente sul controllo dell'infrastruttura IA, ma l'architettura si generalizza pulitamente alla maggior parte dei deployment agentici regolamentati:

• Agente bancario che processa pagamenti. L'LLM traduce l'intento del cliente. L'agente deterministico con policy e limiti emette l'addebito effettivo. Il gemello digitale (o pre-flight check contro un ledger sandboxed) valida prima del commit.
• Agente di triage sanitario. L'LLM media il dialogo, riassume lo storico. L'agente deterministico applica il protocollo. Human-in-the-loop su qualunque azione che produca effetto clinico.
• Agente di controllo industriale. L'LLM spiega i setpoint all'operatore e accetta target di setpoint dal linguaggio naturale. Il controller deterministico muove effettivamente la valvola, dopo che un simulatore ha validato che la mossa non violi i limiti di processo.

In tutti e tre, lo scheletro architetturale è lo stesso del data center del paper: l'LLM non tiene mai l'attuatore. Tiene la spiegazione, la superficie in linguaggio naturale, e la traduzione dell'intento. Il confine non si sposta perché il regolatore e la fisica non si spostano.

Questa è la stessa linea che ho tracciato nei miei post su proof-carrying deployment e architettura di governance verificabile, da un'angolazione diversa. Il paper di Cruzes fornisce la versione physical-infrastructure di un argomento che sta convergendo nei settori regolamentati: LLM utile, LLM non autoritativo, agente deterministico nel percorso della conseguenza.

Cosa metterei sulla roadmap di piattaforma questo trimestre

Se devo tradurre questo terzo post in azioni per un team di piattaforma che fa girare — o pianifica di far girare — IA agentica in un ambiente serio:

1. Mappare il grafo delle azioni. Per ogni operazione che un "agente" può eseguire, segnare quale livello la emette: LLM, agente deterministico tier-1, o umano. Se l'LLM compare da qualche parte nella colonna esecuzione, hai rework da fare prima che lo faccia il regolatore.

2. Mettere un gemello digitale davanti all'attuatore. Anche grezzo. Il punto non è la fedeltà; il punto è il gate. Un'azione che il gemello non può simulare, o che il gemello mostra che viola un vincolo, non si esegue. Punto. Questa singola disciplina rimuove una categoria di incidenti che sembrano catastrofici nel post-mortem e banali a posteriori.

3. Separare il feedback A e B. Gli outcome vanno al control loop. I residui del gemello vanno al gemello. Stessa fonte di telemetria, due pipeline, due politiche di retention, due linee di ownership. Questo è lavoro infrastrutturale poco glamour; è anche il lavoro che rende reale la drift detection.

4. Scrivere il contratto di escalation. Definire cosa succede quando non esiste un'azione congiuntamente fattibile. La risposta è umani, con handoff chiaro e SLA pubblicato sulla risposta. Qualunque altra cosa è un fallback silenzioso che emergerà in un incidente.

5. Auditare il tuo vendor contro i quattro test sopra. LLM non nel percorso di azione; gemello come gate di validazione reale; percorsi di feedback separati; escalation esplicita. Qualsiasi "piattaforma agentica" che ne fallisce due o più non è un sistema regulator-grade; è una demo di produttività con permessi elevati.

La linea che traccio — e perché la tengo

Sono critico dell'attuale hype IA agentica non perché la tecnologia non sia reale — lo è, dimostrabilmente, e la fatturo — ma perché l'architettura marketata è costantemente più vicina all'attuatore di quanto l'architettura di engineering dovrebbe essere. Il paper di Cruzes, lavorando nel dominio operativo più esigente disponibile (infrastruttura IA live sotto vincoli fisici congiunti), arriva a una disciplina che si traduce pulitamente a ogni deployment agentico regolamentato: gli LLM parlano e spiegano. Gli agenti deterministici propongono. I coordinatori controllano la feasibility. I gemelli digitali validano. Gli umani autorizzano la policy e possiedono l'escalation. Il sistema fisico vede solo azioni che hanno superato tutti e quattro i gate precedenti.

La piattaforma agentica più veloce del 2026 non sarà quella il cui LLM si avvicina di più al metallo. Sarà quella il cui LLM è onestamente piazzato dove vivono i suoi punti di forza, con il resto dello stack ingegnerizzato per assorbire le sue debolezze. Quella piattaforma non farà la demo da numero di magia. Farà l'audit un martedì di ottobre alle 09:30 senza che nessuno debba prendersi il giorno libero.

È il sistema che voglio continuare a costruire. Tutto il resto è teatro con permessi.

---

Fonti:

• Sergio Cruzes (Ciena Corporation), AI Infrastructure Sovereignty, arXiv:2602.10900v4, aprile 2026. arxiv.org

Stai mettendo IA agentica in produzione e non sei sicuro che la tua architettura sopravviverebbe a una revisione di incidente? Parla con un CTO — ti aiutiamo a piazzare l'LLM esattamente dove atterrano i suoi punti di forza, e da nessun'altra parte.