Skip to main content
Esta página cobre exclusivamente o HistorinhAI. Para a restrição de dado do lado da API de parceiro (o que a Algar recebe e, mais importante, o que ela nunca recebe), ver HistorinhAI — visão geral.

​
Por que este produto tem uma página própria

O HistorinhAI trata dado de criança e adolescente. Duas normas se somam aqui, não uma substitui a outra:
  • LGPD, Art. 14 — regras específicas para tratamento de dados de crianças e adolescentes, incluindo o requisito de consentimento parental em destaque.
  • ECA (Estatuto da Criança e do Adolescente, Lei 8.069/1990) — o arcabouço de proteção integral que informa o padrão de cuidado esperado, mesmo onde não fala de dado pessoal diretamente (a LGPD trata do dado; o ECA trata da criança).
Isso já é a razão por trás de uma decisão de arquitetura citada em outras páginas: o HistorinhAI roda em um projeto Supabase isolado dos demais produtos (ver Modelo de autenticação e Mapeamento de dados) — não é só organização de código, é isolamento de um tipo de dado que exige tratamento diferente do resto da plataforma.

​
Consentimento parental (Art. 14, §1º)

O Art. 14, §1º da LGPD exige consentimento específico e em destaque, dado por pelo menos um dos pais ou pelo responsável legal, para o tratamento de dados de criança. Sendo honestos sobre o estado atual: o fluxo de cadastro do HistorinhAI hoje gate-keeps corretamente por adulto (só quem cria a conta com e-mail e senha pode adicionar um perfil de criança — não existe caminho para uma criança se cadastrar diretamente), mas a tela de criação de conta (AccountStep) não apresenta hoje um texto de consentimento específico e em destaque nos termos literais do Art. 14, §1º — é uma tela de e-mail/senha sem uma declaração explícita do tipo “sou responsável legal e autorizo o tratamento dos dados da criança conforme a Política de Privacidade”. Isso é um gap real que identificamos ao revisar o componente, não um detalhe formal: registramos aqui como item de correção prioritário, e não vamos descrever uma tela que ainda não existe como se já estivesse em produção.
O que já é real hoje, e vale como parte da mitigação:
  • A ordem do onboarding é: 1) nome do responsável → 2) criação de conta (e-mail/senha, adulto) → 3) plano → e só então (dentro do app, já autenticado) o cadastro do perfil da criança. Uma criança não consegue, por si só, chegar ao ponto de fornecer dado próprio sem que um adulto já tenha criado e autenticado a conta.
  • O modelo de família (families/family_members) trata a conta como pertencendo a adultos — perfis de criança (children) são sempre subordinados a uma família com pelo menos um adulto responsável (owner_user_id), nunca uma entidade que se autogerencia.
Correção proposta (Roadmap imediato, não um item distante): adicionar, na etapa de criação de conta, um texto de consentimento específico e em destaque (não apenas um link genérico de “termos de uso” no rodapé) nomeando explicitamente o tratamento de dado da criança, com checkbox próprio e obrigatório antes de liberar o cadastro do primeiro perfil de criança. Isso é o desenho correto segundo a lei — sinalizamos a ausência em vez de descrevê-lo como já resolvido.

​
Melhor interesse da criança (Art. 14, §2º) — por que não se aplica como excludente aqui

O Art. 14, §2º permite, excepcionalmente, coletar dado de criança sem consentimento específico quando estritamente necessário para proteção da criança (ex: prevenção a dano, situações de segurança). Esse não é o fundamento usado pelo HistorinhAI — o produto coleta dado para fins de personalização de conteúdo educativo/lúdico e relatório aos pais, que é uma finalidade comercial legítima, mas não uma finalidade de proteção que dispensaria consentimento. Por isso o consentimento específico do §1º é a base correta a operacionalizar — a exceção do §2º não se aplica e não deve ser usada como atalho.

​
Proibição de perfilamento comercial de menores

Nenhum dado de criança alimenta segmentação de anúncio, é vendido, ou é compartilhado com terceiros para fins comerciais — isso inclui explicitamente o parceiro de distribuição (ex: Algar):
  • A API de parceiro só expõe entitlement (o assinante tem acesso ao produto, sim/não) e billing agregado (quantos exemplares ativos, para reconciliação de cobrança) — nunca perfil de criança, nunca histórico de leitura individual, nunca as competências mapeadas no relatório mensal. O detalhamento de exatamente quais campos a API expõe (e a garantia estrutural — não apenas de política — de que dado de criança nunca aparece nesses endpoints) está em HistorinhAI — visão geral.
  • Internamente, a personalização (seleção de história por perfil/objetivo) usa o dado da própria criança para servir aquela mesma criança — não para treinar segmentação vendável a terceiros, nem para segmentar publicidade dentro ou fora do produto. O HistorinhAI não veicula publicidade de terceiros.
  • A síntese de voz (TTS) do HistorinhAI passa por um provedor externo (ver Mapeamento de dados) apenas para converter texto em áudio — a chamada é autenticada e sujeita a quota (consume_tts_quota), e o texto enviado é o conteúdo da história, não um perfil da criança.

​
Retenção mais curta e específica

Estes prazos são a proposta da Googa para dado de criança — mais curtos que o prazo geral descrito em LGPD — Retenção, refletindo o cuidado adicional exigido pelo Art. 14 e pelo ECA.
Diferente do dado financeiro de um adulto (que pode ter prazo de guarda fiscal obrigatório — ver LGPD), não há justificativa legal para reter dado de criança além do necessário à própria prestação do serviço — por isso o prazo é deliberadamente mais curto e sem excepcionalidade fiscal.

​
Direito dos pais de excluir os dados do filho a qualquer momento

Isso já está implementado, não é uma promessa: o perfil de uma criança (children) é removível diretamente pelo responsável dentro do app, e a policy children_delete_family garante que só um membro da própria família pode fazer isso — sem depender de suporte manual. Ao excluir a conta inteira (não só um perfil de criança), a função delete_my_account() do HistorinhAI apaga reading_sessions, subscriptions e children da família antes de remover a família e a conta do responsável — descrito em detalhe técnico em Mapeamento de dados — propagação de exclusão. Não existe hoje uma cópia de backup ou log separado que sobrevive a esse fluxo com o perfil da criança identificável.

​
Resumo do que é GA vs. Roadmap nesta página