Como a OpenAI Implementa o textGrain para Marcar Texto no ChatGPT e Codex na UE

Em 5 de outubro de 2026, a OpenAI publicou Our approach to EU text provenance rules, descrevendo como vai responder ao Artigo 50 do EU AI Act para texto gerado por seus modelos. A partir desta data, clientes da API em qualquer lugar do mundo podem ativar watermarking de texto para modelos selecionados, e nas semanas seguintes a OpenAI vai adicionar um watermark invisível em texto elegível gerado por ChatGPT e Codex dentro da UE. No API, o recurso continua desligado por padrão e não vai virar padrão global no lançamento.

A tecnologia tem nome: textGrain. Este artigo explica o mecanismo pelo que a OpenAI divulgou, compara com o que já se sabe da literatura pública sobre watermarks estatísticos (porque o relatório técnico ainda vai ser atualizado), e mostra onde a coisa quebra na prática.

O que é textGrain por baixo do capô

A OpenAI descreve o textGrain como uma tecnologia que adiciona um sinal estatístico invisível às escolhas de palavras do modelo, e um detector procura por esse sinal para avaliar se um trecho contém um watermark da OpenAI. Note a formulação: o sinal está nas escolhas de palavras, não em caracteres invisíveis, não em metadado anexado, não em marcador tipográfico. É pura estatística de quais tokens o modelo preferiu durante a geração.

Pense em um dado viciado. Um dado honesto cai 1 a 6 com probabilidade igual. Se eu te mostrar cem jogadas e você contar que o 4 apareceu 40 vezes, você suspeita do dado. Não dá para saber olhando uma jogada só, mas com cem jogadas a estatística entrega o viés. A analogia quebra em um ponto importante: no dado o viés é fixo, nos tokens o “viés” muda a cada posição em função do contexto anterior, então é preciso a mesma chave para reproduzir qual era a preferência esperada ali. Mas o espírito é esse: um viés pequeno demais para você perceber lendo, grande o suficiente para um teste estatístico detectar em volume.

Como o viés entra no texto

A OpenAI não publicou o algoritmo exato do textGrain neste anúncio, mas a família de métodos é bem documentada na literatura pública e é a mesma que o SynthID do Google usa (que a OpenAI diz ter superado em suas avaliações, segundo o próprio comunicado, onde afirma que o textGrain igualou ou superou outras abordagens testadas, incluindo o SynthID para texto). O esqueleto do método, descrito originalmente por Kirchenbauer e colegas em 2023, funciona assim:

1. Em cada passo da geração, o modelo tem uma distribuição de probabilidade sobre todo o vocabulário para escolher o próximo token.
2. Uma função hash com chave secreta, alimentada pelos tokens anteriores, divide pseudoaleatoriamente o vocabulário em uma lista verde (uma fração, tipicamente 0,5) e uma lista vermelha, e essa partição muda a cada passo porque depende do contexto rolante.
3. Durante a geração, os logits dos tokens verdes são aumentados por um delta. O modelo continua samplando normalmente, só que agora as palavras “verdes” têm um empurrãozinho.
4. Para detectar, usa a mesma chave para reconstruir qual era a lista verde em cada posição e conta. O procedimento de detecção conta quantos tokens verdes aparecem no texto candidato, calcula um z-score sob a hipótese nula de que o texto foi gerado sem watermark, e rejeita a nula se o escore ultrapassa um limiar.

A OpenAI confirma esse formato geral quando diz, no post no X, que o watermark funciona embutindo um sinal estatístico invisível no texto conforme ele é gerado. Os detalhes finos (qual delta, qual tamanho de janela de contexto, qual função hash) estão no relatório técnico, e a OpenAI diz que ele vai ser atualizado com mais detalhes nas semanas seguintes e que planeja disponibilizar a tecnologia em código aberto para que outros possam construir em cima dela.

Por que o detector não é público

O detector precisa da chave para recomputar as listas verdes em cada posição. Com a chave, qualquer um pode detectar. Sem a chave, o sinal parece ruído. Então o controle de acesso ao detector é controle de acesso à chave.

O acesso inicial é limitado a pesquisadores aprovados e organizações especializadas que se inscrevem via formulário de content provenance da OpenAI, concedido caso a caso em linha com o Code of Practice da UE sobre conteúdo gerado por IA, e não está publicamente disponível no lançamento devido ao risco de falsos positivos e watermarks não detectados. O detector só reporta se um watermark está presente, sem identificar o usuário ou seus prompts.

O que isso significa na prática

Para quem usa a API, a mudança operacional é um parâmetro novo opt-in em modelos selecionados. A OpenAI ainda não publicou a referência de API no anúncio em si, mas a semântica é clara: você ativa, o texto sai com viés estatístico embutido, a saída continua indistinguível a olho nu.

Para quem roda produto na UE via ChatGPT ou Codex, a decisão não é sua: nas próximas semanas o watermark passa a ser aplicado em texto elegível por padrão. O que “elegível” significa não foi detalhado no comunicado, mas o Code of Practice da UE já indica a direção: saídas de texto abaixo de 200 tokens (cerca de 150 palavras) estão isentas do requisito de watermarking, com a Comissão notando que o limiar pode diminuir conforme a tecnologia amadurece, porque watermarks estatísticos exigem um volume mínimo de texto para criar um sinal detectável, e completions curtas (um assunto de email reescrito, um snippet de código, uma resposta de uma frase) simplesmente não contêm tokens suficientes para uma marca confiável.

