O centro de dados não é um argumento jurídico.

O centro de dados não é um argumento jurídico.

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.

Os sistemas cloud são concebidos para mover trabalho. A replicação pode melhorar a disponibilidade. Um segundo site pode manter um serviço ativo quando o primeiro está indisponível. Uma localização de edge pode reduzir a latência. Uma equipa de segurança pode encaminhar um registo para um sistema central de análise. Estas são escolhas de engenharia comuns, não indícios de irregularidades. Mas significam que a expressão «armazenado na Europa» precisa de um objeto técnico associado. Que dados, em que estado, durante que período, sob que operação?

A avaliação de riscos cloud da ENISA, publicada pela primeira vez em 2009, continua útil precisamente porque recusou tratar a geografia como um controlo completo. Identifica riscos decorrentes do armazenamento em múltiplas jurisdições, informação insuficiente sobre jurisdições, perda de governação, subcontratação e alterações no controlo do fornecedor. O documento é suficientemente antigo para ter uma predileção por acrónimos que as equipas modernas podem não partilhar, mas o problema organizacional não desapareceu. Se um cliente não consegue ver onde os dados são processados ou quem é responsável pela próxima transferência, não consegue tomar uma decisão de risco fiável.

A residência pode ser um requisito válido. Um arquivo público pode precisar de manter registos dentro de uma área legal definida. Um serviço de saúde pode precisar de um acordo de processamento que limite onde os dados sensíveis podem circular. Um consórcio de investigação pode ter obrigações associadas a um financiador ou a um acordo de partilha de dados. Esses requisitos devem ser escritos como condições operacionais, com um método para os verificar, em vez de um único nome de país que todos são convidados a interpretar generosamente.

Há também uma diferença entre uma restrição e uma garantia. Exigir que um fornecedor mantenha um armazenamento primário na União Europeia restringe uma classe de movimento. Não garante que nenhuma pessoa fora da União possa aceder a um registo, que nenhum metadado saia, ou que nenhuma obrigação legal estrangeira possa alcançar um fornecedor. Uma restrição pode ser útil sem ser uma garantia. Confundir as duas cria uma história de conformidade que passa numa visita à sala de servidores e falha num olhar mais atento ao plano de gestão.

A questão útil sobre residência não é simplesmente «onde está?». É «quais localizações são possíveis para cada estado destes dados, e quem pode fazer essa mudança de estado?» Um fornecedor deve ser capaz de explicar a resposta em termos que um engenheiro possa implementar e um comprador possa verificar. Se a explicação depender de uma exceção não documentada, de um hábito de suporte, ou de uma promessa de que os subcontratados do próprio fornecedor provavelmente se comportarão, a alegação de residência ainda não é operacional.

Cinco perguntas escondidas na palavra onde

Quando as pessoas perguntam onde estão os seus dados, muitas vezes querem dizer várias coisas ao mesmo tempo. Separar as perguntas torna uma conversa de aquisição menos teatral e mais útil.

1. Onde estão os bits? Esta é a questão do armazenamento físico e lógico. Inclui dados primários, réplicas, cópias de segurança, caches, índices e registos relevantes. Uma resposta satisfatória nomeia o âmbito e as condições em que a resposta muda.

2. Onde ocorre o processamento? Um registo pode ser armazenado numa jurisdição e transformado, pesquisado, classificado, encriptado ou desencriptado noutro local. O processamento pode ser uma tarefa agendada, uma ação de suporte, um pipeline de monitorização ou uma cópia temporária feita durante a recuperação.

3. Quem pode aceder-lhe? Esta é a questão da identidade e da operação. Inclui funcionários, administradores, contratantes, contas de serviço, equipas de resposta a incidentes e sistemas automatizados. Uma pessoa não precisa de viver ao lado de um servidor para ter acesso efetivo a ele.

4. Quem pode impor esse acesso? Esta é a questão da jurisdição e da autoridade legal. Segue as organizações e pessoas relevantes, os cargos que ocupam, os contratos que assinam e as obrigações legais que as podem vincular. Não é respondida apenas por um marcador num mapa.

