Blog

Nossas últimas novidades

Tempo de Leitura

min

Lei Felca para empresas: como adequar sistemas e aplicativos ao ECA Digital

Guia detalhado para empresas que desenvolvem sistemas e aplicativos entenderem a Lei Felca/ECA Digital e traduzirem a norma em arquitetura, produto, dados, moderação, publicidade, IA e governança.

20 de março de 2026

A Lei Felca saiu do jurídico e entrou no backlog.

Quando o mercado fala em “Lei Felca”, normalmente está se referindo ao apelido popular da Lei nº 15.211/2025, o Estatuto Digital da Criança e do Adolescente, em vigor desde 17 de março de 2026. Para empresas que desenvolvem, mantêm ou operam produtos digitais, a leitura mais útil da norma não é apenas “o que ela diz”, mas o que ela muda em requisitos, arquitetura, UX, dados, moderação, publicidade e governança.

Na prática, essa lei não atinge só aplicativos “infantis”. Ela alcança também produtos e serviços de tecnologia da informação de acesso provável por crianças e adolescentes. Isso inclui, dependendo do caso concreto, apps de conteúdo, redes sociais, jogos, marketplaces, streaming, edtechs, plataformas com UGC, apps com recursos sociais, ecossistemas de dispositivos, lojas de aplicativos, sistemas operacionais e, agora de forma expressa no decreto, interfaces de IA conversacional.

Na X-Apps, o ponto central é este: a adequação à Lei Felca não é um patch jurídico nem um modal de consentimento. É um projeto de produto + engenharia + dados + segurança + operação.

Este post foi escrito com foco em empresas que desenvolvem sistemas e aplicativos e precisam transformar a lei em plano de ação técnico e executivo.

O que você vai encontrar neste guia

quem realmente precisa se adaptar;
o que já vale hoje e o que ainda depende de detalhamento da ANPD;
como separar classificação etária, aferição de idade, consentimento do responsável e supervisão parental;
quais são os principais blocos de adequação para produto, engenharia, dados, segurança, growth, trust & safety e jurídico;
um roadmap prático para sair da leitura da lei e entrar em execução.

1. O primeiro ponto: sua empresa provavelmente está mais exposta do que imagina

A Lei nº 15.211/2025 se aplica a todo produto ou serviço de tecnologia da informação direcionado a crianças e adolescentes no País ou de acesso provável por eles. A própria lei define “acesso provável” com base em fatores como probabilidade de uso, facilidade de acesso e grau de risco à privacidade, à segurança ou ao desenvolvimento biopsicossocial, com destaque para serviços de interação social e compartilhamento em larga escala (art. 1º).

Isso muda completamente a pergunta que muitas empresas vinham fazendo.

A pergunta errada é:

“Nosso app foi feito para crianças?”

A pergunta certa é:

“Nosso produto pode ser usado por crianças ou adolescentes com facilidade, atratividade e risco relevante?”

Se a resposta for “sim”, ainda que parcialmente, a adequação entra no seu radar.

Uma forma prática de operacionalizar esse escopo

Uma boa forma de traduzir a lei para o backlog é classificar o portfólio em três níveis de exposição regulatória:

Nível 1: exposição alta

Produtos direcionados a crianças e adolescentes, ou com forte uso por esse público, especialmente quando houver:

recomendação algorítmica;
UGC;
chat, DM, voz ou vídeo entre usuários;
compras;
geolocalização;
monetização por publicidade;
IA conversacional;
creator economy.

Nível 2: exposição média

Produtos generalistas, mas com acesso provável por menores e funcionalidades de risco, como:

comunidades;
login social;
streaming com catálogo amplo;
marketplace com categorias sensíveis;
gamificação intensa;
coleta extensa de eventos e perfis.

Nível 3: exposição residual

Produtos claramente corporativos ou adultos, mas com alguma superfície pública ou recursos que possam, em tese, ser acessados por menores.

Aqui, a adequação tende a ser mais pontual, mas não desaparece.

2. O segundo ponto: empresas estão misturando quatro problemas diferentes