Isso casa com os números que a OpenAI reportou: com uma taxa de falso positivo de 1%, o textGrain detecta watermarks em cerca de 80% dos trechos de 200 tokens e 95% dos trechos de 400 tokens, embora conteúdo matemático tenha desempenho pior. Em texto matemático a maioria dos tokens é obrigatória (uma fórmula não tem sinônimo), então não há espaço de escolha para enviesar. Mesma lógica em código: muitas posições têm uma única continuação sintaticamente válida, e a janela de “escolha livre” encolhe.

Já passei por isso em uma situação diferente, mas com a mesma mecânica inversa. Numa plataforma de conteúdo gerado por LLM em escala de catálogo, a geração era ancorada em dado estruturado real com validação antes da publicação. Essa ancoragem reduz alucinação de forma brutal, mas também reduz a variedade do texto, porque o modelo tem menos liberdade de escolha. Watermark estatístico é a situação espelhada: ele precisa de liberdade de escolha para funcionar. Quanto mais o seu prompt amarra o modelo a uma saída obrigatória, menos sinal cabe ali.

Onde quebra

O limite mais duro é a edição posterior. A detecção cai significativamente para texto curto, conteúdo matemático e trechos editados (substituir 25% das palavras por sinônimos corta a detecção de 92% para 17%). Ou seja, uma passagem por um tesauro automático, uma reescrita leve ou uma tradução já destrói o sinal. A própria OpenAI diz isso diretamente: muitas vezes são indetectáveis, especialmente em passagens curtas, e reescrever ou traduzir o texto pode remover o watermark completamente.

Isso tem três consequências práticas que convém encarar de frente:

• Watermark não é prova. O watermark pode indicar que um sistema da OpenAI gerou ou processou parte de um texto, mas não pode dizer quem usou o sistema, quanto uma pessoa contribuiu, quem é dono do texto ou se o conteúdo está correto, e a ausência de watermark não prova que uma pessoa escreveu o texto. Tratar “não detectado” como “escrito por humano” é erro.
• Pipeline de pós-processamento mata o sinal. Se o seu produto gera com OpenAI e passa por um “revisor” LLM, ou por um tradutor, ou por regex de normalização agressiva, o watermark pode não sobreviver. Isso é relevante se você for um deployer na UE que precisa de rastreabilidade.
• Ataques dedicados existem. Qualquer um que saiba que o alvo é um watermark de logit-bias pode projetar paráfrases que embaralham a estatística. A literatura acadêmica já tem papers inteiros sobre isso, e nenhum watermark estatístico publicado hoje resiste a um atacante determinado com acesso a outro LLM.

Já me queimei num padrão parecido antes: analisando texto aberto de avaliação de cliente para decidir feature. O sentimento agregado parecia ótimo, mas o caso extremo, o cliente furioso que descrevia um bug específico, sumia na média. Com watermark é a mesma falácia: a taxa agregada de 95% em 400 tokens parece sólida até você perceber que o caso que importa é o adversário que edita de propósito, e esse caso específico se parece com os 5% que escapam, não com os 95% que são pegos.

O que não dá para afirmar ainda

O comunicado da OpenAI é propositalmente curto em detalhe técnico, e o relatório técnico vai ser atualizado nas semanas seguintes. Então algumas coisas estão em aberto:

• Qual é a função hash exata, o tamanho da janela de contexto e o delta de logit usados no textGrain. Dá para inferir pela família, mas não pela publicação.
• Quais são exatamente os “modelos selecionados” no API hoje, e o nome do parâmetro para ativar.
• O que a OpenAI considera “texto elegível” dentro do ChatGPT e Codex na UE. O corte de 200 tokens do Code of Practice é o palpite óbvio, mas não é confirmação.
• Quando (e se) a tecnologia vira open source de fato. A OpenAI diz que planeja, mas não dá data.
• Como o detector lida com texto parcialmente gerado por IA e parcialmente humano. O comunicado fala em “gerou ou processou parte de”, o que sugere que detecção parcial é possível, mas sem especificar granularidade.

Como testar isso você mesmo

Para experimentar hoje, sem esperar a documentação completa:

1. Entre no painel da API da OpenAI e procure, nas configurações de modelo ou nos parâmetros de requisição, a opção de watermarking (o anúncio diz que está disponível a partir de hoje para modelos selecionados; o nome final do parâmetro deve aparecer na reference da API).
2. Gere o mesmo prompt duas vezes, uma com watermark ligado e outra com watermark desligado, pedindo saídas longas (acima de 400 tokens, para ter sinal suficiente). Guarde as duas saídas.
3. Leia as duas lado a lado. O ponto do exercício é confirmar com os próprios olhos que você não consegue dizer qual é qual. Se conseguir, abra um issue, porque qualidade perceptível caindo é bug do watermark.
4. Pegue a versão com watermark e passe por três transformações separadas: (a) tradução para outra língua e volta, (b) reescrita por outro LLM com instrução de “reescreva mantendo o significado”, (c) substituição manual de 20 a 30% das palavras por sinônimos. Guarde os quatro textos finais (original com watermark mais as três versões transformadas).
5. Quando o acesso ao detector abrir, submeta os quatro textos e compare. Você vai ver na prática a curva de robustez que o paper descreve, e vai saber exatamente quanto o seu pipeline atual destrói do sinal antes de a saída chegar no usuário final.

Se você opera na UE, vale fazer o mesmo exercício com texto saindo do ChatGPT ou Codex assim que o rollout chegar. Não para “burlar”, mas para entender o que acontece com conteúdo gerado por IA quando ele atravessa o seu produto real, que raramente é só “gera e publica”.