5. O que pode o cliente fazer quando a resposta muda? Esta é a questão do controlo e da saída. Pode o cliente restringir o acesso, rodar chaves, obter um registo fiável, restaurar o serviço, mover os dados e terminar a relação sem perder aquilo que tentava proteger?

Estas perguntas sobrepõem-se, mas não são intercambiáveis. Um fornecedor pode responder bem à primeira e mal à terceira. Um contrato pode responder à quinta no papel enquanto a equipa técnica nunca executou a saída. Uma subsidiária local pode responder à questão da identidade corporativa enquanto o serviço depende da infraestrutura ou da organização de suporte da empresa-mãe. A resposta correta não é escolher a resposta mais reconfortante. É manter o conjunto intacto.

É também por isso que as avaliações de soberania podem tornar-se confusas. Pede-se à palavra que cubra a residência física, a independência legal, a competência operacional, a propriedade económica, a autonomia estratégica e a capacidade de sair. São ambições relacionadas. Não são uma única propriedade. Uma instituição precisa diz qual propriedade necessita e que evidência mostraria que ela existe.

A jurisdição segue a autoridade

A jurisdição não é uma nuvem mística à volta de um país. É uma forma de descrever quais as autoridades legais que podem regular, ordenar, investigar, rever ou remediar a conduta dos atores relevantes. Num serviço distribuído, os atores importam tanto quanto os lugares. Uma empresa pode estar constituída num Estado-Membro, operar instalações num segundo, usar uma equipa de suporte num terceiro e depender de uma empresa-mãe ou subcontratante sujeita a obrigações noutro local. Um cliente que tenta compreender o alcance legal tem de seguir a cadeia de autoridade, não parar no edifício mais próximo.

Isto não significa que todas as ligações estrangeiras derrotem o controlo europeu. Os serviços europeus estão interligados por conceção. O comércio transfronteiriço, a investigação, o suporte, o financiamento e a infraestrutura são normais. A questão é saber se a instituição conhece qual ligação transporta qual poder. Um operador europeu pode ser capaz de recusar um pedido comum, mas não ter autoridade para resistir a uma instrução vinculativa de outra organização. Um subcontratante pode deter uma credencial que o principal não incluiu no seu próprio inventário de acessos. Um processo de suporte pode permitir acesso remoto mesmo quando o contrato de armazenamento promete uma região local.

A análise jurídica depende também do tipo de dados e do tipo de pedido. Os dados pessoais trazem para o âmbito de análise as regras de transferência do RGPD e o quadro dos direitos fundamentais. Os dados não pessoais não existem num vazio jurídico. O Regulamento dos Dados contém salvaguardas para determinados pedidos apresentados por autoridades públicas de países terceiros relativamente a dados não pessoais detidos na União. Um pedido deve ser analisado à luz das condições do regulamento, incluindo a natureza do pedido e as proteções disponíveis no sistema jurídico do país terceiro. Os dois regimes são diferentes, e é precisamente essa diferença que explica por que motivo um comprador não deve comprimi-los na palavra residência.

O acórdão do TJUE no processo C-311/18 fornece um padrão jurídico europeu útil. O Tribunal não perguntou se um contrato parecia suficientemente formal. Perguntou se a proteção garantida pelo direito europeu permaneceria essencialmente equivalente nas circunstâncias da transferência, tendo em conta o direito e a prática que pudessem afetar os dados. As cláusulas contratuais tipo podem vincular as partes que as assinam. Não vinculam uma autoridade pública que não seja parte no contrato. Quando o ambiente jurídico compromete as salvaguardas prometidas, o exportador tem de reagir.

Essa lógica é mais ampla do que o litígio em causa. Um contrato é um instrumento de afetação privada. A jurisdição é o campo em que a autoridade pública pode atuar. O contrato pode dizer a um fornecedor o que este prometeu ao cliente. Não pode, por si só, eliminar um poder público que vincula o fornecedor ou os seus colaboradores. Uma boa governação leva ambas as afirmações a sério. Utiliza contratos para definir obrigações e medidas técnicas para tornar essas obrigações observáveis, reconhecendo ao mesmo tempo que o alcance jurídico pode ainda alterar as opções disponíveis.

