ChatGPT Text Watermarking: EU Rollout and API Opt-In

ChatGPT text watermarking is coming to eligible ChatGPT and Codex text output across all plans in the European Union over the coming weeks. OpenAI’s October 5 announcement also makes text watermarking an optional setting for API customers globally, starting today on selected models. That API setting is off by default. Text detector applications are opening, but detector access is not a public feature available to every user. Read the official announcement.

ChatGPT text watermarking: separate the rollout from API opt-in

OpenAI calls the method textGrain and presents it as its response to EU transparency rules. The two availability paths require different checks: rollout status for EU product users, and saved configuration for API organizations.

For an EU team using both ChatGPT and an API application, our recommendation is to evaluate the two workflows separately. The API application has an opt-in configuration decision now; the ChatGPT workflow has an announced product rollout to track. Do not postpone the first decision until the second rollout completes, or report one as confirmation of the other.

This dated news page explains the provenance change, rather than replacing our API setup overview. Keep authentication, model access, and application integration in the existing setup workflow; add provenance configuration as a separate decision.

What textGrain changes in generated text

According to OpenAI’s provenance guide, textGrain alters the statistical pattern of the model’s word choices. A detector looks for that embedded pattern using matching settings and a secret key. It does not insert hidden characters, invisible spaces, or watermark-only tokens. Short answers and code offer less material or flexibility for detection, and performance varies by language.

For an editor, searching a document for strange spaces would inspect formatting, not this mechanism. Consider a product explanation written from a human-approved specification, drafted with AI, then corrected by an editor. Our recommendation is to review its technical claims against the specification and credit contributions through the publication process. A provenance signal addresses a different question from whether the specifications or final wording are correct.

Where API customers can enable text watermarks

OpenAI documents organization settings under Data controls → Text provenance, and project settings under Text provenance. Enable Allow text watermarking, select models, and save. The settings show the currently eligible models; the announcement does not supply a complete list of exact supported Model IDs. Enabling watermark generation does not grant text detector access. See the official configuration instructions.

For a controlled evaluation, our recommendation is to use a dedicated project and synthetic, non-sensitive inputs. Check the selected model and saved project setting before comparing outputs. An organization-wide default and a project override have different scopes, so decide whether the evaluation should affect just that application or the broader organization.

Choose sample tasks that resemble the application: a paragraph-length customer explanation, a concise support answer, and a code-focused task if relevant. Ask reviewers to assess usefulness and correctness without treating a watermark setting as a quality score. Keep the samples labeled as evaluation material, and budget separately for any generation requests. We did not make paid API calls for this article.

The OpenAI text watermark detector is not a public checker

The Content Provenance API documentation describes public checks for supported image and audio files, while text verification requires approved organizational access. Its checks concern supported OpenAI signals, not every AI system. A detected signal is evidence of that signal; an absent signal is not proof of human authorship. The documentation also cautions against inferring a prompt, account, or individual creator from verification results.

That access distinction matters when designing a tool. A developer should not advertise a public text-checking feature merely because watermark generation can be enabled. First identify the verification capability actually available to the organization. If text detector approval is missing, design the interface around the evidence it can genuinely collect rather than displaying an invented detection percentage.

For example, imagine a company checking a document that an employee wrote and then submitted to an AI editing workflow. Even if an authorized check finds a signal, the sensible next step is to examine the draft history and ask what was edited. It is not to declare that the employee contributed nothing. Conversely, a negative check on an unfamiliar document should prompt a source review, not an automatic human-authored certification. These are editorial decision examples, not results from a detector we tested.

How to interpret detection limits

At a target one-percent false-positive rate, OpenAI reports detecting approximately 80% of 200-token psychology passages and 95% at 400 tokens. These are results from a specified evaluation, not guaranteed rates for arbitrary documents. Read the experiment’s context.

For a mixed-language workflow, our recommendation is to keep evaluation results separated by language and task. Do not average a long explanatory article with a short mathematical answer and present the average as a universal reliability figure. Record the sample length, task category, and review outcome so that a later comparison refers to the same kind of work.

The false-positive setting and the detection rate answer different questions. Our interpretation is that a reported 95% detection rate should not become a claim that a positive result has a 95% probability of identifying AI authorship. Before using any result in a consequential review, ask which population was evaluated and how the decision will handle mistakes. An educational institution, for example, should not substitute an isolated score for a student’s drafting history and explanation.

Prepare a publication workflow, not an authorship verdict

OpenAI says watermarking does not determine ownership or the extent of human contribution, and machine-readable signals do not replace visible disclosures. Its customer guidance leaves use-specific disclosure requirements to the customer’s assessment.

Our recommendation is to decide the reader-facing disclosure as part of publication approval, separately from the technical marking setting. Keep privacy choices in their own workflow, covered by our earlier ChatGPT Privacy Center walkthrough. This announcement provides a new provenance mechanism; a useful implementation still needs accurate content, an appropriate disclosure decision, and a review process that can explain its evidence.