What binds on 2 August 2026

The EU AI Act — Regulation (EU) 2024/1689 — has a staggered enforcement calendar that the May 2026 Digital Omnibus reshuffled. The prohibitions in Article 5 bound on 2 February 2025. The high-risk system obligations in Annex III now bind on 2 December 2027 (postponed from 2 August 2026 via the Omnibus). Embedded products covered by EU sectoral safety law follow on 2 August 2028. AI systems already on the market before the Act came into force are subject to retrospective obligations from 2 August 2030.

The dates that most current deployers and GPAI providers need to plan around fall in 2026:

2 August 2026. Articles 51–56 GPAI provider obligations enter formal enforcement. The obligations themselves became applicable 2 August 2025; this is the date the AI Office's enforcement powers and the penalty regime begin biting. Most of Article 50's transparency obligations on providers and deployers also become applicable.

2 December 2026. Article 50(2)'s machine-readable marking obligation for synthetic content — audio, image, video, text generated by AI — becomes effective. The Omnibus negotiated this date as a compromise between the Commission's proposal (early 2027) and Parliament's preference (November 2026). It is the only Article 50 paragraph the Omnibus delayed.

Read together, the back half of 2026 is when the EU AI Act stops being principally a forward-looking compliance program and starts producing actual enforcement events against companies whose business models depend on AI. The maximum penalty for non-compliance is €35 million or 7% of worldwide annual turnover, whichever is higher, for prohibited practices under Article 5; €15 million or 3% for non-compliance with most other obligations including Article 50; €7.5 million or 1% for information-related failures.

This post is about what to ship before those dates. It is not legal advice. It is a practitioner reading of what survives an audit, written by people who run signed-receipt infrastructure for AI inference in production.

Are you a provider, a deployer, or a downstream user?

The first question to settle, before you read another paragraph of the regulation, is which of three roles you occupy. The Act assigns obligations differently to each.

A provider is the legal or natural person that develops an AI system, or has an AI system developed, and places it on the market or puts it into service under its own name or trademark (Article 3(3)). For GPAI models specifically, the provider is whoever trains the model and makes it available — OpenAI, Anthropic, Mistral, Google, Meta, the open-weights labs.

A deployer is the legal or natural person using an AI system under its authority, except where the AI system is used in the course of personal non-professional activity (Article 3(4)). If your company integrates a third-party LLM into a product, an internal workflow, or a customer-facing decision flow, you are a deployer of that LLM. Almost every EU company using AI in production right now is a deployer, not a provider.

A downstream user is informal language sometimes used to describe a deployer who is several steps removed from the model — for example, a SaaS customer using a feature that internally calls an LLM. In the regulation's terms, that company is still a deployer; the obligation runs to whoever is using the AI system under its own authority for its own purposes.

The decision-tree practical version:

You train and release foundation models → GPAI provider. Articles 51–55 apply heavily.
You take a third-party LLM and call it from your product, your internal tools, or your customer-facing flows → deployer. Article 50(3) and 50(4) apply if your use is in scope. Article 50(1) and 50(2) cascade upstream — your provider has to satisfy them, but your contractual posture probably needs to confirm they have.
You buy a SaaS product that has AI inside it → still a deployer of that product, even if the AI is invisible to you. The regulation does not relieve you of obligations because the AI is implemented by your vendor.

Most readers of this post will be deployers. The next two sections are written with that audience in mind, with provider-specific obligations called out as they arise.

What Article 50 actually requires

Article 50 is titled "Transparency obligations for providers and deployers of certain AI systems". It runs four operative paragraphs.

Article 50(1) — Providers shall ensure that AI systems intended to interact directly with natural persons are designed and developed such that the persons concerned are informed they are interacting with an AI system, unless this is obvious from the circumstances. The trigger is "intended to interact directly". A customer-service chatbot triggers it. A back-end inference service that scores a transaction does not, because there is no direct interaction.

Article 50(2) — Providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video, or text content shall ensure the outputs are marked in a machine-readable format and detectable as artificially generated or manipulated. This is the watermarking obligation. The Act does not specify the watermarking technique; that is being settled in technical standards (CEN-CENELEC JTC 21, ISO/IEC) and in the AI Office's anticipated guidance.

Article 50(3) — Deployers of an emotion-recognition system or a biometric-categorisation system shall inform the natural persons exposed to the system. The trigger is the existence of the system in the deployer's environment, not whether output of the system is shown to the user.

Article 50(4) — Deployers of an AI system generating or manipulating image, audio, or video content constituting a deep fake shall disclose that the content has been artificially generated or manipulated. The same paragraph extends to text published to inform the public on matters of public interest, with exceptions for editorial control.

Two things to notice about how Article 50 is structured.