É tentador transformar isto numa caça a um único país perigoso. Isso é menos útil do que mapear as autoridades efetivas. Que entidade é o responsável pelo tratamento ou o subcontratante? Que entidade emprega o administrador? Que entidade detém as chaves de encriptação? Que entidade pode criar uma réplica? Que entidade recebe um pedido de suporte? Que autoridade poderia emitir uma ordem? Que recurso teria o cliente, e em que foro? O mapa pode ser tranquilizador. Pode não ser. Qualquer um dos resultados é mais valioso do que um autocolante de país.

A propriedade é um título, não uma chave

A propriedade tem uma força jurídica e económica genuína. Pode determinar quem pode vender um ativo, nomear administradores, licenciar propriedade intelectual, receber receitas ou tomar determinadas decisões. Num organismo público, pode estar ligada à responsabilidade estatutária pelos registos ou pelas infraestruturas. Num grupo empresarial, pode explicar quem pode votar, fundir, financiar ou substituir um fornecedor. A propriedade tem lugar numa avaliação de soberania.

A propriedade não proporciona automaticamente controlo operacional. Um cliente pode ser proprietário dos dados enquanto um fornecedor opera a base de dados, gere o sistema de cópias de segurança e controla a conta de serviço. Uma instituição pública pode ser proprietária de um edifício enquanto um contratante detém as credenciais de manutenção e a única via testada para repor o equipamento. Uma empresa pode ser proprietária do código-fonte enquanto um terceiro controla a chave de assinatura, o executor de compilações, o registo de pacotes e a identidade de implementação. O título é real. A dependência também.

A distinção torna-se visível nos verbos. A propriedade é um substantivo num contrato. O controlo é a capacidade de inspecionar, operar, alterar, interromper, recuperar, exportar, eliminar e comprovar. Um processo de aquisição que regista apenas substantivos pode deixar os verbos importantes por atribuir. Pode ter um proprietário nomeado para a plataforma e, ainda assim, não ter nenhuma pessoa nomeada que possa rodar uma chave, remover uma conta privilegiada ou restaurar a partir de uma cópia de segurança sem pedir a uma organização que não está na sala.

Não há virtude em exigir a posse máxima. Um hospital, uma universidade ou um município pode não ter pessoal e capacidade de segurança para operar todas as camadas com segurança. Delegar uma tarefa pode ser responsável quando os limites são explícitos e o cliente mantém a capacidade de supervisionar, testar e recuperar. A questão não é colocar todos os servidores numa cave pública. A questão é decidir quais poderes são essenciais à missão e manter esses poderes suficientemente próximos para os governar.

Essa decisão exige evidências. «O cliente é o dono dos dados» deve levar a perguntas sobre o formato de exportação, a custódia das chaves, a retenção, a eliminação, os registos de acesso e as permissões de suporte. «O fornecedor é europeu» deve levar a perguntas sobre o controlo corporativo, os subcontratados, a infraestrutura, a exposição legal e a continuidade. «Os dados estão na União» deve levar a perguntas sobre administração remota, réplicas, locais de processamento e pedidos legais. Uma boa resposta pode ser complicada. A complicação não é um defeito quando o sistema é complicado.

O controlo operacional é o direito de agir

O controlo operacional é mais fácil de entender através de uma ação do que de um adjetivo. Considere um cliente que precisa de revogar um administrador. Quem pode realizar a revogação? Que sistema de identidade a autoriza? O fornecedor é obrigado a executar a alteração, ou o cliente pode fazê-lo diretamente? A ação cobre contas de suporte, contas de emergência e credenciais inativas? Existe um registo que prove quando a permissão desapareceu? Se uma ação depende de uma linha de apoio, a linha de apoio faz parte do plano de controlo.