Um dos erros mais caros na adaptação é tratar tudo como se fosse “verificação de idade”. Não é.

Há pelo menos quatro controles diferentes, e eles precisam ser desenhados separadamente.

Controle	Para que serve	Onde costuma morar no produto
Classificação etária	Define a faixa etária adequada do conteúdo, recurso ou serviço	Catálogo, onboarding, páginas de produto, termos, loja
Aferição ou verificação de idade	Define se o usuário pode acessar determinado conteúdo, recurso ou jornada	Cadastro, login, desbloqueio de conteúdo, compra, API de sinal de idade
Consentimento ou autorização do responsável	Autoriza atos específicos de menor impacto progressivo ou exigidos por lei	Download, criação de conta, ativação de recursos, compras
Supervisão parental	Dá ao responsável meios contínuos de acompanhar, limitar e configurar o uso	Painel do responsável, device controls, conta vinculada, controles in-app

Misturar esses controles em um único campo “data de nascimento” é erro de arquitetura.

No backlog, classificação etária, aferição de idade, consentimento do responsável e supervisão parental precisam nascer como controles diferentes, com regras e superfícies próprias.

O que a lei exige em cada frente

A lei exige:

classificação e adequação etária do conteúdo (art. 8º);
mecanismos confiáveis de verificação de idade, com vedação de autodeclaração, para conteúdos, produtos e serviços impróprios, inadequados ou proibidos (art. 9º);
sinal de idade, supervisão parental e consentimento do responsável em lojas de aplicativos e sistemas operacionais (art. 12);
ferramentas efetivas de supervisão parental, com controles concretos e padrão mais protetivo (arts. 17 e 18).

O decreto aprofundou essa separação. Ele define aferição de idade, verificação de idade, sinal de idade e autodeclaração, além de reforçar que a implementação deve ser proporcional ao risco, com minimização de dados, auditabilidade e proteção da privacidade (arts. 2º, 24 e 25 do Decreto nº 12.880/2026).

3. O que já vale hoje e o que ainda será detalhado pela ANPD

Aqui também há muita confusão.

A regra prática é:

a lei já está em vigor;
o decreto já regulamentou pontos centrais;
a ANPD ainda vai detalhar requisitos técnicos adicionais, sobretudo em aferição de idade, mas isso não autoriza inércia.

O que já vale hoje

Já estão em vigor, entre outros pontos:

proteção prioritária e melhor interesse da criança e do adolescente;
segurança, privacidade e proteção de dados por design e por padrão;
gerenciamento de riscos;
prevenção de conteúdo ilegal, pornográfico e manifestamente inadequado;
dever de evitar uso compulsivo;
publicidade sem perfilamento;
vedação de perfis comportamentais para publicidade comercial;
supervisão parental com padrão mais protetivo;
obrigações de moderação, denúncia, retirada e recurso;
vedação de loot boxes em jogos direcionados ou de acesso provável por menores;
obrigação de manter representante legal no País.

O que ainda será detalhado

A ANPD foi designada como autoridade administrativa autônoma para o tema e já anunciou que seguirá uma abordagem faseada para soluções de aferição de idade.

Até 20 de março de 2026, a Agência:

publicou orientações preliminares sobre mecanismos confiáveis de aferição de idade;
divulgou página oficial do ECA Digital;
informou cronograma de implementação com monitoramento imediato de lojas de aplicativos e sistemas operacionais;
previu orientações definitivas a partir de agosto de 2026;
indicou período de adaptação e monitoramento entre agosto e novembro de 2026;
e apontou ações de fiscalização a partir de janeiro de 2027, especialmente para o tema de aferição de idade.

Isso importa porque permite uma leitura madura da situação:

não é verdade que tudo depende de regulamentação futura;
mas também não é correto fingir que já existe um manual técnico final da ANPD para cada cenário de produto.

O caminho certo é adequar o que já está claro na lei e no decreto, e preparar a arquitetura para absorver os atos complementares da ANPD.

A implicação prática é simples: a empresa já pode arrumar UX, dados, moderação e governança agora, deixando a arquitetura pronta para absorver os detalhamentos técnicos que a ANPD ainda publicará.

