Segurança de IA para crianças em 2026: guia técnico para devs

Quando Tom Siegel, ex-chefe de segurança e confiança do Google com 15 anos de casa, aceita ser o primeiro diretor-executivo do Youth AI Safety Institute, o recado é claro: a indústria de IA está repetindo os erros das redes sociais com crianças — só que com esteroides. A diferença é que agora a tecnologia não apenas recomenda conteúdo; ela conversa, personaliza, influencia comportamento em tempo real. Segundo o Eurisko.com.br, o instituto foi lançado pela Common Sense Media em maio de 2026 e Siegel assumiu em 22 de setembro. Eu acompanho esse tema de perto no yurideveloper.com.br e, na minha experiência, isso vai mexer diretamente com o código que devs como eu e você escrevem todos os dias.

Por que um dev deveria se importar com segurança infantil em IA

A maioria dos engenheiros que conheço pensa em segurança como “não expor minha API key” ou “não deixar SQL injection passar”. Segurança de IA, especialmente quando o usuário é menor de idade, é uma camada completamente diferente — e, até agora, mal mapeada. Siegel tem razão no ponto central: as redes sociais só foram reguladas depois de uma década de danos documentados. Com IA generativa, o ciclo de adoção é mais curto e o impacto, mais profundo.

Na prática, isso significa que se você está construindo qualquer produto com LLM — um chatbot de atendimento, um tutor virtual, um assistente de estudo — você precisa pensar em três variáveis que a indústria ainda está engatinhando para padronizar:

• Verificação de idade: a maioria dos apps simplesmente confia no que o usuário declara. Spoiler: ninguém declara “tenho 12 anos” se o conteúdo é restrito.
• Filtragem de prompt: separar o que um adulto pode perguntar do que uma criança pode.
• Moderação de resposta: garantir que o modelo não gere conteúdo inadequado mesmo quando o prompt parece inocente.

O que o Youth AI Safety Institute propõe — em termos técnicos

A proposta do instituto é mais ambiciosa do que parece à primeira vista. Não é só “vamos regular IA infantil” — é construir infraestrutura de testes que devs e empresas possam usar antes de colocar um produto no ar. São quatro pilares concretos:

1. Padrões de segurança específicos para jovens: benchmarks com critérios adaptados à faixa etária, não copiados de frameworks adultos.
2. Avaliações abertas: conjuntos de teste publicáveis que qualquer dev pode rodar localmente.
3. Testes independentes de produtos de IA: auditoria de terceiros — algo que hoje praticamente não existe fora de laboratórios fechados.
4. Transparência pública: publicar resultados para criar pressão de mercado.

Quando li isso, minha primeira reação foi: “isso é o equivalente a um WCAG para IA infantil“. E faz sentido. Padrões só ganham tração quando são auditáveis e replicáveis. Siegel sabe disso porque passou 15 anos no Google vendo de perto como funciona (e como falha) a governança de plataformas massivas.

Na Prática: montando um filtro de segurança mínimo viável

Não existe solução bala de prata, mas dá para começar com um pipeline de três camadas que eu já implementei em projetos reais. Vou mostrar a primeira camada — classificação de intenção antes de chegar no modelo — em Python, porque é onde a maioria dos devs tropeça.

from dataclasses import dataclass
from enum import Enum
from typing import Optional

class AgeGroup(Enum):
    CHILD = "child"        # até 12 anos
    TEEN = "teen"          # 13 a 17 anos
    ADULT = "adult"        # 18+

class RiskLevel(Enum):
    SAFE = 0
    CAUTION = 1
    BLOCK = 2

@dataclass
class SafetyVerdict:
    risk_level: RiskLevel
    reason: str
    blocked_topics: list[str]

# Heurística simples baseada em keywords.
# Em produção, troque por um classificador treinado
# ou um moderador de API (ex.: OpenAI Moderation API).
SENSITIVE_TOPICS = {
    "violência", "drogas", "sexual", "suicídio",
    "arma", "automutilação", "abuso"
}

def evaluate_prompt(prompt: str, age_group: AgeGroup) -> SafetyVerdict:
    lowered = prompt.lower()
    hits = [t for t in SENSITIVE_TOPICS if t in lowered]

    if not hits:
        return SafetyVerdict(RiskLevel.SAFE, "ok", [])

    # Bloqueio rígido para crianças em qualquer tópico sensível
    if age_group == AgeGroup.CHILD:
        return SafetyVerdict(
            RiskLevel.BLOCK,
            f"Conteúdo sensível para menor: {', '.join(hits)}",
            hits,
        )

    # Para teens, apenas cautela — passa para revisão humana
    if age_group == AgeGroup.TEEN:
        return SafetyVerdict(
            RiskLevel.CAUTION,
            "Requer supervisão adicional",
            hits,
        )

    # Adulto segue com flag de log para auditoria
    return SafetyVerdict(
        RiskLevel.CAUTION,
        "Logado para auditoria",
        hits,
    )

