Come costruire una sovranità calibrata sul rischio nel settore bancario

Executive Summary

La sovranità digitale per le banche e le imprese di servizi finanziari è passata da un dibattito sulla residenza dei dati e sulla politica a una disciplina concreta. È sempre più essenziale per la resilienza operativa, la garanzia di conformità normativa, la strategia cloud e AI e per il modo in cui le imprese gestiscono la propria dipendenza dai provider. Per le istituzioni dell’area DACH e di tutta Europa, la domanda è diventata concreta: quando la perdita di controllo, accesso, resilienza, disponibilità dei dati o della possibilità di uscire da un contratto di sourcing determina un rischio inaccettabile?

La sovranità calibrata sul rischio (Risk-Calibrated Sovereignty, RCS) consiste nell’applicazione di specifici controlli di sovranità ai workload, ai dati e ai provider di un’organizzazione nei casi in cui la perdita di controllo è più rilevante, mantenendo accordi standard altrove. La calibrazione sul rischio consente a un’organizzazione BFSI di disporre di un livello di controllo difendibile anche in caso di interruzioni gravi ma plausibili, anziché limitarsi al minimo controllo possibile. In linea con recenti impostazioni di analisti e mondo accademico, la sovranità viene considerata come un insieme di decisioni graduate lungo lo stack tecnologico, anziché come un’architettura “tutto o niente”.

I requisiti di sovranità rappresentano un’estensione del vendor management basato sul rischio: dovrebbero introdurre livelli incrementali di governance, investimento e scrutinio dei provider proporzionati all’esposizione al rischio, non al volume di spesa.

La disciplina della sovranità digitale si fonda su cinque principi:

• Basata sul rischio, non sulla spesa – anziché seguire il valore del contratto, i controlli devono riflettere dipendenza, criticità, sensibilità dei dati, recuperabilità e fattibilità dell’uscita.
• Progettata e implementata strategicamente – i controlli sono ancorati alla strategia IT e di sourcing, espressi attraverso il disegno dell’ecosistema dei provider ed eseguiti nelle attività di sourcing e vendor management.
• Basata su evidenze – una dichiarazione di “hosting nell’UE” o di servizio “sovrano” non è sufficiente senza evidenze della sovranità sul control plane, sull’accesso al supporto, sui metadati, sulla custodia delle chiavi, sui subfornitori e sugli scenari di uscita testati o pianificati.
• Specifica per workload – workload, capability e funzioni devono essere classificati per ricevere requisiti differenziati.
• Praticabile, non ideologica – le organizzazioni dovrebbero evitare sia il “teatro della sovranità” sia il massimalismo della sovranità; l’obiettivo è garantire un controllo sufficiente dove il controllo conta di più.

Perché la sovranità è oggi una disciplina di rischio bancario

Molte banche, in particolare quelle europee, affrontano una convergenza di pressioni: incertezza geopolitica, concentrazione in un numero ristretto di piattaforme tecnologiche globali, maggiori aspettative di vigilanza sulla resilienza operativa, rapida adozione dell’AI e forte dipendenza da ecosistemi complessi di provider. La sovranità è diventata il linguaggio operativo per il controllo di dati, infrastrutture, management plane, crittografia, evidenze e capacità di ripristino dopo interruzioni non intenzionali.

Il contesto normativo si è irrigidito. DORA è entrato in vigore nel gennaio 2025 e, nel novembre 2025, le Autorità europee di vigilanza hanno designato i primi fornitori terzi critici di servizi ICT (CTPP) sottoposti a supervisione diretta dell’UE. È una prova concreta del fatto che la concentrazione su pochi provider è ormai una preoccupazione di vigilanza. La Guida BCE 2025 sull’esternalizzazione verso fornitori di servizi cloud rafforza un approccio proporzionato e basato sul rischio.

