Nuvem soberana brasileira: o que devs sênior precisam avaliar

2>Por que o governo brasileiro quer construir a própria nuvem — e o que isso muda pra quem desenvolve

Quando li no Olhardigital.com.br que o governo federal está tocando um projeto de “nuvem brasileira” em parceria com o Serpro e empresas de capital majoritariamente nacional, minha primeira reação foi técnica, não política. E essa é a pergunta que todo dev sênior deveria fazer: isso resolve um problema real de soberania de dados, ou é só mais um projeto bilionário que vai sangrar dinheiro público?

Na minha experiência lidando com arquitetura cloud há mais de uma década, o debate de soberania raramente é sobre ideologia — é sobre jurisdição, auditoria e controle do código. E é exatamente esse o ponto que a ministra Esther Dweck tocou quando falou em “controle sobre o código, a operação e a jurisdição”. Vou destrinchar isso abaixo com olhos de quem realmente sobe servidor em produção.

O que é uma “nuvem soberana” do ponto de vista técnico

Não é marketing vazio. Uma nuvem soberana, na prática, precisa entregar quatro garantias:

• Jurisdição clara dos dados: onde os bytes físicos ficam armazenados e qual legislação se aplica em caso de conflito legal.
• Auditoria do código-fonte: você precisa conseguir inspecionar o que roda, não confiar cegamente em binários proprietários.
• Controle operacional: a infraestrutura crítica não pode estar sujeita a sanções externas ou descontinuidades unilaterais.
• Portabilidade real: você consegue sair sem reescrever tudo.

O projeto brasileiro cita explicitamente os três primeiros. O quarto — portabilidade — é onde historicamente projetos desse tipo tropeçam. Vou chegar lá.

Por que o Serpro é peça-chave (e o que isso significa na prática)

O Serpro já opera data centers Tier III em Brasília, São Paulo e Rio. Para quem nunca trabalhou com gov.br em escala, vale o contexto: Serpro hospeda sistemas como o e-CAC, CNPJ, e o próprio gov.br. Eles têm capacidade real, não é slide bonito de PowerPoint.

Mas há um problema que a matéria do Olhar Digital tangencia: capacidade de cloud privada é uma coisa; entregar serviços de IaaS, PaaS e SaaS no padrão AWS/Azure/GCP é outra completamente diferente. A ministra Dweck foi honesta ao admitir que “o país ainda tem poucas companhias com capacidade própria relevante em serviços de nuvem”. Isso é um understatement.

Construir um Kubernetes gerenciado, um object storage com 11 noves de durabilidade, um CDN global — isso leva anos de engenharia dedicada. Não se terceiriza.

As candidatas naturais e o que falta no ecossistema

A Magalu Cloud foi citada pela ministra, e faz sentido: é a única empresa brasileira com footprint público relevante em cloud pública — região em São Paulo, integração com MagaluPay, e tentativa séria de competir com hyperscalers. Testei a API deles em um side project e a latência de rede está ok, mas o portfólio de serviços ainda é limitado se comparado a um AWS.

Outras candidatas que provavelmente apareceram na audiência pública:

• UOL Diveo: capacidade técnica boa, mas em reestruturação societária.
• Globo / GloboCloud: infraestrutura interna robusta, mas nunca expôs isso como produto público.
• Locaweb: forte em hospedagem tradicional, mas com PaaS ainda imaturo.
• Startups: como a Logicalis Brasil e outras integradoras que poderiam entrar como parceiras, não operadoras.

O “porquê” por trás da decisão técnica

Existe um precedente internacional importante: o Gaia-X, na Europa. Começou como projeto visionário de nuvem soberana europeia e, cinco anos depois, virou basicamente um framework de compliance e interoperabilidade — não um hyperscaler. A França chegou mais longe com o Bleu e o S3NS (joint venture entre Thales e Google, com dados sob jurisdição francesa).

O Brasil, pelo que a ministra sinalizou, está indo pelo caminho da parceria público-privada. Na minha leitura, isso significa que o Serpro entra com data centers, compliance e governança, enquanto a iniciativa privada entra com a stack técnica. Modelo inteligente — evita reinventar a roda e ainda gera empregos locais.

Na Prática: o que muda no seu deploy se isso sair do papel

Vamos supor que você mantém um sistema que processa dados fiscais, de saúde ou de defesa. Hoje, o fluxo provável é:

1. Provisionar VM na AWS região São Paulo.
2. Configurar VPC, IAM, criptografia em repouso com KMS.
3. Subir aplicação via Terraform ou Kubernetes (EKS).
4. Configurar backups cruzando regiões (ex.: São Paulo → Virgínia).

Com uma nuvem soberana brasileira madura, o passo 4 provavelmente mudaria — dado sensível fica dentro da jurisdição nacional, com backup em outra região brasileira, sem cruzar fronteira. Isso simplifica compliance com a LGPD e reduz risco de exposição via FISA 702 e ordens judiciais americanas que podem atingir dados em providers dos EUA.

Exemplo prático em Terraform mostrando deploy em cloud soberana hipotética:

# terraform/main.tf
# Exemplo: deploy em cloud soberana brasileira
provider "serprocloud" {
  region     = "br-spo-1"
  api_key    = var.serpro_api_key
  cert_path  = "./certs/icp-brasil.pfx"
}

