Política de Privacidade do ENtrack — minuta

MINUTA NÃO VIGENTE — NÃO ACEITÁVEL. Este texto não é uma política publicada, não autoriza tratamento de dados e não pode ser usado para obter ou registrar consentimento.

Versão: DRAFT-NOT-FOR-ACCEPTANCE. Vigência: não definida. Revisão jurídica e operacional: pendente.

Esta minuta descreve o estado conhecido do beta e organiza as decisões necessárias para uma futura Política de Privacidade. Ela não declara conformidade com a LGPD. Dados reais de estudantes, escolas, crianças ou adolescentes continuam proibidos até a aprovação dos gates aplicáveis.

1. Identificação e papéis

Controlador proposto para as finalidades B2C que ele próprio definir: [RAZAO_SOCIAL_DO_CONTROLADOR], [CNPJ_OU_REGISTRO], [ENDERECO].

Encarregado ou canal responsável por privacidade: [NOME_DO_RESPONSAVEL], [EMAIL], [TELEFONE].

Data proposta de publicação e vigência: [DATA].

Os papéis de controlador e operador são definidos pela função exercida em cada operação, e não apenas pelo nome da empresa ou pelo contrato. Controlador é quem toma as decisões essenciais sobre finalidade e meios do tratamento. Operador trata dados em nome do controlador e conforme instruções lícitas.

No uso direto pelo estudante, a entidade identificada acima poderá atuar como controladora das finalidades que determinar. No uso escolar, a instituição poderá atuar como controladora das atividades pedagógicas que definir, e a entidade do ENtrack poderá atuar como operadora dessas instruções. O ENtrack também poderá ser controlador independente para finalidades próprias e legalmente justificadas, como segurança de sua conta ou cumprimento de obrigação própria. Cada fluxo e exceção precisam ser mapeados no DPA Escolar; não se presume um único papel para todas as atividades.

2. Estado atual do beta

O runtime atual usa Supabase para autenticação e persistência e Vercel para hospedagem e entrega do app. A preferência visual do dispositivo pode ficar no localStorage. A coleta de analytics de usuários está desativada e falha fechada: não há SDK de analytics ativo, envio de eventos reais, cookie publicitário ou armazenamento de payload de analytics no produto atual.

O ambiente continua em beta. Capacidades técnicas existentes não substituem decisões sobre base legal, responsável, retenção, participação de menores, contratos, transferências internacionais ou resposta a incidentes.

3. Dados previstos

Uma versão futura poderá tratar, conforme a necessidade de cada recurso:

• conta e autenticação: e-mail, identificador interno, nome exibido, estado da conta, confirmação e recuperação de acesso;
• aprendizado: trilhas iniciadas e concluídas, progresso, respostas, erros, tentativas, revisões, resultados de simulados e calendário;
• gamificação: XP, ofensiva, vidas, pontos, conquistas e preferências relacionadas à experiência;
• vínculo escolar: escola, turma, papel, convite, trilha atribuída e informações necessárias para mostrar progresso apenas a pessoas autorizadas;
• arquivos opcionais: avatar do estudante ou logotipo da escola, dentro dos limites aprovados;
• preferência do dispositivo: tema visual salvo no localStorage, sem ser apresentado como histórico pedagógico;
• metadados técnicos: data e horário de requisições, endereço IP, tipo de navegador ou dispositivo, identificadores técnicos e registros mínimos necessários para autenticação, segurança, prevenção de abuso e disponibilidade, conforme inventário ainda pendente;
• contato institucional: nome, e-mail profissional, telefone e cidade de representante da escola quando necessários ao fluxo B2B.

O escopo atual não prevê CPF, dados financeiros, endereço residencial, geolocalização precisa, biometria, laudos, dados de saúde ou data de nascimento exata. Qualquer ampliação exige teste de necessidade, finalidade, base legal, segurança, retenção, transparência e nova aprovação.

