Sem Telefone, Sem Conta: A Barreira de QR do Google e o GDPR
O Google agora bloqueia a criação de conta atrás de uma verificação por QR baseada em telefone. Sem smartphone, sem conta. Veja por que isso colide com a minimização de dados do GDPR.

Tente criar uma conta Google hoje e você pode esbarrar em uma barreira antes de digitar um único caractere do seu nome. A tela diz "Verifique algumas informações antes de criar uma conta", mostra um código QR e pede para escaneá-lo com a câmera do seu celular. Não há link para clicar, nem alternativa por e-mail, nem caminho para "pular". Sem um smartphone com câmera funcionando, não há conta. Essa é a interação inteira, e vale a pena parar para olhar, porque ela silenciosamente transforma um telefone em pré-condição para usar a web.
Eu moro nos Países Baixos, dentro da UE, e o enquadramento daquela tela ("o Google precisa verificar algumas informações sobre o seu dispositivo ou número de telefone") soa menos como recurso de segurança e mais como coleta obrigatória de identidade disfarçada de antiabuso. Este post é sobre por que essa distinção importa e onde ela colide com o GDPR.
O que a tela realmente exige
Leia o aviso ao pé da letra. Para criar uma conta, pede-se que você:
- Possua um smartphone com câmera capaz de escanear um código QR.
- Passe o fluxo para esse telefone, abandone o dispositivo onde você começou e conclua etapas que o Google não mostra de antemão.
- Vincule a nova conta a um número de telefone, que na maior parte da UE está, ele próprio, atrelado à identidade governamental verificada no nível do SIM.
- Mais adiante no mesmo funil, forneça uma data de nascimento e outros dados pessoais.
Nada disso é requisito técnico para uma conta de e-mail funcionar. Uma caixa de entrada não precisa saber seu aniversário, o modelo do seu aparelho ou a sua operadora. São decisões de coleta, não restrições de engenharia, e merecem ser julgadas como decisões de coleta.
"Antiabuso" está fazendo muito trabalho aqui
A justificativa é a prevenção de bots: "impedir abuso por programas de computador ou bots". Esse é um problema real, e limitar a taxa de criação de contas é legítimo. Mas observe o formato do controle. Ele não pede que você resolva um quebra-cabeça que um humano resolve e um script não. Ele pede que você apresente um telefone. O que está sendo verificado não é "você é humano", e sim "você consegue produzir um dispositivo e um número que possamos identificar e correlacionar".
Esses são objetivos diferentes. O primeiro é proporcional ao combate ao abuso. O segundo é vinculação de identidade, e uma vez que um número de telefone é anexado no cadastro, ele raramente permanece confinado à finalidade para a qual foi coletado. Números adicionados "por segurança" têm um longo histórico de migrar para segmentação de anúncios, grafos sociais de recuperação de conta e correlação entre serviços. Equipes de segurança chamam isso de function creep. O GDPR chama de problema de limitação de finalidade.
Onde isso colide com o GDPR
Não estou afirmando que um tribunal tenha declarado este fluxo específico ilegal. Estou apontando os princípios que uma autoridade de proteção de dados (DPA) de fato pesaria, porque eles se alinham mal com "escaneie isto ou vá embora".
Minimização de dados, Artigo 5(1)(c)
Os dados pessoais devem ser "adequados, pertinentes e limitados ao necessário" para a finalidade. A finalidade aqui é criar uma conta de e-mail. Um número de telefone e uma data de nascimento não são necessários para operar uma caixa de correio, o que significa que o ônus recai sobre o controlador de demonstrar por que eles são coletados, e não sobre o usuário de justificar a recusa.
Consentimento dado livremente, Artigos 4(11) e 7(4)
O consentimento só é válido se for dado livremente, e o regulamento diz explicitamente que se deve considerar se um serviço é tornado condicional a um consentimento de tratamento que não é necessário para aquele serviço. "Sem número de telefone, sem conta" é a definição de manual de condicional. Quando a única alternativa a compartilhar dados é ser excluído inteiramente do serviço, a "escolha" está fazendo muito pouco trabalho.
Proporcionalidade e necessidade
Mesmo sob uma base de legítimo interesse em vez de consentimento, o tratamento precisa passar por um teste de necessidade e ponderação. Forçar todo usuário em potencial a passar por um hardware que ele pode não possuir, para derrotar bots que são uma fração dos cadastros, é difícil de chamar de opção menos intrusiva quando CAPTCHA, confirmação por e-mail e sinais comportamentais já existem e não exigem câmera.
A exclusão para a qual ninguém projeta
Há um problema mais silencioso por baixo do de privacidade. Uma barreira de QR e câmera pressupõe um usuário específico: alguém que possui um smartphone recente, consegue ver e escanear fisicamente um código, e se sente confortável em mover um fluxo de criação de conta para um aparelho. Essa premissa exclui pessoas que usam apenas desktop, pessoas com deficiência visual, pessoas com telefones básicos, pessoas que mantêm deliberadamente uma pegada mínima de dispositivos, e qualquer um que simplesmente não queira um telefone pessoal conectado a cada login.
"É só usar um telefone" não é um padrão neutro. É uma decisão de projeto que empurra o custo do problema de abuso do Google para os usuários, inclusive usuários para quem um smartphone não é garantido. Acessibilidade e proteção de dados apontam na mesma direção aqui: um serviço tão central deveria ter um caminho que não exija a posse de um hardware específico.
O que a UE poderia de fato fazer a respeito
A maquinaria do GDPR para contestar isso já existe. Não precisa de nova lei, precisa de aplicação dos princípios acima:
- Tratar número de telefone e data de nascimento no cadastro como não necessários por padrão, e exigir que o controlador prove a necessidade em vez de afirmá-la.
- Exigir um caminho alternativo genuíno para a criação de conta que não exija um smartphone ou um número, com base na lógica de condicionalidade do Artigo 7(4).
- Examinar a finalidade: se um número coletado para antiabuso for depois usado para publicidade ou correlação, isso é uma violação de limitação de finalidade, independentemente de como a tela de cadastro foi redigida.
Uma posição coordenada do EDPB, ou uma única DPA determinada, é suficiente para forçar um redesenho. Vimos exatamente esse padrão com os muros de cookies, em que os reguladores acabaram decidindo que "consinta ou vá embora" não é consentimento real. Um muro de hardware é o mesmo argumento com uma câmera anexada.
O que você pode fazer hoje
Nada do que está acima ajuda você nos cinco minutos em que você de fato precisa de uma conta, então, na prática:
- Use um provedor que não exija um telefone para as contas que você controla. Vários provedores de e-mail sediados na UE tratam um número como opcional em vez de obrigatório.
- Mantenha identidade e conveniência separadas. Se você precisar anexar um número em algum lugar, não reutilize aquele que ancora sua identidade bancária e governamental.
- Exerça seus direitos. Um Subject Access Request, e quando apropriado uma reclamação à sua DPA nacional, não são simbólicos. São o mecanismo que transforma os princípios acima em pressão.
A conclusão
Um muro de QR e telefone na criação de conta é vendido como segurança, mas o dado que ele de fato protege é o seu, entregue como preço de entrada. Na UE esse preço tem um enquadramento legal: os dados devem ser minimizados, o consentimento deve ser livre, e um serviço não pode silenciosamente se tornar condicional à entrega de informações de que não precisa para funcionar. "Escaneie isto ou você não pode ter uma conta" falha nos três pontos de cara. Se um regulador vai dizer isso em voz alta é, neste momento, uma questão de vontade e não de lei.
Leia isto a seguir
- AWS Multi-party Approval for Organizations, sobre como controles de identidade e aprovação parecem quando são projetados para restringir poder em vez de coletá-lo.
- Why Your SSH Is Yelling About Quantum Computers, sobre levar avisos de segurança ao pé da letra versus ler o que eles de fato protegem.
Pensando em como assistentes de IA lidam com os dados de identidade e consentimento que recebem? As field notes em ercan.ai cobrem isso. Para consultoria em trabalho de plataforma com formato de nuvem, segurança e compliance, comece em ercanermis.com.
Mais de Ercan
Mais dois sites, mesmo autor, terreno diferente.
IA, LLMs, agentes, ML aplicado.
Notas de campo sobre cargas de IA. Análise de custos do Bedrock, padrões de agentes, trade-offs de armazenamento vetorial, modos de falha em produção.
Visitar ercan.ai →O hub. Sobre, consultoria, contato.
Hub pessoal para as duas trilhas de escrita. Quem sou eu, como funciona a consultoria, como me contatar.
Visitar ercanermis.com →