Dados de criancas e adolescentes na lgpd

O que caracteriza tratamento de dados de crianças e adolescentes

O que caracteriza esse tratamento é a idade do titular, não a finalidade do produto. Uma empresa de software de gestão, uma operadora de benefícios ou um varejo de material de construção tratam dados de menores no momento em que um menor se cadastra, é incluído como dependente ou interage com um canal aberto ao público. A pergunta operacional não é o meu produto é infantil?, e sim o meu sistema consegue perceber que quem está do outro lado tem menos de 18 anos? — e, na maioria das empresas, a resposta honesta é não.

Por que esse dado recebe proteção reforçada

Porque a lei parte do princípio de que o titular menor não avalia consequências de longo prazo do uso do próprio dado. Isso muda o padrão de comportamento esperado do sistema: em vez de coletar tudo o que for tecnicamente possível e restringir depois, o sistema precisa começar restrito e só ampliar mediante manifestação de quem responde pelo menor. Na engenharia, essa inversão tem nome — privacidade por padrão — e é a diferença entre uma configuração que existe e uma configuração que está ligada.

Criança e adolescente: o que muda na operação

A diferença operacional está no peso do responsável e no grau de autonomia que o sistema pode conceder ao próprio titular. Para a criança, o responsável é o interlocutor central: a manifestação parte dele, o canal de exercício de direitos é dele e a interface do produto precisa assumir que quem decide não é quem está usando. Para o adolescente, o responsável continua no circuito, mas o titular ganha participação — e o sistema precisa conseguir falar com os dois sem transformar o vínculo em vigilância.

Isso tem três efeitos concretos no desenho. Primeiro, o cadastro precisa suportar a ideia de duas pessoas ligadas a um registro — o titular e quem responde por ele. Segundo, o canal de atendimento de direitos precisa aceitar pedido feito por terceiro e verificar a relação de responsabilidade antes de executar. Terceiro, as configurações padrão não são as mesmas para todas as faixas: quanto menor o titular, mais restrito o ponto de partida.

Por que a empresa capta menores sem saber

A empresa capta menores sem saber porque a maioria dos seus pontos de entrada de dado nunca perguntou a idade de ninguém. O dado entra por um formulário aberto, é gravado como qualquer outro registro, ninguém marca que ele pertence a um menor — e a empresa passa a tratar dado de criança e adolescente sem conseguir demonstrar nada: nem a hipótese que autoriza o tratamento, nem os padrões aplicados, nem o canal pelo qual o responsável se manifestaria. O problema não é a captação em si; é a cegueira sobre ela.

Os fluxos silenciosos mais comuns

Há um conjunto de fluxos que capta menores em praticamente qualquer empresa, independentemente do ramo. Reconhecer a lista costuma ser o momento em que o tema deixa de parecer distante:

• Formulário de newsletter, contato ou download sem qualquer checagem de idade.
• Login social, que traz o cadastro pronto de uma plataforma que não informa a idade do titular.
• Cadastro de dependentes em plano de saúde, seguro ou benefício — o fluxo em que a empresa recebe data de nascimento de menores de forma explícita e mesmo assim não marca o registro.
• Programas de jovem aprendiz e estágio, que captam candidatos a partir de 14 anos por um portal de vagas comum.
• Promoções, sorteios e programas de indicação, abertos a qualquer pessoa com um e-mail.
• Chat de atendimento e mensageria abertos ao público, onde o interlocutor pode ser qualquer um.
• Pesquisas de satisfação disparadas para a base inteira, sem filtro de idade.
• Conta compartilhada em família, em que o titular formal é adulto e o usuário real não é.

Como montar o inventário de fluxos de captação

O inventário que resolve este problema é de fluxos, não de sistemas. Um inventário de sistemas lista bancos de dados e aplicações; ele não diz por onde uma pessoa de 13 anos entra. O roteiro abaixo produz a informação que falta:

1. Liste todos os pontos de entrada de dado abertos ao público. Formulários do site, landing pages, aplicativos, canais de mensageria, portais de vaga, plataformas de evento, formulários criados por agências ou por outras áreas.
2. Marque quais deles pedem idade ou data de nascimento hoje. Na maioria das empresas, essa coluna vem quase vazia — e esse é o achado.
3. Marque quais poderiam plausivelmente receber um menor. Critério simples: o fluxo é aberto a qualquer pessoa da internet, atende público jovem ou envolve dependentes.
4. Identifique o dono de cada fluxo. Marketing, produto, RH, atendimento, comercial. Sem dono, a regra não é aplicada nem mantida.
5. Descreva o que o sistema faz hoje quando recebe um menor. Na prática, quase sempre a resposta é nada — e escrever isso explicitamente é o que transforma o inventário em pauta.
6. Defina a regra de idade que cada fluxo passará a ter. Bloquear, marcar e restringir, exigir manifestação do responsável ou não coletar.

