Data residency: o que significa na prática garantir que dados ficam no Brasil

"Nossos dados ficam no Brasil" é uma das frases mais repetidas em contratos de tecnologia e mais raramente verificadas na prática. A afirmação parece objetiva — ou os servidores estão aqui ou estão em outro lugar. Mas o conceito de data residency é tecnicamente mais complexo do que a localização física de um datacenter, e a diferença entre o que os contratos garantem e o que acontece na infraestrutura é onde nascem a maioria dos problemas de compliance.

O que data residency realmente significa tecnicamente

Data residency tem três dimensões distintas que raramente são tratadas como separadas. A primeira é onde os dados estão armazenados em repouso — onde os arquivos, registros de banco de dados e objetos de storage fisicamente residem. A segunda é onde os dados são processados — servidores de aplicação que executam queries, transformações e análises podem estar em localidade diferente dos dados que manipulam. A terceira, frequentemente ignorada, é onde os metadados vivem — índices, logs de acesso, dados de configuração e registros de auditoria que descrevem os dados principais.

A maioria dos acordos de data residency cobre apenas a primeira dimensão. Uma empresa pode ter dados de produção armazenados na região Brasil Sul de um provedor de nuvem e, ao mesmo tempo, ter logs de acesso esses dados enviados automaticamente para uma região nos Estados Unidos, réplicas de leitura para performance criadas em outras regiões, ou pipelines de analytics que movem dados para processamento em infraestrutura global.

O processamento de dados é especialmente problemático. Quando um usuário no Brasil faz uma busca e a query é enviada para um motor de busca global distribuído, onde esse processamento ocorre? Quando um modelo de machine learning treinado nos Estados Unidos faz inferência sobre dados brasileiros, qual é a residência dos dados nesse momento? As respostas dependem da arquitetura específica de cada sistema e raramente estão explicitadas nos contratos de serviço padrão.

Como os grandes provedores de nuvem tratam o tema

A AWS oferece a região sa-east-1 em São Paulo desde 2011, com amplo catálogo de serviços disponíveis localmente. A promessa de data residency da AWS é que dados armazenados em uma região não são movidos para fora dela sem ação explícita do cliente. Isso cobre storage primário, banco de dados gerenciado e computação. O que não está automaticamente incluído: AWS CloudTrail logs podem ser configurados para enviar para regiões diferentes, suporte técnico da AWS pode ser realizado por engenheiros em outras regiões com acesso a ambientes de cliente, e serviços globais como AWS IAM e Route 53 têm infraestrutura de controle que não é regional.

A Microsoft com Azure Brazil South em São Paulo oferece garantias similares para os serviços principais, mas com um catálogo menor do que as regiões mais antigas — alguns serviços disponíveis nos Estados Unidos ou Europa não estão disponíveis na região brasileira, o que pode forçar arquiteturas híbridas que contradizem os requisitos de residência. A Oracle Cloud com região em Vinhedo, São Paulo, é uma opção relevante especialmente para cargas de trabalho Oracle Database com requisitos regulatórios.

O que todos os provedores têm em comum: backups geográficos são uma feature que frequentemente exige configuração explícita para permanecer dentro do país. A replicação automática para garantir durabilidade de dados pode por padrão distribuir cópias entre regiões em países diferentes. Verificar a configuração padrão de replicação antes de assumir que os dados estão contidos é responsabilidade do cliente.

As exceções que os contratos raramente mencionam

Acesso de suporte é a exceção mais significativa. Quando uma empresa abre um ticket de suporte técnico com AWS, Azure ou Google Cloud, o engenheiro que atende pode estar em qualquer lugar do mundo e pode requerer acesso ao ambiente do cliente para diagnosticar o problema. Provedores têm controles para limitar esse acesso, mas o padrão não é zero acesso. O AWS Nitro System e o Azure Customer Lockbox são exemplos de mecanismos que dão ao cliente controle sobre quando e por quem seu ambiente pode ser acessado — mas precisam ser habilitados e entendidos.

Logs de compliance e auditoria são outro ponto cego frequente. Ferramentas de SIEM (Security Information and Event Management) e plataformas de monitoramento que agregam logs de múltiplas regiões frequentemente têm sua infraestrutura de armazenamento em regiões onde o serviço é mais barato ou tem mais capacidade. O cliente configura o agente de coleta na região brasileira, mas os dados de log terminam armazenados em outro país.

Serviços de CDN e edge computing por definição distribuem dados próximos aos usuários globalmente. Se uma empresa usa CloudFront, Azure CDN ou Fastly para distribuir conteúdo, partes desse conteúdo — incluindo potencialmente dados de usuário em cache — podem temporariamente existir em servidores em outros países. Para a maioria dos tipos de dados isso é aceitável, mas para dados pessoais sensíveis requer análise específica.

O que perguntar para fornecedores antes de assinar

A due diligence de data residency com fornecedores começa com perguntas específicas, não com a confirmação de que "os dados ficam no Brasil". As perguntas que importam são: onde backups e réplicas são armazenados por padrão, e isso pode ser configurado para permanecer no Brasil? Quais regiões são usadas para processamento de dados de analytics e machine learning? Quais funcionários têm acesso técnico ao ambiente e de onde eles operam? Onde logs de auditoria são armazenados? Há serviços de suporte, ferramentas de diagnóstico ou pipelines de telemetria que enviam dados para infraestrutura fora do Brasil?

Fornecedores que não conseguem responder essas perguntas com precisão não têm data residency real — têm marketing de data residency. A distinção é importante porque impacta diretamente a capacidade de demonstrar compliance em caso de fiscalização pela ANPD ou por clientes que exijam comprovação.

A estratégia prática para quem precisa garantir residência real

O primeiro passo é um inventário de fluxo de dados — mapear onde cada categoria de dado vai depois que entra no ambiente. Não apenas onde é armazenado inicialmente, mas para onde flui através de integrações, replicações, pipelines de analytics e ferramentas de terceiros. Esse mapeamento frequentemente revela pontos de saída de dados que não foram considerados na arquitetura original.

O segundo passo é revisar as configurações padrão de cada serviço em uso. Provedores de nuvem geralmente permitem configurar residência de dados de forma granular, mas as configurações padrão são otimizadas para disponibilidade global, não para compliance local. A diferença entre o que o serviço pode fazer e o que está configurado para fazer é onde a maioria dos projetos de data residency falha.