O mesmo teste aplica-se às chaves. A encriptação pode reduzir a exposição, mas a sua governação depende de quem cria, armazena, roda, recupera e pode usar as chaves. Um registo armazenado localmente pode permanecer ilegível para uma parte que não consiga obter a chave. Também pode tornar-se inacessível ao cliente quando o único caminho de recuperação está nas mãos de um fornecedor. A custódia das chaves não é, portanto, nem um slogan para a soberania nem uma borracha mágica para a jurisdição. É um controlo concreto que deve ser atribuído e ensaiado.

Os registos merecem o mesmo tratamento. Um painel pode mostrar atividade. As evidências exigem um registo que o cliente possa reter, interpretar e contestar. Quem escreve o registo? Um administrador pode alterá-lo? A fonte de tempo é fiável? Cobre o acesso de suporte e o processamento automatizado? O cliente pode obter uma exportação utilizável sem a permissão do fornecedor? O que acontece quando a conta é encerrada? Um registo que desaparece com o serviço é útil para as operações e fraco para a responsabilização.

A recuperação é o teste mais difícil do controlo operacional porque torna visíveis todas as dependências. Um fornecedor pode prometer cópias de segurança, mas a restauração pode exigir uma região específica, uma licença indisponível, um engenheiro que já não trabalha lá ou um segredo armazenado num sistema separado. O cliente pode ser o dono do ficheiro de cópia de segurança e ainda assim não ter a capacidade de o transformar num serviço funcional. A recuperação deve ser testada como uma ação completa, com o resultado registado e as lacunas atribuídas a pessoas que possam fechá-las.

Parar um serviço também é controlo. Uma instituição pode precisar de pausar uma integração, isolar um conjunto de dados, suspender o processamento automatizado ou impedir a criação de uma nova réplica. Se apenas um fornecedor puder realizar a paragem, a identidade do fornecedor, os seus deveres legais, o tempo de resposta e o processo de suporte passam a fazer parte do risco da instituição. Isso pode ser um acordo aceitável. Não é um acordo invisível.

O objetivo destes testes não é desconfiar de todos os fornecedores. É substituir a confiança por uma relação que possa ser inspecionada. Um fornecedor com uma resposta clara pode explicar quais as ações que executa, quais as que o cliente executa e quais exigem cooperação. Um fornecedor que se apoia numa única frase tranquilizadora ainda não respondeu à questão operacional.

Os subcontratados transformam uma resposta numa cadeia

Um serviço raramente é uma organização a fazer uma coisa num só lugar. Os fornecedores de cloud utilizam infraestrutura especializada, parceiros de suporte, serviços de monitorização, operações de segurança, manutenção de hardware, operadores de rede e outros fornecedores. Alguns são visíveis no contrato. Outros aparecem numa lista de subprocessadores, numa descrição do serviço, num aviso de incidente ou num fluxo de suporte. A cadeia é comum. A obrigação de compreender a cadeia também é comum.

A avaliação de risco da ENISA aponta uma falha conhecida: um fornecedor de cloud pode subcontratar serviços a um terceiro que não oferece as mesmas garantias, enquanto uma mudança de controlo pode alterar as condições do fornecedor. O relatório não é uma especificação de arquitetura moderna, nem precisa de o ser. O seu aviso duradouro é organizacional. Um cliente não pode afirmar que compreende um serviço quando apenas avaliou a primeira empresa mencionada na fatura.

As recomendações do CEPD são mais específicas para dados pessoais. O primeiro passo é conhecer as transferências, incluindo transferências subsequentes para processadores e subprocessadores. O acesso remoto a partir de um país terceiro pode, por si só, contar como transferência, mesmo quando o registo permanece num centro de dados do EEE. Um acordo de suporte faz, portanto, parte do mapa de transferências de dados, e não uma nota de rodapé que possa ser tratada após a implementação.

A visibilidade dos subcontratados não é o mesmo que o controlo sobre eles. Uma lista diz ao cliente quem está envolvido. O controlo pergunta o que cada parte pode fazer, que dados pode ver, que instrumento jurídico cobre a atividade, como uma alteração é notificada e que remédio existe quando a parte deixa de cumprir as condições. A cadeia deve ter limites e evidências em cada ponto de transição.

