Atualizado em 17 de agosto de 2026
Em setembro de 2024, a CNIL francesa multou a Voodoo, desenvolvedora de jogos mobile, em 3 milhões de euros e a Apple Distribution International em 8 milhões de euros pelo mesmo tipo de falha: identificadores de publicidade gravados no dispositivo do usuário sem consentimento válido, em um caso mesmo depois de o usuário ter recusado o rastreamento (CNIL, 2024). Nenhuma das duas empresas foi multada por não ter um banner de consentimento. As duas foram multadas porque o banner dizia uma coisa e o SDK fazia outra. Esse é o problema que este guia resolve: não a camada visível do consentimento em apps, já bem documentada, mas a camada de baixo, onde a base legal escolhida para cada finalidade de tratamento, o papel jurídico de cada SDK integrado e a arquitetura técnica do consentimento decidem se a empresa está de fato protegida ou apenas parece estar. Para quem opera no Brasil e também atende usuários europeus, a pergunta certa nunca é "isso é GDPR ou LGPD", porque as duas leis raramente coincidem exatamente onde mais importa.
Principais Pontos
- A CNIL mudou oficialmente, em setembro de 2024 e de novo em abril de 2025, a forma como qualifica juridicamente um fornecedor de SDK: por padrão, operador (processor), a menos que use os dados para finalidade própria, caso em que se torna controlador ou controlador conjunto (CNIL, 2024/2025). Essa reclassificação muda quem assina o quê em cada contrato de SDK.
- GDPR e LGPD divergem no prazo de notificação de incidente de segurança: até 72 horas corridas para a GDPR (Art. 33) contra até 3 dias úteis para a LGPD, conforme a Resolução CD/ANPD nº 15/2024. Não é o mesmo prazo com nomes diferentes: um conta em horas corridas, o outro em dias úteis.
- Mais de 92% dos aplicativos disponíveis nas lojas usam pelo menos um SDK de terceiro, e a maioria integra entre 6 e 10 (Market Growth Reports, 2026). Cada um desses SDKs carrega uma qualificação jurídica própria que precisa ser resolvida individualmente, não em bloco.
- A ANPD ainda não publicou nenhum capítulo específico sobre apps móveis dentro da sua orientação de Relatório de Impacto à Proteção de Dados Pessoais (RIPD); o app precisa se encaixar no framework genérico do Art. 38 da LGPD, o que deixa uma lacuna prática que a GDPR, com os nove critérios do antigo Grupo do Artigo 29 (WP248), preenche de forma mais explícita.
Por Que a Conformidade com Apps Móveis é Diferente da Conformidade com um Site
As diferenças estruturais entre conformidade web e conformidade em apps já foram mapeadas em detalhe no artigo sobre conformidade de privacidade em apps, GDPR, LGPD e as regras da Apple e do Google: responsabilidade distribuída entre publicador e cada fornecedor de SDK, identificadores de dispositivo persistentes que sobrevivem à reinstalação em alguns cenários, e uma camada de regras de loja que se soma à lei aplicável sem nunca substituí-la. Vale ler aquele artigo primeiro se esses três pontos ainda não estiverem claros.
O que falta nessa camada de superfície é o nível abaixo: qual base legal sustenta cada finalidade de tratamento dentro do app, qual é o papel jurídico real de cada SDK (não o que o contrato dele diz que é), e qual arquitetura de consentimento entrega, na prática, a garantia que o regulador está testando. É nesse nível que a maioria das equipes jurídicas e de produto para de conseguir responder com precisão, e é exatamente onde a CNIL, a EDPB e, cada vez mais, a ANPD estão concentrando a fiscalização.
Quando o GDPR Se Aplica, e Onde a LGPD Diverge no Mesmo Ponto
O teste de aplicabilidade territorial da GDPR (Art. 3º) não pergunta onde a empresa está sediada: pergunta se o tratamento está ligado ao oferecimento de bens ou serviços a pessoas na União Europeia, ou ao monitoramento do comportamento delas. Um app publicado por uma empresa brasileira que tem usuários checando o preço em euros, recebendo notificações em português europeu ou sendo rastreados por um SDK de atribuição com cobertura na UE já pode satisfazer esse teste, independentemente de a empresa nunca ter aberto um escritório na Europa.
A LGPD usa a mesma lógica extraterritorial no Art. 3º, mas com um critério ligeiramente diferente: tratamento realizado no Brasil, dados de pessoas localizadas no Brasil no momento da coleta, ou dados coletados no território nacional. Isso significa que uma empresa europeia com um app popular entre usuários brasileiros está sujeita à LGPD pelo mesmo tipo de gatilho, e as duas leis se aplicam de forma simultânea e independente quando o app atende os dois públicos ao mesmo tempo: cumprir uma não é um passo intermediário para cumprir a outra.
A diferença mais consequente para times jurídicos não é o teste de território, é a definição de quem carrega a responsabilidade primária. A GDPR distingue controller e processor pela determinação de finalidade e meios (Art. 4º, itens 7 e 8); a LGPD usa controlador e operador, com definição quase equivalente no Art. 5º, incisos VI e VII, mas com um terceiro papel que a GDPR não nomeia formalmente da mesma forma: o encarregado, cuja função e critério de dispensa para pequenos agentes (receita anual até R$ 4,8 milhões, sem tratamento de alto risco) já foi detalhado no artigo sobre o que é um DPO e quando sua empresa precisa de um. Para revisão dos conceitos básicos de cada lei, os artigos o que é GDPR, a quem se aplica o GDPR e o que é LGPD continuam sendo a referência correta; este guia assume esse conhecimento e vai direto ao ponto onde as duas leis param de ser intercambiáveis.
Bases Legais por Finalidade: o Mapeamento que a Maioria das Equipes Pula
O erro mais comum não é escolher a base legal errada. É escolher uma única base legal para o app inteiro, quando cada finalidade de tratamento dentro dele precisa da sua própria análise.
Funcionalidade essencial do app (autenticação, processamento de pagamento, entrega do serviço contratado): sustentada pela necessidade contratual, Art. 6º(1)(b) da GDPR e, no lado brasileiro, pela hipótese de execução de contrato do Art. 7º, inciso V, da LGPD. Essa é a única finalidade em que travar a funcionalidade principal atrás de uma tela de consentimento é desnecessário e, sob a GDPR, na verdade um sinal de consentimento mal desenhado: exigir aceitação de rastreamento para liberar a função central do app é o padrão de "consentimento condicionado" que a EDPB já identificou como inválido, porque o consentimento deixa de ser livre.
Analytics comportamental e SDKs de publicidade: aqui a base quase sempre precisa ser consentimento, não interesse legítimo. A Diretiva ePrivacy (Art. 5º(3)), que se soma à GDPR para qualquer tecnologia que leia ou grave informação no dispositivo, não reconhece interesse legítimo como alternativa para tecnologias de rastreamento; a base é consentimento explícito ou nada. No lado brasileiro, a mesma finalidade cai na hipótese de consentimento do Art. 7º, inciso I, da LGPD, e a ANPD tem se posicionado de forma crescentemente restritiva sobre o uso de interesse legítimo (Art. 7º, inciso IX) como base residual para rastreamento publicitário, exatamente na mesma direção da leitura europeia.
Prevenção a fraude e segurança da conta: uma das poucas finalidades em que o interesse legítimo genuinamente se sustenta dos dois lados, GDPR Art. 6º(1)(f) e LGPD Art. 7º(IX), desde que o app documente o teste de balanceamento (necessidade, proporcionalidade, expectativa razoável do titular) e não use o mesmo dado para outra finalidade sem uma nova análise.
Dados de crianças e adolescentes: a base muda de novo. Sob a GDPR, processar dados de menores para serviços de sociedade da informação normalmente exige consentimento parental verificável abaixo da idade nacional de consentimento digital (13 a 16 anos, dependendo do Estado-membro). No Brasil, o Art. 14 da LGPD exige consentimento específico e destacado de ao menos um dos pais ou responsável legal para qualquer tratamento de dados de crianças, sem a variação por idade que existe na Europa, e o Estatuto da Criança e do Adolescente Digital, em vigor desde março de 2026, acrescenta a exigência de privacidade por padrão e mecanismos de verificação de idade para qualquer app potencialmente acessível a esse público, com a ANPD já monitorando lojas de aplicativos e sistemas operacionais quanto a isso.
Tratar essas quatro finalidades sob uma única base legal "genérica" é a causa raiz de boa parte das notificações de não conformidade que a CNIL e a ANPD abrem: quando a base legal registrada não corresponde à finalidade real do tratamento, a defesa jurídica cai antes mesmo de chegar à parte técnica.
Quem é Controlador, Quem é Operador: o Novo Padrão da CNIL para SDKs
Até 2024, a prática de mercado era simples e, segundo a CNIL, simples demais: o contrato do SDK dizia "processor" (operador) e a maioria dos publicadores de app aceitava isso sem verificar. A recomendação da CNIL sobre aplicativos móveis, publicada em setembro de 2024 e corrigida em abril de 2025, formalizou um teste de três resultados possíveis para qualquer fornecedor de SDK integrado a um app: operador, quando o SDK trata dados exclusivamente por conta e segundo instruções do editor do app, sem perseguir finalidade própria; controlador, isolado ou conjunto com o editor, quando o SDK usa os dados coletados para as próprias finalidades, como melhorar o produto do fornecedor ou construir perfis publicitários; ou nenhuma responsabilidade sob o RGPD, nos casos raros em que o SDK não trata dado pessoal algum.
O ponto que muda o jogo é o seguinte: a CNIL declara explicitamente que não segue a qualificação que as partes escolheram contratualmente, e sim a análise real de quem influencia a finalidade e os meios do tratamento. Isso significa que um contrato de SDK que se autodeclara "processor" pode ser reclassificado como controlador conjunto numa fiscalização, se o fornecedor efetivamente usa os dados coletados dentro do app para treinar seus próprios modelos de recomendação ou enriquecer seu próprio inventário publicitário, independentemente do que o contrato diz.
A LGPD não tem uma recomendação setorial equivalente publicada pela ANPD especificamente sobre SDKs em apps, mas a estrutura de agente de tratamento do Art. 5º já permite a mesma leitura funcional: o critério brasileiro também é sobre quem efetivamente determina finalidade e meios, não sobre o rótulo contratual. Na prática, para uma empresa brasileira que também atende usuários europeus, o caminho mais defensável é aplicar o teste de três resultados da CNIL a cada SDK integrado ao app, documentar o resultado por escrito e usar essa mesma análise como base para a qualificação sob a LGPD, em vez de manter duas análises paralelas com metodologias diferentes chegando a conclusões inconsistentes sobre o mesmo fornecedor.
GDPR x LGPD: Onde a Mecânica Jurídica Realmente Diverge
| Mecanismo Jurídico | GDPR (União Europeia) | LGPD (Brasil) |
|---|---|---|
| Base legal padrão para rastreamento publicitário/analytics | Consentimento explícito; interesse legítimo não é alternativa válida sob a ePrivacy Art. 5(3) | Consentimento (Art. 7º, I); ANPD restringe cada vez mais o uso de interesse legítimo (Art. 7º, IX) para essa finalidade |
| Qualificação padrão de um SDK de terceiro | Caso a caso, conforme teste da CNIL (2024/2025): operador por padrão, controlador se o fornecedor usa dados para fins próprios | Sem recomendação setorial específica da ANPD; aplica-se o mesmo teste funcional pela via do Art. 5º (agente de tratamento) |
| Gatilho formal de avaliação de impacto | GDPR Art. 35(3) + 9 critérios do WP248 (perfilamento, dados sensíveis em larga escala, monitoramento sistemático, entre outros) | RIPD conforme Art. 38 da LGPD; sem capítulo específico da ANPD para apps móveis até agosto de 2026 |
| Prazo de notificação de incidente de segurança | Até 72 horas corridas à autoridade (Art. 33) | Até 3 dias úteis à ANPD e aos titulares (Resolução CD/ANPD nº 15/2024) |
| Prazo de resposta a solicitação do titular | 30 dias corridos, prorrogável por até 60 dias adicionais em casos complexos | 15 dias corridos para resposta detalhada (Art. 18) |
| Consentimento parental para dados de menores | Exigido; idade de consentimento digital varia entre 13 e 16 anos por Estado-membro | Exigido de forma uniforme para qualquer criança, sem variação por idade (Art. 14), reforçado pelo Estatuto da Criança e do Adolescente Digital desde março de 2026 |
Exigências de Consentimento: Granularidade, Prova e Revogação
A parte de implementação técnica do bloqueio de consentimento (qual SDK inicializa e quando) já está descrita no artigo de referência sobre conformidade em apps; a parte que este guia acrescenta é o padrão jurídico que essa implementação precisa satisfazer para ser defensável numa fiscalização, não apenas funcional no dia a dia.
Granularidade significa que aceitar tudo e recusar tudo precisam ter peso visual idêntico, e que cada categoria de finalidade (essencial, analytics, publicidade, funcional) precisa poder ser aceita ou recusada de forma independente, não em bloco. Prova de consentimento significa que o registro precisa sobreviver a uma fiscalização feita meses depois do evento: data, hora, versão exata da política de privacidade vigente no momento, e a lista de fornecedores apresentada àquele usuário específico, porque a lista de SDKs integrados ao app muda com o tempo e uma prova de consentimento vinculada a uma lista desatualizada não sustenta a base legal para os fornecedores atuais. Revogação significa que retirar o consentimento precisa ser tão simples quanto concedê-lo, e que a retirada precisa se propagar para todo sistema que ainda guarda aquele dado, não apenas para a interface do app.
A Camada de Decisão da Arquitetura de Consentimento: SDK Nativo, WebView e Sincronização entre Dispositivos
Esta é a decisão de arquitetura que mais frequentemente determina se um app cai no mesmo padrão de falha que gerou as multas da Voodoo e da Apple, e é uma decisão de produto e de compliance, não apenas de engenharia.
SDK de consentimento nativo versus tela de consentimento embutida em WebView. Um SDK de consentimento nativo roda no mesmo contexto de execução dos SDKs de rastreamento que ele precisa bloquear: ambos são código nativo carregado no processo do app, o que permite ao SDK de consentimento interceptar a inicialização de qualquer outro SDK antes que ele dispare a primeira chamada de rede. Uma tela de consentimento carregada dentro de uma WebView, por outro lado, roda num contexto isolado: o script que desenha o banner dentro da WebView não tem visibilidade nativa sobre o que o app já decidiu fora dela, e o app nativo não necessariamente escuta o que aconteceu dentro da WebView a menos que essa ponte seja construída deliberadamente. A consequência prática de deixar essa ponte de fora não é apenas uma experiência ruim, com o usuário respondendo duas telas de consentimento diferentes: é a reprodução exata do padrão que a CNIL multou, porque os SDKs nativos de analytics e publicidade já podem ter inicializado antes de o usuário nunca ter chegado a ver o conteúdo dentro da WebView.
A decisão entre as duas abordagens deveria ser guiada por uma pergunta simples: onde a maior parte do rastreamento tecnicamente acontece, no código nativo do app ou em conteúdo web incorporado? Quando a resposta é "principalmente nativo", uma solução com SDKs nativos para iOS, Android, React Native e Flutter, que bloqueia a inicialização no mesmo contexto de execução em que o rastreamento ocorre, fecha a lacuna que a arquitetura baseada em WebView deixa aberta por padrão.
Sincronização de consentimento entre dispositivos. Guardar o consentimento apenas localmente no dispositivo cria uma lacuna específica de mobile que não existe do mesmo jeito na web: identificadores de publicidade podem ser reiniciados pelo próprio usuário ou pela reinstalação do app, e um registro de consentimento puramente local não sobrevive a isso, criando a aparência de um "novo usuário sem histórico" quando, na verdade, é a mesma pessoa que já havia retirado o consentimento. A solução tecnicamente correta é sincronizar o consentimento a um identificador de nível de conta em um backend, não apenas ao identificador de dispositivo, o que por sua vez levanta uma segunda pergunta jurídica que a maioria das equipes não faz: vincular um registro de consentimento à conta do usuário é, em si, um tratamento de dado pessoal que precisa da própria base legal, normalmente sustentada pela necessidade contratual do serviço de conta. Ignorar essa camada e manter o consentimento só localmente resolve o problema de engenharia mais simples e deixa aberto exatamente o cenário que gera reclamação de titular: "eu já tinha recusado, por que voltou a rastrear depois que reinstalei o app?"
Cláusulas Contratuais que Toda Empresa Deveria Exigir de um Fornecedor de SDK
Dado que a qualificação jurídica de um SDK não pode depender só do que o contrato afirma, o contrato em si precisa conter os elementos que permitem verificar e não apenas declarar essa qualificação:
- Declaração de papel com justificativa, não apenas o rótulo: o fornecedor precisa explicar, com base no teste de três resultados descrito acima, por que se qualifica como operador e não como controlador para aquela integração específica.
- Acordo de tratamento de dados com os elementos mínimos do Art. 28 da GDPR quando aplicável: objeto, duração, natureza e finalidade do tratamento, tipos de dados e categorias de titulares envolvidos, e as obrigações e direitos do controlador.
- Divulgação de subprocessadores, com direito de o publicador do app ser notificado antes da inclusão de um novo subprocessador na cadeia, e não apenas informado depois do fato.
- Mecanismo de transferência internacional documentado, quando a infraestrutura do fornecedor de SDK está fora do Espaço Econômico Europeu (cláusulas contratuais-tipo ou decisão de adequação) ou fora do Brasil sob o Art. 33 da LGPD.
- Prova verificável de que o SDK respeita o sinal de consentimento em tempo real, não apenas a afirmação de que respeita: idealmente via documentação técnica auditável do comportamento do SDK diante de cada estado de consentimento, permitindo à equipe de compliance confirmar por análise de tráfego, e não apenas por confiança no fornecedor, que a chamada de rede não é feita antes da resposta do usuário.
- Alinhamento de prazo de notificação de incidente ao prazo mais curto entre os regimes que a empresa precisa cumprir: 72 horas corridas para a GDPR e 3 dias úteis para a LGPD não são o mesmo número, e o contrato do fornecedor precisa notificar o publicador do app a tempo de a empresa cumprir o prazo mais apertado dos dois.
Governança de SDKs e Rastreadores: o Que Já Foi Coberto e o Que Fica de Lição
O inventário de SDKs, a auditoria de tráfego de rede para confirmar comportamento real (em vez de confiar só na documentação do fornecedor) e a minimização de dados por finalidade já foram tratados em profundidade no artigo sobre conformidade de privacidade em apps e no guia técnico sobre auditoria e controle de compartilhamento de dados de SDKs de terceiros. A lição que este guia acrescenta é que esse inventário só tem valor jurídico se cada linha dele estiver amarrada à qualificação de papel (controlador, operador ou nenhuma responsabilidade) e à base legal da finalidade correspondente, não apenas ao nome comercial do SDK e à categoria funcional dele.
Avisos de Privacidade Dentro do App
Um aviso de privacidade correto para um app precisa refletir a lista real de SDKs ativos naquela versão específica publicada, não uma lista genérica mantida por conveniência. Cada atualização de app que adiciona ou remove um SDK deveria disparar automaticamente uma revisão do aviso e, quando a mudança afeta finalidade de tratamento, uma nova captura de consentimento, não apenas uma atualização silenciosa de texto que o usuário nunca vê.
Atendimento a Titulares (DSAR) em Apps Móveis
O prazo é o ponto mais citado, e o mais fácil de errar: até 30 dias corridos para a GDPR, prorrogável por mais 60 em casos complexos, contra 15 dias corridos para resposta detalhada sob o Art. 18 da LGPD, menos da metade do prazo europeu. O ponto que mais frequentemente falha na prática de apps móveis, porém, não é o prazo: é a verificação de identidade. Num site, o titular normalmente já está autenticado numa conta com histórico. Num app, o titular pode estar identificado só por um identificador de dispositivo, que muda a cada reinstalação, tornando difícil provar que a pessoa que pede exclusão de dados é a mesma associada àquele histórico de rastreamento, sem coletar ainda mais dado pessoal só para validar a solicitação. A solução mais defensável é vincular a solicitação a um canal de verificação já existente na relação com o usuário (o e-mail da conta, por exemplo) em vez de inventar um novo processo de verificação ad hoc para cada pedido, e um formulário de DSAR com validação embutido reduz esse atrito ao já nascer conectado ao canal de contato correto.
DPIA para Apps Móveis, e Por Que o RIPD Brasileiro Ainda Não Tem um Capítulo Próprio
A GDPR resolve o gatilho de avaliação de impacto de forma relativamente explícita: o Art. 35(3) lista três hipóteses obrigatórias (avaliação sistemática e extensiva de aspectos pessoais por meio automatizado, tratamento em larga escala de categoria especial de dado, monitoramento sistemático em larga escala de área pública), e as diretrizes do antigo Grupo de Trabalho do Artigo 29, ainda referência prática (WP248 rev.01), acrescentam nove critérios de alto risco, entre eles avaliação ou pontuação de comportamento, uso de tecnologia inovadora e tratamento de dado de titular vulnerável; a regra prática é que dois ou mais critérios presentes já justificam uma DPIA. Para um app típico com analytics comportamental, SDKs de publicidade personalizada e possível uso de modelo de recomendação por IA, é comum bater três ou quatro desses critérios ao mesmo tempo, o que torna a DPIA praticamente obrigatória na prática, mesmo quando nenhuma das três hipóteses do Art. 35(3) se aplica isoladamente.
O lado brasileiro é mais aberto: o Art. 38 da LGPD exige que o RIPD contenha, no mínimo, a descrição dos tipos de dado tratados, a metodologia de tratamento e garantia de segurança, e a análise do controlador sobre medidas e mecanismos de mitigação de risco, mas a elaboração do relatório em si é discricionária, feita a pedido da ANPD ou por decisão preventiva do próprio controlador, sem uma lista fechada de gatilhos equivalente aos nove critérios europeus. Verificando diretamente a página oficial da ANPD sobre o RIPD, não existe até agora nenhuma seção específica endereçando apps móveis como categoria distinta: a autoridade trata operações de alto risco em geral (tratamento de dado sensível em larga escala, decisão automatizada, interesse legítimo) sem detalhar como esses critérios se aplicam à arquitetura peculiar de um app, com múltiplos SDKs de terceiros e fluxo de dados que muitas vezes passa por infraestrutura fora do controle direto do publicador. Na prática, para uma empresa brasileira operando também sob GDPR, a recomendação mais defensável é usar os nove critérios do WP248 como checklist de gatilho mesmo para decidir se vale a pena elaborar um RIPD voluntariamente, preenchendo por analogia a lacuna que a ANPD ainda não fechou.
O conteúdo de uma DPIA para app móvel precisa necessariamente mapear, para cada SDK integrado: qual dado ele coleta, para qual finalidade, se há transferência internacional embutida na infraestrutura do fornecedor, e qual a base legal específica daquela finalidade, não apenas descrever o app como um todo em termos genéricos. Uma DPIA que descreve "o app coleta dados para melhorar a experiência do usuário" sem descer ao nível de cada SDK não sobrevive a uma fiscalização que já testa comportamento técnico, não documento.
iOS x Android: Permissão de Plataforma Não é Base Legal
O App Tracking Transparency da Apple e o Consent Mode v2 do Google já foram documentados em detalhe, incluindo a tabela comparativa completa de exigências por plataforma, no artigo de referência sobre conformidade em apps. O ponto que aquele artigo estabelece e que vale reforçar aqui, porque conecta diretamente com a mecânica jurídica deste guia: a permissão do ATT e os quatro sinais do Consent Mode v2 (ad_storage, analytics_storage, ad_user_data, ad_personalization) são autorizações de plataforma, não bases legais sob a GDPR ou a LGPD. Um usuário que autoriza o ATT concedeu acesso ao IDFA dentro do framework da Apple; isso não substitui a análise de base legal por finalidade feita mais acima neste guia, e a reclassificação de papel jurídico de um SDK de publicidade (controlador ou operador, conforme o teste da CNIL) não muda dependendo de qual sinal de plataforma foi concedido. As duas camadas são independentes e, na sequência correta, o consentimento GDPR ou LGPD deveria ser resolvido antes de o app sequer solicitar a permissão de plataforma correspondente.
Padrões de Falha Mais Comuns, com Casos Reais
O padrão mais caro é o mesmo nos dois casos da CNIL: o SDK inicializa e a chamada de rede sai antes da resolução do consentimento, ou continua saindo depois de uma recusa registrada. A Voodoo foi multada em 3 milhões de euros e a Apple Distribution International em 8 milhões de euros exatamente por essa assinatura de tráfego, identificadores de publicidade gravados ou lidos sem consentimento prévio válido (CNIL, 2024). Reguladores europeus já rodam testes automatizados de tráfego de rede especificamente para detectar esse padrão, e a ANPD está seguindo a mesma direção conforme sua fiscalização de apps se intensifica.
Consentimento condicionado ("aceite tudo para continuar usando o app") continua sendo tratado como padrão inválido sob a GDPR, porque a funcionalidade essencial precisa estar disponível para quem recusa rastreamento não essencial; a LGPD chega à mesma conclusão pela via do princípio da boa-fé e da vedação a práticas abusivas na coleta de consentimento.
"Analytics invisível" é o nome prático para SDKs de mensuração de produto (não publicitários) integrados sem qualquer análise de base legal, sob a suposição equivocada de que, por não servirem à publicidade, não precisam de consentimento. A maioria desses SDKs coleta identificador de dispositivo e padrão de uso comportamental suficiente para caracterizar tratamento de dado pessoal sob as duas leis, e a ausência de consentimento aqui é tão fiscalizável quanto num SDK publicitário.
Registro de consentimento sem valor probatório, mantido em planilha ou em log interno sem timestamp, versão de política e lista de fornecedores vinculados, é o padrão que mais frequentemente aparece quando uma empresa já tem consentimento coletado corretamente na interface, mas não consegue provar isso meses depois numa fiscalização.
O modelo de fiscalização da ANPD também está migrando de verificação documental para verificação de resultado prático: uma ação de dezembro de 2024 já testou se o canal de atendimento ao titular efetivamente funcionava, não apenas se ele existia publicado no aviso de privacidade. Para apps, isso significa que ter um formulário de DSAR listado na política não basta; a autoridade tende a testar se a solicitação enviada por ali de fato chega a alguém, com resposta dentro do prazo do Art. 18.
Automatizando a Conformidade
Sustentar manualmente essa mecânica (qualificação de papel por SDK, base legal por finalidade, prazos distintos de incidente e de DSAR, arquitetura de bloqueio que efetivamente previne o padrão de falha da CNIL) deixa de ser viável a partir de um certo volume de integrações e de usuários. Uma plataforma com registro de consentimento auditável e exportável, detecção automática de localização do visitante para aplicar o fluxo jurídico correto por região, e bloqueio de SDK no mesmo contexto de execução nativo em que o rastreamento ocorre, transforma essa mecânica de um exercício manual e recorrente em uma configuração feita uma vez e mantida automaticamente.
Checklist de Conformidade
| Item | O Que Verificar |
|---|---|
| Base legal por finalidade | Cada finalidade de tratamento (funcionalidade, analytics, publicidade, prevenção a fraude, dados de menores) tem sua própria base documentada, não uma base única para o app inteiro |
| Qualificação de cada SDK | Cada fornecedor de SDK foi classificado como operador, controlador ou controlador conjunto com base no teste funcional, não apenas no rótulo do contrato |
| Bloqueio de inicialização | Nenhum SDK não essencial inicializa, nem faz chamada de rede, antes da resolução do consentimento, verificado por análise de tráfego e não só por documentação do fornecedor |
| Prova de consentimento | Cada registro inclui timestamp, versão da política vigente naquele momento e lista de fornecedores apresentada, sincronizado além do armazenamento local do dispositivo |
| Cláusulas contratuais de SDK | Contratos incluem justificativa de papel, acordo de tratamento de dados, divulgação de subprocessadores e mecanismo de transferência internacional |
| DPIA/RIPD | Avaliação feita por SDK integrado, não pelo app como um todo, cobrindo transferência internacional embutida em cada fornecedor |
| Prazos de incidente e DSAR | Processo interno alinhado ao prazo mais curto entre 72 horas (GDPR) e 3 dias úteis (LGPD) para incidente, e 15 dias (LGPD) para DSAR |
| Avisos de privacidade | Refletem a lista real de SDKs da versão publicada atual, atualizados a cada mudança relevante |
FAQ
Um app precisa cumprir GDPR e LGPD ao mesmo tempo?
Sim, sempre que atender usuários na União Europeia e no Brasil simultaneamente, porque as duas leis se aplicam pelo critério de localização do titular, não pela sede da empresa, e nenhuma substitui a outra. A prática mais eficiente é aplicar o padrão mais rigoroso entre as duas nos pontos em comum (como granularidade de consentimento) e tratar separadamente os pontos onde divergem, como o prazo de notificação de incidente ou o prazo de resposta ao titular.
Um SDK de terceiro é sempre um operador (processor) sob a LGPD e a GDPR?
Não. Depende de uso real dos dados, não do rótulo contratual. Se o fornecedor do SDK usa os dados coletados dentro do app para finalidade própria, como treinar seus próprios modelos ou construir perfis publicitários, ele se torna controlador ou controlador conjunto, mesmo que o contrato o descreva como processor. A CNIL formalizou esse teste de três resultados para SDKs em 2024 e 2025, e a mesma lógica funcional se aplica pela estrutura de agente de tratamento da LGPD.
A permissão do App Tracking Transparency da Apple substitui o consentimento da GDPR?
Não. São camadas independentes. O ATT autoriza acesso técnico ao IDFA dentro do framework da Apple; a GDPR exige uma base legal própria para cada finalidade de tratamento, normalmente consentimento para rastreamento publicitário sob a ePrivacy Art. 5(3). As duas autorizações são necessárias e devem ser sequenciadas com o consentimento legal vindo primeiro.
O que muda entre uma tela de consentimento nativa e uma embutida em WebView?
Uma tela nativa roda no mesmo contexto de execução dos SDKs que precisa bloquear, permitindo interceptar a inicialização deles antes da primeira chamada de rede. Uma tela em WebView roda isolada desse contexto, o que pode deixar SDKs nativos de rastreamento inicializando antes mesmo de o usuário ver a interface de consentimento dentro da WebView, reproduzindo o mesmo padrão de falha já multado pela CNIL.
Toda empresa que publica um app precisa fazer uma DPIA ou um RIPD?
Não automaticamente, mas é comum que um app típico já bata dois ou mais dos nove critérios de alto risco do WP248 (avaliação de comportamento, tecnologia inovadora, dado de titular vulnerável), o que torna a DPIA praticamente obrigatória na prática sob a GDPR. No Brasil, o RIPD é discricionário conforme o Art. 38 da LGPD, mas a ANPD ainda não publicou orientação específica para apps móveis, o que torna prudente usar os critérios europeus como referência voluntária.
Qual é o prazo para responder a uma solicitação de titular vinda de um usuário de app?
Até 30 dias corridos sob a GDPR, prorrogável por mais 60 dias em casos complexos, e até 15 dias corridos sob o Art. 18 da LGPD para resposta detalhada. O desafio prático em apps não é normalmente o prazo, é verificar a identidade do solicitante quando ele só está identificado por um identificador de dispositivo que muda a cada reinstalação.
O prazo de notificação de incidente de segurança é o mesmo nas duas leis?
Não. A GDPR exige notificação à autoridade em até 72 horas corridas (Art. 33), enquanto a LGPD exige comunicação à ANPD e aos titulares em até 3 dias úteis, conforme a Resolução CD/ANPD nº 15/2024. Como um conta em horas corridas e o outro em dias úteis, uma empresa sujeita às duas leis deveria alinhar o processo interno ao prazo mais apertado entre os dois, não tratá-los como equivalentes.
Conformidade com o GDPR em apps móveis, em 2026, deixou de ser uma questão de ter o texto certo no aviso de privacidade. É uma questão de a base legal registrada corresponder à finalidade real de cada SDK, de a qualificação de papel de cada fornecedor sobreviver a uma análise funcional e não só contratual, e de a arquitetura de consentimento efetivamente impedir, no nível de execução, o padrão de falha que já custou 11 milhões de euros só entre a Voodoo e a Apple. Sustentar essa mecânica peça por peça, para cada SDK, cada finalidade e cada uma das duas leis, deixa de escalar manualmente a partir de poucas integrações. A Solução de Consentimento da Secure Privacy, com SDKs nativos para iOS, Android, React Native e Flutter, registro de consentimento auditável e exportável, e governança de fornecedores integrada ao fluxo de compliance, cuida dessa camada técnica para que o time jurídico possa focar na análise que só ele pode fazer. Agende uma demonstração para ver como funciona na prática.