Meno discusse ma altrettanto importanti, le disposizioni del Data Act dell’UE sul cambio di provider cloud e sulla portabilità sono entrate in applicazione nel settembre 2025. Ciò offre alle banche diritti esercitabili di migrazione dei workload e di uscita e rimuove la maggior parte delle commissioni di switching fino a gennaio 2027. L’AI Act dell’UE aggiunge un ulteriore livello: gli obblighi per i fornitori di modelli di AI general-purpose hanno iniziato ad applicarsi nell’agosto 2025, influenzando il modo in cui le banche valutano modelli esterni, hosting e flussi di dati.

Altri due regimi innalzano la baseline di sicurezza e resilienza: 1) NIS2 amplia gli obblighi di cybersecurity e di segnalazione degli incidenti per le entità essenziali e le loro supply chain; 2) il Cyber Resilience Act introduce requisiti di sicurezza per i prodotti digitali. Entrambi incidono sulla selezione dei provider, sulla verifica dei subfornitori e sulle evidenze di resilienza.

Nel 2026 il dibattito politico si è tradotto in framework concreti. Germania e Francia hanno presentato nel giugno 2026 una definizione congiunta di sovranità digitale, sviluppata dal Ministero tedesco per il digitale (BMDS), dalla Cancelleria e dalla Direzione generale francese per le imprese (DGE) come contributo all’EU Tech Sovereignty Package, definendo la sovranità come la capacità di sviluppare, fornire, utilizzare, adattare e controllare tecnologie digitali in modo indipendente.

La definizione si articola in sei dimensioni basate sul rischio:

1. Capacità di enforcement
2. Competenze tecnologiche
3. Creazione di valore economico
4. Protezione dei dati sensibili
5. Sostituibilità e interoperabilità
6. Resilienza dell’infrastruttura

Il pacchetto della Commissione europea aggiunge il Cloud and AI Development Act e una strategia UE per l’open source. Anche il sentiment della domanda va nella stessa direzione: Bitkom rileva che il 78% delle aziende tedesche è preoccupato per la dipendenza da un numero ristretto di provider non UE e quasi due terzi considerano la localizzazione dei data center nell’UE un criterio di selezione importante. Gran parte di questa spinta riguarda lo Stato e il settore pubblico, ma indica la direzione anche per i settori regolamentati: le banche dovrebbero aspettarsi che lo stesso vocabolario emerga nel dialogo con le autorità di vigilanza, nella due diligence dei clienti e nelle interpretazioni della resilienza digitale ai sensi del regolamento DORA.

Oltre la residenza dei dati

La residenza dei dati resta importante, ma da sola non garantisce più il controllo: un workload può essere ospitato in un data center dell’UE mentre amministrazione, supporto e chiavi di cifratura sono governati da giurisdizioni esterne all’Europa.

Analisi recenti dei control plane cloud sostengono che la sovranità debba estendersi all’autorità di governance, agli accessi privilegiati, alla fiducia crittografica, al controllo del ciclo di vita dei dati, all’osservabilità e alla risposta agli incidenti. Per una banca, quindi, le verifiche rilevanti non riguardano soltanto “dove sono archiviati i dati?”, ma anche:

• Chi è autorizzato ad amministrare l’ambiente?
• Chi è autorizzato ad accedere a metadati e telemetria?
• Dove vengono controllate le chiavi di cifratura?
• Come e da dove viene erogato il supporto?
• Quali entità giuridiche sono coinvolte?
• Possiamo continuare a operare se l’accesso del provider è compromesso?

Quest’ultimo punto è reso ancora più critico dall’esposizione a norme con effetti extraterritoriali, come lo U.S. CLOUD Act e il PATRIOT Act, che possono raggiungere un provider globale indipendentemente da dove i dati europei siano fisicamente collocati.

Un panorama dei provider in rapida evoluzione

Le opzioni disponibili sul mercato sono cresciute rapidamente:

• AWS ha aperto il proprio European Sovereign Cloud nel Brandeburgo, in Germania, gestito da personale residente nell’UE sotto una capogruppo controllata nell’UE, nel gennaio 2026.
• Microsoft ha annunciato un modello a tre livelli che comprende Sovereign Public Cloud, Sovereign Private Cloud e National Partner Clouds, tra cui Delos Cloud in Germania e Bleu in Francia.
• Google e T-Systems offrono un cloud sovrano tedesco gestito congiuntamente (T-Systems Sovereign Cloud powered by Google Cloud).
• Schwarz Digits, divisione tecnologica del gruppo tedesco Schwarz (Lidl e Kaufland), sta sviluppando insieme a Google un’offerta workplace sovrana: Google Workspace in esecuzione sul cloud STACKIT di Schwarz, con crittografia client-side e residenza e backup dei dati esclusivamente nell’UE, espressamente indirizzata ai settori regolamentati, inclusi i servizi finanziari.
• Provider europei come OVHcloud propongono servizi qualificati SecNumCloud per workload sensibili.

Il panorama copre un ampio spettro: regioni sovrane degli hyperscaler, provider europei, cloud di partner nazionali, hosting privato e regolamentato, controlli sovereign-SaaS e pattern crittografici.

Per le banche il compito è associare il pattern corretto al workload corretto e verificare la sostanza che si cela dietro ogni etichetta “sovrana”. L’obiettivo va oltre la protezione dei “dati”: sovranità significa garantire un’attività stabile e sicura, coerente con il ruolo della banca come istituzione di fiducia per clienti retail e wholesale.

La sovranità come estensione del vendor management basato sul rischio

La sovranità si comprende al meglio come la successiva evoluzione di un vendor management maturo. Le funzioni mature e resilienti modulano già l’intensità delle attività in base a criticità, sensibilità dei dati, dipendenza, sostituibilità, concentrazione e impatto normativo. La sovranità aggiunge le dimensioni di giurisdizione, control plane, disponibilità dei dati e uscita.

Soprattutto, la spesa è un indicatore poco affidabile del rischio: un provider SaaS di nicchia con bassa spesa può trattare dati sensibili dei clienti o creare un grave vincolo di uscita, mentre un provider ad alta spesa può supportare soltanto servizi commodity. I risultati esemplificativi delle valutazioni del rischio ISG per i clienti mostrano spesso un salto di due livelli di categoria di rischio rispetto alla precedente classificazione basata sulla spesa.

In pratica, ciò significa che il tiering dei provider deve incorporare l’esposizione alla sovranità, non soltanto il valore del contratto; la due diligence deve verificare il controllo operativo e la fattibilità dell’uscita prima della selezione; le evidenze devono essere raccolte in modo continuativo, non solo in fase di onboarding; e il rischio residuo deve essere esplicitamente accettato quando non esiste un’alternativa sovrana praticabile.

Gli appalti pubblici mostrano in quale direzione si sta muovendo la prassi contrattuale. Il Vergabebeschleunigungsgesetz tedesco (in vigore da luglio 2026) rende gli “aspetti della sovranità digitale” un criterio esplicito di aggiudicazione (§ 58 VgV) e, ancor più significativamente, una condizione ammissibile di esecuzione contrattuale (§ 128 GWB) che vincola il provider per l’intera durata del contratto, prevedendo diritti di risoluzione e penali in caso di violazione.

Le banche dovrebbero riflettere questo modello nelle proprie attività di sourcing: i requisiti di sovranità meritano lo status di obblighi contrattuali continuativi e supportati da evidenze – localizzazione dei dati, diritti di accesso, infrastruttura certificata – con conseguenze sull’uscita, oltre a essere valutati in fase di selezione.

Poiché le banche consumano tecnologia attraverso diversi ecosistemi – hyperscaler, piattaforme SaaS, integrator, provider di servizi gestiti e dati, provider di modelli AI e relativi subfornitori – la gestione dell’ecosistema dei provider diventa il ponte tra strategia ed esecuzione.

La sovranità calibrata sul rischio come principio operativo

