Privacidade por Design: Por Que Seu App Não Deveria Pedir Número de Telefone (E O Que Fazer Quando Precisa)

A pergunta que poucos devs fazem antes de adicionar aquele campo de telefone no formulário

Deixa eu te fazer uma pergunta direta.

Na última vez que você adicionou um campo de número de telefone num formulário de cadastro — você parou para perguntar se realmente precisava dele?

Ou foi automático? O design pedia, o PM pediu, "todo mundo pede número de telefone", e lá foi o campo.

Esse é o ponto de partida que eu quero questionar nesse artigo. Não porque número de telefone seja sempre desnecessário — às vezes é genuinamente importante. Mas porque a maioria dos apps pede por hábito, não por necessidade. E essa diferença tem consequências reais para seus usuários e, dependendo do contexto, para a sua empresa.

O Princípio Que Muda Como Você Pensa Sobre Isso

Privacidade por design não é uma regulamentação nem um checklist. É uma filosofia de desenvolvimento que diz: considere privacidade desde o início, não como camada adicionada depois.

Um dos princípios centrais é minimização de dados — colete apenas o que você genuinamente precisa para entregar o serviço. Não o que pode ser útil no futuro. Não o que seria interessante para análise. O que você precisa agora, para o que o usuário veio fazer.

Aplicado ao número de telefone, a pergunta fica simples: para que exatamente você vai usar esse número?

Se a resposta for vaga — "para contato", "para segurança", "todo mundo pede" — você provavelmente não precisa dele.

Os Casos Onde Você Realmente Precisa vs. Os Que Pensa Que Precisa

Vamos ser honestos sobre quando o número de telefone é necessário de verdade.

Casos onde faz sentido:

✓ Autenticação de dois fatores por SMS (quando não há alternativa melhor)
✓ Serviços onde o número é o produto (apps de chamada, WhatsApp clones)
✓ Recuperação de conta quando email não é suficiente por regulamentação
✓ Verificação de identidade exigida por compliance (fintech, saúde)
✓ Notificações urgentes onde email tem latência inaceitável

Casos onde você provavelmente não precisa:

✗ "Para entrar em contato se necessário" — email resolve
✗ "Para segurança adicional" — app autenticador é mais seguro
✗ "Para personalização" — não precisa de número para isso
✗ "Para verificar que é uma pessoa real" — existem outras formas
✗ "Porque o template de cadastro já tinha o campo" — sério?

A diferença entre essas duas listas determina se você está coletando dado necessário ou dado desnecessário com consequências desnecessárias.

O Que Acontece Com o Número Depois Que Você Coleta

Aqui está a parte que muitos devs não pensam porque não é sua responsabilidade direta — mas deveria ser parte da conversa quando o campo é adicionado.

Quando um usuário fornece o número de telefone para o seu app:

1. Ele vai para o banco de dados. Óbvio. Mas com quais controles de acesso? Quem na sua empresa consegue consultar números de usuários? Está criptografado em repouso?

2. Ele provavelmente vai para analytics. Muitas stacks de analytics coletam propriedades de usuário automaticamente. Você verificou se o número não está sendo enviado para ferramentas de terceiros sem mascaramento?

3. Ele pode ir para serviços de marketing. Se existe integração com CRM ou ferramentas de email marketing, o número pode estar sendo sincronizado para sistemas com políticas de privacidade diferentes das suas.

4. Ele vai ficar lá por tempo indefinido — a menos que você tenha implementado explicitamente uma política de retenção e um mecanismo de exclusão.

python

O que muitos sistemas fazem com dados de telefone:

class UserProfile(Model):
phone_number = CharField(max_length=20)
# Sem criptografia
# Sem política de retenção
# Sem log de quem acessa
# Sem mecanismo de exclusão automatizada
# Sincronizado automaticamente com o CRM
# Incluído nos backups que ficam por 7 anos

Quando você coleta um número de telefone, você está assumindo a responsabilidade por todos esses pontos. Se a pergunta "precisamos mesmo desse número?" não foi feita antes, esses problemas aparecem depois — geralmente na forma de um incidente de segurança ou uma pergunta difícil de auditoria.

Alternativas Técnicas Para Casos Comuns
Em vez de SMS para 2FA → Use TOTP

App autenticador (Google Authenticator, Authy, qualquer implementação TOTP) é tecnicamente superior ao SMS para autenticação de dois fatores em praticamente todos os aspectos relevantes:

python
import pyotp

Gerar secret para o usuário

secret = pyotp.random_base32()

Gerar URI para QR code (usuário escaneia no app autenticador)

totp = pyotp.TOTP(secret)
uri = totp.provisioning_uri(
name=user.email,
issuer_name="SeuApp"
)

Verificar código que o usuário digitou

def verify_totp(user_secret: str, code: str) -> bool:
totp = pyotp.TOTP(user_secret)
return totp.verify(code, valid_window=1)

Sem SMS, sem número de telefone coletado, sem vulnerabilidade SS7, sem risco de SIM swap. Mais seguro para o usuário, menos responsabilidade para você.

Em vez de SMS para verificação de cadastro → Use Email + Magic Link

Para verificar que o usuário tem acesso a um contato válido, email com magic link é suficiente para a maioria dos casos:

python
import secrets
from datetime import datetime, timedelta

def generate_magic_link(user_email: str) -> str:
token = secrets.token_urlsafe(32)
expiry = datetime.utcnow() + timedelta(minutes=15)