First, the obligations on providers (50(1) and 50(2)) and on deployers (50(3) and 50(4)) operate on different layers. The provider's obligation runs at the design layer — the system has to be built such that disclosure happens. The deployer's obligation runs at the deployment layer — the deployer has to actually disclose, regardless of what the provider built. A deployer cannot escape an Article 50(3) obligation by saying "the provider should have surfaced that". The obligation runs to you.

Second, "inform" and "disclose" are not the same. Article 50(1) says "informed they are interacting with an AI system" — that can be a chatbot greeting. Article 50(4) says "shall disclose that the content has been artificially generated or manipulated" — that requires per-piece-of-content marking, in a way the recipient can act on.

The practical question for most deployers is whether their use of LLMs falls within Article 50(4)'s second clause — generating or manipulating text published to inform the public on matters of public interest. The text is interpretable. A press release written with LLM assistance probably triggers it. An internal Slack summary probably does not. A customer-service email that paraphrases AI output is in the grey zone. The AI Office's guidance, when it issues, will narrow this; until then, the conservative reading is to assume disclosure obligations apply to any AI-generated public-facing text and to design accordingly.

What Articles 51–55 add for GPAI providers

Articles 51 through 56 — together called Chapter V — are the GPAI provider obligations. They became applicable 2 August 2025, but the AI Office's enforcement powers and the formal penalty regime begin only on 2 August 2026. Practitioner version: the rules have been in force for nine months, but the day the regulator can fine you for ignoring them is 2 August 2026. The headline obligations:

Technical documentation of the model (Article 53(1)(a) + Annex XI), kept up to date and made available to the AI Office and competent authorities on request.
Information for deployers (Article 53(1)(b) + Annex XII) — what downstream deployers need to integrate the model lawfully into their own AI systems.
Copyright compliance policy (Article 53(1)(c)) — written policy on how the provider's training respects EU copyright law including text-and-data-mining opt-outs (Directive 2019/790 Article 4).
Training-data summary (Article 53(1)(d)) — a sufficiently detailed summary of the content used for training, made publicly available. The AI Office is expected to publish a template.

For models with systemic risk — currently the presumption under Article 51(2) is models trained on more than 10^25 floating-point operations of compute, though the threshold is revisable — Article 55 adds further obligations: model evaluations including adversarial testing, systemic-risk assessment, incident reporting to the AI Office, and cybersecurity protections.

Most companies reading this post are not GPAI providers. They are buyers of GPAI models. The relevant question for them is not "do we satisfy Article 53"; it is "does our chosen GPAI provider satisfy Article 53, and what does our deployer-side documentation need to look like to depend on theirs". That question becomes contractually load-bearing once 2 August 2026 passes.

"Notification" isn't enough — the evidence gap

The most common failure mode in deployer-side Article 50 readiness is treating it as a notification-copy task.

A team reads Article 50, asks "what do we have to disclose", and produces three things: a banner in the chatbot UI saying "You're chatting with an AI assistant", a line in the privacy notice listing the AI vendors used, and a policy memo saying disclosure-content-generated-by-AI applies to public press releases. They consider Article 50 closed.

This is not wrong, exactly. It is necessary. It is also, on its own, insufficient.

The reason becomes clear in an investigation scenario. A regulator under Article 74 — a competent authority for market surveillance — asks the deployer to demonstrate that disclosure was made for a specific incident. A user complains they were not informed they were talking to an AI. The regulator wants to see the record.

The deployer can produce the policy. The deployer can produce the privacy notice. The deployer can produce the chatbot's UI banner.

What the deployer cannot produce, in most current setups, is the per-inference record showing that on the specific date, in the specific session, with the specific user, the disclosure was rendered, the model invocation happened against a specifically-versioned upstream provider, and the response was actually attributable to that model rather than to a content moderation rule.

That gap is the Article 50 evidence layer. Notification copy is the surface. Per-inference signed evidence is what survives an investigation.

The same gap maps onto Article 50(2)'s machine-readable marking obligation. A regulator can run a detector against a piece of synthetic content. If the marking is absent or has been stripped, the deployer's defense is "we marked everything we generated; this content predates that policy / was generated by a system other than ours / was modified after generation". Each of those claims requires evidence. A signed receipt produced at the moment of generation is evidence. A policy document that says "we mark our content" is not.

What ships today vs what's required

Almost every team running LLMs in production today has logging. The logs typically capture timestamps, request IDs, and structured payloads. They live in a log aggregator. The retention policy is "until storage gets expensive".

Article 50 raises the bar in three specific ways:

Tamper-evidence. Logs that can be quietly rewritten by the operator are not evidence. A regulator's investigation under Article 74 will treat operator-controlled logs as a starting point, not a conclusion. The Act is non-prescriptive about technique; what survives is anchoring — cryptographic signing at the moment of inference, public timestamping, transparency-log inclusion proofs. None of these are mandatory under the Act. All of them are practical answers to "how do we know your engineers didn't quietly change a record after the complaint came in".

