O guia do desenvolvedor europeu sobre APIs de mapas em conformidade com o RGPD

Você escolheu um centro de dados baseado na UE para sua API de mapas. Os servidores estão em Frankfurt. O contrato diz "residência de dados na UE". Você fecha a lista de verificação de conformidade com o RGPD com a confiança de que está protegido.

Você não está protegido.

Esta é a lacuna de conformidade que pega desenvolvedores e CTOs da UE de surpresa todos os anos, e tornou-se mais consequente desde que a decisão Schrems II invalidou o Privacy Shield e colocou maior escrutínio nos fluxos de dados transatlânticos. Se sua API de mapas é fornecida por uma empresa americana, independentemente de onde seus servidores estejam, os dados de localização dos seus usuários podem ser acessíveis ao governo dos EUA sob o CLOUD Act. Sob o RGPD, isso é uma potencial violação. Em uma auditoria de DPA, é uma constatação.

Este guia explica os requisitos reais do RGPD para uso de API de mapas, por que a residência de dados sozinha não é suficiente, o que o risco do CLOUD Act significa na prática e como avaliar qualquer fornecedor de API de mapas em relação a uma lista de verificação de conformidade rigorosa. É o guia que empresas de mapeamento baseadas nos EUA não podem escrever credalmente, porque não conseguem passar na própria lista de verificação.

Por Que os Dados de Localização Exigem Atenção Séria ao RGPD

Os dados de localização estão na interseção de dados pessoais e dados sensíveis sob o RGPD, dependendo do contexto. O Artigo 4(1) define dados pessoais como qualquer informação relativa a uma pessoa natural identificada ou identificável. Um endereço IP, que toda solicitação de tile de mapa envia ao fornecedor da API, é dado pessoal. Uma consulta de geocodificação contendo um endereço residencial é dado pessoal. Coordenadas GPS, se coletadas, podem ser usadas para inferir endereço residencial, local de trabalho, frequência religiosa, consultas médicas e atividade política, podendo se qualificar como dados sensíveis sob o Artigo 9.

Quando seu aplicativo web ou móvel carrega um mapa, dispara uma busca de geocodificação ou calcula uma rota, ele envia esses pontos de dados ao seu provedor de API de mapas. Seus usuários não consentiram em compartilhar sua localização com uma empresa em San Francisco. Consentiram em usar seu produto. Você, como controlador de dados, é responsável por garantir que todo subprocessador que trate esses dados atenda aos requisitos do RGPD.

Se seu provedor de API de mapas falha no teste de conformidade, você também falha.

O Problema do CLOUD Act: Por Que Fornecedores Americanos Não Podem Alegar Conformidade Total com o RGPD

O CLOUD Act (Clarifying Lawful Overseas Use of Data), aprovado pelo Congresso dos EUA em 2018, exige que empresas de tecnologia americanas cumpram ordens legais do governo dos EUA para produzir dados, independentemente de onde esses dados estejam fisicamente armazenados. Uma empresa americana com servidor em Frankfurt ainda é uma empresa americana. Se um tribunal ou agência federal americana emite uma demanda válida do CLOUD Act, a empresa deve cumprir.

Isso cria um conflito direto com o RGPD. O Artigo 48 do RGPD proíbe a transferência de dados pessoais para autoridades ou tribunais estrangeiros sem uma base jurídica adequada sob a lei da UE. O Comitê Europeu de Proteção de Dados foi explícito: cumprir uma demanda do CLOUD Act, sem uma base jurídica válida da UE, constituiria uma violação do RGPD.

A consequência prática para desenvolvedores da UE é clara:

• Google Maps Platform, operado pelo Google LLC (uma empresa americana), está sujeito às obrigações do CLOUD Act mesmo quando serve solicitações por centros de dados europeus.
• Mapbox, incorporado nos Estados Unidos, enfrenta a mesma exposição estrutural.
• Nenhuma linguagem contratual ou Cláusulas Contratuais Padrão da UE muda a jurisdição legal subjacente da empresa que fornece o serviço.

Isso não significa que essas empresas compartilham seus dados de forma irresponsável. Na prática, as demandas do CLOUD Act são direcionadas a casos de uso de aplicação da lei, não a dados comerciais de rotina. Mas a exposição legal existe, e uma auditoria séria de DPA a identificará. Setores regulamentados, saúde, finanças, serviços jurídicos, não podem aceitar essa exposição de forma alguma.

Residência de Dados vs. Soberania de Dados: Entendendo a Diferença

Esses termos são frequentemente usados de forma intercambiável em conversas de vendas, mas significam coisas diferentes:

Residência de dados significa que seus dados estão armazenados em uma localização geográfica específica. Um provedor americano que oferece "residência de dados na UE" armazena dados em servidores na Irlanda ou Alemanha. A localização física é na UE. A jurisdição legal não é.

Soberania de dados significa que seus dados estão sujeitos às leis de uma jurisdição específica. Para que os dados da UE sejam verdadeiramente soberanos, eles devem ser controlados por uma entidade sujeita à lei da UE, não apenas armazenados em solo da UE por uma empresa-mãe americana.

A verdadeira conformidade com o RGPD para APIs de mapas requer soberania de dados, não apenas residência de dados. A distinção importa mais quando:

• Seu aplicativo trata dados de pacientes de saúde, usuários de serviços financeiros ou outras categorias regulamentadas
• Você opera em um setor que enfrenta auditorias formais de DPA (bancário, seguros, setor público)
• Seu CISO ou equipe jurídica revisa acordos de subprocessadores com escrutínio real
• Você enfrenta uma solicitação de acesso de titular de dados ou uma obrigação de notificação de violação