4. Finalidades e bases legais propostas

As bases abaixo são hipóteses de trabalho, não decisões aprovadas. A versão final deverá documentar finalidade por finalidade, inclusive necessidade, proporcionalidade e melhor interesse de crianças e adolescentes.

Conta, acesso e prestação do serviço

Dados de conta poderão ser usados para criar e proteger a conta, manter a sessão, recuperar acesso e entregar o recurso solicitado. A base proposta é a execução de contrato ou de procedimentos preliminares solicitados pelo titular, quando aplicável, além de obrigação legal para atividades específicas que efetivamente a exijam.

Aprendizado e gamificação

Progresso, respostas e elementos de gamificação poderão ser usados para continuar os estudos, corrigir atividades e apresentar o próprio histórico. A base e o papel do agente variam entre uso direto e uso escolar e permanecem [BASE_LEGAL_APRENDIZADO].

Para tratamento fundado em consentimento, ele deverá ser livre, informado, específico, destacado, associado a finalidades determinadas e revogável. No caso de crianças, o art. 14 da LGPD prevê consentimento específico e em destaque de pelo menos um dos pais ou responsável legal, quando essa for a hipótese aplicável, e esforços razoáveis para verificar quem consentiu. Um checkbox marcado pelo estudante não comprova identidade nem autoridade do responsável.

Segurança e prevenção de abuso

Metadados técnicos estritamente necessários poderão ser usados para autenticação, investigação de acesso indevido, proteção de titulares e estabilidade. As bases possíveis incluem legítimo interesse, cumprimento de obrigação ou exercício regular de direitos; a escolha correta permanece [BASE_LEGAL_SEGURANCA] e exige documentação.

Preferência visual

O tema escolhido poderá ser guardado localmente para manter uma configuração solicitada no dispositivo. A versão final deverá confirmar se essa informação se vincula a uma pessoa identificada e por quanto tempo permanece no navegador.

Melhoria do produto e estatísticas

Analytics de usuários permanece desativado. Se uma versão futura preparar dados pessoais para produzir estatísticas, o tratamento anterior à anonimização precisará de base legal própria. O legítimo interesse somente poderá ser considerado após avaliação de finalidade legítima, necessidade, expectativas, impacto, salvaguardas e melhor interesse.

Resultados efetivamente anônimos, que não possam ser associados a uma pessoa por meios razoáveis, não são tratados como dados pessoais pela LGPD nos limites da lei. Chamar dados apenas pseudonimizados de “anônimos” não é suficiente. Não há autorização nesta minuta para publicidade, outreach, perfilamento comercial ou analytics comportamental.

5. Supabase, Vercel e compartilhamentos

As categorias técnicas hoje conhecidas são:

• infraestrutura Supabase: autenticação, banco de dados e armazenamento usados pelo runtime;
• infraestrutura Vercel: hospedagem, execução e entrega do app;
• analytics: cliente interno desativado, sem fornecedor de analytics ativo e sem coleta de dados reais.

Supabase e Vercel só deverão ser descritos como operadores ou subprocessadores depois da confirmação das entidades jurídicas contratadas, serviços, instruções, regiões, retenção, acesso, medidas e contratos. A função técnica de hospedar não resolve sozinha o papel jurídico em todas as operações.

Nenhuma URL de projeto, chave, credencial ou identificador sensível será publicada. O inventário final deverá preencher [ENTIDADES_CONTRATADAS], [REGIOES_DE_TRATAMENTO], [CATEGORIAS_DE_DADOS], [PRAZOS] e [MECANISMO_DE_TRANSFERENCIA].

Não haverá venda de dados pessoais. Compartilhamento com escola deverá se limitar ao vínculo e à finalidade pedagógica autorizada, sem expor e-mail ou histórico a pessoas sem permissão.

6. Transferências internacionais

