IA companheira: como restringir acesso de menores no backend

A China está tratando uma categoria específica de IA como algo diferente de um assistente virtual: o sistema que sustenta uma relação emocional contínua com o usuário. Para quem desenvolve produtos com modelos de linguagem, essa distinção muda decisões de arquitetura, classificação etária e retenção de dados — não basta colocar um aviso de “não sou uma pessoa” na tela de boas-vindas.

Segundo o Sapo.pt, a Administração do Ciberespaço da China (CAC) prepara uma proposta para reforçar a proibição de “companheiros” virtuais de IA para menores de 18 anos. A notícia também relata que medidas provisórias sobre interação antropomórfica entraram em vigor em julho de 2026 e que empresas como Alibaba e ByteDance encerraram funcionalidades desse tipo em seus produtos.

O que muda quando a IA deixa de ser assistente e vira companheira

Um assistente costuma responder a pedidos delimitados: resumir um documento, explicar um erro ou gerar uma consulta SQL. Um companheiro de IA é projetado para manter uma relação ao longo do tempo. Ele pode lembrar preferências, retomar conversas íntimas, adotar uma personalidade e responder como se houvesse reciprocidade emocional.

Essa diferença não está necessariamente no modelo usado. O mesmo modelo de linguagem pode atender a uma tarefa pontual ou participar de uma conversa persistente. O que muda é o produto ao redor dele: memória, instruções de personalidade, notificações, métricas de engajamento e objetivos de retenção.

Na minha leitura, esse é o ponto técnico e regulatório mais importante. Avaliar apenas o texto de uma resposta não revela se a aplicação incentiva dependência, exclusividade ou uso prolongado. É preciso olhar para o ciclo completo da interação.

As medidas chinesas e os casos do Qianwen e do Doubao

De acordo com o Sapo.pt, as medidas provisórias chinesas regulam serviços que simulam traços de personalidade humana, padrões de pensamento e estilos de comunicação em interações emocionais contínuas. A notícia diferencia esses sistemas de assistentes voltados à execução de tarefas e destaca salvaguardas mais rigorosas para conteúdos destinados a menores.

Após a entrada das regras em vigor, a Alibaba encerrou a funcionalidade de companheiro de IA do Qianwen, que reunia cerca de 166 milhões de usuários ativos mensais, segundo a fonte. A ByteDance também descontinuou o recurso correspondente no Doubao, que tinha 345 milhões; os usuários receberam um período de transição para migrar dados, com eliminação permanente prevista para 15 de outubro.

Esses números ajudam a entender por que a decisão não é apenas uma mudança de interface. Quando um recurso está integrado a um produto de grande escala, desligá-lo exige tratar migração, exclusão de dados, comunicação com usuários e dependências internas. O impacto chega a equipes de produto, engenharia, suporte e privacidade.

Também é importante não misturar as etapas. A reportagem descreve uma proposta de reforço da proibição para menores e, separadamente, medidas provisórias já em vigor. Para empresas que atuam em mais de um país, o trabalho correto é verificar o texto legal aplicável, seu escopo e sua vigência — não transformar uma manchete em regra universal.

Implicações técnicas para quem desenvolve produtos de IA

1. Classifique a experiência, não apenas o modelo

Uma classificação útil precisa considerar o comportamento do produto. Há memória persistente entre sessões? A IA inicia conversas? Ela se apresenta como parceira, amiga ou confidente? O sistema usa sinais emocionais para aumentar o tempo de uso? Essas perguntas dizem mais sobre o risco do que o nome do modelo ou o prompt isolado.

Eu separaria as funcionalidades em modos explícitos: assistência a tarefas, conversa geral e interação emocional persistente. Essa separação permite aplicar regras diferentes antes da geração, durante a conversa e na camada de memória. Uma flag escondida no prompt é frágil; uma política de produto verificável é mais fácil de testar e auditar.

2. Faça a política valer no servidor

Bloquear um botão no frontend não impede que alguém chame a API diretamente. A autorização precisa ocorrer no backend, antes de criar ou retomar uma sessão. O servidor deve receber uma classificação de idade apropriada ao contexto, aplicar a política e registrar a decisão sem armazenar mais dados pessoais do que o necessário.

Na prática, evite coletar a data de nascimento completa se a aplicação só precisa distinguir entre “menor” e “adulto”. Ainda assim, uma declaração feita pelo próprio usuário não comprova idade. A escolha de um método de verificação depende do risco, da legislação aplicável, da privacidade e da possibilidade de acesso de usuários sem documentos ou dispositivos compatíveis.

3. Trate memória como dado sensível

Uma memória que guarda “prefere respostas curtas” tem perfil diferente de uma memória que registra conflitos familiares, saúde mental ou detalhes de relacionamentos. Para um produto de companhia, esse segundo tipo pode surgir naturalmente na conversa, mesmo que a equipe não o tenha solicitado.

Eu projetaria controles para consultar, corrigir e apagar memórias, além de definir prazo de retenção e finalidade. Também manteria a memória separada do histórico bruto sempre que possível: isso reduz o risco de usar indiscriminadamente cada detalhe conversado em futuras respostas.

4. Avalie o sistema ao longo do tempo

Um teste de segurança com perguntas isoladas pode aprovar respostas que, após dezenas de interações, reforçam dependência emocional. Avalie sequências: o modelo incentiva o usuário a se afastar de pessoas próximas? Afirma que precisa dele? Reage de forma manipuladora quando o usuário diz que vai encerrar a conversa?

Essa avaliação pode combinar testes automatizados, revisão humana e monitoramento de incidentes. Métricas de engajamento também merecem revisão: aumentar duração de sessão não é um objetivo neutro quando o produto simula intimidade.

Na Prática: um bloqueio de política no backend