O produto final é uma tabela curta: fluxo, dono, coleta idade (sim/não), pode receber menor (sim/não), comportamento atual, regra definida.

O que fazer com o dado de menor que já está na base

Há quatro decisões possíveis, e a mais barata costuma ser a menos considerada. Quando a empresa descobre que já tem registros de menores, as opções são: marcar o registro e aplicar as restrições correspondentes; restringir o uso, tirando-o de segmentações e enriquecimentos; buscar a manifestação de quem responde pelo titular, quando o tratamento precisa continuar; ou eliminar o dado.

Eliminar é uma opção legítima e, com frequência, a decisão certa. Se o registro não sustenta nenhuma finalidade real — o menor entrou por um formulário de newsletter, nunca comprou nada, nunca interagiu —, mantê-lo cria obrigação permanente em troca de valor nenhum. A TI tende a evitar a exclusão por reflexo de preservação de base; do ponto de vista de risco e de custo operacional, apagar o que não serve é a saída mais simples. A regra prática é: só permanece na base o dado de menor que alguma finalidade concreta justifica manter.

Aferição etária: métodos, precisão e efeito colateral

Aferição etária é o conjunto de mecanismos pelos quais um serviço estima ou verifica a idade de quem está do outro lado — e é um problema de engenharia, com trade-offs mensuráveis, não uma caixa de seleção com a frase "declaro ter mais de 18 anos". A escolha do método define, ao mesmo tempo, quanta certeza a empresa terá sobre a idade e quanto dado adicional ela passará a coletar para obter essa certeza. Esses dois eixos andam em direções opostas, e é aí que mora a decisão.

Por que a caixa de "declaro ter 18 anos" não é aferição etária

Porque ela não produz informação — produz apenas um registro de que a pergunta foi feita. Qualquer usuário marca a caixa, inclusive o menor que quer acessar o serviço, e o sistema segue sem nenhum sinal aproveitável sobre a idade real. O resultado é o pior dos dois mundos: a empresa não sabe quem é menor na sua base e ainda assim acredita ter tratado o assunto.

O primeiro degrau útil é diferente e mais simples do que parece: pedir data de nascimento em vez de uma declaração binária, tratá-la como dado de cadastro e definir o que o sistema faz com cada faixa. Isso não impede que alguém minta, mas produz um dado sobre o qual regras podem operar — bloqueio, marcação, defaults restritivos, exclusão de audiências. Sair da caixa de seleção para o campo de data já resolve boa parte dos fluxos silenciosos descritos acima.

Comparativo de métodos de aferição etária

Os métodos disponíveis diferem em precisão, em atrito para o usuário e — o ponto que a maioria das análises ignora — no dado adicional que passam a exigir. A comparação a seguir é referência de mercado sobre como esses métodos se comportam na prática, não benchmark estatístico de acurácia:

Como escolher o método proporcional ao risco do serviço

O critério é a proporcionalidade entre o risco do serviço e o dado que o método exige — e não a busca pela maior precisão possível. Existe um paradoxo que precisa ser dito com todas as letras: quanto mais forte a verificação de idade, mais dado sensível a empresa passa a coletar de um público que a lei protege mais. Exigir documento de identidade para saber se alguém tem 15 ou 19 anos significa coletar, armazenar e proteger documento de menores — criando um risco novo para mitigar o risco antigo. Aferição etária não é uma solução sem custo, e vendê-la como tal é desonesto com o leitor.

Na prática, a decisão segue três perguntas. Qual o dano se um menor acessar este serviço? Um formulário de newsletter e uma plataforma com conteúdo restrito a adultos não estão na mesma categoria. Qual o volume de usuários? Métodos de alto atrito derrubam conversão e viram problema de negócio em fluxos de massa. O dado adicional é proporcional? Se o método exige mais dado sensível do que o serviço justifica, ele está errado, mesmo sendo mais preciso.

A arquitetura que costuma equilibrar isso é em camadas: data de nascimento declarada como piso para todos os fluxos, sinais de estimativa como triagem para detectar inconsistências, e verificação forte reservada aos poucos pontos em que o risco justifica. O Estatuto Digital da Criança e do Adolescente estabelece cronograma para a adoção de mecanismos de aferição etária, e esse cronograma foi incorporado ao plano de conformidade exigido pela autoridade brasileira de proteção de dados no caso descrito na seção seguinte^[1] — o que indica a direção que o mercado brasileiro tende a seguir, mesmo fora das plataformas de grande porte.

Os controles que a TI precisa implantar e demonstrar