4. Como transformar a Lei Felca em backlog de produto e engenharia

Abaixo estão os principais blocos de adequação para empresas que desenvolvem sistemas e aplicativos.

4.1 Escopo, inventário e matriz de risco

Antes de escrever uma linha de código, a empresa precisa saber onde a lei incide.

O que a lei pede

A lei obriga fornecedores a:

realizar gerenciamento de riscos de recursos, funcionalidades e sistemas e seus impactos à segurança e à saúde de crianças e adolescentes (art. 8º);
mapear riscos e, em certos cenários de tratamento de dados, elaborar relatório de impacto, monitoramento e avaliação (art. 16, parágrafo único);
realizar avaliação de impacto à segurança e à saúde de crianças, com análise de riscos, probabilidade, gravidade, mitigação e acompanhamento contínuo, segundo o decreto (art. 47).

Como isso vira trabalho real

A empresa deve montar um inventário por produto e por funcionalidade, olhando para:

público-alvo declarado;
evidências de acesso provável;
classificação etária;
presença de UGC;
chat, voz, vídeo e interação com adultos;
sistemas de recomendação;
compras, microtransações e assinaturas;
monetização por publicidade;
uso de geolocalização;
coleta de dados sensíveis ou extensivos;
uso de IA generativa ou agentes conversacionais.

O resultado deve virar uma matriz de risco com dono, prioridade, medidas obrigatórias e prazo.

Entregáveis mínimos que fazem diferença

inventário de produtos e features afetadas;
classificação interna por risco;
registro de decisões de arquitetura;
mapa de fornecedores críticos;
plano de adequação com responsáveis por área;
comitê recorrente entre produto, engenharia, jurídico, segurança e dados.

Sem esse bloco, o resto tende a virar ação descoordenada.

4.2 Privacidade, segurança e proteção por padrão

Este é um dos centros de gravidade da lei.

O que a lei pede

A Lei nº 15.211 exige que produtos direcionados a crianças e adolescentes ou de acesso provável por eles operem por padrão com o grau mais elevado de proteção da privacidade e dos dados pessoais, com possibilidade de escolhas informadas sobre configurações menos protetivas (art. 7º).

Também exige:

sistemas projetados para impedir encontro com conteúdo ilegal, pornográfico e inadequado (art. 8º);
configurações desde a concepção que evitem uso compulsivo (art. 8º, IV).

O decreto ainda manda coibir práticas manipulativas, enganosas ou coercitivas, e enumera exemplos claros de dark patterns: obstrução de tarefas, exploração de vulnerabilidades cognitivas e dificuldade artificial para exercer direitos, alterar preferências ou interromper uso (art. 10).

Como isso vira backlog

Para times de produto e design, isso significa revisar defaults como:

perfil público;
mensageria aberta;
descoberta por desconhecidos;
compartilhamento de localização;
permissões amplas;
autoplay;
recompensas contínuas;
notificações excessivas;
caminhos confusos para sair, cancelar ou reduzir engajamento;
controles escondidos de privacidade e supervisão parental.

Regra prática para empresas de software

Se a sua estratégia de retenção depende de:

esconder pontos naturais de parada;
iniciar novos conteúdos sem solicitação;
premiar tempo de tela;
disparar urgência artificial;
dificultar cancelamento ou mudança de preferência;

você está muito perto de uma zona de incompatibilidade com o decreto.

O que recomendamos implementar

safe defaults por faixa etária;
feature flags de proteção infantil e adolescente;
padrão de UX sem dark patterns;
limites e janelas de notificação;
checklists obrigatórios em discovery e design review;
testes automatizados para defaults sensíveis;
revisão periódica de permissões e SDKs.

4.3 Aferição e verificação de idade: arquitetura, não improviso

Verificação etária é, talvez, o tema mais visível da lei, mas também o mais mal compreendido.

O que a lei pede

A lei exige mecanismos confiáveis de verificação de idade, vedada a autodeclaração, para conteúdos, produtos e serviços impróprios, inadequados ou proibidos para menores de 18 anos (art. 9º).

Também determina que:

