OpenAI's text watermark isn't your record of what AI wrote.

What did OpenAI actually switch on?

If your product calls the OpenAI API to write anything a customer reads (product copy, support replies, order emails, a monthly report), there's a new setting in your dashboard as of today, October 5, 2026. Someone on your team is going to ask about it this week.

Here's what OpenAI announced. API customers anywhere can now opt in to text watermarking for select models. It's off by default. You turn it on for one project under Project Settings → Text provenance, or for the whole organization under Organization settings → Data controls → Text provenance, then pick which models get it (OpenAI Help Center). OpenAI says more models, including legacy ones, are coming over the next few weeks, and that it's working with cloud partners so outputs reached through their services can carry the watermark too.

Separately, and also over the coming weeks, OpenAI will watermark eligible ChatGPT and Codex text in the EU. Only in the EU. It isn't becoming a global default.

The technology is called textGrain. It nudges the model's word choices into a keyed statistical pattern. There are no hidden characters, no odd spacing, nothing a reader would notice. A detector holding the key can look for the pattern later.

The detail that matters most for you: that detector isn't public. Access is limited to approved researchers and expert organizations, case by case. Turning the watermark on doesn't get you access either.

How much can a watermark really tell anyone?

Less than the word "watermark" suggests, and OpenAI is unusually blunt about that.

In its own tests on English answers, at a 1% false-positive target, the detector found the watermark in about 80% of 200-token passages and about 95% of 400-token passages for psychology-style content. For mathematics, where there are fewer ways to say the same thing, detection was substantially lower. Swap 10% of the words in a 400-token passage for synonyms and detection fell from about 92% to 66%. Swap 25% and it fell to 17%.

Now think about what your product actually ships. A product description of a few sentences. A three-line support reply that someone on the team tidied up before sending. An order email with one generated paragraph in the middle. OpenAI notes that short passages usually don't carry enough signal, that code is harder to watermark, and that the EU Code of Practice doesn't require watermarks on outputs under 200 tokens (about 150 words of English) or on code snippets. Detection also varies by language.

Even when detection works, OpenAI lists what a result doesn't tell you:

• how much a person contributed
• who owns the text or is responsible for it
• which user, account, or prompt produced it
• whether it's true

And no watermark doesn't mean a person wrote it. The text might be short, edited, translated, older than the setting, or from another company's model.

So treat it as what it is: a faint, machine-readable hint that an OpenAI model was involved, readable today by a small group of people who aren't you.

So should we flip it on?

For some projects, probably, and the project is the right level to decide at. Most products don't run on one undifferentiated API key. The support-reply flow, the catalog-copy job, and the internal analytics tool usually live in different projects with different stakes.

Start by listing every place generated text reaches someone outside your company. For each one, ask:

1. Do EU customers or users see it?
2. Is it long enough to carry a signal: a few paragraphs, not a subject line?
3. Does it go out mostly as generated, or does a person rewrite it?

Long, lightly edited text going to EU readers is where the switch does most of what it's for. Short, heavily edited, or internal text gets little from it.

The costs OpenAI reports are small: no meaningful quality difference on the benchmarks it runs for Astra, its latest frontier model, and a negligible effect on speed. We'd still run your own prompts through a watermarked project and read the outputs side by side before switching a customer-facing flow. That's what you'd do for any model setting change.

One thing the switch won't settle is whether your product counts as a "provider" under Article 50 of the EU AI Act, which, as OpenAI puts it, requires generative AI providers to make generated text identifiable in a machine-readable way. OpenAI's own guidance says customers are responsible for their own obligations. That's a question for counsel, not a settings page. Bring them the list you just made.

If the watermark isn't proof, what is?

Your own records. This is the part we'd actually spend time on.

Sooner or later someone will ask "did AI write this?" about one specific thing your product put in front of a customer. It might be the customer, a partner's compliance team, a regulator, or your own support lead after a bad reply. You can't run OpenAI's detector. Even if you could, it might miss an edited passage and tell you nothing about a short one. The answer you can rely on is the one you wrote down at the time.

That record doesn't need to be elaborate. For each piece of generated text that ships, keep:

• What made it: the model, and the version of your prompt or template.
• What went in: the source data it was built from, stored as a reference rather than a copy where privacy calls for that.
• Who touched it: whether a person edited or approved it, who, and when.
• Where and when it went out: the page, email, or ticket, and the timestamp.
• The watermark setting: whether the project had it on at the time.

Most teams already log some of this for debugging, then throw it away after a few weeks. The real change is deciding it's a product record with an owner and a retention period, set with whoever handles compliance, instead of a debug log.

It earns its keep in ordinary ways too. When a product page says something wrong, you can see which prompt version wrote it and find every other page that came from the same one.

Do we still need an AI label on the page?

The watermark doesn't answer that. OpenAI says plainly that watermarks and metadata are for software to read, and that they don't replace visible labels, banners, or other notices that may be required.

On the legal side, the European Commission describes the deployer duty covered by the Code of Practice as disclosing deepfakes and AI-generated text published to inform the public on matters of public interest, unless that text has had human review and someone holds editorial responsibility. The Commission has also published icons deployers can use. Whether any of your product's text falls in there is, again, for counsel. Keep that conversation short and bring real examples.

The product side is yours either way. A visible label is a design decision about what someone should know at the moment they read something. In a support chat, we'd tell people when a reply was drafted by AI. A product description written from your own spec sheet may not need a badge. A generated summary of someone's account should probably say what it is and where its numbers came from.

Decide per surface and write the decision down. And make the label true. "Drafted with AI, reviewed by our support team" is only honest if your record shows the review happened.

Where would we start this week?

With a short list. None of it needs a big project:

1. List every place generated text leaves your system, grouped by OpenAI project.
2. Decide the watermark switch per project, with a one-line reason next to each decision.
3. If you reach OpenAI models through a cloud provider, check whether the setting has arrived there yet.
4. Start the record: model, prompt version, human review, ship time, watermark setting.
5. Take the list and a few examples to counsel on Article 50, and treat visible labels as a product decision.

On timing: the Commission says Article 50's transparency obligations have applied since August 2, 2026, so for EU-facing products this isn't a someday item.

None of this is exotic. The record is a handful of fields written where your app already writes events, plus a screen someone can actually search when the question comes. It's the kind of thing we build in AI applications & agents and web application development work. If you'd like a second pair of eyes on where your generated text goes, tell us what you're running.

Related work: PatientIQ, where the reporting had to meet CMS reimbursement requirements.