AI5 min read

What an AI Image Metadata Check Actually Proves

EU AI Act Article 50(2) asks providers to mark AI output so machines can detect it. What a metadata check proves, what it cannot, and a free tool.

Abstract editorial illustration of a flat image plane with a ribbon of metadata trailing from its edge, dissolving into empty space past a small blue seal

Disclosure first. I am the co-founder and CTO of PiktID, we build On-Model, a generative imagery platform for fashion e-commerce, and the checker I link at the end is ours and free. I am writing this because the underlying question confused us for a while, and the explanation seems worth having on its own.

What Article 50(2) actually asks for

Article 50(2) of the EU AI Act asks providers of generative AI systems, which includes us, to mark output in a machine-readable format so it can be detected as artificially generated. It has applied since 2 August 2026.

In an image file, a machine-readable mark means one of two things in practice:

  • C2PA Content Credentials. A cryptographically signed manifest describing what made the file and what was done to it afterwards.
  • IPTC DigitalSourceType in XMP. A single field naming the content as, for example, trainedAlgorithmicMedia.

Both live in metadata. That one fact is where most of the confusion starts.

A missing mark proves less than it looks like

Metadata is fragile. A CDN re-encode, a screenshot, a social upload or a pass through an image editor will strip it, and none of those steps announce themselves.

We found some of our own marketing images had lost their mark, because our compression step was dropping XMP. Nobody removed anything on purpose. The pipeline just did what pipelines do.

So a file with no mark tells you one thing: this file has no mark. It tells you nothing about whether the image was generated, and nothing about whether the provider did their job.

A present mark proves less than it looks like

A manifest is bytes, and anyone can write bytes. Nothing stops someone from attaching a manifest that claims an AI image came out of a camera.

We tested the weaker version of the same problem: sign a file, alter the pixels afterwards, leave the manifest untouched. Anything that only parses the claim reports the file back as authentic. The signature has to be verified, and the verification has to cover whether the pixels still match what was signed.

An IPTC field is weaker still. It carries no signature at all, so it is an unsigned assertion by whoever wrote it.

Some marking is invisible to any metadata tool

SynthID and the watermarks like it live in the pixels, not in the file header. An image can be fully compliant through a pixel watermark and show nothing at all in a metadata reader.

A blank result is therefore never proof that a provider failed to mark its output. Anyone telling you otherwise is selling something.

That makes it a good instrument for auditing a catalogue you own, and a bad thing to wave at a regulator on its own.

The checker

on-model.com/ai-image-checker

Free, no signup, and it runs entirely in your browser, so the image bytes never leave your machine. Drop in a folder, get a verdict per image, export a CSV if you need to hand something to legal.

Where a file carries Content Credentials, it runs the official C2PA validator in the browser and reports whether the signature holds, who signed it, and whether the pixels still match what was signed. It does not check that signer against an official trust list, because fetching the list would mean talking to a third party and breaking the promise that nothing leaves your browser. So it can tell you a signature is intact and who claims to have made it. It cannot tell you that the claimant is who they say they are.

It reads metadata. It is not a pixel-level "is this AI?" detector and it does not pretend to be.

Easy to build, easy to build wrong

Davide, a colleague of mine, built the first version of this. I refined it and shipped it on the On-Model site. The whole thing was vibecoded in an afternoon, which is sort of the point: the hard part was never the parsing.

When we tested our version against the official c2pa-rs reference fixtures, several cases came back confidently wrong. A foreign APP11 segment read as Content Credentials. A manifest that had been stripped after signing read as present. A source type mangled out of its CBOR encoding. Each of those produces a clean, plausible looking verdict that happens to be false, which on a compliance tool is worse than returning nothing, because at least nothing leaves you knowing that you do not know.

Every one of those cases is a test now. That is the part I would copy if you build your own: not the parser, the fixtures.

If you run a catalogue of generated images, point it at a sample of what you actually ship. The interesting result is not the files that come back marked. It is the ones you were sure were marked and are not.

eu-ai-actc2pametadatacompliancegenai