Il data center non è un argomento legale

Il data center non è un argomento legale

The address on the brochure

There is a sentence that appears in cloud tenders with the confidence of a completed argument: the data will be stored in a European data centre. The sentence may be true. It may also be doing far more work than it can carry.

A data centre has a location. That location matters for physical security, resilience, energy, connectivity, national rules and the practical reach of a local authority. It tells a buyer something useful about where some equipment stands. It does not, by itself, tell the buyer who owns the service, who operates the equipment, where copies are made, who holds the keys, which people can administer it, which companies are allowed to subcontract parts of the work, or which legal system can compel a party to provide access.

The distinction is easy to state and surprisingly easy to lose. A postcode is visible. Control is distributed. The postcode fits neatly in a procurement spreadsheet; control arrives as a chain of contracts, identities, support accounts, management planes, encryption keys, corporate relationships, operational procedures and legal duties. The first is a fact about place. The second is a question about power.

European data protection law has been making this point in increasingly precise language. In the Schrems II judgment of 16 July 2020, the Court of Justice of the European Union examined how personal data could leave the European Economic Area while retaining a level of protection essentially equivalent to the one guaranteed inside it. The Court upheld standard contractual clauses as a possible transfer tool, but made clear that they do not operate in a vacuum. The exporter has to examine the law and practice of the destination in the circumstances of the transfer, and act when the safeguards cannot work in practice.

The judgment did not say that a border is irrelevant. It said that a border is one part of the question. The European Data Protection Board's subsequent recommendations turn that principle into a method: know the transfers, identify the legal tool, assess the law and practice that can affect it, add measures where they can work, complete the required procedure, and keep the assessment under review. A server address appears in that map. It is not the map.

This matters beyond personal data. The Data Act treats cloud and other data-processing services as infrastructure from which customers should be able to switch. It also addresses conditions under which a third-country public authority seeks access to non-personal data held in the Union. Again, the legal answer is built from actors, purposes, safeguards, evidence and remedies. A building is involved. A building is not enough.

The practical lesson for a European institution is therefore blunt. Ask where the data is. Then keep asking questions until the answer includes who can read it, who can change it, who can stop it, who can export it, who can be forced to disclose it, and what evidence will remain when the parties disagree. If the answer ends at the door of the data centre, the useful part of the investigation has only just begun.

Residency is about place

Data residency is a statement about where data is stored or processed under a defined arrangement. The definition needs a scope. Is it the primary copy, the backup, the index, the cache, the telemetry, the disaster-recovery site, or all of them? Does processing include an administrator viewing a record from another country? Does a support session count? What happens when an incident team needs to copy a diagnostic trace? A residency promise that does not say what it covers is an attractive label attached to an unfinished sentence.

I sistemi cloud sono progettati per spostare il lavoro. La replica può migliorare la disponibilità. Un secondo sito può mantenere attivo un servizio quando il primo non è disponibile. Una edge location può ridurre la latenza. Un team di sicurezza può instradare un log verso un sistema di analisi centrale. Sono scelte ingegneristiche ordinarie, non prove di illeciti. Significano però che l'espressione "conservato in Europa" deve essere accompagnata da un oggetto tecnico. Quali dati, in quale stato, per quale periodo, sotto quale operazione?

La valutazione del rischio cloud di ENISA, pubblicata per la prima volta nel 2009, resta utile proprio perché ha rifiutato di trattare la geografia come un controllo completo. Identifica i rischi derivanti dall'archiviazione in più giurisdizioni, dalle informazioni insufficienti sulle giurisdizioni, dalla perdita di governance, dal subappalto e dai cambiamenti nel controllo del fornitore. Il documento è abbastanza vecchio da avere un debole per gli acronimi che i team moderni potrebbero non condividere, eppure il problema organizzativo non è sparito. Se un cliente non può vedere dove vengono trattati i dati o chi è responsabile del passaggio successivo, non può prendere una decisione di rischio affidabile.

La residenza può essere un requisito valido. Un archivio pubblico può avere bisogno che i documenti rimangano entro un'area giuridica definita. Un servizio sanitario può avere bisogno di un accordo di trattamento che limiti i luoghi in cui i dati sensibili possono viaggiare. Un consorzio di ricerca può avere obblighi legati a un finanziatore o a un accordo di condivisione dei dati. Questi requisiti dovrebbero essere scritti come condizioni operative, con un metodo per verificarli, piuttosto che come un singolo nome di paese che tutti sono invitati a interpretare con generosità.

