On 2 December 2026, a four-month runway closes. Providers who had generative AI systems on the EU market before 2 August 2026 have until that date to mark their outputs in a machine-readable format under Article 50(2) of the AI Act — the concession Regulation (EU) 2026/1744, the Digital Omnibus on AI, granted in the new Article 111(4) it inserts, and explained in its recital 38, while it was deferring the high-risk regime to 2027 and 2028.
That is roughly fifteen weeks. And it is an unusual sort of deadline, because the control it designates is the subject of an active, published attack literature.
Most controls a compliance programme adopts are stable. Encryption at rest, access review cadence, retention windows — implement them correctly and they hold. Content watermarking does not behave that way. In Watermark Stealing in Large Language Models, presented at ICML 2024, Nikola Jovanović, Robin Staab and Martin Vechev showed that for text, querying a watermarked model's public API is enough to approximately reverse-engineer the scheme, and that this enables both spoofing and scrubbing. Their stated result: "for under $50 an attacker can both spoof and scrub state-of-the-art schemes previously considered safe, with average success rate of over 80%."
Spoofing matters as much as scrubbing here. Scrubbing strips your mark off content you generated. Spoofing stamps your mark onto content you did not. A control that can be forged in both directions is not, on its own, a reliable statement about where a piece of content came from.
The statute already concedes the point
Article 50(2) requires providers of AI systems that generate synthetic audio, image, video or text — general-purpose systems included — to ensure outputs "are marked in a machine-readable format and detectable as artificially generated or manipulated." The qualifying clause is the interesting part. Technical solutions must be "effective, interoperable, robust and reliable as far as this is technically feasible, taking into account the specificities and limitations of various types of content, the costs of implementation and the generally acknowledged state of the art, as may be reflected in relevant technical standards."
That is not a threshold. It is a judgment standard, and it is drafted the way it is because the drafters knew the underlying technology was unsettled.
Judgment standards are not evidenced the way thresholds are. A threshold is evidenced by a measurement: the key length is 256 bits, the log retention is 400 days. A judgment standard is evidenced by a decision record — what you chose, when you chose it, what the state of the art looked like at that moment, and why the choice was reasonable given cost and content type. The Cloud Security Alliance's AI Safety Initiative, in a research note published on 29 July 2026, reached the same operational conclusion: organisations should maintain a documented rationale for their marking technology, including its known limitations, rather than an unexamined default.
Which means the compliance artifact you need is not primarily the watermark. It is the record of the decision, and the record of what was generated.
Why the mark cannot be the evidence
Here is the structural problem, and it is a problem of where things live rather than how good the algorithm is.
A watermark travels inside the content. That is its entire design: the mark is embedded in the artifact so the artifact can be checked anywhere, by anyone, without reference back to you. The property that makes it useful in the wild is exactly the property that makes it fragile as evidence — once the artifact leaves your infrastructure, every party that touches it can modify it, and some of them are trying to. Re-encoding drops metadata. Screenshots discard it. And the research above shows that the embedded signal itself yields to a motivated attacker with a small budget.
So consider what happens when a market surveillance authority asks a straightforward question: did this specific output come from your system, and was it marked when it left? If your answer depends on inspecting a copy of the artifact that has been through three platforms, you are asserting a fact about your own system using an object you no longer control. You may be right. You cannot demonstrate it.
The copy an adversary downstream cannot reach is the one that never left. A generation-time record — this model, this prompt context, this output, this timestamp, this marking treatment applied — sits in your infrastructure and is not part of the artifact's journey. It does not degrade when someone screenshots a PNG.
This is the same shape as the attribution problem SOC 2 auditors already flag on autonomous agent actions: the control may well have operated correctly, but if the operation was not recorded at the point it happened, there is nothing to show. It is also why "requires human review" is only a control when the review is enforced and logged rather than assumed. Marking is heading for the same audit conversation.
Marking is a per-output property, not a deployment setting
The second architectural consequence follows from the first. Article 50(2) attaches to outputs, not to systems. Article 50(5) reinforces the pattern for the disclosure duties, requiring that information reach the person "in a clear and distinguishable manner at the latest at the time of the first interaction or exposure."
Obligations that attach per-interaction cannot be satisfied by a deployment-time configuration flag. A flag records an intention. It does not record what happened on the four million generations that followed, and it cannot tell you which of them went out unmarked because a code path bypassed the wrapper, a fallback model was substituted during an incident, or a retry took a different route.
An agent pipeline makes this sharper, because the number of places an output can be produced multiplies. A coordinator calls a planner, which calls a summarisation step, which calls a model your team did not choose. Marking applied in the application layer of one service says nothing about the others. The obligation is on the output; the enforcement point therefore has to be wherever outputs cross the boundary, and the record has to be produced there too.
The penalty structure makes the record worth building properly. Article 99(4)(g) of the Act puts transparency obligations under Article 50 in the tier carrying administrative fines of up to EUR 15 000 000 or, for an undertaking, up to 3 % of total worldwide annual turnover — whichever is higher.
And this deadline is genuinely separate from the one most teams tracked. The Commission's AI Office and national authorities began enforcing on 2 August 2026, and the interaction-disclosure and deepfake-disclosure duties applied that day. Only the machine-readable marking sub-obligation, and only for systems already on the market, got the runway to December. We covered what applied on 2 August and what the Omnibus deferred as the date approached; this is the piece of it still ahead of you.
How Waxell handles this
Waxell does not implement C2PA content credentials or embed watermarks, and no part of this obligation is discharged by installing an SDK. What Waxell Observe addresses is the other half — the half the artifact cannot carry for you.
Observe captures every LLM call, tool invocation and agent decision, and enforces runtime policies before the next step executes. For a marking programme, two of its 50+ policy categories carry most of the weight. Audit configures logging and compliance so that, in the product page's own words, every decision, every call and every cost is recorded immutably for review — which is the generation-time record a judgment standard needs. Content scans and filters inputs and outputs in real time, at the point where output leaves the stack, which is the boundary the obligation actually attaches to.
Because instrumentation is automatic across 200+ Python libraries, the record covers generation paths a per-service integration tends to miss — the fallback model, the retry, the nested call in a multi-agent tree. Traces are OpenTelemetry-native with parent-child spans, so a specific output can be walked back to the model and context that produced it.
That is the difference between believing your outputs were marked and being able to show which ones were. The watermark is your claim to the outside world. The record is your evidence.
FAQ
Does the 2 December 2026 date apply to my system?
It applies to the machine-readable marking duty in Article 50(2), and only for providers whose generative systems were already placed on the EU market before 2 August 2026. Recital 38 of Regulation (EU) 2026/1744 describes it as a four-month transitional period so existing providers can adapt without market disruption. Systems placed on the market after 2 August 2026 do not get the runway.
Was Article 50 deferred along with the high-risk rules?
No. The Digital Omnibus deferred the obligations in Sections 1, 2 and 3 of Chapter III — to 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Annex I. Article 50 sits outside that risk-tiered structure and applied from the general date of 2 August 2026, apart from the narrow marking runway described above.
If watermarking can be defeated, why comply at all?
Because the standard is "as far as this is technically feasible," not "unbreakable." A scheme being defeated in the literature does not excuse the obligation; it shapes what a defensible implementation looks like. Adopt a current approach, document why you chose it and what its known limits are, revisit that decision on a defined cadence, and keep a generation-time record so your compliance position does not rest solely on an artifact you no longer control.
Who is responsible — the model provider or us?
Article 50(2) places the marking duty on providers of the AI system generating the content, including general-purpose systems. If you build a product on someone else's model, examine where provider responsibility sits in your arrangement rather than assuming it transfers. The disclosure duties in Article 50(1) and 50(4) allocate differently again, falling on providers of interactive systems and on deployers respectively.
What does an auditor actually want to see?
Three things, in practice: the marking mechanism enabled and tested rather than merely available; a decision record explaining the technology choice against the state of the art at the time; and per-output evidence that the mechanism ran. The first two are documentation exercises. The third is an instrumentation problem, and it is the one that cannot be produced retroactively.
Sources
- European Parliament and Council, "Regulation (EU) 2026/1744 of 8 July 2026 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 (Digital Omnibus on AI)", OJ L, 2026/1744, 24 July 2026
- European Parliament and Council, "Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 50 and Article 99", OJ L, 12 July 2024
- European Commission, "Commission starts enforcing AI Act rules and new transparency requirements on 2 August", Shaping Europe's Digital Future, updated 31 July 2026
- Nikola Jovanović, Robin Staab and Martin Vechev, "Watermark Stealing in Large Language Models", arXiv:2402.19361, ICML 2024
- Cloud Security Alliance AI Safety Initiative, "EU AI Act Article 50: Transparency Obligations Take Effect", 29 July 2026
Originally published on the Waxell blog.
Fifteen weeks is enough time to build a generation-time record. It is not enough time to reconstruct one after a regulator asks.
Start free with Waxell Observe — two lines of Python, 10,000 traced executions a month, and an immutable record of what your agents generated: https://waxell.dev/signup
Top comments (0)