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: a provider of an AI system that generates synthetic audio, image, video or text has to ensure the outputs are marked in a machine-readable format and detectable as artificially generated. It came into force on 2 August 2026. The part that catches people is Article 111(4): a system already on the market before that date has until 2 December 2026. If you shipped before August, December is your deadline, and it is nearer than the August headline suggested.
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 were: the server render, the image generator, the in-browser recording, a standalone document export, and a developer script for test fixtures. Three of the five were unmarked. 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, it is that the recording API has no metadata hook. 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 rewrite the file's index so the claim sits in the standard metadata location. That means recomputing the byte offsets 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 it is required to skip any box type it does not recognise. There is a reserved box type for exactly this kind of extension, and the metadata standard fixes a known identifier for carrying a metadata packet inside one. Appending that box after the last existing box cannot disturb anything before it. Playback and seeking are untouched because nothing they depend on moved.
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 — a published term meaning media generated by a trained algorithm — and it is what the provenance ecosystem keys on. Using it means a detector that has never heard of your product can still classify 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
One format in our export set has no append-safe extension point. Rewriting it in the browser was possible in principle and risky in practice, so we did not, and the function reports that the file came back unmarked rather than returning it as though the job were done.
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 18 September 2026.