C'è anche una differenza tra una restrizione e una garanzia. Richiedere a un fornitore di mantenere un archivio primario nell'Unione Europea limita una classe di spostamenti. Non garantisce che nessuna persona al di fuori dell'Unione possa accedere a un documento, che nessun metadato esca, o che nessun obbligo giuridico straniero possa raggiungere un fornitore. Una restrizione può essere utile senza essere una garanzia. Confondere le due cose crea una storia di conformità che supera un giro nella sala server e fallisce a un esame più attento del piano di gestione.

La domanda utile sulla residenza non è semplicemente "dove si trova?". È "quali posizioni sono possibili per ogni stato di questi dati, e chi può causare quel cambiamento di stato?". Un fornitore dovrebbe essere in grado di spiegare la risposta in termini che un ingegnere possa implementare e un acquirente possa verificare. Se la spiegazione dipende da un'eccezione non documentata, da un'abitudine del supporto, o da una promessa che i subappaltatori del fornitore si comporteranno probabilmente bene, l'affermazione di residenza non è ancora operativa.

Cinque domande nascoste nella parola dove

Quando le persone chiedono dove si trovano i loro dati, spesso intendono diverse cose contemporaneamente. Separare le domande rende una conversazione di procurement meno teatrale e più utile.

1. Dove sono i bit? Questa è la domanda sullo storage fisico e logico. Include i dati primari, le repliche, i backup, le cache, gli indici e i log pertinenti. Una risposta soddisfacente indica l'ambito e le condizioni in cui la risposta cambia.

2. Dove avviene l'elaborazione? Un record può essere archiviato in una giurisdizione e trasformato, cercato, classificato, cifrato o decifrato altrove. L'elaborazione può essere un job pianificato, un'azione di supporto, una pipeline di monitoraggio o una copia temporanea creata durante il ripristino.

3. Chi può accedervi? Questa è la domanda su identità e operatività. Include personale, amministratori, appaltatori, account di servizio, addetti alla risposta agli incidenti e sistemi automatizzati. Una persona non deve vivere accanto a un server per avere accesso effettivo ad esso.

4. Chi può imporre quell'accesso? Questa è la domanda su giurisdizione e autorità legale. Segue le organizzazioni e le persone rilevanti, i ruoli che ricoprono, i contratti che firmano e gli obblighi legali che possono vincolarli. Non si risponde con un solo segnaposto sulla mappa.

5. Cosa può fare il cliente quando la risposta cambia? Questa è la domanda su controllo e uscita. Può il cliente limitare l'accesso, ruotare le chiavi, ottenere una registrazione attendibile, ripristinare il servizio, spostare i dati e terminare il rapporto senza perdere ciò che stava cercando di proteggere?

Queste domande si sovrappongono, ma non sono intercambiabili. Un fornitore può rispondere in modo convincente alla prima e male alla terza. Un contratto può rispondere alla quinta sulla carta mentre il team tecnico non ha mai eseguito l'uscita. Una filiale locale può rispondere alla domanda sull'identità aziendale mentre il servizio dipende dall'infrastruttura o dall'organizzazione di supporto della società madre. La risposta corretta non è scegliere la risposta più rassicurante. È mantenere intatto l'insieme.

Questo è anche il motivo per cui le valutazioni di sovranità possono diventare confuse. Alla parola viene chiesto di coprire la residenza fisica, l'indipendenza legale, la competenza operativa, la proprietà economica, l'autonomia strategica e la capacità di uscire. Sono ambizioni correlate. Non sono una proprietà unica. Un'istituzione precisa indica quale proprietà le serve e quali prove dimostrerebbero che esiste.

La giurisdizione segue l'autorità

La giurisdizione non è una nuvola mistica che circonda un paese. È un modo per descrivere quali autorità legali possono regolamentare, ordinare, indagare, rivedere o sanzionare la condotta degli attori rilevanti. In un servizio distribuito, gli attori contano tanto quanto i luoghi. Una società può essere costituita in uno Stato membro, gestire strutture in un secondo, utilizzare un team di supporto in un terzo e dipendere da una società madre o da un subappaltatore soggetto a obblighi altrove. Un cliente che cerca di comprendere la portata legale deve seguire la catena di autorità, non fermarsi all'edificio più vicino.

