Desde março de 2026, o Estatuto da Criança e do Adolescente Digital exige que qualquer aplicativo acessível a menores de 18 anos no Brasil adote proteções de privacidade específicas por padrão, e a Autoridade Nacional de Proteção de Dados (ANPD) abriu 19 novos processos sancionadores só em junho daquele ano. Na União Europeia, o Comitê Europeu de Proteção de Dados já não avalia aplicativos pela aparência da tela de consentimento, mas por uma pergunta técnica: os SDKs realmente param de transmitir dados quando o usuário recusa? Em 2024, a Procuradoria-Geral da Califórnia cobrou US$ 500 mil da desenvolvedora de jogos Tilting Point Media por SDKs mal configurados que seguiam enviando dados de crianças mesmo quando a interface de consentimento registrava recusa (Departamento de Justiça da Califórnia, 2024). Conformidade de privacidade em apps móveis não é mais um problema jurídico com um detalhe técnico. É um problema de arquitetura de software com consequência jurídica, e essa consequência muda de acordo com o país do usuário.
Principais Pontos
- GDPR (União Europeia, inclusive Portugal) e LGPD (Brasil) são leis distintas, com bases legais, prazos e multas diferentes. Nenhuma das duas substitui a outra, e um app que atende usuários dos dois blocos precisa cumprir as duas ao mesmo tempo, não uma versão combinada.
- Regras de plataforma como o App Tracking Transparency (ATT) da Apple e a seção Data Safety do Google Play valem para qualquer app, em qualquer país, independentemente de qual lei de privacidade se aplica ao usuário.
- SDKs de terceiros não podem inicializar antes da resolução do consentimento. Um banner que registra "recusado" enquanto o rastreador continua rodando é uma violação regulatória, não um detalhe de design.
- No Brasil, a LGPD prevê multa de até 2% do faturamento local, limitada a R$ 50 milhões por infração (Art. 52), mas o valor efetivamente cobrado até hoje pela ANPD é bem menor. A escala de risco real está mudando com a nova fase de fiscalização.
O Que Realmente Exige a Conformidade de Privacidade em Apps
Conformidade de privacidade em apps é o conjunto de obrigações legais, técnicas e operacionais que regem como um aplicativo móvel coleta, processa, armazena, compartilha e elimina dados pessoais. O escopo é mais amplo do que a maioria das equipes de produto assume: cobre cada SDK integrado ao app, cada evento de analytics enviado a um servidor terceiro, cada permissão solicitada em tempo de execução e cada fluxo de dados entre o app e os sistemas de backend ou operadores.
Três princípios atravessam praticamente todas as leis de privacidade relevantes para apps. Consentimento e transparência significam que o usuário precisa ser genuinamente informado sobre o que é coletado e por quê, com um meio real de controlar isso. Minimização de dados significa coletar apenas o que é necessário para a finalidade declarada, não o que pode ser útil depois. Segurança significa proteger os dados coletados durante todo o ciclo de vida deles, inclusive dentro de SDKs de terceiros que operam dentro do aplicativo.
O princípio da responsabilização do controlador agrava essas obrigações para quem publica o app. Tanto o GDPR quanto a LGPD tratam o publicador como o responsável (controlador, ou "agente de tratamento" na LGPD) por todo o tratamento de dados pessoais que ocorre dentro do aplicativo, incluindo o que é feito por bibliotecas de SDK que a empresa não escreveu. Um SDK de relatório de falhas que extrai identificadores de dispositivo, um SDK de publicidade que coleta dados comportamentais antes do consentimento, um SDK de login social que acessa a lista de contatos sem necessidade: todos esses casos são falha de conformidade do publicador, não do fornecedor do SDK. Não é possível terceirizar essa responsabilidade por contrato.
Três Regimes Que Não Se Confundem: GDPR, LGPD e Regras de Plataforma
A confusão mais comum entre equipes que lançam apps para o mercado brasileiro e o europeu ao mesmo tempo é tratar GDPR e LGPD como praticamente a mesma lei com nomes diferentes. Elas compartilham inspiração e princípios, mas divergem em pontos que têm efeito prático direto: bases legais, prazos de resposta, exigência de encarregado de dados e estrutura de multas. Regras de plataforma como o ATT da Apple e a Data Safety do Google Play formam uma terceira camada, que não depende de onde o usuário está: valem para o app em qualquer loja, em qualquer país.
| Aspecto | GDPR (União Europeia e Portugal) | LGPD (Brasil) | Regras de Plataforma (Apple e Google) |
|---|---|---|---|
| A quem se aplica | Qualquer app que trate dados pessoais de pessoas na UE/EEE, inclusive Portugal, não importa onde a empresa esteja sediada | Qualquer app que trate dados de pessoas no Brasil ou dados coletados no Brasil, não importa onde a empresa esteja sediada | Qualquer app publicado na App Store ou na Play Store, independentemente do país do usuário ou da lei aplicável |
| Base legal para rastreamento não essencial | Consentimento explícito exigido pela Diretiva ePrivacy para acesso ao dispositivo (Art. 5(3)) | Consentimento como uma das dez bases do Art. 7º da LGPD, exigido para a maioria dos rastreadores de publicidade e analytics | Não define base legal; exige apenas que o app declare e obtenha a permissão da plataforma (ATT) ou declare a prática (Data Safety) |
| Prazo de resposta ao titular | 30 dias corridos, prorrogável por mais 60 em casos complexos | 15 dias corridos para resposta detalhada (Art. 18), metade do prazo europeu | Não se aplica; não é uma obrigação de direito do titular |
| Multa máxima | Até 20 milhões de euros ou 4% do faturamento global anual, o que for maior | Até 2% do faturamento no Brasil por infração, limitado a R$ 50 milhões (Art. 52) | Rejeição, remoção ou suspensão do app na loja; não é multa monetária |
| Vale independentemente da jurisdição do usuário? | Não. Aplica-se apenas a usuários na UE/EEE | Não. Aplica-se apenas a usuários no Brasil ou dados coletados no Brasil | Sim. Vale para todo app na loja, não importa o país do usuário |
Um app pode estar plenamente em conformidade com o GDPR e ainda assim violar a LGPD, ou vice-versa, porque as duas leis avaliam consentimento, prazo e risco de forma diferente. Já as regras de plataforma são a única camada comum às duas: um app que atende usuários portugueses e brasileiros precisa satisfazer GDPR, LGPD, ATT e Data Safety ao mesmo tempo, não uma combinação simplificada das quatro.
Quando o GDPR Se Aplica ao Seu App (Portugal e Toda a União Europeia)
Para uma equipe sediada em Portugal ou que atende usuários portugueses, o GDPR é a lei diretamente aplicável, sem necessidade de nenhum teste adicional de território: Portugal é Estado-membro da UE, e o regulamento tem aplicação direta. O mesmo vale para qualquer app, esteja a empresa onde estiver, que processe dados pessoais de pessoas na UE ou no Espaço Econômico Europeu. Os detalhes de quem exatamente precisa cumprir o GDPR e o que a lei cobre já estão descritos em o que é GDPR e em a quem se aplica o GDPR; vale revisar esses dois artigos antes de avançar para a parte específica de apps.
A camada que mais pega desenvolvedores de aplicativos de surpresa é a Diretiva ePrivacy, que se soma ao GDPR para qualquer tecnologia que leia ou grave informações no dispositivo do usuário, incluindo identificadores de publicidade e técnicas de fingerprinting. Isso significa que SDKs de analytics, redes de publicidade, plataformas de atribuição e SDKs sociais exigem consentimento prévio no contexto europeu. Não existe uma alternativa de "interesse legítimo" para tecnologias de rastreamento sob a ePrivacy: sem consentimento explícito, não há base legal.
Se o mesmo app também atende usuários no Brasil, o cumprimento do GDPR não resolve a parte brasileira automaticamente. As duas leis compartilham a lógica de proteção ao titular, mas divergem exatamente nos pontos que geram risco de conformidade quando alguém assume equivalência total, como mostra a tabela anterior.
Quando a LGPD Se Aplica ao Seu App (Brasil e Qualquer App Que Trate Dados de Brasileiros)
A LGPD (Lei nº 13.709/2018) tem alcance extraterritorial no mesmo espírito do GDPR: aplica-se a qualquer tratamento de dados pessoais realizado no Brasil, direcionado a pessoas no Brasil, ou que envolva dados coletados no Brasil, independentemente de onde a empresa que publica o app esteja sediada. Um app desenvolvido nos Estados Unidos ou em Portugal, mas com uma base relevante de usuários brasileiros, está sujeito à LGPD por esse critério, não pelo endereço do desenvolvedor.
A exigência de nomear um encarregado de dados recai sobre a maioria dos controladores, mas não é idêntica à exigência de Data Protection Officer do GDPR: agentes de pequeno porte, com receita anual de até R$ 4,8 milhões, têm dispensa condicional dessa obrigação, exceto quando fazem tratamento de alto risco, como dados de crianças ou uso de dados para treinar modelos de inteligência artificial. Quem quiser entender a fundo quando essa exigência se aplica e quais são as atribuições do cargo deve consultar o que é um DPO (encarregado de dados) e quando sua empresa precisa de um, já que os critérios de isenção e as funções do cargo não mudam por o tratamento acontecer dentro de um app em vez de um site.
A fiscalização da LGPD sobre apps mudou de patamar em 2026. A Lei nº 15.352/2026 transformou a ANPD em agência reguladora de regime especial, com poder de polícia administrativa e verba própria, e a autoridade abriu 19 processos sancionadores de uma só vez em junho, o maior lote de sua história. Desde março de 2026, o Estatuto da Criança e do Adolescente Digital impõe obrigações específicas a qualquer plataforma, incluindo apps de jogos, redes sociais, streaming e educação, que possa ser acessada por menores de 18 anos, com privacidade por padrão e verificação de idade entre os pontos fiscalizados. A multa máxima continua sendo de até 2% do faturamento da empresa no Brasil, limitada a R$ 50 milhões por infração (Art. 52), mas o histórico real de cobrança é mais modesto do que esse teto sugere: até agora, o único valor efetivamente pago é o da Telekall Infoservice, R$ 14.400 em 2023. A ANPD tem preferido suspensões cautelares em casos de alto risco, como as determinadas contra a Meta e a X Corp em 2024 por uso de dados de usuários brasileiros para treinar modelos de IA, sem multa monetária confirmada em nenhum dos dois casos. Isso não deve ser lido como sinal de baixo risco: o volume de fiscalização está crescendo, não recuando. Os detalhes completos desse histórico e o roteiro de conformidade estão em LGPD 2026: guia completo de conformidade e fiscalização, e os conceitos básicos da lei em o que é LGPD.
Regras da Apple e do Google: Válidas em Qualquer Lugar
iOS e Android impõem camadas próprias de exigência que não substituem GDPR ou LGPD e não dependem de qual das duas leis se aplica ao usuário. O framework App Tracking Transparency (ATT) da Apple, em vigor desde o iOS 14.5 em 2021, exige um prompt explícito do sistema antes que qualquer app acesse o IDFA, o identificador de publicidade usado para rastreamento entre apps. O ATT não substitui o consentimento do GDPR nem da LGPD: é uma permissão de plataforma separada, que opera em paralelo. Para um usuário na União Europeia, a sequência correta é consentimento GDPR primeiro, depois ATT, estabelecendo a base legal antes de solicitar a permissão da plataforma; apresentar o ATT antes do consentimento GDPR produz um registro que não sustenta sozinho a base legal exigida pelo regulamento europeu.
Os Privacy Manifests da Apple, obrigatórios para SDKs de terceiros desde maio de 2024, são declarações que documentam o uso de dados e o acesso a APIs de cada SDK, revisadas pela Apple no envio à App Store; divergências entre a prática declarada e o comportamento real do SDK acionam rejeição. Do lado do Google, o Consent Mode v2, obrigatório desde março de 2024 para personalização de anúncios com tráfego do Espaço Econômico Europeu, comunica quatro sinais de privacidade (analytics_storage, ad_storage, ad_user_data e ad_personalization) que precisam refletir a escolha real do usuário antes de qualquer SDK do Google inicializar. A seção Data Safety da Play Store exige o mesmo nível de precisão que o rótulo de privacidade da Apple: categorias de dados coletados, compartilhamento com terceiros e possibilidade de exclusão.
| Requisito | iOS (Apple) | Android (Google) |
|---|---|---|
| Permissão para rastreamento entre apps | Prompt do App Tracking Transparency antes do acesso ao IDFA, desde o iOS 14.5 | Consent Mode v2 com quatro sinais de privacidade, obrigatório desde março de 2024 para tráfego do EEE |
| Rótulo de privacidade na loja | Privacy Nutrition Label na página do app, cruzada com o Privacy Manifest de cada SDK | Seção Data Safety, com categorias de dados coletados e prática de compartilhamento |
| Documentação de SDKs de terceiros | Privacy Manifest obrigatório desde maio de 2024, revisado no envio à App Store | Sem exigência equivalente de manifesto formal; a responsabilidade recai sobre a declaração do publicador |
| Exclusão de conta pelo usuário | Obrigatória dentro do app desde 30 de junho de 2022, para qualquer app que permita criação de conta | Exigida pela política de dados do usuário, mas sem prazo de implementação tão específico quanto o da Apple |
Como Funciona o Bloqueio de Consentimento na Prática
O ponto mais consequente da conformidade técnica é o bloqueio de consentimento: a exigência arquitetural de que SDKs não essenciais não inicializem antes de o estado de consentimento do usuário estar resolvido. É essa etapa que separa apps genuinamente conformes de apps que só parecem conformes.
Na abertura do app, o SDK de consentimento inicializa primeiro e verifica se já existe um registro de consentimento válido, não expirado e correspondente à versão atual da lista de fornecedores. Se não existir, o app apresenta a interface de consentimento antes de qualquer outro processamento, com opções de aceitar tudo e recusar tudo em igual destaque visual, granularidade por finalidade (analytics, publicidade, funcional) e descrições em linguagem simples. Só depois da resposta do usuário o app inicializa os SDKs não essenciais, e apenas os que correspondem às categorias autorizadas.
O registro de consentimento precisa ser imutável e ficar armazenado tanto localmente quanto em um backend remoto: o armazenamento local evita a condição de corrida em que um SDK inicializa antes de o estado salvo ser carregado, e a sincronização remota cria a trilha de auditoria que reguladores exigem. Cada atualização de preferência deve ser adicionada como um novo evento, sem sobrescrever o anterior, com data, hora, versão da política de privacidade e método de captura. Manter esse histórico organizado por planilha deixa de ser viável a partir de um certo volume de instalações; um registro de consentimento auditável e exportável automaticamente é o tipo de evidência que tanto a ANPD quanto uma autoridade de proteção de dados europeia pedem primeiro numa fiscalização.
Minimização de Dados, Retenção e Auditoria de SDKs
Gestão de consentimento é a exigência mais visível, mas minimização de dados e retenção são igualmente importantes e mais frequentemente negligenciadas. Cada campo de dado coletado, cada permissão solicitada, cada SDK integrado deveria ser justificado por uma finalidade específica e declarada. Pedir a data de nascimento do usuário quando só o endereço de entrega é necessário é uma violação de minimização; solicitar localização precisa quando a granularidade de cidade já atende à funcionalidade é outra. Essas decisões acontecem na fase de design do produto, não na revisão de conformidade depois que o app já está pronto.
Prazos de retenção precisam existir para cada categoria de dado, documentados de forma que possam ser apresentados numa fiscalização. Dados de conta devem ser retidos pelo período da relação contratual mais um prazo pós-encerramento documentado; eventos de analytics, por um período vinculado à finalidade declarada; dados sob consentimento retirado devem ser apagados, e essa exclusão precisa acontecer de fato em todos os sistemas, não só no banco de dados do próprio app, mas também em plataformas de analytics, fornecedores de atribuição e qualquer operador cujo contrato rege esses dados.
Auditar SDKs de terceiros contra a prática declarada por eles, e verificar por análise de tráfego de rede (não apenas pela documentação do fornecedor) que o SDK realmente para de transmitir dados quando o usuário recusa, é o ponto mais estruturalmente importante e menos consistentemente feito na conformidade de apps móveis.
Erros Mais Comuns Que Levam a Multas e Rejeições
Carregar SDKs antes da resolução do consentimento é a falha mais comum e mais grave. A assinatura de tráfego é inconfundível: um endpoint de analytics ou publicidade recebe uma requisição milissegundos após a abertura do app, antes mesmo de a interface de consentimento aparecer. Reguladores europeus e a própria ANPD têm ferramentas automatizadas para detectar esse padrão, e é o gatilho mais comum para investigações.
Consentimento condicionado, ou seja, um único botão de "aceitar tudo para continuar" que amarra a funcionalidade principal do app ao rastreamento, é um padrão enganoso que reguladores europeus visam ativamente: o GDPR exige que o consentimento para tratamento não essencial seja livremente dado, o que implica que a funcionalidade principal precisa estar disponível para quem recusa o rastreamento.
Assumir que a permissão de plataforma substitui a conformidade regulatória é um erro estrutural recorrente. Um usuário que autoriza o ATT concedeu acesso ao IDFA sob o framework da Apple; isso não constitui consentimento válido para GDPR ou LGPD. As duas coisas são exigidas, na ordem certa, e sustentadas pela documentação legal apropriada.
Não atualizar o Privacy Nutrition Label e a seção Data Safety quando novos SDKs são integrados é cada vez mais arriscado, à medida que Apple e Google passam a verificar essas declarações de forma mais ativa. Uma divergência entre prática declarada e comportamento real do SDK é, ao mesmo tempo, violação de política de loja e potencial evidência numa investigação regulatória, seja pela ANPD, seja por uma autoridade europeia. Vale revisar os maiores casos de multa já aplicados sob o GDPR para ver como esse tipo de divergência já custou caro a outras empresas.
FAQ
O que torna um aplicativo compatível com o GDPR?
Bases legais documentadas para cada tipo de tratamento, consentimento obtido antes da inicialização de SDKs não essenciais, um aviso de privacidade alinhado à prática real do app, mecanismos funcionais de direitos do titular e contratos de tratamento de dados com todos os fornecedores de SDK. Para usuários na União Europeia e em Portugal, essas exigências valem independentemente de onde a empresa esteja sediada.
O que torna um aplicativo compatível com a LGPD?
Base legal documentada entre as dez hipóteses do Art. 7º, consentimento obtido antes de qualquer rastreamento não essencial para usuários no Brasil, canal de atendimento a titulares capaz de responder em 15 dias, notificação de incidente em até 3 dias úteis quando aplicável e, para a maioria das empresas, um encarregado de dados nomeado. Pequenos agentes com receita anual até R$ 4,8 milhões têm dispensa condicional dessa última exigência, exceto em tratamento de alto risco.
O ATT da Apple ou a permissão do Google substituem o consentimento do GDPR ou da LGPD?
Não. São permissões de plataforma que operam em paralelo às leis de privacidade, não em lugar delas. Um usuário que autoriza o ATT ou aceita uma configuração de anúncios do Google concedeu acesso técnico dentro daquele framework específico, não uma base legal válida para GDPR ou LGPD. As duas camadas precisam ser satisfeitas, sequenciadas corretamente e documentadas.
Meu app precisa cumprir GDPR e LGPD ao mesmo tempo?
Sim, se o app atende usuários na União Europeia e no Brasil simultaneamente. As duas leis não se substituem: cada uma se aplica pelo critério de onde o titular dos dados está, não pela sede da empresa. Implementar ao padrão mais rígido entre as duas para os elementos comuns, e complementar com controles específicos onde divergem (como prazo de resposta ou exigência de encarregado), costuma ser mais eficiente do que manter dois fluxos de consentimento totalmente separados.
Como funciona o consentimento em apps móveis na prática?
O SDK de consentimento inicializa primeiro na abertura do app. Se não houver um registro válido armazenado, a interface de consentimento aparece antes de qualquer outro processamento. A partir da resposta do usuário, apenas os SDKs autorizados por categoria são inicializados, e o registro correspondente é armazenado localmente e sincronizado com um backend, com timestamp e versão da política de privacidade.
Todo aplicativo precisa de um encarregado de dados (DPO)?
Não necessariamente. Na LGPD, agentes de pequeno porte com receita anual de até R$ 4,8 milhões têm dispensa condicional, exceto em tratamento de alto risco, como dados de crianças ou uso de dados para IA. No GDPR, a obrigação de nomear um encarregado depende de critérios como monitoramento sistemático em larga escala ou tratamento de categorias especiais de dados como atividade principal, não do simples fato de operar um app.
Conformidade de privacidade em apps móveis, em 2026, é uma disciplina de engenharia fiscalizada por reguladores que testam comportamento técnico, não documentos de política. Os apps que resistem ao escrutínio são os que têm o bloqueio de consentimento realmente funcionando, os fluxos de dados de SDK regidos por contratos documentados com cada fornecedor, e mudanças de preferência do usuário propagadas de imediato para cada sistema que toca dados pessoais.
Sustentar isso manualmente, em planilha, para GDPR, LGPD e as regras de cada loja de apps ao mesmo tempo, deixa de ser viável a partir de um certo volume de usuários. A Solução de Consentimento da Secure Privacy, com SDKs nativos para iOS, Android, React Native e Flutter, detecção automática de localização do visitante e fluxos de consentimento específicos por região, cuida da complexidade técnica de manter as três camadas (GDPR, LGPD e regras de plataforma) sincronizadas, para que a equipe possa focar em construir o app. Agende uma demonstração para ver como funciona na prática.