resource "serprocloud_object_bucket" "dados_fiscais" {
  name         = "dados-fiscais-producao"
  region       = "br-spo-1"
  replication  = "br-rjo-1"  # backup em região secundária BR
  encryption   = "AES-256-SOVEREIGN"  # chave gerenciada dentro do país
  audit_log    = true  # obrigatório para compliance gov
}

resource "serprocloud_kubernetes_cluster" "app_fiscal" {
  name        = "cluster-fiscal-prod"
  version     = "1.29"
  node_pools = [{
    name       = "general-purpose"
    size       = "medium"
    replicas   = 3
    gpu        = false
    encrypted  = true
  }]

  network_policy = "strict"
  egress_restriction = "allowlist"
}

output "endpoint_api" {
  value = serprocloud_kubernetes_cluster.app_fiscal.endpoint
}

Repare nos detalhes que mudam do padrão AWS/GCP: encryption = "AES-256-SOVEREIGN" indica chave nacional, egress_restriction = "allowlist" impede exfiltração acidental, e audit_log é nativo, não um patch.

Erros Comuns que devs cometem em projetos de soberania

Já vi muita empresa e muito órgão público tropeçando nos mesmos pontos:

• Confundir “datacenter no Brasil” com “cloud soberana”. Um provedor pode ter data center em São Paulo, mas o código, as atualizações, o billing e o suporte rodarem nos EUA. Isso não é soberania, é cosmética.
• Subestimar vendor lock-in. Se a API for proprietária e fechada, você troca de tirano, não de problema. Exija suporte a padrões abertos (Terraform, Kubernetes, S3-compatible).
• Ignorar o fator humano. Contratar engenheiros SRE/DevOps no Brasil custa caro — e ninguém fala disso. Um plano de 5 anos precisa incluir capacitação, não só datacenter.
• Esquecer do plano de saída. Toda migração para cloud soberana deveria começar com um plano de saída. Se você não consegue descrever como sai em 30 dias, não é soberania, é prisão.
• Achar que compliance resolve segurança. LGPD-compliant não é o mesmo que seguro. São camadas diferentes.

O que um dev deveria observar antes de aderir

Quando (e se) essa nuvem sair do papel, não saia correndo pra migrar. Na minha experiência, eu avalio assim:

1. API compatível com ecossistema aberto? Se exigir SDK proprietário fechado, fuja.
2. Tem mercado secundário de profissionais? Se só 50 pessoas no Brasil conhecem a plataforma, é um risco operacional.
3. Documentação é tão boa quanto a AWS? AWS tem gaps, mas ninguém chega perto. Se a doc for pior que a GCP, desconfie.
4. Tem suporte 24/7 com SLA claro? Sem SLA assinado, sem contrato sério.
5. Como é o pricing? Custo 30% acima do mercado é aceitável para soberania. 200% acima é roubo.

FAQ — Perguntas que um dev realmente faz

1. A nuvem soberana brasileira vai substituir AWS e Azure?

Não. E nem precisa. O objetivo real é ter uma alternativa nacional para cargas estratégicas — saúde, defesa, fiscal, dados pessoais sensíveis. Para o resto (CDN, machine learning em escala, big data), hyperscalers continuam sendo a melhor opção.

2. Vai sair mais barato que AWS?

Improvável no curto prazo. AWS, Azure e GCP operam em escala global com décadas de otimização. Espere um premium de 20-50% para começar, caindo conforme a maturidade aumenta — se aumentar.

3. Isso é só política ou tem chance real de dar certo?

Tem chance real, mas depende de continuidade administrativa. Projetos de infraestrutura cloud levam 5-10 anos. Se mudar o governo e mudar a prioridade, morre. É o que aconteceu com vários projetos anteriores no Serpro e na Dataprev.

4. Como isso afeta a LGPD na prática?

Facilita o compliance em alguns pontos (transferência internacional, base legal de execução por terceiros), mas não substitui as outras 14 obrigações da lei. Cuidado com marketing de “LGPD automática” — não existe isso.

5. Posso já preparar meu código pra essa realidade?

Sim. Use padrões abertos, evite SDKs proprietários demais, mantenha sua infraestrutura como código em Terraform ou Pulumi, e documente dependências externas. Quando a oferta existir, migrar leva semanas, não meses.

Minha opinião direta

O projeto faz sentido técnico, não apenas político. Brasil tem empresas capazes, tem demanda regulatória (LGPD), tem histórico de Serpro operando infra crítica. Mas o histórico recente de grandes projetos de TI governamentais no Brasil é desastroso — dos auxílios do COVID ao DNIT, da Dataprev ao CNJ. Quem programa sabe que a distância entre um slide bonito e um sistema em produção estável é medida em anos, em burnout, em incidentes.

A audiência pública com 59 empresas mostra interesse do mercado. A presença da Magalu Cloud na mesa é boa notícia — significa que pelo menos uma operadora nacional tem tração real. O resto é execução. E execução, no Brasil, é a parte que historicamente falha.

Vou acompanhar de perto. Quando houver um MVP público, pretendo subir um cluster de teste e publicar o que descobri — inclusive o que não funciona.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto. Se você trabalha com cloud soberana, SRE ou tem experiência em projetos do Serpro, sua visão vai enriquecer a discussão.