Questo non significa che ogni collegamento estero vanifichi il controllo europeo. I servizi europei sono interconnessi per progettazione. Commercio transfrontaliero, ricerca, supporto, finanziamenti e infrastrutture sono normali. La questione è se l'istituzione sappia quale collegamento detiene quale potere. Un operatore europeo può rifiutare una richiesta ordinaria ma non avere l'autorità di resistere a un'istruzione vincolante di un'altra organizzazione. Un subappaltatore può detenere una credenziale che il principale non ha incluso nel proprio inventario degli accessi. Un processo di supporto può consentire l'accesso remoto anche quando il contratto di storage promette una regione locale.

L'analisi giuridica dipende anche dal tipo di dati e dal tipo di richiesta. I dati personali portano in primo piano le norme sul trasferimento del GDPR e il quadro dei diritti fondamentali. I dati non personali non sono un vuoto giuridico. Il Data Act contiene garanzie per alcune richieste provenienti da autorità pubbliche di paesi terzi relative a dati non personali detenuti nell'Unione. Una richiesta deve essere valutata alla luce delle condizioni del regolamento, inclusa la natura della richiesta e le protezioni disponibili nell'ordinamento giuridico del paese terzo. I due regimi sono diversi, e questa differenza è proprio il motivo per cui un acquirente non dovrebbe comprimerli nella parola residenza.

La sentenza della CGUE nella causa C-311/18 offre un utile modello giuridico europeo. La Corte non si è chiesta se un contratto apparisse abbastanza formale. Si è chiesta se la protezione garantita dal diritto europeo sarebbe rimasta sostanzialmente equivalente nelle circostanze del trasferimento, tenendo conto del diritto e della prassi che potevano incidere sui dati. Le clausole contrattuali standard possono vincolare le parti che le firmano. Non vincolano un'autorità pubblica che non è parte del contratto. Quando il contesto giuridico mina le garanzie promesse, l'esportatore deve intervenire.

Questa logica va oltre la controversia specifica. Un contratto è uno strumento di allocazione privata. La giurisdizione è il campo in cui l'autorità pubblica può agire. Il contratto può dire a un fornitore ciò che ha promesso al cliente. Non può, da solo, rimuovere un potere pubblico che vincola il fornitore o le sue persone. Una buona governance prende sul serio entrambe le affermazioni. Usa i contratti per stabilire obblighi e misure tecniche per rendere osservabili tali obblighi, riconoscendo che la portata giuridica può comunque modificare le opzioni disponibili.

È allettante trasformare tutto questo in una caccia a un unico paese pericoloso. È meno utile che mappare le autorità effettive. Quale entità è il titolare o il responsabile del trattamento? Quale entità impiega l'amministratore? Quale entità detiene le chiavi di cifratura? Quale entità può creare una replica? Quale entità riceve una richiesta di assistenza? Quale autorità potrebbe emanare un ordine? Quale rimedio avrebbe il cliente, e in quale foro? La mappa può essere rassicurante. Può anche non esserlo. In entrambi i casi, il risultato vale più di un'etichetta sul paese.

La proprietà è un titolo, non una chiave

La proprietà ha una reale forza giuridica ed economica. Può determinare chi può vendere un bene, nominare gli amministratori, concedere in licenza la proprietà intellettuale, ricevere ricavi o prendere determinate decisioni. In un ente pubblico può essere legata alla responsabilità statutaria per i documenti o le infrastrutture. In un gruppo societario può spiegare chi può votare, fondersi, finanziare o sostituire un fornitore. La proprietà fa parte di una valutazione di sovranità.

La proprietà non garantisce automaticamente il controllo operativo. Un cliente può possedere i dati mentre un fornitore gestisce il database, amministra il sistema di backup e controlla l'account del servizio. Un'istituzione pubblica può possedere un edificio mentre un appaltatore detiene le credenziali di manutenzione e l'unica via testata per ripristinare le apparecchiature. Un'azienda può possedere il codice sorgente mentre un terzo controlla la chiave di firma, il sistema di build, il registro dei pacchetti e l'identità di distribuzione. Il titolo è reale. Anche la dipendenza lo è.

La distinzione diventa visibile nei verbi. La proprietà è un sostantivo in un contratto. Il controllo è la capacità di ispezionare, operare, modificare, fermare, recuperare, esportare, eliminare e dimostrare. Un processo di approvvigionamento che registra solo sostantivi può lasciare i verbi importanti non assegnati. Può avere un proprietario nominato per la piattaforma e non avere comunque una persona nominata che possa ruotare una chiave, rimuovere un account privilegiato o ripristinare da un backup senza chiedere a un'organizzazione che non è nella stanza.