Para a maioria dos aplicativos voltados para o consumidor, o risco prático de uma demanda do CLOUD Act é baixo. Mas conformidade não é um cálculo de probabilidade. Ou você está em conformidade ou não está.

A Lista de Verificação Prática do RGPD para Avaliar Fornecedores de API de Mapas

Use esta lista de verificação ao avaliar qualquer fornecedor de API de mapas para conformidade com o RGPD:

Entidade Legal e Jurisdição

• O fornecedor de API está incorporado como entidade legal na UE ou EEA?
• A empresa-mãe (se houver) também está dentro da jurisdição da UE, sem empresa-mãe incorporada nos EUA?
• O fornecedor confirma explicitamente nenhuma exposição ao CLOUD Act em seu DPA?

Acordo de Processamento de Dados

• O fornecedor oferece um DPA abrangente que referencia artigos específicos do RGPD?
• O DPA identifica as categorias de dados pessoais processados (endereços IP, strings de consulta, coordenadas)?
• O DPA especifica períodos de retenção de dados e obrigações de exclusão?
• Os subprocessadores estão listados, e também são entidades da jurisdição da UE?
• O DPA aborda prazos de notificação de violação (o RGPD exige 72 horas)?

Armazenamento e Processamento de Dados

• Todos os dados são armazenados e processados dentro da UE, com transferências documentadas para terceiros países?
• A transferência de dados entre serviços (CDN, análises, ferramentas de suporte) está documentada e em conformidade com o RGPD?
• O fornecedor oferece seleção de residência de dados no nível da conta?

Certificações de Segurança

• O fornecedor possui certificação ISO 27001 (o padrão internacional para gerenciamento de segurança da informação)?
• O fornecedor passa por auditorias de segurança regulares de terceiros?
• Existe um processo documentado de divulgação de vulnerabilidades e gerenciamento de patches?

Direitos do Usuário e Controle

• Você pode configurar a API para minimizar a coleta de dados (por exemplo, IP anonimizado, sem rastreamento analítico)?
• O fornecedor suporta solicitações de acesso de titulares de dados e solicitações de exclusão?
• Existem processos documentados para responder a consultas regulatórias de DPAs da UE?

MapAtlas: Construído para Soberania de Dados da UE desde o Início

O MapAtlas é uma plataforma europeia de API de mapas, operada pela MapMetrics, uma empresa incorporada na UE. Nossa infraestrutura funciona dentro da jurisdição da UE sem empresa-mãe americana e sem exposição ao CLOUD Act. A certificação ISO 27001 está em vigor, e nosso DPA documenta categorias específicas de dados, políticas de retenção e compromissos de subprocessadores.

Isso não é uma empresa americana que adicionou opções de centros de dados na UE. É uma empresa da UE onde a conformidade com a UE é a arquitetura padrão, não um complemento.

Nossa API de visualização e estilização de mapas processa solicitações de tiles por infraestrutura da UE. Consultas de geocodificação, cálculos de rota e todas as outras chamadas de API permanecem dentro da jurisdição da UE desde o momento em que saem do seu aplicativo. O DPA reflete isso, não é um boilerplate adaptado de um modelo jurídico americano.

Para desenvolvedores que criam aplicativos em setores regulamentados, ou para qualquer empresa da UE que deseja conformidade genuína em vez de conformidade performática, essa distinção é relevante.

Comparando Fornecedores de API de Mapas na Conformidade com o RGPD

Para uma comparação completa de preços e funcionalidades, consulte nossos detalhamentos de MapAtlas vs. Google Maps. Se o custo também é uma preocupação, veja os preços da API do Google Maps em 2026, a lacuna de conformidade vem além de diferenças significativas de preço.

Etapas Práticas para Desenvolvedores da UE Agora

Se você está usando atualmente um fornecedor de API de mapas americano e não pode fazer a migração imediatamente, aqui estão etapas intermediárias para reduzir sua exposição:

1. Anonimize endereços IP antes que saiam da sua origem. Algumas APIs de mapas permitem que você passe solicitações pelo seu próprio servidor, removendo ou hasheando endereços IP antes que cheguem à API de terceiros. Isso não resolve totalmente o problema do CLOUD Act, mas reduz a superfície de dados pessoais.

2. Faça uma auditoria do que sua API de mapas realmente coleta. Leia cuidadosamente a política de privacidade e o DPA do fornecedor. Identifique cada categoria de dados pessoais que eles recebem dos seus usuários. Documente isso no seu próprio registro de mapeamento de dados.

3. Atualize seu aviso de privacidade. Seu aviso de privacidade deve divulgar subprocessadores que recebem dados pessoais. Se você usa o Google Maps, o Google LLC é um subprocessador. Seus usuários têm direito de saber isso.

4. Avalie o nível de risco do seu caso de uso. Um site de marketing exibindo um mapa estático de localização do escritório tem um perfil de risco muito diferente de um aplicativo de saúde roteando pacientes para clínicas. Calibre sua urgência adequadamente.

5. Avalie os custos de migração de forma realista. Trocar de APIs de mapas é uma tarefa técnica, não um projeto de transformação de negócios. A maioria das migrações é concluída em um ou dois sprints. Nossa página de preços mostra a comparação de custos, e nossa documentação cobre o caminho de migração técnica do Google Maps e Mapbox.

O quadro de proteção de dados da UE é o mais abrangente do mundo, e está sendo ativamente aplicado, 1,3 bilhão de euros em multas de RGPD foram emitidos apenas em 2023. Dados de localização são dados pessoais. APIs de mapas processam dados de localização. A cadeia de conformidade vai diretamente dos seus usuários ao seu provedor de API. Verifique cada elo dessa cadeia. E se um elo não conseguir passar na lista de verificação acima, substitua-o por um que consiga.