> ## Documentation Index
> Fetch the complete documentation index at: https://developers.googa.com.br/llms.txt
> Use this file to discover all available pages before exploring further.

# Proteção de dados de crianças — LGPD Art. 14 & ECA

> Consentimento parental, proibição de perfilamento comercial, retenção reforçada e o direito dos pais de excluir os dados do filho — o tratamento específico do HistorinhAI.

<Info>
  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](/historinhai/overview).
</Info>

## 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](/architecture/supabase-auth-model) e [Mapeamento de
dados](/security/data-processing)) — 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º)

<Warning>
  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.
</Warning>

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](/historinhai/overview).
* 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](/security/data-processing)) 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

<Info>
  Estes prazos são a proposta da Googa para dado de criança — mais curtos que o prazo geral
  descrito em [LGPD — Retenção](/security/lgpd#retenção), refletindo o cuidado adicional exigido
  pelo Art. 14 e pelo ECA.
</Info>

| Categoria                                                             | Prazo proposto                                                                                                                                                |
| --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Histórias lidas / sessões de leitura da criança (telemetria granular) | 6 meses, depois agregado só ao nível de competência (ex: "Vocabulário +6") sem o texto/evento original                                                        |
| Relatório mensal enviado aos pais                                     | Mantido enquanto a conta estiver ativa; removido junto com a exclusão do perfil da criança                                                                    |
| Perfil da criança (idade, interesses, desafio do mês)                 | Enquanto o perfil existir — excluído imediatamente quando os pais removem o perfil ou a conta (ver abaixo), sem período de retenção "por segurança" adicional |

Diferente do dado financeiro de um adulto (que pode ter prazo de guarda fiscal obrigatório — ver
[LGPD](/security/lgpd#retenção)), 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](/security/data-processing#como-um-pedido-de-exclusão-se-propaga). 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

| Item                                                                               | Status                                                                                    |
| ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Adulto obrigatório antes de qualquer dado de criança (gate estrutural)             | **GA**                                                                                    |
| Isolamento do dado de criança em projeto Supabase próprio                          | **GA**                                                                                    |
| Exclusão de perfil/conta de criança sob controle dos pais, a qualquer momento      | **GA**                                                                                    |
| Nenhum dado de criança exposto à API de parceiro (estrutural, não só política)     | GA no desenho da Platform API — ver [HistorinhAI — visão geral](/historinhai/overview)    |
| Texto de consentimento específico e em destaque (Art. 14, §1º) na tela de cadastro | **Roadmap — gap identificado, correção prioritária**                                      |
| Retenção mais curta automatizada (agregação após 6 meses)                          | Roadmap — hoje a retenção não é purgada automaticamente, só por exclusão explícita        |
| RIPD formal documentando este tratamento                                           | Roadmap — ver [LGPD — RIPD](/security/lgpd#ripd-relatório-de-impacto-à-proteção-de-dados) |