Machine-readable marking of AI content: what providers must have arranged since 2 August 2026

Since 2 August 2026, providers of AI systems that generate synthetic audio, image, video or text must ensure the output is marked in a machine-readable format and detectable as artificially generated or manipulated. This follows from Article 50(2) of the AI Act and also applies to general-purpose AI systems (GPAI). The duty sits with the provider, not the party deploying the system. Generative systems that were already on the market before 2 August 2026 have a backstop: they have until 2 December 2026 to meet the marking requirement.

This page accompanies the explanation of Article 50 AI Act, with the provider and deployer split per paragraph. Below you will find what the marking duty entails, who carries it, which techniques qualify, what the code of practice of 10 June 2026 asks and which exceptions apply.

What does machine-readable marking entail?

Article 50(2) requires providers to ensure that the output of their generative AI system is marked in a machine-readable format and detectable as artificially generated or manipulated. So it is not a visible label for the viewer, but a signal that machines can read. The solutions must be effective, interoperable, robust and reliable as far as technically feasible, taking into account the specificities and limitations of the different content types, the costs and the state of the art.

That nuance matters. The law does not demand perfection, but it does require a serious effort that fits what is technically reasonable for the type of content concerned. Audio, image, video and text each have their own possibilities and limitations.

Who must mark?

The duty sits with the provider: the party that develops the generative AI system or has it developed and places it on the market or puts it into service under its own name, including providers of general-purpose AI systems. Not the organisation that then deploys the system, and not the end user.

The misconception that marking is a matter for the party publishing the content is exactly where organisations go wrong. Marking at the source is a design choice of the provider. Anyone integrating an external model into their own service is well advised to agree contractually that the provider takes care of this marking.

Which techniques qualify?

The law does not mandate a technique. Recital 133 gives watermarks, metadata, cryptographic methods for proving provenance and authenticity, logging and fingerprints as examples, or a combination of them. In practice a layered approach works best, because every single technique can be circumvented or has limits per content type.

The Code of Practice on Transparency of AI-generated Content of 10 June 2026 works out that layering. For images, audio, video and documents it asks for digitally signed metadata and an imperceptible watermark; for free text longer than 200 tokens a watermark. Fingerprinting or logging is only a supplement and never enough on its own. The code is voluntary; the law itself does not prescribe a specific technique.

In practice, marking falls short when it:

• consists only of metadata that is lost when saving or sharing;
• is a watermark that disappears with a simple edit;
• is not interoperable and is therefore not recognised by common detection tools;
• is not robust against normal processing of the file;
• does not follow a common standard, such as C2PA Content Credentials for provenance data.

Detection: can someone else check whether content came from your system?

Marking is half of paragraph 2. The output must also be detectable as artificially generated or manipulated. The draft code of practice of December 2025 already expected providers to offer an interface or detector for this, for example an API, with which users and other parties can check whether content was generated by their system.

That also makes Article 50 a testing and quality question. A detector is only useful if you know how often it is wrong: measure false positives and false negatives on samples and test robustness across distribution channels. A marking that survives your own platform but breaks when compressed, cropped or uploaded to social media is not robust.

Also look at your own chain. Not only the model can strip marks; video editing, image libraries, export functions and social media compression can too. An architecture review therefore looks at the model and at distribution. Test whether the marking survives compression, cropping and conversion, and record the result.

Which exceptions apply?

The duty is not absolute. It does not apply to the extent the AI system performs an assistive function for standard editing or does not substantially alter the input or its semantics, such as a spelling or grammar checker (guidelines, point 92). There is also an exception for systems authorised by law to detect, prevent, investigate or prosecute criminal offences.

These exceptions are powerful but require discipline. Anyone relying on the assistive editing exception must be able to explain why the system does not substantially alter the content.

Machine-readable marking versus visible deepfake disclosure

Two duties are often confused. Machine-readable marking under Article 50(2) sits with the provider and is a signal machines can read. The visible disclosure of a deep fake under Article 50(4) sits with the deployer and is aimed at the person seeing the content. A deployer cannot rely on the provider's marking for that disclosure. Anyone integrating an external model into their own service may face both and should agree contractually who handles what. More on the visible side is in making deep fakes recognisable.

What should you do now?

If your generative system was on the market before 2 August 2026, 2 December 2026 is the final date. If your system comes to market later, the duty applies immediately. Want to determine which obligation applies to your own use case? Walk through the Article 50 decision tree.