Non c'è alcun merito nel pretendere il possesso massimo. Un ospedale, un'università o un comune possono non avere il personale e le capacità di sicurezza per gestire ogni livello in modo sicuro. Delegare un compito può essere responsabile quando i confini sono espliciti e il cliente mantiene la capacità di supervisionare, testare e recuperare. Il punto non è mettere ogni server in un seminterrato pubblico. Il punto è decidere quali poteri sono essenziali per la missione e tenere quei poteri abbastanza vicini da poterli governare.

Quella decisione richiede prove. "Il cliente possiede i dati" dovrebbe portare a domande sul formato di esportazione, la custodia delle chiavi, la conservazione, la cancellazione, i registri di accesso e le autorizzazioni di supporto. "Il fornitore è europeo" dovrebbe portare a domande sul controllo societario, i subappaltatori, l'infrastruttura, l'esposizione legale e la continuità. "I dati sono nell'Unione" dovrebbe portare a domande sull'amministrazione remota, le repliche, le sedi di elaborazione e le richieste legali. Una buona risposta può essere complicata. La complicazione non è un difetto quando il sistema è complicato.

Il controllo operativo è il diritto di agire

Il controllo operativo si comprende più facilmente attraverso un'azione piuttosto che un aggettivo. Si consideri un cliente che deve revocare un amministratore. Chi può eseguire la revoca? Quale sistema di identità la autorizza? Il fornitore è tenuto a eseguire la modifica, oppure il cliente può farlo direttamente? L'azione copre gli account di supporto, gli account di emergenza e le credenziali dormienti? Un registro dimostra quando l'autorizzazione è scomparsa? Se un'azione dipende da un helpdesk, l'helpdesk fa parte del piano di controllo.

Lo stesso test si applica alle chiavi. La crittografia può ridurre l'esposizione, ma la sua governance dipende da chi crea, conserva, ruota, recupera e può utilizzare le chiavi. Un record archiviato localmente può rimanere illeggibile per una parte che non può ottenere la chiave. Può anche diventare inaccessibile al cliente quando l'unico percorso di recupero passa da un fornitore. La custodia delle chiavi non è quindi né uno slogan per la sovranità né una gomma magica per la giurisdizione. È un controllo concreto che deve essere assegnato e provato.

I registri meritano lo stesso trattamento. Una dashboard può mostrare l'attività. Le prove richiedono un record che il cliente possa conservare, interpretare e contestare. Chi scrive il registro? Un amministratore può modificarlo? La fonte dell'ora è affidabile? Copre l'accesso del supporto e l'elaborazione automatizzata? Il cliente può ottenere un'esportazione utilizzabile senza il permesso del fornitore? Cosa succede quando l'account viene chiuso? Un registro che scompare con il servizio è utile per le operazioni e debole per la responsabilità.

Il recupero è il test di controllo operativo più difficile perché rende visibile ogni dipendenza. Un fornitore può promettere il backup, ma il ripristino può richiedere una regione specifica, una licenza non disponibile, un tecnico che non lavora più lì o un segreto archiviato in un sistema separato. Il cliente può possedere il file di backup e non avere comunque la capacità di trasformarlo in un servizio funzionante. Il recupero dovrebbe essere testato come un'azione completa, con il risultato registrato e le lacune assegnate a persone che possano colmarle.

Anche fermare un servizio è controllo. Un'istituzione può dover mettere in pausa un'integrazione, isolare un set di dati, sospendere l'elaborazione automatizzata o impedire la creazione di una nuova replica. Se solo un fornitore può eseguire l'arresto, l'identità del fornitore, gli obblighi legali, i tempi di risposta e il processo di supporto diventano parte del rischio dell'istituzione. Può essere un accordo accettabile. Non è un accordo invisibile.

Lo scopo di questi test non è diffidare di ogni fornitore. È sostituire la fiducia con una relazione che possa essere ispezionata. Un fornitore con una risposta chiara può spiegare quali azioni esegue lui, quali esegue il cliente e quali richiedono cooperazione. Un fornitore che si affida a una sola frase rassicurante non ha ancora risposto alla domanda operativa.

I subappaltatori trasformano una risposta in una catena

Un servizio è raramente una singola organizzazione che fa una cosa in un unico luogo. I provider cloud utilizzano infrastrutture specializzate, partner di supporto, servizi di monitoraggio, operazioni di sicurezza, manutenzione hardware, carrier di rete e altri fornitori. Alcuni sono visibili nel contratto. Altri compaiono in un elenco di subresponsabili, in una descrizione del servizio, in un avviso di incidente o in un flusso di supporto. La catena è ordinaria. Anche l'obbligo di comprenderla è ordinario.