Há uma razão prática para resistir a cadeias vagas. Quando ocorre um incidente, a responsabilidade viaja frequentemente na direção oposta aos dados. O cliente pergunta ao fornecedor. O fornecedor pergunta à equipa da plataforma. A equipa da plataforma pergunta a um fornecedor especializado. O fornecedor especializado pergunta a um administrador noutra organização. Cada transição pode acrescentar atraso, incerteza e uma oportunidade para o registo original perder contexto. Um mapa de controlo deve mostrar o percurso antes do incidente, enquanto as pessoas envolvidas ainda têm tempo para serem precisas.

Dados pessoais: a proteção viaja com o registo

O RGPD não torna os dados pessoais seguros apenas por os colocar atrás de uma porta europeia. As suas regras de transferência foram concebidas para preservar um nível de proteção elevado quando os dados são transferidos para um país terceiro. O CEPD descreve o princípio de forma clara: um nível de proteção essencialmente equivalente deve acompanhar os dados onde quer que estes se encontrem, durante e após a transferência.

Isto não significa que todas as transferências sejam proibidas. O RGPD prevê diferentes instrumentos e condições de transferência, incluindo decisões de adequação e garantias ao abrigo do artigo 46.º. A questão jurídica é saber se o instrumento escolhido funciona nas circunstâncias em causa. As recomendações do CEPD indicam aos exportadores que avaliem o direito e a prática relevantes para a transferência em questão, que considerem se o importador ou os dados podem ser abrangidos por regras problemáticas e que documentem o seu raciocínio. Se nenhuma medida suplementar puder restabelecer o nível de proteção exigido, a transferência deve ser evitada, suspensa ou terminada.

Três pormenores são especialmente fáceis de ignorar numa conversa sobre residência. Em primeiro lugar, uma transferência subsequente é relevante. Um fornecedor pode manter o registo principal no EEE e enviar uma cópia para um serviço de apoio ou de análise localizado noutro local. Em segundo lugar, o acesso é relevante. Um administrador num país terceiro pode conseguir ler um registo sem que este seja fisicamente movido para a secretária dessa pessoa. Em terceiro lugar, a responsabilização é relevante. O exportador deve ser capaz de demonstrar a avaliação e de a rever quando o serviço, o direito, as pessoas ou as circunstâncias mudarem.

O enquadramento exige, portanto, que o cliente compreenda tanto o percurso técnico como o contexto jurídico. Um diagrama com regiões e setas é útil. Não pode substituir a avaliação de transferência. Também não pode substituí-la uma promessa contratual de que o fornecedor cumprirá, se o cliente não tiver verificado o que as garantias relevantes podem alcançar face às leis e práticas que possam aplicar-se ao fornecedor.

A legislação europeia de proteção de dados tem uma saudável aversão a palavras mágicas. «Alojamento na UE» pode descrever um facto útil. «Conforme» pode descrever uma conclusão que exige fundamentação. «Soberano» pode descrever um objetivo político. Nenhuma destas palavras deve substituir a evidência de que os dados estão protegidos, o acesso é regulado e a decisão pode ser defendida.

Dados não pessoais: um regime diferente, a mesma disciplina

O Regulamento dos Dados abrange um conjunto mais vasto de relações de dados e inclui regras para serviços de processamento de dados, como os serviços de cloud e de edge. Não substitui o RGPD e não transforma todas as decisões sobre cloud numa avaliação de transferência de proteção de dados. Constitui, no entanto, um segundo lembrete europeu de que a localização, o acesso, a mudança de fornecedor e a autoridade têm de ser considerados em conjunto.

Para os dados não pessoais detidos na União, a explicação da Comissão sobre o Regulamento dos Dados descreve salvaguardas para determinados pedidos ou decisões de uma autoridade pública de um país terceiro. Quando nenhum acordo internacional aplicável rege o acesso, o regulamento estabelece condições destinadas a proteger os interesses europeus, incluindo a atenção ao sistema jurídico do país terceiro e à proporcionalidade do pedido. Espera-se que os fornecedores adotem medidas razoáveis, como encriptação, auditorias ou acordos de certificação, para impedir o acesso não autorizado e para informar os clientes sempre que possível.