La RCS è l’applicazione deliberata di controlli sufficienti ai workload, ai dati, ai provider e ai layer tecnologici in cui la perdita di controllo genererebbe un rischio inaccettabile. Respinge sia l’ipotesi che ogni workload richieda uno stack completamente sovrano, sia l’ipotesi che i servizi standard di public cloud, SaaS o AI siano accettabili semplicemente perché convenienti o privi di alternative pratiche.

L’obiettivo è un controllo gestito in funzione del rischio, progettato consapevolmente e governato in modo trasparente senza perdere funzionalità e valore di business. Le banche dovrebbero evitare due modalità di fallimento:

• Teatro della sovranità – dichiarazioni fondate sulla localizzazione dei data center nell’UE o su etichette di marketing, senza un controllo operativo applicabile e supportato da evidenze, che producono falsa sicurezza e una debole posizione in sede di audit.
• Massimalismo della sovranità – tentare di replicare ogni servizio con un’alternativa sovrana indipendentemente da rischio, costo o valore di business, generando costi eccessivi, innovazione più lenta e fragilità operativa.

Tra questi due estremi si trova una trappola più sottile: acquistare sovranità al prezzo di una nuova dipendenza. La valutazione del rischio delle misure di sovranità e delle alternative sovrane deve quindi considerare anche le nuove dipendenze e i lock-in che esse creano. Sostituire un hyperscaler con un singolo vendor UE può semplicemente scambiare un rischio di concentrazione con un altro, spesso caratterizzato da interfacce proprietarie, un ecosistema più ristretto e alternative meno collaudate.

Le strategie di uscita devono tenerne conto: portabilità, second source e runbook di uscita testati si applicano all’alternativa sovrana non meno che al provider che essa sostituisce. Standard aperti, architetture modulari, una software bill of materials (SBOM) e opzioni open source credibili sono gli strumenti pratici che mantengono reale la sostituibilità ed evitano che un posizionamento sovrano diventi semplicemente un’altra scommessa su un singolo vendor.

Una postura calibrata sul rischio può comunque fissare standard rigorosi. Per un workload di pagamento critico, ad esempio, può richiedere un forte controllo operativo nell’UE, chiavi detenute dal cliente, uscita testata, backup indipendente, limiti rigorosi all’accesso del supporto e rischio residuo approvato dal board.

Per la collaboration commodity, può invece significare controlli contrattuali, un data boundary UE, crittografia di base, monitoraggio standard e una dichiarazione documentata del rischio residuo, inclusa una second source flessibile e testata disponibile in caso di cessazione improvvisa o indisponibilità.

I critici della RCS sostengono che, di fronte a scenari di tail risk come sanzioni improvvise, imposizioni legali o fratture geopolitiche, una postura “minima” possa lasciare una banca esposta proprio quando il controllo conta di più e che il costo di una sovranità più completa sia semplicemente il prezzo della resilienza reale. Il tail risk è concreto: quando nel 2025 le sanzioni statunitensi hanno colpito il procuratore capo della Corte penale internazionale, l’accesso alla sua e-mail ospitata da Microsoft è stato perso e la Corte ha successivamente iniziato a migrare verso alternative open source. Per una banca, una sospensione equivalente di un servizio di pagamenti, screening delle sanzioni o trading gestito da un operatore statunitense entrerebbe in conflitto, nel giro di secondi o giorni, con gli obblighi SEPA di pagamento istantaneo e regolamento: un gap che nessun rimedio contrattuale potrebbe colmare abbastanza rapidamente.

La RCS prende sul serio questa obiezione e risponde con la governance: il trade-off viene reso esplicito e affidato al board, come per ogni requisito normativo che richiede consapevolezza del rischio e accettazione consapevole da parte del board. Quando un tail risk credibile sarebbe catastrofico e irreversibile, il workload appartiene a un tier più elevato con controlli più forti, e il rischio residuo di qualsiasi opzione inferiore deve essere consapevolmente accettato anziché dato per scontato.

Dalla strategia all’esecuzione