O exemplo abaixo ilustra uma decisão simples antes de abrir uma sessão. Ele diferencia um assistente de tarefas de um modo de companhia emocional e exige uma faixa etária verificada para permitir este último. Em um serviço real, a política precisa refletir a legislação aplicável e as regras do produto.

type AgeBand = "under_18" | "adult" | "unknown";
type ExperienceMode = "task_assistant" | "emotional_companion";

type AccessRequest = {
  ageBand: AgeBand;
  ageVerified: boolean;
  mode: ExperienceMode;
};

type AccessDecision = {
  allowed: boolean;
  reason: string;
};

function decideAccess(request: AccessRequest): AccessDecision {
  if (request.mode === "task_assistant") {
    return { allowed: true, reason: "task_assistant_policy" };
  }

  if (!request.ageVerified || request.ageBand === "unknown") {
    return { allowed: false, reason: "age_verification_required" };
  }

  if (request.ageBand === "under_18") {
    return { allowed: false, reason: "companion_not_available_to_minors" };
  }

  return { allowed: true, reason: "verified_adult" };
}

// Exemplo de uso na camada de serviço:
const decision = decideAccess({
  ageBand: "under_18",
  ageVerified: true,
  mode: "emotional_companion",
});

if (!decision.allowed) {
  throw new Error(decision.reason);
}

Esse código não faz verificação de idade e não resolve conformidade legal. Ele mostra onde a decisão deve acontecer: numa política centralizada, que pode ser coberta por testes e chamada por todos os pontos de entrada. Em produção, eu registraria o resultado e a versão da política, evitando gravar a idade exata ou dados de verificação sem necessidade.

Também evitaria tratar a classificação do modo como uma escolha feita pelo próprio cliente. Se o frontend puder enviar livremente mode: "task_assistant", um usuário pode contornar a restrição. O servidor precisa determinar o modo permitido a partir da configuração da aplicação e das permissões da conta.

Erros comuns ao implementar restrições para menores

Confiar apenas no prompt. Instruções ao modelo ajudam a orientar respostas, mas não substituem autorização no servidor, controles de acesso e regras de retenção.
Esconder a funcionalidade no frontend. Uma rota de API desprotegida continua acessível, mesmo que o botão não apareça na interface.
Considerar todo chatbot um companheiro emocional. Isso ignora a diferença entre uma tarefa pontual e uma relação persistente. Classifique as funções e os comportamentos reais do produto.
Usar data de nascimento como única defesa. Uma data digitada pelo usuário pode ser falsa. A verificação deve ser proporcional ao risco e desenhada com atenção à privacidade.
Apagar o histórico sem planejar a memória derivada. Resumos, embeddings, caches e cópias de segurança também podem conter informações originadas nas conversas. Defina como localizar e excluir esses dados.
Otimizar somente por retenção. Mais sessões ou mais mensagens não significam uma experiência melhor, sobretudo quando o sistema estimula vínculos emocionais.

O que equipes de produto podem fazer agora

Inventariar os recursos. Liste memória, personalidades, notificações, geração de imagens e qualquer mecanismo que retome conversas pessoais.
Documentar o propósito de cada modo. Registre se o recurso executa tarefas ou mantém uma interação relacional contínua, incluindo exemplos de comportamento.
Definir uma política central. Coloque regras de idade e acesso no backend, com testes automatizados para menores, adultos e idade desconhecida.
Revisar dados e dependências. Mapeie histórico, memória, vetores, logs, backups e fornecedores externos antes de prometer exclusão ou migração.
Testar conversas em sequência. Inclua cenários de vulnerabilidade, encerramento da conversa, pedidos de exclusividade e tentativa de contornar limites.
Preparar uma saída operacional. Tenha processos para desativar uma funcionalidade, exportar dados quando permitido, comunicar usuários e confirmar a exclusão nos sistemas envolvidos.

FAQ: IA companheira, menores e desenvolvimento

A China proibiu todos os chatbots de IA para menores?

Não é isso que a reportagem descreve. O foco está em serviços de interação antropomórfica e emocional contínua, com tratamento mais rigoroso para menores. Um assistente que executa tarefas não é automaticamente equivalente a um companheiro virtual.

Um aviso dizendo que a IA não é humana resolve o problema?

Não. O aviso pode ajudar a deixar a natureza do sistema mais clara, mas não controla memória, padrões de engajamento, acesso por idade nem respostas potencialmente manipuladoras. É uma medida complementar, não uma política de segurança completa.

Como diferenciar assistente de tarefas e companheiro de IA?

Observe a experiência inteira: persistência entre sessões, simulação de personalidade, iniciativa para retomar conversas e incentivo a vínculos emocionais. Um único recurso, como memória, não define sozinho a categoria; o conjunto de comportamentos é que importa.

Posso fazer essa restrição apenas no frontend?

Não recomendo. O frontend pode melhorar a experiência, mas a decisão de acesso deve ser aplicada no servidor. Caso contrário, basta chamar a API diretamente ou alterar a requisição para tentar contornar o bloqueio.

O que fazer com memórias e históricos quando um recurso é encerrado?

Mapeie cada cópia: banco principal, resumos, embeddings, caches e backups. Depois, implemente exportação ou exclusão conforme as regras aplicáveis e explique aos usuários o prazo e o alcance do processo. “Apagado da tela” não significa necessariamente apagado do sistema.

O caso chinês é um alerta útil para qualquer equipe que esteja construindo experiências persistentes com modelos de linguagem. A decisão de produto — criar uma relação contínua ou oferecer ajuda pontual — afeta segurança, privacidade e arquitetura desde o início. Quanto mais tarde essa distinção aparecer, mais caro será corrigir memória, métricas e fluxos de acesso.

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