L'azienda è tua. Chi controlla ciò che la fa funzionare?

Il consiglio più diffuso sulla sovranità del software è costruire tutto in casa. Suona deciso, ma confonde la proprietà con il controllo. Un Paese può finanziare un modello nazionale e continuare a dipendere da chip stranieri, da capacità cloud altrui, da un'orchestrazione proprietaria, da assistenza esterna e da contratti che rendono l'uscita impraticabile.

Io intendo la sovranità come controllo graduato sugli snodi critici dello stack. La domanda rilevante non è se un'organizzazione possieda ogni componente. È se qualcun altro possa negare l'accesso, cambiare le condizioni, ispezionare dati sensibili, limitare il deployment o catturare il valore creato sopra una dipendenza.

Questo fa della sovranità del software una questione di economia politica. La risposta decide chi controlla l'AI, chi ne cattura i margini, quanto potere negoziale conservano gli acquirenti e se gli appalti pubblici creano capacità durevole o si limitano ad affittare l'accesso all'infrastruttura di un'altra azienda.

La sovranità è controllo, non proprietà

Il primo errore è trattare la sovranità come una bandiera appesa a un prodotto. Un servizio può portare un marchio locale mentre calcolo, catena di fornitura del software, aggiornamenti, accesso all'assistenza o esposizione legale restano esterni. All'inverso, un'organizzazione può mantenere un controllo reale su uno stack misto se è in grado di verificare i componenti, spostare i carichi di lavoro, proteggere le proprie chiavi e negoziare avendo in mano un'alternativa credibile.

Il Cloud Sovereignty Framework della Commissione europea dà a questa idea una forma operativa. Valuta la sovranità su 48 criteri in otto categorie, tra cui apertura, trasparenza e indipendenza dello stack tecnologico, invece di ridurre tutto alla localizzazione dei dati. I criteri chiedono se il software sia a licenza aperta, verificabile, modificabile e ridistribuibile, e se l'acquirente disponga di diritti concreti per ispezionare il codice, cambiare fornitore e mantenere il controllo delle chiavi di cifratura. In questa impostazione la sovranità è qualcosa che l'acquirente può mettere alla prova.

All'inizio dell'anno ho chiesto chi controlla l'AI e ho risposto che si decide nei contratti, non nei parlamenti. A giugno, quando un ordine statunitense ha ritirato Fable 5 tre giorni dopo il lancio, ho scritto che l'interruttore non è tuo. Una clausola e un interruttore, ciascuno su un solo strato. Questo pezzo è la mappa dell'intero stack, e di dove stanno tutti gli altri interruttori.

I punti di controllo stanno ad altezze diverse. I controlli sulle esportazioni possono limitare l'accesso ai chip avanzati anche quando il codice resta aperto. La concentrazione del cloud può dare a pochi fornitori influenza su prezzi, capacità di deployment ed esposizione legale. I formati proprietari possono rendere costoso spostare un carico di lavoro che in teoria sarebbe portabile. I contratti possono decidere chi può riutilizzare i dati, addestrare un modello, gestire il sistema o recuperarlo alla scadenza.

Il test pratico: individua la dipendenza che può fermare il deployment o estrarre la rendita più alta, poi misura quanto è facile sostituirla.

Guardo la questione da un punto di osservazione europeo, ma la logica vale ovunque. Governi, investitori e chi guida un'azienda affrontano la stessa scelta di fondo: localizzare una dipendenza, diversificarla o accettarla negoziando delle tutele. La risposta giusta dipende dallo strato, dalla minaccia e dal valore in gioco.

Una domanda binaria, sovrano o non sovrano, produce decisioni sbagliate. Una mappa graduata del controllo dice dove spendere, dove irrigidire le condizioni di acquisto e dove un'etichetta di sovranità offre poco più di una rassicurazione.

Che cos'è davvero lo stack: dal silicio all'applicazione

Lo stack del software va dal silicio all'applicazione, e ogni strato crea una dipendenza distinta. Semiconduttori e strumenti di produzione sono le fondamenta; l'infrastruttura cloud fornisce l'ambiente operativo; middleware e orchestrazione ne coordinano il funzionamento interno; i modelli forniscono capacità specializzate; le applicazioni trasformano tutto questo in servizi per clienti e istituzioni pubbliche.