I requisiti di sovranità devono essere ancorati alla strategia IT e di sourcing, derivati nella gestione dell’ecosistema dei provider ed eseguiti attraverso sourcing e vendor management. Senza questa catena, la sovranità degenera in una checklist tardiva di procurement o in un’eccezione architetturale. Non può essere di responsabilità esclusiva del sourcing, perché molti requisiti sono architetturali, operativi e legali; né della sola architettura, perché leva sul provider, applicabilità contrattuale ed economia dell’uscita determinano la fattibilità.

Un modello operativo praticabile definisce i diritti decisionali tra:

• CIO / CTO: direzione tecnologica, principi cloud e guardrail architetturali
• CISO / Technology Risk: requisiti di controllo, evidenze di sicurezza e test di resilienza
• CRO / Operational Risk: allineamento alle operazioni critiche, analisi di scenario e accettazione del rischio residuo
• Sourcing / Procurement: coinvolgimento del mercato, gestione dell’ecosistema dei provider, struttura commerciale e impegni contrattuali
• Vendor Management: governance continuativa, garanzia dell’eccellenza operativa, raccolta delle evidenze, review e remediation
• Legal / Data Protection: giurisdizione, privacy, subfornitori e applicabilità
• Enterprise Architecture, Portfolio and Service Design: category management, posizionamento dei workload, portabilità, integrazione e progettazione dell’uscita
• AI Governance: governance dei modelli, flussi di prompt e dati, evidenze a runtime

Classificare i workload e valutare il rischio

Un programma di sovranità parte dalla classificazione dei workload e del perimetro: lo stesso provider può essere accettabile per un workload e inaccettabile per un altro. La classificazione deve andare oltre le applicazioni e includere domini dati, servizi di integrazione e rete, identità, strumenti di sicurezza, backup e recovery, modelli AI, operazioni di servizi gestiti e toolchain degli sviluppatori, dove spesso si trovano punti di controllo nascosti.

Per ogni workload, la valutazione ruota attorno a quattro domande:

1. Quanto siamo dipendenti?
2. Possiamo accedere ai dati e recuperarli sotto stress?
3. Possiamo uscire o sostituire il provider entro le soglie di tolleranza?
4. Manteniamo la titolarità della proprietà intellettuale generata dai nostri sistemi e modelli AI, invece di cederla al provider?

Lo scoring dovrebbe combinare rischio intrinseco, maturità dei controlli e rischio residuo e guidare azioni concrete di controllo e mitigazione, anziché produrre un punteggio teorico di compliance. Ogni valutazione dovrebbe portare a uno dei quattro esiti:

• Accettare: accettabile con controlli baseline e rischio residuo documentato
• Rafforzare i controlli: accettabile una volta introdotti specifici controlli tecnici, contrattuali o operativi
• Posizionamento sovrano: migrare verso un cloud sovrano, un provider europeo, una piattaforma privata o un pattern con controlli rafforzati
• Remediation strategica o uscita: la dipendenza è inaccettabile; ridurla, costruire capacità di uscita o sostituire il provider

In questo senso, la valutazione della sovranità aggiunge un livello di analisi più sofisticato alla domanda su quale sia il “core IP” di un’istituzione che dovrebbe sempre essere mantenuto internamente.

Dal settore pubblico stanno emergendo vocabolari di valutazione già pronti. Il Cloud Sovereignty Framework (CSF) della Commissione europea definisce otto obiettivi di sovranità con cinque Sovereignty Effectiveness Assurance Levels (SEAL-0–SEAL-4) e un punteggio ponderato di sovranità. È già stato applicato a una gara del valore di circa 180 milioni di euro.

In Germania, il catalogo C3A dell’autorità per la sicurezza IT BSI (Criteria enabling Cloud Computing Autonomy, aprile 2026) integra il consolidato catalogo C5 del BSI (Cloud Computing Compliance Criteria Catalogue), standard de facto di attestazione per la sicurezza cloud nei settori regolamentati tedeschi: mentre C5 attesta quanto sia sicuro un servizio cloud, C3A valuta se possa essere gestito in modo autonomo. Insieme alle sei dimensioni della definizione franco-tedesca, questi cataloghi forniscono alle banche una base riconosciuta esternamente per definire i tier, predisporre questionari di due diligence e attribuire scoring ai provider.

