Article 50(2) of the EU AI Act requires providers of AI systems that generate synthetic audio, image, video or text to mark those outputs machine-readably and make them detectable as artificial. Because the duty names “providers”, it is easy to treat as the foundation-model developer’s concern. It is not. It reaches a far larger group, on a threshold most cross without noticing, and this article sets out who owes it and what they can do about it.
1. Beyond the model developers
Most of the public conversation about Article 50(2) has fixed on the large model developers: who watermarks, which technique survives re-encoding, when interoperability arrives. Those most likely to be caught out, though, are not the labs. They are companies that never trained a model and never meant to, but have built something around one: an agentic workflow that calls a frontier model, a branded generation tool, a narrow utility that drafts or summarises at scale. Acquiring the duty is easy; meeting it is not, and that asymmetry, a line quickly crossed followed by a demanding technical obligation, is the practical heart of Article 50(2).
2. The provider’s duty to mark and detect
The obligation has two limbs: a provider must ensure its system’s outputs are both “marked in a machine-readable format” and “detectable as artificially generated or manipulated”, through technical solutions that are “effective, interoperable, robust and reliable as far as this is technically feasible”; the Commission’s Guidelines on the Article 50 transparency obligations (published on 20 July 2026, “the Guidelines”) are clear that satisfying one limb without the other does not comply (Guidelines paras. 69–70). And the obligation falls on the provider, whereas Article 50(4), which governs deep fakes, binds deployers. So it applies only where two things coincide: an AI system that generates synthetic content, and a company as its provider. Section 3 takes the first, Section 4 the second.
Article 50 applies from 2 August 2026. Generative systems placed on the market before that date have until 2 December 2026 to bring their Article 50(2) marking and detection into line, under a grandfathering rule added to the AI Act by the Digital Omnibus (new Article 111(4)), now published in the Official Journal and in force ahead of the 2 August application date. Outputs generated before 2 August 2026 need not be marked retroactively (Guidelines para. 154). Breach carries the AI Act’s second-highest fines: up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher, and the lower of the two for SMEs (Article 99(4)(g), (6)).
3. Which systems Article 50(2) reaches
Start with what triggers the duty, because it is broader than the debate suggests and turns on function, not scale. Article 50(2) is triggered by any AI system that generates or manipulates synthetic audio, image, video or text. All four modalities count, and so does content that mixes them. What the system is built on, and how capable it is, does not matter.
Two common misreadings narrow it. It is not the same as being a general-purpose AI model: that is a different thing at a different layer, defined by its generality across many tasks (Article 3(63)) and carrying its own obligations under Article 53. Article 50(2) does not require you to have, or to provide, such a model. Modify the model itself, a substantial fine-tune being the classic case, and you may instead cross onto the model layer and become the provider of a general-purpose AI model, a separate and heavier regime. And the system need not be general-purpose at all: a narrow, single-purpose tool that generates synthetic content is caught just the same (Guidelines paras. 57–58): a single-domain image generator or a voice tool is not general-purpose, yet each plainly produces synthetic content.
Against that broad trigger, three groups of output need no marking:
- Standard editing (Guidelines paras. 90–92), where a system merely assists standard editing or does not substantially alter the input or its meaning. Grammar, spellchecking, cropping and minor colour correction were always outside. The final example list now adds AI translations of text, face pixelation and blurring, and transcription. What changes substance stays in: AI-generated summaries, paraphrase that shifts meaning, added or removed objects, synthetic voices of real people.
- Output no human is meant to perceive (Guidelines paras. 64–68): machine-to-machine outputs, source code, short symbol strings, and content used only inside closed production loops, which the final text extends beyond film to “film, animation, games or advertising production” (Guidelines para. 68). The intermediate that never leaves the pipeline is not marked, the final synthetic output is.
- Narrow feasibility and proportionality reliefs (Guidelines paras. 86–88): output sealed inside a closed physical product it cannot leave, such as a vehicle navigation system; strictly technical output confined to a pre-defined professional circle and safeguarded against external sharing, public and consumer-facing systems aside; and ephemeral, immediately-consumed content such as in-game or virtual-reality generation, where marking is not feasible and users are told in-experience.
The first two groups sit outside the duty, the third is within it but excused. For a company building a tool, the question each time is the same: is this an output I must mark?
4. When building on a model makes you the provider
Article 50(2) is owed by the provider and no one else. Under Article 3(3), a provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. Having a tool built for you can satisfy the development limb, but you are its provider only if you also put it into service under your own name. Putting into service extends to supply for your own use (Article 3(11)), so a tool rolled out to your own staff, with no external customer, qualifies.
The decisive element is development. A new, distinct system exists only where something is developed, by you or on your behalf, around the model. Calling a model through an API is therefore not, in itself, the dividing line: the mere user and the provider reach for the same endpoint, and what separates them is whether a distinct system has been developed and put into service under one’s own name.
Whether a build amounts to a new system is a matter of degree. Two examples mark the ends of the range:
- A thin interface over a finished system. A company reaches a model already offered as a usable system (a chatbot, or an API that returns finished output), wires a thin interface to it, and passes prompts in and responses out. Nothing new has been developed: an interface is not itself an AI system, since it infers nothing. The company is using the provider’s system: it is a deployer, and the Article 50(2) duty rests with that provider.
- A workflow built in-house. A company builds an agentic workflow with a purpose of its own, has it plan and act across the company’s systems, wraps it in guardrails and retrieval over internal documents, and calls an LLM by API as one step among several. Whether this amounts to a system of its own always turns on the detail, but a build of this kind will, on its face, look like a distinct AI system the company has developed and put into service under its own name, in which case the company is its provider and owes the duty, internal use included (only the agent’s perceptible outputs are covered, not its internal reasoning or machine-directed actions, Guidelines para. 63).
Most builds fall between these poles, and there the threshold is a case-by-case question: has a distinct AI system been developed, or merely an interface to someone else’s? Even a comparatively thin build can fall on the provider side and make the company the downstream provider the AI Act contemplates (Recital 133). This is the plain Article 3(3) route, not the Article 25 role-shift, which applies only to high-risk systems.
5. What compliance requires
For a provider, compliance with Article 50(2) is a substantial technical and governance undertaking. On technique the Guidelines are neutral: a single technique or a combination will do, so long as the overall solution, assessed as a whole, meets the four statutory criteria (Guidelines paras. 72, 80). The Code of Practice on Transparency of AI-Generated Content (the “Code”) binds only its signatories and, following the Digital Omnibus, confers no presumption of conformity (Digital Omnibus Recital 41; Article 50(7) as amended). On the concrete implementation, however, it is highly instructive, and it carries strong evidential weight for non-signatories too. It sketches what an adequate solution looks like: two machine-readable layers, signed metadata plus an imperceptible watermark (Code, Measure 1.1), alongside a free detection route (Code, Measure 2.1) and an audit-ready compliance process (Code, Measure 4.1). A provider taking its own route will in practice be measured against that benchmark.
The duty runs only “as far as this is technically feasible”, and the Guidelines make that test objective: it is measured against the technology available within the specific architecture and operational environment, not against the provider’s resources, so an architectural impossibility can excuse where mere expense cannot (Guidelines paras. 81, 85). For free-form text, the Code expects a watermark alone (metadata is impossible), from 200 tokens up (Code, Measure 1.1), and detection may be limited to verified expert users (Code, Sub-measure 2.1.2). On detection generally, the Guidelines steer providers to industry-standard tools, accepting an own or shared tool only transitionally (Guidelines para. 76), and require the provider to ensure any third-party detection complies (Guidelines para. 78). Under the Code, signatories must have a watermark-detection interoperability solution in place by 2 February 2027 (Code, Measure 3.4). For a provider building on a model it does not control, much of this can come from upstream.
6. Relying on the model provider’s marking
The provider need not apply the mark itself. The generative work happens inside a model the provider neither built nor controls, reached through a third party’s API, with no obvious place at the model layer to embed a watermark. The regime therefore lets the mark sit where the generation does. Recital 133 of the AI Act records that marking may sit at the level of the AI system or of the model, and the Guidelines let a provider rely on marking implemented by an upstream model provider or a third party, but only “to the extent that the marking solution is compliant with Article 50(2)”, and “without prejudice to the responsibility of the provider … to demonstrate compliance” (Guidelines para. 74). Reliance is permitted; responsibility is not transferable. Three things follow. Reliance is not assumption: you must verify that the upstream marking meets the standard, through the model card, the provider’s documentation and your own testing, and be able to show that you did. And the mark may simply not be there: model providers are for now only encouraged, not required, to mark at model level (Guidelines para. 27). Whether a conforming mark exists upstream is a procurement question: a model whose marking already conforms, contractual representations, a right to verify. The same extends to detection, the duty’s other limb: a provider may lean on the upstream’s detection route just as on its mark, but the responsibility remains its own, and detection must be available to those exposed, human-readable, at the latest when a person sets out to verify the content (Article 50(5), Guidelines paras. 75, 77).
Whether reliance works is, today, chiefly a question of modality. For images, machine-readable marking is close to an industry convention: cryptographically signed C2PA metadata paired with an imperceptible watermark, applied broadly at model level after a cross-industry convergence in May 2026. Video follows at a short distance, and audio is partly covered. For free-form text, by contrast, the upstream offer is thinnest. One major model provider now embeds a text watermark in its consumer products and is previewing detection tooling, but comparable marks across the wider market remain sparse, and whether a watermark is applied on the API route, the one that matters to a downstream provider, was still unconfirmed as of late July 2026. The picture moves week to week, so monitoring it is itself part of compliance. Where no conforming upstream mark yet exists, free-form text today, the provider needs a considered position. Section 7 sets out the routes, matched to what the upstream delivers.
7. Three routes to meeting the duty
A system provider in the middle of the value chain, without control over the model it builds on, has three ways to meet the duty, none of them a safe harbour. Which one fits depends on what the upstream actually delivers:
- Rely where the market delivers. Where the upstream mark exists, the task is the Section 6 discipline of verifying it, contracting for it and securing a detection route, whether the upstream’s or your own. That is the closest the market comes to a settled position.
- Mark at the system level yourself. Signed metadata on every file or container is plain application logic within your control, and post-hoc watermarking of image, audio and video is available, including from specialists. The Guidelines now name post-hoc marking at system level as a value-chain point where the solution may sit (Guidelines para. 74). For free-form text this is precisely what is missing: post-hoc text watermarking has not reached the generally acknowledged state of the art the Guidelines take as the yardstick (Guidelines para. 83), and free-form text carries no metadata to sign.
- Implement the feasible maximum and document the limit, where the first two do not reach: metadata wherever a container allows, a queryable logging or fingerprint registry, a working detection route and a reasoned, dated file explaining where the architecture ends. That file must answer the point a supervisor will press first: both the Code and the Guidelines name post-hoc marking as a recognised technique, so the provider has to show why, for text, it currently fails the statutory criteria, and revisit that as the technique matures (Guidelines para. 83). None of this makes the position “green”. It makes it a considered one with a dossier behind it, which is what an objective feasibility standard rewards.
8. What to do and what to watch
For an in-house team the sequence is short. Inventory the AI systems in use across the organisation, including those built only for internal use. For each that generates synthetic content, apply the Section 4 test, and where the company is the provider, sort the outputs by modality and map them to the routes in Section 7. (Separately, Article 50(1)’s disclosure duty for interactive systems applies from 2 August 2026 with no transition, Guidelines para. 153.) On the Code of Practice, decide deliberately whether to sign, align or document an equivalent. The Guidelines call it the only Union-wide recognised framework for demonstrating compliance (Guidelines para. 146).
One task stays continuous: monitoring what the upstream models actually mark, and confirming with the model provider directly whether the mark is applied on the API route, since that is what a provider may lean on. As the major providers converge on how they mark and detect, their approach will become the benchmark against which everyone building on their models is measured. The companies most exposed remain those that have not yet realised the rule is theirs.
For further information, please contact:
Oliver Belitz, Partner, Bird & Bird
oliver.belitz@twobirds.com
