Un’azienda può dichiararsi indipendente quanto vuole, ma basta che un identity provider smetta di rispondere, che un’API cambi condizioni di accesso o che un servizio cloud diventi improvvisamente indisponibile per scoprire quanto quella dichiarazione fosse distante dalla realtà operativa. La sovranità digitale, prima ancora di essere una questione di tecnologia europea, cloud nazionale o controllo dei dati, è infatti una questione molto più concreta: sapere esattamente da che cosa dipende il funzionamento dell’organizzazione.

È un passaggio meno spettacolare delle grandi strategie di trasformazione digitale, ma probabilmente più importante. Perché negli ultimi anni le imprese hanno costruito ecosistemi tecnologici estremamente efficienti proprio moltiplicando le interdipendenze: SaaS specializzati, piattaforme cloud, API esterne, sistemi di autenticazione, librerie software, modelli di intelligenza artificiale, marketplace, partner tecnologici e competenze distribuite lungo catene di fornitura sempre più articolate.

Il problema non è che queste dipendenze esistano. Il problema è non sapere quali siano realmente critiche.

Dalla sovranità dichiarata alla sovranità misurabile

Nel dibattito sulla sovranità digitale si tende spesso a partire dalla soluzione: cambiare cloud provider, localizzare i dati, scegliere tecnologie europee, sviluppare internamente alcune componenti o diversificare i fornitori. Sono decisioni che possono essere corrette, ma diventano premature se vengono prese prima di conoscere l’architettura delle dipendenze dell’organizzazione.

La domanda iniziale dovrebbe essere diversa: se domani una determinata tecnologia, un servizio, un partner o una competenza non fossero più disponibili, che cosa smetterebbe di funzionare?

È qui che il concetto di sovranità smette di essere una dichiarazione di principio e diventa un problema di governance.

Un’organizzazione può avere i propri dati ospitati in Europa e continuare a dipendere in modo critico da un sistema di autenticazione esterno. Può utilizzare software open source e scoprire che alcune componenti fondamentali sono mantenute da pochissimi sviluppatori. Può distribuire i workload su più cloud e utilizzare, contemporaneamente, servizi proprietari talmente integrati nei processi da rendere una migrazione estremamente costosa.

La localizzazione, in altre parole, non coincide automaticamente con il controllo. E il controllo non coincide necessariamente con la proprietà.

Ciò che conta è comprendere quanto una dipendenza limiti la capacità dell’organizzazione di scegliere, modificare, sostituire o continuare a operare.

L’inventario che manca nei sistemi complessi

Molte aziende possiedono già inventari tecnologici. Sanno quali server utilizzano, quali licenze acquistano, quali applicazioni sono installate e quali fornitori hanno contratti attivi. Ma una mappa delle dipendenze strategiche è qualcosa di diverso.

Non fotografa soltanto ciò che l’organizzazione possiede o utilizza: ricostruisce le relazioni tra le componenti e, soprattutto, le conseguenze della loro eventuale indisponibilità.

Un CRM può dipendere da un servizio cloud, ma anche da un identity provider, da alcune API, da un sistema di pagamento, da un database gestito e da competenze specialistiche detenute da un partner esterno. Un’applicazione apparentemente interna può incorporare librerie open source, utilizzare servizi di terze parti e interrogare modelli AI forniti attraverso API.

La dipendenza, quindi, non termina al primo fornitore.

Ed è proprio nelle dipendenze indirette che spesso si nasconde una parte significativa del rischio. L’azienda conosce il proprio vendor, ma non necessariamente l’infrastruttura dalla quale quel vendor dipende; conosce la piattaforma SaaS acquistata, ma non sempre i servizi sottostanti che ne garantiscono l’operatività.

In un ecosistema digitale maturo, la catena tecnologica assomiglia sempre meno a una sequenza lineare e sempre più a una rete.

Identify: vedere prima di decidere

Il primo livello di una strategia di sovranità dovrebbe quindi essere apparentemente semplice: identificare. Infrastrutture, SaaS, API, sistemi di identity management, repository di dati, modelli AI, componenti software, librerie, competenze specialistiche, partner tecnologici e servizi esterni devono entrare nella stessa rappresentazione.

Non per produrre l’ennesimo database destinato a diventare obsoleto dopo qualche mese, ma per rendere visibili le relazioni tra tecnologia e processi aziendali. La domanda non è soltanto “quali strumenti utilizziamo?”, ma “quali capacità aziendali dipendono da questi strumenti?”.

È una differenza sostanziale.

Un servizio dal costo marginale può sostenere un processo estremamente importante; una piccola API può trovarsi nel percorso critico di un servizio che genera milioni di euro; una competenza posseduta da due sole persone può rappresentare una dipendenza più significativa di un contratto cloud multimilionario.

Il valore dell’inventario emerge quando tecnologia, processi e business vengono osservati insieme.

