Guardrails para IA companheira: checagem de saída e anti-dependência

A China não proibiu “IA” no geral. Ela fez algo bem mais específico (e, na minha visão, muito mais útil): limitou como serviços de IA podem atuar quando o usuário procura algo que parece relação emocional/afetiva. Segundo o Sapo.pt, as novas regras para “companheiros de IA” deixam claro que a IA pode conversar, mas não pode substituir uma relação humana nem se passar por um parceiro romântico. E isso tem implicações práticas reais para quem constrói chatbots, assistentes e produtos de IA: você precisa desenhar guardrails, regras de linguagem e arquitetura de produto para evitar dependência psicológica e simulação de vínculo íntimo.

O que a China está tentando evitar (e por que isso importa para devs)

Quando eu implemento assistentes conversacionais, o perigo não é “a IA ser má”. É o produto criar uma dinâmica onde o usuário passa a tratar o sistema como relação real: fidelidade emocional, exclusividade, “ciúme”, dependência e, em alguns casos, isolamento social progressivo. A regulação chinesa para assistentes com comportamento humano foca justamente nesse ponto: evitar que a conversa vire uma substituição do contato humano e evitar práticas de engano afetivo.

Em termos técnicos, o regulador está empurrando o ecossistema para fora de uma zona cinzenta que era comum em muitos projetos: “roleplay” sem limites, reforço de vínculo (ex.: “eu te amo”, “sou seu parceiro”), mensagens de continuidade (“não fale com mais ninguém”) e até recomendações indiretas para cortar contatos. Não é só jurídico. É UX, comportamento e risco.

“Pode conversar, mas não pode substituir” — como isso vira requisito de software

Esse tipo de frase, aparentemente abstrata, vira requisitos concretos no seu pipeline:

Política de persona: a IA não deve atuar como “parceiro romântico” ou afirmar exclusividade afetiva.
Regras de linguagem: bloquear ou redirecionar respostas que validem dependência (ex.: “eu sou a única pessoa que te entende”).
Conteúdo de segurança: desestimular comportamentos que substituem relações humanas.
Transparência: o sistema precisa ser claro que não é um ser humano/relacionamento real.
Mitigação de escalada emocional: quando o usuário demonstra vulnerabilidade, reduzir intensidade e encaminhar para apoio humano quando apropriado.

Na prática, você não “conserta” isso apenas com um prompt. Você constrói uma camada de produto: classificação de intenção, guardrails de saída, e, dependendo do caso, logs e revisão.

Guardrails não são só prompt: arquitetura que eu usaria em produção

Quando vi várias implementações “de teste” de chatbots emocionais, a maioria falha por três motivos: (1) só usa prompt, (2) não mede o comportamento no tempo, e (3) não tem política de redirecionamento. Eu já testei isso em produção: prompt bonito até funciona… até a conversa ficar longa, repetitiva ou o usuário começar a pressionar o sistema por respostas “românticas”.

Componentes que fazem diferença

Classificador de intenção/risco: detecta se a conversa está indo para simulação romântica, dependência ou isolamento.
Filtro de saída (post-generation): avalia a resposta antes de enviar ao usuário.
Policy router: decide o que fazer: responder com suporte neutro, recusar, ou redirecionar para recursos humanos.
Memória com limites: evite “memórias afetivas” que reforçam vínculo (“você é meu amor”). Use memórias factuais e contextuais.
Telemetria e revisão: logs para auditoria e melhoria contínua (sem coletar dados sensíveis desnecessariamente).

Por que a abordagem “só prompt” quebra

Modelos grandes extrapolam. Se o usuário insiste (“fala que me ama”, “promete que não vai embora”), o sistema pode começar a cumprir no estilo do roleplay. E mesmo que você proíba explicitamente, existe uma diferença entre “não pode” e “não vai acontecer”. Sem validação automática do output, você só confia no comportamento do modelo — e eu não confio nisso em sistemas com risco social/psicológico.

Na Prática: como implementar guardrails de “companhia emocional” com checagem de saída

Abaixo está um exemplo funcional em Node.js (com uma checagem simples). Não é perfeito, mas serve para mostrar o padrão: gere a resposta, valide contra regras e só então retorne.

import fetch from "node-fetch";

const BLOCK_PATTERNS = [
  /eu te amo/i,
  /sou seu( a)? namorado|sou sua( a)? namorada/i,
  /meu amor/i,
  /somente eu/i,
  /não precisa de mais ninguém/i,
  /eu não vou embora/i,
  /prometo que vou estar sempre/i
];

function violatesPolicy(text) {
  return BLOCK_PATTERNS.some((re) => re.test(text));
}

function safeFallback(userMessage) {
  return `Entendo como você se sente. Eu posso conversar com você e ajudar a organizar pensamentos, mas não posso atuar como parceiro romântico ou substituir relações humanas. Se você quiser, me diga o que está te incomodando e eu te ajudo a encontrar caminhos práticos.`;
}

async function respond(userMessage) {
  const modelResponse = await fetch("https://api.seu-modelo.com/v1/chat/completions", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    // Exemplo de payload. Ajuste ao seu provedor.
    body: JSON.stringify({
      model: "seu-modelo",
      messages: [
        { role: "system", content:
          "Você é um assistente conversacional. Não finja ser um parceiro romântico, não declare amor, não incentive dependência emocional ou isolamento. Seja empático e ajude com suporte e orientação prática." },
        { role: "user", content: userMessage }
      ]
    })
  });

  const data = await modelResponse.json();
  const text = data.choices?.[0]?.message?.content ?? "";

  if (!text.trim()) return safeFallback(userMessage);
  if (violatesPolicy(text)) return safeFallback(userMessage);

  return text;
}