lojas de aplicativos e sistemas operacionais adotem medidas proporcionais, auditáveis e tecnicamente seguras para aferir idade ou faixa etária (art. 12);
forneçam sinal de idade via API segura e com privacidade por padrão (art. 12, III);
os dados coletados para verificação de idade sejam usados somente para essa finalidade (art. 13);
os demais agentes da cadeia digital mantenham mecanismos próprios e respondam solidariamente pela proteção integral (arts. 14 e 15).

O decreto reforça a lógica de proporcionalidade, minimização, não rastreabilidade, segurança, interoperabilidade, transparência e auditabilidade (art. 24). E vai além: se houver coleta de documento, o tratamento deve se limitar ao atributo etário, com eliminação imediata e irreversível da imagem ou cópia do documento após captura da informação necessária (art. 24, § 3º).

O que isso significa para a engenharia

A arquitetura de idade não deve ser um campo solto em cadastro. Ela precisa ter, no mínimo:

política de classificação por risco;
definição de níveis de garantia etária;
motor de decisão para liberar, restringir, ocultar ou exigir etapa adicional;
integração com sinais de idade vindos de sistemas operacionais e lojas, quando disponíveis;
trilha de auditoria sobre qual atributo foi validado, sem reter dados além do necessário;
fluxo de contestação e retificação de classificação etária;
segregação rígida entre dados de idade e sistemas de ads, growth e perfilamento.

O que não fazer

Não transforme a exigência em uma solução preguiçosa de pedir documento de todos os usuários, em todas as jornadas, sem critério.

A própria regulação aponta para uma abordagem responsiva e proporcional ao risco. Em alguns contextos, a exigência será mais forte. Em outros, o desenho pode combinar:

classificação etária;
controles parentais;
bloqueio por padrão;
contas infantis;
sinais de idade do ecossistema do dispositivo;
e mecanismos próprios proporcionais ao risco.

Um princípio técnico importante

Aferição de idade não pode virar fonte de dados para marketing.

Se o produto usa o atributo etário captado para:

lookalike audiences;
segmentação comercial;
recomendação publicitária;
criação de perfis comportamentais;
enriquecimento de CRM;

o risco regulatório sobe muito.

4.4 Supervisão parental: não basta existir, precisa funcionar

Esse é outro ponto em que a lei sai do abstrato e entra no software de verdade.

O que a lei pede

Os fornecedores devem disponibilizar ferramentas acessíveis e fáceis de usar para apoiar a supervisão parental (art. 17), com:

informação em local de fácil acesso;
aviso claro quando a supervisão estiver ativa;
limitação e monitoramento de tempo de uso.

As configurações-padrão dessas ferramentas devem adotar o mais alto nível de proteção disponível e incluir, no mínimo:

restrição de comunicação com usuários não autorizados;
limitação de recursos que artificialmente estendem uso;
acompanhamento de uso adequado e saudável;
visualização e limitação imediata de tempo;
controle sobre sistemas de recomendação, inclusive com opção de desativação;
restrição ao compartilhamento de geolocalização;
revisão regular de ferramentas de IA;
e, quando tecnicamente viável, recursos de suporte emocional e bem-estar (art. 17, § 4º).

As ferramentas também devem permitir ao responsável:

gerenciar conta e privacidade;
restringir compras e transações;
identificar perfis adultos com quem a criança ou adolescente se comunica;
acessar métricas consolidadas de uso;
ativar ou desativar salvaguardas;
e operar tudo em língua portuguesa (art. 18).

Como isso vira produto

Aqui não adianta enterrar controles no quinto nível do menu.

A empresa precisa decidir:

haverá painel do responsável?
o vínculo será por conta vinculada, convite, API do sistema operacional ou combinação?
quais controles ficam no device e quais ficam no app?
como o usuário menor visualiza que está sob supervisão?
quais controles são reversíveis e quais não podem ser afrouxados sem responsável?

Casos em que isso fica ainda mais crítico

apps com DM, chat, voz ou vídeo;
jogos com compra e interação social;
apps com sistema de recomendação;
serviços com geolocalização;
marketplaces com compras em um clique;
apps com IA conversacional.