Sovranità dell’AI: una dimensione distinta

L’AI aggiunge un secondo livello di esposizione alla sovranità oltre all’infrastruttura: il controllo deve ora estendersi ai modelli, alle pipeline di training e ai dati che le attraversano.

Oltre a sapere dove risiedono i dati, le banche devono monitorare dove vengono elaborati e archiviati prompt, embedding, dati di fine-tuning, log e output dei modelli; se un provider può utilizzare dati della banca o dei clienti per addestrare o migliorare i propri modelli e se un eventuale opt-out è contrattualmente applicabile; e come le decisioni prese o supportate da modelli esterni possano essere spiegate e documentate alle autorità di vigilanza.

La titolarità è la dimensione che si perde più facilmente. I dati possono appartenere alla banca, ma modelli, pesi e output generati spesso rimangono del provider: una forma di lock-in più sottile rispetto alla dipendenza infrastrutturale. La due diligence sulla sovranità dovrebbe quindi coprire i diritti di proprietà intellettuale sui contenuti generati dall’AI, le licenze dei modelli e del fine-tuning e il rischio che conoscenze proprietarie confluiscano in un modello condiviso.

L’uscita da un modello AI o dal relativo provider richiede la stessa disciplina di un’uscita dal cloud: la banca può passare a un altro foundation model senza perdere capability essenziali, tuning accumulato o evidenze di audit? Anche in questo caso una second source testata è importante – e le opzioni pratiche europee di foundation model restano limitate, con Mistral attualmente il provider con sede nell’UE più rilevante, pur rimanendo molto indietro rispetto ai modelli top-tier nei benchmark e nelle leaderboard – rendendo l’astrazione deliberata, cioè mantenere portabili prompt, dati di retrieval e orchestrazione, la salvaguardia più affidabile.

Considerata in questo modo, la sovranità dell’AI diventa un’estensione della stessa logica basata sul rischio: include i provider AI nella governance di vendor, tecnologia e model risk e allinea le evidenze alle aspettative dell’AI Act dell’UE per i modelli general-purpose, la supervisione umana e l’auditabilità. L’obiettivo è controllo, trasparenza e accountability sul modo in cui l’AI viene costruita, ospitata e governata.

Una roadmap di 24 mesi

La sovranità si realizza al meglio come una trasformazione per fasi, integrata nella governance esistente di vendor, outsourcing, cloud e resilienza, anziché come una valutazione una tantum.

Un programma dovrebbe definire in parallelo due baseline: il rischio di sovranità dei singoli workload, attraverso il tiering, e la maturità della sovranità dell’organizzazione, con una valutazione da 1 a 5 del controllo, della trasparenza e della resilienza su dati, infrastruttura e cloud, AI governance, resilienza operativa, competenze e allineamento dei fornitori. La baseline di maturità mostra dove devono migliorare le capability, non soltanto l’architettura, e consente di sequenziare di conseguenza la roadmap.

Nei primi 90 giorni, le banche dovrebbero dare priorità a tre azioni:

1. Aggiungere l’esposizione alla sovranità al modello di vendor tiering.
2. Classificare rapidamente 20–30 workload candidati tra cloud, SaaS, dati e AI.
3. Selezionare due ambiti pilota, ad esempio uno infrastrutturale e uno SaaS o AI, per testare nella pratica – non solo sulla carta – le evidenze e le capacità di uscita.

ISG aiuta le imprese a posizionare la sovranità digitale come estensione strategica del vendor management, del sourcing e del rischio tecnologico. Supportiamo le organizzazioni nell’identificare le dipendenze di workload, dati, provider, AI ed ecosistemi che richiedono interventi, nell’allineare ruoli dei provider e canali di sourcing e nel trasformare la sovranità in governance continuativa, raccolta di evidenze, issue management e reporting al board. Contattaci per scoprire come possiamo supportare la tua organizzazione.