A redação é importante. O Regulamento dos Dados não afirma que a União pode fazer desaparecer os sistemas jurídicos estrangeiros. Cria um enquadramento para avaliar e limitar determinadas vias de acesso. O fornecedor continua a ter de saber que sistemas opera, que dados detém, quem pode responder a um pedido e que provas podem ser apresentadas ao cliente. O cliente continua a ter de compreender quais as partes dos dados que são pessoais, quais não são e que outros regimes jurídicos se aplicam.

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.

A tabela é deliberadamente prosaica. Foi feita para sobreviver ao contacto com uma equipa de compras. Dá também ao comprador uma forma de comparar fornecedores sem fingir que um certificado, uma bandeira nacional ou uma visita a um centro de dados resolve tudo. As provas podem ser confidenciais. A exigência de ter provas não deve ser.

Peça uma demonstração da ação crítica, não apenas uma descrição. Mostre como uma conta privilegiada é removida. Mostre como uma sessão de suporte é aprovada. Mostre o que o cliente recebe quando pede uma exportação. Mostre como uma réplica é localizada. Mostre o que um pedido legal faz ao fluxo de trabalho de incidentes. Mostre como a organização continua quando a conta do fornecedor é suspensa. O objetivo não é encenar uma falha dramática. É ver se o controlo existe fora do diapositivo.

Depois pergunte quem é dono do resultado. Um teste sem dono é uma encenação. Uma lacuna sem data é uma funcionalidade permanente. Um controlo sem registo é uma crença. O mapa deve, portanto, nomear a pessoa ou o organismo que aceita o risco, o fornecedor que deve executar a ação e a via para contestar o resultado. Governação não é uma pilha de perguntas. É um conjunto de decisões com um destino.

Uma experiência de pensamento sobre um arquivo europeu

O que se segue é uma hipótese rotulada, não um relato de um cliente ou incidente real. Imagine um arquivo municipal a selecionar um serviço alojado para registos de planeamento digitalizados. O concurso exige armazenamento primário na União Europeia e pede encriptação, backups e um balcão de suporte. Três fornecedores cumprem as palavras. Um está incorporado localmente, mas depende de um subcontratado de suporte fora da União. Um mantém armazenamento e suporte na União, mas usa a plataforma de identidade da empresa-mãe. Um tem uma operação local mais pequena, custódia clara das chaves e uma exportação testada, mas precisa de um nível de serviço cuidadosamente definido porque não pode oferecer todas as funcionalidades opcionais.

O primeiro fornecedor pode ainda assim ser aceitável. O segundo pode ainda assim ser aceitável. O terceiro pode ainda assim ser inadequado para um requisito específico de disponibilidade. O objetivo da experiência de pensamento é que a residência sozinha não pode escolher entre eles. O arquivo tem de perguntar que acesso de suporte é possível, quem pode fazer uma cópia, que entidades legais podem receber uma ordem, como as chaves são governadas, o que os registos mostram e se os registos podem ser recuperados noutro local.

Suppose the archive decides that local storage is its most important condition. It can write that requirement into the contract. It should also define the objects covered by the condition, require notice of a change, and ask how a breach would be detected. Suppose it decides that remote support is allowed only for a documented incident. The service needs an approval path, time-limited credentials and a record that can be reviewed. Suppose it decides that the archive must be able to leave. The exit should be tested before the service becomes the only place anyone knows how to read the records.

Nothing in this hypothetical requires the archive to operate a data centre. It requires the archive to understand the powers it delegates. That is the difference between responsible outsourcing and a purchase that moves the risk into a room the buyer cannot enter.

What Europe can honestly mean by sovereign