Le fondamenta partono dai chip avanzati, dalle macchine per produrli e dalle catene di fornitura che rendono possibile il calcolo su larga scala. Questi componenti decidono quali carichi di lavoro possono girare, con quale capacità e con quali autorizzazioni. La sequenza dei controlli statunitensi sulle esportazioni mostra perché questo strato appartiene a qualsiasi valutazione di sovranità. I controlli sono iniziati il 7 ottobre 2022, si sono ampliati il 17 ottobre 2023, e una norma pubblicata il 13 gennaio 2025 ha introdotto vincoli di licenza a livello mondiale per i chip avanzati e i pesi dei modelli, con adeguamento fissato al 15 maggio 2025 — poi la norma è stata ritirata poco prima di quella data, il che conferma il punto invece di indebolirlo: l'accesso a questo strato cambia per decisione amministrativa. La guida pratica di Onelex Partners ai controlli statunitensi ricostruisce come quelle decisioni ridisegnano l'accesso agli artefatti fisici e ai modelli che stanno sotto il software.

L'infrastruttura cloud poggia su quelle fondamenta. Fornisce calcolo, storage, rete e servizi gestiti che trasformano l'hardware in un ambiente operativo accessibile. La sovranità del cloud riguarda quindi molto più della posizione di un server: include la proprietà del fornitore, la giurisdizione, l'accesso al piano di controllo, le condizioni di assistenza, la resilienza e la capacità di imporre condizioni tecniche o commerciali.

Middleware e orchestrazione collegano l'infrastruttura ai carichi di lavoro. Pianificano i container, gestiscono le identità, espongono le interfacce e coordinano il movimento dei dati. Il loro disegno decide spesso se un cliente può spostare un'applicazione senza riscriverla. Interfacce documentate e componenti sostituibili danno all'acquirente più controllo reale di quanto ne diano formati privati o comportamenti non dichiarati.

I modelli aggiungono un'altra dipendenza. Pesi, dati di addestramento, requisiti di inferenza, controlli di sicurezza e processi di aggiornamento possono ricadere sotto proprietà e regimi giuridici diversi. Un'organizzazione può controllare la propria applicazione e restare dipendente dalla politica di accesso, dai prezzi, dal calendario delle release o dagli usi consentiti dal fornitore del modello. Quella dipendenza incide sulle opzioni di acquisto e sul margine disponibile per chi possiede l'applicazione.

Le applicazioni occupano lo strato visibile e trasformano lo stack in valore commerciale o pubblico. Contengono i flussi di lavoro, le relazioni con i clienti e la conoscenza operativa, quindi è lì che spesso compaiono i ricavi. Ma gli strati inferiori possono catturare il margine con i costi di calcolo, di accesso, di cambio fornitore e di assistenza.

L'architettura conta perché il valore può accumularsi in uno strato che il cliente non vede mai. Un'applicazione curata può dipendere da un'infrastruttura controllata altrove. Un servizio locale può ereditare comunque un'esposizione legale straniera. Un modello può sembrare aperto mentre i suoi requisiti di calcolo rendono irrealistico farlo girare in autonomia.

Come ogni strato diventa uno snodo di controllo

La sovranità cede nei punti in cui un altro attore può negare l'accesso, alzare i costi, ispezionare l'attività, imporre condizioni o rendere difficile la sostituzione. Ogni strato crea una forma di controllo diversa, e la domanda decisiva è chi può interrompere le operazioni o catturare il margine che ne deriva.

Il silicio trasforma la regolazione in controllo della capacità

Lo strato dei chip converte la legge in accesso autorizzato a una capacità tecnica scarsa. I controlli sulle esportazioni sono passati dalle restrizioni mirate sulla Cina del 2022 a una supervisione più ampia nel 2025, che copre chip avanzati e pesi dei modelli su una geografia più estesa. La cronologia documentata dei controlli mostra perché il codice aperto non può garantire una capacità sovrana quando l'hardware necessario per farlo girare resta soggetto a licenze esterne.