La valutazione del rischio di ENISA evidenzia un fallimento noto: un provider cloud può subappaltare servizi a terzi che non offrono le stesse garanzie, mentre un cambio di controllo può alterare le condizioni del provider. Il rapporto non è una specifica architetturale moderna, e non deve esserlo. Il suo monito duraturo è di natura organizzativa. Un cliente non può affermare di comprendere un servizio se ha valutato solo la prima società indicata in fattura.

Le raccomandazioni dell'EDPB sono più specifiche per i dati personali. Il primo passo è conoscere i trasferimenti, inclusi quelli successivi verso responsabili e subresponsabili. L'accesso remoto da un paese terzo può di per sé costituire un trasferimento, anche quando il record rimane in un data center dello SEE. Un accordo di supporto fa quindi parte della mappa dei trasferimenti di dati, non una nota a piè di pagina da gestire dopo la distribuzione.

La visibilità dei subappaltatori non equivale al controllo su di essi. Un elenco dice al cliente chi è coinvolto. Il controllo chiede cosa può fare ciascuna parte, quali dati può vedere, quale strumento giuridico copre l'attività, come viene notificato un cambiamento e quale rimedio esiste quando la parte cessa di soddisfare le condizioni. La catena dovrebbe avere confini ed evidenze a ogni passaggio di consegne.

C'è una ragione pratica per resistere a catene vaghe. Quando si verifica un incidente, la responsabilità spesso viaggia nella direzione opposta rispetto ai dati. Il cliente chiede al provider. Il provider chiede al team di piattaforma. Il team di piattaforma chiede a un fornitore specializzato. Il fornitore specializzato chiede a un amministratore di un'altra organizzazione. Ogni passaggio può aggiungere ritardi, incertezza e un'opportunità per il record originale di perdere contesto. Una mappa dei controlli dovrebbe mostrare il percorso prima dell'incidente, mentre le persone coinvolte hanno ancora il tempo di essere precise.

Dati personali: la protezione viaggia con il record

Il GDPR non rende sicuri i dati personali semplicemente mettendoli dietro una porta europea. Le sue norme sul trasferimento sono concepite per preservare un livello elevato di protezione quando i dati si spostano verso un paese terzo. L'EDPB descrive il principio in modo chiaro: un livello di protezione sostanzialmente equivalente dovrebbe accompagnare i dati ovunque vadano, durante e dopo il trasferimento.

Ciò non significa che ogni trasferimento sia vietato. Il GDPR prevede diversi strumenti e condizioni di trasferimento, incluse le decisioni di adeguatezza e le garanzie di cui all'articolo 46. La questione giuridica è se lo strumento scelto funzioni nelle circostanze concrete. Le raccomandazioni dell'EDPB invitano gli esportatori a valutare il diritto e la prassi pertinenti al trasferimento specifico, a considerare se l'importatore o i dati possano rientrare in norme problematiche e a documentare il ragionamento. Se nessuna misura supplementare può ripristinare il livello di protezione richiesto, il trasferimento dovrebbe essere evitato, sospeso o cessato.

Tre dettagli sono particolarmente facili da trascurare in una discussione sulla residenza dei dati. In primo luogo, il trasferimento successivo è rilevante. Un fornitore può conservare il registro principale nel SEE e inviarne una copia a un servizio di assistenza o di analisi altrove. In secondo luogo, l'accesso è rilevante. Un amministratore in un paese terzo può essere in grado di leggere un registro senza che il registro venga mai fisicamente spostato sulla scrivania di quella persona. In terzo luogo, la responsabilità è rilevante. L'esportatore deve essere in grado di dimostrare la valutazione e di rivederla quando cambiano il servizio, il diritto, le persone o le circostanze.

Il quadro normativo chiede quindi al cliente di comprendere sia il percorso tecnico sia il contesto giuridico. Un diagramma di regioni e frecce è utile. Non può sostituire la valutazione del trasferimento. Né può farlo una promessa contrattuale di conformità da parte del fornitore, se il cliente non ha verificato cosa le garanzie pertinenti possano ottenere rispetto alle leggi e alle prassi che possono applicarsi al fornitore.