Os controles se organizam em quatro frentes: configurações restritivas por padrão, supervisão pelo responsável, supressão de publicidade e perfilamento, e capacidade de demonstrar o que foi aplicado. Esse conjunto não é teórico — é aproximadamente a lista que a autoridade brasileira de proteção de dados exigiu em plano de conformidade ao aplicar multa de R$ 153,7 milhões à ByteDance, controladora do TikTok, em processo administrativo sancionador sobre falhas na proteção de dados de crianças e adolescentes^[1]. Para o gestor de TI, o valor dessa decisão não é o número: é a lista de controles que ela detalha, que funciona como régua do que se espera de um produto com público jovem.

Privacidade por padrão nas contas de menores de 16

Privacidade por padrão significa que a conta nasce na configuração mais restritiva e o usuário amplia se quiser, em vez de nascer aberta e depender de o usuário fechar. No plano de conformidade referido acima, isso aparece como aplicação automática das configurações mais restritivas de privacidade às contas de quem tem menos de 16 anos, além de reforço de controle parental e filtros de conteúdo mais rigorosos^[1].

Traduzido em configuração real de produto, o conjunto costuma incluir: perfil não público por padrão; mensagem de remetente desconhecido bloqueada; geolocalização desligada; descoberta do perfil por busca limitada; download e reencaminhamento de conteúdo restritos; e notificações reduzidas em horários noturnos. O ponto de engenharia é que esses valores precisam ser aplicados por regra de sistema no momento da criação da conta, e não por uma tarefa manual ou por um processo que depende de alguém lembrar.

Vale registrar o que a mesma decisão determinou para o consumo sem cadastro, porque é um desenho que outras plataformas tendem a imitar: experiência do feed limitada a 12 horas, suspensão total de anúncios no Brasil nesse modo e impossibilidade de criar conteúdo, comentar ou enviar mensagens^[1].

Controle parental, publicidade e o que desligar no pipeline

Controle parental é a exposição técnica do vínculo entre a conta do responsável e a conta do menor, com visibilidade de atividade e limites de tempo e de contato. A armadilha é o excesso: um controle parental que entrega ao responsável o conteúdo integral das conversas do adolescente troca um problema de proteção por outro, de vigilância. O desenho equilibrado dá ao responsável controle sobre configurações e limites — quem pode entrar em contato, quanto tempo de uso, que tipo de conteúdo aparece — sem transformar a supervisão em leitura de tudo.

Do lado da publicidade, a exigência é de supressão, e ela precisa acontecer no pipeline, não na intenção. Três desligamentos concretos: segmentação comportamental para o público marcado como menor; exportação desse público em audiências enviadas a plataformas de anúncio; e enriquecimento por dados de terceiros sobre esses registros.

Fornecedores que captam em nome da empresa e como demonstrar conformidade

O dever não desaparece porque o formulário é de terceiro. Formulário de agência, ferramenta de automação de marketing, plataforma de gestão de eventos e SDK embarcado no aplicativo captam dado em nome da empresa e sob responsabilidade dela. O que exigir é objetivo: saber quais campos o fornecedor coleta, se há captura de idade, o que ele faz com o registro de um menor, se há compartilhamento com terceiros e como ele devolve ou elimina o dado no fim do contrato. Esse é um recorte específico do processo mais amplo de avaliação e monitoramento de fornecedores, tratado no artigo Gestão de risco de terceiros (TPRM) na prática para a TI, e da concessão de acesso a externos, em Acessos para terceiros.

Demonstrar conformidade é uma capacidade separada de estar correto, e é onde a maioria falha. Quatro evidências sustentam a demonstração: registro dos defaults aplicados a cada conta de menor, com data; evidência da manifestação do responsável, quando ela foi a base do tratamento; log da decisão de aferição etária, mostrando qual método foi usado e qual foi o resultado; e versionamento da configuração vigente, para responder à pergunta "qual era a regra em vigor naquela data?". Sem isso, a empresa pode ter feito tudo certo e não conseguir provar.

O roteiro consolidado, para quem vai começar do zero, é este:

1. Inventariar os fluxos de captação abertos ao público, com dono declarado.
2. Definir a regra de idade de cada fluxo: bloquear, marcar, exigir manifestação do responsável ou não coletar.
3. Escolher o método de aferição proporcional ao risco de cada serviço.
4. Aplicar os defaults restritivos por regra de sistema, no momento da criação do registro.
5. Propagar a marcação de menor para os sistemas a jusante — CRM, adtech, analytics, BI.
6. Abrir e divulgar o canal pelo qual o responsável exerce direitos, com dono e prazo definidos.
7. Registrar as evidências de defaults, manifestação, aferição e versão de configuração.
8. Revisar todo fluxo novo antes de ele entrar em produção.