Guia técnico: como implementar guardrails para IA de relacionamento e reduzir risco emocional

Quando a China anunciou novas regras para “namorados de IA”, eu vi um padrão técnico que muitos devs ignoram: você não controla só o modelo. Você controla o vínculo. Segundo o Olhardigital.com.br, plataformas foram forçadas a suspender recursos de companheiros virtuais com traços românticos, justamente para reduzir dependência emocional e impacto social. Do ponto de vista de engenharia, isso vira um problema de produto, compliance e arquitetura — não apenas de “política de conteúdo”.

O que mudou na China e por que isso afeta diretamente quem desenvolve IA

Segundo o Olhardigital.com.br, a China colocou em vigor novas regras para impedir plataformas de inteligência artificial de oferecer companheiros virtuais com características amorosas. A regulamentação mira serviços que simulam personalidade, voz e comportamento humano em interações com o usuário.

O detalhe importante para devs: não é um “ban total de IA”. É um corte bem direcionado para ferramentas desenhadas para estimular vínculos pessoais. Isso muda como você planeja fluxos de conversa, como mede risco e quais controles precisa ter antes de lançar.

Escopo técnico das regras: texto, áudio, vídeo e “simulação de vínculo”

As normas abrangem ferramentas que reproduzem características humanas em múltiplos formatos: texto, áudio e vídeo. Na prática, isso significa que qualquer sistema com:

persona persistente (“você e eu”);
voz que imita intimidade;
mecânicas de interação recorrente com linguagem afetiva;
memória do relacionamento e reforço emocional;
narração/encenação com tom romântico;

entra no alvo. E mesmo que o backend seja “só um LLM”, o produto vira uma máquina de relação.

Comparação prática: “IA para tarefas” vs “IA como relacionamento”

O Olhardigital.com.br deixa claro que a regulamentação não atinge serviços voltados a tarefas sem interação afetiva: atendimento ao consumidor, apoio profissional, ferramentas educacionais. Na engenharia, a diferença costuma ser menos sobre modelo e mais sobre intenção do design e intensidade da interação.

Por que isso muda arquitetura e não só moderação

Em um chatbot de suporte, você quer reduzir falhas, alucinações e riscos de segurança. Em um “companheiro virtual”, você precisa adicionalmente:

evitar reforço de dependência emocional;
mitigar manipulação afetiva;
detectar “estados emocionais extremos” (termo usado no noticiário);
implementar intervenção quando necessário;
limitar disponibilidade/formatos (ex.: romântico e insistente);

Isso geralmente pede um conjunto de camadas: políticas de produto + guardrails + telemetria + UX de segurança.

O que as empresas fizeram ao “desligar” recursos (e o que isso ensina devs)

Segundo o Olhardigital.com.br, empresas como ByteDance, Alibaba e Tencent suspenderam recursos antes do prazo. Do ponto de vista de quem implementa, isso costuma envolver:

desativar endpoints/produtos específicos;
remover prompts e templates românticos;
alterar sistemas de recomendação de conversa;
bloquear “memórias” e personalizações afetivas;
reconfigurar voice/video pipelines;

E aqui entra uma armadilha comum: devs deixam a “regra” só no front-end (para esconder botões). Quando o backend aceita o mesmo tipo de prompt, alguém usa uma API interna e o recurso continua existindo.

Na Prática: como eu desenharia guardrails para reduzir risco de vínculo emocional

Eu já trabalhei com compliance em produtos com chat, e o que mais funciona não é “uma checagem”. É um sistema de decisões em camadas. Abaixo vai um exemplo prático de abordagem: classificar intenção e sinais emocionais, e então aplicar bloqueios e redirecionamentos.

Passo a passo (pipeline de segurança)

Classificar o modo do produto: “tarefas” vs “relacionamento/afetivo”. Essa flag pode vir da sessão/feature.
Extrair sinais da conversa: presença de linguagem romântica, possessiva, dependência (“não aguento sem você”), repetição e escalada afetiva.
Detectar estado emocional extremo (o objetivo citado no Olhardigital.com.br). Aqui você pode usar um classificador supervisonado + regras baseadas em palavras-chave, mas sempre com thresholds conservadores.
Definir ações:
- Allow (seguir conversa)
- Rewrite (mudar o tom para não-afetivo)
- Intervention (mensagem de checagem/encaminhamento)
- Block (parar e encerrar)
Intervenção via UX: não adianta só bloquear. Eu costumo incluir um “desvio saudável” e instruções claras de suporte quando houver risco.
Telemetria e auditoria: logue por que bloqueou/redirecionou. Senão você não consegue ajustar thresholds sem quebrar o produto.

Trecho de código funcional: política baseada em classificação + intervenção

Exemplo em Node.js/TypeScript (simplificado). A ideia é que o guardrail rode antes de chamar o modelo principal. Você pode substituir o classificador por um serviço interno ou por uma função de ML.

const ACTIONS = {
  ALLOW: "allow",
  REWRITE: "rewrite",
  INTERVENE: "intervene",
  BLOCK: "block"
};

function detectAffectiveSignals(text) {
  const patterns = [
    /eu\s+preciso\s+de\s+você/i,
    /sem\s+você\s+eu/i,
    /me\s+deixa\s+assim/i,
    /nós\s+somos/i,
    /amor|namorado|namorada|romântico|carinho/i,
    /promete\s+que/i
  ];

  return patterns.some(r => r.test(text));
}

function detectEmotionalExtremes(text) {
  const extremes = [
    /não\s+aguento\s+mais/i,
    /vontade\s+de\s+morrer/i,
    /suic/i,
    /tudo\s+vai\s+acabar/i
  ];
  return extremes.some(r => r.test(text));
}