Il diritto europeo in materia di protezione dei dati nutre una sana diffidenza verso le parole magiche. "Hosting UE" può descrivere un dato di fatto utile. "Conforme" può descrivere una conclusione che richiede motivazioni. "Sovrano" può descrivere un obiettivo politico. Nessuna di queste espressioni dovrebbe sostituire le prove che i dati sono protetti, che l'accesso è disciplinato e che la decisione può essere difesa.

Dati non personali: un regime diverso, la stessa disciplina

Il Data Act riguarda un insieme più ampio di relazioni relative ai dati e include norme per i servizi di trattamento dei dati, come i servizi cloud e edge. Non sostituisce il GDPR e non trasforma ogni decisione sul cloud in una valutazione del trasferimento ai fini della protezione dei dati. Offre però un secondo richiamo europeo al fatto che ubicazione, accesso, portabilità e autorità debbano essere considerati insieme.

Per i dati non personali conservati nell'Unione, la spiegazione della Commissione sul Data Act descrive garanzie per determinate richieste o decisioni di un'autorità pubblica di un paese terzo. Laddove nessun accordo internazionale applicabile disciplini l'accesso, il regolamento stabilisce condizioni intese a proteggere gli interessi europei, inclusa l'attenzione al sistema giuridico del paese terzo e alla proporzionalità della richiesta. Ci si aspetta che i fornitori adottino misure ragionevoli, come crittografia, audit o accordi di certificazione, per prevenire accessi non autorizzati e informare i clienti ove possibile.

La formulazione è importante. Il Data Act non sostiene che l'Unione possa far sparire i sistemi giuridici stranieri. Crea un quadro per valutare e limitare determinate vie di accesso. Un fornitore deve comunque sapere quali sistemi gestisce, quali dati conserva, chi può rispondere a una richiesta e quali prove può fornire al cliente. Un cliente deve comunque capire quali parti dei dati sono personali, quali non lo sono e quali altri regimi giuridici si applicano.

The Act also approaches control through switching. Customers should be able to move between data-processing services, use services in parallel and port exportable data and digital assets. Providers must give information about export formats, interfaces, known limitations and the time needed for the process. The rules on functional equivalence recognise a practical truth: a file that can be downloaded is not necessarily a service that can be recovered.

Switching is often described as a competition measure, and it is one. It is also a sovereignty measure in the operational sense. An institution that can leave has more room to refuse a change it cannot accept. An institution that cannot leave may own a contract and still be governed by the provider's defaults. A legal right to switch is an important start. A rehearsed migration that preserves the data, the configuration and the evidence is the part that makes the right usable.

Contracts, keys and the limits of reassurance

Contracts remain essential. They allocate duties, set notification rules, identify subprocessors, define permitted processing, describe deletion and retention, create audit rights and establish assistance during a transition. The Data Act's cloud-switching provisions reinforce the need for clear contractual terms, exportable data and information about the mechanics of an exit. ENISA's older guidance likewise recommends paying attention to data transfers, change of control, law-enforcement access, breach notifications and liability when evaluating cloud contracts.

A contract is not a runtime control. A clause saying that the customer may export is weaker than an export run against a representative dataset and restored in a second environment. A clause saying that the provider will delete is weaker than an auditable deletion process that covers replicas, caches, backups and derived records. A clause giving an audit right is weaker than logs and evidence the customer can actually obtain. Paper matters. Paper that never meets a working system is politely framed optimism.

Keys provide a similar lesson. Customer-controlled encryption can reduce what a provider or an unauthorised party can read. It does not answer who can compel a person who holds a recovery key, who controls the hardware security module, who can change the key policy, or what happens when the customer loses its own credential. The right design may use split authority, independent custody, carefully scoped access and tested recovery. The wrong design can put the decisive key in a different jurisdiction and call the arrangement local because the database is local.

Legal and technical measures should be designed together. If a contract requires the customer to approve support access, the service should have an approval flow that leaves a record. If the customer needs to prevent onward transfers, the provider should expose the route and enforce the boundary. If a public authority request must be evaluated, the incident process should preserve the request, the legal analysis, the decision, the notification and the response. A legal promise becomes credible when a system can show how it is carried out.

The same principle applies to ownership changes. A supplier acquisition, a new parent company, a change in subcontractor or a change in the service's operating region can alter the control map without changing the customer-facing brand. Contracts should require notice and remedies. Technical inventories should be updated. A change ledger should show which powers moved. Governance that exists only at initial signature has a short half-life.

A buyer's control map

A public or private buyer does not need a magical questionnaire. It needs a map that connects claims to evidence. The following questions are a useful starting point because they ask for actions, actors and records rather than a preferred adjective.