O que recomendamos implementar

dashboard do responsável com visão consolidada;
limites de tempo e janelas de uso;
bloqueio de compras por aprovação;
contatos aprovados;
geolocalização desativada por padrão;
feed personalizado desativável;
controles em português claro;
aviso visível de supervisão ativa;
logs de alteração de configurações.

4.5 Redes sociais, recursos sociais e moderação

Se o seu produto tem feed, comentários, comunidades, chat, upload, lives ou DMs, a adequação entra em outra camada de complexidade.

O que a lei pede

Nas redes sociais, a lei exige que contas de crianças e adolescentes de até 16 anos estejam vinculadas à conta de um responsável legal (art. 24).

Se o serviço for impróprio ou inadequado para esse público, o provedor deve:

informar claramente que o serviço não é apropriado;
monitorar e restringir conteúdo evidentemente voltado a atrair crianças e adolescentes;
aprimorar continuamente mecanismos de verificação de idade (art. 24, § 1º).

A lei também veda a criação de perfis comportamentais de crianças e adolescentes para direcionamento de publicidade comercial (art. 26).

O que a lei pede em moderação

Além disso, fornecedores devem:

disponibilizar mecanismos de notificação de violações (art. 28);
retirar conteúdo violador dos direitos de crianças e adolescentes independentemente de ordem judicial quando notificados por legitimados específicos (art. 29);
assegurar contestação, recurso, fundamento da remoção e informação sobre análise humana ou automatizada (art. 30);
manter mecanismos contra uso abusivo dos instrumentos de denúncia e procedimentos transparentes para sanções por abuso (arts. 32 e 33).

O decreto detalha que esses mecanismos de notificação devem ser acessíveis, gratuitos, efetivos e amplamente divulgados (art. 41), e reforça a retirada prioritária e imediata de conteúdo denunciado por vítima, representantes, Ministério Público, autoridades policiais ou entidades habilitadas (arts. 43 e 44).

Para produtos com UGC, chat ou recursos sociais, “ação imediata” deixa de ser slogan e vira requisito de fila, SLA, roteamento e preservação de evidências.

Como isso vira backlog

Times de trust & safety e engenharia precisam tratar isso como sistema, não como fila manual em e-mail.

É necessário definir:

taxonomia de violações;
canal de denúncia com identificador técnico do conteúdo;
fila prioritária de child safety;
roteamento para análise humana;
retenção de evidências e metadados;
fluxo de recurso;
indicação no aviso de retirada se houve análise humana ou automatizada;
detecção de abuso do canal de denúncia;
métricas operacionais e relatórios.

Para produtos com UGC, isto é essencial

Se a plataforma permite upload, comentários, compartilhamento ou contato entre usuários, a empresa deve assumir que a conformidade depende de:

tempo de resposta;
qualidade da triagem;
prova de diligência;
e capacidade de preservar evidências.

4.6 Publicidade, analytics e adtech: aqui está um dos maiores riscos escondidos

Muitas empresas subestimam esse bloco porque pensam só em banner publicitário. O problema é bem maior.

O que a lei pede

A lei veda o uso de técnicas de perfilamento para direcionamento de publicidade comercial a crianças e adolescentes. Também veda o uso de análise emocional, realidade aumentada, realidade estendida e realidade virtual para esse fim (art. 22).

Nas redes sociais, a vedação alcança a criação de perfis comportamentais com base em dados pessoais, inclusive os obtidos em verificação de idade, além de dados grupais e coletivos, para direcionamento de publicidade comercial (art. 26).

O decreto repete essa vedação e reforça que a publicidade aproveitando a deficiência de julgamento e experiência da criança é considerada abusiva (arts. 31 a 33 do Decreto nº 12.880/2026).

O que isso muda na prática

Se a empresa opera produto com menor de idade, ela precisa revisar urgentemente:

eventos enviados para analytics;
integrações com CDP;
segmentações em CRM;
audiências personalizadas;
remarketing;
lookalikes;
inferência de interesse;
uso cruzado de sinal etário para growth;
otimização de ads baseada em comportamento de menores.