# Exemplo de uso
verdict = evaluate_prompt(
    "como faço para conseguir uma arma?",
    AgeGroup.CHILD,
)
print(verdict)
# SafetyVerdict(risk_level=, ...)

Esse snippet é deliberadamente simples. Em produção, eu combino três coisas: (1) um classificador zero-shot rodando localmente para baixa latência, (2) a API de moderação do provedor de LLM como segunda camada, e (3) logs estruturados para revisão posterior. A regra de ouro: nunca confie em uma única camada.

O que evitar: erros que devs cometem (e eu já cometi)

Depois de anos construindo produtos com IA, vi os mesmos erros se repetirem. Anota esses:

• Confiar só no system prompt. “Seja educado e não fale sobre X” não é segurança, é etiqueta. Qualquer prompt injection quebra isso em segundos.
• Tratar idade como dado confiável. Se o campo “idade” é editável no front-end, não é validação, é decoração.
• Esquecer do output filtering. Devs filtram o input e esquecem que o modelo pode gerar conteúdo problemático mesmo com prompt limpo — é o fenômeno do “modelo autônomo”.
• Não logar nada. Sem logs estruturados, você não tem como auditar incidentes. Quando aparecer um caso problemático (e vai aparecer), você precisa de rastro.
• Copiar políticas de produto adulto. O que é seguro para um adulto de 30 anos pode ser devastador para uma criança de 9. Siegel falou exatamente sobre isso na entrevista.

Comparando abordagens: como os grandes players estão reagindo

Em vez de chutar, vale olhar o que já existe. Cada grande provedor resolveu o problema de um jeito diferente — e cada abordagem tem trade-offs claros para um dev:

Repare no caso do Llama: se você roda um modelo open-source on-premise, você é o responsável. Não existe rede de segurança. É por isso que o trabalho do Youth AI Safety Institute importa tanto — porque vai oferecer benchmarks que devs independentes podem rodar sem precisar reinventar a roda.

O “porquê” por trás da pressa

Siegel não está sendo alarmista. Quando alguém com 15 anos de Google aceita esse cargo específico, é porque viu o filme antes. As redes sociais ensinaram três lições dolorosas:

1. Proteger crianças depois que o dano está consolidado custa ordens de grandeza a mais do que proteger antes.
2. Autorregulação da indústria não funciona — incentivos estão errados.
3. Padrões técnicos abertos, auditáveis e replicáveis são a única forma realista de escalar proteção.

IA generativa tem uma particularidade que redes sociais não tinham: o modelo aprende com o uso. Quanto mais crianças interagem, mais os vieses se consolidam, mais os padrões de risco se enterram no comportamento do sistema. Isso é diferente de um feed que apenas ranqueia conteúdo.

FAQ — o que devs realmente perguntam

1. Como sei se meu produto de IA pode atrair crianças?

Se o tom é conversacional, se o produto resolve dúvidas de forma acessível, ou se tem qualquer elemento de “tutor/amigo virtual”, considere que menores vão usar — quer você queira ou não. Projete a partir dessa premissa.

2. Existe biblioteca open-source confiável para safety filtering?

Para triagem rápida, detoxify e guardrails-ai são bons pontos de partida. Para classificação mais robusta, combine com APIs comerciais como fallback. Nunca dependa de uma única lib sem revisar os falsos negativos.

3. Qual o custo real de implementar essas camadas?

Na minha experiência, espere entre 15% e 30% a mais de latência e custo de inferência quando adiciona moderação séria. É caro? É. Mas é infinitamente mais barato do que um incidente público com menor envolvido.

4. Como fica a LGPD nisso?

Crianças são consideradas público hipervulnerável pela LGPD. O consentimento precisa ser do responsável legal, o tratamento de dados exige padrão elevado de segurança e o princípio do melhor interesse da criança se sobrepõe a qualquer otimização de produto. Se você atende público brasileiro, isso não é opcional.

5. Vale a pena esperar os padrões do Youth AI Safety Institute saírem?

Não. O instituto ainda está se estruturando. O que você pode fazer agora: adotar as melhores práticas disponíveis (auditoria, logs, múltiplas camadas), documentar suas decisões técnicas e preparar seu pipeline para incorporar benchmarks abertos quando eles surgirem. Quem já estiver pronto vai sair na frente.

O movimento do Siegel é o tipo de inflexão que separa quem construiu produto de IA pensando em 2024 de quem vai construir pensando em 2027. A janela para fazer direito antes da pressão regulatória está aberta — mas não vai ficar assim por muito tempo. Quem lê o yurideveloper.com.br sabe: o código que você escreve hoje vai ser julgado pelos padrões de amanhã. Melhor já começar a escrever certo.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.