Qui il controllo funziona per autorizzazione. Un regolatore non ha bisogno di possedere un'applicazione per influenzare chi può addestrarla, distribuirla o scalarla. Chi controlla le macchine di produzione, i componenti o le autorizzazioni legali rilevanti fissa il perimetro praticabile dell'economia del software. Chi compra dovrebbe quindi trattare l'accesso al calcolo come una dipendenza contrattuale e politica, non solo come un input infrastrutturale.

Il cloud trasforma la concentrazione in potere negoziale

La concentrazione del cloud crea uno snodo sia commerciale sia giurisdizionale. L'analisi di Synergy Research sul mercato cloud del secondo trimestre mostra un numero ristretto di fornitori con una quota ampia dell'infrastruttura cloud mondiale, il che concentra in poche mani la capacità di calcolo, storage e deployment dell'AI delle imprese.

L'effetto va oltre il prezzo. La concentrazione plasma le condizioni di acquisto, la pianificazione della resilienza, la localizzazione dei dati e l'esposizione a giurisdizioni straniere. Un acquirente che non può spostare un carico di lavoro senza riprogettarlo ha già ceduto il proprio potere negoziale prima del prossimo rinnovo. I costi di cambio trasferiscono valore da chi possiede l'applicazione a chi fornisce l'infrastruttura, anche quando il cliente è il proprietario della relazione con l'utente finale.

La provenienza del software decide se il controllo è verificabile

Lo strato software stabilisce se un'organizzazione può ispezionare, modificare e ridistribuire i componenti da cui dipende. Le licenze aperte non eliminano ogni dipendenza, ma creano le condizioni legali e tecniche per la verifica e la sostituzione. I componenti chiusi possono andare bene per un carico di lavoro, ma l'acquirente dovrebbe mettere a bilancio quella dipendenza invece di chiamarla sovranità.

Il Sovereign Cloud Stack rende concreta questa scelta ingegneristica. Usa componenti open source modulari, tra cui OpenStack e Kubernetes, con API aperte e interfacce documentate. Il disegno punta a rendere tecnicamente praticabile il cambio di fornitore e a dare agli utenti una base per verificare e adattare lo stack senza dipendere da un unico soggetto. Tratta la sovranità come una proprietà del progetto, non come una promessa in una presentazione commerciale.

I contratti decidono chi cattura il valore a valle

Al confine con l'applicazione, i contratti assegnano i diritti su dati, formati, modelli, assistenza e uscita. L'analisi dell'OCSE sull'AI negli appalti pubblici avverte che accordi restrittivi sulla licenza dei dati creano lock-in, e che tecnologie e formati proprietari possono lasciare un'amministrazione fortemente dipendente dal proprio fornitore. Le condizioni di acquisto sono un meccanismo diretto per distribuire interoperabilità, costi di uscita e potere negoziale.

Per questo tratto la sovranità come una mappa del controllo, non come un'indicazione di nazionalità. Un'organizzazione può controllare le proprie chiavi di cifratura, dipendere da chip esterni e mantenere un controllo parziale sull'orchestrazione. La sua posizione dipende da quale debolezza può interrompere le operazioni, limitare le scelte o spostare margine verso un fornitore. Una dipendenza diventa politica quando un attore può decidere chi partecipa, a quali condizioni e a quale costo — la stessa logica che ho applicato alle mappe dei social network.

Tre modelli di sovranità dello stack nella pratica

Tre modelli di policy si contendono l'influenza, e nessuno garantisce l'autosufficienza completa. L'approccio europeo cerca garanzie graduate e interoperabilità. Quello statunitense combina il controllo degli snodi critici con la portata dell'infrastruttura hyperscale. Quello cinese dà più peso alla sostituzione quando vincoli esterni minacciano l'accesso.

Il modello europeo parte dalla misurazione. Il Cloud Sovereignty Framework definisce i criteri di apertura, trasparenza e indipendenza, mentre il Cloud and AI Development Act fissa quattro livelli di garanzia per la sovranità del cloud e dell'AI. Il livello 2 richiede ai fornitori di dimostrare l'indipendenza da Paesi terzi e la trasparenza sulla catena di fornitura del software, e gli Stati membri possono riconoscere un fornitore solo dopo un audit. Provenienza e governance diventano condizioni di accesso al mercato.

