EU AI Act Article 50 in Practice: What ProvStamp Needs to Actually Deliver

Five months to August

August 2, 2026 is when the bulk of EU AI Act obligations take effect. I wrote about this in week 1, the date is still live. The Digital Omnibus rumours of deferral have not materialised into anything formal.

For ProvStamp specifically, I want to be clear about what we’re targeting: Article 50 transparency requirements. Not the high-risk AI system obligations (those require a whole separate compliance programme). Article 50 is focused on disclosure, if AI generated it, that needs to be surfaced.

Let me work through the four Article 50 requirements and what they mean in practice:

1. AI systems interacting with humans must disclose they’re AI. Chatbots, voice assistants, automated social media accounts. The disclosure needs to happen before the interaction or at least at the start. This is a UX/product requirement more than a cryptographic one, ProvStamp doesn’t help much here. It’s about interface design.

2. Emotion recognition and biometric categorisation must notify users. Relevant to specific verticals (HR, retail, security). Not our focus.

3. Deepfakes must carry machine-readable watermarks and be labelled. This is exactly what C2PA content credentials address. A deepfake video signed with a C2PA manifest declaring c2pa.ai_generative as the creation method, with a visible disclosure label, satisfies this requirement technically. The signed manifest proves the claim hasn’t been tampered with after the fact.

4. AI-generated content that could mislead must be disclosed. Broader than deepfakes, applies to text, images, audio. The “could mislead” qualifier is doing a lot of work and hasn’t been fully defined in implementing regulations yet.

What ProvStamp needs to be

After working through the spec in week 3 and thinking about this for a month, here’s what the API needs to cover for the August use case:

Core signing endpoint. Accept an asset (image, video, audio, eventually text), attach a C2PA manifest declaring AI generation metadata, return the signed asset. The manifest includes: creation tool, model used if known, creation date, signing certificate chain.

Verification endpoint. Accept an asset (or a URL), extract and validate the C2PA manifest chain, return a trust status and the provenance metadata. This is what a downstream platform or regulator uses to verify a disclosure claim.

Certificate management. The trust chain needs to be valid. We need to be a properly certified entity in the C2PA trust hierarchy, not using self-signed certs. This means getting a certificate from a CA that participates in the C2PA trust list, Adobe’s CAI implementation and the broader C2PA trust programme are the relevant paths.

A disclosure label generator. Separate from the cryptographic signing, but practically necessary: a visible “AI generated” label overlay or metadata badge that can be embedded in the asset for human-readable disclosure. Article 50 requires the disclosure to be accessible to users, not just machine-readable.

What’s still unclear

The text content problem I noted in week 3 hasn’t gone away. C2PA handles files. Text output from an LLM (a paragraph, a summary, a generated report) doesn’t fit cleanly into the spec. The Commission’s implementing regulations will presumably address this, but they haven’t. For now ProvStamp will handle image, video, and audio. Text provenance we’ll document as a gap with a proposed approach.

Also unclear: enforcement mechanism. The EU AI Act creates obligations but enforcement is delegated to member state market surveillance authorities. How aggressively they act in the first year is genuinely unknown. That said, building on the assumption of weak enforcement is bad risk management.

Build plan

Rough sequence for ProvStamp before August:

1. Core sign/verify API, end of March
2. Certificate authority integration, April
3. Disclosure label generator, May
4. Documentation + compliance mapping (which article, which requirement, how addressed), June
5. Beta with one or two enterprise customers, July

That’s tight. The CA integration is probably the hardest dependency, it’s not purely within our control.

Side note on the week

The Moxel prefetching numbers came back cleaner this week. Running Mixtral 8x7B across 4x 3090s with prefetching: ~23 tokens/second at batch size 1, up from ~11 without. Still not close to NVLink-connected hardware, but the gap is narrowing. Planning a proper writeup next week.

Also moved all AuvaLabs project repos and research documentation to GitHub this week. Most of the work has been running on internal infrastructure until now, so the GitHub activity starts here. The research itself goes back to January, documented in these notes, but the repos are new. ThreatWatch and PhishRig are public. Everything else stays private for now.

---

Next week: Moxel 4-GPU benchmark writeup, and the first results from the LLM phishing A/B test I’ve been setting up in PhishRig.