Os locais de processamento e os mecanismos de transferência internacional ainda não foram aprovados. A futura política deverá informar de modo claro quando dados saírem do Brasil, quem os recebe, para qual finalidade e qual mecanismo previsto na LGPD e na regulamentação da ANPD sustenta a transferência.

Até essa verificação, esta minuta não afirma país, região, nível de proteção equivalente ou cláusula contratual específica.

7. Uso escolar (B2B)

Quando uma escola definir atividades pedagógicas, ela poderá atuar como controladora dessas finalidades, e a entidade do ENtrack poderá atuar como operadora que executa instruções documentadas. Para finalidades próprias, cada parte poderá ter outro papel, que deverá ser identificado de forma funcional.

Antes do uso real, as partes precisarão assinar um contrato e uma versão aprovada do DPA Escolar, definir quem informa estudantes e responsáveis, limitar quem vê o progresso e coordenar direitos, retenção e encerramento. A minuta pública do DPA não autoriza o envio de planilhas, criação de contas em nome de estudantes ou tratamento de dados reais.

8. Crianças e adolescentes

Toda finalidade envolvendo pessoa menor de 18 anos deverá observar seu melhor interesse, proteção integral, privacidade, desenvolvimento e direito a uma explicação adequada à sua capacidade de compreensão. A política de idade e as faixas efetivamente atendidas continuam [FAIXAS_ETARIAS_APROVADAS].

Como salvaguarda de produto proposta, a participação de qualquer pessoa menor de 18 anos dependerá do fluxo de responsável legal que vier a ser aprovado. Isso não significa que o consentimento seja automaticamente a única base legal possível para todo tratamento de adolescentes ou crianças; a base deverá ser definida por finalidade conforme a LGPD e as orientações aplicáveis, sempre com prevalência do melhor interesse.

Para crianças, as exigências específicas do art. 14 incluem informação pública sobre dados e usos, minimização e, quando aplicável, consentimento específico e destacado de pai, mãe ou responsável. A verificação deverá usar esforços razoáveis e proporcionais. Conta escolar, declaração de idade ou checkbox isolado não prova parentesco, guarda ou autorização.

O ENtrack não deverá condicionar a participação de criança ao fornecimento de dados além do estritamente necessário. Não serão ativados publicidade, outreach, comparação pública ou perfilamento comportamental de menores por esta minuta.

As regras propostas e o modelo de autorização estão nos Termos para Participação de Menores, também sem vigência.

9. Direitos das pessoas titulares

Depois de identificado o controlador e ativado um canal verificável, a pessoa titular poderá solicitar, nos termos da LGPD:

• confirmação de que existe tratamento e acesso aos dados;
• correção de dados incompletos, inexatos ou desatualizados;
• informação sobre compartilhamentos e consequências de negar consentimento;
• anonimização, bloqueio ou eliminação de dados desnecessários, excessivos ou tratados em desconformidade;
• portabilidade, quando aplicável e conforme regulamentação;
• eliminação de dados tratados com consentimento, ressalvadas hipóteses legais de conservação;
• revogação de consentimento por procedimento gratuito e facilitado;
• oposição a tratamento irregular e revisão de decisão automatizada, se houver;
• petição perante a ANPD e órgãos de defesa competentes.

Canal proposto: [EMAIL] e [TELEFONE]. Responsável: [NOME_DO_RESPONSAVEL].

Para evitar exposição indevida, o atendimento deverá verificar a identidade de quem pede e, quando representar um menor, sua autoridade. Essa verificação deverá ser proporcional e não coletar cópia de documento por padrão. O app não executará exclusão imediata apenas porque alguém marcou uma opção.

10. Retenção, devolução e exclusão

Nenhum prazo de retenção foi juridicamente aprovado. O motor técnico de retenção permanece desabilitado e não deve ser apresentado como política ativa.

A matriz final deverá definir prazos separados para conta, tentativas, progresso, rascunhos de simulado, vínculos escolares, arquivos, protocolos, logs e backups. Ao terminar a finalidade, os dados deverão ser eliminados, anonimizados ou conservados somente quando houver hipótese legal documentada.

