Durante muito tempo, as decisões tecnológicas foram avaliadas com base num conjunto familiar de perguntas: É mais rápido? É mais barato? Consegue escalar? Vai tornar a equipa mais produtiva?
Essas perguntas continuam a ser importantes. Já não chegam.
Quando uma organização depende de infraestrutura, plataformas e, cada vez mais, de modelos de IA externos, há uma pergunta mais difícil que surge primeiro: o que acontece quando os termos mudam? O que acontece quando o acesso se torna mais caro, mais restrito, politicamente exposto ou difícil de explicar a um regulador, ao conselho de administração ou a um cliente?
Essa é a questão da soberania em TI e IA.
Não se trata apenas de onde os dados estão armazenados. Trata-se de controlo num sentido mais amplo: quem pode inspecionar o sistema, interrompê-lo, impor acesso, alterar as regras ou dificultar a saída. Trata-se também de responsabilização. Quando algo corre mal, quem continua a ser responsável?
Não existe uma definição global única de soberania digital. Diferentes jurisdições dão ênfase a aspetos diferentes: alcance jurídico, dependência de infraestrutura, controlo dos dados, resiliência operacional, concentração de fornecedores e, cada vez mais, controlo sobre a camada dos modelos de IA. O fio condutor é prático, e não ideológico.
A soberania é a capacidade de manter um controlo significativo sobre as capacidades digitais de que uma organização mais depende.
Isto não significa que todos os países ou empresas tenham de construir tudo por si próprios. Significa saber onde a dependência é aceitável, onde é perigosa e que controlo deve permanecer internamente ou ser contratualmente exigível.
A soberania não é autossuficiência
A soberania é frequentemente confundida com autossuficiência ou residência de dados. Nenhuma das duas abrange o problema por completo.
Uma empresa pode armazenar os seus dados na jurisdição certa e continuar exposta se a plataforma envolvente for difícil de abandonar, se o fornecedor continuar sujeito a exigências legais estrangeiras ou se os sistemas de IA integrados em fluxos de trabalho críticos não puderem ser auditados nem influenciados pelo cliente.
A IA torna esta distinção mais urgente. Um modelo não é apenas mais um componente de software. Pode moldar a forma como uma organização escreve, pesquisa, classifica, presta apoio ao cliente, analisa informação e toma decisões. Quando isso acontece, a dependência sobe na stack. A questão deixa de ser apenas onde uma máquina corre. Passa a ser quem molda a inteligência dentro do trabalho.
A maioria das organizações reconhece isto em momentos operacionais banais. Um fornecedor altera os preços e um caso de uso viável torna-se subitamente dispendioso. Uma atualização do modelo muda os resultados e os fluxos de trabalho internos têm de ser recalibrados. As equipas jurídicas ou de conformidade colocam perguntas simples sobre o tratamento de dados e recebem respostas vagas. A área de compras descobre que uma arquitetura supostamente flexível seria cara e lenta de substituir.
Não é necessária uma crise geopolítica. A dependência normal basta.
Um debate global com linguagem jurídica diferente
A questão é global, mesmo quando a terminologia difere.
Nos Estados Unidos, a preocupação é frequentemente expressa através da autorização federal e dos controlos de segurança nacional, em vez da expressão soberania digital. O FedRAMP fornece uma abordagem padronizada para avaliar, autorizar e monitorizar continuamente os serviços cloud utilizados por agências federais. As agências continuam responsáveis pelas suas cargas de trabalho depois de as transferirem para a cloud, e os ambientes de defesa acrescentam requisitos adicionais.
O Reino Unido tende a enquadrar a questão em termos de resiliência operacional e dependência sistémica. O Bank of England, a PRA e a FCA estabeleceram um regime de Critical Third Parties porque uma perturbação grave num fornecedor externo pode criar risco não apenas para uma empresa, mas para o sistema financeiro em geral.
O perfil de controlo cloud do Canadá para informação Protected B torna explícito o princípio da responsabilização: as responsabilidades podem ser delegadas em fornecedores cloud, mas a responsabilização não desaparece com essa transferência.
A Índia combina requisitos de localização de dados para dados de sistemas de pagamento com a expectativa de que as entidades reguladas continuem responsáveis pelos acordos de IT externalizada e cloud. Singapura acolhe a adoção da cloud, tratando-a ao mesmo tempo como uma forma de externalização que tem de ser governada. A Austrália, o Brasil e a África do Sul abordam igualmente a questão através da resiliência operacional, do risco associado aos prestadores de serviços, do acesso de supervisão, da governação de dados e das infraestruturas estratégicas.
O padrão é claro. A soberania não é uma preocupação europeia de nicho. É uma resposta ampla ao facto de a dependência digital se ter tornado estratégica.
Porque é que a abordagem europeia importa
A Europa levou o conceito mais longe do que a maioria das jurisdições, ao transformá-lo num quadro de contratação e avaliação.
O Cloud Sovereignty Framework da Comissão Europeia avalia os fornecedores de cloud soberana em oito objetivos: considerações estratégicas, jurídicas e jurisdicionais, de dados e IA, operacionais, da cadeia de abastecimento, tecnológicas, de segurança e conformidade, e ambientais. Utiliza dois mecanismos complementares:
- Sovereignty Effectiveness Assurance Level (SEAL): um nível mínimo de garantia para cada objetivo.
- Overall sovereignty score: uma comparação ponderada das propostas que cumprem o limiar de SEAL exigido.
A distinção é importante. O SEAL global é determinado pelo nível relevante mais baixo alcançado entre os objetivos. Uma fragilidade séria numa área crítica pode, por isso, limitar o nível global do fornecedor, independentemente da sua solidez noutras áreas. A pontuação serve um propósito diferente: distinguir entre propostas que já ultrapassaram o limiar mínimo.
O nível segue uma lógica de limiar; a pontuação segue uma lógica comparativa.
As orientações da Comissão dão à entidade adjudicante margem para definir o SEAL mínimo exigido para uma contratação e, depois, comparar as propostas qualificadas através da pontuação. A sua contratação de cloud soberana de 2026 exigia que os fornecedores atingissem pelo menos o SEAL-2. O quadro também reconhece graus de soberania: o SEAL-2 está associado à soberania dos dados, o SEAL-3 à resiliência digital e o SEAL-4 à soberania digital plena.
O nível mais elevado é deliberadamente exigente. A Comissão observa que a soberania plena continua a ser difícil no contexto europeu atual devido a dependências persistentes nas cadeias de abastecimento, em particular no hardware e nos chips. Isto corrige de forma útil o pensamento binário. Um serviço pode melhorar a posição de soberania de uma organização sem satisfazer a definição mais exigente imaginável de soberania.
É por isso que o quadro é mais do que uma checklist. Obriga o conceito a resistir ao contacto com a contratação, a engenharia, a revisão jurídica e a responsabilização institucional.
Porque isto importa para além dos setores regulados
Os bancos, os operadores de telecomunicações, as organizações de defesa, os sistemas de saúde e as autoridades públicas tendem a sentir estas pressões primeiro porque a regulação torna visível o que está em jogo. A vulnerabilidade subjacente é muito mais ampla.
Um fabricante que depende de uma única região de um hyperscaler para a análise da produção, uma empresa de software que construiu funcionalidades essenciais em torno de um único fornecedor de modelos, um retalhista que depende de uma infraestrutura de identidade externa, ou uma universidade que incorpora ferramentas de IA de terceiros na investigação e na administração enfrentam, todos eles, variantes do mesmo problema.
Parte do risco é geopolítica. Controlos de exportação, sanções, intervenções por motivos de segurança nacional e exigências legais transfronteiriças podem penetrar mais profundamente na stack tecnológica do que muitas organizações presumiam. Outra parte é estrutural: um pequeno número de empresas sustenta uma grande fatia da capacidade global de cloud, plataformas, identidade e IA. As suas capacidades são muitas vezes excelentes. É precisamente por isso que a dependência pode tornar-se profunda.
A IA acentua a questão porque os serviços externos passam a ser capacidades internas. Quando um modelo é integrado em fluxos de trabalho de apoio, redação, pesquisa, revisão de conformidade ou experiência de produto, passa a fazer parte da forma como a organização pensa e opera. Se essa camada for difícil de auditar, governar ou substituir, a dependência deixa de ser meramente técnica. Torna-se de gestão e estratégica.
O que a perspetiva da soberania ajuda a ver
A soberania entende-se melhor como uma disciplina de discernimento, não como uma exigência de independência total.
A pergunta útil não é se uma organização controla tudo. Quase nenhuma consegue. A melhor pergunta é: qual é o objetivo de soberania mais fraco, e porquê?
O fator limitativo é a propriedade e a governação? A exposição jurídica? O controlo dos dados? A dependência operacional? A fragilidade da cadeia de abastecimento? O lock-in tecnológico? Ou a própria camada de IA?
Quando isso se torna visível, a resposta passa a ser concreta. Algumas organizações precisam de direitos de auditoria e de saída mais robustos. Algumas precisam de limites jurisdicionais mais apertados para dados ou cargas de trabalho específicas. Algumas podem manter funções selecionadas portáveis entre fornecedores de cloud ou de modelos, mesmo quando isso acrescente custos. Outras podem aceitar uma dependência gerida em áreas menos críticas, mantendo ao mesmo tempo um controlo mais forte sobre sistemas que determinam a resiliência, a responsabilização ou a vantagem competitiva.
Esse é o valor da perspetiva da soberania. Não prescreve uma única conclusão política nem exige uma autossuficiência tecnológica dramática. Dá às organizações uma forma disciplinada de identificar o seu objetivo relevante mais fraco, compreender por que razão é fraco e decidir se a exposição é aceitável.
Essa questão aplica-se agora à infraestrutura, aos dados e, cada vez mais, à IA.
Fontes
- Comissão Europeia: Explicação do Sovereign Cloud Framework (2026)
- Comissão Europeia: Cloud Sovereignty Framework — Orientações de implementação (2026)
- Comissão Europeia: A Comissão promove a soberania da cloud através da contratação estratégica (2026)
- APRA: CPG 230 Gestão do Risco Operacional
- U.S. General Services Administration: Segurança na cloud
- Bank of England, PRA e FCA: Terceiros Críticos para o setor financeiro do Reino Unido
- Governo do Canadá: Perfil de Controlo de Segurança para Serviços GC baseados na cloud
- Reserve Bank of India: FAQ sobre o Armazenamento de Dados de Sistemas de Pagamento
- Reserve Bank of India: Diretrizes para Bancos Comerciais — Gestão dos Riscos na Subcontratação, 2025
- Monetary Authority of Singapore: Cloud
- Banco Central do Brasil: Resolução CMN nº 4.893
- Governo da África do Sul: Política Nacional sobre Dados e Cloud (2024)