La tabella è volutamente prosaica. È pensata per sopravvivere al contatto con un team acquisti. Offre inoltre all'acquirente un modo per confrontare i fornitori senza fingere che un certificato, una bandiera nazionale o un tour del data center risolvano tutto. Le prove possono essere riservate. Il requisito di avere prove non dovrebbe esserlo.

Chiedete una dimostrazione dell'azione critica, non solo una descrizione. Mostrate come viene rimosso un account privilegiato. Mostrate come viene approvata una sessione di supporto. Mostrate cosa riceve un cliente quando richiede un'esportazione. Mostrate come viene localizzata una replica. Mostrate cosa fa una richiesta legale al flusso di lavoro degli incidenti. Mostrate come l'organizzazione continua quando l'account del fornitore viene sospeso. Il punto non è inscenare un guasto drammatico. È verificare se il controllo esiste al di là della presentazione.

Poi chiedete chi possiede il risultato. Un test senza proprietario è una messa in scena. Una lacuna senza una data è una caratteristica permanente. Un controllo senza registrazione è una convinzione. La mappa dovrebbe quindi indicare la persona o l'organo che accetta il rischio, il fornitore che deve eseguire l'azione e il canale per contestare il risultato. La governance non è un elenco di domande. È un insieme di decisioni con un luogo dove andare a finire.

Un esperimento mentale su un archivio europeo

Quanto segue è un'ipotesi etichettata, non un resoconto di un cliente o incidente reale. Immaginate un archivio comunale che seleziona un servizio hosted per i registri urbanistici digitalizzati. La gara richiede l'archiviazione primaria nell'Unione Europea e chiede crittografia, backup e un help desk. Tre fornitori soddisfano le parole. Uno è incorporato localmente ma dipende da un subappaltatore di supporto fuori dall'Unione. Uno mantiene archiviazione e supporto nell'Unione ma utilizza la piattaforma di identità della società madre. Uno ha un'operazione locale più piccola, una custodia chiara delle chiavi e un'esportazione testata, ma necessita di un livello di servizio attentamente definito perché non può offrire ogni funzionalità opzionale.

Il primo fornitore può comunque essere accettabile. Il secondo può comunque essere accettabile. Il terzo può comunque essere inadatto per un particolare requisito di disponibilità. Il punto dell'esperimento mentale è che la sola residenza non può scegliere tra loro. L'archivio deve chiedere quale accesso di supporto è possibile, chi può fare una copia, quali entità legali possono ricevere un ordine, come sono governate le chiavi, cosa mostrano i log e se i registri possono essere recuperati altrove.

Supponiamo che l'archivio decida che l'archiviazione locale sia la sua condizione più importante. Può scrivere questo requisito nel contratto. Dovrebbe anche definire gli oggetti coperti dalla condizione, richiedere la notifica di un cambiamento e chiedere come verrebbe rilevata una violazione. Supponiamo che decida che l'assistenza remota sia consentita solo per un incidente documentato. Il servizio necessita di un percorso di approvazione, credenziali con scadenza temporale e una registrazione che possa essere esaminata. Supponiamo che decida che l'archivio debba poter uscire. L'uscita dovrebbe essere testata prima che il servizio diventi l'unico posto in cui qualcuno sappia come leggere i documenti.

Nulla in questa ipotesi richiede che l'archivio gestisca un data center. Richiede che l'archivio comprenda i poteri che delega. Questa è la differenza tra esternalizzazione responsabile e un acquisto che sposta il rischio in una stanza in cui l'acquirente non può entrare.

Ciò che l'Europa può onestamente intendere per sovrano

La sovranità europea nell'infrastruttura digitale dovrebbe essere descritta in termini che possano resistere a una domanda scomoda. Può significare che un'istituzione europea mantiene l'autorità sulle decisioni critiche. Può significare che le dipendenze chiave sono visibili, vincolate e recuperabili. Può significare che i diritti legali sono accompagnati da capacità tecniche. Può significare che un acquirente pubblico può cambiare, contestare, ispezionare e continuare a operare quando un fornitore o una legge modifica il percorso disponibile.

Non dovrebbe significare che un servizio sia automaticamente sicuro perché il suo indirizzo di marketing è europeo. Né dovrebbe significare che ogni connessione estera sia vietata. L'Europa dipende da sistemi transfrontalieri, e una regola che finge il contrario verrà ignorata o aggirata silenziosamente. La posizione matura è più esigente: consentire le dipendenze che servono la missione, documentarle, ridurre quelle che comportano un potere inaccettabile e mantenere un'uscita per quelle che non possono essere rese affidabili.