Per-inference resolution. A log that aggregates "12 million inferences served in March" does not satisfy an investigation about a specific user's specific session. The required granularity is one record per inference, with stable identifiers linking the record back to the input the user submitted. Most LLM applications today produce records at this granularity in their primary log; few do so in a way that survives operator compromise or that can be exported to a regulator on request.

Cross-linkage. Article 50(1) (provider's design obligation), Article 50(2) (provider's marking obligation), and Article 50(4) (deployer's disclosure obligation) interact. A deployer's disclosure has to point to a specifically-versioned upstream model. The upstream model's marking has to be present in the response. The deployer's record has to link the disclosure event, the model invocation, and the marked output as a single causal chain.

A logging stack that produces independent records of each step but does not link them with stable identifiers leaves the deployer in the position of saying "we believe this disclosure refers to that inference, which we believe used that upstream model" — when what they need to be able to say is "here is the cryptographically anchored record showing all three together".

A 12-week practical path

Eighty-five days from today is enough time for most teams to close the gap on the August 2026 obligations, on the assumption that the team is not also building the underlying inference platform. (For Article 50(2) machine-readable marking, the timeline is roughly thirty weeks until 2 December 2026 — different shape, similar engineering.) The path:

Week 1 — Decide your role. If you are a deployer (most readers), enumerate every place in your product or workflow where an LLM is called. For each, classify the call as Article 50(1) (interactive with users), Article 50(2) (synthetic content generation), Article 50(3) (emotion or biometric categorisation), Article 50(4) (deep fake or public-interest text), or out of scope. The list will be longer than expected.

Week 2 — Map the disclosure surface. For each in-scope call, document where the disclosure to the user happens, in what form, on what trigger. Audit whether the disclosure is actually rendered to every user (mobile clients, embedded views, API consumers). Find the gaps.

Weeks 3–4 — Map the evidence surface. For each in-scope call, document what record is produced today. Audit: is the record anchored? Is it tamper-evident? Does it link the disclosure, the model invocation, and the output? Where the answer is no, scope a fix.

Weeks 5–8 — Ship the evidence pipeline. The cheap version is structured logging plus periodic anchoring (a daily merkle root committed somewhere durable). The robust version is a signed receipt per inference, anchored to a public transparency log at request time. The right choice depends on the deployer's risk profile and whether the use is in Annex III high-risk territory.

Weeks 9–10 — Rehearse the audit response. Pick five real inferences from the past month. Reconstruct, for each: what model served it, with what version, what disclosure was rendered, with what output, attributed to what causal chain. Whatever takes more than thirty minutes per case will fail under regulatory pressure.

Weeks 11–12 — Lock the contracts. If you depend on a GPAI provider, your contract has to cover their Article 53 documentation, their cooperation in your Article 74 investigations, and their technical support for your Article 50(2) machine-readable marking obligation. If your contract today says "we use OpenAI for AI features", it is not sufficient.

The teams who will land 2 August 2026 cleanly are not the ones who started in Week 12. They are the ones who started somewhere in this calendar before the deadline got close enough to panic.

Where Lucairn fits

Lucairn's gateway sits between your application and the upstream LLM provider. Every request that crosses the gateway emits a per-inference record that is signed by an in-process witness service using a key the upstream model never sees, timestamped against a public RFC 3161 timestamp authority, and anchored to a public Sigstore Rekor transparency log so that the inclusion proof itself becomes evidence the record existed at the timestamped instant.

This addresses three Article 50 readiness gaps directly. The record is per-inference, so deployers can answer Article 74 investigations at the right granularity. The record is anchored, so it survives operator compromise. And the record links the disclosure event, the model invocation (with specific upstream version), and the output, so the causal chain a regulator wants to trace is reconstructable.

Lucairn does not produce your Article 50 disclosure copy for you. That is your call, your voice, your privacy notice. Lucairn produces the evidence layer underneath, so that when the disclosure is challenged, the record exists.

We deploy in days for typical deployers. For GPAI providers needing Article 53 documentation infrastructure or Article 55 systemic-risk attestation pipelines, the work is larger; talk to us.

[The EU AI Act: from regulation text to deployment](/blog/eu-ai-act-architecture-2026) — full architecture mapping including the high-risk path under Annex III (which now binds 2 December 2027 post-Omnibus).
[Article 12 logging in practice](/blog/ai-act-article-12-logging-in-practice) — the companion article on the high-risk system logging obligation, which interlocks with Article 50's evidence layer.
[EU AI Act compliance landing](/compliance/eu-ai-act#gpai) — control-by-control mapping, including the Article 50 / GPAI section that this post expands on.
[Audit trail for AI](/audit-trail-for-ai) — the architecture deep-dive on how cryptographic anchoring works and why it survives an investigation.
[Compliance assessment](/compliance/assessment) — if you want a concrete read on where your deployment sits against the 2 August 2026 obligations, this is the way in.

Article 50 in 12 weeks: what GPAI providers and deployers must ship before 2 August 2026