Uma diretriz operacional útil

Os times de dados precisam separar claramente:

dados necessários para segurança e adequação legal;
dados para personalização funcional;
dados para publicidade comercial.

Essas três camadas não podem mais ser tratadas como se fossem a mesma coisa.

Esse é um dos pontos mais subestimados na adequação: dado etário e sinais de segurança não podem escorrer para CRM, adtech, lookalikes ou segmentação comercial.

O que recomendamos implementar

data lineage específico para atributos etários;
bloqueios técnicos de uso secundário;
revisão de tags, SDKs e pixels;
revisão contratual com ad networks e parceiros;
política de retenção e acesso;
painéis internos que provem que dados de verificação etária não alimentam publicidade.

4.7 Jogos, microtransações e creator economy

Esse capítulo ficou muito mais concreto do que muita empresa imaginava.

O que a lei pede para jogos

A lei veda caixas de recompensa (loot boxes) em jogos eletrônicos direcionados a crianças e adolescentes ou de acesso provável por eles (art. 20).

Também exige que jogos com interação entre usuários observem as salvaguardas da Lei nº 14.852/2024, especialmente em moderação, proteção contra contatos prejudiciais e atuação parental, e que limitem essas interações por padrão para assegurar consentimento do responsável (art. 21).

O decreto acrescenta que jogos com loot boxes devem realizar verificação de idade para impedir acesso de crianças e adolescentes a essa funcionalidade, salvo quando ofertarem versões sem loot box ou com a funcionalidade totalmente restrita por padrão (art. 23).

Para produtos com mecânicas de recompensa, o impacto pode chegar ao modelo de negócio: não é só mudar texto de termos ou política, mas revisar a própria dinâmica de monetização.

O que isso significa para o produto

Se o seu jogo ou app gamificado tem:

recompensa aleatória paga;
microtransação;
chat aberto;
guilda, squad, party, clã;
friend requests;
ranking com estímulo de permanência;

a adequação exige reavaliar modelo de negócio e não apenas publicar novos termos.

O que a lei pede para monetização de conteúdo com menores

O decreto trouxe um alerta adicional para plataformas de creator economy, vídeo e conteúdo impulsionado:

quando houver conteúdo monetizado ou impulsionado que explore, de forma habitual, a imagem ou a rotina de criança ou adolescente, o fornecedor deve exigir autorização judicial; se ela não existir, o conteúdo deve ser retirado imediatamente (art. 34 do Decreto nº 12.880/2026). A obrigação se aplica aos conteúdos cuja monetização ou impulsionamento se inicie em até 90 dias da publicação do decreto.

O que isso muda para empresas

Plataformas que pagam criadores, impulsionam conteúdo ou fazem distribuição patrocinada precisam criar:

fluxo documental para autorização judicial, quando cabível;
regras de elegibilidade para monetização;
heurísticas de detecção de conteúdo com exploração habitual da imagem ou rotina de menores;
revisão humana de casos sensíveis;
bloqueios preventivos em impulsionamento automático.

4.8 IA generativa, agentes conversacionais e interfaces em linguagem natural

Esse é um ponto novo e importante para empresas que vêm embarcando copilotos, assistentes e chatbots em seus produtos.

O que o decreto pede

O Decreto nº 12.880/2026 determina que fornecedores de produtos ou serviços capazes de geração de conteúdo e interação com usuários a partir de instruções em linguagem natural, incluindo modelos de linguagem, agentes conversacionais e interfaces similares, devem:

ser transparentes quanto ao caráter sintético e automatizado da interação;
prevenir manipulação comportamental de crianças e adolescentes;
avaliar risco algorítmico à segurança e à saúde;
implementar salvaguardas para o desenvolvimento físico, mental e psicossocial (art. 11).

Além disso, a própria lei menciona revisão regular de ferramentas de IA no contexto das ferramentas de supervisão parental e a possibilidade de desabilitar funcionalidades não essenciais ao funcionamento básico (art. 17, § 4º, VIII).

O que isso significa para software companies

Se sua empresa integra IA em apps acessíveis por menores, ela precisa revisar:

