Article 50(2): the provider duty to mark AI outputs machine-readably
Article 50(2) makes providers mark synthetic outputs in machine-readable form. What the wording says, what is exempt, and what to ask a generator vendor.

Article 50(2) says providers must mark synthetic outputs in a machine-readable format so they are detectable as artificially generated. The solutions must be "effective, interoperable, robust and reliable as far as technically feasible". An exception covers assistive editing functions that do not substantially alter the input.
The wording in brief
The article text on the linked site is the source. This table is shorthand.
| Element | What it says |
|---|---|
| Who | Providers (of systems that generate synthetic outputs) |
| What | Mark outputs in machine-readable form, detectable as artificially generated |
| Quality bar | Effective, interoperable, robust and reliable, as far as technically feasible |
| Exception | Assistive standard editing that does not substantially alter the input |
Provider or deployer
Article 50(2) is a provider duty. If you use a generator through its API and publish the results, you are generally on the deployer side, and Article 50(4) sets separate duties for deepfakes and certain text. That split is why the first question for any workflow is which role you hold, and that depends on how you build and offer your product.
If you wrap a generation API in a product you offer to others, the role question gets harder. That is a question for counsel, not a table.
What to ask a generator vendor
Ask in writing how outputs are marked, which formats carry the mark, and what happens after a trim or re-encode. Sume's public docs reviewed for this post describe generation, trimming and routing, and do not describe a marking mechanism, so direct that question to Sume support and keep the answer on file. The video trim docs state that trim re-encodes by default, which is the kind of step that can change embedded metadata.
Marks that live in file metadata do not always survive editing. Marks that live in the pixels or audio are designed to survive more, with their own limits. Ask which kind you have.
- How is each output type marked: video, image, audio?
- Does the mark survive a trim, resize or re-encode?
- How can a third party detect it?
- Which version of the code or standard does the vendor follow?
Keep your own records
Whatever the vendor does, keep your own job IDs, prompts and dates per clip. If a mark is lost or a question arises, your records are the evidence you control.
Questions that stay open
The phrase "as far as technically feasible" leaves room for judgement, and the code of practice is where that judgement is spelled out. Read it for the techniques it names and how it treats re-encoding.
Marking in one place is rarely enough. A robust approach tends to combine several signals, and a team that downloads files, re-encodes them and re-uploads them may drop some of them. Whether a mark remains is something you can test, as the C2PA post in this batch describes.
Until the vendor answers in writing, assume nothing about marking, keep your own records and apply your own labels where the deployer duties require them.
Sources
Related posts
More in Use cases
- Article 50(2) assistive editing: trim and crop vs generate
Article 50(2) exempts assistive editing that does not substantially alter input. Sort your Sume outputs into generated and file-processed before you rely on it.
- Clean a transcript with a 2,000-character instruction, then caption
ElevenLabs speech to text can edit a transcript from a natural-language instruction up to 2,000 characters. A cleanup then captions workflow with Sume captions.
- Article 50: creator duties vs provider duties, side by side
Article 50(4) puts deepfake and certain text disclosure on deployers, while 50(2) puts marking on providers. A two-column split for teams that publish AI video.
- Demand Gen carousels: 2 to 10 matching cards from one reference
Demand Gen carousels take 2 to 10 cards. Image assets run 4:5 or 9:16 at 5 MB. How to batch matching cards from one reference image with the Sume image API.
Written by Sume