L'obiettivo economico è il potere dell'acquirente. Le amministrazioni che possono confrontare le garanzie, mantenere il controllo delle chiavi, ispezionare il software e cambiare fornitore trattengono nel mercato europeo più valore generato dall'AI. Il compromesso è pratico: criteri, audit e architetture interoperabili aumentano il lavoro degli acquisti e possono ridurre il numero di fornitori idonei. La sovranità europea è una disciplina d'acquisto, non un test di nazionalità.

Il modello statunitense funziona attraverso il controllo degli snodi. I controlli sulle esportazioni regolano l'accesso al calcolo avanzato, mentre i fornitori con sede negli Stati Uniti detengono una quota combinata dominante dell'infrastruttura cloud mondiale. La concentrazione nello strato infrastrutturale permette alla scala di rafforzare l'influenza strategica. Il modello cattura valore attraverso input controllati e le rendite ricorrenti generate da un'infrastruttura usata ovunque. Clienti e governi stranieri, in cambio, si trovano con una dipendenza concentrata, un'esposizione giurisdizionale e un minore potere di cambiare fornitore.

Il modello cinese spinge sulla sostituzione dove le restrizioni esterne minacciano l'accesso. Il rimpiazzo con componenti nazionali protegge la continuità e sostiene la domanda interna, ma crea anche duplicazioni, costi di compatibilità e un accesso meno efficiente ai sistemi globali. L'obiettivo è la resilienza strategica. Il prezzo è il capitale e il coordinamento necessari a sostituire i componenti esterni invece di governare la dipendenza da essi.

I tre modelli distribuiscono il controllo in modo diverso:

• Garanzie graduate (Europa). Leva: criteri, audit, interfacce aperte e condizioni d'acquisto. Compromesso: controllo più verificabile, con maggiori oneri di conformità e integrazione.
• Controllo degli snodi (Stati Uniti). Leva: controlli sulle esportazioni, accesso al calcolo avanzato e infrastruttura hyperscale. Compromesso: leva strategica e scala, con una dipendenza estera concentrata per gli acquirenti.
• Sostituzione (Cina). Leva: rimpiazzo nazionale dei componenti soggetti a vincoli esterni. Compromesso: continuità e controllo politico, con costi di duplicazione e interoperabilità.

La domanda rilevante è chi paga e chi cattura il margine che ne risulta. L'Europa prova a spostare il potere verso acquirenti e istituzioni pubbliche. Il modello statunitense concentra il valore intorno a input e infrastrutture controllati. La Cina privilegia la continuità attraverso la sostituzione. Un'organizzazione europea che sceglie uno stack per l'AI sceglie una logica economica, non solo una configurazione tecnica.

La sovranità si misura sul controllo di chip, capacità cloud, provenienza del software e uscita contrattuale — non sulla proprietà di ogni strato.

Trasformare la sovranità in contratti e potere d'acquisto

La sovranità diventa reale quando un acquirente può verificarla prima di firmare e farla valere dopo il deployment. La nazionalità del fornitore non risponde alle domande operative. È il contratto che deve stabilire chi può ispezionare, spostare, gestire, aggiornare e recuperare il sistema.

Partire dai diritti, non dalle etichette

Il framework europeo offre un vocabolario utile per gli acquisti. L'acquirente dovrebbe chiedersi se può ispezionare il codice rilevante, modificare i componenti consentiti, ridistribuirli dove la licenza lo permette, controllare le chiavi di cifratura e cambiare fornitore senza perdere funzioni essenziali. Questi diritti trasformano un obiettivo politico generico in criteri di accettazione.

L'architettura tecnica deve sostenere il contratto. Il modello del Sovereign Cloud Stack si basa su API aperte e interfacce documentate perché il cambio di fornitore resti praticabile. Non garantisce una migrazione economica, ma sposta la posizione dell'acquirente da una portabilità teorica a un requisito ingegneristico che si può mettere alla prova.

Un capitolato serio dovrebbe richiedere prove di:

• Provenienza del software: un inventario aggiornato dei componenti critici, delle licenze, delle dipendenze e delle responsabilità di aggiornamento.
• Accesso in audit: il diritto di ispezionare codice, configurazioni, log e registri della catena di fornitura, entro legittimi vincoli di sicurezza.
• Autorità sulle chiavi: chiavi di cifratura controllate dal cliente e un processo chiaro per accesso, rotazione, recupero e revoca.
• Portabilità: formati di esportazione documentati, interfacce utilizzabili e obblighi di assistenza che non dipendano dalla discrezione di un solo fornitore.
• Indipendenza operativa: responsabilità nominate per risposta agli incidenti, ripristino, patch e continuità se il fornitore viene meno.
• Economia dell'uscita: supporto all'uscita definito, restituzione dei dati, prova della cancellazione e limiti ai costi che potrebbero rendere impraticabile andarsene.

Regola contrattuale: se un fornitore non sa spiegare come te ne andrai, la sua sovranità descrive una dipendenza, non un controllo.

Trattare i diritti sui dati come diritti sul valore

L'analisi dell'OCSE sugli appalti mette la licenza dei dati al centro del lock-in. Un'amministrazione può possedere fisicamente i dati e non avere il diritto legale di condividerli con un altro sviluppatore, riutilizzarli in un sistema sostitutivo o conservare i formati necessari alla migrazione. Quell'assetto dà al fornitore il controllo sulle opzioni future dell'acquirente e sul valore a valle che i dati generano.

Chi compra dovrebbe separare tre domande che i fornitori tendono a fondere. Chi possiede o controlla i dati di origine? Chi può usarli per migliorare un servizio o un modello? Chi riceve gli output derivati, i metadati e le registrazioni operative alla scadenza del contratto?

Le risposte incidono sui margini. Se un acquirente deve pagare il fornitore uscente per interpretare i propri dati, il fornitore cattura valore molto dopo l'implementazione iniziale. Ho affrontato il problema più ampio della distribuzione del valore in Task force sull'AI, dove il tema è la governance più che la scelta del prodotto.

L'acquirente dovrebbe anche pretendere garanzie proporzionate al carico di lavoro. La struttura a quattro livelli del Cloud and AI Development Act offre un modello di requisiti graduati. Un servizio pubblico sensibile può richiedere un'indipendenza verificata da Paesi terzi e controlli trasparenti sulla catena di fornitura del software. Un flusso di lavoro interno a basso rischio può richiedere portabilità e diritti sui dati senza lo stesso onere di garanzia.

L'economia della sovranità: quando duplicare conviene e quando no

Uno stack sovrano ha un costo, ma ce l'ha anche la dipendenza. L'errore è contare solo l'infrastruttura duplicata e ignorare il prezzo del potere negoziale perduto, dell'accesso limitato, dei ritardi regolatori o di un'uscita che arriva nel mezzo di una crisi.

IDC ha rilevato nel 2026 che il 63% delle organizzazioni era più propenso ad adottare servizi di cloud sovrano a causa degli eventi geopolitici. La stessa analisi prevede che entro il 2028 il 60% delle multinazionali dividerà i propri stack per l'AI tra zone sovrane, con costi di integrazione triplicati man mano che cresce la frammentazione. La domanda di controllo sale mentre le architetture frammentate impongono un onere di integrazione significativo.

Questo non rende la duplicazione irrazionale. Significa che l'investimento ha bisogno di uno scopo definito. La ridondanza sulle infrastrutture critiche protegge la continuità. Il controllo locale preserva l'accesso ai mercati regolati. I componenti aperti riducono il costo futuro del cambio. Ma duplicare un servizio commodity senza ridurre una dipendenza reale trasferisce denaro dal margine dell'acquirente a un altro strato infrastrutturale.

Una decisione di portafoglio per chi guida la finanza

Dividerei lo stack in tre portafogli.

Proteggere: localizzare o duplicare gli strati in cui un guasto, un intervento legale o il ritiro del fornitore minaccerebbero le operazioni essenziali. I chip sono difficili da localizzare, ma un'organizzazione può comunque pianificare capacità, priorità dei carichi e percorsi di esecuzione alternativi.

