Em junho de 2025, a Microsoft anunciou um pacote de soluções de soberania para clientes europeus. Uma delas, batizada de Data Guardian, restringe o acesso remoto aos sistemas que guardam dados europeus a funcionários da própria empresa baseados na Europa, com aprovação em tempo real e registro à prova de adulteração de cada acesso.
Sete meses depois, em janeiro de 2026, a AWS anunciou a entrada em operação da sua própria nuvem soberana europeia: mais de 7,8 bilhões de euros investidos, primeira região funcionando no estado alemão de Brandemburgo, e uma frase que resume a intenção — "zero controle operacional fora das fronteiras da União Europeia". Em novembro de 2025, a Google Cloud já tinha aberto em Munique seu primeiro centro dedicado a soluções de soberania de dados, sob a justificativa, nas palavras de um vice-presidente da empresa, de que "organizações europeias deveriam ter controle sobre o próprio destino digital".
Três das maiores provedoras de nuvem do mundo, num intervalo de pouco mais de um ano, criaram estruturas jurídicas e operacionais inteiramente novas para um único propósito: convencer clientes europeus de que os dados — e, cada vez mais, o funcionamento dos agentes de IA que os usam — ficam sob regras que a empresa cliente entende e consegue verificar. Isso não é um movimento de marketing regional. É um sinal de para onde a conversa de compra está indo em qualquer lugar do mundo, inclusive aqui.
A pergunta que mudou de lugar
Durante anos, a pergunta de um comitê de compras sobre a nuvem de um fornecedor era geográfica: em que país fica o servidor. As três empresas trataram essa pergunta como insuficiente. A Microsoft descreve a Sovereign Public Cloud como um ambiente em que "os dados do cliente ficam na Europa, sob a lei europeia, com operação e acesso controlados por pessoal europeu, e a criptografia sob controle total do cliente" — quatro condições, não uma.
A AWS foi na mesma direção com outra ênfase: a nuvem soberana europeia é descrita como "física e logicamente separada" das demais regiões da empresa, "operada exclusivamente por residentes da União Europeia", sem dependências críticas de infraestrutura fora do bloco, e projetada para continuar funcionando "mesmo em caso de interrupção de comunicação com o resto do mundo". A governança inclui uma controladora e subsidiárias na Alemanha lideradas por cidadãos europeus, mais um conselho consultivo com integrantes independentes.
O padrão nas três empresas é o mesmo: residência física do dado deixou de ser suficiente como resposta. O que passou a valer é quem tem acesso operacional, sob qual lei, com qual registro e com que possibilidade de auditoria — dito com essa precisão, e de preferência escrito em contrato.
Isso explica por que a Google Cloud descreve o próprio movimento como uma questão de "controle sobre o destino digital" da empresa cliente, e não apenas de localização de dado. E explica também por que a estrutura de governança da AWS na Europa inclui um conselho consultivo com integrantes independentes do quadro da própria Amazon: a ideia é que a supervisão não dependa só da palavra do fornecedor.
Onde a promessa de soberania ainda esbarra na prática

Nenhuma dessas três estruturas nasceu de um capricho de engenharia. Nasceu de uma pergunta que reguladores, auditores e diretorias europeias já fazem há anos e que se tornou impossível de ignorar quando a IA generativa passou a lidar com contrato, política interna e dado de cliente: se uma lei de outro país obriga a divulgação de informação armazenada na nuvem, quem decide, e sob qual processo, o que é entregue?
A resposta de cada provedora é uma combinação de arquitetura técnica e estrutura jurídica local — não um adesivo de "servidor na Europa" colado sobre um produto que continua operado de fora. E é exatamente aí que a maioria dos contratos de IA assinados por empresas fora da Europa ainda falha: a residência do dado é mencionada, mas o acesso operacional, a cadeia de aprovação e a trilha de auditoria não são especificados em nenhuma cláusula verificável. Um servidor "no país certo" não resolve nada se o fornecedor pode acessar, mover ou usar aquele dado sem nenhum registro que a empresa contratante consiga conferir depois.
O que precisa existir na prática
O movimento das três provedoras aponta para quatro elementos que qualquer empresa — europeia ou não — já pode exigir antes de assinar um contrato de IA corporativa.
Residência e arquitetura definidas por contrato, não por promessa verbal. Onde o dado é processado e armazenado precisa estar escrito, com a possibilidade real de auditoria — não apenas afirmado numa página de vendas.
Cada empresa com dados e regras separados. O ambiente de um cliente não pode se misturar com o de outro, nem tecnicamente nem em termos de política de acesso. É a mesma lógica que levou a AWS a descrever sua nuvem soberana como fisicamente separada das demais regiões da empresa.
Retenção configurável com expurgo automático. Por quanto tempo um dado fica guardado, e o que acontece com ele depois, precisam ser parâmetros que a empresa contratante define — não uma política genérica do fornecedor.
Trilha de auditoria de quem acessou o quê, quando e por quê. Sem esse registro, "soberania" é uma palavra em um material de marketing, não uma garantia verificável.
É assim que a Skyller foi desenhada: residência e arquitetura conforme o plano e o contrato de cada cliente, cada empresa com dados e regras separados, e retenção configurável com expurgo automático desde o primeiro dia.
O que muda para quem está comprando IA hoje

Para uma empresa brasileira ou latino-americana, nada disso é um assunto só europeu. A mesma pergunta que levou Microsoft, AWS e Google a criar estruturas dedicadas — quais regras exatamente valem para este dado, e quem pode prová-lo — vale para qualquer fornecedor de IA corporativa contratado aqui, independentemente de onde ele tenha nascido.
O ganho prático de tratar isso como critério de compra, e não como detalhe técnico, é dobrado. Do lado do risco, a empresa deixa de depender da palavra do fornecedor e passa a ter uma cláusula que pode cobrar em uma auditoria ou numa investigação de incidente. Do lado da negociação, uma diretoria que sabe exatamente quais perguntas fazer chega à mesa em posição mais forte do que uma que só pergunta "os dados ficam seguros?" — pergunta ampla demais para gerar qualquer resposta útil.
Há ainda um efeito que costuma passar despercebido: uma vez que a empresa escreve essas quatro exigências num processo interno de compra, elas passam a valer para qualquer fornecedor novo, de IA ou não. O critério deixa de ser um capricho de um contrato específico e vira parte do jeito como a empresa avalia qualquer serviço que vai lidar com dado sensível.
Infraestrutura inteiramente controlada pelo cliente, em nuvem própria ou em ambiente local, segue como possibilidade adicional para quem tem essa exigência específica — mas para a maioria das empresas o que resolve o problema real não é onde o servidor está fisicamente, é a arquitetura e o contrato que definem quem manda naquele dado.
Quatro perguntas para levar à próxima reunião de compra
Antes de assinar o próximo contrato de IA, seja com um fornecedor local ou internacional, vale levar estas perguntas para a mesa:
- Onde exatamente o dado é processado e armazenado, e isso está escrito em contrato ou só numa página do site? Uma afirmação de marketing não vale como cláusula.
- Quem, na prática, tem acesso operacional ao ambiente que guarda nosso dado, e sob qual aprovação? Se a resposta for vaga, o fornecedor provavelmente não sabe, ou não quer dizer.
- Existe uma trilha de auditoria que a nossa própria equipe consegue consultar, ou só o fornecedor tem acesso a esse registro? Um registro que só o fornecedor vê não serve para uma investigação interna.
- O que acontece com o dado quando o contrato termina, e isso é automático ou depende de alguém lembrar de pedir? Retenção sem prazo definido é risco acumulado silenciosamente.