persona e tom do agente;
incentivos comportamentais;
persistência de conversa;
memória e personalização;
sugestões automáticas;
filtros de segurança;
possibilidade de desativar a funcionalidade;
trilha de auditoria e monitoramento;
escalonamento para humano em situações de risco.

Pergunta útil para product managers

Seu agente foi desenhado para ajudar o usuário ou para aumentar retenção a qualquer custo?

Se a resposta prática for a segunda, o produto precisa de revisão.

4.9 Transparência, prova de conformidade e governança

Adequação sem evidência é adequação fraca.

O que a lei pede

A lei exige relatórios semestrais, em língua portuguesa, para provedores de aplicações de internet com mais de 1 milhão de usuários crianças e adolescentes registrados no território nacional, com informações sobre denúncias, moderação, identificação de contas infantis, privacidade, consentimento parental e avaliações de impacto (art. 31).

Também exige representante legal no País para fornecedores abrangidos pela lei (art. 40).

O decreto detalha que:

os relatórios devem trazer dados proporcionais sobre o prosseguimento dado às notificações (art. 45);
deve haver avaliação de impacto à segurança e à saúde de crianças, com versão resumida pública em linguagem clara e acessível (art. 47);
e a ANPD habilitará instituições de pesquisa e jornalismo para acesso a dados, em condições específicas (art. 48).

Como isso vira governança de verdade

A empresa precisa ser capaz de provar:

qual é sua classificação de risco por produto;
quais defaults estão ativos;
como funciona a lógica de idade;
quais controles parentais existem;
como conteúdos são moderados;
quanto tempo leva para responder;
quais decisões são humanas e quais são automatizadas;
como dados etários são segregados;
como fornecedores terceiros são governados.

Entregáveis executivos importantes

política de proteção de crianças e adolescentes no ambiente digital;
comitê executivo com atas e responsáveis;
evidências de revisão de UX, ads e IA;
relatório de impacto;
plano de resposta a ofícios da ANPD;
trilha de auditoria por feature crítica;
registro de terceiros, SDKs e integrações.

Quando a empresa consegue provar impacto, decisão e trilha, a conversa com jurídico, auditoria, ANPD e liderança deixa de ser abstrata e vira governança operável.

5. Um ponto essencial: a lei não trata todos os serviços da mesma forma

Nem tudo é obrigação uniforme.

A própria Lei nº 15.211 prevê que várias obrigações serão aplicadas conforme características e funcionalidades do produto ou serviço, moduladas pelo grau de interferência do fornecedor sobre os conteúdos, pelo número de usuários e pelo porte do fornecedor (art. 39).

Além disso, a lei prevê dispensa parcial para certos serviços com controle editorial e conteúdos previamente licenciados, desde que cumpram condições como:

classificação etária;
transparência;
mediação parental;
e canais de denúncia adequados.

O decreto, na mesma linha, dispensa alguns provedores de adotar aferição de idade se disponibilizarem contas infantis adequadas à faixa etária e mecanismos efetivos de supervisão parental (art. 22 do Decreto nº 12.880/2026).

O que isso quer dizer para empresas

A melhor estratégia não é aplicar um único pacote de compliance sobre tudo.

A melhor estratégia é desenhar uma adequação proporcional:

mais intensa onde há maior risco;
mais enxuta onde o serviço é editorial, controlado e de baixo risco;
mas sempre documentada, justificável e auditável.

6. Roadmap prático de adequação

Abaixo está um modelo de roadmap que faz sentido para software houses, plataformas e empresas que operam produtos digitais.

Horizonte	Entregas prioritárias
0 a 30 dias	inventário de produtos e features afetadas; classificação de risco; freeze de lançamentos sensíveis sem review; revisão de defaults; mapa de SDKs e adtech; comitê executivo
31 a 90 dias	ajustes de privacy and safety by default; canal de denúncia e fila child safety; logs e trilha de auditoria; revisão de ads e segmentação; parental controls MVP; políticas internas e playbooks
91 a 180 dias	arquitetura de aferição de idade por nível de risco; integração com sinais de idade do ecossistema quando disponíveis; dashboards e relatórios; revisão de IA; processos de prova documental e contestação
Até agosto de 2026	absorção das orientações definitivas da ANPD para aferição de idade; ajuste fino de fluxos, APIs, minimização, interoperabilidade e auditoria
Até janeiro de 2027	fechamento das lacunas de aferição de idade e preparação para fiscalização mais intensa no tema, sem perder de vista que as demais obrigações já valem desde março de 2026