# Armazena token hasheado, não em plaintext
store_token(
    email=user_email,
    token_hash=hash_token(token),
    expires_at=expiry
)

return f"https://seuapp.com/verify?token={token}"

Envia por email, sem precisar de número de telefone

send_email(
to=user_email,
subject="Confirme seu cadastro",
body=f"Clique aqui para confirmar: {generate_magic_link(user_email)}"
)

Sem número de telefone coletado. Funciona para a grande maioria dos casos de verificação de cadastro.

Em vez de SMS para notificações → Use Push Notifications

Se você tem um app mobile e precisa notificar usuários de forma rápida, push notifications via FCM/APNs são mais confiáveis, mais rápidas, e não requerem número de telefone:

javascript
// Firebase Cloud Messaging — sem número de telefone
const message = {
notification: {
title: 'Atualização importante',
body: 'Sua solicitação foi processada'
},
token: user.fcmToken // Token do dispositivo, não número de telefone
};

await admin.messaging().send(message);
Quando Você Genuinamente Precisa Do Número: Faça Do Jeito Certo

Ok, digamos que você passou pela análise e realmente precisa do número. Talvez seja uma fintech com requisitos de KYC. Talvez seja um serviço de comunicação. Seja qual for o motivo legítimo — aqui está como implementar com responsabilidade.

Seja explícito sobre por que você precisa:

html

Usaremos este número apenas para enviar seu código de verificação. Não usamos para marketing e não compartilhamos com terceiros.

Armazene com criptografia:

python
from cryptography.fernet import Fernet

Nunca armazene número de telefone em plaintext em produção

class UserProfile(Model):
_phone_encrypted = BinaryField()

@property
def phone_number(self) -> str:
    return decrypt(self._phone_encrypted)

@phone_number.setter
def phone_number(self, value: str):
    # Normaliza para E.164 antes de criptografar
    normalized = normalize_phone(value)
    self._phone_encrypted = encrypt(normalized)

Implemente exclusão real:

python
def delete_user_phone(user_id: int) -> None:
user = User.get(user_id)

# Remove do banco principal
user.phone_number = None
user.save()

# Remove de sistemas conectados
crm.remove_contact(user.email)
analytics.delete_user_property(user.id, 'phone')

# Log para auditoria (sem o número em si)
audit_log.record(
    action='phone_deleted',
    user_id=user_id,
    timestamp=datetime.utcnow()
)

Para o caso de uso onde número virtual faz sentido no seu produto:

Se você está construindo um serviço onde usuários precisam de um número para verificação mas você quer minimizar a coleta de dados pessoais, considere integrar com provedores de números virtuais como parte da arquitetura. Em vez de pedir o número pessoal do usuário, você provisiona um número virtual para aquela sessão ou propósito específico.

Para entender como isso funciona na prática e quais casos de uso são suportados, o NumeroVirtual é um provedor com foco em verificação por SMS e privacidade que vale explorar como referência de como esse tipo de serviço pode ser estruturado.

A Conversa Que Você Deveria Ter Com o PM

Se você está lendo isso como dev e pensando "mas o PM pediu o campo de telefone", aqui está o framework para a conversa:

PM: "Precisa ter campo de telefone no cadastro."

Dev: "Para que exatamente vamos usar esse número?"

PM: "Para contato se necessário / segurança / verificação."

Dev: "Email não resolve o contato?
App autenticador não é mais seguro para verificação?
Se for só para ter, o custo de coletar e proteger
esse dado é maior do que o benefício?"

Não é uma conversa adversarial. É o dev trazendo perspectiva de implementação e compliance que o PM pode não ter considerado. Na maioria das vezes, quando a questão é colocada dessa forma, a resposta é que email resolve, ou que o TOTP é mais seguro mesmo, ou que o campo era padrão do template e ninguém tinha pensado se era necessário.

Essa conversa é mais fácil antes de implementar do que depois de ter coletado dados de milhares de usuários que agora precisam ser gerenciados, protegidos, e potencialmente excluídos.

LGPD e o Princípio da Necessidade

No contexto brasileiro, a LGPD tem um artigo específico que é diretamente relevante aqui: o princípio da necessidade — limitação do tratamento ao mínimo necessário para a realização das finalidades de tratamento.

Na prática, isso significa que se você coleta um número de telefone e não consegue articular claramente a finalidade específica e necessária para aquela coleta, você pode estar em desacordo com a lei — independente de ter um banner de cookies bonito ou uma política de privacidade extensa.

O teste simples: você consegue responder "por que precisamos desse número" com uma finalidade específica, não com "pode ser útil"?

Se não, você não deveria estar coletando.

TL;DR Para Copiar e Mandar Para o Time
Antes de adicionar campo de telefone:

1. Por que exatamente precisamos desse número?
   Se a resposta for vaga → não adicione

2. Email não resolve?
   Para contato e verificação de cadastro → geralmente resolve

3. TOTP não é mais seguro para 2FA?
   Para autenticação → quase sempre sim

4. Se precisar coletar:
   → Seja explícito sobre o uso na UI
   → Armazene criptografado
   → Implemente exclusão real
   → Documente a finalidade para compliance LGPD

5. Princípio geral:
   Dado que você não coleta não pode vazar,
   não pode ser mal usado, e não vira problema de compliance.

Você já teve essa conversa sobre coleta de número de telefone no seu time? Ou passou por algum momento onde percebeu que estava coletando dado desnecessário? Conta nos comentários — esse tipo de experiência real ajuda muito mais do que qualquer doc de boas práticas.