Il modello AI può cambiare. Il controllo dell’infrastruttura deve rimanere. È la tesi di Sovereign AI Architecture, il documento di Andrea Ciofani che porta la discussione oltre la scelta dell’LLM e la colloca dove diventa strategica: nel governo dell’intera catena di esecuzione.
Quale modello ragiona meglio? Quale costa meno per token? Quale conviene installare sulle proprie GPU? Sono domande utili, ma insufficienti per progettare un’infrastruttura destinata a durare più di una generazione di modelli. Il documento propone un cambiamento di prospettiva: rendere i modelli risorse computazionali intercambiabili, all’interno di una piattaforma controllata dall’organizzazione.
Scarica il documento completo · PDF, 21 pagine
Dal modello come piattaforma al modello come risorsa
Nelle prime applicazioni LLM, il legame era diretto: applicazione, API, modello. L’introduzione di RAG, strumenti e agenti ha ampliato le capacità del sistema. Il passo successivo descritto nel documento consiste nel separare l’applicazione dalla scelta del modello: l’applicazione dichiara che cosa deve essere fatto; l’infrastruttura seleziona le risorse con cui farlo.
È un’evoluzione coerente con la distinzione già discussa in LLM vs Sistema AI: perché integrare ChatGPT non crea vantaggio competitivo. Il valore architetturale nasce dall’integrazione di modelli, dati, memoria, strumenti e controllo. Il PDF sviluppa questa impostazione fino al livello dell’infrastruttura sovrana.
Il Sovereign AI Execution Layer
Il livello che rende possibile questa separazione è il Sovereign AI Execution Layer: uno strato intermedio tra applicazioni e infrastruttura AI, capace di coordinare modelli, agenti, conoscenza privata, strumenti e ambienti di esecuzione. Può operare on-premise, in private cloud, in sovereign cloud o attraverso una combinazione controllata di questi ambienti. Il requisito decisivo è che la governance rimanga nelle mani dell’organizzazione.
Selezionare modelli, coordinare agenti, proteggere il contesto
Il Model Router sceglie la risorsa appropriata in funzione del task, della qualità richiesta, del contesto, della latenza, delle GPU disponibili e dei vincoli di sicurezza. Il documento ne descrive l’evoluzione dalle regole statiche a un routing che può apprendere dalle esecuzioni precedenti, bilanciando qualità, affidabilità e costo computazionale.
L’Agent Orchestrator affronta il livello successivo: scompone un obiettivo complesso in attività coordinate. Analizzare documenti, individuare rischi, verificare risultati e preparare un report può coinvolgere più agenti, modelli e strumenti. L’unità di lavoro diventa l’obiettivo da raggiungere, con il relativo percorso di esecuzione.
Il Sovereign RAG mantiene la conoscenza aziendale separata dal modello. Documenti, database, ERP, CRM e knowledge base alimentano una pipeline controllata di acquisizione, indicizzazione, retrieval e costruzione del contesto. Anche embedding e reranking possono essere eseguiti localmente. Contesto e memoria fanno parte della catena da governare, insieme ai dati dai quali dipendono.
Agire sui sistemi entro confini espliciti
Il Tool Gateway espone strumenti tramite API interne o MCP e applica autenticazione, autorizzazioni, policy, limiti, audit, isolamento delle credenziali e flussi di approvazione. L’agente riceve capacità controllate, senza ottenere automaticamente accesso a tutta l’infrastruttura.
L’Agent Sandbox definisce invece il perimetro dell’esecuzione: filesystem isolato, policy di rete, credenziali temporanee, limiti di risorse e durata, audit. Container, microVM e sandbox runtime sono possibili strumenti di implementazione. È il collegamento diretto con il sandbox come nuova unità di deployment dell’AI agentica: Kubernetes orchestra i workload software, mentre il Sovereign AI Layer coordina quelli cognitivi.
Security by architecture e Sovereign Routing
La localizzazione del modello non garantisce, da sola, la sicurezza. Il documento richiede un livello strutturale di controlli: Zero Trust, RBAC/ABAC, gestione dei segreti, segmentazione, cifratura, protezione dalla prompt injection, prevenzione della perdita di dati e sicurezza della supply chain. Anche i modelli devono attraversare processi di verifica della provenienza, scansione, validazione e approvazione.
La data classification entra nella decisione di routing. Classi come PUBLIC, INTERNAL, CONFIDENTIAL, RESTRICTED e CLASSIFIED possono determinare quali modelli, pool GPU, dataset, strumenti, sandbox e reti siano consentiti. Il router diventa così anche un punto di applicazione delle policy.
Questo chiarisce il significato di Sovereign Routing: decidere dove eseguire un workload in base alle regole dell’organizzazione. Quando le policy lo consentono, un servizio esterno può essere una destinazione possibile. In un ambiente isolato, quel ramo può essere assente. Il controllo resta nell’architettura.
Osservare la qualità, separare governo ed esecuzione
Una piattaforma multi-model e multi-agent deve rendere ricostruibile ogni esecuzione: modello scelto e motivo della scelta, prompt e contesto, strumenti utilizzati, risultato, latenza e consumo GPU. L’observability si completa con l’evaluation: qualità delle risposte, aderenza alle fonti, qualità del retrieval, successo di tool e agenti, costo ed energia per task. Le prestazioni dell’hardware raccontano soltanto una parte del risultato.
AI Control Plane
Governa registri di modelli e agenti, routing, identità, policy, valutazione, osservabilità, deployment e scheduling. Definisce le condizioni entro cui l’intelligenza può operare.
AI Data Plane
Esegue inferenza, embedding, reranking, RAG, agenti, strumenti, sandbox e workload GPU. Traduce le decisioni del piano di controllo in lavoro operativo.
Dal GPU Cluster alla Sovereign AI Factory
Alla base rimane il GPU Cluster. Serving, parallelismo, batching, cache, caricamento dei modelli e scheduling permettono di gestire risorse condivise senza legarle a un unico LLM: il cluster diventa un AI Compute Fabric.
La Sovereign AI Factory emerge quando a questa base si aggiungono inference, model registry, routing, orchestrazione, RAG, MCP, sandbox, osservabilità e governance. Le applicazioni possono richiedere capacità come cercare, classificare, estrarre, analizzare, pianificare o verificare senza conoscere il modello sottostante.
È la prospettiva strategica del documento: modelli, hardware, agenti e strumenti possono evolvere, mentre il livello che ne governa l’impiego rimane sotto il controllo dell’organizzazione.
È questo il punto di arrivo della Sovereign AI Architecture.
Sovereign AI Architecture — Dal modello AI al Sovereign AI Execution Layer
Approfondisci l’architettura attraverso 19 sezioni e i relativi schemi: criteri di routing, pipeline Sovereign RAG, controlli del Tool Gateway, isolamento degli agenti, classificazione dei dati, separazione dei piani e architettura integrata della Sovereign AI Factory.