Negoziare: gestire le dipendenze in cui la sostituzione sarebbe antieconomica. Usare interfacce aperte, controllo delle chiavi, diritti di audit e durate limitate per tenere confinata l'influenza del fornitore. Spesso è più razionale che ricostruire ogni componente.

Sostituire: investire in alternative aperte o nazionali dove la dipendenza cattura un valore rilevante e la sostituzione è tecnicamente praticabile. La decisione deve includere costo di migrazione, capacità di assistenza, manutenzione della sicurezza ed effetti sull'interoperabilità.

L'agenda europea 2026 sulla sovranità tecnologica collega semiconduttori, cloud, AI e open source, e punta a triplicare la capacità dei data center in cinque-sette anni. Lo studio del Parlamento europeo sulle dipendenze software e cyber mostra perché la costruzione di capacità non può essere separata dalle scelte su software e acquisti. Più capacità aiuta, ma non crea sovranità se piani di controllo, licenze e assistenza restano esterni.

La domanda sul margine è quindi più netta di "possiamo costruirlo da soli?". È "quale dipendenza può estrarre da noi più valore, e qual è il modo credibile più economico per ridurre quella leva?". Come i fornitori concentrati catturano il surplus economico l'ho esplorato in surplus del produttore e monopolio.

Che cosa dovrebbero fare adesso i decisori

Chi guida un'azienda dovrebbe mappare lo stack per dipendenza, non per logo del fornitore. Registrare chi controlla l'accesso all'hardware, gli account cloud, le chiavi, il codice sorgente, i pesi dei modelli, i formati dei dati, gli aggiornamenti e il ripristino. Poi ordinare ogni dipendenza per il danno che può causare e per il costo della sua sostituzione.

Gli investitori dovrebbero trattare le dichiarazioni di sovranità come questioni di prova. Chiedersi se un'azienda controlla un vero snodo critico, ha un'architettura portabile, o si limita a reimpacchettare infrastrutture controllate da altri. I ricavi possono crescere mentre il controllo strategico si riduce, se il fornitore cattura il margine critico.

I legislatori dovrebbero fissare soglie d'acquisto graduate invece di pretendere un'autosufficienza di facciata. Richiedere catene di fornitura del software verificabili, interfacce aperte, dati portabili, controllo delle chiavi da parte del cliente e piani di uscita credibili, dove il valore pubblico o la sicurezza giustificano l'onere.

La decisione del prossimo trimestre è pratica. Scegli una dipendenza ad alto valore, documenta i diritti di cui hai bisogno, prova un percorso di migrazione e metti un prezzo al costo di restare esposto. La sovranità diventa utile quando cambia quella decisione.

Lo stesso test, applicato a ELECTE

Ho applicato lo stesso test a ELECTE prima di scrivere questo pezzo. La risposta onesta non è che siamo sovrani. È che sappiamo quali fornitori potrebbero interromperci, che cosa possono vedere e quanto ci costerebbe andarcene, e che abbiamo tenuto quella lista corta di proposito. La piattaforma ELECTE 4.5, che annunciamo questa settimana, è costruita con la stessa regola. È l'unica dichiarazione di sovranità che ti chiederei di verificare, per noi come per chiunque altro.

Fonti

• Commissione europea, Sovereign Cloud Framework explained (giugno 2026)
• Commissione europea, Cloud and AI Development Act
• Onelex Partners, US export controls and AI: a practitioner's guide
• Synergy Research Group, Q2 cloud market passes $143 billion, highest growth rate in eight years
• Sovereign Cloud Stack, About SCS
• OCSE, Governing with Artificial Intelligence: AI in public procurement (2025)
• IDC, The high cost of sovereignty in the age of AI (2026)
• Parlamento europeo, Study on software and cyber dependencies (2025)

Fabio Lauria

CEO & Founder, ELECTE

Ogni settimana esploriamo l'AI senza l'hype — con dati, analisi e una prospettiva indipendente.

Se hai trovato utile questa analisi, condividila con qualcuno che potrebbe esserne interessato. E se desideri scoprire come ELECTE utilizza l'intelligenza artificiale per automatizzare l'analisi dei dati e la creazione di report, puoi trovare ulteriori informazioni su electe.net.