Classify: non tutte le dipendenze sono uguali

Costruita la mappa, occorre evitare il secondo errore tipico: considerare ogni dipendenza come un problema. Un’organizzazione moderna deve dipendere da qualcuno. Pretendere autonomia assoluta significherebbe rinunciare a buona parte dei vantaggi della specializzazione, delle economie di scala e dell’innovazione distribuita.

La questione strategica è quindi classificare le dipendenze.

Alcune sono facilmente sostituibili e hanno un impatto limitato. Altre sono importanti, ma possono essere gestite attraverso ridondanza, contratti adeguati o piani di migrazione. Altre ancora rappresentano veri punti di concentrazione: componenti dalle quali dipendono numerosi processi e per le quali non esiste una sostituzione rapida, economicamente sostenibile o tecnicamente equivalente.

È in quest’ultima categoria che la sovranità assume rilevanza per il board. Perché il rischio non è più soltanto IT. Diventa rischio operativo, finanziario, normativo e, in alcuni casi, strategico.

Assess: misurare il costo della dipendenza

La criticità di una tecnologia non può essere valutata soltanto sulla base della probabilità che smetta di funzionare. Un hyperscaler può avere livelli di affidabilità enormemente superiori a quelli che un’azienda potrebbe garantire internamente e rappresentare comunque una dipendenza strategica.

Occorre quindi cambiare prospettiva.

Quanto tempo servirebbe per sostituire quella componente? Quanto costerebbe migrare? I dati sono realmente esportabili? In quale formato? Le applicazioni possono funzionare altrove? Esistono competenze interne sufficienti? Quanto codice dovrebbe essere riscritto? Quali contratti limitano la portabilità? Quali processi si fermerebbero durante la transizione?

Con l’intelligenza artificiale queste domande diventano ancora più rilevanti. Un’organizzazione che costruisce processi, prodotti e knowledge base intorno a un determinato modello non sta semplicemente acquistando capacità computazionale: sta progressivamente adattando workflow, prompt, sistemi di valutazione, integrazioni e competenze a uno specifico ecosistema.

La dipendenza può crescere senza che nessuno abbia formalmente deciso di aumentarla. Ed è forse questo uno degli aspetti più insidiosi del lock-in contemporaneo: non sempre viene imposto dal fornitore; spesso viene prodotto dall’accumulazione delle nostre stesse scelte.

Decide: scegliere quali dipendenze accettare

Solo dopo avere identificato, classificato e valutato le dipendenze diventa possibile decidere. Ed è qui che una strategia di sovranità digitale dovrebbe dimostrare maturità, evitando l’equazione semplicistica secondo cui essere sovrani significhi necessariamente internalizzare.

Per alcune componenti sarà razionale accettare la dipendenza. Per altre sarà opportuno costruire alternative, introdurre architetture più portabili, distribuire il rischio o negoziare condizioni contrattuali differenti. In alcuni casi sarà necessario mantenere competenze interne anche quando l’operatività viene affidata all’esterno. In altri, il costo di una vera alternativa potrebbe risultare superiore al rischio che dovrebbe mitigare.

La sovranità non consiste quindi nell’eliminazione delle dipendenze, ma nella capacità di scegliere consapevolmente quali dipendenze assumere e quali margini di manovra preservare.

È una distinzione importante anche per il board, perché sposta la discussione dal terreno ideologico a quello economico e strategico.

Dal catalogo tecnologico alla mappa del potere

Una mappa delle dipendenze digitali racconta qualcosa di più dell’architettura IT di un’impresa. Racconta dove risiede il potere di condizionare le sue decisioni future.

Mostra quali fornitori possono essere sostituiti in settimane e quali richiederebbero anni. Rivela quali dati sono realmente mobili e quali soltanto teoricamente esportabili. Evidenzia dove l’organizzazione possiede competenze e dove, invece, ha progressivamente delegato anche la capacità di comprendere ciò che utilizza.

Ed è proprio questo il punto sul quale la sovranità digitale è destinata a evolvere. Nei prossimi anni probabilmente conterà meno stabilire se una tecnologia sia interna o esterna, nazionale o straniera, proprietaria o open source. Conterà sempre di più capire quanto l’organizzazione rimanga libera di cambiare decisione.

La vera misura della sovranità potrebbe essere proprio questa: non l’assenza di dipendenze, impossibile in qualsiasi ecosistema digitale avanzato, ma la possibilità concreta di governarle senza trasformarle in vincoli irreversibili.

Per questo il primo documento di una strategia di sovranità digitale non dovrebbe essere necessariamente un piano di migrazione o una lista di nuovi fornitori. Potrebbe essere qualcosa di molto meno appariscente e molto più utile: una mappa.

Se dovessi disegnare oggi la mappa delle dipendenze digitali della tua azienda, sapresti da dove iniziare?