Article 50(2) of the EU AI Act reads like a labelling requirement. In practice it is a question about your export path, and the answer is usually that you have more export paths than you remembered.
The obligation itself is short. Providers of AI systems generating synthetic audio, image, video or text "shall ensure that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulated" — qualified by technical feasibility, the cost of implementation and the generally acknowledged state of the art. It applies from 2 August 2026 under Article 113.
The part that catches people is Article 111(4): a system already placed on the market before that date has until 2 December 2026. That paragraph is marked in the Act Explorer as added by amendment — it was not in the text most people read in 2024, which is exactly why a deadline that is not 2 August comes as a surprise. If you shipped a generator before August, December is your real date.
The obligation lands on files, not on features
We assumed we had done this. The server-side render wrote the claim into the container with encoder metadata flags, and generated images carried it in their own metadata chunks. Both were correct and both had been correct for a while.
Then we followed the file a founder actually downloads.
Our video is composed and recorded in the browser, not on a render farm — the animation is captured from the page itself and encoded locally. That path never touched the server encoder, so it never touched the marking code. The export most people use was the one export that was unmarked, and it stayed that way precisely because the other two were done and made the problem look solved.
The generalisable lesson is that the audit is not "do we mark our output". It is "list every way a file leaves this system, and check each one". Ours:
| Export path | Container | Marked before the audit | Marking mechanism |
|---|---|---|---|
| Server-side render | MP4 | Yes | ffmpeg -metadata at encode |
| Studio image generator | PNG | Yes | tEXt chunk |
| In-browser recording | MP4 | No | XMP uuid box, appended after encode |
| In-browser recording | WebM | No | None available — reported as unmarked |
| Developer test-fixture script | MP4 | No | XMP uuid box, appended after encode |
Three of five were unmarked, and the one most founders actually use was among them. The developer script mattered more than it looks, because test output has a way of ending up in a deck.
Browser encoders give you nowhere to put it
The reason the in-browser path was unmarked is not negligence. MediaRecorder, the browser API that records a canvas, has no metadata hook at all: you get encoded chunks and you assemble them into a file. There is no field to set.
So the marking has to happen after encoding, on the container. That leaves two options and only one of them is safe.
The unsafe one is to splice the claim into moov, where a file's standard metadata lives. That means recomputing the chunk offsets in stco or co64 that point at the media data, and a mistake there does not produce an unmarked video, it produces a corrupt one. Getting a compliance detail wrong is recoverable. Handing a founder a broken export on launch day is not.
The safe one uses a property of the format. An MP4 is a flat sequence of typed boxes; a reader walks them by their declared sizes, and ISO/IEC 14496-12 requires it to skip any box type it does not recognise. The uuid box is reserved for precisely this kind of extension, and the XMP specification fixes one UUID for an XMP packet in ISO base media files:
BE7ACFCB-97A9-42E8-9C71-999491E3AFAC
Append a uuid box carrying that identifier and an XMP packet after the final box, and nothing before it moves. ftyp, moov and mdat are untouched, so playback and seeking are untouched. ExifTool reads it, Adobe tooling reads it, and C2PA validators read it, because it is a real interchange format rather than a string we invented.
Write the vocabulary other people read
The temptation is to append a sentence saying the file was AI-generated and call it machine-readable. It is greppable, which is not the same thing.
There is a controlled vocabulary for this. IPTC's digital source type registry publishes a term for media generated by a trained algorithm, and the full IRI is what goes in the packet:
http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia
That exact IRI is what C2PA, Google's "About this image" and the major stock libraries key on. Using it means a detector that has never heard of your product still classifies the file correctly. Using your own wording means only you can read your own claim, which satisfies the letter of a requirement about machine readability while missing its point entirely.
Signed content credentials are the stronger version of this and the eventual target. They need a signing identity and a certificate, which is a procurement problem rather than an engineering one. Unsigned metadata in the standard vocabulary is what is available today, and it is a real improvement over nothing.
Say what you could not mark
WebM has no append-safe extension point. Matroska offers no equivalent to the uuid box, and rewriting EBML in the browser was possible in principle and risky in practice, so we did not. The function returns a marked: false flag rather than handing back the blob as though the job were done, and the caller has to decide what to do with that.
In practice the exposure is small and shrinking: Chrome 126 and later give us MP4 and the recorder already prefers it, so WebM is the fallback for browsers that cannot do H.264. Small is not zero, which is why it is in this post.
That honesty has a cost — there is a real file type we hand over unmarked — and it buys the thing that matters more. A compliance claim that is true of four paths and quietly false of the fifth is worse than a narrower claim that holds everywhere, because the first one fails exactly when someone checks.
What it does not require
It does not require a visible watermark. Machine readability and visible labelling are different obligations, and this one asks for the first. Our exports carry no visible mark and the promise that they do not is unaffected.
It does not require you to hold a record of what was generated, or to phone home when a file is opened. The claim travels inside the file and nothing about it reports back.
And it does not change what a founder may do with what they generate. Marking describes how the file was made. It grants us nothing over how it gets used.
Compliance work is the least glamorous thing in a product and the easiest to defer into a quarter where it becomes urgent. This one took an afternoon once we stopped assuming and started listing exit points. If you want to see the export path this describes, the launch video generator is free and needs no account, and the reasoning behind what we ship is written down.
Last reviewed 21 September 2026.