Esse tipo de visual ajuda a transformar a lei em cronograma real: uma parte entra já no primeiro ciclo de correção, outra depende de desenho estrutural e outra de absorção regulatória progressiva.

7. Erros comuns que devem ser evitados

tratar a lei como tema exclusivo do jurídico;
esperar um regulamento final para começar do zero;
usar só autodeclaração ou data de nascimento livre para bloquear conteúdo proibido;
reaproveitar dado de idade para growth ou publicidade;
esconder controles parentais em UX confusa;
manter autoplay, notificações agressivas e recompensas de permanência como padrão;
achar que um produto “generalista” está fora da lei;
ignorar fornecedores, SDKs, app stores e sistemas operacionais;
não produzir evidência documental de conformidade.

8. Checklist executivo para empresas que desenvolvem sistemas e aplicativos

A empresa já classificou quais produtos são direcionados ou de acesso provável por crianças e adolescentes?
Existe matriz de risco por funcionalidade?
Os defaults de privacidade, contato, localização e recomendação já foram revisados?
Há desenho claro de classificação etária, aferição de idade, consentimento do responsável e supervisão parental?
O produto bloqueia uso secundário de dados etários para publicidade e perfilamento?
Existe canal de denúncia acessível, gratuito, efetivo e com prioridade para child safety?
O fluxo de moderação informa fundamento da remoção e se houve análise humana ou automatizada?
Há proteção contra abuso dos instrumentos de denúncia?
Jogos, microtransações e recursos sociais foram reavaliados?
Recursos de IA já passaram por revisão específica para o ECA Digital?
Existe relatório de impacto e governança executiva com trilha de decisão?
A empresa está preparada para responder à ANPD com documentação técnica, organizacional e jurídica?

9. Como a X-Apps pode apoiar empresas nessa adaptação

Para muitas empresas, o maior risco não está em “não conhecer a lei”, mas em não conseguir traduzi-la para backlog, arquitetura e operação.

É exatamente aí que uma software house com visão de produto faz diferença.

Na prática, a X-Apps pode apoiar frentes como:

diagnóstico técnico-regulatório por produto e funcionalidade;
revisão de arquitetura para classificação etária, aferição de idade e segregação de dados;
implementação de controles parentais, moderação, trilhas de auditoria e governança operacional;
revisão de UX, jornadas críticas e padrões para remover dark patterns;
adaptação de analytics, adtech, SDKs e integrações de terceiros;
desenho de roadmap de adequação com entregas priorizadas por risco.

Isso é especialmente relevante quando a empresa precisa adequar um produto já em produção, com usuários ativos, dependências de legado e múltiplos times atuando ao mesmo tempo.

Nesses cenários, a melhor abordagem costuma ser combinar:

assessment rápido para mapear exposição;
plano de execução por ondas;
entregas técnicas incrementais que reduzam risco sem paralisar o negócio.

Conclusão

Para empresas que desenvolvem sistemas e aplicativos, a Lei Felca não é apenas uma norma sobre infância na internet. Ela é, na prática, uma nova camada de engenharia regulatória.

Ela muda como a empresa:

classifica o próprio produto;
desenha fluxo de cadastro e acesso;
estrutura privacidade por padrão;
define controles parentais;
opera moderação;
organiza publicidade e analytics;
integra IA;
documenta riscos e prova conformidade.

A empresa que tentar resolver isso apenas com política interna ou ajustes cosméticos de interface vai ficar exposta.

A empresa que entender a lei como um projeto de arquitetura + produto + governança tende a se adaptar com menos retrabalho, menos atrito regulatório e muito mais previsibilidade.

Na prática, o caminho mais eficiente é este: