The EU AI Act Deadline Did Not Move for You: What Developers Have to Ship by August 2026

In June 2026, most engineering teams saw the same headline: the EU delayed the AI Act.

They read the first paragraph, noted that high-risk obligations had slipped to 2027, and moved the whole thing back down the backlog. That was a reasonable reaction to an unreasonable headline, because the delay was real. On 29 June 2026, the Council gave its final green light to the Digital Omnibus, and the obligations for stand-alone high-risk systems moved from 2 August 2026 to 2 December 2027. For AI embedded in regulated products, they moved to 2 August 2028.

Here is what the headline left out. Article 50, the transparency chapter, was not postponed. It applies from 2 August 2026, and it is the part of the AI Act that touches the largest number of ordinary software products. Not medical devices, not credit scoring, not CV screening. Chatbots. Support assistants. Agents. Anything that produces synthetic text, images, audio, or video.

If your product does any of that and has users in the EU, you have a shipping deadline, and the penalty ceiling for getting it wrong is 15 million euro or 3 percent of worldwide annual turnover, whichever is higher.

This article is not legal advice, and I am not a lawyer. It is the translation I wanted when I first read the regulation: which paragraphs of Article 50 turn into code, which turn into copy, which turn into logging, and which do not apply to you at all.

What Actually Moved, and What Did Not

The confusion is worth resolving precisely, because the two dates ended up in the same news cycle and got merged into one.

The AI Act was always designed to apply in stages. The Digital Omnibus, agreed provisionally in May 2026 and finalised at the end of June, shifted some of those stages and left others exactly where they were.

The single exception carved out of Article 50 is narrow and worth knowing if it applies to you. The Omnibus granted a grace period on the technical marking requirement in Article 50(2), running to 2 December 2026, and it applies only to generative systems that were already on the market before August 2026. Anything you place on the market on or after 2 August 2026 gets no grace period at all. And the grace period does not touch the deployer-facing duties in Article 50(4), which land on the original date regardless.

So the practical read is this. If you are building a high-risk system in the Annex III sense (recruitment, credit, education, essential services, and so on), you genuinely bought eighteen months. Everyone else building ordinary LLM-powered software bought nothing, and the clock is running.

First, Work Out Which Role You Are In

Article 50 assigns different duties to different roles, and half the confusion I have seen comes from teams reading a paragraph that was never addressed to them.

A provider is whoever develops an AI system and places it on the market or puts it into service under their own name or trademark. A deployer is whoever uses an AI system under their own authority in a professional capacity.

The instinct among engineering teams building on top of OpenAI, Anthropic, or Google is to assume that the provider is the model vendor and that they themselves are just a deployer with lighter duties. That instinct is usually wrong.

If you take a foundation model, wrap it in your own system prompt, your own tools, your own retrieval layer, and your own interface, and you ship that to users under your company's name, you are the provider of that AI system. The model vendor is the provider of the underlying general-purpose model, which carries its own separate obligations. Yours do not disappear into theirs.

This matters because the two paragraphs that require actual engineering work, 50(1) and 50(2), both bind providers. The paragraphs that bind deployers, 50(3) and 50(4), are mostly about disclosure at the point of publication.

A quick way to place yourself:

Most teams reading this will land in the first two rows, which is why the rest of the article spends most of its time there.

Article 50(1): The Chatbot Rule

The text is short. Providers must design AI systems intended to interact directly with natural persons so that those persons are informed they are interacting with an AI system.

That is it. Tell people they are talking to a machine.

The interesting part is the exception, and the interesting part of the exception is how narrow the Commission decided it is. The obligation does not apply where the interaction is obvious "from the point of view of a natural person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use."

Teams love this exception. It feels like a way out. It is not, and the final Guidelines the Commission adopted on 20 July 2026 make that fairly clear by reading it narrowly. A few things that are worth internalising:

Naming your assistant something robotic is not disclosure. Calling it "AI Assistant" in the header is a good signal, but a product whose entire value proposition is that it sounds human is not one where AI interaction is obvious. The more capable your conversational layer, the weaker your claim to the exception. That is an uncomfortable inversion: quality of experience reduces your legal cover.

Context resets the clock. A user who knows the widget on your pricing page is a bot may not know that the follow-up email, the voice call, or the WhatsApp thread is the same system. Each surface is its own first interaction.

Voice is the hard case. A synthetic voice on a phone line is exactly the scenario the paragraph exists for, and it is the scenario where the "obvious" argument is weakest and getting weaker every model release.

The Agent Twist

This is the part that caught most teams by surprise, and it is specific to 2026.

The Guidelines confirm that agents fall inside Article 50(1) where they are capable of interacting with the person instructing them or with other natural persons while carrying out their tasks. And they push the requirement further than the chatbot case: an agent must disclose both its artificial nature and the person on whose behalf it is acting.

Think about what that means architecturally. If you have built an agent that sends emails, books appointments, negotiates with a supplier's system, or opens support tickets on a user's behalf, the disclosure is no longer a banner in your own UI. It has to travel with the agent, into channels you do not own, and it has to carry identity: this is an AI, acting for this principal.

That is a design requirement, not a copy change. In practice it means the agent's outbound messages need a consistent, structured signature, and the identity of the principal needs to be part of the agent's context rather than something assembled ad hoc per channel. If you are already building on MCP or a framework like the OpenAI Agents SDK, the natural place for this is the same layer that assembles the system prompt and tool definitions, so that no outbound path can be added later that bypasses it.

What This Looks Like in Code

The requirement is boring to implement and easy to get subtly wrong, mostly by making the disclosure a property of one screen instead of a property of the system.

Bad:  a line of copy in the chat widget's React component
Good: a disclosure the transport layer cannot send a message without

Concretely, the pattern that holds up is to make disclosure a required field of whatever object represents a conversation channel, so that adding a new channel forces someone to answer the question.

type Channel = {
  id: string
  // Not optional. Adding a channel without answering this
  // should not compile.
  aiDisclosure: {
    text: string          // "You are chatting with an AI assistant."
    principal: string     // required for agents acting on behalf of someone
    shownAt: 'first-interaction'
  }
}

The point is not the specific shape. It is that a type error is a much better compliance control than a checklist item in Notion.

Article 50(2): Machine-Readable Marking of Synthetic Output

This is the paragraph that turns into real engineering work, and it is the one most teams underestimate.

Providers of AI systems that generate synthetic audio, image, video, or text must ensure the outputs are marked in a machine-readable format and detectable as artificially generated or manipulated. The standard is that the solutions be effective, interoperable, robust, and reliable as far as is technically feasible, taking into account the specificities and limitations of different content types, the cost of implementation, and the generally acknowledged state of the art.

Two words in that sentence do a lot of work. Machine-readable means a visible "generated by AI" caption does not satisfy the obligation on its own. And as far as technically feasible is the acknowledgement, written into the law, that this is genuinely hard for some content types.

The Exception That Covers More Than You Think

Article 50(2) does not apply where the AI system performs an assistive function for standard editing, or does not substantially alter the input data provided by the deployer, or the semantics of that data.

This is a real exception with real scope. On the safe side of the line sit grammar and spell checking, style suggestions, format conversion, compression, minor cropping, colour correction, and dust spot removal. Tools that make human-authored content cleaner without changing what it says.

On the other side sit translation, summarisation, composite imagery, adding or removing objects, face pixelation, and anything that changes meaning. If your feature rewrites a paragraph, it is in scope. If it fixes the comma in the paragraph, it is not.

The word "substantially" has no case law behind it yet, and it will be litigated. If your product sits close to the line, the honest engineering answer is to mark anyway. Marking costs you very little; being wrong costs 3 percent of turnover.

How to Actually Mark Content

The Commission's Code of Practice on transparency of AI-generated content, published in June 2026, is voluntary, but following it is currently the cleanest way to demonstrate compliance. It does not point at a single technology. It describes a layered approach, and the layering exists because every individual technique is defeatable.

For images, video, and audio, the practical baseline today is C2PA manifests written at generation time, plus a watermark for resilience, plus your own log. If you generate through a hosted API, check what the provider already attaches, because several attach provenance metadata by default and you may only need to stop stripping it in your pipeline. If you self-host open-weight models, nothing is attached for you and you write it yourself with the C2PA SDKs.

Text is where this gets genuinely unresolved, and it is worth saying so plainly rather than pretending otherwise. Watermarking short text is close to impossible: there is not enough entropy in a two-sentence answer to carry a robust signal, and any paraphrase destroys what signal there is. The regulation's "as far as technically feasible" qualifier is doing heavy lifting here. For text, a defensible position today is provenance metadata where the text travels as a file or a structured API response, a documented and consistent approach, and a clear record of why stronger marking is not currently feasible for your content type. Documenting the reasoning is part of the compliance posture, not an excuse for skipping it.

One pipeline detail that catches people out: marking at generation is useless if your own processing strips it. Thumbnail generation, image optimisation, CDN transforms, and re-encoding all routinely discard metadata. If you add C2PA at the model boundary and then run every asset through an optimiser that rewrites the file, you have shipped nothing. This is worth an actual integration test.

generate() -> mark() -> [ resize, optimise, CDN transform ] -> deliver()
                              ^
                        verify the manifest survives this

Article 50(3): Emotion Recognition and Biometric Categorisation

Short paragraph, narrow scope, and it binds deployers rather than providers.

If you operate an emotion recognition system or a biometric categorisation system, you must inform the people exposed to it that it is running, and you must process their personal data in line with the GDPR. The law enforcement exception applies where such use is authorised by law.

Most product teams reading this are not in scope, and the sensible move is to confirm that quickly and move on. The cases where teams are in scope without realising it tend to involve sentiment analysis on video or voice in call centres, attention or engagement scoring in ed-tech and retail analytics, and biometric attribute inference in identity flows. Note the boundary: text sentiment analysis on a support ticket is not emotion recognition in the Article 3 sense, which is concerned with inferring emotions from biometric data.

Article 50(4): Deepfakes and Public-Interest Text

This paragraph binds deployers, meaning the organisation publishing the content rather than the vendor whose model produced it. There are two distinct duties inside it.

Deepfakes. A deployer of an AI system that generates or manipulates image, audio, or video content constituting a deep fake must disclose that the content has been artificially generated or manipulated. Where the content forms part of an evidently artistic, creative, satirical, fictional, or analogous work, the obligation softens: you disclose the existence of the generated content in a manner that does not hamper the display or enjoyment of the work. The Guidelines read those categories narrowly, and content that is purely informative or commercial does not get the softened treatment. A synthetic spokesperson in an advertisement is not satire.

Text on matters of public interest. A deployer publishing AI-generated or AI-manipulated text for the purpose of informing the public on matters of public interest must disclose that it was artificially generated. The exception is significant: the duty does not apply where the content has undergone human review or editorial control and a natural or legal person holds editorial responsibility for the publication.

Read that exception carefully, because it rewards a workflow rather than a technology. If you run an AI-assisted newsroom or content operation with a named human accountable for what ships, you are outside the obligation. If you run an unattended pipeline that publishes to a news section, you are inside it. The compliance boundary is whether a person owns the output, which is close to what an editorially serious team would do anyway.

Note also the scope limit. This duty is about text informing the public on matters of public interest. Your product changelog, your marketing page, and your support macros are not that.

Article 50(5): How and When You Have to Say It

The mechanics paragraph, and the one most likely to turn an otherwise compliant product into a non-compliant one on a technicality.

Information required by the paragraphs above must be provided to the people concerned in a clear and distinguishable manner, at the latest at the time of the first interaction or exposure, and it must conform to applicable accessibility requirements.

Three engineering consequences:

"At the latest at first interaction" rules out disclosure-on-request. A bot that admits it is a bot when you ask it is not compliant. The disclosure precedes or accompanies the first exchange.

"Clear and distinguishable" rules out burying it. A line in your terms of service is not disclosure. Grey 10px text under the input box is a defensible target for a regulator who wants to make an example of someone.

Accessibility is not optional here. The disclosure has to reach screen reader users and people using assistive technology. In practice that means real text in the accessibility tree, not an image, not a CSS pseudo-element, and an aria-label or live region that announces it rather than a purely visual badge.

What This Adds Up To in a Codebase

Stripping out the legal framing, a team shipping an LLM product to EU users has roughly six things to build or verify. None of them are large. The failure mode is not difficulty, it is that no one owns them.

1. A disclosure that is structural, not cosmetic. Attached to the channel abstraction, present on every surface, impossible to add a new surface without.
2. Agent identity propagation. If agents talk to anyone outside your UI, the artificial nature and the principal travel with the message.
3. Marking at the generation boundary. C2PA manifests plus watermarking for image, audio, and video, written where output leaves the model, not bolted on per feature.
4. A pipeline test that provenance survives. Assert the manifest is still present after your optimisation and CDN path, in CI.
5. A generation log. What was generated, by which model and version, when, for which user. This is your evidence if anyone asks, and it doubles as the substrate for the tracing and evaluation work you should be doing anyway.
6. A written record of your reasoning. Which paragraphs you concluded apply, which exceptions you are relying on, and why marking is or is not technically feasible for your content types. A one-page decision document, versioned in the repo next to the code.

That last one deserves emphasis, because engineers tend to skip it. The AI Act's transparency regime is enforced by national market surveillance authorities, which means the intensity of enforcement will vary across member states and the first cases will come from the more active regulators. In that environment, a documented, reasoned position is worth considerably more than an undocumented correct one.

There is also an uncomfortable overlap worth flagging: your disclosure text is part of your system's output surface, and output surfaces are attack surfaces. If a user can talk your assistant into denying that it is an AI, you have a compliance problem produced by prompt injection. The fix is the same as it always is, which is that the disclosure must not be something the model can be argued out of. It belongs in the UI layer and the transport layer, not in the system prompt.

Where the Model You Chose Matters

One practical dependency worth checking before August: your provider's behaviour on marking.

The obligation in 50(2) sits on you as the provider of your system, but what your upstream model already does affects how much you have to build. Hosted image and video generation from the major vendors increasingly attaches provenance metadata by default. Open-weight models running on your own infrastructure attach nothing.

That turns into a real input to model selection, alongside the usual cost, latency, and capability trade-offs. A self-hosted open-weight stack is often the right call for cost or data residency, and it is entirely workable here, but it moves the marking work onto your team. Budget for it rather than discovering it in late July.

The same reasoning applies to the general-purpose model obligations that have been in force since August 2025. Those bind the model provider, not you, but if you are fine-tuning and redistributing a model you may have inherited more of that role than you assumed. Worth a conversation with whoever handles contracts.

What Comes Next

Two dates to put in the calendar after August.

2 December 2026. The Article 50(2) grace period ends for generative systems that were already on the market before August 2026, so the marking obligation becomes universal. The new prohibitions on AI systems generating non-consensual intimate imagery and child sexual abuse material also take effect, added to Article 5 by the Omnibus.

2 December 2027. The high-risk obligations for stand-alone Annex III systems, which is what actually got delayed. If you are anywhere near recruitment, credit, insurance, education, essential public services, or employment decisions, this is your date, and eighteen months is not as long as it sounds when it involves risk management systems, data governance, technical documentation, logging, human oversight design, and conformity assessment. Teams treating December 2027 as a snooze button in July 2026 will be the ones scrambling in mid-2027.

If your organisation is at the earlier stage of working out where AI belongs in its processes at all, the sequencing question is worth thinking through properly before the compliance question, and I wrote about how to integrate AI into business processes without disrupting everything separately. The short version as it relates to this article: knowing which of your use cases could become high-risk classified is a design input, not a legal afterthought, and it is much cheaper to answer before you build.

The Honest Summary

The AI Act's transparency rules are, on the whole, not unreasonable. Tell people when they are talking to a machine. Mark content your machine generated. Say who your agent works for. Most of it is what a team with decent instincts would do without being told.

What makes this deadline awkward is not the substance. It is that the delay headline gave a lot of teams permission to stop reading, the Commission's final Guidelines landed on 20 July with less than two weeks to spare, and the marking technology for text is genuinely behind what the regulation asks for.

If you do one thing this week, work out which of the five paragraphs apply to your product and write the answer down. That exercise takes an afternoon, and for most teams it ends with a short list: a disclosure that needs to move from a component into the channel layer, a marking step that needs to move to the generation boundary, and a test that proves your CDN is not quietly stripping it all.

That is a sprint, not a quarter. The teams that will have a bad August are the ones still assuming the deadline moved.

Building production AI systems? I write regularly about applied AI engineering, system architecture, and the real lessons from production deployments. Find me on LinkedIn or reach out directly at [email protected].