Article 50 Lands in August: Machine-Detectable AI Provenance, and Why We Sign It At Source

By Micky Irons

There is a date now, and it is close. From 2 August 2026, Article 50 of the EU AI Act obliges providers and deployers of generative systems to make synthetic content transparent. Text, images, audio and video produced or manipulated by AI must be marked in a form that machines, not just people, can detect and attribute. The draft EU Code of Practice on AI-Generated Content, with a final version expected around June 2026, points at a specific technical pathway to satisfy that duty: C2PA Content Credentials. So the standard is no longer a debate. It is a deadline with a named mechanism attached.

Most organisations are about to discover that they are holding this problem at the wrong end. They generate content through a cloud API, get an artefact back, and then reach for a watermark or a credential to staple on afterward. That works until someone asks the only question that matters in an audit: can you prove this mark reflects what actually happened when the content was made? A credential applied after the fact is a label. It is not evidence. We built Mickai so that provenance is not a label you add later. It is a property of the act of creation itself.

What Article 50 actually asks for

Strip the legalese and Article 50 wants two things. First, machine-detectable marking, so that downstream platforms, regulators and other systems can identify AI-generated or AI-manipulated content without a human squinting at it. Second, attribution that survives, so the mark carries information about how the content came to exist and does not simply fall off when a file is re-saved or re-shared.

C2PA answers this by wrapping content in a cryptographically signed manifest. The manifest records what tool made the asset, what was done to it, and who stands behind the signature, and it is bound to the content so tampering is detectable. This is genuinely good engineering, and we are glad the draft Code names it rather than inventing a bespoke EU-only scheme. But a C2PA manifest is only ever as trustworthy as the process that produced the claims inside it. If those claims are generated by a cloud service you cannot inspect, on infrastructure you do not control, your provenance rests on somebody else's word.

We already sign every action, and C2PA is the same signature pointed outward

Here is the intersection nobody else is serving: model provenance plus on-premise ownership. Mickai is a sovereign intelligence operating system. Regulated organisations own it and run it inside their own walls, air-gapped where the workload demands it, and every action it takes is written to a cryptographically-signed audit record. That record is not a feature we added for this regulation. It is how the system was built to work, because a sovereign system that cannot prove what it did is not sovereign, it is just private.

So when a media desk, a legal team or a public-sector communications unit generates content on their own Mickai instance, the signed audit entry for that generation already exists: which model produced it, what prompt and inputs were involved, which policy applied, when, and under whose authority. Emitting a C2PA Content Credential is not a second, separate act of trust. It is the same signature, pointed outward. The manifest that ships with the file and the internal audit record that never leaves your walls are two views of one signed event. That is what we mean by signing it at source.

The practical difference shows up under pressure. When a regulator, a court or a platform integrity team challenges a piece of content, an organisation running Mickai does not have to reconstruct a story. It can produce the external credential and, if it chooses, the matching internal record, both signed, both from the moment of creation, both under its own key rather than a vendor's. Attribution stops being a claim and becomes a chain.

Why owning it is the honest position here

We are careful about how we frame the market, because the diligence matters. It is not true that regulated organisations are legally barred from cloud AI. DORA, the FCA and PRA, the EBA, the NHS DSP Toolkit and GDPR almost all permit cloud with the right controls. The genuine no-cloud bar is workload-specific: classified material at SECRET and above, ITAR-controlled data, isolated operational technology, and cases where a data protection impact assessment comes back negative. For the vast majority, the driver is preference, not prohibition. Sovereignty of control, cost, and the plain reluctance to let sensitive material leave the building.

Provenance is exactly where that preference becomes concrete. Under Article 50 you are being asked to sign a durable claim about content your organisation is accountable for. Doing that with a key you hold, on a system you own, using an audit record you can inspect, is simply a stronger position than trusting a marking function inside a service you rent. The signing key is yours. The manifest points back to you. Nothing about the moment of creation lives on infrastructure you cannot see. For the roughly 16,092 UK and EU institutions in the register-backed sovereign market, 7,933 regulated core and 8,159 in the large-private adjacency, that is the difference between compliance you can defend and compliance you have to hope holds. It is worth being plain that this is a preference-led market rather than a legal mandate, and provenance is one of the clearest places that preference pays for itself.

The patents behind the record

The signed-at-source architecture is not incidental. It sits inside our filed intellectual property. Mickai holds 104 UK patent applications spanning around 2,340 claims across 13 families, with Mickarle Wagstaff-Irons as named inventor, moving through the process toward examination and grant. Those filings describe how a sovereign system binds actions to a tamper-evident, cryptographically-signed record and how that record can be surfaced as external attestation without exposing the internal audit trail. When we say provenance is native rather than bolted on, that is what the filings contain, not a claim about what any office has yet granted.

The takeaway

Article 50 is not asking whether you can watermark a file. It is asking whether you can prove, in a form a machine trusts, how that file came to exist and who stands behind it. A credential added after a cloud API hands you an artefact answers the letter and misses the point. When the system that creates the content is one you own, and it signs every action as a matter of course, the C2PA Content Credential is not extra work. It is the same signature you were already making, now facing outward. That is the position we built Mickai to give you before the deadline, not after it.

Frequently asked questions

Does Mickai's approach satisfy Article 50 and the draft Code of Practice?

Article 50 requires machine-detectable marking and durable attribution for AI-generated content, and the draft Code of Practice names C2PA Content Credentials as a technical pathway. Mickai emits C2PA-compatible Content Credentials at the moment of generation, bound to the same signed audit record we write on every action. You hold the signing key, so the credential attributes back to your organisation rather than to a cloud vendor.

Why is signing at source better than adding a credential after generation?

A credential applied afterward is a label about content whose creation you cannot fully evidence. Because Mickai signs every action as it happens, the external credential and the internal audit entry are two views of one signed event. Under challenge you can produce provenance that reflects what actually occurred, not a reconstruction.

Do we have to run Mickai air-gapped to get this?

No. Air-gapped operation is available where a workload demands it, but the signed audit record and C2PA emission work on any owned Mickai instance inside your walls. The point is that the signing key and the record stay under your control. Cloud is not prohibited for most regimes, so this is about sovereignty preference and defensibility rather than a legal bar.

Is provenance tied to a blockchain or token?

No. Attribution rests on the cryptographically-signed audit record and C2PA manifests. On-chain attestation is an optional supporting capability for organisations that want an external anchor, and there is no token involved. The core guarantee is the signature at source.

Related reading from us: our work on the cryptographically-signed audit record on every action, our sovereign intelligence operating system architecture inside your own walls, and our filed patent portfolio of 104 UK applications.