European sovereignty in digital infrastructure should be described in terms that can survive an awkward question. It can mean that a European institution retains authority over critical decisions. It can mean that key dependencies are visible, constrained and recoverable. It can mean that legal rights are matched by technical capability. It can mean that a public buyer can switch, challenge, inspect and continue operating when a provider or a law changes the available path.

It should not mean that a service is automatically safe because its marketing address is European. Nor should it mean that every foreign connection is forbidden. Europe depends on cross-border systems, and a rule that pretends otherwise will be ignored or quietly circumvented. The mature position is more demanding: permit the dependencies that serve the mission, document them, reduce the ones that carry unacceptable power, and keep an exit for the ones that cannot be made trustworthy.

That position also gives European providers a fairer test. A local provider should not have to perform a flag ceremony to be taken seriously. It should be able to show what it operates, what it delegates, who can access it, what law may apply, how data is protected, and how a customer can leave. A global provider should face the same questions. The standard is control evidence, not origin theatre.

The word sovereignty becomes useful when it changes buying behaviour. A ministry can use procurement to reward a tested exit path. A hospital can require key arrangements that match its clinical duties. A university can make the provenance of research data visible. A regulator can ask for the state of a system at the time of a decision. A supplier can design its service so that customer authority is not a decorative paragraph. These are institutional actions, not a slogan contest.

A small note from us

At Dweve, our public analysis The Sovereignty Illusion: where control really sits, published on 29 June 2026, uses a similar discipline. It separates ownership, technology, capital, infrastructure and legal exposure instead of allowing a European label to stand for all five. This article is narrower. It follows the data-centre claim into the operational and legal layers that a buyer has to govern.

That is also how we prefer to describe our own work. A system should make its boundaries legible: what is local, what is delegated, what is recorded, what can be challenged and what can be changed. The useful claim is the one a reader can inspect. The rest is decoration, and Europe already has plenty of decorative infrastructure.

The legal argument starts after the address

A data centre's location is worth knowing. It can affect physical access, resilience, connectivity, applicable local rules and the design of a service. It can be the right first question. It is a poor final answer.

A resposta final tem de ligar o lugar à autoridade. Tem de nomear o operador, as identidades, as chaves, os subcontratantes, os instrumentos jurídicos, os pedidos possíveis, as provas e a saída. Para dados pessoais, o nível de proteção europeu tem de permanecer essencialmente equivalente quando os dados são transferidos, e os exportadores têm de avaliar as circunstâncias em vez de repetir uma alegação de localização. Para dados não pessoais, o Regulamento relativo aos dados harmonizados acrescenta regras sobre o acesso estrangeiro e a mudança de fornecedor de serviços na nuvem, que voltam a tornar concretos o controlo e a portabilidade.

Não existe um único número europeu que possa transformar um serviço complicado num serviço soberano. Existe uma sequência de perguntas, testes e registos. A sequência é mais lenta do que imprimir «alojado na UE» num folheto. É também a parte que continua a ser útil depois de o folheto ficar desatualizado.

Quando um comprador pergunta onde estão os dados, responda com precisão à localização. Depois pergunte quem os pode ler, quem pode agir sobre eles, quem pode ser obrigado, quem pode provar o que aconteceu e quem pode sair. Um centro de dados europeu pode fazer parte de um acordo digno de confiança. Não pode ser, por si só, o argumento jurídico.

Fontes

• Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data, Comité Europeu para a Proteção de Dados, versão final de 18 de junho de 2021. A página ligada inclui o PDF oficial.
• Case C-311/18, Data Protection Commissioner v Facebook Ireland and Schrems II, Tribunal de Justiça da União Europeia, acórdão de 16 de julho de 2020, EUR-Lex.
• Regulation (EU) 2023/2854, the Data Act, Parlamento Europeu e Conselho, 13 de dezembro de 2023, EUR-Lex.
• Data Act explained, Comissão Europeia, publicado em 2025 e consultado em 5 de agosto de 2026.
• Cloud Computing Risk Assessment e o relatório oficial em PDF, Agência da União Europeia para a Cibersegurança (ENISA), 2009.
• The Sovereignty Illusion: where control really sits, Dweve, 29 de junho de 2026.