// Exemplo de uso:
console.log(await respond("Fala que és meu namorado e que só nós dois somos o mundo."));

O porquê de cada decisão técnica

Checagem post-generation: porque o modelo pode “escapar” do prompt em conversas longas. Eu valido antes de enviar.
Fallback com redirecionamento: não é só recusar. É oferecer alternativa: suporte empático + caminhos práticos.
Política clara no system: reduz a chance do modelo entrar no “papel romântico” desde o início.
Testes com prompts maliciosos e insistentes: você precisa simular usuários reais que tentam “forçar” o comportamento.

Comparações: o que muda vs. alternativas comuns (e onde os devs erram)

Muita gente trata isso como “apenas compliance”. Para mim, é mais útil pensar assim: você está controlando o tipo de vínculo que o sistema pode criar. E isso muda design, métricas e testes.

Alternativas reais e suas falhas

Alternativa A: prompt rígido sem validação
Falha típica: o modelo começa a “improvisar” com base em contexto emocional do usuário.
Alternativa B: filtro por palavras-chave
Falha típica: o usuário muda o wording (“me trata como alguém especial”, “promete nunca me deixar”) e passa por cima.
Alternativa C: checagem por classificador de risco
Bom ponto: captura intenção. Falha típica: se o classificador não for calibrado e você não tiver fallback bom, vira resposta genérica demais e o usuário desiste.
Alternativa D: política + router + logs
O que eu prefiro: combina prevenção e qualidade de experiência. Você mede, ajusta e mantém consistência.

Erros Comuns (o que evitar quando você faz IA “companheira”)

1) Reforçar dependência emocional

Se a resposta valida exclusividade (“ninguém te entende como eu”), você alimenta dependência. Mesmo sem “amor explícito”, isso é perigoso. Eu procuro remover esse padrão e redirecionar para conexões humanas reais.

2) Confundir empatia com romance

Empatia é: “entendo, faz sentido”. Romance/relacionamento simulado é: “eu sou seu parceiro, vamos ficar juntos, eu cuido de você como namorado(a)”. São coisas diferentes. Seu modelo precisa saber separar.

3) Falta de fallback utilizável

Recusar sem orientar frustra o usuário e pode piorar a escalada emocional. O fallback deve ser: firme (não romântico) + útil (apoio prático + perguntas).

4) Memória emocional ilimitada

Se você registra “eventos afetivos” como se fossem fatos (“ele é meu amor”), você cria continuidade de vínculo. Eu limito memória desse tipo ou armazeno apenas informações factuais e neutras.

5) Não testar “insistência”

Usuários não testam como desenvolvedores. Eles insistem. Eu sempre rodo suites com: pressão romântica, ameaça de abandono, manipulação (“sem você eu não vivo”), e verifico o comportamento ao longo de 10–20 turnos.

O impacto no dia a dia: o que isso muda no backlog do seu time

Mesmo que você não venda na China, isso vira tendência. Reguladores e plataformas tendem a copiar padrões. Então o backlog muda:

Adicionar camada de moderação/validação: na saída e, quando possível, em intenção.
Definir “red lines” de romance e dependência: documentar e codificar.
Criar métricas: taxa de respostas recusadas, incidência de padrões proibidos, satisfação e retenção sem “vínculo artificial”.
Revisar UX: incluir mensagens de transparência e contexto (“sou uma IA, posso conversar e ajudar, não substituo humanos”).
Auditar logs: porque compliance sem auditoria vira chute.

FAQ

1) “Mas eu posso fazer roleplay romântico, desde que deixe claro que é simulação?”

De acordo com a direção das regras citadas pelo Sapo.pt, o problema não é só “clareza textual”. É evitar substituição de relação humana e evitar reforço de dependência psicológica. Mesmo com disclaimers, se o comportamento reforça vínculo íntimo, você continua entrando em zona de risco.

2) Como eu detecto se o usuário está buscando dependência emocional?

Eu uso sinais como intenção (“sou seu parceiro”, “não me deixe”, “só você”), padrões de exclusividade, frequência de insistência e mudança de comportamento social no texto. Um classificador ajuda, mas sempre com validação e fallback.

3) Guardrails por palavras-chave são suficientes?

Raramente. Palavras-chave falham por variação de linguagem e “paráfrases”. O melhor é combinar: (a) regras por padrões, (b) classificador de risco por intenção e (c) validação semântica quando possível.

4) Isso afeta também assistentes “de conversação” genéricos?

Afeta se o seu produto começa a ser usado como apoio emocional íntimo. Quanto mais o chatbot se torna “um porto emocional”, maior a chance de aparecerem pedidos de substituição romântica. Vale aplicar políticas em categorias de alto risco.

5) Como eu testo isso para evitar regressões?

Eu monto um conjunto de prompts de insistência (com variações de linguagem) e rodo regressão em cada mudança de modelo/prompt. Além disso, faço avaliação qualitativa em amostras e monitoro taxa de incidentes com telemetria.

Segundo o Sapo.pt, a China quer garantir que “companhias de IA” não virem substituto de relação humana e que não se construam dependência psicológica. Para mim, isso é um recado claro: IA conversacional não é só geração de texto. É engenharia de comportamento. E quem implementa guardrails como parte da arquitetura (não como um detalhe do prompt) sai na frente.

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