Por muito tempo, as decisões de tecnologia foram avaliadas com base em um conjunto familiar de perguntas: é mais rápido? É mais barato? Consegue escalar? Vai tornar a equipe mais produtiva?
Essas perguntas ainda importam. Mas já não bastam.
Quando uma organização depende de infraestrutura, plataformas e, cada vez mais, de modelos de IA externos, uma pergunta mais difícil vem primeiro: o que acontece quando os termos mudam? O que acontece quando o acesso fica mais caro, restrito, politicamente exposto ou difícil de explicar a um regulador, conselho ou cliente?
Essa é a questão da soberania em TI e IA.
Não se trata apenas de onde os dados estão. Trata-se de controle em um sentido mais amplo: quem pode inspecionar o sistema, interrompê-lo, exigir acesso, mudar as regras ou dificultar a saída. Trata-se também de responsabilidade. Quando algo dá errado, quem continua sendo responsável?
Não existe uma definição global única de soberania digital. Diferentes jurisdições enfatizam aspectos diferentes: alcance legal, dependência de infraestrutura, controle de dados, resiliência operacional, concentração de provedores e, cada vez mais, controle sobre a camada de modelos de IA. O fio condutor é prático, não ideológico.
Soberania é a capacidade de manter controle significativo sobre os recursos digitais dos quais uma organização mais depende.
Isso não significa que todo país ou empresa precise construir tudo por conta própria. Significa saber onde a dependência é aceitável, onde ela é perigosa e qual controle precisa permanecer interno ou ser contratualmente exigível.
Soberania não é autossuficiência
Soberania costuma ser confundida com autossuficiência ou residência de dados. Nenhuma das duas abrange o problema por completo.
Uma empresa pode armazenar seus dados na jurisdição correta e ainda assim estar exposta se a plataforma ao redor for difícil de abandonar, se o provedor continuar sujeito a exigências legais estrangeiras ou se os sistemas de IA incorporados a fluxos de trabalho críticos não puderem ser auditados nem influenciados pelo cliente.
A IA torna essa distinção mais urgente. Um modelo não é apenas mais um componente de software. Ele pode moldar a forma como uma organização escreve, pesquisa, classifica, atende clientes, analisa informações e toma decisões. Quando isso acontece, a dependência sobe na pilha. A pergunta deixa de ser apenas onde uma máquina roda. Passa a ser quem molda a inteligência dentro do trabalho.
A maioria das organizações reconhece isso em momentos operacionais comuns. Um fornecedor muda sua precificação e um caso de uso viável de repente se torna caro. Uma atualização de modelo altera os resultados, e os fluxos de trabalho internos precisam ser recalibrados. Equipes jurídicas ou de compliance fazem perguntas diretas 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 é preciso uma crise geopolítica. A dependência cotidiana já basta.
Um debate global com linguagens jurídicas diferentes
A questão é global, mesmo quando a terminologia varia.
Nos Estados Unidos, a preocupação costuma ser expressa em termos de autorização federal e controles de segurança nacional, e não pela expressão soberania digital. O FedRAMP oferece uma abordagem padronizada para avaliar, autorizar e monitorar continuamente serviços de nuvem usados por agências federais. As agências continuam responsáveis por suas cargas de trabalho depois de migrá-las para a nuvem, e ambientes de defesa acrescentam exigências 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 grande interrupção em um fornecedor externo pode criar risco não apenas para uma empresa, mas para o sistema financeiro mais amplo.
O perfil canadense de controles de nuvem para informações Protected B explicita o princípio da responsabilização: responsabilidades podem ser delegadas a provedores de nuvem, 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 entidades reguladas continuem responsáveis por arranjos terceirizados de TI e nuvem. Singapura acolhe a adoção de nuvem, mas a trata como terceirização que precisa ser governada. Austrália, Brasil e África do Sul também abordam a questão por meio de resiliência operacional, risco de prestadores de serviço, acesso de supervisão, governança de dados e infraestrutura estratégica.
O padrão é claro. Soberania não é uma preocupação europeia de nicho. É uma resposta ampla ao fato de que a dependência digital se tornou estratégica.
Por que a abordagem europeia importa
A Europa levou o conceito mais longe do que a maioria das jurisdições ao transformá-lo em uma estrutura de compras e avaliação.
O Cloud Sovereignty Framework da Comissão Europeia avalia provedores de nuvem soberana em oito objetivos: considerações estratégicas, legais e jurisdicionais, de dados e IA, operacionais, de cadeia de suprimentos, tecnológicas, de segurança e compliance, e ambientais. Ele usa 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 entre ofertas que atendem ao limite mínimo exigido de SEAL.
A distinção importa. O SEAL geral é definido pelo menor nível relevante alcançado entre os objetivos. Uma fragilidade séria em uma área crítica pode, portanto, limitar o nível geral do provedor, independentemente da força em outras áreas. A pontuação cumpre um papel diferente: distinguir entre ofertas que já superaram o limite mínimo.
Nível é lógica de limiar; pontuação é lógica comparativa.
A orientação da Comissão dá à autoridade contratante margem para definir o SEAL mínimo exigido em uma contratação e, depois, comparar as ofertas qualificadas por meio da pontuação. Sua contratação de nuvem soberana de 2026 exigiu que os provedores alcançassem pelo menos o SEAL-2. A estrutura também reconhece graus de soberania: o SEAL-2 está associado à soberania de dados, o SEAL-3 à resiliência digital e o SEAL-4 à soberania digital plena.
O nível mais alto é deliberadamente exigente. A Comissão observa que a soberania plena continua difícil no contexto europeu atual por causa de dependências persistentes nas cadeias de suprimentos, especialmente em hardware e chips. Isso corrige de forma útil o pensamento binário. Um serviço pode melhorar a postura de soberania de uma organização sem satisfazer a definição mais forte imaginável de soberania.
É por isso que a estrutura é mais do que um checklist. Ela obriga o conceito a resistir ao contato com compras, engenharia, revisão jurídica e responsabilização institucional.
Por que isso importa além dos setores regulados
Bancos, operadoras de telecomunicações, organizações de defesa, sistemas de saúde e autoridades públicas tendem a sentir essas pressões primeiro porque a regulação torna os riscos visíveis. A vulnerabilidade subjacente é muito mais ampla.
Um fabricante que depende de uma única região de hyperscaler para analytics de produção, uma empresa de software que construiu funcionalidades centrais em torno de um único provedor de modelos, um varejista que depende de infraestrutura externa de identidade ou uma universidade que incorpora ferramentas de IA de terceiros à pesquisa e à administração enfrentam versões do mesmo problema.
Parte do risco é geopolítica. Controles de exportação, sanções, intervenções de segurança nacional e exigências legais transfronteiriças podem alcançar camadas mais profundas da stack tecnológica do que muitas organizações supunham. Outra parte é estrutural: um pequeno número de empresas sustenta uma grande parcela da capacidade global de nuvem, plataforma, identidade e IA. Suas capacidades costumam ser excelentes. É justamente por isso que a dependência pode se tornar profunda.
A IA torna a questão mais aguda porque serviços externos passam a ser capacidades internas. Quando um modelo é integrado a fluxos de trabalho de suporte, redação, busca, revisão de conformidade ou experiência de produto, ele passa a fazer parte de como a organização pensa e opera. Se essa camada é difícil de auditar, governar ou substituir, a dependência deixa de ser apenas técnica. Ela se torna gerencial e estratégica.
O que a lente da soberania ajuda você a enxergar
A soberania é melhor entendida como uma disciplina de julgamento, 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 pergunta melhor é: qual objetivo de soberania está mais fraco, e por quê?
O fator limitante é propriedade e governança? Exposição jurídica? Controle de dados? Dependência operacional? Fragilidade da cadeia de suprimentos? Lock-in tecnológico? Ou a própria camada de IA?
Quando isso fica visível, a resposta se torna concreta. Algumas organizações precisam de direitos mais fortes de auditoria e saída. Algumas precisam de limites jurisdicionais mais rígidos para dados ou cargas de trabalho específicas. Algumas podem manter funções selecionadas portáveis entre provedores de nuvem ou de modelos, mesmo quando isso aumenta o custo. Outras podem aceitar uma dependência gerenciada em áreas menos críticas, ao mesmo tempo em que preservam um controle mais forte sobre sistemas que determinam resiliência, accountability ou vantagem competitiva.
Esse é o valor da lente da soberania. Ela não prescreve uma única conclusão política nem exige uma autossuficiência tecnológica dramática. Ela oferece às organizações uma forma disciplinada de identificar seu objetivo relevante mais fraco, entender por que ele é fraco e decidir se a exposição é aceitável.
Essa pergunta agora se aplica à 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 em nuvem por meio de compras estratégicas (2026)
- APRA: CPG 230 Gestão de Risco Operacional
- U.S. General Services Administration: Segurança em Nuvem
- Bank of England, PRA e FCA: Terceiros Críticos para o setor financeiro do Reino Unido
- Governo do Canadá: Perfil de Controles de Segurança para Serviços do GC baseados em nuvem
- Reserve Bank of India: FAQ sobre Armazenamento de Dados de Sistemas de Pagamento
- Reserve Bank of India: Diretrizes para bancos comerciais — gestão de riscos em terceirização (2025)
- Monetary Authority of Singapore: Nuvem
- Banco Central do Brasil: Resolução CMN nº 4.893
- Governo da África do Sul: Política Nacional sobre Dados e Nuvem (2024)
