Editar 10% das palavras reduz a detecção da marca d'água da OpenAI de 92% para 66%

Uma marca d'água para texto soa como uma solução conveniente: o modelo marca a resposta de forma invisível, e um detector especial determina depois a sua origem. Na prática, tudo se resume a um velho problema de produto: o usuário não é obrigado a publicar a resposta sem alterações. Ele a encurta, reorganiza frases, traduz ou pede a outro modelo que reescreva o texto. Depois desse processamento, o sinal oculto enfraquece rapidamente.

A OpenAI apresentou o textGrain, um método pensado, entre outras coisas, para cumprir as exigências do artigo 50 do AI Act europeu. Nos testes da empresa, ele encontrou a marca em cerca de 95% dos textos de 400 tokens, mas apenas em 80% dos textos de 200 tokens. A edição é ainda mais reveladora: trocar 10% das palavras por sinônimos reduziu a detecção em trechos de 400 tokens de 92% para 66%, e trocar 25% das palavras, para 17%.

Como o texto recebe uma marca invisível

A cada passo, um modelo de linguagem escolhe a próxima palavra, ou parte dela, entre várias opções prováveis. Digamos que, depois da frase "hoje o tempo está...", ele possa continuar com "quente" ou "fresco". A marca d'água, por meio de uma chave secreta, influencia levemente essa escolha. Para o leitor, a resposta parece normal, mas na sequência de palavras surge um padrão estatístico conhecido pelo detector.

A particularidade do textGrain é o controle da entropia, isto é, da reserva de variabilidade permitida. O desenvolvedor define quanta liberdade pode ser gasta na incorporação do sinal, e o sistema tenta equilibrar a visibilidade da marca para o detector com a naturalidade da resposta. Não se trata de um carimbo nem de um registro em cada frase: a confiança surge apenas depois do acúmulo de indícios estatísticos suficientes.

Daí o problema das mensagens curtas. Em uma resposta de duas frases, pode simplesmente faltar dado. Com a taxa declarada de falsos positivos de 1%, o detector marcará por engano cerca de um em cada cem textos sem marca d'água. Ao mesmo tempo, um resultado positivo não mostra quanto foi escrito por uma pessoa, e um negativo não prova autoria humana.

Por que uma edição comum quebra a verificação

O sinal depende não apenas de uma palavra isolada, mas também da sequência que a antecede. Se um editor troca uma palavra, vários trechos seguintes do padrão estatístico podem mudar de uma só vez. Por isso, até uma revisão literária tranquila, sem tentativa deliberada de enganar o sistema, piora notavelmente a detecção.

Imagine um serviço que gera uma descrição de produto de 150 palavras. Um gerente muda o título, corta repetições e troca uma dezena de formulações. O texto ainda foi, em grande parte, criado pelo modelo, mas o detector já pode devolver um resultado negativo. O erro inverso também é doloroso: ao verificar milhares de trabalhos de estudantes ou solicitações, 1% de falsos positivos se transforma em dezenas de suspeitas infundadas.

Ainda não há avaliação independente do textGrain. A OpenAI deu acesso a um grupo limitado de pesquisadores, que ainda precisam testar diferentes idiomas, temas e comprimentos. A afirmação da empresa de que ele é comparável ou superior ao Google SynthID Text também ainda não foi confirmada por testes externos.

O que devem fazer desenvolvedores e produtos

As regras europeias exigem uma marcação legível por máquina do conteúdo sintético, que seja eficaz, interoperável, robusta e confiável na medida em que isso seja tecnicamente possível. Mas ainda não há limiares mensuráveis para essas características. O código de prática voluntário, por sua vez, não exige marcas d'água para textos com menos de 200 tokens.

A conclusão prática é simples: não se deve transformar o resultado do detector no único fundamento para bloquear, acusar ou sancionar. Em um produto generativo, é melhor combinar vários níveis de proveniência: marca d'água, metadados assinados, identificador do modelo, registro de geração e rotulagem explícita na interface. Casos controversos exigem revisão manual e possibilidade de recurso.

Os desenvolvedores devem testar separadamente cenários reais de uso: encurtamento, tradução, correção de estilo, troca de palavras e nova geração. Uma métrica em texto de laboratório intocado diz pouco sobre o funcionamento do recurso após a publicação. O textGrain parece um sinal adicional útil, mas não um detector universal da verdade, e o produto deve ser projetado justamente com essa limitação em mente.