The deadline passed on August 2 and your pipeline did not break
The EU AI Act's transparency obligation for AI-generated content took effect on August 2, 2026. If you run an LLM product that serves European users, that was supposed to be a big deal. Then the date passed and, for almost everyone, nothing happened. No errors, no latency spike, no bill increase.
That is exactly why it is worth understanding now rather than during your next compliance review.
Anthropic published its approach in late July, confirming it had signed the EU Code of Practice on Transparency of AI-Generated Content along with roughly 190 other signatories. The mechanism they shipped is text watermarking based on SynthID-Text, the technique Google DeepMind published in Nature in 2024.
Here is the part engineers keep getting wrong: watermarking is not a tag appended to the output. There is no header, no invisible Unicode, no zero-width space, no extra token. If you diff a watermarked response against an unwatermarked one, you will not find a marker to strip.
How SynthID-Text actually works
An LLM does not pick the next token deterministically. At each step it produces a probability distribution over the vocabulary, then samples from it using a pseudorandom source.
SynthID-Text modifies the randomness source, not the distribution. It uses a keyed pseudorandom function seeded by the preceding context to bias sampling among tokens the model already considered roughly equally likely.
Take a model completing "The deployment failed because the container ran out of". Suppose the top candidates are:
memory 0.41
RAM 0.22
space 0.19
disk 0.11All four are fluent and correct. A normal sampler picks one according to those weights. A watermarked sampler nudges the choice toward whichever token scores higher under the secret key at that position.
Do this across a few hundred tokens and the sequence carries a statistical signal. A detector holding the key computes the expected score under the watermark and compares it to what chance would produce. Individually each choice looks arbitrary. In aggregate the distribution is measurably skewed.
Three consequences follow directly from that design, and they explain nearly every practical question:
- 1It needs entropy. If the model is near-certain about the next token, there is nothing to bias. Watermarking only has room to work where genuine alternatives exist.
- 2It needs length. Statistical confidence accumulates. A four-word reply carries almost no signal.
- 3It degrades under editing. Rewrite half the tokens and you destroy half the evidence.
Why code is watermarked less
Anthropic states explicitly that code receives less watermarking, "where exact output is required."
That is not a policy carve-out, it falls out of point 1. Code is low-entropy in the places that matter. When a model writes import numpy as np, there is no equally-valid alternative token. Swapping np for numpy because a hash function preferred it would produce code that does not match the rest of the file.
The same logic applies to JSON keys, SQL identifiers, UUIDs, and any structured output your schema pins down. Prose has synonyms. Syntax does not.
So if you are building a coding assistant or an agent that emits structured tool calls, watermarking is close to a no-op for the parts of your output that are machine-parsed.
The five places this actually shows up in a real system
Compliance posts stop at "the law says X." Here is where it touches an actual codebase.
1. RAG corpora are now mixed provenance
This is the one nobody plans for. If your retrieval index ingests content that was itself LLM-generated (summaries you produced, support macros, docs written with AI assistance), your corpus now contains watermarked text.
That does not break retrieval. Watermarks do not affect embeddings in any way you will notice, because the semantic content is unchanged by design.
What it does affect is attribution. When a detection API arrives and someone runs it over your knowledge base, chunks will come back flagged. If you cannot explain which chunks are human-authored versus model-authored, you will be reconstructing that history from git blame under time pressure.
Store provenance at write time. A single source enum on each chunk costs nothing now and is expensive to backfill:
CHUNK_SOURCE = ("human", "model_generated", "model_assisted", "third_party")
def index_chunk(text: str, source: str, model: str | None = None):
assert source in CHUNK_SOURCE
store.upsert({
"text": text,
"embedding": embed(text),
"source": source, # provenance, recorded at write time
"model": model, # e.g. "claude-opus-5"
"indexed_at": utcnow(),
})This is the same discipline as tracking provenance in your evaluation sets, and it pays off for the same reason: you cannot recover metadata you never wrote down.
2. Golden datasets built from model output
If your regression suite compares today's output against a stored reference generated months ago, and watermarking rolled out between those points, exact-match assertions can drift.
Not because quality changed, but because sampling changed. The model may now prefer "memory" where it previously chose "RAM", both correct.
If your tests already assert on semantics rather than exact strings, you are fine. If you have exact-match assertions on prose, they were fragile before this and watermarking is just the thing that finally exposes it. Test behaviour, not token sequences.
3. Detection is not available yet
Anthropic's post describes a detection API as "coming soon." That is the single most important operational fact in this whole topic.
You currently cannot verify your own compliance posture. You cannot scan your corpus, you cannot check whether a given string carries a watermark, and you cannot build a provenance dashboard on top of a detector that does not exist.
Anyone selling you AI-text detection today is not using the watermark key. They are using a classifier that guesses from stylistic features, and those have well-documented false positive rates that fall hardest on non-native English writers. Do not wire one into a decision that affects a person.
4. Paraphrasing pipelines wash the signal out
If you post-process model output through another model, a translation step, or aggressive templating, you are attenuating the watermark.
This is worth stating plainly because the naive reading is "we should preserve watermarks to stay compliant." The obligation as described sits with the model provider, and it is applied at generation time. Your summarisation step is not a compliance violation.
But if you are relying on downstream detection for your own governance, know that a multi-model pipeline degrades the signal at every hop.
5. Short outputs carry almost nothing
Classification labels, sentiment scores, yes/no answers, extracted entities. If your product's outputs are mostly under a few dozen tokens, watermarking is statistically irrelevant to you.
Which is a useful filter: if you are trying to work out whether to spend time on this, look at your median output length first.
What actually changed for cost and latency
Nothing. Anthropic states there is no cost increase, no quality impact, and no effect on creativity or readability.
That claim is credible given the mechanism. Biasing a sampler is arithmetic on a distribution you already computed. There is no extra forward pass and no extra token.
If you are tuning spend, watermarking is not a lever. Your levers remain the ones that always mattered: routing cheap requests to cheap models, caching, and cutting context you do not need.
The transition period is the real gap
Models launched before August 2, 2026 have a transition period, with watermarking rolling out over time.
For engineers this means your fleet is inconsistent right now. Depending on which model version a given request hits, output may or may not be watermarked. Any logic that assumes uniform behaviour across your model set is assuming something that is not currently true.
Pin your model versions and record which version produced each stored artefact. This is good practice regardless, and it is the same reason you want version-controlled prompts: when behaviour changes, you need to know what produced what.
What I would actually do this quarter
Ranked by value per hour spent:
- 1Add a provenance field to anything you persist that a model wrote. Cheap now, expensive later. This is the only item I would call urgent.
- 2Pin model versions and log the exact version alongside stored outputs.
- 3Audit exact-match assertions on prose in your test suite and convert them to semantic checks.
- 4Write down where model-generated text enters your systems. Most teams cannot answer this, and it is a harder question than it sounds.
- 5Do not buy an AI detector. Wait for the keyed detection API.
Notice that four of those five are things you should have done anyway. That is typical of transparency regulation: it rarely demands new capability, it demands that you can account for what you already do. Teams with decent observability and clear governance practices absorb it without noticing. Teams without either discover they cannot answer basic questions about their own pipeline.
The honest summary
Watermarking is a well-designed, low-impact change that most engineering teams can safely ignore for another quarter, with one exception: start recording provenance today, because that is the piece you cannot reconstruct after the fact.
The regulation is not asking you to change how you build. It is asking you to know what you built.
Frequently Asked Questions
Does watermarking make model output worse?
No. The mechanism biases sampling among tokens the model already rated as roughly equally likely, so the alternatives it chooses between are ones it considered acceptable anyway. Anthropic states there is no impact on quality, creativity, or readability, and no cost increase. The design supports that claim: there is no extra forward pass and no extra token.
Can I remove the watermark from output I generated?
Heavy paraphrasing or translation will attenuate it, since the signal lives in accumulated token choices. But you should ask why you want to. The obligation described applies to the model provider at generation time, not to you as a downstream consumer, so stripping it is not a compliance requirement. Deliberately laundering provenance is also a poor look in any audit.
How do I check whether a piece of text is watermarked?
Right now you cannot. Anthropic has described a detection API as coming but has not shipped it. Third-party AI detectors do not use the watermark key, they guess from writing style, and they have high false positive rates that disproportionately affect non-native English writers. Do not use one to make decisions about people.
Does this affect code generated by AI coding tools?
Barely. Watermarking needs multiple genuinely interchangeable token options to encode signal, and code is low-entropy in exactly the places that matter. Anthropic confirms code receives less watermarking where exact output is required. The same applies to JSON, SQL identifiers, and schema-constrained structured output.
Do I need to label AI-generated content in my own product?
That depends on your jurisdiction, your use case, and legal advice specific to your situation, which this article is not. What engineers can do independently of the legal question is make labelling possible: record provenance for model-generated content at write time so the decision is a configuration change later rather than a data archaeology project.
Where to go from there
Provenance tracking, model version pinning, and semantic testing are the unglamorous parts of running LLMs in production, and they are what separates a system you can reason about from one you cannot.
If you want to work through these patterns hands-on, I run a 2-hour live workshop most Sundays where we build in real time with real code and no slides. ₹499 / $19 with a full refund guarantee. See what's coming up →
If you are earlier in the journey, the AI engineer roadmap lays out the order I would learn these things in.