Existe capacidade operacional de solicitar exclusão de conta de estudante sem responsabilidade escolar impeditiva, mas ela depende de protocolo autenticado e análise. Escola, turma, vínculo e conta institucional exigem encerramento coordenado. A exclusão em sistemas ativos e o ciclo de backups deverão ser explicados sem prometer remoção instantânea não comprovada.

11. Cookies, localStorage e tecnologias semelhantes

O produto guarda a preferência visual do dispositivo no localStorage. Apagar os dados do navegador pode remover essa preferência.

Não há analytics ativo, cookie publicitário ou rastreamento comportamental aprovado. Tecnologias estritamente necessárias à autenticação, segurança e entrega podem ser usadas pela aplicação ou pela infraestrutura, mas o inventário de nomes, finalidade, duração e controle ainda é [INVENTARIO_DE_TECNOLOGIAS].

Esta minuta não afirma que nenhum cookie ou registro técnico exista. A versão final deverá distinguir claramente tecnologias necessárias, preferências e qualquer categoria opcional antes de oferecer controles.

12. Segurança

Os agentes deverão adotar medidas técnicas e administrativas adequadas aos riscos, à natureza dos dados e aos direitos das pessoas. Controles de autorização, isolamento, recuperação, registro mínimo e resposta a incidentes deverão ser verificados e descritos em evidências próprias.

Esta minuta não promete criptografia em trânsito ou em repouso, certificação, auditoria independente, disponibilidade, RPO ou RTO enquanto cada afirmação não tiver evidência e escopo confirmados. Nenhum sistema será apresentado como infalível.

13. Incidentes de segurança

Um incidente confirmado deverá ser contido, registrado e avaliado quanto ao risco ou dano relevante. Quando houver dever de comunicação, o controlador deverá comunicar a ANPD e as pessoas titulares afetadas no prazo legal aplicável. A Resolução CD/ANPD nº 15/2024 estabelece, em regra, três dias úteis a partir da ciência pelo controlador, ressalvada legislação específica.

Se houver menores afetados, a mensagem deverá ser clara, adequada à idade e enviada também ao responsável verificado quando cabível, sem revelar dados a solicitante não autorizado. Ela deverá explicar natureza do incidente, dados envolvidos, riscos, medidas adotadas e canal de ajuda, na extensão possível.

O prazo de 72 horas não é apresentado nesta política como prazo legal brasileiro. Se for negociado entre operador e controlador, ele será apenas um SLA contratual interno para cooperação e não substituirá os três dias úteis aplicáveis à comunicação externa.

14. Atualizações da política

Uma versão final deverá conter identificador imutável, resumo das mudanças, data de publicação, data [DATA] de vigência e responsável [NOME_DO_RESPONSAVEL]. Mudanças materiais deverão ser destacadas e poderão exigir novo aviso, novo consentimento ou outra providência conforme a base legal.

Nenhuma atualização poderá transformar esta minuta em política vigente sem revisão jurídica, aprovação formal, preenchimento dos campos e publicação de outro documento sem o marcador DRAFT-NOT-FOR-ACCEPTANCE.

Gate para publicação

• identificar controlador, operador, encarregado e papéis por finalidade;
• aprovar bases legais, teste de legítimo interesse e avaliação do melhor interesse;
• aprovar faixas etárias e verificação de responsável;
• mapear Supabase, Vercel, regiões, contratos e transferências;
• definir retenção, exclusão coordenada e backups;
• validar inventário de cookies e metadados;
• comprovar medidas de segurança que serão declaradas;
• ativar e testar [EMAIL], [TELEFONE] e o responsável [NOME_DO_RESPONSAVEL];
• definir [DATA], concluir revisão jurídica e criar versão final.

Até lá, não use este documento para consentimento, aceite, cadastro ou tratamento de dados reais.