Visible Label or Machine-Readable Marking? What Article 50 Asks of Each

Teams reading Article 50 for the first time usually come away with one obligation in mind and pick a technology for it. The provision contains two, they sit on different parties, and they are satisfied in different places: one inside the file, one on the face of it.

Two obligations on two parties, and neither discharges the other

The trigger, the party, the medium and the moment all differ. The only thing they share is a chapter. Which of the two is addressed to you depends on the role question worked through in Provider or Deployer?.

What machine-readable marking means in practice

The provision names no technology, and that is deliberate. Recital 133 supplies the menu instead:

• Watermarks, including imperceptible signals embedded in the content itself.
• Metadata identifications, written into the file’s own fields.
• Cryptographic methods for proving provenance and authenticity of content. C2PA Content Credentials are the best-known implementation of this category.
• Logging methods, recording generation events outside the file.
• Fingerprints, deriving an identifier from the content.

Recital 133 also permits a combination, and allows the technique to be implemented at the level of the AI system or the underlying model, “including general-purpose AI models generating content, thereby facilitating fulfilment of this obligation by the downstream provider of the AI system”. A downstream provider building on a model that already marks its output inherits some of the work.

The standard is qualified rather than absolute. “As far as this is technically feasible” and “the generally acknowledged state of the art” both appear in the text, which matters because no current marking technique survives every transformation.

When the provider’s marking duty does not apply

Article 50(2) removes itself in two situations written into the provision: to the extent the AI system performs an assistive function for standard editing, or does not substantially alter the input data provided by the deployer or the semantics of that data. Recital 133 frames both as proportionality measures.

The Commission’s FAQ adds output types it treats as outside the duty:

• Short sequences of numbers, symbols or letters.
• Source code.
• Machine-to-machine output.
• Closed-loop industrial output, unless it is the final output.
• Output where the system provided standard editing assistance.

The line between “assistive standard editing” and generative alteration is the one that will be argued about. Adjusting exposure, straightening a horizon or removing sensor dust changes how an image looks. A generative fill that adds an object changes what the image depicts, and the semantics limb becomes hard to lean on.

Why a deployer cannot point at the provider’s watermark

This is the single most consequential point on this page, and it is stated directly in the Commission’s guidance rather than inferred: a deployer subject to the Article 50(4) disclosure cannot simply rely on the machine-readable marking embedded in the content by the provider under Article 50(2).

The reason sits in Article 50(5). The information has to reach the natural persons concerned “in a clear and distinguishable manner at the latest at the time of the first interaction or exposure”. A cryptographic manifest does not reach a person looking at a picture. The Commission puts the test as understandable and perceivable by natural persons, for example through visible or audible labels, without needing specific technical tools or dedicated actions.

So a compliance position resting on “our image model watermarks everything it produces” answers a question that was addressed to the model vendor. It leaves the deployer’s own obligation untouched.

The converse holds too. A visible label placed by a deployer does nothing for a provider’s Article 50(2) duty, which asks for something software can detect.

What survives a re-upload, and what does not

Durability is where the two mechanisms diverge most sharply in practice, and it is worth being concrete because the theory is misleading.

Pixels survive; metadata often does not. Many platforms re-encode uploaded images, resize them and strip EXIF, XMP and similar fields in the process. That behaviour predates the AI Act and is usually about file size and privacy rather than provenance. The effect is that a disclosure carried only in metadata can disappear between upload and display, with nobody intending it.

Neither survives a determined edit. Cropping removes a corner label. Re-screenshotting removes a manifest. Recital 133’s “as far as this is technically feasible” is an acknowledgement of exactly this.

This is also why the Commission’s icon guidance asks for the label to be directly embedded into the content so that it remains visible if the content is reshared or downloaded, rather than rendered as a page element beside it. Where to put it once it is embedded is covered in Where Should an AI Disclosure Label Go on an Image?.

Where EU Labels sits, stated plainly

EU Labels renders a disclosure label into the image pixels. That addresses the perceivability side: the mark is part of the picture, so it travels with ordinary downloads and re-uploads.

It does not add C2PA Content Credentials, embedded watermarks, or any other machine-readable provenance marker. Re-encoding a JPG or PNG may also not carry over existing metadata such as EXIF, so if you depend on metadata already in your files, check an export before running a batch.

Two consequences follow, and both are worth stating rather than leaving to be discovered. If you are a provider with an Article 50(2) marking duty, a visible label does not discharge it. And if you already receive C2PA-signed output from your model vendor, adding a visible label does not remove that signature from the original file, but the re-encoded export is a new file and should not be assumed to carry it.

Doing both

For an organisation holding both roles, the two obligations run in parallel and are discharged in different parts of the pipeline.

1. At generation, the provider’s marking obligation attaches. If you build the system, this is yours. If you buy it, this is a question for your vendor, and a reasonable one to ask in procurement.
2. At publication, the deployer’s disclosure obligation attaches, on the content that meets the Article 50(4) trigger.

Neither Article 50 nor the Commission’s guidance prescribes a technology on either side, so the choice of marking technique and the form of the visible disclosure are both yours. What the text does fix is that the two obligations are answered separately, and that discharging one leaves the other exactly where it was.