Questa posizione offre anche ai fornitori europei una prova più equa. Un fornitore locale non dovrebbe dover eseguire una cerimonia della bandiera per essere preso sul serio. Dovrebbe poter mostrare cosa gestisce, cosa delega, chi può accedervi, quale legge può applicarsi, come vengono protetti i dati e come un cliente può uscire. Un fornitore globale dovrebbe affrontare le stesse domande. Lo standard è l'evidenza del controllo, non il teatro dell'origine.

La parola sovranità diventa utile quando cambia il comportamento d'acquisto. Un ministero può usare gli appalti per premiare un percorso di uscita testato. Un ospedale può richiedere accordi chiave che corrispondano ai suoi doveri clinici. Un'università può rendere visibile la provenienza dei dati di ricerca. Un regolatore può chiedere lo stato di un sistema al momento di una decisione. Un fornitore può progettare il suo servizio affinché l'autorità del cliente non sia un paragrafo decorativo. Queste sono azioni istituzionali, non una gara di slogan.

Una breve nota da parte nostra

In Dweve, la nostra analisi pubblica The Sovereignty Illusion: where control really sits, pubblicata il 29 giugno 2026, utilizza una disciplina simile. Separa proprietà, tecnologia, capitale, infrastruttura ed esposizione legale invece di permettere a un'etichetta europea di rappresentare tutte e cinque. Questo articolo è più limitato. Segue la rivendicazione del data center negli strati operativi e legali che un acquirente deve governare.

È anche così che preferiamo descrivere il nostro lavoro. Un sistema dovrebbe rendere leggibili i suoi confini: cosa è locale, cosa è delegato, cosa è registrato, cosa può essere contestato e cosa può essere modificato. L'affermazione utile è quella che un lettore può verificare. Il resto è decorazione, e l'Europa ha già abbondanza di infrastruttura decorativa.

L'argomento legale inizia dopo l'indirizzo

La posizione di un data center merita di essere conosciuta. Può influenzare l'accesso fisico, la resilienza, la connettività, le regole locali applicabili e la progettazione di un servizio. Può essere la giusta prima domanda. È una risposta finale povera.

La risposta finale deve collegare il luogo all'autorità. Deve nominare l'operatore, le identità, le chiavi, i subappaltatori, gli strumenti giuridici, le possibili richieste, le prove e l'uscita. Per i dati personali, il livello di protezione europeo deve rimanere sostanzialmente equivalente quando i dati vengono trasferiti, e gli esportatori devono valutare le circostanze piuttosto che ripetere un'affermazione sulla localizzazione. Per i dati non personali, il Data Act aggiunge norme sull'accesso straniero e sul cambio di fornitore cloud, che rendono nuovamente concreti il controllo e la portabilità.

Non esiste un numero europeo unico che possa trasformare un servizio complesso in uno sovrano. Esiste una sequenza di domande, test e registrazioni. La sequenza è più lenta che stampare "hosting UE" su una brochure. È anche la parte che rimane utile dopo che la brochure è diventata obsoleta.

Quando un acquirente chiede dove si trovano i dati, rispondi con precisione sulla localizzazione. Poi chiedi chi può leggerli, chi può agire su di essi, chi può essere obbligato, chi può dimostrare cosa è successo e chi può andarsene. Un data centre europeo può far parte di un accordo affidabile. Non può essere da solo l'argomento giuridico.

Fonti

• Raccomandazioni 01/2020 sulle misure che integrano gli strumenti di trasferimento per garantire la conformità al livello di protezione dei dati personali dell'UE, Comitato europeo per la protezione dei dati, versione finale del 18 giugno 2021. La pagina collegata include il PDF ufficiale.
• Causa C-311/18, Data Protection Commissioner contro Facebook Ireland e Schrems II, Corte di giustizia dell'Unione europea, sentenza del 16 luglio 2020, EUR-Lex.
• Regolamento (UE) 2023/2854, il Data Act, Parlamento europeo e Consiglio, 13 dicembre 2023, EUR-Lex.
• Data Act spiegato, Commissione europea, pubblicato nel 2025 e consultato il 5 agosto 2026.
• Valutazione del rischio del cloud computing e il PDF del rapporto ufficiale, Agenzia dell'Unione europea per la cibersicurezza (ENISA), 2009.
• The Sovereignty Illusion: where control really sits, Dweve, 29 giugno 2026.