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.

5 min readSume
All posts

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.

Article 50(2) summary (read 2026-10-03)
ElementWhat it says
WhoProviders (of systems that generate synthetic outputs)
WhatMark outputs in machine-readable form, detectable as artificially generated
Quality barEffective, interoperable, robust and reliable, as far as technically feasible
ExceptionAssistive 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

All Use cases posts

Written by Sume