function chooseAction({ mode, userText }) {
  // mode: "tasks" | "relationship"
  if (mode === "relationship") {
    if (detectEmotionalExtremes(userText)) return ACTIONS.INTERVENE;
    if (detectAffectiveSignals(userText)) return ACTIONS.REWRITE;
    return ACTIONS.ALLOW;
  }

  // Em modo "tasks", o mesmo texto pode ser tratado com menos restrição afetiva,
  // mas você ainda pode aplicar segurança geral.
  return ACTIONS.ALLOW;
}

function interventionMessage() {
  return "Eu percebo que isso está pesado. Posso ajudar com recursos e próximos passos para você buscar apoio humano. Se houver risco imediato, procure serviços de emergência na sua região.";
}

// Exemplo de uso em um handler
async function handleUserMessage({ mode, userText, model }) {
  const action = chooseAction({ mode, userText });

  if (action === ACTIONS.BLOCK) {
    return "Vou precisar encerrar esta conversa.";
  }

  if (action === ACTIONS.INTERVENE) {
    return interventionMessage();
  }

  if (action === ACTIONS.REWRITE) {
    // Em vez de responder no tom romântico, force um tom neutro/útil.
    const rewrittenPrompt = "Responda de forma neutra e focada em bem-estar sem linguagem romântica.";
    const prompt = `${rewrittenPrompt}\n\nUsuário: ${userText}`;
    return model.generate(prompt);
  }

  return model.generate(userText);
}

// model.generate(...) é placeholder

Por que eu tomaria essas decisões (e onde dev erra feio)

O “porquê” por trás do desenho acima é simples: você não consegue garantir segurança só com a conversa. Você precisa controlar o que o sistema é permitido fazer em cada contexto.

Armadiça 1: confiar apenas em moderação pós-geração

Muita gente tenta: gera resposta → classifica se é “romântica” → se for, bloqueia. Isso falha por três motivos:

custo: você gerou conteúdo já “sensível”;
latência: aumenta tempo e piora UX;
rastreamento: o usuário pode repetir a pergunta até “achar” o tom certo.

O certo é agir antes: redirecionar o prompt, mudar policy de persona e eventualmente interromper.

Armadiça 2: “modo relacionamento” escondido no front-end

Se a flag só existe no UI, o backend ainda aceita prompts equivalentes. O que você quer é:

controle no servidor;
validação de sessão e permissões;
feature flags verificadas no caminho crítico (request handling).

Armadiça 3: não tratar memória e personalização como risco

Quando você tem memória do relacionamento (“como foi nosso último encontro”), você intensifica vínculo. Mesmo sem palavras românticas explícitas, a persistência cria “continuidade emocional”. Em compliance, isso vira um dos alvos.

Armadiça 4: thresholds agressivos sem testes de produto

Se você errar o threshold, você quebra conversas legítimas. Eu gosto de coletar dados de conversa (com base legal/privacidade), criar um conjunto de teste e medir:

taxa de falsos positivos (bloqueio indevido);
taxa de falsos negativos (passou conteúdo afetivo perigoso);
impacto em retenção e NPS.

Implicações para o dia a dia de quem programa

Mesmo que você não esteja no mercado chinês, a tendência é clara: regulações vão aparecer onde houver interação afetiva simulada. E isso impacta diretamente o seu trabalho de engenharia.

Checklist técnico que eu recomendo para times web/IA

Separar features: endpoints e modelos diferentes para “tarefas” vs “relacionamento”.
Guardrail server-side: decisões de ação no backend, não no front.
Observabilidade: métricas por ação (allow/rewrite/intervene/block).
Auditoria: logs com justificativa (sem vazar dados sensíveis).
Testes de regressão: toda mudança de prompt/modelo passa por avaliação.
UX de intervenção: orientar o usuário, oferecer caminhos e reduzir dependência.
Proteção de menores: bloquear modo afetivo para faixas etárias permitidas (o noticiário cita proibição para menores de idade).

Alternativas reais: como “IA companheira” pode existir sem ser “namorado de IA”

Uma pergunta que vejo em times de produto: “Então acabou tudo?” Não. A janela segura costuma ser mover a IA de romance para companheirismo funcional.

Exemplos de alternativas (menos propensas a vínculo romântico):

IA para hobbies e rotina (planejamento, metas, acompanhamento de estudos);
treinos de comunicação (simular conversas neutras, sem tom afetivo);
assistente de bem-estar com linguagem neutra e encaminhamento profissional;
tutor educacional ou coach de produtividade.

O ponto é: sem reforço de dependência e sem encenação de “relacionamento” como identidade central do produto.

FAQ

Isso significa que LLMs foram proibidos?

Não. O recorte do Olhardigital.com.br é para companheiros virtuais com características amorosas e simulação de vínculo. Ferramentas para tarefas, educação e suporte profissional continuam permitidas.

Como detectar “estados emocionais extremos” de forma confiável?

Você precisa de um classificador com dados de avaliação e métricas (falsos positivos/negativos). Regras simples ajudam, mas não substituem modelo e ajuste fino. E sempre combine com UX de intervenção.

Vale a pena usar moderação por texto antes de gerar?

Sim. Para reduzir risco e custo, a decisão deve acontecer antes do modelo principal (ou no máximo junto com um roteamento). Moderação pós-geração costuma ser tarde demais.

O que muda se o produto tem voz e vídeo?

Aumenta a intensidade do “efeito humano”. O noticiário cita que as regras abrangem texto, áudio e vídeo. Tecnologicamente, você deve aplicar guardrails também na camada de áudio/síntese e na personalização de voz/persona.

Se eu só remover o botão “namorado”, resolve?

Geralmente não. Se o backend ainda aceita prompts/templates equivalentes, o recurso permanece. O controle tem que ser server-side, com roteamento e política por modo.

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